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.

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?

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: 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.

[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.

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).

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.

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: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.