Вычислительный конвейер iOS Metal медленнее, чем реализация ЦП для задачи поиска

Я провел простой эксперимент, реализовав наивный алгоритм поиска символов, выполняющий поиск 1 000 000 строк по 50 символов в каждой (карта 50 mil char) как на ЦП, так и на графическом процессоре (с использованием вычислительного конвейера iOS8 Metal).

Реализация CPU использует простой цикл, реализация Metal предоставляет каждому ядру 1 строку для обработки (исходный код ниже).

К моему удивлению, реализация Metal в среднем в 2-3 раза медленнее, чем простой линейный процессор (если я использую 1 ядро) и в 3-4 раза медленнее, если я использую 2 ядра (каждое из них просматривает половину базы данных)! Я экспериментировал с разными потоками для каждой группы (16, 32, 64, 128, 512), но все же получил очень похожие результаты.

Айфон 6:

CPU 1 core:  approx 0.12 sec
CPU 2 cores: approx 0.075 sec
GPU: approx 0.35 sec (relEase mode, validation disabled)

Я вижу, что шейдер Metal тратит более 90% доступа к памяти (см. ниже).

Что можно сделать для его оптимизации?

Буду признателен за любую информацию, так как в Интернете не так много источников (кроме стандартных руководств по программированию Apple), предоставляющих подробную информацию о внутренних механизмах доступа к памяти и компромиссах, характерных для фреймворка Metal.

ДЕТАЛИ РЕАЛИЗАЦИИ МЕТАЛЛА:

Суть кода хоста: https://gist.github.com/lukaszmargielewski/0a3b16d4661dd7d7e00d

Код ядра (шейдера): https://gist.github.com/lukaszmargielewski/6b64d06d2d106d110126

Результаты профилирования захвата кадров GPU:

введите здесь описание изображения


person Lukasz    schedule 25.05.2015    source источник
comment
не вставляйте скриншоты кода. они в основном бесполезны... вырежьте и вставьте фактический код.   -  person Marc B    schedule 25.05.2015
comment
@MarcB Я заменил скриншот сутью github. Надеюсь, все в порядке (были большие проблемы с правильным форматированием этого фрагмента кода).   -  person Lukasz    schedule 26.05.2015
comment
Первое, что я бы попробовал, это переместить searchPhrase в память устройства. Apple говорит не использовать постоянное пространство для массивов. Дайте нам знать, если это что-то сделает.   -  person Jessy    schedule 26.05.2015
comment
@Jessy: переход на пространство устройства ничего не изменил. Более того: я потерял возможность установить буфер шейдера с помощью setBytes: (что, по утверждению Apple, быстрее, так как вам не нужно создавать объект ‹MTLBuffer›).   -  person Lukasz    schedule 26.05.2015
comment
Интересный. Я предполагаю, что соответствующая документация нуждается в капитальном ремонте. Вранье!   -  person Jessy    schedule 26.05.2015
comment
Вам когда-нибудь удавалось что-то улучшить?   -  person luna_    schedule 29.03.2016
comment
К сожалению нет.   -  person Lukasz    schedule 29.03.2016
comment
Привет, Kykasz, я пытаюсь сделать то же профилирование графического процессора для вычислительной задачи Metal. Однако мне не удалось добиться результатов профилирования графического процессора, показанных на рисунке выше. не могли бы вы дать мне несколько советов о том, как заставить его работать. Спасибо.   -  person Robert Wang    schedule 06.12.2016
comment
@RobertWang - в вопросе есть ссылки как на шейдер, так и на клиентский код. Не знаю, чем еще я могу помочь?   -  person Lukasz    schedule 07.12.2016


Ответы (2)


Шейдер графического процессора также перемещается по памяти вертикально, в то время как процессор перемещается горизонтально. Учтите, что адреса фактически затрагиваются более или менее одновременно каждым потоком, выполняющимся синхронно в вашем шейдере, когда вы читаете charTable. Графический процессор, вероятно, будет работать намного быстрее, если ваша матрица charTable транспонирована.

Кроме того, поскольку этот код выполняется в стиле SIMD, каждому потоку графического процессора, вероятно, придется выполнять цикл до полной длины поисковой фразы, в то время как центральный процессор сможет воспользоваться преимуществами ранних выходов. Код графического процессора на самом деле может работать немного быстрее, если вы удалите ранние выходы и просто сохраните код. Многое зависит от длины поисковой фразы и вероятности совпадения.

person Ian Ollmann    schedule 18.06.2016

Я тоже приму свои предположения, gpu не оптимизирован для if/else, он не предсказывает ветвления (вероятно, он выполняет оба), попробуйте переписать алгоритм более линейным способом без каких-либо условий или свести их к минимуму .

person workless    schedule 03.06.2015
comment
Инструменты профилирования ясно показывают (видно на прикрепленном снимке экрана), что это не является узким местом. Более 90% времени тратится на доступ к памяти. - person Lukasz; 09.06.2015