Re[5]: .Net на эльбрусах - .NET

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

S>Серверные процессоры интел — это два FMA модуля на ядро. Каждый из них умеет делать по 1 FMA операции за такт. То есть мы берём 8 даблов, умножаем их на другие 8 даблов, и прибавляем к ним третьи 8 даблов.

Это для AVX512 так?
Если правда, тут я упустил.
А можно сылку на эти команды?

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

S>Итого, с учётом автораспараллеливания, потенциально мы имеем эквивалент 16ти FMA операций за такт.

В одном потоке вычислений или в двух по гипертредингу?

S>Если у вас есть какие-то другие цифры — велком, приводите.

Да там много чего приводить можно...
Просто не всё еще задействовано в полный рост из-за, хотя бы, портированного ядра Linux и другого портированного кода.
В исходниках программ можно и нужно много чего менять для извлечения полезных фишек.

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

V>>Но нет команд одновременного сложения/умножения нескольких пар чисел из регистров, это даётся на откуп скалярному OoO и там как повезёт.
S>Я не склонен называть везением результат целенаправленных действий. Хотя да, явное склеивание команд, наверное, помогло бы. Но примерно для этого у нас есть scatter/gather в AVX, что позволяет добиваться впечатляющих результатов даже в областях, далёких от линейной алгебры и "упакованных данных". Например, разбор XML/json/UTF8/http headers.

Та не, подгрузка нескольких регистров vs FIFO в 4 КБ у Эльбруса — это несравнимо.
Ну вот у тебя обработка потока данных. В Эльбрусе ты заказываешь асинхронную подгрузку данных с некоторым опережением по обработке (до 4 кб окно), и обрабатываешь эти данные в алгоритмах без задержки, бо данные уже внутри кристалла.

V>>Проблема в том, что многие алгоритмы вычисления многочленов плохо ложатся на FMA3, который в мейнстриме.
S>Например?

d = a*b + c;
Это FMA4.

V>>Когда-то AMD добавила FMA4, но не зашло. Синусы-косинусы и проч квадратные современные процы считают через табличную интерполяцию. Но это ограниченный набор ф-ий. Иногда нужны произвольные многочлены.
S>Нужны. И в чём затруднение?

AMD c Intel не договорились.
У Эльбруса такой проблемы нет.

V>>Нельзя одним тактом выполнить квадратичную интерполяцию.
S>Ну так и во VLIW нельзя.

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

V>>Например, есть условный пропуск инструкции по ранее сохранённому предикату, что делает эффективной реализацию тринарного оператора ?:.
V>>В современных GPU используется такой же подход.
S>Я так понял, что это примерно то же самое, что и в интеле — то есть просто обе ветки вычисляются, но результат одной из них отбрасывается.

Интересно, как это могло бы выглядеть при параллельном вычислении двух блоков FMA над векторами в памяти в Интел-архитектуре?
ИМХО, никак.
Такие фокусы можно совершать только во внутреннем файле переименованных регистров.
В Эльбрусе же оно работает именно так — вычисляются две ветки, а в память уходят результаты только одной из них по вычисленному на этом же такте предикату.

V>>Я опираюсь на доступные в интернете тесты, про высоконагруженные вычисления везде одно и то же — Эльбрус оччень неплох, в сравнении с Интел.
V>>Разница во многие разы всегда.
S>

Ну, там, где на Эльбрусе применяют вручную оптимизированную библиотеку, а на интеле — наивный студенческий код, там да.

Изначально давались цифры стандартных HPC тестов, где Интел сливал в разы.
Да и как выше головы прыгнешь, если у самого мощного Интела сейчас 270 гигафлопс в одинарной точности, а Эльбрус 16с 1500 гигафлопс одинарной и 750 двойной?
У тестируемых было соответственно 150 и 576, и эти тесты выжимают физический максимум из кристаллов.

V>>Максимальная по ширине FMA или dot product инструкция — это и есть максимум того, что может выполнить суперскаляр за такт.
S>Это не отвечает на мой вопрос. Каким волшебным образом VLIW сможет обогнать SIMD на невыровненных данных вроде разбора сетевых пакетов. Там же недостаточно просто зачитать кусочек данных в регистры — надо найти, скажем, длину заголовка, и прибавить её к текущему смещению.

Длина заголовка обычно константа во фрейм-ориентированных протоколах (TCP или упакованный в TCP SSL/TSL).
Речь об обработке самих данных, которые в памяти в общем случае находятся в невыровненном состоянии после случайной фрагментации TCP-потока.

