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

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

Cкорее демонстрация, как можно изначально т.с. "неоптимальный" код с минимальными изменениями оптимизировать. То, что EML (в данном случае) с этим прекрасно справляется, сомнений не вызывает. Вещь безусловно полезная и интересная.

4>>Это такая-же нелепость как сравнивать перемножение матриц с использованием SIMD и без него.

V>С чего ты решил, что SIMD не используется?

В статье не приведены ключи GCC под Intel, упоминается только:

Самое простое перемножение без eml. Компилируем пример с оптимизацией -O3

-O3 включает автовекторизацию в GCC, но для дефолтового профиля x86-64 заиспользует что-то по мелочи из SSE2 (дальше надо ключи указывать), и для данного примера все-равно ничего путного само по себе не получится. Следовательно сравнивать eml_Algebra_GEMM_64F с этой мурой не стоит, тем более удивляться разнице в 20+ раз.

V>MKL даёт прирост от наихудшей наивной реализации в ~10 раз.

Это имеет смысл обсуждать при наличии соответствующего теста.

V>В общем, у этой архитектуры есть характеристика — флопсы на такт.
V>Необходимо в реализации софта поднимать эту характеристику на максимум (т.е. загружать максимальное кол-во исполнительных блоков в каждом такте), чтобы Эльбрус показывал себя во всей красе.

V>Компилятор надо развивать нон-стоп, ес-но, на него вся надежда.

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

Я не просто чуть ранее упомянул Cell, ибо там тоже делалась ставка на компилятор и SDK, которые постоянно будут улучшать, тем самым постепенно раскрывая потенциал SPE (все уши тогда этим прожужали), в результате следующее поколение консолей PS4/X1 тупо получили AMD64 (причем с в 2 раза меньшей тактовой частотой).