On Tue, Mar 10, 2009 at 6:08 PM, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > On Mon, 2009-03-09 at 20:22 -0400, Tom Lane wrote: >> "Patrick O'Callaghan" <pocallaghan@xxxxxxxxx> writes: >> > On Mon, 2009-03-09 at 12:49 -0700, Adam Williamson wrote: >> >> The most common CPU-bound operation in our world, I guess, is >> >> compilation, and you would notice a definite improvement in speed there, >> >> running x86-64 vs x86-32 - not huge, but noticeable. Certain database >> >> and I think scientific operations that are CPU-bound also derive a >> >> significant benefit. It depends on whether the code can take advantage >> >> of much bigger registers, AIUI. >> >> > Anyone who does even casual video processing (e.g. with transcode >> > filters) definitely will notice. This is something that pegs both cores >> > to 100% when I run it, until the fan kicks in and it slows a bit. >> >> It's not so much about *bigger* registers as *more* registers. The >> x86 architecture is incredibly register-starved (what comes of being >> bug-compatible with a 1971 CPU design...). When AMD did the x86_64 >> redesign they took advantage of the opportunity to define a more >> reasonable number of registers. Avoiding swapping values in and out >> to memory all the time is a large chunk of the reason for the >> performance boost in x86_64 code. It's not uncommon for x86_64 >> code to be physically smaller than comparable x86 code because of >> elimination of those extra instructions, even though the individual >> instructions tend to be wider. >> >> But I agree that a lot of people seldom do anything CPU-intensive >> enough to notice. > > Video encoding is also one of the few things that may get a boost from > the post-i586 instruction set enhancements (MMX, SSE, 3DNow!, all that > crap), which can't be used in i586 packages but are used in x86-64 > packages, as all x86-64 CPUs support them so it's safe. Most (almost all) video en/decoders have hand written asm code paths that are selected at runtime to take advantage of those instructions, so if you encode a video on a see2 capable machine sse2 will be used even thought the package is compiled for i586. > And yeah, Patrick, media encoding is probably the *second* most common > high-CPU-use scenario in our world :) It's probably the most common > scenario in the general set of computer users, actually. That's why > Intel is forever harping on it in commercials. Well anything crypto/compression related will see a boost from x86_64 see (unless you are limited by disk speed of course). -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