Я не говорю сейчас о реально существующем коде, я рассужаю о возможностях архитектуры.
В плане портированного легаси-кода сейчас даже ядро Linux работает без защиты тегированием, потому что требует переписывания в типобезопасной манере.

По интеропу дотнета тоже вопросы — IntPtr может интерпретироваться как указатель, так и как обычное число.
В защищённом тегированном режиме, если в это значение был записан указатель, интрепретировать его затем можно лишь как указатель, но системой типов байт-кода это не проверяется, т.е. прямо сейчас сложно сказать — возникнут ли аппаратные исключения на де-факто работающем без такой защиты коде?
Зато примитивы навроде Span<T> ложатся на такую защиту хорошо.

S>Пока это не сделано, мы не можем загружать следующий блок данных. А когда сделано — SIMD точно так же прекрасно прочтёт этот блок в регистр.

Обычно в алгоритмах потоковые данные указываются упаковаными в памяти и они должны быть выровнены.
Суть в том, что в этих FMA-вычислениях зачастую один из множителей — условная константа (т.е. или прямо в коде, или заранее подготовленные данные-коэфициенты или корреляционные последовательности, т.е. заведомо проблем с выравниванием нет), а второй множитель прогоняет некий получаемый извне поток данных.

Отличия FMA-инструкций от простого попарного умножения компонент векторов в том, что умножение и сложение выполняется с повышенной разрядностью унутре, а округляется уже результат.
Это помогает уменьшить накапливаемую ошибку округления при суммировании ряда.
Например, в таких вычислениях средняя ошибка округления будет в 4 раза меньше:
c = a0*b0 + a1*b1 + a2*b2 + a3*b3 + c

V>>Мне резало глаза от твоей "векторизации" применительно к Эльбрусу из-за сужения понятий.
V>>Спецификация SIMD представлена как вычисления над последовательностями чисел, а эффективность происходит из-за де-факто параллельных вычислений.
V>>VLIW — это тоже способ организации параллельных вычислений, просто чуть другой, местами более универсальный.
S>Это всё понятно. Непонятно, за счёт чего VLIW объедет SIMD.

Стоит выше в иерархии вычислений:
https://ru.wikipedia.org/wiki/MIMD

V>>Для Эльбруса есть еще специфические — про предварительную подкачку данных и про подготовку к эффективному ветвлению/переходу.
S>Построение компилятора, который способен построить близкий к идеальному код, опираясь только на такие невнятные намёки, представляет собой плохо изученную и очень сложную область.
S>Её невозможно вскопать в узком кругу высококлассных единомышленников.

ХЗ. Обычно критичные вещи разрабатываются соотв. специалистами.
Например, такие как шифрование, алгоритмы кодирования/декодирования мультимедия, драйвера файловых систем, коннектов к БД, сами алгоритмы работы БД, алгоритмы работы GUI-подсистем и проч.

Работающий поверх всего этого прикладной код редко совершает какие-то нагруженные вычисления, эффективность его работы во многом зависит от эффективности низлежащего уровня.
Например, когда-то еще видел сравнение работы алгоритма GC mark-and-sweep на Эльбрус 8c, и он там тоже обогнал сравниваемый Интел.
Таки, предикатная система и полутактные вычисления тоже работают, если это правильно задействовать.
Надо поискать, там было что-то смешное кол-во тактов на цикл в Эльбрусе в скомпиллированном варианте (как бы не 2 VLIW слова на цикл mark, если склероз не изменяет).

V>>В деле вычислений давно устоялся стандарт BLAS.
V>>Последние лет ~15 аспирантура активно использует тот же Питон с обертками над нейтивными либами по этому стандарту для игрищ с большими вычислениями.
V>>Для Эльбруса это всё доступно изначально как часть стандартной поставки их Линухов (ОС Эльбрус).
S>Это для линейки. Её одной — недостаточно. Возвращаемся к вопросу коммерческой применимости — сколько (в % рынка) у нас занимают вычисления линейной алгебры?

Только лишь линейная алгебра была изначально/исторически, это давно не так.
Ссылку на состав EML-библиотеки я давал:
https://www.altlinux.org/%D0%AD%D0%BB%D1%8C%D0%B1%D1%80%D1%83%D1%81/eml

Аналогично от Интел либа тоже не только лишь линейной алгеброй промышляет:
https://ru.wikipedia.org/wiki/Integrated_Performance_Primitives

