Почему ARM NEON не быстрее обычного C++?

Конвейер NEON на Cortex-A8 выполняется по порядку и имеет ограниченное количество попаданий (без переименования), поэтому вы ограничены задержкой памяти (поскольку вы используете размер кэша больше, чем L1 / L2). Ваш код имеет непосредственную зависимость от значений, загруженных из памяти, поэтому он будет постоянно останавливаться в ожидании памяти. Это объясняет, почему код NEON немного (на крошечную величину) медленнее, чем не-NEON.

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

vld1.32   {q0}, [%[x]]!
vld1.32   {q1}, [%[y]]!
vld1.32   {q2}, [%[x]]!
vld1.32   {q3}, [%[y]]!
vadd.i32  q0 ,q0, q1
vadd.i32  q2 ,q2, q3
...

Там много неоновых регистров, так что вы можете развернуть его много. Целочисленный код будет страдать от той же проблемы, но в меньшей степени, потому что целочисленный код A8 имеет лучшее попадание при промахе, а не остановку. Узким местом будет пропускная способность/задержка памяти для тестов, настолько больших по сравнению с кешем L1/L2. Вы также можете запустить тест на меньших размерах (4 КБ..256 КБ), чтобы увидеть эффекты, когда данные полностью кэшируются в L1 и/или L2.

Хотя в этом случае вы ограничены задержкой для основной памяти, не совсем очевидно, что версия NEON будет медленнее, чем версия ASM.

Используя калькулятор циклов здесь:

http://pulsar.webshaker.net/ccc/result.php?lng=en

Ваш код должен занять 7 циклов, прежде чем штрафы за промахи кэша. Это медленнее, чем вы могли ожидать, потому что вы используете невыровненные загрузки и из-за задержки между добавлением и хранилищем.

Между тем, цикл, сгенерированный компилятором, занимает 6 тактов (в целом он тоже не очень хорошо спланирован или оптимизирован). Но он выполняет в четыре раза меньше работы.

Подсчет циклов из сценария может быть не идеальным, но я не вижу в нем ничего явно неправильного, поэтому я думаю, что они, по крайней мере, будут близки. Существует вероятность дополнительного цикла ветки, если вы максимизируете пропускную способность выборки (также если циклы не выровнены по 64-битным), но в этом случае есть много остановок, чтобы скрыть это.

Ответ не в том, что целое число на Cortex-A8 имеет больше возможностей скрыть задержку. На самом деле, обычно их меньше из-за поэтапного конвейера NEON и очереди задач. Конечно, это верно только для Cortex-A8 — на Cortex-A9 ситуация вполне может быть обратной (NEON отправляется по порядку и параллельно с целым числом, а целое имеет возможности не по порядку). Поскольку вы пометили этот Cortex-A8, я предполагаю, что вы используете его.

Это требует дальнейшего расследования. Вот несколько идей, почему это может происходить:

• Вы не указываете какое-либо выравнивание в своих массивах, и хотя я ожидаю, что new будет выравниваться по 8 байтам, он может не выравниваться по 16 байтам. Допустим, вы действительно получаете массивы, которые не выровнены по 16 байтам. Тогда вы будете разделяться между строками при доступе к кешу, что может иметь дополнительные штрафы (особенно при промахах)
• Промах кеша происходит сразу после сохранения; Я не верю, что Cortex-A8 имеет какое-либо устранение неоднозначности памяти, и поэтому должен предположить, что загрузка может быть из той же строки, что и хранилище, поэтому требуется, чтобы буфер записи истощался до того, как может произойти отсутствующая загрузка L2. Поскольку существует гораздо большее расстояние конвейера между загрузками NEON (которые инициируются в целочисленном конвейере) и хранилищами (инициируемыми в конце конвейера NEON), чем целочисленные, потенциально может быть более длительная задержка.
• Поскольку вы загружаете 16 байтов за доступ вместо 4 байтов, размер критического слова больше, и, следовательно, эффективная задержка для заполнения первой строки критического слова из основной памяти будет выше (от L2 до L1 предполагается, что быть на 128-битной шине, поэтому не должно быть такой же проблемы)

Вы спросили, чем хорош NEON в подобных случаях — на самом деле NEON особенно хорош для тех случаев, когда вы осуществляете потоковую передачу в/из памяти. Фишка в том, что нужно использовать предзагрузку, чтобы максимально скрыть латентность основной памяти. Предварительная загрузка добавит память в кеш L2 (не L1) раньше времени. Здесь у NEON есть большое преимущество перед целым числом, потому что он может скрыть большую задержку кэша L2 из-за его поэтапного конвейера и очереди задач, а также потому, что у него есть прямой путь к нему. Я ожидаю, что вы увидите эффективную задержку L2 до 0-6 циклов и меньше, если у вас меньше зависимостей и вы не исчерпываете очередь загрузки, в то время как на целочисленном вы можете застрять с хорошими ~ 16 циклами, которых вы не можете избежать (вероятно хотя зависит от Cortex-A8).

