Slashdot Mirror
Visions Of The Future Of Grid Computing
CaptianGrid writes "Computing grids, or software engines that pool together and manage resources from isolated systems to form a new type of low-cost supercomputer, have finally come of age. BetaNews sat down with some of the world's leading grid gurus to discuss the significance of such distributed technologies and separate grid hype from grid reality."
Hasn't the blackout taught us to move away from GRID type setups? If people just created their own power the blackout would have affected us less. Could this principle not be used for home computing? Rely on yourself and not on others?
Live forever, or die trying.
Threads are a step backwards in the evolution of software. Basically you are turning your back on all the protection that the OSes give you for free. A single bad instruction in a thread will bring down the entire process. Because threads are very difficult to migrate across machines in a cluster you will see more software written to use heavier-weight but more grid-friendly ways to communicate like sockets and pipes.
Grids are great for non-time critical computations tasks. But what happens when everyone needs cycles now! My guess is that systems will evolve to give cycles to the highest bidder/highest priority. In such an environment, low-priority tasks will become effectively impossible on a grid - there will always be some higher-priority/higher-paying task that usurps the cycles.
I wonder how long SETI@home will last if home PC users realize they can "sell" cycles to meet for-pay demand for computational power.
Two wrongs don't make a right, but three lefts do.
Sure. You're tasked with simulating atomic bomb detonations, and your algorithm's data is all tightly coupled with each other (I don't know enough about this particular task to state to what degree this is the case). Sure, you can't split up the simulation of any particular bomb simulation, but are you going to be simulating just one explosion? Doubtful - you'll undoubtedly be testing at least a couple dozen, probably hundreds or thousands of explosions (different environments, different bomb configurations, etc). Each simulation can be fanned out to its own node.
"Lock and load, Brides of Christ!"
Maybe it's less efficient (as in your chess example), but the amount available may be able to compensate for it. If your grid is only 60% as efficient as your supercomputer, but you have three times the power (#'s pulled out of the air), then grid is still beneficial.
hm. The european data grid is a grid OF clusters and shared memory supercomputers (as is the american "teragrid"). You don't use it for trivially parallelisable jobs necessarily - you use the grid infrastructure to farm out runs of potentially tightly coupled codes to different computers on the grid, not run the jobs across the grid (even with a perfect continent-wide grid, lightspeed lag would kill your latency!). So on Cluster A, because there's a time slot at 17:00, I'm running my job with input parameters XYZ, and on Cluster B, because it's not busy at 03:00 with PQR.
The grid provides a system to batch-submit to a continent-wide set of batch queues, and replicate input and output data sets to a continent-wide set of storage systems. You don't have to be running a job spread _across_ 3 clusters to be using the grid's ability to marshall spare capacity!
packaging the task up, transmitting it to another machine through a glacially slow network, unpackaging the task, performing the work ...
:)
This would help.
Unless your task is significantly computationally demanding
Isn't that what we're talking about here?
Of course, one can't forget the main benefit of grid networking: it's *cheap*. You get a *lot* more CPU horsepower for your dollar, so you want to use it on "computationally demanding" tasks if you can.
"Lock and load, Brides of Christ!"
What on earth are you bothering with X-grid for?
You have the in-house developed Condor that's amazing!
Me neither, but for slightly different reasons.
The main definition of a grid is a pattern of intersecting lines. While sun or ibm may arrange their computers neatly in rows of vertical racks and build it in a grid pattern physically, nothing of this remains for the actual use or architecture of so-called grid computing. This leaves large swaths of parallel algorithms by the wayside. The only things you can efficiently compute on a grid are the "embarassingly parallel" codes that don't interact much with neighboring CPUs nor require large data sets. Sure, you can do SETI work units and compute large primes, but for chess, weather, and crash sims you'd be better off with a traditional supercomputer or local cluster.
Wiki reference here
The use of the word "grid" here is in the sense of an electric power grid. The idea is that you should get computing power on demand, just like you get electic power on demand.
The reason for such an arrangement is that high-speed interconnects are expensive. Building a single cluster that is uniformly very high performance would be horrible for anyone other than a very rich organization to consider.
On the other hand, grids alone are way too slow to handle the needs of time-critical communication, which is what you have a lot of the time in parallel computing.
A hybrid, able to place components of a problem according to that component's needs, would seem to be the logical solution. It is also the scalable solution. Clusters often have an upper limit in size. By having grids of clusters, you have a virtually infinite capacity. True, there simply aren't any clusters that have reached the upper limit. Yet. But it's getting tough at the size they are at right now.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)