QUICKUPDATE

A Crise dos Threads

Paralelizar ou no paralelizar... H escolha?
a Edio 31 (Novas Fronteiras na Evoluo do Java), escrevi: a escalada dos Gigahertz est nos ltimos suspiros. Acabou a facilidade de tornar suas aplicaes duas vezes mais rpidas a cada 18 meses, simplesmente instalando uma CPU com freqncia duas vezes maior. Ser preciso instalar um nmero maior de CPUs para continuar ganhando desempenho. Na poca em que escrevi esse texto, CPUs dual-core eram novidade. Hoje temos laptops dualcore de baixo custo, desktops quad-core acessveis, e no high-end, servidores comerciais disponibilizando at 768 ncleos num nico sistema1. Em vrios artigos falando do assunto, tenho advertido ao

leitor da importncia desse assunto e agora o fao de forma mais explcita: fique logo fera em concorrncia, pois logo isso ser to importante quanto algoritmos, estruturas de dados, OO... Mas, alto l! Esse j um discurso antigo. Mais de trs anos j se passaram, desde que Herb Sutter nos avisou que The Free Lunch is Over2. E agora? O que aconteceu? O que mudou? Como esto as ferramentas, linguagens, desenvolvedores? Vamos fazer um estado da arte da questo do paralelismo no desenvolvimento de software.
1 Um modelo da Azul Systems, com 16 CPUs Vega2, cada uma contendo 48 ncleos. 2 http://www.gotw.ca/publications/concurrency-ddj.htm

Os descontentes
O fato que me motivou a escrever este artigo foi ver um nmero crescente de artigos, blogs e discusses do contra. Nem todo mundo est satisfeito com a necessidade de empregar paralelismo em toda parte. E no me refiro apenas a programadores iniciantes, preguiosos, ou pouco talentosos. Veja, por exemplo, o guru da programao Donald Knuth, reclamando do seu desgosto com a tendncia para arquiteturas multicore: Me parece que os designers de hardware esgotaram suas idias, e esto tentando passar o abacaxi para os programadores dando-nos mquinas que s so mais rpidas

8 Java Magazine Edio 58

Java59.indb 8 01.07.08 18:17:48

E como?
para uns poucos benchmarks! Eu no ficaria surpreso se toda a idia de multithreading acabe se revelando um fiasco, pior que o do Itanium. (...) Nos ltimos 50 anos eu escrevi mais de mil programas, muitos dos quais com tamanho considervel. No consigo pensar sequer em cinco desses programas que se beneficiariam muito de paralelismo.3 No entanto, Knuth humilde ao afirmar que prefere focar naquilo que conhece melhor, concluindo: Outros entendem mquinas paralelas bem melhor do que eu; os programadores devem escutar a eles, no a mim, para conselhos sobre programao concorrente. Em outro texto, Threads considered Harmful, James Reinders faz um paralelo com o famoso paper GOTO Statement Considered Harmful de Edsger Dijkstra, que em 1968 teve enorme influncia ao promover a programao estruturada. Reinders uma das muitas vozes denunciando que os threads so a verso moderna do GOTO: produzem cdigo-espaguete, s que de uma forma diferente em outra dimenso, a do tempo. O problema, no entanto, no necessariamente a programao concorrente (PC), e sim a tcnica especfica de threads. Da mesma forma que Dijkstra no era contrrio a todas as estruturas de controle, s ao GOTO por ser muito primitivo e indisciplinado, a reclamao moderna que threads e locks so uma espcie de programao Assembly da PC. So ferramentas demasiado rudes. Adequadas para cenrios de baixo nvel, como um sistema operacional, ou o corao de um Application Server que deve atender a milhares de requests simultneos com uma eficincia extrema. Inadequadas, porm, para aplicaes em geral, em cuja balana a facilidade de desenvolvimento e manuteno tm sempre um peso muito alto.
Listagem 1. Exemplo de Fortress
component contaPrimos export Executable

Muitos esto insatisfeitos com a guinada da indstria em direo s arquiteturas multicore, exigindo processamento concorrente. Precisamos de melhores ferramentas, e elas esto vindo

OSVALDO PINALI DOEDERLEIN

run(args:String...); ()=do var nPrimos:Z32=0 for i <- 1#1000 do if (isPrimo(i)) then atomic nPrimos += 1 end end println(Primos entre 1 e 1000: nPrimos) end end

