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

V>

V>    for(var k = 0; k < L; k++)
V>        for(var j = 0; j < N; j++)
V>            for (var i = 0; i < M; i++)
V>                c[k * N + j] += a[k * M + i] * b[i * N + j];
V>

Ну, ок. Смотрим, что у авторов:

for(i = 0; i < N; i++)
  for(j = 0; j < N; j++)
    for(k = 0; k < N; k++)
      C[i*N+j] += A[i*N+k] * B[k*N+j];

Порядок обхода — ровно тот же, что и у вас, с точностью до имён переменных. Где тут "У авторов схема kij, которая, увы, является наихудшей."???

V>Боюсь, для того самого общего случая, т.е. стандарта BLAS — предел.
Зря боитесь. Вот, к примеру, декабрь 2020: https://www.sciencedirect.com/science/article/pii/S2090447920300058
Если вам трудно читать текст, можете промотать сразу в конец — там графически сравнивается производительность предлагаемого кода по умножению матриц с MKL.
Заодно, кстати, интересно сравнить поведение кода, собранного лучшим в мире MSVC, с кодом, собранным ICC.

V>Потому что хватает ссылок, где наивный код сравнивается с EML.
V>Я просмотрел пару таких ссылок, везде ускорение примерно в 10 раз (плюс-минус проценты), позволил себе сделать соотв. прикидки от обсуждаемых цифр.
Было бы ещё лучше, если бы вы привели хотя бы одну из просмотренных ссылок.

V>Или в зависимости от опции компилятора для целевой архитетуры.
Опций компилятора недостаточно.
V>В общем, зря тут упираешься.
Просто практика ваши слова не подтверждает. Вы же сами привели ссылку на статью, где в дополнение к опциям приходится руками развёртывать цикл в нужный размер, подбирая магические чиселки.
Я бы понял, если бы gcc (или какой-нибудь mcstcc) сам разворачивал циклы нужным образом при указании ему версии целевой архитектуры.
Увы, нет — только магия, только шаманство. "Не переставляйте эти инструкции местами, иначе результат может оказаться неоптимальным".

V>Пока что мало чего произошло, оно только-только начинает происходить (заметные подвижки начались с 5-го и 6-го дотнета ) и это очень надолго.
Смотря с чем сравнивать. Заметные подвижки начались уже очень давно. Напомню, что первый подход к SIMD произошёл ажно 8 лет назад: https://devblogs.microsoft.com/dotnet/the-jit-finally-proposed-jit-and-simd-are-getting-married/

V>Тебе сразу говорилось, что до твоей пенсии ты своё светлое будущее не застанешь.
Странно. До пенсии ещё далеко, а то, о чём мы говорили — вот оно.

V>Я приводил в пример чистые ФП-языки, которые дают намного больше простора для бета-редукций, но за ~15 лет активных телодвижения результаты были слишком скромные на середину нулевых.
V>Уже более 30-ти лет примерно с теми же результатами.
Надо полагать, это оттого, что одними бета-редукциями код не спасёшь. В итоге, за последние три версии в дотнете всё улучшилось сильнее, чем для чистого ФП за 30 лет.

V>Помнишь проект Avalon и фантазии, что всё GUI в будущих Windows будет managed?
Да там много было фантазий. В том числе и про объектно-ориентированную ФС с элементами реляционки.
Я не помню точно, что я думал по поводу GUI в будущих Windows, потому что десктопных приложений я не писал примерно года с 2003го.

V>А которые C# UWP-приложения — там лишь тонкая обёртка над нейтивной подсистемой, и оно пашет в разы шустрее, чем WPF, да еще в памяти чуть ли не на порядок меньше мусора.
V>Боюсь, что по этому вопросу "наша" точка зрения победила даже не до твоей пенсии, а до конца твоей жизни.
Не очень понятно, что именно она победила. Было бы интересно, приведи вы какой-нибудь пример того, против чего вы выступали.

V>И что меня раздражало в оппонентах (не только в тебе) — я подробно разбирал низкоуровневую механику WPF и объяснял почему так — загвоздка в вызове пайплайна подсистемы GUI, в необходимости осуществлять тысячи вызовов низлежащего рендерера (а для последних версий DirectX вызовов еще больше, хотя сами вызовы легковесней).
Да, я за всю жизнь раза три заходил в форум .Net GUI. Наверное, вы там вели какие-то войны.
Мне и тогда это было неинтересно, и сейчас не стало.
V>И в этом месте дотнет сильно проседает из-за дороговизны вызова нейтивных ф-ий.
Стоимости вызова нейтивных функций мы уже обсуждали.

V>Как они выкрутились в WPF — со стороны C# идёт сериализация команд в некий байт-буфер, отправка сериализованных команд в специальный поток, обслуживаемый нейтивной библиотекой.
V>В этом потоке нейтивный код десериализует команды, пакеты вида { код_операции, операнды... } и по таблице кодов команд вызывает соотв. методы-адаптеры, которые, в свою очередь, вызывают ф-ии низлежащего GUI с поданными в сообщении аргументами.
Прикольно. А я думал, что там сразу поток команд идёт в драйвер, а не в нативную библиотеку, которая вызывает низлежащий GUI, который уже потом опускается в драйвер.

