-----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, "[log in to unmask]"  
>> <[log in to unmask]> 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: [log in to unmask]
>>> To: [log in to unmask]
>>> 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-----