Linguaggio funzionale più veloce

Recentemente ho approfondito la programmazione funzionale, in particolare Haskell e F #, il precedente ancora. Dopo aver cercato su Google non sono riuscito a trovare un confronto comparativo dei linguaggi funzionali più importanti (Scala, F # ecc.).

So che non è necessariamente giusto per alcune delle lingue (mi viene in mente Scala) dato che sono ibridi, ma voglio solo sapere quali superano quali su quali operazioni e in generale.

— Farouk
fonte

Le lingue non sono veloci o lente, le implementazioni lo sono.

— Starblue il

Le implementazioni linguistiche non sono veloci o lente, i programmi eseguiti utilizzando tali implementazioni linguistiche lo sono (rispetto ad alcuni altri programmi). Sii caritatevole - quando qualcuno parla di un linguaggio di programmazione più veloce di un altro, il modo più ovvio che ha senso è capire che stanno parlando di programmi specifici eseguiti usando particolari implementazioni linguistiche.

— igouy,

@starblue: questa è una risposta molto debole, e non molto utile. Sebbene sia certamente possibile creare due implementazioni della stessa lingua, una delle quali è più lenta dell'altra, il modo in cui la metti lì implica che non esistono dettagli di progettazione della lingua che richiedono necessariamente determinate inefficienze nell'implementazione rispetto ad altre lingue, dal loro design, non richiedono. E questo semplicemente non è vero. (Soprattutto in questo particolare argomento; i linguaggi funzionali sono noti per loro!)

— Mason Wheeler,

@igouy "Le implementazioni del linguaggio non sono veloci o lente" Questo non è vero. CPythonvs PyPyviene subito in mente.

— NlightNFotis

@NlightNFotis - Quanti secondi impiega CPython? Quanti secondi impiega PyPy? Le implementazioni del linguaggio non sono veloci o lente. Quanti secondi impiega quel programma con CPython?

— igouy

Risposte:

Secondo il Great Benchmarks Game , ATS è più veloce degli altri con Haskell, Scala e una delle varianti di Common Lisp in un pareggio approssimativo per la velocità vicina a quella. Dopodiché Ocaml e F # sono approssimativamente nella stessa categoria di velocità con Racket e Clojure in ritardo dietro ...

Tuttavia, quasi nulla di tutto ciò significa davvero qualcosa. È tutta una questione di problema, macchina, compilatore, tecniche di codifica e, in alcuni casi, pura fortuna. In generale, i linguaggi codificati direttamente dalla macchina come Haskell supereranno i linguaggi compilati di VM come F # e supereranno ampiamente i linguaggi interpretati in modo puro. Inoltre, in genere, i linguaggi digitati staticamente sono più veloci di quelli tipizzati dinamicamente a causa dell'analisi statica che consente di calcolare tutte le operazioni di tipo in fase di compilazione anziché in fase di esecuzione. Ancora una volta, queste sono regole generali, ci saranno sempre delle eccezioni. I "paradigmi" hanno poco a che fare con questo.

— Ingegnere mondiale
fonte

So che ci sono molti fattori da prendere in considerazione e anche se tutte le cose fossero perfette potrebbero funzionare diversamente su dati diversi, la mia domanda è piuttosto vaga. Grazie per il link, davvero utile - non ho mai saputo che ATS fosse così veloce

— Farouk il

Bel collegamento con informazioni dettagliate sul confronto. Sono un po 'deluso nel vedere Clojure che consuma molta più memoria e impiega molto più tempo di Java. Ricordo alcune affermazioni sul fatto che Clojure avesse una performance simile, il che non sembra essere il caso.

— DPM,

Il sito web ATS afferma che ATS supporta una varietà di paradigmi di programmazione, quindi prima di affermare che ATS è più veloce di tutti gli altri, è necessario dimostrare che tali programmi sono effettivamente scritti in uno stile funzionale. Potrebbe essere che l'ATS funzionale non sia più veloce del resto.

— igouy,

Il sito web di Scala afferma che Scala integra funzionalità orientate agli oggetti e funzionali. Hai verificato che i programmi Scala siano scritti come programmi funzionali anziché programmi orientati agli oggetti?

— igouy,

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

Quindi, quando chiedi "il linguaggio funzionale più veloce", cosa stai veramente chiedendo del meglio delle attuali implementazioni dei linguaggi.

Il commento di @ igouy solleva il punto che ci sono altre misure di performance per l'implementazione del linguaggio; ad es. 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.

Si consideri Java per esempio. Supponiamo che io scriva un benchmark a thread singolo utilizzando esclusivamente le funzionalità del linguaggio Java classico (Java 1.0). Se compilo ed eseguo usando JDK 1.0, otterrò una prestazione scadente (perché 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 ciò non è dovuto alle modifiche al linguaggio Java ... perché il mio benchmark utilizza lo stesso sottoinsieme di lingue. 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 es. Ordini di grandezza) per la stessa lingua. Quindi il fatto che la migliore implementazione per la lingua X sia più veloce della migliore (o unica) implementazione della lingua Y non ti dice necessariamente molto sulla lingua stessa.

— Stephen C
fonte

Il meglio che puoi fare è misurare le prestazioni di programmi specifici. Quando misuriamo le prestazioni di un'implementazione del linguaggio vogliamo scoprire quanto tempo ci vuole per compilare un programma, non quanto tempo impiega quel programma per essere eseguito.

— igouy,

Il tempo di esecuzione del programma è una proprietà di quel particolare programma quando viene eseguito utilizzando l'implementazione di quella particolare lingua su quel particolare hardware ecc. Dato che il tempo di esecuzione del programma non è una proprietà della lingua, è caritatevole consentire che in questo contesto il nome della lingua viene utilizzato come scorciatoia per le consuete implementazioni linguistiche ben note.

— igouy,

@igouy - è vero. Ma molte persone non fanno la differenza, come illustrato da molti vecchi siti Web che proclamano che "Java è lento. Sfortunatamente, questa assurdità è stata letta letteralmente da un'intera generazione di programmatori ... e ha danneggiato in modo significativo la reputazione di Java. è per questo che sto sottolineando QUI.

— Stephen C

Come vuoi avere la libertà di dire - "una misura (indiretta) dell'implementazione di una lingua" - spiega perché qualcun altro non dovrebbe essere libero di dire - una misura (indiretta) di una lingua .

— igouy,

@igouy - 1) Sei libero di dire quello che ti piace. Ma questo non ti rende giusto. 2) Considera il caso in cui l'unica implementazione di una lingua è una schifezza. Lo valutiamo. Quindi aggiorniamo l'implementazione, la confrontiamo e le prestazioni sono migliorate notevolmente. Ciò significa che le prestazioni linguistiche sono migliorate? Che senso ha ... visto che la lingua NON è cambiata !!!

— Stephen C,

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

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

Erlang utilizza il suo sistema di monitoraggio integrato per consentire la creazione di sistemi di errore in grado di offrire un livello di affidabilità enorme a fronte di vari tipi di guasti. Inoltre, Erlang può offrirti un livello di concorrenza difficile da trovare in altre lingue.

In verità considererei la velocità di esecuzione dei giorni nostri piuttosto al di sotto dell'elenco 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)

— Zachary K
fonte