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