On 16/07/07, bryce at kampjes.demon.co.uk <bryce at kampjes.demon.co.uk> wrote:
> sig writes:
>  > Another point why i'd prefer to use a single struct (call it foo, or
>  > anything else) for interpreter globals, is to encapsulate all global
>  > values in single place:
>  > - VM variables
>  > - pointers to VM functions.
>  >
>  > And in generated code use foo->bar for values, and foo->bar(...) for
>  > function calls.
>  >
>  > This will give me ability to replace a function pointer with own code
>  > on the fly in running VM, without recompiling code at all.
>  > And moreover, this eliminates the need in having InterpreterProxy
>  > variable for each plugin.
>

I changed code to generate indirect calls everywheren in interp.c.
See results:

1 tinyBenchmarks
direct calls:
'120640904 bytecodes/sec; 3180012 sends/sec'
'118518518 bytecodes/sec; 3260940 sends/sec'
'119962511 bytecodes/sec; 3253634 sends/sec'
'119180633 bytecodes/sec; 3227123 sends/sec'
'117323556 bytecodes/sec; 3227123 sends/sec'


indirect calls:
'119626168 bytecodes/sec; 3263383 sends/sec'
'118848653 bytecodes/sec; 3219968 sends/sec'
'118408880 bytecodes/sec; 3305475 sends/sec'
'118628359 bytecodes/sec; 3441245 sends/sec'
'117972350 bytecodes/sec; 3273190 sends/sec'

As you suggested yearly, the main bottleneck is branch mispredicting.
As you can see benchmarks results, difference lies in error bounds. It
may be slower than direct calls ( by 1/1000 maybe).
At least on my AMD Athlon 1.1 Ghz i see no reason, why i must
sacrifice having VM with ability to replace different functions at run
time for 1/1000 speed boost.