Version 1 (modified by chromatic, 13 years ago)

Added profiling runcore notes to the wiki

The profiling runcore allows users and HLL developers to profile their programs at the PIR level. Rakudo needs this desperately.

* Make runloops pluggable (pluggable_runcore branch)

  • factor out the common runcore operations
  • define a struct to represent these operations
  • refactor existing runcores to use this struct
  • define a mechanism to load and register a new runcore
  • beware of runcore switching; probably need a better way to switch than compile-time constants

* Create a new profiling dyncore

  • figure out the extra data and this runcore needs for profiling
    • open output file
    • store profiling information
    • close output file

* Explore callgrind output format (NYTProf format a good second strategy)

  • How do you represent non-local jumps?
  • How do you detect non-local jumps and other CPS-style control flow changes?
  • How do you get current line number and source file from the active Context?
  • (stretch goal) How do you retrieve and record current HLL location?
  • How do you report different runcores (exceptions) and threads (interpreters)
  • Probably need to avoid PIO to avoid that overhead
  • Can you add timing to include what's expensive in C terms?

possible problem: can callgrind represent all the ways PIR can do control flow

  • parrot_op_info table gets populated based on what kind of flow
  • function attrs in ops files will probably help too

- if callgrind supports it, find what happens between ops (i.e. how much time between starting ops)