Por que o paralelismo / concorrência implícita não é mais difundido? [fechadas]

O paralelismo implícito ^ pode tirar um fardo de muitos programadores, colocando-o no computador. Então ... por que não é mais difundido no momento?

Porque, com algumas exceções (Haskell), não há como o compilador desembrulhar um loop. O problema é que cada iteração através do loop pode modificar o estado global. Portanto, fazer isso em uma ordem diferente pode fazer com que as coisas quebrem. No haskell, você pode contar com uma função pura, ou seja, não lê ou altera o estado global, para que possa ser executada em qualquer ordem.

O problema real é que, com poucas exceções, como fazer bem a concorrência ainda é um problema em aberto. As comunidades Erlang e Haskell parecem estar indo muito bem, mas ainda é um longo caminho a percorrer antes de realmente entendermos como programar um sistema N-core para grandes N.

A maioria das linguagens de programação que estamos usando agora veio no momento em que a programação de thread único e a interação de usuário único são as mais usadas para muitos aplicativos (por exemplo: aplicativos de desktop independentes). Com o aumento de aplicativos da Web, computação em nuvem e aplicativos multiusuário, agora precisamos de mais aplicativos multiencadeados.

As linguagens de programação herdadas estão tentando oferecer suporte aos recursos multiencadeados da própria linguagem lentamente (como o java adicionado java.util.concurrent).

Os novos idiomas que virão no futuro terão melhor suporte de encadeamento e simultaneidade.

Além dos pontos mencionados nas outras respostas (difícil provar que as operações são independentes e os programadores pensam em série), há um terceiro fator que precisa ser considerado: o custo da paralelização.

A verdade é que esse paralelismo de encadeamento tem custos muito significativos associados a ele:

• A criação de threads é muito cara: para o Kernel, iniciar um thread é quase o mesmo que iniciar um processo. Não tenho certeza dos custos precisos, mas acredito que seja da ordem de dez microssegundos.

• A comunicação de encadeamento por mutexes é cara: geralmente, isso requer uma chamada do sistema de cada lado, possivelmente colocando um encadeamento em suspensão e ativando-o novamente, o que produz latência, além de caches frios e TLBs liberados. Em média, obter e liberar um mutex custa em torno de um microssegundo.

Por enquanto, tudo bem. Por que isso é um problema para o paralelismo implícito? Porque o paralelismo implícito é mais fácil de provar em pequenas escalas. Uma coisa é provar que duas iterações de um loop simples são independentes uma da outra; é totalmente diferente provar que a impressão de algo stdoute o envio de uma consulta para um banco de dados são independentes um do outro e podem ser executados em paralelo ( o processo do banco de dados pode estar do outro lado do canal!).

Ou seja, o paralelismo implícito que um programa de computador pode provar é provavelmente inexplorável, porque os custos da paralelização são maiores que a vantagem do processamento paralelo. Por outro lado, o paralelismo em grande escala que pode realmente acelerar um aplicativo não é comprovável para um compilador. Pense em quanto trabalho uma CPU pode fazer em um microssegundo. Agora, se a paralelização for mais rápida que o programa serial, o programa paralelo deve ser capaz de manter todas as CPUs ocupadas por vários microssegundos entre duas chamadas mutex. Isso requer um paralelismo realmente granular, o que é quase impossível de provar automaticamente.

Finalmente, nenhuma regra sem uma exceção: a exploração do paralelismo implícito funciona onde não há threads envolvidos, como é o caso da vetorização do código (usando conjuntos de instruções SIMD como AVX, Altivec, etc.). Isso realmente funciona melhor para o paralelismo de pequena escala que é relativamente fácil de provar.

Os programadores pensam em série, e as linguagens atuais são construídas para suportar esse modelo. Com exceção das linguagens periféricas, como Haskell Erlang, etc, as línguas (evito usar o adjetivo "moderno") são essencialmente de montagem de alto nível, onde ainda dizemos ao computador o que fazer, quando e como fazê-lo. Até que tenhamos um sistema de eco em que digamos ao computador que resultado queremos é avaliável, não temos capacidade mental, como programadores, de fazer pleno uso da capacidade de multithreading.

ou seja, não é natural ......

As transações devem ser ACID; portanto, o programador tende a pensar principalmente em um segmento.

Idiomas e plataformas devem proteger o programador da concorrência, tanto quanto puderem pagar

E a simultaneidade não é tão fácil de testar quanto a própria funcionalidade; portanto, os programadores tendem a sair além desses problemas e, mesmo, sem pensar em confirmar o tratamento da simultaneidade, o que é um erro