Re: Octave profiler,

[David Bateman]

Muthiah Annamalai wrote:
> On Sat, 2007-01-27 at 07:20 -0600, Muthiah Annamalai wrote:
>   
>> On Thu, 2007-01-25 at 20:28 -0600, Muthiah Annamalai wrote:
>>     
>>> <SNIP>
>>> In typical implementations,this function delegates events to particular
>>> handlers.
>>>
>>> Essentially, we need to be able to provide a hookup like
>>> 'sys.setprofile' in Octave core, we may be able to profile calls to
>>> C/C++ , Fortran and Octave routines
>>>       
>> I was wondering if the proper positions to insert hooks for invoking the
>> profiler would be at the point in subsref() member functions, before the
>> point where the code calls on do_multi_index_op() in the following
>> source files:
>>
>>      Source File                     Profiler Events
>> ---+-----------------------------+---------------------------------------
>> 1    ov-mex-fcn.cc                   mex-call, mex-ret, mex-exception
>> 2    ov-user-fcn.cc                  o-call, o-ret, o-exception
>> 3    ov-mapper.cc                    mapper-call,mapper-ret,exception
>> 4    ov-builtin.cc                   builtin-call,ret,exception
>>
>> Will this be the proper places to add profiling code? I also want to
>> know if we will not have really bad overheads due to this. AFAIK other
>> languages (Ruby, Python) report about 30% overhead when using a
>> compiled-with-core profiler, that does a full call-graph profiling.
>>
>> For Matlab compatibility, Octave needs such a call-graph based
>> profiling. Even if Octave uses just flat-profiling with just reporting
>> of number of calls, times for calls, Octave needs to provide the
>> profiler hook like I mentioned is done in Python (and in Ruby, with
>> set_profile_func ).
>>
>> So, we need a hook function. But is this the right place to provide
>> them?
>>
>> ~ Muthiah
>>     
>
>
> I have implemented a rudimentary "flat-profiler" that can just give
> statistics of the cpu-time of the functions (only), self & total average
> runtimes, and frequency of call to each function.
>
> This code is a C++ rewrite of the Ruby's flat-profiler from
> $(Ruby-Install-Path)/lib/profiler.rb authored by 'Matz' (Yukihiro
> Matsumoto).
>
> Sample output of profile command testcase 'testprofile.m' (attached)
> looks like:
>
>   %   cumulative   self              self     total
>  time   seconds   seconds    calls  ms/call  ms/call  name
>   2.41     0.00      0.00        4     0.06     0.06  anonymous1
>   2.57     0.00      0.00        4     0.06     0.06  anonymous2
>   0.00     0.00      0.00        1     0.00     9.71  #toplevel
> ans = info
>
>
> I have also added some elementary support for 'event-based' profiler ,
> from the Octave side, that notifies the routines for 'calls', and
> 'returns' from functions. Exception handling is not implemented.
> The API support touches the 4 files mentioned in the previous post.
>
> >From this point, a simple call-graph profiler can also be implemented
> with the present infrastructure. The python profiler ('import profiler')
> does something like this, and serves as a good template.
>
> [Profiler API Support]
> Many design decisions remain to be made, which I must leave it to better
> experienced. I would personally prefer a 'event-based' profiler API like
> the JAVA's JVMPI (JVM Profiler Interface) which lets people build/use a
> sophisticated or simple profiler based on the application.
> Please see JVM-PI design at
> http://java.sun.com/j2se/1.4.2/docs/guide/jvmpi/jvmpi.html.
>
>
> There are following good points about the code,
>
>  1. It recognizes anonymous functions
>  2. Does CPU times with least overhead.
>  3. Can write a basic call-graph profiler
>  4. Works in rudimentary Matlab syntax
>
> Caveats of the present code,
>
>  0. Cannot lookinto execution times of specific lines-of-code
>  1. Not Matlab compatible
>  2. Cannot handle exceptions in profiler gracefully.
>  3. Regular caveats of a flat-profiler in not knowing context 
>     of the function calls; (call-graph based profilers help here,
>     sort-of)
>  4. No event filtering
>  5. Sub-Optimal API design
>
> For compatibility with Matlab, it suffices to provide an API to reach
> the level of a event-based, call-graph profiler with access to
> individual lines.
>
> I am posting the diffs against the files, and the 2 new files for
> octave/src/profile.cc & octave/src/profile.h 
>
> Please comment.
>
> Thanks,
> -Muthiah
>   
Muthu,

Not bad, but is this really the best place for the hooks to the
profiler? I'd have thought in the parser was better, though I don't know
where exactly to include the hooks as I'm not a YACC expert.. Doing it
in the parser would allow easier inclusion of code to get finer grained
profiling... I believe with the hook in the right place in the parser,
most of your existing code could easily be transitioned there without
much effort..

D.


-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary