Накладные расходы на передачу памяти в и из Intel MIC

Question

Я наблюдаю странное поведение и хотел бы знать, связано ли это с Intel Xeon Phi или нет.

У меня есть небольшой пример кода, по сути, всем известное матричное умножение (три вложенных цикла for).Я переношу вычисления на Intel MIC с OpenMP 4.0. target прагма и отобразите три матрицы с помощью map(to:A,B) map(tofrom:C).

Теперь я наблюдаю, что для небольших матриц, например.1024х1024 передача памяти занимала очень много времени.По сравнению с собственной версией (тот же код, та же стратегия распараллеливания, только без разгрузки) версия с разгрузкой занимает примерно на 320 мс больше времени.Я выполнил предварительный запуск кода, чтобы удалить накладные расходы на инициализацию.

По сравнению с Nvidia Tesla K20, где тот же объем памяти копируется, не замечая этого, 320 мс — это очень плохо.

Существуют ли какие-либо настройки среды, которые могут улучшить скорость передачи данных из памяти?

Дополнительно вопрос:Я включил отчеты о разгрузке через переменную среды OFFLOAD_REPORT.Каковы различия между двумя результатами хронометража, показанными в отчете:

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

Чего не хватает этим 10 секундам во время MIC (перенос памяти?)

Ну и третий вопрос.Можно ли использовать закрепленную память с микрофонами Intel?Если да, то как?

Answer 1

Возможно, выделение памяти на MIC требует времени.Попробуйте разделить три источника накладных расходов, чтобы лучше понять, на что уходит время:

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

Поскольку вы сказали: «Я выполнил прогрев кода, чтобы удалить накладные расходы на инициализацию», я предполагаю, что вы запустили среду выполнения разгрузки, выгрузив фиктивный раздел.Я помню, что есть настройка для запуска «on_offload» (по умолчанию) или во время инициализации программы (OFFLOAD_INIT=on_start).В любом случае, в движке DMA есть и быстрый путь.Быстрый путь выбирается, когда буферы (подлежащие передаче) выравниваются по размеру страницы.Для приложения разгрузки вы можете просто установить переменную среды вместе с пороговым целым числомB|K|M|G|T, где M — это мегабайты (например, MIC_USE_2MB_BUFFERS=2M).Этот порог определяет размер буфера, который необходим перед использованием огромных страниц.Итак, вы получаете две вещи:огромные страницы и более быстрые переводы!Эта функция по-прежнему имеет смысл даже при наличии в сопроцессоре прозрачных огромных страниц (THP).

После простой попытки OFFLOAD_INIT=on_start и MIC_USE_2MB_BUFFERS=0 вы можете захотеть выровнять буферы на хозяин сторону соответственно (макс.из.векторная ширина и размер страницы ;-).Помните, что без дополнительных положений о разгрузке (LEO;но не уверен насчет OpenMP 4.0) выравнивание буфера хоста просто унаследованный по разделу разгрузки.Выравнивание до 2 МБ должно охватывать все (но вы можете сделать распределение намного разумнее, чтобы не тратить ресурсы на маленькие буферы).При этом у вас должно быть достаточно ключевых слов, чтобы при необходимости найти дополнительную информацию.