Ubuntu 14.04 LTS 32-bit vs. 64-bit Performance

[whitecat]

PAE really really sucks.

For me it's morre interesting to see comparison of 8-16GB RAM system with PAE on 32bit vs 64 bit.

But PAE testing is good idea

PAE really really sucks.

The biggest single reason to go 64-bit is exactly
because of physical address space. Your virtual address
space needs to bea multiple of the physical one:
when you hit 1GB of RAM, 32-bit virtual memory is no longer
acceptable. You literally do need more virtual memory than
physical.

PAE turned that very simple fact on its head, and screwed
things up royally. Whoever came up with the idea was
totally incompetent, and had forgotten all the DOS HIGHMEM
pains. There's a damn good reason why we left the 286
behind, and started using 386's, instead of having HIGHMEM
crap with windows into a bigger physical space.

Repeat after me: virtual space needs to be bigger than
physical space. Not "as big". Not "smaller". It needs to
be bigger, by a factor of at least two, and that's
quite frankly pushing it, and you're much better off
having a factor of ten or more.

Anybody who doesn't get that is a moron. End of discussion.

[...]

So repeat after me: PAE didn't ever really fix anything.
It was a mistake. It was just a total failure, and the
result of hw engineers not understanding software.

So no, PAE does not mean that you can use more than
4GB of RAM. Even before PAE, the practical limit was around
1GB, and PAE didn't move that post a fraction of an inch!

http://www.realworldtech.com/forum/?threadid=76912&curpostid=76973

[stqn]

Can someone explain the +100% performance of a disk benchmark in 64 bit? Are the SSDs *faster* than the CPU and RAM now? (I don?t think so! This test of a 1st gen i7 shows a minimum RAM speed of 15GB/s.)

Also I wonder if Apache serving encrypted pages would be faster or slower, given the slowdown of Apache in 64 bit and the huge increase in encryption speed of openssl (just curious).

[philipmorris]

Well be nice see the impact of using 32 bits aplication inside a x86_64 enviroment. Like a 32 bit game.

[sarmad]

These benchmarks should also include memory usage.

[pinguinpc]

Good test

But PAE testing is good idea, on my case use 32bit distribution for wine, compiling is more easy (minor dependency conflicts), and mayor apps (32bit apps) run on wine

On my case mainly test games DX9

On my youtube channel

https://www.youtube.com/user/mrdeathjr28

[brent]

This is likely why there's so little interest in x32, it's a big win for benchmarks of linked data structures but not for 99% of real-world code written with even basic knowledge of performance issues.

You can also get most of the benefits of x32 without x32. Just use offsets into the heap instead of pointers. If you don't need access with byte granularity, you can address much more than 4 GB of memory this way with only 32 bit. The overhead of decoding offsets into addresses is quite low on modern CPUs. Oracle's JRE implements this, but it is also possible to implement this for performance/memory critical C/C++ code quite easily.

[imposeren]

Phoronix: Ubuntu 14.04 LTS 32-bit vs. 64-bit Performance

For those curious about the performance advantages of using 64-bit Ubuntu Linux over 32-bit Ubuntu on a modern Intel laptop, here are 32-bit vs. 64-bit benchmarks of Ubuntu 14.04 LTS on the ASUS Zenbook Prime.

http://www.phoronix.com/vr.php?view=20365

For me it's morre interesting to see comparison of 8-16GB RAM system with PAE on 32bit vs 64 bit.

[Azrael5]

programs' comparison are native 64bit?

[strcat]

I guess SSE2 has a lot to do with this (someone told me it is enforced by the compiler for AMD64, see quote), and also, those programs that are slower in 64b distros, are so because a process uses more memory than in a 32b system.
From 'man gcc':

Good benchmark, thank you very much.

x86_64 has twice as many general purpose registers and they're twice as large, so it can be significantly faster for some workloads. These workloads are usually numeric in nature (scientific computations, encryption, encoding). x86_64 does also have a higher base instruction set (including SSE2) but -march=native will take advantage of that and far more. If 64-bit integers are required as part of the core workload then it's going to be much faster, but the workloads tested here likely use 32-bit integers on 32-bit and 64-bit on 64-bit, by doing less work in each iteration on 32-bit.

The x32 ABI was created to get the performance wins from x86_64 without the cost of 64-bit pointers using up cache space. For linked data structures with a lot of pointers (2 or 3 pointers per element for a red-black tree) this can be a big issue, although usage of more modern cache-friendly data structures tends to avoid these. It's better to use hash tables or b-trees instead of red-black or avl trees and dynamic arrays or ring buffers instead of singly/doubly-linked lists when possible. There are edge cases where intrusive linked data structures can win, but not in the general cases. This is likely why there's so little interest in x32, it's a big win for benchmarks of linked data structures but not for 99% of real-world code written with even basic knowledge of performance issues.

[asdfblah]

I guess SSE2 has a lot to do with this (someone told me it is enforced by the compiler for AMD64, see quote), and also, those programs that are slower in 64b distros, are so because a process uses more memory than in a 32b system.
From 'man gcc':

Intel 386 and AMD x86-64 Options
[...]
For the i386 compiler, you must use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For
the x86-64 compiler, these extensions are enabled by default.

Good benchmark, thank you very much.