As alternativas
Criticar o status quo dos threads e locks fcil, mas uma crtica construtiva exige solues para o dilema: afinal, nenhuma quantidade de gritaria ir reverter as tendncias da tecnologia para no falar nos limites da fsica resultando em CPUs de 50GHz no ano que vem.
Existem, sim, alternativas para voltar aos bons tempos das CPUs cada vez mais rpidas: tcnicas revolucionrias, envolvendo novos materiais ou modelos de computao. Nesta categoria encontramos a computao quntica, computadores de DNA, chips de carbono (nanotubos ou grafeno), ou fotnica (uso de ftons ao invs de eltrons). Infelizmente, todos esses campos tm evoludo num passo glacial, enfrentando obstculos monumentais para questes prticas de produo e operao. Para no descartar estas tcnicas como fico cientfica, podemos dizer que est muito longe dcadas ou mais o dia em que podero resultar em CPUs produzidas em larga escala.

3 http://www.informit.com/articles/article.aspx?p=1193856

A resposta da comunidade de programao veio na forma de ferramentas de mais alto nvel que, respondendo crtica de James Reinders, substituem (ou encapsulam) operaes de PC primitivas, oferecendo um leque de facilidades de mais alto nvel. Linguagens de programao otimizadas para PC no so novidade. As mais antigas so linguagens de pesquisa / acadmicas, como PROMELA.

Modernamente, h linguagens como Erlang, Concurrent Haskell, Scala e Fortress. So linguagens de qualidade industrial (capazes de construir aplicaes reais), mas ao mesmo tempo, que trazem suporte avanado a PC na veia. J observei que o paradigma de programao funcional um ingrediente quase obrigatrio para as melhores linguagens concorrentes. Na minha opinio, na melhor hiptese (para quem no aprecia este paradigma), linguagens concorrentes de sucesso sero pelo menos funcionais-hbridas, ou emprestaro da programao funcional alguns truques essenciais, como objetos imutveis ou estruturas de iterao de alto nvel (como comprehensions). Veja a Edio 56 (Programao Funcional (ou quase) em Java) para mais detalhes, que por ser um artigo recente, no repetirei aqui. Desnecessrio dizer, como apreciador da plataforma Java, que estou de olho em linguagens projetadas para a JVM como Scala ou Fortress. Em especial, Scala boa candidata a ser sucessora ou companheira natural do Java. Mas j vimos um pouquinho de Scala no artigo citado, por isso, aproveito para mostrar agora outra linguagem para a JVM muito interessante: Fortress (da Sun), que teve seu release 1.0 recentemente. No exemplo da Listagem 1, a primeira coisa especial a estrutura de controle for. Sua sintaxe lembra as comprehensions de

Edio 58 Java Magazine

Java59.indb 9

01.07.08 18:17:50

URLs amigveis em aplicaes web

outras linguagens funcionais, executando um bloco de cdigo para todos os valores de i gerados pelo intervalo 1#1000. Mas a maior novidade que este for paralelo: o runtime da linguagem ir executar essas iteraes em vrios threads teoricamente, no mximo 1000 threads, um por iterao. Na prtica, o runtime escolher o nmero de threads conforme o nmero de CPUs/cores disponveis e a quantidade de cdigo executado por iterao. Num sistema quad-core provvel que o runtime utilize quatro threads, cada um executando 250 iteraes. Se voc quiser que o loop execute de forma seqencial, pode escrever: for i <seq(1#1000). Note a mudana de paradigma: alm de ser capaz de paralelizar cdigo automaticamente, a linguagem faz isso por default; a execuo seqencial secundria e precisa ser ativada de forma explcita. Outra caracterstica PC de Fortress, ainda mais notvel, o suporte a STM (memria transacional). O comando atomic, utilizado dentro do loop, executa uma ou mais operaes de forma atmica. Isso lembra o synchronized do Java, mas no preciso utilizar nenhum monitor ou lock, pois o atomic no faz lock nenhum: todos os threads que entrarem neste bloco executam ao mesmo tempo. Mas cada bloco atomic funciona como uma transao com controle de concorrncia otimista; ao final do bloco, acontece um commit, mas somente se no houve interferncias (races) com outros threads. Se esta situao for detectada, a transao falha, sofre rollback, e executa de novo de forma automtica (retry), at conseguir sucesso. Observe que no programa de exemplo, a maior parte do cdigo de cada bloco atomic a execuo de um mtodo isPrimo() (no mostrado). Somente a seqncia de leitura/incremento/atualizao de nPrimos corre o risco de gerar race entre threads. Mas este risco muito pequeno, pois a operao nPrimos += 1, alm de executar somente em algumas iteraes (as que detectam um nmero primo), muito rpida em comparao com a execuo de isPrimo(). Portanto, na prtica, o nmero de conflitos ser pequeno e teremos muito poucos rollbacks e retrys, resultando num excelente desempenho para o loop paralelizado. Num programa minsculo, difcil

