On Wed, Jan 06, 2010 at 01:31:30PM +0100, Markus Peter wrote: > On 05.01.2010, at 18:34, Tim Bunce wrote: > > > The is_pmc logic was added for Larry Wall so he could profile his > > STD.pm Perl6 compiler. I've forgotten the details now, except that the > > way it currently works suited his needs at the time. > > > > If you give me detailed instructions to reproduce the problem you're > > seeing I'll ponder what changes I might make. > > Hello Tim > > I'll look into creating a reduced test case soon.
Great. > >> 2) Hi-Resolution Clocks on Mac OS X > > > > That would be great! Could you produce a patch for that? > > I've looked at the example code again a bit closer and then went with > my own mach_absolute_time based implementation which is simply based > on different macros and included it as default replacement for > gettimeofday on Mac OS X. The clock_gettime_stub.c was unfortunately > unusable: Mach's clock_get_time is painfully slow (time of profiling > increased by a factor of 4, even after I optimized the code to not > constantly re-acquire the clock port) and the > PROCESS_CPUTIME_ID/THREAD_CPUTIME_ID branch of the code was completely > flawed (it seems the author misunderstood the tech note and did not > realize, that he's actually measuring the performance of the > getpid()/sched_yield() calls instead of returning the proper time). > Please see the attached patch - I hope everything's ok with it. Many thanks, applied! > I've set the resolution of the mach clock to 100ns similar to the > clock_gettime variant - the macros actually calculate it in 1ns > resolution. I've got no clue what the real resolution of > mach_absolute_time is (it pretends it's 1ns but well...), but so far > my tests indicated that the resolution is at least a lot higher than > with gettimeofday. 100ns is about how long my perl 5.8.6 (debugging + threads) to execute "1;"; The resolution could be made a runtime option. The downside of greater precision is larger average tick values and so larger profile data volumes. Some people might like that trade-off to get 10ns ticks. Patches welcome! Actually, what I'd really like to see is the concept of a 'clock' abstracted further so there's a pointer to structure with pointers to functions and a some private data. Then the clock=X option would be much more useful. The usecputime and zero options would disappear and Nick's work on memory profiling could be folded in a a new kind of 'clock'. Any volunteers for that one? Tim.
-- You've received this message because you are subscribed to the Devel::NYTProf Development User group. Group hosted at: http://groups.google.com/group/develnytprof-dev Project hosted at: http://perl-devel-nytprof.googlecode.com CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf To post, email: [email protected] To unsubscribe, email: [email protected]
