Supercomputing: Raw Power vs. Massive Storage
securitas writes "The NY Times reports that a pair of Microsoft researchers are challenging the federal policy on funding supercomputers. Gordon Bell and Jim Gray argue that the money would be better spent on massive storage instead of ultra-fast computers because they believe today's supercomputing centers will be tomorrow's superdata centers. They advocate building cheap Linux-based Beowulf clusters (PCs in parallel) instead of supercomputers." NYTimes free reg blah blah.
Its nice to see some MS researchers going against the perceived stereotype and being open in their suggestions like this.
And I think they have a good point about massive memory being a very important part of computing advancement right now.
Atheism is a religion to the same extent that not collecting stamps is a hobby.
You're right, this could be more about impeding Sun and IBM than anything else, but I don't seem them recommending this as a one-size-fits-all deal - rather, they're making the case that clusters should be pursued over supercomputers for the data-intensive number crunching activities like nuclear explosion modeling, etc.
Stop by my site where I write about ERP systems & more
You have to wonder why, all things seriously being equal, they don't recommend a *BSD-based solution instead of a Linux-based one. Esp given the near-equivalent functionality of the *BSDs, and the fact that MS has publicly endorsed the BSD license in the past, citing it as an superior alternative to the GNU License.
From the MS site, the Bay Area Research Center is "... a small Microsoft Research group located in the San Francisco Bay Area. We've been working on two large projects with other universities, companies, other Microsoft Research groups, and with Microsoft product groups in Redmond and Cupertino. These projects are Scalable Servers and Media Presence. "
I can't see scalability involving commodity hardware with MS OSes. In spite of Microsoft's desktop domination strategies, and small business server dominance (arguably, at least for the moment) they know they won't be taken seriously about clustering Windows 2003 server, purely because there is no design AFAIK in the kernel for operating in clusters in the first place. This is supercomputing using commodity hardware, not supercrashing using commodity OSes. Linux is perfectly situated to be recommended by anyone because it is not a competitors product, per se.
The homepages of the two men can be seen here, if anyone is interested in some of the more interesting history of the two. Little of it has to do with Microsoft propaganda and the marketing machine:-
Gordon Bell
Jim Gray
Conversion Rate Optimisation French / English consultant
Raw speed will always be useful for problems that are hard to parallelize. Right now those problems (parts of crypto, some quantum physics calculations, etc.) are important scientifically, but away from the money.
Industry will spend R&D money on clustering for storage and reliability, without major government subsidy, because there's a crying need for it. How much government money went into Google/eBay/Amazon?
Government research is supposed to complement industry R&D - to be aimed at fields where the results are still important, but maybe not as profitable. This is why government should not abandon raw speed as a research goal.
To a Lisp hacker, XML is S-expressions in drag.
I agree to the point that money should be spent on data storage, but I'm not sure that money should be taken out of the "super computing" budget or wherever the money comes from. I think it should be another priority, but really, we need both. Clusters aren't the solution to every problem, and super computers have their place. All in all I think it amounts to we need more government spending in the IT sector, and better spending in general. The ISP where I work at is also a geological data and oil resevoir company. We recently did a project for the DOE and they budgeted us $2 Mil. just for a web page about the project. Ridiculous. That $2 Million would buy a pretty nice data storage center I would think. But I guess that's what happens when your govt pays $500 for a hammer.
Everyone is entitled to their own opinion. It's just that yours is stupid.
Try using a Beowulf-style cluster for a CFD problem, and watch as all computation grinds to a halt as your processors and interconnects devote all their capacity to inter-node coherency and synchronization. You need a traditional supercomputer like an SGI Origin for jobs like that, because of its massive internal bandwidth.
That used to be true, but I don't think it is anymore. A high-end Beowulf compute node these days typically gives you 2 processors and 2-4 Gigabit Ethernet channels, going into a high-end switch. That seems like it's in the same ballpark as the SGI Origin, which gives you nodes with up to 16 processors, up to 12GB/sec aggregate memory bandwidth, and 8 channels going into the router. They aren't going to perform identically, but I think the differences are diminishing.
Furthermore, with distributed shared memory software, parallel linear algebra libraries, and SIMD-on-MIMD libraries, you can program it more or less like you would have a traditional supercomputer, without having to worry a lot about synchronization.
OpenMosix, in an upcoming release, even promises to give you address spaces that cross machines, giving you effectively a NUMA machine on a network of PCs.
B...S...; we use a small Beowulf (16 dual 1 GHz PIII boards with a fast ethernet backplane from PSSC) for oceanic numerical modeling and the problem scaled almost perfectly with number of processors.
Our models are 3-dimensional, but sudivision and message passing takes place only in the horizontal two-D direction. And message passing only needs to account for the boundary nodes.
Ease of use is a bit of a larger issue, however. For convenience sake I usually end up running at home on the dual Athlon and then doing big runs and batch jobs on the Beowulf.
... grumble, grumble, grumble, mutter, mutter, Millenium... Hand... Shrimp, I tol' 'em, I tol' 'em.