32-bit vs 64-bit: Performance

[Tsonn]

Following the 'why 64 bit' thread, I thought it might be a good idea to compile a list of what sort of performance differences people can expect, on a per-program basis.

Obviously this is complicated by different GCC versions, compiler flags, etc... but we should be able to give a general idea. For example, if you happen to be doing encoding using mencoder, using a 32-bit compile appears to give much better performance at the moment. A useful thing to know!

Code: Select all

Program                 Benchmark               32-bit/64-bit

 == Faster when 64-bit ==

boot                    same kernel, services   22s/20s
*compile                Firefox                 1382s/916s
*compile                xorg-x11                1812s/1298s
hdparm                  hdparm -Tt              1192 MB/s, 55.8Mb/s vs 1250MB/s, 55.8MB/s
bzip2-1.0.2             bzip an avi file        69.3s/60.3s
java                    bitwise ops on longs    39s/12s
java                    bitwise ops on ints     49s/19s
oggenc-1.0.1            encode song             17.5s/13.3s
PAN circuit simulator   see post #4             2-5% faster
POVRay                  render scene            1624s/1335s

 == No appreciable difference ==

gzip-1.3.3              gzip an avi file        9.2s/9.2s

 == Faster when 32-bit ==

*compile                kernel                  246s/254s
lame                    encode                  276s/294s
mencoder-1.0pre4.3.3.4  transcode/ffmpeg        ~160fps/~80fps
mplayer-1.0pre4-3.3.4   -benchmark/ffmpeg       18.3s/26.2s
xvid                    encode                  984s/>2400s

* Note that compilation tests are not comparisons of processing power, since
  compiles were with different flags and for different architectures!

[jeffroman]

once the source fully supports the new 64bit features, youll definately see performance increases. Especially so in encoding, ripping, downsampling, etc. anything processor intensive will eventually be faster on 64bit. just waiting on the source.

[Tsonn]

Yep. This would also be a good thread to mention any major advances in 64-bit optimisation

[gian]

comparison using our homebrew circuit simulator (32 bit vers. at brambilla.elet.polimi.it _only bin_)with a single benchmark ( a large 30K mos circuit, only DC operating point analysis)


compiled on AMD64 (gentoo amd64 gcc 3.3 -O3 ) it goes no more than 2 to 5 % faster than 32 bit version (Debian stable gcc 3.0 -O3 -fast-math), moreover the -fast-math option is safe in the 32bit version but totally unsafe on the 64 bit version... (NOTE: we still have some work to do ...)
...

[gian]

I (humbly) suggest that a performance comparison topic should be set sticky (just as the most appreciated "masked applications that work" topic)

[Tsonn]

Added

Hmm. Being a Java programmer, it's about time I compared Java performance...

[myuser]

Yes, more stuff like this would be excellent.

I think we all accept this is new ground, and it is very interesting to be around at the start of the 64Bit era as it starts to emerge into the mainstream.

[Fran]

Well, I made a small comparative some time ago in a spanish forum (Meristation). I think the results are easy to understand even for non-spanish people, but if you want I can translate .

[Tsonn]

Thanks ... I think I've added everything that wasn't on the list already, with the exception of 'Tiempo de carga'... perhaps you could translate that one?

