Pré-visualização parcial do texto
Baixe Programando Para Processadores Paralelos e outras Manuais, Projetos, Pesquisas em PDF para Informática, somente na Docsity!
Wen-Mei W. Hwu DO) sd, ê David B. Kirk 1) 1) PROGRAMANDO PARA PROCESSADORES PARALELOS Uma Abordagem Prática à Programação de GPU IN t pa N TAN N MATAR MN PROGRAMANDO PARA PROCESSADORES PARALELOS beta Programming Massively Paralio! Processors: A Hands-on Approach. adução autorizada do idioma inglós da edição publicada por Elsevier Inc. Copy 6 2010 9 Davi KUNVIDIA Composto ad Worst € 2011, Elsevier Editora Lida. Todos os direitos reservados e protegidos pela Lei no 9.610, de 19/02/1998. Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida ou transmitida sejam quais forem os meios empregados: eletrônicos, mecânicos, fotográficos. gravação ou quaisquer outros. Conhecimento Rua Sete de Setembro, 111 — 16º andar 20050-006 — Centro — Rio de Janeiro - RJ - Brasã Rua Quintana, 753 — 8º andar 04569-011 — Brooklin - São Paulo - SP Serviço de Atendimento ao Cliente 0800-0265340 sacQelsevier. com br ISBN 978-85-3521-4188-4 Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a comunicação ao nosso Serviço de Atendi- mento ao Ciente, para que possamos esclarecer ou encaminhar a questão. Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas à pessoas ou bens, originados do uso desta publicação. CIP-Brasil. Catalogação-na-fonte Nacional dos Editores de Livros, RJ Kirk, David, Programando para processadores paraletos: uma prática à programação de GPU David B. Kirk e Wen-mes W. Hwu, tradução de Daniei Vieira. = Rio de Janeiro: Elsevier, 2011. Tradução de: Programming massively parallel processors Apêndices ISBN 978-85-352-4188-4 1. Programação paralela (Computação). a Processamento paralelo (Computação). à Aga cota 1 Wa 10-5021 CDD: 004.35 CDU: 00403224 A Caroline, Rose e Leo. A Sabrina, Amanda, Bryan e Carissa. Por suportarem nossa ausência enquanto trabalhávamos no curso e no livro. Prefácio Por que escrevemos este livro? Os sistemas de computação do mercado em massa que combinam CPUs com múl- tiplos núcleos e GPUs com muitos núcleos trouxeram a computação para a escala tera no caso dos laptops e à escala pela para os clusters. Armados com tal poder de computação, estamos no auge do uso da computação para aplicações nas diversas áreas da ciência, tais como engenharia, saúde e negócios. Muitos serão capazes de alcançar grandes avanços em suas disciplinas usando experimentos de computação que são de um nível de escala, controle e observação sem precedentes. Este livro oferece um ingrediente crítico para a vi- são: ensinar a programação paralela a milhões de alunos de graduação e pós-graduação, de modo que as habilidades de pensamento computacional e programação paralela sejam tão difundidas quanto o cálculo. Começamos com um curso que agora é conhecido como ECE498AL. Durante o fe- riado de Natal de 2006, estávamos freneticamente trabalhando nos slides de aulas e tarefas de laboratório. David estava trabalhando no sistema, tentando puxar as primeiras remessas de placas de GPU GeForce 8800 G'TX do Illinois, o que não aconteceria antes das primei- ras semanas após o início do semestre. Também ficou claro que a CUDA não se tornaria pública até algumas semanas após o início do semestre. Tínhamos que trabalhar com os acordos legais, para podermos oferecer o curso aos alunos sob acordo de não divulgação (NDA) durante as primeiras semanas. Também precisamos anunciar para que os alunos se inscrevessem, pois o curso não foi anunciado antes do período de pré-matrícula. Demos nossa primeira aula em 16 de janeiro de 2007. Tudo entrou nos eixos. David viajava semanalmente para Urbana, para dar aulas. Tínhamos 52 alunos, alguns a mais do que nossa capacidade. Tínhamos slides de rascunho para a maioria das primeiras 10 aulas. Um aluno de pós-graduação de Wen-mei, John Stratton, gentilmente foi voluntário como assistente de ensino e preparou o laboratório. Todos os alunos assinaram o NDA, de modo que pudemos prosseguir com as primeiras aulas até que a CUDA se tornou pública. Gravamos as aulas, mas não as liberamos na Web até fevereiro. Tínhamos alunos de física, astronomia, química, engenharia elétrica, engenharia mecânica, além de ciência da com- putação e engenharia da computação. O entusiasmo nas aulas fez tudo isso valer a pena. viii Programando para processadores paralelos ELSEVIER Desde então, lecionamos o curso três vezes em formato de um semestre e duas vezes em formato intensivo de uma semana. O curso ECE498AL tornou-se um curso perma- nente, conhecido como ECE408 na Universidade de Illinois em Urbana-Champaign. Começamos a escrever alguns dos capítulos iniciais deste livro quando ofereciamos o ECEA9BAL, pela segunda vez. Testamos esses capítulos em nossa turma da primavera de 2009 e em nossa turma de verão de 2009. Também compartilhamos esses primeiros capítulos na Web e recebemos um retorno valioso de diversas pessoas. Fomos encorajados pelo retorno que recebemos e decidimos partir para um livro inteiro. Aqui, apresentamos humildemente para vocês a primeira edição. Público-alvo O público-alvo deste livro são alunos de graduação e pós-graduação de todas as disci- plinas de ciência e engenharia, nas quais são necessárias habilidades de pensamento com- putacional e programação paralela para usar o hardware de computação em escala de teraflops para obter grandes avanços. Assumiremos que o leitor tem pelo menos alguma experiência com programação C básica e, portanto, são programadores mais avançados, tanto dentro quanto fora do campo da Ciência da Computação. Visamos, especialmen- te, os cientistas da computação em campos como engenharia mecânica, engenharia civil, engenharia elétrica, bioengenharia, fisica e química, que usam a computação para faci- litar seu campo de pesquisa. Dessa forma, esses cientistas são tanto especialistas em seu domínio quanto programadores avançados. O livro utiliza a técnica de construir sobre as habilidades de programação em C. Para ensinar programação paralela em C usamos C para CUDA!M, um ambiente de programação paralela que é suportado nas GPUs NV DIA e emulado em CPUs menos paralelas. Existem aproximadamente 200 milhões desses processadores nas mãos de consumidores e profissionais, e mais de 40 mil programadores usando CUDA ativamente. As aplicações que você desenvolver como parte da experiência de aprendizado poderão ser executadas por uma comunidade de usuários muito grande. Como usar o livro Gostaríamos de oferecer parte de nossa experiência no ensino do curso ECEA9BAL, usando o material detalhado neste livro. Uma abordagem em três fases No curso ECEA498AL, as aulas e os trabalhos de programação são equilibrados e Fase 1: Uma aula baseada no Capítulo 3 é dedicada ao ensino do modelo básico de memória/tkreading da CUDA, as extensões CUDA à linguagem € e as ferramentas básicas de programação/ depuração. Após a aula, os alunos podem escrever um código simples de multiplicação paralela de matrizes em algumas horas. x Programando para processadores paralelos ELSEVIER O seminário de projetos O principal veículo para a turma inteira contribuir para as ideias do projeto final uns dos outros é o seminário de projetos. Normalmente, dedicamos seis periodos de aula para os seminários de projetos. Os seminários são preparados para o benefício dos alunos. Por exemplo, se um aluno tiver identificado um projeto, o seminário serve como um canal para apresentar o pensamento preliminar, obter opiniões e recrutar colegas. Se um aluno não tiver identificado um projeto, ele ou ela pode simplesmente assistir às apresentações, participar das discussões e se juntar a uma das equipes de projeto. Os alunos não recebem notas durante os seminários, a fim de manter uma atmosfera mais calma e permitir que eles focalizem um diálogo significativo com o(s) instrutor(e/s), assistentes de ensino e o restante da turma. Os horários do seminário são planejados de modo que os instrutores e assistentes de ensino possam dedicar algum tempo para dar opiniões às equipes de projeto e para que os alunos possam fazer perguntas. As apresentações são limitadas a 10 minutos, para que haja tempo para opiniões e perguntas durante o período da aula. Isso limita o tama- nho da turma a cerca de 36 apresentadores, considerando períodos de aula de 90 minu- tos. Toda as apresentações são previamente carregadas em um PC, a fim de controlar o horário estritamente e maximizar o tempo para opiniões. Como nem todos os alunos se apresentam no seminário, conseguimos acomodar até 50 alunos em cada turma tempo extra do seminário disponível conforme a necessidade. com o Os instrutores e assistentes precisam se comprometer em assistir a todas as apre: tações e oferecer opiniões úteis. Os alunos normalmente precisam de mais ajuda para responderem às perguntas a seguir. Primeiro, os projetos são muito grandes ou muito pequenos para a quantidade de tempo disponível? Segundo, existe trabalho suficiente no campo, do qual o projeto possa se beneficiar? Terceiro, os cálculos estão sendo direciona- dos para a execução paralela apropriada ao modelo de programação CUDA? O documento de design Quando os alunos decidem sobre um projeto e formam uma equipe, eles precisam submeter um documento de design para o projeto. Isso os ajuda a refletir nas etapas do projeto antes que embarquem nele. A capacidade de realizar tal planejamento será im- portante para o sucesso de sua carreira futura. O documento de design deverá discutir a base e a motivação para o projeto, objetivos em nível de aplicação e impacto em poten- cial, principais características da aplicação final, uma visão geral do seu design, um plano de implementação, seus objetivos de desempenho, um plano de verificação e teste de aceitação e um cronograma do projeto. Os assistentes de ensino mantêm uma clínica de projeto para as equipes do projeto final, durante a semana anterior ao simpósio em sala de aula. Essa clinica ajuda a garantir que os alunos estão no caminho certo e que identificaram o quanto antes as barreiras em | do processo. As equipes de alunos deverão chegar à clinica com um rascunho inicial das três versões a seguir de sua aplicação: |O melhor código sequencial da CPU em termos de desempenho, com SSE2 e outras otmazações que estabelecem uma forte base serial do código para suas comparações de ganho de velocidade; (2) O melhor código paralelo CUDA em termos de desempenho. Essa versão < a saida principal do projeto; (3) en Prefácio xi E: Uma versão do código sequencial da CPU que é baseada no mesmo algoritmo da versão usando precisão simples. Essa versão é usada pelos alunos para caracterizar a sobrecar- ga do algoritmo paralelo em termos de computações extras envolvidas. As equipes de alunos deverão estar preparadas para discutir as principais ideias usadas em cada versão do código, quaisquer questões de precisão em ponto flutuante, qualquer comparação com resultados anteriores da aplicação e o potencial impacto no grande ganho de velocidade no campo em que o projeto se enquadra. Pela nossa experi- ência, o momento ideal para a clínica é uma semana antes do simpósio em sala de aula. Antes disso, os projetos estão menos maduros e as sessões são menos significativas. Depois disso, os alunos não terão tempo suficiente para revisarem seus projetos de acordo com o resultado da clínica. O relatório de projeto Os alunos deverão submeter um relatório de projeto sobre as principais de de sua equipe. Seis períodos de aula são combinados em um simpósio de um dia intei- ro em sala de aula. Durante o simpósio, os alunos utilizam períodos de apresentação proporcionais ao tamanho das equipes. Durante a apresentação, os alunos destacam as melhores partes de seu relatório de projeto para o benefício da turma inteira. A apresenta- ção representa uma parte significativa das notas dos alunos. Cada aluno deverá responder às perguntas dirigidas a ele/ela individualmente, de modo que diferentes notas podem ser dadas aos indivíduos na mesma equipe. O simpósio é uma oportunidade importante para os alunos aprenderem a produzir uma apresentação concisa, que motive seus colegas a lerem um artigo inteiro. Após sua apresentação, os alunos também entregam um relatório completo em seu projeto final. cobertas Suplementos on-line As tarefas de laboratório, orientações para projeto final e especificações de exemplo de projeto estão disponíveis aos instrutores que utilizam este livro para suas aulas. Embora este livro ofereça o conteúdo intelectual para essas aulas, o material adicional será essen- cial para conseguir os objetivos gerais da educação. Gostaríamos de convidá-lo a tirar proveito do material on-line que acompanha este livro, que está disponível no website da editora, em www.elsevier.com.br/kirk. Finalmente, gostaríamos de saber sua opinião. Gostaríamos de saber se você tem alguma ideia para melhorar este livro e o material suplementar on-line. Naturalmente, jo sobre o que gostou no livro. também queremos saber a sua op David B. Kirk e Wen-mei W. Hwu Agradecimentos Agradecemos especialmente a Ian Buck, o pai da CUDA, e John Nickolls, o arquiteto chefe da Tesla GPU Computing Architecture. Suas equipes criaram uma excelente infra- «estrutura para este curso. Ashutosh Rege e a equipe Dev Tech da NVIDIA contribuiram para os slides originais e o conteúdo utilizado no curso ECE498AL, Bill Bean, Simon Green, Mark Harris, Manju Hedge, Nadeem Mohammad, Brent Oster, Peter Shirley, Eric Young e Cyril Zeller providenciaram comentários de revisão e correções dos ma- nuscritos. Nadeem Mohammad organizou os esforços de revisão da NVIDIA e também ajudou a planejar o Capítulo 11 e o Apêndice B. Os esforços heroicos de Nadcem foram essenciais para a concretização deste livro. “Também agradecemos a Jensen Huang por oferecer muitos recursos financeiros e hu- manos para o desenvolvimento do curso. A equipe de “Tony Tamasi contribuiu bastante para a crítica e revisão dos capítulos do livro. Jensen também gastou tempo para ler os pri- meiros rascunhos dos capítulos e nos deu um retorno valioso. David Luebke facilitou os re- cursos de computação em GPU para o curso. Jonah Alben ofereceu ideias valiosas. Michael Shebanow e Michael Garland nos ofereceram palestras e contribuíram com materiais. John Stone e Sam Stone em Illinois contribuíram com grande parte do material de base para o estudo de caso e capítulos sobre OpenCL. John Stratton e Chris Rodrigues contribuíram com algum material de base para o capítulo sobre pensamento computacio- nal. EJui “Ray” Sung, John Stratton, Xiao-Long Wu, Nady Obeid contribuíram para o material de laboratório e ajudaram a revisar o material do curso, sendo voluntários traba- lhando como assistentes de ensino em relação à sua pesquisa. Laurie Talkington e James Hutchinson ajudaram a determinar as primeiras palestras, que serviram como base para os cinco primeiros capítulos. Mike Showerman ajudou a montar duas gerações de clusters de computação em GPU para o curso. Jeremy Enos trabalhou incansavelmente para ga- rantir que os alunos tenham um cluster de computação em GPU estável e facilitado para trabalhar em suas tarefas de laboratório e projetos. xiv | Programando para processadores paralelos ELSEVIER Agradecemos a Dick Blahut, que nos desafiou a montar o curso no Illinois. Suas lem- branças constantes de que precisávamos escrever o livro nos ajudaram a seguir em frente. Beth Katsinas conseguiu uma reunião entre Dick Blahut e o vice-presidente da NVIDIA Dan Vivoli. Através desse encontro, Blahut foi apresentado a David e o convidou para vir até o Illinois e montar o curso com Wen-mei. “Também agradecemos a Thom Dunning, da Universidade do Illinois, e Sharon Glot- zer, da Universidade do Michigan, codiretores da multiuniversidade Virtual School of Com- putational Science and Engineering, por gentilmente hospedar a versão do curso de verão. Trish Barker, Scott Lathrop, Umesh Thakkar, Tom Scavo, Andrew Schuh e Beth McKown ajudaram a organizar o curso de verão. Robert Brunner, Klaus Schulten, Pratap Vanka, Brad Sutton, John Stone, Keith Thulborn, Michael Garland, Vlad Kindratenko, Naga Govindaraj, Yan Xu, Arron Shinn e Justin Haldar contribuíram para as palestras e dis- cussões de painel na escola de verã Nicolas Pinto testou as primeiras versões dos primeiros capítulos em sua turma no MIT e montou um excelente conjunto de comentários e opiniões de correção. Steve Lu- metta e Sanjay Patel lecionaram versões do curso e nos deram opiniões valiosas. John Owens gentilmente nos permitiu usar alguns de seus slides. Tor Aamodt, Dan Connors, “Tom Conte, Michael Giles, Nacho Navarro e diversos outros instrutores e seus alunos do mundo inteiro nos deram opiniões valiosas. Michael Giles revisaram os capítulos do ras- cunho semifinal em detalhes e identificaram muitos erros de digitação e inconsistências. Agradecemos, especialmente, aos nossos colegas Kurt Akeley, AL Aho, Arvind, Dick Blahut, Randy Bryant, Bob Colwell, Ed Davidson, Mike Flynn, John Hennessy, Pat Han- rahan, Nick Holonyak, Dick Karp, Kurt Keutzer, Dave Liu, Dave Kuck, Yale Pati, David Parterson, Bob Rao, Burton Smith, Jim Smith e Mateo Valero, que gastaram tempo com- partilhando suas ideias conosco no decorrer dos anos. Somos humildemente gratos pela generosidade e entusiasmo de todas as pessoas in- críveis que contribuíram para o curso e para o livro. David B. Kirk e Wen-mei W. Hwu xvi | Programando para processadores paralelos ELSEVIER 3.6 Resumo... 1) 46 47 47 47 3.6.1 Declarações de função. 3.6.2 Chamada ou disparo do kernel 3.6.3 Variáveis predefinidas 3.6.4 API de runtim Capítulo 4 Threads CUDA ..............sireererereserererererererereeereneereras GB 41 42 43 44 45 4.6 47 Organização de threads no CUDA...... Usando blockldx e threadidx... Sincronismo e escalabilidade transparente Atribuição de threads... Escalonamento de threads e tolerância Resumo....... Exercícios ...... Capítulo5 Memórias no CUDA..........ecsereerseneeseneenseneensersereersersas 62 51 5.2 5.3 5.4 5.5 5.6 Importância da eficiência do acesso à memória ...... Tipos de memória do device CUDA ...... Uma estratégia para reduzir o tráfego da mem Memória como fator limitador do paralelismo... Resumo. Exercícios Capítulo 6 Considerações de desempenho......... nresenicenmanonanisaeçsa 6.1 62 63 64 65 6.6 6.7 68 Mais sobre execução de threads... Largura de banda da memória global. Particionamento dinâmico de recursos do SM Pré-busca de dados. Mistura de instruções Detalhamento de threads... Desempenho medido e resumo. Exercícios ... Capítulo7 Considerações de ponto flutuante....................cee 101 74 7.2 73 74 Formato do ponto flutuante .... 7.1.1 Representação normalizada de 7.1.2 Codificação em excesso de E, Números representáveis Padrões de bits especiais e precisão. Precisão aritmética e arredondamento asvir 7.5 Considerações de algoritmo... Capítulo 8 Estudo de caso de aplicaçã avançada. reconstrução IRM 8.1 Fundamentos da aplicaç 8.2 Reconstrução iterativa.. 8.3 Calculando F“d 8.4 Avaliação final 8.5 Exercícios... Capítulo 9 Estudo de caso de aplicação: visualização e análise de moléculas ..........emes REREIPNE NI 140 9.1 Fundamentos da aplicação. 9.2 Uma implementação simples do kernel..... 9.3 Eficiência de execução da instrução. 9.4 Aglutinação de memóri: 9.5 Comparações adicionais de desempenho .. 9.6 Usando múltiplas GPU: 9.7 Exercícios Capítulo 10 Programação paralela e pensamento computacional.............. oe cos isa nana EPE 17, 10.1 Objetivos da programação paralela 10.2 Decomposição do problema . 10.3 Seleção do algoritmo.. 10.4 Pensamento computacional 10.5 Exercícios Capítulo 11 Uma breve introdução à OpenCLTM ........................167 11.1 Fundamentos... 11.2 Modelo de paralelismo de dados 11.3 Arquitetura de device. 11.4 Funções do kernel... 11.5 Gerenciamento de device e chamada do kernel 11.6 Mapa do potencial eletrostático em OpenCL 11.7 Resumo... 11.8 Exercícios..... Introdução | Sumário do Capítulo 1.1 GPUs como computadores paralelos.. 1.2 Arquitetura de uma GPU moderna... 1.3 Por que mais velocidade ou paralelismo' 1.4 Linguagens e modelos de programação paralela 1.5 Objetivos abrangentes. 1.6 Organização do livro .. Referências e leitura adicional... icroprocessadores baseados em uma única unidade central de processamento (CPU), como aqueles na família Intel Pentium e na família AMD* Opteron”, impulsionaram aumentos de desempenho e reduções de custo nas aplicações de com- putador por mais de duas décadas. Esses devices trouxeram giga (bilhões) operações de ponto flutuante por segundo (GFLOPS) para o desktop e centenas de GFLOPS para os ser- vidores em cluster. E o contínuo impulso de melhoria de desempenho tem permitido que o software de aplicação ofereça mais funcionalidade, tenha melhores interfaces com o usuário e gere resultados melhores. Os usuários, por sua vez, pedem ainda mais melhorias, uma vez os usuários, acostumados com essas melhorias, demandem mais capacidades, criando um ciclo positivo para a indústria de computadores. Durante o processo, a maior parte dos desenvolvedores de software contou com os avanços no hardware para aumentar a velocidade de suas aplicações; o mesmo sof- tware simplesmente roda mais rápido à medida que cada nova geração de processa- dores é introduzida. Esse impulso, porém, diminuiu desde 2003 devido a questões de consumo de energia e dissipação de calor, que limitaram o aumento da frequência de clock e o nível de tarefas que podiam ser realizadas em cada período de clock dentro de 2 Programando para processadores paralelos ELSEVIER uma única CPU. Praticamente todos os fabricantes de microprocessador passaram para mo- delos em que várias unidades de processamento, conhecidas como núcleos, são usadas em cada chip para aumentar o poder de processamento. Essa mudança exerceu um impacto tremendo sobre a comunidade de desenvolvimento de software [Sutter 2005] Tradicionalmente, a grande maioria das aplicações de software é escrita como progra- mas sequenciais, conforme descrito por von Neumann [1945] em seu relatório embrionário. A execução desses programas pode ser compreendida por um ser humano percorrendo o código em sequência. Historicamente, os usuários de computador se acostumaram com a expectativa de que esses programas rodam mais rapidamente a cada nova geração de microprocessadores. Essa expectativa não será mais estritamente válida daqui para frente. Um programa sequencial só rodará em um núcleo, que não se tornará muito mais rápido do que os disponíveis atualmente. Sem a melhoria no desempenho, os desenvolvedores de aplicação não poderão mais introduzir novos recursos e capacidades em seu software à me- dida que novos microprocessadores forem introduzidos, reduzindo assim as oportunidades de crescimento da indústria de computadores inteira. Ao invés disso, os softwares que continuarão a gozar da melhoria de desempenho a cada nova geração de microprocessadores serão formados por programas paralelos, em que vários threads de execução cooperam para completar o trabalho mais rapidamente. Esse novo incentivo, dramaticamente escalado para o desenvolvimento de programa pa- ralelo, tem sido conhecido como a revolução da concorrência [Sutter 2005]. A prática da programação paralela de forma alguma é novidade. A comunidade de computação de alto desempenho tem desenvolvido programas paralelos há décadas. No entanto estas só fun- cionavam em computadores de grande escala, muito caros, nos quais somente algumas aplicações de elite podiam justificar o seu uso, limitando, desse modo, a prática da progra- mação paralela a um pequeno número de desenvolvedores de aplicações. Agora que todos os novos microprocessadores são computadores paralelos, o número de aplicações que precisam ser desenvolvidas como programas paralelos aumentou dra- maticamente. Hoje existe uma grande necessidade de que os desenvolvedores de software aprendam programação paralela, que é o foco deste livro. ER GPUs como computadores paratetos Desde 2003, a indústria de semicondutores tem estabelecido duas trajetórias princi- pais para o projeto de microprocessador [Hwu 2008]. A trajetória de múltiplos núcleos (multicore) busca manter a velocidade de execução dos programas sequenciais enquanto se move para múltiplos núcleos. Os múltiplos núcleos começaram como processadores de dois núcleos, sendo que o número de núcleos praticamente dobra a cada nova geração de semicondutor. Um exemplo atual é o recente microprocessador Intel Core i7, que tem quatro núcleos processadores, cada um sendo um processador independente, com emissão de múltiplas instruções, implementando todo o conjunto de instruções x86; o microprocessador admite Ayperthreading com duas threads de hardware e foi projetado para maximizar a velocidade de execução dos programas sequenciais. Por outro lado, a trajetória baseada em muitos núcleos (many-core) foca-se mais na execução de várias aplicações paralelas. Os muitos núcleos começaram como um grande número de núcleos muito menores e, tal como na arquitetura com múltiplos núcleos, os núcleos dobram a cada geração. Um exemplar atual é a unidade de processamento 
