jul-2011

I. INTRODUÇÃO

o artigo [1], os autores propuseram uma abordagem não-especulativa para extração automática de threads

chamada Decoupled Software Pipelining (DSWP). DSWP explora o paralelismo de granularidade mais fina requerendo para isto conhecimento da microarquitetura para comunicação inter-core.

N

Para um melhor entendimento do leitor, os autores examinam o paralelismo obtido pela técnica DOACROSS que é caracterizada pela execução concorrente de partes da iteração de um loop através de múltiplos cores. As dependências são respeitadas a partir do encaminhamento dos valores de dependência entre as threads por algum mecanismo de comunicação (normalmente, memória compartilhada) com sincronização. Como consequencia, o roteamento presente entre os cores, estende o caminho crítico do loop por pelo menos a latência média de comunicação multiplicado pelo número de iterações.

A alternativa apresentada pelo DSWP é que, em vez de colocar cada iteração alternadamente em cada núcleo, DSWPquebra a iteração do loop colocando a primeira parte, responsável por percorrer as estruturas de dados recursivas ou ligadas, no core 0 e a segunda parte, o corpo do loop, no core 1. Como conseqüência disto, o caminho crítico do ciclo de dependências permanece no core 0 e portanto, não estará sujeito aos atrasos provocados pela latência de comunicação.

DSWP exige que o fluxo de dados entre os núcleos seja acíclico. Isto implica que as instruções de cada recorrência devem ser agendadas no mesmo núcleo com todas as outras instruções da mesma recorrência. Recorrências diferentes são muitas vezes atribuídos a diferentes núcleos na prática, pois, por definição, as dependências entre eles são acíclicas. Claramente, esta exigência pode limitar os loops passíveis de DSWP. Os autores descrevem a experiência deles em relação à aplicabilidade de DSWP em códigos existentes face a esta limitação e concluem que são raros em códigos após otimizações ILP. Alem disso, o paralelismo DOACROSS normalmente é mais restritivo. Em muitos casos, essas

O trabalho em referência foi apresentado na conferência MICRO'38 realizado entre os dias 12 e 16 de novembro de 2005 na cidade de Washington, DC, USA. O resumo é parte do trabalho de pesquisa de doutorado do Instituto de Computação da UNICAMP (IC-Unicamp) e foi elaborado por Pereira, M. M. (e-mail: mpereira@ic.unicamp.br ).

transformações requerem que loops sejam contaveis, operações exclusivamente em arrays, padrões de acesso de memória regular, controles de fluxo simples (ou mesmo sem controle de fluxo), enquanto que DSWP não tem qualquer dessas restrições.

O mecanismo utilizado para implementar a comunicação inter-core foi a matriz de sincronização (synchronization array). Este mecanismo utiliza duas instruções especiais, produce e consume que, respectivamente, enviam e recebem um valor escalar por uma fila FIFO, não bloqueante (a não ser nos casos de fila cheia ou vazia) do hardware.

Os autores investigaram algumas alternativas para o mecanismo synchronization array com o objetivo de reduzir os custos de hardware [2]. Observaram, por exemplo, que as filas de comunicação podem ser implementadas através de memória compartilhada, por uma pequena penalidade no desempenho. Isto não só reduz os custos de hardware, mas também facilita a virtualização. Para obter um bom desempenho através de memória compartilhada, no entanto, duas alterações de hardware ainda são necessários. Primeiro, as instruções produce e consume são necessários para evitar os custos de implementação da sincronização em software. Em segundo lugar, é necessário alterar o protocolo de coerência de cache para realizar o encaminhamento das linhas de cache (forwarding of cache lines) usadas para implementar as filas. Ter uma linha de cache transmitida do núcleo produtor, quando esta ficar cheia, elimina-se os stalls para acessar as filas no núcleo consumidor.

II.O ALGORITMO DSWP

O primeiro passo do algoritmo DSWP é construir o grafo de dependências para o loop em questão. Neste grafo, cada vértice corresponde a uma instrução do loop e as arestas representam as dependências entre as instruções: dependências de dados, de controle e de memória, bem como as dependências de malha (loop-carried dependence). Dependências de saída e as anti-dependências podem ser ignoradas. O segundo passo é garantir um particionamento acíclico encontrando os componentes fortemente conexos (SCCs) e criando um grafo dirigido acíclico a partir deles (DAGSCC). DSWP requer que todas as instruções contidas no mesmo SCC permaneçam na mesma thread.

Os autores definem então um particionamento válido P de DAGSCC, a sequencia P1, P2, …, Pn de conjunto de vertices

1

Automatic Thread Extraction with Decoupled Software Pipelining

Guilherme Ottoni Ram Rangan Adam Stoler David I. AugustDepartments of Computer Science and Electrical Engineering

