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."
Check out Apple's X-Grid technology!
It runs on any OSX system, 10.2.8 and up. Put your spare cycles to work.
Xgrid: High Performance Computing for the Rest of Us
Never ask for directions from a two-headed tourist! -Big Bird
If you want examples of operating systems that help with gridding, check out Plan 9 from Bell Labs and it's sister project Inferno. Nice thing about Inferno is that it runs on Linux, Windows, Mac OS X, Plan 9, and on native hardware.
Free of Flash! Free of Flash!
The new generation of marketeers use Grid, but they rarely are refering to what computer science engineers refer to grid clustering. I think the marketeers talk about Grid when they really mean virtual Operating Systems running on abstracted hardware platforms: either a mainframe, or otherwise kick-ass multi-way system that has been virtually partioned, or something like vmware piecing together several x86 style servers.
Frankly, I don't like the word Grid being applied in this way. However, the latter technology is facinating (virtual OS) and will come to dominate computing in the next few years.
The basic idea is total abstraction of the application/service from hardware/location. The app gets the resources it needs, can be cloned/replicated to another location for distaster tolerance, and can scale and grow on demand based on needs by simply throwing more hardware modules at it. It's not just limited to computing but also applied to storage and network.
Someone you trust is one of us.
True; however, when you think about the big picture, the vast majority of real-world situations have at least *one* parallelism in them, and with even one parallelism, a grid usually makes sense.
For example, let's say you're trying to determine the best FOO, and running a FOO is a highly serial process. Even though you can't split up running each FOO, you can pass the processing of each FOO test case that you want to run to a different machine.
True - sometimes, you need the results of your previous run in order to plan your next run, and sometimes your *only* need is a single run of a very simple algorithm for which there can be absolutely no parallelization. However, more often than not, even algorithms that need tightly coupled data have at least *one* stage which can benefit from parallelization - and you really need only one to get the benefits.
"Lock and load, Brides of Christ!"
If you've got a problem that's trivially parallelizable, then sure grid computing is great! RC5, seti@home, and similar projects can benefit from grid computing (really, that's what grid computing is -- someone else's code able to run on your machine when it's idle and do work).
However, don't even begin to think you'll be solving anything that requires any sort of processor to processor communication. Rocket simulation (our local favorite example here at UIUC) for instance is heavily communication based.
The linpack benchmark that top500 uses also needs a low-latency interconnect to perform really well, so don't expect to see "the grid" sitting up at the #1 supercomputer slot on top500.org anytime soon (or really, ever, unless someone develops FTL networking). Latency on the internet in general (and specifically around the world thru all those switches and latest_slashdot_hot_chick_movie.torrent packets) is nothing near what a supercomputer needs.
Now, there are research groups looking at ways of making communiation delays less of a problem, including the one I was in while I was in grad school. There's a number of ways to do it, but none of them I've seen are going to take on worldwide-network-latency and survive with their performance intact.
Even something as "simple" as chess wants to have a fast interconnect - every node that's gotten stranded working on low-priority (bad move) work is a wasted node you may as well not have.
Slashdot Patriotism: We Support our Dupes!
Um, no, Univac was a real 20th-century computer company (later merged into Unisys). Asimov probably named Multivac after Univac, not vice versa.
"Grid" technology to do this stuff has been around for decades e.g. NQS, hell NASA gave away PBS in the 80s & 90s.
The problem is that most of the CPUs out there run Windows, which is currently damned near useless for this kind of thing. It'll require a rewrite of the OS to take proper advantage of the potential of a network of windows boxes for general purpose computing. OTOH, a couple of shell scripts and SGE (http://gridengine.sunsource.net/) does the job on Linux and other Unix systems.
Government of the people, by corporate executives, for corporate profits.
Yes, but you know that there are tighly coupled clusters with hundreds or thousands of nodes available on the grid that looks/acts like a single resource on the grid. There are also vector supercomputers like Cray's and NEC's available if one need the capabilities these provide.
Here is a link to a cool Java applet that shows all jobs running on the European research grid:
LCG2 Real Time Grid Monitor
I don't know about which part of networking you are talking but sockets in Java are about as complicated as the concept can be implemented. Most other high-level languages I know do it a lot more intuitive and e.g. Perl or Python run on at least as many different platforms as Java does.
Linux is not Windows
In a Grid context, people usually mean Condor-G.
Parity: What to do when the weekend comes.
Because I'm feeling contrarian, too, I'll call you on your claims. Virtualization can be very cheap, and very easy to administer. VM/370 was based on CP/CMS, which was developed using government money, so it was open source. In an early example of why open source is such a good idea, several big timesharing companies took CP/CMS and hacked CMS to get rid of the real I/O instructions (CCW's, or Channel Command Words) inside it. You see, CMS was a real single-user OS. So CMS could run on bare hardware, just like it could run under CP. Thus, CMS issued CCW's to talk to what CMS thought were "real" I/O processors on "real" hardware. Which meant that when CMS ran under CP in user (non-privileged) mode, every time the machine tripped over one of these CCW's, an illegal instruction trap was generated. The trap was caught by CP, which then parsed and painstakingly emulated the CCW in an extremely complex routine called "CCWTRANS." Many have lost their sanity reading the code to CCWTRANS. Anyway, although really cool, this strategy also turned out to be really expensive.
Meanwhile, because they all had the source code to CP/CMS, the timesharing companies all came up with the same basic great idea. They hacked CMS to get rid of the CCW's, and replaced the CCW's with the equivalent of fast BIOS traps into CP. So CP didn't have to translate or emulate anything any more, things began to run at native speed, and suddenly everything was lickety-split fast again. In fact, this hack sped up CMS to the point where the premier speed vendor, National CSS, could run 250 users with decent performance on a 370/168 mainframe. VM/370, meanwhile, topped out at a measly 60-70 users. IBM either never figured out the hack, or as is more probable, wasn't very interested in VM/370 anyway (their cash cow was and still is OS/MVT and its successors).
So you are correct; VM/370 was a dog. But CP/CMS, hacked with traps, was totally amazing. I was there; I was a CP system programmer; I know.
The modern equivalent of this strategy is called Xen. Xen has been a topic here before. I predict you will see a lot more about it in the future.