Jump to content
HWBOT Community Forums

wwwww

Members
 View Profile  See their activity

  • Posts

    42

  • Joined

  • Last visited

 Content Type 

Posts posted by wwwww

    Some wPrime help please

    in Benchmark software

    Posted · Edited by 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.

    Some wPrime help please

    in Benchmark software

    Posted · Edited by 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. :S

    wPrime 2.00 beta

    in General overclocking

    Posted

    version 1.43 - 438.393

    version 2.00 beta 6 - 382.99

     

    that's a whole lot faster in my book ;)

     

    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.

    wPrime 2.00 beta

    in General overclocking

    Posted

    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.

    wPrime 2.00 beta

    in General overclocking

    Posted

    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.

    wPrime 2.00 beta

    in General overclocking

    Posted · Edited by wwwww

    Beta2 also says Beta 1;) he just forgot the rename

     

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

    wPrime 2.00 beta

    in General overclocking

    Posted

    is it possible to set the amount of threads in Wprime 2.0 ? in the older one you could adjust the amount in the "advanced" menu

     

    1.43 1.53 1.55 2.0b0 2.0b1 results below:

    [ATTACH]345[/ATTACH]

     

    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.

    wPrime 2.00 beta

    in General overclocking

    Posted · Edited by jmke

    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:

    wPrime --->checksum(invalid)<---

    in Submission & member moderation

    Posted

    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.

    wPrime......AGAIN.........

    in Submission & member moderation

    Posted

    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.

    why hwbot uses wprime?

    in Benchmark software

    Posted

    but it adjusts number of threads to cores :/ are there user applications which do this?

     

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

×
×
  • Create New...