On 10/09/01 Bryan C. Warnock wrote:
> > About the goto label feature discussed elsewhere, if the dispatch
> > loop is emitted at compile time, there is no compatibility problem
> > with non-gcc compilers, since we know what compiler we are going to use.
> > I got speedups in the 10-20% range with dispatch-intensive benchmarks in
> > mono. It can also be coded in a way similar to the switch code
> > with a couple of defines, if needed, so that the same code compiles
> > on both gcc and strict ANSI compilers.
>
> I also tested (previously; I need to hit it again) replacing the loop,
> switch, and breaks with a lot of gotos and labels.
>
> LOOP:
> /* function look up, if need be */
> switch (*pc) {
> case (1) : { /* yada yada yada */; goto LOOP }
> ...
> }
>
> It improved the speed of non-optimized code, because you didn't jump to the
> end of the switch simply to jump back to the loop conditional. But I didn't
> see any additional improvements with optimized code, because the optimizers
> take care of that for you. (Well, really, they put another copy of the
> while condition at the bottom.)
Yes, that was basically the same mistake I did at first when testing
the goto label stuff, little or no improvement. But the 'right' way to do
it is to use the goto label construct not only instead of switch(), but
also instead of 'break;'. Oh, and the address array needs to be
declared const and static, too.
const static void * goto_map[] = {&&OP1_LABEL, &&OP2_LABEL, ...};
...
while (1) {
goto *goto_map [*ip]; // switch (*ip)
OP1_LABEL:
do_stuff ();
update_ip ();
goto *goto_map [*ip]; // break;
OP2_LABEL:
do_other_stuff ();
update_ip ();
goto *goto_map [*ip]; // break;
...
}
> > The problem here is to make sure we really need the opcode swap
> > functionality, it's really something that is going to kill
> > dispatch performance.
> > If a module wants to change the meaning of, eg the + operator,
> > it can simply request the compiler to insert a call to a
> > subroutine, instead of changing the meaning assigned to the
> > VM opcode. The compiler is free to inline the sub, of course,
> > just don't cripple the normal case with unnecessary overhead
> > and let the special case pay the price of flexibility.
> > Of course, if the special case is not so special, a _new_
> > opcode can be introduced, but there is really no reason to
> > change the meaning of an opcode on the fly, IMHO.
> > Comment, or flame, away.
>
> But how are you going to introduce the new opcode? Recompile Perl?
Nope, this is done at the design and early beta stage: we decide which
opcodes make sense and which not and we may add specialized opcodes if
it makes sense to do so. Once the opcode set is defined, it can't be
changed until the next release.
> Unacceptable. We understand that from a classic language perspective, we're
> slow and lumbering. We're Perl. We need that flexibilty. We're trying to
> make that flexibility as fast as possible.
Completely agree. My point is that I don't see a real reason to be
flexible at the opcode level (changing the meaning of the opcodes)
when you can have the same outcome with a cleaner design (set a
different method in a class' vtable).
Many things were done as opcodes in perl5 because calling subroutines
is slow there, IIRC. Many of that features can simply be methods
in some class in perl6: it's cleaner and it's flexible and it doesn't
require to change the meaning of the opcodes.
> I've got three different opcode loops so far for Parrot. (Linux(x86)/gcc,
> Solaris(SPARC)/Forte, and Solaris(SPARC)/gcc). I've tried most every
> combination I can think of (am still working off the last couple, as a
> matter of fact). (Particularly ever since I received the inexplicable
> slowdown adding a default case.) Take nothing for granted, and try it all.
> I've posted some of my more ridiculous failures, and have posted what I have
> found to be my best numbers. Anyone is free to come up with a better,
> faster solution that meets the requirements.
Thanks for your efforts, hard numbers are always better than talk! :-)
I was just trying to offer the experience I gathered working on similar
issues, hoping it can be useful. And yes, I was suggesting to change
a bit the requirements (not of the language, but of the current VM design)
more than proposing an implementation of it.
lupus
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
