Slashdot Mirror

"(especially since gromacs probably has tons of x86 optimizations in it) than a PS3 would."

http://www.gromacs.org/content/view/25/

I wouldn't bank on that, it gets almost Double the processing done on a g5 with a slower clock than a high end p-4. you might have wanted to look into that before you put your foot in your mouth. according to wikipedia the SPE in the ps3 is clocked to 3.2 ghz.

"Linux Pentium 4 1 Intel 8 3000 1024 10176 2280 1353 164 3045 357 0.95"

"Apple G5 PPC 970 1 IBM 2500 512 15309 4177 2213 175 5069 544 1.74"

As an academic I hope, for my own sake, that the quality of a code doesn't represent the intelligence of the one who wrote it, but more the lack of proper training in writing proper code. A lot of academic software is meant to solve one specific problem and then forget about it. At some point someone discovers that with a bit of rewriting an existing code can be re-used for another project, and over a few years you have yourself a 'software package' based on a combination of scripts, fortran, and C code, with a Makefile that should be tuned by hand and an input file format that is only comprehensible to the one who wrote it, and breaks at the moment you reverse two lines. Let's not talk about documentation at this point.

Things are getting better, though, projects like gromacs (a moleculer dynamics package) and jmol (a viewer), are build up pretty strictly, carefully written and sufficiently documented.

Crafting a solid code is an important and difficult task, which requires an experienced person to do it. A PhD is bound to have experience, but more likely in developing algorithms, not in writing solid code. I guess a matter of hiring the right person for the right job.

Thanks for your comments. You make a good point that scaling alone is not enough, if the code being scaled is inefficient. So you are probably aware that a good thing to check is how many "seconds" of some standard simulation can be done per computing unit. Although Gromacs is supposed to be the fastest gun in the West - and it is on a single processor, it doesn't scale vary well. At least in my experience. This may be due to the kind of machines I have access to. You may want to look at the Gromacs web site where some examples of scaling are listed: http://www.gromacs.org/content/view/26/39/ For "large" jobs, it is probably best to do some tests to decide which program to use. There are, of course, other reasons one might prefer NAMD (Schulten's system) to Gromacs such as its integration with VMD (the Illinois group's graphics program) or the possibility of interacting with a simulation "on the fly" using a haptic device... Ciao, OC

As someone else already said, and mentioned in Parent's link, this is a very specific machine, for Molecular Dynamics simulations, everything from memory handling to processing is optimized only for handlig particles and doing force calculations on them. Therefore, it'll serve a relatively small market.

That said, I'm very curious to see how fast it'll run gromacs, the MD program I use. This is pretty optimized for parallel simulations already, and I'm able to do the calculations I need on a small opteron cluster in no time.

The biggest problem might be now to find useful research questions to simulate on it! Actually that is the main problem why computational medicine didn't really take over yet. The good thing is that this machine will give researchers time to think about this instead of spending their time thinking how to get enough computing power.

Actually, for my field (Chemistry), what GCC -O3 does is irrelevant, except during the development phase of a program, or as a last resort for portability. We care about what the fastest native compiler we can find + optimized libraries does. The Cell will be no different; a few hand-optimized routines such as BLAS, FFTPack, etc, in libraries, then an auto-vectorizing Fortran-95 compiler on top. I will be interested in seeing how packages such as GAMESS or NWChem http://www.emsl.pnl.gov/docs/nwchem/nwchem.html/ behave once Fortran is available, and Cell shipped in something other than game consoles.

On the other hand, the GROMACS guys http://www.gromacs.org/, who write hand-optimized code on a per-processor basis, ought to be stoked. It already runs well using single-precision, so it looks to be tailor-made to a Cell-based setup.

PLease also check out GROMACS, a program capable of doing MD simulations and visualisations. It is GPL from [gromacs.org]. Just my $0.02 ...

  You'll have to confirm this with the Folding@Home people, but the versions I saw previously were spitting out Gromacs http://www.gromacs.org/ messages, which is written in C++.


Nope. Gromacs is written in plain C, with alternative implementations for some inner loops in fortran and asm.

Why can't the program have both C++ and Fortran modules in it? We do this all the time where I work.

You'll have to confirm this with the Folding@Home people, but the versions I saw previously were spitting out Gromacs http://www.gromacs.org/ messages, which is written in C++. Depending on what version they use will depend on whether the Gromacs team included the PPC optimizations.

Incidentally, IBM's XL Fortran simply screams on G5s. I've compiled ab-initio codes (Quantum Chemistry) with it, and get speeds identical to Opterons running Linux, compiled with Pathscale or IFC (in em64T mode). IBM's fortran may be why my cluster gets rolled into PPC Linux, when I can afford memory upgrades, rather than remain under OS-X. I like OS-X for the ease of use and programming, but it's hard to beat XLF in the field.

Would be interesting to know exactly what stuff do these machines do? Maybe they would even be able to share some code so that people can fiddle around with it optimizing


I don't know about the VT cluster specifically, but here's a couple of typical supercomputer applications that happen to be open source:

ABINIT, a DFT code.

CP2K, another DFT code, focused more on Car-Parinello MD.

Gromacs, a molecular dynamics program.


(should be fun)


Well, if optimizing 200 000 line Fortran programs parallelized using MPI sounds like fun to you, jump right in! ;-)

