AMD Athlon 64 Performance Preview

k-hell writes "It seems like X-bit Labs have gotten their hands on an 'engineering sample of the AMD Athlon 64 2800+ processor'. Damage at Tech Report is writing that 'This is really fun, but I am a little concerned about their memory latency numbers.'"

Comments

For strange values of "worse"

[AndroidCat]

When Athlon processors came out in 1999, the competition in the processor market became much worse.

I don't think that word means what they think it does.

Re:For strange values of "worse"

[SirDaShadow]

They are from Russia, you got to cut them some slack. I've been pondering talking to Anna and offer some sort of proofreading service. Then again, my English ain't perfect :)

here's a mirror

[linuxbaby]

temporary mirror here

Context Context Context

[robbyjo]

You should include the full quote of Damage, because just quoting out of context can be misleading. Here's the full paragraph (emphasis is mine):

This is really fun, but I am a little concerned about their memory latency numbers. They haven't specified what units those numbers are in, but latency numbers come out of programs like cachemem in CPU cycles. Obviously, processors with higher clock speeds will see more clock cycles pass per second than processors with lower clock speeds. One must convert those numbers into comparable units, such as nanoseconds, in order to compare CPUs at different clock speeds. I do expect the Athlon 64 to have low memory access latencies because of its integrated memory controller, but I don't think the gap will be so great as the X-bit numbers would seem to indicate.

So, the worry is about the units the latency numbers are expressed in. And when you'd see the numbers below, you get an idea why it is so:

Athlon 64 2800+

• Mem read speed: 2610.2 MB/s
• Mem write speed: 1099 MB/s
• Mem copy speed: 1541.7 MB/s
• Latency: 96

Athlon XP 1.6GHz

• Mem read speed: 1747.8 MB/s
• Mem write speed: 1156.9 MB/s
• Mem copy speed: 1244.8 MB/s
• Latency: 165

Pentium 4 2.8C

• Mem read speed: 3193.5 MB/s
• Mem write speed: 1320.5 MB/s
• Mem copy speed: 2678.6 MB/s
• Latency: 260

See it for yourself.

Re:Context Context Context

[zenyu]

Athlon 64 2800+ (true clock 1.6Ghz)
latency: 96 cycles or 96/1.6 => 60 ns

Pentium 4 2.8C
latency: 260 cycles or 260/2.8 => 92 ns

So there is a 33% improvement, which is cool. (i.e. the P4 is 50% slower)

The SSE2 instructions were pretty much in equal to the P4 in throughput per cycle, that is as a SEE2 processor it performs like a 1.6Ghz P4... Hopefully they can push the clocks up as fast as Intel has with NetBurst.

Got their hands on it?

[bplipschitz]

Did they burn their fingers?

How old is this "'engineering sample"?

[AndroidCat]

On the picture of the chip, it's stamped "Copyright 2001".

Re:How old is this "'engineering sample"?

[Anonymous Coward]

The manufacture date shows as 0301 (jan 2003) and copyright applies to the text/picture on the chip not the tech inside.

3DNow!: Cause of Slow Clock Frequency in InnerCore

[Anonymous Coward]

The review of the Athlon 64 notes that the core frequency is actually less than that in the Athlon XP. The reason is that the wires are being loaded down with too many transistors, so the resistance-capacitance (RC) time constant is too high. I doubt that the AMD engineers are somehow less capable than the Intel engineers in designing transistor interconnects with low RC time constants.

So, what could be the problem? The problem is that AMD is trying to support too many instruction sets. AMD should have axed 3DNow! and swallowed its pride. Supporting MMX, SSE, and SSE2 is sufficient.

When you try to put everything and the chicken sink into a chip, you inevitably pay for it with a slower clock speed.

My Observations

[MBCook]

Well, first off I'll say that I agree that we need units on the memory latency. If they are in a unit of time (microseconds or something) then they really show what can be done with an onboard memory controller. But onto more "important" things.

The processor doesn't take to many benchmarks, but you can't fault it too much. It's nice to see some numbers are the CPU in 32 bit mode, but let's not forget that EVERYTHING here is 32 bit (OS, programs, etc). I'd LOVE to see a comparison between 32 bit programs running under and identicle OS versions that do and don't support 64 bits (Win XP vs Win XP for x86-64 for example). I'd suspect that the performance would go up with a 64 bit OS (especially on the games, where drivers and such play such a big part). Considering it's clockspeed, it holds up very well. The fact that it's almost never far behind a current athlon with an identicle performance rating (which is actually like 400 mhz faster) shows that it can definatly run things well. This isn't the horridly crippled performance that we've all heard about with the Itanic.

So what's my take on all of this? I think that this shows that the x86-64 can really become a success. I know some of you out there are thinking "Why would I buy one? I've got a 2.4 ghz Octium 7 and my PC is faster than that thing." That may be true, but many people aren't like you. My fastest computer is a PIII 933, so even at 1.6 ghz that Athlon64 can run circles around my best PC. If you are using a PC that's even a year or so old, you can probably benefit alot if you were to move up to an Athlon64 when it comes out.

