You might want to read over those tech-docs again, or more specifically the "AMD64 Architecture Programmer's Manual Volume 1:", in section 1.2: Modes of Operation.
<quoting sub-section 1.2.3> Compatibility mode--the second submode of long mode--allows 64-bit operating systems to run existing 16-bit and 32-bit x86 applications. <end quote>
However, I think what you're looking for is a little earlier in the section.
<quoting sub-section 1.2.1> Long mode does not support legacy real mode or legacy virtual-8086 mode, and it does not support hardware task switching. <end quote>
Now, this may seem like a bit of a loss, since DOS was run in real mode, and Linux 1.xx made use of the hardware task switching, but neither of these operating systems are ever going to run in Long mode on an x86 chip since they're both long since being EOLed. Even running DOS programs under Win2003 won't require real mode (unless I'm really off as to how the DOS window works).
In short, this is just cruft that would never be used in x86-64 long mode anyway.
It will be almost exactly like what FX!32 does, because that software is no longer "Alpha FX!32", but rather "Intel FX!32". Intel bought pretty much all of the old Alpha technology, software and design teams, as well as the plant that Digital used to build the chips in. This occurred over quite a number of years (starting just before Compaq bought Digital), but this is the first really obvious sign of Intel technology to come out of it.
Why is it that everyone seems to think that it's even remotely useful to get rid of the GUI on a modern server? I keep seeing messages talking about Windows is so bad because you have to run a GUI and can't just sit in a command line.
Now, I'm not saying that there isn't a place for the comamnd line, in fact I find it quite useful and many tasks can be accomplished faster by using a good command line shell rather than a GUI.
What I'm worried about is that people seem to think that a GUI somehow slows down a modern system. Maybe if you're still running a server on a 486 with 4MB of RAM the GUI would be a big problem, but a modern server these days is WAY more powerful! The GUI only takes up a couple of MB of memory, most of it swapped. The amount of processor cycles a GUI takes up on anything beyond about a Pentium 100 is so minute it's completely negligible. Still though, I keep seeing people on Slashdot complaining about all of the overhead of the GUI.
Loading tons of useless services/applications, sure that will bloat your server, and both Linux and Windows suffer from this very badly in most default configurations (though both can be slimmed down significantly). Extra drivers can slow things down, bad settings can slow things down, but a GUI? That's the least of the problems on most systems.
The Opteron has a single 128-bit wide memory controller, rather than the two 64-bit wide memory controllers in some other systems (most notably the nForce/nForce2 chipsets and Intel's i840 and i850 RDRAM chipsets, dunno about the new Intel i865 and i875 chipsets).
There are some potential performance differences that could favor either one design or the other. In general though, the difference is likely to be significantly smaller than anyone will be able to reliably measure.
It may still be possible to run the Athlon64 in dual-processor mode, in much the same way that the Athlon XP can quite easily work in a dual-processor system but doesn't "support" dual processor setups.
The plan with dual-processors setups on the Athlon64/Clawhammer has always been to split it's single 16-bit HyperTransport link and use it as two seperate 8-bit HT links. This would cut your I/O bandwidth in half (might reduce performance in some applications, but the available bandwidth is still pretty good for the price bracket), but dual-processor systems could work.
FWIW it's not possible to do dual-processing with the Athlon64 without doing some pretty tricky/expensive stuff. Such a chipset would be almost as complicated as making chipsets for a 16-processor Opteron server. Long story short: it ain't gonna happen since a dual-Opteron system would be WAY cheaper.
That being said, dual-Opteron systems don't look liek they'll be all that expensive. The chips will probably be available for about $300-$500 a piece (for an Opteron 244, slower Opterons could be cheaper) by the time the Athlon64 makes it to market, and motherboards could easily be down to the $200 range for a workstation board.
Promises to be an interesting standard?! I'd say that it's more of an outdated standard that is sufficient for the task, but could use a bit of refreshing!
PC/104 is hardly new, actually it's been around for a while (initial spec came out in '92), and it's all based around an AT bus (bleah!). Fortunately they already have a replacement, PC/104-Plus, which uses a PCI bus instead of the old AT bus (though it retains backwards compatability). Even that standard has been around for 5 or 6 years though.
The real promising development is not so much the form factor itself, but the modern chips which let us pack a lot of functionality into such a small form factor.
By the time the Athlon64 makes it to market, chipsets should be decent. The Athlon64 and the Opteron use the same chipsets, and AMD has an Opteron chipset coming out in a few days, so they'll have 5 months to iron out any bugs (and early reports are that the chipsets were pretty stable a year ago).
AMD also now has nVidia making chipsets for them, which has signficantly improved the quality of chipsets available IMO. Previously it was mainly just VIA, with SiS throwing in the odd chipset here and there. VIA's solutions were rather weak and the lack of competition meant that there wasn't much insentive to improve them. Now though, not only are nVidia chipsets available and stable, but they're also giving VIA some serious competition which (hopefully) will result in more stable chipsets from both companies.
Ok, maybe I'm being a bit of an optimist here, but the theory is good.
The Athlon64's single-channel controller offers considerably MORE bandwidth than the AthlonXP/nForce's dual-channel memroy controller.
Why? Because the Athlon64 has an on-die memory controller, which means two very important things. First, there is no longer any processor-side bus (or "front-side bus" as it is usually, somewhat inaccurately referred to). The AthlonXP might have had 5GB/s+ of potential bandwidth on the memory bus, but it's limited to 3.2GB/s on the processor side bus (assuming AMD brings out 400MHz bus speed Athlons). The Athlon64 has 3.2GB/s of memory bandwidth straight to the processor.
Second, since the memory is connected straight to the processor, this greatly increases the percentage of your theoretical bandwidth that is actually usuable. That's why in the benchmark numbers the Athlon64 with it's 3.2GB/s of theoretical bandwidth actually comes pretty close to matching the P4-C (800MHz bus speed, dual channel DDR400) with it's 6.4GB/s of theoretical bandwidth.
Besides that, the on-die memory controller offers SIGNIFICANTLY lower latency than any of the off-die memory controllers out there, and latency is often more important for performance than bandwidth.
Of course, if you really want dual-channel DDR, there's always the Opteron 1xx series, which should be quite reasonably priced.
The other enhancements to the chip more than make up for it. In fact, it should typically perform anywhere from 5-25% faster than an equally clocked AthlonXP.
The big downside to a longer pipeline is that it increase the performance penalty of flushing the pipeline after a mispredicted branch. However, AMD did two things here. First the Athlon64 has a better branch predictor than the AthlonXP, which should reduce the number of mispredicted branches. The second thing that AMD did was to change the pipeline slightly so that the extra pipeline stages don't need to be flushed on a missed branch.
FWIW AMD is kind of following Intel's lead in this regard. While the P4 has a VERY long pipeline (twice the length of the Athlons), it doesn't take all that much of a performance hit for a missed branch because they don't need to flush all of their pipeline. The P4 also has excellent branch predictors (second only to the old AMD K6 in the x86 world from what I've seen). That being said, the P4 still has a very long pipeline and very small L1 caches, as well as a number of odd quirks as to what instructions can be where in the pipeline, so the end result tends to be a reduction in the average IPC of the chip vs. the AthlonXP/64.
As for clock speeds, my understanding is that AMD is aiming for the 2.0GHz range when they bring the chip to market.
From a practical standpoint of "What chip to buy", you are quite correct, price/performance is the key factor.
However, in this case neither the Athlon64 or the P4-C (the 800MHz bus speed P4s) are actually available for sale, so the test is rather academic to begin with. In this case a 1.6GHz P4 might have been interesting to compare against.
Umm, I'm going to give you the benefit of the doubt and assume that you didn't read the article too closely. To quote directly from the article though:
<quote> In our test session we will compare Athlon 64 2800+ with the following processors: [...] Pentium 4 2.8C GHz processor. This CPU working with 800MHz bus and supporting Hyper-Threading technology <end quote>
I would STRONLY second the above suggestion! I'm working in a spam-fighting company right now, so I see a ton of spam. I'd guess that somewhere between 30 and 40% of all spam does exactly what the above poster is talking about, sending back a user-id or e-mail address attached to a remote image URL. Just opening that URL to grab the image will let the spammers know that they've got a live one.
If you have remote image loading in email turned on, it doesn't matter too much what else you do, you're going to start getting a LOT more spam in the future.
On a slightly more serious note though, the place were your e-mail address is harvested from definitely seems to have an effect on the sort of spam you receive. On my old (now abandoned) e-mail account, I used to get TONS of Chinese spam (not overly effective since I can't even display the character set, let alone read the messages!), while most of my friends (using the same server at our university) hardly got any. On the other hand, I rarely got any penis enlargement spams and significantly less porn spam then they did.
The difference? My friends mostly had their addresses either harvested from websites or commercial mailing lists, as well as some alt.* newsgroups. My e-mail, on the other hand, was mostly harvested from comp.* newsgroups.
Raiding hotmail wouldn't do any good, there is essentially no spam ever sent from their servers. There might be the odd person that tries (and fails) to send spam from Hotmail, but that would make up less then 0.001% of all spam sent.
However, a HUGE quantity of spam is sent with false hotmail address in the From: line. Many spammers also falsify a variety of other headers (like the Received: lines and Message-IDs) to make the message look like they're from Hotmail. If you know what you're looking for though, you'll find that none of these actually come from Hotmail at all.
As for the spam received by Hotmail, it is HUGE. Hotmail gets more spam sent to their servers than any other company or orginisation in the world. Every day Hotmail gets between 2 and 2.5 billion spam messages. A very significant portion of this is filtered out before any users ever see it. Still, like the original poster, many people receive a LOT of spam that has got past the filters.
I think you hit the proverbial nail on the head there.
I'm working for a spam-blocking company, so I see a LOT of spam. I see basically two types of spammers. The first are just like what you describe, people who get suckered into sending the stuff and never make any money off it.
The other type are the well known spammers, who don't ever actually sell anything themselves, but makes TONS of cash sending spam for companies looking to sell things.
For the most part I suspect that people trying to sell products via spam aren't making much, if any money at all. Even the majority of complete morons recognize the fact that penis-enlargement pills probably aren't going to work, and if they're dumb enough to buy these pills once, they certainly aren't likely to be repeat customers!
There are a few places that might make some money, most notably are some of the porn spammers. For the most part though, I think that you're right in that most people trying to sell their crap by sending spam are, first off, VERY dumb people, and secondly they don't make any money off it.
Fortunately the low average intelligence of spammers sometimes makes the job of filtering spam somewhat easier. Often the things that spammers do in an effort to avoid spam filters actually makes their junk easier to filter rather than harder!
Double the FPU if you use SpecFP using Sun's newest compiler, but only if you look at the overall score. Look at the individual benchmarks, the Sparcs are really lackluster performers EXCEPT in 179.art. This is because Sun managed to find a new optimization in their compiler that is letting them absolutely DESTROY every other processor out there in that ONE test.
If you look at SpecINT, it's a lackluster performer, and if you look at every SpecFP benchmarket other than 179.art it's not much better.
I understand a 64bit cpu has.. more "bits" at it's disposal to calculate and therefore some calculations will be much faster due to a single calculation or not having to "trick' it's way round a mathematical computation.....
This is true, but it's quite rare. 32-bit integers give you a range of 4 billion, which is usually more than enough for calculations, however there are some situations where it's not (cryptography is one that jumps to mind). This was a much bigger issue in the change from 16-bits to 32-bit chips. Floating point calculations are almost always done in 64-bits, even on "32-bit" processors.
I understand it can address more memory also.
This is the real reason for going to a 64-bit chip. A 32-bit processor can only address 4GB of memory without resorting to some REALLY UGLY hacks. A 64-bit chip can access some rather ridiculously large amount of memory (1.8 x 10^19 if memroy serves).
but what about the ways in which we speak to the cpu / entire system?
This is more or less independant of the processor core. Every x86 chip since the Pentium has used a 64-bit bus for talking to the rest of the system. The Opteron actually changes this around quite dramatically, using two separate buses. The Opteron has a built-in memory controller to talk directly to memory (the vast majority of I/O traffic for a CPU) and than one or more other buses using AMD's new Hypertransport technology to talk to other CPUs and/or I/O devices.
do we need a "64bit" pci slot? will that help - will it only help due to increased bandwidth on the PCI slot or will a 32bit pci slot
64-bit PCI slots as well as the newer PCI-X slots do offer more bandwidth for I/O, particularly useful on servers for things like RAID cards and gigabit ethernet. However, you definitely don't need a 64-bit chip to use these, you can get 64-bit PCI slots or PCI-X slots on existing AthlonMP or Xeon motherboards.
does a 64bit exe file contain more lines of code,....... does it contain more physical datA?
No and maybe. A 64-bit exe file should contain the same or fewer lines of code, however the address pointers will be 64-bits rather than 32-bits, so it will contain more data. Integers may also be 64-bits instead of just 32, but as mentioned above, this is rarely needed and therefore the default is to keep them at just 32-bits.
do we need a different file system
Not at all. Filesystems already use 64-bit integers when they are needed (they are needed occasionally). For a 32-bit chip, these are hacked as 2 32-bit integers, with a 64-bit chip, they can be done as a single 64-bit one, but otherwise everything remains unchanged.
I guess I should remember that even 32bit boards had 8bit isa slots......... but they slowed the machine down in general when being accessed right?)
This was simply a matter of using ISA. ISA was the most bass-ackwards, poorly designed piece of crap bus ever to see the light of day. Using ISA always slowed the system down, but when it first came out everythign else was so slow that this wasn't a big issue. Once we got 32-bit chips, this had become a major problem, which is why IBM tried unsuccessfully to kill ISA when the 386 came out. Of course, the market didn't bite until 5+ years later when PCI came out, and even then ISA still kept rearing it's ugly head every now and then. Fortunately no current bus is anywhere near as broken as ISA.
No need to guess, AMD already paid their dues to Microsoft. Jerry Sanders (founder and former CEO of AMD) testified in favor of Microsoft in their anti-trust trial. Well, to be fair, AMD claims that this was not to encourage Microsoft to port to x86-64, but it certainly did seem like it at the time.
unless you make tricky optimizations, like packing 32-bit variables into a single 64-bit register and doing operations on them simultaneously (which, in general, isn't that useful, BTW).
Don't tell that to Intel and AMD! Or Apple, Motorola and IBM for that matter! What you just described is called SIMD, and it's exactly what MMX, 3DNow!, SSE, Altivec, etc. are designed to do!
The graphics bus is completely independant of the processor used. AGP could work just as well with a 16-bit chip as with a 64-bit chip.
Right now, AGP is a 32-bit wide bus, running at 66MHz, using either quad or 8-time (octal?) data rate, giving it 1.07 or 2.13GB/s of bandwidth. This is quite a lot of bandwidth, not likely to be saturated by graphics cards any time soon (especailly since the VAST majority of bandwidth with graphics comes from the memory on the card).
Now, that being said, AMD does have a rather neat technology to go along with their Opteron called Hypertransport. This is a chip-to-chip interconnect technology that offers high bandwidth per pin and a very flexible interface. In the case of the Opteron and Athlon64, AMD will have between 1 and 3 Hypertransport links, used for either connecting multiple processors or connecting to I/O chips (like an AGP controller) on the motherboard. The Hypertransport links in these chips offer up to 3.2GB/s of bandwidth in each direction.
As for next generation buses to replace AGP, there isn't much of a need for this right now, AGP isn't a bottleneck at this point in time, and isn't likely to be in the near future. However, there are some replacements for PCI on the horizon, mainly the existing PCI-X standard (common in servers now, moving down into the workstation market and possible even to the desktop soon), and the next-generation PCI Express (formerly known by about 15 other names, most notably 3GIO). AMD already has a PCI-X Hypertransport tunnel available, and a PCI Express Hypertransport tunnel is possible for the future.
FWIW if you look at most of the first Opteron motherboard you won't see any AGP slots because they are using the PCI-X tunnel instead of the AGP tunnel. Under the right setup, you can use both tunnels on one board easily, but for the first boards it will be either one or the other.
Sun's chips only scale to 4-way SMP all on their own, beyond that it's all interconnect and, more imporantly, software.
AMD's Opteron's scale to 8-way SPM on their own, and AMD's Hypertransport gives them a lot more interconnect bandwidth than Sun's FirePlane.
That's not to say that anyone WILL build a system with 106 Opteron chips, but these chips could, theoretically, scale better than UltraSparc chips do. If someone where to design a system to get all of the chips working together and than get an operating system that will scale well to a large NUMA system, it could be done.
I can actually picture Opterons working fairly well at up to 64 CPUs. Simply take a system with 8 blocks (8 processors each) in the same sort of configuration as an 8-processor Opteron system (slightly tough to explain without the use of diagrams, so I'm not even going to try!:> ).
Is it just me, or are those jokes about AMD chips running hot getting kind of tired? Especially consider that they haven't run hotter than Intel for some time now, and don't come close to touching the power consumption of Power4 or Itanium chips?
For those who are wondering, AMD's top-end Athlons consume on the order of 60-70W Intel's top-end P4's consume 90-100W IBM's Power4 chips are somewhere around 110W Intel Itanium chips top out at 130W
In a related line: the reason why Sun chose to use AMD's chips in their x86 blade servers instead of Intel chips is because the AMD chips used less power/ran cooler than their Intel counterparts (though with the release of the Pentium M, this is no longer the case).
I'm sorry, what machine kicks a Sun SPARC's butt in the apps they give a damn about? I don't think Sun cares if your Intel box gets more fps in Quake3 than a SPARC.
When it comes to raw number crunching, SPARC chips are terrible. They can now manage to beat PIIIs most of the time, and even the newer Celerons sometimes, but they're well behind the latest AthlonXP or P4 in terms of processing performance.
However, what Sun does have is great software support, great supporting hardware that gives their processors tons of I/O bandwidth, the ability to scale very well to a large number of processors and the customer and sales support to bring this all together. That's something that neither AMD or Intel can touch (or anyone else for that matter except for perhaps IBM).
Still, despite all that, Sun has to do something if they plan to keep Sparc around for too much longer. They used to have top-notch processors, but now their chips are average at best. They're also seriously suffering from being almost a whole manufacturing process generation behind their competition.
The performance of these chips would be nice, but the power consumption is too high.
What I want is a Mini-ITX form factor board using an Intel chipset and a Pentium M processor. Much better performance than the VIA chips but still with the low power consumption (a 900MHz or 1GHz Pentium M should be able to work with only passive cooling).
Now, obviously such a product isn't going to come from VIA, and it will undoubtably cost more than the current offerings, but it would make for quite a nice little box (and one that would, hopefully, be reasonably well supported in Linux too).
The problem with those Packard Hell systems wasn't so much that everything was soldered on board, it was that everything that was soldered on board was complete and utter SHIT!
When all the components that are integrated are of sufficient quality that you don't really worry about upgrading them for the specific tasks, it's not that much of a disadvantage, but with the Packard Hells, their on-board stuff was total crap (as was everything else with their systems). Now, that's not to say that everything in these VIA boards is of good quality, I haven't used one so I can't really comment much one way or the other.
The other real big difference between the old Packard Hell's and these VIA systems is that the Packard Bells cost about $1500, while the VIA Mini-ITX systems can be had for $150. That means that upgradability really isn't that big of an issue (want to upgrade? throw out the old board/processor and buy a new one).
Slashdot Mirror
You might want to read over those tech-docs again, or more specifically the "AMD64 Architecture Programmer's Manual Volume 1:", in section 1.2: Modes of Operation.
<quoting sub-section 1.2.3>
Compatibility mode--the second submode of long mode--allows 64-bit operating systems to run existing 16-bit and 32-bit x86 applications.
<end quote>
However, I think what you're looking for is a little earlier in the section.
<quoting sub-section 1.2.1>
Long mode does not support legacy real mode or legacy virtual-8086 mode, and it does not support hardware task switching.
<end quote>
Now, this may seem like a bit of a loss, since DOS was run in real mode, and Linux 1.xx made use of the hardware task switching, but neither of these operating systems are ever going to run in Long mode on an x86 chip since they're both long since being EOLed. Even running DOS programs under Win2003 won't require real mode (unless I'm really off as to how the DOS window works).
In short, this is just cruft that would never be used in x86-64 long mode anyway.
It will be almost exactly like what FX!32 does, because that software is no longer "Alpha FX!32", but rather "Intel FX!32". Intel bought pretty much all of the old Alpha technology, software and design teams, as well as the plant that Digital used to build the chips in. This occurred over quite a number of years (starting just before Compaq bought Digital), but this is the first really obvious sign of Intel technology to come out of it.
Why is it that everyone seems to think that it's even remotely useful to get rid of the GUI on a modern server? I keep seeing messages talking about Windows is so bad because you have to run a GUI and can't just sit in a command line.
Now, I'm not saying that there isn't a place for the comamnd line, in fact I find it quite useful and many tasks can be accomplished faster by using a good command line shell rather than a GUI.
What I'm worried about is that people seem to think that a GUI somehow slows down a modern system. Maybe if you're still running a server on a 486 with 4MB of RAM the GUI would be a big problem, but a modern server these days is WAY more powerful! The GUI only takes up a couple of MB of memory, most of it swapped. The amount of processor cycles a GUI takes up on anything beyond about a Pentium 100 is so minute it's completely negligible. Still though, I keep seeing people on Slashdot complaining about all of the overhead of the GUI.
Loading tons of useless services/applications, sure that will bloat your server, and both Linux and Windows suffer from this very badly in most default configurations (though both can be slimmed down significantly). Extra drivers can slow things down, bad settings can slow things down, but a GUI? That's the least of the problems on most systems.
The Opteron has a single 128-bit wide memory controller, rather than the two 64-bit wide memory controllers in some other systems (most notably the nForce/nForce2 chipsets and Intel's i840 and i850 RDRAM chipsets, dunno about the new Intel i865 and i875 chipsets).
There are some potential performance differences that could favor either one design or the other. In general though, the difference is likely to be significantly smaller than anyone will be able to reliably measure.
It may still be possible to run the Athlon64 in dual-processor mode, in much the same way that the Athlon XP can quite easily work in a dual-processor system but doesn't "support" dual processor setups.
The plan with dual-processors setups on the Athlon64/Clawhammer has always been to split it's single 16-bit HyperTransport link and use it as two seperate 8-bit HT links. This would cut your I/O bandwidth in half (might reduce performance in some applications, but the available bandwidth is still pretty good for the price bracket), but dual-processor systems could work.
FWIW it's not possible to do dual-processing with the Athlon64 without doing some pretty tricky/expensive stuff. Such a chipset would be almost as complicated as making chipsets for a 16-processor Opteron server. Long story short: it ain't gonna happen since a dual-Opteron system would be WAY cheaper.
That being said, dual-Opteron systems don't look liek they'll be all that expensive. The chips will probably be available for about $300-$500 a piece (for an Opteron 244, slower Opterons could be cheaper) by the time the Athlon64 makes it to market, and motherboards could easily be down to the $200 range for a workstation board.
Promises to be an interesting standard?! I'd say that it's more of an outdated standard that is sufficient for the task, but could use a bit of refreshing!
PC/104 is hardly new, actually it's been around for a while (initial spec came out in '92), and it's all based around an AT bus (bleah!). Fortunately they already have a replacement, PC/104-Plus, which uses a PCI bus instead of the old AT bus (though it retains backwards compatability). Even that standard has been around for 5 or 6 years though.
The real promising development is not so much the form factor itself, but the modern chips which let us pack a lot of functionality into such a small form factor.
By the time the Athlon64 makes it to market, chipsets should be decent. The Athlon64 and the Opteron use the same chipsets, and AMD has an Opteron chipset coming out in a few days, so they'll have 5 months to iron out any bugs (and early reports are that the chipsets were pretty stable a year ago).
AMD also now has nVidia making chipsets for them, which has signficantly improved the quality of chipsets available IMO. Previously it was mainly just VIA, with SiS throwing in the odd chipset here and there. VIA's solutions were rather weak and the lack of competition meant that there wasn't much insentive to improve them. Now though, not only are nVidia chipsets available and stable, but they're also giving VIA some serious competition which (hopefully) will result in more stable chipsets from both companies.
Ok, maybe I'm being a bit of an optimist here, but the theory is good.
The Athlon64's single-channel controller offers considerably MORE bandwidth than the AthlonXP/nForce's dual-channel memroy controller.
Why? Because the Athlon64 has an on-die memory controller, which means two very important things. First, there is no longer any processor-side bus (or "front-side bus" as it is usually, somewhat inaccurately referred to). The AthlonXP might have had 5GB/s+ of potential bandwidth on the memory bus, but it's limited to 3.2GB/s on the processor side bus (assuming AMD brings out 400MHz bus speed Athlons). The Athlon64 has 3.2GB/s of memory bandwidth straight to the processor.
Second, since the memory is connected straight to the processor, this greatly increases the percentage of your theoretical bandwidth that is actually usuable. That's why in the benchmark numbers the Athlon64 with it's 3.2GB/s of theoretical bandwidth actually comes pretty close to matching the P4-C (800MHz bus speed, dual channel DDR400) with it's 6.4GB/s of theoretical bandwidth.
Besides that, the on-die memory controller offers SIGNIFICANTLY lower latency than any of the off-die memory controllers out there, and latency is often more important for performance than bandwidth.
Of course, if you really want dual-channel DDR, there's always the Opteron 1xx series, which should be quite reasonably priced.
The other enhancements to the chip more than make up for it. In fact, it should typically perform anywhere from 5-25% faster than an equally clocked AthlonXP.
The big downside to a longer pipeline is that it increase the performance penalty of flushing the pipeline after a mispredicted branch. However, AMD did two things here. First the Athlon64 has a better branch predictor than the AthlonXP, which should reduce the number of mispredicted branches. The second thing that AMD did was to change the pipeline slightly so that the extra pipeline stages don't need to be flushed on a missed branch.
FWIW AMD is kind of following Intel's lead in this regard. While the P4 has a VERY long pipeline (twice the length of the Athlons), it doesn't take all that much of a performance hit for a missed branch because they don't need to flush all of their pipeline. The P4 also has excellent branch predictors (second only to the old AMD K6 in the x86 world from what I've seen). That being said, the P4 still has a very long pipeline and very small L1 caches, as well as a number of odd quirks as to what instructions can be where in the pipeline, so the end result tends to be a reduction in the average IPC of the chip vs. the AthlonXP/64.
As for clock speeds, my understanding is that AMD is aiming for the 2.0GHz range when they bring the chip to market.
From a practical standpoint of "What chip to buy", you are quite correct, price/performance is the key factor.
However, in this case neither the Athlon64 or the P4-C (the 800MHz bus speed P4s) are actually available for sale, so the test is rather academic to begin with. In this case a 1.6GHz P4 might have been interesting to compare against.
Umm, I'm going to give you the benefit of the doubt and assume that you didn't read the article too closely. To quote directly from the article though:
<quote>
In our test session we will compare Athlon 64 2800+ with the following processors:
[...]
Pentium 4 2.8C GHz processor. This CPU working with 800MHz bus and supporting Hyper-Threading technology
<end quote>
I would STRONLY second the above suggestion! I'm working in a spam-fighting company right now, so I see a ton of spam. I'd guess that somewhere between 30 and 40% of all spam does exactly what the above poster is talking about, sending back a user-id or e-mail address attached to a remote image URL. Just opening that URL to grab the image will let the spammers know that they've got a live one.
If you have remote image loading in email turned on, it doesn't matter too much what else you do, you're going to start getting a LOT more spam in the future.
For sure!
On a slightly more serious note though, the place were your e-mail address is harvested from definitely seems to have an effect on the sort of spam you receive. On my old (now abandoned) e-mail account, I used to get TONS of Chinese spam (not overly effective since I can't even display the character set, let alone read the messages!), while most of my friends (using the same server at our university) hardly got any. On the other hand, I rarely got any penis enlargement spams and significantly less porn spam then they did.
The difference? My friends mostly had their addresses either harvested from websites or commercial mailing lists, as well as some alt.* newsgroups. My e-mail, on the other hand, was mostly harvested from comp.* newsgroups.
Raiding hotmail wouldn't do any good, there is essentially no spam ever sent from their servers. There might be the odd person that tries (and fails) to send spam from Hotmail, but that would make up less then 0.001% of all spam sent.
However, a HUGE quantity of spam is sent with false hotmail address in the From: line. Many spammers also falsify a variety of other headers (like the Received: lines and Message-IDs) to make the message look like they're from Hotmail. If you know what you're looking for though, you'll find that none of these actually come from Hotmail at all.
As for the spam received by Hotmail, it is HUGE. Hotmail gets more spam sent to their servers than any other company or orginisation in the world. Every day Hotmail gets between 2 and 2.5 billion spam messages. A very significant portion of this is filtered out before any users ever see it. Still, like the original poster, many people receive a LOT of spam that has got past the filters.
I think you hit the proverbial nail on the head there.
I'm working for a spam-blocking company, so I see a LOT of spam. I see basically two types of spammers. The first are just like what you describe, people who get suckered into sending the stuff and never make any money off it.
The other type are the well known spammers, who don't ever actually sell anything themselves, but makes TONS of cash sending spam for companies looking to sell things.
For the most part I suspect that people trying to sell products via spam aren't making much, if any money at all. Even the majority of complete morons recognize the fact that penis-enlargement pills probably aren't going to work, and if they're dumb enough to buy these pills once, they certainly aren't likely to be repeat customers!
There are a few places that might make some money, most notably are some of the porn spammers. For the most part though, I think that you're right in that most people trying to sell their crap by sending spam are, first off, VERY dumb people, and secondly they don't make any money off it.
Fortunately the low average intelligence of spammers sometimes makes the job of filtering spam somewhat easier. Often the things that spammers do in an effort to avoid spam filters actually makes their junk easier to filter rather than harder!
Double the FPU if you use SpecFP using Sun's newest compiler, but only if you look at the overall score. Look at the individual benchmarks, the Sparcs are really lackluster performers EXCEPT in 179.art. This is because Sun managed to find a new optimization in their compiler that is letting them absolutely DESTROY every other processor out there in that ONE test.
If you look at SpecINT, it's a lackluster performer, and if you look at every SpecFP benchmarket other than 179.art it's not much better.
I understand a 64bit cpu has .. more "bits" at it's disposal to calculate and therefore some calculations will be much faster due to a single calculation or not having to "trick' it's way round a mathematical computation.....
This is true, but it's quite rare. 32-bit integers give you a range of 4 billion, which is usually more than enough for calculations, however there are some situations where it's not (cryptography is one that jumps to mind). This was a much bigger issue in the change from 16-bits to 32-bit chips. Floating point calculations are almost always done in 64-bits, even on "32-bit" processors.
I understand it can address more memory also.
This is the real reason for going to a 64-bit chip. A 32-bit processor can only address 4GB of memory without resorting to some REALLY UGLY hacks. A 64-bit chip can access some rather ridiculously large amount of memory (1.8 x 10^19 if memroy serves).
but what about the ways in which we speak to the cpu / entire system?
This is more or less independant of the processor core. Every x86 chip since the Pentium has used a 64-bit bus for talking to the rest of the system. The Opteron actually changes this around quite dramatically, using two separate buses. The Opteron has a built-in memory controller to talk directly to memory (the vast majority of I/O traffic for a CPU) and than one or more other buses using AMD's new Hypertransport technology to talk to other CPUs and/or I/O devices.
do we need a "64bit" pci slot? will that help - will it only help due to increased bandwidth on the PCI slot or will a 32bit pci slot
64-bit PCI slots as well as the newer PCI-X slots do offer more bandwidth for I/O, particularly useful on servers for things like RAID cards and gigabit ethernet. However, you definitely don't need a 64-bit chip to use these, you can get 64-bit PCI slots or PCI-X slots on existing AthlonMP or Xeon motherboards.
does a 64bit exe file contain more lines of code,....... does it contain more physical datA?
No and maybe. A 64-bit exe file should contain the same or fewer lines of code, however the address pointers will be 64-bits rather than 32-bits, so it will contain more data. Integers may also be 64-bits instead of just 32, but as mentioned above, this is rarely needed and therefore the default is to keep them at just 32-bits.
do we need a different file system
Not at all. Filesystems already use 64-bit integers when they are needed (they are needed occasionally). For a 32-bit chip, these are hacked as 2 32-bit integers, with a 64-bit chip, they can be done as a single 64-bit one, but otherwise everything remains unchanged.
I guess I should remember that even 32bit boards had 8bit isa slots......... but they slowed the machine down in general when being accessed right?)
This was simply a matter of using ISA. ISA was the most bass-ackwards, poorly designed piece of crap bus ever to see the light of day. Using ISA always slowed the system down, but when it first came out everythign else was so slow that this wasn't a big issue. Once we got 32-bit chips, this had become a major problem, which is why IBM tried unsuccessfully to kill ISA when the 386 came out. Of course, the market didn't bite until 5+ years later when PCI came out, and even then ISA still kept rearing it's ugly head every now and then. Fortunately no current bus is anywhere near as broken as ISA.
No need to guess, AMD already paid their dues to Microsoft. Jerry Sanders (founder and former CEO of AMD) testified in favor of Microsoft in their anti-trust trial. Well, to be fair, AMD claims that this was not to encourage Microsoft to port to x86-64, but it certainly did seem like it at the time.
Here's a story about it.
unless you make tricky optimizations, like packing 32-bit variables into a single 64-bit register and doing operations on them simultaneously (which, in general, isn't that useful, BTW).
Don't tell that to Intel and AMD! Or Apple, Motorola and IBM for that matter! What you just described is called SIMD, and it's exactly what MMX, 3DNow!, SSE, Altivec, etc. are designed to do!
The graphics bus is completely independant of the processor used. AGP could work just as well with a 16-bit chip as with a 64-bit chip.
Right now, AGP is a 32-bit wide bus, running at 66MHz, using either quad or 8-time (octal?) data rate, giving it 1.07 or 2.13GB/s of bandwidth. This is quite a lot of bandwidth, not likely to be saturated by graphics cards any time soon (especailly since the VAST majority of bandwidth with graphics comes from the memory on the card).
Now, that being said, AMD does have a rather neat technology to go along with their Opteron called Hypertransport. This is a chip-to-chip interconnect technology that offers high bandwidth per pin and a very flexible interface. In the case of the Opteron and Athlon64, AMD will have between 1 and 3 Hypertransport links, used for either connecting multiple processors or connecting to I/O chips (like an AGP controller) on the motherboard. The Hypertransport links in these chips offer up to 3.2GB/s of bandwidth in each direction.
As for next generation buses to replace AGP, there isn't much of a need for this right now, AGP isn't a bottleneck at this point in time, and isn't likely to be in the near future. However, there are some replacements for PCI on the horizon, mainly the existing PCI-X standard (common in servers now, moving down into the workstation market and possible even to the desktop soon), and the next-generation PCI Express (formerly known by about 15 other names, most notably 3GIO). AMD already has a PCI-X Hypertransport tunnel available, and a PCI Express Hypertransport tunnel is possible for the future.
FWIW if you look at most of the first Opteron motherboard you won't see any AGP slots because they are using the PCI-X tunnel instead of the AGP tunnel. Under the right setup, you can use both tunnels on one board easily, but for the first boards it will be either one or the other.
Sun's chips only scale to 4-way SMP all on their own, beyond that it's all interconnect and, more imporantly, software.
:> ).
AMD's Opteron's scale to 8-way SPM on their own, and AMD's Hypertransport gives them a lot more interconnect bandwidth than Sun's FirePlane.
That's not to say that anyone WILL build a system with 106 Opteron chips, but these chips could, theoretically, scale better than UltraSparc chips do. If someone where to design a system to get all of the chips working together and than get an operating system that will scale well to a large NUMA system, it could be done.
I can actually picture Opterons working fairly well at up to 64 CPUs. Simply take a system with 8 blocks (8 processors each) in the same sort of configuration as an 8-processor Opteron system (slightly tough to explain without the use of diagrams, so I'm not even going to try!
Is it just me, or are those jokes about AMD chips running hot getting kind of tired? Especially consider that they haven't run hotter than Intel for some time now, and don't come close to touching the power consumption of Power4 or Itanium chips?
For those who are wondering, AMD's top-end Athlons consume on the order of 60-70W
Intel's top-end P4's consume 90-100W
IBM's Power4 chips are somewhere around 110W
Intel Itanium chips top out at 130W
In a related line: the reason why Sun chose to use AMD's chips in their x86 blade servers instead of Intel chips is because the AMD chips used less power/ran cooler than their Intel counterparts (though with the release of the Pentium M, this is no longer the case).
I'm sorry, what machine kicks a Sun SPARC's butt in the apps they give a damn about? I don't think Sun cares if your Intel box gets more fps in Quake3 than a SPARC.
When it comes to raw number crunching, SPARC chips are terrible. They can now manage to beat PIIIs most of the time, and even the newer Celerons sometimes, but they're well behind the latest AthlonXP or P4 in terms of processing performance.
However, what Sun does have is great software support, great supporting hardware that gives their processors tons of I/O bandwidth, the ability to scale very well to a large number of processors and the customer and sales support to bring this all together. That's something that neither AMD or Intel can touch (or anyone else for that matter except for perhaps IBM).
Still, despite all that, Sun has to do something if they plan to keep Sparc around for too much longer. They used to have top-notch processors, but now their chips are average at best. They're also seriously suffering from being almost a whole manufacturing process generation behind their competition.
The performance of these chips would be nice, but the power consumption is too high.
What I want is a Mini-ITX form factor board using an Intel chipset and a Pentium M processor. Much better performance than the VIA chips but still with the low power consumption (a 900MHz or 1GHz Pentium M should be able to work with only passive cooling).
Now, obviously such a product isn't going to come from VIA, and it will undoubtably cost more than the current offerings, but it would make for quite a nice little box (and one that would, hopefully, be reasonably well supported in Linux too).
The problem with those Packard Hell systems wasn't so much that everything was soldered on board, it was that everything that was soldered on board was complete and utter SHIT!
When all the components that are integrated are of sufficient quality that you don't really worry about upgrading them for the specific tasks, it's not that much of a disadvantage, but with the Packard Hells, their on-board stuff was total crap (as was everything else with their systems). Now, that's not to say that everything in these VIA boards is of good quality, I haven't used one so I can't really comment much one way or the other.
The other real big difference between the old Packard Hell's and these VIA systems is that the Packard Bells cost about $1500, while the VIA Mini-ITX systems can be had for $150. That means that upgradability really isn't that big of an issue (want to upgrade? throw out the old board/processor and buy a new one).