Look, now I'm rewriting a patch for pbc2c.pl which will use computed goto
*ONLY* in a few ops like jump or ret (or any other that modifies the
program flow) in all other cases it will stay with the actual goto model
which is ,in my opinion, the fastest.
# ./mops
Iterations: 100000000
Estimated ops: 300000000
Elapsed time: 2.228982
M op/s: 134.590583
On Thu, 1 Nov 2001, Kevin Huber wrote:
> Daniel Grunblatt wrote:
>
> > I have tested times using computed goto in the interpreter and here are
> > the results:
> >
> > # ./test_prog mops.pbc
> > Iterations: 100000000
> > Estimated ops: 300000000
> > Elapsed time: 8.604721
> > M op/s: 34.864582
>
>
>
> Yes, I wrote a poor-man's computed goto version just of mops.pasm the
> other day with an inner loop like this:
>
> #define NEXT goto **ip++
>
> op8:
> if (ireg[2] == ireg[4]) {
> *ip+=3;
> goto **ip;
> }
> NEXT;
> op9:
> ireg[2] += ireg[3];
> NEXT;
> op10:
> *ip-=3;
> goto **ip;
>
> It ran at ~58 M op/s, slightly over twice the current dispatcher.
> Obviously my code is not a general machine, but I hypothesized that
> 58 would be near the ideal upper bound on direct-threading
> performance for the current architecture on my computer.
>
> -Kevin
>
>
>
