Linux Shootout: Opteron 150 vs. Xeon 3.6 Nocona
by Kristopher Kubicki on August 12, 2004 2:35 PM EST- Posted in
- Linux
Our preliminary look at Intel's 64-bit Xeon 3.6GHz Nocona (which happens to be identical to the Intel 3.6F Pentium 4) stirred up a bit of controversy. The largest two concerns were:
- We tested Intel's Xeon server processor against an Athlon desktop CPU.
- We chose poor benchmarks to illustrate the capabilities of those processors.
Fortunately, with the help of the other editors at AnandTech, we managed to reproduce an entire retest of the Nocona platform and an Opteron 150 CPU. We also managed to find an internet connection stable enough for this editor to redraft en entire performance analysis on his vacation.
| Performance Test Configuration | |
| Processor(s): | AMD Opteron
150 (130nm, 2.4GHz, 1MB L2 Cache) Intel Xeon 3.6GHz (90nm, 1MB L2 Cache) |
| RAM: | 2 x 512MB PC-3200 CL2 (400MHz) Registered 2 x 512MB PC2-3200 CL3 (400MHz) Registered |
| Memory Timings: | Default |
| Operating System(s): | SuSE 9.1 Professional (64 bit) Linux 2.6.4-52-default Linux 2.6.4-52-smp |
| Compiler: | linux:~ # gcc -v Reading specs from /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib64 --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 3.3.3 (SuSE Linux) |
| Libraries: | linux:~ # /lib/libc.so.6
GNU C Library stable release version 2.3.3
(20040405), by Roland McGrath et al.
Copyright (C) 2004 Free Software Foundation,
Inc.
This is free software; see the source for
copying conditions.
There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 3.3.3 (SuSE
Linux).
Compiled on a Linux 2.6.4 system on 2004-04-05.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael
Glad and others
linuxthreads-0.10 by Xavier Leroy
GNU Libidn by Simon Josefsson
NoVersion patch for broken glibc
2.0 binaries
BIND-8.2.3-T5B
libthread_db work sponsored by
Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by
Thorsten Kukuk
Thread-local storage support included.
Report bugs using the `glibcbug' script
to |
The Intel Xeon 3.6GHz has HyperThreading enabled by default, so we use that
with the SMP kernel during the review. The entire review uses 64-bit binaries
either compiled from scratch or as installed from RPM. We only used a 32-bit
benchmark during the synthetic analysis, but still on SuSE 9.1 Pro (x86-64).
As one reader has pointed out, the GCC 3.3.3 used in this review has a few back ported optimizations from GCC 3.4.1 care of the SuSE development team. Thus, architecture specific optimizations for nocona are included.
Special thanks to Super Micro for getting us additional Intel components
for testing on such short notice!
Facebook
Twitter
RSS
92 Comments
View All Comments
adiposity - Thursday, August 12, 2004 - link
> From looking at the graphs, it becomes easy to> see why JTR makes a difficult program to use as
> a benchmark. Had we left the default -O2
> compilation, Blowfish hashing would have been
> faster on the Xeon processor than the Opteron.
> However, as soon as we use -O3, the Opteron
> outperforms the Xeon processor.
Um, no it doesn't. The opteron continues to lose, even with the -O3 optimization. In fact, -O3 doesn't seem to help either significantly in any of the JTR benchmarks.
-O2: Xeon wins 481 to 419
-O3: Xeon wins 478 to 420
Of course, Opteron wins the rest, and -O3 doesn't seem to matter there, either.
-Dan
Dranzerk - Thursday, August 12, 2004 - link
Kris glad you included Crafty chess program into review. If you want to address anything dealing with the Program (like test wise) you can contact Dr. Robert Hyatt directly through ICC (Internet chess club, free to use if you log on as a Guest) he is online there as the name Hyatt.He is very easy to talk to about crafty if you need help.
douglar - Thursday, August 12, 2004 - link
The one thing that I really see in these benchmarks is how much Intel is suffering when they are trying to run AMD64 optimized code. Normally intel makes the spec for new instructions before AMD impliments, the compiler writers and software coders take advantage of Intel's peculiaries and then AMD has to build the functionality with the same peculiaries as the intel implimentation if they want to compete. Look at most SSE2 benchmarks. I think AMD is at a disadvantage having had to back fit the instructions using the existing CPU op units.This time it looks like intel is getting a taste of their own bitter medicine, trying to make 32bit integer units look and perform like 64bit units to the outside world, if the rumors about intel's 64bit implimentation are true. Now it will be interesting to see if compiler writers and software coders will (or are able to) go back to the drawing board and make this round of intel chips perform up to the strong initial AMD 64 bit performance baseline.
I'm guessing that there will be a 64 bit performance gap (larger than the 32 bit gap) until intel respins the silicon a couple times. I look at this round of 64bit intel chips as like a em64sx, in reference to the 386sx, even though the 386sx was 32 internally an 16 externally, kind of the opposite of having 64bit registers and 32bit ops units, but perhaps still an appropriate analogy.
Macro2 - Thursday, August 12, 2004 - link
Kris,I have to hand it to you, you took a lickin' and kept on tickin'. I realize it's pathetic that in order to do a review you have to literally dissect every benchmark for "fuzzy" code but that's the way it is. Got to do the homework and if it's out of the realm om your expertise yoou have to ask other. Remember, benchmarks are for liars.
That said, you'll probably turn out to be the best comparitive benchmark reviewer on the internet.
Mac
mrdoubleb - Thursday, August 12, 2004 - link
Good job, Kris!1, Now I'd just like to point out, that it's not like nobody is complaining now becouse this time AMD wins. This time around the processor choice was ok and, as much as I see from the opinions of readers who are much better informed in the server/linux world than me, the benchmark choice/execution was great, too.
2, I know you're off to your vacation now (by the way, have a good time!), bat later it would be interesting if you managed to do a 2 and/or 4 processor setup with Noconas and opteron 250/850s as well. As far as i know, Opteron's biggest advantage was its excellent scalability. Opteron's advantage used to grow immensly. Does this change with the new Noconas?
3, I saw this at another HW site: on the final page of their reviews they have a chart where they list all the benchmarks once more and show with a percentage number how faster/slower a processor is compare to its rival. E.g. you take the nocona as 100% (or zero) and list for every benchmark how faster/slower Opteron was. (Say, +25% or -37%).
4, As for pos #36 by kaoman. I think that if they had compared 2 desktop processors, than we wouldn't have seen any of these benchmarks, save for Lame. We would have seen office, gaming, AV, and rendering benchmarks. And about the price: let's wait for it, shall we?! By the time Prescott 3.6F is available, 90nm A64 is out, which might also be tweaked, if the rumor mill is right, and it will also be cheaper for AMD to produce, so it might be cheaper for us as well.
Have great holiday, Kris!
kresek - Thursday, August 12, 2004 - link
Thanks for the SSL benches.Especially useful are 1024+ bits RSA/DSA sign/verify figures (at the bottom), digests: MD5 or SHA-1, and popular ciphers, like RC4, blowfish. Take 1024 bytes or bigger blocks, and you have valuable, easy to visualize comparison information.
Pjotr - Thursday, August 12, 2004 - link
""Now will all of you A-Holes get off KrizK's & AT editorial staff's back!!"HAHHAHAHAHAHA I'm laughing my ass off.
Great Job getting in the first post, and a good first post at that."
I don't think it was a good post. Calling people with valid views, that even the author acknowledged, "A-holes" is just blunt and irrelevant.
skiboysteve - Thursday, August 12, 2004 - link
great review, glad to see you take the readers to heart.Pjotr - Thursday, August 12, 2004 - link
Great job, Kris, and thanks to Super Micro! It's good to see when people don't just hide, but both listen and respond. I was ready to remove Anand from my bookmarks like I did with Tom's years ago, but it's staying now.Soultrap - Thursday, August 12, 2004 - link
Kris,Awsome! You took it like a man, and I think that all of us learned from your hard work including the errors in it. I feel that you did your abosolute best to accomodate & listen to your readers, correct your errors, and produce an unbiased evaluation.
There is nothing anybody can do about their mistakes except do their best to correct them and learn from them.
After reading these posts to your new article I am sure that you blood preasure has dropped greatly. Harsh (un)constructive criticism can be very difficult to take.
Good work!