Who is using 64-bit Linux?

From: Roger Rowlett
Date: 3 April 2012 20:57
The time has come for me to upgrade my Linux OS to something more recent for me and my student workstations. A 32-bit distro is certainly conservative and compatible with CCP4 and Coot, but it seems like that solution hobbles my hardware and puts some limitations on available memory, even with PAE enabled. So who is using a 64-bit distro these days, and are there lingering issues of compatibility and dependency hell with commonly used XRD software, like CCP4, Coot, iMOSFLM etc.?

Ubuntu 12.04 LTS (beta) actually works OK with one simple workaround for the global menu for CCP4 and Coot, and wine compatibility is fine for running CrysalisPro in the same environment, so it's really comes down to whether or not the extra performance of a 64-bit OS is worth the pain of compatibility issues for XRD software. Any thoughts?

Cheers,

_______________________________________
Roger S. Rowlett

----------
From: Tom Peat
We use the 64 bit Centos (Red Hat) distro and CCP4, Coot, etc seem to work fine on this.
I can't say I notice a big performance boost from the 64 bit side of things.
Maybe I'm just impatient.
cheers, tom


Tom Peat

----------
From: Ed Pozharski
Whatever you do, make sure you have enough bottled water before the next
doomsday:

http://en.wikipedia.org/wiki/Year_2038_problem

I am using 64-bit linux almost exclusively for some time now.  "XRD
software" works fine, no lingering issues that I can report.  ia32-libs
do the trick for 32-bit binaries.

--
Oh, suddenly throwing a giraffe into a volcano to make water is crazy?
                                               Julian, King of Lemurs

----------
From: Bernhard Rupp (Hofkristallrat a.D.)
I have RHEL62-64 in a win 7-64 8GB desktop VMware installation. CCP4, ccp4i,
coot, and shelxcde beta executables run fine.
There were issues with the coot package installation due to unresolved
dependencies
and my ignorance thereof, but I think a working RHEL62-64 compatible package
is available now, the coot wiki has latest info.
I could not get Xtalview running, probably some xterm thing beyond my grasp,
which also screws up the latest hkl2mapV0.3,
V0.2 runs fine.
Free intel ifort runs great.

The great part about the VM ware installation is that I also got it running
on a win7-64 8GB laptop
by simply copying the virtual RHEL machine (files).
That alone saved a few day's work.
Also the Unity feature of VMware is a blast.

BR

-

----------
From: David Schuller
We have been using 64 bit Linux for several years. I'm not aware of any lingering issues with the 64 bit-ness.
Linux is always sprinkling in a few new bugs, but I don't know of any current issues with 32 bit vs. 64 bit.

--
=======================================================================
All Things Serve the Beam
=======================================================================
                              David J. Schuller

----------
From: Harry Powell

Hi Roger

CCP4 and Mosflm work fine in my testing - I do builds for Linux and Macs, both 32 and 64 bits. I wouldn't expect to see a difference in performance (and don't see anything significant in practice).

One thing - I think you will need to install 32-bit compatibility libraries for some of the code that is dynamically linked and has been built as 32-bit, e.g. I think ActiveTcl distros might need them (for iMosflm).

Harry

--

Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH

----------
From: Kip Guja

Fedora and RHEL 64-bit work well and run pretty much all the standard programs (CCP4/Coot/Phenix/CNS/SHELX).  By installing the relevant 32-bit libraries you can also run older programs if need be.

On a related note, XtalView will work on Fedora/RHEL if you install/compile the appropriate XView library files. For more info, check out: http://www.physionet.org/physiotools/xview/

Hope that helps,
Kip

----------
From: Ho Leung Ng
Roger,

My lab is using 64 bit distros of SUSE and Linux Mint and hasn't had
any compatibility issues that I can recall.


Ho

Ho Leung Ng

----------
From: Tim Gruene

Dear Tom,

64-bit is about memory addressing - why would you expect a performance
boost? I have wondered where this notion originated from.

Cheers,
Tim

- --
- --
Dr Tim Gruene

----------
From: Tom Peat
Hello Tim,

I believe the notion comes about as one can thread 64 instead of 32 addresses concurrently, thereby boosting performance.  If it has no performance boost, why would they bother?

Cheers, tom

----------
From: Tim Gruene

Hi Tom,

because there are PCs out there with more than 200GB RAM, as well as
programs and systems that make use of them. As far as I understand a
32-bit compiled kernel would have not possibility to address anything
beyong 4GB.

Regards,
Tim

----------
From: Takanori Nakane
Dear Tim,

64-bit is about memory addressing - why would you expect a performance
boost? I have wondered where this notion originated from.

The x86_64 architecture has more registers than 32bit (x86)
architecture. Register access is faster than memory access so
the more data programs can put on registers, the faster it runs.

Best regards,

Takanori Nakane

----------
From: Roger Rowlett
A 32 bit Linux OS with PAE enabled (which is all of the current Linux distros) can actually address 64 Gb of memory, but no more than 3 Gb per process. 3 Gb may not be that much of a limitation for many processes, so large performance increases on a 64-bit system compared to a 32-bit may be difficult to observe in practice for now.

