Changes between Version 1 and Version 2 of ProfilingRuncore

Show
Ignore:
Timestamp:
07/21/09 19:25:37 (13 years ago)
Author:
chromatic
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ProfilingRuncore

    v1 v2  
    11The profiling runcore allows users and HLL developers to profile their programs at the PIR level.  Rakudo needs this desperately. 
    22 
    3 * Make runloops pluggable (pluggable_runcore branch) 
    4     * factor out the common runcore operations 
    5     * define a struct to represent these operations 
    6     * refactor existing runcores to use this struct 
    7     * define a mechanism to load and register a new runcore 
    8     * beware of runcore switching; probably need a better way to switch than compile-time constants 
    9 * Create a new profiling dyncore 
    10     * figure out the extra data and this runcore needs for profiling 
    11         * open output file 
    12         * store profiling information 
    13         * close output file 
    14 * Explore callgrind output format (NYTProf format a good second strategy) 
    15     * How do you represent non-local jumps? 
    16     * How do you detect non-local jumps and other CPS-style control flow changes? 
    17     * How do you get current line number and source file from the active Context? 
    18     * (stretch goal) How do you retrieve and record current HLL location? 
    19     * How do you report different runcores (exceptions) and threads (interpreters) 
    20     * Probably need to avoid PIO to avoid that overhead 
    21     * Can you add timing to include what's expensive in C terms? 
     3 * Make runloops pluggable (pluggable_runcore branch) 
     4     * factor out the common runcore operations 
     5     * define a struct to represent these operations 
     6     * refactor existing runcores to use this struct 
     7     * define a mechanism to load and register a new runcore 
     8     * beware of runcore switching; probably need a better way to switch than compile-time constants 
     9 * Create a new profiling dyncore 
     10     * figure out the extra data and this runcore needs for profiling 
     11         * open output file 
     12         * store profiling information 
     13         * close output file 
     14 * Explore callgrind output format (NYTProf format a good second strategy) 
     15     * How do you represent non-local jumps? 
     16     * How do you detect non-local jumps and other CPS-style control flow changes? 
     17     * How do you get current line number and source file from the active Context? 
     18     * (stretch goal) How do you retrieve and record current HLL location? 
     19     * How do you report different runcores (exceptions) and threads (interpreters) 
     20     * Probably need to avoid PIO to avoid that overhead 
     21     * Can you add timing to include what's expensive in C terms? 
    2222 
    2323possible problem: can callgrind represent all the ways PIR can do control flow