Note: Above applies to abinit and cp2k only, I don't know anything about gromacs except that it's written in C, not Fortran (though inner loops are in Fortran for speed).

Oh, and then there's MM5, a weather prediction code which I think is also open source. I don't know anything about it, though.

Sure, the benchmarks are impressive, but it would be nice to see more benchmarks using 64-bit-optimized software (eg. an optimized gromacs). 32 bit software just doesn't use all the power these chips have.

Like this: XPM file format.

Be afraid. Be very afraid.

---
If cars were open sourced, there would be at least five steering wheels in the cockpit, each operating differently -- but you'd be able to shift gears with your car stereo.

in case you were interested...

GROMACS is the main simulation program we use. Its very well programmed, optimized, and GPL to boot. I hope that the software I write will have this sort of functionality and optimization.

Optimized number crunching aps for Mac smoke (most) anything else out there, and certainly anything on the x86 side of computing.

Sorry, but this just isn't true. As far as I know, there is one single application (Genentech BLAST) where a heavily altivec-optimized G4 version beats a completely unoptimized x86 version. What Apple don't say is that there are several commercial x86-optimized BLAST versions that beat the Genentech one.

The true story is that anything using double precision (and most scientific/numbercrunching code does!) will run a factor two faster on x86 than G4, simply because Altivec only does single precision. There are also several applications optimized for double precision SSE2, while there is no such alternative on the G4.

It is also a myth that Altivec should be so much better than SSE. Sure, it does better per clock, but the clock in a P4 is more than twice that of a G4. Just check out e.g. ATLAS or GROMACS. Both these programs use Altivec on G4 and SSE/SSE2 on x86, and the x86 performance is significantly better even in single precision, not to mention the hardware price.

Finally, this assumes you don't consider the cost of porting the code to Altivec, or that writing it in Altivec from the beginning makes it unportable. This might not be important to photoshop users, but it is for scientific use: there isn't a single Altivec-capable machine among the world's 500 fastest supercomputers. If you just take a portable source and compile it, code generated by the Intel compilers on x86 will run about twice as fast as anything generated on G4.

No, I'm not a 'mac basher'. But you don't serve the Mac community by inflating benchmark results (Apple "flops" vs. real double precision flops, comparing hand-optimized code vs. nonoptimized code, not giving any details on how benchmarks where performed, not publishing SPECbench results like ever other vendor does).

All this will do is make people p*ssed off when they compile their first code on a G4 and realize it's a factor 2 slower.

For a comparision, have a look at a recent AMD cluster installation at

HPC2N. They could have used SSE/3DNow instructions to increase a bogus "flopcount" by a factor 4, but they don't. Instead they only mention the standard double precision flops (800 Gflop peak), and in practice they really achieve 481 Gflops on LINPACK.