Windows S5R3 "power users" App 4.26 available

Most definitely not less. Much of the speed increase originates from going back to an older version of the Microsoft compiler that avoids generating some instruction patterns that are extremely costly on at least P6, K8 and even recent Core(2) microarchitecture CPUs, a so called store-forwarding stall.

For the curious:

Simplified, that code pattern would look like this:

...
- write a double word (32 bits) to address x
- write another double word to address x+4
- maybe do something else, but at most a few instructions
- read a quad word (64 bits) from address x
...

(so basically: reading 64 bits from a memory location that was written to shortly before, but in two separate chunks of 32 bits each).

This is deadly for performance. At the time of reading, the CPU internal memory I/O logic is clever enough to notice if that address was written to only "recently" (as frequently happens for memory representing local variables in higher programming languages) and can then take a shortcut and get that data from a buffer where pending store operations are kept.
So the CPU doesn't have to wait until the data is actually written to memory (which is still comparatively slow).

However, the CPU is not clever enough to find this shortcut if the memory location in question was written to in several partial chunks. In that case, it has to wait until the preceding store operations are finished, somewhat stalling the whole flow of processing instructions.

Maybe the latest Penryns can deal with this better? But at least the pre-Penryn Core 2s should see a significant speed increase from avoiding this particular code pattern generated by the MS compiler (bug) involved.

CU
Bikeman

Yes it does - the frequency is the same - 791.10

However, that's not particularly important. The important bit is the sequence number which tells you what part of the cycle you are in. You really need to do a bit of recent reading :).

The cycle for 791.10 has a period of 128.9

Peaks in runtime will therefore be at seq#s of 0, 129, 258, 387, ...
Troughs in runtime will therefore be at seq#s of 64, 193, 322, 451, ...

Your 4.15 crunched result had a seq# of 316 which is near the trough at 322.
Your 4.26 crunched result had a seq# of 246 which is near the peak at 258.

As you accumulate more data, you will find that Bernd has done you a big favour by making the 4.26 app official. You should go seek out Mike Hewson's ReadyReckoner as documented in this thread.