Simon,

For testing I believe you've got to set the affinity of the executable to CPU #0.

I was running your test platform (the batch files, not the installer) and checked my CPU activity for this Athlon 64 X2 3800+ cpu, and both cores were working on parts of the program.  This, sometimes, doesn't allow the data in one of the core's caches to be used as the other core then takes over when control returns to the app.

I then downloaded a MS utility to set the cpu affiniity for an executable and changed all of the .exes to be CPU #0 only.  For testing this is ok, but not for the release version.

Note: BOINC does this when running the executables, by starting child tasks and setting the CPU affinity before begining worker.


Side note: I noticed the mention of the "cheating" on Intel's part in another thread...checking for "GenuineIntel" and the option to patch executable to overcome this.   Well intel has gotten more clever lately and their CPU checking in 4 places in your executables (each of the 4 uses different code).   I just patched them to be "AuthenticAMD" and all executables are running on this AMD cpu; even the ones that failed on your table...heheh.   Can't be certain any of the SSE2 or SSE3 code is being called but the executables run.

Good thread...but about that affinity?

Er,

checked out what it actually does (I thought it would set cpu affinity on the fly, not set it permanently), and future test packs will probably contain executables with affinity set to cpu #1.

Regards,
Simon.