Paralelização automática de laços para arquiteturas multicore

(1)

(2)

FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA DO IMECC DA UNICAMP

Bibliotecária: Maria Fabiana Bezerra Müller – CRB8 / 6162

Vieira, Cristianno Martins

V673p Paralelização automática de laços para arquiteturas multicore/Cristianno Martins Vieira-- Campinas, [S.P. : s.n.], 2010.

Orientador : Sandro Rigo.

Dissertação (mestrado) - Universidade Estadual de Campinas, Instituto de Computação.

1.Processadores multicore. 2.Arquitetura de computador. 3.Politopos. I. Rigo, Sandro. II. Universidade Estadual de Campinas. Instituto de Computação. III. Título.

Título em inglês: Automatic loop parallelization for multicore architectures

Palavras-chave em inglês (Keywords): 1. Multicore processors. 2. Computer architecture. 3. Polytopes.

Titulação: Mestre em Ciência da Computação

Banca examinadora: Prof. Dr. Sandro Rigo (IC - UNICAMP)

Prof. Dr. Guido Costa Souza de Araújo (IC – UNICAMP)

Prof. Dr. Ricardo Ribeiro dos Santos (Faculdade de Computação - UFMS)

Data da defesa: 08/11/2010

Programa de Pós-Graduação: Mestrado em Ciência da Computação

(3)

(4)

Instituto de Computa¸c˜ao Universidade Estadual de Campinas

Paraleliza¸

c˜

ao Autom´

atica de La¸

cos para

Arquiteturas Multicore

Cristianno Martins Vieira

1

Novembro de 2010

Banca Examinadora:

• Prof. Dr. Sandro Rigo (Orientador)

• Prof. Dr. Guido Ara´ujo

Instituto de Computa¸c˜ao (Unicamp)

• Prof. Dr. Ricardo Ribeiro dos Santos

Faculdade de Computa¸c˜ao (UFMS)

• Prof. Dr. Ricardo Pannain (Suplente)

Instituto de Computa¸c˜ao (Unicamp)

• Prof. Dr. Roberto Hexel (Suplente)

Departamento de Inform´atica (UFPR)

1_{Suporte financeiro de: Bolsa Fapesp (processo 2008/52922-0) 2008–2010.}

(5)

Resumo

Embora muitos programas possuam uma forma regular de paralelismo, que pode ser

expressa em termos de la¸cos paralelos, muitos exemplos importantes n˜ao a possuem. Loop

skewing é uma transforma¸cão que remodela o espa¸co de itera¸cão dos la¸cos para que seja

poss´ıvel expressar o paralelismo impl´ıcito atrav´es de la¸cos paralelos. Como consequˆencia

da complexidade em se modificar o espa¸co de itera¸c˜ao dos la¸cos, e de poss´ıveis problemas

causados por transforma¸c˜oes deste tipo – como o poss´ıvel aumento na taxa de miss em

caches –, no geral, elas n˜ao s˜ao largamente utilizadas.

Neste projeto, implementamos a transforma¸c˜ao loop skewing sobre o compilador da

lin-guagem C presente no GCC (GNU Compiler Collection), de forma a permitir a assistˆencia

pelo programador. Utilizamos a ferramenta Graphite como base para a implementa¸c˜ao

da otimiza¸c˜ao, apenas representando-a como uma transforma¸c˜ao afim sobre um objeto

matem´atico multidimensional chamado pol´ıtopo.

Mostramos, atrav´es de um estudo detalhado sobre o modelo matem´atico denominado

modelo polit´opico, que la¸cos com estruturas espec´ıficas – perfeitamente aninhados, com

limites e acesso à memória descritos por fun¸cões afins – poderiam ser representados como

pol´ıtopos, e que transforma¸c˜oes aplicadas a estes seriam espelhadas no c´odigo gerado a

partir desses pol´ıtopos. Dessa forma, qualquer transforma¸c˜ao que possa ser estruturada

como uma transforma¸c˜ao afim sobre um pol´ıtopo, poder´a ser implementada.

Mostramos, ainda, durante a análise de desempenho, que transforma¸cões deste tipo são

vi´aveis e, apesar de algumas limita¸c˜oes impostas pela infraestrutura do GCC, aumentam

relativamente o desempenho das aplica¸c˜oes compiladas com ela – obtivemos um ganho

m´aximo de aproximadamente 115% para o uso de quatro threads em uma das aplica¸c˜oes

executadas. Verificamos o impacto do uso de programas j´a paralelizados manualmente

sobre a plataforma, e obtivemos um ganho m´aximo de 11% nesses casos, mostrando que

ainda aplica¸c˜oes paralelizadas podem conter paralelismo impl´ıcito.

(6)

Abstract

Although many programs present a regular form of parallelism, which can be expressed as parallel loops, many important examples do not. Loop skewing is a transformation that reorganizes the iteration space of loops to make it possible to expose the implicit parallelism through parallel loops. In general, as a consequence of the complexity in modifying the iteration space of loops, and possible problems caused by such changes – such as the possibility of increasing the miss rate in caches –, they are not widely used.

In this work, the loop skewing transformation was implemented on GCC’s C compiler (GNU Compiler Collection), allowing programmer’s assistance. Graphite provides us a basis for implementation of the optimization, just representing it as an affine transforma-tion on a multidimensional mathematical object called polytope.

We show, through a detailed study about the mathematical model called polytope mo-del, that for a very restricted loop structure – perfectly nested, with limits and memory accesses described by affine functions - could be represented as polytopes, and transforma-tions applied to these would be carried by the code generated from these polytope. Thus, any transformation that could be structured as an affine transformation on a polytope, could be added.

We also show, by means of performance analysis, that this type of transformation is feasible and, despite some limitations imposed by the still under development GCC’s in-frastructure for auto-parallelization, fairly increases the performance of some applications compiled with it – we achived a maximum of about 115% using four threads with one of the applications. We also verified the impact of using manually parallelized programs on this platform, and achieved a maximum gain of 11% in these cases, showing that even parallel applications may have implicit parallelism.

(7)

Agradecimentos

Este trabalho se tornou poss´ıvel gra¸cas a muitas pessoas que me ajudaram de diferentes formas. Gostaria de citar todas elas explicitamente, mas sei que dificilmente esta lista estaria incompleta.

Antes de mais nada, eu gostaria de agradecer ao meu orientador Sandro Rigo, que

sempre esteve dispon´ıvel para mim quando eu precisei – n˜ao importava se a raz˜ao fosse

alguma d´uvida t´ecnica, um problema administrativo, ou “apenas” planejando o futuro.

Obrigado, Sandro, por seu apoio em qualquer situa¸c˜ao.

Tamb´em gostaria de agradecer aos membros do Laborat´orio de Sistemas de

Com-puta¸c˜ao da Unicamp: apesar de n˜ao estar presente durante grande parte do

desenvol-vimento deste trabalho, sempre obtive apoio dos colegas dal´ı. Gostaria de agradecer principalmente ao amigo Rodrigo Faveri pelas caronas, conversas, viagens (onde tive a

oportunidade de conhecer não só mais um peda¸co do Brasil, mas sua admirável fam´ılia),

enfim, pela paciˆencia para com um colega t˜ao distante de seu lar.

Entretanto, h´a tamb´em muitas outras pessoas que me ajudaram fora dos colegas da

´

area. Sou muito grato a Robson Peixoto, colega de mestrado, com quem eu tive algumas

discussões frut´ıferas em vários tópicos sobre este projeto. Obrigado, Robson, por sua

colabora¸c˜ao produtiva.

Agrade¸co imensamente aos amigos Marcos Vieira e Rodrigo Tripodi pelas horas dedi-cadas às revisões e aux´ılio a tradu¸cão de textos, sem os quais eu realmente não conseguiria

as duas ou trˆes horas de sono por dia (merecidas) em per´ıodos pr´oximos a deadlines.

Agrade¸co tamb´em aos amigos cuiabanos Daniel Vecchiato e Willian Maja, e ao mineiro

Douglas Leite, principalmente pelos grupos de estudo, que nos fortalecia o conhecimento

pelo compartilhamento do mesmo. Obrigado tamb´em aos demais originais companheiros

do ”Bubbles”, que (bom) cresceu tanto durante esses dois anos: Thiago Lechuga e Maria

A. Souza; não esqueci de vocês – só pensei em guardar o melhor para o final ;). Espero

sinceramente que nossas vidas, ainda que separadas, sincronizem-se em algum momento e voltemos a nos encontrar =D

Em resumo, gostaria de agradecer a todos os meus amigos, novos e antigos. Vocˆes me

forneceram o equil´ıbrio perfeito entre motiva¸c˜ao e energia para trabalhar, ao mesmo tempo

(8)

que a distância necessária disto e uma importante conexão com o mundo além do trabalho.

Agrade¸co, particularmente, `a Isaura Souto que, por vezes, tirou-me do confinamento quase

que à for¸ca, ainda que fosse para “dar uma volta”; suas visitas são muito agradáveis. À

Amanda Nascimento pelos cavaqueios, pelos conselhos, pela sinceridade, enfim, por ser

uma boa amiga. Tamb´em a Victor Seino e Caroline Barros, colegas de pens˜ao e, acima

disso, amigos, que da mesma forma se dispuseram, principalmente no per´ıodo mais cr´ıtico

do projeto: durante a escrita da disserta¸c˜ao. Obrigado tamb´em aos demais colegas da

pens˜ao; ainda que n˜ao citados explicitamente, tenham a certeza que sou muito grato por

seu companheirismo, amizade e carinho.

Agrade¸co, ainda, ao suporte direto `as minhas atividades de pesquisa dado pela Funda¸c˜ao

