Ho fatto un paio di test e mi risulta più veloce di jruby!
http://mastrodonato.info/index.php/2010/09/ruby-1-9-2-prestazioni-al-top/
On Mon, Sep 6, 2010 at 11:16 PM, Marco M.
[email protected] wrote:
Ho fatto un paio di test e mi risulta più veloce di jruby!
http://mastrodonato.info/index.php/2010/09/ruby-1-9-2-prestazioni-al-top/
mi sovviene, io da tempo non seguo lo sviluppo, ma nel design iniziale
di YARV c’era anche compilazione JIT e AOT (e a un certo punto
funzionava pure, in parte). Non ci lavora più nessuno?
Io non ho mai seguito lo sviluppo e non so che tipo di compilazione
faccia la vm YARV, so che ci stanno lavorando perchè è stata integrata
in ruby dalla serie 1.9 (KRI).
Solo che nell’implementazione precedente, la vm era molto simile alla
precedente vm MRI delle versioni 1.8, era si molto più performante ma
simile nel comportamento nel senso che era molto reattiva e costante, al
contrario di quella java che ha bisogno di un tempo di warming.
Questa nuova versione di KRI è più veloce sia a freddo che dopo il
warming!
Dai miei test (poi bisogna vedere nella realtà ) la jvm, dopo il warming
aumenta le prestazioni del 25%! La KRI 1.9.2 invece è anche più
costante, solo del 14%.
La precedente KRI invece, come anche la MRI, non miglioravano o non
avevano il decadimento iniziale, a seconda di come la si vuole
interpretare.
2010/9/7 Marco M. [email protected]:
> La precedente KRI invece, come anche la MRI, non miglioravano o non > avevano il decadimento iniziale, a seconda di come la si vuole > interpretare.non penso dovresti vedere questo comportamento.
Io so come funziona yarv (è una vm per bytecode che non dumpa niente,
con il main loop direct threaded) e non dovrebbe avere nessun
meccanismo che possa causare una cosa simile 
Non è che lo penso, l’ho verificato. Avviene proprio quello che ho
scritto, stavo commentando i dati.
Fino alla 1.9.1 tu hai mai notato differenze con le partenze a freddo?
Erano interpreti molto costanti, anche come consumo di memoria…
l’unica cosa che variava era il tempo di esecuzione.
Ciao Pietro,
non sapevo del problema e neanche che in una singola richiesta Rails
venissero allocati quelle migliaia di oggetti!
2010/9/6 Marco M. [email protected]:
Ho fatto un paio di test e mi risulta più veloce di jruby!
Ciao,
molto interessante.
Tuttavia, secondo alcuni, ad esempio [1], ciò che più influisce sulle
prestazioni di un’applicazione ruby di una certa complessità è la
garbage collection.
Hai provato a testare questo aspetto, ad esempio creando tanti (ma
proprio tanti) oggetti, per poi eliminarne ogni riferimento, e
ripetendo il tutto più volte?
pietro
[1] Merbist
2010/9/8 Marco M. [email protected]:
Non è che lo penso, l’ho verificato. Avviene proprio quello che ho
scritto, stavo commentando i dati.
infatti sono io che pensavo fosse diverso non tu
Fino alla 1.9.1 tu hai mai notato differenze con le partenze a freddo?
Erano interpreti molto costanti, anche come consumo di memoria…
l’unica cosa che variava era il tempo di esecuzione.
certo, ma mentre nel resto del tuo benchmark consideri più casi, nel
considerare la differenza ne prendi uno solo.
Questi sono i valori che ottengo io facendo girare 29 volte il
testcase, e sommando i tempi del primi giri a freddo, e dei tempi medi
finali
310.275
310.59
la differenza più o meno è zero, le variazioni sono nell’ordine del
15% dalla mediana, e dipendono da cose esterne a ruby (swap in/out, io
di rete, demoni in background e cose così).
infatti sono io che pensavo fosse diverso non tu
ops 
Fino alla 1.9.1 tu hai mai notato differenze con le partenze a freddo?
Erano interpreti molto costanti, anche come consumo di memoria…
l’unica cosa che variava era il tempo di esecuzione.certo, ma mentre nel resto del tuo benchmark consideri pi� casi, nel
considerare la differenza ne prendi uno solo.
Ne ho provati di interpreti eppure non ho mai riscontrato differenze:
http://mastrodonato.info/index.php/2010/01/ruby-vs-ruby-vs-python-vs-python/
a meno che mi sia perso qualche modalità di esecuzione?
Questi sono i valori che ottengo io facendo girare 29 volte il
testcase, e sommando i tempi del primi giri a freddo, e dei tempi medi
finali
310.275
310.59la differenza pi� o meno � zero, le variazioni sono nell’ordine del
15% dalla mediana, e dipendono da cose esterne a ruby (swap in/out, io
di rete, demoni in background e cose cos�).
Ok, era solo per evidenziare quella curiosa diversità con le versioni
precedenti.
L’utilizzo “reale” per istanze web e processi batch di un certo peso non
si accorgono nemmeno di questo particolare. Forse i piccoli processi ma
basterebbe non farli troppo piccoli e trovare il giusto compromesso tra
gestione/occupazione memoria e tempi. Ma forse neanche questo e sono
solo pippe