S>А для простого бизнеса нужно быстрое исполнение java, js, C#.

Для быстрого исполнения нужна эффективная низлежащая инфраструктура.

S>Нужны библиотеки/фреймворки с быстрым разбором и генерацией XML/json/HTML.

Это в чисто управляемом виде достаточно быстро никогда не будет.
Например, в JS-движке v8 разбор XML, HTML и JSON выполняется в нейтиве.

Все эти вещи системообразующие, пишутся один раз для всех.

S>Нужны всякие преобразования над картинками, в основном png и jpeg.
S>Нужна видеокомпрессия/декомпрессия.

Дык, поинтересуйся по ссылкам выше.

V>>Размер в процессоре Эльбрус 4с был 4 КБ на ядро, сейчас не в курсе.
S>Маловато по сравнению с интеловским L1.

Кеш L1 тоже есть.
Для потоковой обработки этого окна предзагрузки вполне достаточно, чтобы ядро не простаивало.

V>>Технология эта не является уникальной для Эльбруса, гуглить по "асинхронная подкачка данных".
V>>Например:
V>>https://vk.com/@kawaiipc-ustroistvo-obrascheniya-k-massivam
S>Ну, это интересно. Хотя по большому счёту, это всего лишь этакий кэш со специальной политикой вытеснения, оптимизированной для линейного сканирования; рукопашное асинхронное управление кэшем на интеле тоже есть в виде инструкции PREFETCH.

Это на одну линейку кеша.

V>>Дело еще в другом — у них не потрачено так много транзиторов на суперскалярные вычисления над потоком исполнения.
V>>Поэтому они позволили себе нехилую многомерную спекулятивность, т.е. когда потенциальные ветвления порождают опять потенциальные ветвления, т.е. размерность потенциальных состояний растёт. Т.е., это примерно то же, для чего служит OoO + предсказание ветвлений, просто заход к проблеме с другой стороны.

S>Вот это место не очень понятно. Вы хотите сказать, что у эльбруса есть какой-то большой запас вычислительных блоков, которые позволяют одновременно исполнять несколько веток спекулятивно, а потом отбрасывать результат всех, кроме истинной? Это было бы крайне удивительно.

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

V>>В первых версиях Итаниумы не отставали в целочисленных вычислениях и резко опережали в вещественных числомолотилках.
V>>Но они были дороже топовых Зионов, в этом была ошибка.
S>Удивительно, что интел не исправил эту ошибку за долгие годы истории итаниума.

Ну а мне удивительно, что MS резко не снизила цену на Windows (особенно серверную) еще в середине нулевых, когда стало видно, что Linux вовсю набирает оброты.
Или что Apple продолжала держать высокие цены на свои Маки в эпоху набора популярности IBM-совместимого парка, хотя возможность снизить цены на Маки была.
Такие вещи необъяснимы, но ведут к похожим последствиям.

V>>Им надо было отдавать их, наоборот, дешевле, "подсаживая" отрасль на эту архитектуру.
S>Ну, давайте применим этот аргумент к Эльбрусам. Пока что выглядит так, что МЦСТ тщательно копирует ошибки Интел, не копируя их удачные шаги.

И я о том.
Просто у Интел была возможность продавать Итаниумы дешевле (т.е. временный убыток по одной из областей, за счёт прибылей в другой), а у МЦСТ такой возможности нет.
Тут только если гос-во вмешается.
Мои аппеляции здесь к гос-ву, есно.

V>>У них тоже был рывок (низкий старт), теперь тоже в насыщение попали.
S>Ну какое же там насыщение.

Ну так сравнить прорыв архитектуры Бульдозер с предыдущей и последней с предпоследней.
Начинается такая же скука, как в последних поколениях Интел.

V>>Просто чуть позже, чем Интел.
S>Ни один из производителей не может расслабиться, иначе потеряет долю рынка.

Дык, АМД и потеряла дофига.
Вынуждена была продать свои заводы арабам, сосредоточиться на разработке сугубо "на бумаге", выпуская процы на Тайване.
Выжила чудом.

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

Я такой пока мест не видел.
Что CUDА, что OpenCL — это чудовищная угрёбищность с т.з. "обычного программирования".

Подход Эльбрус тут выглядит не в пример лучше.

V>>Но на вершине встретятся обязательно.
S>Вопрос только — кто там с кем встретится. Эльбрус может и не успеть