V>Плюс задержки с сериализацией и передачей сцены нейтивной либе.
Странно.

V>Как эти ограничения переплюнуть точному GC — лично я ума не приложу.
Увы, я крайне далёк от визуальщины, так что ничего хорошего я вам не подскажу. Но в целом, очевидно, нужно смотреть на то, что ест аппаратура — как там устроен конвеер современной видеокарты — и стараться готовить максимально крупные блоки для отдачи в неё. Потому что собственно манипуляции байтиками в менеджед ничуть не хуже, чем в нативе. Сложности начинаются только в момент интеропа, и то, основные из них связаны с референс-типами.
А просто уложить байты в буфер, а потом сделать один раз вызов с маршалингом запиненного указателя — тьфу, семечки.

V>Здесь подход мало чем отличается от биндинга Питоновских либ к нейтивным BLAS-либам.
Этот подход хорошо работает для тех случаев, когда собственно код обработки "ячейки" фиксирован — как в BLAS.
Тогда можно выставить наружу крупноблочный API типа "сделай мне A * B ^T".
А вот для задач типа наложения фильтров, где параметром вызова является ядро, скомпилировать нативный код заранее не выйдет.

V>Так вот, подводя жирную черту под всеми этими фапаниями на несостоявшийся Avalon когда-то:
Лучше подведём её над этими фантазиями. Какое значение имеет проект Авалон в контексте .Net на эльбрусах?

V>Почти всегда мне понятны мотивы принятых тех или иных решений (хотя местами улыбали явно индусские мотивы, но это обычно был не самый критичный код).
В тех немногих случаях, когда мы проверяли ваши предположения о мотивах тех или иных решений, вы попадали пальцем в небо. Впрочем, я тоже.

V>Всё вместе это болото, токсичность, невозможность поступления свежего воздуха, как грится, невозможность даже просто предметно дискутировать.
Нет, просто конкретно вы неспособны вести дискуссию в приличных рамках. Если вы когда-нибудь научитесь фокусироваться на технических вопросах и воздерживаться от оскорблений оппонентов, то внезапно окажется, что и свежего воздуха хватает, и предметно дискутировать можно.

V>А потом эту секту грубо разогнали нафик и подтянули простых работяг, не замутнённых никакими предрассудками.
"Разогнали", ха-ха. Мне прямо даже интересно, кто эти простые работяги, которым не давали коммитить, и кого именно разогнали.
V>Почитывал периодически блог руководителя дотнетного направления (уже забыл как его), был рад, что его турнули.
Ха-ха.
V>Например, такого пошиба типчик не выжил бы в тех условиях, в которых работаю я, он довольно быстро зарекомендовал себя как болтун низкой полезности и почти нулевого выхлопа.
V>Боже, его эксперименты с кодом были до того идиотскими в своей наивности, что я порой был в шоке, как он вообще на эту должность попал и почему так долго продержался.
Вот эти — как раз характерный пример рассуждений, за которые вас многие считают токсичным мудаком.

S>>А я — наблюдаю. Просто вы не вращаетесь в тех кругах, где принято пилить JVM.
V>Э, нет, я одно время (пару лет назад) наблюдал весьма плотно, поплотнее, чем за дотнетом.
V>(у нас есть версия продукта и для Джавы)
Вы, возможно, путаете выражение "пилить JVM" с "пилить для JVM". Те, о ком я говорю, это не те ребята, что "мы тут пишем приложение для Java — как нам оптимизировать нагрузку на GC?", а те, которые "нам что-то не нравится JVM, щас мы её форкнем и подпилим JIT".

V>В экосистеме Джавы в разработке высокоуровневого энтерпрайз г-на народу пасётся прилично и ротация имеется, но на низком уровне одни и те же лица чуть ли не десятилетиями, любопытство со стороны минимальное.
Скорее всего, всё упирается в отсутствие единого столбового направления.
То есть "любопытство со стороны" применяется к альтернативным версиям JVM, вместо контрибуций в общую ветку.

V>Про Перл тоже так думали, бо вменяемых альтернатив не было полтора десятилетия.
Это где это перлу не было альтернатив? Что-то не верю я в существование каких-то феерически больших кодовых баз на перле.
V>Но чуть заматерел Питон, потом выстрелил сразу же мощно JS-node — и досвидан.
Как интересно. Что же это за ниша, в которой живут сразу и Питон и Node?

V>Ввели же генерики в Джаве, подсуетились... ))
Это не генерики, а слабое подобие левой руки. В этом смысле я с вами согласен — темпы развития Java как платформы разочаровывают.
Ну, приняты определённые решения. Спасибо, что хоть лямбды с недогенериками прикрутили. Value-типы уже несколько лет как в виде прототипа доступны

V>Конкурент номер один дотнету — Джава.
Ну, во-первых, JVM на Эльбрус вроде всё же спортировали.
V>Судьба дотнета во многом будет зависеть от судьбы Джавы и наоборот.
Для начала они должны хоть как-то начать работать на эльбрусе. Потом уже можно что-то говорить о судьбе.

V>Изначально программисты MS, у которых почему-то стоит C/C++ в профиле.
V>Т.е. подкинули в проект портирования дотнета на линуха плюсовиков, по понятной причине.
V>И вот тут всё заверте...
Интересная гипотеза.