New JIT Compiler

[vuott]

Ambasciata della Comunità italiana di Gambas sulla mailing list internazionale

Comunicazione n. 6 dal vostro Ambasciatore    

Questa Ambasciata porta a conoscenza un avviso inviato oggi da Emil Lenngren (della mailing list internazionale di Gambas):


Hi everybody.

I've been working on a JIT-compiler for Gambas for some months, and I'm now
ready to release an alpha-version in the latest svn of Gambas.
The compiler uses LLVM to produce machine code for x86 or x86_64. You need
LLVM on your computer for it to work, preferably the latest version from
svn (3.0 from Ubuntu repos does not seem to work any well). Find more
instructions in the README file.

To use it, place the word "Fast" at the top of a Gambas Class file, for a
class that you want all functions JIT-compiled instead of interpreted. (At
the moment you cannot make individual functions JIT-compiled, but that is
limited by the gbc compiler.)

As it takes some milliseconds for LLVM to emit machine code and do
optimizations, you should only use it for functions you really need
optimizations.

As the JIT compiler analyses the whole function before execution starts,
some extra type safety is added. In interpreter mode, you can normally do
things like:
Print "hello"
Print 1.3 \ 5
and you will first see hello on the screen, and then an error message
complaining you can't do integer division on floats.
If you run the same function in the JIT compiler, the error message will be
thrown before execution starts instead, hopefully in order to make programs
less buggier.
As a consequence, you can not have code like "Try Print 1.3 \ 5" either. At
the moment the incorrect line is reported in the error message...

The best speed-ups will be in functions that use a lot of low-level
calculations and control flows (except For Each loops), like functions that
do a lot of math. If the function mostly calls other libraries, you won't
see speed-ups either.
There are still the same overhead when calling functions, since the gambas
stack must be maintained as before, to make error handling work.
Using Try/Catch is probably slightly slower too because a real exception
handler must be set up.

Something the LLVM optimizer is very good at is transforming a chain of
if-else statements to a jump table, so code like:
Select Case x
  Case 1:
    ..
  Case 2:
    ..
  Case 3:
    ..
End Select
will be much faster than before, so you don't have to use the "On Goto"
syntax and a lot of labels. This will produce identical machine code.

Most things are implemented, but there are still many bugs to fix.
Some of the (so far) unimplemented features are
Calling external C libraries (the Extern keyword).
The use of "_unknown" special method.
IIf and Choose with different argument data types.
The possibility to use Component.Load to load functions that are executed
right after in the same function.
Profiling
Breakpoints

Some of the benchmarks from http://gambasdoc.org/help/doc/benchmark
Polynom: 102.7 seconds to 4.7 seconds
Primes: 18.3 seconds to 3.5 seconds
Nbody: 16.0 seconds to 1.8 seconds

If you are curious and want to see the optimized LLVM IR you can uncomment
the line M->dump() at the bottom of the jit_codegen.cpp file in gb.jit/src.

I hope the JIT compiler will be useful for you

/Emil

Forgot to mention that the 64-bit version is probably more bug-free than
the 32-bit version, since I myself have a 64-bit computer and therefore
have run only some few tests on 32-bit...

[vuott]

Aggiornando normalmente Gambas-3 da SVN, al termine di ./configure -C si avrà questo avviso:

||
|| Unable to find file: llvm/LLVMContext.h
|| Unable to find file: libLLVM-3.2svn.so
|| gb.jit is disabled
||


ed alla fine:

||
|| THESE COMPONENTS ARE DISABLED:
|| - gb.jit
||


Per chi volesse installare quel componente:
https://www.google.it/#q=gb.jit+is+disabled


Successivamente è molto probabile che occorra posizionarsi nella directory ~ $ trunk/gb.jit. Quindi lanciare lì: ./configure senza il flag -C.

Si può quindi provare a continuare l'aggiornamento di Gambas. Si consiglia di rilanciare come di consueto: ~ $ trunk ./reconf, poi ~ $ trunk ./configure -C .

Se al termine di ~ $ trunk ./configure -C dovesse comparire l'avviso:

||
|| THESE COMPONENTS ARE DISABLED:
|| - gb.jit
||


