ANÁLISE SOBRE O ARTIGO: AUTOTUNING GEMMS FOR FERMI

1. ANÁLISE SOBRE O ARTIGO:AUTOTUNING GEMMS FOR FERMI André Moraes Julio Toss

2. TEMA • O contexto do paper é o da programação paralela em GPUs. Mais especificamente, como definir os parâmetros ideais para a execução de uma aplicação de multiplicação de matriz em uma dada arquitetura de GPU. • Rotinas de multiplicação de matriz são um componente crucial nos pacotes de softwares numéricos, tais quais LAPACK e ScaLAPACK, e representam uma das cargas de trabalho mais importantes a serem implementadas em GPUs.

3. MOTIVAÇÃO • GEMM é um importante componente em softwares como LAPACK e ScaLapack sendo essencial para suas performances. • GEMM é também crítico para a performance do benchmark HPL, usado para determinar os TOP500 computadores mais rápidos do mundo. • Está inserido no contexto amplo da performance em Exascale.

4. A principal motivação do artigo é a geração automática de kernels GEMM otimizados. Até agora esses kernels eram gerados através de experimentações exaustiva em vez de usar um processo sistemático de autotuning.

5. OBJETIVO • Como definir os parâmetros ideais para a execução de uma aplicação de multiplicação de matriz em uma dada arquitetura de GPU.

6. MODELO • Os autores definiram um modelo parametrizável de código de multiplicação de matriz em GPU. A forma da multiplicação utilizada é C = C + A x B. • O código pode ser parametrizado para definir a granularidade e forma dos blocos de trabalho que serão executados por cada thread na GPU. • Tais parâmetros são: • Tamanho do trabalho de thread block = Mblk x Nblk x Kblk • Forma do grid de threads = Mdim x Ndim • Pode se usar uma forma de grid diferente para leitura do valores das matrizes A e B: (MdimA x NdimA ) e (MdimB x NdimB)

7. MODELO GEMM no nível do Thread Block

8. Geração do Espaço de Busca: • O papel do gerador do espaço de busca é determinar todos os valores possíveis e plausíveis para os parâmetros do modelo anterior. Porém um espaço de busca de 9 dimensões é imenso e existem restrições de diversas partes. • 4 tipos de restrições foram definidas: • Queryable Hardware constraints: determinadas em tempo de execução • Non-queryable hardware constraints: limitaçôes fixas ligadas ao modelo do hardaware • Hard implementation constraints: restrições que se violadas invalidam a implementação • Soft implementation constraints: restrições que se violadas fazem com que a implementação rode sem provas , mas não é invalida.

9. O gerador considera também algumas diretivas (guidelines) de performance que ajudam a diminuir o espaço de busca para focar na melhores combinações, são elas: • “Occupancy” mínima • Número mínimo de blocos por MP • Mínimo de reutilização dos registradores • Todas essas restrições e diretivas são codificadas sob formas de regras no gerador de espaço de busca.

10. RESULTADOS DA DEMONSTRAÇÃO • Pré-Seleção: Devido ao gerador de espaço de buscas, 100 soluções são dadas como as melhores (Num espaço de 100 milhões) • Definidas as restrições, o gerador foi executado para 16 casos de multiplicação de matriz. O resultado da limitação do espaço de busca mostrou se muito promissor, por exemplo em alguns casos (SGEM AxB) gerador forneceu pouco mais de 100 combinações possíveis contra mais de um milhão caso não houvesse o mecanismo de restrições do espaço de busca. • A performance do kernel é independente do tamanho da matriz de entrada, portanto não mudaria os resultados do gerados, demonstrado por gráfico.

11. Gerador não substitui o benchmark das soluções obtidas: • Com os kernels gerados realizaram-se testes de performance nas gpus para avaliar o seu desempenho real. Os tempos obtidos comprovam que o gerador por si só não poderia ser usado como único mecanismo de seleção, embora todas a combinações geradas são boas candidatas à ser um kernel rápido, a performance pode variar bastante. Aumentar ainda mais as restrições não significa que iremos convergir para o melhor kernel (i.e o mais rápido).

12. NOSSA CONCLUSÃO • Autotuning é crucial para o desenvolvimento de código para GPU. • O trabalho se limita a GEMM, o que é apenas 1 tipo de workload. Encontrar heurísticas para aplicar auto-tuning em workloads genéricos seria um nível de dificuldade maior. • Como as GEMM são fundamentais, esse trabalho resulta sim em otimizações de programas reais, tornando-os mais portáveis em performance. • Software é distribuído através do projeto MAGMA sobre a licença BSD.

13. NOTAS • Motivação: 5 • O contexto está bem classificado e é um problema útil a comunidade. • Objetivos e Modelo: 5 • O modelo foi feito de acordo com os objetivos e os objetivos são focados nas arquiteturas atuais. • Resultados e comparações: 4 • Apresentaram bons resultados que explicitam pontos interessantes. Não há comparação de resultados. • Redação e Formatação: 4 • A formatação está excelente, com gráficos apoiando a constatação do autor. O paper foi enviado sem ter os protótipos publicados na época. Apesar dos links terem sidos informados. É explicitado detalhes de implementação no artigo.