Il GC OCaml impone un blocco globale che impedisce ai mutatori (thread) di essere eseguiti in parallelo sebbene possano essere eseguiti contemporaneamente (interleaved). Credo che lo stesso valga per SML/NJ e MLton ma non per PolyML, GHC, F #, Clojure e Scala.Quali implementazioni del linguaggio funzionale consentono ai thread di funzionare in parallelo?
Quali altre implementazioni del linguaggio funzionale consentono ai thread di funzionare in parallelo?
Sono felice di dirvi che tu abbia ragione e che F #, essendo basato su CLR, non soffre di tale limitazione a tutti, e invece beneficia di multithreading specifica funzionalità tra cui async workflows, the mailboxprocessor e la meravigliosa libreria di Parallel Task (.NET 4.0).
Haskell supports parallel threads via Data Parallel Haskell
Scala e Clojure sono entrambi in esecuzione sulla JVM, il che consente una concomitanza reale senza alcun singolo punto di colli di bottiglia.
Puoi raccomandare un collegamento a qualcosa sulla programmazione parallela in Scala? –
Scala supporta gli attori http://www.scala-lang.org/node/242 se ti piace quel modello ed è possibile utilizzare java.util.concurrency proprio come faresti in Java. Suppongo che dato che la domanda riguarda la programmazione funzionale, gli attori sono più appropriati. –
Oltre a Haskell, è possibile eseguire i processi contemporaneamente in Erlang (Programmazione orientata alla concorrenza) e lo si può fare anche in F # utilizzando .NET Parallel Extensions e Asynchronous Workflows.
Erlang implementa i propri processi e la pianificazione dei processi e consente migliaia, decine di migliaia e persino milioni di processi di Erlang (all'interno di un singolo processo del sistema operativo).
Nelle macchine SMP e multi-core, la macchina virtuale Erlang assegna il numero di thread del sistema operativo e i processi del sistema operativo alla pianificazione dei processi e alla coda dei processi per ottimizzare l'utilizzo delle operazioni concorrenti sottostanti nell'architettura hardware.
Il paradigma della concorrenza esposto alle applicazioni rimane lo stesso, ovviamente.
Esistono numerose buone implementazioni. Al momento, le persone Haskell sembrano ottenere i migliori risultati (vedere ICFP 2009 paper by Simon Marlow and others e Haskell Symposium 2009 paper by Donnie Jones and others). Erlang è abbastanza vicino, soprattutto se vuoi andare distribuito.
In sei a dodici mesi le risposte possono essere cambiati :-)
Questi risultati di Haskell sono inutili: le loro implementazioni parallele sono spesso di ordine di grandezza più lente della maggior parte delle implementazioni seriali. –
@Jon: dov'è la tua prova? –
Confrontare le misurazioni delle prestazioni riportate nei documenti citati con programmi equivalenti scritti in altre lingue. Ad esempio, il secondo documento fornisce risultati sulle prestazioni per quicksort parallelo (~ 14s per ordinare solo 100k ints) che sono 100 volte più lenti di una soluzione decente nella maggior parte degli altri linguaggi. Puoi anche confrontare i loro programmi paralleli da soli. Ho condotto uno studio esaustivo sull'ingenua parallelizzazione di Saynte applicata a quattro delle implementazioni Haskell di Lennart del mio ray tracer e ho scoperto che uno smetteva di ridimensionare a 6 core e tutti gli altri smettevano di ridimensionare a soli 5 core. –
python non è un linguaggio particolarmente funzionale, e con la GIL, non è molto parallelo, sia, ma in combinazione con il modulo multiprocessing (standard dal 2.6), ottieni entrambi, ma non è così elegante come i linguaggi funzionali puri.
from multiprocessing import Pool
def f(x):
return x*x
if __name__ == '__main__':
pool = Pool(processes=4) # start 4 worker processes
result = pool.apply_async(f, [10]) # evaluate "f(10)" asynchronously
print result.get(timeout=1) # prints "100" unless your computer is *very* slow
print pool.map(f, range(10)) # prints "[0, 1, 4,..., 81]"
Non mi aspettavo che questa risposta fosse terribilmente popolare, ma per favore spiega un po 'quello che trovi così discutibile riguardo questa tecnica? – SingleNegationElimination
La mia domanda riguardava specificamente i thread e non i processi. –
CPython presenta un problema che coinvolge i thread del kernel simultanei, impedendo il suo pieno utilizzo. il modulo multiprocessing consente di utilizzare un'interfaccia quasi identica a processi anziché thread per ottenere risultati quasi identici. Questo problema non è presente in altre versioni di Python perché manca il GIL. – SingleNegationElimination
Solo alcune aggiunte Ad ulteriore conferma parti della lista speculativa:
Poly/ML supporta discussioni nativi (thread POSIX o discussioni Windows) dalla versione 5.2 (dal 2006). L'attuale Poly/ML 5.5 (estate 2012) ha migliorato il supporto per la gestione della memoria parallela: alcune delle fasi GC utilizzano thread multipli, esiste un supporto speciale per la condivisione online di valori immutabili per ridurre l'ingombro di memoria di applicazioni enormi.
Isabelle/ML fornisce una libreria futura aggiuntiva per i thread Poly/ML. Isabelle è un dimostratore di teoremi interattivi, ma è integrato con una versione aumentata SML basata su Poly/ML.
Data Parallel Haskell è ancora abbastanza sperimentale, ma il supporto per il thread parallelo nel primo collegamento è molto più maturo. DPH è implementato con thread paralleli, non viceversa. –
Grazie per aver chiarito che –