Да куда он денется, особенно сейчас?
Космос и военку в любом случае на чём-то обсчитывать надо.
Это почему "гражданская" прибыльность Эльбруса не является определяющим фактором.

V>>Нужно, просто страшно поддерживать.
V>>Например мы не поддерживаем.

S>А чего не поддерживаете-то? Правильно: на ваших задачах AVX512 не даст ощутимого выигрыша.

Потому что мы даём бинарь.

S>Иначе — поддерживали бы. Риска ведь никакого нет — ваш код не станет хуже работать на avx2 после включения поддержки avx512.

Код просто упадёт, если инструкции avx512 процом не поддерживаются у клиента.

V>>Если в 90-е гды можно было не рассматривать во многих нишах процы, допустим, 4-хлетней давности, то сегодня приходится брать во внимание процы даже 10-тилетней давности, увы.
S>И что?

И всё, avx512 будет поддержан нескоро.

V>>Любые обращения к облакам всё более зашифрованы.
V>>Вот как раз Эльбрус по нашим ГОСТ-ам шифрует в разы быстрее x86-х.
S>Есть подозрение, что за оптимизацию шифрования нашими ГОСТами на интеле никто ещё толком и не брался.

Возможно.
Но разница в пиковой производительности должна давать себя знать на тщательно вылизанном коде.
VLIW, собсно, за этим и создавался, чтобы при том же кол-ве транзисторов на кристалле больше их отдавать на вычислительные блоки.

В последних суперскалярах наверняка кол-во транзисторов в логике обслуживания потока команд превышает оное кол-во в целевых блоках (они расширили кол-во меток предсказателя переходов и окно анализа ОоО).

Т.е. VLIW-архитектура сможет достаточно безболезненно наращивать кол-во ядер, т.к. каждое ядро банально кушает меньше транзисторов, в сравнении с суперскаляром.
Это почему я и говорил, что в пределе Эльбрус встречается с графическими ускорителями будущего, когда кол-во ядер у него будет сотни (умножь на кол-во АЛУ на ядро).

V>>Или есть что-то, чего я не знаю? Т.е. У Интел есть какой-то скрытый козырь в рукаве?
S>Тут скорее есть бочка дёгтя в ложке мёда Эльбруса. Горстка хороших инженеров не вытащит команду некомпетентных управленцев, увы.

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

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

V>>Если нет, если развитие процессоров будет идти так же, как шло последние 10 лет — то там всё ясно уже.
V>>За очередные лет 10 получишь еще 30-40% прибавки эффективности на ядро на частоту, ну и частота вырастет процентов на 20-25.
V>>Скучно... ))
S>А также будут допиливаться всякие нишевые ништяки — дополнительные AVX команды для специальных случаев типа криптографии и видеокодирования.

Они уже есть.
Ситуация такова, что для того, чтобы отрасль переползла хотя бы на avx512, как раз потребуется лет 10.

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

V>Это для AVX512 так?
Да.
V>Если правда, тут я упустил.
V>А можно сылку на эти команды?
Конечно. https://www.felixcloutier.com/x86/vfmadd132pd:vfmadd213pd:vfmadd231pd

V>Для AVX512 я когда-то увидел четырёх-итерационные новые команды, когда в упакованных 4-х регистрах лежали по 4 числа, по одному регистру лежали данные в памяти и еще по одному — указатель на результат.
Эмм, что значит "по одному регистру лежали данные в памяти"?
Да, один из аргументов FMA-команд может быть memory location. "Регистр" тут ни при чём.

V>Эта команда применяла 4 раза умножение из регистров к данным в памяти и в память же записывала результат (удобно, например, при загрузке 16-ти коэфициентов фильтра в регистры и прогон памяти через цифровой фильтр).
Насколько я знаю, таких команд не бывает. Результат FMA операций (и он же — первый операнд) всегда лежит в регистре.
V>Но на каждой итерации всё-равно было 4*4 числа в векторах.
Что такое "4*4"? В AVX512 каждый вектор содержит как минимум по 8 значений — это если вам нужен double. Если вас устраивает single precision, то — по 16 single значений.

V>В одном потоке вычислений или в двух по гипертредингу?
В одном. У неё CPI = 0.5.

V>Да там много чего приводить можно...
Ну, так приводите.
V>Просто не всё еще задействовано в полный рост из-за, хотя бы, портированного ядра Linux и другого портированного кода.
Не очень понятна эта фраза. Мы же говорим про способности железа и про то, что из него можно выжать.
Если где-то какой-то код недопортирован — его допортируют, проблемы нет. Спеки открыты, железа — хоть попой ешь; садись да пиши. Нет проблемы "доступ к аппаратуре доступен лишь узкому кругу ограниченных людей".

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

