[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 64-bit Kernel Question

On Tue, Mar 10, 2009 at 6:08 PM, Adam Williamson <awilliam redhat com> wrote:
> On Mon, 2009-03-09 at 20:22 -0400, Tom Lane wrote:
>> "Patrick O'Callaghan" <pocallaghan gmail com> 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).

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]