Il parallelismo implicito ^ può portare un grosso onere a molti programmatori, collocandolo sul computer. Quindi ... perché non è attualmente più diffuso?
Risposte:
Perché con alcune eccezioni (Haskell) non è possibile 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 può causare la rottura delle cose. In haskell puoi contare su una funzione che è pura, vale a dire che non legge o cambia lo stato globale, quindi possono essere eseguiti in qualsiasi ordine.
Il vero problema è che, con poche eccezioni, come fare bene la concorrenza è ancora un problema aperto. Le comunità di Erlang e Haskell sembrano andare abbastanza bene, ma è ancora molta strada da percorrere prima di capire davvero come programmare un sistema N-core per grandi N.
La maggior parte dei linguaggi di programmazione che stiamo utilizzando è giunta nel momento in cui la programmazione a thread singolo e l'interazione con l'utente singolo sono i più utilizzati per molte applicazioni (ad esempio applicazioni desktop stand-alone). Con l'aumento di applicazioni web, cloud computing e applicazioni multiutente ora abbiamo bisogno di più applicazioni multi thread.
I linguaggi di programmazione legacy stanno cercando di supportare lentamente le funzionalità multi thread dal linguaggio stesso (come java ha aggiunto java.util.concurrent).
Le nuove lingue che arriveranno in futuro avranno un migliore supporto per il threading e la concorrenza.
A parte i punti menzionati nelle altre risposte (difficile dimostrare che le operazioni sono indipendenti e che 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 associati:
La creazione di thread è molto costosa: per il kernel, l'avvio di un thread è quasi lo stesso dell'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: di solito, richiede una chiamata di sistema su ciascun lato, che può mettere in pausa un thread e riattivarlo, producendo latenza, cache fredde e TLB svuotati. In media, prendere e rilasciare un mutex costa circa un microsecondo.
Fin qui tutto bene. Perché questo è un problema per il parallelismo implicito? Perché il parallelismo implicito è più facile da dimostrare su piccola scala. Una cosa è dimostrare che due iterazioni di un semplice ciclo sono indipendenti l'una dall'altra, un'altra cosa è dimostrare che stampare qualcosa stdoute inviare una query a un database sono indipendenti l'uno dall'altro e possono essere eseguiti in parallelo ( il processo del database potrebbe essere dall'altra parte del tubo!).
Cioè, il parallelismo implicito che un programma per computer può dimostrare è probabilmente inesplicabile 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 si suppone che la parallelizzazione sia più veloce del programma seriale, il programma parallelo deve essere in grado di mantenere occupate tutte le CPU per diversi microsecondi tra due chiamate mutex. Ciò richiede un parallelismo veramente grossolano, che è quasi impossibile provare automaticamente.
Infine, nessuna regola senza eccezioni: lo sfruttamento del parallelismo implicito funziona dove non sono coinvolti thread, come nel caso della vettorializzazione del codice (utilizzando set di istruzioni SIMD come AVX, Altivec, ecc.). Funziona davvero meglio per il parallelismo su piccola scala che è relativamente facile da dimostrare.
I programmatori pensano in serie e le lingue attuali sono costruite per supportare quel modello. Ad eccezione delle lingue marginali come Haskell Erlang ecc., Le lingue (mi astengo dall'uso dell'aggettivo "moderno") sono essenzialmente un assemblaggio di alto livello in cui diciamo ancora al computer cosa fare, quando farlo e come farlo. Fino a quando non avremo un sistema ecologico in cui diciamo al computer quale risultato desideriamo sia disponibile, non abbiamo la capacità mentale, come programmatori, di sfruttare appieno la capacità del multithreading.
cioè non è naturale ......
don't have the patiencesia una valutazione più accurata di don't have the mental capacityquanto non lo sia. Nel corso della mia carriera, ho visto molti più programmatori pigri di quelli che ho visto stupidi . Sono stato fortunato, mi hanno insegnato la programmazione funzionale e la programmazione parallela a grana fine insieme a procedurale e OO, nel mio primo anno all'università. Sospetto che molti programmatori non siano stati così fortunati e, di conseguenza, i loro processi di pensiero siano stati sottoposti a un processo diretto.
Le transazioni devono essere ACID, quindi il programmatore tende principalmente a pensare a un thread.
Le lingue e le piattaforme devono proteggere i programmatori dalla concorrenza per quanto possono permettersi
E la concorrenza non è così facile da testare come la stessa funzionalità, quindi i programmatori tendono ad andarsene oltre a questi problemi e, anche, non pensando al commit della gestione della concorrenza, qual è un errore