Prática de Análise Comparativa de Eficiência Computacional

Esta página põe a «comparação de eficiência computacional» em prática de forma reproduzível:comparar, numa mesma tarefa evolutiva, a eficiência ponta a ponta da iteração serial indivíduo a indivíduo em CPU tradicional com o processamento em lote tensorial na GPU via EvoX. O objetivo não é memorizar a conclusão de que «a GPU é mais rápida», mas compreender de onde vem exatamente o ganho de velocidade trazido pelo paralelismo tensorial, qual é o seu custo e onde estão os seus limites.

Duas linhas de base, uma mesma tarefa

Linha de base serial em CPU: utiliza um laço para chamar a função de avaliação indivíduo a indivíduo, exigindo N agendamentos independentes, atualizações de estado e agregação de resultados por geração. O controle do laço, a sobrecarga do interpretador e os acessos dispersos à memória diluem o poder computacional efetivo; quanto mais indivíduos, maior a proporção desses custos «não computacionais».
Implementação de comparação com tensores na GPU: o EvoX organiza a população, as entradas de avaliação e o estado de execução como tensores, executando avaliações e operadores em lote na GPU, de modo que uma única chamada cobre todo o conjunto de candidatos, reduzindo drasticamente os laços seriais e o número de agendamentos.

Protocolo de medição: tornar a comparação reproduzível

Uma comparação reproduzível devefixar o problema, o tamanho da população, o número de gerações e a semente aleatória, e então registrar: o tempo real (wall-clock) por geração, o tempo total, a taxa de transferência (avaliações/segundo), a aceleração, além da utilização da GPU e do uso de memória de vídeo. Antes de cronometrar, é necessárioaquecimentopara eliminar o efeito da primeira compilação e da alocação de memória de vídeo, e realizar, nos pontos de medição,sincronização do dispositivo, contabilizando separadamente o tempo de computação e o tempo de transferência de dados entre host e dispositivo. A ausência de qualquer uma dessas etapas pode distorcer a aceleração obtida.

De onde vem a diferença e a que restrições está sujeita

Origem dos ganhos: o paralelismo em lote, os operadores tensoriais e o paralelismo no dispositivo permitem que uma única chamada processe todo o conjunto de candidatos, concluindo mais avaliações por unidade de tempo.
Condições restritivas: o tamanho do lote, a dimensionalidade do problema, o grau de vetorização da função de avaliação, o custo de cópia host–dispositivo e o custo de lançamento de kernels afetam todos a aceleração final. Lotes muito pequenos têm os ganhos consumidos pelo custo de lançamento; se a função de avaliação não puder ser vetorizada, o processamento em lote dificilmente terá efeito.

Conclusões práticas

A ordem correta é:primeiro verificar se a função de avaliação pode ser processada em lote e só depois comparar as implementações em CPU e GPU. A vantagem de eficiência deve, em última análise, traduzir-se em «obter mais gerações ou mais soluções candidatas com o mesmo orçamento computacional», e, com base nisso, decidir a forma de implantação e o desenho experimental, em vez de simplesmente perseguir um número de aceleração vistoso.

Comparação de eficiência entre CPU serial e processamento em lote na GPU

Na comparação, a linha de base serial em CPU avalia indivíduo a indivíduo num laço, exigindo N agendamentos e atualizações de estado por geração, com a sobrecarga do interpretador e dos acessos à memória diluindo o poder computacional efetivo; o processamento em lote na GPU organiza a população e as entradas de avaliação como tensores, cobrindo todo o conjunto de candidatos numa única chamada. A aceleração está sujeita ao tamanho do lote, ao grau de vetorização da função de avaliação e ao custo de cópia host–dispositivo.

Questão 1

Na implementação de linha de base com iteração serial de indivíduos na CPU, de onde vem o principal custo de tempo por geração?

Do custo de transferência de dados entre host e dispositivo

Do custo de lançamento de kernels na GPU

Do custo de redução em lote dos operadores tensoriais

Do custo de agendamento, do interpretador e dos acessos dispersos à memória decorrentes de chamar a função de avaliação individualmente para cada indivíduo

Questão 2

Qual é o mecanismo-chave pelo qual a avaliação em lote do EvoX na GPU consegue reduzir a sobrecarga serial?

Organizar a população, as entradas de avaliação e o estado de execução como tensores, cobrindo todo o conjunto de candidatos numa única chamada

Reduzir automaticamente o tamanho da população para diminuir a carga computacional por geração

Aumentar a precisão do cálculo da avaliação de cada indivíduo, reduzindo assim o número de gerações

Usar menos sementes aleatórias para reduzir o número de reamostragens

Questão 3

Qual das opções a seguir corresponde melhor a um protocolo de medição padronizado para comparação de eficiência computacional?

Não fazer sincronização do dispositivo nos pontos de medição, para capturar a execução assíncrona mais completa

Relatar apenas o tempo total, sem necessidade de fixar a semente aleatória

