Co-Design and Evaluation of a CPU-Free MPI GPU Communication Abstraction and Implementation

Este artigo descreve o projeto, implementação e avaliação de uma API de comunicação MPI baseada em GPU que elimina a necessidade do processador no caminho de comunicação, demonstrando reduções significativas de latência e melhorias de desempenho em supercomputadores como o Frontier e o Tuolumne.

O essencial

Imagine que você está organizando uma festa gigante em um prédio com milhares de apartamentos (os GPUs, ou placas de vídeo). O objetivo é que todos os vizinhos troquem pratos de comida (os dados) rapidamente para que a festa continue.

No mundo dos supercomputadores atuais, existe um problema: para que dois vizinhos troquem um prato, eles precisam pedir ajuda ao porteiro (o CPU, ou processador central). O porteiro tem que sair do seu posto, verificar se o prato está pronto, confirmar que o vizinho está esperando e só então autorizar a troca. Isso cria uma fila, um atraso, e o porteiro fica sobrecarregado, impedindo que a festa (o cálculo científico) corra o mais rápido possível.

Este artigo descreve uma solução genial: tirar o porteiro da linha de frente da troca de dados.

Aqui está a explicação do que os pesquisadores fizeram, usando analogias do dia a dia:

1. O Problema: O "Porteiro" que atrasa tudo

Antes, quando um computador com muitas placas de vídeo precisava se comunicar, o processo era assim:

• A placa de vídeo (GPU) calculava algo.
• Ela gritava para o processador (CPU): "Ei, tenho um dado pronto!"
• O processador parava o que estava fazendo, ia até a placa, verificava, e dizia: "Ok, agora você pode enviar."
• A placa enviava.
• O receptor recebia e gritava para o processador: "Recebi! Agora posso processar."
• O processador voltava a trabalhar.

Isso é como se, para cada mensagem, você tivesse que parar, escrever um bilhete, correr até a mesa do gerente, esperar ele carimbar e só então entregar. Em supercomputadores, esse "carimbo" demora microssegundos, mas quando você faz isso milhões de vezes, o tempo total explode.

2. A Solução: O "Sistema de Semáforos Inteligentes"

Os pesquisadores criaram um novo sistema (uma nova "API") que permite que as placas de vídeo conversem diretamente entre si, sem chamar o porteiro para cada pequena troca.

Eles usaram uma tecnologia especial das redes HPE Slingshot (que são como estradas super-rápidas para dados) e criaram um mecanismo de "trabalho adiado".

A Analogia do Restaurante:
Imagine que, em vez de pedir ao gerente para trazer cada prato, os garçons (as GPUs) têm um sistema de contadores e semáforos:

• Pré-Preparo (Persistência): Antes da festa começar, os garçons já combinam quem vai levar o quê para quem. Eles não precisam perguntar "você está pronto?" a cada vez. Eles já sabem.
• O Semáforo (Contador): Cada garçom tem um contador na parede. Quando o garçom da cozinha termina de preparar o prato, ele dá um "toque" no contador (uma operação na memória).
• A Entrega Automática: Assim que o contador bate no número certo, o sistema de entrega (a rede) sabe automaticamente: "Ok, o prato está pronto, pode enviar!". O porteiro (CPU) nem precisa saber que a entrega aconteceu naquele momento.

3. O Que Eles Criaram (A "Mágica")

Eles desenvolveram uma linguagem de programação que permite:

• Comunicação sem CPU: O computador não precisa "acordar" o processador principal para cada mensagem.
• Troca de Dados em "Fila" (Stream): Você pode colocar uma lista de 1.000 entregas na fila de uma vez só. A GPU executa tudo sozinha, como um trem que segue a trilha sem precisar de um maquinista em cada estação.
• Segurança: Eles garantiram que, mesmo sem o porteiro, ninguém entrega um prato se a mesa do vizinho ainda não estiver pronta (evitando colisões ou dados perdidos).

4. Os Resultados: A Festa Ficou Muito Mais Rápida

Eles testaram isso em supercomputadores gigantes (como o Frontier e o Tuolumne nos EUA). Os resultados foram impressionantes:

• Latência Reduzida: Para mensagens médias, a comunicação ficou 50% mais rápida. É como se o tempo de espera para o porteiro carimbar tivesse sido cortado pela metade.
• Escalabilidade: Quando eles aumentaram o número de computadores para 8.192 GPUs, o sistema novo foi 28% mais eficiente do que o sistema antigo.
• O "Pulo do Gato": Em tarefas onde os computadores precisam trocar dados constantemente (como simular o clima ou o movimento de átomos), essa economia de tempo é crucial. É a diferença entre terminar um cálculo em 1 hora ou em 1 hora e 20 minutos.

Resumo Simples

Os pesquisadores criaram um "atalho" para os supercomputadores. Em vez de toda comunicação ter que passar por uma "caixa de entrada" do processador principal (que é lento para lidar com milhões de micro-tarefas), eles permitiram que as placas de vídeo se organizassem sozinhas, usando sinais automáticos.

Resultado: O processador principal fica livre para fazer o trabalho pesado de cálculo, enquanto as placas de vídeo trocam dados entre si em alta velocidade, como se estivessem em uma via expressa sem semáforos. Isso torna a inteligência artificial e a ciência de dados muito mais rápidas e eficientes.

Resumo técnico

Resumo Técnico: Co-Design e Avaliação de uma Abstração de Comunicação MPI para GPU sem CPU

1. O Problema

Em sistemas de Computação de Alto Desempenho (HPC) e Aprendizado de Máquina (ML) modernos baseados em GPU, a comunicação eficiente é crítica. As abordagens tradicionais de comunicação MPI (Message Passing Interface) "conscientes de GPU" ainda dependem da CPU para gerenciar o fluxo de dados, o que introduz latências significativas no caminho crítico de comunicação ("fast path").

Os principais gargalos identificados são:

• Sincronização CPU/GPU: O lançamento de kernels, barreiras de memória e sincronização de streams consomem tempo (na ordem de microssegundos) que se soma à latência de rede.
• Custos de Configuração: Protocolos de comunicação de dois lados (como Ready-to-Send/Clear-to-Send) e correspondência de mensagens (matching) exigem intervenção da CPU.
• Limitações de APIs Existentes: APIs existentes que tentam remover a CPU (como NVSHMEM) geralmente sacrificam a expressividade da API (ex: removendo correspondência de mensagens ou comunicação de dois lados), tornando-as difíceis de integrar em frameworks de portabilidade de desempenho como o Cabana/Kokkos.

O objetivo é criar uma API que permita comunicação totalmente livre de CPU (CPU-free), mantendo as abstrações familiares de dois lados do MPI e a facilidade de uso.

2. Metodologia e Abordagem

Os autores propuseram um co-design de uma nova API de extensão MPI e sua implementação específica para cartões de rede HPE Slingshot 11. A abordagem baseia-se nos seguintes pilares:

• Operações Persistentes do MPI: Utilizam operações persistentes (ponto a ponto e coletivas) para separar a configuração da comunicação do seu uso no caminho rápido. Isso permite que a correspondência de mensagens (matching) seja resolvida antes da execução no GPU.
• API de Disparo por Stream (Stream-Triggered): Introduzem um objeto MPI_Queue associado a um stream de GPU. As operações de comunicação são enfileiradas neste objeto e executadas diretamente pelo hardware da GPU quando o stream avança, sem intervenção da CPU.
• Mecanismo de "Match" (Correspondência): Propõem uma nova função MPI_Match que transforma requisições persistentes em requisições permanentemente correspondidas. Isso remove a necessidade de negociação de correspondência durante a execução, permitindo que o GPU dispare a comunicação diretamente.
• Uso de Recursos de Hardware (Slingshot 11/libfabric):
  • Contadores de Disparo (Triggering Counters): A GPU incrementa um contador em memória mapeada para iniciar a comunicação.
  • Fila de Trabalho Adiada (Deferred Work Queue - DWQ): O hardware da NIC executa operações de comunicação (como fi_write e fi_atomic) apenas quando o contador atinge um valor específico.
  • Sincronização de Recebimento: Para garantir que o receptor esteja pronto (evitando perda de dados em envios padrão), o sistema usa uma cadeia de operações atômicas (fi_atomic) disparadas pelo recebimento de dados para sinalizar ao emissor que o buffer de destino está pronto (CTS - Clear-To-Send).

