Custom Search
-- 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.eduReceived on Sun May 14 2006 - 06:07:13 PDT