Transferencia de memoria sobrecargada hacia y desde un MIC Intel

Question

Observo un comportamiento extraño y me gustaría saber si está relacionado con Intel Xeon Phi o no.

Tengo un pequeño código de ejemplo básicamente la multiplicación de matrices que todos conocen (tres bucles for anidados).Descargo el cálculo a un Intel MIC con OpenMP 4.0 target pragma y mapear las tres matrices con map(to:A,B) map(tofrom:C).

Ahora, lo que estoy observando es que para matrices pequeñas, p.1024x1024, la transferencia de memoria tomó mucho tiempo.En comparación con la versión nativa (mismo código, misma estrategia de paralelización, pero sin descarga), la versión de descarga consume aproximadamente 320 ms de tiempo.Hice una ejecución de calentamiento del código para eliminar la sobrecarga de inicialización.

En comparación con una Nvidia Tesla K20 donde se copia la misma cantidad de memoria sin darnos cuenta, estos 320 ms son muy malos.

¿Existen algunas configuraciones ambientales que puedan mejorar la velocidad de transferencia de memoria?

Una pregunta adicional:Habilité los informes de descarga a través de la variable de entorno OFFLOAD_REPORT.¿Cuáles son las diferencias entre los dos resultados de tiempo que se muestran en el informe?

[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)

¿Cuáles son esos 10 segundos que faltan en MIC Time (transferencia de memoria?)

Bueno una tercera pregunta.¿Es posible utilizar memoria fijada con micrófonos Intel?Si es así, ¿cómo?

Answer 1

Posiblemente sea la asignación de memoria en el MIC la que esté tardando.Intente separar las tres fuentes de gastos generales para comprender mejor a dónde va el tiempo:

// 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

Como dijiste "Hice una ejecución de calentamiento del código para eliminar la sobrecarga de inicialización", supongo que iniciaste el tiempo de ejecución de descarga descargando una sección ficticia.Recuerdo que hay un ajuste para iniciarlo "on_offload" (predeterminado) o en el momento de la inicialización del programa (OFFLOAD_INIT=on_start).De todos modos, también existe una vía rápida en el motor DMA.La ruta rápida se toma cuando los buffers (que se van a transferir) están alineados con el tamaño de la página.Para una aplicación de descarga, simplemente puede configurar una variable de entorno junto con un umbral enteroB|K|M|G|T donde M es Megabytes (por ejemplo, MIC_USE_2MB_BUFFERS=2M).Este umbral define el tamaño del búfer que se necesita antes de que se utilicen páginas enormes.Entonces obtienes dos cosas:¡páginas enormes y transferencias más rápidas!Esta característica sigue siendo significativa incluso con la introducción de páginas grandes transparentes (THP) en el coprocesador.

Después de simplemente probar OFFLOAD_INIT=on_start y MIC_USE_2MB_BUFFERS=0, es posible que desee alinear los buffers en el anfitrión lado correspondiente (máx.de.ancho de vector y tamaño de página ;-).Recuerde, sin cláusulas de descarga adicionales (LEO;pero no estoy seguro acerca de OpenMP 4.0) la alineación del búfer del host es simplemente heredado por una sección de descarga.La alineación a 2 MB debería cubrir todo (pero puede hacer que su asignación sea mucho más inteligente para evitar desperdiciar recursos en buffers pequeños).Con eso deberías tener suficientes palabras clave para encontrar más antecedentes si lo necesitas.