Здравствуйте, 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 лет позже, чем могли бы. Дождёмся ли для Эльбруса — хз.