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, типа фиксированной точки посредине ?

[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 ?
Или от "умности" компилятора всё зависит, как он "зашедулит" ?