Knowing Intel, I'd be fairly certain that they will do everything that they can to avoid using x86-64. However, their hand might be forced.
As it stands right now, IA-64 is hurting REAL bad. The Itanium is quite possibly the biggest flop in recent history of all technology flops out there (and it's got some tough competition from products that really failed miserably!). If Intel's next generation of IA-64 chips (McKinley), to be released late this year, doesn't improve things DRAMATICALLY, it will probably be the final stake in IA-64. Intel will be forced to drop the architecture and will need to play catch-up real fast with AMD.
Now, the interested rumor that just came out though is that Microsoft may be refusing to support any 64-bit architecture from Intel that is different from AMD's x86-64. If that's the case, Intel may be forced to use AMD's instruction set.
As I said, I'm sure that this isn't something that Intel wants, but unless the McKinley is a HUGE improvement over the Merced/Itanium, then they might well be forced to.
Reasons against 128 or 256-bit computers? Here are the three important ones:
1. These machines would be slower then 32 or 64-bit machines
2. These machines would expensive.
3. It wouldn't help anything except in extremely rare cases (some have suggested some crypto stuff as an example)
Having more bits in a computer system is useful for two main reasons, one is to deal with larger numbers without resorting to some funny math (eg. combining two 8-bit numbers toghether to make a 16-bit number if you need a range of values greater then 256). The other is to support large amounts of memory.
The first reason used to be quite important. Back in the day of 8-bit computers, most systems used a 16-bit or greater memory bus, but could only deal with data in 8 bit chunks. As a result, if you wanted to do anything at all complicated, you needed at least two variables together. Faster forward to 32-bit data though, and the range of numbers you can deal with is now 4 billion, ie more then enough for all but the most extreme situations, and for those situations you now have floating point units (which can deal with much larger numbers), as well as MMX, SSE/SSEII, etc., which can sometimes be used instead.
Therefore, the only real benefit of going to 64-bits is to access larger amounts of memory. 32-bit processors can only access 32-bits worth of memory directly, ie 4GiB. Actually, usually you end up with a limit of only 2GiB since you can have relative pointers (ie a pointer can be +/- 2GiB from the current location). There are some ways around this, ie Intel's PEA, but this gets into the same kinda of ugliness we had back in the old DOS segmented memory days. It was an ugly kludge back then, and if anything it's even worse now. With 64-bit chips, you can have pointers to access 10^19 bytes of memory directly.
So, going to 128-bits would buy us what? The ability to access more then 10^19 bytes of memory? That isn't likely to be an issue for quite some time, even if memory use continues to double every 18-months or so. It also doesn't help for accessing larger values, because it's quite rare to need more then 32-bits integers, let alone 64-bit integers, and for those extremely odd cases, there are potential workarounds.
The downside of going to wider CPUs though is that, all else being equal, they're slower. A 64-bit CPU needs to get twice as much data from memory as a 32-bit CPU, and a 128-bit CPU would need twice as much data again, for each and every variable! Now, those who look at computer performance today will probably already know that memory bandwidth is a potentially major bottleneck. Making a system require twice as much data from memory can place even greater restrictions on memory bandwidth.
So, for today, the advantages of 64-bit CPUs tend to outweight the disadvantages, at least for the high-end. However a 128-bit CPU makes no sense at all, since it offers no advantages but lots of disadvantages.
As for the game consoles, don't get confused by the terminology. Their "128-bit" and "256-bit" chips are for the video portion of their systems. Virtually all current graphics chips for PCs are 128-bit or 256-bit in much the same way. However this is a whole other ballpark from the general purpose CPUs being discussed here.
Am I the only one that's worried that the next step in computer mods is going to take a page from rice rockets?! ie mods that do absolutely nothing useful but make a HUGE racket?!
I can just see it now, some 3133t d00d show's up at a LAN party driving a Honda Civic with a 5" exhaust pipe, whiping out his computer that has a special noise maker attached to the rear fan duct so that the air leaving his case makes 4 times as much noise as normal.
Hmm. I think I'll stick to my nice, almost completely silent Athlon system thank you.. and the stock exhaust on my car while I'm at it.
AMD Alchemy Au1100 400MHz : 0.25W Max Intel XScale PX250 400MHz : 0.30W Max
Max = Maximum possible real-world power consumed by the chip Typ = Typical power use under heavy processing TDP = Thermal Design Power, usually just slightly higher then typical power, though it's defined by the manufacturer
So, just to keep things in perspective, we're talking about these embedded chips using two orders of magnitude less power then even laptop x86 chips. Now, obviously the performance isn't going to be at all the same, but in terms of power, it doesn't make any sense at all to compare the power consumption of either.
AMD MIGHT be able to squeeze out a model 2200+ chip based on their old.18 micron fab process, but that's probably about it. That being said, this probably isn't a huge worry for AMD at this point, since they started shipping AthlonXP's based on a.13 micron fab process last month. They haven't officially released the chips yet, but it's going to happen sometime this month. Just a matter of weeks now.
What's perhaps more interesting then the AthlonXP 2200+ and faster desktop parts though is that their mobile chips based on the new fab process should be out too. This should bring the Athlon 4 mobile chips into the same power bracket as the old PIII mobile chips (quite a bit less power the the P4-M). Combine that with AMD's reasonably advanced PowerNow! technology, and these should be quite high performing chips that don't suck batteries dry.
I'm running an nForce platform now and have been quite impressed with the stability of the thing. I had a slight problem when I first installed the system using the beta drivers that shipped on the CD, howeve as soon as I put the final release drivers on it, everything worked out great.
For comparison, I've also used VIA, SiS and Intel chipsets in the past. VIA are the worst of the bunch, but I wouldn't call either SiS or Intel "trouble-free" by any stretch. All those people thinking that Intel's chipsets are all that obviously never went through the terrible growing pains of their IDE bus mastering drivers, first with PIIX4 southbridge (430TX and 440LX chipsets) and then later with their first batch of ICH drivers (i810, i820 and i840 chipsets).
All in all, I'd say that the situation with motherboard drivers is really quite poor. SiS and Intel get good drivers eventually, but it takes them 6 months after bringing out a totally new southbridge/IO hub. VIA and ALi never really get good drivers, though they're usually acceptable 6 months after the first release. So far the nVidia's 1.0 drivers have been as good as any I've used, so I've got a fair bit of hope for them.
MOST applications don't get optimized at all! Or if they do, it's merely someone turning on a -O2 flag in the compiler. Optimizing stuff for a specific processor is a definitely non-trivial task. Some applications will have a few key bottleneck areas optimized for one architecture or another, but usually any optimizations that do occur are fairly general purpose optimizations that are designed to make the code run faster on ANY platform.
Accessing memory over a network?! What in the hell?! Already memory latency is one of the largest bottlenecks in computers today (hence the reason for L1, L2 and in some cases even L3 caches on chips), and there we're talking about access times in the hundreds of nanoseconds! You're suggesting that we access network memory that would have approximately a million times worse latency?! (and that's assuming good ping-times:> )
Directly accessing memory over a network is just plain dumb. It may make sense to distribute data over networks in some situations, but that in no way requires or would benefit from being able to directly address memory in hardware. Even if for some bizzare reason you DID want to have direct memory access over networks, this would severly limit interoperability of systems! This sort of thing belongs entirely in the realm of software.
FWIW the Athlon4 mobile processor at it's highest speed available now has a thermal design power consumption of 25W. Intel's P4 mobiles are all expected to be well over 30W of TDP (for comparison, AMD's desktop Athlon chips range from ~40-75W, while Intel's desktop P4's range from about 50-85W).
What's more, that's for AMD's.18 micron fab process mobile chips vs. Intel's.13 micron fab process chips. When you start comparing AMD's mobile.13 micron chips vs. Intel's mobile.13 micron chips (both of which should be available in a month or two) things should look even a bit better for AMD.
Simpel answer: because there isn't anything that needs 128-bits now or in the near future.
Beyond that, all else being equal, having more bitness makes a processor SLOWER! Yes, you read that right, all else being equal, a 64-bit chip is SLOWER then a 32-bit chip because you need to read in twice as much data. However, when it comes to a point where it's a question of using a single 64-bit number vs. two 32-bit number, then the 64-bit application becomes much faster.
What's even more important though is the memory addressing issue. With a 32-bits gives you 4GB of memory address space. With x86 chips/operating systems, you're actually limited to only 2GB of addressible memory if my memory serves me correctly. Going beyond that you have to do wierd funky things with segmented memory. Intel has defined an extension to x86 that does allow this segmented memory model, but it's just as bad of a kludge to do this now with 32-bit chips as it was back when they were doing it with 16-bit chips.
Anyway, long story short, 64-bit chips should be good for quite some time to come, going to 128-bits would just cost more for less performance.
How long have Macs had 64-bit processors? That one's easy, NEVER!
The G4 is still as much a 32-bit processor as the Athlon or P4 are. Sure, Altivec can handle 128-bits of data at a time, but so can SSE2. No, the current Macs are, but every meaningful definition (ie nothing that Steve Jobs might say) a 32-bit chip.
Now, that being said, Apple SHOULD be the first company to bring a 64-bit processor to consumer PCs. The upcoming G5's ARE a 64-bit processor. IF Apple/Motorola manage to get these chips to market on schedule for this summer they will beat AMD's planned Q4 release for the first Hammer chips.
When the chips first came out, this was true. However, eventually Intel found out that the 486SX was so popular and allowed them to sell more chips by competing in new markets (albeit at lower price points), they ended up having to disable the FPU on MANY of the 486SX chips that they sold to meet demand (ie they didn't have enough 486DX chips with broken FPUs). Later on Intel fixed this for good by releasing a new 486SX revision that didn't have the FPU circuitry on it at all.
FWIW, given Intel's manufacturing model, this sort of thing tends to make a fair bit of sense. Each different processor die that they have to produce costs money, so it's often cheaper for them to simply disable the features on more expensive dies rather then to produce two different types of dies.
In that case the PentiumPro, Pentium II, Pentium III, Celeron and Pentium 4 are also not "Pentium-compatible" by your definition, because they have at least as many differences from the original Pentium chips as AMD does. What's more, these chips are not 100% compatible with the 486 or 386 either. And no, I'm not talking about new features being added.
Have a look at Intel's "Specification Updates" some time. Intel has over 80 errata listed for their Pentium III processor in ways that it differs from the "expected behavior".
It WAS, however, documented as a hardware bug in AMD's April 2001 update of their Errata sheets that are available on AMD's website for any and all to download. It's bug #16 in AMD's Athlon Revision Guide.
As an aside, I don't quite get the "It's a motherboard bug" thing, assuming that they're talking about the same bug as the Win2K thing. The documentation for the Win2K bug is clearly the same as the hardware bug mentioned in the above errata sheet. If you ask me, it's a rather well documented hardware bug that really should have been noticed and worked around in software long ago.
Alan Cox and other kernel hackers do read these documents. The question is if AMD documented this bug in their errata, or just fixed for Windows 2000 and figured that was good enough.
Bug #16 in AMD's Errata list for the AMD Athlon Model 6 processor (ie the AthlonXP/MP) lists the following:
(Begin quoting)
16 INVLPG Instruction Does Not Flush Entire Four-Megabyte Page Properly with Certain
Linear Addresses
Products Affected. A0, A2
Normal Specified Operation. After executing an INVLPG instruction the TLB should not contain any
translations for any part of the page frame associated with the designated logical address.
Non-conformance. When the logical address designated by the INVLPG instruction is mapped by a 4-MB page mapping and LA[21] is equal to one it is possible that the TLB will still retain translations after the instruction has finished executing.
Potential Effect on System. The residual data in the TLB can result in unexpected data access to stale or invalid pages of memory.
Suggested Workaround. When using the INVLPG instruction in association with a page that is mapped via a 4-MB page translation, always clear bit 21.
(end quoting)
It's there. It's been listed there for quite some time. No one read the errata and/or no one bothered to check to see if this one affected Linux systems. I hate to break it to the Linux boys, but they kinda missed the boat on this one. Normally Linux kernal hackers seem pretty good at staying on top of processor bugs, but it looks like this one slipped through the cracks.
FWIW, anyone looking for this errata list can find it here. As a bit of an aside, none of AMD's PDF documents will load for me in Mozilla/Netscape 6 with Acrobat 5, but they all work fine with IE/Acrobat 5. Wierd.
The Windows "patch" just changes a registry key, so the correct answer to your initial question is No, a Win2K user does NOT need to be connected to the internet (other then to figure out just which key to change in the first place, in which case a Linux user would also need an internet connection to figure out which line to add to the bootloader).
The only really valid point I see against Windows in this situation is that the registry has essentially no documentation! There are TONS of settings and customizations available within the registry for Windows, but essentially nobody knows even 1/10th of them because of lack of documentation!
Of course it's due to money! Coming up with a fix to a bug like this doesn't just happen overnight, and since the errata in processors barely ever effect anyone and can usually be easily worked around in software (and the software fix for this bug is trivial), most companies have better things to do with their time. As it turns out, AMD did eventually get around to fixing this issue with Stepping A5 of the AthlonXP/MP core.
In the same vein, out of the 83 bugs that Intel currently has listed for their Pentium III processor, quite a bit more then 50% of them are listed as "NoFix", ie Intel has no plans on ever fixing these bugs.
The real question I have to ask is why no one caught this earlier? This bug is well documented in AMD's errata list, complete with a workaround. AMD's Athlon chips only have something like 10-15 known bugs listed, which is quite a few less then the 59 known bugs for Intel's P4 or the 83 known bugs for Intel's PIII processors, so going through the list of AMD bugs should be a fairly easy thing to do (aside: one could argue either that AMD chips have fewer bugs then Intel or simply that Intel documents their chips better.. I don't want to take either side on that flame war though).
If anyone is really interested in this sort of thing, both AMD and Intel have their list of known bugs up on their website under "specification updates" for each of their processors.
Well, a good place to start is to identify where the noise is coming from. In a PC this is generally three places: CPU Heatsink fan, power supply fan and hard drives.
For the CPU heatsink fan, the best way to silence the thing is to use a CPU that doesn't need a fan. The only currently available chip that comes to mind here is the VIA Cyrix III. Sure, this chip is quite a bit slower then a Celeron or a Duron, but as you said, performance wasn't your top criteria.
For the power supply fan, you could try getting rid of this altogether to, however your best bet would probably be to get a power supply that uses a relatively large, slow spinning fan. The PC Power and Cooling fan mentioned is one option, though you could probably get just about any power supply out there and simply replace the fan with a quiet, slow spinning fan instead. Pabst is known for making some very quiet fans, or just a plain old ~2000-2500rpm 80mm Panasonic fan should do the trick.
For hard drives, obviously some 15K rpm SCSI drives are out of the question. The quietest common drive out there today, according to Storage Review's Testbed3 is the Seagate U6 5400rpm IDE drive. For a higher performance drive, Seagates Baracuda IV drives get top marks for low-noise. Beyond that, you can further reduce drive noise by putting the hard drive into a drive sleeve type thing (put a 3.5" drive into a sound-proof casing that fits in a 5.25" drive bay).
After all of this is done, you should have yourself a VERY quiet system. Will it be truly and totally silent? No, obviously not, but hopefully it should be quiet enough for your tastes. At the very least it's likely to be about the quietest PC (meaning x86) you can get.
The Radeon might be competitive with the GeForce3 under Windows, but their Linux drivers are VERY immature at the moment and it get's completely blown out the water.
The simple fact of the matter is that if you want good 3D performance under Linux TODAY, you NEED nVidia. No other company can even beat the low-end nVidia cards, let alone their high-end stuff.
To a certain extent you have a point that the 2.0GHz Northwood is not the fastest chip that Intel offers.
However, the other way to look at it is that they're comparing a $350 AMD processor to a $500 Intel processor, so one could say that the comparison is actually biased in the other direction as well.
If Apple's G4 had half of what the hype for it is, it would be twice as fast as it is now! Don't get me wrong, the G5 has some nice parts to it, but I don't expect it to be setting any records for raw speed by any stretch of the imagination. The raw computing power of the G4 is roughly comperable to an Athlon, clock for clock, and the G5 isn't likely to be any better (probably very slightly worse at equivalent clock speeds). Considering that it will only be coming in at ~1.5GHz by mid-year, that will put it as being about on-par with the slowest Celeron and Duron chips being sold at the time.
Steve Jobs does a great job of hype, and Mac OS X looks REAL nice, but really, when it comes to raw processing power, the G4 and G5 aren't the end-all be-all processors that many make them out to be. Anyone ever wondered why Apple/Motorola don't test these chips on ANY industry standard benchmarks, resorting only to some totally outdated "ByteMark" and the VERY easily manipulated Photoshop "benchmarks" (using the term loosely).
I'd bet just about any amount of money that this "1.6GHz G4" is really a dual-800MHz G4 that someone (totally incorrectly) assumed was the same thing as a 1.6GHz processor.
The obvious answer is that people don't overclock because they need more CPU speed, they overclock because it makes them super-kewl with all their script-kiddie buddies! Or perhaps it makes their penis larger or some such thing. Some people overclock their systems for mostly the same reasons why a lot of people put special high-performance parts in their cars, not because it does anything really useful for them, but because it's a hobby.
I don't see what's so bad about the comparison? Idle power for all modern mobile chips is under 1W, while the Eden and the Crusoe are likely to have typical power use of about 6W. The Crusoe has a slight advantage in that it has a built-in memory controller, so you don't need to add in any extra power for that component like you do on the Eden, but overall the two systems (as well as the Ultra Low Voltage PIII) are going to be in the same general power consumption range. Once you figure in the power requirements of the display and hard drive as well as video, the difference between these chips in terms of power consumption is likely to amount to nothing more then noise.
Where the real difference occurs is price and performance. Intel's ULV PIII, even at fairly slow clock speeds, has the others beat pretty much hands down in terms of performance, no question at all. On the other hand, these are also rather pricy chips. The thing that makes these VIA chips exciting is that they're dirt-cheap and work with the same sort of components that mobile PIIIs do. The problem for Transmeta is that their chips are relatively expensive and also very slow, making them an all around bad choice for the most part.
Well that's obviously not 100% true, Intel had special low-powered "mobile" processor lines well before Crusoe was ever released. I think they started producing special low-powered chip for notebooks somewhere fairly early in the Pentium line, or perhaps even earlier. Transmeta might have given them a bit of a push though, since it was only after the Crusoe started getting some attention then Intel brought out chips like their "Ultra Low Voltage" PIII on top of their regular mobile PIIIs and Celerons.
I think for the most part the push for lower powered chips came as a direct result of the desktop chips requiring more power. Most Pentiums were in the 10-20W range to begin with, and 486 consumed less power still. It wasn't until the PII came out that Intel had a desktop processor that was pumping out over 30W worth of heat that low powered chips really became a requirement.
Transmeta may have managed to shift a lot of the focus of things towards power consumption, but they did so only because they had no other selling point of the processor. Originally the hype was that they were going to have industry-leading performance, but when it became painfully obvious that this wasn't going to happen, they turned to the whole low-power thing.
Slashdot Mirror
Knowing Intel, I'd be fairly certain that they will do everything that they can to avoid using x86-64. However, their hand might be forced.
As it stands right now, IA-64 is hurting REAL bad. The Itanium is quite possibly the biggest flop in recent history of all technology flops out there (and it's got some tough competition from products that really failed miserably!). If Intel's next generation of IA-64 chips (McKinley), to be released late this year, doesn't improve things DRAMATICALLY, it will probably be the final stake in IA-64. Intel will be forced to drop the architecture and will need to play catch-up real fast with AMD.
Now, the interested rumor that just came out though is that Microsoft may be refusing to support any 64-bit architecture from Intel that is different from AMD's x86-64. If that's the case, Intel may be forced to use AMD's instruction set.
As I said, I'm sure that this isn't something that Intel wants, but unless the McKinley is a HUGE improvement over the Merced/Itanium, then they might well be forced to.
Reasons against 128 or 256-bit computers? Here are the three important ones:
1. These machines would be slower then 32 or 64-bit machines
2. These machines would expensive.
3. It wouldn't help anything except in extremely rare cases (some have suggested some crypto stuff as an example)
Having more bits in a computer system is useful for two main reasons, one is to deal with larger numbers without resorting to some funny math (eg. combining two 8-bit numbers toghether to make a 16-bit number if you need a range of values greater then 256). The other is to support large amounts of memory.
The first reason used to be quite important. Back in the day of 8-bit computers, most systems used a 16-bit or greater memory bus, but could only deal with data in 8 bit chunks. As a result, if you wanted to do anything at all complicated, you needed at least two variables together. Faster forward to 32-bit data though, and the range of numbers you can deal with is now 4 billion, ie more then enough for all but the most extreme situations, and for those situations you now have floating point units (which can deal with much larger numbers), as well as MMX, SSE/SSEII, etc., which can sometimes be used instead.
Therefore, the only real benefit of going to 64-bits is to access larger amounts of memory. 32-bit processors can only access 32-bits worth of memory directly, ie 4GiB. Actually, usually you end up with a limit of only 2GiB since you can have relative pointers (ie a pointer can be +/- 2GiB from the current location). There are some ways around this, ie Intel's PEA, but this gets into the same kinda of ugliness we had back in the old DOS segmented memory days. It was an ugly kludge back then, and if anything it's even worse now. With 64-bit chips, you can have pointers to access 10^19 bytes of memory directly.
So, going to 128-bits would buy us what? The ability to access more then 10^19 bytes of memory? That isn't likely to be an issue for quite some time, even if memory use continues to double every 18-months or so. It also doesn't help for accessing larger values, because it's quite rare to need more then 32-bits integers, let alone 64-bit integers, and for those extremely odd cases, there are potential workarounds.
The downside of going to wider CPUs though is that, all else being equal, they're slower. A 64-bit CPU needs to get twice as much data from memory as a 32-bit CPU, and a 128-bit CPU would need twice as much data again, for each and every variable! Now, those who look at computer performance today will probably already know that memory bandwidth is a potentially major bottleneck. Making a system require twice as much data from memory can place even greater restrictions on memory bandwidth.
So, for today, the advantages of 64-bit CPUs tend to outweight the disadvantages, at least for the high-end. However a 128-bit CPU makes no sense at all, since it offers no advantages but lots of disadvantages.
As for the game consoles, don't get confused by the terminology. Their "128-bit" and "256-bit" chips are for the video portion of their systems. Virtually all current graphics chips for PCs are 128-bit or 256-bit in much the same way. However this is a whole other ballpark from the general purpose CPUs being discussed here.
Hmm..
Am I the only one that's worried that the next step in computer mods is going to take a page from rice rockets?! ie mods that do absolutely nothing useful but make a HUGE racket?!
I can just see it now, some 3133t d00d show's up at a LAN party driving a Honda Civic with a 5" exhaust pipe, whiping out his computer that has a special noise maker attached to the rear fan duct so that the air leaving his case makes 4 times as much noise as normal.
Hmm. I think I'll stick to my nice, almost completely silent Athlon system thank you.. and the stock exhaust on my car while I'm at it.
Just FWIW, here's a couple processor heat numbers:
Desktop AMD AthlonXP 2000+ : 70.0W Max/62.0W typ
Desktop Intel P4 2.0GHz : 75.3W TDP
Desktop Intel P4 2.0A : 52.4W TDP
Mobile AMD Athlon4 1500+ : 25.0W TDP
Mobile Intel P4-M 1.6GHz : 30.0W TDP
Mobile Intel PIII-M 1.2GHz : 22.0W TDP
AMD Alchemy Au1100 400MHz : 0.25W Max
Intel XScale PX250 400MHz : 0.30W Max
Max = Maximum possible real-world power consumed by the chip
Typ = Typical power use under heavy processing
TDP = Thermal Design Power, usually just slightly higher then typical power, though it's defined by the manufacturer
So, just to keep things in perspective, we're talking about these embedded chips using two orders of magnitude less power then even laptop x86 chips. Now, obviously the performance isn't going to be at all the same, but in terms of power, it doesn't make any sense at all to compare the power consumption of either.
Ohh, and just for fun, here's one more chip:
Intel Intanium 800MHz : 130W Max
Regards
Tony
AMD MIGHT be able to squeeze out a model 2200+ chip based on their old .18 micron fab process, but that's probably about it. That being said, this probably isn't a huge worry for AMD at this point, since they started shipping AthlonXP's based on a .13 micron fab process last month. They haven't officially released the chips yet, but it's going to happen sometime this month. Just a matter of weeks now.
What's perhaps more interesting then the AthlonXP 2200+ and faster desktop parts though is that their mobile chips based on the new fab process should be out too. This should bring the Athlon 4 mobile chips into the same power bracket as the old PIII mobile chips (quite a bit less power the the P4-M). Combine that with AMD's reasonably advanced PowerNow! technology, and these should be quite high performing chips that don't suck batteries dry.
I'm running an nForce platform now and have been quite impressed with the stability of the thing. I had a slight problem when I first installed the system using the beta drivers that shipped on the CD, howeve as soon as I put the final release drivers on it, everything worked out great.
For comparison, I've also used VIA, SiS and Intel chipsets in the past. VIA are the worst of the bunch, but I wouldn't call either SiS or Intel "trouble-free" by any stretch. All those people thinking that Intel's chipsets are all that obviously never went through the terrible growing pains of their IDE bus mastering drivers, first with PIIX4 southbridge (430TX and 440LX chipsets) and then later with their first batch of ICH drivers (i810, i820 and i840 chipsets).
All in all, I'd say that the situation with motherboard drivers is really quite poor. SiS and Intel get good drivers eventually, but it takes them 6 months after bringing out a totally new southbridge/IO hub. VIA and ALi never really get good drivers, though they're usually acceptable 6 months after the first release. So far the nVidia's 1.0 drivers have been as good as any I've used, so I've got a fair bit of hope for them.
Whoa! That's being VERY optimistic!
MOST applications don't get optimized at all! Or if they do, it's merely someone turning on a -O2 flag in the compiler. Optimizing stuff for a specific processor is a definitely non-trivial task. Some applications will have a few key bottleneck areas optimized for one architecture or another, but usually any optimizations that do occur are fairly general purpose optimizations that are designed to make the code run faster on ANY platform.
Accessing memory over a network?! What in the hell?! Already memory latency is one of the largest bottlenecks in computers today (hence the reason for L1, L2 and in some cases even L3 caches on chips), and there we're talking about access times in the hundreds of nanoseconds! You're suggesting that we access network memory that would have approximately a million times worse latency?! (and that's assuming good ping-times :> )
Directly accessing memory over a network is just plain dumb. It may make sense to distribute data over networks in some situations, but that in no way requires or would benefit from being able to directly address memory in hardware. Even if for some bizzare reason you DID want to have direct memory access over networks, this would severly limit interoperability of systems! This sort of thing belongs entirely in the realm of software.
FWIW the Athlon4 mobile processor at it's highest speed available now has a thermal design power consumption of 25W. Intel's P4 mobiles are all expected to be well over 30W of TDP (for comparison, AMD's desktop Athlon chips range from ~40-75W, while Intel's desktop P4's range from about 50-85W).
What's more, that's for AMD's .18 micron fab process mobile chips vs. Intel's .13 micron fab process chips. When you start comparing AMD's mobile .13 micron chips vs. Intel's mobile .13 micron chips (both of which should be available in a month or two) things should look even a bit better for AMD.
Simpel answer: because there isn't anything that needs 128-bits now or in the near future.
Beyond that, all else being equal, having more bitness makes a processor SLOWER! Yes, you read that right, all else being equal, a 64-bit chip is SLOWER then a 32-bit chip because you need to read in twice as much data. However, when it comes to a point where it's a question of using a single 64-bit number vs. two 32-bit number, then the 64-bit application becomes much faster.
What's even more important though is the memory addressing issue. With a 32-bits gives you 4GB of memory address space. With x86 chips/operating systems, you're actually limited to only 2GB of addressible memory if my memory serves me correctly. Going beyond that you have to do wierd funky things with segmented memory. Intel has defined an extension to x86 that does allow this segmented memory model, but it's just as bad of a kludge to do this now with 32-bit chips as it was back when they were doing it with 16-bit chips.
Anyway, long story short, 64-bit chips should be good for quite some time to come, going to 128-bits would just cost more for less performance.
How long have Macs had 64-bit processors? That one's easy, NEVER!
The G4 is still as much a 32-bit processor as the Athlon or P4 are. Sure, Altivec can handle 128-bits of data at a time, but so can SSE2. No, the current Macs are, but every meaningful definition (ie nothing that Steve Jobs might say) a 32-bit chip.
Now, that being said, Apple SHOULD be the first company to bring a 64-bit processor to consumer PCs. The upcoming G5's ARE a 64-bit processor. IF Apple/Motorola manage to get these chips to market on schedule for this summer they will beat AMD's planned Q4 release for the first Hammer chips.
When the chips first came out, this was true. However, eventually Intel found out that the 486SX was so popular and allowed them to sell more chips by competing in new markets (albeit at lower price points), they ended up having to disable the FPU on MANY of the 486SX chips that they sold to meet demand (ie they didn't have enough 486DX chips with broken FPUs). Later on Intel fixed this for good by releasing a new 486SX revision that didn't have the FPU circuitry on it at all.
FWIW, given Intel's manufacturing model, this sort of thing tends to make a fair bit of sense. Each different processor die that they have to produce costs money, so it's often cheaper for them to simply disable the features on more expensive dies rather then to produce two different types of dies.
In that case the PentiumPro, Pentium II, Pentium III, Celeron and Pentium 4 are also not "Pentium-compatible" by your definition, because they have at least as many differences from the original Pentium chips as AMD does. What's more, these chips are not 100% compatible with the 486 or 386 either. And no, I'm not talking about new features being added.
Have a look at Intel's "Specification Updates" some time. Intel has over 80 errata listed for their Pentium III processor in ways that it differs from the "expected behavior".
Processor bugs happen.
It WAS, however, documented as a hardware bug in AMD's April 2001 update of their Errata sheets that are available on AMD's website for any and all to download. It's bug #16 in AMD's Athlon Revision Guide.
As an aside, I don't quite get the "It's a motherboard bug" thing, assuming that they're talking about the same bug as the Win2K thing. The documentation for the Win2K bug is clearly the same as the hardware bug mentioned in the above errata sheet. If you ask me, it's a rather well documented hardware bug that really should have been noticed and worked around in software long ago.
Alan Cox and other kernel hackers do read these documents. The question is if AMD documented this bug in their errata, or just fixed for Windows 2000 and figured that was good enough.
Bug #16 in AMD's Errata list for the AMD Athlon Model 6 processor (ie the AthlonXP/MP) lists the following:
(Begin quoting)
16 INVLPG Instruction Does Not Flush Entire Four-Megabyte Page Properly with Certain Linear Addresses
Products Affected. A0, A2
Normal Specified Operation. After executing an INVLPG instruction the TLB should not contain any translations for any part of the page frame associated with the designated logical address.
Non-conformance. When the logical address designated by the INVLPG instruction is mapped by a 4-MB page mapping and LA[21] is equal to one it is possible that the TLB will still retain translations after the instruction has finished executing.
Potential Effect on System. The residual data in the TLB can result in unexpected data access to stale or invalid pages of memory.
Suggested Workaround. When using the INVLPG instruction in association with a page that is mapped via a 4-MB page translation, always clear bit 21.
(end quoting)
It's there. It's been listed there for quite some time. No one read the errata and/or no one bothered to check to see if this one affected Linux systems. I hate to break it to the Linux boys, but they kinda missed the boat on this one. Normally Linux kernal hackers seem pretty good at staying on top of processor bugs, but it looks like this one slipped through the cracks.
FWIW, anyone looking for this errata list can find it here. As a bit of an aside, none of AMD's PDF documents will load for me in Mozilla/Netscape 6 with Acrobat 5, but they all work fine with IE/Acrobat 5. Wierd.
The Windows "patch" just changes a registry key, so the correct answer to your initial question is No, a Win2K user does NOT need to be connected to the internet (other then to figure out just which key to change in the first place, in which case a Linux user would also need an internet connection to figure out which line to add to the bootloader).
The only really valid point I see against Windows in this situation is that the registry has essentially no documentation! There are TONS of settings and customizations available within the registry for Windows, but essentially nobody knows even 1/10th of them because of lack of documentation!
Of course it's due to money! Coming up with a fix to a bug like this doesn't just happen overnight, and since the errata in processors barely ever effect anyone and can usually be easily worked around in software (and the software fix for this bug is trivial), most companies have better things to do with their time. As it turns out, AMD did eventually get around to fixing this issue with Stepping A5 of the AthlonXP/MP core.
In the same vein, out of the 83 bugs that Intel currently has listed for their Pentium III processor, quite a bit more then 50% of them are listed as "NoFix", ie Intel has no plans on ever fixing these bugs.
The real question I have to ask is why no one caught this earlier? This bug is well documented in AMD's errata list, complete with a workaround. AMD's Athlon chips only have something like 10-15 known bugs listed, which is quite a few less then the 59 known bugs for Intel's P4 or the 83 known bugs for Intel's PIII processors, so going through the list of AMD bugs should be a fairly easy thing to do (aside: one could argue either that AMD chips have fewer bugs then Intel or simply that Intel documents their chips better.. I don't want to take either side on that flame war though).
If anyone is really interested in this sort of thing, both AMD and Intel have their list of known bugs up on their website under "specification updates" for each of their processors.
Well, a good place to start is to identify where the noise is coming from. In a PC this is generally three places: CPU Heatsink fan, power supply fan and hard drives.
For the CPU heatsink fan, the best way to silence the thing is to use a CPU that doesn't need a fan. The only currently available chip that comes to mind here is the VIA Cyrix III. Sure, this chip is quite a bit slower then a Celeron or a Duron, but as you said, performance wasn't your top criteria.
For the power supply fan, you could try getting rid of this altogether to, however your best bet would probably be to get a power supply that uses a relatively large, slow spinning fan. The PC Power and Cooling fan mentioned is one option, though you could probably get just about any power supply out there and simply replace the fan with a quiet, slow spinning fan instead. Pabst is known for making some very quiet fans, or just a plain old ~2000-2500rpm 80mm Panasonic fan should do the trick.
For hard drives, obviously some 15K rpm SCSI drives are out of the question. The quietest common drive out there today, according to Storage Review's Testbed3 is the Seagate U6 5400rpm IDE drive. For a higher performance drive, Seagates Baracuda IV drives get top marks for low-noise. Beyond that, you can further reduce drive noise by putting the hard drive into a drive sleeve type thing (put a 3.5" drive into a sound-proof casing that fits in a 5.25" drive bay).
After all of this is done, you should have yourself a VERY quiet system. Will it be truly and totally silent? No, obviously not, but hopefully it should be quiet enough for your tastes. At the very least it's likely to be about the quietest PC (meaning x86) you can get.The Radeon might be competitive with the GeForce3 under Windows, but their Linux drivers are VERY immature at the moment and it get's completely blown out the water.
The simple fact of the matter is that if you want good 3D performance under Linux TODAY, you NEED nVidia. No other company can even beat the low-end nVidia cards, let alone their high-end stuff.
To a certain extent you have a point that the 2.0GHz Northwood is not the fastest chip that Intel offers.
However, the other way to look at it is that they're comparing a $350 AMD processor to a $500 Intel processor, so one could say that the comparison is actually biased in the other direction as well.
If Apple's G4 had half of what the hype for it is, it would be twice as fast as it is now! Don't get me wrong, the G5 has some nice parts to it, but I don't expect it to be setting any records for raw speed by any stretch of the imagination. The raw computing power of the G4 is roughly comperable to an Athlon, clock for clock, and the G5 isn't likely to be any better (probably very slightly worse at equivalent clock speeds). Considering that it will only be coming in at ~1.5GHz by mid-year, that will put it as being about on-par with the slowest Celeron and Duron chips being sold at the time.
Steve Jobs does a great job of hype, and Mac OS X looks REAL nice, but really, when it comes to raw processing power, the G4 and G5 aren't the end-all be-all processors that many make them out to be. Anyone ever wondered why Apple/Motorola don't test these chips on ANY industry standard benchmarks, resorting only to some totally outdated "ByteMark" and the VERY easily manipulated Photoshop "benchmarks" (using the term loosely).
I'd bet just about any amount of money that this "1.6GHz G4" is really a dual-800MHz G4 that someone (totally incorrectly) assumed was the same thing as a 1.6GHz processor.
The obvious answer is that people don't overclock because they need more CPU speed, they overclock because it makes them super-kewl with all their script-kiddie buddies! Or perhaps it makes their penis larger or some such thing. Some people overclock their systems for mostly the same reasons why a lot of people put special high-performance parts in their cars, not because it does anything really useful for them, but because it's a hobby.
I don't see what's so bad about the comparison? Idle power for all modern mobile chips is under 1W, while the Eden and the Crusoe are likely to have typical power use of about 6W. The Crusoe has a slight advantage in that it has a built-in memory controller, so you don't need to add in any extra power for that component like you do on the Eden, but overall the two systems (as well as the Ultra Low Voltage PIII) are going to be in the same general power consumption range. Once you figure in the power requirements of the display and hard drive as well as video, the difference between these chips in terms of power consumption is likely to amount to nothing more then noise.
Where the real difference occurs is price and performance. Intel's ULV PIII, even at fairly slow clock speeds, has the others beat pretty much hands down in terms of performance, no question at all. On the other hand, these are also rather pricy chips. The thing that makes these VIA chips exciting is that they're dirt-cheap and work with the same sort of components that mobile PIIIs do. The problem for Transmeta is that their chips are relatively expensive and also very slow, making them an all around bad choice for the most part.
Well that's obviously not 100% true, Intel had special low-powered "mobile" processor lines well before Crusoe was ever released. I think they started producing special low-powered chip for notebooks somewhere fairly early in the Pentium line, or perhaps even earlier. Transmeta might have given them a bit of a push though, since it was only after the Crusoe started getting some attention then Intel brought out chips like their "Ultra Low Voltage" PIII on top of their regular mobile PIIIs and Celerons.
I think for the most part the push for lower powered chips came as a direct result of the desktop chips requiring more power. Most Pentiums were in the 10-20W range to begin with, and 486 consumed less power still. It wasn't until the PII came out that Intel had a desktop processor that was pumping out over 30W worth of heat that low powered chips really became a requirement.
Transmeta may have managed to shift a lot of the focus of things towards power consumption, but they did so only because they had no other selling point of the processor. Originally the hype was that they were going to have industry-leading performance, but when it became painfully obvious that this wasn't going to happen, they turned to the whole low-power thing.