multiple independant instructions passed to the processor at once, yeah, that sounds a lot like itanium to me. Regardeless of the "data flow magic no-register jump-and-shout" it should still face the same problems itaniums see: finding enough parallelism in the code to put in a common block. Pushing the complexity out to the compiler is only going to benefit you at all if the hardware was doing a poor job of extracting parallelism, but taking a broader, more dynamic look will reveal parallelism. Good in some cases, but there's a lot of times where there just isn't that much parallelism. One is still backed up on the fact that memory is REALLY, REALLY slow compared to pushing numbers between registers./natch
Most of the cost of a cluster is in the software, not the hardware. Even running on linux, you need your middleware and application to be written to deal with a cluster environment. You probably even need some sort of cluster filesystem or at least san hardware. In short: for anything resembling even 3 9's of uptime, you can't begin to deploy for as little as $40,000. Linux and x86 reduces the cost of the servers by 40%, everything else stay pretty damn expensive.
As I said, the distinction of cluster is a soft and squishy one. One must distinguish between a "commodity cluster" and a cluster. The Sx-8 (or sx-6, or earth simulator) uses 8-cpu shared-memory bus nodes, and connects them with the IXS crossbar switch. Alternately, one can get these nodes connected with hippi for a lower cost. While they support distributed memory operations, NEC suggests using message-passing methods between nodes, as this often performs the best. I don't know if this recommendation is based on the state of their libraries and compilers, or if the hardware limits shared-mem performance. ---- because they are capable of direct memory addressing, I would call these systems a vector-mpp. However, the fact that you can walk between the nodes* lends support to the cluster nomenclature.
The Cray X1 is probably even less of a cluster, as you can't get a box with one node in it. However, again, it's a 4-way shared-bus SMP, with 32parallel interconnect ports. Again distributed memory is possible, and cray tends to encourage it, as it performs really well on these machines. The scalar processor on those machines is pretty slow, and everything is highly tuned to chugging through numbers, so you tend to get fairly high (10us) MPI latencies. The memory controllers are fast, and 32-way parallel, so writing memory, even remote memory, is really fast. From my point of view these are the least commodity-cluster style systems around. However, from the cray engineering lexicon, they actually are cluster like. The X1 is a derivative of the SV1 super-clusters. Compared to a T932, a X1 is a cluster. Thus the cray engineers, at least the old-school engineers, occasionally call it a cluster.
We're really in violent agreement here, though I will challenge the statement that clusters have orders of magnitude less memory/interconnect bandwidth. Many do. The predominant cluster out there is gigabit ethernet connecting 2-way SMPs of xeons or opterons. They're cheap, and often get the job done quite well. However, some clusters are quite competitive performers. They are not as cheap as a rack of dells, but they are quite impressive. In the last few months I've worked on a cluster of 8-way IBM power4+ boxes using their federation switch. Fast! That's a 4GByte/s link and 50GB/s of memory bandwidth. And that's a last generation IBM cluster. Similarly the cray xd1 is a cluster of dual-opterons, with 13GB/s memory bandwidth per node, and 16GB/s interconnect bandwidth. Fast and a lot cheaper than a vector system.
I also challenge the statement that clusters don't do "real" hpc. Why do all the national labs use big commodity-clusters? NCAR, boeing, NOAA, all the oil/gas customers? They don't solve every problem, but they solve quite a few, and quite inexpensively. I was recently at a oilpatch customer last week who deploys a new 64-cpu commodity-cluster EVERY WEEK. They have about 90 of them so far. For the really hard problems, you can't top a cray, but who wants to pay for one? I have, however, noticed a lot more big SMP boxes in the last year. The new IBM power5 bbb's (big-black-boxes) seem to be making a real come-back, and HP seems to finally have convinced people that Itanium is a reasonable replacement to pa-risc. That's just my observation though.
* random trivia time. One of the requirements doe had for the cray red-storm (not the xt3 product, but the big custom job), was that you can split it 100%/0%, or 66%/33% either way secure/non-secure. The requirement states that a soldier carrying an M4 rifle must be able to march between the halves of the machine to establish that they are completely physically disconnected. Now you go out and build an interconnect mesh that is both high-speed and can be easily and quickly disconnected.
Though mpp's are kind of like clusters, and the boundary between the two is vague, I think there's definately a distinction. In many MPPs, nodes share access to memory, just at a performance penalty. Often the scientific binary is written using a message-passing tool like MPI, but the OS is often run with direct memory access. Definately from a systems-administration point of view, an mpp is different from a cluster. In an MPP you don't have 4000 root hard drives and 4000 power supplies to replace when they break. An mpp may be like a (fast) cluster from the programmer's point of view, but they are a lot simpler to deploy and manage. (Blue Gene, xt3, altix)
I also contest some of the distinctions drawn about vector processor systems. The two vector systems currently on the market, the cray X1 and the NEC SX-8 are clusters. Each node just happens to be a vector-smp. The earth simulator is a 640 node cluster of 8-way SMP boxes, where each of the processors in the smp is a vector cpu. However, the predominant programming method even on these boxes is with explicite message passing like MPI. Co-array fortran and Unified Parallel C are faster, but slow to catch on.
If this company really did have a non-volatile 2TB memory chip, like hell they would dump all the engineering time into developing a LAPTOP based around it. Bullshit! They would package them up, 20 or so in a box with a couple power supplies, and start shopping them around to raid manufacturers. They'd put 10TB in a 3.5" package and sell it to systems integrators. They'd put seagate out of business, and then use the money to do cool things with processors or whatever.
No, you can tell from the hairbrained business-plan that this is cowflop. Noone is going to go straight into consumer electronics right out of the gate. You'd need to raise so much capital just to deal with customer support issues, sales, inventory, marketing, no way. If they had come up with a real product, they'd be oem-ing it out to the mainframe or supercomputer world as a first step.
So basically video games are not like the movie industry. Or the music industry. It's not great, but that's the way a market economy works.
You have your major production houses that put out a lot of expensively produced, glitzy crap. Every once in a while they stumble upon a great piece of tallent, and end up with a classic.
Surrounding these are a moderate number of small houses that put out inexpensive "art-house" games that lack the glitz, but might hold some special content of their own.
Where isn't this true? People always bitch about the nature of big organizations, but I haven't met a big program that isn't full of this sort of thing. Government or private sector, US or Europe, It doesn't matter. Yes small organizations are nimble, but have implicite limitations. Large organizations are inefficient, slow to change, but can do things that small ones can't. The fact that the shuttle actually works (mostly) is testament to that fact.
Re:Whatever happened to single-stage-to-orbit?
on
NASA's Shuttle Plans
·
· Score: 1
Depends on your objectives, budget, and window of opportunity. If the shuttle is supposed to be retired by 2010, then a new vehicle needs to be ready for prime-time by 2012, which means first flight in 2009. That's 4 years from now. Capsules are well understood, well studied, and very simple. The US has tons of experience with capsules from the mercury and apollo missions. From a balistics stand-point none of the new technology changes anything, except making the vehicle lighter.
As for getting the thing to orbit, they have solid rocket motors, they have worked well for the shuttle, why not use them. They have liquid-fuel upper stages, they use them atop delta rockets all the time. Well understood.
If you are going to have a seperate crew vehicle, I think I'd rather have it be tried-and-true, simple dependable technology. Put the experimental stuff in unmanned vehicles.
Except when you can't replace them. There is a government customer downloading data from satelites and doing some post-processing on the data. (I don't know what data, or what sort of processing they did, just that they needed it to be fast). They built a network of 6 cray T90's, and a bunch of solid-state-disk. Towards the end of the 5-year life-cycle of the machine they tried to replace it with something faster, but couldn't. Cray had stopped making vector machines, and the cray/IBM/SGI/etc distributed machines could not deal with the huge I/O load the system needed to handle. They had to limp along with the old cray's for 3 or 4 more years before anyone could produce a machine that could actually do the work. [Even in the mid 90's the cray had 24GB/s of memory bandwidth. Ten years later an itanium2 has 6.4GB/s of bandwidth. You see the problem.]
Maybe, but that assumes that they need a really large capability class computer for one task. I have no idea what the NSA uses their supercomputers for, nor do I have any idea how those programs behave. However, they may not need one big super, and might instead have dozens of machines in the 2-10 TF range. For a lot of complicated codes, there is a transition point around 100 processors, where adding more processors does very little to speed up the job. Certaintly not all codes, but some.
NSA did fund the development of the cray X1 and X1e. It's pretty safe to assume they have several pretty large X1s somewhere in maryland. A 512 node X1 weighs in at only 6TFlops, but has the memory bandwidth to actually sustain that, unlike some of the highly parallel machines like blue gene.
It's probably safe to say that they also have a lot of BIG IBM machines too.
you just said mdb = great. Now I know you're just making it up. Mdb is just about useless when the core file is generated on a system other than the one you're debugging with. (always the case if the binary crashes at a customer site, rather than the test-lab) We just went through a lot of effort to convert from using sun CC to compiling with gcc, not because gcc produces better code, but so we could get the right symbols for using gdb.
mdb is the biggest pain in the world; gdb isn't perfect, but it's a lot simpler than mdb.
You are absolutely incorrect. multi-threaded programming is the predominant programming model on servers. Some tasks, such as web serving, mail serving, and to some degree data-base machines scale almost linearly with the number of processors. All of the first tier, and some of the second tier server manufacturers have been selling 32+-way SMP boxes for years. They work pretty damn well.
Sun is not trying to create a chip to supplant pentiums in desktops. They are not going for the best Doom3 performance. They want to handle SQL transactions, and IMAP requests, and most likely are targetting this at JSP in a big way.
As a user of a slightly aged sun SMP box, I'd rather have those many slow CPUs and the accompanying I/O capability, than a pair of cores that can spin like crazy waiting for memory.
This has been going on for years. IBM gave up on bigger single CPUs about 1980, so did cray, cyber, and unisys. Everyone has been doing multiprocessors for decades now. The only new thing is that they are sticking lots of them on a single piece of silicon, instead of one per chip. (or multiple chips per cpu, as the case may be).
You know I've done a lot of reading on ZFS, and I can't say it's likely to make that much of a difference. It's a journalled, 64-bit (yes they claim 128, but that's junk, as the underlying scsi layer doesn't support it), scalable filesystem. It has a few bells and whistles with indexing and access controls, but nothing that isn't already in a lot of other products. Basically it's catching up with where most other 3rd generation filesystems have been for years. It's probably not a bad filesystem, but I don't think it's going to bring about any major storage revolution.
Solaris (with Veritas filesystem and volume manager) has always been a good platform for archival storage. It's a good, stable platform for a database, file-serving, and the I/O capability of the machines is quite good. Where they really need to add value is on the software side of things. It's not enough to have servers, disks, and tape drives. Anyone can do that, buy it from dell even. What else are they going to offer? What will it cost? How well does it work? I don't think it's a bad combination, but it's two ho-hum companies combining into a larger ho-hum.
Neither consumers nor enterprises buy intel or amd. They buy hp or ibm or dell or gateway. Sun has come out strong for AMD, HP put them on the list. The fact of the matter is that the performance differences are small enough that it doesn't really matter. People are still willing to pay big bucks for SPARC processors, and they are complete dogs compared to either intel or amd kit. It's the entire system, the level of support, the performance of peripherals and storage that matters to most buyers.
IBM has one product that uses opteron, dell hasn't started selling one yet. Before opteron can really take off, I think one of those guys needs to turn around on the issue. These guys aren't going to give up on intel chips because they've been unimpressive for the last couple of years. Intel would have to foul things up in a REALLY BIG way, or keep screwing up for five or six years before many enterprises would change direction.
As for dual cores, AMD was quite wise to release a server product before the consumer product. I already know that multiple CPUs work well for my server. I'm not really sure what I'd do with them on my desktop.
Hard drive heads are tiny air-foils. They depend on a certain barometric pressure to keep from crashing into the platter. I had a device that measured weather characteristics in the mountains of antarctica. We had to use magneto-optical drives, because the heads on a disk drive kept crashing. This was many years ago though. I'd think it has improved since then. Maybe not.
Sodium would be very good for cooling things down to 400-C, more than enough to melt the entire CPU.
They would have to use some exotic conditions to get a liquid metal at under 50-C. I can't imagine they would talk about gamers (i.e. consumer products, i.e. liability) if they were using Mercury.
Because this is really only useful for a few, very specific tasks. The cell works because all those cores churn over a very small set of data, and do a lot of math without needing to get a whole lot of stuff from main memory. That doesn't work for most tasks.
Server tasks, unlike multimedia tasks, are generally branch-limited or IO-limited. They require large amounts of data, and program code. You can't easily improve memory bandwidth or I/O bandwidth without adding more pins to the back of the chip. If you start doubling the number of pins, well, you start to ask why you bothered putting two cores on a chip.
2 cores, well because it's easy and the chip makers can't really come up with other good uses for the transistors. 4 cores - I'm sure it'll happen, trends don't die quickly. 8-cores, you're gonna need a lot more memory buses, I/O connections, clock pins, ground pins, etc. I'm sure they'll find clever ways to put 2000 pins on a chip, maybe 4000, but you scale this up too high, and the chips will be too fragile for users to install themselves. Sooner or later the benefits start diminishing, and the costs jump above the point where a more complex motherboards ends up being easier.
Because linux is free (in some part speech, but in this case mostly beer is relevant) it's been able to develop a huge following of users and supporters. Any time a group of any sort gets that large, you end up with a more perceptible concentration of idiots.
To quote Twain: "The pitifulest thing out is a mob." The democratic nature of OSS development gives strength (in terms of control) to anyone who wants it, but you have to work for it. Anyone can contribute to the linux kernel, but only a couple thousand do. It takes a lot of work, and it's not an easy way to earn respect.
Criticism, on the other hand, is easy. It doesn't take to much effort to tare someone down. Especially if you do it in an internet forum where you don't even need to look them in the eye.
The only silly thing about the article is that these groups are somehow surprised that the internet is mostly full of idiots, and that the people with enough time to flame research groups are teenagers. You'd think they'd have done their research... well, we won't get into that.
the real advantage of credit card signatures is an added criminal charge. In a lot of states using someone else's credit card to buy $1000 worth of stuff amounts to petty theft, and is only grand larceny if you steal a certain monetary value from a single party. Thus the prison terms are often very short. However, if you sign the line, it's fraud, which is usually a felony.
The real paradigm shift of commercially released risc processors wasn't a simplified instruction set (they may have once been simple, but that's definately no longer true). The real difference is a consistent addressing schema and a load/store architecture. EPIC, the instruction set architecture of the itanium, does this also.
In fact, if you read each instruction sequentially out of ia64 bundles, each could be an instruction on a hypothetical risc processor. This defeats some of the purpose of the ISA, but is technically valid. I have to agree with the previous poster who suggested that the itanium is risc-like. It is. It's a rather-wide risc processor whose pipe-line control logic is part of the compiler, rather than embeded in hardware. Everything else in the itanium could be added to a risc processor except for the back-wards compatibility thing. (rolling register window, predicated execution, speculative loads, etc)
Phase-change (spray-evaporative) cooling is the best available technology for removing heat from a very hot surface. They us it in the Cray X1 supercomputer by spray an electrically non-conducting flourocarbon onto the chip surface. The fluid evaporates and is sucked out by a high speed vacume. Flourinert is not really appropriate for home use, as it can turn into phosgene gas if heated too hot (a building fire or electrical short).
I think spraycool and cray announced a patent cross-licensing deal a couple years ago. I'm very impressed that they are selling into the blade-server space, as it indicates that they've really brought the price down. However I don't think they are likely to be quiet. There are no fans or heat sinks on the processors, but the fluid is in a closed-loop system. Thus the heat needs to go somewhere. Probably they have one large heat exchanger per rack, which feeds into the sprayers for a dozen or more blade servers. If they're selling into the server market, quiet isn't a selling point anyway.
Spray cooling is also used in some industrial processes, though often water is used, as electrical conduictivity isn't a real big issue. (power plants for example)
That's EXACTLY what blue gene is. It happens to use a derivative of IBM's embedded processor, rather than AMD's, but that's the design. Each node is pretty wimpy, but make up for that by using 65,000 of them.
It works pretty well for problems that can be cut up into 65,000 pieces. However, a lot of problems don't easily divide into that many tiles, or the work of parallelizing the problem exceedes the benefit at some point.
Slashdot Mirror
multiple independant instructions passed to the processor at once, yeah, that sounds a lot like itanium to me. Regardeless of the "data flow magic no-register jump-and-shout" it should still face the same problems itaniums see: finding enough parallelism in the code to put in a common block. Pushing the complexity out to the compiler is only going to benefit you at all if the hardware was doing a poor job of extracting parallelism, but taking a broader, more dynamic look will reveal parallelism. Good in some cases, but there's a lot of times where there just isn't that much parallelism. One is still backed up on the fact that memory is REALLY, REALLY slow compared to pushing numbers between registers. /natch
Most of the cost of a cluster is in the software, not the hardware. Even running on linux, you need your middleware and application to be written to deal with a cluster environment. You probably even need some sort of cluster filesystem or at least san hardware. In short: for anything resembling even 3 9's of uptime, you can't begin to deploy for as little as $40,000. Linux and x86 reduces the cost of the servers by 40%, everything else stay pretty damn expensive.
As I said, the distinction of cluster is a soft and squishy one. One must distinguish between a "commodity cluster" and a cluster. The Sx-8 (or sx-6, or earth simulator) uses 8-cpu shared-memory bus nodes, and connects them with the IXS crossbar switch. Alternately, one can get these nodes connected with hippi for a lower cost. While they support distributed memory operations, NEC suggests using message-passing methods between nodes, as this often performs the best. I don't know if this recommendation is based on the state of their libraries and compilers, or if the hardware limits shared-mem performance. ---- because they are capable of direct memory addressing, I would call these systems a vector-mpp. However, the fact that you can walk between the nodes* lends support to the cluster nomenclature.
The Cray X1 is probably even less of a cluster, as you can't get a box with one node in it. However, again, it's a 4-way shared-bus SMP, with 32parallel interconnect ports. Again distributed memory is possible, and cray tends to encourage it, as it performs really well on these machines. The scalar processor on those machines is pretty slow, and everything is highly tuned to chugging through numbers, so you tend to get fairly high (10us) MPI latencies. The memory controllers are fast, and 32-way parallel, so writing memory, even remote memory, is really fast. From my point of view these are the least commodity-cluster style systems around. However, from the cray engineering lexicon, they actually are cluster like. The X1 is a derivative of the SV1 super-clusters. Compared to a T932, a X1 is a cluster. Thus the cray engineers, at least the old-school engineers, occasionally call it a cluster.
We're really in violent agreement here, though I will challenge the statement that clusters have orders of magnitude less memory/interconnect bandwidth. Many do. The predominant cluster out there is gigabit ethernet connecting 2-way SMPs of xeons or opterons. They're cheap, and often get the job done quite well. However, some clusters are quite competitive performers. They are not as cheap as a rack of dells, but they are quite impressive. In the last few months I've worked on a cluster of 8-way IBM power4+ boxes using their federation switch. Fast! That's a 4GByte/s link and 50GB/s of memory bandwidth. And that's a last generation IBM cluster. Similarly the cray xd1 is a cluster of dual-opterons, with 13GB/s memory bandwidth per node, and 16GB/s interconnect bandwidth. Fast and a lot cheaper than a vector system.
I also challenge the statement that clusters don't do "real" hpc. Why do all the national labs use big commodity-clusters? NCAR, boeing, NOAA, all the oil/gas customers? They don't solve every problem, but they solve quite a few, and quite inexpensively. I was recently at a oilpatch customer last week who deploys a new 64-cpu commodity-cluster EVERY WEEK. They have about 90 of them so far. For the really hard problems, you can't top a cray, but who wants to pay for one? I have, however, noticed a lot more big SMP boxes in the last year. The new IBM power5 bbb's (big-black-boxes) seem to be making a real come-back, and HP seems to finally have convinced people that Itanium is a reasonable replacement to pa-risc. That's just my observation though.
* random trivia time. One of the requirements doe had for the cray red-storm (not the xt3 product, but the big custom job), was that you can split it 100%/0%, or 66%/33% either way secure/non-secure. The requirement states that a soldier carrying an M4 rifle must be able to march between the halves of the machine to establish that they are completely physically disconnected. Now you go out and build an interconnect mesh that is both high-speed and can be easily and quickly disconnected.
Though mpp's are kind of like clusters, and the boundary between the two is vague, I think there's definately a distinction. In many MPPs, nodes share access to memory, just at a performance penalty. Often the scientific binary is written using a message-passing tool like MPI, but the OS is often run with direct memory access. Definately from a systems-administration point of view, an mpp is different from a cluster. In an MPP you don't have 4000 root hard drives and 4000 power supplies to replace when they break. An mpp may be like a (fast) cluster from the programmer's point of view, but they are a lot simpler to deploy and manage. (Blue Gene, xt3, altix)
I also contest some of the distinctions drawn about vector processor systems. The two vector systems currently on the market, the cray X1 and the NEC SX-8 are clusters. Each node just happens to be a vector-smp. The earth simulator is a 640 node cluster of 8-way SMP boxes, where each of the processors in the smp is a vector cpu. However, the predominant programming method even on these boxes is with explicite message passing like MPI. Co-array fortran and Unified Parallel C are faster, but slow to catch on.
Good summary of the common case though.
If this company really did have a non-volatile 2TB memory chip, like hell they would dump all the engineering time into developing a LAPTOP based around it. Bullshit! They would package them up, 20 or so in a box with a couple power supplies, and start shopping them around to raid manufacturers. They'd put 10TB in a 3.5" package and sell it to systems integrators. They'd put seagate out of business, and then use the money to do cool things with processors or whatever.
No, you can tell from the hairbrained business-plan that this is cowflop. Noone is going to go straight into consumer electronics right out of the gate. You'd need to raise so much capital just to deal with customer support issues, sales, inventory, marketing, no way. If they had come up with a real product, they'd be oem-ing it out to the mainframe or supercomputer world as a first step.
So basically video games are not like the movie industry. Or the music industry. It's not great, but that's the way a market economy works.
You have your major production houses that put out a lot of expensively produced, glitzy crap. Every once in a while they stumble upon a great piece of tallent, and end up with a classic.
Surrounding these are a moderate number of small houses that put out inexpensive "art-house" games that lack the glitz, but might hold some special content of their own.
Where isn't this true? People always bitch about the nature of big organizations, but I haven't met a big program that isn't full of this sort of thing. Government or private sector, US or Europe, It doesn't matter. Yes small organizations are nimble, but have implicite limitations. Large organizations are inefficient, slow to change, but can do things that small ones can't. The fact that the shuttle actually works (mostly) is testament to that fact.
Depends on your objectives, budget, and window of opportunity. If the shuttle is supposed to be retired by 2010, then a new vehicle needs to be ready for prime-time by 2012, which means first flight in 2009. That's 4 years from now. Capsules are well understood, well studied, and very simple. The US has tons of experience with capsules from the mercury and apollo missions. From a balistics stand-point none of the new technology changes anything, except making the vehicle lighter.
As for getting the thing to orbit, they have solid rocket motors, they have worked well for the shuttle, why not use them. They have liquid-fuel upper stages, they use them atop delta rockets all the time. Well understood.
If you are going to have a seperate crew vehicle, I think I'd rather have it be tried-and-true, simple dependable technology. Put the experimental stuff in unmanned vehicles.
Except when you can't replace them.
There is a government customer downloading data from satelites and doing some post-processing on the data. (I don't know what data, or what sort of processing they did, just that they needed it to be fast). They built a network of 6 cray T90's, and a bunch of solid-state-disk. Towards the end of the 5-year life-cycle of the machine they tried to replace it with something faster, but couldn't. Cray had stopped making vector machines, and the cray/IBM/SGI/etc distributed machines could not deal with the huge I/O load the system needed to handle. They had to limp along with the old cray's for 3 or 4 more years before anyone could produce a machine that could actually do the work. [Even in the mid 90's the cray had 24GB/s of memory bandwidth. Ten years later an itanium2 has 6.4GB/s of bandwidth. You see the problem.]
Maybe, but that assumes that they need a really large capability class computer for one task. I have no idea what the NSA uses their supercomputers for, nor do I have any idea how those programs behave. However, they may not need one big super, and might instead have dozens of machines in the 2-10 TF range. For a lot of complicated codes, there is a transition point around 100 processors, where adding more processors does very little to speed up the job. Certaintly not all codes, but some.
NSA did fund the development of the cray X1 and X1e. It's pretty safe to assume they have several pretty large X1s somewhere in maryland. A 512 node X1 weighs in at only 6TFlops, but has the memory bandwidth to actually sustain that, unlike some of the highly parallel machines like blue gene.
It's probably safe to say that they also have a lot of BIG IBM machines too.
you just said mdb = great. Now I know you're just making it up. Mdb is just about useless when the core file is generated on a system other than the one you're debugging with. (always the case if the binary crashes at a customer site, rather than the test-lab) We just went through a lot of effort to convert from using sun CC to compiling with gcc, not because gcc produces better code, but so we could get the right symbols for using gdb.
mdb is the biggest pain in the world; gdb isn't perfect, but it's a lot simpler than mdb.
You are absolutely incorrect.
multi-threaded programming is the predominant programming model on servers. Some tasks, such as web serving, mail serving, and to some degree data-base machines scale almost linearly with the number of processors. All of the first tier, and some of the second tier server manufacturers have been selling 32+-way SMP boxes for years. They work pretty damn well.
Sun is not trying to create a chip to supplant pentiums in desktops. They are not going for the best Doom3 performance. They want to handle SQL transactions, and IMAP requests, and most likely are targetting this at JSP in a big way.
As a user of a slightly aged sun SMP box, I'd rather have those many slow CPUs and the accompanying I/O capability, than a pair of cores that can spin like crazy waiting for memory.
This has been going on for years. IBM gave up on bigger single CPUs about 1980, so did cray, cyber, and unisys. Everyone has been doing multiprocessors for decades now. The only new thing is that they are sticking lots of them on a single piece of silicon, instead of one per chip. (or multiple chips per cpu, as the case may be).
You know I've done a lot of reading on ZFS, and I can't say it's likely to make that much of a difference. It's a journalled, 64-bit (yes they claim 128, but that's junk, as the underlying scsi layer doesn't support it), scalable filesystem. It has a few bells and whistles with indexing and access controls, but nothing that isn't already in a lot of other products. Basically it's catching up with where most other 3rd generation filesystems have been for years. It's probably not a bad filesystem, but I don't think it's going to bring about any major storage revolution.
Solaris (with Veritas filesystem and volume manager) has always been a good platform for archival storage. It's a good, stable platform for a database, file-serving, and the I/O capability of the machines is quite good. Where they really need to add value is on the software side of things. It's not enough to have servers, disks, and tape drives. Anyone can do that, buy it from dell even. What else are they going to offer? What will it cost? How well does it work? I don't think it's a bad combination, but it's two ho-hum companies combining into a larger ho-hum.
you can't put donuts on the table in the break room and then complain when someone eats them.
Complaining about it shows a great lack of grace.
Neither consumers nor enterprises buy intel or amd. They buy hp or ibm or dell or gateway. Sun has come out strong for AMD, HP put them on the list. The fact of the matter is that the performance differences are small enough that it doesn't really matter. People are still willing to pay big bucks for SPARC processors, and they are complete dogs compared to either intel or amd kit. It's the entire system, the level of support, the performance of peripherals and storage that matters to most buyers.
IBM has one product that uses opteron, dell hasn't started selling one yet. Before opteron can really take off, I think one of those guys needs to turn around on the issue. These guys aren't going to give up on intel chips because they've been unimpressive for the last couple of years. Intel would have to foul things up in a REALLY BIG way, or keep screwing up for five or six years before many enterprises would change direction.
As for dual cores, AMD was quite wise to release a server product before the consumer product. I already know that multiple CPUs work well for my server. I'm not really sure what I'd do with them on my desktop.
Hard drive heads are tiny air-foils. They depend on a certain barometric pressure to keep from crashing into the platter. I had a device that measured weather characteristics in the mountains of antarctica. We had to use magneto-optical drives, because the heads on a disk drive kept crashing. This was many years ago though. I'd think it has improved since then. Maybe not.
Sodium would be very good for cooling things down to 400-C, more than enough to melt the entire CPU.
They would have to use some exotic conditions to get a liquid metal at under 50-C. I can't imagine they would talk about gamers (i.e. consumer products, i.e. liability) if they were using Mercury.
Because this is really only useful for a few, very specific tasks. The cell works because all those cores churn over a very small set of data, and do a lot of math without needing to get a whole lot of stuff from main memory. That doesn't work for most tasks.
Server tasks, unlike multimedia tasks, are generally branch-limited or IO-limited. They require large amounts of data, and program code. You can't easily improve memory bandwidth or I/O bandwidth without adding more pins to the back of the chip. If you start doubling the number of pins, well, you start to ask why you bothered putting two cores on a chip.
2 cores, well because it's easy and the chip makers can't really come up with other good uses for the transistors. 4 cores - I'm sure it'll happen, trends don't die quickly. 8-cores, you're gonna need a lot more memory buses, I/O connections, clock pins, ground pins, etc. I'm sure they'll find clever ways to put 2000 pins on a chip, maybe 4000, but you scale this up too high, and the chips will be too fragile for users to install themselves. Sooner or later the benefits start diminishing, and the costs jump above the point where a more complex motherboards ends up being easier.
imagine. I've had an rp2600 under my desk for a couple years now.
Yeah it's fast; that does not intrinsically make it exciting, or sexy.
Because linux is free (in some part speech, but in this case mostly beer is relevant) it's been able to develop a huge following of users and supporters. Any time a group of any sort gets that large, you end up with a more perceptible concentration of idiots.
To quote Twain: "The pitifulest thing out is a mob." The democratic nature of OSS development gives strength (in terms of control) to anyone who wants it, but you have to work for it. Anyone can contribute to the linux kernel, but only a couple thousand do. It takes a lot of work, and it's not an easy way to earn respect.
Criticism, on the other hand, is easy. It doesn't take to much effort to tare someone down. Especially if you do it in an internet forum where you don't even need to look them in the eye.
The only silly thing about the article is that these groups are somehow surprised that the internet is mostly full of idiots, and that the people with enough time to flame research groups are teenagers. You'd think they'd have done their research... well, we won't get into that.
the real advantage of credit card signatures is an added criminal charge. In a lot of states using someone else's credit card to buy $1000 worth of stuff amounts to petty theft, and is only grand larceny if you steal a certain monetary value from a single party. Thus the prison terms are often very short. However, if you sign the line, it's fraud, which is usually a felony.
That's not exactly true either.
The real paradigm shift of commercially released risc processors wasn't a simplified instruction set (they may have once been simple, but that's definately no longer true). The real difference is a consistent addressing schema and a load/store architecture. EPIC, the instruction set architecture of the itanium, does this also.
In fact, if you read each instruction sequentially out of ia64 bundles, each could be an instruction on a hypothetical risc processor. This defeats some of the purpose of the ISA, but is technically valid. I have to agree with the previous poster who suggested that the itanium is risc-like. It is. It's a rather-wide risc processor whose pipe-line control logic is part of the compiler, rather than embeded in hardware. Everything else in the itanium could be added to a risc processor except for the back-wards compatibility thing. (rolling register window, predicated execution, speculative loads, etc)
Phase-change (spray-evaporative) cooling is the best available technology for removing heat from a very hot surface. They us it in the Cray X1 supercomputer by spray an electrically non-conducting flourocarbon onto the chip surface. The fluid evaporates and is sucked out by a high speed vacume. Flourinert is not really appropriate for home use, as it can turn into phosgene gas if heated too hot (a building fire or electrical short).
I think spraycool and cray announced a patent cross-licensing deal a couple years ago. I'm very impressed that they are selling into the blade-server space, as it indicates that they've really brought the price down. However I don't think they are likely to be quiet. There are no fans or heat sinks on the processors, but the fluid is in a closed-loop system. Thus the heat needs to go somewhere. Probably they have one large heat exchanger per rack, which feeds into the sprayers for a dozen or more blade servers. If they're selling into the server market, quiet isn't a selling point anyway.
Spray cooling is also used in some industrial processes, though often water is used, as electrical conduictivity isn't a real big issue. (power plants for example)
That's EXACTLY what blue gene is. It happens to use a derivative of IBM's embedded processor, rather than AMD's, but that's the design. Each node is pretty wimpy, but make up for that by using 65,000 of them.
It works pretty well for problems that can be cut up into 65,000 pieces. However, a lot of problems don't easily divide into that many tiles, or the work of parallelizing the problem exceedes the benefit at some point.