Posted February 23, 201312 yr whats the point then ? seriously, that shouldnt be allowed and about half the submission should be pulled may as well run superpi then or use hyperpi as a replacement for superpi, what made hyperpi interesting was the speed at which the cpu can calculate multiple threads of pi, but not one ..... one can be done by superpi please reconsider the rules, they are not correct TIA, Dan
February 23, 201312 yr The issue was raised internally, standby for an official statement. --- In mod neoficial trebuie rulat cu toate threadurile
February 23, 201312 yr Author The issue was raised internally, standby for an official statement. --- In mod neoficial trebuie rulat cu toate threadurile Thank you, will be looking forward to the decision, I am sure it has to coincide with mine it just makes sense, the whole point of this bench was to multi-thread bench --- pai si logic eu nici nu vreau sa rulez altfel, nu vad sensu deja
August 23, 201311 yr If you ask me, either we remove the benchmark, or we block subs with less threads than the cpu is capable of. It's clearly the purpose of the benchmark to run the same number of threads that the CPU is capable of. I don't feel sorry for the folks who have chosen to run just one thread, it's CLEAR that this benchmark is just superpi32m if one thread is selected - and that it's not supposed to be run that way. Rules are rules, but mistakes happen, and why those who read the # of processor sentence in the rules didn't scratch their heads a bit is quite strange.
August 23, 201311 yr Okay, thanks. I also think that value of Hyperpi is higher stability requirements due to multithreaded run and bigger memory consuption. Using less cores makes the benchmark senseless. But the benchmark itself is very nice - I normally use it to confirm RAM stability for benchmarks. So it is better to make a clear statement in the rules that thread # should be equal to the capabilities of CPU.
August 23, 201311 yr Needs a wrapper IMO. As is it seems like an addition to the moderator workload that doesn't really give much value.
August 23, 201311 yr We could have a workaround: make the score calculation slightly different, instead of avg. time, we can use avg time divided by threads run. So, a 10 thread chip with an avg. time of 1000 seconds will have a "score" of 100. Then these singlethread results will be worthless This is just my idea, nothing that has been discussed internally. +1 for a wrapper.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.