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
dke - Monday, August 9, 2004 - link
Hi, I just read this comparison betweenthe Xeon 3.6 (Nocona) and the Athlon 64 3500+. This is from an e-mail I sent out earlier today and I didn't want to re-write it again. Here it is:
"I started reading
AnandTech's article and noticed that on the third page they have a
little note that says:
"Our Nocona server was setup in a remote location with little access,
so we had limited time to run as many real world benchmarks as we are
typically accustomed to. Fortunately, there are multitudes of
synthetic benchmarks that we can use to deduce information quickly and
constructively."
This seems to contradict the statements they made in the first
paragraph of the first page of the review:
"... we found ourselves fairly entertained to come into the possession
of a 3.6GHz EM64T Xeon processor. ..."
What does that mean?
Unless I am not understanding this correctly, is sounds like
AnandTech's reviewers didn't have local access to the computer that
they were using to benchmark the Nocona. Does that mean that they
didn't have local access to the computer for [any] of their benchmarks,
or only the synthetic ones? If that's true, I don't think this can be
a trusted review. Who would setup a Nocona server for AnandTech to
"review"? Intel? I can see that...
Intel: "we equipped this machine with the following specs, xxxxxx. we
promise..."
Right.
This article just seems questionable to me, and I remain fairly
skeptical about how accurate this review/comparison is. If AnandTech
didn't have local access to the machine, how can anyone be certain
that the system's specs are what AnandTech claims they are? How can
AnandTech's reviewers themselves be certain? [The benchmarks given in this comparison do not duplicate previous benchmarks using the same hardware as well as the same benchmarking software.] It's not that I think
AnandTech is feeding us misinformation, but I question the information
given to them by this mysterious third party [who has local access to
the machine?]."
I just don't understand and I would like an official response from AnandTech. I don't care to hear Intel fangirls respond to my question. They don't know anything more than I do. I can read enough sarcasm and smart-arse comments on this board without any new sarcastic responses to this post.
Thank you.
David K.
ThunderPC - Monday, August 9, 2004 - link
Nice way to generate site hits by making the entire "techy" world come by for a good dose of laughter at the "comparison".Graphic67 - Monday, August 9, 2004 - link
Keep in mind that Mr. Kubicki is the "Senior Display, Optical Storage and Linux Editor" and from a listing of available articles he has not done a CPU review before.AnandTech had a reputation of quality over quantity (or speed) which made the articles that much more worthwhile to read. "Quick and dirty" as an earlier post called this review is a phrase which would normally not be applicable to an AnandTech posting.
ThunderPC - Monday, August 9, 2004 - link
Like everyone else has said, the worst review I have seen since boycotting Tom's hardware. I am completely unbiased on processor manufacturer, and have a relatively new Intel and AMD system. That being said, why the #$%( are we comparing these two processors? How much did Intel pay you to do such a lopsided test? I have a Kyro video card sitting in a box if you care to test it against a 6800 :Dsnorre - Monday, August 9, 2004 - link
This bad review really have created a big buzz. People are debating it heavily over at Ace's Hardware:http://www.aceshardware.com/forum?read=115093783
This review should never have been published, and if it dosen't get removed of fixed soon Anandtech will for ever lose its credibility and join the line of biased sites like Tom's Hardware & Extreme Tech.
Viditor - Monday, August 9, 2004 - link
johnsonx - "The memory thing too.... if the benchmarks in question don't need more than 1Gb of ram, then why isn't 1Gb enough? Is there some magic of 64-bit systems where having 13267432Gb of RAM somehow makes them faster? Of course not."A reasonable question...
The reason that memory is questioned is that the Nocona has no hardware IOMMU. This means that when using larger amounts of memory (3 Gig+), the Nocona (and all other EMT64 chips) will actually start to slow down.
schemer - Monday, August 9, 2004 - link
AnandTech! Did you try benchmarking KristopherKubicki against a Blonde?coldpower27 - Monday, August 9, 2004 - link
I believe benching the Opteron 150, would have been a fairer choice like I said.
I also don't beleive the 512KB of cache vs 1Mb of cache holds any water, because of the fact that the Netburst Prescott has to make due with 16KB of LV1 cache while the Athlon 64 gets 128KB of it which is 8 times more :S
I am also not all that sure if the Opteron 150 will be all that much faster then the Athlon 64 3500+ considering it has to work with registered memory and 600MHZ HT.
Comparing AMD's K8's and Intel Netburst Architecture has been always Apples to Oranges. you couldn't really compare Apples to Apples anyway with how different these 2 architectures are.
mkruer - Monday, August 9, 2004 - link
to add more flamebait, you got to love this quote"Since the excuse to not compare Athlon 64s to Intel Pentium based processors has always been "you can't compare apples to oranges,""
so now hes comparing oranges to apples.
Snoop - Monday, August 9, 2004 - link
Kristopher,Are you going to defend this article? It seems that your silence to these charges speaks for itself. If you cannot dispute these claims, then remove the article.