Linux and L2 Cache; Sempron vs. Athlon
by Kristopher Kubicki on August 18, 2004 2:29 AM EST- Posted in
- Linux
John The Ripper
We used John the Ripper (JTR) 1.6.37 as a loose benchmark of encryption/hashing. The 1.6 "stable" branch for JTR is actually very dated, so we used the much more updated 1.6.37 tree instead. There are fewer hand coded ASM routines in the 1.6.37 release which allows us to better directly compare our processors.
Just like the chess benchmarks from before, we used four different configurations to compile JTR. The first configuration is identical to "make linux-x86-any-elf" target.
- Configuration 1.) -O2
- Configuration 2.) -O3
- Configuration 3.) -O2 -march
- Configuration 4.) -O3 -march
Obviously, we used the athlon arch flag for the Athlon XP processor and k8 for the Athlon 64.
![John The Ripper 1.6.37 - DES [24/32 4K]](https://images.anandtech.com/graphs/linux and l2 cache sempron vs _081704110838/3577.png)
![John The Ripper 1.6.37 - Blowfish (x32) [32/64]](https://images.anandtech.com/graphs/linux and l2 cache sempron vs _081704110838/3578.png)
![John The Ripper 1.6.37 - MD5 [32/64 X2]](https://images.anandtech.com/graphs/linux and l2 cache sempron vs _081704110838/3579.png)
It is likely that JTR uses some optimized ASM code for the Athlon XP, which is why we see such good marks for a two year old CPU.
OpenSSL
The most comprehensive OpenSSL "speed" benchmarks can be downloaded as separate text files (Athlon 2200+, Athlon 64 3000+, Sempron 3100+) but we also provided some graphical mappings below.
The AES speed test scales very well across AMD's budget computing line, and we really see the additional L2 cache increasing thoroughput. However, we go down one graph to see that signing RSA keys had very little performance increase with the 512KB L2 cache.
Facebook
Twitter
RSS
59 Comments
View All Comments
AnonymouseUser - Wednesday, August 18, 2004 - link
Yes, more everyday apps for benches, please. I wanna know which of the CPUs will be fastest to compromise Windows XP on a fresh install, how fast XP can install IE toolbars and Comet Cursor, how many IE and Messenger popups can be done in one minute, how long it takes to run a full system virus and spyware scan, etc. Also, I need to know which one boots fastest for all the reboots necessary. :)FWIW, I think the XP 2200+ is a good choice for comparison. Same clock speed and cache of the Sempron 3100+ shows how much better the new core is.
phaxmohdem - Wednesday, August 18, 2004 - link
I would love to see an old school 1.8 GHz P4 400 FSB pitted against these processors. Not quite fair I know, but I like seeing how incredibly crappy those old p4s were. Clock for clock comparisons interest me though, good article, however as sems to be the general concensus, mre everyday apps would be helpfull for benchmarks.Illissius - Wednesday, August 18, 2004 - link
It's not a bad review, but I don't entirely get the point (or rather, entirely don't). Using Linux makes good sense when you're benching either 64-bit and/or server processors, but this was neither. Most people who're actually deciding between an A64 2800+ and a Sempron 3100+ would've been much more interested in your standard benchmark suite of desktop applications and games.TauCeti - Wednesday, August 18, 2004 - link
First: kudos for the new comparison. I would imagine myself still cursing (and worse) the unfair readers after the recent onslaught ;)Second: TSCP/SSE2
Ok, i admit that i ditched compiler lectures at university BUT: Did GCC really generate SSE2-code for the TSCP sources?
You wrote that you ommitted the XP scores because of SSE2. Did you check if SSE2 code was generated on the AMD64s?
I checked TSCP source but i have no idea where the compiler would opt to use SSE2 at all.
PLease give me a hint (this is not ironic, i really want to know how the compiler managed to use SSE2 for TSCP)
Tau
johnsonx - Wednesday, August 18, 2004 - link
In general, I found all the graphs to be oddly arranged. Since the point of the article was to compare the Sempron 3100+ to the A64 2800+, it would have been a little clearly if those two had always been graphed together. As it stands now, the 3100+ was always at the top of the multi-bar graphs, followed by the 3000+, then the 2800+ and finally the AXP. I kept having to jump over the 3000+ scores to see the benefit (or lack thereof) of the 512k cache. In general, I think the order of the graphs should be the same throughout the article, and any chip(s) that are the particular highlight of the article should be group together somehow.Secondly, I'd like to second the suggestion that an AthlonXP 2500+ would have made an interesting point of comparison as well, though I do realize the 1.8Ghz Socket-754 were in fact the point of the article.
Regards,
Dave
DerwenArtos12 - Wednesday, August 18, 2004 - link
I really wish you had included the Athlon XP 2500+ barton as a reference cpu as it runs at 1.83ghz on the socket A platform and has a 333fsb wich is easir to bomapre to the 400fsb A64 and 400fsb Sempron 3100+. plus that woudl give an idea of how the cache per platform makes a difference as it has the 512k l2 cache to compare to the 256 L2 on the 2200+ plus the core revisions of going to barton give a better idea of current competitors. teh 2200+ is in a completely different price range than the other three processors here where the 2500+ would also closer there. Just my opinion. but I think it would have added a much better current market perfomance comparison.skiboysteve - Wednesday, August 18, 2004 - link
on your Gzip bench the graph is ordered oddskiboysteve - Wednesday, August 18, 2004 - link
wierdKristopherKubicki - Wednesday, August 18, 2004 - link
Something happened to the document engine and the article posted while I was still working on it. That has been fixed.Kristopher