It's taken AMD almost the entire life-span of the Athlon 64, but Intel is finally on the run. Pick whatever measure of success you'd like, whether it is performance benchmarks, the Dell announcement, or being publicly accepted as a threat - AMD has done it. It's because of AMD's extremely successful uphill battle against Intel these past few years that we've had such high expectations from the company. So when Intel first started talking about its new Core architecture, we turned to AMD for a response that it surely must have had in the works for years, but as you all know we came up empty handed.

Only recently has AMD begun talking about what's coming next, and it will divulge even more information in the following weeks. The problem is that the architectural revisions to K8 that AMD is finally talking about now are still things we will see in the 2007 - 2008 time frame, while Intel's Core architecture is still on schedule to be a reality for 2006. What AMD does have planned to keep itself afloat during 2006 and until the new K8L core debuts is a brand new platform: Socket-AM2.

The long awaited Socket-AM2 platform marks the beginning of AMD's transition to DDR2 memory. If you'll remember, Intel made this transition about two years ago with the introduction of its 925X and 915 series of chipsets. The move to DDR2 proved to yield very little in the way of performance, but it was necessary as Intel was able to drive enough quantity of DDR2 in order to make the cost reasonable today. With DDR2 prices low enough, and availability high enough, AMD was poised to take advantage of Intel's work in establishing DDR2 as a desktop memory standard and support it on a new platform.

In AMD's uncharacteristic silence over the past several months, performance expectations for DDR2 on Socket-AM2 remained completely unset. A little over a month ago we previewed the Socket-AM2 platform and concluded that even when paired with DDR2-800, you shouldn't expect a performance increase from AM2. While AMD didn't publicly confirm or refute our benchmarks, all of its partners were in agreement with the results we had seen. Today, with final AM2 hardware in our hands, we're able to see exactly how far the platform has come in the month since we last looked at it.

AM2 in Detail
Comments Locked

83 Comments

View All Comments

  • Griswold - Tuesday, May 23, 2006 - link

    quote:

    Okay, here's my guess for the stopgap solution...drum roll...L3 cache. I think AMD will release a 2.8 revised FX-62 with L3 cache or an ahead of schedule 3.0 GHz FX-64 with L3 cache. Just my guess.


    Sounds conceiveable indeed. Though, the latter option would probably blow TDP out of proportion on 90nm.
  • mlittl3 - Tuesday, May 23, 2006 - link

    Yeah, that is a problem but Anand did say "trick up its sleeve" so maybe they have one last 90 nm manufacturing process that's better than today's. I've read some articles about L3 cache coming for AMD and one inquirer.net article (take with grain of salt) that says AMD will ramp clock speeds fast. Maybe the trick will have something to do with these factors. Who knows?
  • darkdemyze - Tuesday, May 23, 2006 - link

    Whatever it is I'm interested in reading about it
  • Regs - Tuesday, May 23, 2006 - link

    Whatever it is, it's going to be expensive.
  • TrogdorJW - Tuesday, May 23, 2006 - link

    Actually, I was sort of thinking that the "stopgap solution" might be to cut prices. God only knows that I would love to see a $200 X2 processor!
  • Griswold - Tuesday, May 23, 2006 - link

    Well, they will have to drop prices at some point after core 2 is actually available.
  • xFlankerx - Tuesday, May 23, 2006 - link

    Indeed, same results as expected. Maybe this will make the AMD fanboys shut up about "waiting to see what the final results are." NOTE: I have a AMD system, I'm simply addressing those that refuse to accept Conroe's superiority.

    Although...I must say that this "stop gap" solution by AMD has piqued my curiosity.

    But I believe that these say it perfectly;

    "One of its stipulations for sending out Socket-AM2 review kits was that the CPUs not be compared to Conroe."

    "We do get a sense of concern whenever Conroe is brought up around AMD."

    "So when Intel first started talking about its new Core architecture, we turned to AMD for a response that it surely must have had in the works for years, but as you all know we came up empty handed."

    Those just say it all for me. Seems like AMD's in trouble. From what I've been reading, K8L doesn't bring in architectural changes either. Sure you get Quad Cores, L3 cache, FB-DIMM support, DDR3, and faster HyperTransport, but if AMD doesn't improve on it's performance-per-clock efficiency, then Intel's Quad Cores (due almost 9 months before AMD's) are going to rule supreme yet again.
  • Griswold - Tuesday, May 23, 2006 - link

    quote:

    Those just say it all for me. Seems like AMD's in trouble. From what I've been reading, K8L doesn't bring in architectural changes either.


    Maybe read up on it first.

    Memory mirroring, data poisoning, HT retry protocol support, doubled prefetch size (32byte instead of 16), 2x 128bit SSE units (instead of 2x 64bit), out of order load execution, Indirect branch predictors and a handful new instructions sure sounds like a few architectural changes and not just a simple revision stepping.
  • rADo2 - Tuesday, May 23, 2006 - link

    Sorry, links again:

    Intel Conroe @ 3.9GHz: SuperPI 1M - 12.984s
    http://www.xtremesystems.org/forums/showthread.php...">http://www.xtremesystems.org/forums/showthread.php...

    AMD FX-57 @ 4.2GHz: SuperPI 1M - 21.992s
    http://www.xtremesystems.org/forums/showthread.php...">http://www.xtremesystems.org/forums/showthread.php...
  • MadAd - Monday, May 29, 2006 - link

    Try measuring like for like and then come back with your silly benchmark comparison. EG use a superpi data size that will fit on BOTH cpus caches, not just conroes and then compare performance.

    With the FX57 having just a 1M cache its bullsht smoke and mirrors saying the 1M superpi is slower, o rly? perhaps thats because it takes more than 1M to hold both the feature and data sets on a 1M superpi.

    muppet

Log in

Don't have an account? Sign up now