[gmx-developers] Opteron

[Mike Sullivan]

Erik Lindahl wrote:

> Hi,
>
>> I have compiled using g77 on gingin 64. I get slightly better clock 
>> for clock performance
>> than on the athlon. This is using FFT. Supposedly the AMD FFT 
>> routines are very fast and
>> if a lot the execution time in gromacs is spent in FT calcs then 
>> there could be a significant
>> performance boost. I had a quick look at the function calls for FFT 
>> and the names
>> of the routines differ so the source code will have to be changed to 
>> call the AMD FFT
>> functions.
>
>
> Stay away from g77, it is a horrible compiler :-)
>
> Intels ifc is much better.

I had problems getting ifc to work on the RedHat x86-64 beta Gingin64. 
The version of
 g77 that ships with the RedHat beta outperforms the Portland compiler. 
I have the Opteron
box back in house now and will have another crack at getting ifc to work.

>
> However, if you compile in 32-bit mode and enable SSE support (should 
> be automatic on x86, but you might have to use --enable-x86-assembly 
> or something on Opteron) you will use assembly loops instead, which is 
> always the fastest option. 

I actually got better performance by disabling the x86 assembly and 
using g77. Let
me redo the test as it is significant. I have been told that the Opteron 
emulates an x87
FPU so if the assembly routines use x87 only then performance will not 
be great. Again
I need to confirm this with AMD.

>
>
> Gromacs only uses FFTs with PME, and even then it only accounts for 
> 5-10% of the runtime, so I don't think it's worth spending time 
> optimizing that.
>
Thanks that was the kind of input I was looking for. Thanks

>
> I'm definitely interested in access to both systems. However - there 
> is one caveat:
>
> When testing the AMD SSE code in folding at home, there has been one 
> workunit that managed cause a total system crash when running the SSE 
> stuff.
>
> Interestingly, the crash only occured on Thoroughbred Athlons, not the 
> older Palamino.
>
> This *shouldn't* be possible in a modern memory-protected OS, so 
> something is probably very wrong in either windows or the CPU (haven't 
> seen it in Linux).

Both machines are running Linux, However the firewall is currently the 
dual MP
machine,  as my intention is to have it tortured by the users, I will be 
putting in another
unit in to act as the firewall.

>
> So, if we're unlucky it might crash the machine. Nothing a reboot 
> can't fix, but if this is an important production system we should 
> probably avoid testing on it. 

The machines are being designated for test drives and devel work. If 
they get heavily
loaded then I will add more hardware. If you crash either then we have 
learned something important, so ..... go ahead make my day.


                                                                        
                                    Regards
                                                                        
                                    Mike

-- 
----------------------------------------------------------------------
Mike Sullivan                           Director Performance Computing
@lliance Technologies,                  Voice: (416) 385-3255,
18 Wynford Dr, Suite 407                Fax:   (416) 385-1774
Toronto, ON, Canada, M3C-3S2            Toll Free:1-877-216-3199
http://www.alltec.com