Dan Sugalski wrote:
> I wanted to do this not so much to reduce the size of the core (They're not
> *that* much code) as to reduce the number of opcodes being used. I really,
> *really* want to trim down the opcode list.

If we reduce the number of opcodes, we need to consider the performance
impact -- perl ops run a *lot* of machine instructions and reducing the
number of them might mean more ops have to run in order to accomplish the
same thing as before. There is a nice paper "The Structure and Performance
of Interpreters" by Romer, Lee, et al. that compares Java, Perl and Tcl.
They ran them on a hardware simulator so they could measure things like
pipeline stalls, cache misses and a whole bunch of interesting things. One
of the reasons Perl performed well is that it spent a lot of time in what
they called native code, i.e. not decoding and dispatching ops.

I wouldn't mind reducing the number of ops if (whatever replaces XS) can
be called as fast as an op. Right now the performance difference between
an op and an XSUB is horrible.

- Ken

Reply via email to