Re: [Lightning] About using lightning on a dynamically typed language

[Paulo César Pereira de Andrade]

Paolo Bonzini wrote:
>>  The language vm is currently implemented using computed gotos, and
>> I plan to add several "super instructions" to it to attempt to reduce
>> the cost of indirect jumps.
>
> You can expect 15-40% performance improvement from that, depending on
> the architecture (unfortunately 40% was on the Pentium 4...).

  I think it is dependent on the cpu, but a simple "noop" example:
-%<-
void test() {
    auto a, b;
    for (a = b = 0; a < 10000000; ++a)
        b += a;
    print("%d\n", b);
}
test();
-%<-
that becomes pseudo bytecode:
-%<-
test:
  enter 3   ;; # of stack slots (including unnamed push operand of add)
  int 0
  sd a
  sd b
L1:
  ld b
  push
  ld a
  add
  sd b
  ld a
  inc
  sd a
  push
  int 10000000
  lt
  jt L1
  ld b
  push
  literal "%d\n"
  builtin print 2
  ret
main:
  call test
  exit
-%<-

just by adding the extra opcodes:
  ld+push <arg>
  sd+push <arg>

it already gave almost 40% speedup for gcc -O3 compiled vm,
-O0 gives like sub 10%, but I am only testing on i686 and ia64.
I believe it is because gcc can add extra optimizations for the
longer vm code sequence in C.
[there were even more of those vm instructions some time ago, but
I removed then when implementing "proper" support for statically
typed variables, and only reimplemented a few]

  The idea of "super instructions" is to have sequences like:
  ld+push+ld+add+sd <arg1>,<arg2>,<arg3>
and variants if any of the arguments are the same, where of course,
it can avoid the push on the vm stack.
  This can be tedious and error prone, and should be done with lots
of macros... But the static code may allow gcc to do some very
effective optimizations (but may require a few GB of memory to
compile in a single unit).

> So you have three types, int64/float64/object?

  Those are basically what can be the "current value" in the vm, but
there are opcodes for load/store u?int{8,16,32,64} and float{32,64}
of statically typed variables and record fields (vectors currently
are always checked at runtime because some operations may change the
base type, but I am working on it...), anything else is treated as
dynamically typed.

>>  I understand that it may make it significantly hard to implement as
>> pure jit, but I was wondering how/if it could be made in a way where
>> it kind of "cut&paste" blocks of compiled code
>
> People tried that but it's very difficult as more optimizations were
> added to modern GCC. lightning could be used to cut&paste those blocks
> after you converted them from C to lightning's pseudo-assembly.

  I will try to do some experiments, or at least some small extension
to http://code.google.com/p/exl/source/browse/trunk/check/vm-test.c
that implements the sample program in the start of this email, using
some different approaches/patterns for a simple virtual machine. While
experimenting I should at least better understand lightning. I packaged
lightning in Mandriva some month ago, at least was a start :-)

>> and have it to choose
>> the next opcode in a way where it can tell in advance the processor
>> where it is jumping next; if you look in the code, you can see that
>> it sets a "register void *const *label" variable significantly before
>> jumping to the next instruction, but that doesn't help branch
>> prediction,
>> and I don't know if I could somehow instruct gcc to generate code to
>> tell about it...
>
> On ia64 you can add __asm__("bNN") to the declaration of the variable.
>  You can look at GCC's generated assembly to find a suitable value of
> NN.  On PPC, GCC should take care of splitting the mtctr and bctr
> instructions.  But on i686 there's no instruction to aid branch
> prediction (better, instruction fetch speculation) in the presence of
> indirect jumps.

  I will test the ia64 ones as soon as I have a chance [I develop most
of the code at home, and only have i686s here currently...]

>> [the language doesn't have yet a defined name, it is also a kind of
>> hobby, doesn't have yet a defined usage either, it is "just for fun",
>
> Nothing wrong with it!

:-)

> Paolo
>

Paulo

my name almost matches yours :-)