My notes on some specific benchmarks:

• 3DMark 2k3 - The chip is only 4% behind the P4 despite the fact it's clocked at only about 60% of the P4. Impressive.
• 3DMark 2k1 - The A64 is nearly identicle to the P4, despite the massive clock difference. And this is 32 bit code. Compiling a game for the x86-64 is supposed to increase performance up to 30%. Drooling yet?
• UT2003 - The A64 is nearly 10% FASTER than the P4, despite the clock difference. "Office" benchmarks may not look impressive, but games are what counts ;)

Now my objections to the benchmarking

• Where is the 1.6 ghz P4 in this? They could underclock the P4, or just get a TRUE 1.6 ghz P4 so we can see how they compare clock for clock.
• No 64 bit OS. I'd have liked to see them run Linux so they could do some tests to see how it performed with 32 bit code (UT2k3, Q3, etc) under a 64 bit OS. I understand that Windows isn't out yet so they couldn't use it.

My final thoughts are this: it looks quite promising, and I can't wait to see more. More and more people with comeout with benchmarks as time goes on, and with the Opteron released now, we'll soon see benchmarks of it in SMP mode against other chips in both 32 and 64 bit OSes with 32 and 64 bit code. Either way, it looks like it's more successful than the Itanic.

Re:My Observations

[SEE]

Uh, the Itanium 2 processor at 1GHz performs about as well as a 2.5GHz P4.

On 32-bit x86 code, which is what this benchmarking tested?

Re:My Observations

[captaineo]

No, performance in general would go *down* if you simply re-compiled existing code from 32 to 64 bits. (this is because pointers would double in size, and executables would grow slightly, increasing the cache footprint).

The only ways to gain performance moving to 64 bits are:

1) re-write software that needs a >4GB working set (e.g. databases) to use 64-bit pointers rather than paged or segmented 32-bit addressing