V>Та не, подгрузка нескольких регистров vs FIFO в 4 КБ у Эльбруса — это несравнимо.
Почему несравнимо-то?
V>Ну вот у тебя обработка потока данных. В Эльбрусе ты заказываешь асинхронную подгрузку данных с некоторым опережением по обработке (до 4 кб окно), и обрабатываешь эти данные в алгоритмах без задержки, бо данные уже внутри кристалла.
А в интеле ты заказываешь асинхронную подгрузку данных с опережением по обработке при помощи PREFETCH (до 32кб кэша), и обрабатываешь эти данные в алгоритмах без задержки, т.к. они уже внутри кристалла.

V>>>Проблема в том, что многие алгоритмы вычисления многочленов плохо ложатся на FMA3, который в мейнстриме.
S>>Например?

V>d = a*b + c;
V>Это FMA4.
Я знаю, что такое FMA4. Вопрос в том, какое отношение это имеет к полиномам. В вашей формуле никакого полинома нет.

V>AMD c Intel не договорились.
V>У Эльбруса такой проблемы нет.
Я спрашиваю — в чём затруднение с вычислением полиномов через FMA3? Как я понимаю, за один такт вычислить x⁵, x⁴, x³, x² невозможно ни в SIMD, ни во VLIW.
Потому, что результаты зависят друг от друга.
А за несколько тактов вычисление степеней x работает и там и там — потому что операции однотипные.

V>Вычисления предикатов в Эльбрусе происходят за условные пол-такта, т.е. вычислить предикат и по нему условно выполнить одно из вычислений, заданных в слове, можно за один такт.
Как мы перепрыгнули от квадратичной интерполяции к предикатам?
V>Физически происходят оба вычисления под предикатом, ес-но, просто в конце в результат сохраняется только одно.
Ну, так в SIMD всё то же самое. Откройте для себя masked-версии AVX команд, а также команду выбора VBLENDMP.

V>Интересно, как это могло бы выглядеть при параллельном вычислении двух блоков FMA над векторами в памяти в Интел-архитектуре?
V>ИМХО, никак.
Именно так и делается. Тернарный оператор c = expr ? a: b выполняется так:
1. Вычисляем a
2. Вычисляем b
3. Вычисляем expr
4. Вычисляем с на основе a, b, и expr при помощи команды BLEND.
1, 2, и 3 параллелятся, т.к. между ними нет зависимостей. Только 4 вынуждена ждать окончания выполнения предыдущих трёх команд.
На практике у существующих Интелов не хватит блоков для одновременного исполнения всёх трёх команд; но, к примеру, для вычисления минимума/максимума у нас expr зависит от a и b (expr == a < b), так что его в любом случае придётся отложить до окончания 1 и 2.

V>Такие фокусы можно совершать только во внутреннем файле переименованных регистров.
V>В Эльбрусе же оно работает именно так — вычисляются две ветки, а в память уходят результаты только одной из них по вычисленному на этом же такте предикату.
С учётом того, что скалярных блоков FMA у эльбруса всего 6 штук, в каждой из параллельных веток можно вычислить не более 3х результатов за такт.
Ну, может быть в v6 они умеют делать 2 64-bit операции в каждом блоке, т.к. теперь они 128разрядные. Ок, 12 FMA c двойной точностью, из которых мы половину выбросим.
Примерно то же самое будет и в intel, только блоков там не 12, а 16 (2 векторных FMA-блока по 8 double).
Судя по спекам, ШК выполняется за 6 тактов. Итого, имеем 8 операций "min" за 3 такта против 6 операций за 6 тактов.

V>Изначально давались цифры стандартных HPC тестов, где Интел сливал в разы.
Кем и кому давались такие результаты?
V>Да и как выше головы прыгнешь, если у самого мощного Интела сейчас 270 гигафлопс в одинарной точности, а Эльбрус 16с 1500 гигафлопс одинарной и 750 двойной?
V>У тестируемых было соответственно 150 и 576, и эти тесты выжимают физический максимум из кристаллов.
Что-то я потерял нить. О каких тестах идёт речь? Те, что приводились в топике, не показывают того, о чём вы говорите.

