Prestazioni del linguaggio Dynamic .NET?

Question

Capisco che IronPython è un'implementazione di Python sulla piattaforma .NET, proprio come IronRuby è un'implementazione di Ruby e F # è più o meno OCaml.

Quello che non riesco a capire è se queste lingue si avvicinano ai loro "antenati" o più vicino a qualcosa come C # in termini di velocità. Ad esempio, IronPython è in qualche modo "compilato" fino allo stesso bytecode utilizzato da C # e, pertanto, verrà eseguito altrettanto velocemente?

Answer 1

IronPython e IronRuby sono basati sul DLR - Dynamic Language Runtime - e sono compilati al CIL (il bytecode utilizzato da .NET) al volo. Sono più lenti di C # ma faaaaaaar più veloci delle loro controparti non -.NET. Non ci sono benchmark decenti là fuori, per quanto ne sappia, ma vedrai la differenza.

Answer 2

IronPython è in realtà l'implementazione Python più veloce in circolazione. Per alcune definizioni di "più veloce", almeno: l'overhead di avvio del CLR, ad esempio, è enorme rispetto a CPython. Inoltre, il compilatore di ottimizzazione IronPython ha davvero senso solo quando il codice viene eseguito più volte.

IronRuby ha il potenziale per essere il più veloce IronPython, poiché molte delle interessanti funzionalità che rendono veloce IronPython, sono state estratte in Dynamic Language Runtime, su cui sia IronPython che IronRuby (e Managed JavaScript, Dynamic VB, IronScheme, VistaSmalltalk e altri) sono costruiti.

In generale, la velocità di un'implementazione del linguaggio è praticamente indipendente dalle caratteristiche del linguaggio reale, e dipende maggiormente dal numero di anni di ingegneria che la riguardano. IOW: dinamico vs. statico non importa, il denaro conta.

Ad esempio, Common Lisp è un linguaggio ancora più dinamico di Ruby o Python, eppure ci sono compilatori Common Lisp là fuori che possono persino dare una scossa a C per i suoi soldi. Le buone implementazioni Smalltalk funzionano velocemente come Java (il che non sorprende, dal momento che entrambe le principali JVM, Sun HotSpot e IBM J9, in realtà sono VM Smalltalk leggermente modificate) o C ++. Negli ultimi 6 mesi, le principali implementazioni JavaScript (Mozilla TraceMonkey, Apple SquirrelFish Extreme e il nuovo bambino sul blocco, Google V8) hanno apportato miglioramenti delle prestazioni ginormous , 10 volte e più, per portare JavaScript in testa a testa con C. non ottimizzato

Answer 3

Attualmente IronRuby è piuttosto lento sotto molti aspetti. È decisamente più lento della risonanza magnetica (Matz 'Ruby Implementation), sebbene in alcuni punti siano più veloci.

IronRuby ha il potenziale per essere molto più veloce, anche se dubito che si avvicineranno mai a C # in termini di velocità. Nella maggior parte dei casi non importa. Una chiamata al database rappresenterà probabilmente il 90% della durata complessiva di una richiesta Web, ad esempio.

Sospetto che il team cercherà innanzitutto la completezza della lingua piuttosto che la performance. Ciò ti consentirà di eseguire IronRuby & amp; eseguono la maggior parte dei programmi su ruby ??con 1.0, quindi possono migliorare perf mentre vanno.

Sospetto che IronPython abbia una storia simile.

Answer 4

Hai l'idea giusta supponendo che le prestazioni di una moderna implementazione .NET saranno comprese tra quelle dell'antenato e di C #. Il motivo è che C # è molto simile a .NET stesso.

F # è un gioco da ragazzi perché C # e OCaml hanno caratteristiche prestazionali simili.

IronPython è molto più difficile perché Python e C # hanno caratteristiche prestazionali incredibilmente diverse. In effetti, la risposta dipende dalla stessa implementazione di IronPython, che si adopererà per convertire inefficienti valutazioni in stile Python in efficienti valutazioni in stile C # ogni volta che sarà possibile. Aspettatevi che IronPython sia generalmente molto più lento di C # con i picchi occasionali nello stesso territorio. Puoi vedere questo effetto qui .

Saluti, Jon Harrop.