This review sucked. You used pc3200 on all the test systems except the hammer one, where you used pc2100. Who came up with that bright idea? I don't think any of the numbers obtained here are fair. Maybe the reviewer should try some pc3200 for the hammer system so we could have some accurate nuimbers?

I was looking at the SiSoft Sandra SSE numbers.

For integer

P4 12949 / 2.53ghz = 5,118 per ghz,
P4 20635 / 2.8ghz = 7,369 per ghz.
A64 9161 / 1.6ghz = 5,725 per ghz.

Since the 2.53 and the Athlon 64 have a similar front side bus throughput, and come out with similar marks per ghz while the Intel systems have similar ghz yet differ in marks and front side bus. We can assume the SSE tests are very dependant on front side bus throughput. We will only know this when a dual memory controller Opteron is tested. Since it operates with a similar front side bus throughput as the 875. Or is it hyperthreading that makes the P4 2.8(800) so fast?

Just wondering if anyone else was impressed since this Athlon 64 ran at 1.6 Ghz, while the Athlon XP was clocked 33% faster and the Pentium 4 is clocked 75% ( over 1 GHz) faster. I think that the Athlon64 is very impressive especially since we haven't even gotten 64 bit Windows to run the tests on or final silicon from VIA or AMD. It appears that while not revolutionary with 32 bit code, the Athlon 64 is a much needed evolution in its efficiency and memory interface.

From my perspective this is much more exciting than any die shrink or another GHz.

Doesn't cachemem report latency in clock cycles? Thus invalidating any comparison between cpus unless they have the same clockspeed?

AMD is beginning to lose too much in the Mhz's, hope the can increase clockspeeds asap!

The test and the performance looked good to me. You have to remember that this is also a 64 bit processor and a 64 bit OS was not tested here. The P4 will not be able to run anything in 64 bit. That will require another board and processor such as the Itanium II unless Intel decides to build the X86/64 that has been rumored to exist for so long.

One disappointment in this test was that the processors weren't tested on Linux. Suse and at least one other Linux disti have both 32 and 64 bit versions which would have shown how the Athlon 64 does running on 64 bit as compared to the P4 running on 32 bit. That I think is where the Athlon 64's real strength will lie. But if all the testers wait for Windows we will have to wait for the results of that comparison until Microsft releases their 64 bit OS in the fall. Just my opinion but I think that would be an interesting comparison now.

I knew this processor was going to be garbadge!

You mentioned that the Clawhammer has a longer (integer) pipeline (12 to 10 stages) in order to achieve higher clockspeeds. This cannot be true.
Higher clockspeeds can only be achieved with a longer pipeline if the same amount of work is distributed among all stages so that each stage has less to do per clock. This yields a less complex circuitry for each stage and therefore less circuit time which is the only reason for the ability to gain higher clockspeeds.

But this is not the case with Clawhammer. Here the amount of work is not constant. The two new stages do extra work by examining the decoded µOps for each lane and optimising them (rearranging, changing lanes, combining if there is mixed int/fp code and much more), before they enter the scheduler of the execution units.

I don't want to go deeply into details but the fact is that the two extra pipeline stages are not for increasing the processor frequency but for increasing the ILP (Instruction Level Parallism) of the Clawhammer.
This is also well described here:

http://www.chip-architect.com/news/2002_06_24_Hammers_Two_ Extra_PipelineStages.html

Beside that, some more real-world benchmarks would have been nice.

Greets,

GloomY

Is it possible to release some information about the temperature?
Why wasn't the athlon 64 overclocked, amd will probably introduce cpus with a higher frequency, so if you will overclock the cpu we could get a glimp of the possible performance increase with a higher frequency.

>64bit operation systems and applications supporting x86-64 are not available yet.

I can't believe Xbit got this wrong; there are about a half-dozen 64-bit operating systems out, IIRC 5 distributions of Linux and one of Free or NetBSD, and a large number of applications known to work on 64-bit systems like sparc 64 that should work without problem when recompiled for x86-64. Is Xbit like 2 years behind the time or what?

