Re: [Sablevm-user] SableVM question

[Etienne M. G. <eg...@j-...>]

Marcel Ammerlaan wrote:
> I've experimented with pre-interpretation but it doesn't seem to matter
> much (ie. same results). 

I modified your benchamrk to include time measurments (using the clock()
function).  My tests indicate that test3.c  is a little faster than
test.c.  This means that, using these tests, the goto approach is
faster, but just a little.

This was compiled using the following gcc options (CFLAGS environment
variable being unset):

gcc -O2 -o test test.c
gcc -O2 -o test3 test3.c

Now, I used ddd to get a first feel of why the generated machine code
for the switch was so efficient (to be so close to the goto approach),
and it became much easier to understand what's happening...

I have included, in attachent, the assembly code for two programs,
generated with:

gcc -O2 -S test.c
gcc -O2 -S test3.c

You will notice that gcc is quite clever (sometimes;-), and it has
detected that your "case" statements are all alike!  So, gcc took
advantage of this.  I have not checked carefully, but you should also be
aware that gcc could detect that it does not need to do the assignment
"var = i;", as "var" is not volatile, and only the last iteration has
any real side effect...

In other words, your while/switch is simple for gcc to optimize, and
this optimization wouldn't happen in a real interpreter, as each
bytecode has a different body (there's no point in having duplicate
bytecodes in an interpreter).

I'm sure that, if you test with a somewhat more complex example, you
will soon discover that the goto approach is faster.  Just look at the
assembly code.

What to look for: gcc does encode a test on the value of the switch, to
test if it is in bound of its encoded array of destination addresses. 
Gcc has no (theoretical) basis to be able to soundly remove such test. 
Also, you (at least) get two branches for every iteration:
(1) jump from the switch to the appropriate "case"
(2) jump from the end of the "case" to the back to the loop head
(possibly the "switch")
This is already assuming an optimizing compiler that had removed
spurious jumps (as you would probably get with gcc -O0).

I might still be wrong, so please continue testing and keep us updated
on your findings.

Cheers,

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableVM:                             http://www.sablevm.org/
----------------------------------------------------------------------