Slashdot Mirror
Supercruncher Applications
starheight writes "Bill McColl has written an article contrasting traditional massively parallel supercomputing with a whole new generation of compute-intensive apps that require massively scalable architectures and can deliver both incredible throughput and real-time responsivenes when processing millions or billions of tasks."
Just in time for Vista!
Dell's website consumer pricing generator.
Argh.
Imagine a Beowulf cluster of-- oh. Wait.
"No freeman shall ever be debarred the use of arms." -- Thomas Jefferson
Looking at his examples (Search, Ecommerce, Software-as-a-Service, Infrastructure-as-a-Service, Fraud Detection) I have to think "wow, single point of failure". Lots and lots of fault-tolerance needed to put all your eggs in one basket like that.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Slow news day, huh?
Can we please have a "no links to random, boring blogs week" on Slashdot?
The term "massively parallel" indicates a system operating without those constraint.
Engineering is the art of compromise.
There is no such thing as "massively parallel!" It makes no sense! Parallel in qualitative, NOT quantitative! Things are either parallel or they're not, there are no degrees of "parallelness!"
Sure there are. Say you want to find the maximum of 4 integers. You can do that in parallel, but you won't gain much if you have more than two processors (or execution units). Contrast this with say rendering an image using a path tracer, where each ray is independent of each other. First problem is hard to scale up, second one isn't. I'd say that means that ray tracing is a "more parallel" task.
Also, writing algorithms that has to run on 10000 processors efficiently is not exactly the same as one that has to run on 4 processors, in the same way that writing a multiplayer game that handles four players isn't the same as writing one that can handle thousands of concurrent players. So they toss on the "massive" part to separate the cases. At least that's my take on it.
"Give me a SUPER number crunch."
"We have a 32.33, repeating, of course, percent chance of survival."
"That's better than we usually do."
"Never give up, for that is just the time and place when the tide will change." -Harriet Beecher Stowe ^_^
In most cases, researchers request a specific number of cores, based on experience of how well their code scales. Some codes to auto-scale, depending on available cores, but these are rarer. The way it works is in a batch queue system... Users submit a job required 2000 cores, and wait until that many are available. Then, when the cores become available, their job runs for 6-48hrs or more, depending on the job. In most cases, a large number of researchers are often in contention for computing time, and wait their turn in line. The good ones tend to understand the system better, and will submit workloads that reflect the current available resources, thus limiting the time their work spends sitting in the queue.
Microsoft Sucks, F/OSS Rocks. I get mod points now right?