de Amparo à Pesquisa do Estado de São Paulo, que me permitiu permanecer em dedica¸cão

exclusiva atrav´es de bolsa pelo per´ıodo relativo a este projeto.

Da universidade, gostaria de agradecer primeiramente ao secretariado do Instituto de

Computa¸c˜ao (IC), formado por Fernando Okabe, Fl´avio Luzia, Wilson Bagni, Ademilson

Ramos e Daniel Capeleto: muito obrigado pelo suporte, eficiˆencia e muitas informa¸c˜oes

prestados não só a mim, mas a todos os alunos de gradua¸cão e pós do IC. Acredito que falo

em nome de todos quando digo que nem imagino nossas vidas acadˆemicas sem seu apoio.

Muit´ıssimo obrigado `as pessoas que tive contato tamb´em junto ao SAPPE/UNICAMP,

em especial Dra. C´elia, que se tornou um conforto e ombro amigo no per´ıodo que precisei.

Gostaria de agradecer também a todos os demais funcionários da Unicamp (médicos,

faxi-neiros, seguran¸cas, jardifaxi-neiros, etc.) que se esfor¸cam para manter um ambiente agrad´avel

para n´os, alunos.

Por ´ultimo, mas n˜ao menos importante, obrigado a todos os membros da minha fam´ılia,

principalmente aos meus pais que, de certo, sofreram, assim como eu, por meu tempo

limitado. Obrigado especialmente `a minha m˜ae, que me garantiu a possibilidade de seguir

este caminho. Muito obrigado por seu amor, que tem sido uma fonte infinita de energia para mim.

Agrade¸co a Deus por todos vocˆes.

(9)

“Todas as coisas grandes deste mundo s˜ao feitas por pessoas ingˆenuas

que tˆem uma ideia obviamente imposs´ıvel.”

(10)

Sum´

ario

Resumo v

Abstract vi

Agradecimentos vii

1 Introdu¸c˜ao 1

2 Revis˜ao Bibliogr´afica 4

3 Conceitos B´asicos 11

3.1 Conceitos Alg´ebricos . . . 12

3.1.1 Modelo Polit´opico . . . 14

3.2 Alcan¸cando o Paralelismo . . . 19

3.2.1 An´alise das Dependˆencias . . . 20

3.2.2 Transforma¸c˜oes . . . 24

4 Materiais e M´etodos 29 4.1 GNU Compiler Collection . . . 29

4.2 Graphite . . . 31

4.2.1 Polyhedral Compilation Package . . . 33

4.2.2 GPOLY: GIMPLE representado atrav´es de pol´ıtopos . . . 37

4.3 Autopar . . . 41

4.4 Implementa¸c˜ao . . . 45

5 Experimentos 50

6 Conclus˜oes e Trabalhos Futuros 57

A Tabelas de Resultados 60

(11)

Lista de Tabelas

A.1 Tabela que mostra as medidas de speedup e eficiˆencia para os programas

selecionados no Phoronix Text Suite para a execu¸c˜ao com 4 threads. . . 63

selecionados no Phoronix Text Suite para a execu¸c˜ao com 8 threads. . . 66

selecionados no Phoronix Text Suite para a execu¸c˜ao com 12 threads. . . . 69

(12)

Lista de Figuras

2.1 Classifica¸cão hierárquica das abordagens para paraleliza¸cão de aplica¸cões . 5

3.1 Representa¸c˜ao gr´afica de espa¸co bidimensional . . . 15

3.2 Exemplo de Loop Statement Tree para o algoritmo 3.3 . . . 17

3.3 Padr˜ao de dependˆencias trabalhadas por loop skewing . . . 26

4.1 Representa¸c˜oes intermedi´arias do GCC . . . 30

4.2 Representa¸cões intermediárias do GCC e sua fusão com o Graphite . . . . 31

4.3 Visão geral dos módulos que compõem o Graphite . . . 32

4.4 Representa¸c˜oes em GIMPLE, Pcp e GPOLY . . . 35

4.5 Arquitetura do PCP . . . 36

4.6 Exemplo de detec¸c˜ao de SCoP . . . 38

4.7 Dependˆencias entre os acessos a vetores no algoritmo 4.3(c) . . . 43

5.1 Speedup para as aplica¸c˜oes selecionadas do Phoronix Test Suite . . . 51

5.2 Eficiˆencia para as aplica¸c˜oes selecionadas do Phoronix Test Suite . . . 53

(13)

Lista de Algoritmos

3.1 Estruturas perfeitamente aninhadas de la¸cos . . . 12

3.2 Exemplo de passeio sobre pol´ıtopo da figura 3.1 . . . 15

3.3 N´ucleo da fatora¸c˜ao de Cholesky . . . 17

3.4 Trecho de c´odigo que ilustra dependˆencia de dados . . . 20

3.5 Trecho de c´odigo que ilustra dependˆencia c´ıclica de dados . . . 20

3.6 Exemplo de dependˆencia entre diferentes itera¸c˜oes . . . 22

3.7 Exemplo de dependˆencia entre diferentes itera¸c˜oes . . . 24

3.8 Algoritmo que ilustra dependências de dados em todas as dimensões do la¸co 25 3.9 Algoritmo com diagonal projetada para a dimensão J . . . 26

3.10 Algoritmo ap´os aplica¸c˜ao de loop skewing . . . 27

4.1 Exemplo de c´odigo para constru¸c˜ao de pol´ıtopo . . . 40

4.2 Exemplo de estrutura aninhada de la¸cos com dependˆencia n˜ao muito simples 42 4.3 Exemplos de la¸cos ignorados pelo Autopar . . . 44

4.4 La¸co paralelo reescrito da figura 4.3(c) . . . 44

4.5 Estruturas de la¸co perfeitamente aninhadas geradas a partir de la¸co ani-nhado imperfeito . . . 46

4.6 Exemplo de la¸co perfeitamente aninhado com padr˜ao de dependˆencias com-plexo . . . 46

4.7 La¸co exibido na figura 4.6 ap´os transforma¸c˜oes . . . 47

4.8 Pseudoc´odigo da transforma¸c˜ao loop skewing . . . 49

(14)

Cap´ıtulo 1

Introdu¸

c˜

ao

Uma aplica¸cão em software é a ponte entre o usuário e a plataforma de hardware. Com a

evolu¸cão da tecnologia dos últimos anos, o que vemos é uma quantidade cada vez maior

de dados que precisa ser processada em um per´ıodo cada vez menor de tempo. Isso mo-tiva os engenheiros de hardware a buscar avan¸cos em arquiteturas de microprocessadores

e tecnologia de fabrica¸c˜ao, visando criar plataformas capazes de suprir as necessidades

das novas aplica¸c˜oes. At´e recentemente, principalmente no que se refere a processadores

de prop´osito geral (usados em computadores pessoais, por exemplo), o aumento de

de-sempenho era alcan¸cado atrav´es de sucessivos aumentos na densidade de transistores e

frequˆencia do processador. Isto desencadeou s´erios problemas de projeto, principalmente

relacionados a consumo de energia e dissipa¸c˜ao de calor. Al´em disso, mesmo que o tempo

necessário para um impulso elétrico trafegar num processador seja muito pequeno, ele não

´e igual a zero, o que imp˜oe uma barreira f´ısica como limite para o clock do processador.

Essas limita¸c˜oes obrigaram os projetistas de grandes fabricantes de processadores a buscar

novos modelos de arquitetura de computadores.

Um modelo de computa¸cão já conhecido há bastante tempo e utilizado principalmente

para aplica¸c˜oes cient´ıficas ´e o processamento em paralelo. Para entender como esse modelo

funciona, basta comparar o processador a um c´erebro humano. ´E sabido que o tempo

gasto para um impulso nervoso transitar entre neurˆonios ´e muito maior que o de um

sinal elétrico trafegando em um circuito. Porém, pela existência de milhões de neurônios

trabalhando em conjunto, o modelo do c´erebro ´e mais eficiente, sendo, portanto, superior.

Assim, adaptando-se ao modelo do cérebro, projetistas adicionaram vários “neurônios

eletrônicos” (núcleos de processamento) simples e confiáveis a um mesmo processador.

Esse novo modelo mais especificamente visa combinar elementos m´ultiplos – tais como

sistemas de comunica¸cão, barramentos, caches e unidades lógicas e aritméticas – em um

´

unico chip, objetivando aumentar o paralelismo em n´ıvel de tarefas [6, 48]. Dessa forma, os novos projetos de processadores e sistemas utilizam multiprocessamento para atingir

(15)

2

os requisitos de desempenho, sem comprometer o projeto com problemas relacionados ao

calor dissipado. Esses novos processadores s˜ao denominados processadores multicore e

tornaram-se os principais produtos de empresas como Intel (Core2Duo e Core2Quad) e

AMD (Opteron e Athlon X2) para computa¸c˜ao de prop´osito geral.

O principal problema é que aplica¸cões sequenciais – também conhecidas como

