Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.

    Comment


    • #3
      Originally posted by asdfblah View Post
      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.
      Last edited by strcat; 09 May 2014, 05:58 AM.

      Comment


      • #4
        programs' comparison are native 64bit?

        Comment


        • #5
          Originally posted by phoronix View Post
          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.

          Comment


          • #6
            Originally posted by strcat View Post
            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.

            Comment


            • #7
              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

              En este canal encontraran principalmente: *Resultados de juegos de windows probados en el wine Generalmente en todas las listas de reproduccion hay videos distintos y si se llegasen a presentar videos repetidos puede ser por que hubo un cambio en el hardware de pruebas o por algun cambio importante en el wine que afecte algun titulo en especifico Para mas informacion pueden consultar mi blog http://gamesonwine.blogspot.com O en el foro de CHW http://www.chw.net/foro/gnu-linux-y-otros-sistemas-operativos/247392-juegos-windows-probados-wine.htm *Algunos videos de assasins creed brotherhood y revelaciones en multiplayer sobre windows


              Comment


              • #8
                These benchmarks should also include memory usage.

                Comment


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

                  Comment


                  • #10
                    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).

                    Comment

                    Working...
                    X