avaliar todas as vantagens da STM em comparao com locks; seria preciso examinar um programa mais complexo, com muitas variveis compartilhadas e muitos blocos atmicos. A STM no exige que o programador atribua locks para cada varivel (ou grupo de variveis) que quer proteger. No havendo uma multiplicidade de locks explcitos, desaparecem complicaes como saber qual lock deve ser usado conforme as variveis que sero alteradas; desaparecem bugs como deadlocks, que ocorrem em threads que sincronizam dois ou mais locks em comum numa ordem distinta; no h mistrio para o problema de composio de concorrncia (construir um componente concorrente a partir de outros componentes concorrentes reusveis). Enfim, a grande maioria dos problemas de PC desaparece, ou fica muito mais simples. Infelizmente, Fortress no uma linguagem de uso geral uma linguagem especializada em computao numrica (da seu nome: pretende ser um substituto moderno do Fortran). O leitor certamente reparou no aspecto bonito da listagem. Fortress abandona as limitaes do ASCII, optando por uma linguagem simblica rica e expressiva. Por exemplo, o smbolo o familiar conjunto dos nmeros inteiros da Matemtica, sendo fcil deduzir que 32 um conjunto contendo somente os inteiros representveis em base binria com 32 bits ou seja, nosso familiar int.
Ainda no h editores WYSIWYG de Fortress, mas os fontes so armazenados em ASCII (o que exige sintaxes alternativas - como ZZ32 = 32), sendo possvel usar qualquer editor. A partir desses fontes, usa-se o comando fortify para gerar um documento TeX, e o LaTeX para renderiz-lo para PDF. Tive sucesso em rodar essas coisas no Windows com o Cygwin ( preciso instalar todos os componentes default e mais os pacotes tetex*, emacs e vim). O Fortress tambm oferece suporte ao emacs para auxiliar a digitao, mas sendo preguioso demais para aprender o emacs, prefiro esperar por um plugin WYSIWYG para NetBeans ou Eclipse.

de PC inovadora. Pode ser vista como um laboratrio para tcnicas como paralelizao automtica e STM, que um dia estou certo sero obrigatrias em qualquer linguagem de programao de alto nvel que se preze.

Questionando a Lei de Moore

Um ponto de vista que no vejo praticamente ningum discutindo: e se tudo der errado digamos, se a programao concorrente for realmente to difcil que mesmo uma nova gerao de linguagens e ferramentas s consiga aumentar de forma modesta o paralelismo mdio das aplicaes? Esta hiptese deve ser levada em conta porque, cedo ou tarde, ser verdadeira; a questo no e se, mas e quando. Paralelismo no mgica. Se voc tem um algoritmo qualquer, especificado como um conjunto de N passos, o seu grau mximo de paralelizao N se todos os passos puderem executar em paralelo. Mas na prtica, o grau de paralelismo bem mais restrito, devido s dependncias de dados existentes nos algoritmos. Um exemplo: na frmula de Baskara para resolver equaes do 2. grau, quanto paralelismo possvel mesmo num cenrio ideal, onde o custo de gerenciar threads seja zero (permitindo usar threads separados para cada operao, por menor que seja)? Vamos examinar o algoritmo:

Isto pode ser decomposto em seis passos: Destes passos, , e podem ser exe-

, , ,
cutados em paralelo; depois temos que executar isoladamente, e finalmente, podemos executar tambm e em paralelo. Assim, existem trs etapas seqenciais, que poderiam ser agrupados de duas formas: a) ( | | ) ( ) ( e ) b) ( | ) ( | ) ( e )

Devido sua especialidade, Fortress nunca ser muito popular, fora de reas como computao cientfica, engenharia e supercomputao. Mas uma linguagem

10 Java Magazine Edio 58

Java59.indb 10 01.07.08 18:17:52