single-threaded – n˜ao conseguem tirar proveito das caracter´ısticas das novas arquiteturas

multi-core ou multiprocessadas. Em outras palavras, o desempenho de uma aplica¸c˜ao desse tipo

n˜ao melhora simplesmente por executarmos o programa em um processador multicore. E

existe uma grande quantidade de aplica¸c˜oes codificadas de forma sequencial que poderiam

aproveitar-se das vantagens dos sistemas multicore. Muitas aplica¸c˜oes multim´ıdia – como

algoritmos de processamento de imagens, por exemplo – s˜ao naturalmente paraleliz´aveis.

Contudo, a paraleliza¸cão de aplica¸cões não é uma tarefa trivial. O principal problema

´e encontrar o paralelismo na aplica¸c˜ao e efetivamente dividir aquela tarefa de forma a

aproveitar ao m´aximo a m´aquina alvo.

Com o objetivo de atingir um ganho razo´avel de desempenho minimizando a carga

sobre o desenvolvedor, pesquisadores tˆem desenvolvido ferramentas que auxiliam a

para-leliza¸c˜ao [10]. Entretanto, mais interessante seria se linguagens como C/C++, muito

comuns no desenvolvimento de aplica¸c˜oes de prop´osito geral e para sistemas

dedica-dos, oferecessem na pr´opria linguagem mecanismos para ajudar no particionamento da

aplica¸cão. Mais que isso, o compilador, que já possui uma sofisticada tecnologia de análise

e otimiza¸cão de código, poderia agregar a paraleliza¸cão como uma de suas otimiza¸cões,

desobrigando ao desenvolvedor a interven¸c˜ao no processo de paraleliza¸c˜ao.

No entanto, o paralelismo introduz muito mais complexidade ao processo de

oti-miza¸cão. Primeiro, porque é necessário escolher trechos de código que tragam ganhos reais

`

a aplica¸cão. Na maioria dos casos, dada otimiza¸cão restringe seu dom´ınio de aplica¸cão.

La¸cos, ou fun¸cões recursivas, que tendem a ser partes de código executadas inúmeras

vezes, são fortes candidatos à paraleliza¸cão. Ainda assim, por influência de limitantes,

como dependˆencias nos acessos aos dados, nem todos estes trechos de c´odigo podem ser

aproveitados.

Além disso, encontrar paralelismo através da análise estática do código nem sempre

nos dá uma visão concreta dos acessos aos dados realizados durante a execu¸cão de uma

aplica¸c˜ao. O uso de apontadores ou acessos irregulares a vetores (como o uso de vetores

para indexar vetores) deturpam os resultados das análises de dependências, e o código,

muitas vezes independente, n˜ao pode ser paralelizado; al´em disso, na maioria dos casos o

paralelismo não está explicitado na aplica¸cão. Nestes casos, é necessária uma boa análise

de dependˆencias por parte do compilador, ou um bom processo de paraleliza¸c˜ao deveria

ser capaz de detectar o paralelismo impl´ıcito.

(16)

3

skewing, uma transforma¸c˜ao que pode reorganizar as itera¸c˜oes de la¸cos perfeitamente

ani-nhados de forma a mover as dependˆencias de dados para os la¸cos mais externos. As

prin-cipais vantagens desta abordagem s˜ao o tratamento do paralelismo, mesmo que impl´ıcito

na aplica¸cão, e a garantia da independência das itera¸cões nos la¸cos internos, deixando-os

completamente paraleliz´aveis.

Neste projeto, uma abordagem baseada no modelo matem´atico denomidado modelo

politópico foi adotada para a implementa¸cão de transforma¸cões sobre o código

inter-medi´ario do GCC. Primeiramente, um estudo aprofundado sobre as aplica¸c˜oes do modelo

polit´opico foi realizado. Fundamentalmente, este modelo permite a representa¸c˜ao de um

conjunto de restri¸c˜oes por objetos matem´aticos multidimensionais chamados poliedros.

Certas tranforma¸cões (como rota¸cão e transla¸cão) podem ser aplicadas a esses objetos,

desde que elas possam ser representadas por um conjunto de opera¸c˜oes descritas por

fun¸cões afins. Um estudo sobre representa¸cão de hierarquia e dependências presentes em

estruturas aninhadas de la¸cos foi realizado, a fim de representar trechos de c´odigo em

al-guma linguagem de programa¸cão através de pol´ıtopos, garantindo que exista a tradu¸cão

inversa (de pol´ıtopo para a linguagem de programa¸c˜ao). Ao representar transforma¸c˜oes

complexas (como loop skewing, por exemplo) por um conjunto de transforma¸c˜oes sobre

pol´ıtopos, esse tipo de transforma¸c˜ao pode ser facilmente aplicado aos la¸cos represent´aveis

pelo modelo. Essa disserta¸cão, então, foca na aplica¸cão de transforma¸cões que expõem

paralelismo sobre la¸cos aninhados utilizando o modelo polit´opico como base.

O restante do texto est´a organizado como se segue: o pr´oximo cap´ıtulo descreve

tra-balhos relacionados ao tema deste projeto. O cap´ıtulo seguinte fornece alguns conceitos

básicos; no cap´ıtulo 4, são apresentados os materiais e a solu¸cão implementada sobre o

GCC (GNU Compiler Collection) para a paraleliza¸c˜ao de aplica¸c˜oes desenvolvida neste

trabalho; os resultados das execu¸c˜oes de programas reais compilados com a nova solu¸c˜ao

e sua análise são apresentados no cap´ıtulo 5 para a valida¸cão da solu¸cão; o cap´ıtulo

se-guinte realiza as considera¸c˜oes finais e exp˜oe trabalhos futuros sobre o tema; e, por fim,

(17)

Cap´ıtulo 2

Revis˜

ao Bibliogr´

afica

Devido a limitantes f´ısicos para o tamanho e temperatura dos circuitos, avan¸cos recentes

em microarquitetura têm na replica¸cão de núcleos de processamento uma esperan¸ca para

ganho de desempenho. Atualmente, mesmo sistemas embarcados j´a possuem

processado-res formados por mais de um n´ucleo [32].

Al´em desses processadores aumentarem o paralelismo permitindo que uma maior

quan-tidade de dados seja processada por vez, a proximidade dos n´ucleos de processamento

também minimiza o tempo de comunica¸cão entre eles. Este fator é uma importante

caracter´ıstica das novas arquiteturas: enquanto v´arias aplica¸c˜oes distintas podem ser

exe-cutadas nos vários núcleos presentes no processador, caso uma aplica¸cão paralela seja

executada, ela também deve tirar proveito dos vários núcleos. Para tal, quando alguma

sincroniza¸cão se fizer necessária, haverá a comunica¸cão entre os núcleos, que não ocorre

numa versão serial da mesma aplica¸cão. A comunica¸cão, neste caso, representa apenas

overhead e, portanto, ´e desej´avel gastar o m´ınimo de tempo para que ela ocorra.

Mas, ao contr´ario do que acontecia com o aumento do desempenho do sistema ao

aumentar a frequˆencia do processador, por exemplo, a mudan¸ca de um processador de

núcleo simples para um com vários núcleos não é o bastante para diminuir o seu tempo de

resposta. Se, por um lado, essas novas arquiteturas aumentam a taxa de throughput1 _[40],

permitindo o processamento de várias tarefas simultaneamente, para aplica¸cões que não

fazem uso intensivo de threads, ou sistemas que não são multitarefa, não haverá qualquer

diferen¸ca no tempo de execu¸c˜ao.

Para que haja um aproveitamento real das aplica¸cões de propósito geral, há duas

abordagens poss´ıveis: o programador reformula o c´odigo do programa para que ele usufrua

os múltiplos núcleos de processamento, seja através de paralelismo de threads, processos,

tarefas, etc., usando bibliotecas que exigem sincroniza¸c˜ao e divis˜ao de tarefas expl´ıcita; ou

o pr´oprio hardware, ou uma interface com o mesmo (como o compilador, por exemplo),

1_{Taxa que relaciona o n´}_{umero de tarefas que entram com as tarefas que saem do sistema.}

(18)

5

automaticamente reconheceria partes potencialmente paralelas do c´odigo, selecionando-as

para execu¸cão concorrente. Uma classifica¸cão hierárquica para as abordagens discutidas

aqui pode ser vista na figura 2.1. A abordagem adotada neste projeto seria denominada

solu¸cão automática por software assistida pelo programador seguindo esta classifica¸cão.

Paralelização

Manual + custosa

Automática

Solução por HW Combinada a SW (API)

Reprojeto de HW ñ flexível ñ escalável Solução por SW Semiautomatizada induzida Modelagem/Programação retreino de programadores Modificações em Compiladores Stand-alone auto-suficiente Assistida autoparallel.mmap - 5/9/2010 - Mindjet

Figura 2.1: Classifica¸cão hierárquica das abordagens para paraleliza¸cão de aplica¸cões. Na

figura, os acrˆonimos HW e SW fazem referˆencia a hardware e software, respectivamente.

´

E importante frisar que a distin¸c˜ao entre paraleliza¸c˜ao semiautomatizada e assistida se

d´a pelo grau de interferˆencia do programador: na primeira delas, o programador indica

os trechos de c´odigo a serem paralelizados, enquanto na segunda, o programador recebe

informa¸cões sobre trechos onde a autoparaleliza¸cão não pôde ser aplicada com sucesso, e

este poderá modificar o código para permitir sua aplica¸cão.

A primeira alternativa claramente ´e a mais custosa, uma vez que anos de software

legado deveriam ser reprojetados para fazer uso dos recursos de hardware atuais. Neste

caso, a paraleliza¸cão automática não requereria tanto esfor¸co para realizar a mesma

ta-refa. Nesta vertente, alguns estudos sugerem mudan¸cas no hardware, provendo suporte

a opera¸c˜oes que permitam extrair o m´aximo do potencial dos processadores. Em [8], por

exemplo, um modelo de arquitetura multicore heterogˆenea em conjunto com uma API2

2_{Do inglˆ}_{es, Application Programming Interface ´}_{e uma interface que um programa implementa para}

(19)

6

espec´ıfica são discutidos como uma poss´ıvel solu¸cão para problemas de sincroniza¸cão

en-tre as threads de um programa. O processador seria formado por um n´ucleo principal,

onde a por¸cão serial do programa executaria, e vários núcleos menores especializados em

processamento num´erico e sem mecanismos de preemp¸c˜ao, que seriam alocados a tarefas

paralelas.

Também, em [46] é apresentada a técnica conhecida como Thread-Level Data

Specula-tion3 _{(TLDS), que representa o uso de especula¸c˜}_{ao sobre dados na mem´}_{oria para permitir}

a sobreposi¸cão da execu¸cão de trechos interdependentes de código. Sua unidade m´ınima

de execu¸cão é a thread, e, caso algum acesso à memória viole alguma das regras básicas

do modelo, seus cálculos são descartados e a execu¸cão daquela thread é reiniciada. Neste

artigo, pequenas modifica¸cões no hardware (como uma extensão do protocolo de coerência

de cache para permitir a deteçcão de viola¸cão de dependências entre os processadores)

s˜ao sugeridas para tornar a t´ecnica mais agressiva. Ainda, em [47] o mesmo autor discute

o desempenho da implementa¸c˜ao de TLDS e sugere uma implementa¸c˜ao de algoritmo em

hardware para sincroniza¸c˜ao dinˆamica entre as threads.

Por outro lado, [51] sugere uma reformula¸c˜ao da arquitetura para processadores

mul-ticore, apresentando o processador Voltron como proposta, que adiciona `a arquitetura

