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

V>Этот тест показывает, что авторы статьи не потрудились поискать наилучшую стратегию обхода памяти.
Они показали, что наивная ручная оптимизация позволяет разогнать Эльбрус до примерно 2х от того, что даёт интел для неоптимизированного кода.

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

V>Далее, обрати внимание на +=.
V>Надо заводить локальную переменную и накапливать результат в ней, а затем писать лишь однажды.
Ровно это делается в статье.

V>Ты дочитай до конца, автор там поиграл еще и получил на вручную написанной реализации результат примерно вдвое быстрее, чем с помощью EML, т.е. в 200 раз быстрее от исходного варианта.
Не вижу, где там вдвое быстрее, чем на EML.
Вижу, что вначале он пишет, что "всё это уже применено в EML".
После второго этапа оптимизации он получил времена

real 167.63
user 167.52
sys    0.01

Это всё ещё примерно в 10 раз хуже, чем EML.

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

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

V>С чего ты решил, что SIMD не используется?
V>Компилятор компиллирует с SIMD инструкциями в любом случае.
У компилятора довольно вялые возможности по автовекторизации. И это видно что для случая x86, что для e8c.
V>Особенно хорошо для матриц.
Особенно плохо компилятор справляется для матриц. Для векторов ещё куда ни шло — посмотрите на первую половину статьи.
V>Просто SIMD бывает очень разный.
V>Просто надо правильно обходить память и раскручивать циклы, чтобы какие надо SIMD инструкции подставлялись.
А то. Вы же не думаете, что в EML написана наивная реализация без оптимизации обхода и раскрутки циклов.

4>>В данном случае было бы интересно сравнить результаты с использованием упомянутого в статье MKL от Intel.

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

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