[Shootout-list] Re: Timing issues

[Isaac Gouy]

--- Brian Hurt <bhurt@spnz.org> wrote:
> > The Mono timings in the reversefile benchmark, at least, look
> > unrealistically low.
> 
> I agree.  I'm wondering if what is happening here is that the Mono
> runtime is detecting that the results aren't needed, and so isn't
even
> computing them. 

I wish! You might find places where Haskell and Clean are doing that,
but the problem with Mono is more mundane. This is the answer from the
Mono developers list:

> I wrote to the kernel developers: it looks like timing info is not
> reported from subthreads unless the subthread exits: it's a timing
> issue. Sometimes after executing the C# program the subthread that
> executes it manages to call pthread_exit() before the main program
> quits and sometimes not, so you get the incorrect timings.
>
> This could be considered a buglet in mono, though the time results
> are the only thing that should be affected by it. Maybe Dick has
> further insights why we don't properly wait for a thread with 
> pthread_join() (ie why we use pthread_detach(): there may be other
> ways for us to wait for the thread to call pthread_exit ()).
> 
> lupus 

You can see this in the comparison timings (sometimes 0.05s sometimes
0.23s; wallclock always >0.24s) 
   Mono 100  0.271137   0.05
   Mono 100  0.241688   0.05
   Mono 100  0.245944   0.23
   Mono 100  0.272433   0.24
   Mono 100  0.269268   0.25

And we have timing resolution problems, here wallclock time should be
greater than the usr+sys time, but it isn't:
   OO2C 100  0.033074   0.04

The fastest implementations are pushing below the timing resolution
available with the Perl times() function. 

Time::HiRes seems to provide much better resolution for wallclock time.


  


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush