wwwww

The 2nd and 3rd runs on some systems should be faster. One of the issues faced when designing wPrime was that threads weren't performing at the same speed. Usually due to system load (though this shouldn't be an issue on well optimized systems) but it is particular noticeable on HT systems where the virtual threads tend to perform worse (also could be a problem on Core CPU with Turbo as cores run at different clocks but I haven't yet heard of any issues - probably because when all cores are loaded equally, they should all run at the same clock). When you split the job between each core equally, we have some threads finishing first and others finishing later which causes unrealistically bad scores (as for a small part of the test we're only using 12.5%, or 25% of the processor waiting for the last thread. If your score was affected by this, you'd see one of the threads in the console view finish later than the others. The solution was to measure the relative speed of each thread in each run (just by comparing the final times of each thread) and adjust the % of the job between the threads more appropriately for the next test. This won't have any effect until a test is run though (as it adapts from running the test). While loading wPrime, 1.55 runs a quick test (512K) to sync the threads properly (and also to load the processor before CPU clock reading to avoid false clock readings though this doesn't work that well) but often this doesn't completely adapt to your system so running the test a 2nd or 3rd time may actually provide a better score (on Hyper Threaded or poorly optimized systems). When 1.55 was designed, mainstream processors weren't fast enough to justify a more intensive test than 512K as it'd add too much time to the loading time but since then increasing it to 2M shouldn't add too much to the load time as even a basic Core i3 can finish 2M in under 2 seconds. While this increase gives it better data to adapt the job load per thread, modern day processors tend to have more threads to deal with so it may still not be perfect. So 2nd and 3rd runs on the same load may still provide better scores. So running them continuously without restarts allows me to see the best score each version is capable of (which is really what you want to compare as in real time people would go for the best score). This is also the reason why 1024M is often faster than 32x 32M because it has a lot more time to adapt.

So we got any results yet? I've tested an i7 skt 1156 @ 2.66GHz Core 2 Duo 6M @ 2.4Ghz Athlon X2 550 BE @ 3.2Ghz, 3.6Ghz, 4GHz All within 1% difference, avg 0.6% variance.

I am working on a version of wPrime that uses the 1.55 engine and all the features of 2.xx (good hardware detection, detecting thread count on vista, better score management, score submission, etc). The idea is that it'll offer comparable scores and the nifty 2.xx stuff. So far the results are promising but I'm looking for more comparisons with 1.55 so if you'd like to help out: Version 1.64: http://www.wprime.net/Download/wPrime164.zip Version 1.55: http://www.wprime.net/Download/wPrime155.zip I need 32M comparisons, 3 consecutive runs on each version (from a fresh start, no restarts in between). And if you have time (or a quad hexa-core system that does it in a minute) 1024M comparisons would help too (just 1 from each). Thanks. Btw the top half of my message isn't rendering on iexplore 7.

You can just press ~ and type cleanup <enter> to reset to default settings The CPUz version in wPrime 1.55 is outdated so it might not detect your CPU.

Yes but older CPU's represent such a small portion of the scores, all it'll mean is a few benchers will need to re-bench. As long as the bulk of the scores (modern CPUs) are consistent, it should be fine.

I don't think there's a problem with being too fast on older CPUs, as long as it's faster, as there aren't too many scores that'll be affected and it'll just require retesting. What's important that results on modern day CPUs are still in line with version 1.55 and that 2.0 is faster than 1.43 which I think 2.0 succeeds at.

Thanks for that. All the 2.00 versions detect hardware information the same way, there must be other reasons why it doesn't detect correctly. Do you have CPUz running in the background? If so, you should close it before starting up wPrime. Beta2 is too slow for modern CPUs, I'm thinking the 1/3/6 (they all use the same calc script) is most suitable as they still perform comparatively fast to 1.55.

See some of the K6 scores the first page, it's much faster on older setups.

http://www.wprime.net/?q=download&f=wprime_200_beta6.zip Can someone with a multi-CPU system test that this correctly sets the thread count (as in cores*processors - eg dual Clovers should run with 8 threads)

Nah I did it to confuse everyone By the way, Realtime priority won't boost performance as the calculations are not done in the parent process (unless you do it to the children process).

Hmm , seems too slow. http://www.wprime.net/?q=download&f=wprime_200_beta3.zip Another thing, 2.00 will be perfectly consistent between versions (as the calculation modules won't be recompiled).

http://www.wprime.net/?q=download&f=wprime_200_beta2.zip Still too fast, this should be slightly slower again.

Yeah, just hit ~, type ft x where x is the thread count <enter> then gui <enter> I might put a thread change option in the interface before release though.

Ok how about this: http://www.wprime.net/?q=download&f=wprime_200_beta1.zip Should be slightly slower - how does it perform on the K6?

Thanks for the feedback - The approved hwbot version is up to Frederik, but with those types of scores, I'd say I need to slow it down a little - I'm aiming for it to be on par with version 1.53.