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.

In an effort to solve the problem of unbeatable scores achieved with older wPrime versions, I've completely re-done the calculation and threading section of wPrime in an effort to bring the score on par with or slightly faster than v1.53. I could use some testers to compare scores with older versions, in particular on higher processor count SMP systems as I've completely redesigned the threading model so I'm not sure of the effect it'll have on 8 core + systems (only have quads here to test on). - Wprime 2.00 Beta6: http://www.wprime.net/?q=download&f=wprime_200_beta6.zip - Wprime 2.00 Beta3: http://www.wprime.net/?q=download&f=wprime_200_beta3.zip - Wprime 2.00 Beta2: http://www.wprime.net/?q=download&f=wprime_200_beta2.zip - Wprime 2.00 Beta1: http://www.wprime.net/?q=download&f=wprime_200_beta1.zip - Wprime 2.00 Beta0: http://www.wprime.net/?q=download&f=wprime_200_beta.zip Compare with: - Wprime 1.55 (current stable): http://www.wprime.net/?q=download&f=wprime_155.zip - Wprime 1.53: http://www.hwbot.org/blog/wp-content/wprime_153.zip - Wprime 1.43: http://www.hwbot.org/blog/wp-content/wprime_gui143.zip Basically would like to know, too fast or still too slow? Note that you won't be able to submit scores at this stage. Thanks :thumpsup:

It's a bug in version 1.55 that occurs when one or more of the bytes in the checksum is smaller than 16 causing the checksum, when converted to ascii represented hex (as stored in the save files) to be shorter than 8 bytes. This was corrected around v1.58. You can load the score in version 1.63 and submit from there, it shouldn't have a problem with hwbot as long as the score was done in v1.55.

Where are you downloading from? Try from: http://wprime.net/?q=download Version 1.55 for hwbot.

The loading files bug occurred when the hex representation of the checksum had leading zeros (was fixed in v1.58), I feel that this might be occurring upon submission as well. Basically, wPrime doesn't send leading zeros in the checksum, this caused problems in the load/save feature as there were exactly 8 bytes allocated for the checksum, and required a new version to fix. If when comparing checksums, adding leading 0s when comparing should fix the problem. Feel free to e-mail me direct at walter@wprime.net with any problems.

When you run F@H (or almost any other distributed processing task) on a multithreaded system - you run as many processes as you have logical threads for optimal efficiency. Likewise, any well-written encoding task acts in the same way, if hdd isn't a bottleneck in such a scenario, it'll scale similarly as well. The single threaded user is free to adjust it to use as many threads as he wants, but he won't benefit from it (unless his CPUs aren't all the same speed, eg. HyperThreaded CPUs or if you have background processes slowing things down).

Vista's definitely faster than XP (handles the threading much better), though I don't see how there can be a difference between 32bit and 64bit Vista.

Run as Administrator or turn off UC.

He hasn't got CPUz installed. Without CPUz, the reported clock speed will be on bootup, and some systems will report any Core series CPU as a Pentium 3.

80w powers my X7900 nicely.

Umm, I'm have no idea what I'm doing here, but I can't see it doing anything beyond printing, "Loading file..." Will fix shortly...