V>Длина заголовка обычно константа во фрейм-ориентированных протоколах (TCP или упакованный в TCP SSL/TSL).
В таком случае SIMD прекрасно затащит эти данные при помощи GATHER-команд.
V>Речь об обработке самих данных, которые в памяти в общем случае находятся в невыровненном состоянии после случайной фрагментации TCP-потока.
Никаких проблем.
V>Я не говорю сейчас о реально существующем коде, я рассужаю о возможностях архитектуры.
Я тоже.
V>В плане портированного легаси-кода сейчас даже ядро Linux работает без защиты тегированием, потому что требует переписывания в типобезопасной манере.
Как мы перепрыгнули от разбора невыровненных данных к тегированию?
Тегирование — тупиковая ветвь архитектуры. Корректность программ эффективнее гарантировать статической верификацией, чем динамической проверкой.

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

V>Обычно в алгоритмах потоковые данные указываются упаковаными в памяти и они должны быть выровнены.
А зачем вам "обычно", когда можно написать так, как надо именно вам?
Потоковые данные — на то и потоковые. Невыровненность данных влияет только на скорость загрузки. Если у вас есть какой-то длинный поток double, который начинается с неудачного адреса, то вы делаете скалярный разбор его головы, а потом бежите по нему при помощи MOVAPD, который чуть быстрее за счёт выравненности данных. Вклад головы в общую производительность будет пренебрежимо мал.

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

V>Отличия FMA-инструкций от простого попарного умножения компонент векторов в том, что умножение и сложение выполняется с повышенной разрядностью унутре, а округляется уже результат.
V>Это помогает уменьшить накапливаемую ошибку округления при суммировании ряда.
V>Например, в таких вычислениях средняя ошибка округления будет в 4 раза меньше:
V>c = a0*b0 + a1*b1 + a2*b2 + a3*b3 + c
Непонятно, как вы перепрыгнули от рассуждений об упакованности потока и выровненности данных к вопросам округления. Не вижу логики.

V>Стоит выше в иерархии вычислений:
V>https://ru.wikipedia.org/wiki/MIMD
По-прежнему непонятно, за счёт чего он объедет. Приведите пример задачи — ну, например, разбор TCP-пакета. Где и как там VLIW станет быстрее, чем SIMD?

V>ХЗ. Обычно критичные вещи разрабатываются соотв. специалистами.
Совершенно верно.
V>Например, такие как шифрование, алгоритмы кодирования/декодирования мультимедия, драйвера файловых систем, коннектов к БД, сами алгоритмы работы БД, алгоритмы работы GUI-подсистем и проч.
Вот вы перечислили 6 направлений. У вас все эти направления будет делать одна команда одновременно? Или по очереди?
Или у МЦСТ есть в запасе 6+ команд специалистов, которые совмещают глубокие знания архитектуры Эльбруса и понимание соответствующей предметной области?
А если мы расширим список до реального набора прикладных задач, то количество потребных команд быстро вырастет.

V>Таки, предикатная система и полутактные вычисления тоже работают, если это правильно задействовать.
Интересно было бы почитать подробности.
V>Надо поискать, там было что-то смешное кол-во тактов на цикл в Эльбрусе в скомпиллированном варианте (как бы не 2 VLIW слова на цикл mark, если склероз не изменяет).
Да, поищите.

V>Только лишь линейная алгебра была изначально/исторически, это давно не так.
V>Ссылку на состав EML-библиотеки я давал:
V>https://www.altlinux.org/%D0%AD%D0%BB%D1%8C%D0%B1%D1%80%D1%83%D1%81/eml
Да, эта ссылка прекрасно подтверждает то, о чём я говорил — даже чтобы почитать список функций, нужно поставить соответстсвующую ОС, а в ней — пакет eml-doc.
Опубликовать референс в интернете? Не, мы не знаем, как это.

V>Аналогично от Интел либа тоже не только лишь линейной алгеброй промышляет:
V>https://ru.wikipedia.org/wiki/Integrated_Performance_Primitives
Всё верно. Сравните состав EKL и IPP. А ещё там есть секция See also, где ссылки на другие интеловские библиотеки.
Кто будет окучивать весь этот объём работы? Одна конторка на 374 человека, из которых пилением библиотек заняты процентов 20%?
К какому году будет достигнут паритет по функциональности?

V>Для быстрого исполнения нужна эффективная низлежащая инфраструктура.
Именно об этом я и говорю.

S>>Нужны библиотеки/фреймворки с быстрым разбором и генерацией XML/json/HTML.

