Como devo relatar informações de perfil / tempo sobre meu código?

Eu já vi muitas publicações em periódicos de Física Computacional usarem métricas diferentes para o desempenho de seu código. Especialmente para o código GPGPU, parece haver uma grande variedade de resultados de tempo publicados pelas pessoas. Em particular, eu já vi:

Comparações de (essencialmente) executando timenas versões GPU e CPU e relatando uma média
Comparações de dados de criação de perfil em cada função de GPU / CPU chamada (portanto, cronometrando a execução maine todas as funções chamadas a partir dele, mas ignorando o tempo de inicialização do driver)
Comparações de dados de criação de perfil para várias funções relevantes, ignorando coisas como transferências de memória (no barramento PCI-E, neste caso), E / S para o disco, transformando os dados de um formato para outro, etc.
Comparações de dados de criação de perfil para apenas uma função (por exemplo, comparando apenas o tempo para fazer atualizações de rotação em uma CPU versus GPU Quantum Monte Carlo) e ignorando coisas como tempo de transferência de memória, E / S para disco, configurando o Hamiltoniano / diagonalizando-o etc

Meu sentimento é que a primeira opção é a mais 'honesta' das quatro, embora eu possa ver os méritos da segunda e terceira também. É um pouco ridículo relatar uma diferença de tempo de execução de 5s quando 4,99s eram a diferença nas implementações de E / S entre idiomas ou Infiniband vs Gigabit. A última opção parece um pouco "superficial" para mim, pois, a menos que essa função seja o ponto problemático de todo o programa que relata informações sobre ela, não refletirá o desempenho que alguém que replicaria meus resultados veria. Qual dessas abordagens é mais direta? Idealmente, um artigo conteria tudo isso, mas no caso de uma limitação de figuras / comprimento, qual é / é mais valiosa, honesta e relevante para fornecer?

performance publications documentation

— limas
fonte

Respostas:

O tempo total de execução (relógio de parede) é a única métrica importante para aplicações industriais ou da vida real: esse número nunca deve ser omitido, mesmo que seja embaraçoso. Obviamente, essa métrica depende muito do ambiente de teste, portanto, isso deve ser descrito em detalhes.

Todas as outras métricas podem (ou devem ser) relatadas se fornecerem informações sobre o problema ou conclusões interessantes (por exemplo, verificação de algum limite teórico) podem ser extraídas delas.

Penso que esta entrada de blog aborda esse ponto, especialmente o último parágrafo.

— Stefano M
fonte

Até o tempo do relógio de parede me parece possivelmente enganoso, porque a qualidade das implementações de cada algoritmo é importante. Joel Spolsky aborda a questão de "não existe o código mais rápido" em uma postagem no blog. Sem postar o código fonte das implementações (e eu suspeito que, em alguns casos, mesmo que alguém tenha publicado o código fonte das implementações), como vou saber o que é realmente "mais rápido"? Em outras palavras, como fazer uma comparação dos tempos do relógio de parede (ou qualquer outra métrica) significativa?

— 9605 Geoff Oxberry

@ GeoffOxberry Em um passado distante, quase todos os cálculos eram seriados, e a hierarquia de memória era de apenas dois níveis, dentro e fora do núcleo. Naqueles dias (felizes) matlabainda relatados, flopscontagem após cada comando ... Atualmente, temos CPUS, GPGPUS, clusters, nuvens multicore, caches L1 / L2 / L3, ... Eficiência é determinada pela capacidade de mapear um algoritmo à arquitetura hw / sw fornecida. É tolice tentar condensar tudo em uma única figura, mas, no entanto, devemos ser capazes de introduzir uma ordem e dizer, em algumas condições determinadas e bem definidas, quem é mais rápido.

— 18712 Stefano M

Sim eu concordo. Estou perguntando como alguém deve introduzir essa ordem para fazer comparações significativas que determinarão, sob quaisquer condições definidas e bem definidas que você especificar, quem é mais rápido.

— 9608 Geoff Oxberry

+1 Tudo isso faz sentido e depende do ponto que se está tentando destacar na publicação. Se o ponto é sobre desempenho, ele precisa ser explicado com muito mais cuidado.

— Mike Dunlavey

Geralmente, é possível relatar a ponta do iceberg de todo o trabalho e compromissos que foram inseridos em um software. O desempenho dos relatórios é bom, mas o verdadeiro problema é quando o código é acessado livremente na Internet, assim, qualquer pessoa interessada pode avaliar e reproduzir os resultados.

Idealmente, se você lançar o software, também poderá disponibilizar os testes que geram os dados apresentados em um documento.

— fcruz
fonte

Concordo plenamente: figuras nuas não fazem sentido. Para obter um código-fonte de resultados reproduzíveis e significativos, os conjuntos de dados de teste, a configuração hw, a configuração sw devem ser tornados públicos.

— Stefano M

No caso de eu ter implementado um algoritmo duas vezes, uma na GPU e outra na CPU, concordo que as configurações de HW / SW são absolutamente necessárias para incluir. Ainda não estou claro sobre quais dados apresentar no caso em que encontro um "efeito de escala" (por exemplo, comparando velocidade versus tamanho da matriz para ED). Devo comparar relógios? Apenas a parte ED do cálculo?

— limes

Se você está interessado em uma comparação profunda de códigos, eu como o trabalho de Volkov e Demmel, em seu papel (um pouco antiga, mas ilustrativo): Aferição GPUs para sintonizar densa linear álgebra

— fcruz