convencional duas caracter´ısticas principais: uma rede de intercomunica¸c˜ao entre os

ban-cos de registradores dos n´ucleos, que aparentemente habilitaria sincroniza¸c˜ao entre os

núcleos através de uma comunica¸cão com baixa latência; e suporte a dois modos de

execu¸c˜ao, nos quais os n´ucleos poderiam ter o comportamento de um multicluster VLIW

(modo acoplado), explorando basicamente ILP (Instruction-Level Parallelism), ou

explo-rar paralelismo de gr˜aos mais grossos (modo desacoplado), do tipo TLP (Thread-Level

Parallelism) ou LLP (Loop-Level Parallelism).

Nenhuma dessas mudan¸cas, entretanto, ´e trivial, exigindo um reprojeto dos

proces-sadores para cada nova técnica. Desse modo, além de não escalável, a solu¸cão dada por

hardware é inflex´ıvel[17]. A paraleliza¸cão por software, então, claramente se torna mais

vi´avel.

Entretanto, apesar de haver uma longa história envolvendo paraleliza¸cão de aplica¸cões

cient´ıficas, existem alguns problemas ainda intrat´aveis – decorrentes de dependˆencias

com-plexas, por exemplo – al´em das diferen¸cas aparentes na estrutura de aplica¸c˜oes cient´ıficas

e aquelas de propósito geral, o que excluiria um grande número de técnicas geralmente

aplicadas às primeiras, mas não tão próximas em contexto das últimas. Geralmente,

então, opta-se por aplica¸cão de uma paraleliza¸cão semiautomatizada (ou induzida), na

qual indica-se a um preprocessador onde o paralelismo pode ser explorado, e como se

3_{TLDS trata-se de uma varia¸}_c˜_{ao de Thread-Level Speculation (TLS), onde os valores dos dados}

pre-sentes na memória podem ser previstos. Em TLS, é permitida a execu¸cão paralela de threads cujos códigos são potencialmente interdependentes, mas os resultados de sua execu¸cão é apenas considerado caso nenhuma dependência tenha sido violada.

(20)

7

comportam as dependências naquele código, e este geraria automaticamente o código

pa-ralelo para a aplica¸cão; outra alternativa é abordar a paraleliza¸cão de casos espec´ıficos,

onde pode-se determinar a existência de dependências (como impor a restri¸cão de

para-lelizar c´odigos com vetores, mas n˜ao com listas encadeadas, por exemplo).

Para auxiliar na paraleliza¸c˜ao semiautom´atica, existem algumas API que

implemen-tam o paralelismo e podem ser invocadas para iniciar e finalizar uma regi˜ao paralela

de c´odigo (onde as unidades processantes deveriam ser replicadas). Em [6], por

exem-plo, ´e apresentado o Multicore Framework, uma API para programa¸c˜ao de processadores

multicore heterogêneos. Esta API provê uma visão abstrata do hardware com rela¸cão à

computa¸c˜ao de conjuntos de dados multidimensionais. Em [2] ´e apresentada uma

biblio-teca de primitivas paralelas de c´odigo aberto chamada SWARM (Software and Algorithms

for Running on Multicore). Um conjunto de algoritmos, incluindo ordena¸c˜ao, sele¸c˜ao e

m´axima parsimˆonia, foi implementado utilizando esta biblioteca para avaliar sua facilidade

de uso e desempenho (apesar de sua implementa¸c˜ao ainda n˜ao encontrar-se totalmente

otimizada). ´

E discutido em [25] o Multicore Communication API (MCAPI), a especifica¸c˜ao de um

framework para constru¸c˜ao de algoritmos paralelos para processadores multicore baseada

em passagem de mensagens. O objetivo ao desenvolver essa especifica¸c˜ao era torn´

a-la um padr˜ao para arquiteturas multicore heterogˆeneas, uma vez que pThreads[43] foi

projetado para ambientes multiprocessados homogˆeneos – e a maioria das implementa¸c˜oes

OpenMP[11] s˜ao baseadas em pThreads. De maneira semelhante, o uso de frameworks

que implementam o padr˜ao MPI (Message Passing Interface)[45] n˜ao foram projetados

para essas arquiteturas, e poder˜ao n˜ao usufruir completamente de seus recursos.

Em alguns casos, mudan¸cas no pr´oprio modelo de programa¸c˜ao foram sugeridas, como

em [4], que oferece um sistema baseado em C para programa¸c˜ao paralela multithreaded.

Este sistema permite a cria¸c˜ao de threads a partir de um conjunto de comandos, e escalona

tarefas entre elas baseado em work-stealing.

Existem, ainda, ferramentas que auxiliam na escrita do c´odigo para ambas as

aborda-gens de paralelismo (autom´atica e manual): em [27] ´e apresentado o iPat/OMP, uma

ferra-menta para assistência interativa à paraleliza¸cão que escolhe a correta diretiva OpenMP

para la¸cos a partir da assistˆencia do programador, enquanto em [22] ´e realizada uma

análise entre diferentes blocos básicos, e código alvo apropriado para a abordagem de

passagem de mensagens ´e gerado. O principal objetivo de tais ferramentas ´e tornar o

processo de paraleliza¸cão o mais próximo poss´ıvel da automatiza¸cão. Em geral, ambas

as abordagens s˜ao melhor aplicadas a casos com caracter´ısticas espec´ıficas. Algumas

su-gestões a mudan¸cas nos padrões dessas abordagens, tornando a automatiza¸cão de seu

uso mais genérica, como em [21], que propõe algumas técnicas de otimiza¸cão para

(21)

8

ser encontradas na literatura.

Em comum a todas as abordagens mencionadas, a paraleliza¸c˜ao autom´atica

concentra-se em minerar partes de c´odigo que apresentam potencial para o paralelismo. Fun¸c˜oes

recursivas, por exemplo, geralmente apresentam algoritmos com estrat´egia do tipo

“di-vidir e conquistar”. Caso não existam dependências, códigos baseados nesse tipo de

estrat´egia podem ser facilmente paralelizados [23]. Na maioria dos casos, no entanto,

compiladores paralelizantes focam em la¸cos, por potencialmente executarem por longos

per´ıodos de tempo, e possu´ırem um padr˜ao de acesso aos dados entre suas itera¸c˜oes.

Al-gumas aplica¸c˜oes, tais como jogos, som, v´ıdeo e aplica¸c˜oes cient´ıficas usam intensamente

opera¸c˜oes sobre conjuntos de dados em la¸cos, por exemplo.

Devido à incerteza quanto à independência dos dados na autoparaleliza¸cão, é bastante

comum o uso de heur´ısticas, que não garantem a solu¸cão ótima, mas produzem

rapida-mente um bom código paralelo na maioria dos casos. TLS, já citada anteriormente, é um

bom exemplo deste tipo de heur´ıstica. Em especial, ´e poss´ıvel ver em [39] o uso de TLS

