Version 12 (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.
todo (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.
- docs/parrotbyte.pod duplicates some of pdd13. Merge parrotbyte.pod into the pdd. It's hard enough to keep one document up-to-date.
- It'd also be nice to speed up Parrot_Sub_get_line_from_pc since it currently eats about 15% of the processing time *after* caching its results. Knowing PackFiles might help.
- Add --hash-seed=xxx to parrot so that hash order-related failures can be diagnosed more quickly. Coke recently ran a case where this would have made life easier. (submitted in tt #1383)
- test profiling output (pprof format)
- test pprof to callgrind conversion and callgrind-style output
- Create an efficient binary output format with optional compression, similar to NYTProf.
- 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.
todo (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
- It'd also be nice if parrot were smart enough to treat -Rp or -Rprof to the same as -Rprofiling
- Switch to a Configure.pl-based approach for finding the appropriate timing functions.
profiling testing todo:
- Figure out what to test. (see TestingProfiling)
- 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.
- There's now no reason that multiple output formats can't coexist apart from the extra testing burden.
- specific test cases
- 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
- threads
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.