L2-cache off result: 6.8 credits per hour.
Average for 40 samples (including the above result): 13.02.
In the last few days I also got another low result, so it may just be "bad luck".

I confirmed that my hack to disable the L2 cache works by measuring the speed of a memcpy() with varying size of data, and it's about half as fast as the corresponding memcpy on a comparable machine without L2-disabling hack.

As to me being "classical education", no, I'm not educated at all - at least not in computer architecture or such - I've just worked closely to processors and such for a long time - on the software side, but close to the hardware (often working with actual hardware/software interface and writing code to excercise some particular hardware interface or features).

I'll leave this machine running without L2-cache for a little longer, to see what happens.

--
Mats

Just to further declare "dead" the theory of L2-cache "harming" the performance of Rosetta: The machine that had an average of 13 credits per hour has on the last five finished results got (credit per hour):
6.84
7.88
7.75
7.16
6.84
8.85

I'm going to switch the L2 cache back on now...

--
Mats

---

Just to further declare "dead" the theory of L2-cache "harming" the performance of Rosetta: The machine that had an average of 13 credits per hour has on the last five finished results got ...

Provin the point for that CPU and L2 cache only.

A program that spilled over the cache size in its innermost loops would give the opposite result.

It is good to do the test - but the outcome only applies to that combination of cache size, cache speed, memory speed, and chip clock speed. For a given type of WU I'd expect the result of such a test to come down quite clearly one way or the other. Four or five tries is a fair test.

R~~