Реализация алгоритма на ускорителе с архитектурой MIC

Ускорители Xeon Phi с архитектурой MIC поддерживают три режима эксплуатации [8]:

• — Offload (режим разгрузки для центрального процессора, в этом режиме происходит автоматическая пересылка данных на ускоритель и обратно);
• — Native (режим запуска всей программы на ускорителе из его файловой системы, т.к. ускоритель представляет собой отдельную вычислительную систему под управлением своей операционной системы; в этом режиме требуется явная пересылка и данных, и программы на ускоритель в виде файлов);
• — Symmetric (поддержка одновременных вычислений на MIC и CPU, сложен в реализации).

Последний режим редко используется из-за своей сложности. Первый режим для ускорителей является преобладающим, но для следующего поколения устройств архитектуры MIC основным будет являться режим Native. В рамках данной работы использовались оба режима, при этом Offload показывал лучшие результаты из-за меньших накладных расходов на передачу данных на ускоритель. Поскольку первый этап алгоритма для первого прецедента (формирование шинглов и контрольных сумм для них) в данной реализации плохо поддерживает многопоточность, имело смысл реализовывать на 224-поточном MIC (с 57 ядрами) только сравнение контрольных сумм. Также необходимо отметить, что максимум производительности ускорителя можно получить только, если использовать его векторные 512-битные регистры. В данном случае есть возможность использовать 16-элементые векторы, так как сравниваются 32-битные коды. С помощью автоматической векторизации компилятором этого добиться не удалось, поэтому были использованы интринсики (С-обертки для векторных инструкций ускорителя) [9] для явного управления векторизацией :

#pragma omp parallel for.

for (int i = 0; i < sizeA; i++) {.

int A[16] __attribute__((aligned (64)));

for (int j = 0; j < 16; j++) { A[j] = bufA[i]; }.

__m512i first = _mm512_load_epi32(A);

for (int j = 0; j < sizeB; j += 16) {.

__m512i second = _mm512_load_epi32(&bufB[j]);

__mmask16 found = _mm512_cmpeq_epi32_mask (first,.

second);

if (found) { arrMatches[i]++; break; }.

}.

}.

В результате тестирования данного решения (расчет контрольных сумм на двух CPU Xeon E5 и сравнение их на Xeon Phi в режиме offload) при сравнении больших документов (третья пара) время вычислений составило 1.08 секунды, что примерно вдвое хуже, чем время сравнения только на двух CPU Xeon E5. Таким образом, применение MIC для сравнения документов размером до 100 000 слов нецелесообразно. Для реализации быстрого сравнения двух произвольных документов с расчетом контрольных сумм шинглов по CRC32 или другим алгоритмам можно рассмотреть применение других типов ускорителей, например, GPU или ПЛИС [10].

Был отдельно рассмотрен только этап сравнения хэшей на MIC, как наиболее удачный с точки зрения многопоточной реализации. Использовался режим offload. Тестирование проводилось на сгенерированных таблицах хэшей размером до 1000 000 значений. Результаты представлены в таблице № 3.

Время многопоточных вычислений для CPU несколько отличается от результатов из таблицы № 2, поскольку использованы другие входные данные, в частности, для теста со 100 000 хэшей было много совпадений. Из таблицы 3 видно, что при увеличении объема сравниваемых таблиц MIC ускоритель начинает опережать CPU. На практике при сравнении двух файлов такой объем таблицы хэшей никогда не будет встречаться, он соответствует документам в несколько тысяч страниц. В то же время полученный результат позволяет предположить, что для второго варианта использования (сравнение документа с большим количеством документов, для которых заранее рассчитаны контрольные суммы) применение MIC также может быть эффективным.

Таблица № 3 Время сравнения двух таблиц контрольных сумм на серверной платформе Xeon E5 v3 с использованием и без использования MIC — ускорителя.

При решении задачи сравнения заданного файла со списком уже загруженных в систему файлов применение MIC должно позволить получить потенциально ускорение пропорционально количеству имеющихся в системе ускорителей. В этой задаче нет необходимости вычислять хэш-функции шинглов для ранее загруженных файлов и все вычисления сводятся к сравнению значений хэшей шинглов заданного файла с ранее загруженными значениями хэшей файлов из списка, распределенными между разными ускорителями. Был разработан прототип для сравнения 10 000 хэшей с 16 000 хешами в 100, 200 и 300 файлах на двух CPU и на одном MIC ускорителе в режиме Native (данные для обработки предварительно должны быть загружены в файловую систему MIC). Результаты тестирования прототипа показаны в таблице № 4.

Таблица № 4 Время сравнения заданной таблицы контрольных сумм (10 000 значений) с большим числом таблиц контрольных сумм на двух CPU Xeon E5 v3 и на MIC — ускорителе.

При количестве файлов от 200 и выше время сравнения на одном ускорителе MIC примерно в два раза больше, чем на двух CPU. Объем файла с хэшами при этом не превышает 30 Мб, такой файл можно спокойно разместить в файловой системе ускорителя, объем локальной памяти которого 8Гб. Полученное соотношение производительности MIC ускорителя к CPU Xeon E5 v3 (2 к 1) для данной задачи близко к соотношению величин их пиковой теоретической производительности (1 к 0.7) для операций с плавающей запятой. Это стало возможным благодаря использованию 512-битных регистров MIC с одновременной обработкой 16 целочисленных элементов векторов.