Prestazioni F # vs prestazioni Erlang, ci sono prove che la VM di Erlang sia più veloce?


19

Ho dedicato del tempo all'apprendimento della programmazione funzionale e sono arrivato alla parte in cui voglio iniziare a scrivere un progetto invece di dilettarmi in tutorial / esempi.

Durante la mia ricerca, ho scoperto che Erlang sembra essere piuttosto potente quando si tratta di scrivere software simultaneo (che è il mio obiettivo), ma le risorse e gli strumenti per lo sviluppo non sono maturi come i prodotti di sviluppo Microsoft.

F # può essere eseguito su Linux (Mono) in modo tale da soddisfare i requisiti, ma mentre mi guardo intorno su Internet non riesco a trovare alcun confronto tra F # vs Erlang. In questo momento, mi sto sporgendo verso Erlang solo perché sembra avere la maggior parte della stampa, ma sono curioso di sapere se c'è davvero qualche differenza di prestazioni tra i due sistemi.

Dato che sono abituato a sviluppare in .NET, probabilmente potrò essere più veloce con F # molto più velocemente di Erlang, ma non riesco a trovare alcuna risorsa per convincermi che F # sia scalabile quanto Erlang.

Sono molto interessato alla simulazione, che sta lanciando molti messaggi elaborati rapidamente su nodi persistenti.

Se non ho fatto un buon lavoro con quello che sto cercando di chiedere, si prega di chiedere ulteriori verifiche.


12
Le lingue non hanno velocità. Le implementazioni linguistiche specifiche che eseguono un programma specifico su un input specifico (questo può includere tutto il mondo esterno, a seconda del programma) hanno una velocità.

1
F # viene eseguito sul runtime .NET ed Erlang viene eseguito sulla propria VM. I processi di Erlang sono considerati leggeri rispetto alle lingue che sono nel suo dominio (come Scala). Per una simulazione che genera nodi e passa molti messaggi, il runtime .NET / Mono è buono quanto la VM di Erlang o la VM di Erlang è superiore?
afuzzyllama,

3
@delnan: le lingue hanno caratteristiche prestazionali.
Jon Harrop,

2
@JonHarrop In che modo? Un linguaggio di programmazione è semplicemente una sintassi e una semantica associata.

1
@delnan: la semantica pone limiti all'ottimizzazione. Ad esempio, i linguaggi tipizzati dinamicamente sono proibitivi in ​​modo proibitivo nella pratica. La mancanza di tipi di valore sulla JVM comporta un'allocazione dell'heap molto maggiore rispetto a .NET e, di conseguenza, una sollecitazione molto maggiore sul GC. Come i generatori di codice, i garbage collector possono e sfruttare informazioni come l'immutabilità per migliorare le prestazioni. La progettazione di un linguaggio di programmazione ha un enorme effetto su questo.
Jon Harrop,

Risposte:


21

Cosa intendi con "praticabile?" "Avere il massimo della stampa" non è necessariamente il modo migliore per scegliere una lingua.

La richiesta di fama di Erlang è la sua capacità di una massiccia parallelizzazione. Ecco perché è comunemente usato negli interruttori telefonici Ericsson. Erlang è soft-realtime, quindi puoi fare alcune garanzie prestazionali a riguardo.

F # beneficia delle capacità di ottimizzazione di .NET Jitter. Inoltre, il linguaggio stesso è progettato per essere un linguaggio funzionale ad alte prestazioni (essendo una variante di OCaml, ampiamente utilizzato nel settore finanziario a causa della sua velocità).

Alla fine, a meno che tu non preveda di eseguire milioni di piccoli agenti contemporaneamente (che è ciò per cui Erlang è ottimizzato), F # dovrebbe essere all'altezza del compito.

Questa pagina spiega i casi d'uso appropriati per Erlang.


Per "fattibile" intendevo scalabile. So che avere la stampa non significa che quella lingua sia necessariamente migliore, ma sembra che Erlang sia stato provato (almeno da Ericsson). Cosa intendi con agenti? Processi?
afuzzyllama,

1
Sì. È stato dimostrato che Erlang gestisce contemporaneamente molte telefonate su uno switch Ericsson. Devi capire se il tuo caso d'uso è simile. Lo vedo come un caso d'uso relativamente specializzato; se questa caratteristica è assente nella tua applicazione, non vedo alcun vantaggio nell'uso di Erlang e la pagina Erlang descrive effettivamente alcuni casi d'uso per i quali Erlang non è adatto.
Robert Harvey,

2
Agenti, attori, è un concetto di design che emerge molto nelle discussioni linguistiche funzionali; Sono sorpreso che non l'abbia ancora incontrato. it.wikipedia.org/wiki/Agent-based_model
Patrick Hughes

In altre parole, hai bisogno di un'enorme scalabilità (ora o alla fine) del tipo di Erlang? La maggior parte dei programmi no.
Robert Harvey,

1
F # ha anche il modello di agente - usando il "MailboxProcessor" leggermente criptico che è lo stesso tipo di cose di Erlang. Non posso commentare le relative caratteristiche prestazionali di ciascuno però.
Finlandia,

7

Poche affermazioni oggettive possono essere fatte su questo argomento perché le prestazioni di questi due linguaggi dipendono fortemente dall'applicazione e dallo stile di programmazione.

L'unico consiglio che posso dare è che F # ha il vantaggio in termini di prestazioni di un sistema di tipo statico e CLR fa un buon lavoro sfruttandolo per migliorare le prestazioni. F # ha agenti asincroni e passaggio di messaggi ma non è stato ottimizzato e il codice sincrono è spesso 10 volte più veloce.

Erlang è tipizzato in modo dinamico, il che pone uno svantaggio significativo in termini di prestazioni (aspettatevi molto più boxe) ma è stato costruito da zero per supportare il passaggio rapido di messaggi tra agenti asincroni, quindi potrebbe essere molto più veloce dell'equivalente F # . Tuttavia, non ho risultati di benchmark a sostegno di questo: è solo una mia aspettativa.

A parte questo, sia Erlang che F # sono lingue relativamente marginali con piccole comunità e, a causa dei loro diversi mercati target, le persone che hanno familiarità con entrambi sono rare. L'unica persona a cui riesco a pensare che si qualifica quasi è Jesper Louis Andersen, ma non sono sicuro di quanto F # abbia fatto.


4

Dovresti leggere questo post di Joe Armstrong: http://erlang.org/pipermail/erlang-questions/2012-February/064277.html

Il fatto è che Erlang non è stato progettato per essere veloce! È ragionevolmente veloce in molti casi, ma è secondario a problemi come la tolleranza agli errori e la stabilità.

La verità è che sia Erlang che F # sono belle lingue, e mentre ho dato una rapida occhiata a F # ho scritto un libro su Erlang: Creazione di applicazioni Web con Erlang e posso dire che è un linguaggio divertente in cui lavorare.

Vorrei anche sottolineare che sembra esserci un boom dei libri di lingua funzionale che verranno pubblicati nei prossimi 6-9 mesi. Conosco almeno 4 su Erlang (incluso il mio), One su Haskell, nonché Titoli su OCaml, Clojure e F #.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.