3. Principais Contribuições

O artigo apresenta quatro contribuições principais:

1. Design de uma Nova API MPI para GPU: Uma extensão que suporta comunicação de dois lados livre de CPU, preservando a semântica familiar do MPI (matching, buffers prontos) e introduzindo primitivas de enfileiramento (MPI_Enqueue_start, MPI_Enqueue_wait).
2. Implementação em Cabana/Kokkos: Demonstração da utilidade da API ao criar versões revisadas de objetos de troca de halo (halo exchange) no framework Cabana, permitindo que primitivas de coleta/dispersão (gather/scatter) sejam executadas sem CPU.
3. Implementação de Baixo Nível para Slingshot 11: Uma implementação completa que utiliza as filas de trabalho adiadas (DWQ) e contadores do provedor libfabric CXI da HPE para fornecer comunicação ponto a ponto MPI totalmente livre de CPU.
4. Avaliação de Desempenho em Supercomputadores: Avaliação rigorosa nos sistemas Frontier (ORNL) e Tuolumne (LLNL), comparando a nova abordagem com o Cray MPICH padrão.

4. Resultados

Os experimentos foram conduzidos em benchmarks de microdesempenho (ping-pong) e em benchmarks de aplicação (troca de halo no "Jogo da Vida" usando Cabana).

• Latência e Largura de Banda (Ping-Pong):

  • Redução de latência de até 50% para mensagens de tamanho médio (entre 4KB e 1MB) em comparação com o Cray MPICH.
  • A latência reduzida deve-se à eliminação de lançamentos de kernels e sincronizações CPU/GPU no caminho crítico.
  • Para mensagens muito grandes (>8MB), o Cray MPICH ainda apresenta melhor largura de banda devido a otimizações de hardware específicas para grandes volumes que a implementação atual ainda não igualou.

• Escalabilidade Forte (Halo Exchange):

  • No supercomputador Frontier (até 8.192 GPUs), a abordagem com disparo por stream (Stream-Triggered) mostrou um aceleração (speedup) de 28% na escalabilidade forte para o problema grande (30GB) em comparação com o Cray MPICH.
  • Para o problema pequeno (2GB), a abordagem superou o Cray MPICH até 256 processos MPI, embora o MPICH padrão tenha se recuperado em escalas maiores devido a otimizações de mensagens pequenas (unexpected messages).
  • A implementação "Ready Send" (envio pronto) mostrou o melhor desempenho geral, alcançando o mesmo speedup do MPICH em metade dos nós para o problema pequeno e superando-o significativamente no problema grande.

• Análise de Mensagens Pequenas:

  • Mensagens muito pequenas (<8KB) ainda sofrem penalidade de desempenho na implementação atual devido à espera por sinais CTS (Clear-To-Send) e falta de otimização com buffers de rebote (bounce buffers), uma área identificada para melhoria futura.

5. Significância e Conclusão

Este trabalho é significativo porque demonstra que é possível remover completamente a CPU do caminho crítico de comunicação em sistemas HPC modernos sem sacrificar a expressividade da API MPI de dois lados.

• Viabilidade Técnica: Prova que as capacidades de hardware de redes modernas (como Slingshot 11) podem ser exploradas via software para eliminar a sobrecarga de sincronização CPU-GPU.
• Impacto em Aplicações: A integração com o framework Cabana/Kokkos mostra que essa tecnologia pode ser adotada por aplicações de produção e benchmarks complexos, melhorando a escalabilidade forte em milhares de GPUs.
• Futuro: O trabalho abre caminho para otimizações futuras, como o uso de buffers de rebote para mensagens pequenas e a portabilidade para outras arquiteturas de rede (como InfiniBand da NVIDIA), permitindo comparações diretas com soluções como NCCL.

Em resumo, a proposta oferece um caminho viável para a próxima geração de comunicações HPC, onde a GPU controla diretamente a rede, maximizando a eficiência energética e de tempo de execução em aplicações de larga escala.