V>Это в чисто управляемом виде достаточно быстро никогда не будет.
Во-первых, будет. Любой нативный код, написанный для таких задач на С++ с интринсиками интела, портируется 1-в-1 в современный C#, без малейшей потребности в интеропе с нативом.
V>Например, в JS-движке v8 разбор XML, HTML и JSON выполняется в нейтиве.
Во-вторых, речь не о том, что мы хотим разбирать JSON managed-кодом. А о том, что нужна как минимум нативная либа для оптимального разбора и порождения JSON, оптимизированная для эльбруса.
V>Все эти вещи системообразующие, пишутся один раз для всех.
"Один раз" — это утопия. Можно взять любую высокоскоростную либу для прикладной задачи и посмотреть на её историю коммитов.
То есть недостаточно один раз на полгода посадить десяток крутых парней, и потом десятилетиями пользоваться тем же исходником, который они отдали в продакшн.
Нужна постоянная поддержка и развитие. То есть этот "один" раз растягивается на сотни коммитов и десятки лет.

V>Дык, поинтересуйся по ссылкам выше.
Ну, я ж не говорю, что там — чистое поле. Но объём несделанного всё ещё превышает объём сделанного на порядок. И к тому, что сделано, тоже возникают вопросы.
По нескольким отдельным направлениям достигнуты неплохие результаты. Что по остальным направлениям? На сколько % реализован потенциал платформы?

S>>Ну, это интересно. Хотя по большому счёту, это всего лишь этакий кэш со специальной политикой вытеснения, оптимизированной для линейного сканирования; рукопашное асинхронное управление кэшем на интеле тоже есть в виде инструкции PREFETCH.

V>Это на одну линейку кеша.
Что "на одну линейку кэша"?

V>Есть подробное описание процесса спекулятивного исполнения и слияния результатов такого исполнения в официальном руководстве к эффективному програмированию на Эльбрусе.
Да, и я его прочитал.
Во-первых, там даже простые скалярные операции занимают по 6 тактов. То есть там, где интел делает вычисление a = expr1; b = expr2; c = a < b : a : b за три такта, Эльбрус тратит 6.
Во-вторых, рассматриваемые скалярные примеры как раз запихивают в одну ШК несколько операций потому, что они — скалярные. Чудес не бывает; если в ядре есть 6 арифметических блоков, то они могут исполнить параллельно 6 операций. Вся разница — в том, что эльбрус даст исполнить 6 разных операций, а интел — два блока по 8 одинаковых.
Предикатное исполнение означает, что часть из рассчитанных результатов можно отбросить. Оно не означает, что вы сделаете 12 операций, а потом оставите только 6 результатов.

V>Многомерной спекуляция получается из-за хранения диагностических бит, т.е. при независимости по данным спекулятивное исполнение может быть достаточно глубоким, получаясь де-факто многомерным.
Я не понимаю, что значит "многомерным".

V>И я о том.
V>Просто у Интел была возможность продавать Итаниумы дешевле (т.е. временный убыток по одной из областей, за счёт прибылей в другой), а у МЦСТ такой возможности нет.
V>Тут только если гос-во вмешается.
V>Мои аппеляции здесь к гос-ву, есно.
Ну, про наше государство трудно сказать доброе слово. Но опять мы возвращаемся к вопросу о том, почему не принимаются бесплатные или околобесплатные меры. Ссылка на то, что с господдержкой можно было бы сделать что--то ещё — это отмазки. "Почему вы не выпускаете эмулятор?" — "а зачем? Вот если бы нам дали триллион рублей, мы бы раздали реальные машинки нуждающимся".

V>Ну так сравнить прорыв архитектуры Бульдозер с предыдущей и последней с предпоследней.
V>Начинается такая же скука, как в последних поколениях Интел.

Вы путаете технические вопросы с финансовыми. Пока вы скучаете, выручка AMD выросла на 70% за последний год.
Всем бы так скучать.

V>Выжила чудом.

V>Я такой пока мест не видел.
Ну, так мы далеки от финала цивилизации.
V>Что CUDА, что OpenCL — это чудовищная угрёбищность с т.з. "обычного программирования".
Я краем уха слыхал про более высокоуровневые вещи. Типа, функцию активации нейросетки мы пишем в виде "человеческой" формулы, а код обучения порождается библиотекой.
Впрочем, я от этого очень далёк, так что уверенно рассуждать не берусь.
V>Подход Эльбрус тут выглядит не в пример лучше.
По каким критериям? Тренировки нейросетей на видеокартах уже являются вполне повседневным и весьма прибыльным бизнесом.
Что должно случиться, чтобы все эти ребята рискнули заменить nvidia на Эльбрус?

