Changes between Version 7 and Version 8 of CottoTasklist

Timestamp:

12/15/09 20:49:50 (12 years ago)

Author:

cotto

Comment:

rearranging and cleanup

CottoTasklist

@@ -1 +1 @@
 This page is a personal todo list for me, cotto.  Others are welcome to take on any tasks mentioned here, but the primary purpose for this page is to keep track of what I intend to do.  Because of that, I haven't spend much effort on breaking tasks down into bite-size chunks or made much of a concrete plan.  If you are interested in helping but don't know where to start, catch me on #parrot and I'll put you to work.  
 
-profiling:
- - Get to know the PackFile code.
-   - Read through the bytecode pdd (13) and make it match the current implementation.
-   - Focus on annotations, but it wouldn't be a bad thing to lower the PackFile bus number.
+profiling (important, in decreasing order):
+ - Annotations are slow.  Make it possible to avoid a Schlemiel the Painter algorithm by getting annotations from bytecode iteratively.
+   - http://irclog.perlgeek.de/parrot/2009-12-12#i_1828456
+   - Get to know the PackFile code.
+     - Read through the bytecode pdd (13) and make it match the current implementation.
+     - Focus on annotations, but it wouldn't be a bad thing to raise the PackFile bus number.
  - test profiling output (pprof format)
  - test pprof to callgrind conversion and callgrind-style output
- - Figure out a nice way to integrate annotations into the profile.
- - Switch to a Configure.pl-based approach for finding the appropriate timing functions.
  - Create an efficient binary output format with optional compression, similar to NYTProf.
- - Optimize the profiling runloop code.
- - Consider moving the Callgrind output code into the profiling runcore.
+   - Alternately, consider moving the Callgrind output code into the profiling runcore and using the pprof output only for testing.
+   - Look into spitting out NYTProf-compatible output too.
+ - Optimize the profiling runloop code.  Major refactors should wait until some tests are in place.
  - ~~Abstract output in the profiling runcore to minimize the amount of code that cares about the output format.~~
+ - ~~Figure out a nice way to integrate annotations into the profile.~~
+
+profiling (would be nice):
  - Fix CLI argument parsing so that options can be passed to the profiling runcore.
    - It'd also be nice if parrot were smart enough to treat -Rp or -Rprof to the same as -Rprofiling
      - This is a trivial change to compilers/imcc/main.c
- - Annotations are slow.  Make it possible to avoid a Schlemiel the Painter algorithm by getting annotations from bytecode iteratively.
-   - http://irclog.perlgeek.de/parrot/2009-12-12#i_1828456
+ - Switch to a Configure.pl-based approach for finding the appropriate timing functions.
 
 Questions:
@@ -23 +26 @@
    * A basic block is a straight line piece of code without any branches or branch targets.  It's the smallest individual unit of code to which you can apply a compiler optimization.
 
-
 profiling testing todo:
- - figure out what to test
- - actual profiling runcore output (does it work, is the output valid)
+ - Figure out what to test.
+ - Write some fake tests to figure out what the profiling testing interface should look like.
  - pprof2cg (split into a module, test individual components, multiple output formats (when implemented))
    - The Callgrind output code may end up in C since nqp is way too slow and even the Perl 5 version isn't very fast.  This would make testing more interesting, though I'd still have a way to produce either the pprof or the callgrind formatted output.
- - stats output should also be tested since it's nice for debugging (note to self: ???)
+   - There's now no reason that multiple output formats can't coexist apart from the extra testing burden.
  - specific test cases
-  - stupid hello world
+  - test all output types (currently none and pprof, possibly cg and nytprof if I get ambitious)
+  - hello world 
   - profiling a pbc without line information (if possible)
   - proper namespace support