Ubuntu 12.10: 32-bit vs. 64-bit Linux Performance

[multics]

Intel calls it long mode in the CPU flags

Regular Phoronix readers will certainly know what CPU flag designates 64 bit. You may mention it anyway.
It is "lm" in the flags (less -p lm /proc/cpuinfo).

Btw, the late Pentium 4s had 64 bit back then. Looong ago.

Cheers

[energyman]

reeeeaaallly?

and you have some sources for that claim? because I read it here first....


and please - whoever mentioned x32 - forget it. As fast as you can. It was created by Intel to make Atom suck a bit less. Breaking all and everything just to make a crap CPU look better is NOT a good thing to do.

[bug77]

Is it theoretically possible for 32 bit to be superior to 64 bit for some workloads, and if so, what kinds? Or, if not, should we file bugs on software packages whose performance regresses when compiled for 64 bit?

If a piece of software uses pointers heavily (memory addresses for the uninitiated), there is a strong possibility it will run faster on 32 bit hardware. Because on 64 bit addresses are twice as long, therefore 'harder' to access. Techniques have been developed to use 32 bit pointers on 64 bit hardware when addressing less than 4GB, but even their use is slower than direct 32 bit access.

[Linuxhippy]

would it be possible to have 2 32bit operations done in parallel in one 64bit operation? would it be a software or hardware implementation?
Can anyone explain what these fingerprints are?

Usually this is what SSE2 is about - you can do multiple operations in one instruction (like 4x32bit operations) even on a 32-bit machine.
What makes x86_64 code usually faster is the higher amount of registers and to a limited degree the availability of 64-bit operations without using special registers.
Pointers beeing 64-bit large is never a performance win

lg

[jakubo]

would it be possible to have 2 32bit operations done in parallel in one 64bit operation? would it be a software or hardware implementation?
Can anyone explain what these fingerprints are?

[Linuxhippy]

Hmm

Unfourtunatly most of the benchmarks used are microbenchmarks usually not relevant for desktop systems.
Execpt for the encoding tests, but even though thats client-workload, is usually not something frequently done.

What I would be looking forward to, would be to have more dektop related tests like Firefox page parsing & rendering (and no, not again some meaningless javascript benchmark) or OpenOffice stuff.

[ayandon]

But just like good software engineering pushing such things through management may be hard

So true, they always want fast solution with quick fix, not the best solution.

very nice shearing with you.
let me know your Facebook ID.

[bridgman]

Reading up on the X32 ABI gives you another data point -- X32 exposes the AMD64 architectural extensions (eg more registers for the compiler to use) while staying with 32-bit pointers in most cases. If you don't need an address space that requires >32-bit pointers it gives you "best of both worlds".

[enteon]

Well thanks for supporting my conclusions (and for clarifying the automatic SIMDification)

[drago01]

Yeah sure, 64bit is better in some aspects than 32bit...but the opposite is also true.

In the end i will prefer always 32bit for compatibility issues with games....i had a bad enough experience with 64bit in a recent past to even consider it any time soon...

This has nothing to do with 32 vs. 64 bit but with your distro, x86_64 cpus can natively execute 32bit code, the rest is the job of your distro to get right.

I'm no expert on this, but I'd say it depends on your language and time available. In java you have almost no chance of optimizing for different hardware. C on the other hand allows you to do that. Both use compilers that are supposed to optimize. But creating a good compiler is one of the most difficult things to do for a programmer. Therefore you may want to not rely on the compiler for optimization, if you have the time and the time invested is less than the saved runtime.

But still there are algorithms that no compiler can optimize. It's your responsibility to choose the best algorithm for the data you are to compute. No compiler can ever do that (perfectly).

A compilers job is not to replace your bad algorithm with a good one but to create good machine code.

This includes (I believe, but don't have experience in it) the usage of x86 extensions, SSE units, AES units, even GPGPU (not x86 of course). You have to implicitly use these features, no compiler will add them automagically.

Not quite true either ... compilers do very well use SIMD extensions when producing code (auto vectorization) and for x86_64 they are free to use SSE2 because it is part of the ABI (runs on all CPUs). GPGPU is a different story.

As for languages like Java, Javascript and .NET it is the JIT compiliers job to produce efficient code. When working with such languages just make sure that your code uses sane algorithms ... you are not supposed to worry about machine level stuff when using them.