Affordable Dual Core from AMD: Athlon 64 X2 3800+
by Anand Lal Shimpi on August 1, 2005 9:36 AM EST- Posted in
- CPUs
For the past couple of months, we've asked, hoped and dreamed for it, and today, AMD is launching it - the $354 Athlon 64 X2 3800+; the first somewhat affordable dual core CPU from AMD.
If necessity is the mother of invention, then the birth of the Athlon 64 X2 3800+ should be no surprise to anyone. In one of their strongest CPU paper-launches ever, AMD put their best foot forward this past May and introduced the Athlon 64 X2 processor. While AMD was late to the desktop dual core game compared to Intel, the Athlon 64 X2 processor had absolutely no problem outperforming Intel's Pentium D. But at the end of the day, despite AMD's clear victory, our recommendations were quite complicated, thanks to one major flaw in AMD's execution: price.
The cheapest dual core Pentium D processor could be had for under $300, yet AMD's cheapest started at $537. Intel was effectively moving the market to dual core, while AMD was only catering to the wealthiest budgets.
The Pentium D 820, running at 2.8GHz and priced at $280, offered the most impressive value that we've seen in a processor in quite some time - if you could properly use the power. Multitaskers and users of multithreaded applications found themselves with the cheapest 2-way workstation processor that they had seen since the SMP Celerons and ABIT's BP6. While Intel satiated our demands for affordable dual core, we knew it wasn't the perfect option. AMD's Athlon 64 X2 was the better overall performer, just at the very wrong price point.
After much pressure from all sides and some very important manufacturing changes, AMD went ahead with the decision to release a cheaper Athlon 64 X2. The decision was made around the time of Computex 2005 and that's when we first heard of the $354 Athlon 64 X2 3800+.
The Athlon 64 X2 3800+ is basically two Athlon 64 3200+ cores stuck together, each running at 2.0GHz and each with its own 512KB L2 cache. This is a full 200MHz lower clock per core than the 4200+, but with the same amount of cache.
The original Athlon 64 X2 (Toledo core) processors all had the same exact specifications:
Update: As many of you have correctly pointed out, the 4200+ and 4600+ were available as both Toledo and Manchester cores. More than half of the Athlon 64 X2's transistor count is spent on cache, which means that if there are going to be any manufacturing defects on the chip, they will more than likely occur in the processor's cache. Born out of that fact, the Toledo based Athlon 64 X2 4600+ and 4200+ were nothing more than 4800/4400+ X2s with too many manufacturing defects; instead of throwing the bad cores away, AMD simply rebranded them and sold them at lower price points. The problem with this approach is that an Athlon 64 X2 4200+ took the same amount of space on a wafer as an Athlon 64 X2 4800+, despite only having half the cache. Thus we have the Manchester core: a core designed from the ground up to only feature a 512KB L2 cache per core.
As manufacturing ramps up, yields improve and it is now possible to actually create a cost-reduced Athlon 64 X2, using the smaller Manchester die - and that's where the Athlon 64 X2 3800+ gets its cost savings.
The transistor count of the 3800+ goes down to 154 million, and the die gets shrunk down to 147 mm2 compared to the 233.2M and 199 mm^2 of its bigger brothers (4800/4400+). The thermal envelope of the new core also dropped from 110W down to 89W, both still lower than Intel's Pentium D or single-core Pentium 4 for that matter.
With a smaller die and lower transistor count, the Athlon 64 X2 3800+ is able to support its $354 price tag.
If necessity is the mother of invention, then the birth of the Athlon 64 X2 3800+ should be no surprise to anyone. In one of their strongest CPU paper-launches ever, AMD put their best foot forward this past May and introduced the Athlon 64 X2 processor. While AMD was late to the desktop dual core game compared to Intel, the Athlon 64 X2 processor had absolutely no problem outperforming Intel's Pentium D. But at the end of the day, despite AMD's clear victory, our recommendations were quite complicated, thanks to one major flaw in AMD's execution: price.
The cheapest dual core Pentium D processor could be had for under $300, yet AMD's cheapest started at $537. Intel was effectively moving the market to dual core, while AMD was only catering to the wealthiest budgets.
The Pentium D 820, running at 2.8GHz and priced at $280, offered the most impressive value that we've seen in a processor in quite some time - if you could properly use the power. Multitaskers and users of multithreaded applications found themselves with the cheapest 2-way workstation processor that they had seen since the SMP Celerons and ABIT's BP6. While Intel satiated our demands for affordable dual core, we knew it wasn't the perfect option. AMD's Athlon 64 X2 was the better overall performer, just at the very wrong price point.
After much pressure from all sides and some very important manufacturing changes, AMD went ahead with the decision to release a cheaper Athlon 64 X2. The decision was made around the time of Computex 2005 and that's when we first heard of the $354 Athlon 64 X2 3800+.
The Athlon 64 X2 3800+ is basically two Athlon 64 3200+ cores stuck together, each running at 2.0GHz and each with its own 512KB L2 cache. This is a full 200MHz lower clock per core than the 4200+, but with the same amount of cache.
Note: The 512KB X2s are available in both 154M and 233M transistor versions.
A New Core
AMD didn't sit on the X2 3800+ just because they were greedy and expected everyone to gobble up the $500+ parts. Instead, today's release is the result of a slightly revised core, codenamed Manchester, specifically designed to cut costs.The original Athlon 64 X2 (Toledo core) processors all had the same exact specifications:
- 233.2M transistorsFor the Athlon 64 X2 4800+ and the 4400+, the shared transistor count and die size made sense. They both were identical from a transistor standpoint, one chip just ran 200MHz faster than the other. But the 4200+ and the 4600+ weren't identical; unlike the 4800/4400+ X2s, the 4200+ and 4600+ only had a 512KB L2 cache per core, not a 1MB L2.
- 199 mm2 die size
- 110W max power
Update: As many of you have correctly pointed out, the 4200+ and 4600+ were available as both Toledo and Manchester cores. More than half of the Athlon 64 X2's transistor count is spent on cache, which means that if there are going to be any manufacturing defects on the chip, they will more than likely occur in the processor's cache. Born out of that fact, the Toledo based Athlon 64 X2 4600+ and 4200+ were nothing more than 4800/4400+ X2s with too many manufacturing defects; instead of throwing the bad cores away, AMD simply rebranded them and sold them at lower price points. The problem with this approach is that an Athlon 64 X2 4200+ took the same amount of space on a wafer as an Athlon 64 X2 4800+, despite only having half the cache. Thus we have the Manchester core: a core designed from the ground up to only feature a 512KB L2 cache per core.
As manufacturing ramps up, yields improve and it is now possible to actually create a cost-reduced Athlon 64 X2, using the smaller Manchester die - and that's where the Athlon 64 X2 3800+ gets its cost savings.
The transistor count of the 3800+ goes down to 154 million, and the die gets shrunk down to 147 mm2 compared to the 233.2M and 199 mm^2 of its bigger brothers (4800/4400+). The thermal envelope of the new core also dropped from 110W down to 89W, both still lower than Intel's Pentium D or single-core Pentium 4 for that matter.
With a smaller die and lower transistor count, the Athlon 64 X2 3800+ is able to support its $354 price tag.
Facebook
Twitter
RSS
109 Comments
View All Comments
justly - Tuesday, August 2, 2005 - link
It would seem I have to put this in even simpler terms for you.Processing POWER is not necessarily the same as processing SPEED.
Using an analogy may be the only way to explain this to you.
If you are given a task that is simple for you to accomplish, maybe something like moving two bricks 50 feet, having a second person help you will not result in you getting that task done any faster. The only thing that will make this task faster is if you run instead of walk. That difference is speed not power.
On the other hand if the task is more demanding, this time you need to move a 100 bricks 50 feet, then the second person should be able to cut that time in half if both of you move the same amount of bricks at the same speed.
I hope that wasn’t too hard for you to understand.
To go one step further, If in the first scenario (when you had to move just two bricks) if you only move one brick at a time then adding a second person (also capable of moving one brick) will show 100% scaling.
This demonstrates what I said about a poor performing processor will see a higher scaling when adding a second core, proving my point that higher scaling “shows how “inefficient” a single core is in that test”, not how efficient a duel core is.
To even attempt to show scaling efficiency in the manor that was done in the article is questionable, and to use a test that was not only less than processor limited on duel core, but less than processor limited on a single core was ignorant (again I am talking processor limited in terms or computational power not speed).
Since adding a second core does not change memory bandwidth or disk access time I don’t know why you even brought this up, as its irrelevant.
masher - Tuesday, August 2, 2005 - link
> "This demonstrates what I said about a poor performing processor will see a higher scaling when adding a second core..."Are you stupid? Your analogy-- muddled and poorly phrased as it is-- proves my point. Not yours. We're discussing a multitasking benchmark. Got any idea what the "multi" in multitasking means? More than one. A single core executes ONE thread at a time. This benchmark has multiple threads running at once.
To translate this back to your analogy, a single core cannot carry two "bricks" (threads) at the same time. It carries one-- partway or all the way-- then has to "run back" to carry the other one. And so on until the job is done. Sorry for the kindergarten-level analysis, but your posting history demands it.
Two cores carry two bricks at once...and get the job done faster. If you only had a single brick (a single nonthreaded app) then a second core wouldn't help you. If your second brick only had to move 1 foot rather than 50 (poor app scaling), then a second core would help very little. If your brick-carrying kept being interrupted by a traffic cop (disk or memory bottlenecks) then one core might run as fast as two. But in general-- two cores run multiple threads faster than one.
Get it now? I rather doubt it...but hope springs eternal to the human breast.
> "if you only move one brick at a time then adding a second person (also capable of moving one brick) will show 100% scaling."
Read my explanation above...then take your foot out of your mouth. This statement is the very reason for multicore processors. One core moves one brick at a time. Period.
> "Since adding a second core does not change memory bandwidth or disk access time I don’t know why you even brought this up, as its irrelevant. "
Again, you fail to understand the most basic concepts. An "app" that does nothing but copy a large file from A to B is disk-bound. Add two cores or a hundred, and it won't speed up. That's why this is relevant.
Of course, no app or benchmark is ever 100% disk-bound. But the faster the processor, the more impact a bottleneck will have. An infinitely fast single-core cpu will not run apps in zero time...it'll just spin, waiting for memory or disk. And adding a second core to such a cpu won't yield any gain...BECAUSE of the bottleneck.
Get it now?
Of course, our scenario of "Multitask Benchmark 1" and the A64 3800 isn't even close to this scenario. I only mentioned it to discount it, as it was the only quasi-reasonable explanation you could have believed the drivel in your first post. I see otherwise now...you were simply wholly and utterly clueless from the start.
justly - Wednesday, August 3, 2005 - link
Since you seem to believe that we should see an improvement in any multitasking test no matter how simple those tasks are explain this.If we know that adding a second core will increase performance (as indicated by 9.1% increase of the duel core PD over a single non-HT P4 for the test in question) then why does the AMD duel core show no increase in performance?
It can’t be that the AMD duel core is not functioning, because we can tell that it is functioning based on all the other tests.
Since this IS a multitasking benchmark (as you made sure to point out) maybe you would like a stab at this question also.
How is it that a duel core PD at 3.0GHz it is still not able to beat (or even match) a single core AMD at 2.0GHz?
It’s not like this test was designed to cripple an Intel processor (this test runs “files copy in the background while the script runs Microsoft Outlook and Internet Explorer in the foreground”).
fitten - Thursday, August 4, 2005 - link
Please stop using "duel" and use the proper term "dual". Continued use of "duel" when talking about "dual cores" pretty much erodes anything else you will possibly say.masher - Wednesday, August 3, 2005 - link
> "If we know that adding a second core will increase performance...why does the AMD duel core show no increase in performance? ...It can’t be that the AMD duel core is not functioning..."Easy question. Why? Because some resource in contention between the two cores is negating whatever slight gain the second core can offer.
Your notion that a second core that works in ANY case has to work in ALL cases is terribly misinformed. Consider Intel's HT for instance. Two virtual cores...but given they share so many resources between them, there are many cases where HT not only shows no performance gain, but an actual performance drop.
It's less common with two physical cores, or even two physical processors...but it can and DOES happen. Intentionally writing code that runs slower on a duallie (even 100X slower) is easy. Writing it accidentally is very possible as well.
Now here's the part you actually have to use your brain to understand. Take a deep breath and think before reading on. There are implementation differences between AMD and Intel's dual core designs. That means they share different resources, and to differing degrees. Meaning a program that causes some slight contention on Intel may cause more on AMD...or may cause none at all. Whereas different code may contend in totally different areas, and show a totally reverse pattern.
Starting to make sense to you?
masher - Monday, August 1, 2005 - link
The statement says "comparing AMD to the Intel Dual Cores". Multitask 1 has Intel averaging (9.1+2.3)/2=5.7% better than AMD. Multitask 2 has AMD averaging 14.4 - (13.9+9.1)/2 = 2.3% better than Intel.So Anand is calling a 5.7% Intel advantange "slight" but a 2.3% AMD advantage "significant".
Toss out the Intel Dual Core + HT row -- a fairer comparison in my opinion) and Intel does even better. Add in the non-dualcore Intel row and Intel does better on MT1 and worse on MT2...but not even the most strident AMD fanboy could call that a fair comparision.
NullSubroutine - Monday, August 1, 2005 - link
Not to take sides, but this was just comparision of AMD singc vs AMD dualc % vs Intel singc vs Intel dualc. The performance advantage wasnt direct comparison of AMD's dual core vs Intel's dual core. Disreguard if you understood this, but to simplify the explantion. Say AMD single core has benchmark of 100, Intel single core (/w ht lets say) is 90; then AMD dual core (same cache/mhz) has benchmark of 120 (20% increase) while Intel Dual core was 115 (27.7*% increase). Showing Intel's second core gave 7.7*% more power vs AMD's second core over its first. The purpose of this comparison was to try to find a benchmark (since none seem to be known to the author at this time) to see whose dual core implimentation is more "effiecent". Also possible the author, when describing "significant" or "slight" he did not seem to be averaging their numbers between ht and no ht, but simply sticking with one, at least I would assume this to be the case.Houdani - Monday, August 1, 2005 - link
OK, you averaged the dual scores (HT and no-HT) to get your numbers. I'm good with that.Regardless, it's moot now since Anand subsequently revised his statement to remove the inkling of bias. (He left a typo too -- tried to get rid of "a lot" but forgot to remove the "a")
BornStar18 - Monday, August 1, 2005 - link
The interesting part of his statement is the fact that the AMD Dual Core actually beats the Intel Dual Core in MMCC Winstone. I agree though that a 9.1% improvement is more than slightly better than 0%.GhandiInstinct - Monday, August 1, 2005 - link
"Ah, ah, ah, you didn't say the magic word."AMD and ATi, FTW.
http://nedry.ytmnd.com/">Source