Version 6 (modified by cotto, 12 years ago) |
---|
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:
- 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.
Abstract output in the profiling runcore to minimize the amount of code that cares about the output format.- 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
- It'd also be nice if parrot were smart enough to treat -Rp or -Rprof to the same as -Rprofiling
- Annotations are slow. Make it possible to avoid a Schlemiel the Painter algorithm by getting annotations from bytecode iteratively.
Questions:
- What are "basic blocks" in Callgrind's format? Callgrind's docs aren't at all helpful here. RTFS applies.
- 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)
- 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: ???)
- specific test cases
- stupid hello world
- profiling a pbc without line information (if possible)
- proper namespace support
- threads