Mac's rule. PeeCee's drule. Buuyah!

I don't know when parallel processors started being called supercomputers. They're very limited in what they can do fast. In normal problems, they're no faster than your desktop PC. The publicity picks the problem to prove they're really fast.

A machine that's actually faster doesn't have to worry what problem it's being asked to do.

I would think that as long as the machine is multi-threaded, it can send a single thread (operation) of a process to an idle processor. Since supercomputers are measured in operations per second, that should be what counts, not so much the processes themselves.

Then it's no different than that many PC's. Just pick one that isn't busy.

The general problem is that you can't find problems that have many threads. As a result, you have 32,000 processors idle waiting for one to finish; and then you have the same 32,000 waiting for the next one to finish. Basically it's running at the speed of a PC unless you can find 32,000 things to do all the time.

Certain scientific calculations can with a lot of programming effort be forced into parallel form, meaning that you find 32,000 things to do all the time; and then it's actually 32,000 times faster than a PC. But such problems are very rare.

Google I think fragments its archives into 32,000 pieces in effect, and speeds a search by that amount as well. Another example of a problem being set up and forced into parallel form, by fragmenting the task with serious programming effort in setting it up for exactly this.

In general it's hard to find such problems, and so you're stuck with a white elephant if you have one of these. You literally can't give them away.

Even the Crays had the parallel problem. The processor wasn't really very fast, but it had an architecture that would keep almost every piece of hardware busy all the time if you worked at finding an application that it fit.

A real supercomputer is one that's actually faster on every problem. It becomes more of a stretch (there's a pun there) the more esoteric the problem becomes that you have to feed it in order to get it to come out fast.

You're all wrong. Depending on how the software was written, a single process can theoretically be run on all the computers, thus virtualizing them into one "super" computer. Sure, when you boot up Adobe Photoshop and its written to run on a dual processor, the super computer will only use two processors to run the application. But if Adobe Photoshop was written to run on 1100 Dual Processor G5's, then the calculations would be performed in a fraction of the time over all the machines. So it works, but it takes special software. But for the price, you can't beat it. Oh yeah, and Mac's rule. PeeCee's blow. That is all.

The ``special software'' part is where the problem is concealed. There is no ``special software'' unless you have first of all a problem that can be done in parallel. Most problems cannot be. They're mostly serial. Get one of these beasts and it will run exactly like your PC on your PC stuff.

Ron,

I'm a little confused about your terminology. What do you mean by "problem"? I'm used to talking in terms of processes and threads. A computer program runs processes which in turn breaks each process into threads. (A thread being an operation that requires a processor time slice.) In a multi threaded operating system, configured for multiple processors, the operating system takes all those requests and sends them to an available processor. The only special programming that should be needed is telling the process to use multiple processors, and telling the operating system how to load the processors.

We've been doing that sort of thing with telecom equipment for a while now. You just tell the operating system to load share the processors.

The supercomputer model is: a single superfast processor. You can run anything on it that you can run on a PC, and it will run thousands of times faster.

It is very rare that a problem breaks up so you can do this with parallel processors of average speed. It happens, but it's rare.

There are applications. A simple one is a time-sharing system with lots of processors. It simply sends the next independent job to an idle processor. Everybody runs at the average processor speed but it supports lots of users.

Another is any parallel computation that can be set up to solve a problem, where threads are identified that don't have to interact for a while, and so they can be run in parallel.

Most programs though solve problems that require constant decisions affecting everything downstream, and these cannot be made parallel, and they're a bitch to program even with lots of hardware support for it. That is to say, most problems are inherently single-thread.

A true supercomputer would not care whether it was single thread or multi thread. It would run faster on them all.

It's easy to imagine though that telcom equipment has independent threads and only wants to build up volume. Multiprocessing is fine for that. It's not a supercomputer though.

The amazing part of this article has nothing to do with how good the computer is. The surprise is a mac being cheaper. Overpriced would be the norm for market macs. Hell, this supercomputer is pretty close to a desktop mac.

There are basically three different classes of problems as far as "supercomputers" are concerned:

1) Ones that easily and obviously break down into many independent jobs. Most server applications fit this, since the requirement is usually to do many fairly easy jobs for many different users, and no single job requires too much CPU power. SETI was another example - the requirement was to search a whole lot of recorded data for certain patterns, so all that was needed was to split them out into a lot of separate short recordings. These are easy, but someone still has to write the software to split up and parcel out the separate jobs, and keep the loads more or less balanced. Simply sending each thread to a different computer doesn't do, since some threads will take 1,000 times as long as others in a typical program.

2) Jobs requiring many repetitive calculations, but also requiring frequent data exchange between cells. E.g., Finite Element Analysis, used by engineers for analyzing loads on structures, but also used for such things as trying to simulate the weather. That is, you divide the atmosphere up into a lot of little cells. For each cell, from the conditions (temp, humidity, cloudiness, wind) and inputs (sun, air temperature in surrounding cells) now, you can calculate the conditions a minute from now. Repeat this across all the cells, again and again. FEA is quite simple, except for the calculation load so you try to split the job up across several computers. The problem is the heat and air flow across the boundaries between cells - it requires a continuous exchange of information, which means that your clustered computers are soon spending most of their time talking to each other rather than computing. SMP (a few very fast CPU's sharing a large fast memory) seems to be the best way to parallelize something like this. It's quite good enough to figure out whether the wings will come off of an airplane, but still orders of magnitude short of accurate climate modeling.

3) Problems with much decision-making and little obvious repetition. Don't even think about parallellizing these, unless you can find a way to rewrite the program.