Preferi o arranjo b, pois utiliza somente dois threads; o arranjo a no seria vantajoso, pois exigiria um thread a mais para o primeiro grupo, mas isso no reduziria o nmero de etapas seqenciais. Assim, o mximo grau de paralelismo possvel para este algoritmo dois. Mais que isso impossvel devido s dependncias de dados: por exemplo, depende de dados gerados por e , por isso, impossvel executar simultaneamente com ou . Nenhuma nova linguagem, runtime, ou paradigma de computao, poderia paralelizar ainda mais este algoritmo4. O ponto onde quero chegar : mesmo que, daqui a dez ou vinte anos, todos ns estejamos afiados em PC e utilizando ferramentas nativamente concorrentes como linguagens a la Fortress isso no significar uma escalabilidade arbitrria via paralelismo. Aquele seu processador de texto, sistema de faturamento ou portal de e-business, talvez fique trs vezes ou dez vezes mais rpido explorando paralelismo de forma intensa. Mas no ir ficar mil vezes mais rpido; mesmo que voc tenha ferramentas de PC ideais, e mesmo que em 2018 tenhamos servidores com 100.000 ncleos.
O que me preocupa, aqui, a possibilidade de executar uma operao individual cada vez mais rpido. Um nmero maior de ncleos sempre contribuir para a escalabilidade horizontal por , exemplo, o nmero de requests HTTP simultneos que uma aplicao web poder atender mas isso outro problema. E mesmo para esse tipo de escalabilidade, um nmero muito alto de ncleos ser limitado por gargalos como memria, disco, rede e bus. Os servidores com centenas de ncleos que voc j pode comprar hoje, s atingem seu desempenho mximo (para aplicaes corporativas tpicas, ex.: que acessam uma database) se voc investir uma fortuna em storage (arrays de disco de alto desempenho), hardware de rede e memria, para minimizar estes gargalos.

D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/javamagazine/feedback

projectfortress.sun.com/Projects/ Community
Projeto Fortress

www.cygwin.com Cygwin, um ambiente UNIX-like necessrio para rodar o Fortress em ambiente Windows

Isso significa que, assim como atingimos um limite prtico para o clock da CPU (em torno dos 4GHz), tambm atingiremos um limite para a tecnologia multi-core. E tam4 Mesmo a computao quntica no uma panacia, e tipicamente, exige algoritmos novos, mais complexos.

Osvaldo Pinali Doederlein opinali@gmail.com Mestre em Engenharia de Software Orientado a Objetos, membro individual do Java Community Process e trabalha na Visionnaire Informtica como arquiteto e desenvolvedor.

Edio 58 Java Magazine

Java59.indb 11

01.07.08 18:17:56

edio ta

bm para qualquer outra coisa, como velocidade de memrias, barramentos, redes e outros componentes de um computador. Na verdade, a maioria destes componentes j se aproxima destes limites, no quesito velocidade. Por exemplo, as memrias RAM tm aumentado de velocidade num ritmo bem inferior ao exponencial. A Lei de Moore continua funcionando, mas produz mais quantidade do que velocidade: podemos dobrar o tamanho das memrias a cada 18 meses, mas no temos memrias duas vezes mais rpidas (em Gb/s, ou muito mais importante, em latncia) a cada 18 meses. A taxa de 20Gb/s x 32 bits, prometida pela GDDR5 (ainda em projeto), j est prxima dos limites da tecnologia, pois exige clocks acima de 4GHz o mesmo ponto at onde as CPUs chegaram, e pararam. Um dia, os computadores iro parar de ficar mais rpidos. Atingiremos um plat de desempenho que ficar quase inalterado, somente com acrscimos lentos e medocres. O que isso significar para o mundo da informtica? Na minha opinio, ser uma tima notcia. A estabilidade do desempenho dos computadores permitir que o restante do mundo da computao amadurea. A engenharia de software muito criticada pela sua crise permanente, mas difcil ser diferente quando tudo muda o tempo todo, numa velocidade agonizante. Os profissionais no tm tempo para aprender de forma aprofundada tudo que deveriam conhecer; consumidores so forados a um ciclo contnuo e desestabilizante de atualizaes; a integrao entre sistemas uma tarefa de Ssifo, jamais finalizada. Como tecnfilo, acredito e desejo que a inovao tecnolgica seja permanente, mas creio tambm que esta inovao pode ser melhor direcionada. Fazendo um paralelo, observe um campo mais maduro, como a indstria automobilstica. Todo ano temos motores ligeiramente mais eficientes ou potentes, mas s ligeiramente; dcadas se passam antes de cada avano significativo. Existem, sim,

melhorias contnuas na tecnologia, mas estas se concentram em outros aspectos: segurana, design, custo, responsabilidade ambiental, conforto, etc. Ou seja, ningum deve temer que a computao se torne um campo montono e estril, s porque o desempenho ser eventualmente estabilizado. No entanto, mesmo essa tese no nos livra do trabalho de explorar o paralelismo, pois esta situao que projeto um congelamento na escalada do desempenho s acontecer depois que o paralelismo tenha sido explorado ao mximo. Talvez a PC seja o ltimo captulo na histria das tcnicas orientadas ao desempenho de software; mas um captulo inevitvel, sem o qual no saberemos o final da histria.

D seu feedback sobre esta edio! A Java Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista!
D s

Feedback eu
sobre e s

11