Linux and EM64T; Intel's 64-bit Suggestion
by Kristopher Kubicki on August 9, 2004 12:05 AM EST- Posted in
- Linux
Since the excuse to not compare Athlon 64s to Intel Pentium based processors has always been "you can't compare apples to oranges," we found ourselves fairly entertained to come into the possession of a 3.6GHz EM64T Xeon processor. Intel's EM64T is Intel's true x86_64 initiative. This 3.6GHz Xeon processor is actually the exact same CPU in as the LGA775 Pentium 4F we will see in just a few weeks. We are offering a preview of an unreleased processor on 64-bit Linux systems. Now, we have Intel and AMD 64-bit x86 processors, 64-bit Linux operating systems and a few days to get some benchmarking done.
We are going to run the benchmarks for this review slightly different than we have in the past. We want to make our numbers easily replicable for those who have the necessary components, but we also want to show the fullest capabilities of the hardware that we have. Many of our previous benchmarks are not multithread (POV-Ray) or do not scale well. Unfortunately, this forces us to use a lot of synthetic benchmarks; but we feel the overall results are accurate and reflective of the hardware used.
The delicate bit for this review was using the SuSE 9.1 Pro (x86_64) installation rather than compiling it from scratch (à la Gentoo). This was done to preserve the ability to replicate our benchmarks easily. Fedora Core 2 refused to install on the IA32e machine because there was no recognized AMD CPU.
As there may have been a little confusion from the last review, the DDR PC-3500 only runs at 400MHz. The Infineon Registered RDIMMs used on the Xeon runs at slightly high latencies. All memory runs in dual channel configurations. We removed 1 CPU for the tests in this benchmark, but since HyperThreading was enabled, we used the SMP kernel. During the second half of the benchmarks, SMP was disabled and the tests were re-run under the single CPU generic kernel. These are both 64-bit CPUs, and so, all benchmarks are run on 64-bit OSes with 64-bit binaries wherever possible.
We are going to run the benchmarks for this review slightly different than we have in the past. We want to make our numbers easily replicable for those who have the necessary components, but we also want to show the fullest capabilities of the hardware that we have. Many of our previous benchmarks are not multithread (POV-Ray) or do not scale well. Unfortunately, this forces us to use a lot of synthetic benchmarks; but we feel the overall results are accurate and reflective of the hardware used.
The delicate bit for this review was using the SuSE 9.1 Pro (x86_64) installation rather than compiling it from scratch (à la Gentoo). This was done to preserve the ability to replicate our benchmarks easily. Fedora Core 2 refused to install on the IA32e machine because there was no recognized AMD CPU.
Performance Test Configuration | |
Processor(s): | Athlon 64 3500+ (130nm, 2.2GHz, 512KB L2 Cache) Intel Xeon 3.6GHz (90nm, 1MB L2 Cache) |
RAM: | 2 x 512MB PC-3500 CL2 (400MHz) 2 x 512MB PC2-3200 CL3 (400MHz) Registered |
Memory Timings: | Default |
Hard Drives | Seagate 120GB 7200RPM IDE (8Mb buffer) |
Operating System(s): | SuSE 9.1 Professional (64 bit) Linux 2.6.4-52-default Linux 2.6.4-52-smp |
Compiler: | GCC 3.3.3 |
Motherboards: | NVIDIA NForce3 250 Reference Board SuperMicro Tumwater X6DA8-G2 (Only 1 CPU) |
As there may have been a little confusion from the last review, the DDR PC-3500 only runs at 400MHz. The Infineon Registered RDIMMs used on the Xeon runs at slightly high latencies. All memory runs in dual channel configurations. We removed 1 CPU for the tests in this benchmark, but since HyperThreading was enabled, we used the SMP kernel. During the second half of the benchmarks, SMP was disabled and the tests were re-run under the single CPU generic kernel. These are both 64-bit CPUs, and so, all benchmarks are run on 64-bit OSes with 64-bit binaries wherever possible.
275 Comments
View All Comments
WiZzACkR - Tuesday, August 10, 2004 - link
Regarding Post: 166 - Posted on Aug 10, 2004 at 9:28 AM by ss284hi steve - just a short reply. first of all let me say sorry for definitely overreacting, BUT:
"just mentioning that you seriously post in the [H]ardforums drops your credibility to 0. Saying that Hardocp, and especially the disgustingly bad hardocp forums come even close to Anandtech and its forums are an insult."
i don't really know where you have such a bad impression from, and frankly i don't care. however, for someone calling me biased and accusing me of "huge sweeping assumptions" this seems put you into the same boat, doesn't it?
"obviously written by that of a person who has done minimal research and has made huge sweeping assumptions."
it's actually quite simple: i just had their forums open at the time i was writing! look at the huge posts here in anandtech's forums ( http://forums.anandtech.com/messageview.cfm?catid=... ) or in whatever forum you want (just as another one you may want to look here http://www.aceshardware.com/forum?read=115093788 ) - it' everywhere ppl ranting over the review. so don't call me biased, don't accuse me of simple sweeping assumptions or minimal research. mind you - the wording here in anandtechs forums about the topic was not one bit better than the [H] forums...
"Oh, and FIFI, insulting people loudly with the intent to attention only shows how much your typical, non insulting postings command no respect or deserve any thought whatsoever, and that the only way for you to get a reponse is to yell."
i admit this is true and again want to apologize for overreacting. however, this remains the poorest review i've read at anandtech's for YEARS and think articles like this HAVE to go through an editors office - and prevented from being published!
"Last I checked it was AMD that came up with these processor ratings. Yet they dont seem to be taking any of the blame. A PR rating of 3500+ means its supposed to be competing with intel's p4 3.5, which doesnt exist. Kris took the nearest speed, a 3.6, and mentioned that in the review."
ok, you got a point there i admit. however, intel themselves is changing to a non-performance related numbering scheme and the article is comparing a $850 SERVER chip against the cheapest 939 MID-Level DESKTOP cpu. AMDs PR-rating scheme was designed comparing them to the previous generation of intel CPUs. put it ups against something equally expensive and a SERVER chip i say, but giving the unavailable 3.6F as an excuse i find inappropriate.
"Its sad to see how many horribly biased morons are posting this crap."
you have to admit it's the whole freaking internet you are talking about, as i really do not represent a minority here...
"Yes, there were problems with the article, and Kris is actively trying to remedy it."
then change the last paragraphs and not just add this little update-thing at the very end. how can you correct the benchmarks and then leave the conclusion the same - even though the first benches now show the 3500 winning (still being 500 bucks cheaper)?
"He is even testing an opteron system per request. Yet people continue to flame. Maybe you should offer some constructive criticism instead of going off on lame conspiracy theories and dooming the fate of Anandtech."
Let me say again i am sorry for the wording i chose - and again that a site as reputable as anandtec's is HAS to edit articles to prevent this from happening. sorry, there is just no excuse for dropping the ball so badly. i wouldn't even have cared if it wasn't one of the most professional sites on the net.
"If this is seriously how you feel, dont bother posting anymore. If the content is that bad, dont bother reading it."
i was so upset mainly because lots of ppl are reading this and take it as a fact, go out and buy a product. it's not about me really.
to put this to an end: excuse my swearing, it'll not let it happen again, but all criticism about the article still seems valid to me.
kresek - Tuesday, August 10, 2004 - link
Wouldn't a "openssl speed" make a better encryption test?John the Ripper uses some quite outdated assembly routines, and imvho does not represent a typical encryption workload.
Matthew Daws - Tuesday, August 10, 2004 - link
Okay, an update after reading over at Ace's. GCC under 64-bit linux does default to 64-bit mode (as expected). No idea what processor it defaults to though. There is also some suggestions that -O3 would make a big difference. There are some quite powerful critiques of Jack-The-Ripper as well:"The key parts of the tests John the Ripper runs are written in ancient assembler code, with different routines for an intel CPUID. From what I can see, the AMD code path uses 8 bit operations half the time and does a lot of memory copying! COmpletely invalid to use this as a benchmark."
--Matt
kresek - Tuesday, August 10, 2004 - link
johnsonx - Tuesday, August 10, 2004 - link
I've read and read and read all this drivel in here, and I still don't get it. Everyone keeps complaining what a bad CPU Review this is; back to my earlier point about borderline illiteracy, did anyone notice the title of the article?"Linux and EM64T: Intel's 64-bit suggestion".
Doesn't sound like a CPU review to me. Sounds like a quick preview or first look at running 64-bit linux on the first x86-64 capable Intel processor AT had gotten their hands on. That's how I read the article.
Also, why does everyone take the conclusion line out of context:
"Without a doubt, the 3.6GHz Xeon trounces over the Athlon 64 3500+ in math-intensive benchmarks."
Everyone who quotes this line leaves out the "...in math intensive benchmarks.". Why is this incorrect? What other conclusion could be drawn from the benchmark results? Sure I guess if you want to get really picky and legal about it, it might have said "....in THE math intensive benchmarks WE RAN". But seriously, what other benchmarks would he be referring to?
ianwhthse - Tuesday, August 10, 2004 - link
I don't know about the rest of you, but I do thank my mailman.Matthew Daws - Tuesday, August 10, 2004 - link
John the Ripper really needs some better work on the GCC flags. The generic configuration tries to optimise for a 486, which is why it fails (I would have, ahem, expected this to be obvious to someone doing a linux benchmark). The supplied text files indicate that "John optimizes itself during the build" is certainly not the case. The following flags are used:-c -Wall -O2 -fomit-frame-pointer -funroll-loops
Does anyone know what the default CPU target is? There is not explicit -mtune or -mcpu command, and no explicit command to use SSE(2) for math processing (hmm, a check shows that the x86-64 compiler defaults to SSE for math). For something like encryption, I would expect that optimisation would have a HUGE difference, so for the nocona (with GCC 3.4.1) I'd use -march=nocona. You can force 64-bit support with the -m64 command, which might be worth trying. Also, what about using the -O3 command or the -ffast-math command?
Anyone got a 64-bit linux system and know what target GCC defaults to? I can only presume 64-bit.
I've just downloaded the source-code from http://www.openwall.com/john/ and it appears that there are specially optimised modules to use x86 options (e.g. MMX). These are NOT being compiled in your test (from checking the attached transcripts). There is also a BETA version which offers much improved performance. You might consider using this?
Also, from my (limited) understanding of encryption algorithms, they don't use "math" (which tends to mean floating-point code as far as computers go) but use bit-twidling and such-like. This makes the fact that Nacona can thrash the Athlon 64 even more surprising (and hence suspect).
Just a few thoughts, --Matt
Arias74 - Tuesday, August 10, 2004 - link
Ok, I guess it's time to throw my $.02 into the mix. I've almost all the posts, and I think I understand the frustration.First of all, let me just say that I am a fan of AMD's processors. Within the past 6 months, I've puchased for myself or work several Opterons, an Athlon 64, and about a half dozen Athlon XP's. So, I'm fairly familiar with their products. That doesn't mean that I like Intel, only that I prefer AMD.
I think the most objectionable point in the article for me, and probably for most people, is the conclusions that the reviewer derived from his benchmarks. Especially the first sentence of the second paragraph "Without a doubt, the 3.6GHz Xeon trounces over the Athlon 64 3500+...", it seems to me that the conclusion was written to generate more of a "sound bite" than anything. In fact, I was pointed to this article from another website that used that line as a quote. And for you Intel fans out there, how would you feel if a website of technical merit published a review and declared "Intel's latest offerings is a joke compared to AMD's products...". Seems a little biased, don't you think? And the few corrections made throughout the article barely make it onto the conclusions, as an afterthought or a p.s. line at the bottom.
I've always relied on Anandtech to give very thorough and useful reviews of products. It's almost a given. However, with this current review, I am sincerely beginning to doubt that. With a review filled with numerous errors, I would think that a correction AT THE BEGINNING of the article would be the least that could be done, not at the end.
Also, I have to say that the choice of benchmarks should be seriously reconsidered. As many people have already pointed out, synthetic benchmarks are entirely useles compared to real world applications. I think one of the best reviews I've read in recent memory is the Anandtech Database performance shootout (http://www.anandtech.com/IT/showdoc.aspx?i=1982). You present 2 competing architectures and use them in a real world environment to derive a solid conclusion. These are the types of benchmarks to use when comparing enterprise level hardware. And if you decide to use desktop level hardware, use benchmarks that users can relate with, including gaming benchmarks and the like. It's difficult to make a definitive statement comparing two products when the methodology is flawed. Synthetic benchmarks are just that, synthetic. The only way to use them is to compare to similar products, such as a Prescott from a Northwood, or an Athlon 64 to an Athlon XP. In any other case, it's always best to use real application benchmarks.
Unfortunately, I have to say that the review was simply a waste of my time. Why? Because unlike other Anandtech.com reviews, I came away knowing that I learned nothing from the review. Nothing in the review made sense, from the choice of processors, to the choice of benchmarks. It was very disapointing.
Sorry for the long post... just wanted to say what was on my mind...
tfranzese - Tuesday, August 10, 2004 - link
#166, it's a poor comparison anyway you slice it. Anandtech assumes most of it's readers are not who the PR rating is targeted at persuading. This has been made clear in the past. You don't compare by number but by price and by performance.ss284 - Tuesday, August 10, 2004 - link
Regarding post: 159 - Posted on Aug 10, 2004 at 3:12 AM by WiZzACkRJust mentioning that you seriously post in the [H]ardforums drops your credibility to 0. Saying that Hardocp, and especially the disgustingly bad hardocp forums come even close to Anandtech and its forums are an insult. Then again, your post seems of the typical hardforums quality, biased, and obviously written by that of a person who has done minimal research and has made huge sweeping assumptions.
Oh, and FIFI, insulting people loudly with the intent to attention only shows how much your typical, non insulting postings command no respect or deserve any thought whatsoever, and that the only way for you to get a reponse is to yell.
Another thing, people are still complaining about the comparison. He has already mentioned that this is the same thing as a 3.6. Last I checked it was AMD that came up with these processor ratings. Yet they dont seem to be taking any of the blame. A PR rating of 3500+ means its supposed to be competing with intel's p4 3.5, which doesnt exist. Kris took the nearest speed, a 3.6, and mentioned that in the review. Not to mention the favorable timings on the AMD system.
Its sad to see how many horribly biased morons are posting this crap. Yes, there were problems with the article, and Kris is actively trying to remedy it. He is even testing an opteron system per request. Yet people continue to flame. Maybe you should offer some constructive criticism instead of going off on lame conspiracy theories and dooming the fate of Anandtech. If this is seriously how you feel, dont bother posting anymore. If the content is that bad, dont bother reading it.
In every review, kris had paid attention to the comments, and even actively participates in the forums. He takes suggestions, and usually makes good on them. Give him some time, and I'm sure the article will satisfy at least half of you. Some fanatics will go crazy no matter what, whether AMD or Intel.
-Steve