Lingua funzionale più veloce

Secondo il Great Benchmarks Game , ATS è più veloce del resto con Haskell, Scala, e una delle varianti di Common Lisp in un brutto tiro per la velocità dietro a quello. Dopo che Ocaml e F # si trovano approssimativamente nella stessa categoria di velocità con Racket e Clojure in ritardo ...

Tuttavia, quasi niente di tutto ciò significa davvero niente. È tutta una questione di problemi, macchine, compilatori, tecniche di codifica e, in alcuni casi, semplice fortuna. In generale, i linguaggi con codifica diretta della macchina come Haskell superano i linguaggi compilati VM come F # e superano ampiamente le lingue puramente interpretate. Inoltre, le lingue tipizzate staticamente sono più veloci di quelle dinamiche tipizzate a causa dell'analisi statica che consente di calcolare tutte le operazioni di tipo in fase di compilazione anziché in fase di esecuzione. Di nuovo, queste sono regole generali, ci saranno sempre delle eccezioni. I "paradigmi" hanno poco a che fare con questo.

Va inoltre sottolineato che non è possibile misurare / quantificare le prestazioni di un linguaggio di programmazione . Il meglio che puoi fare è misurare le prestazioni di una specifica implementazione della lingua su piattaforme specifiche, eseguendo programmi specifici.

Quindi quando chiedi di "il linguaggio funzionale più veloce", cosa stai chiedendo veramente sul meglio delle attuali implementazioni della / e lingua / e.

Il commento di igouy solleva il punto che ci sono altre misure di rendimento per l'implementazione del linguaggio; per esempio. tempo di compilazione. Ma ciò non cambia il fatto che il tempo di esecuzione del programma applicativo è una misura (indiretta) dell'implementazione di una lingua, non una misura della lingua stessa.

Considera Java per esempio. Supponiamo che io scriva un benchmark a thread singolo usando solo le caratteristiche linguistiche del classico Java (Java 1.0). Se compilo ed eseguo l'uso di JDK 1.0, otterrò una prestazione scadente ('cos JDK 1.0 non aveva un compilatore di codice nativo). Se vado da JDK 1.1 a ... JDK 1.7, molto probabilmente otterrò risultati progressivamente migliori. Ma questo non è dovuto alle modifiche alla lingua Java ... perché il mio benchmark utilizza lo stesso sottoinsieme di lingua. Piuttosto, l'accelerazione è dovuta a miglioramenti nei compilatori, nel sistema di runtime e / o nell'implementazione delle librerie di classi. Questi sono tutti problemi di implementazione .

L'altro punto è che queste differenze di implementazione possono essere davvero significative (ad esempio ordini di grandezza) per la stessa lingua. Quindi il fatto che la migliore implementazione per il linguaggio X sia più veloce della migliore (o unica) implementazione del linguaggio Y, necessariamente ti dice molto sul linguaggio stesso.

Se stai guardando le lingue solo sulla velocità di esecuzione, mancano alcuni punti importanti. La velocità è una buona cosa, ma non è l'unica cosa.

Haskell utilizza un sistema di tipi molto robusto per creare programmi che avranno molte più probabilità di essere privi di bug e robusti.

Erlang usa il suo sistema di monitoraggio integrato per permetterti di creare sistemi di guasti che possano darti un enorme livello di affidabilità di fronte a vari tipi di guasti. Inoltre, Erlang può darti un livello di concorrenza difficilmente eguagliabile in altre lingue.

In verità, ritengo che la velocità di esecuzione dei giorni nostri sia piuttosto in fondo alla lista di ciò che considererei nella maggior parte dei casi. (OK se stavo facendo un calcolo numerico massiccio probabilmente avrei voluto usare fortran per la velocità, ma per il resto non è abbastanza importante da importare)