Some wPrime help please

[wwwww]

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.

Edited March 30, 2010 by wwwww

[BenchZowner]

I will try to do that for ya in a few hours with a couple of CPUs

[TRG]

Will try new version asap, thanks for putting effort in this cool benchapp.

 

Your post does not render properly here either, but only your post and only in IE7. Wtf?

 

I've had the same problem, only in IE7 and only on this forum. See my topic about superpi and pifast in the same subforum.

[wwwww]

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.

[knopflerbruce]

I'll try on socket F, 939, 754 and AM2 at some point, but I have an exam I must do before I can create enough space here for another setup:D

[filmbot]

I can try this today on 8600 and REX. Just wondering, why do you want no restarts in between the runs? Are results affected by restarts? Seems it would be the opposite.

[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.

Edited April 13, 2010 by wwwww