Please note that all the SIEpedia's articles address specific issues or questions raised by IAC users, so they do not attempt to be rigorous or exhaustive, and may or may not be useful or applicable in different or more general contexts.
Said in a very simple way, 32-bit CPUs process data in 32-bit chunks, while 64-bit CPUs process data in 64-bit chunks. Perhaps the main advantage is that with a 32-bit register one can address 2^32 memory addresses (about 4 GB of RAM), while 64-bit registers can address 2^64 addresses (17.2 billion GB of RAM). Also, a 32bit CPU must process 64-bit numbers in two steps, while 64-bit CPUs only require one step.
For further information about this topic, see for instance http://en.wikipedia.org/wiki/64-bit, Myths and facts about 64-bit Linux, 64-bit computing in theory and practice: the first two pages offer a Windows-oriented but quite nice introduction to 64-bit architecture and computing.
Please note that 64-bit does not mean twice the performance of 32-bit: indeed 64-bit code may run slower due to its higher memory consumption, and hence a larger number of cache misses (failed attempts to read or write a piece of data in the cache, which results in a main memory access with much longer latency).
The quickest way to find out whether your machine is 32- or 64-bit it to execute the command:arch
If the answer is i686, then you've got a 32-bit machine, if the answer is x86_64, then you've got a 64-bit machine.
Notice that the newer PCs, the Dell Optiplex 740MT, all have a 64-bit AMD CPU.
If you would like to check what machines at our Institute are 32-bit and what are 64-bit, the simplest way is to type:condor_status
and look at the third column, the one headed Arch. INTEL means 32-bit, while x86_64 means, you already guessed it, 64-bit.
You bet they are! Broadly speaking, both 64-bit processors and 64-bit Operating System provide full compatibility with 32-bit applications. Most people won't even realize that their 32-bit machine has been replaced by a 64-bit one (or at least, the differences they are likely to notice are the ones related to the new OS, Fedora 8, not to the CPU bitness change). Indeed, each 64-bit OS installs two sets of libraries (down to the lowest level): the 32-bit libraries, usually located in /lib and /usr/lib, and the 64-bit ones, in /lib64 and /usr/lib64.
Of course, 64-bit applications won't run in a 32-bit CPU.
Occasionally, you may find that some 32-bit application fails to load because of missing compatibility libraries (which somehow were skipped when installing the 64-bit OS, Fedora 8). In such cases the solution is to install them using yum. For instance, a user found that Gaia didn't work in her laptop, complaining about a missing libg2c.so shared library. First we checked in a Fedora 8 desktop what package provides the missing library (logged in as root):yum whatprovides /usr/lib/libg2c.so.0
and then installed it in the laptop:yum install compat-libf2c
At the present time (July 2008), even after the recent en mass replacement of 5-year old PCs with newer models, still about half of the existing machines are 32-bit.
Taking advantage of the full compatibility of 64-bit machines with 32-bit software, astronomical software packages are installed, and will continue to be installed or updated, in 32-bit. Some specific applications, such as IDL, come both in the 32- and 64-bit versions: the startup script determines the machine architecture and load the appropriate executables and libraries in a transparent way. On the other hand, some applications can't be ported to 64-bit (or doing so requires quite a big effort): one illustrious example is IRAF, see for instance the discussion in this thread: http://iraf.net/phpBB2/viewtopic.php?t=86101.
So far, virtually all 32-bit astronomical packages work flawlessly in 64-bit machines. However, some 32- vs 64-bit issues have surfaced (see below), so it's likely that some selected packages will be compiled and installed natively in 64-bit, also with the aim of gaining experience and assessing potential problems or conflicts.
Here we describe two of the problems we have experienced recently, to give you an idea of what can happen, and to encourage you to report similar problems you might encounter.
In general, mixing 64-bit software with 32-bit libraries or tools is not possible.
On the same line, code that links to the cfitsio library (installed for now only in 32-bit) can't be compiled in a 64-bit machine with a 64-bit compiler (but it can by using a 32-bit compiler, see below).
So, for the time being please take this into account when compiling a complex software package in a 64-bit machine. While you can use some appropriate ./configure options, modify the Makefile, switch to the 32-bit version of the Fortran or C/C++ compiler, etc., in order to compile the package in 32-bit mode, this may be complicated and error-prone. Your best bet is to do the compilation and installation remotely in a 32-bit machine: if this succeeds, there are excellent chances that the package will run both in 32-bit and 64-bit machines.
By "standalone program" we mean software that relies on standard libraries and does not link to other packages such as Python, HDF, Iraf, Midas, Cfitsio, etc. If you are writing code yourself, it's important that you know the differences between the 32-bit and 64-bit programming environments, what common and dangerous pitfalls must be avoided, and how to write code that work out-of-the-box in both platforms.
A very good discussion on this topic, together with practical examples and useful recommendations, can be found in: Porting Linux applications to 64-bit systems - Tips and techniques for a smooth transition.
Several compilers are available at the IAC: the whole set of GCC compilers (g77, gcc, gfortran, etc. - all of them free), and the Intel and the PGI C/C++ and F90 compilers (these latter each with a 2-seat floating license).
By default, a 64-bit machine will use the 64-bit version of these compilers, while a 32-bit machine will use the 32-bit version. If you have a 64-bit machine but wish to use a 32-bit compiler (either because your code is not 64-bit ready, or because it needs to run also in a 32-bit PC), probably the most effective solution is, as mentioned before, to do the compilation in a 32-bit PC. Alternatively, for the GCC compilers you can use the -m32 flag, while for Intel and PGI you may need to modify your environment so as to call the 32-bit compilers by default. Get in touch with us if this is what you need.
We estimate that the migration to 64-bit will be completed in about one year, as next spring all Dell Optiplex GX280 PCs, by then 5-year old and thus with the maintenance contract expired, will be replaced by 64-bit workstations (Dell Optiplex 740MT or similar models).
Then astronomical software packages will gradually be recompiled and installed in 64-bit whenever possible and when this does not conflict with existing 32-bit packages which can not be upgraded to 64-bit (IRAF, for instance).