$208 Million Petascale Computer Gets Green Light

coondoggie writes "The 200,000 processor core system known as Blue Waters got the green light recently as the University of Illinois at Urbana-Champaign and its National Center for Supercomputing Applications (NCSA) said it has finalized the contract with IBM to build the world's first sustained petascale computational system. Blue Waters is expected to deliver sustained performance of more than one petaflop on many real-world scientific and engineering applications. A petaflop equals about 1 quadrillion calculations per second. They will be coupled to more than a petabyte of memory and more than 10 petabytes of disk storage. All of that memory and storage will be globally addressable, meaning that processors will be able to share data from a single pool exceptionally quickly, researchers said. Blue Waters, is supported by a $208 million grant from the National Science Foundation and will come online in 2011."

Comments

More crap code

[kramulous]

Cool thing about the globally addressable petabyte. That way people writing really crappy code that don't bother thinking about their memory storage can just thrash away. And who cares about pipeline stalls.

I find it funny how the people who have never been formally trained with writing in a language (Mathematics, and just science in general) write the best codes while the majority of the IT people I see write the most appalling code I've ever seen. I think it has something to do with the fact that the science people don't pretend to know everything and are much more willing to learn something new while the IT people already know everything.

Re:More crap code

[Anonymous Coward]

Cool thing about the globally addressable petabyte. That way people writing really crappy code that don't bother thinking about their memory storage can just thrash away. And who cares about pipeline stalls.

I doubt they can just write crappy code. It's very unlikely that all this memory is on a single bus, so the more distant a core is from the memory it's addressing, the slower that access is.

It's a little bit like putting a video card with 1GB of lightning-quick video RAM in your computer. That VRAM is part of your computer's address space, so you can certainly use it just like regular RAM. But talking to it over the PCI-E bus is slow as fuck compared to talking to main memory. This is why game developers spend a lot of time ensuring that all the textures in a scene can fit in a typical video card's local RAM. It has nothing to do with whether the GPU itself can handle that level of detail without slowing down: it's because your framerate will drop from 50 to 2 the instant you have to transfer a texture from main memory to VRAM.

I think it has something to do with the fact that the science people don't pretend to know everything and are much more willing to learn something new while the IT people already know everything.

It's because science people aren't familiar with the programming aphorism: "Code first, optimize second, if at all." Optimized code is more difficult to write, more difficult to understand, more difficult to make bug-free, more difficult to maintain, and more difficult to extend to include new features. It's also more difficult to port, which is a big problem because optimized code is dependent not just on a particular processor family or manufacturer, but sometimes on the microcode level of a specific stepping of a processor model.

Being a little more kind to the science-types, it's probably also because most scientific problems are very well-defined before they get to the stage where computers get involved. So it might be quite acceptable for a scientific program to run on only one machine and produce correct output for a certain narrow type of inputs. In that case -- and considering that the highly-paid research scientist and his team of grad students might be sitting on their thumbs until they gets back the results of the computations -- it can certainly make sense to expend significant effort on optimization.

For the most part, though, it's more important for a program to be usable, featureful, secure, and correct (more or less in that order) than it is for it to run fast. Only when poor performance begins to impact those primary concerns should you begin to optimize.