Supercomputer Seeks Comeback

Artigo na Wired.

Mais um livro que chega

Agora foi Concepts, Techniques and Models of Computer Programming de Peter Van Roy e Seif Haridi, considerado o novo SICP.

A falta de posts reflete o fato que ultimamente não tenho estudado muito, mas espero voltar à ativa em breve.

The Role of the Study of Programming Languages in the Education of a Programmer

Transcrição de uma palestra proferida por Dan Friedman (pdf, ps).

Defende que todo programador deve estudar ao menos o essencial sobre os mecanismos utilizados pelas linguagens de programação, apresentando exemplos de transformações e testemunhos de ex-alunos. A idéia é que entendendo os mecanismos básicos das linguagens, de forma independente das sintaxes específicas, pode-se trabalhar com os programas como dados, realizando transformações que preservam a semântica a fim de melhorar propriedades do código. E que para entender os mecanismos, é importante ver implementações dos mesmos; implementar as idéias em outra linguagem (no caso, Scheme).

É a abordagem utilizada no Essentials of Programming Languages.

Parallel and Distributed Programming Using C++

Livro de 2003, de autoria de Cameron Hughes e Tracey Hughes.

Superficial e sem foco, apesar de ter alguns exemplos que podem ser úteis para a implementação de sistemas usando PVM, pthreads ou MPI. Os primeiros capítulos são mais conceituais, e possivelmente a parte mais útil do livro (embora seja também superficial). Os capítulos "aplicados" tratam mais de C++ e UML do que do tópico do livro. E os capítulos finais, que deveriam ser os grandes exemplos e estudos de caso, se limitam a discutir um pouco sobre a arquitetura dos sistemas e mostrar meia dúzia de linhas de código. Vagamente interessante, mas nada muito proveitoso.

Novos livros

Chegaram hoje:

Introduction to Process Algebra, de Wan Fokkink

Communicating and Mobile Processes: the Pi-calculus, de Robin Milner

Postarei resenhas quando estiver lendo e/ou terminado de ler.

Motivações

Em algum post anterior eu fiz a pergunta "Por que usar processamento paralelo/concorrente?". A resposta que eu dei no mesmo post se baseou em ganhos de eficiência. Esta talvez seja, sim, a principal motivação para usar processamento paralelo, especialmente em aplicações científicas. Mas não é a única possibilidade.

Além de alta eficiência, pode-se usar sistemas paralelos para alta disponibilidade. A idéia, neste caso, é ter uma rede com nós redundantes de forma que, mesmo se alguns nós falharem o sistema inteiro continua executando suas funções sem maiores problemas. É o mesmo tipo de redundância-como-tolerancia-a-falhas que encontramos em sistemas de disco RAID, servidores de bancos de dados e sondas espaciais da NASA. A questão aí, quando se lida com informações e processamento, é como manter os nós redundantes em sincronia para que a falha não seja percebida externamente: o nó redundante que entra em ação para substituir o nó problemático deve continuar exatamente onde ele parou.

Essa noção de redundância também encontra analogias na biologia. Os sistemas biológicos normalmente contem redundâncias, do código genético a partes macroscópicas de corpos que se regeneram, passando pelos neurônios no cérebro (de novo). Parece ser uma forma óbvia de criar sistemas robustos e tolerantes a falhas.

O que mais podemos levantar como motivos ? Alguns (por ex. Joe Armstrong, criador da linguagem Erlang) defendem que alguns sistemas são mais naturalmente modelados por tarefas concorrentes, ao invés de uma única sequencial. Além disso, podemos pensar em modularidade: se temos tarefas isoladas que se comunicam com as outras, mas cada uma fazendo seu trabalho, temos fronteiras de abstração mais administráveis e interfaces mais definidas, reduzindo o acoplamento; isso pensando em um modelo de concorrência com passagem assíncrona de mensagens. Componentes concorrentes com estado compartilhado (shared state) se tornam mais acoplados do que se fossem realizados sequencialmente. Essa é a diferença de abordagem de Erlang e outros versus o modelo de concorrência encontrado em linguagens populares como Java e C#.