para permitir a la¸cos aninhados o usufruto do potencial de processadores multicore. A

implementa¸cão apresentada neste artigo não exigia modifica¸cões no hardware atual, mas

obteve cerca de 15% de ganho, na m´edia, no tempo de execu¸c˜ao dos programas testados.

Outro uso de especula¸cão na tentativa de driblar o problema das dependências é

discutido em [35], onde, para la¸cos com dependências, é escolhido o número de itera¸cões

a serem executadas em paralelo, considerando a probabilidade de ocorrer a viola¸c˜ao de

alguma dependência naquele conjunto de itera¸cões. Neste caso, os resultados também

mostraram ganho de cerca de 12% em m´edia.

Outro uso de especula¸c˜ao para maximizar o uso de multicore pode ser visto em [52],

onde algumas transforma¸cões para la¸cos são apresentadas para diminuir a influência das

dependências sobre o desempenho da aplica¸cão de TLS. São aplicadas transforma¸cões,

tais quais fiss˜ao especulativa de la¸cos e isolamento de dependˆencias pouco frequentes,

mas é importante notar que a aplica¸cão de transforma¸cões que isolam as dependências

(e, portanto, exp˜oem paralelismo) ajudam a aumentar o desempenho de t´ecnicas para

autoparaleliza¸c˜ao.

Uma aplica¸cão mais interessante de especula¸cão é encontrada em [15], onde é discutida

uma solu¸cão baseada em alguns princ´ıpios do modelo politópico para a paraleliza¸cão de

estruturas espec´ıficas de la¸cos: la¸cos do tipo for aninhados em um la¸co do tipo while que

itera sobre uma condi¸c˜ao convergente (estrutura presente em grande parte de aplica¸c˜oes

numéricas). Neste caso, o próprio número de itera¸cões do la¸co externo deve ser

especu-lado. No entanto, al´em de bastante espec´ıfico, o artigo deixa claro que nenhum teste foi

executado para verificar a solu¸c˜ao – trata-se apenas de um conceito – e n˜ao foi encontrado

(22)

9

Outra heur´ıstica adotada atualmente tem sido a especula¸c˜ao de traces de execu¸c˜ao4_.

Em trabalhos como [48], traces s˜ao somente utilizados para auxiliar na visualiza¸c˜ao da

intera¸cão entre múltiplas threads, enquanto em [7] há a implementa¸cão de um modelo de

execu¸cão paralelo baseado em traces. Na discussão sobre os resultados, a aplica¸cão da

t´ecnica apresentou resultados muito parecidos com a TLDS.

Todavia, em determinados contextos, ´e poss´ıvel paralelizar automaticamente o c´odigo

por aplica¸cão de procedimentos algor´ıtmicos, ao invés de usar heur´ısticas; a técnica

deno-minada modelo polit´opico, por exemplo, que pode ser aplicada para otimiza¸c˜oes de la¸cos

com acesso à memória, limitantes e incremento descritos por fun¸cões afins. Em [24] e [34]

´e aplicada a transforma¸c˜ao chamada tiling sobre la¸cos perfeitamente aninhados5. Em [5],

ainda, temos a cria¸c˜ao de um preprocessador que recebe um c´odigo em C e devolve outro

c´odigo tamb´em em C com tiling aplicada a todos os la¸cos que sejam poss´ıveis.

Em especial, em [37] s˜ao relatados os resultados dos testes realizados sobre o

com-pilador autoparalelizador OSCAR, avaliando seu desempenho sobre dois processadores

de quatro n´ucleos (o FR1000, com n´ucleos VLIW6_{, desenvolvido pela Fujitsu Ltda.; e o}

RP1, com n´ucleos SH4A, desenvolvido num cons´orcio entre Renesas Technology Corp.,

Hitachi Ltda. e Waseda University). Ao contr´ario do trabalho desenvolvido neste projeto,

o OSCAR aproveita-se de informa¸c˜oes espec´ıficas da arquitetura para otimizar o c´odigo,

o que garante melhores resultados, mas ao custo de exigir uma sele¸c˜ao – e, talvez,

reim-plementa¸cão – de otimiza¸cões única para cada nova arquitetura cujo suporte venha a ser

adicionado.

Ainda outro fator est´a relacionado com a qualidade do c´odigo gerado pelo compilador:

sendo que a maioria destas transforma¸cões é implementada como otimiza¸cões sobre o

código fonte, é importante notar que, a depender da aplica¸cão, a ordem de otimiza¸cões

de la¸cos é ótima [49]. Compiladores mais simples apenas impõem determinada ordem

na aplica¸cão das otimiza¸cões, enquanto outros utilizam a técnica conhecida como

gerar-e-testar, onde todos os arranjos sobre otimiza¸c˜oes s˜ao testados; o primeiro claramente ignora

um ganho em potencial no desempenho das aplica¸c˜oes compiladas, enquanto o segundo

perde muito tempo na gera¸cão do código. Em [9], utilizam-se técnicas de aprendizado de

máquina para constru¸cão de um compilador que escolha a melhor ordem para a aplica¸cão

de otimiza¸c˜oes.

Demais disto, v´arios estudos sobre como melhor aproveitar-se do potencial das

arqui-4_{Originalmente desenvolvido para aumentar os blocos cont´ıguos de instru¸}_c˜_{oes para m´}_{aquinas VLIW}

(Very Long Instruction Word ), um trace trata-se de um poss´ıvel caminho tomado ao longo de um con-junto de branches no código. No processo de otimiza¸cão, as decisões mais comumente tomadas sobre branches são assumidas sempre tomadas em uma cópia do código, que possui uma maior oportunidade de otimiza¸cão (uma vez que os branches não se fazem necessários aqui).

5_{Um conjunto de la¸}_{cos ´}_{e dito estar perfeitamente aninhado se, para cada la¸}_{co, ou ele possui exatamente}

um la¸co em seu corpo, ou ele ´e o la¸co mais interno e possui instru¸c˜oes diferentes de um la¸co no seu interior.

(23)

10

teturas multicore tˆem sido realizados. Uma vis˜ao geral de quanto se tem desenvolvido

nesta ´area pode ser obtida em [30]. Nesta mesma pesquisa, o autor chama a aten¸c˜ao

para o fato que as linguagens de programa¸c˜ao mais utilizadas em aplica¸c˜oes comerciais

(C, C++, Java, etc.) foram escritas com base em paradigmas seriais e a paraleliza¸c˜ao

automatizada a partir das mesmas n˜ao ´e uma tarefa trivial.

Em se tratando especificamente de transforma¸c˜oes sobre la¸cos aninhados, muitas

abor-dagens tˆem sido implementadas e introduzidas a compiladores. A grande maioria delas

simplesmente reestrutura o c´odigo-fonte, devolvendo um c´odigo na mesma linguagem com

a transforma¸c˜ao aplicada aos la¸cos. ParaScope[16] e Polaris[3], por exemplo, s˜ao

para-lelizadores fonte-a-fonte para Fortran baseados em dependˆencias. Entretanto, s˜ao

ferra-mentas fundamentalmente acadˆemicas e, portanto, sem muito contato com programas

reais.

O PIPS [26] ´e um dos mais completos compiladores com reestrutura¸c˜ao de la¸cos,

imple-mentando análise politópica e transforma¸cões, além de análise interprocedural. Ele utiliza

uma árvore sintática estendida com anota¸cões para representar pol´ıtopos, dificultando um

pouco a implementa¸cão de transforma¸cões. O compilador MARS[38] unifica as idéias de

transforma¸cões de la¸cos baseadas em dependências com otimiza¸cões de armazenamento

de dados. No entanto, sua representa¸cão intermediária não é capaz de capturar todas as

informa¸cões de la¸cos; somente dom´ınios e fun¸cões de acesso são representáveis, não sendo poss´ıvel o armazenamento do escalonamento. O Graphite[41], por sua vez, objetiva ser

uma ferramenta modular de reestrutura¸cão de código em representa¸cão intermediária, de

uso geral. Por ter sido constru´ıda inicialmente sobre uma ferramenta de produ¸c˜ao (GCC),

é poss´ıvel notar que pretende-se aplicá-lo a programas reais, e não apenas mantê-lo como

ferramental acadˆemico.

Este projeto utilizou o Graphite como base para a implementa¸c˜ao de transforma¸c˜oes

afins sobre la¸cos a fim de tornar suas itera¸c˜oes independentes. Para la¸cos nos quais n˜ao

foi poss´ıvel aplicar a t´ecnica, mensagens a partir do otimizador podem ser habilitadas

para auxiliar o programador a descobrir quais la¸cos estavam sendo reestruturados. Al´em

disso, uma an´alise do uso da ferramenta em aplica¸c˜oes reais mostrou que o desempenho

(24)

Cap´ıtulo 3

Conceitos B´

asicos

Programas passam a maior parte de seu tempo de execu¸c˜ao efetuando a mesma opera¸c˜ao

sobre diferentes conjuntos de dados. Logo, as estruturas que realizam o controle desta repeti¸cão são pass´ıveis de serem paralelizadas. La¸cos e fun¸cões recursivas são as principais razões de repeti¸cão de código; essas estruturas geram, durante suas execu¸cões, múltiplas

instˆancias das instru¸c˜oes em seus corpos.

Este trabalho concentra-se nas estruturas de la¸cos, representando-as atrav´es de

