Quanto è difficile il multi-threading Haskell?

Question

Ho sentito dire che in Haskell la creazione di un'applicazione multi-thread è semplice come prendere una normale applicazione Haskell e compilarla con il flag -threaded. Altri casi, tuttavia, hanno descritto l'uso di un comando par all'interno del codice sorgente effettivo.

Qual è lo stato di multi-threading Haskell? Quanto è facile introdurre nei programmi? Esiste un buon tutorial multi-threading su questi diversi comandi e sui loro usi?

Answer 1

Qual è lo stato di Haskell multi-threading?

Maturo. L'implementazione ha circa 15 anni, con memoria transazionale per 5 anni. GHC è un compilatore ampiamente utilizzato, con ampio supporto open source e supporto commerciale.

Quanto è facile introdurre nei programmi?

Questo dipende dall'algoritmo. A volte può essere un uso di linea di par per ottenere il parallelismo. A volte devono essere sviluppati nuovi algoritmi. In generale sarà più facile introdurre parallelismo e concomitanza sicuri in Haskell, che nei linguaggi tipici, e le prestazioni sono buone.

Esiste un buon tutorial multi-threading su questi diversi comandi e sui loro usi?

Ci sono 3 principali modelli di programmazione parallela e simultanea in Haskell.

• parallelismo implicito via par
• concorrenza esplicita e parallelismo via forkIO/MVars e software memoria transazionale
• dati parallelismo tramite le librerie DPH

Queste sono le cose principali. In tutti i casi si compila con -threaded per utilizzare il runtime multicore, ma quanto è facile parallelizzare un particolare problema dipende dall'algoritmo che si utilizza e dal modello di programmazione parallelo adottato da tale elenco.

Ecco an introduction to the main parallel programming models in Haskell, e come ottenere gli aumenti di velocità.

Penso che Chapter 24 of Real World Haskell sia un buon tutorial.

Answer 2

C'è anche un termine di concorrenza.

Senza alcuna modifica nel codice tuoi RTS Haskell cercheranno di usarli per qualche processo interno, ma da utilizzare nella propria applicazione si dovrebbe dare un suggerimento che è fatto da par b (f a b) che costringe Haskell non essere così pigro su caculation di b anche se f non lo richiederà per il risultato.

Una delle ragioni per non farlo per ogni funzione che richiede tutti i suoi argomenti (come a+b) è che la sincronizzazione (calcoli di pianificazione e attesa dei risultati) fornisce un sovraccarico e probabilmente non si vuole spendere extra- tick per (2*3)+(3*4) solo perché è possibile calcolare le moltiplicazioni in parallelo. E probabilmente perderai alcuni colpi di cache o qualcosa del genere o ottimizzazioni che vengono fatte quando lo fai su un singolo processore (cioè dovrai passare comunque il risultato da un processore a un altro).

Ovviamente il codice che utilizza par è brutto e quando si piega l'elenco o alcune altre strutture di dati con sotto-elementi di luce probabilmente si vorrà calcolare alcuni pezzi di quegli elementi chiari per assicurarsi che l'overhead/calc sia davvero piccolo Per risolvere il problema, è possibile consultare parallel.

Esiste anche Data Parallel Haskell (DPH).

Se il tuo programma è più incentrato su IO monade di quello che hai sicuramente bisogno di molte modifiche. Vedere forkIO, Software Transactional Memory (STM) e molti altri da Concurrency category