Athlon64 3000+: 64-bit at Half the Price

75 Comments

View All Comments

• TrogdorJW - Wednesday, December 24, 2003 - link

  And as for Pumpkinierre's comments about the PR ratings, I hate to do it, but I agree with him. They suck! Like, black-hole suckage! Only problem is, there really isn't a good way to fix them.
  
  The fact of the matter is that in any given architecture, more MHz is pretty much always faster (although not necessarily by a large amount). So while the Pentium 4 1.4 GHz chips really weren't much better than the P3 1.0 GHz, once we get to 2.0 GHz and above, there's no real comparison. Also, the various changes to the chipsets and cache sizes made P4 a real winner in the long term. I'm still running a P3, and trust me, it really stinks!
  
  For the educated market (most of the people reading Anandtech, ArsTechnica, Tom's Hardware Guide, HardOCP, etc.), the PR ratings are pretty much meaningless. At least, I *HOPE* they are. We all know that there's more to a system than a fast processor. Not so for the more typical customer... the PR ratings are either a good way of equating performance, or in some instances, they're a great way to make a sale.
  
  If AMD actually got realistic benchmarks out to all the people, most still wouldn't have a clue what to make of them. And the funny thing is, if you go into many computer stores, the advantage is really in AMD's favor with their PR scheme. I have heard many salespeople say something like, "Oh, the 3200+ AMD system is just as fast as a Pentium 4 3.2 GHz, and it costs less," which is a bold-faced lie. But it has closed many a sale, I'll wager, and so it continues.
  
  Intersting to note that while Intel certainly pushes clock speeds, they really aren't making any unsubstantiated claims. (Well, they are, but no more than anyone else...) And you don't see Intel trying to tell people that a Celeron 2.8 GHz is a better CPU than a 2.0A GHz Pentium 4 (which it isn't!), because they know that clock speeds are only part of the story. That's why we get great marketing speak like "FSB800", "Quad-pumped", "Dual-channel", "HyperThreading", and so on. And the fact is that pretty much every one of those items does indeed tie in to performance benefits. Intel just doesn't bother to try to explain to the simpletons of the world exactly how MUCH of an impact each technology has. ;)
  
  

• TrogdorJW - Wednesday, December 24, 2003 - link

  Larger caches DO cause some increase in latency. Basically, you have more circuitry and such to go through. However, the real penalty can be seen quite clearly: The 512 KB cache CPU beats the 1 MB cache CPU by an AMAZING two clock cycles. Or, since we're talking 90 cycle compared to 92 cycles, it wins by 2.2%!!!!!!!
  
  Wow, that's so significant that I think I need even more exclamation points to prove the importance of that win: !!!!!!!!!!!!!
  
  Okay, so we see an overall decrease in latency of 2%. Compared to the P4 where it only has latencies that are 58.7% lower. And we can see that where low latency is important, the A64 definitely gains an advantage over the P4. But overall, a miniscule difference in memory latencies isn't going to matter in most benchmarks. The remaining tests bear this fact out.
  
  The question about benches in 64-bit is an interesting one, however. Code that's twice as large will need twice as much cache to maintain parity with a 32-bit core. I think the 1 MB cache version will outperform the 512 KB version by a larger margine in 64-bit, but larger than "almost no difference" may not be that large. :)

• KF - Wednesday, December 24, 2003 - link

  >wrong data can be purged and refreshed within the average computational cycle.
  
  Wrong (unneeded?) data is not purged.It is overwritten. Therefore no time is used to purge wrong data.
  
  I don't know where you got this from.It would be like saying the data on hard drive had to be erased before you could reuse a sector. Not true.
  
  The only thing I know of that could make a larger cache slower is that the tag comparitor that does the comparison of addresses (tags) with an extra bit could have a longer propagation delay.
  
  Sorry about the multiple posts. I don't know what I'm doing to cause this. IE just jumped away as I was typing and I saw multiple copies of the partially done message come up.
  
  
  

• KF - Wednesday, December 24, 2003 - link

  >If the cache is too small it starves the cpu, if too big it causes lag
  
  A bigger cach does not cause any lag.
  
  >wrong data can be purged and refreshed within the average computational cycle.

• Pumpkinierre - Tuesday, December 23, 2003 - link

  "There are no instances where a larger cache will noticably slow down a computer. There are many instances where it will noticably speed it up"
  
  #37 Its difficult to understand your statement when this very article shows a 512K A64 beating a 1 Mb A64 on memory latency. If it was the mobos as you say, at the very least it shows that cache size has no effect on memory latency. Yes, if you run 5-10 apps at the same time you need a large cache. But gamers dont do this - they run one app.(the game) to maximise CPU power. Yes I agree with better prediction algorithms and compilation etc. but these are only of use if the task is predictive. Gaming is not predictive and some of these optimisations could in fact hinder this application. Cache is a middle man and as a consequence suffers a delay. The ideal system is the memory running at CPU speed with memory addresses buffered in the CPU(ie cached memory)no L1 or L2 cache. In the real world the large differencer betweeen cpu and memory speed make caches useful. For 3Dgaming the cache must minimise system latency. If the cache is too small it starves the cpu, if too big it causes lag. For gaming the ideal cache would be optimal in size and running faster than the cpu so that wrong data can be purged and refreshed within the average computational cycle. The k8 lends itself to this low latency development with its on die mem. controller and single bridge(nf150) mobo design but AMD have changed their direction- servers, multi-tasking, heavy caches, big dies, costly.
  
  As for the rating system you couldnt have brought up a better example than the Cyrix/IBM ratings of long ago to show AMD what not to do. They were a total farce, again the rating not reflecting the truth, and customers including myself avoided them in droves.

• RZaakir - Tuesday, December 23, 2003 - link

  #38. It shuts down like the Athlon XP has been doing for a while now.

• kmmatney - Tuesday, December 23, 2003 - link

  So what happens if you pull off the HSF with the Athlon 64? Does the cpu fry up, or does it shut down with no harm? I recently had a Duron fry up when one of the HSF tabs snapped. off the cpu socket...

• Reflex - Tuesday, December 23, 2003 - link

  #32: The lack of a huge performance difference with larger cache sizes is actually indicative of the fact that most applications are optimized for CPU's with 256kb of L2 cache. As applications start to be compiled to take advantage of the ability to place more instructions in the cache, CPU's that have larger caches will start to pull ahead noticably. Furthermore, larger cache sizes aid in multi-tasking, most of these benchmarks are performed with a single application running at a time, but in reality I often have 5-10 apps running simultaniously. The larger the cache, the more responsive the system will be.
  
  There are no instances where a larger cache will noticably slow down a computer. There are many instances where it will noticably speed it up. Your comment about the motherboards is rediculous: you can 'expect' whatever you like, but the simple fact is that they are made by different manufacturers and experience has shown that there is a large variety of BIOS tweaks that can be done for the AMD64 platform, performance has been going up almost weekly with new BIOS updates, and its likely that that trend will continue. You do not know the differences between the two boards tested, so your statement is pure speculation based on zero evidence and an obvious lack of knowledge of how cache is used by applications(for instance, the prediction tables/algorithms used is FAR more important than the cache size itself).
  
  As for your statement about Mhz, that has also been proven a falsehood. Back in the days of the Pentium, AMD and Cyrix both tried to list their Mhz accuratly with the K5 and 6x86 series. They were both clobbered until they switched to the PR system instead. Unfortunatly they did not maintain pace using this system and discredited the PR system altogether(Cyrix was the worst about it). The average consumer who sees "Athlon64 2.0Ghz 640kb" on a system next to a "Pentium4 3.0Ghz HT" *is* going to assume that the P4 is the better system, even though it performs at a lower level in 90% of the benchmarks out there and costs more money. Labeling their systems this way would be suicide for AMD. I would highly suggest you learn a thing or two about marketing before making such rediculous statements...
  
  #33: Where have you seen otherwise? Certainly not on Anandtech. Also, performance has improved considerably since the release of the A64 and FX due to BIOS updates and tweaks, so your probably seeing that reflected in these later articles appearing. However, even at the start the A64 was an extremely strong performer against the P4 line(and the FX in a league of its own).

• HammerFan - Tuesday, December 23, 2003 - link

  #25, it isn't possible to use an A64 on a socket 940 board, nor is it possible to use an A64FX on a socket 754 board. If it were, AT probably would've used the same board for all 3 CPUs

• arejerjejjerjre - Tuesday, December 23, 2003 - link

  By the way why did they use different motherboards for A64 and A64 FX? Wouldn't it be more accurate to compare those processor with the same motherboard?
  I don't know about you guys but I think soltek isn't as good as asus but that may just be in my head...