Version 35 (modified by cotto, 11 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.
architecty todo
- work through RFC tickets
- prepare for PDS on Jan 29(-ish)
- look at and steal from #1020 for Lorito
- to implement the MOP, we'll need the following. Figure out what they should look like in M0
- array
- struct
- hash
- invokable thing that can be passed arguments
- put architecture team to work
- work through (and blog about):
- GC
- Namespaces
- imcc
- pcc
- exceptions and exception handling
- lexicals
- NCI
misc todo
- Take a shot at implementing one-pass lazy PMC class initialization.
- http://irclog.perlgeek.de/parrot/2010-06-20#i_2460692
- add stuff from http://irclog.perlgeek.de/parrot/2010-05-28#i_2378589 to LoritoRoadmap
- Add a test for #1652 to t/profiling/profiling.t
- 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.
- 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.
- Profile/optimize the profiling runloop code.
profiling testing todo:
- Make -Rprofiling good enough for everyday use.
- Get it up to the level of pmichaud's q&d profiler, i.e.
- print enough information to show how many times each sub is called
- make sure there's enough information to uniquely identify subs (esp. MULTIs)
- Get it up to the level of pmichaud's q&d profiler, i.e.
- Dealing with options for a runcore is a mess. Consider breaking it out into its own frontend.
- if a user wants to profile something quickly, give -Rprofiling sensible defaults
- for more dedicated use, make parrot-profiler that parses all parrot's options and adds profiling-specific options
- Make docs/dev/profiling.pod helpful to a (hypothetical) annoyed and scared newbie.
- Figure out what to test. (see TestingProfiling)
- 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 (should parrot get proper threading)
- make profiler useful to HLLs (nqp especially, pge would be helpful too)
- time spent per sub/method would be very helpful to pmichaud
- deal gracefully with tailcalls
- optimize pprof2cg, see this and the ensuing discussion
Questions:
- What are "basic blocks" in Callgrind's format? Callgrind's docs aren't at all helpful here. UTSL 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.