The problem here is that the benchmarks were performed using a 32bit operating system, which is leaning heavily on the 32bit execution of the Athlon64. If you were to replace Windows with an x86-64-native operating system, such as Linux, the numbers would be drastically different, without a doubt. The OS is limiting the benchmarks, and as such, providing factually inaccurate results for 64bit or overall performance. In other words - these benchmarks are NOT a factual representation of overall performance, only a preliminary view of 32bit only performance.

why wasn't it compared to a 1.6 P4, as it is running at 1.6ghz? of course a faster p4 will outdo it in some categories. also, why did you guys not use a 64 bit operating system? there's more out there than windows, ya know.

my impressions...as far as 32bit apps go, meh. on the other hand, it could kick butt in 64bit, but of course it wasn't tested that way. a good benchmark of the final version will be interesting, if it ever gets here. and it REALLY needs to be running a lot faster than 1.6ghz, that's just rediculous. amd can't keep playing these "less is more" games forever. apple isn't fooling us with it and neither is amd.

Maybe the Athlon64 2800+ just needs a higher clock speed. 1.6GHz isn't that fast. If it was at maybe 2.0GHz then it could be a serious contender.

How disappointing that you pretend to test a CPU without trying to run a single program it was designed for. Would you test the latest NVIDIA product with the original Quake, too?

Having Athlon 64 at such a low clock rate still perform as well as it did with 32 bit applications is quite impressive, as we all know that it's very difficult to find new ways to push 32 bit operation further than it already has. The real test only begins when you try 64 bit, however. Especially stupid was making any conclusions out of 32 bit scientific computing, since that will be the first category to take advantage of the 64 bit capabilities.

There is already a 64bit version of Linux for the Athlon-64 cpu, in addition linux has supported 64bit architectures such as Alpha, UltraSparc, etc... for years, so there is a fair amount of software which could be compiled for the amd-64 architecture to take advantage of it.

Sorry to correct you, but 1MB plus 128 KB is actually 1152 KB, right? ;-)

From the article "Unfortunately, 64bit operation systems and applications supporting x86-64 are not available yet"
Which is of course not correct. Linux for IA-64 and x86-64 has been available for some time now, and most major application may be compiled for 64bit operation if they wouldn't come pre-compiled with your 64bit distribution (try Mandrake 9 http://www.mandrakesoft.com/company/press/briefs?n=/mandra kesoft/news/2414 )

First: no ACPI support? Strange, processor taking so much power should be able to throttle down it clock and disconnect not used parts.
Second: What about bullshit, that there are no 64 bit OSes avaiable? FreeBSD has the x86-64 support, so has Linux for few years(!).

Why not recompile userspace for 64 bit and compare then, with 32 equivalents?

This review is biased - and it shows.

Why didn't you use a 64 Bit OS? The claim "Unfortunately, 64bit operation systems and applications supporting x86-64 are not available yet" only makes this worse, not better. There are so many x86-64 OSes available (SuSE, other Linux, BSD) that I don't believe you when you claim you never heard of them. For example the UT-Linux server became 30% faster by just recompiling (according to the UT-guys), so using a 32-Bit OS only makes this review biased against Athlon64.

To regain at least some credibility, you should remove the claim that x86-64 OSes don't exist immediately and add some Linux benchmarks.

I think most people are missing the real point to 64 bit CPU's It has more to do with adresssing than speed. now servers can easiely get past the 4 gigbyte limitations of 32bit CPU's with out going to a expensive Alpha or Sparcstation. That is where this CPU is going to find its home on the market. Although there are serveral other factors in play here, they were running a 32 bit OS and apps. If you were to look back at the alphas running WinnT 4.0 and FX32 they ran the 32bit appz just quite a bit slower. but with native 64bit apps like on Digital Unix they were amazingly faster to intel x86 offerins mhz for mhz