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

V>Порядок вложения циклов обхода для приведённого мною алгоритма.
V>В статье другие идентификаторы, т.е. ijk не те, что я привёл.
В статье — ровно те же i, j, k.
V>Произведи подстановку имён переменных.
Поясните. Лучше всего — приведите пример "наивного" кода, который является наиболее оптимальным.

V>Но почему-то интелловская либа ускоряет только в 10 раз.
У вас есть ссылка, подтверждающая эту оценку?
V>Наверно потому что ей недоступны "оптимизации", которые приведены в статье по твоей ссылке?
Конечно же доступны.
V>Ведь характер задачи заранее неизвестен.
Известен: умножение матриц.
V>Того монстра, что они породили, пусть погоняют на небольших матрицах и увидят, что вряд ли сделали лучше.
V>Как бы не хуже.
Очень вряд ли там будет хуже. Дружелюбность к кэшу очень редко ухудшает работу в случае, когда выигрыша за счёт кэша нет.
V>Ну и на матрицах небольшого размера тот код просто упадёт, т.к. некорректный.
Конкретно тот код зависит только от кратности размеров. Для того, чтобы он работал для произвольных матриц, там надо к каждому циклу прикрутить "голову" и "хвост" для выравнивания данных. Объём кода будет больше, но быстродействие будет сильно отличаться только для вырожденных случаев.
А эти случаи, в свою очередь, нетрудно отловить, и обработать более простым алгоритмом.
Впрочем, это всё несущественные подробности. Только что вы писали, что под интел как ни крути — а больше не накрутишь. Когда оказалось, что накрутишь — вы начинаете вилять.

V>В сети есть несколько тестов MKL, поэтому в сравнении с EML Интел всё еще отстаёт примерно в два раза, при том что процы работают на разной тактовой.
У есть ссылка, подтверждающая эту оценку? Я не нашёл ни одного теста, где бы совместно гонялись MKL и EML.

V>Нормальные там возможности у обоих процов, если память правильно обходить.

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

V>Т.е. чуть ли не на ассемблере код написан.
И именно это и есть продуктивный способ писать эффективный код в 2022 году.
V>В отличе от, подсказки насчёт раскрутки циклов есть и для x86/x64 архитектуры.
V>Это не то же самое, что писать на асме.
Подсказки насчёт раскрутки циклов мало что дают. В статье про эльбрус автор не пользовался интринсиками, зато пользовался знанием таймингов команд. Это ещё хуже — то есть вместо того, чтобы напрямую написать компилятору, какой код ты от него хочешь, приходится шаманить при помощи подбора параметров. Цитирую уместный фрагмент:

При оптимизации гнезда циклов важно не упираться в ресурсы аппаратуры: количество вещественных операций, которое мы можем выполнять в одной ШК, количество доступных регистров. Поэтому для архитектуры e8c было бы правильным подобрать параметры следующим образом:

Подбор параметров unroll&fuse по i на 8 и по j на 6...

То есть при смене процессора придётся заново подбирать эти параметры.

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

V>Но компилятор С++ не отдали, и этот компилятор от MS один из лучших в мире, особенно в деле LTO.
V>И не отдадут в обозримом будущем.
То, что один из — это точно. Лучший — вряд ли. Gcc — тоже один из лучших в мире. При этом за gcc не стоит компания с капитализацией Microsoft.

V>Зато к коду по твоей ссылке эти вопросы есть.
V>И это то, чего хотелось бы избегать.
В теории — да. На практике — не выйдет без DSL. Для DSL нужны ресурсы, которых у МЦСТ нет и не было. Зато ресурсы есть у комьюнити, если его поддерживать.