Princeton University{ottoni, ram, astoler, august} @ princeton.edu

Resumo realizado por Marcio Machado Pereira – RA 780681

jul-2011

DAGSCC (i.e. Pis são conjuntos de SCCs) satisfazendo as sequintes condições:

1. 1 ≤ n ≤ t, onde t é o número de threads que o processador alvo pode executar simultaneamente;2. Cada vértice em DAGSCC pertence a exatamente uma partição em P ;3. Para cada aresta (u→v) em DAGSCC, com u Є Pi e v Є Pj, temos i ≤ j.

Após a partição ser feita o algoritmo considera os custos das instruções produce e consume para verificar se esta partição é vantajosa ou não. O problema da escolha de uma partição válida que minimiza o custo total de exeução é um problema NP-completo. Na prática, são usadas heurísticas para maximizar o balanceamento de carga entre as threads, computando os cíclos estimados necessários para executar todas as instruções em cada SCC.

A divisão do código envolve os seguintes passos:1. Computa-se o conjunto de blocos básicos relevantes (BBs) para cada partição Pi.

Este conjunto contempla todos

os BBs do loop original que contém as instruções atribuídas à Pi bem como as instruções que Pi depende para permitir a inserção das instruções produce e consume nos pontos onde os valores dependentes são definidos no código. Isto preserva as condições onde as dependências ocorrem.2. Cria-se os BBs para o Pi.3. Insere as instruções atribuídas à Pi no BB correspondente, mantendo a ordem original relativa dentro do bloco básico;4. Fixa-se os branch targets.

O último passo do algoritmo DSWP é a inserção dos pares de instruções produce e consume (chamado de flows) para garantir a corretude do código transformado. Os flows criados são classificados em 3 categorias: data dependence, control dependence e memory/synchronization dependence. Neste último não há valor a ser transmitido. O mesmo é usado como um token para reforçar as restrições de ordenação das operações.

No DSWP, as filas são reusadas a cada iteração e, dependendo do caminho executado, o conjunto de filas pode variar de iteração a iteração. Para garantir a corretude, o compilador precisa fazer com que os valores de diferentes iterações sejam entregues corretamente. Para isto, o controle de fluxo da thread é verificado a cada iteração. Isto requer alguns controles de dependências adicionais, chamados loop-iteration control dependence. Para capturar tais dependências, conceitualmente desenrola-se a primeira iteração do loop. O algoritmo calcula então as dependências de controle padrão para a versão desenrolada do código para uso no código original. O grafo de dependência de controle resultante usado pelo DSWP é obtido pela coalescência dos pares correspondentes de nós no grafo de dependência de controle para o código desenrolado.

III. IMPEMENTAÇÃO E AVALIAÇÃO

Para avaliar o DSWP, os autores implementaram o algoritimo no back-end do compilador IMPACT como um passo

adicional ao número de sofisticadas técnicas de otimização ILP, incluindo Software Pipelining. O conjunto de benchmarks utilizados incluem aplicações do SPEC-CPU2000, do Mediabench e o utilitário 'wc' do Unix. Para avaliar os resultados eles usaram o Itanium com 2 núcleos. A matriz de sincronização tinha um total de 256 filas, cada uma com 32 elementos. Um speedup de 19,4% foi alcançado em importantes benchmarks e uma média de 9,2% foi medida levando em conta todos os benchmarks, o que mostra, segundo os autores, que esta técnica é promissora.

Ainda, de acordo com os autores, outras técnicas de paralelização, não especulativas, e de propósito geral existem, mas normalmente estas técnicas requerem linguagens com suporte a “construções paralelas”, ou seja, o programador precisa reescrever a aplicação para expor o paralelismo.

IV.CONCLUSÃO

Em adição às promessas iniciais, o artigo mostra que os resultados podem ser melhorados através de uma análise de memória mais acurada, heuristicas de particionamento mais elaboradas, novas otimizações para reduzir o número de flows, etc. Os autores acreditam que DSWP pode vir a ser um habilitador para futuras pesquisas relacionadas a TLP.

V. REFERENCIAS

[1] G. Ottoni, R. Rangan, A. Stoler, and D. I. August. Automatic Thread Extraction with Decoupled Software Pipelining. In Proceedings of the 38th annual IEEE/ACM International Symposium on Microarchitecture (MICRO 38). IEEE Computer Society, Washington, DC, USA, 105-118. 2005

[2] R. Rangan, N. Vachharajani, A. Stoler, G. Ottoni, D. I. August, and G. Z. N. Cai. Support for high-frequency streaming in CMPs. In Proceedings of the 39th International Symposium on Microarchitecture, pages 259–269, December 2006.

2