(if I had to guess, it'd be 'boot time'...)

[gian]

if I get it right the comparison by fran was performed on the same machine, is that right ?

[Fran]

if I had to guess, it'd be 'boot time'

Well guessed . The boot services and kernels in both linuxes (x86 and x86-64) were the same when I made that comparative.

Kernel compilation time is not very indicative. Kernels are quite different from one architecture to the other. However, firefox and xorg-x11 compilation times are impressive in the x86_64 system, 30% faster than x86.

Lame and xvid are obviously optimized for x86. x86/assembly vs. x86_64/C is not a fair duel .

I still don't understand why I get better results in hdparm with x86_64 .

if I get it right the comparison by fran was performed on the same machine, is that right

Yep, its the same machine: Athlon 64 Newcastle 3200+, MSI K8T NEO FSR and 2x512 Kingston with Infineon chips DDR400 3-3-3-8.

[Sivar]

Other than certain apps which need to deal with big numbers (very few apps really need to deal with numbers greater than 4.3 billion), most of the performance improvement for AMD64 systems will come not from the fact that the CPU has 64-bit registers, but from the fact that it has twice as many of them. While x86 is often called a "register-starved" architecture, doubling the number of available processors is not really *that* big of a deal. It is largely responsible for the 10-15% improvement that most applications get. 10-15% is not very noticeable on most systems, and many applications get as good or better a boost by using the Intel compiler and running in 32-bit mode.

In my opinion, the primary reason to use an AMD64 chip is not yet the 64-bit GPR size, but the integrated memory controller. Many types of applications get a big boost from having an integrated, at-speed*, low-latency memory controller, and it is available whether running a 64-bit, 32-bit, or even 16-bit application.

*(while the memory controller usually runs at CPU speed, it uses a different clock and is not synchronized with the CPU core)

[Medah]

Would changing to gcc 3.4 be a big difference? and if so, is there any howto how to rebuild the whole system using gcc 3.4?

[gian]

declaring register variables is then a way to exploit amd64 vs 32bit x86s .... and I should obtain better performance in programs using intensive memory I/O...

[Tsonn]

Since I happened to be playing with cellular automata in java, I thought I'd experiment with using longs and bitwise operations to do the number crunching. Unsurprisingly, the 64-bit JRE was vastly quicker at it... almost four times quicker, in fact!

The JREs used were blackdown-jdk-1.4.2_rc1 on 64-bit and blackdown-jdk-1.4.1 on 32-bit.

To be fair, I suppose I should write a version using ints rather than longs and see how those compare. I'll keep you posted

[Tsonn]

It seems that the same amount of calculation done using ints instead of longs is again noticably faster on a 64-bit JRE. Maybe it's time to port those video codecs to java

[Zarathustra[H]]

Interesting.

I expected that many rendering and media applications would be faster on 64 bit platforms due to the compression algoriths probably being able to take advantage of the longer 64 bit numbers...

But then again, as Fran said, many of these applications have significant assembler optimizations for x86...


I wonder if we'll see any x86_64 assembler optimizations for these packages.


Also.. As sivar mentions, I have heard that the Intel compiler is a bit more efficient than GCC. Are we talking significatnly more efficient?

[LaNcom]

ICC is quite a bit faster than GCC. But it doesn't support AMD64 right now. I think the only real alternative for GCC on AMD64 would be Pathscale - it's fully mix-and-matchable with GCC and highly optimized for AMD64 (it should be the fastest compiler for current AMD CPU's). But it's quite expensive I'm afraid ($ 1495 for a 1 year subscription)...

See:
http://www.pathscale.com/performance.html

[Zarathustra[H]]

ICC is quite a bit faster than GCC. But it doesn't support AMD64 right now. I think the only real alternative for GCC on AMD64 would be Pathscale - it's fully mix-and-matchable with GCC and highly optimized for AMD64 (it should be the fastest compiler for current AMD CPU's). But it's quite expensive I'm afraid ($ 1495 for a 1 year subscription)...

See:
http://www.pathscale.com/performance.html

Interesting...


Now I don't hvae that kind of money to spend on a compiler for recreational use, but if I did....

is it possible to set it up to work with portage?

[LaNcom]

Don't know. I applied for a 30 day trial, but they didn't send me the link to download the demo, yet...


On another note, anyone want's to try MPlayer with 64bit assembler support? I just checked, it works and the patch is easier to apply then the old, crude hack. According to the dev, the patch doesn't use all availble registers yet...

See:
http://fixounet.free.fr/amd64/

UPDATE:
Pathscale just sent me the link and the license key. I'm currently trying to make that thing work and will do some tests later. It really seems to be fully compatible with GCC so far - it even uses the same flags, so almost any Makefile should work as is...

[Tsonn]

I've just moved to GCC 3.4... no major problems yet, although one or two (nonessential) packages refused to compile. The speed boost isn't bad; I've tested lame and mplayer, since they're both listed as better under 32-bit. Mplayer now manages 23.3s instead of 26.2s; I didn't do the lame benchmark listed, but it appears to be roughly 4% slower under 32-bit instead of 6.5% slower.

So, it definitely improves matters on the 64-bit side of things.

[slugworth]

I definatly like spending a couple hundered more for 32 more bits to enjoy waiting 600 less seconds for a compile xorg.

[adrin]

Hello,
I will install gentoo on my new box and would like to ask how is gentoo 64bit (EMT64/AMD64) performance compared to 32 bit's one?

[di1bert]

I found the performance better on 32it. I also had a few annoying issues with 64bit.

Personally I'm alot happier running 32bit on my laptop....

</0.02c>

-m

[Nephilim666]

I cannot comment on any speed difference, but I have no troubles using the 64bit version.
Everything is fine and dandy as long as you take the multilib profile and firefox-bin, if you need flash in your browser.

And since I got a 64bit cpu why shouldn't i make use of it?

Cheers!