2) re-write high-performance integer code to process values in wider chunks (although you can do this on today's hardware with MMX and SSE)

The great part about AMD's new chips is that you will be able to run a hybrid 32/64-bit system. 64 bits for the few programs that actually benefit from it, and 32 bits for everything else. Running an entire system at 64 bits, although cleaner, is a loss for most mundane programs (cat, grep, bash, etc).

Re:My Observations

[AxelTorvalds]

If the code size change is noticable I worry for your code.

There won't be a cache difference either, the 64bit chips are word aligned to 64bits. They are optimized for that.

Generally no differnece at all between 64 and 32bit processors, as demonstrated by sparc and POWER/PowerPC.

Re:My Observations

[SEE]

True in general, but there's one more factor -- the x86-64 instruction set has more registers than x86-32.

For those who don't RTFA

[uhmmmm]

'This is really fun, but I am a little concerned about their memory latency numbers.'
Note, this is not because they're bad numbers, but rather because the units aren't specified, and may be clock cycles, which wouldn't be a fair comparison to the other processors.

tested with windows

[paradesign]

in 32 bit mode... wtf?

couldnt they have used any one of the 64bit linuxes? this sounds like a bs review to me;

Re:tested with windows

[atam]

Why not? One of the supposed selling point for the Athlon 64 is that it will run 32-bit software equally well (unlike the Itanic). Also, at its introduction, there will not be that many 64-bit software available. Hence, it is important to look at its 32-bit performance so that you could decide whether to get it early (if the 32-but performance is good) or wait until more 64-bit software is available (if 32-bit performance is worse than current Athlon XP).

Re:best processor/price?

[spike hay]

At $500, you have just limited yourself to a mid-ranged Athlon or P4.

More like very high range. A quick glance at Pricewatch will show you that currently, the fastest Intel, 3.06 ghz, costs $388. The fasted Athlon, the 3000+, costs $320. Even the 2.8 Xeon is $425.

Single page view

[TeknoHog]

Printable version here.

Umm....

[LucidityZero]

From the article:

Unfortunately, 64bit operation systems and applications are not available yet.

Really? I could have sworn...

Re:best processor/price?

[atrus]

Note this is for Motherboard/Processor/RAM, so, if you get a $425 processor, you won't be finding a board and good ram for it for $75

re: athlon 64 performance.

[herrd0kt0r]

lemme sum up the article:
- WAHOO! CHECK dis shit OUT! we got an athlon 64 chipz0rz!
- it's beefcake, dood. memory controller insIIIIDE!
- we're just gonna test it with 32 bit shizzle.
- it's like, good at some things, not so good at others.

anyway, here's something to consider: the sample they tested is 2800+ per AMD's performance rating spec, and it runs at 1.6gHz. yeah. most of the tests and graphs n stuff show it running around the level of a P4@2.53gHz. alright, so it doesn't exactly match the P4@2.8gHz. but think about this:

it's running at 1.6gHz!

nevermind the fact that it doesn't squash the fastest P4 they tested it against into the ground. it's just amusing to see how good the architecture is of the A64. i dunno. i think it's pretty cool, anyway.

anyway, seriously speaking: what use is testing a processor touted as being a 32-bit compatible 64-bit chip, when _NO_ 64 bit apps were used in testing?!

"uh. well. it ran the 32 bit stuff fine. and uh. it didn't fry."

For those who don't follow every AMD move.

[WoTG]

Remember that this "preview" probably violates one or more NDA's, and it is of a desktop x86-64 chip that is scheduled for September release. In the meantime, it's bigger brother, the Opteron, who has more memory bandwidth, (usually) more cache, and multiple processor support will be released in less than a week (Tuesday to be exact).

Now the reviews that out in 4 days time should be much more interesting reads. I expect to see someone do a solid x86-32 vs. x86-64 comparison using Linux, maybe other OS's too. And yes, probably even Quake frame rate results. =)

Re:Quick conclusion

[herrd0kt0r]

or, for the more intuitive of you: simply click the "11" at the top. it takes you to the 11th page without you having to click through all the pages.

here's a graphic:

Pages:1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11
click here^^

AMAZING! MODERATORS: MOD ME UP AS +10000, INFORMATIVE! 8P

Check out date on processor.

[OoSync]

To add more fuel to the "its only an engineering sample", check out the date on the

processor itself.

Imagine, with nearly two years of time to improve on this piece of silicon just what is in store for the Clawhammer. Personally, i'm waiting for it so I can finally upgrade my Athlon 600.

Re:Check out date on processor.

[certron]

While this is 110% pure speculation, there are other numbers on the CPU. The one that I'm looking at is 0301 (2nd line of numbers/letters) which I will guess to be 1st week 2003. However, since this is pure speculation, and they got their hands on it *somehow* it could just as easily be 3rd week 2001.

OK, so that doesn't clear up anything. :-)

Re:Check out date on processor.

[rabidcow]

The one that I'm looking at is 0301 (2nd line of numbers/letters) which I will guess to be 1st week 2003.

Exactly, date codes on chips, which tell you the date of manufacture, are usually 4 digits: two digits for the year, then two digits for the week in that year.

If you RTFA (as opposed to just looking at the pretty pictures), they say, right under that image: "The production date in the next line of the marking indicates the beginning of this year."

This is pretty standard, I can pull out my old 8088 MB and read the date code off the processor: 8937 (1989, 37th week) You can find similar date codes on most chips and PCBs. (eg, that 8088 MB has 8945 printed on the back)

very old rev

[Anonymous Coward]

Being that I am an AMD employee, I know for a fact that B0 (the version of clawhammer that they are benchmarking) is a very early rev, and should not even be considered when thinking about final benchmarks. Geez.

Well, one thing is for sure, xbit labs just blew their chances of ever getting their hands on another upcoming bleeding edge technology again.

WORK per DOLLAR is all that matters

[aeoo]

Where is the 1.6 ghz P4 in this?

That's irrelevant. The proper way to square off chips is based on money. In other words a $200 dollar chip should go head to head with another $200 dollar chip, and an $800 chip goes against another $800 chip.

That's the only way to get fair results that are independant of implementation details. Clock rate the chip runs at is an implementation detail. It's not important. What's important is WORK per DOLLAR. That's the only thing that matters. Period.

Re:WORK per DOLLAR is all that matters

[gunix]

The problem with work per dollar is that prices are cut with 40% anyday.. so a price comparison is not valid for a long time. But, they sure as hell are important when it comes to placing an order for 200 machines..

So what matters is: work per time and then you can calculate costs later....

The two ways of looking at a half-empty glass

[vlad_petric]

The tests are pretty much showing that an Athlon-64 does not outperform a 32 bit Athlon when running 32 bit apps.

But here's another way to look at it - Itanium also has an x86 layer, but because it's really just an emulation, its performance sucks.

So I view this as a huge success. Why ? Because an Athlon-64 will be able to run "legacy" 32 apps at the same speed, while 64 apps will run faster.

You'd probably wonder why this is the case. Well, IMNSHO it's not because of the wider registers/ALUs, etc, but because of other improvements to the Instruction Set Architecture, like the 8 extra registers (16 total). Because you only have 8 registers on a regular x86, compilers can register-allocate very little. Adding 8 more registers means that you can keep more stuff in the register file, and you don't have to go to the stack (data cache) every single time.

Re:Quick conclusion

[TitusC3v5]

Umm...please tell me I wasn't the only person who tried to click on that. :-o

UT2003...

[Nameles]

Wasn't that designed with 64-bit processors in mind?

Now this doesn't make much sense, because how can you run that in 64-bit mode even though you have a 64-bit processor, when the OS is running in 32-bit mode?

Or am I dreaming?

Re:UT2003...

[mabinogi]

You can't.

The UT2003 they tested was the normal 32 bit version.
And as they said, it already favoured the Athlon XP, and the Athlon64 is very similar to an XP.

Re:3DNow!: Cause of Slow Clock Frequency in InnerC

[RzUpAnmsCwrds]

3DNow! is essentially a subset of SSE. Removing it would not save a signifigant number of transistors.

Re:No SMP??

[Slack3r78]

You mean this one coming out next week?

Re: athlon 64 performance.

[Hoser McMoose]

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.