Roger Rowlett

----------
From: Roger Rowlett

Thanks everyone for the info. To summarize, it looks like 64-bit Linux is not the issue it was a few years ago for crystallography software. Many typically used crystallography packages are compiled for 64 bit now and the ia32 libs typically provide compatibility for those not yet compiled as 64 bit binaries.
Cheers,
Roger Rowlett

----------
From: David Aragao
Hi All,

I did quite a bit of performance comparison with XDS between two centOS 5 (64 vs 32) and did notice performance boost when writing results to a remote NFS directory. Interestingly, using same OSs writing locally the performance boost was not noticeable. At the time I thought that somehow the temporary files that XDS was creating on the 32bit OS were better handled in memory instead. This off course was done using 32bit compiled XDS vs 64 bit compiled XDS. I did not try to run the 32bit XDS on the 64 bit OS. Maybe I should.
This was done on particular machines configuration and would not generalize to all programs and situations.

On the topic of 64 bit vs 32 which to choose?

Funny enough I can't get iMosflm running reliably on 32 bit CentOS 5 or CentOS 6 and I can on 64 bits versions.

We have all running (CCP4, Coot, iMosflm, XDS, phenix, best, etc, etc) running in 64 bit and intent to move all user computers to uniform 64 bit environment on the next shutdown as it is more difficult to support both 32 and 64 bit enviroment.

David
--

----------
From: Harry Powell

Hi David

I'm curious - do you mean running on a 32-bit Centos box or running the 32-bit Mosflm executable on a 64-bit Centos box? 

We did have one report of problems with the 32-bit exe on a 64-bit box, which (seemingly) randomly gave one of two different results (either the same failure or success) - but that was fixed in the beta we released in July last year, and didn't occur with the 64-bit exe at all.

We really are grateful to people who tell us about the bugs they find rather than try to struggle on in silence!

Funny enough I can't get iMosflm running reliably on 32 bit CentOS 5 or CentOS 6 and I can on 64 bits versions. 

We have all running (CCP4, Coot, iMosflm, XDS, phenix, best, etc, etc) running in 64 bit and intent to move all user computers to uniform 64 bit environment on the next shutdown as it is more difficult to support both 32 and 64 bit enviroment. 

David

--

Harry

--

Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH

----------
From: James Holton

I myself recently had the misfortune of trying to get a java program relying on the (apparently 32-bit only) "JMF" package to run on 64-bit linux.  This wasted almost an entire week of my life!  I tried downgrading the operating system to 32-bit, but that reduced the number of "CPUs" available in the system from 24 to 8.  Still don't know why that is (I'm not all that familiar with Ubuntu, and don't want to be), but I imagine one could call that a "performance hit".

On the whole, however, I have not seen any significant performance advantage of 64 over 32 bit running crystallography programs side-by-side on equivalent hardware.  I have also been unimpressed with the supposed "memory access" advantages of 64 bit.  I had to do a LOT of recompiling programs in order to create maps or MTZ files bigger than 2 GB, and I also still have certain programs "running out of virtual memory" at 4GB as well.  Despite the fact that the relevant machine has 48 GB of RAM and 80 GB of swap.

I tell you.  Technology just doesn't work.

-James Holton
MAD Scientist

----------
From: Sabuj Pattanayek

> I tell you.  Technology just doesn't work.

developers and user's don't, technology is usually ok, but I feel your pain.

----------
From: James Stroud

On Apr 13, 2012, at 1:24 PM, James Holton wrote:

I tried downgrading the operating system to 32-bit, but that reduced the number of "CPUs" available in the system from 24 to 8.  Still don't know why that is 

I'm probably wrong, but I'll guess that a 32 bit operating system can only spare 3 of those bits to address CPUs ;-)

James

----------
From: Sabuj Pattanayek
No, that's a limit set by the ubuntu 32 bit kernel maintainers when
they configured and compiled the kernel (again, see my comment about
the problem being with developers and users). I think the limit is 256
for x86, 4096 for ia64 (itanium), even old versions of RHEL supported
16 and 32 logical CPUs for x86 :

http://support.bull.com/ols/product/system/linux/redhat/help/kbf/g/inst/PrKB11417

http://cateee.net/lkddb/web-lkddb/NR_CPUS.html

----------
From: Pete Meyer

On the whole, however, I have not seen any significant performance advantage of 64 over 32 bit running crystallography programs side-by-side on equivalent hardware.  I have also been unimpressed with the supposed "memory access" advantages of 64 bit.  I had to do a LOT of recompiling programs in order to create maps or MTZ files bigger than 2 GB, and I also still have certain programs "running out of virtual memory" at 4GB as well.  Despite the fact that the relevant machine has 48 GB of RAM and 80 GB of swap.

Eventually all of the programs using cute memory tricks to deal with the restrictions of 70s, 80s, and early 90s systems will be patched, or replaced by ones which don't use these acrobatics.

But I don't think it'll be anytime soon.

Pete