and the Tech people said "Oh, we have validation routines in our applications, we don't need ECC memory"
Actually I think the tech people were well aware of the fact that their cluster was damn near useless without ECC, they knew that they had to run everything twice at the very least, and they *DEFINITELY* knew that their validation routines had ABSOLUTELY nothing to do with this correcting memory errors.
Unfortunately many posters on/. are not nearly as intelligent. I saw LOTS of people here yelling and screaming about how these validation routines meant that the system didn't need ECC (which was always total bullshit).
So, why was the first cluster put together? Well now that one should be obvious given the fact that we're still talking about the damn thing, despite the fact that it may still have never actually been used for real work. Don't get me wrong, I think the Xserve G5 systems make a great base for this sort of cluster, but the original setup with desktop G5 systems was a total joke.
I ran some numbers a little while ago. Given 100% efficient solar panels getting a full 12 hours worth of noon-day sun at the equator, 365 days of the year, you would have to cover the entire state of Texas to produce enough solar power to fill current US electrical needs.
For more practical, real-world figures, you're looking at pretty much covering the entire United States with solar panels in order to provide sufficient electricity. Ohh, and Europe is in even worse shape due to their larger population, higher lattitude, not to mention the fact that Britain only gets about 3 or 4 days of sunshine each year:>
Solar power is nice for limited uses and small-scale stuff, but it will never be more than a small portion of our total energy production.
Uhh.. the Opteron is a 64-bit processor, not a 32-bit one.
However you are correct, Intel's and AMD's latest 32-bit chips (ie the P4 and the AthlonXP) both have 36-bits worth of physical address lines. They can't properly deal with all that memory at once, using rather ugly kludges, but at least they can physically use it.
As mentioned above though, this system uses 64-bit processors so it's all rather moot. The Opteron has 40-bits worth of physical address lines and can properly address up to 48-bits worth of data (easily extendable up to 50+ bits for future versions if/when that becomes useful).
All Athlon64 and Opteron systems support ECC memory unless the motherboard manufacturer went to great lengths to disable such support. It is that this is the case with this particular system, I couldn't say for sure as IWill doesn't have the specs listed yet. However other IWill Opteron boards do support ECC.
One of the really nice features about pulling the memory controller onto the processor die is that now AMD controls this sort of thing and doesn't need to depend on the motherboard and chipset vendors nearly as much.
CPUs almost never cause problems on their own, but motherboards are a whole other issue. My money would be on the motherboard.
In particularly, your problems sound similar to what a lot of people have reported with trying to get Linux installed on a Serial ATA hard drive. The SATA drivers are, as a general rule, terrible at the moment. The only SATA driver that seems to be at all mature is the one for Intel's ICH chips, every other SATA chipset seems to causes a lot of issues that you've mentioned. I understand that the situation is slowly imporving, but lack of support from the chipset vendors has made this a rather long processs.
As for why only 8 more, the AMD people did their homework. 8 more would give more bang for buck compared to 24 more.
It was more to do with keeping the instruction set basically the same. 8 extra registers was the most that AMD could squeeze into the existing x86 framework without dramatically changing things.
In terms of the transistors, extra registers are dirt-cheap, a one or two million more doesn't make much of a difference on chips that is already over 100 million transistors. Hell, most x86 processors have over a hundred registers in silicon, but only 8 or 16 of the actually accessible to software, the rest are just for register renaming. So really it wasn't a question of cost from the hardware point of view. It was all about ease of porting code.
While the VIA and Transmeta both make some very comperable performing chips (both in terms of raw performance and power consumption), you really couldn't "merge" the technlogy.
The two companies have taken a dramatically different approach to things. VIA went for a VERY simple x86 core, not entirely unlike the original Pentium but with a few tweaks to the memory subsystem and bus, among other things. Transmeta, on the other hand, went for the most obscure possible way to make an x86 chip. They designed an entirely new VLIW architecture with a translation layer thrown overtop of it.
The end result is the same, but the path to get there is totally different. One could probably make a valid enough argument for which of these is better, though I would tend to side with VIA on this one due to the fact that their managing the same performance when built on the same manufacturing process but with a die size less than half the size of what Transmeta has. What's more, VIA is actually making money on their processor business while Transmeta is DEEP in the red. I think things are only going to get worse for them as well now that AMD and Intel are both starting to offer processors with bthe same power consumption, better performance and low cost (the ULV Celeron chips from Intel and the GeodeNX line from AMD).
The Opteron basically smacks the Transmeta cluster silly when it comes to performance. Best case scneario for that 12-CPU Transmeta workstation is that it might match the performance a 2P x 2 cores/processor setup, but the Transmeta cluster would be about 3 times as expensive.
Of course, in many workloads a single Opteron 140 (the cheapest/slowest Opteron out there) will easily out-gun that 12P Transmeta cluster. Even in cases that are multithreaded one or two Opterons running at a decent speed will beat out the Transmeta cluster.
The real advantage of the Transmeta workstation (beyond the fact that it's available today and dual-core Opterons are not) is that the power consumption would be somewhat lower. Compared to what is available today this is a fairly large advantage, though those dual-core Opterons should be able to get very similar performance/watt when they are released.
As the other poster mentioned, this is part of the Tandem Non-Stop line. Servers designed for extremely high reliability.
This is a sort of odd-ball situation that came about due to all the buying and merging that went on. Tandem was originally an independant company (or maybe split off from another company?) that was bought out by Digital many years back. Digital planned to switch the servers over to Alpha processors, but never go the chance before they were bought out by Compaq. Compaq didn't do much of anything with Tandem and then they merged with HP.
Through this all the Tandem line just stuck with their old MIPS chips as the Alpha design never really got off the ground. Now the plan is to switch it over to Itanium, and I understand that this has progressed fairly well along, though it's likely to be an extremely slow process. Due to the sort of market that they're dealing with here, HP will probably be offering MIPS based Tandem servers for at least another 5 years.
There are somewhere in the order of 1.4M Xeon units shipped in the same time-frame that AMD shipped 60,000 Opteron servers. Strong growth rate from previous servers, but still less than 5% of the market.
They claim sustained performance of 1.56Gflops per processor. I don't know if this is all that accurate, it seems a bit high considering the Crusoe could only manage something like 350MFlops at 1.0GHz. However the Efficeon did add SSE2 support which might have dramatically improved performance for this sort of workload, so I'll take their number as accurate for comparison sake.
A 3.0GHz P4 can manage somewhere around 4.0Gflops sustained. So basically the 12-processor version of this system should give you slightly better performance for Linpack workloads than a top-end 4-processor Intel Xeon setup (or a 2 x 2P cluster), but with lower power consumption (they claim 220W for the 12P setup vs. about 400W for a similar 4P Xeon setup). Of course, that does assume decent scaling for each system
You would actually do much better for this sort of workload with an Apple Xserve, which can manage about 6.0 Gflops per 2.0GHz processor. Here you could get roughly the same performance with 3 Xserver cluster nodes as with 2 of these 12-processor cluster boards. Power consumption of the XServers would be higher, though not by a huge amount.
Of course, Linpack performance is not the end-all, be-all measure of processing power and other workloads could differ greatly. Unfortunately Transmeta is *HUGELY* secretive of just how their processors perform in the real world (likely because what little I have seen has shown very weak performance), so we don't have much else to go on. Suffice it to say though that simply have 96 processors in a single box is definitely NOT a sure-fire way to get increadible performance.
With a 32-bit OS and 32-bit applications you can only access a maximum of 2 or 3GB of data at a time (possibly even less due to memory fragmentation). This may or may not affect what you do.
If you do indeed have files as big as DVDs, it would certainly help with editing those files. You CAN break those up into chunks, only having 2GB or less in memory at any given time, and for the most part this works ok, however it does tend to be a bit of a kludge at the best of times, and sometimes it just flat out doesn't work.
As you correctly guess, servers are the first situation where this really makes sense. If you've got a database that is more than 2GB in size, you REALLY want a 64-bit system, otherwise you'll tend to take a big performance hit. Many high-end workstations require 64-bit systems as well to process all the data.
So, where is the benefit for the end-user? Well that depends on the user. First off, having more than 2GB of physcial memory on a 32-bit processor requires some really ugly hacks to make things work. They do work, but it is a really dumb idea. It was a annoying and crappy when we were forced to do it back in the 16-bit days, and it hasn't gotten any better. Secondly people are using bigger and bigger data files on their home PC, editing larger pictures and videos, playing games with more graphics and sound, some even run into issues with types of databases (I know my Usenet newsreader sometimes craps out when I'm downloading too much pr0n because of database limits). Basically you might not need it, but someone else might. The best part about it though is that 64-bits is "free".
Basically you've got a 64-bit CPU that is no more expensive than competiting 32-bit chips and Microsoft has said that 64-bit WinXP Pro will sell for the same price as 32-bit WinXP Pro, so really the question is not so much "Why" do we need 64-bit, but "why not?"
For those of you who didn't bother to RTFA, the P4 Extreme Edition is *NOT* being discontinued, just the 3.2GHz model.
Beyond that though, AMD doesn't really have a problem. They have done a decent job to position the Athlon64 FX chip they are currently selling as simply being the top-of-the-line Athlon64 chip at any given time. The Athlon64 FX-53 is a little bit faster than the current top-end Athlon64 3900+ and sells for only a fairly small ($100-$150) more.
For Intel it is similar except that they have a much larger price gap. Their top-end regular P4 processor (that is actually being sold) is the 3.4GHz model, while the P4EE 3.4GHz is their model up from that. It is a faster chip and therefore can carry a somewhat larger price premium, but Intel is charging a MUCH larger price premium.
As for the 3.2GHz P4EE, it obviously made no sense now that the 3.4GHz P4EE is here, hence the reason why it's being discontinued. Just as AMD only carries one model of Athlon64 FX at any given time, Intel will likely only carry one speed grade of the P4EE at any given time.
"The 3.2GHz P4EE sells for over $900 and the 3.4GHz P4EE sells for only a few dollars more. Anyone dumb enough to waste their money on such an expensive chip might as well spend the extra few dollars for the fastest and get the bragging rights".
As the original poster correctly stated it is NOT the entire line that is being discontinued, only the 3.2GHz P4EE.
FWIW AMD does the exact same thing with their Athlon64 FX line, they have already discontinued their FX-51 model and the FX-53 model will be discontinued in a couple of months when the FX-55 shows up.
Go out there and talk to enough people and you'll find dozens of people with horror stories about drives failing left, right and center for EVERY hard drive company out there. Doesn't matter one lick of it's Maxtor, Seagate or WD, they ALL fail, and they all fail with a MUCH higher frequency than damn near any other component in a modern computer system (the possible exception to this rule would be fans, which also fail quite regularly).
Use whatever the heck companies drives you feel like, but honestly there is ZERO difference in reliability from any of the big three drive companies (Maxtor, Seagate and WD).
Re:You mean criminals aren't abiding by the law?
on
CAN-SPAM Is A Bust
·
· Score: 1
Yeah, because all those spammers sending out Nigerian 419 scams, phishing scams, credit card fraud and similar such stuff are all such law-abiding citizens. People sending out boatloads of porn while making no attempt to filter it from children's inboxes are totally legit. People advertising for unlicensed pharmacies and illegal gambling sites are within the bounds of the law... right... Ohh, and they're doing all this by hacking computers and distributing viruses so that they can send their spam through compromised systems.
Face it, spammers are a bunch of criminals! Always have been! This new law didn't change that fact, it just added one VERY minor additional offense to an mile-long list of laws that your average spammer breaks on a daily basis.
If the law enforcement agencies don't have the resources to stop spammers from breaking major laws like fraud and computer hacking, obviously they aren't going to have the resources to stop someone from breaking this little CAN-SPAM act!
Uhh, you do realize that you are totally talking out of your ass, right?
These SGI systems have TERMENDOUS memory bandwidth. The whole design is basically centered around memory bandwidth. The whole idea of going for this single-image shared memory space type of system is that it offers much more memory bandwidth.
A Beowulf cluster, on the other hand, has *terrible* internode bandwidth for memory, limited entirely by your network architecture which is usually orders of magnitude slower than native system bandwidth. For many problems this isn't a big bottleneck and the huge cost savings you get from COTS parts can often more than make up for it (ie who cares if it only scales half as well when you get 4 times as many processors), but that certainly is not always the case. Sometimes Beowulf-style clusters just do NOT scale at all, no matter how many chips you throw at the problem.
I think that one of the most interesting things to come out of this article is that running 32-bit applications on a 64-bit OS is generally NOT slower than the 64-bit counterparts, or at least not by any significant amount.
This is significant because most applications out there are still 32-bit ones, so if you can upgrade to a 64-bit OS for one or two important 64-bit applications you don't need to worry about upgrading all your legacy 32-bit apps.
This is in stark contrast to Intel's IA-64 (Itanium) solution in which you take a BIG performance hit when running 32-bit code on a 64-bit OS vs. sticking with x86 hardware. This might seem like an obvious conclusion given that the AMD64 hardware fully supports 32-bit x86 code while IA-64 requires emulation to run 32-bit x86 code, however that point is likely to be lost on a lot of people who control the purse strings.
Just as a FWIW, AMD64 supports 48-bit (or is it 52-bit?) virtual memory space, but only 40-bit physical memory space. From the operating system perspective the virtual memory space is all that counts. Changing physical address space is pretty easy in that it's completely hidden from the software side of things.
As for your bit of code, I'm pretty certain that would seg fault on any operating system, regardless of bitness.
1. It places a load on the sending of legitimate e-mail. Not a big deal for people such as myself who's out-going e-mail is usually in the single-digits for the day (and often week), but what about for big ISPs or news services? The big ISPs and mail services (ie those that are needed to make such a system work) would require WAY more computing power to send out legit messages. Similarly you would need to calculate the solution in order to verify that the sender is actually doing the calculations and not just spitting a set of random numbers back at you, so the big mail servers get hit on both ends. When you're sending and receiving hundreds of millions of messages a day (billions in the case of AOL and MSN/Hotmail), that translates to a LOT of computer time and a LOT of added expenses.
2. I can pretty much assure you that whatever someone comes up with as an equation to solve some spammer will find a way around actually spending the pre-message computing time of solving it.
3. Spammers don't send e-mail using conventional mail servers anyway. A VERY significant portion of spam is delivered through broadband connected PCs that have been 0wned by some virus or worm. The quantity of vulnerble systems is pretty much infinite and there's nothing that's going to change this in the near future. In fact, I suspect that it's going to get MUCH worse before it will get any better.
I do tend to agree that simply making spam illegal is not going to do anything, the trick is in enforcement. Most of what spammers are doing has been illegal for AGES. Using viruses and worms to infect computers has been a crime in most countries for many years now. Same goes for illegal credit card scams, bank fraud and all the other trash that spammers are "selling". Hell, even the pr0n spam is almost always illegal as it often gets sent to children's inboxes. New laws are not what is needed, enforcement of existing laws is the trick.
Still, end the end, as long as there are millions upon millions of complete *MORONS* out there willing to spend their hard-earned cash to buy pills to "enhance their manhood", spam will exist in one form or another.
The flaw to these economics is that probably only about 50,000 people or maybe 100,000 tops will actually make use of this program. The flaw will very rarely affect most users, and as a general rule, most people don't read/. (or similar news sites) and probably don't care much about this unless it actually causes problems for them.
What's more, even if it does cause problems, most people will probably just end up blaming Microsoft anyway.
Just as a little FWIW, if you download the NIC drivers for WinXP, as opposed to the ones listed as being "For all operating systems", they are only 10MB. Still too big for a floppy, but at least it's a small improvement.
As to why the system restore disks do not double as a driver disk, that one is completely beyond me. The drivers ARE all on the disk and you actually can access them, but doing so is definitely NOT easy, especially if you don't already know the SoftPaq number you need (you can't just look for Network drivers or anything sensible like that, gotta look for SP25763 or some such nonsense).
FWIW if you're interested in how a very simple cores compares to today's copmlex P4 and Athlon64 chips, look for some comparisons with the VIA C3 chips. The C3 is essentially what you describe, a core very similar to the old Pentium but updated to the latest and greatest manufacturing process, a new bus (the old Pentium bus with it's off-chip cache just stank for scaling) and a few other tweaks and enhancements.
The size, cost and power consumption are excellent for this chip, but it's performance is rather low. However you can pack about 4 of these chips in the same die space as a single P4 or Athlon64 and you can get about 8 of these chips for the power budget of AMD and Intel's latest and greatest. For highly multithreaded applications this could be a better solution.
The problem is that many applications are not highly multithreaded. It's always a trade-off between good multi-threaded performance and good single-threaded performance. For the time being going beyond 2 cores probably doesn't make much sense for desktop and workstation users, there just aren't enough apps that can effectively make use of more than 2 threads to make up for the loss in single threaded performance. For servers, that's another story. What you're describing is pretty much the exact strategy that Sun is taking with their "Niagara" chip design, 8 simple SPARC cores on a single chip. Low single threaded performance but should do VERY well for highly multithreaded applications that are common in the server world. For it's intended use the performance/die size and performance/watt of power should be excellent for that chip.
Slashdot Mirror
and the Tech people said "Oh, we have validation routines in our applications, we don't need ECC memory"
Actually I think the tech people were well aware of the fact that their cluster was damn near useless without ECC, they knew that they had to run everything twice at the very least, and they *DEFINITELY* knew that their validation routines had ABSOLUTELY nothing to do with this correcting memory errors.
Unfortunately many posters on /. are not nearly as intelligent. I saw LOTS of people here yelling and screaming about how these validation routines meant that the system didn't need ECC (which was always total bullshit).
So, why was the first cluster put together? Well now that one should be obvious given the fact that we're still talking about the damn thing, despite the fact that it may still have never actually been used for real work. Don't get me wrong, I think the Xserve G5 systems make a great base for this sort of cluster, but the original setup with desktop G5 systems was a total joke.
I ran some numbers a little while ago. Given 100% efficient solar panels getting a full 12 hours worth of noon-day sun at the equator, 365 days of the year, you would have to cover the entire state of Texas to produce enough solar power to fill current US electrical needs.
:>
For more practical, real-world figures, you're looking at pretty much covering the entire United States with solar panels in order to provide sufficient electricity. Ohh, and Europe is in even worse shape due to their larger population, higher lattitude, not to mention the fact that Britain only gets about 3 or 4 days of sunshine each year
Solar power is nice for limited uses and small-scale stuff, but it will never be more than a small portion of our total energy production.
Uhh.. the Opteron is a 64-bit processor, not a 32-bit one.
However you are correct, Intel's and AMD's latest 32-bit chips (ie the P4 and the AthlonXP) both have 36-bits worth of physical address lines. They can't properly deal with all that memory at once, using rather ugly kludges, but at least they can physically use it.
As mentioned above though, this system uses 64-bit processors so it's all rather moot. The Opteron has 40-bits worth of physical address lines and can properly address up to 48-bits worth of data (easily extendable up to 50+ bits for future versions if/when that becomes useful).
All Athlon64 and Opteron systems support ECC memory unless the motherboard manufacturer went to great lengths to disable such support. It is that this is the case with this particular system, I couldn't say for sure as IWill doesn't have the specs listed yet. However other IWill Opteron boards do support ECC.
One of the really nice features about pulling the memory controller onto the processor die is that now AMD controls this sort of thing and doesn't need to depend on the motherboard and chipset vendors nearly as much.
CPUs almost never cause problems on their own, but motherboards are a whole other issue. My money would be on the motherboard.
In particularly, your problems sound similar to what a lot of people have reported with trying to get Linux installed on a Serial ATA hard drive. The SATA drivers are, as a general rule, terrible at the moment. The only SATA driver that seems to be at all mature is the one for Intel's ICH chips, every other SATA chipset seems to causes a lot of issues that you've mentioned. I understand that the situation is slowly imporving, but lack of support from the chipset vendors has made this a rather long processs.
As for why only 8 more, the AMD people did their homework. 8 more would give more bang for buck compared to 24 more.
It was more to do with keeping the instruction set basically the same. 8 extra registers was the most that AMD could squeeze into the existing x86 framework without dramatically changing things.
In terms of the transistors, extra registers are dirt-cheap, a one or two million more doesn't make much of a difference on chips that is already over 100 million transistors. Hell, most x86 processors have over a hundred registers in silicon, but only 8 or 16 of the actually accessible to software, the rest are just for register renaming. So really it wasn't a question of cost from the hardware point of view. It was all about ease of porting code.
While the VIA and Transmeta both make some very comperable performing chips (both in terms of raw performance and power consumption), you really couldn't "merge" the technlogy.
The two companies have taken a dramatically different approach to things. VIA went for a VERY simple x86 core, not entirely unlike the original Pentium but with a few tweaks to the memory subsystem and bus, among other things. Transmeta, on the other hand, went for the most obscure possible way to make an x86 chip. They designed an entirely new VLIW architecture with a translation layer thrown overtop of it.
The end result is the same, but the path to get there is totally different. One could probably make a valid enough argument for which of these is better, though I would tend to side with VIA on this one due to the fact that their managing the same performance when built on the same manufacturing process but with a die size less than half the size of what Transmeta has. What's more, VIA is actually making money on their processor business while Transmeta is DEEP in the red. I think things are only going to get worse for them as well now that AMD and Intel are both starting to offer processors with bthe same power consumption, better performance and low cost (the ULV Celeron chips from Intel and the GeodeNX line from AMD).
The Opteron basically smacks the Transmeta cluster silly when it comes to performance. Best case scneario for that 12-CPU Transmeta workstation is that it might match the performance a 2P x 2 cores/processor setup, but the Transmeta cluster would be about 3 times as expensive.
Of course, in many workloads a single Opteron 140 (the cheapest/slowest Opteron out there) will easily out-gun that 12P Transmeta cluster. Even in cases that are multithreaded one or two Opterons running at a decent speed will beat out the Transmeta cluster.
The real advantage of the Transmeta workstation (beyond the fact that it's available today and dual-core Opterons are not) is that the power consumption would be somewhat lower. Compared to what is available today this is a fairly large advantage, though those dual-core Opterons should be able to get very similar performance/watt when they are released.
As the other poster mentioned, this is part of the Tandem Non-Stop line. Servers designed for extremely high reliability.
This is a sort of odd-ball situation that came about due to all the buying and merging that went on. Tandem was originally an independant company (or maybe split off from another company?) that was bought out by Digital many years back. Digital planned to switch the servers over to Alpha processors, but never go the chance before they were bought out by Compaq. Compaq didn't do much of anything with Tandem and then they merged with HP.
Through this all the Tandem line just stuck with their old MIPS chips as the Alpha design never really got off the ground. Now the plan is to switch it over to Itanium, and I understand that this has progressed fairly well along, though it's likely to be an extremely slow process. Due to the sort of market that they're dealing with here, HP will probably be offering MIPS based Tandem servers for at least another 5 years.
There are somewhere in the order of 1.4M Xeon units shipped in the same time-frame that AMD shipped 60,000 Opteron servers. Strong growth rate from previous servers, but still less than 5% of the market.
They claim sustained performance of 1.56Gflops per processor. I don't know if this is all that accurate, it seems a bit high considering the Crusoe could only manage something like 350MFlops at 1.0GHz. However the Efficeon did add SSE2 support which might have dramatically improved performance for this sort of workload, so I'll take their number as accurate for comparison sake.
A 3.0GHz P4 can manage somewhere around 4.0Gflops sustained. So basically the 12-processor version of this system should give you slightly better performance for Linpack workloads than a top-end 4-processor Intel Xeon setup (or a 2 x 2P cluster), but with lower power consumption (they claim 220W for the 12P setup vs. about 400W for a similar 4P Xeon setup). Of course, that does assume decent scaling for each system
You would actually do much better for this sort of workload with an Apple Xserve, which can manage about 6.0 Gflops per 2.0GHz processor. Here you could get roughly the same performance with 3 Xserver cluster nodes as with 2 of these 12-processor cluster boards. Power consumption of the XServers would be higher, though not by a huge amount.
Of course, Linpack performance is not the end-all, be-all measure of processing power and other workloads could differ greatly. Unfortunately Transmeta is *HUGELY* secretive of just how their processors perform in the real world (likely because what little I have seen has shown very weak performance), so we don't have much else to go on. Suffice it to say though that simply have 96 processors in a single box is definitely NOT a sure-fire way to get increadible performance.
With a 32-bit OS and 32-bit applications you can only access a maximum of 2 or 3GB of data at a time (possibly even less due to memory fragmentation). This may or may not affect what you do.
If you do indeed have files as big as DVDs, it would certainly help with editing those files. You CAN break those up into chunks, only having 2GB or less in memory at any given time, and for the most part this works ok, however it does tend to be a bit of a kludge at the best of times, and sometimes it just flat out doesn't work.
As you correctly guess, servers are the first situation where this really makes sense. If you've got a database that is more than 2GB in size, you REALLY want a 64-bit system, otherwise you'll tend to take a big performance hit. Many high-end workstations require 64-bit systems as well to process all the data.
So, where is the benefit for the end-user? Well that depends on the user. First off, having more than 2GB of physcial memory on a 32-bit processor requires some really ugly hacks to make things work. They do work, but it is a really dumb idea. It was a annoying and crappy when we were forced to do it back in the 16-bit days, and it hasn't gotten any better. Secondly people are using bigger and bigger data files on their home PC, editing larger pictures and videos, playing games with more graphics and sound, some even run into issues with types of databases (I know my Usenet newsreader sometimes craps out when I'm downloading too much pr0n because of database limits). Basically you might not need it, but someone else might. The best part about it though is that 64-bits is "free".
Basically you've got a 64-bit CPU that is no more expensive than competiting 32-bit chips and Microsoft has said that 64-bit WinXP Pro will sell for the same price as 32-bit WinXP Pro, so really the question is not so much "Why" do we need 64-bit, but "why not?"
Or, for those who can't/don't want to have their own domain, just use the Spam Gourmet to do essentially the same thing.
For those of you who didn't bother to RTFA, the P4 Extreme Edition is *NOT* being discontinued, just the 3.2GHz model.
Beyond that though, AMD doesn't really have a problem. They have done a decent job to position the Athlon64 FX chip they are currently selling as simply being the top-of-the-line Athlon64 chip at any given time. The Athlon64 FX-53 is a little bit faster than the current top-end Athlon64 3900+ and sells for only a fairly small ($100-$150) more.
For Intel it is similar except that they have a much larger price gap. Their top-end regular P4 processor (that is actually being sold) is the 3.4GHz model, while the P4EE 3.4GHz is their model up from that. It is a faster chip and therefore can carry a somewhat larger price premium, but Intel is charging a MUCH larger price premium.
As for the 3.2GHz P4EE, it obviously made no sense now that the 3.4GHz P4EE is here, hence the reason why it's being discontinued. Just as AMD only carries one model of Athlon64 FX at any given time, Intel will likely only carry one speed grade of the P4EE at any given time.
Or more to the point:
"The 3.2GHz P4EE sells for over $900 and the 3.4GHz P4EE sells for only a few dollars more. Anyone dumb enough to waste their money on such an expensive chip might as well spend the extra few dollars for the fastest and get the bragging rights".
As the original poster correctly stated it is NOT the entire line that is being discontinued, only the 3.2GHz P4EE.
FWIW AMD does the exact same thing with their Athlon64 FX line, they have already discontinued their FX-51 model and the FX-53 model will be discontinued in a couple of months when the FX-55 shows up.
Every drive company sucks, trust me.
Go out there and talk to enough people and you'll find dozens of people with horror stories about drives failing left, right and center for EVERY hard drive company out there. Doesn't matter one lick of it's Maxtor, Seagate or WD, they ALL fail, and they all fail with a MUCH higher frequency than damn near any other component in a modern computer system (the possible exception to this rule would be fans, which also fail quite regularly).
Use whatever the heck companies drives you feel like, but honestly there is ZERO difference in reliability from any of the big three drive companies (Maxtor, Seagate and WD).
Yeah, because all those spammers sending out Nigerian 419 scams, phishing scams, credit card fraud and similar such stuff are all such law-abiding citizens. People sending out boatloads of porn while making no attempt to filter it from children's inboxes are totally legit. People advertising for unlicensed pharmacies and illegal gambling sites are within the bounds of the law... right... Ohh, and they're doing all this by hacking computers and distributing viruses so that they can send their spam through compromised systems.
Face it, spammers are a bunch of criminals! Always have been! This new law didn't change that fact, it just added one VERY minor additional offense to an mile-long list of laws that your average spammer breaks on a daily basis.
If the law enforcement agencies don't have the resources to stop spammers from breaking major laws like fraud and computer hacking, obviously they aren't going to have the resources to stop someone from breaking this little CAN-SPAM act!
Uhh, you do realize that you are totally talking out of your ass, right?
These SGI systems have TERMENDOUS memory bandwidth. The whole design is basically centered around memory bandwidth. The whole idea of going for this single-image shared memory space type of system is that it offers much more memory bandwidth.
A Beowulf cluster, on the other hand, has *terrible* internode bandwidth for memory, limited entirely by your network architecture which is usually orders of magnitude slower than native system bandwidth. For many problems this isn't a big bottleneck and the huge cost savings you get from COTS parts can often more than make up for it (ie who cares if it only scales half as well when you get 4 times as many processors), but that certainly is not always the case. Sometimes Beowulf-style clusters just do NOT scale at all, no matter how many chips you throw at the problem.
I think that one of the most interesting things to come out of this article is that running 32-bit applications on a 64-bit OS is generally NOT slower than the 64-bit counterparts, or at least not by any significant amount.
This is significant because most applications out there are still 32-bit ones, so if you can upgrade to a 64-bit OS for one or two important 64-bit applications you don't need to worry about upgrading all your legacy 32-bit apps.
This is in stark contrast to Intel's IA-64 (Itanium) solution in which you take a BIG performance hit when running 32-bit code on a 64-bit OS vs. sticking with x86 hardware. This might seem like an obvious conclusion given that the AMD64 hardware fully supports 32-bit x86 code while IA-64 requires emulation to run 32-bit x86 code, however that point is likely to be lost on a lot of people who control the purse strings.
Just as a FWIW, AMD64 supports 48-bit (or is it 52-bit?) virtual memory space, but only 40-bit physical memory space. From the operating system perspective the virtual memory space is all that counts. Changing physical address space is pretty easy in that it's completely hidden from the software side of things.
As for your bit of code, I'm pretty certain that would seg fault on any operating system, regardless of bitness.
The problem with this theory is three-fold:
1. It places a load on the sending of legitimate e-mail. Not a big deal for people such as myself who's out-going e-mail is usually in the single-digits for the day (and often week), but what about for big ISPs or news services? The big ISPs and mail services (ie those that are needed to make such a system work) would require WAY more computing power to send out legit messages. Similarly you would need to calculate the solution in order to verify that the sender is actually doing the calculations and not just spitting a set of random numbers back at you, so the big mail servers get hit on both ends. When you're sending and receiving hundreds of millions of messages a day (billions in the case of AOL and MSN/Hotmail), that translates to a LOT of computer time and a LOT of added expenses.
2. I can pretty much assure you that whatever someone comes up with as an equation to solve some spammer will find a way around actually spending the pre-message computing time of solving it.
3. Spammers don't send e-mail using conventional mail servers anyway. A VERY significant portion of spam is delivered through broadband connected PCs that have been 0wned by some virus or worm. The quantity of vulnerble systems is pretty much infinite and there's nothing that's going to change this in the near future. In fact, I suspect that it's going to get MUCH worse before it will get any better.
I do tend to agree that simply making spam illegal is not going to do anything, the trick is in enforcement. Most of what spammers are doing has been illegal for AGES. Using viruses and worms to infect computers has been a crime in most countries for many years now. Same goes for illegal credit card scams, bank fraud and all the other trash that spammers are "selling". Hell, even the pr0n spam is almost always illegal as it often gets sent to children's inboxes. New laws are not what is needed, enforcement of existing laws is the trick.
Still, end the end, as long as there are millions upon millions of complete *MORONS* out there willing to spend their hard-earned cash to buy pills to "enhance their manhood", spam will exist in one form or another.
The flaw to these economics is that probably only about 50,000 people or maybe 100,000 tops will actually make use of this program. The flaw will very rarely affect most users, and as a general rule, most people don't read /. (or similar news sites) and probably don't care much about this unless it actually causes problems for them.
What's more, even if it does cause problems, most people will probably just end up blaming Microsoft anyway.
Just as a little FWIW, if you download the NIC drivers for WinXP, as opposed to the ones listed as being "For all operating systems", they are only 10MB. Still too big for a floppy, but at least it's a small improvement.
As to why the system restore disks do not double as a driver disk, that one is completely beyond me. The drivers ARE all on the disk and you actually can access them, but doing so is definitely NOT easy, especially if you don't already know the SoftPaq number you need (you can't just look for Network drivers or anything sensible like that, gotta look for SP25763 or some such nonsense).
FWIW if you're interested in how a very simple cores compares to today's copmlex P4 and Athlon64 chips, look for some comparisons with the VIA C3 chips. The C3 is essentially what you describe, a core very similar to the old Pentium but updated to the latest and greatest manufacturing process, a new bus (the old Pentium bus with it's off-chip cache just stank for scaling) and a few other tweaks and enhancements.
The size, cost and power consumption are excellent for this chip, but it's performance is rather low. However you can pack about 4 of these chips in the same die space as a single P4 or Athlon64 and you can get about 8 of these chips for the power budget of AMD and Intel's latest and greatest. For highly multithreaded applications this could be a better solution.
The problem is that many applications are not highly multithreaded. It's always a trade-off between good multi-threaded performance and good single-threaded performance. For the time being going beyond 2 cores probably doesn't make much sense for desktop and workstation users, there just aren't enough apps that can effectively make use of more than 2 threads to make up for the loss in single threaded performance. For servers, that's another story. What you're describing is pretty much the exact strategy that Sun is taking with their "Niagara" chip design, 8 simple SPARC cores on a single chip. Low single threaded performance but should do VERY well for highly multithreaded applications that are common in the server world. For it's intended use the performance/die size and performance/watt of power should be excellent for that chip.
Err, these dual-core Opterons are going to be socket 940 compatible, just like existing Opterons.
This simple fact kinda of makes your rant completely pointless.