Benchmarks I
Ignoring SiSoft SANDRA's memory benchmark due to the number of different chipsets involved, I'll start the benchmarking with Pifast. As you should by now know, it simply calculates the constant Pi to 10 million places. CPU power and masses of available bandwidth are keys here.
At stock, the Celeron 2GHz just beats out the XP1600, but gets given the run around by the 2.26GHz Northwood P4. Ramping up the clock to 3.15GHz and increasing available memory bandwidth firmly puts it in the P4 2.8 and XP2700+ territory. It appears, that in this test at least, the lack of L2 cache is not a detrimental factor with respect to performance. The operating code is small enough not to be adversely affected by the 128kb of cache. The results bore this out.
How about MP3 encoding using LAME and U2's Pop album. Crunched into 192kb/s MP3, the 600MB+ of WAV files should take a little while to compress.
What do we see here ?. The overclocked Celeron takes top honours above the P4 2.8 and XP2700+ (stock, of course). Once again, MP3 encoding benefits little from having data stored in L1 or L2 cache: it's more of a streaming process. Sheer clockspeed is what you need here.
On to DVD-to-DivX encoding using DivX4.12 and VDub 1.4.10. Benchmarked using a 2-pass encoding of Gone in 60 seconds with the video bitrate set to 1800kb/s. An average is calculated when the first VOB is complete.
The architecture behind the P4 / Celeron 2GHz processor lends itself well to DVD encoding. The stock Celeron puts daylight between it and the XP1600, and the overclcoked Celeron running with massive memory bandwidth (210MHz, 420MHz DDR @ CAS2) eclipses the benchmarks laid down by the XP2700+. The PC1066 RAMBUS-powered P4 2.8 stomps on the rest. Again, the streaming nature of this benchmark, where code isn't reused on a repeating basis, lends itself to pure clockspeed.
So far so good. How about SETI ?. SETI works from a large dataset with code being reused on a continual basis. Let's see how our protagonists do.
There is no mistake in the graph presented above. I reran the benchmark on the Celeron twice. Why is it so slow when it has been reasonably good in other benchmarks ?. The answer lies in the lack of L2 cache. SETI just loves fast memory and lots of on-board cache. By loading as much of the operational code as we can into the cache, we negate the need to go back into main system memory on a frequent basis. As the computations used in SETI are used over and over again, having the required code in L2 is paramount to achieving a fast time. The Northwood P4, with 512kb of L2 cache can load 4x the amount of operational data into L2 that the 128kb Celeron can. That's why Alpha processors with MBs of on-board cache are so good at SETI. If SETI is your thing, the Celeron isn't for you. Here, with respect to P4-based processors, cache is king.
