1

I've been told that 32-bit Linux with a bigmem kernel (when the system has >=4GB RAM) will perform better than 64-bit Linux.

I'd love to define "perform better than" for you, but unfortunately the person who told me this didn't elaborate/justify.. hence this post!

Is there any truth to this at all? Any circumstance under which this would be true?

Thanks

3 Answers 3

3

in x86 processors, 64-bit code helps two ways:

  • bigger addresses let you access more memory directly (only relevant for processes that manage huge datasets)
  • more registers might let a compiler reduce memory accesses for tight variables (slight extra optimization, unnoticeable except in tight loops of highly optimized code).

and has the following cons:

  • more and bigger registers means more state to save/restore on every context switch.
  • bigger pointers means more RAM use and bigger structures, more data to read/write.

therefore, in a lot of cases, the best of both worlds is a 64-bit OS and 32-bit processes:

  • a 64-bit OS can handle lots of RAM, both to hold many processes and for big caches
  • 32-bit apps are limited to 2 or 3 GB RAM for each process, but it's enough for the vast majority of tasks.
  • no matter where in the 64-bit space a 32-bit task's RAM is located, it will only need 32-bit pointers to access its memory, so all pointers and data structures are still the smaller 32-bit variety.
  • a 32-bit task (process or thread) only have to save/restore the few and small registers available in 32-bit x86, the 64-bit Linux scheduler handles this case well.

but, in all, the advantage is seldom noticeable (just guessing it would be far less than 5%), so just go with 64-bit everywhere and get it all simpler.

the only case where i would definitely go with 32-on-64 is when doing OpenVZ-kind of isolation. That way each partition owner would make the most of the limited RAM he can access.

still, i don't know of any advantage of PAE over 64-bit (not even small pointers, since each PAE pointer has a 32-bit offset and an extra (up to 32-bit) 'start' (remember the segmented memory of 8086? what a load of bloat!)

3
  • I believe that an additional advantage of 64-bit systems is that you can move more memory faster, since you can fetch data 64 bits at a time. Also, read mikeperham.com/2010/01/18/varnish-on-32-bit-systems for an example of a "small" application that suffers substantial performance penalties on a 32 bit system.
    – larsks
    Nov 19, 2010 at 1:32
  • Linux is (was?) capable of doing a "4G/4G" split whereby a process would get almost the entire 4GB of address space for itself, at the cost of some performance. Nov 19, 2010 at 1:47
  • @larsks: memcpy() would execute a smaller number of steps, but the speed is dictated by cache-RAM bandwidth. AFAIK, cache lines are the same, so each cache miss would trigger a whole-line fetch, no matter if afterwards you pick from there 32 or 64 bits at a time
    – Javier
    Nov 19, 2010 at 17:02
2

PAE hurts performance. The only possible gain would be that pointers are half the size, but now you have to deal with swapping pages of memory around.

0

Besides being less register-starved, x86_64 gives you more sensible floating points ops. It also guarantees your binaries got better optimisations, because the compiler never needed to emit backwards compatible opcodes. If you're running anything cpu-bound, it's a big win.

You must log in to answer this question.