Nvidia's Fermi hits flop-hungry challengers

Nvidia's Fermi graphics coprocessors have begun shipping through its OEM partner channel with a slew of tier-two players hoping the flop-happy GPUs give them a competitive edge against established players in the HPC server racket. The Fermi graphics cards and GPU coprocessors that are based on them were both previewed last …

[Brian Miller]

CPUs not as good as GPUs? No, really?

Does anybody remember the hey-days of Wietek? When an x86 motherboard would come with a socket for a Wietek FPU? The 32032-based Celerity minisupercomputers could sport four Wietek FPUs, as well as a dedicated Wietek integer unit. Yeah, six math coprocessors in a machine.

Now we are getting back to the old concept of dedicated hardware for math. Gee, been there before, huh? The big workstations have always had a huge need for FP math. The graphics workstation that hooked up to the Celerity had just as much memory as the main system. Things have shrunk from a dedicated cabinet to a card, then card to chips, then multiple chips. And now those chips have been tweaked to be their own math subsystem.

Nope, not revolution. Evolution, all the way.

Run, rabbit, run / Dig that hole, forget the sun / And when at last the work is done / Don't sit down / It's time to dig another one

[Mint Sauce]

Bring back co-processor sockets :-)

Woo, memory lane. I remember fitting an IIT 387 maths co-processor to my 386. Got scene rendering times in POV down to well under a day :-D

[RayG]

Just clarify one thing...

Are these the same nvidia chips that are widely slated for being too hot and PCIe-bustingly power-hungry in consumer graphics cards? And, remind me, is heat and power performance more or less important in massive HPC applications?

[Anonymous Coward]

Power Hungry?

It takes around 8.5 Xeon x5550 chips to equal the 630 Gflops of a C2070.

These Nehalem chips consume ~95 Watts a piece, for a total of over 800 Watts.

So the NVIDIA card has less than a quarter the power consumption of an equivalent intel solution.

[Graham Bartlett]

@Brian

Never mind FPU accelerators - how's about the whole parallel thing? Anyone else remember the Transputer? The company who sponsored me at uni (GEC Alsthom Transmission and Distribution Power Electronic Systems Limited, to give it its full title) used them, and they were pretty damn cool.

The Occam2 language in particular was a neat idea, since it gave native support for parallelism. No messing around with the detail of threads and stuff - you just said "PAR", and the paths under that statement ran in parallel. If you happened to be at the top level then those paths got spread over the separate cores, or at lower levels it timesliced, but all that was done for you. And comms between processors was equally seamless - from a software PoV it just looked the same as running over separate cores.

For a little while it was the fastest thing around. Trouble is that like all British technology, no-one was prepared to put money into it. So it drifted backwards until a single 486SX25 could comfortably blow away a bunch of Transputer cores, and that was that.

Now of course we're back where we started, bcos single cores have basically run out of speed-up potential. And of course, since Win95 programs use multiple threads to do stuff in parallel with time-slicing. So everyone has the joy of managing threads for themselves without any decent techniques for tracking deadlocks and livelocks, when back in the late 80s and early 90s anyone using Transputers had already solved this problem.

This is why I differentiate between computer science and software engineering. Engineering is about solving problems and keeping the solutions around, so you don't have to reinvent it every time. A civil engineer doesn't have to go back to first principles for a bridge, bcos after 1861 the principles for building a strong bridge have been pretty well ingrained in the profession. The trouble with computer science is that in constantly chasing the bleeding edge, they seem to have absolutely no idea of the history behind where they are, or following patterns in this. So single-core code gets hacked to explicitly support dual-core when dual-core processors come around; and then someone releases a quad-core processor and the CompSci boys need to hack their code again for "if(cores==4)". The idea that there's a pattern involved - number of cores increasing - seems to pass them by, as does the fact that back in the 80s there was a ton of work done on load-sharing across parallel processors.

[RayG]

Scotty's Law

AC: it's the same chip as the GTX480 games card that is claimed to burn a suspiciously similar 250w but actually gobbles 320; with a similar clock and more memory, it's not going to eat less. Your comparison is made even trickier because the Xeons can do a lot more than a graphics processor; the abilities of these things are pretty narrow. Most proposed GPU-assisted high performance computers need a lot of standard CPUs to keep the GPUs busy. It's pretty nifty, but it's no miracle. The ATI equivalents get more raw flops per watt - but do even less, so they need more CPU support. Same tradeoff (if you ignore coding difficulties, which you can't). Ye cannae change the laws of physics, Captain!

nVidia will continue to rule GPGPU for a while because they have a (fairly) widely known and (kinda) not too difficult language, but neither that nor this card will help them break out of fairly narrow applications where the performance per watt advantage creeps above marginal.

Graham: The transputer was a brilliant piece of engineering at totally the wrong time. It's like inventing the Ferrari in 1800; far more improvement in travel speeds from improving the roads would be needed before it was worth having. NOW we need it back, I agree... although I'm not sure I agree with your assesment of computer science; it's full of great ideas for parallelism in an ideal world but hasn't got much chance of meshing with the existing mess most people have to deal with...