fill_params GCI task

[Peter Lobsinger]

On Fri, Jan 7, 2011 at 9:45 AM, Andrew Whitworth <wknight8111 at gmail.com> 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.