Utilizzo di Clojure invece di Python per motivi di scalabilità (multi-core), buona idea? [chiuso]

Can't I make really efficient use of all cores using a more imperative language like Python, than a lisp dialect or other functional language?

Sicuramente puoi . A seconda del tipo di problema (ad es. Elaborare parti chiaramente separabili di qualche grande attività computativa in parallelo), può anche essere abbastanza facile. Immagino che la maggior parte della concorrenza nel mondo sia ancora fatta direttamente nelle lingue imperative, sebbene il paradigma si stia spostando verso soluzioni funzionali.

Python non è esattamente noto per le sue capacità di concorrenza, però. Un esempio di un linguaggio imperativo ben consolidato con un eccellente supporto per la concorrenza è Java.

It seems that all the benefits of it come from using immutable data, can't I do just that in Python and have all the benefits?

Il trucco con dati immutabili è che, se lo fai con le tradizionali e semplici strutture di dati come gli array, finirai con una copia e una garbage collection massicce, rovinando le prestazioni. Invece, vuoi dati effettivamente immutabili , che possono essere implementati con varie strutture dati persistenti , come è fatto in Clojure sotto il cofano. Tali strutture potrebbero essere eseguite in quasi tutte le lingue come biblioteche, ma naturalmente il supporto diretto della lingua è sempre più bello.

Python è estremamente dannoso per le applicazioni che richiedono più thread, ma è causato dalla mancanza delle macchine virtuali disponibili, non dalla lingua stessa. I generatori di Python sarebbero davvero dei buoni candidati per la parallelizzazione implicita. Il problema è che l'implementazione standard, CPython, può eseguire solo il codice python su una CPU, solo le chiamate nelle librerie native possono essere eseguite in parallelo. Il runtime PyPy pianifica di risolverlo, ma non c'è ancora e mentre le implementazioni Jython e IronPython non hanno la limitazione, sono piuttosto incomplete (non hanno molto della libreria standard, devi usare la libreria standard dell'ambiente di hosting in loro).

Tuttavia ci sono molti altri linguaggi progettati e implementati con il parallelismo. Ovviamente il parallelismo è molto più semplice nei linguaggi funzionali, motivo per cui tutte le lingue con un buon supporto per il parallelismo sono funzionali o hanno un strong supporto per la programmazione funzionale. Posso pensare a:

• Haskell , il linguaggio funzionale puro e non rigoroso più usato. La natura pura e non rigorosa consente al compilatore di mettere in parallelo alcune cose in modo implicito.
• Erlang è un linguaggio funzionale rigoroso progettato specificamente per l'implementazione di server paralleli robusti, con supporto integrato per la distribuzione ai cluster.
• Clojure, ovviamente. Come altre lisps è progettato per la programmazione funzionale, ma supporta anche la programmazione imperativa.
• Vai è un nuovo linguaggio procedurale compilato progettato per la concorrenza, anche se né i tempi di esecuzione né il linguaggio stesso sono ancora molto maturi.
• Rust è un nuovo linguaggio procedurale compilato progettato per la concorrenza, il sovraccarico e il controllo statico della memoria e la sicurezza della concorrenza. Neanche molto maturo.

I ragazzi qui hanno dato risposte davvero eccellenti.

La programmazione simultanea di solito è difficile a causa dello "stato di condivisione". La programmazione funzionale potrebbe non essere la risposta definitiva, ma sicuramente la rende fattibile senza perdere i capelli.

Il Clojure è sicuramente un'opzione valida, ma anche con i suoi eccellenti strumenti di concorrenza, potresti aver bisogno di costruire qualcos'altro. Controlla Prismatico per un esempio:

Our backend language choice is Clojure on the JVM. There are other great functional languages on the JVM, like Scala, but what we like about Clojure is that it has a small, simple core focused around processing data represented in its excellent set of persistent data structures (or their mutable java.util equivalents, when the need strikes). While we make heavy use of the core of Clojure, we don't use its concurrency primitives (atoms, refs, STM, etc.) because a function like pmap doesn't have enough fine grained control for our needs. We opt instead to build our own concurrency abstractions in Clojure on top of the outstanding java.util.concurrent package.

Se vuoi davvero scatenarti, controlla anche Julia Programming Language .

Julia does not impose any particular style of parallelism on the user. Instead, it provides a number of key building blocks for distributed computation, making it flexible enough to support a number of styles of parallelism, and allowing users to add more.

Oltre a ciò che Jan Hudec ha scritto, vorrei menzionare Scala che, oltre a uno stile di programmazione funzionale, supporta anche un imperativo / stile di programmazione orientato agli oggetti.

Scala offre il parallelismo attraverso attori (usato anche da Erlang).

Note that I don't think that using semaphores, lock mechanisms or other similar concurrency mechanism are good alternatives to Clojure 'automatic' parallelization.

Gli attori sono una modalità di astrazione orientata agli oggetti dai thread / processi sottostanti: in pratica si vedono solo oggetti in esecuzione simultanea e l'invio reciproco di messaggi. Quindi, se vuoi un modo orientato agli oggetti di implementare il parallelismo, lo farei dare anche un'occhiata alle lingue (o ai framework) che supportano il modello degli attori.

Puoi trovare alcuni link su wikipedia , per Python c'è ad es. Pykka .