Benchmarks for 24.12

[geoff]

Originally Posted by PhilF

At this point, as another sanity check, I would like to invite anyone else reading this thread who has a 128K L2 Celeron to run a benckmark and report it here.

A further note to this benchmark http://www.mersenneforum.org/showpos...0&postcount=88:
90% of the time when I start mprime on this machine it runs at the speed in this benchmark (actually faster now as I have overclocked it), but the other 10% of starts it runs much slower, sometimes 30-40% slower.

Once running it keeps running at the same speed it started at, so the first time I start mprime I check that it is running at full speed and if not I stop and then restart until it is.

Other programs I run on this machine (mainly gmp-ecm) don't display this behaviour. It is running Linux so I can't do a benchmark with the test program.

[PhilF]

George,

I put a P4 1.7Ghz Northwood with 256K L2 cache in the same board that has been running the 2.8Ghz Celeron we have been discussing here. Times were better, but still below where they should be. I did some checking, and discovered Windows XP was using some driver of its own for the integrated VGA. After loading the proper VGA drivers, the iteration times improved considerably. I thought I was on to something, so I re-installed the 2.8G Celeron. Now it is even slower than it was before!

So I have given up on the 128K Celeron, but I will post the new benchmark for it if you want. The benchmark attached to this post is the one for the P4 1.7Ghz 256K cache. If you would like the FullBench=1 version for this processor, let me know.

I feel like I have been leading you on a wild goose chase. On the other hand, it is possible the memory performance of this board is so bad that any differences in cache optimization will be exaggerated, making it easier to spot.

[sdbardwick]

Benchmark results for C2200 attached

[koekie]

Benchmarks for a P-IV 2,8Ghz with 1MB L2 (HP Cpmpaq d330 DT) 512MB ram

[ric]

... running 2003 SP1. If of any interest, I've results for the benchmark of TST2 as well (but at first sight, they look the same).

[Prime95]

Thanks everyone. I have enough data to analyze for now. I'm going to add a 10 level pass 2 option mainly for 128KB caches.

I need to understand pass 1 cache behavior better. It is not working quite as I expected.

We'll probably do this again soon.

[PhilF]

George, just an FYI. I find this quite interesting.

The 2.8Ghz 128K Celeron with such lousy P95 performance will encode 30 minutes of video in 5 hours.

It takes the much better for P95 1.7Ghz 256K P4 7 hours to encode that same video.

[TheJudger]

FFT-Size 32MB? OMFG

so we can do M79.300.000 in 4MB FFT,
so I expect we can do M600.000.000 with 32MB FFT

From ric's 3GHz Xeon benchmark I can read around 1.77s per iteration...
so one Test with an exponent around 600.000.000 will last ~34 years ;)

[ric]

Originally Posted by TheJudger

From ric's 3GHz Xeon benchmark I can read around 1.77s per iteration...
so one Test with an exponent around 600.000.000 will last ~34 years ;)

PRESTO!
I need to start right now, if I want to see the result (given average life duration) ;-P

[Dresdenboy]

Originally Posted by PhilF

George, just an FYI. I find this quite interesting.

The 2.8Ghz 128K Celeron with such lousy P95 performance will encode 30 minutes of video in 5 hours.

It takes the much better for P95 1.7Ghz 256K P4 7 hours to encode that same video.

You found out, that different algorithms with different behaviour regarding memory accesses, calculations or the like, can show different results on different cores with different cache configurations (size and latency)

I suppose, such video encoding kernels are mostly optimized for L1 cache usage and throughput. The Northwood-based 128K Celeron has a faster but smaller L1 cache and a much higher clock speed than the Prescott-based 256k Celeron and it's core (Northwood) has a somewhat higher average performance per clock (especially with the 512kB L2 vs. 1MB L2 models).

OTOH every not cached data will cause a delay. And if an algorithm needs more cache than another, it may be hurt much more, if the cache is smaller. So, what you saw, is a normal situation in the world of CPUs

BTW, the integrated video steals bandwith from apps like Prime95. So try to use low resolutions with low refresh rate and less colors to improve iteration times. Maybe that was, what changed the iteration times after the driver change. Just remember, that drivers included with Windows are also written by the hardware vendors, not Microsoft.

[PhilF]

Originally Posted by Dresdenboy

BTW, the integrated video steals bandwith from apps like Prime95. So try to use low resolutions with low refresh rate and less colors to improve iteration times. Maybe that was, what changed the iteration times after the driver change. Just remember, that drivers included with Windows are also written by the hardware vendors, not Microsoft.

Good points. But with that 128K Celeron, iteration times were still absolutely horrible even when booted with text based linux and using mprime. I think the only hope for 128K Celerons (especially when used with a motherboard with slow memory) is for George to figure out a way to better optimize the code for such a small cache.

I suppose I could try disabling the integrated video and installing a PCI video card, but I do remember trying the Celeron on another motherboard that did not have integrated video and getting about the same iteration times.

I did some more speed comparisons, and came up with the following:
---------------------------------------

2.8Ghz Celeron, 128K L2 cache:

1792K FFT iteration time: 243 ms.
5 hours to encode 30 minutes of video.

---------------------------------------

1.7Ghz P4, 256K L2 cache:

1792K FFT iteration time: 146 ms.
7.5 hours to encode 30 minutes of video.

---------------------------------------
To me, these are amazing differences.