Linux and L2 Cache; Sempron vs. Athlon
by Kristopher Kubicki on August 18, 2004 2:29 AM EST- Posted in
- Linux
Opstone
Blue Sail Software's Opstone benchmarks were used in this portion of the review. We will use the Athlon XP 32-bit precompiled optimized binaries of the Scalar Product (SP) and Sparce Scalar Product (SSP) benchmark. Unfortunately, this means the Athlon 64 does not receive the benifit of SSE2 in this benchmark. The SP benchmark is explained by the author:
"The 'SP' benchmark calculates the scalar product (dot product) of 2 vectors ranging in size from 16 elements to 1048576 elements for both single and double-precision floats. Although the Gflops/sec. for every vector length is recorded (in the resulting output log file), the average of all these values is reported. This benchmark is indicative of the performance of many raw floating-point data processing apps (movie format conversion, MP3 extraction, etc.)"
The integer intensity scalar product benchmark is relatively unscathed by the difference in L2 cache, with the exception of a slightly higher sustained mean GFlops.
Below is the SSP benchmark, as explained by the author:
"The 'ssp' benchmark also calculates the scalar product of 2 vectors, except that these vectors are sparsely populated (only the non-zero value elements are stored) ranging from a 'loading factor' (non-zero/zero elements) of 0.000001 to 0.01 for both single and double-precision floats. Since the data is not contiguous in memory, the performance is much lower than regular 'sp' and is measured in Mflops/sec. There is not much difference in performance between different loading factors as this benchmark really challenges the ability of the processor to perform short bursts of calculations coupled with lots of conditional testing. It is this reason that the P4 with its longer pipeline does not generally perform as well as the Athlon64. This benchmark is indicative of the performance of many 3D games as the processing is similar (short bursts of calculations with numerous conditional testing)"
Floating point operation scales much better than integer processing if we are to trust Opstone. All three processors scale in the same order of their price range, although the AMD PR rating obviously does not hold on this benchmark.
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