Linux and EM64T; Intel's 64-bit Suggestion
by Kristopher Kubicki on August 9, 2004 12:05 AM EST- Posted in
- Linux
John the Ripper
Out of all of our synthetic benchmarks, John the Ripper is perhaps the most robust; we can benchmark a wide range of encryption algorithms with many or no options very easily and quickly. For this benchmark, we downloaded John the Ripper 1.6. We had originally intended to build the program with the generic Linux make configuration. Unfortunately, John did not want to play nicely with that idea. We only ran the Intel CPU with HyperThreading for this portion of the benchmark.linux:~/john-1.6/src # make linux-x86-any-elf
ln -sf x86-any.h arch.h
make ../run/john ../run/unshadow ../run/unafs ../run/unique \
JOHN_OBJS="DES_fmt.o DES_std.o BSDI_fmt.o MD5_fmt.o MD5_std.o BF_fmt.o BF_std.o AFS_fmt.o LM_fmt.o batch.o bench.o charset.o common.o compiler.o config.o cracker.o external.o formats.o getopt.o idle.o inc.o john.o list.o loader.o logger.o math.o memory.o misc.o options.o params.o path.o recovery.o rpp.o rules.o signals.o single.o status.o tty.o wordlist.o unshadow.o unafs.o unique.o x86.o" \
CFLAGS="-c -Wall -O2 -fomit-frame-pointer -m486"
make[1]: Entering directory '/root/john-1.6/src'
gcc -c -Wall -O2 -fomit-frame-pointer -m486 -funroll-loops DES_fmt.c
'-m486' is deprecated. Use '-march=i486' or '-mcpu=i486' instead.
cc1: error: CPU you selected does not support x86-64 instruction set
make[1]: *** [DES_fmt.o] Error 1
make[1]: Leaving directory '/root/john-1.6/src'
make: *** [linux-x86-any-elf] Error 2
Undeterred, we proceeded to build John with the generic configuration instead. John optimizes itself during the build, so you may view the builds of each configuration here (Intel) and here (AMD).
For those of you who downloaded the text files, you already know that the Intel CPU has pulled ahead, at least according to John. Below are some of the scores John posted while testing the utility.
As we saw in the intensive math benchmarks, the Athlon 64 has trouble keeping up with the Intel CPU.
Facebook
Twitter
RSS
275 Comments
View All Comments
kresek - Thursday, August 12, 2004 - link
Kris, how about the OpenSSL benchmark?Among others, RSA, DSA and AES-128 show nice performance boosts for AMD64, so it would be interesting to see how a EM64T capable chip performs in 32/64 bit modes.
BTW it does not take much time to complete ;)
JGunther - Thursday, August 12, 2004 - link
It's now past noon in half the country. :(splice - Thursday, August 12, 2004 - link
#261What the hell are you talking about? A free review? What site makes you pay to see there review of hardware? Don't forget Anandtech is partly, if not mostly, funded by it's readers and forum members! Ever notice those banner/dealtime ads and forums ads?
Kris' review was sloppy and skewed. He needs to make it right. He owes it to his readers and his boss! Otherwise, it's going to look like Anandtech could care less about what it publishes.
nastyemu25 - Thursday, August 12, 2004 - link
The message is clear: it's noon.Aileur - Thursday, August 12, 2004 - link
Its crazy how ungrateful you all are, he spends time on his vacation to please all of you whiners and all of you are complaining your free review isnt on time to the second.KristopherKubicki - Thursday, August 12, 2004 - link
The review is finished, I cannot post it until Noon though because we had another review go live instead. I am just about to get on the plane to go home anyway. Just wait a few more hours.Kristopher
offtangent - Thursday, August 12, 2004 - link
Ok, its been a lot more than 24 hours now ... is an actual report expected any time soon?snorre - Thursday, August 12, 2004 - link
Still no new review?!Kristopher: You should've also tested ApacheBench as well as compile times for the Linux kernal.
A proper review should at least compare 32-bit vs. 64-bit and 64-bit vs. 64-bit performance for both the Xeon 3.6GHz EM64T and Opteron 150 AMD64 processors.
gnuorder - Thursday, August 12, 2004 - link
This review is so poor, I'm sure it's not an attempt to skew the results. It looks to me to be a rushed review and a lack of understanding of the platform on which the testing was done.First you have the CPU selection. A server CPU that is not in hand as a stand in for a CPU that hasn't been released yet vs a chip that has been around and is most likely at it's EOL. This wouldn't be a problem for me if we are constantly reminded of this fact and no conclusions are drawn.
Second, The tests are done on a linux platform, which supports 64 bit but has to be tuned for 64 bit. It's a fair platform since 64 bit windows isn't ready but you have to know what you are doing. I think this was new to the author.
Third, tests should be selected carefully to either try and isolate certain aspects of each CPU or try and broadly select all aspects of the CPUs evenly. knowing what the test is actually doing helps out a lot. To the author's credit, he has source code and his binaries available for others to use. I dont think he knew what his various tests were doing, though, so conclusions based on them were meaningless.
Fourth, optimize for each platform or find a common optimization to test on. People are interested in both. Some will run off the shelf software that will be compiled to run on both, others will run software they can tweak for one CPU or the other and would be interested in seeing how far either CPU can be tweaked. What you can't do is run a test on both when it's tweaked for one and not the other. Again, I dont think the author knew how to tweak it, thus his confussion over the compile error he got.
One other note to those who think people are whining only because AMD lost, There have been many fair reviews pitting Intel vs AMD where AMD has lost and you didn't get this kind of response.
I don't think this review was meant to be a head to head test but it does have serious flaws that can't just be addressed by changing a few of the results. I think the article should be pulled and the tests re-done. This time don't rush through it to get it done before a vacation. We can all wait for a thoughtful review that gives us deep insight. This one does us no good.
Since the review is on a new mid-range desktop CPU, compare 2 new mid-range desktop CPUs on desktop motherboards with other mid-range desktop hardware. You can also throw in other CPUs and run 32bit vs 64bit tests as well but at least have 2 pretty well matched systems, and both in your control. Since it is desktop, run some typical desktop benchmarks along with your speciallized synthetic tests.
You serve the desktop users (gamers) better if they know how well doom3 or their favorite app is going to run on CPU x and how they can tweak it to run better. Using mathmatic or database tests on what is to be a desktop CPU on the desktop server is meaningless especially since you have a server platform as a stand in for one CPU.
Well I'm trying to end this but I keep thinking of more flaws to comment on and it's turning into another rant. It is just an awful review but let's give the author a chance to redeem himself.
cdo - Thursday, August 12, 2004 - link