V>Да куда он денется, особенно сейчас?
Как куда? В нишевые применения, где по политическим причинам, стиснув зубы, его будут применять насильно. См.тж. "картофель и Пётр I".
V>Космос и военку в любом случае на чём-то обсчитывать надо.
Потребности космоса и военки в вычислительных мощностях — это эпсилон по сравнению с коммерческим сектором.
V>Это почему "гражданская" прибыльность Эльбруса не является определяющим фактором.
Для чего? Для того, чтобы Эльбрус совсем не умер? Да, не является. Как, скажем, прибыльность общественного транспорта в США. Автобусы в Орландо продолжат ходить по маршрутам, несмотря на близкую к 100% убыточность.
А для того, чтобы он развивался? Нет, коммерческая прибыльность и есть основной фактор успеха.

V>Потому что мы даём бинарь.
И?
S>>Иначе — поддерживали бы. Риска ведь никакого нет — ваш код не станет хуже работать на avx2 после включения поддержки avx512.
V>Код просто упадёт, если инструкции avx512 процом не поддерживаются у клиента.
Ну, вас же не пугает падение вашего кода, если инструкции AVX2 не поддерживаются у клиента.
Надо полагать, оттого, что в вашем бинаре стоит ветвление по архитектуре. Мы конкретно этот вопрос уже обсуждали неоднократно.
V>И всё, avx512 будет поддержан нескоро.

Если бы AVX512 давал на ваших задачах выигрыш больше, чем затраты на проверку processor feature, то вы бы его поддержали ещё позавчера.

V>Т.е. VLIW-архитектура сможет достаточно безболезненно наращивать кол-во ядер, т.к. каждое ядро банально кушает меньше транзисторов, в сравнении с суперскаляром.
V>Это почему я и говорил, что в пределе Эльбрус встречается с графическими ускорителями будущего, когда кол-во ядер у него будет сотни (умножь на кол-во АЛУ на ядро).
Давайте посмотрим на нынешнее положение. Топовый Интел тащит 38 ядер по 2 FMA блока. В терминах скалярных операций, он делает 38*2*8 = 608 FMA операций за такт. Что у нас в 32C, у которого опытные образцы появятся ещё года через три, и то при самом оптимистичном развитии событий?

А чтобы количество ядер достигло сотен, нужно переходить на более другой техпроцесс. С этим у нас всё плохо.

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

Осталось дождаться правильной команды "надо".
К примеру, команды на раздачу эльбрусов в ВУЗы мы ждём до сих пор.

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

V>Они уже есть.
V>Ситуация такова, что для того, чтобы отрасль переползла хотя бы на avx512, как раз потребуется лет 10.
Будут потребности — переползёт. Понимаете, если у меня появится проект, который сможет выиграть от AVX-512, то я смогу сесть и начать его пилить прямо сейчас.
Если мне потребуется купить железную машинку, чтобы проверить теоретические выкладки насчёт эффективности моего кода, то я смогу за смешные деньги приобрести экземпляр.
Если у меня появится проект, которому был бы полезен Эльбрус, то я буду сосать лапу. Несмотря на то, что я нахожусь в РФ, и покупка Интела осложнена санкциями, а Эльбрус — это православная отечественная технология.

Результат такого подхода немного предсказуем.
Вы много смеётесь над моими наивными ожиданиями из ранних нулевых — что MS вытащит голову из задницы и разовьёт .Net до достойного уровня. Но сейчас вы продолжаете испытывать ровно такой же юношеский энтузиазм по отношению к Эльбрусу — что вдруг "центры принятия решений" вынут головы из задниц и наконец начнут рулить в какую-то нужную сторону.
Ну, для MS мы обещанного будущего дождались, хоть и на 10 лет позже, чем могли бы. Дождёмся ли для Эльбруса — хз.

Здравствуйте, 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>И вот тут всё заверте...

Интересная гипотеза.

	От:	vdimas
	Дата:	07.09.22 22:05
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	08.09.22 06:40
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	08.09.22 11:40
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	08.09.22 12:01
Оценка:

	От:	vdimas
	Дата:	08.09.22 19:05
	Оценка:

	От:	Sharov
	Дата:	09.09.22 13:00
	Оценка: