Qual é a estrutura subjacente do desempenho do código científico?

Considere dois computadores com configurações diferentes de hardware e software. Ao executar exatamente o mesmo código serial de Navier-Stokes em cada plataforma, leva um tempo x e y para executar uma iteração para o computador 1 e 2, respectivamente. Nesse caso, , é a diferença de tempo de iteração entre o computador 1 e o computador 2. $\Delta = x-y$

Qual poderia ser o impacto na magnitude de ? Um candidato óbvio é a CPU, minha pergunta principal é se existem outros fatores que podem estar afetando na mesma ordem que a diferença de hardware entre as CPUs? $\Delta$ $\Delta$

performance iterative-method navier-stokes Oscilação isópcica
fonte

Claro que o seu

é apenas uma amostra. Você também deve investigar como

depende do tamanho e da estrutura do problema. Em segundo lugar gostaria de sugerir para o perfil do código, tentando dividir

na soma das diferentes contribuições, e analisar o desempenho de diferentes partes do código em relação ao hw e configurações sw.

Δ

$\Delta$

Δ

$\Delta$

x

$x$

y

$y$

27513 Stefano M

LINHAS CACHE FALTAS . Essa é a primeira coisa a considerar. A memória é o fator de gargalo para muitos algoritmos.

Deer Hunter

Respostas:

Esta lista não está nem de longe completa, mas espero que o tamanho dela dê uma dica sobre a escala de possíveis fatores. Suponho que você esteja compilando o código da fonte na sua plataforma de escolha.

Programas

Desempenho da biblioteca padrão
Lin. Alg. Desempenho da biblioteca (se o software vincular a bibliotecas externas)
Escolha do compilador
Otimização do compilador
Sinalizadores do compilador
Processos em segundo plano (podem variar significativamente se os sistemas operacionais forem diferentes)

Hardware

CPU

Velocidade do relógio
Arquitetura (a mesma instrução pode levar diferentes números de ciclos em diferentes arquiteturas)
Tamanhos de cache
Latência do cache
Capacidade SIMD (instrução única, vários dados)

Memória

Número de canais
Rapidez

HDD

Velocidade de leitura / gravação (principalmente importante apenas para gravar resultados, isso depende da frequência com que você está gravando a saída no arquivo para um solucionador NS, mas pode ser importante para outros programas que realizam tarefas como processamento de imagem)

Isso tudo ignora os pequenos truques e os recursos que diferentes fabricantes incluem para dar uma vantagem aos chips no mercado. O grande problema é que muitas bibliotecas lineares de álgebra esparsas estão ligadas à memória. Fazer uma multiplicação de matriz esparsa envolve muitos dados se movendo sem muitos flops reais.

Godric Seer
fonte

Eu acrescentaria à CPU o número de núcleos e seus recursos SIMD.

Pedro Pedro

@ Pedro Deixei os núcleos desligados desde que a pergunta dizia o solucionador serial, mas adicionarei o SIMD. Obrigado.

Godric Seer

@GodricSeer Compilei em uma máquina e depois a executei. Então, usando o mesmo executável compilado, eu o executei na segunda máquina. Pela sua explicação, parece que seria melhor recompilar da fonte no segundo computador. É esse o caso?

Oscilação Isopycnal

@IsopycnalOscillation Ao compilar em / para uma máquina específica, você pode usar a opção gcc / gfortran -march=native, ou a opção icc / ifort, -xHOSTque aplicará otimizações específicas à arquitetura subjacente.

Pedro Pedro

Um ponto chave aqui é que o desempenho do computador não é uma quantidade unidimensional. O saldo relativo de todos os fatores que Godric listou acima pode variar tremendamente, mesmo para computadores com chips de processador do mesmo fabricante (por exemplo, Intel.) Como resultado, diferentes benchmarks podem mostrar taxas de desempenho muito diferentes para dois processadores. Por uma questão prática, a maioria das máquinas modernas carece seriamente de largura de banda de memória para suportar cargas de trabalho de computação científica e esse é geralmente o gargalo.

Brian Borchers

$x/y$ $x-y$

Segundo, sua pergunta exclui especificamente diferenças de software. Na minha experiência, as recompensas de desempenho por ajustes cuidadosos podem ser grandes fatores; portanto, enquanto você está considerando problemas de hardware, não se esqueça dos problemas de software. Afinal, o hardware pode executar apenas as instruções que você der e, se você der menos, terminará mais cedo.

Não para expandir muito isso, mas para qualquer problema, existe uma infinidade contável de programas que o resolverão. Entre esses, alguns levam menos tempo que todos os outros, e esse é um limite inferior. Não assuma que nenhum programa esteja no limite inferior ou mesmo próximo a ele se não tiver sido cuidadosamente ajustado.

Este link explica em detalhes o método não ortodoxo que eu uso.

Mike Dunlavey
fonte