Acabou o almoço grátis? [fechadas]


12

Em seu famoso artigo The Free Lunch Is Over, de 2005, Herb Sutter previu uma Revolução de Programação Concorrente tão grande quanto a Revolução Orientada a Objetos. Essa revolução realmente aconteceu nos anos de 2005 a 2013?


Pontos principais no artigo:

  • Os fabricantes de processadores ficaram sem espaço com a maioria de suas abordagens tradicionais para aumentar o desempenho da CPU. Em vez de aumentar a velocidade do relógio, eles estão se voltando para arquiteturas hyperthreading e multicore.

  • Os aplicativos precisarão cada vez mais ser concorrentes se quiserem explorar totalmente os ganhos de taxa de transferência da CPU.

  • “Ah, o desempenho não importa tanto, os computadores estão ficando cada vez mais rápidos” a instrução estará errada.

  • A eficiência e a otimização do desempenho serão cada vez mais importantes. As linguagens que já se prestam a otimização pesada encontrarão nova vida; aqueles que não precisam encontrar maneiras de competir e se tornar mais eficientes e otimizáveis. Espere aumento da demanda a longo prazo por sistemas e linguagens orientadas para o desempenho.

  • Linguagens e sistemas de programação serão cada vez mais forçados a lidar bem com a simultaneidade. Precisamos desesperadamente de um modelo de programação de nível superior para simultaneidade do que as línguas oferecem hoje.


15
Quantos núcleos seu telefone possui?
Matt D

6
Meu Nokia 2700 tem um núcleo.
Cpp

5
@ MattD Desculpe, mas por que é "hora de atualizar" e o que o número de núcleos no telefone da cpp tem a ver com isso? Como você sabe que um Nokia 2700 não é suficiente para suas necessidades?
Andres F.

2
Vou registrar, por uma observação totalmente não científica, que houve uma revolução no lado do hardware, mas a revolução do software foi extraordinariamente lenta. Obter ferramentas simultâneas de qualidade para todos os programadores ainda é uma tarefa difícil e a simultaneidade ainda é algo que atrapalha até mesmo desenvolvedores paralelos experientes de maneiras difíceis de reproduzir.
Jesse C. Slicer

2
Eu só quero ressaltar que, apenas porque o momento das previsões está errado, isso não necessariamente as torna erradas. É óbvio que os pontos principais que você listou acima não obtiveram a importância implícita, mas houve etapas na direção de cada um desses pontos. Então, eu diria que as previsões acima se tornarão verdadeiras, é apenas uma questão de quando. O WHEN será quando se tornar um requisito e não apenas um desejo. Saber quando esse limite será ultrapassado é por que prever quando é tão difícil.
Húmido

Respostas:


23

Sim, mas depende.

Você não pode esperar escrever software não trivial e de alto desempenho sem tirar proveito do hardware paralelo e usar a simultaneidade como uma técnica de estruturação de programa. Mas a maioria dos softwares é trivial e não crítica ao desempenho. Um aplicativo Web não está processando muito números, e os aplicativos CRUD não têm nada como os limites de tempo de alguns softwares médicos e de simulação.

Os desenvolvedores de jogos, em particular, precisam se preocupar com isso, porque os jogos são o tipo mais comum de aplicativo com requisitos em tempo real. O problema é evidente em um telefone celular, no qual você deseja extrair o máximo possível de computação e renderização de um chip integrado com dois núcleos de CPU e uma GPU de baixa potência. Essa é outra razão pela qual muitos desenvolvedores estão olhando para Haskell e aguardando idiomas como Rust amadurecer - queremos segurança e desempenho em hardware moderno.

Desde 2005, adquirimos ferramentas novas e aprimoradas, como OpenCL, CUDA, OpenMP e conjuntos de instruções vetoriais para trabalhar com simultaneidade e paralelismo de dados em idiomas estabelecidos. No entanto, os recém-chegados relativos são projetados desde o início para fazer muitas coisas mais interessantes com simultaneidade.

O tempo de execução simultâneo de Haskell permite que o idioma forneça suporte avançado para paralelismo leve (faíscas) e abstrações de simultaneidade (threads, canais e referências mutáveis ​​compartilhadas). O Go e o Rust também oferecem tarefas leves, o Go usando canais e o Rust usando a passagem de mensagens.

