Re: [ck] [ANNOUNCE] Interbench 0.27

[Gabriel Devenyi <ace@staticwave.ca>]

Con Kolivas wrote:
> On Thu, 4 Aug 2005 21:44, Gabriel Devenyi wrote:
> 
>>Hi Con,
>>
>>You must hate me by now...
> 
> 
> No. A bug report is a bug report. I hate the fact that I coded up 2000 lines 
> of code and am still suffering from a problem in the same 10 lines that I did 
> in version .01. PEBKAC. 
I guess we all have our weaknesses, mine is off-by-one errors, which are 
a bad thing when writing code for a statistics class at school ;)

> 
> 
>>The "Gaming" benchmark has the same issue with nan coming out of the
>>STDEV calculations, probably requires the same fix as before.
> 
> 
> Anyway Peter Williams has promised to fix it for me (yay!).
> 
> 
>>Secondly, the benchmarking of loops_per_ms is running forever, and I
>>managed to determine where its happening.
>>
>>In calibrate loops you run a while loop and iterate to get 1000 for
>>run_time, then you calculate it one more time to ensure it was right
>>*however* you put a sleep(1) before that. It seems to seriously skew the
>>results, as it consistently adds ~500 to run_time, as run_time is now
>>1500, it jumps back up to redo because of the goto statement, and runs
>>the while loop again, continue ad nausium. I added some simple debugging
>>output which prints run time at the end of each while loop, and right
>>before the goto if statement, this is the output.
> 
> 
>>The solution I used is of course to simply comment out the sleep
>>statement, then everything works nicely, however your comments appear to
>>indicate that the sleep is there to make the system settle a little,
>>perhaps another method needs to be used. Thanks for your time!
> 
> 
> I have to think about it. This seems a problem only on one type of cpu for 
> some strange reason (lemme guess; athlon?) and indeed leaving out the sleep 1 
> followed by the check made results far less reliable. This way with the sleep 
> 1 I have not had spurious results returned by the calibration. I'm open to 
> suggestions if anyone's got one.
Yeah, thats right, it spins forever on both my athlon-tbird and my 
athlon64 (in x86_64 mode). I'll take another look at the code tonight, 
to see if I can figure out why its causing this, or another way of 
incurring the delay you're looking for.

> 
> Cheers,
> Con
> 

--
Gabriel Devenyi
ace@staticwave.ca