-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just to add a few comment on the 32b vs. 64b on intel processor based
computers :
Whereas on most platform the sole advantage of 64b computing is ony
easier handling of large data chunks, the pricture is a bit different
on intel x86 chips. The reason is that intel used the pretext of
going 64bits to add some registers, so when one compile for x86_64
the compiler has access to twice the number of register (both
floating point and integer, and this is also true -as far as I know-
for registers used by the SSEs and MMX engines) and this can make
some diff. on performance of the resulting code.
On the mean time for all 64b architecture (including intel's x86_64),
process which use a lot of pointer will suffer from the doubling of
memory usage and bandwidth required for storing and moving addresses
around.
In short, if one's program doesn't require large data-space it will
nearly always perform better using 32b, at the exception of the
x86_64 vs. x86(32b) where the difference will be coming from a
completely different reason (namely : more registers available on the
processors) and the overall performance results is likely to vary
from one software to the other.
Serge.
Le 16 févr. 07 à 13:08, George M. Sheldrick a écrit :
I am using the Intel ifort for the precompiled versions of shelx
that I distribute for Linux, Windows and IntelMac. I am pretty
happy with it and it produces very fast code. However I am only
producing 32-bit binaries and for reasons indicated by Lynn I
bought commercial licences (and also pay for the software support,
though the main use of the support is to continue to get updates).
The only real advantage I can see of using 64-bit code would be to
use larger matrices for full-matrix least-squares refinement in
shelxl (to get real esds), the 32 bit code seems to run fine on 64-
bit systems.
George
Lynn Ten Eyck wrote:
I have used the Intel compilers, and yes, they work pretty well.
However,
they do not solve this particular problem. I have one problem
with them; if
you read the fine print on the academic license, you find that you
are not
supposed to use them for things other than your own research
unless you pay
for them. Since I try to write software for wide free
distribution, whether
or not this counts as my own research is a gray area.
Lynn Ten Eyck
On 2/15/07 9:45 PM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
Although I have not yet tried to compile coot or CCP4, I have
found that the
GNU provided packages (gcc, g77) do not make life convenient (how
is that for
a euphamism for 'banging your head against the wall)?
Things worked better with gfortran than g77 and again better with
the Intel
compilers (both fortran and C(++)). When I say 'worked better'
this means
'less effort to get it working' and also (particularly in case of
Intel)
'faster'. My experience was not with Fedora but with RHEL
(similar problems as
described below, not the same though).
In my humble opinion it is worth to spend the money, get the paid-
for
compiler, and get around the problems like the one you describe.
Life gets
even better: if you want to try, you can get a free trial license
for either
fortran or C(++) or both and convince yourself that it is better.
The Intel
compilers are a one-time expense with an indefinite license, but
you must pay
annually if you want support. Academic licenses are (appropriately)
inexpensive.
My 2 cents worth.
Mark
-----Original Message-----
From: [EMAIL PROTECTED]
To: [email protected]
Sent: Wed, 14 Feb 2007 1:09 PM
Subject: Re: [ccp4bb] x86-64
--
Prof. George M. Sheldrick FRS
Dept. Structural Chemistry,
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany
Tel. +49-551-39-3021 or -3068
Fax. +49-551-39-2582
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFF1aLy5EPeG5y7WPsRAhlnAKCEv5Flu7KWbb3bRREISyZbAE9vyQCg6nit
DUfk+L9hE4FVB+Wd6qfLB5g=
=1xbO
-----END PGP SIGNATURE-----
