Re: tracing and profiling at the repl

[Andy Wingo]

Hi,

On Wed 23 Dec 2009 17:03, Neil Jerram <address@hidden> writes:

> I think you're assuming that there is no requirement (or usefulness)
> for tracing or profiling below the program level - i.e. within a
> sequence of VM operations.
>
> Is that assumption correct?  Doesn't it mean that we can profile/trace
> less as the compiler becomes cleverer?

Well, you're right that statprof only works on the function level, and
as the compiler gets better, the number of allocated closures goes down,
and so we see less detail. But function-level profiling is still a very
useful first step.

Profiling on the instruction level is possible, though. You could use
the next-instruction hook, but that might affect the results too much;
or you could handle interrupts if they are present in the NEXT handler.
I have the feeling that this would be too expensive to leave on
normally, but we could build another VM engine that has this enabled.

This would allow you to see in what instructions your hot function is
spending its time, and you can either use that to annotate a
disassembly, or map directly back to source information.

>>> - What if the function that you want to trace is not the one that you
>>>   want to invoke at top level?
>>>
>>> - What if you want to trace several functions within a given
>>>   computation?
>>
>> This works. You get a lot of output, as things are currently; but we can
>> restrict tracing to work only on certain procedures, etc.
>
> That sounds good.  I would suggest that we allow for any combination of
>
> - some procedures for which only call+args and return value are
>   traced
>
> - some procedures for which all applications within the dynamic context
>   of those procedures are traced
>
> - some top-level computation (presumably including some of the previous
>   procedures), for which the tracing function is enabled.

Sounds like good ideas. I do think that specifically tracing certain
functions or forms using a macro and set! is still useful. To me, the
VM-level tracing support is mostly for when you don't want to recompile
your functions, and just want to get a picture of what's happening.

See http://www.scheme.com/csug/debug.html#./debug:h0 for more takes on
this question.

> I'm just not sure how things work as the generated code becomes more
> optimised.  For example, when a `map' procedure is inlined.  But maybe
> that's a fundamental problem, and it's well known (except to me!) that
> you can't unambiguously trace or profile optimised code.

I think the thing is that `lambda' doesn't create a function -- it's
just an abstraction, that might instantiate itself in a number of ways.
A compiler has the time to analyze things in more detail, widening the
number of ways that `lambda' might instantiate itself.

My ideas were recently clarified by
http://www.brics.dk/~hosc/local/HOSC-11-4-pp399-404.pdf, page 4, last
paragraph.

Anyway the thing that changes in optimized code is that a lambda often
isn't a closure, expressions get jumbled, variables that exist in the
source might never be bound -- and this is all good! Code gets faster
this way, and the semantics stay the same. It does make optimizing a but
more confusing, though, and that is unfortunate, as you note.

Happy holidays :)

Andy
-- 
http://wingolog.org/