On Fri, Jan 7, 2011 at 9:45 AM, Andrew Whitworth <[email protected]> wrote: > 1a) For that matter, we could replace get_params with a handful of new > ops: get_pmc, get_pmc_slurpy, get_x_named, get_x_optional, etc. Each > one would make a single transaction with the signature object. In this > case, fill_params evaporates entirely, and the onus is put onto the > PIR compiler to generate the argument unpacking code instead of > get_params/fill_params. A huge benefit here is that arguments could be > retrieved *lazily*, only if they are needed in a particular codepath. > What this does do, however, is insert PIR op dispatches between the > processing of individual arguments (which is bad for our current naive > runcores), but each op becomes extremely simple compared to current > fill_params.
Parrot performance is not dominated by op dispatch, except for the most contrived examples (and even then you have to work at it). Yes, we have 100% dispatch mispredict, no it doesn't matter at the current time, and we can greatly improve this if/when it does begin to matter. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
