At 01:52 PM 8/2/00 -0400, Ken Fox wrote:
>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.
I'm not talking about tossing sassign or the like. I'm talking about fork,
wait, log, localtime... things that don't get called enough to be an
opcode. I mean, if we doubled the amount of time that localtime took, would
it really matter?
>here is a nice paper "The Structure and Performance
>of Interpreters" by Romer, Lee, et al. that compares Java, Perl and Tcl.
URL?
>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.
There'll be two levels, I think. (Or will be, if I ever stop reading email
and start writing RFCs...) One at near-op speed (with the overhead of a
single pointer deref) and one at perl 6 sub call speed. (Which should
hopefully be faster than perl 5's sub calls)
I'd also like to teach PI (or whatever it becomes) to produce joined
opcodes. Ilya did some profiling of perl 5 code, and there were a bunch of
common op pairs. Joining them together (thus saving both dispatch time
*and* op setup/teardown) would get us a small win, but then saving 5 cycles
an op on ops that take 40 cycles is nothing to sneeze at...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
