[gmx-users] Performance in ia64 and x86_64

[Mark Abraham]

On 11/02/2011 11:33 PM, Ignacio Fernández Galván wrote:
> Hi all,
>
>
> I'm compiling and testing gromacs 4.5.3 in different machines, and I'm wondering
> if it's normal that the ia64 is much slower than the x86_64
>
> I don't know full details of the machines, because I'm not the administrator or
> owner, but /proc/cpuinfo says:
>
> ia64 (128 cores): Dual-Core Intel(R) Itanium(R) Processor 9140N
>
> x86_64 (16 cores): Intel(R) Xeon(R) CPU           E5540  @ 2.53GHz
>
> Just looking at the GHz, one is 2.5 and the other is 1.4, so I'd expect some
> difference, but not a tenfold one: with 8 threads (mdrun -nt 8) I get 0.727
> hours/ns on the x86_64, but 7.607 hours/ns on the ia64. (With 4 threads, it's
> 1.3 and 13.7).
>
> I compiled both cases with gcc, although different versions, and default
> options. I had read assembly or fortran kernels could help with ia64, but
> fortran is apparently incompatible with threads, and when I tried with assembly
> the mdrun seemed stuck (no timestep output was written). Is this normal? Is
> there something else I'm missing?

GROMACS assembly kernels for IA64 have been known to have problems (see 
mailing list archives), but IIRC usually in compilation, not execution. 
You will need to inspect the first few hundred lines of the .log files 
where GROMACS reports what kernels are being used for the execution.

> Also, in the x86_64 system I get much lower performance with 12 or 16 threads, I
> guess that could be because of the cores/processors, but I don't know what's the
> exact configuration of the machine. Again: is this normal?

We can't say with the information given. For best performance, the 
number of threads cannot exceed the number of physical cores available 
to one processor. To go higher, you need to compile and use GROMACS with 
MPI, not threading. If the IA64 is "dual core" then you are not 
measuring anything useful. You also need to be sure you're measuring for 
a decent length of time - a few minutes at least.

Mark