Além do mais, do jeito que as coisas vão, em pouco tempo ninguém precisará mais pensar muito em motivos para usar o paralelismo: a tendência é realmente usar sistemas multi-processados e com processamento paralelo mesmo em equipamentos domésticos e consoles de video-game. Sistemas paralelos e distribuídos parecem ser o futuro da computação, em escalas e instâncias variadas.

Paralelismo e o cérebro humano

No cérebro temos dezenas de bilhões de neurônios, e eles operam paralelamente. Os sinais são transmitidos em cadeias de neurônios, mas isso acontece em várias cadeias ao mesmo tempo.

A analogia com processadores paralelos é óbvia, e também nada nova. O projetista da connection machine, Daniel Hillis, pensou em criar uma máquina que funcionasse de forma similar à mente humana. Tanto que o nome da empresa que ele fundou era Thinking Machines Corporation, e até hoje fala-se da connection machine relacionada à Inteligência Artificial. Paralelismo massivo para simular o processamento realizado pelo cérebro.

O interessante, ao meu ver, é que apesar do cérebro, fisiologicamente, funcionar de maneira paralela, nosso pensamento se aproxima mais de algo sequencial. Não é linear, em geral, mas só conseguimos pensar em uma coisa de cada vez, mesmo que numa sucessão tão rápida que às vezes nem lembramos de tudo. O processamento sequencial faz parte de como pensamos.

O que isso implica para as pessoas que querem construir sistemas paralelos/concorrentes ? E será possível ter paralelismo nas camadas inferiores, mas um modelo sequencial na superfície (que é mais fácil de entender, portanto), de forma similar ao cérebro ?

Idéias soltas

• Hierarquias de sistemas concorrentes (threads, processos, nós, redes, clusters, grids)
  
