Slashdot Mirror
Cray Unveils Its First GPU Supercomputer
An anonymous reader writes "Supercomputer giant Cray has lifted the lid on its first GPU offering, bringing it into the realm of top supers like the Chinese Tianhe-1A"
The machine consists of racks of blades, each with eight GPU and CPU pairs (that can even be installed into older machines). It looks like Cray delayed the release of hardware using GPUs to work on a higher level programming environment than is available from other vendors.
...will promptly be used for mining BitCoins.
Now to put this to work mining bitcoins!
Wait you mean there are legitimate reasons to have racks of supercomputing GPU's other than to solve arbitrary math problems in the name of psuedocurrency?
In a bit of shameless internet panhandling, I accept Litecoin Donations at Lbd2oH9QsthD1GfuUXPyka12YxvWJYnBVf
A Beowulf cluster of these!
At least until the value of bitcoin is such that it produces zero economic profit. The return on your supercomputer powered bitcoin venture will approximate the return on T-bills in... about... hold on..., OK. Now!.
...can it run Metro 2033 on High?
Does it use bus-parity?
I did some rough calculations regarding NICS's Kraken Cray XT5 and bitcoin mining. FYI, The Kraken was the 8th fastest supercomputer in Novermber of 2010. I determined that if the supercomputer put forth all of it's resources to mine bitcoins, it could generate 1,511.61 per day (or about $8,450.53/day). Granted, the Kraken has just regular CPU's doing the calculations. I could only imagine what a Cray supercomputer with GPU's in it would be capable of...
The fact that writing C and Fortran code using a message passing library constitutes a high level programming environment is a complete indictment of the sad state of parallel programming today. Seriously, do you want to be programming complex parallel algorithms on HPC machines using Soviet Era technology? I've tried that and it made me want to jump out a window. It's about as easy to program in this type of an environment as it is to program an FPGA (hint: it's a pain in the ass).
There is still a lot of HPC applications written in Fortran with this run them?
Also how hard if any of a porting will be needed to get good results from this.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
You would be right except that their are applications that do require the performance.
You can never have too much computing power for some applications like climate modeling. So what is your point?
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Occam is higher-level than C or Fortran, and it should be possible to adapt Erlang to parallelize across a cluster.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
bringing it into the realm of top supers like the Chinese Tianhe-1A
Uh, Cray already has machines in service that blow Tianhe-1A out of the water on real science. Tianhe-1A doesn't even exist anymore. It was a publicity stunt. Cray is already making the top supers. It's others that have to catch up.
You're forgetting things like PGAS and other higher-level parallel programming models. MPI is the dominant technology in use so these machines have to support it well. But they also support more future-looking tools.
It is if you just mint and sell or buy to keep the money. But if you use it to trade dematerialized goods, it can become a rally efficient currency.
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
Really, you've tried it and it made you want to jump out of a window? OpenMP is an extremely simple, easy to use add-on to the C language. It is one of the two current standards used for parallelized scientific computing, and although it will eventually be succeeded by a language with more features, it will be difficult for its successor to match its ease and workmanlike grace.
I honestly have trouble believing someone could have much difficulty with it. If you want to have the work in a "for" loop parallelized the extremely mentally challenging thing to do is write
#pragma omp for
just before your for loop. Look at all that difficult message passing you have to contend with! And since you're writing scientific calculations, C generally lends itself to good clarity in the code. I worked with a math major who had only done the smallest bits of C and Java beforehand, and he picked up OpenMP immediately. If you can't handle it, you really should reconsider whether your talents lie in software development. If you want to see what a truly awful parallelizing language or API is, look at UPC - unified parallel C.
MPI != OpenMP
MPI != OpenMP
HTH.
Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
The point is not for the job to be easy for your lazy ass, the point is for the code to execute as quickly as possible.
Nothing but a complete moneypit if we have no actual experiments to run on them that require that kind of scale
And we have plenty, the big ones off the top of my head being nuclear weapons work (as we've replaced live tests with computer simulations entirely), protein folding, climate modelling, and signals intelligence processing. I'm sure other ./ers without your childishly narrow experience of the world can think of others.
It's made of cores!
You can never have too much computing power for some applications like climate modeling.
...or calculating more Pi digits, as we're talking about useful applications.
What did you find awful about UPC? I've foudn it very pleasant to work with.
Craft Beer Programming T-shirts
Have you tried it off-node?
Yes...I am a rocket scientist.
Using applications that can take advantage of GPU processing power and multi-core CPU's to crack passwords means that anyone that can afford one of these can do a whole lot more in that regard...
Imagine generating rainbow tables!
Impressive hardware.
The article said they're adding OpenMP support, hence my comments were about OpenMP. If they also support MPI (I admit I skimmed quickly), all the better -- it's not particularly difficult to use, either.
"Private homosexuality was a criminal offence in Britain up until - astonishingly - 1967. In 1954 the British mathemetician, Alan Turing, a candidate along with John Neumann for the title of father of the computer, committed suicide after being convicted of the criminal offence of homosexual behaviour in private.He was offered a choice between two years in prison (you can imagine how the other prisoners would have treated him) and a course of hormonal injections which could be said to amount to chemical castration, and would have caused him to grow breasts. His final, private choice was an apple that he had injected with cyanide. As the pivotal intellect in the breaking of the German Enigma codes, Turing arguably made a greater contribution to defeating the Nazis than Eisenhower or Churchill. Thanks to Turing and his 'Ultra' colleagues at Bletchley Park, Allied generals in the field were consistently, over long periods of the war, privy to detailed German plans before the German generals had time to implement them. After the war, when Turing's role was no longer top secret, he should have been knighted and feted as a saviour of his nation. Instead, this gentle, stammering eccentric genius was destroyed, for a 'crime', committed in private, which harmed nobody. Once again, the unmistakable trademark of the faith-based moralizer is to care passionately about what other people do (or even think) in private."
Then again, if "high-end" means "we've implemented a lot of busywork in an effective way, so you can focus on your actual problem", I'm all for it. ... as long as the modules you use for the heavy lifting are written in a lower-level language. ;)
Oh, and there's nothing fundamentally wrong about writing HPC code in e.g. python
It depends on the task. Some of them are not complex. Some things are so embarrassingly parallel that you just tell the first node or whatever to apply a function to the first lot of data, feed the next lot to the next node and so on - then just concatenate the results together at the end. There's a lot of stuff in geophysics like that, for example - apply filter X to twenty million traces (where a trace is just like an audio track). You could do that with twenty million processor cores if you had them (but other bottlenecks would render that insane long before you got near that number).
There is still a lot of HPC applications written in Fortran with this run them?
Also how hard if any of a porting will be needed to get good results form builder.
But is it compatible with Duke Nukem Forever?
Sadly, the machine I casemodded in full Duke regalia in anticipation of DNF back in 1997 is wholly incapable of running the game, and since it's AT form factor it ain't gettin' upgraded...
Do not look into laser with remaining eye.
Yep. Works great!
There's more information on the GPU programming model in the HPCWire article. It is OpenMP directive-based, making it quite a bit easier to use than low-level CUDA and other such things.
Maybe so, but the comment to which you replied, and with which you disagreed, was specifically about "using a message passing library." That's MPI, not OpenMP. It's like responding to someone saying, "I don't like spam!" with "But grilled cheese sandwiches are so much tastier when you put ham on them, so clearly you're wrong!" Your statement may be technically correct, but as a response to the topic at hand, it is in error. :-)
Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
Have you tried it off-node?
Yes, and it works just fine; the only issues would be if I got my placement wrong via poor layout/blocking or I neglected to upc_memget something that I needed intense access to but for some reason couldn't make local in the initial layout. Neither of those require much forethought at all to avoid.
Craft Beer Programming T-shirts