Здравствуйте, vdimas, Вы писали:
V>Потому что нет смысла.
V>На остальных вычислениях суперскаляр не нагрузит эффективно простаивающие вычислительные блоки.
Нагрузит, отчего нет*

S>>К примеру, AVX-512 может обработать 8 упакованных double за одну операцию.
V>Это и есть 4*4.
Я не понимаю вашу формулу. Что вы тут и на что умножаете?
Серверные процессоры интел — это два FMA модуля на ядро. Каждый из них умеет делать по 1 FMA операции за такт. То есть мы берём 8 даблов, умножаем их на другие 8 даблов, и прибавляем к ним третьи 8 даблов.
Итого, с учётом автораспараллеливания, потенциально мы имеем эквивалент 16ти FMA операций за такт.
У эльбруса по 6 скалярных арифметических модулей на ядро. В новой v6 архитектуре эти модули 128разрядные. То есть, при удачных погодных условиях, одно ядро эльбруса может выполнить 12 FMA-операций над 8байтными даблами за такт. То есть, проигрывает интелу примерно 25%. Добавляем разницу в тактовой частоте, и получаем отставание.

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

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

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

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

V>>>Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
S>>Ничего ужасного. Инструкций будет не одна, а три, а вот быстродействие я бы померил. Сколько тактов делается эльбрусовский fmax/fmin?

V>Минимум 6 за такт.
V>Но могу и ошибаться, тогда 18-24.
Брр. Вы сейчас про скалярный fmax/fmin? Непонятно. В интеле будет три инструкции, но каждая из них вычисляет 8 fmax/fmin за три такта. При независимости по данным — можно сделать 16 за три такта. Это если я сходу не затупил — тогда за 2 такта.

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

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


V>>>С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера.
V>>>Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
S>>Не очень понятно, как это так получится, и что помешает суперскаляру исполнять несколько SIMD за такт при тех же вводных.

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

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

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

V>В деле вычислений давно устоялся стандарт BLAS.
V>Последние лет ~15 аспирантура активно использует тот же Питон с обертками над нейтивными либами по этому стандарту для игрищ с большими вычислениями.
V>Для Эльбруса это всё доступно изначально как часть стандартной поставки их Линухов (ОС Эльбрус).
Это для линейки. Её одной — недостаточно. Возвращаемся к вопросу коммерческой применимости — сколько (в % рынка) у нас занимают вычисления линейной алгебры?
А для простого бизнеса нужно быстрое исполнение java, js, C#. Нужны библиотеки/фреймворки с быстрым разбором и генерацией XML/json/HTML. Нужны всякие преобразования над картинками, в основном png и jpeg.
Нужна видеокомпрессия/декомпрессия.

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

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

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

V>Я рядом говорил — примерно в 10 раз ускорение от наихудшей наивной реализации.
Хотелось бы каких-то подтверждений.
V>У Эльбруса там у автора получилось ускорить в 200 раз от наивной реализации.
Вы так и не указали, откуда 200 раз. Я увидел 1/10 от быстродействия EKL.
Можете процитировать фрагмент статьи с цифрами, на которые вы опираетесь?

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

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

V>Который буксует уже 10-й год?
V>Два супердорогих провальных проекта — P4 и Itanium.
Итаниуму — 20 лет. Из которых примерно 15 понятно, что он мёртв.
V>Ребят, это приплызд, на самом-то деле.


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

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

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

V>Нужно, просто страшно поддерживать.
V>Например мы не поддерживаем.
А чего не поддерживаете-то? Правильно: на ваших задачах AVX512 не даст ощутимого выигрыша.
Иначе — поддерживали бы. Риска ведь никакого нет — ваш код не станет хуже работать на avx2 после включения поддержки avx512.

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

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

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

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