Transferência de memória sobrecarga para e a partir de um Intel MIC

Question

Eu estou observando um comportamento estranho e gostaria de saber se é Intel Xeon Phi, relacionados ou não.

Eu tenho um pouco de código de exemplo, basicamente, a multiplicação de matrizes, todo mundo sabe (três loops for aninhados).Eu descarregar o cálculo para um Intel MIC com OpenMP 4.0 target pragma e mapear as três matrizes com map(to:A,B) map(tofrom:C).

Agora, o que eu estou observando é que para pequenas matrizes e.g.1024x1024 a transferência de memória tomou extremamente longo.Comparado com a versão nativa (mesmo código, mesmo parallelisation estratégia, apenas não o descarregamento) descarregamento da versão consome cerca de 320ms mais tempo.Eu fiz um warm-up de execução do código para remover a inicialização de sobrecarga.

Comparado com uma Nvidia Tesla K20, onde a mesma quantidade de memória é copiado sem perceber este 320ms são muito ruins.

Existem algumas configurações de ambiente que pode melhorar a memória, a velocidade de transferência?

Além disso, um pergunta:Eu ativado descarregamento de relatórios através do OFFLOAD_REPORT variável de ambiente.Quais são as diferenças entre os dois resultados tempo mostrado no relatório:

[Offload] [HOST]  [Tag 5] [CPU Time]        26.995279(seconds)
[Offload] [MIC 0] [Tag 5] [CPU->MIC Data]   3221225480 (bytes)
[Offload] [MIC 0] [Tag 5] [MIC Time]        16.859548(seconds)
[Offload] [MIC 0] [Tag 5] [MIC->CPU Data]   1073741824 (bytes)

Quais são os 10 segundos faltando no MIC (Tempo de transferência de memória?)

Bem, uma terceira questão.É possível utilizados preso memória com Intel MICs?Se sim, como?

Answer 1

É, possivelmente, a alocação de memória no MIC, que é a tomada de tempo.Tentar separar os três fontes de sobrecarga para entender melhor onde o tempo passa:

// Device initialization
#pragma offload_transfer target(mic)
...
// Memory allocation and first data transfer
// This is expected to have overhead proportional to the amount of memory allocated
// Doing at least one transfer will speed up subsequent transfers
#pragma offload_transfer target(mic) in(p[0:SIZE] : alloc_if(1) free_if(0))

...
// This transfer should be faster
// For large sizes, approaching 6 GiB/s
#pragma offload_transfer target(mic) in(p[0:SIZE] : alloc_if(0) free_if(0))

Answer 2

Desde que você disse "eu fiz um warm-up de execução do código para remover a inicialização sobrecarga", eu suponho que você começou o descarregamento de tempo de execução pelo descarregamento de um manequim seção.Eu lembro que há um ajuste para iniciá-lo "on_offload" (padrão) ou no programa de inicialização de tempo (OFFLOAD_INIT=on_start).De qualquer maneira, lá também é um caminho rápido no mecanismo de DMA.O caminho mais rápido é obtido quando os buffers (a ser transferido) estão alinhadas com o tamanho da página.Para um descarregamento do aplicativo, você pode simplesmente definir uma variável de ambiente, juntamente com um limite de integerB|K|M|G|T, onde M é Megabytes (por exemplo, MIC_USE_2MB_BUFFERS=2M).Este limite define o tamanho do buffer que é necessário, antes de enorme páginas são usadas.De modo a obter duas coisas:enorme páginas e transferências mais rápidas!Este recurso ainda é significativa, mesmo com transparente enorme páginas (THP) a ser introduzido no co-processador matemático.

Depois de simplesmente tentar OFFLOAD_INIT=on_start e MIC_USE_2MB_BUFFERS=0, você pode querer alinhar os buffers do host do lado de acordo (max.de.vetor de largura e tamanho de página ;-).Lembre-se, sem adicionais de descarregamento de cláusulas (LEO;mas não tem a certeza sobre o OpenMP 4.0) o alinhamento do host do buffer é simplesmente herdadas por um descarregamento de seção.Alinhando-2MB deve cobrir tudo (mas você pode fazer a sua alocação muito mais inteligente para evitar o desperdício de recursos para pequenos buffers).Com isso você deve ter uma quantidade suficiente de palavras-chave para encontrar mais fundo, se você precisa.