Stackless Python vs. Go

Nota: Ho fattop qualche ricerca in piu’ ed ho trovato che la runtime gc genera un solo OS thread e quindi aggiunge thread uno alla volta per evitare conflitti di I/O. D’altra parte la runtime di gccgo mappa le goroutine sui p_thread in rapporto di 1 a 1 (almeno per il momento).

Ho seguito con relativa noncuranza lo sviluppo del linguaggio Go per un po’
di tempo, quando improvisamente mi sono imbattuto in questo post di “Appunti
Digitali” che fa riferimento a questo post su Dalke Scientific.

Mi ha davvero colpito come Stackless Python le dia di santa ragione a Go,
quindi ho deciso di esguire da solo i test sul mio caro vecchio IBM X-41
(Pentium-M 1.5 GHz).

Ho compilato Stackless Python e la toolchain per Go, quindi ho eseguito i
test esattamente come trovati sulla pagina di Dalke. I risultati sono qui
riportati:

$ time ./8.out
100000

real 0m5.197s
user 0m1.508s
sys 0m1.352s

$ time
/usr/local/bin/python2.6 test.py
100000

real 0m3.315s
user 0m1.556s
sys 0m0.148s

Quello che mi ha davvero colpito e’ il fatto che ambo i programmi spendano
aprrossimativamente lo stesso lasso di tempo in userland. Quello che davvero
uccide le prestazioni del programma GO e’ che spende quasi altrettanto tempo in
kernel mode. Mi sono domandato perche’…

Poi mi sono ricordato che, nel Google Tech Talk, Pike dice qualcosa riguardo
al fatto che la runtime di Go gestisce i thread per conto degli utenti, ed io
ho automaticamente interpretato che avrebbe associato i thread utente con gli
OS thread in qualche modo (come e’ la norma). Di fatto questo e’ quello che fa
gccgo (usando gli NTPL).

D’altra partle, leggendo la documentazione di Stackless Python, ho trovato
la pagina riguardante le Tasklets. Si dice chiaramente:
“Le Tasklet sono caratterizzate dall’essere estremamente leggere e portabili, e
sono una eccezionale alternativa a thread di sistema o processi”.

Sono quindi propenso a pensare che le Tasklet siano gestite dalla VM Python
stessa e che non richiedano alcuna transizione user-to-kernel, ne’ altre
interazioni con il kernel… perche’ non sono thread veri (al contrario delle
goroutines in Go).

Questo, con il fatto che Go e’ principalmente inteso per tagliare i tempi
di compilazione, mi fa pensare che la comparativa sia piuttosto ingiusta
e credo che Go garantisca una notevole performance!

Riguardo certe situazioni potenzialmente pericolose ammetto che sono senza
ombra di dubbio un problema. In ogni caso credo che verranno trattate molto in
fretta: Go e’ un linguaggio appena sfornato e qualche spigolatura qua e la non
puo’ essere che attesa, pur con un grande spazio di crescita.

Update:

Ho modificato i programmi di test cosi’ che ogni goroutine/Tasklet chiami una
seconda funzione che cicla 1000 volte e cumula il risultato di “sum = sum+1”.

I risultati sono come previsto: il compilato e’ un ordine di grandezza piu’
veloce dell’interpretato Stackless Pyhton! Ho anche rimpiazzato la chiamata a
range con xrange, come suggerito da Cesare
Di Mauro, ma non ha cambiato molto le cose… cosi’ come non le ha cambiate
usare psyco (un JIT per Python).


$time ./test2 && time /usr/local/bin/python test2.py
100000

real 0m19.567s
user 0m15.697s
sys 0m0.160s


The source code for Python is:
default=100000)

stackless.tasklet(main)()
stackless.run()


And the test code for Go is:
"fmt";
)

func f(left, right chan int) {
loop();
left < - 1+<-right; } func loop() { var sum int; sum = 0; for i := 0; i < 1000; i++ { sum = sum + 1 } } func main() { flag.Parse(); leftmost := make(chan int); var left, right chan int = nil, leftmost; for i := 0; i < *ngoroutine; i++ { left, right = right, make(chan int); go f(left, right); } right <- 0; // bang! x := <-leftmost; // wait for completion fmt.Println(x); // 100000 }