Re: [Patch] FIrst experimental profiler

[Jordi Gutiérrez Hermoso]

2011/7/14 Daniel Kraft <address@hidden>:

> On 07/14/11 08:31, Jordi Gutiérrez Hermoso wrote:
>> 2011/6/30 Daniel Kraft <address@hidden>:
>>> Attached is my current working code for the first experimental
>>> profiler.
>>
>> I have pushed your code on the default branch, along with the
>> following minor stylistic fixes:
>
> thanks!  To summarize, the stylistic changes you made were:
>
>  * Return variables are called ratval.
>
>  * Only warn about ignoring extra arguments.
>
>  * Call print_usage() otherwise for missing arguments and the like.
>
> Right?  Ok, then I'll try to follow those conventions in the future.

Yes. Also, it's customary to not error out at that stage over extra
output argument. The interpreter already handles this in general. Try
it:

     [a,b] = sin(pi)

so I also removed the checks for that, plus a few comments that seemed
were explaining something that I thought was too obvious from just
reading the code.

>
>> I briefly tested your code, and it seems to work. Looks like a
>> solid initial implementation. Can you quickly mimic the Matlab
>> interface to profiling? I think this should be quick and should not
>> take longer than a week. The next step I'd like to see after that
>> is to produce hierarchical profiling output and to also count
>> operators in the profiling output.
>
> Yes, I also think that it should be possible to do the Matlab
> interface soon.  It contains some more fields than is currently
> available (especially the list of parent/child functions), but I can
> either ignore those for now or implement missing bits which seem
> easy (those lists don't look like a "real" hierarchical output and I
> think should be straight-forward to implement).

Yes, go ahead, implement whatever you can of the Matlab interface and
ignore anything for which you don't have a backend yet.

> And I agree that after that, we should think about real hierarchical
> output.  I like the idea by Andy Wingo and Paolo Bonzini that we
> might output data in gprof or callgrind format so that we can reuse
> that tools - -- at least as an option; so maybe I'll look at this
> more closely.

This would be very nice, but consider that an extra feature for now.
Focus immediately on the Matlab interface and then on producing
hierarchical output, by whatever means possible. This is the interface
we need:

     http://www.mathworks.com/help/techdoc/ref/profile.html

Just to make sure, you're aware that in this language

     foo bar
     foo("bar")

and

     baz -quux
     baz("-quux")

are completely equivalent function calls, right? Implementing the
interface with m-scripts is thus a matter of parsing string options to
a profile function.

>  BTW, does Matlab support hierarchical output with a "standard"
> interface?  I don't remember I read about this when looking up
> "profile".

I don't know. We need input from someone who uses Matlab. I'll ask
around in IRC. Can someone here in the mailing list tell us how the
Matlab output looks? We might not need to cosmetically mimic it
exactly, but at least functionally yes.

> With count operators you mean profiling per line or "just" to count
> the number of statements executed alongside the time?

I mean operators are functions so they should be treated the same as
functions in the profiler output. Octave actually has named functions
for I think all operators except indexing and range operators, so for
example,

     x = A\b;
     x = mldivide(A,b);

are completely equivalent function calls, but your profiler only
catches the second one and doesn't report at all the first one. I'm
not sure if the parser translates operators to their equivalent named
functions, perhaps jwe or someone else can comment on how this part
works.

- Jordi G. H.