I'm absolutely possitive that sun did not implement a radix-3000 router of any sort, particularly infinaband. If you look at the earth simulator, a ridiculously high percent of the cost was to build a 640-way crossbar, and even that wasn't quite a full crossbar. I'm sure that the sun design is some sort of tapered fat-tree inside the box. It's possible that they overclocked the all-internal connections, as the traces are only a couple feet long, but there's still up to 8 hops from 1 port to another, assuming a rad-24 building block, 7 hops if you use sidelinks at the top level.
I'm not arguing that the sun solution is bad because it's commodity-based. That really keeps down the cost. $50million for a top-5 super is quite modest. It's just not as exotic, and thus interesting, as IBM's Blue Gene, Cray's XT4, or NEC's SX-8. (Though even BG and XT use commodity-derived processors, with custom packaging&interconnect) I'm a software guy, so the fact that Sun's system uses vanilla, off-the-shelf solaris/linux makes it somewhat less interesting than the more exotic designs.
A tricky question, but not all that interesting. A fast server processor is within a factor of 4 of the fastest supercomputer processor in the world. That does not mean that you can do equivalent work with the server processor. Among other things, processing performance (gigaflops) of a CPU, is no longer the interesting part of a supercomputer. (It never really was) memory bandwidth, interconnect bandwidth and latency, and I/O performance are the more interesting features of supers. 12 year old Cray processors still have five times the memory bandwidth of modern PC processors, and twenty times the I/O bandwidth.
You'll notice, that 98% of the supercomputers, sold in the last 10 years, all use server processors. (Blue Gene actually uses an embedded systems processor, but it's the same idea) However, in the late 80's putting 256 processors in a super was cutting edge. In the 90's, a few thousand. Soon you'll see a quarter million cores. So supers are actually getting faster at a higher rate than are desktops, at least by most measures.
It appears that Sun's design is less revolutionary. It's just a bunch of off-the-shelf blade servers strung together with infinaband. They use the same cabinets, powersupplies, etc as the regular blade server offerings for non-technical computing. It also runs as a regular linux OS, clustered, rather than a supercomputer specific OS, as the Blue Gene does. The big differentiator of the Sun system is the massive 3000 port infinaband switch. I'm sure it's not actually a 3000-port switch, but a bunch of small switches packed together, running over printed circuit boards, rather than cables.
Sun's design is affordable, and probably has a pretty decent max performance, and pretty reasonable power/memory per node. However, it's not as exotic as IBM's design. The IBM design has fantastic flops/watt and flops/square-foot performance. However, each node is really wimpy, which forces you to use a LOT of nodes for any problem, which inreases the necessary amount of communication. Some problems work really well, others, not so much.
IBM has limited blue gene to a small number of customers, all with fairly large systems. I suspect that's because it's very difficult to port an application to the system, and get good performance.
Don't quote wikipedia in an attempt to dispell misunderstandings about urban legends. Wikipedia is written by the same rumor-propogating folks that post in slashdot forums. Not always the most informed of folks.
I've certainly seen my fair share of very expensive SANs melt down, both as a buyer and as a vendor. I'm not convinced, however, that rolling your own is going to make that any better. It seems to me that the number one cause of storage-system failure is user-error. (EBCAK - Error Between Chair and Keyboard) This is true for the million dollar san, and it is true for the four thousand dollar beige box. Rolling your own just increases the number of places for you to screw it up, and increases your employer's dependance on you to keep it running. (Good for job security, not so good for long term data retention)
Absolutely, high-end SAN storage breaks. That's the reason that the tape industry just won't die. No matter what you're primary storage is, you need a backup and disaster recovery plan. Note: more RAID levels, or even mirrored servers are NOT a backup plan. "rm -rf" can wipe out both halves of a mirror.
Having been on the vendor side of this equation, I'm not so sure that the SAN story is so much bullflop. After you get hauled across the carpet and then kicked out of a customers' machine room once, you bust your ass to make sure things work right. I remember overnighting 96 drives to On-Track to get data off of failed drives, and then stiching raid-stripes together to get back customer data. I'm sure that one weekend cost more than all of the storage they had, ten times over. On the other hand, we fixed the bug, got the data back, the customer was happy, and kept buying our stuff.
Caveat Emptor, but also: you get what you pay for.
I'm sure the origional writer meant hundreds of megs per second, which is a reasonably good rate for 24 sata drives. Most 3/4U raid enclosures can get this level of performance, particularly for reads. I can get about 330MB/s out of a 14 drive Apple Xraid, and almost 400M/s out of a 24 drive engenio, but that's with a lot of careful tuning.
Hundreds of gigs per second is limited to the very largest GPFS or Lustre configurations. The fastest filesystem throughput I'm aware of, anywhere in the world, is about 100 gig/second at Sandia national labs. That requires dozens of high-end raid cabinets.
It could replace low end nas, but what the poster is describing, basically IS low end nas. An AX150i is a cheap box, crammed full of drives, running an iscsi target and a NFS/SMB server. It's more expensive than a beige box, but not by a lot. (after you account for the real cost of the drives and redundant gigE, etc) Somebody already had this idea, it was EMC (or netapp, comvault, etc), and they built it, marketed it, and are sellinig it to you with a 32% gross margin. I'll bet that 32% is probably worth it.
How much is your time worth? How much testing do you have to do before your manager is comfortable putting this thing in production, and how much time do you spend pushing security updates onto your new solaris box? Adminning a NAS box is not without some effort, but it's generally fairly little. What do you do when you want another one? What if you want a bigger one? What if you leave the company, and they guy who replaces you doesn't know much about a roll-your-own nas box?
This seems like a great solution for a dorm room, or maybe a college research lab.
And google can get away with it because they have VERY specialized needs, but on a very large scale. GoogleFS is not posix compliant. You can't run third party software apps on top of it, and expect them to behave well. It supports a very high level of read performance, with limited write performance, and depends on very highly ordered machine environments. It would be wonderful if we could all afford millions of dollars of custom engineering for our specific needs, but there's a reason most of us pay the big bucks to the storage companies of the world: it's often cheaper, in sum, than rolling your own.
I think it is foolish to believe that computer manufacturers are going to act in any way to prevent a monopoly. Businesses have a difficult enough time conducting their own operations in any way that looks beyond the next product cycle. Purchasing higher-cost or lower-performing parts in the short term, because it could prevent a future monopoly, is the sort of foresite businesses are not apt to do. This is herd mentality folks, short-term gain is the name of the game.
A lot of the time parallel builds are going to be more limited by your filesystem I/O than by processor speed. This obviously depends on what you're building, but it has been true for me in a lot of cases.
back in the mid 80's Apple made a couple stabs at making their own processor architecture and gave up on the idea.
Until recently, apple steadfastly supported the powerpc architecture that had no other proponent in the desktop/laptop/workstation market. They finally gave up on the idea.
Why would apple, a company whose fortune is progressively less tied to the computer hardware market, want to buy a processor company? Apple's hardware division has been doing okay in the last few years, but it's the professional applications software, consumer electronics, and entertainment cross-marketing deals that have made the stock price shine. Why invest billions into the part of the business that has the least traction?
I'd say it looks more like VLIW or EPIC. Instructions grouped into blocks with no looping or data dependence, running in parallel. It looks like a 16-wide Itanium, with all the same problems actually generating code that will run on it very well.
Well, it gets rid of the isa-visible register file. That doesn't mean there aren't sram cells in there holding onto data. Don't confuse architecture an implementation.
To answer your question - the last Submersion cooled cray was the mid-90's era T90, which submersed 32 processor boards and the memory, in a pool of flourinert. It did not, howerver, submerse the rest of the system, in particular the I/O, which would use standard pin connectors. One of the more exotic pieces of technology in the T90 was the robotic claw connectors that clamped down on the edges of compute boards at 400 contacts per inch. The unit costs of these connectors were very high, in part because they had to operate in the dialectric environment.
I will point out that after the T90, Cray moved away from immersion cooling, because it made the machine too difficult to service. The T3E used cold-plates, a somewhat more sophisticated version of the waterblocks you see today in some entusiast machines today. The X1, the current Cray vector system uses phase-change spray caps that actually spray dialectric onto the surface of the chip, which vaporizes the liquid. Even this has proved not cost-effective, even at the price-point of a cray. Cray's announced future products are all air-cooled. If immersion cooling isn't prudent on a cray, I can't possibly see how it's a good idea for a rack full of standard servers.
On the performance front: The T90 offered 60Gflops of performance, which is comparable to a modern 8-core xeon, though with 24GB/s of memory bandwidth per processor, which is STILL, twelve years later, considerably better than Core Duo Xeons, which offer just more than 5GB/s of bandwidth per core. The T90 supported at least 4 gigaring I/O channels at 1GB/s of bandwidth, each. Again, you still need to go to a pretty high-end commodity server to beat the I/O performance of the 12 year old cray. However, your point about per-watt performance is absolutely correct. The T90 consumed hundreds of thousands of watts and required 440volt 3-phase power.
They did compare system power, thus the title "refreshing". Correct, they did it wrong by not comparing identical systems. However, there is some merrit in this. I don't care if the power usage is from the processor, or from the northbridge needed to support said processor. Saying that a processor uses X amount of power makes for a good bullet point on marketing slides, but the actual user experience is with the whole platform, so I think it's appropriate to benchmark the power draw of the platform. Otherwise it's a purely accademic argument.
The only way in which the usage by the actual processor is interesting is when one is trying to estimate what a future product or related product will do. Since it's all speculation, though, it's not all that interesting of an exercise.
What gets to me is the way that most reviewers compare power usage by simply comparing the listed thermal envelopes. AMD lists the maximum power used, whereas intel lists the typical power used. Furthermore, for laptops and other machines where heat is your big concern, you do care a lot about the loaded maximum power used. However, for most desktops in which heat is not really an issue, you're more concerned about the cost of the electricity you burn. In that case it's almost more relevant to measure the idle power usage, since most desktops sit around doing nothing most of the time. Any good review should actually measure the system power between wall socket and PSU, otherwise it's not really infromative to the actual concerns of the user.
small parts of the market might be interested, but only the parts that are now served by GPUs integrated into chipsets. The advantage of discrete graphics chips, whether plugged into a cpu socket or into an expansion slot, is upgradability, and the chance to differentiate products. Putting everything on one die lowers total system costs, and circuitboard complexity, but is a hard sell in many segments of the PC market.
My question is what advantage will they get from plugging these coprocessors into CPU sockets, as opposed to PCIe risers? Does the coprocessor realy need to be cache coherent? If it is, how do you deal with interrupt handling? Does the GPU run independant threads that are peers to CPU threads?
given the current state of the space shuttle fleet, and the known safety issues with the design, NASA has no choice but to design a successor spacecraft. The only question is what sort of a spacecraft should they design. Should the shuttle successor be a little transit-craft only useful for flying to the iss, or do they do something bold that can go out of low earth orbit? Nasa, at the urging of the president, and many others, decided to build a bold craft, which consequently costs a lot of money, and takes focus off of other things.
Anytime nasa reprioritises money, something gets left behind. It's a careful balancing act of expense vs. return on that investment. There is still some science being done on iss, and will be more in the future. It's just not as much as origonally envisioned. How important is that? How do you prefer to weigh that against going to the moon and preparing to go to mars?
Ideally, we do both, but that means taking money from defense, with which this president isn't likely to go along.
There are 2 areas of latency for a cache, the first is the performance of the actual data cells, and the second is the speed of doing a lookup in the cache. The larger the cache, and the higher the degree of set associativity, the longer the lookup takes. Thus you're unlikely to see this eDRAM used for L1 caches, and probably not for L2 caches either, as more cache would slow them down, even if the cells are just as fast as SRAM. The sweet spot will probably be for L3 caches, that are already slow by cache standards, but a whole lot faster than system memory. Since L3 caches are large, the cost savings for switching to eDRAM would be largest there.
As for power concerns, DRAM is higher than SRAM, but a larger L3 cache may reduce the traffic through the memory controller, and out to the DIMMs, which will probably more than make up for any increase in power density in the cache.
They might not fork it for Novell's sake, but how about their own? How many gcc contributors are gplv3 zealots, and how many are compiler zealots? I bet more of the latter. I imagine the pragmatists winning out more often that not.
Once the fsf lays down the gauntlet, how many foss developers are going to do a doubletake, and get really nervous about getting tied up in a mess.
But the current versions of those tools are all licensed under GPLv2. If the FSF wants to play hardball, and releases future versions under GPLv3, Novell, or anyone else for that matter, can fork the GPLv2 version and continue developments from that base. The FSF would have to count on the community adopting the v3 versions, rather than the v2 versions. Since the number of FSF developers is small, relative to the number of other contributors, it's a fight the FSF may not want to start.
Why can't they. I've been on both sides of a FSF legal threat, and I can tell you their bark is worse than their bite. The fact of the matter is that the FSF does the "right" thing, and licenses all of their software under the GPL. Thus they give up a lot of their ability to do anything about it when someone uses that code in a way the FSF doesn't like. They want their cake and to eat it too. I don't see the FSF being able to do a lot to stop Novell.
Furthermore, from a market perspective, Novell doesn't care if a bunch of slashdot readers get upset. Slashdot readers don't pay for Linux support services. They're not losing any sales by pissing off the slashdot crowd. They want to get into the corporate server-room, and that DOES mean playing well with Windows. Note, I did not say playing well with Microsoft. The technology, however, needs to provide services to predominantly Windows clients running CIFS, and IE. For good or ill, that's the reality of Novell's market, and they may have signed a pact with the devil to get there.
Ah, but $100,000 over 25 years isn't $4,000 either. Since you're essentially taking out a loan on future energy use, you have to factor in the ~8% return that money would bring you if you had invested it. Lets say 3% inflation, so that's really more like $5500 per year. Of course the cost of fossil fuel energy will probably rise over this period too.
Slashdot Mirror
I'm absolutely possitive that sun did not implement a radix-3000 router of any sort, particularly infinaband. If you look at the earth simulator, a ridiculously high percent of the cost was to build a 640-way crossbar, and even that wasn't quite a full crossbar. I'm sure that the sun design is some sort of tapered fat-tree inside the box. It's possible that they overclocked the all-internal connections, as the traces are only a couple feet long, but there's still up to 8 hops from 1 port to another, assuming a rad-24 building block, 7 hops if you use sidelinks at the top level.
I'm not arguing that the sun solution is bad because it's commodity-based. That really keeps down the cost. $50million for a top-5 super is quite modest. It's just not as exotic, and thus interesting, as IBM's Blue Gene, Cray's XT4, or NEC's SX-8. (Though even BG and XT use commodity-derived processors, with custom packaging&interconnect) I'm a software guy, so the fact that Sun's system uses vanilla, off-the-shelf solaris/linux makes it somewhat less interesting than the more exotic designs.
A tricky question, but not all that interesting. A fast server processor is within a factor of 4 of the fastest supercomputer processor in the world. That does not mean that you can do equivalent work with the server processor. Among other things, processing performance (gigaflops) of a CPU, is no longer the interesting part of a supercomputer. (It never really was) memory bandwidth, interconnect bandwidth and latency, and I/O performance are the more interesting features of supers. 12 year old Cray processors still have five times the memory bandwidth of modern PC processors, and twenty times the I/O bandwidth.
You'll notice, that 98% of the supercomputers, sold in the last 10 years, all use server processors. (Blue Gene actually uses an embedded systems processor, but it's the same idea) However, in the late 80's putting 256 processors in a super was cutting edge. In the 90's, a few thousand. Soon you'll see a quarter million cores. So supers are actually getting faster at a higher rate than are desktops, at least by most measures.
It appears that Sun's design is less revolutionary. It's just a bunch of off-the-shelf blade servers strung together with infinaband. They use the same cabinets, powersupplies, etc as the regular blade server offerings for non-technical computing. It also runs as a regular linux OS, clustered, rather than a supercomputer specific OS, as the Blue Gene does. The big differentiator of the Sun system is the massive 3000 port infinaband switch. I'm sure it's not actually a 3000-port switch, but a bunch of small switches packed together, running over printed circuit boards, rather than cables.
Sun's design is affordable, and probably has a pretty decent max performance, and pretty reasonable power/memory per node. However, it's not as exotic as IBM's design. The IBM design has fantastic flops/watt and flops/square-foot performance. However, each node is really wimpy, which forces you to use a LOT of nodes for any problem, which inreases the necessary amount of communication. Some problems work really well, others, not so much.
IBM has limited blue gene to a small number of customers, all with fairly large systems. I suspect that's because it's very difficult to port an application to the system, and get good performance.
Don't quote wikipedia in an attempt to dispell misunderstandings about urban legends. Wikipedia is written by the same rumor-propogating folks that post in slashdot forums. Not always the most informed of folks.
I've certainly seen my fair share of very expensive SANs melt down, both as a buyer and as a vendor. I'm not convinced, however, that rolling your own is going to make that any better. It seems to me that the number one cause of storage-system failure is user-error. (EBCAK - Error Between Chair and Keyboard) This is true for the million dollar san, and it is true for the four thousand dollar beige box. Rolling your own just increases the number of places for you to screw it up, and increases your employer's dependance on you to keep it running. (Good for job security, not so good for long term data retention)
Absolutely, high-end SAN storage breaks. That's the reason that the tape industry just won't die. No matter what you're primary storage is, you need a backup and disaster recovery plan. Note: more RAID levels, or even mirrored servers are NOT a backup plan. "rm -rf" can wipe out both halves of a mirror.
Having been on the vendor side of this equation, I'm not so sure that the SAN story is so much bullflop. After you get hauled across the carpet and then kicked out of a customers' machine room once, you bust your ass to make sure things work right. I remember overnighting 96 drives to On-Track to get data off of failed drives, and then stiching raid-stripes together to get back customer data. I'm sure that one weekend cost more than all of the storage they had, ten times over. On the other hand, we fixed the bug, got the data back, the customer was happy, and kept buying our stuff.
Caveat Emptor, but also: you get what you pay for.
I'm sure the origional writer meant hundreds of megs per second, which is a reasonably good rate for 24 sata drives. Most 3/4U raid enclosures can get this level of performance, particularly for reads. I can get about 330MB/s out of a 14 drive Apple Xraid, and almost 400M/s out of a 24 drive engenio, but that's with a lot of careful tuning.
Hundreds of gigs per second is limited to the very largest GPFS or Lustre configurations. The fastest filesystem throughput I'm aware of, anywhere in the world, is about 100 gig/second at Sandia national labs. That requires dozens of high-end raid cabinets.
It could replace low end nas, but what the poster is describing, basically IS low end nas. An AX150i is a cheap box, crammed full of drives, running an iscsi target and a NFS/SMB server. It's more expensive than a beige box, but not by a lot. (after you account for the real cost of the drives and redundant gigE, etc) Somebody already had this idea, it was EMC (or netapp, comvault, etc), and they built it, marketed it, and are sellinig it to you with a 32% gross margin. I'll bet that 32% is probably worth it.
How much is your time worth? How much testing do you have to do before your manager is comfortable putting this thing in production, and how much time do you spend pushing security updates onto your new solaris box? Adminning a NAS box is not without some effort, but it's generally fairly little. What do you do when you want another one? What if you want a bigger one? What if you leave the company, and they guy who replaces you doesn't know much about a roll-your-own nas box?
This seems like a great solution for a dorm room, or maybe a college research lab.
And google can get away with it because they have VERY specialized needs, but on a very large scale. GoogleFS is not posix compliant. You can't run third party software apps on top of it, and expect them to behave well. It supports a very high level of read performance, with limited write performance, and depends on very highly ordered machine environments. It would be wonderful if we could all afford millions of dollars of custom engineering for our specific needs, but there's a reason most of us pay the big bucks to the storage companies of the world: it's often cheaper, in sum, than rolling your own.
I think it is foolish to believe that computer manufacturers are going to act in any way to prevent a monopoly. Businesses have a difficult enough time conducting their own operations in any way that looks beyond the next product cycle. Purchasing higher-cost or lower-performing parts in the short term, because it could prevent a future monopoly, is the sort of foresite businesses are not apt to do. This is herd mentality folks, short-term gain is the name of the game.
You want to back up those claims with some data or at least links?
A lot of the time parallel builds are going to be more limited by your filesystem I/O than by processor speed. This obviously depends on what you're building, but it has been true for me in a lot of cases.
back in the mid 80's Apple made a couple stabs at making their own processor architecture and gave up on the idea.
Until recently, apple steadfastly supported the powerpc architecture that had no other proponent in the desktop/laptop/workstation market. They finally gave up on the idea.
Why would apple, a company whose fortune is progressively less tied to the computer hardware market, want to buy a processor company? Apple's hardware division has been doing okay in the last few years, but it's the professional applications software, consumer electronics, and entertainment cross-marketing deals that have made the stock price shine. Why invest billions into the part of the business that has the least traction?
I'd say it looks more like VLIW or EPIC. Instructions grouped into blocks with no looping or data dependence, running in parallel. It looks like a 16-wide Itanium, with all the same problems actually generating code that will run on it very well.
Well, it gets rid of the isa-visible register file. That doesn't mean there aren't sram cells in there holding onto data. Don't confuse architecture an implementation.
To answer your question - the last Submersion cooled cray was the mid-90's era T90, which submersed 32 processor boards and the memory, in a pool of flourinert. It did not, howerver, submerse the rest of the system, in particular the I/O, which would use standard pin connectors. One of the more exotic pieces of technology in the T90 was the robotic claw connectors that clamped down on the edges of compute boards at 400 contacts per inch. The unit costs of these connectors were very high, in part because they had to operate in the dialectric environment.
I will point out that after the T90, Cray moved away from immersion cooling, because it made the machine too difficult to service. The T3E used cold-plates, a somewhat more sophisticated version of the waterblocks you see today in some entusiast machines today. The X1, the current Cray vector system uses phase-change spray caps that actually spray dialectric onto the surface of the chip, which vaporizes the liquid. Even this has proved not cost-effective, even at the price-point of a cray. Cray's announced future products are all air-cooled. If immersion cooling isn't prudent on a cray, I can't possibly see how it's a good idea for a rack full of standard servers.
On the performance front: The T90 offered 60Gflops of performance, which is comparable to a modern 8-core xeon, though with 24GB/s of memory bandwidth per processor, which is STILL, twelve years later, considerably better than Core Duo Xeons, which offer just more than 5GB/s of bandwidth per core. The T90 supported at least 4 gigaring I/O channels at 1GB/s of bandwidth, each. Again, you still need to go to a pretty high-end commodity server to beat the I/O performance of the 12 year old cray. However, your point about per-watt performance is absolutely correct. The T90 consumed hundreds of thousands of watts and required 440volt 3-phase power.
My cell phone got into the HoHos again, and now I can't fit that fat MF into my pants pocket.
They did compare system power, thus the title "refreshing".
Correct, they did it wrong by not comparing identical systems. However, there is some merrit in this. I don't care if the power usage is from the processor, or from the northbridge needed to support said processor. Saying that a processor uses X amount of power makes for a good bullet point on marketing slides, but the actual user experience is with the whole platform, so I think it's appropriate to benchmark the power draw of the platform. Otherwise it's a purely accademic argument.
The only way in which the usage by the actual processor is interesting is when one is trying to estimate what a future product or related product will do. Since it's all speculation, though, it's not all that interesting of an exercise.
What gets to me is the way that most reviewers compare power usage by simply comparing the listed thermal envelopes. AMD lists the maximum power used, whereas intel lists the typical power used. Furthermore, for laptops and other machines where heat is your big concern, you do care a lot about the loaded maximum power used. However, for most desktops in which heat is not really an issue, you're more concerned about the cost of the electricity you burn. In that case it's almost more relevant to measure the idle power usage, since most desktops sit around doing nothing most of the time. Any good review should actually measure the system power between wall socket and PSU, otherwise it's not really infromative to the actual concerns of the user.
small parts of the market might be interested, but only the parts that are now served by GPUs integrated into chipsets. The advantage of discrete graphics chips, whether plugged into a cpu socket or into an expansion slot, is upgradability, and the chance to differentiate products. Putting everything on one die lowers total system costs, and circuitboard complexity, but is a hard sell in many segments of the PC market.
My question is what advantage will they get from plugging these coprocessors into CPU sockets, as opposed to PCIe risers? Does the coprocessor realy need to be cache coherent? If it is, how do you deal with interrupt handling? Does the GPU run independant threads that are peers to CPU threads?
given the current state of the space shuttle fleet, and the known safety issues with the design, NASA has no choice but to design a successor spacecraft. The only question is what sort of a spacecraft should they design. Should the shuttle successor be a little transit-craft only useful for flying to the iss, or do they do something bold that can go out of low earth orbit? Nasa, at the urging of the president, and many others, decided to build a bold craft, which consequently costs a lot of money, and takes focus off of other things.
Anytime nasa reprioritises money, something gets left behind. It's a careful balancing act of expense vs. return on that investment. There is still some science being done on iss, and will be more in the future. It's just not as much as origonally envisioned. How important is that? How do you prefer to weigh that against going to the moon and preparing to go to mars?
Ideally, we do both, but that means taking money from defense, with which this president isn't likely to go along.
There are 2 areas of latency for a cache, the first is the performance of the actual data cells, and the second is the speed of doing a lookup in the cache. The larger the cache, and the higher the degree of set associativity, the longer the lookup takes. Thus you're unlikely to see this eDRAM used for L1 caches, and probably not for L2 caches either, as more cache would slow them down, even if the cells are just as fast as SRAM. The sweet spot will probably be for L3 caches, that are already slow by cache standards, but a whole lot faster than system memory. Since L3 caches are large, the cost savings for switching to eDRAM would be largest there.
As for power concerns, DRAM is higher than SRAM, but a larger L3 cache may reduce the traffic through the memory controller, and out to the DIMMs, which will probably more than make up for any increase in power density in the cache.
They might not fork it for Novell's sake, but how about their own? How many gcc contributors are gplv3 zealots, and how many are compiler zealots? I bet more of the latter. I imagine the pragmatists winning out more often that not.
Once the fsf lays down the gauntlet, how many foss developers are going to do a doubletake, and get really nervous about getting tied up in a mess.
But the current versions of those tools are all licensed under GPLv2. If the FSF wants to play hardball, and releases future versions under GPLv3, Novell, or anyone else for that matter, can fork the GPLv2 version and continue developments from that base. The FSF would have to count on the community adopting the v3 versions, rather than the v2 versions. Since the number of FSF developers is small, relative to the number of other contributors, it's a fight the FSF may not want to start.
Why can't they.
I've been on both sides of a FSF legal threat, and I can tell you their bark is worse than their bite. The fact of the matter is that the FSF does the "right" thing, and licenses all of their software under the GPL. Thus they give up a lot of their ability to do anything about it when someone uses that code in a way the FSF doesn't like. They want their cake and to eat it too. I don't see the FSF being able to do a lot to stop Novell.
Furthermore, from a market perspective, Novell doesn't care if a bunch of slashdot readers get upset. Slashdot readers don't pay for Linux support services. They're not losing any sales by pissing off the slashdot crowd. They want to get into the corporate server-room, and that DOES mean playing well with Windows. Note, I did not say playing well with Microsoft. The technology, however, needs to provide services to predominantly Windows clients running CIFS, and IE. For good or ill, that's the reality of Novell's market, and they may have signed a pact with the devil to get there.
Ah, but $100,000 over 25 years isn't $4,000 either. Since you're essentially taking out a loan on future energy use, you have to factor in the ~8% return that money would bring you if you had invested it. Lets say 3% inflation, so that's really more like $5500 per year. Of course the cost of fossil fuel energy will probably rise over this period too.