obje-tos matem´aticos, conhecidos por pol´ıtopos1_{. Ap´}_{os a aplica¸c˜}_{ao de um conjunto de}

trans-forma¸c˜oes sobre esses pol´ıtopos, outra estrutura de la¸cos ´e gerada, otimizada para algum

critério (código mais compacto, menor consumo de memória, ou exposi¸cão de

parale-lismo, por exemplo). Em especial, esta técnica é somente aplicável a estruturas de la¸cos

perfeitamente aninhadas.

Defini¸c˜ao 1 (Aninhamento perfeito). Um conjunto de la¸cos ´e dito estar

perfeita-mente aninhado se, para cada la¸co, ou ele possui exataperfeita-mente um la¸co em seu corpo, ou ele ´e o la¸co mais interno e possui instru¸c˜oes diferentes de la¸cos no seu interior.

No algoritmo 3.1(a) ´e poss´ıvel visualizar um exemplo de la¸co aninhado. Esta defini¸c˜ao,

no entanto, pode ser relaxada, como foi implementada neste projeto, para que estruturas

de la¸cos como mostrada na figura 3.1(b) tamb´em sejam consideradas perfeitamente

ani-nhadas. Para isso, basta considerar o la¸co mais interno na figura (cuja vari´avel de indu¸c˜ao

´e k) como um bloco de instru¸c˜oes pertencente ao corpo do la¸co um n´ıvel acima. Dessa

forma, o la¸co de ´ındice j passa a ser o la¸co mais interno, e o aninhamento ´e perfeito.

Neste cap´ıtulo, serão discutidos conceitos básicos de álgebra e paralelismo para auxiliar

no entendimento do que foi desenvolvido neste trabalho.

1_{Ou politopo.}

(25)

3.1. Conceitos Alg´ebricos 12

Algoritmo 3.1: Estruturas perfeitamente aninhadas de la¸cos. O exemplo em (a)

segue a defini¸c˜ao 1, onde instru¸c˜oes diferentes de la¸cos somente aparecem no interior

o la¸co mais interno. Em (b), apenas os dois primeiros la¸cos (cujas vari´aveis de

indu¸c˜ao s˜ao i e j) formam uma estrutura perfeitamente aninhada, e o terceiro la¸co

pode ser visto como uma senten¸ca pertencente ao corpo do segundo la¸co. (a) for i ← 1 to 10 do for j ← i to 10 do for k ← i to 10 do S: a ← a + b ∗ c T: b ← b ∗ b end end end (b) for i ← 1 to 10 do for j ← i to 10 do T: b ← b ∗ b for k ← i to 10 do S: a ← a + b ∗ c end end end

3.1 Conceitos Alg´

ebricos

Por restri¸cões presentes na representa¸cão do modelo matemático a ser utilizado neste

pro-jeto, ´e exigido que os la¸cos cumpram alguns requisitos [19, 31]; esses la¸cos s˜ao conhecidos

como La¸cos de Controle Afim (Affine Control Loops, ACL).

Defini¸cão 2 (Fun¸cão linear). Uma fun¸cão d0-dimensional f com d argumentos v1, . . . , vd

´e linear se ela pode ser expressa da seguinte forma:

linear f (v) = Mfv, onde v =    v1 .. . vd   e Mf ∈ R

d0×d _´_{e uma matriz com d}0 _{linhas e d colunas.}

No contexto do conjunto de ´ındices, s´o se faz interessante tratar com matrizes inteiras,

ou seja, Mf ∈ Zd

0_×d

.

Defini¸cão 3 (Fun¸cão afim). Uma fun¸cão d0-dimensional f com d argumentos v1, . . . , vd

´e af im se ela pode ser expressa da seguinte forma:

af im f (v) = Mfv + f0, onde v =    v1 .. . vd   , Mf ∈ R

d0×d _´_{e uma matriz com d}0 _{linhas e d colunas, e f}

0 ∈ R. Ou

(26)

Da mesma forma, para o problema da representa¸c˜ao do espa¸co de ´ındices do la¸co,

Mf ∈ Zd

0_×d

e f0 ∈ Z.

´

E importante notar que, em ambas as defini¸c˜oes, ´e somente permitido a Mf e f0

possu´ırem valores inteiros, n˜ao podendo ser vari´aveis, mesmo que estas se comportem

como constantes simb´olicas2.

Defini¸c˜ao 4 (La¸co com controle afim). Um la¸co ´e dito com controle afim (ACL) se,

e somente se, ele satisfaz as seguintes condi¸c˜oes:

• Ser uma estrutura perfeitamente aninhada de la¸cos;

• Possuir limites superiores e inferiores de cada la¸co como fun¸c˜oes afins envolvendo

´ındices dos la¸cos mais externos e constantes;

• Possuir corpo formado apenas por comandos que acessam escalares ou vetores, com dependência e acesso afim, isto é, não são permitidas dependências irregulares (como vetores indexando vetores, por exemplo).

Outras defini¸cões importantes, antes de esclarecer o modelo matemático utilizado, são

mostradas a seguir.

Defini¸c˜ao 5 (Hiperplano). Um hiperplano pode ser um espa¸co vetorial, transforma¸c˜ao

afim ou subespa¸co afim de dimens˜ao dim(H) = d − 1 de um espa¸co d-dimensional. Logo,

um hiperplano pode ser representado por uma equa¸c˜ao afim. Um hiperplano divide o

espa¸co em dois semiespa¸cos.

Em especial, em um espa¸co tridimensional, um hiperplano ´e o pr´oprio plano; num

plano, um hiperplano ´e uma reta; numa reta, um ponto.

Defini¸c˜ao 6 (Semiespa¸cos). Um semiespa¸co ´e o conjunto de pontos de um espa¸co

d-dimensional que est˜ao de um lado do hiperplano. Logo, todo semiespa¸co pode ser

representado por uma inequa¸c˜ao afim. Caso algum semiespa¸co inclua o hiperplano, a este

´e dado o nome de semiespa¸co fechado (e pode ser representado por H≤ ou H≥); caso

contr´ario, denomina-se semiespa¸co aberto (indicado por H< ou H>).

Note que, na perspectiva do conjunto Z, para qualquer hiperplano H, Zn= H≤∪ H> = H≥∪ H<

2_{O termo constante simb´}_{olica ´}_{e utilizado aqui para descrever valores que podem variar, mas nunca no}

espa¸co em questão; em uma analogia à programa¸cão de computadores, seriam variáveis que não mudam de valor no bloco de código sendo analisado.

(27)

.

Sistemas de equa¸c˜oes afins s˜ao frequentemente representadas seguindo a forma normal

M v = 0, onde M é uma matriz r × d, r é o número de equa¸cões do sistema e d é o tamanho

do vetor de variáveis e parâmetros v. Semelhantemente, em sistemas de inequa¸cões afins,

utiliza-se a forma normal M v ≥ 0.

3.1.1 Modelo Polit´

opico

Defini¸cão 7 (Pol´ıtopo). À interseçcão de um número finito de semiespa¸cos fechados

d´a-se o nome de pol´ıtopo3_{. Todo pol´ıtopo pode ser representado por uma desigualdade}

matricial como

P =_{x ∈ R}n

: Ax ≤ b, A ∈ Rm×n, b ∈ R .

Como consequˆencia imediata da defini¸c˜ao 7, pode-se representar um pol´ıtopo por um

sistema de inequa¸c˜oes afins e, a partir da´ı, construir uma matriz M sobre este sistema:

cada linha da matriz representar´a um semiespa¸co.

Em [13], Philippe Clauss prop˜oe um m´etodo para contagem de inteiros dentro de um

pol´ıtopo usando a teoria dos polinˆomios de Ehrhart. Esta teoria pode ser vista como

uma generaliza¸c˜ao dimensional da f´ormula de Pick no plano Euclidiano4_{. A discuss˜}_ao

deste m´etodo foge ao escopo deste trabalho, e recomenda-se a leitura de [13] para maiores

detalhes. Para fins desta disserta¸cão, é interessante apenas saber que o número de pontos

inteiros internos a um pol´ıtopo ´e cont´avel.

Modelo Matem´atico de um Programa Fonte

O primeiro passo para aplicar otimiza¸cões utilizando o modelo politópico é transferir

informa¸c˜oes relevantes sobre o programa sendo compilado para a representa¸c˜ao de um

pol´ıtopo. Para isso, é importante saber o que é poss´ıvel representar através do modelo.

Como mencionado anteriormente, este trabalho foca em otimiza¸c˜oes sobre la¸cos. Mais

que isso, restringimos o conjunto dos la¸cos a serem otimizados aos la¸cos ACL – la¸cos com

controle e acessos à memória descritos por fun¸cões afins. Para criar um pol´ıtopo que

represente um ACL5_{, s˜}_{ao quatro as principais informa¸c˜}_{oes que devem ser armazenadas,}

que ser˜ao ilustradas pelo problema descrito a seguir.

3_{Em se tratando de espa¸}_{cos tridimensionais, pol´ıtopos s˜}_{ao conhecidos por poliedros. Similarmente,}

para duas dimens˜oes temos os pol´ıgonos, e pol´ıcoros em quatro dimens˜oes.

4_{A f´}_{ormula de Pick ´}_{e um teorema publicado em 1899 por George Alexander Pick, e trata-se de um}