Esses sistemas oferecem segurança de memória, tempos de execução de desempenho e proteção estática contra certos tipos de raças. A imutabilidade padrão de Haskell e Rust torna a concorrência muito mais fácil para os humanos gerenciarem. Erlang fazia isso nos anos 80, mas as necessidades do software e nosso conhecimento sobre como projetar sistemas de programação também melhoraram desde então - graças a Deus.

Por fim, muitos idiomas existentes - não vou citar nomes - estão prontos para declinar como escolhas credíveis para escrever um novo software. Seus encargos de complexidade e abstrações de simultaneidade fracas os tornam inadequados para as considerações de aplicativos modernos. Estamos simplesmente esperando por alternativas maduras.


2
Não tenho tanta certeza sobre o declínio de certos idiomas, espero que vejamos o código escrito com mais foco na minimização de dependências do que qualquer outra coisa. Afinal, não é realmente o idioma que está com defeito, é como você o usa. E a "fruta baixa" de seu uso não está mais alinhada com multithread / simultaneidade.
Matt D

6
@ MattD: Tanto a maneira como você usa um idioma quanto o próprio idioma podem estar errados . Diga que seu programa está errado. Foi você quem escreveu errado, mas o idioma não ajudou necessariamente a escrever direito , e isso é tão importante quanto.
Jon Purdy

6

Aqui estão alguns pontos de dados; decida por si mesmo se isso conta como uma revolução.

Hardware paralelo

Por volta de 2005, a Intel e a AMD iniciam CPUs de desktop x86 de dois núcleos com produção em massa (Pentium D e Athlon 64), com velocidades de clock em torno de 3 GHz.

Em 2006, o PlayStation 3 é lançado, apresentando o processador Cell com 8 + 1 núcleos a 3,2 GHz.

Em 2006, a série GeForce 8 foi lançada. Consiste em grandes números (~ 100) de 'processadores de fluxo' de uso geral, em oposição a unidades específicas de gráficos. Por volta de 2007, as especificações CUDA 1.0 são liberadas, permitindo que alguns cálculos de uso geral sejam executados em hardware NVidia massivamente paralelo.

Desde então, as tendências continuaram.

Digamos, agora, em 2013, a Intel e a AMD oferecem CPUs de 4, 8 e 16 núcleos, com velocidades de clock ligeiramente acima de meros 4 GHz. Projetos de núcleo duplo e quad-core são comuns para dispositivos de menor consumo de energia, como laptops e smartphones.

Tudo isso é um hardware de computador diário produzido em massa e de qualidade para o consumidor.

Programas

O CUDA é lançado em 2007, depois o OpenCL em 2008, permitindo o uso de GPUs paralelas em massa em computação geral (não gráfica). O modelo se torna popular; muitas empresas de hospedagem (por exemplo, Amazon) oferecem GPUs para tarefas gerais de computação.

O Go foi lançado em 2009, apresentando threads preventivos muito baratos ("goroutines") e permitindo expressar com eficiência algoritmos altamente concorrentes.

O kit de ferramentas Akka foi lançado para Java e Scala em 2009, permitindo a simultaneidade baseada em ator.

Erlang (um idioma altamente concorrente) vê algum aumento no uso.

Simultaneidade vs Paralelismo

Observe que, para utilizar hardware paralelo, não é necessário, necessariamente , simultaneidade de software , ou seja, manipular threads de execução em uma computação. Muitos problemas são resolvidos por processos paralelos e sem interação, onde cada processo é um programa seqüencial tradicional.

O processamento paralelo pode utilizar linguagens mais tradicionais e estruturas paralelas, como redução de mapa ou MPC ou OpenMP. Para essas estruturas, a presença de vários núcleos no mesmo cristal de CPU não é conceitualmente muito diferente de apenas ter mais CPUs no cluster; a diferença é principalmente velocidade.

Até agora, não há almoço grátis

As velocidades da CPU ainda permanecem em torno de 5 GHz na extremidade alta. Com melhores tecnologias à vista, como transistores de grafeno, as frequências podem aumentar novamente no futuro, mas provavelmente não muito em breve.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.