I linguaggi funzionali sono intrinsecamente più parallelizzabili dei loro OO o cugini imperativi?

Question

Ho letto e pensato un bel po 'su questo. Il ronzio sembra essere quello nel futuro multi-core, le lingue funzionali diventeranno più popolari. Sono relativamente noob alla programmazione funzionale. La mia unica esposizione era accademica, e nulla di abbastanza complicato da mettere davvero alla prova questa classe di linguaggio.

Quindi, a quanto ho capito, le funzioni pure possono essere facilmente e in modo trasparente parallelizzate. Questa è una grande funzionalità, dal momento che non comporta problemi con la scrittura del codice di threading. Tuttavia, non sembra dare molto aiuto con il codice seriale.

Example: 

fooN(... (foo3(foo2(foo1(0))))) 

Le chiamate di serie come questa sembrano essere un problema comune e talvolta inevitabile. Per me questi sono alla radice del perché la parallelizzazione è così difficile. Alcune attività sono semplicemente (o sembrano essere) altamente seriali. Avere una "mentalità funzionale" consente di decomporsi meglio alcune attività apparentemente serie? Esistono linguaggi funzionali esistenti che offrono meccanismi trasparenti per una migliore parallelizzazione del codice altamente seriale? Infine, i linguaggi funzionali sono intrinsecamente più parallelizzabili di OO o lingue imperative, e perché?

Answer 1

I linguaggi funzionali sono più parallelizzabili dei linguaggi imperativi e OO a causa delle funzioni pure. Tuttavia, hai assolutamente ragione, se hai questo tipo di dipendenza dai dati, non puoi parallelizzarlo. Il valore principale della programmazione funzionale sta nel rendere più facile individuare e ragionare il parallelismo presente nel codice, poiché solo le dipendenze dei dati, non lo stato mutabile condiviso, possono interferire. Infatti, poiché la maggior parte dei semplici programmatori mortali hanno difficoltà a lavorare in linguaggi puramente funzionali, e poiché la politica draconiana di disabilitare completamente lo stato mutabile può essere inefficiente, c'è stata qualche ronzio sull'idea di permettere ai corpi delle singole funzioni di essere scritti in modo imperativo , ma non consente effetti collaterali tra le funzioni. In altre parole, tutte le funzioni che devono essere parallelizzate dovrebbero essere pure. Quindi, è possibile avere lo stato mutabile per le variabili locali per rendere il codice più facile da scrivere e più efficiente, ma consentire comunque una parallelizzazione automatica sicura e semplice delle chiamate a queste funzioni pure. Questo è stato esplorato, per esempio, nel ramo 2.0 del linguaggio D.

Answer 2

Si tratta principalmente di effetti collaterali. Se il compilatore sa che alcune parti del codice non hanno effetti collaterali, può ottimizzare in base alla struttura del codice per eseguirne alcune in parallelo.

consideri LINQ in C#/che è semi-funzionale:

var someValues = from c in someArray 
       where // some comparisson with no side effects 
       select c; 

si sta specificando l'intenzione di ciò che si vuole fare, se il compilatore conosceva ogni pezzo di espressione non ha effetti collaterali, potrebbe Assegnare in sicurezza diverse parti dell'array per elaborare su core differenti. In realtà c'è un .AsParalell che arriverà su parallelo linq (plinq), che abiliterà proprio questo. Il problema arriva dal fatto che non sarà in grado di far rispettare il bit senza effetti collaterali (essendo su un linguaggio/framework che non ha supporto per esso), che può diventare davvero brutto se gli sviluppatori non ne sono a conoscenza. A causa di ciò, lo hanno reso esplicito, ma puoi vedere che causano problemi lungo la strada.