Assuming that I am running Intel MKL (BLAS, LAPACK), is there any difference in performance if I run it on a 32 or 64 bit OS? (Of course, assuming that my hardware remains the same).

My processor is a 64 bit Intel i3. But am currently running Debian 32 bit. (Long story why)

Most of my work is shared memory parallelization.

Also, I know that the RAM above 3 GB is useless on 32 bit but assume that memory isn't as important.

A couple of our old computers running Debian 32 bit (2 GB RAM) got upgraded to 4 GB RAM. It shows 2.9 GB in our system specs.

We are wondering whether it makes sense to wipe the OS, install a new one, install all our softwares on the new system, change the link lines of all our automated scripts (Intel MKL link line advisor) and waste 2 days in this?

tl;dr : Is there a performance boost if I run a 64 bit OS (& 64 bit MATLAB/Intel MKL) rather than a 32 bit one?

  • $\begingroup$ 4GB RAM should not be a problem. You need to use a kernel with PAE mode support. I am running Debian (testing; 32 bit; 3.1.0-1-686-pae) and have no trouble using 4GB RAM with an Intel i5. $\endgroup$
    – stali
    Mar 13 '12 at 13:33
  • $\begingroup$ Porting code to 64 bits can take much more than just two days. There are quite a few potential problems when dealing with arrays of pointers, size types, etc. that can be a nightmare to track-down and resolve. $\endgroup$
    – Pedro
    Mar 13 '12 at 13:37
  • $\begingroup$ stali, RAM isn't our biggest issue. @Pedro, as of now, we aren't using that many pointers, size types etc. Its just plain calls to DGESV, DGEMV etc. Thats why the question. We don't want to go too far and then repent not shifting to 64 bits. $\endgroup$
    – Inquest
    Mar 13 '12 at 14:15
  • 1
    $\begingroup$ You are not going to know frankly unless you measure the performance on 32 bit OS against 64 bit OS and even then you will be comparing it against a fresh OS. Always measure before and after any change you make. $\endgroup$
    – EdChum
    Mar 14 '12 at 0:04
  • $\begingroup$ @EdChum, if that is really what I must do....Drats :| $\endgroup$
    – Inquest
    Mar 14 '12 at 12:53

TL;DR: It all depends, and you need to benchmark it, but the big differences besides memory are that you have twice as many registers, pointers are twice as big, and if newer software is limited to one type of architecture, it's probably going to be 64-bit (for the time being).

Super User has a nice post on the distinctions between 32-bit and 64-bit operating systems and their effect on performance. Ignoring the part about addressing more memory (as you requested), pointers are twice as big (4 bytes in 32-bit, 8 bytes in 64-bit), so you can store half as many pointers in cache, but you have twice as many registers to work with. If the bottleneck in your computations is register memory, then having twice as many can be a big help, and you may see substantial performance gains (the top Super User answer claims as much as 30% from the poster's own experience).

However, if you look at this presentation on molecular dynamics codes by Axel Köhlmeyer, the answer isn't so clear. He claims that he saw no difference in performance between 32-bit and 64-bit versions of the codes he was using, though I found the graphs he presented confusing because he doesn't seem to actually compare 32-bit and 64-bit versions of his codes.

Wade Spires wrote a report when he was a graduate student at UCF on the differences in performance of the SPEC2000 benchmark on 32-bit and 64-bit operating systems. The 64-bit operating system isn't necessarily more performant overall; there are some tasks where programs execute more quickly on the 32-bit OS.

The best advice is to benchmark, so that you know for sure what the performance gains will be. It requires some work on your part, and time that you may not have for benchmarking. If you choose to benchmark, I recommend using a virtual machine as a testbed for these sorts of comparisons so that you can easily switch between guest operating systems on the same machine while doing the minimum amount of setup and teardown work.

  • $\begingroup$ I think I'll benchmark. Any directions on that? Any guides/documentation or something you can think of? Also, thanks for the virtual machine direction. I didn't think of that. $\endgroup$
    – Inquest
    Mar 14 '12 at 16:32
  • $\begingroup$ Basically, run some test problems, time the runs, and profile your code. You can use gprof to profile your code, and you can also use TAU to instrument it in more detail if you feel you need it. $\endgroup$ Mar 14 '12 at 20:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.