SIMD-расширение NEON в ARM-архитектуре, Где кто узнавал тонкости по этому DSP-расширению современных мобил ? Опции

[WitFed]

Или в DSP-подфоруме этот топик лучше будет выглядеть ? Или в "Начинающих" ?
Предлагаю тут делиться "нарытым" и конкретными ссылками по сабжу. Ниже мои текущие позиции.
Кое-как-то с С-колокольни NEON описан в "Appendix G. Using NEON Support" из DUI0491C_arm_compiler_reference.pdf с сайта ARM.
Для точного понимания смысла интринсиков нужно также ознакомиться с "ARM Compiler toolchain Assembler Reference" (DUI0489G_arm_assembler_reference.pdf), "Chapter 4. NEON and VFP Programming" или чем-то подобным, информирующим более подробно, ибо там содержится семантика исполнения каждой инструкции процессора, зачастую вообще не отражённая в DUI0491C при нетривиальных операциях, -- хотя и не так полно, как в TI-руководствах на их "самые крутые DSP Вселенной", часто нужно для уточнений проводить опыты на железе, если хоть как-то врубился
Есть ещё документ DDI0409I_cortex_a9_neon_mpe_r4p1_trm.pdf: "Cortex™-A9 NEON™ Media Processing Engine. Revision: r4p1. Technical Reference Manual", там тоже много интересного, в том числе намёки, что время исполнения каждой команды зачастую не 1 такт, а в регистр её результат попадёт ещё позже...
В DDI0406C_b_arm_architecture_reference_manual.pdf тоже много информации, но мне в тамошних 2734 страницах просто страшно !
Кто что ещё может добавить существенное ? На русском выходило что-то по NEON-у ?
Вообще, система команд NEON достаточно широкая, схожа на DSP-работу у TI, только не по 8 операций в одном такте, т.е. скорость обработки будет на порядок меньше при тех же частотах, а "печкообразность" кристалла послабей
Если следующая команда будет ждать выгрузки результата предыдущей 5 тактов, да ещё ОЗУ подтормаживать при 128-битных обращениях туда-сюда, то и ещё "[пол]порядка" тормозов...
Кто какие на практике получал результаты ? Возможно задействовать пайплайн, чтобы пропадало не более 10 % на "совсем уж жуткие" кэш-промахи ?
Интересно узнать про 16-битный плавающий "полу-тип" __fp16, который вроде бы есть (на знак 1 бит, на мантиссу 10, на порядок -- 5 бит), а работы с ним нет, кроме преобразования в __fp32 и обратно.
Также непонятны типы типа poly8x8_t -- зачем они ?
Не нахожу команды типа Тексусового интринсика _dotpsu(), который умножал 4 байта на другие 4 байта и все 4 16-разрядных произведения складывал до кучи. Как у этого NEON-а такое можно вытворить ? Из памяти читать накопленные по раздельности и выгруженные аккумуляторы и плюсовать в конце -- как-то некошерно, одна "в себе" _dotpsu() тоже бывает полезна. Команда очень лезущая во все проекты с фильтрацией.
По интринсикам со словом "Reciprocal" тоже непонятки -- с float32x2_t они работают логично, хотя и не сильно точно, а с uint32x2_t выход вообще левый, значения 1 и 2 дают FFFFFFFF после вызова "uint32x2_t vrsqrte_u32(uint32x2_t a);". В каком формате должен быть uint32, типа фиксированной точки посредине ?

[meloden2]

Можете бросать чёткие вопросы мылом, не всегда на тех.поддержки иногда отвечвают.

[WitFed]

Думал я думал несколько дней, что может означать Ваша строка... Разве на 40 складах может лежать что-то по этой теме обучающее ?
Сам попробовал простой пример поставляемых Альтерой со своей версией DS-5 компиляторах: arm-altera-eabi-* на основе gcc и "фирменного" armcc.
Функция:

Код

#include <arm_neon.h>
#include <alloca.h>
#include <time.h>
typedef uint8_t uc;
void test_neon(const int M, const uc *in0, const uc *in1, uc *ou) {
  for (int i = 0; i < M; i += 16, ou += 16) {
    uint8x16_t v0 = vld1q_u8(in0 + i), v1 = vld1q_u8(in1 + i);
    uint8x16_t v2 = vaddq_u8(v0, v1);
    vst1q_u8(ou, v2);
  }
}

вызывается так:

Код

{ int i, t0, t1; enum {M = 800};
  uc *in0 = (uc*)alloca(M), *in1 = (uc*)alloca(M), *ou = (uc*)alloca(M);
  printf("bT\n"); t0 = time(0);
  for (i = 0; i < 1000*1000; i++)
    test_neon(M, in0, in1, ou);
  t1 = time(0); printf("eT %i\n", t1 - t0);
}

У toolchain-а arm-altera-eabi-* время где-то 21 с, у armcc -- 15, причём первый глотает ключ "-ftree-vectorize" без последствий, второй -- "--vectorize", и от цифры в "-O*" мало что зависит.
Во втором случае самый интересующий внутренний цикл в test_neon() занимает 7 команд, в том числе те 4, готоры я точно ожидал видеть -- две загрузки, одно сохранение, ну и переход. Ещё 3 арифметических -- продвижения адресов. счётчика цикла, а 800 -- это примерная частота работы процессора в МГц, общее время работы хотелось бы видеть равным размеру в командах самого внутреннего цикла.
Вроде процессор такие инкременты адресов должен уметь тянуть в хитрых режимах адресации сразу при операциях чтений-записи -- какой-то компилятор или ключ в текущих может родить этот цикл в 4 команды и весь пример работающим за 4 секунды, чтобы каждая команда выполнялась за такт в pipeline ?
Или учетверить тело ради этого придётся ? Или вообще ASM учить очередной ? Или просто кэши не допустят 1 команду за такт в этой архитектуре ?
Какой документ у ARM описывает техники оптимизации циклов ?

[WitFed]

Вчера постил предыдущую мессагу с другого компа -- так она выглядит "свежей" !
Кого-то из Модераторов форума можно переквалифицировать в WEB-Программисты ?

Быстрей 14 с не выходит разогнать тест, хотя я изменил чтение и запись не через индексную переменную i, а прямым инкрементом адреса после операции: компилятор послушался, команд лишних в цикле не ставит. Тексусы были более "прозорливыми".
И вся разница между 14 и 21 секундами у обоих компиляторов заключается в памяти, из которой стартует программа -- ончип это или DDR.
Для контраста сделал то же самое сложение через байтовые операции, типа "while (M--) *ou++ = *in0++ + *in1++" -- работает 140 c после armcc, так что толк от NEON-а очевиден.
А arm-altera-eabi-* сделал из этого цикла 14 с за счёт "прошаривания" NEON-а, причём без моих намёков !
Но коду породилось очень много -- видимо, там перебираются все варианты входных сочетаний адресов/счётчиков.

Так архитектура ARM в принципе не может pipelin-ить исполнение нескольких команд в параллель, чтобы каждый такт стартовала следующая, а результаты предыдущих выгружались бы "естественным" путём в регистры через 5-10 тактов и использовались бы остальными обработками, сдвинутыми попозже, как у Тексусных DSP ?
Или от "умности" компилятора всё зависит, как он "зашедулит" ?