Ian -
Thanks for posting your results. The cellulose benchmark is now part of
amber9; look under amber9/benchmarks. I have not yet been using it, mostly
because I have been using large blood coag benchmarks out of Lee Pedersen's
group instead (not ready for release); I will start using it a bit in the
near future though. Ross has a great set of benchmarks out at SDSC for
amber 9; there's a pointer on the amber web site.
Best Regards - Bob Duke
----- Original Message -----
From: "ian gould" <i.gould.imperial.ac.uk>
To: <amber.scripps.edu>
Sent: Friday, May 12, 2006 3:35 AM
Subject: Re: AMBER: Opteron vs. Xeon performance
> Hi Everyone
>
> Thought I'd throw my two pennyworth in on this issue. Cann't give you
> em64t
> numbers but can furnish some opteron numbers which may be of use.
>
> Machines Used
>
> Iwill 8501
> 8 x 870 (2.0Ghz) = 16 cores
> 32 Gb Ram
> 1Tb sata raid
>
> HP proliant
> 4 x 885 (2.6 Ghz) = 8 cores
> 16Gb Ram
> 250Gb sata raid
>
> Both running RH AS 4
>
> PMEMD 9 has been compiled with ifort 9.0 and MKL 8.0 and LAM
> I have yet to get a successful compilation of MPICH2 to work
>
> JAC numbers are ps per day
>
> No. processors Iwill ( 2.0GHZ) HP (2.6Ghz)
> 2 417.39 552.30
> 4 752.88 987.95
> 8 1331.69 1757.83
> 16 1893.49
>
>
> Factor IX ps per day
>
> No. processors Iwill ( 2.0GHZ) HP (2.6Ghz)
> 2 190.50 249.22
> 4 324.57 421.94
> 8 547.21 721.37
> 16 810.00
>
>
> This will hopefully give a flavour of what's possible. I will in the
> future
> do the complete set of benchmarks as for the other big tin on the web
> site.
> One comment I'd like to pass on is that whilst I have not got pmemd to
> compile with the pathscale compiler/amd pathscale maths libraries at the
> moment, busy with other things, I can tell you that this combination gives
> my fastest performance of gaussian03 on my opteron tin. I'm getting
> anywhere
> from 1.1 to 1.4 times slower that an altix 350 with 1.5 Ghz's compared
> with
> my 2.0ghz iwill and on the HP it beats the SGI on all jobs!!, if you check
> SGI's report on opteron vs altix they get > 2x slower performance with
> faster processor in their opteron vs. altix 350 1.5ghz. So it may be that
> it
> will give comparable/if not better performance on pmemd than intel/mkl.
>
> BTW Ross/Bob could you shoot me the cellulose benchmark and I'll give that
> a
> whirl.
>
> Cheers
> Ian
>
> I've seen things you people wouldn't believe. Attack ships on fire off the
> shoulder of Orion. I watched C-beams glitter in the dark near the
> Tannhauser
> gate. All those moments will be lost in time, like tears in rain. Time to
> die.
> Roy Batty ... Bladerunner
> --
> Dr Ian R Gould
> Senior Lecturer Biological and Biophysical Chemistry
> Imperial College London
> Exhibition Road
> London
> SW7 2AY
> E-mail i.gould.imperial.ac.uk
> http://dumb.ch.ic.ac.uk/~igould
> Tel +44 (0)207 594 5809
>
>
> On 12/5/06 03:02, "Robert Duke" <rduke.email.unc.edu> wrote:
>
>> Okay, I do have opteron vs. intel em64t numbers; for the specific opteron
>> and intel chips I run on they are very close for pme simulations using
>> pmemd
>> on the benchmarks I have done (pmemd 9). The specifics are 2.2 GHz
>> opteron
>> dual cpu/infiniband interconnect (note, NOT dual core, which may actually
>> give you more bang for the buck, though my numbers on this are loose
>> (just
>> based on some rough benchmarks on dual core cray xd1, which I have not
>> done
>> a lot of analysis on)) vs 3.6 GHz em64t intel xeon, 2 MB
>> cache/infiniband.
>> On the two clusters I bench on for these types of chip, the numbers are
>> pretty darn close for pme. For GB, I would probably tend to prefer the
>> xeon
>> because I am a little bit chicken about trying to use the Intel MKL with
>> Opterons, and it really helps GB performance - off the top of my head at
>> least 20% (this is a very crude recollection from GB which I hacked into
>> pmemd but have not yet put a lot of effort into optimizing - but it was
>> clear that the MKL was worth it. I don't know if the AMD equivalent is
>> as
>> good, and have not tried crossing manufacturers any further than using
>> ifort
>> to compile on opterons (which is maybe a little slower than pathscale
>> unless
>> you get adventurous in lying to the compiler about what the chip is
>> (Andreas
>> Svrcek-Seiler sent me some numbers on this, and has tried lots of
>> different
>> things in compiling on the opteron; I tend to try to get a few things
>> working and move on to the next platform). Okay, so the performance is
>> close, and I could believe that a really well configured opteron can do a
>> bit better, but I have not seen dramatic differences myself. Don't get
>> me
>> wrong, I like the opteron very much, but the later intel chips are
>> delivering too. Now, if I were buying hardware, I would be worried about
>> getting a reliable cpu + reliable motherboard + reliable interconnect.
>> The
>> thing that will kill you is if you buy something cheap, and one of the
>> components is not well balanced, or prone to heat-induced or other
>> failure.
>> This is stuff where it is handy to be able to ask someone who has a
>> specific
>> configuration what their experience has been (so ask the vendor for
>> references, or buy from a manufacturer that is first tier at a bit of a
>> premium).
>>
>> At this point in time, I find developing performance code for either the
>> intel ia32 family, opteron or ibm sp4/5 all to be roughly equivalent
>> experiences, and the chips respond in a similar fashion to attempts at
>> optimization. RISC architectures, at least the ones I have available,
>> are
>> falling behind. The itanium is a heck of a chip for brute power, but it
>> is
>> touchy to optimize and expensive. I mostly develop on the ia32's and
>> move
>> off to the similar chips first, and then, while grumbling something akin
>> to
>> "what a pain" over how differently it optimizes, move off to the itanium,
>> and then I finally make sure everything still runs on the RISC chips.
>> This
>> gives you a clue or two as to what pmemd will run well on for the near
>> future.
>>
>> Regards - Bob Duke
>>
>> ----- Original Message -----
>> From: "Ross Walker" <ross.rosswalker.co.uk>
>> To: <amber.scripps.edu>
>> Sent: Thursday, May 11, 2006 7:17 PM
>> Subject: RE: AMBER: Opteron vs. Xeon performance
>>
>>
>>> Dear Joseph
>>>
>>>> I am looking for recent data comparing the performance
>>>> between Opterons
>>>> and Xeons using Amber, as well as interpretation of that data.
>>>
>>> This sort of thing is never a simple as it sounds. As with all
>>> comparissons
>>> it very much depends what you compare. E.g. periodic boundary PME
>>> simulations on a top end Opteron will probably be better than a top end
>>> Xeon, however, this may be reversed when one tries Generalized Born
>>> implicit
>>> solvent calculations. This is all a function of cache hits, code
>>> branching
>>> etc. I.e. some problems do well on some chips but worse on others and
>>> vice
>>> versa. This is certainly the case with IA64 chips.
>>>
>>> E.g.
>>>
>>> JAC Benchmark (PME) (PMEMD v9.0)
>>> Pentium-D 3.2GHz = 231.79 ps/day
>>> Itanium 2 1.5GHz = 395.37 ps/day
>>> Ratio IA64/P4 = 1.71
>>>
>>> GB_MB Benchmark (GB) (PMEMD v9.0)
>>> Pentium-D 3.2GHz = 266.03 ps/day
>>> Itanium 2 1.5GHz = 191.51 ps/day
>>> Ratio IA64/P4 = 0.72
>>>
>>> Anyway, I know that this is not dealing with Opterons which is what you
>>> are
>>> interested in but at present we don't have any amber9 timings on Opteron
>>> chips. However, there are some timings here for dual core opterons:
>>> http://amber.scripps.edu/amber8.bench1.html
>>>
>>> JAC Benchmark (PME) (PMEMD v8.0)
>>> Dual Core Opteron 875 (2.2GHz) = 187.0 ps/day
>>> Single Core Opteron (1.4GHz) = 124.0 ps/day
>>>
>>> All the best
>>> Ross
>>>
>>> /\
>>> \/
>>> |\oss Walker
>>>
>>> | HPC Consultant and Staff Scientist |
>>> | San Diego Supercomputer Center |
>>> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
>>> | http://www.rosswalker.co.uk | PGP Key available on request |
>>>
>>> Note: Electronic Mail is not secure, has no guarantee of delivery, may
>>> not
>>> be read every day, and should not be used for urgent or sensitive
>>> issues.
>>>
>>>
>>> -----------------------------------------------------------------------
>>> The AMBER Mail Reflector
>>> To post, send mail to amber.scripps.edu
>>> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>>>
>>
>>
>> -----------------------------------------------------------------------
>> The AMBER Mail Reflector
>> To post, send mail to amber.scripps.edu
>> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Sun May 14 2006 - 06:07:13 PDT
