Здравствуйте, Sinclair, Вы писали:

V>>По классике наилучший результат из наивных даёт схема kji.
V>>У авторов схема kij, которая, увы, является наихудшей.
S>Что такое "kji"?

Порядок вложения циклов обхода для приведённого мною алгоритма.


S>Это вы перечисляете переменные итерирования изнутри наружу? Тогда в статье приведён код для kji.

В статье другие идентификаторы, т.е. ijk не те, что я привёл.
Произведи подстановку имён переменных.


V>>А для Интел как ни крути — ничего уже особо не накрутишь.
S>Ну зачем же так сразу. На интеле гонялся наивный код с оптимизацией компилятором. Немножко покрутив его, можно ускорить эту реализацию примерно в 60 раз.

Но почему-то интелловская либа ускоряет только в 10 раз.
Наверно потому что ей недоступны "оптимизации", которые приведены в статье по твоей ссылке?
Ведь характер задачи заранее неизвестен.

Того монстра, что они породили, пусть погоняют на небольших матрицах и увидят, что вряд ли сделали лучше.
Как бы не хуже.
Ну и на матрицах небольшого размера тот код просто упадёт, т.к. некорректный.


4>>>при этом уступает в 20-ть раз тесту с использованием eml.
V>>При этом eml ускорила наихудший вариант вычислений в 100 раз.
S>Ну, он при этом был всё ещё хуже интела.

В сети есть несколько тестов MKL, поэтому в сравнении с EML Интел всё еще отстаёт примерно в два раза, при том что процы работают на разной тактовой.


V>>С чего ты решил, что SIMD не используется?
V>>Компилятор компиллирует с SIMD инструкциями в любом случае.
S>У компилятора довольно вялые возможности по автовекторизации.

Нормальные там возможности у обоих процов, если память правильно обходить.
Обрати внимание, что код под Эльбрус всё еще не использовал интистики и не использовал подкачку данных.


S>Особенно плохо компилятор справляется для матриц. Для векторов ещё куда ни шло — посмотрите на первую половину статьи.

Дык, вектора обходятся в памяти линейно, а при умножении матриц у одной из матриц нужно ходить поперёк памяти.


V>>Просто SIMD бывает очень разный.
V>>Просто надо правильно обходить память и раскручивать циклы, чтобы какие надо SIMD инструкции подставлялись.
S>А то. Вы же не думаете, что в EML написана наивная реализация без оптимизации обхода и раскрутки циклов.

Попахивает манипуляциями.
Ты привёл пример, где вовсю используются SIMD-интистики напрямую.
Т.е. чуть ли не на ассемблере код написан.

В отличе от, подсказки насчёт раскрутки циклов есть и для x86/x64 архитектуры.
Это не то же самое, что писать на асме.


V>>MKL даёт прирост от наихудшей наивной реализации в ~10 раз.
S>Думаю, должно быть не меньше, чем в хабрастатье.

Подумай еще.


V>>Компилятор надо развивать нон-стоп, ес-но, на него вся надежда.
S>Надо. Но для этого надо расширять штат развиваторов. В микрософте ничего не шло вперёд, пока не отдали в опенсорс.

Ты про дотнет?
С этим фруктом всё было понятно изначально.
И заметь — оно пошло вперёд, как только дотнет повернулся к нейтиву лицом, потому что заинтересовал более широкие слои населения.
Не те, коорые просто потребители технологий.

Но компилятор С++ не отдали, и этот компилятор от MS один из лучших в мире, особенно в деле LTO.
И не отдадут в обозримом будущем.

Компилятор Эльбруса тоже показывает себя неплохо именно в деле LTO.


V>>Но что здесь внушает оптимизм — при улучшении компилятора можно перепрогонять им софт и получать профит, не меняя ни исходники, ни железо.
S>Это да, тут вопросов нет.

Зато к коду по твоей ссылке эти вопросы есть.
И это то, чего хотелось бы избегать.