On Wed, Aug 17, 2011 at 7:01 AM, Christoph Otto <[email protected]> wrote: > 1) Threading ... > 2) Asynchronous I/O ...
These are going to be done at the same time. We're not going to have AIO until we have at least basic threading support. What we need is a good plan/design for a new system going forward. I had put forward some ideas a few weeks ago, but I got a lot of good feedback and am not so sure about some of the specifics now. Rakudo could serve as a major driver in this area. The kind of system and the kinds of designs we pursue could be significantly influenced by what Rakudo wants. Also, if they have some hackers who want to get their hands dirty, that's a big help too. The people doing the work are going to play a major role in setting the overall direction. > 3) sub cloning ... I published a blog post last night addressing some of these issues, and I've started an exploratory branch locally to try and cut down some of the cruft of the Sub PMC. I can expand on some of my short-term plans on IRC or in another blog post. Longer-term, the specific goals are a lot more fuzzy. Again, guidance from the Rakudo folks to help direct our efforts would be very welcome. > 4) PCC ... > 5) invocation ... I have several ideas with respect to these items, some of which have made it into blog posts. I've also done some comparative timings and found that we can make some improvements to invocation performance by adding a few new specialty PIR opcodes and avoiding the use of fill_params and friends. The one area where I don't have a concrete solution is a replacement for ":named :slurpy" parameters. I know NQP makes some use of those, so we can't abandon them completely and we can't have them be slower than the current implementation. We can chat more about this on IRC, or I can write up more thoughts in a blog post. As we've said before, profiling tools will be helpful in this regard, so we want to give that a nudge in the forward direction. If people besides myself have ideas for any of these things, please start making them public. They are all places where Parrot needs to improve, but the paths we need to take to reach those improvements are not straight-forward. The more input we have to guide decisions, the better. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