si può provare rimuovendo i file gb.jit/DISABLED* rimasti (comando: ~/trunk/gb.jit $ rm gb.jit/DISABLED*, e sempre restando nella directory ~ $ trunk/gb.jit lanciare quindi il comando make seguito da sudo make install .

Al termine, ripetere il completamento dell'aggiornamento di Gambas ripetendo i passaggi come di consueto: ~ $ trunk ./reconf, poi ~ $ trunk ./configure -C ; quindi dando gli ultimi due comandi make seguito da sudo make install.

[vuott]

Potete quindi provare le fuzionalità del componente acceleratore gb.jit lanciando questo codice con e poi senza la parola "Fast" posta all'inizio del codice medesimo):

Codice: gambas [Seleziona]

 Fast

 Public Sub Button1_Click()

 Dim i As Long

   For i = 1 To 1000000000
   Next
   
  Print "Funziona !"
   
 End

Lo scopo è verificare quanto tempo sarà impiegherà per stampare in console la frase "Funziona !".

Oppure potete provare quest'altro (sempre con e poi senza la parola "Fast":

Codice: gambas [Seleziona]

 Fast

Public Sub Button1_Click()

Dim I As Integer

 For I = 1 To 10
   Print Test(0.2)
 Next
 
 End

 
Sub Test(X As Float) As Float

  Dim Mu As Float = 10.0
  Dim Pu, Su As Float
  Dim I, J, N As Integer
  Dim aPoly As New Float[100]

  N = 500000

  For I = 0 To N - 1
    For J = 0 To 99
      Mu = (Mu + 2.0) / 2.0
      aPoly[J] = Mu
    Next
    Su = 0.0
    For J = 0 To 99
      Su = X * Su + aPoly[J]
    Next
    Pu += Su
  Next

  Return Pu

End

Verrà scritta in console una cifra per dieci volte. Se impiegherà pochi secondi, il componente gb.jit funziona, se impiega alcuni minuti il componente non funziona.


Se e quando attivate la parola "Fast" ed il componente gb.jit funziona, noterete la differenza di tempo impiegato !  

[md9327]

Insomma, un ottimizzatore di codice... un pò strano ma se i risultati sono evidenti, allora...

Un paio di dubbi:

1) se è necessario un ottimizzatore (generico in quanto non mi sembra sia parametrizzabile), vuol dire (cosa che già sapevo) che Gambas è da sistemare;
2) da quanto si evince dal messaggio ad inizio thread, ha delle limitazioni. Questo non vuol dire che abbia dei problemi, solo che potrebbe crearli con codice non perfetto.

[vuott]

Insomma, un ottimizzatore di codice... un pò strano ma se i risultati sono evidenti, allora...

Un paio di dubbi:

1) se è necessario un ottimizzatore (generico in quanto non mi sembra sia parametrizzabile), vuol dire (cosa che già sapevo) che Gambas è da sistemare;
2) da quanto si evince dal messaggio ad inizio thread, ha delle limitazioni. Questo non vuol dire che abbia dei problemi, solo che potrebbe crearli con codice non perfetto.

Cosa dire ?  Io ho apportato 'sta modifica al carburatore  , ed in sé la cosa effettivamente funziona..... se son rose fioriranno.   

[md9327]

Immagino di sì, dato che hai fornito anche esempi ad-hoc.

Bè, i miei sono solo dubbi in quanto lo vedo un controsenso. Se funziona è un'altro paio di maniche, e và pure bene così.

Tengo sottomano le tue note, nel caso mi venga in mente di utilizzare questa libreria. 

[vuott]

Comunque sia, come è chiaro, se non si pone la parola chiave "Fast" ad inizio del codice, il... turbo non s'attiva, e tutto funziona semplicemente come prima.

[md9327]

Sì, ho capito.

La trasformazione avviene durante l'esecuzione, implementando le funzionalità avanzate di questa nuova libreria. Diciamo che è una duplicazione delle librerie base di Gambas, ovviamente ottimizzate...

[milio]

Caspiterina... ho fatto il test con il secondo esempio:

Senza Fast:

00:02:14.683

con Fast:

