L'approccio di pypy è più unico che raro e da il meglio di sé in linguaggi altamente dinamici. La maggior parte dei JIT attuali ha scarsa considerazione dell'esecution path, se non per scegliere i "punti caldi", ma la compilazione avviene solitamente a blocchi, senza troppo badare alle altre informazioni disponibili a runtime.
"Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares
In realtà l'approccio PyPy (tracing JIT con generazione tentativa di codice ottimizzato per il caso specifico) è usato anche da LuaJIT (e, dai risultati, sembra anche implementato in maniera più efficace, anche se leggevo che Lua come linguaggio è più facile di Python da gestire per un JIT) come anche da TraceMonkey e parenti (anche se adesso mi sembra che abbiano cambiato un po' le carte in tavola con IonMonkey). Comunque sì, ovviamente è essenziale con linguaggi dinamici dove il discorso del dispatching delle operazioni in base al tipo giusto è cruciale per avere buone performance (mentre in Java o C#, a meno di non lavorare in maniera deliberatamente stupida in late binding con tipi boxed, le operazioni sui tipi primitivi vengono compilate come tali fin da subito).
Dall'altro lato, leggevo che qualche anno fa è stato implementato un approccio del genere per CIL (SPUR), per cui le ottimizzazioni da tracing JIT "stile PyPy" si dovrebbero applicare automaticamente a qualunque linguaggio CLR. Il paper puntava a vedere le performance di un'implementazione CLR di Javascript (e non andava male a livello di runtime), però un po' delle ottimizzazioni citate (come devirtualizzazione e inlining) dovrebbero avere il loro perché anche su linguaggi a tipizzazione più statica; non so però come la cosa si collochi rispetto al JIT .NET "normale", al compilatore AOT e, ad esempio, alle relative varianti Mono (specie quella basata su LLVM).
Amaro C++, il gusto pieno dell'undefined behavior.
Tracemonkey che io sappia è stato un po' messo da parte, luajit è oscuro al mainstream e pypy (implementazione di python) resta l'unico ampiamente usato. Quello volevo dire.
A parte che pypy (il framework) ha capacità spaventose: non devi preoccuparti del jit compiler in quanto è generato automaticamente a partire dall'implementazione dell'interprete.
Da questo punto di vista è enne volte avanti rispetto l'implementazione di tracemonkey. Su luajit non sono particolarmente informato...
Comunque, al giorno d'oggi, se parli di jit compiler, al 99% non stai parlando di un tracing...
"Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares
Leggendo in giro pare che l'approccio di TraceMonkey sia stato tirato agli estremi in JagerMonkey per essere poi un attimo accantonato in IonMonkey, dove hanno riscritto tutto con un approccio più tradizionale per poter applicare ottimizzazioni "classiche" in maniera più semplice; leggevo però che a tendere vogliono reintrodurre anche il tracing (il cui output andrebbe a rientrare nella pipeline generica dell'ottimizzatore) per ottenere il meglio dei due mondi.Originariamente inviata da Scara95
rpython & co. fa pauraA parte che pypy (il framework) ha capacità spaventose: non devi preoccuparti del jit compiler in quanto è generato automaticamente a partire dall'implementazione dell'interprete.
Da questo punto di vista è enne volte avanti rispetto l'implementazione di tracemonkey. Su luajit non sono particolarmente informato...dall'altro lato, LuaJIT è implementato tutto a manina con inserti in assembly (sia l'interprete che il JIT), e se guardi le performance si vede che alla fine come sistema paga (l'ho visto più di una volta battere il compilato C), ma ovviamente è tutto molto specifico e "hand tuned" (cosa di cui si bullava l'autore in un thread su lambda the ultimate, dove prendeva in giro gli autori di PyPy e TraceMonkey
).
Comunque, al giorno d'oggi, se parli di jit compiler, al 99% non stai parlando di un tracing...my bad se ho enfatizzato troppo prima, è che PyPy e affini mi gasano abbastanza
Ultima modifica di MItaly; 14-08-2015 a 10:23
Amaro C++, il gusto pieno dell'undefined behavior.
@Scara95 @MItaly wow grazie mille per la completezza delle risposte, credo di aver capito ,e anzi ho scoperto anche degli aspetti di linguaggi come il c (che credevo di conoscere) che neanche immaginavo,sapreste consigliarmi qualche libro/manuale magari "testato" da voi per approfondire l'argomento?più che il linguaggio vero e proprio, i loro funzionamenti come "sistemi", quindi a livello prestazionale ecc.. e appunto come funzionano i linguaggi a livello di ottimizzazione ecc, grazie ancora
Prima di studiare le ottimizzazioni ce n'è di roba...
"Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares
@Scara95 quindi dici prima di approfondire con un determinato linguaggio e poi andare a vedere appunto le ottimizzazioni per quel linguaggio?
Permessi di invio
Rispondi quotando