Intel Xeon Phi — запуск нескольких однопоточных исполняемых файлов

Я пытаюсь выяснить, могу ли я использовать сопроцессор Intel Xeon Phi для «распараллеливания» следующей проблемы:

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

Например:

FILES=/path/to/*
for f in $FILES
do
    # take action on each file
    ./executable $f outFileCorrespondingTo_f
done

Инструменты не предназначены для многопоточного выполнения или циклического просмотра файлов, и мы пока не хотим ничего менять в их коде. Они написаны на C с некоторыми внешними библиотеками.

Мои вопросы:

  1. Можно ли запустить этот вид «зацикливания сценариев» на собственной ОС Xeon Phi таким образом, чтобы он распараллелил вызовы исполняемого файла, чтобы они выполнялись одновременно на всех его ядрах? Достаточно ли для этого «общего назначения»?

  2. Сами файлы довольно маленькие, поэтому 8 ГБ памяти будет более чем достаточно для хранения данных во время выполнения, но не для хранения всего вывода на устройстве, поэтому мне нужно будет выводить на хост. Итак, мой второй вопрос: возможен ли такой обмен памятью «извне»?

т. е. не закодировано в инструменте, но управляется хост-ОС и устройством для каждого выполнения исполняемого файла.

  1. Если это возможно, может ли это как-то повысить производительность, или узкие места в распределении памяти и потоков будут слишком интенсивными? В основном каждое выполнение занимает несколько секунд, в зависимости от длины входного файла, но я вполне уверен, что это на несколько порядков больше, чем то, сколько потребуется для передачи файла.

c++ concurrency xeon-phi
person OntZ    schedule 01.10.2015    source источник
comment
Что касается производительности, то одновременное выполнение нескольких процессов может привести к большому количеству конфликтов / перегрузок кэша L2. Хорошее использование L2 обычно очень важно для получения хорошей производительности на KNC. Это зависит от рабочей нагрузки, поэтому YMMV.   -  person amckinley    schedule 01.10.2015

Ответы (2)


arrow_upward
0
arrow_downward

Сопроцессоры Xeon phi работают под управлением очень многофункциональной версии операционной системы Linux, поэтому большая часть того, к чему вы привыкли в Linux, скорее всего, будет работать и на Xeon Phi.

Теперь, что касается вашей конкретной проблемы, я думаю, что GNU Parallel должен просто позволить вам делать то, что вы хотите на одном дыхании. Просто вам нужно будет смонтировать файловую систему на карте, чтобы иметь прямой доступ к файлам, но это просто стандартная вещь для узла Xeon Phi. И имейте в виду, что это создаст некоторый трафик на канале PCIe между хостом и сопроцессором для передачи файлов.

Что касается производительности, тут сложно сказать: более низкая однопоточная производительность ядер Xeon Phi вместе со временем передачи определенно указывают на большой успех в этой области, но уровень параллелизма, который вы можете извлечь из устройства, вполне может преодолеть это. , в зависимости от того, насколько интенсивна ваша рабочая нагрузка. Лучший ответ для вас, чтобы попробовать...

person Gilles    schedule 01.10.2015
comment
В том-то и дело, что в настоящее время у нас его нет, и я пытаюсь выяснить, будут ли вложения того стоить. Спасибо! - person OntZ; 01.10.2015

arrow_upward
0
arrow_downward

Это дополнение к ответу, данному Жилем.

Да, Xeon Phi должен уметь делать то, что вы хотите, на базовом операционном уровне.

Тем не менее, я думаю, что это неправильная платформа для ваших целей по нескольким причинам.

  • Каждое ядро ​​Xeon Phi является ядром Pentium. Хотя он улучшен (4 потока на ядро, 512-битный векторный движок и т. д.), он все еще остается Pentium. Это означает, что он запускает скалярный код как Pentium. Ваша задача звучит как целая куча последовательных процессов, работающих параллельно. Таким образом, каждый процесс будет работать так, как если бы он работал на Pentium.
  • Чтобы достичь выдающейся производительности, вам нужен код, который хорошо распараллеливается (читай это как OpenMP, облегченные потоки и объединение потоков), а также векторизуется (использует преимущества 512-битного векторного механизма). Без обоих этих улучшений вы работаете на Pentium, а не на многих Pentium.
  • Перемещение данных по шине PCIe происходит медленно. Если вы передаете много файлов, это может быть еще медленнее, хотя вы можете немного уменьшить конкуренцию, скрыв задержку (в зависимости от вашего приложения). Если вы загружаете шину PCIe с 244 запросами на чтение файлов при запуске, это довольно много конфликтов. Даже в стационарных условиях кажется, что вы будете читать более 20 файлов в любой момент времени (и я подозреваю, что даже больше, учитывая, что мы выполняем скалярный код как Pentium).

Теперь архитектура KNL может больше подходить для ваших нужд, но она еще не вышла.

Если вы все еще считаете, что Xeon Phi подходит для ваших целей, вы можете обратиться на форум Xeon Phi Intel. эксперты. Если ваше приложение является закрытым или конфиденциальным, вы можете обратиться к экспертам Intel в личном сообщении.

person Taylor Kidd    schedule 02.10.2015
comment
Если бы я мог получить 5-10-кратное ускорение, работая на 60 пентиумах, а не на одном xeon, это все равно было бы огромным улучшением. Параллелизм самих инструментов с openMP не вариант, учитывая наши временные рамки. - person OntZ; 05.10.2015