Gráfico de escala / eficiência paralelo de log-log

Muito do meu trabalho gira em torno de melhorar a escala dos algoritmos, e uma das maneiras preferidas de mostrar escala paralela e / ou eficiência paralela é traçar o desempenho de um algoritmo / código sobre o número de núcleos, por exemplo,

onde o eixo representa o número de núcleos e o eixo uma métrica, por exemplo, trabalho realizado por unidade de tempo. As diferentes curvas mostram eficiências paralelas de 20%, 40%, 60%, 80% e 100% em 64 núcleos, respectivamente.$x$$y$

Infelizmente, porém, em muitas publicações, esses resultados são plotados com uma escala de log-log , por exemplo, os resultados deste ou deste artigo. O problema com esses gráficos de log-log é que é incrivelmente difícil avaliar a escala / eficiência paralela real, por exemplo

Qual é o mesmo gráfico acima, mas com escala de log-log. Observe que agora não há grande diferença entre os resultados para eficiência paralela de 60%, 80% ou 100%. Eu escrevi um pouco mais sobre isso aqui .

Então, eis a minha pergunta: que justificativa existe para mostrar resultados no dimensionamento de log-log? Uso regularmente o dimensionamento linear para mostrar meus próprios resultados, e regularmente sou martelado pelos árbitros que dizem que meus próprios resultados de dimensionamento / eficiência paralelos não parecem tão bons quanto os resultados (log-log) de outros, mas para a minha vida eu não vejo por que devo mudar os estilos de plotagem.

No momento, estamos escrevendo um artigo que contém várias parcelas comparáveis ​​e tivemos mais ou menos o mesmo problema. O artigo trata da comparação da escala de algoritmos diferentes sobre o número de núcleos, que varia entre 1 e até 100k em um BlueGene. A razão para usar gráficos de log nesta situação é o número de ordens de magnitude envolvidas. Não há como traçar 6 ordens de magnitude em uma escala linear.

E, de fato, ao plotar o tempo sobre o número de núcleos no log de log, os algoritmos não são muito distinguíveis, como você pode ver na plotagem a seguir.

$E_p=T_1/(p T_p)$$T_1$$T_p$$p$$p$$E_p$$p$

$E_p=T_{ref}/(p T_p)$$T_{ref}$

Plotar a eficiência paralela relativa em uma escala semilog mostra claramente a escala de um algoritmo e também mostra como os algoritmos se desempenham relativamente um ao outro.

Georg Hager escreveu sobre isso em Enganando as massas - Conluio 3: A escala do log é seu amigo .

Embora seja verdade que os gráficos de log-log de escala forte não sejam muito exigentes, eles permitem mostrar a escala em muitas outras ordens de magnitude. Para ver por que isso é útil, considere um problema 3D com refinamento regular. Em uma escala linear, é possível mostrar razoavelmente o desempenho em cerca de duas ordens de magnitude, por exemplo, 1024 núcleos, 8192 núcleos e 65536 núcleos. É impossível para o leitor dizer a partir da trama se você executou algo menor e, realisticamente, a trama apenas compara as duas maiores execuções.

Agora, supondo que possamos ajustar 1 milhão de células da grade por núcleo na memória, isso significa que, após uma forte escalada duas vezes por um fator de 8, ainda podemos ter 16 mil células por núcleo. Esse ainda é um tamanho considerável de subdomínio e podemos esperar que muitos algoritmos sejam executados com eficiência lá. Abordamos o espectro visual do gráfico (1024 a 65536 núcleos), mas ainda nem entramos no regime em que a forte escala se torna difícil.

Suponhamos que começássemos com 16 núcleos, também com 1 milhão de células de grade por núcleo. Agora, se escalarmos para 65536 núcleos, teremos apenas 244 células por núcleo, o que será muito mais exigente. Um eixo de log é a única maneira de representar claramente o espectro de 16 núcleos a 65536 núcleos. É claro que você ainda pode usar um eixo linear e ter uma legenda dizendo "os pontos de dados para 16, 128 e 1024 núcleos se sobrepõem na figura", mas agora você está usando palavras em vez da própria figura para mostrar.

Uma escala de log-log também permite que seu dimensionamento "se recupere" dos atributos da máquina, como ir além de um único nó ou rack. Depende de você se isso é desejável ou não.

Concordo com tudo o que Jed tinha a dizer em sua resposta, mas queria acrescentar o seguinte. Tornei-me fã da maneira como Martin Berzins e seus colegas mostram o dimensionamento para a estrutura Uintah. Eles plotam a escala fraca e forte do código nos eixos log-log (usando o tempo de execução por etapa do método). Eu acho que mostra como o código é escalado muito bem (embora o desvio do dimensionamento perfeito seja um pouco difícil de determinar). Veja as páginas 7 e 8, figuras 7 e 8 deste documento *, por exemplo. Eles também fornecem uma tabela com os números correspondentes a cada figura de escala.

Uma vantagem disso é que, depois de fornecer os números, não há muito que um revisor possa dizer (ou pelo menos não muito que você não possa refutar).

* J. Luitjens, M. Berzins. “Melhorando o desempenho de Uintah: uma estrutura computacional de malha adaptativa em larga escala”, nas continuações do 24º Simpósio Internacional de Processamento Paralelo e Distribuído do IEEE (IPDPS10), Atlanta, GA, pp. 1--10. 2010. DOI: 10.1109 / IPDPS.2010.5470437