[Beowulf] Athlon64 / Opteron test
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Daniel Fernandez daniel at labtie.mmt.upc.esMon May 17 11:27:15 PDT 2004
- Previous message: [Beowulf] Athlon64 / Opteron test
- Next message: [Beowulf] Athlon64 / Opteron test
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
What kind of applications are you running ? Just only to get a reference regarding our "theorical" future performance running our code on an Opteron. As a side note there's the power that the Opteron processor draws from the power supply , supposedly less than an Athlon at same clockspeed. I think a standard ATX 300W one should suffice for one Opteron, memory and a small harddisk. ¿ Are you using any other kind of power supply for AMD64 platforms ? Thanks. -- Daniel Fernandez <daniel at labtie.mmt.upc.es> Heat And Mass Transfer Center - CTTC www.cttc.upc.edu c/ Colom nº11 UPC Campus Industrials Terrassa , Edifici TR4 On Fri, 2004-05-14 at 02:06, Robert G. Brown wrote: > On Thu, 13 May 2004, Daniel Fernandez wrote: > > > Hi, > > > > We're studying the possibility of installing a 64 bit testing node. > > > > The main purpose is about getting impressions related to the performance > > increase we would obtain in our particular scenario, computational fluid > > dynamics. > > > > In order to do the test, we have no doubt about the OS: Red Hat > > Enterprise 3, but we are a bit confused about the harware of choice: > > > > Athlon64 > > Opteron > > > > As far as we know, Opteron has two main differences: > > > > - A wider memory interface (128 bit in front of 64) > > - A larger L2 cache memory (1 Mb) > > > > Before doing any test, the questions are: > > > > 1) > > > > Which is the theoretical maximum performance gain using full 64 bit > > architecture in front of 32 bit, taking into account that our > > computations are done in double precision floating point using really > > big matrices? > > I don't know what theoretical maximum gain means -- something with > multiplying out clocks, pipeline form factors, datapath widths, and > assuming perfect state? Never happens, more or less useless number. > > I do have a moderate amount of faith in what process-specific > microbenchmarks like stream and lmbench tell one (not as much as one > might think, but some useful data points). I also have a LOT of faith > in using your own application as a benchmark on a loaner machine (or > machines). So much so that this is one of the points of focus of my > next couple of Cluster World columns -- the importance of understanding > your application and the deep significance of "YMMV" when asking other > people what to buy. > > If stream or stream-like microbenchmarks would be of any use to you, I > have Opterons but not Athlon64's handy. Maybe somebody else can do the > other for you. Remember, though, that even these results may vary > significantly with compiler, with link libraries, with WHICH Opteron > motherboard you get and how memory is loaded onto the motherboard. It > is very, very difficult to get portable numbers without a prototyping > machine that is "like" the architecture you are considering in very > specific form (ideally, identical). > > > 2) > > > > Is it nowadays the 64 bit solution using Linux ready for production? > > If this is the case, which problems may we have to deal with in order to > > compile and run our code in a full 64 bit environment? > > I'm using dual Opterons (Penguin Altus 1000E's) running Fedora right now > without any major problems. Your two problems are likely to be > rebuilding things that aren't for some reason in the Fedora core and > already built for the Opteron. So far I haven't encountered any major > problems compiling gcc-based code linked to the GSL and other > useful/standard libraries. YMMV, but a lot of people have these boxes > now and together they form a powerful force pushing for full and clean > distros, so even if you find something that doesn't work it likely WILL > work and at worst you might have to help make it work in the best of > open source tradition, if it is in your key work pathway. > > We're likely to buy nothing else for cluster nodes in the medium run. > So far they are by far the cost-benefit winner. > > > 3) > > > > Which is the most mature solution: AMD Opteron or Intel Itanium? > > Did you mean mature or moribund;-)? > > I'm only half kidding. Itanium is dead as a doornail as technology goes > -- overpriced, underperforming, incompatible. Intel is migrating to a > (more or less) Opteron compatible 64 bit processor as fast as they can > get there, as Major Software Companies (MSC) have announced that they > aren't going to do major ports to new chips with new machine languages > and compilers anymore if they can possibly avoid it. If Intel dropped > the price of an Itanium to slightly LESS than that of an Opteron, I > think they'd still have trouble maintaining a market, because Opterons > are relatively easy to port to and will in principle run i386 code > (badly, of course) native. Sometimes. I haven't had a lot of luck with > it, of course, because you can't mix i386 code and 64 bit DLLs and we > installed a 64 bit version of the OS from the start, but theoretically > it will work. > > The good news is that Opterons are surprisingly fast for MY applications > for their relatively pokey CPU clocks, and some benchmarks show that > they can be really quite fast indeed for memory intensive applications > relative to e.g. an Athlon or P4 clock. They also run much cooler than > regular Athlons (again for my application). I draw ballpark of 185 > watts loaded (dual CPU Opteron) vs 230 Watts or so loaded (dual CPU > Athlon) running more or less the same code. > > rgb
- Previous message: [Beowulf] Athlon64 / Opteron test
- Next message: [Beowulf] Athlon64 / Opteron test
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
