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

[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.

[Linuxhippy]

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.

[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]

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

[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.

[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.

[multics]

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

[whitecat]

Pointers beeing 64-bit large is never a performance win

Not sure.
64-bit addressing can map all the memory in a sane way. With 32-bit addressing you have to use different indirections to map all the memory (especially with PAE) so it take CPU time to calculate this.

Because on 64 bit addresses are twice as long, therefore 'harder' to access.

I'm quite sure this is FUD!
Processors are natively 64-bit, so they must handle 64-bit address natively too. There is no reason that 64-bit address are slower to access. I even would say the contrary...

[energyman]

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

and with 'the late P4' you mean 'the latest iteration of P4s got 64 bit bolted on, much to the dismay of Intel when they were not able to hold back any longer and even the last one realized that Itanium was a dead end'.

[multics]

and with 'the late P4' you mean 'the latest iteration of P4s got 64 bit bolted on, much to the dismay of Intel when they were not able to hold back any longer and even the last one realized that Itanium was a dead end'.

Of course! :-)

I certainly didn't mean to say, that 64 bit computing entered the x86 realm /early/. ;-)
Alpha for example had 64bit from the start, IIRC. Around 1992.

Cheers