Apple probably has more to think about here than just "can this guy be held to the click-wrap license". There are laws in various states regulating labor for people under the age of 18. I know I had "fun" with this when I worked paid theater shows in high school. Since Apple is going to take this and sell it, couldn't his work be considered "child labor"?
This sounds like such a boneheaded descision, though, that it must have come from their legal department.
Yeah - in fact there is an interconnect that is gaining popularity (among vendors 'cause it's still vapor:) called Infiniband. It approaches the speeds of what is presently NUMAlink, although I think it has longer latency. Hopefully it will make it beyond the vapor stage 'cause it's a really cool technology.
As for MOSIX, it is somewhat similar to the Cray T3E operating system (Unicos/mk) which uses microkernels on each processor. The programming model on it is generally MPI, which is one of the standard programming models for large scientific applications. Beowulf is actually a (partial? maybe it's full by now) MPI implementation.
Replying to my own post - I misread slightly. Irix graphics vs. Linux clusters is probably not a debate. Irix needs to be continued for SGI to keep selling the big Origin servers/supercomputers. Linux, while it has gotten dramatically better recently, isn't ready to run a 1024 processor system with a single kernel. So if you want SGI to ditch Irix, you're also saying they should ditch their monster machines. This would be exactly what Rocket Rick Belluzo tried (and failed) to do. That is what got SGI into the mess that they are slowly trying to climb out of now.
Your oversimplification is the problem. You don't just slap a NUMAFlex (ugh, I hated that name when I worked there - from now on I'll be calling it ccNUMA) "card" into a PC. ccNUMA is not I/O based, it's memory controller based. This is a big difference. One of the major advantages of an Origin (network is built into the memory system) over an x86 Linux cluster (network is part of I/O) is that it is a single system image to programmers and sysadmins. The advantage of a Linux cluster is....it's cheap. Quite a number of companies have tried building Linux clusters and found that there are a limited number of customers who are willing to pay large amounts for support but demand cheap commodity hardware. If you can afford $9000/year in support, you can probably afford the hardware in the first place. (Yes, yes, there are *some* places that will buy...)
You also made the same fundamental mistake that SGI made at one point with Linux clusters. You said "Think NUMAFlex cards for x86 hardware". Suddenly, you are now talking about spinning custom ASICs that don't sell in large volumes. Your harware is no longer entirely "commodity". This drives the price up more than you would think.
But would you go to jail to keep the privacy promise of the company you work for (assuming you don't work for a very small company with, like, 2 or 3 employees)? Somehow I doubt it (though, of course, I don't know you so I may well be wrong). My understanding of Lindows is that while they certainly aren't huge, they're not a "ma and pa" shop either.
Schools pay somewhere between a little and a lot less than list price for Macs. Apple has always been good about educational discounts on their products. I have gotten a number of them that way going all the way back to my Apple IIc+.
No longer dominates the Top 500 and no longer dominates the marketplace are two different things. The Top500 benchmark (LINPAC) doesn't do a lot of interprocessor communication and hence is the type of job well suited to a cluster.
As for cycles wasted/cost, that is going to depend on the applications involved. At some point, the sheer cost of the power wasted is going to be a factor. Obviously not on a garage built six node cluster, but if you start talking about 2048p the power *will* be an issue.
The IBM SP, while being *mostly* commodity uses some non-commodity parts and has a lot of proprietary software to make it work.
CPU caches, modern or otherwise, are not an issue with an application that has, say, a 1 gigabyte working set. It simply doesn't fit in the cache no matter what you do. You can restructure loops to make things better, but you're still going to be banging on memory.
You're right, commodity systems have overtaken a lot of areas that used to require traditional supercomputers, but then, the market for traditional-architecture supercomputers has *never* been big.
The article would have people believe that all a supercomputer is is a collection of not-quite-modern processors, memory, and an interconnect of some sort. This is simply not the case. If it were, why do many (granted a smaller number than before) people still buy real big iron? The answer is that Cringely's (sp?) collection of processors is not a real supercomputer for the kinds of applications that are associated with traditional machines. Traditional vector supercomputers still have processors that are faster than Pentium 4 class systems. Traditional massively parallel supercomputers (which are the most similar to a cluster) have a number of features not found in your average garage built cluster like a truely low-latency interconnect, gang scheduling of entire jobs, single system image for users/administrators/processes.
Clusters are great for embarassingly parallel applications (ie ones that have threads which don't communicate with each other much. This includes things like SETI@home and batch rendering of images. What they don't compare on is applications that communicate a lot like nuclear physics simulations. This is not to say that that will never change in the future, but for the time being it's still true.
Last, and certainly not least, real supercomputers have memory bandwidth that can match the speed of the processor. A Cray or an SGI Origin has an absolutely massive amount of bandwith from the processor to local memory compared to a PC. That allwos a traditional supercomputer to actually *achieve* the fantastic peak performance numbers. On many applications, the working sets are huge and don't fit in cache so you end up relying on memory being fast. On a PC, it's not and I've heard from sources I consider reliable (though I have no actual numbers to back this up so it may be rumor only) that one large cluster site sees around 10% or less of peak on a cluster for a nuclear physics simulation, whereas, on a vector Cray, you can hit ~80% of peak. This means that the cluster has to be 8 times more powerful and when you start multiplying the costs by 8, they start looking like the same price as a real supercomputer.
So my point is that building a real supercomputer does not mean grabbing a bunch of off-the-shelf components, slapping them together with a decent network and running Beowulf (or a similar product).
I am most certainly *not* confused about this difference, having dealt with it quite heavily the last two years. However, the original post didn't say which API was im question. Quite often, reworking API's involves mucking up the source API also.
Also, you are dead wrong on "no work has to be done on Open Source drivers." They have to be recompiled. That is work. Especially at a company that has a good release process that involves regression testing after the recompile. Also, just because the driver is Open Source doesn't mean that everyone who uses it is compiling it themselves from scratch.
Part of what I meant was that when you make changes to API's that require any sort of recoding, even if I, as a company, decide to open source my driver, I will *still* have to ensure that the code gets updated to comply with the new API if I want to call what I do "supporting Linux." Joe Random Clueless User isn't going to want to wade into the source to some random driver to fix it in case it breaks. Heck, I am a kernel devloper and *I* don't want to do that to make my drivers work (unless I'm the one writing the driver). My point is that breaking stuff doesn't necessarily mean that it's only going to break binary-only modules.
Maybe. Developers who care if anyone other than other developers is going to use their software care about whether it's easy for users to use their software. Having to constantly recompile and release new versions or making your users do the same is not friendly to either the release manager or the user. I am a developer and so I know that all I have to do is cd to the right place and type make/make install. Try describing that to someone who really never uses a Unix shell or worse what to do if that doesn't work for whatever reason. Breaking binary compatibilty also makes upgrading the kernel more of a production if you use any modules that don't ship as part of baseline Linux.
Also, I still maintain that doing stuff like this is counterproductive to getting people to develop for or use Linux. It's also a strategy that Microsoft uses (change document formats any time someone figures out your old one).
You obviously haven't tried stacking a medium to large sized PA. I've helped set up stacks of TurboSound speakers 3 high/3 wide + subs (ok, I know, that's not an enormous setup, but it's not for your bedroom either) and while they have wheels, they are quite awkward and heavy. However, I strongly suspect that these speakers will sound pretty bad at high volumes when the bladder starts to vibrate, but hey, I could be wrong. They would certainly look interesting, though:)
Re:Keeping up with kernels
on
Torvalds Tells All
·
· Score: 4, Insightful
Changing the API often will result in companies that *do* opensource drivers to drop support as well. If there's a valid technical reason to change API's, great - go for it. Otherwise, you're pulling the exact same kind of crap that Microsoft does to try to force people to use their platform and that people on this forum regularly complain about. If I were a product manager and got told "you're going to have to have a developer spend 2 weeks rewriting some code because some guy decided to break the API for no good reason", I would *not* be a happy camper.
Well, the problem is, you need to store the stuff in a way in which there's no oxygen present. That's pretty darn rare on Earth. In your example of the car, I still maintain that hydrogen is more dangerous in a crash than gas if the tank ruptures. In the case of hydrogen (liquid or otherwise) it will turn into a gas quite quickly (if it isn't one already) and come in contact with oxygen and probably sparks/flames. Bang. With gasoline, it will at least stay a liquid. There you'll get a (rather hot and nasty) burn and not an explosion. This is basically the old addage that an empty gas can is more dangerous than a full one. Personally, I'd still rather have a hydrogen powered car, but more for polution reasons than safety.
You know people will pay a lot more attention to you if you leave off the personal insult. Of course I did. In both high school and college. Maybe you'd prefer the following: "When in the presence of a couple million pounds of liquid oxygen, liquid hydrogen is quite explosive". Hydrazine is as inert as helium when there's nothing for it to react with too. In fact, every chemical that doesn't break down all by itself is. I didn't think I really had to state this, since I think the majority of people reading this realize that stuff doesn't burn or explode all by itself sitting around.
Kinda depends on what you do for a living doesn't it? I'd like to see you predict the weather acurately (well, as I guess I should say "as accurately as the standard weather forcast") over the coming week or two without a supercomputer. Or design an aerodynamic car. Or an airplane. Or a new medical drug. Or a spaceship. Or any number of defense/military applications. There is plenty that a supercomputer can do that people do on a day to day basis. You just have to be in the right line of work. (And by the way, a supercomputer *can* do everything a desktop machine could do, it'd just be rather pointless to use a machine that big as a desktop...)
I think you're confusing your propellants. The shuttle does launch on liquid Oxygen and liquid Hydrogen, a fact confirmed by this. The explosion of the Challenger was caused when the LO2 and the LH mixed in the presence of the heat from the rocket motors. Liquid hydrogen itself is quite explosive. As for the hydrazine, I believe that shuttles do carry it, but use it for their on-orbit manuevering thrusters because it doesn't require a spark to ignite. I think most satelites use it also.
(Yeah, I know, I'm feeding the trolls) Please provide an example of another system providing a total single system image which does better at the same system size. You may have problems since there aren't that many machines out there that grow to 128p (I suppose the 106p Sun box is "close enough").
What are *you* smoking? The Origin 3800 is certainly *not* using the "same back plane a the sun was 2 gens back". In fact, if you were anything other than a hopeless troll, you'd realize that the Origin 3800 doesn't *use* a backplane at all. You get, on a 512p system, 128 I/O channels, each of them supporting up to 12 PCI slots or 4 XIO slots. I can't remember off the top of my head what the bandwidth per channel is but it's on the order of a gigabyte/second (I wanna say it's 1.6 GB/sec, but I might be wrong).
Let's not forget SGI with the Origin 3000 (a system which I worked on a lot when I worked for SGI). It scales to 512 processors in a single system image (perhaps 1024 by now?) with a terabyte of RAM. In addition, you get 128 I/O channels with that each of which can have up to 12 PCI slots (or 4 "legacy" XIO ports). If you want redundancy, you can partition the system into multiple OS images. A 128p Origin as a single system image regularly gets over a month of uptime without a failure. So basically, while Sun can make this look like the best thing since sliced bread, it *has* been done before.
Bin Laden *has* declared war on the United States. He may call it a Jihad (though according to what I know about Islam, what Bin Laden is doing goes against every principal of the religion) or a Fatwa or whatever, but he has told his followers it is their duty to kill Americans. That is a declaration of war. How we respond to this declaration is what needs to be debated. I agree completely that we need to understand why these people hate us so much and I don't get the impression that many people know. If we fail to understand why we were attacked, we will probably make the problem worse with everything we do. On the other hand, we can't let mass murderers run around loose.
As for WOrld War II, please enlighten me as to when the French government harbored Hitler any more than the rest of what eventually became the Allies? Or do you mean the French government after Hitler's army set up a puppet government? We *did* attack that government for doing exactly what you said - harboring Hitler.
Although, you do bing up a good point with the comparison of Hitler to Bin Laden. Both have a fanatical following in an incredibly impoverished country that was screwed over by the West. Both have identified an "evil" enemy to blame their country's suffering.
There are multiple different acredidation boards. The one that would do MIT is almost certainly different than the one that would do Missouri-Columbia. I know that the one that does Ripon College (where I grew up) is totally different than the one that does Carnegie Mellon (where I went to school).
Yeah, I will definetly admit that as benchmarks go, LINPAC is a very good one. I was just trying to make the point that it is not the be all/end all of the world of scientific computing:)
The Top 500 is not a list of who makes the best machines. It's a list of what real world installations that run LINPAC the best. LINPAC is a benchmark, not a real piece of code. The T3E holds the record for *sustained* performance on real world code. That, in my opinion, and probably the opinions of the people still buying them, is more valuable than any benchmark. The "systems" on the list above the T3E in question are all strongly connected clusters, not single system image machines. Well, the Hitachi and NEC boxes are probably is an SSI. That's not saying they are bad, mind you, just that they aren't single machines. There are still some codes that run best on vector based SMP systems and for those codes, you buy a Cray. Also, for MPI code that communicates *a lot* between nodes, the T3E will run rings around a cluster.
Just to sumarise my basic point: The Top 500 is a benchmark and is not necesarily a good indication of who makes better computers than who.
When you were working on Origin, there *were* no Origins past 512 processors. The first one came online less than a month ago. Anything you saw was a cluster.
As for Irix being 32 bit, that is 100% false. Irix for Indy/R4000 Indigo and O2 is 32 bit. Everything else has a full 64 bit kernel and can run 64 bit binaries. Heck, we couldn't even address all the memory on all the nodes in an Origin without 64 bits. Just because the time is stored in a 32 bit value does *not* mean it's a 32 bit OS.
Slashdot Mirror
This sounds like such a boneheaded descision, though, that it must have come from their legal department.
As for MOSIX, it is somewhat similar to the Cray T3E operating system (Unicos/mk) which uses microkernels on each processor. The programming model on it is generally MPI, which is one of the standard programming models for large scientific applications. Beowulf is actually a (partial? maybe it's full by now) MPI implementation.
Replying to my own post - I misread slightly. Irix graphics vs. Linux clusters is probably not a debate. Irix needs to be continued for SGI to keep selling the big Origin servers/supercomputers. Linux, while it has gotten dramatically better recently, isn't ready to run a 1024 processor system with a single kernel. So if you want SGI to ditch Irix, you're also saying they should ditch their monster machines. This would be exactly what Rocket Rick Belluzo tried (and failed) to do. That is what got SGI into the mess that they are slowly trying to climb out of now.
You also made the same fundamental mistake that SGI made at one point with Linux clusters. You said "Think NUMAFlex cards for x86 hardware". Suddenly, you are now talking about spinning custom ASICs that don't sell in large volumes. Your harware is no longer entirely "commodity". This drives the price up more than you would think.
But would you go to jail to keep the privacy promise of the company you work for (assuming you don't work for a very small company with, like, 2 or 3 employees)? Somehow I doubt it (though, of course, I don't know you so I may well be wrong). My understanding of Lindows is that while they certainly aren't huge, they're not a "ma and pa" shop either.
Schools pay somewhere between a little and a lot less than list price for Macs. Apple has always been good about educational discounts on their products. I have gotten a number of them that way going all the way back to my Apple IIc+.
As for cycles wasted/cost, that is going to depend on the applications involved. At some point, the sheer cost of the power wasted is going to be a factor. Obviously not on a garage built six node cluster, but if you start talking about 2048p the power *will* be an issue.
The IBM SP, while being *mostly* commodity uses some non-commodity parts and has a lot of proprietary software to make it work.
CPU caches, modern or otherwise, are not an issue with an application that has, say, a 1 gigabyte working set. It simply doesn't fit in the cache no matter what you do. You can restructure loops to make things better, but you're still going to be banging on memory.
You're right, commodity systems have overtaken a lot of areas that used to require traditional supercomputers, but then, the market for traditional-architecture supercomputers has *never* been big.
Clusters are great for embarassingly parallel applications (ie ones that have threads which don't communicate with each other much. This includes things like SETI@home and batch rendering of images. What they don't compare on is applications that communicate a lot like nuclear physics simulations. This is not to say that that will never change in the future, but for the time being it's still true.
Last, and certainly not least, real supercomputers have memory bandwidth that can match the speed of the processor. A Cray or an SGI Origin has an absolutely massive amount of bandwith from the processor to local memory compared to a PC. That allwos a traditional supercomputer to actually *achieve* the fantastic peak performance numbers. On many applications, the working sets are huge and don't fit in cache so you end up relying on memory being fast. On a PC, it's not and I've heard from sources I consider reliable (though I have no actual numbers to back this up so it may be rumor only) that one large cluster site sees around 10% or less of peak on a cluster for a nuclear physics simulation, whereas, on a vector Cray, you can hit ~80% of peak. This means that the cluster has to be 8 times more powerful and when you start multiplying the costs by 8, they start looking like the same price as a real supercomputer.
So my point is that building a real supercomputer does not mean grabbing a bunch of off-the-shelf components, slapping them together with a decent network and running Beowulf (or a similar product).
Also, you are dead wrong on "no work has to be done on Open Source drivers." They have to be recompiled. That is work. Especially at a company that has a good release process that involves regression testing after the recompile. Also, just because the driver is Open Source doesn't mean that everyone who uses it is compiling it themselves from scratch.
Part of what I meant was that when you make changes to API's that require any sort of recoding, even if I, as a company, decide to open source my driver, I will *still* have to ensure that the code gets updated to comply with the new API if I want to call what I do "supporting Linux." Joe Random Clueless User isn't going to want to wade into the source to some random driver to fix it in case it breaks. Heck, I am a kernel devloper and *I* don't want to do that to make my drivers work (unless I'm the one writing the driver). My point is that breaking stuff doesn't necessarily mean that it's only going to break binary-only modules.
Also, I still maintain that doing stuff like this is counterproductive to getting people to develop for or use Linux. It's also a strategy that Microsoft uses (change document formats any time someone figures out your old one).
You obviously haven't tried stacking a medium to large sized PA. I've helped set up stacks of TurboSound speakers 3 high/3 wide + subs (ok, I know, that's not an enormous setup, but it's not for your bedroom either) and while they have wheels, they are quite awkward and heavy. However, I strongly suspect that these speakers will sound pretty bad at high volumes when the bladder starts to vibrate, but hey, I could be wrong. They would certainly look interesting, though :)
Changing the API often will result in companies that *do* opensource drivers to drop support as well. If there's a valid technical reason to change API's, great - go for it. Otherwise, you're pulling the exact same kind of crap that Microsoft does to try to force people to use their platform and that people on this forum regularly complain about. If I were a product manager and got told "you're going to have to have a developer spend 2 weeks rewriting some code because some guy decided to break the API for no good reason", I would *not* be a happy camper.
Well, the problem is, you need to store the stuff in a way in which there's no oxygen present. That's pretty darn rare on Earth. In your example of the car, I still maintain that hydrogen is more dangerous in a crash than gas if the tank ruptures. In the case of hydrogen (liquid or otherwise) it will turn into a gas quite quickly (if it isn't one already) and come in contact with oxygen and probably sparks/flames. Bang. With gasoline, it will at least stay a liquid. There you'll get a (rather hot and nasty) burn and not an explosion. This is basically the old addage that an empty gas can is more dangerous than a full one. Personally, I'd still rather have a hydrogen powered car, but more for polution reasons than safety.
You know people will pay a lot more attention to you if you leave off the personal insult. Of course I did. In both high school and college. Maybe you'd prefer the following: "When in the presence of a couple million pounds of liquid oxygen, liquid hydrogen is quite explosive". Hydrazine is as inert as helium when there's nothing for it to react with too. In fact, every chemical that doesn't break down all by itself is. I didn't think I really had to state this, since I think the majority of people reading this realize that stuff doesn't burn or explode all by itself sitting around.
Kinda depends on what you do for a living doesn't it? I'd like to see you predict the weather acurately (well, as I guess I should say "as accurately as the standard weather forcast") over the coming week or two without a supercomputer. Or design an aerodynamic car. Or an airplane. Or a new medical drug. Or a spaceship. Or any number of defense/military applications. There is plenty that a supercomputer can do that people do on a day to day basis. You just have to be in the right line of work. (And by the way, a supercomputer *can* do everything a desktop machine could do, it'd just be rather pointless to use a machine that big as a desktop...)
I think you're confusing your propellants. The shuttle does launch on liquid Oxygen and liquid Hydrogen, a fact confirmed by this. The explosion of the Challenger was caused when the LO2 and the LH mixed in the presence of the heat from the rocket motors. Liquid hydrogen itself is quite explosive. As for the hydrazine, I believe that shuttles do carry it, but use it for their on-orbit manuevering thrusters because it doesn't require a spark to ignite. I think most satelites use it also.
(Yeah, I know, I'm feeding the trolls) Please provide an example of another system providing a total single system image which does better at the same system size. You may have problems since there aren't that many machines out there that grow to 128p (I suppose the 106p Sun box is "close enough").
What are *you* smoking? The Origin 3800 is certainly *not* using the "same back plane a the sun was 2 gens back". In fact, if you were anything other than a hopeless troll, you'd realize that the Origin 3800 doesn't *use* a backplane at all. You get, on a 512p system, 128 I/O channels, each of them supporting up to 12 PCI slots or 4 XIO slots. I can't remember off the top of my head what the bandwidth per channel is but it's on the order of a gigabyte/second (I wanna say it's 1.6 GB/sec, but I might be wrong).
Let's not forget SGI with the Origin 3000 (a system which I worked on a lot when I worked for SGI). It scales to 512 processors in a single system image (perhaps 1024 by now?) with a terabyte of RAM. In addition, you get 128 I/O channels with that each of which can have up to 12 PCI slots (or 4 "legacy" XIO ports). If you want redundancy, you can partition the system into multiple OS images. A 128p Origin as a single system image regularly gets over a month of uptime without a failure. So basically, while Sun can make this look like the best thing since sliced bread, it *has* been done before.
As for WOrld War II, please enlighten me as to when the French government harbored Hitler any more than the rest of what eventually became the Allies? Or do you mean the French government after Hitler's army set up a puppet government? We *did* attack that government for doing exactly what you said - harboring Hitler.
Although, you do bing up a good point with the comparison of Hitler to Bin Laden. Both have a fanatical following in an incredibly impoverished country that was screwed over by the West. Both have identified an "evil" enemy to blame their country's suffering.
There are multiple different acredidation boards. The one that would do MIT is almost certainly different than the one that would do Missouri-Columbia. I know that the one that does Ripon College (where I grew up) is totally different than the one that does Carnegie Mellon (where I went to school).
Yeah, I will definetly admit that as benchmarks go, LINPAC is a very good one. I was just trying to make the point that it is not the be all/end all of the world of scientific computing :)
Just to sumarise my basic point: The Top 500 is a benchmark and is not necesarily a good indication of who makes better computers than who.
As for Irix being 32 bit, that is 100% false. Irix for Indy/R4000 Indigo and O2 is 32 bit. Everything else has a full 64 bit kernel and can run 64 bit binaries. Heck, we couldn't even address all the memory on all the nodes in an Origin without 64 bits. Just because the time is stored in a 32 bit value does *not* mean it's a 32 bit OS.