Among other things, it works a whole lot better in the deserts of the southwest, where you get sunshine 345 days of the year. Not as well in most population centers.
gallium arsenide was a reasonable technology to pursue at the time. It had teething problems, was expensive to manufacture, and ccc ran into funding problems related to a drop off in defense spending after the end of the cold war. That is not to say that Gaas was a completely foolish technology for the time. There are many reasons to believe that it offered faster switching times, and smaller module packages than did ECL logic of the time. CCC was putting out a 500mhz machine in the early 90's, four years before ECL machines hit that speed, and six years before cmos could.
Of course, wire delays started to become a concern for multi-board processors, and cmos began to deliver enough transistors on a package that out-of-order superpipelining became possible, and the performance advantage of a slightly higher clocked ecl/gaas processor evaporated. This is not to say that there was not a good six-seven year window of opportunity for gallium arsenide, while cmos was still pretty feeble. I'll also point out that gaas has continued to be used in specilized applications like serdes, high-speed signal-drivers, and cell-communications drivers. You're never going to get millions of mesfets on a chip, but they work really well, if you need a few dozen really fast drivers.
As for trips, and a lot of other designs like it, it essentially is working on the problem that modern cmos introduced. We have more transistors than we know what to do with, but we can't drive them any faster. I've seen some clever designs that are very good at solving one type of problem. I have yet to see a design that solves the problem in the general case, and with minimal change in the programming model. A lot of smart people are working on the problem, however, so I suspect that something will come about; It may not happen quickly, however.
Probably this means that the system is funded for 4 years. About 2 years in, they will try to renew their grants. If they do, they will probably upgrade the system at about 3 years with a mid-life kicker. This would probably be new blades using 8-core opterons and 2-4 times as much memory. They might even get a second kicker if AMD comes out with a socket-compatible upgrade. After that it's probably time for a forklift upgrade.
This cycle is fairly typical for HPTC systems, and a 6 year total life-span is pretty usual. (Though there seem to be a ton of old origins still out there, for some reason. I don't think the altix has sold well enough to displace all the old irix machines)
The cost (power, man-hours) of running a big machine like this is pretty high, so you really only run the thing if you can get a lot of billable hours out of it. Some machines stick around for a long time, as there are specific codes that run on them, that aren't easily ported to the successor machine. Since this is just a big linux cluster, the codes can easily be run on the next big linux cluster, so the desire to keep the outdated machine (or part of it) around, is pretty small. That's why you often see a machine room with a huge linux cluster on one end, and a couple of big, but outdated IBM/SUN/SGI/Alpha SMPs at the other end. I remember Cray J90s hanging around WAY past their competitive lifespans, because you could run the old codes from the 80's on them with no modifications. That's not gonna happen for JAXLB (Just Another x86 Linux Box).
"The F22 can take over many of the original roles of the B-2" What? The F22 and B2 are ridiculously different aircraft with hugely different roles. The F22 is a short range air superiority fighter. The B2 is a long-range penetration/strategic bomber. They are about as diametricly different as two military jets can be. Even the proposed fb-22 bomber variant of the raptor has radiacally different capabilities compared to the B2. (half the range, 1/10th of the bombload)
"congress is only funding a handful of new aircraft" Congress has only funded a handful (21) or the B2s. It has funded 130 of the F22s. The reason for the low funding of each is the same. It's not clear of how much use either are. Both planes were designed to wage war (either open, or proxy) with the soviet union. IF you look at the most useful planes in the Iraq and afgan wars, they are the B52, F16, and (are you ready for this one) the predator drone. We don't need more sophisticated air superiority jets, because we established air superiority in the first 10 hours of the conflict. We don't need new stealth penetration bombers because the bombers from the 50's are just as good, and can be based from simpler airfield, closer to the action. The air force brass seems to have gadget-lust that doesn't seem at all realated to the real threats and mission requirements. If you want to give the air force new planes, give them lower maintence F16s and B52s.
Furthermore, do you really think that the F22s and F35s will be cheaper to maintain than the existing planes? You're gonna pay those costs either way.
Lastly, the air force budget is higher now, as a share of GDP, than any time since the second world war. If they can't buy planes with they money they are already getting, they are seriously mismanaging their money.
Sandia and Oak Ridge are not coming up with an exaflops computer. They are contemplating how to write software, in a way that will effectively use exaflop computers when they become available. This little group has a budget of $4.7million, which is enough to pay a dozen high-level research scientists, and a half dozen software developers for a year. They're not going to reinvent high performance technical computing.
They're going to rework some fundamental math libraries to deal with the obvious trend in HPTC. They know that they are going to have to learn to deal with a million nodes, each with dozens or hundreds of CPU cores. The ratio of memory latency to processor speed is getting worse, not better. The ratio of interconnect bandwidth to node performance is getting worse, not better. Memory capacity per node is going up, but capacity per processor core is flat or downward. Disk performance per flop is flat or down. Checkpoint/restart of a million nodes in a non-starter. Flops are more plentiful, and massively cheaper, with each generation, but there are costs associated with that. There are a lot of paradigm changes in the way that these systems are managed, and the way that these codes are written, to deal with the limits imposed by these machines.
Ten years ago the largest systems had ~1000 processors, and jobs would usually run on 100-300 nodes. Now they have ~20,000 processors, and jobs tend to typically use 4000 nodes. Presumably an exaflop machine will have ~1,000,000 processor cores, and typical jobs will use 200,000 nodes.
I think this institute is being funded to deal with issues exactly like the problem you present. Checkpoint/restart was a decent solution for a YMP, but it has outlived its usefullness. I imagine there will someday be some sort of transactional checkpoint that allows nodes to save state periodically, and independantly. Algorithms will have to be rewritten to do it, but it's necessary. We can't get away from massive parallelism. There are serious limits to how fast you can make a processor, so the only way to make a faster machine is to make more.
The other possibility is to use redundancy and fault tollerance to deal with node failure, much in the way that commercial banking systems run. This, of course, quadruples the cost, which most HPTC shops are unlikely to deal with. It's a gross problem, and all the solutions are poor.
True. Sandia does a lot of nuclear systems simulation.
However, Oak Ridge is an unclassified facility doing mostly academic research on climate change, fusion energy, biological systems modeling, geological systems,... the list goes on, but almost any US researcher can get an account on their systems, and purchase cpu time. The trouble is that neither of these labs has quite enough resources to dramatically change computer architecture directions. They can both afford to have 1 or 2 very high end machines at a time, which is enough for companies like IBM or Cray to make subtle changes in their product lineup, but not enough to completely redraw the map of the HPTC marketplace.
SGI probably got the technology for pennies on the dollar. When a company closes its doors, the investors and creditors are left holding the bag, and they're interested in getting out from under a little bit of that debt, and do it quick. If they don't unload the intellectual property quickly, it decays, looses mindshare in the marketplace, and falls out of date. This is doubly true in the world of linux, where you have to keep up with the kernel changes, and the changing distributions.
Similarly, SGI has changed a lot of their focus from their expensive cache-coherent single-system-image servers to clusters of small/cheap nodes. SGI has great compiler technology, data-management software, and systems integration knowledge. They may not, however, have great systems-management tech. You don't need that for single-system-image machines. Even the big columbia machine at nasa is only a cluster of 20 machines. You can do a lot of stuff by hand, or with creative shell scripts, when you're dealing with 20 machines. With 400, it's tougher. I'm sure this won't solve all their problems, but I bet it will help quite a bit.
They made money on their cash ballance, and by offering more shares, that's not really the same as an operating profit. Investors aren't going to keep dumping money into you, if you don't make a return on that money better than a t-bill. (that said, they sure do keep throwing good money after bad at sgi.)
2007 may have been better than 2006 for SGI, but I look at it as loosing money on every deal, just to drive up volume. It's too bad, as they have good technology in the altix and cxfs, but they just can't seem to produce them at a price that allows them to be profitable.
ACtually Blue Gene is not a big SMP. From the OS point of view, it's basically a cluster. So the article basically says that instead of using a cluster of 2U rackmount servers to host your internet app, you can use a cluster of Blue Gene nodes to host a large internet app. Trade one cluster for another. The Blue Gene alternative is attractive, in that each node uses very little power, and is very densely packaged. However, you do lose some flexibility. If, for some reason, your application required many hundreds of 2U servers to host it, you could replace it with a single rack of Blue Gene, and save some floor space and power. However, for most applications, which use a couple dozen web servers, it seems like overkill.
publishing something on facebook is exactly that, publishing. You have no reasonable expectation of privacy; It's just like buying an ad in the newspaper, and printing a picture there.
It seems to me that the fun of table-top Role Playing Games is the storytelling. It's the plots, and the character development, and the mythical settings that make RPGs so exciting. Do we really need to further refine the game rules, or is this a simple cash grab for the publisher, when all the gamers out there update to the new rules?
Anyone willing to lend you the money also understands how inflation works.
The difference between utility costs and your mortgage/rent math, is that most of the costs for the utility are consumables, they really have no cost until someone is paid to dig them out of the ground. The costs of a home are all up-front whether they are yours, or a landlords'. You're not really comparing apples to apples.
There is a LOT of coal in North America. As more appalacian mountains are leveled, the political cost will rise, but I think it's a LONG time before we use up all the coal.
Nanosolar uses a thin-film substrate, if I'm not mistaken, which will likely break down, ironically from sun exposure. The thin-film products I'm familiar with, break down after a few years, so they must have done something clever to prevent that. I'd be surprised if they last 25 years, but don't really know.
You can't send excess electricity into the grid in very large amounts. Like I said, a few home hobbyist can get away with that, but you can't really store much electricity in the grid, you just reduce localized demand, and the transmission infrastructure can only tollerate a limited amount of this. If we are talking about hobbyist-scale offerings, it's meaningless to compare against the cost of coal, and we should really only compare against the residential rate charged by the local utility. If we're looking at hundred-megawatt scale deployments, then we can compare against coal.
Also, $1/W panels don't exist. Some startups are promising that they can do it, in the hopes of collecting enough venture capital to put together some production lines. I've heard a lot of promises from startups looking for capital, and few of them are completely true. There is also a lot of infrastructure necessary, beyond the cost of the panels, in a PV solar system. I'm sure that PV will continue to be deployed, and I welcome any reduction in the cost, but I don't think price-parity with fossil fuels is likely, near-term.
True: The top500 is mostly a contest of who can buy/power more processors. That doesn't mean there is no innovation going on, it simply doesn't matter for placement in the top 500. Most savy HPC customers know that linpack performance isn't all that important, and they do use other metrics to select their HPC solutions.
Infinaband is a much better interconnect than ethernet, and it's made it into a lot of the top500 systems. IBM's Blue-Gene and Cray's seastar networks are even better and they're represented too. Even within infinaband, we're seeing more DDR products, and 4x cards in compute nodes. Switches are becoming bigger, and the switch links are wider, and some are even going Quad-data-rate. Sun put together a very impressive fat-tree-in-a-box for the tacc system. The next generation Bluegene and cray networks are just around the corner, and NEC dramatically improved the IXS in the SX series. Interconnects have been changing quite a bit in the last couple years, and look like the trend will continue.
Memory is following the curve set by the server/desktop world, but processors have been showing some real innovation. Dual and quad core CPU's aren't the answer to every problem, but they offer a real improvement for some problems, with a low cost/power impact. Cray is working on the next generation of vector and multithreaded processors. NEC just put out a 100Gflop vector processor. Power6 looks like an amazingly fast superscalar cpu. Blue gene and sicortex use low-power processors in innovative ways. Cell, clearspead, and GPU coprocessors are beginning to be deployed in very limited ways; with the promise of a lot more to come.
I hate to be an optimist when cynicism is in vogue, but I see a lot of innovation in the last few years, and a lot on the horizon. How effective some of that innovation is, and how cost competitive, I do not know. It's pretty cool though.
Your example of the 2400 baud modems for a linux cluster isn't completely accurate, as linpack does a little bit of communication, though the point is well taken. The top500 list only uses linpack to measure performance, and linpack represents a very easy problem to solve. Essentially, the top500 list is a list of which machines do a really good job of solving a trivially difficult problem. The hpcc benchmarks (http://icl.cs.utk.edu/hpcc/) are a lot more interesting; though, even these need to be read with some caution.
Ranking supercomputers is a really hard problem. Each application has different needs for communication latency, bandwidth, programming model, cache size, memory bandwidth, and computational throughput. Then you have to ask: how much optimization can I do to the benchmark? Am I going to be able to do the same amount of optimization for each of my applications? How easy is it to extract this performance? The guys writing the software for these things are usually professors or post-docs in the hard sciences, not in supercomputing.
You're forgetting two very important things. In your math you're forgetting to amortize your capital costs. Basically you're assuming that you can get a 0% loan. In reality, paying for solar up-front, instead of coal as you need it, you need to tripple the cost of the solar, because of the interest you will have to pay over the 25-year life of that "loan".
Secondly, solar provides great energy during the middle of the day. However, most residential electrical demand happens in the early evening, when people get home from work and turn everything on. Most industrial users of electricity need a constant supply, around the clock. Commercial users need electricity throughout the day, with a spike in the late afternoon as air conditioning demand increases. Solar-electricity provides for some, but not all of these needs. Storing solar energy in batteries, thermal storage systems, or mechanical storage systems doubles or tripples the cost again.
Thus, even with $1/W panels, general-purpose solar power is still 8-10X the cost of coal. I'm terribly doubtful that solar power will ever be economically competitive with coal, UNLESS you factor in the ecological costs. Unless we start taxing utilities for the carbon that they emit, we will not see solar become competitive, beyond little feel-good projects, and home-hobbyists.
Cell only provides that throughput using single precision (32bit) floating point. Its double precision performance is almost an order of magnitude slower. IBM is introducing a revised version of cell, that greatly improves double precission, but not to the same level as the single precision speeds.
Even if the computational rate qualifies, the usability is greatly hampered by the lack of memory.
There are several petaflop machines in their initial phases of roll-out right now, but peak performance isn't the only number worth paying attention to. The SX-9 is an amazing architecture, with orders of magnitude more bandwidth than the roadrunner system, both in interconnect, and in memory bandwidth. It's also a very expensive machine. The SX, however, has an advantage of being an update and refinement to a very established architecture. codes written for the SX-3 are going to perform well on the sx-9.
Roadrunner is a cool machine, but hard to program. You have most of your compute capability on the cell coprocessors, which are connected by a non-coherent infinaband pipe, to the host opteron processor. On the cell, you have a powerpc doing the program setup, and the 8 spu engines chunking through the data in parallel. If you can parallelize your program enough, you can get those working really quickly, but you have to do all the memory management in software, and control flow has to happen on the ppc. It's not impossible to get good performance from such a machine, but don't expect to just drop your existing software onto it and get decent performance. Blue gene is a less radical approach, and it took 3-4 years for a dozen codes to be rewritten to take advantage of it. Los Alamos runs a small number of applications, but needs a lot of performance. Thus they can spend the time to optimise their small list of apps for such a heirarchical design.
infinaband is not bad for a single processor node. The trouble is that everyone wants to use a single port to power 16 cores.
Sadly, linpack does play a role in the computers that are purchased. Sometimes the guys making the decision are not the engineers and programmers, who then have to suffer with the consequences. Alas.
Well, the answer depends on your problem. These are sort of at the opposite end of the spectrum from distributed. There are a lot of solutions in between. In order from cheapest to most expensive per flop.
Distributed computing needs to do a lot of computation on very tiny bits of data. You can pack up the problem set and send it over the internet, then do an hour or two of work on a CPU, and send another internet-sized transfer back. It's very economical, only cares about raw cpu performance, and can't be used for very many tasks. [you can use any hardware for these]
Low-end Commodity clusters are build up of cheap servers connected with a cheap interconnect like ethernet. They can pass data between nodes at several tens of MB/second, and with latencies under a tenth of a second (realized). Again, most of the concern is the raw processor performance, though a little more coordination amongst processors is needed, and the amount of data being crunched can exceed a node's memory size, though it's best if it doesn't. [everybody and their mother makes these, HP and IBM make a lot of money on these]
High-end commodity clusters add a much higher performance interconnect like quadrics, myrinet, or infinaband. They also add software features like parallel filesystems, and virtualized system mangement. They also use higher-reliability nodes, and maybe more processors per node. [IBM, HP, SUN, SGI, fujitsu, Bull, and a lot of smaller shops sell these]
scalar-supercomputers are integrated machines using commodity processors, but with custom interconnects, packaging, operating systems, and software. They can often use more sophisticated memory sharing programming models, though are often still programmed with mpi. They pass even more data around the nodes, more often. They have parallel filesystems and have highly integrated system management tools. They tend to deploy a lot of redundancy features to insulate the user from node failures. [IBM, Cray, SGI]
vector-supercomputers use custom vector processors to amortize the cost of memory loads/stores across the computation, and do away with a lot of the branches that exist in scalar code. This allows VERY high performance on some codes (often many tens of times the performance of scalar processors), but poor performance on code that doesn't vectorize well. They are very expensive, but quite useful for a select set of usage schenarios. [NEC and Cray]
A rough estimate of the cost per peak-flop is that it approximately doubles for each of these, as you go up the list. It's important to realize, however, that peak-flops isn't the same as realized-flops.
The NEC processor is modern in its memory protection, so linux could easily be ported, however, there's a lot of time/money invested in super/ux so there's little incentive to do so. Even if linux were ported, it wouldn't be like the linux running on your desktop, it would be a stripped-down kernel, and some basic libraries.
I don't know what you're talking about with Xen and mosix. Neither seem at all applicable to the sort of software run on big-iron machines like this. NEC SX machines run code written for the SX, and highly tuned for the environment. They run openMP codes on a node, and MPI codes across nodes, or hybrid MPI/OpenMP nodes if you've got really good programmers. Mosix is for thread-migration around a cluster. It's more of a parallel database or web server sort of solution. The SX is a far too expensive machine to use for those sorts of tasks.
Slashdot Mirror
Among other things, it works a whole lot better in the deserts of the southwest, where you get sunshine 345 days of the year. Not as well in most population centers.
gallium arsenide was a reasonable technology to pursue at the time. It had teething problems, was expensive to manufacture, and ccc ran into funding problems related to a drop off in defense spending after the end of the cold war. That is not to say that Gaas was a completely foolish technology for the time. There are many reasons to believe that it offered faster switching times, and smaller module packages than did ECL logic of the time. CCC was putting out a 500mhz machine in the early 90's, four years before ECL machines hit that speed, and six years before cmos could.
Of course, wire delays started to become a concern for multi-board processors, and cmos began to deliver enough transistors on a package that out-of-order superpipelining became possible, and the performance advantage of a slightly higher clocked ecl/gaas processor evaporated. This is not to say that there was not a good six-seven year window of opportunity for gallium arsenide, while cmos was still pretty feeble. I'll also point out that gaas has continued to be used in specilized applications like serdes, high-speed signal-drivers, and cell-communications drivers. You're never going to get millions of mesfets on a chip, but they work really well, if you need a few dozen really fast drivers.
As for trips, and a lot of other designs like it, it essentially is working on the problem that modern cmos introduced. We have more transistors than we know what to do with, but we can't drive them any faster. I've seen some clever designs that are very good at solving one type of problem. I have yet to see a design that solves the problem in the general case, and with minimal change in the programming model. A lot of smart people are working on the problem, however, so I suspect that something will come about; It may not happen quickly, however.
Probably this means that the system is funded for 4 years. About 2 years in, they will try to renew their grants. If they do, they will probably upgrade the system at about 3 years with a mid-life kicker. This would probably be new blades using 8-core opterons and 2-4 times as much memory. They might even get a second kicker if AMD comes out with a socket-compatible upgrade. After that it's probably time for a forklift upgrade.
This cycle is fairly typical for HPTC systems, and a 6 year total life-span is pretty usual. (Though there seem to be a ton of old origins still out there, for some reason. I don't think the altix has sold well enough to displace all the old irix machines)
The cost (power, man-hours) of running a big machine like this is pretty high, so you really only run the thing if you can get a lot of billable hours out of it. Some machines stick around for a long time, as there are specific codes that run on them, that aren't easily ported to the successor machine. Since this is just a big linux cluster, the codes can easily be run on the next big linux cluster, so the desire to keep the outdated machine (or part of it) around, is pretty small. That's why you often see a machine room with a huge linux cluster on one end, and a couple of big, but outdated IBM/SUN/SGI/Alpha SMPs at the other end. I remember Cray J90s hanging around WAY past their competitive lifespans, because you could run the old codes from the 80's on them with no modifications. That's not gonna happen for JAXLB (Just Another x86 Linux Box).
"The F22 can take over many of the original roles of the B-2"
What? The F22 and B2 are ridiculously different aircraft with hugely different roles. The F22 is a short range air superiority fighter. The B2 is a long-range penetration/strategic bomber. They are about as diametricly different as two military jets can be. Even the proposed fb-22 bomber variant of the raptor has radiacally different capabilities compared to the B2. (half the range, 1/10th of the bombload)
"congress is only funding a handful of new aircraft"
Congress has only funded a handful (21) or the B2s. It has funded 130 of the F22s. The reason for the low funding of each is the same. It's not clear of how much use either are. Both planes were designed to wage war (either open, or proxy) with the soviet union. IF you look at the most useful planes in the Iraq and afgan wars, they are the B52, F16, and (are you ready for this one) the predator drone. We don't need more sophisticated air superiority jets, because we established air superiority in the first 10 hours of the conflict. We don't need new stealth penetration bombers because the bombers from the 50's are just as good, and can be based from simpler airfield, closer to the action. The air force brass seems to have gadget-lust that doesn't seem at all realated to the real threats and mission requirements. If you want to give the air force new planes, give them lower maintence F16s and B52s.
Furthermore, do you really think that the F22s and F35s will be cheaper to maintain than the existing planes? You're gonna pay those costs either way.
Lastly, the air force budget is higher now, as a share of GDP, than any time since the second world war. If they can't buy planes with they money they are already getting, they are seriously mismanaging their money.
Sandia and Oak Ridge are not coming up with an exaflops computer. They are contemplating how to write software, in a way that will effectively use exaflop computers when they become available. This little group has a budget of $4.7million, which is enough to pay a dozen high-level research scientists, and a half dozen software developers for a year. They're not going to reinvent high performance technical computing.
They're going to rework some fundamental math libraries to deal with the obvious trend in HPTC. They know that they are going to have to learn to deal with a million nodes, each with dozens or hundreds of CPU cores. The ratio of memory latency to processor speed is getting worse, not better. The ratio of interconnect bandwidth to node performance is getting worse, not better. Memory capacity per node is going up, but capacity per processor core is flat or downward. Disk performance per flop is flat or down. Checkpoint/restart of a million nodes in a non-starter. Flops are more plentiful, and massively cheaper, with each generation, but there are costs associated with that. There are a lot of paradigm changes in the way that these systems are managed, and the way that these codes are written, to deal with the limits imposed by these machines.
Sort of.
Ten years ago the largest systems had ~1000 processors, and jobs would usually run on 100-300 nodes. Now they have ~20,000 processors, and jobs tend to typically use 4000 nodes. Presumably an exaflop machine will have ~1,000,000 processor cores, and typical jobs will use 200,000 nodes.
I think this institute is being funded to deal with issues exactly like the problem you present. Checkpoint/restart was a decent solution for a YMP, but it has outlived its usefullness. I imagine there will someday be some sort of transactional checkpoint that allows nodes to save state periodically, and independantly. Algorithms will have to be rewritten to do it, but it's necessary. We can't get away from massive parallelism. There are serious limits to how fast you can make a processor, so the only way to make a faster machine is to make more.
The other possibility is to use redundancy and fault tollerance to deal with node failure, much in the way that commercial banking systems run. This, of course, quadruples the cost, which most HPTC shops are unlikely to deal with. It's a gross problem, and all the solutions are poor.
True. Sandia does a lot of nuclear systems simulation.
... the list goes on, but almost any US researcher can get an account on their systems, and purchase cpu time. The trouble is that neither of these labs has quite enough resources to dramatically change computer architecture directions. They can both afford to have 1 or 2 very high end machines at a time, which is enough for companies like IBM or Cray to make subtle changes in their product lineup, but not enough to completely redraw the map of the HPTC marketplace.
However, Oak Ridge is an unclassified facility doing mostly academic research on climate change, fusion energy, biological systems modeling, geological systems,
SGI probably got the technology for pennies on the dollar. When a company closes its doors, the investors and creditors are left holding the bag, and they're interested in getting out from under a little bit of that debt, and do it quick. If they don't unload the intellectual property quickly, it decays, looses mindshare in the marketplace, and falls out of date. This is doubly true in the world of linux, where you have to keep up with the kernel changes, and the changing distributions.
Similarly, SGI has changed a lot of their focus from their expensive cache-coherent single-system-image servers to clusters of small/cheap nodes. SGI has great compiler technology, data-management software, and systems integration knowledge. They may not, however, have great systems-management tech. You don't need that for single-system-image machines. Even the big columbia machine at nasa is only a cluster of 20 machines. You can do a lot of stuff by hand, or with creative shell scripts, when you're dealing with 20 machines. With 400, it's tougher. I'm sure this won't solve all their problems, but I bet it will help quite a bit.
They made money on their cash ballance, and by offering more shares, that's not really the same as an operating profit. Investors aren't going to keep dumping money into you, if you don't make a return on that money better than a t-bill. (that said, they sure do keep throwing good money after bad at sgi.)
2007 may have been better than 2006 for SGI, but I look at it as loosing money on every deal, just to drive up volume. It's too bad, as they have good technology in the altix and cxfs, but they just can't seem to produce them at a price that allows them to be profitable.
ACtually Blue Gene is not a big SMP. From the OS point of view, it's basically a cluster. So the article basically says that instead of using a cluster of 2U rackmount servers to host your internet app, you can use a cluster of Blue Gene nodes to host a large internet app. Trade one cluster for another. The Blue Gene alternative is attractive, in that each node uses very little power, and is very densely packaged. However, you do lose some flexibility. If, for some reason, your application required many hundreds of 2U servers to host it, you could replace it with a single rack of Blue Gene, and save some floor space and power. However, for most applications, which use a couple dozen web servers, it seems like overkill.
What makes you think noone brought this to their attention? I imagine a parent found out, and alerted the school.
publishing something on facebook is exactly that, publishing. You have no reasonable expectation of privacy; It's just like buying an ad in the newspaper, and printing a picture there.
It seems to me that the fun of table-top Role Playing Games is the storytelling. It's the plots, and the character development, and the mythical settings that make RPGs so exciting. Do we really need to further refine the game rules, or is this a simple cash grab for the publisher, when all the gamers out there update to the new rules?
Anyone willing to lend you the money also understands how inflation works.
The difference between utility costs and your mortgage/rent math, is that most of the costs for the utility are consumables, they really have no cost until someone is paid to dig them out of the ground. The costs of a home are all up-front whether they are yours, or a landlords'. You're not really comparing apples to apples.
There is a LOT of coal in North America. As more appalacian mountains are leveled, the political cost will rise, but I think it's a LONG time before we use up all the coal.
Nanosolar uses a thin-film substrate, if I'm not mistaken, which will likely break down, ironically from sun exposure. The thin-film products I'm familiar with, break down after a few years, so they must have done something clever to prevent that. I'd be surprised if they last 25 years, but don't really know.
You can't send excess electricity into the grid in very large amounts. Like I said, a few home hobbyist can get away with that, but you can't really store much electricity in the grid, you just reduce localized demand, and the transmission infrastructure can only tollerate a limited amount of this. If we are talking about hobbyist-scale offerings, it's meaningless to compare against the cost of coal, and we should really only compare against the residential rate charged by the local utility. If we're looking at hundred-megawatt scale deployments, then we can compare against coal.
Also, $1/W panels don't exist. Some startups are promising that they can do it, in the hopes of collecting enough venture capital to put together some production lines. I've heard a lot of promises from startups looking for capital, and few of them are completely true. There is also a lot of infrastructure necessary, beyond the cost of the panels, in a PV solar system. I'm sure that PV will continue to be deployed, and I welcome any reduction in the cost, but I don't think price-parity with fossil fuels is likely, near-term.
True: The top500 is mostly a contest of who can buy/power more processors. That doesn't mean there is no innovation going on, it simply doesn't matter for placement in the top 500. Most savy HPC customers know that linpack performance isn't all that important, and they do use other metrics to select their HPC solutions.
Infinaband is a much better interconnect than ethernet, and it's made it into a lot of the top500 systems. IBM's Blue-Gene and Cray's seastar networks are even better and they're represented too. Even within infinaband, we're seeing more DDR products, and 4x cards in compute nodes. Switches are becoming bigger, and the switch links are wider, and some are even going Quad-data-rate. Sun put together a very impressive fat-tree-in-a-box for the tacc system. The next generation Bluegene and cray networks are just around the corner, and NEC dramatically improved the IXS in the SX series. Interconnects have been changing quite a bit in the last couple years, and look like the trend will continue.
Memory is following the curve set by the server/desktop world, but processors have been showing some real innovation. Dual and quad core CPU's aren't the answer to every problem, but they offer a real improvement for some problems, with a low cost/power impact. Cray is working on the next generation of vector and multithreaded processors. NEC just put out a 100Gflop vector processor. Power6 looks like an amazingly fast superscalar cpu. Blue gene and sicortex use low-power processors in innovative ways. Cell, clearspead, and GPU coprocessors are beginning to be deployed in very limited ways; with the promise of a lot more to come.
I hate to be an optimist when cynicism is in vogue, but I see a lot of innovation in the last few years, and a lot on the horizon. How effective some of that innovation is, and how cost competitive, I do not know. It's pretty cool though.
CIGS, like all photovoltaic cells, can only provide power while the sun is shining.
I like to run my lights at night, not during the day.
molten sodium solar has the ability to provide 24-hour solar energy, which solar cells do not.
Your example of the 2400 baud modems for a linux cluster isn't completely accurate, as linpack does a little bit of communication, though the point is well taken. The top500 list only uses linpack to measure performance, and linpack represents a very easy problem to solve. Essentially, the top500 list is a list of which machines do a really good job of solving a trivially difficult problem. The hpcc benchmarks (http://icl.cs.utk.edu/hpcc/) are a lot more interesting; though, even these need to be read with some caution.
Ranking supercomputers is a really hard problem. Each application has different needs for communication latency, bandwidth, programming model, cache size, memory bandwidth, and computational throughput. Then you have to ask: how much optimization can I do to the benchmark? Am I going to be able to do the same amount of optimization for each of my applications? How easy is it to extract this performance? The guys writing the software for these things are usually professors or post-docs in the hard sciences, not in supercomputing.
You're forgetting two very important things. In your math you're forgetting to amortize your capital costs. Basically you're assuming that you can get a 0% loan. In reality, paying for solar up-front, instead of coal as you need it, you need to tripple the cost of the solar, because of the interest you will have to pay over the 25-year life of that "loan".
Secondly, solar provides great energy during the middle of the day. However, most residential electrical demand happens in the early evening, when people get home from work and turn everything on. Most industrial users of electricity need a constant supply, around the clock. Commercial users need electricity throughout the day, with a spike in the late afternoon as air conditioning demand increases. Solar-electricity provides for some, but not all of these needs. Storing solar energy in batteries, thermal storage systems, or mechanical storage systems doubles or tripples the cost again.
Thus, even with $1/W panels, general-purpose solar power is still 8-10X the cost of coal. I'm terribly doubtful that solar power will ever be economically competitive with coal, UNLESS you factor in the ecological costs. Unless we start taxing utilities for the carbon that they emit, we will not see solar become competitive, beyond little feel-good projects, and home-hobbyists.
Cell only provides that throughput using single precision (32bit) floating point. Its double precision performance is almost an order of magnitude slower. IBM is introducing a revised version of cell, that greatly improves double precission, but not to the same level as the single precision speeds.
Even if the computational rate qualifies, the usability is greatly hampered by the lack of memory.
There are several petaflop machines in their initial phases of roll-out right now, but peak performance isn't the only number worth paying attention to. The SX-9 is an amazing architecture, with orders of magnitude more bandwidth than the roadrunner system, both in interconnect, and in memory bandwidth. It's also a very expensive machine. The SX, however, has an advantage of being an update and refinement to a very established architecture. codes written for the SX-3 are going to perform well on the sx-9.
Roadrunner is a cool machine, but hard to program. You have most of your compute capability on the cell coprocessors, which are connected by a non-coherent infinaband pipe, to the host opteron processor. On the cell, you have a powerpc doing the program setup, and the 8 spu engines chunking through the data in parallel. If you can parallelize your program enough, you can get those working really quickly, but you have to do all the memory management in software, and control flow has to happen on the ppc. It's not impossible to get good performance from such a machine, but don't expect to just drop your existing software onto it and get decent performance. Blue gene is a less radical approach, and it took 3-4 years for a dozen codes to be rewritten to take advantage of it. Los Alamos runs a small number of applications, but needs a lot of performance. Thus they can spend the time to optimise their small list of apps for such a heirarchical design.
Also, you have your number off a little. The updated cell will provide 100Gflops of double precision performance, according to IBM. Still very fast. http://www.cs.utk.edu/~dongarra/cell2006/cell-slides/04-Ken-Koch.pdf
http://repositories.cdlib.org/cgi/viewcontent.cgi?article=4262&context=lbnl
infinaband is not bad for a single processor node. The trouble is that everyone wants to use a single port to power 16 cores.
Sadly, linpack does play a role in the computers that are purchased. Sometimes the guys making the decision are not the engineers and programmers, who then have to suffer with the consequences. Alas.
Well, the answer depends on your problem. These are sort of at the opposite end of the spectrum from distributed. There are a lot of solutions in between. In order from cheapest to most expensive per flop.
Distributed computing needs to do a lot of computation on very tiny bits of data. You can pack up the problem set and send it over the internet, then do an hour or two of work on a CPU, and send another internet-sized transfer back. It's very economical, only cares about raw cpu performance, and can't be used for very many tasks. [you can use any hardware for these]
Low-end Commodity clusters are build up of cheap servers connected with a cheap interconnect like ethernet. They can pass data between nodes at several tens of MB/second, and with latencies under a tenth of a second (realized). Again, most of the concern is the raw processor performance, though a little more coordination amongst processors is needed, and the amount of data being crunched can exceed a node's memory size, though it's best if it doesn't. [everybody and their mother makes these, HP and IBM make a lot of money on these]
High-end commodity clusters add a much higher performance interconnect like quadrics, myrinet, or infinaband. They also add software features like parallel filesystems, and virtualized system mangement. They also use higher-reliability nodes, and maybe more processors per node. [IBM, HP, SUN, SGI, fujitsu, Bull, and a lot of smaller shops sell these]
scalar-supercomputers are integrated machines using commodity processors, but with custom interconnects, packaging, operating systems, and software. They can often use more sophisticated memory sharing programming models, though are often still programmed with mpi. They pass even more data around the nodes, more often. They have parallel filesystems and have highly integrated system management tools. They tend to deploy a lot of redundancy features to insulate the user from node failures. [IBM, Cray, SGI]
vector-supercomputers use custom vector processors to amortize the cost of memory loads/stores across the computation, and do away with a lot of the branches that exist in scalar code. This allows VERY high performance on some codes (often many tens of times the performance of scalar processors), but poor performance on code that doesn't vectorize well. They are very expensive, but quite useful for a select set of usage schenarios. [NEC and Cray]
A rough estimate of the cost per peak-flop is that it approximately doubles for each of these, as you go up the list. It's important to realize, however, that peak-flops isn't the same as realized-flops.
The NEC processor is modern in its memory protection, so linux could easily be ported, however, there's a lot of time/money invested in super/ux so there's little incentive to do so. Even if linux were ported, it wouldn't be like the linux running on your desktop, it would be a stripped-down kernel, and some basic libraries.
I don't know what you're talking about with Xen and mosix. Neither seem at all applicable to the sort of software run on big-iron machines like this. NEC SX machines run code written for the SX, and highly tuned for the environment. They run openMP codes on a node, and MPI codes across nodes, or hybrid MPI/OpenMP nodes if you've got really good programmers. Mosix is for thread-migration around a cluster. It's more of a parallel database or web server sort of solution. The SX is a far too expensive machine to use for those sorts of tasks.