Version 1 (modified by chromatic, 7 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)