Fixar o problema, o tamanho da população, o número de gerações e a semente aleatória; fazer aquecimento e sincronização do dispositivo antes de cronometrar; e distinguir o tempo de computação do tempo de transferência de dados

Comparar apenas diferentes tamanhos de lote na GPU, sem necessidade de confrontar com a linha de base em CPU

Questão 4

Por que é obrigatório executar a sincronização do dispositivo antes de medir o tempo da GPU?

Porque a GPU geralmente executa de forma assíncrona; sem sincronização, a medição pode omitir cálculos ainda não concluídos e subestimar o tempo real

Porque a sincronização aumenta diretamente o poder computacional de pico da GPU

Porque a sincronização reinicia a semente aleatória para garantir a reprodutibilidade

Porque a sincronização elimina toda a transferência de dados entre host e dispositivo

Questão 5

Quando o grau de vetorização da função de avaliação é muito baixo, como costuma variar a vantagem de eficiência do processamento em lote na GPU?

Estabiliza-se automaticamente numa aceleração fixa de dez vezes

Pelo contrário, aumenta sem limite à medida que o lote cresce

Não é afetada em nada pelo grau de vetorização, mantendo a aceleração constante

Diminui nitidamente, podendo até ter ganhos limitados devido aos custos de cópia e de lançamento de kernels

Estudo de caso: um experimento de comparação de eficiência reproduzível

Leia o desenho experimental a seguir, responda às duas questões e explique os fundamentos das suas conclusões e o seu raciocínio.

A equipe quer comparar, numa mesma tarefa evolutiva, uma implementação serial em CPU com uma implementação de processamento em lote tensorial na GPU via EvoX. A dimensionalidade do problema é alta, o corpo da função de avaliação é composto por operações numéricas vetorizáveis, havendo apenas uma pequena parte de lógica de pós-processamento indivíduo a indivíduo. Planeia-se fixar o problema, o tamanho da população N=512, o número de gerações e a semente aleatória, registando o tempo real (wall-clock) por geração, o tempo total, a taxa de transferência e a aceleração. Numa execução preliminar, um membro cronometrou diretamente no lado da GPU sem fazer sincronização do dispositivo e usou esse resultado para anunciar publicamente uma aceleração de cerca de 9 vezes; ao mesmo tempo, outro membro testou com um lote extremamente pequeno (b=8) e obteve uma aceleração de apenas cerca de 1,2 vezes.

1. Por que a «aceleração de cerca de 9 vezes» obtida sem sincronização do dispositivo é provavelmente pouco confiável? Como se deve corrigir o experimento?

Resposta:
A GPU adota um modelo de execução assíncrona: depois de enviar um kernel, o host continua a executar sem esperar pela sua conclusão; se não houver sincronização do dispositivo nos pontos de medição, o tempo medido pode cobrir apenas a fase de envio do kernel, omitindo os cálculos ainda em execução, o que subestima gravemente o tempo da GPU e infla a aceleração. A correção consiste em: chamar a sincronização do dispositivo em cada ponto de medição, garantindo que todo o trabalho enviado esteja realmente concluído antes de ler o carimbo de tempo; fazer também iterações de aquecimento para eliminar o custo da primeira compilação e da alocação de memória de vídeo; e contabilizar separadamente o tempo de transferência de dados entre host e dispositivo do tempo de computação pura. Só o tempo por geração e o tempo total medidos com semente fixa, aquecimento e sincronização podem servir de base confiável para a aceleração.

2. A equipe observou simultaneamente que, com lote pequeno (b=8), a aceleração é de apenas cerca de 1,2 vezes, o que não contradiz os ganhos que uma função de avaliação vetorizável deveria trazer. Explique o motivo e apresente sugestões de otimização.

Resposta:
Os ganhos de aceleração do processamento em lote estão sujeitos ao tamanho do lote, ao custo de lançamento de kernels e ao custo de transferência de dados. Quando o lote é demasiado pequeno, a quantidade de trabalho paralelizável no dispositivo é insuficiente, e os custos fixos, como o lançamento de kernels e a cópia host–dispositivo, ocupam uma fração elevada do tempo por geração, impedindo que o paralelismo efetivo dilua esses custos, o que naturalmente comprime a aceleração para perto de 1. Sugestões: (1) aumentar o tamanho do lote dentro dos limites permitidos pela memória de vídeo (por exemplo, de b=8 para b=64, b=256 ou mais), fazendo com que os custos fixos sejam diluídos por mais indivíduos candidatos; (2) vetorizar ao máximo a função de avaliação e a lógica de pós-processamento como um todo, reduzindo o retorno ao dispositivo e os desvios indivíduo a indivíduo; (3) medir novamente seguindo o protocolo padronizado — fixar o problema, a população, as gerações e a semente aleatória; cronometrar após aquecimento e sincronização; e relatar separadamente o tempo por geração, o tempo total, a taxa de transferência e a aceleração, para determinar se os ganhos realmente se traduzem no objetivo de «obter mais gerações ou mais candidatos com o mesmo orçamento».