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
Anemone - Monday, August 9, 2004 - link
I just can't help but wonder, if you already knew, by numerous tests, that the math ability of the A64 is leaps and bounds ahead of the P4 or Xeon, didn't you want to question your results?I know the P4EE and the A64's are often neck and neck in some tests (obviously not Doom3 haha) so I'm not going to be shocked if Xeons do well in some apps. But there are literally thousands of posts of pi tests (of the many flavors) in which the P4 is soundly trounced in every single one of them, and by a large margin. The Xeon even the EM64T version is just a Prescott core, and quite honestly its math ability should not be, even in 64bit mode, night and day different from its current results.
Anyway, have to at least say you stood by your convictions and stated things as they were presented to you. And hopefully more information will help us all to understand if maybe the Xeon at least does relatively well in 64 bit, which would be a nice bit of news I think.
$02
SDA - Monday, August 9, 2004 - link
Funny, it looks like you're testing the 3500+ in 32-bit mode, in MySQL Test-Select at least...http://images.anandtech.com/graphs/amd%20and%20lin...
http://images.anandtech.com/graphs/linux%20and%20e...
Decoder - Monday, August 9, 2004 - link
Hello Kristopher,Some people don't know how to articulate their thoughts properly, as we see in this thread.
Anyways, for your followup review please test the 64 bit implementations by AMD and Intel using more than 4 GB of rams. 6 or 8 GB will do nicely. I heard Intel implementation relies on software where as AMD's is 100% hardware and this is where AMD Opteron's shine and Intel's EM64T has performance issues.
Again, testing 64 bit mode with 1 gig's is probably not worth it.
Regards,
Decoder.
tfranzese - Monday, August 9, 2004 - link
Some of you, the very few of you, that cannot see the problem with the quality, consistency, and lack of comparisons in this article compared to not only other sites, but this one's as well seriously need your heads checked. It's that simple.tfranzese - Monday, August 9, 2004 - link
I don't visit Anandtech (or any site for that matter) if I weren't expecting well thought out and quality articles. I don't think many here visit to see rushed out numbers and editorials. I don't thank a publication that thrives on users reading their material for sub-par work. Publications survive thanks to the readers and not the other way around.mino - Monday, August 9, 2004 - link
manno: U're Idiot or Intel PR (You can choose your favourite).Kris: The best thing to do is to either: COMPLETELY rewrite or call in this BS U produced.
No Offence. I'm disgusted.
danidentity - Monday, August 9, 2004 - link
You all sound like a bunch of whiny little babies. It's amazing how many people come out of the woodwork when something puts AMD in a bad light. I'm actually laughing outloud reading these commments.As KK pointed out, the upcoming P4 3.6F will produce extremely similar numbers to the Xeon benched in this article.
The P4 3.6 is a comparable processor to the 3500+.
fritz64 - Monday, August 9, 2004 - link
Hello Kristopher,I have been a silent member on this forum since I registered but this article made me search for my password in order to make a comment. You guys at Anandtech have been doing a good job of keeping us informed about capabilities of current day computer hardware. However this current review need serious attention and should be immediately considered based on the various opinion expressed in the forum.
I love to see more of number crunching on real applications using 32/64 bit set up. I mean 32-bit OS/32-bit compiler and 32-bit/64-bit AMD vs Intel.
As for the current review. I think the idea of using the installed Suse Linux OS 9.1 is not a real test of a hardware capability. The OS should be compiled for the best performance optimization on both Intel and AMD platform. Further, the use of 32-bit compiler for AMD Athlon 3500+ does not make use of its 16 registers and thus cripple it's performance a little bit. For best performance, Since Intel writes optimize compiler for their CPUs, I will suggest that you get the best compiler for the Intel system and bench it against the best compiler for AThlon 64 which is undoubtedly the PATHSCALE COMPILER SUITE ( YOU CAN GET A 30-DAY FREE DOWNLOAD VERSION AT www.pathscale.com). Whether the 30-day trial version consist of all the necessary optimization is what I don't know. However the PATHSCALE compiler gives the best SpecInt score that blows the Itanium2 away.
TauCeti - Monday, August 9, 2004 - link
to #74"Look they stuck their head out and released some early numbers, and rather than thank them for doing it, people are throwing tomatoes at them."
I wish i could agree with you, but:
Well, if the numbers are that early that you do not detect obviously wrong results, you should at least inform your readers that you have no idea at all what your benchmark results mean.
I mean: The TSCP Bench on the 3500+ produced a score BELOW 1.0. IF you use that arcane bench you should at least wonder why your 3500+ performs worse then a 2000+.
I cannot understand how one could publish a TSCP score below 1.0 without any comment on that.
FYI: TSCP defines score 1.0 (about 243k nodes/sec):
/* Score: 1.000 = my Athlon XP 2000+ */
Tau
fritz64 - Monday, August 9, 2004 - link
Hello,Testing. Please ignore