• Formalismos: CSP, CCS, pi-calculus
• Linguagens: Occam, Erlang, Oz, Alice, CML, Concurrent Haskell, etc
• Abordagem: o problema do paralelismo/concorrência como um problema de linguagens de programação/expressividade do programador
• Especificações explícitas (Haskell#)
• Impedance mismatch entre linguagens de computação e coordenação
• Grids e clusters: o panorama arquitetural dos sistemas computacionais do futuro
  

Execução sequencial ?

Em oposição à execução concorrente. Imagine seu computador doméstico (garden-variety), que deve ser um Pentium qualquer, ou Athlon, Duron, Celeron, K6, o que seja. Digamos que seja um Pentium III: este é o processador, ou CPU do computador; como o próprio nome diz, é a unidade central de processamento. Tudo que a CPU faz é obedecer ordens, ou seja, executar as instruções que recebe. As instruções estão na memória, e são códigos que dizem "some estes dois números e me dê o resultado", ou coisas similares. O interessante é que, apenas com as operações aritméticas e operações para mover dados na memória de um lugar para o outro, o computador consegue fazer tudo que faz...

Mas estou me desviando do assunto. O importante aqui é que temos apenas um processador nos nossos computadores caseiros usuais. E, a rigor, um processador só pode executar uma instrução de cada vez (*). Por isso dizemos que a execução é sequencial.

E a multitarefa ? E o editor de texto, navegador web, programa de email e campo minado rodando ao mesmo tempo ? Truque simples: tendo vários programas para executar, o processador alterna entre eles o tempo todo, de forma muito rápida. Por exemplo, digamos que existam apenas 5 programas executando. O processador pode executar cada um deles por 2 décimos de segundo de cada vez; em cada segundo, todos os 5 programas serão executados durante algum tempo. Para o usuário, não dá para perceber essas trocas, porque elas são muito rápidas, normalmente mais rápidas que 2 décimos de segundo. E os processadores atuais executam milhares ou milhões de instruções em apenas 2 décimos de segundo. Assim, cria-se a ilusão de vários programas rodando ao mesmo tempo, apesar do processador continuar executando apenas uma instrução de cada vez.


* Isso é uma simplificação. Nos processadores atuais as instruções são executadas em pipelines superescalares; isso significa que, a rigor, mais de uma instrução é executada simultaneamente. Mas com restrições: as instruções devem estar em fases diferentes de execução e são obtidas (fetch) sequencialmente. Os detalhes são complicados, mas em suma isso significa que não é concorrência arbitrária; no fundo, é apenas uma forma de acelerar a execução sequencial.

Antes que eu me esqueça...

Vou comentar mais sobre a Connection Machine assim que chegar o livro que eu encomendei. Também pretendo definir, de maneira tentativa, o que são sistemas de processamento paralelo e o que são sistemas distribuídos, quais as diferenças entre eles, e outras considerações taxonômicas. E então chegar num ponto onde eu vou tentar responder, principalmente para mim mesmo, qual é a relevância desses assuntos, hoje e no futuro.

Mas vai ser assim, aos pedaços, e tudo diretamente da minha cabeça, sem edição. Então não me culpe se você copiar o que eu digo aqui em um trabalho e o professor expressar a frustração dele com muita tinta vermelha. De resto, a caixa de comentários está aí, logo abaixo dos posts.

Novidade

Não são assuntos realmente novos. As idéias por trás do processamento paralelo são quase tão antigas quanto os computadores em si (lembrando que os computadores analógicos operavam de maneira paralela, por assim dizer). Computação distribuída, apesar de estar na moda, também não é novidade. Sobre processamento maciçamente paralelo existem trabalhos pioneiros como a connection machine, com a qual até o lendário físico Richard Feynman esteve envolvido.

Por que usar arquiteturas que realizam processamento paralelo ? Intuitivamente, sempre pareceu que ter vários processadores colaborando para uma tarefa comum deveria ser mais eficiente que um único processador trabalhando sequencialmente na mesma tarefa. Imagine, então, se pudéssemos ter dezenas, centenas, quem sabe milhares de processadores trabalhando em conjunto... teríamos um poder de processamento além da imaginação, e poderíamos calcular (computar) várias coisas que são impossíveis hoje em dia.

Essa foi exatamente a idéia por trás da Connection Machine. Mas aí de cara surgiram as dificuldades: a comunicação e coordenação dos processadores se tornaram tão complicadas que o esforço realizado para realiza-las praticamente inviabilizou o projeto. Os projetistas da connection machine tiveram de baixar a bola e pensar mais com os pés no chão, abandonando as idéias iniciais.

E assim foi a história do processamento paralelo, aparentemente. A promessa é tentadora mas os custos altos demais, o que sobe o nível dos problemas para os quais compensa pagar. Por décadas, os supercomputadores usados em aplicações científicas e militares de ponta utilizaram o processamento paralelo como base para sua eficiência. Mas quem pode pagar por um deles ? Apenas um punhado de gente nos países muito ricos.

Mas aí apareceram os clusters na história.

Começando

O assunto é processamento paralelo. Ou computação distribuída. Não são a mesma coisa, mas pode ser um dos dois. E, em comum entre eles existe a noção de concorrência: duas ou mais coisas que acontecem simultaneamente. Na programação concorrente temos tarefas que executam simultaneamente em busca de um objetivo comum.

Multitarefa é outra coisa; nesse tipo de sistema, temos várias tarefas que executam simultaneamente, mas são independentes entre si. Editor de texto, navegador web, programa de email, tudo executando ao mesmo tempo, nos sistemas multitarefas que são corriqueiros hoje em dia.

Na programação concorrente não, as tarefas se comunicam e devem ser coordenadas. Daí os desafios de sincronização e comunicação, sobre os quais ainda se falará muito.

Início

E aqui começamos com esse blog que vai servir de dump para pensamentos e leituras e etc da minha pesquisa.