Il parallelismo implicito ^ può togliere un grosso peso a molti programmatori, posizionandolo sul computer. Quindi ... perché non è più diffuso al momento?
^ Il parallelismo implicito è quello di rendere un computer in grado di capire da sé come fare più di una cosa alla volta, invece di un programmatore che ha bisogno di fare questo lavoro usando thread e simili
Perché con poche eccezioni (Haskell) non c'è modo che il compilatore possa scartare un ciclo. Il problema è che ogni iterazione attraverso il ciclo può modificare lo stato globale. Quindi, farlo in un ordine diverso potrebbe causare la rottura delle cose. In haskell puoi contare su una funzione pura, vale a dire che non legge o cambia lo stato globale, in modo che possano essere eseguiti in qualsiasi ordine.
Il vero problema è che, con alcune eccezioni, come fare bene la concorrenza è ancora un problema aperto. Le comunità di Erlang e Haskell sembrano andare piuttosto bene, ma è ancora una lunga strada da percorrere prima di capire veramente come programmare un sistema N-core per grandi N.
La maggior parte dei linguaggi di programmazione che stiamo usando ora è arrivata nel momento in cui la programmazione a thread singolo e l'interazione con un singolo utente sono le più utilizzate per molte applicazioni (es: applicazioni desktop stand alone). Con l'aumento delle applicazioni Web, del cloud computing e delle applicazioni multiutente ora abbiamo bisogno di più applicazioni multi-thread.
I linguaggi di programmazione legacy stanno provando a supportare le funzionalità multi-threaded dal linguaggio stesso lentamente (come java aggiunto java.util.concurrent).
Le nuove lingue che verranno in futuro avranno una migliore funzionalità di threading e supporto alla concorrenza.
Oltre ai punti menzionati nelle altre risposte (difficile dimostrare che le operazioni sono indipendenti e i programmatori pensano in serie), c'è un terzo fattore che deve essere considerato: il costo della parallelizzazione.
La verità è che il parallelismo dei thread ha costi molto significativi ad esso associati:
La creazione del thread è molto costoso: per il kernel, l'avvio di un thread equivale all'incirca all'avvio di un processo. Non sono sicuro dei costi precisi, ma credo che sia nell'ordine di dieci microsecondi.
La comunicazione del thread tramite mutex è costosa: in genere, richiede una chiamata di sistema su ciascun lato, probabilmente mettendo un thread in stop e risveglio, producendo latenza e cache fredde e TLB scaricati. In media, prendere e rilasciare un mutex costa circa un microsecondo.
Finora, tutto bene. Perché questo è un problema per il parallelismo implicito? Perché il parallelismo implicito è più facile da dimostrare sulle piccole scale. Una cosa è dimostrare che due iterazioni di un ciclo semplice sono indipendenti l'una dall'altra, è una cosa completamente diversa dimostrare che la stampa di qualcosa su stdout e l'invio di una query a un database sono indipendenti l'una dall'altra e possono essere eseguite in parallelo (il processo del database potrebbe essere sull'altro lato del tubo!).
Cioè, il parallelismo implicito che un programma per computer può dimostrare è probabilmente non sfruttabile perché i costi della parallelizzazione sono maggiori del vantaggio dell'elaborazione parallela. D'altra parte, il parallelismo su larga scala che può davvero accelerare un'applicazione non è dimostrabile per un compilatore. Basti pensare a quanto lavoro può fare una CPU in un microsecondo. Ora, se la parallelizzazione dovrebbe essere più veloce del programma seriale, il programma parallelo deve essere in grado di mantenere tutte le CPU occupate per diversi microsecondi tra due chiamate mutex. Ciò richiede un parallelismo a grana grossa, quasi impossibile da provare automaticamente.
Infine, nessuna regola senza eccezione: lo sfruttamento del parallelismo implicito funziona dove non sono coinvolti i thread, come nel caso della vettorizzazione del codice (utilizzando set di istruzioni SIMD come AVX, Altivec, ecc.). Questo in effetti funziona meglio per il parallelismo su piccola scala che è relativamente facile da dimostrare.
I programmatori pensano in serie, e le lingue correnti sono costruite per supportare quel modello. Ad eccezione dei linguaggi marginali come Haskell Erlang ecc., Le lingue (mi astengo dall'usare l'aggettivo "moderno") sono essenzialmente assemblaggi di alto livello in cui continuiamo a dire al computer cosa fare, quando farlo e come farlo. Finché non avremo un sistema di eco in cui diciamo al computer quale risultato desideriamo è disponibile, non abbiamo la capacità mentale, in quanto programmatori, di sfruttare appieno la capacità di multithreading.
vale a dire. non è naturale ......
Le transazioni devono essere ACID, quindi il programmatore tende principalmente a pensare a un thread.
Lingue e piattaforme devono proteggere il programmatore dalla concorrenza quanto possono permetterselo
E la concorrenza non è così facile da testare come funcionality stessa, quindi i programmatori tendono a lasciare oltre questi problemi e, anche se non pensano di gestire la gestione della concorrenza, cos'è un errore
Leggi altre domande sui tag concurrency parallelism