m´etodo simples para calcular a ´area de pol´ıgonos.

5_{Dado que as fun¸}_c˜_{oes afins extra´ıdas de la¸}_{cos para a representa¸}_c˜_{ao do pol´ıtopo s˜}_{ao (para la¸}_{cos com}

(28)

Suponha um conjunto de restri¸c˜oes afins que descrevem uma parte de um espa¸co

d-dimensional. O conjunto dessas restri¸c˜oes ´e chamado dom´ınio. Considere, sem perda

de generalidade, o seguinte conjunto de restri¸cões, onde i e j são as duas dimensões do

espa¸co (d = 2), e m e n são os parâmetros (constantes simbólicas):

2 ≤ i ≤ n 2 ≤ j ≤ m j ≤ n + 2 − i

(3.1)

Considere, ainda, que se conhece parcialmente os valores dos parˆametros, chamado de

contexto, expressados tamb´em como inequa¸c˜oes afins:

m ≥ 2

n ≥ 2 (3.2)

Uma representa¸c˜ao gr´afica dessa parte do espa¸co bidimensional pode ser vista na figura

3.1. j>=2 j<=m i<=n i>=2 j 1 2 1 2 n i m j<=n+2-i

Figura 3.1: Representa¸c˜ao gr´afica de espa¸co bidimensional. Os pontos na figura mostram

os valores inteiros contidos no espa¸co ilustrado.

Um algoritmo para percorrer os pontos inteiros mostrados na figura, dados o dom´ınio e o contexto, pode ser visto no algoritmo 3.2.

Algoritmo 3.2: Exemplo de passeio sobre pol´ıtopo da figura 3.1. for i ← 2 to n do

for j ← 2 to m do S(i, j)

end end

(29)

Dados o contexto e o dom´ınio como sistemas de inequa¸c˜oes afins, como visto neste

exemplo, podem-se represent´a-los atrav´es de pol´ıtopos.

Note que o corpo do la¸co no algoritmo 3.2 ´e mostrado como uma fun¸c˜ao dos ´ındices

dos la¸cos em torno do bloco. Na verdade, n˜ao ´e importante representar completamente

as senten¸cas presentes no corpo do la¸co atrav´es do modelo, mas apenas as dependˆencias

entre elas (a importância das dependências para a otimiza¸cão é discutida na se¸cão 3.2.1).

Para ser poss´ıvel computar as dependências, é necessário possuir conhecimento sobre a

intera¸c˜ao entre as opera¸c˜oes no conjunto de ´ındices.

Em ACLs apenas s˜ao permitidos vetores com acesso descrito por fun¸c˜oes afins,

poden-do-se tamb´em representar esses acessos por pol´ıtopos; cada linha da matriz representaria

uma dimensão do vetor, e cada coluna, as dimensões e parâmetros do pol´ıtopo. Assim,

todo acesso a uma vari´avel pode ser modelada por uma matriz de acesso, juntamente com

um identificador para o tipo de acesso como leitura ou escrita.

Por ´ultimo, os dom´ınios somente definem um conjunto de pontos inteiros a percorrer,

mas n˜ao especificam uma ordem para fazˆe-lo. Para ser poss´ıvel expressar a ordem de

execu¸cão entre as senten¸cas presentes nos la¸cos, são usadas as fun¸cões de escalonamento.

Defini¸c˜ao 8 (Fun¸c˜ao de escalonamento). Um escalonamento θ de um programa

é uma fun¸cão que mapeia toda opera¸cão para um vetor inteiro que representa o tempo

l´ogico. Para toda senten¸ca S, seu escalonamento θS pode ser representado por uma matriz

Θt×d_{, onde t ´}_{e o n´}_{umero de dimens˜}_{oes de tempo, e d ´}_{e a dimensionalidade do conjunto de}

´ındices de S mais o número de parâmetros simbólicos.

Em outras palavras, um escalonamento θS pode ser utilizado para indicar uma data

lógica para a execu¸cão de uma senten¸ca, a partir das dimensões originais, dos parâmetros

e de escalares. Em [18] é discutido um método bastante simples para calcular as fun¸cões

de escalonamento. A ideia ´e construir uma Loop Statement Tree6 _{(LST) para o programa,}

e ler o escalonamento para cada senten¸ca. Observe o algoritmo 3.3.

A LST correspondente é dada na figura 3.2. Para sua constru¸cão, um nó raiz não

nomeado ´e criado, com arestas dirigindo-se aos n´os que representam todos os la¸cos mais

externos do algoritmo; no exemplo, apenas o la¸co de ´ındice i encontra-se no n´ıvel mais externo. O nó que representa este la¸co, então, é nomeado por sua variável de indu¸cão, e a

aresta que leva até ele é nomeada por um ´ındice inteiro que representa a ordem cronológica

para sua execu¸c˜ao (a ordem em que o la¸co aparece no programa). Internos ao la¸co de

´ındice i, encontram-se um la¸co de ´ındice j, a senten¸ca S2 e outro la¸co de ´ındice tamb´em j,

nesta ordem. Para senten¸cas, um nó com um rótulo identificador é criado. Novamente, as

arestas recebem identificadores que representam sua ordem no c´odigo original. Os passos

6_{Uma Loop Statement Tree ´}_{e uma representa¸}_c˜_{ao em ´}_{arvore da estrutura hier´}_{arquica de la¸}_{cos, que}

(30)

Algoritmo 3.3: N´ucleo do algoritmo de fatora¸c˜ao de Cholesky.

for i ← 1 to n do for j ← 1 to i − 1 do S1: A[i][j] -= A[i][j]; end S2: A[i][i] = sqrt(A[i][i]); for j ← i + 1 to n do for k ← 1 to i − 1 do S3: A[j][i] -= A[j][k]*A[i][k]; end S4: A[j][i] /= A[i][i]; end end

descritos são repetidos para cada nó que represente um la¸co até que todas as folhas na

´

arvore representem senten¸cas.

i j j k S2 S1 S4 S3 0 2 1 0 0 1 0 0

Figura 3.2: Exemplo de Loop Statement Tree para o algoritmo 3.3.

A partir dessa ´arvore, obtemos as fun¸c˜oes de escalonamento

         θS1(i, j) T _{= (0, i, 0, j, 0)}T θS2(i) T _{= (0, i, 1)}T θS3(i, j, k) T _{= (0, i, 2, j, 0, k, 0)}T θS4(i, j) T _{= (0, i, 2, j, 1)}T

onde θT é a matriz transposta de θ. Para entender sua constru¸cão, é necessária a seguinte

defini¸c˜ao:

Defini¸cão 9 (Passeios em árvores). Dada uma árvore T, um passeio é qualquer

(31)

vértices são adjacentes se, e só se, são vértices consecutivos nesta lista, e mediados pela

aresta que os liga. Para o caso espec´ıfico de árvores, todo passeio é também chamado de

caminho (passeio que não repete vértices), uma vez que árvores não possuem ciclos.

Assim sendo, para construir a fun¸c˜ao de escalonamento para S1, por exemplo,

realiza-se o pasrealiza-seio da raiz at´e a folha que representa esta senten¸ca na LST. O escalonamento

para a dada senten¸ca, denotado por θS1, ´e a lista obtida para tal passeio, que (note) ´e

dada em fun¸cão dos nós i e j. De maneira semelhante, podem-se descrever as fun¸cões de

escalonamento para todas as demais senten¸cas pertencentes a esta ´arvore.

Por constru¸c˜ao, perceba que nenhum v´ertice de uma LST possui mais que um caminho

até a raiz: primeiro porque, por defini¸cão, não existem ciclos em árvores; segundo,

ne-nhuma senten¸ca (v´ertices mais externos da ´arvore, ou simplesmente folhas) aparece mais

de uma vez na árvore. Então, a fun¸cão de escalonamento de um vértice que representa

uma senten¸ca S ´e dada pelo caminho da raiz da LST at´e a folha que representa a dada

senten¸ca.

Essas fun¸cões de escalonamento dependem das variáveis de indu¸cão, e dão, para cada

senten¸ca, uma data de execu¸cão única. Gra¸cas a isso, é poss´ıvel gerar código equivalente

ao original a partir de uma representa¸c˜ao de pol´ıtopo.

Além disso, as fun¸cões de escalonamento são fundamentais para a reestrutura¸cão de

código. É através delas que otimiza¸cões ou a própria paraleliza¸cão do código são

im-plementadas: s˜ao essas fun¸c˜oes que ditam a ordem a seguir para percorrer o conjunto

de ´ındices. Mas ´e importante perceber que nem todo escalonamento para um conjunto

de ´ındices é válido: somente os escalonamentos que respeitam as dependências entre as

senten¸cas pertencentes ao la¸co. Formalmente, é necessário ao escalonamento respeitar à

seguinte condi¸c˜ao de casualidade:

Defini¸c˜ao 10 (Condi¸c˜ao de casualidade). Um escalonamento deve obedecer ao

se-guinte princ´ıpio de casualidade, que estabelece uma rela¸c˜ao entre dependˆencias e

escalo-namentos:

(∀u, v ∈ Ω : u δ v ⇒ θ(u) + 1 ≤ θ(v)).

Onde Ω ´e o conjunto de todas as opera¸c˜oes7 _{de uma senten¸ca, e u δ v representa}

uma dependˆencia de v para com u8. Em outras palavras, se alguma instˆancia de uma

senten¸ca depende de uma instˆancia de outra senten¸ca, o escalonamento da segunda deve

ser anterior ao da primeira para preservar o sentido desta dependˆencia.

7_{Uma opera¸}_c˜_{ao pode ser vista como uma instˆ}_{ancia em tempo de execu¸}_c˜_{ao de uma senten¸}_ca. 8_{Cf. defini¸}_c˜_{ao 11.}

(32)

3.2. Alcan¸cando o Paralelismo 19

3.2 Alcan¸

cando o Paralelismo

´

E trabalho do compilador transformar uma computa¸c˜ao de uma representa¸c˜ao em alto

n´ıvel, que é fácil para um humano entender, para uma representa¸cão em baixo n´ıvel, que

a máquina pode executar. Um ponto cr´ıtico é que a representa¸cão humana raramente

comporta detalhes sobre a arquitetura da m´aquina que executar´a o programa, for¸cando

a introdu¸c˜ao de trechos ineficientes de c´odigo em linguagens de alto-n´ıvel. A fim de

eliminar essa ineficiência do código, fases de otimiza¸cão do código foram introduzidas aos

compiladores.

Otimiza¸cões têm sido desenvolvidas para alcan¸car o máximo desempenho, apesar das

diferen¸cas nas arquiteturas dos computadores – entre escalares, superescalares, vetoriais,

etc. Como consequência natural, compiladores também deveriam ser responsáveis por

transformar o c´odigo automaticamente para que o programa resultante tenha vantagens

sobre máquinas paralelas; afinal, o compilador é livre para transformar o código, desde

que o programa gerado compute os mesmos resultados que o original.

Mas as otimiza¸c˜oes – e, na maioria das vezes, a combina¸c˜ao delas – que permitem

explorar o paralelismo s˜ao demasiado radicais. Por exemplo, para alcan¸car desempenho

´

otimo num algoritmo de multiplica¸cão de matrizes, é necessário realizar loop interchange,

loop splitting, loop distribution, vetoriza¸c˜ao e, enfim, paraleliza¸c˜ao [29]. Metade dessas

transforma¸c˜oes nem ao menos s˜ao encontradas na maioria dos compiladores.

Como visto na se¸c˜ao anterior, as transforma¸c˜oes (e, em especial, as que exploram

paralelismo) modificam a ordem de execu¸c˜ao das instru¸c˜oes do programa. O principal

desafio que um compilador deve enfrentar ´e justamente determinar quando dada ordem de

execu¸cão é válida. Em outras palavras, o compilador deve conhecer, e respeitar, restri¸cões

que garantam que o código sempre irá computar os mesmos resultados do código original.

Dado que tais restri¸cões limitam as transforma¸cões, a chave é encontrar um conjunto

m´ınimo de restri¸cões que garantam que o código transformado irá gerar o resultado correto.

Nesta disserta¸cão, usaremos um conjunto de restri¸cões denominadas dependências.

Defini¸cão 11 (Dependência). Dependência pode ser vista como uma rela¸cão entre as

instru¸cões de um programa. O par hS1, S2i é uma rela¸cão de dependência se S1 deve

executar antes de S2 em qualquer reordenamento v´alido das instru¸c˜oes. Comumente,

denota-se por S1 δ S2, para duas senten¸cas S1 e S2no c´odigo, representando a dependˆencia

de S2 para com S1.

Para ilustrar esta defini¸c˜ao, considere o fragmento de c´odigo a seguir.

Para este c´odigo, os resultados originais est˜ao definidos como aqueles gerados quando

(33)

Algoritmo 3.4: Trecho de código que ilustra dependências de dados e rela¸cões de

ordem entre essas dependˆencias.

S1: pi ← 3.14159

S2: r ← 5

S3: area ← pi ∗ r2

hS2,S1,S3i produz o mesmo resultado (o mesmo valor de ´area ´e calculado). As

de-pendências presentes em S3 para as duas instru¸cões anteriores, porém, impedem que

esta seja executada em qualquer outro momento.

Apesar de ser um conceito f´acil de identificar em trechos mais simples (sem desvios),

a otimiza¸cão de tais trechos não garante a utiliza¸cão efetiva dos recursos em máquinas

paralelas: o conceito de dependˆencia deve ser aplicado a fragmentos mais complexos,

como corpos de la¸co, ou chamadas a fun¸c˜oes, por exemplo. Nesses ambientes, entretanto,

podem ocorrer rela¸c˜oes de dependˆencia muito mais dif´ıceis de serem manipuladas. Um

exemplo est´a mostrado no fragmento de c´odigo exibido no algoritmo 3.5.

Algoritmo 3.5: Trecho de c´odigo que ilustra dependˆencia c´ıclica de dados.

for i ← 1 to N do

S1: A[i] ← B[i] + 1

S2: B[i + 1] ← A[i] − 5

end

Neste algoritmo, existe uma dependˆencia que for¸ca a ordem hS1,S2i, porque todo

elemento de A computado pela primeira senten¸ca ´e imediatamente utilizado pela segunda

senten¸ca, e também existe uma outra rela¸cão do tipo hS2,S1i, uma vez que toda itera¸cão

do la¸co usa o valor do elemento em B calculado na itera¸c˜ao anterior. A este tipo de

dependência, dá-se o nome de dependência c´ıclica. É importante notar que dependências

c´ıclicas também podem ocorrer numa instru¸cão sobre ela mesma, como será discutido no

algoritmo 3.7.

3.2.1 An´

alise das Dependˆ

encias

Otimiza¸c˜oes de c´odigo, em especial as mais sofisticadas, introduzem alguma complexidade

ao processo de compila¸cão; a paraleliza¸cão automática introduz muito mais complexidade

a este processo. Para computadores paralelos, encontrar paralelismo em c´odigo sequencial

é, por si só, uma otimiza¸cão. Para auxiliar nessa tarefa, as dependências no código do

programa são identificadas e as otimiza¸cões são ajustadas para preservar o sentido dessas

(34)

Defini¸cão 12 (Teorema Fundamental de Dependência). Qualquer transforma¸cão

que reordena senten¸cas preservando toda dependˆencia no programa preserva tamb´em o

significado do programa.

A prova do teorema acima pode ser visto em [29]. Como consequˆencia direta deste

teo-rema, qualquer transforma¸cão que busque paralelismo por reescalonamento de instru¸cões é

válida, desde que preserve o sentido das dependências. Ao usar as dependências do código

como base para transforma¸cões, então, sua identifica¸cão e análise são pontos cr´ıticos:

de-vem prover informa¸c˜oes suficientes para descobrir se (e como) alguma transforma¸c˜ao pode

ser aplicada.

Dependências representam dois diferentes tipos de restri¸cões para transforma¸cões no

código: restri¸cões que permitem ou não que instru¸cões executem baseadas na execu¸cão de

outras instru¸cões, conhecidas por dependências de controle; e restri¸cões que garantem que

dados sejam consumidos e produzidos em determinada ordem, chamadas de dependˆencias

de dados. Este trabalho concentra-se apenas no ´ultimo tipo de dependˆencias, visto que, no

caso geral, paralelismo ´e encontrado ao aplicar decomposi¸c˜ao de dados9_{. As dependˆ}_encias

de controle, portanto, serão mantidas pelas versões das transforma¸cões discutidas aqui10_.

Formalmente,

Defini¸cão 13 (Dependência de dados). Existe dependência de dados da senten¸ca S1

para S2 (ou seja, a senten¸ca S2 depende de S1) se, e somente se, (1) ambas as senten¸cas

acessam a mesma posi¸c˜ao de mem´oria e, no m´ınimo, uma delas realiza uma escrita e (2)

h´a um caminho poss´ıvel entre S1 e S2 durante a execu¸c˜ao.

Note que instru¸c˜oes que realizam leitura de mesmos dados n˜ao caracterizam

de-pendência de dados: uma vez que a leitura não modifica dados na memória, a ordem

entre duas ou mais leituras pode ser alterada sem modificar a semˆantica do programa.

Logo, pode existir uma dependˆencia de dados entre duas instru¸c˜oes, sejam S1, S2 e S1 δ

S2, se S1 escreve em um dado que S2 lerá (chamada dependência verdadeira), se S1 lê

de um dado que ser´a atualizado por S2 (antidependˆencia), ou se S1 escreve num dado

que será sobrescrito por S2 (dependência de sa´ıda). Ademais, duas instru¸cões que não

9_T´_{ecnica na qual v´}_{arias tarefas paralelas executam opera¸}_c˜_{oes similares sobre conjuntos diferentes de}

dados.

10_{Com algumas modifica¸}_c˜_{oes, as transforma¸}_c˜_{oes podem passar a manipular certos tipos de dependˆ}_encias

de controle. Além disso, algumas dessas dependências podem ser traduzidas em dependências de dados, o que permitiria o uso das transforma¸cões como são mostradas aqui; mas essas modifica¸cões não serão discutidas neste trabalho. Dessa forma, qualquer cita¸cão a dependências no texto a partir daqui, faz referência à dependência de dado (exceto quando explicitado). Para maiores detalhes sobre tratamento de dependências de controle, consultar o cap´ıtulo 7 da referência [29].