00:00:05.854

Pazzesco! 

[md9327]

Come ho detto, questo insinua dei dubbi sull'ottimizzazione del codice base di Gambas...

Devo assolutamente dare un'occhiata ai sorgenti...

[Ceskho]

Sarebbe interessante sapere perchè queste novità non vengono introdotto di default...mah....

[md9327]

Caro vuott, mi hai incuriosito, per cui stò tentando di compilare i sorgenti per testare quest enuove funzionalità.
Il problema è che:
||
|| THESE COMPONENTS ARE DISABLED:
|| - gb.desktop.gnome
|| - gb.jit
||
questi due componenti non vengono compilati, e non c'è alcuna spiegazione nella doc per capire quali librerie mancano.
Tu che hai testato jit, come l'hai compilato?

[vuott]

Caro vuott, mi hai incuriosito, per cui stò tentando di compilare i sorgenti per testare quest enuove funzionalità.
Tu che hai testato jit, come l'hai compilato?

Dai un'occhiata al mio secondo messaggio sopra.

Ad ogni modo ti riporto in sequenza temporale i suggerimenti che ho ricevuto via posta elettronica da Emil Lenngren, che è il realizzatore di quel componente:

Innanzitutto mi ha suggerito questo passaggio (e mi ha chiesto di inviargli il relativo listato del terminale):
Go to the gb.jit directory. Then try to run ./configure without the -C flag.

Dopo che gli ho inviato il listato da ./configure, mi ha scritto:
Try to remove any gb.jit/DISABLED* files left behind and then run make followed by sudo make install in the gb.jit directory.
In gambas top-level: rm gb.jit/DISABLED*

Quindi mi ha precisato di ripetere la procedura di aggiornamento partendo da...:
You must issue a ./reconf before ./configure -C

Minisini, intervenendo, mi precisa che una CPU andrà comunque al 100% facendo il test:
CPU must be at 100% (on one core) in both case. The JIT compiled
function is just faster. Just try with the FAST keyword, and without, and compare the execution time.


.....non so se ho soddisfatto la tua richiesta....  


Se, poi, continui ad avere problemi, non avrai altra possibilità che appellarti a... Papa Ceskho I  !   

[md9327]

Nooooo, papa checkho noooooo !!!! (ho detto papa?!?)

In effetti mi era sfuggito qualche tuo passo precedente (è l'età...).

Quindi tocca fare qualche operazioncina manuale in modo da abilitare il modulo...
La cosa brutta, anche se comprensibile, è il fatto del consumo esponenziale delle risorse. Vuol dire che le funzionalità di Fast vanno ad agire pesantemente e direttamente sui cicli macchina. A questo punto è ovvio l'incremento delle prestazioni, solo che a questo punto la vedo dura... Non si può impegnare un sistema per una singola applicazione, magari bloccando il multitasking e il parallelismo insito in Linux. Sicuramente si può considerare un tentativo di miglioramento, ma solo una specie di verifica delle potenzialità di alcune logiche.

Ad ogni modo, appena ho un attimo, cercherò di analizzare la cosa, per saperne di più. Secondo me, al momento, è meglio usare la libreria per soli test...

[md9327]

Aggiornamento...

Ho dato un'occhiata ai sorgenti della libreria, e ho notato che non è altro che una serie di funzionalità legate ad una linbreria esterna LLVM, che è un ottimizzatore di codice, questo il link

http://llvm.org/

Stò leggendo qualcosa sul sito, anche perchè non ne ero a conoscenza, e magari vedo di reportare quanto appreso qui nel forum.

Ad occhio, però, il discorso è un tantino diverso dal quello scaturito dai miei dubbi iniziali, anche se comunque aggiunge uno strato, anzi scavalca totalmente, il motore base di Gambas. Attualmente, dai metodi implementati, sono stati coperti solo alcune funzioni base, ma sicuramente fattibile la copertura totale di tutto il motore.

Non sono ancora andato a spulciare la documentazione e le specifiche, ma come tutti gli ottimizzatori, la cosa ha i suoi pro e suoi contro, ed è quindi pensabile un uso limitato per determinati tipi di applicazione.