Поэтому я бы порекомендовал вам выровнять ваши массивы по размеру строки кэша (64 байта), развернуть циклы так, чтобы они выполняли как минимум одну строку кэша за раз, использовать выровненные загрузки/сохранения (поставьте :128 после адреса) и добавить инструкция pld, которая загружает несколько строк кэша. Что касается количества строк: начните с малого и продолжайте увеличивать его, пока не перестанете видеть какую-либо пользу.

Ваш код C++ также не оптимизирован.

#define ARR_SIZE_TEST ( 8 * 1024 * 1024 )

void cpp_tst_add( unsigned* x, unsigned* y )
{
    unsigned int i = ARR_SIZE_TEST;
    do
    {
        *x++ += *y++;
    } (while --i);
}

эта версия потребляет на 2 цикла/итерацию меньше.

Кроме того, ваши результаты тестов меня совершенно не удивляют.

32 бит:

Эта функция слишком проста для NEON. Недостаточно арифметических операций, оставляющих место для оптимизации.

Да, это так просто, что версии C++ и NEON почти каждый раз страдают от опасностей конвейера без каких-либо реальных шансов извлечь выгоду из возможностей двойной задачи.

В то время как версия NEON может выиграть от обработки 4 целых чисел одновременно, она также гораздо больше страдает от всех опасностей. Это все.

8 бит:

ARM ОЧЕНЬ медленно считывает каждый байт из памяти. Это означает, что пока NEON показывает те же характеристики, что и с 32-битной, ARM сильно отстает.

16 бит: то же самое здесь. За исключением того, что 16-битное чтение ARM не так уж плохо.

float : версия C++ будет скомпилирована в коды VFP. И на Coretex A8 нет полноценного VFP, но есть облегченный VFP, который не конвейеризирует ничего, что отстойно.

Дело не в том, что NEON ведет себя странно при обработке 32-битных файлов. Это просто ARM, который соответствует идеальному состоянию. Ваша функция очень не подходит для бенчмаркинга из-за ее простоты. Попробуйте что-то более сложное, например преобразование YUV-RGB:

К вашему сведению, моя полностью оптимизированная версия NEON работает примерно в 20 раз быстрее, чем моя полностью оптимизированная версия C, и в 8 раз быстрее, чем моя полностью оптимизированная версия сборки ARM. Надеюсь, это даст вам некоторое представление о том, насколько мощным может быть NEON.

И последнее, но не менее важное: инструкция ARM PLD — лучший друг NEON. При правильном размещении он даст не менее 40% прироста производительности.

Вы можете попробовать некоторые модификации для улучшения кода.

Если можете: - используйте третий буфер для хранения результатов. - попробуйте выровнять данные по 8 байт.

Код должен быть примерно таким (извините, я не знаю встроенного синтаксиса gcc)

.loop1:
 vld1.32   {q0}, [%[x]:128]!
 vld1.32   {q1}, [%[y]:128]!
 vadd.i32  q0 ,q0, q1
 vst1.32   {q0}, [%[z]:128]!
 subs     %[i], %[i], $1
bne      .loop1

Как говорит Exophase, у вас есть некоторая задержка конвейера. может быть, вы можете попробовать

vld1.32   {q0}, [%[x]:128]
vld1.32   {q1}, [%[y]:128]!

sub     %[i], %[i], $1

.loop1:
vadd.i32  q2 ,q0, q1

vld1.32   {q0}, [%[x]:128]
vld1.32   {q1}, [%[y]:128]!

vst1.32   {q2}, [%[z]:128]!
subs     %[i], %[i], $1
bne      .loop1

vadd.i32  q2 ,q0, q1
vst1.32   {q2}, [%[z]:128]!

Наконец, ясно, что вы насытите пропускную способность памяти

Можно попробовать добавить небольшой

PLD [%[x], 192]

в вашу петлю.

скажи нам, если это лучше ...

Разница в 8 мс НАСТОЛЬКО мала, и вы, вероятно, измеряете артефакты кэшей или конвейеров.

EDIT: вы пробовали сравнивать с чем-то подобным для таких типов, как float и short и т. д.? Я ожидаю, что компилятор еще лучше оптимизирует его и сократит разрыв. Также в вашем тесте вы сначала выполняете версию C++, а затем версию ASM, это может повлиять на производительность, поэтому я бы написал две разные программы, чтобы быть более справедливым.

for ( register int i = 0; i < ARR_SIZE_TEST/4; ++i )
{
    x[ i ] = x[ i ] + y[ i ];
    x[ i+1 ] = x[ i+1 ] + y[ i+1 ];
    x[ i+2 ] = x[ i+2 ] + y[ i+2 ];
    x[ i+3 ] = x[ i+3 ] + y[ i+3 ];
}

И последнее, в подписи вашей функции вы используете unsigned* вместо unsigned[]. Последнее предпочтительнее, потому что компилятор предполагает, что массивы не перекрываются, и ему разрешено переупорядочивать доступ. Попробуйте также использовать ключевое слово restrict для еще лучшей защиты от алиасинга.