Как стать автором
Обновить

Комментарии 809

Спасибо за статью. Есть пара добавлений или комментариев.
Начну с несолгасия. Думаю, что для некоторых серверных задач, Эльбрус (VLIW) вполне подходит. Конечно в общем случае своя архитектура более затратна, по приведенным вами причинам, но Itanium занимал свою серверную нишу. И в качестве развития, интересной архитектуры, это может сработать. Еще одна, очень хорошая ниша, это DSP обработка, например TI имеет свою VLIW архитектуру для DSP ядер, и на этих задачах (числодробилка) VLIW может дать фору и CISC и RISC. Но тогда да, нужно отказываться от бинарной трансляции и упрощать сам кристалл.
Замечание по проблем работы с памятью дополню тем что все еще более сложно, ведь когда происходит прерывание, нужно как то завершить текущие операции памяти, и если их несколько и они в разных адресах (не в одной линейке) то это требует освобождать конвеер и так далее. То есть да, модель работы с памятью для VLIW не эффективна для процессоров общего назначения.
Ну и по поводу экосистемы, без которой не возможно развить конкурентоспособный продукт. Да, Elbrus Tech Day это был прорыв, и открытие описания команд тоже, но это все настолько закрыто, что данные вещи это капля в море.

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

Собственно, именно это мы и видим на примере GPU и NPU. Задачи DSP в современных устройствах тоже решаются на отдельных ядрах - вроде тех же ядер на Hexagon (VLIW), на которых собираются модемы Qualcomm. Я могу поверить в будущее модифицированного Эльбруса как архитектуры для DSP-процессоров или иных ускорителей - но не в будущее Эльбруса как application processor.

А Itanium в серверном пространстве - это отдельная история. Идёт она от того, что несколько весьма крупных клиентов купились на обещания Intel, и сделали свои новые системы на Itanium. Вот только потом появился AMD64 (сейчас известный как x86-64) и всем вскоре стало ясно, что IA-64 не взлетает - но системы уже были сделаны и стали legacy. Поэтому Itanium в зомби-состоянии и продолжал существовать весьма долго. Только недавно его официально закопали, свернув линейку и обрубив поддержку.

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

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

Про itanium, тоже частично согласен. Но я имел в виду, что в этой сфере можно найти сегмент где будет достаточно эффективен VLIW и если речь идет об поддержке и развитии архитектуры (я лично считаю что так и нужно делать) то это один из возможных вариантов

Скажем так, на некоторых серверных задачах недостатки Эльбруса становятся минимальными, но при этом всё равно он будет проигрывать топовым RISC/CISC'ам. В HPC, где мы молотим много плавучки и паттерны доступа к памяти несложные - Эльбрус может показывать близкие к максимумам цифры. Но HPC - это лишь часть серверного рынка, причём довольно специфическая, там вообще на GPU переходят часто. А если ваши сервера хостят сайтики - там перформанс Эльбруса будет стремиться ко дну.

Скажем так, на некоторых серверных задачах недостатки Эльбруса становятся минимальными,

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

А если ваши сервера хостят сайтики - там перформанс Эльбруса будет стремиться ко дну.

Так и есть, когда то Sun позиционировал Niagarа для сервера для веб серверов, и AMD если нужно высокопроизодительная считалка. Остается вспомнить что МЦСТ изначально Московский Центр Спарк (SPARC) Технологий.


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

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

Но HPC — это лишь часть серверного рынка, причём довольно специфическая, там вообще на GPU переходят часто. А если ваши сервера хостят сайтики — там перформанс Эльбруса будет стремиться ко дну.
Я не думаю, что Эльбрус вообще планировали для десктоп приложений, это случилось скорее вынужденно.
А делали его скорее для вояк и как раз для HPC применений – суперкомпьютеры, симуляция ядерных взрывов (испытания давно не проводят, а считают на суперкомпьютерах), обработка данных радаров раннего обнаружения и прочее.

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

К тому же, можно посмотреть на историю Эльбруса. Там будет видно что его изначально позиционировали как убийц Pentium, что подразумевает и десктопные применения. В общем советую почитать материалы времен когда Бабаян работал в МЦСТ. Кажется в каких-то журналах были интервью и уже тогда МЦСТ позиционировали процессор как универсальный, и именно акцентировали внимание на том что VLIW традиционно таковым не считаются, но они стараются и делают и верят в свой успех.

В общем советую почитать материалы времен когда Бабаян работал в МЦСТ.
Бабаян в 1992 году основал центр SPARC-технологий, который позднее стал МЦСТ.

Если они всерьез позиционировали Эльбрус как универсальный, зачем тогда основывать центр по RISC технологиям и развивать и выпускать линейки RISC процессоров?
Первый RISC процессор они выпустили еще в 2001.

В интервью тех времен об этом кажется тоже говорилось - потому что на разработку деньги были нужны. А SPARC в тот момент можно было лицензировать и относительно быстро сдать заказчику.

SPARC лицензировали в 1992 году, а RISC процессорами начали заниматься еще в 1986, так что связи тут нет — они изначально развивали RISC направление
В ИТМиВТ Владимир Пентковский принимал участие в разработке суперкомпьютеров Эльбрус-1 (1978) и Эльбрус-2 (1984). В 1986 году он возглавил проект 32-разрядного микропроцессора Эль-90. К 1987 году логический дизайн будущего микропроцессора был завершен, а в 1990г произведены первые прототипы. В Эль-90 сочетались концепция RISC и архитектура Эльбрус-2.

Основные характеристики Эль-90:

выдача до трех команд за такт
32-разрядная архитектура
упрощенный набор команд (по сравнению с Эльбрус-2), большинство команд исполняются за один такт
аппаратная поддержка языков программирования высокого уровня
исполнение по предположению
изменение порядка исполнения команд
предсказание ветвлений
переименование регистров
раздельные кэши команд и данных по 32KB
конвейеризованное устройство вещественной арифметики
поддержка многоуровневой иерархии памяти, кэш первого и второго уровня
поддержка мультипроцессорности (до 10 процессоров)
поддержка отладки, мониторинг производительности
режим «сверхнадежных вычислений» (несколько процессоров независимо производят вычисления и сравнивают результаты, а если результаты расходятся, считают заново). Этот режим требовался, потому что используемая в Эльбрус элементная база была недостаточно надежной для некоторых военных приложений.

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

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

Я прочитал интервью Бабаяна, там нигде не говорится, что они готовы конкурировать с Пентиумом, только что там используются схожие принципы суперскалярности, которые они начали разрабатывать как комерческий продукт еще до HP, IBM и Intel (и кстати бывший их сотрудник Пентковский работал над разработкой Пентиума). Что они хотят ставить VLIW Эльбрусы на десктопы там вообще ни слова. Зато есть про Эльбрус-90, который RISC.
Нет, это за «Эльбрус-90микро», это другая линия. Э-90 не суперскаляр, простой RISC, независимая от Е2К вещь.

И еще раз, что они почти всю дорогу занимались и RISC направлением, как раз хорошо показывает, что они не считали, что VLIW универсальный и «подойдет для всего», как говорите вы.

Есть простой ответ, открываем страничку про Эльбрус на сайте МЦСТ и читаем

Микропроцессор «Эльбрус» (1891ВМ4Я) – универсальный микропроцессор

Можете пойти дальше, в статью 2001 года (ее вообще в контексте данной статьи очень забавно почитать), там в общем-то прямое сопоставление идет с классическими подходами, нигде нет ничего про какую-то мифическую узкую специализацию.

Можно в общем пойти копать дальше, почитать публикацию Бабаяна в Спрингере (она правда на английском по очевидным причинам) - она в более сжатом виде повторяет ровно то же самое.

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

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

P.S. И в соседней части этой ветки Вы вообще об истории МЦСТ спорите с человеком, который очень много лет проработал в этом МЦСТ, мне честно говоря кажется что Вам просто стоит его послушать и принять к сведению.

Рассказываю. В 90х были тяжёлые времена и Мцст тесно сотрудничали с Sun, занимаясь разными проектами по Sparc и в окрестностях, чтобы прокормиться. Но параллельно пытались развивать свою линейку Эльбрус как General purpose cpu, в том числе активно пытаясь найти деньги в Штатах. Всё это закончилось ничем, а в итоге когда военные в конце 90х пришли и сказали "дайте нам хоть что-то работающее ", единственный реальный вариант было взять простенький Sparc (на который была лицензия) и его сделать. Т. к. Эльбрус был крайне далёк от производства в то время. Собственно, так и получилось исторически 2 линейки General purpose cpu в Мцст

В 90х были тяжёлые времена и Мцст тесно сотрудничали с Sun, занимаясь разными проектами по Sparc и в окрестностях
Разработку RISC Эльбруса-90 они начали еще в 1986 году, еще в ИТМиВТ, задолго до сотрудничества с Sun.

Без сотрудничества с Sun они бы не получили лицензию на Sparc. В любом случае, даже если так, это никак не меняет того, что я написал

Это меняет причину-следствие.
С Sun они стали работать и лицензировать SPARC потому что уже ранее сами разработали RISC процессор. А не сделали RISC процессор, потому что от безденежья пришлось работать с Sun.

То есть у них был сознательный выбор RISC архитекторы и было желание заниматься этим направлением.

Они выпускали Спарки что бы как то выжить в условиях экономического кризиса.

HPC - это далеко не только серверный рынок в общем-то. Задач, упирающихся в числодробление, хватает в, например, мульмедиа и всяческой цифровой фотографии. И эти задачи обычно решают специализированным VLIW DSP. В приложении к военным задачам речь идет о работе с большими архивами спутниковых фото, например.

Ну это не совсем так. Если посмотреть на всем известный top500 суперкомпьютеров - там, кажется, в первом top100 ноль с VLIW DSP. top1 вообще без акселераторов, просто ARMv8 с SVE, потом идет пачка с nVidia V100 и nVidia A100, еще есть китайцы с кастомным RISCом и китайцы с Xeon-Phi подобным собственным акселератором (который есть 128 in-order RISC ядер собственной разработки), есть еще пачка с Xeon Phi и несколько где просто много x86 процессоров без акселераторов (в основном Epyc'ов).

Я конечно допускаю что кого-то упустил, но в массе своей это видеокарты или RISC-акселераторы.

DSP (и некоторые из них - VLIW) используются, но скорее в условно мобильных устройствах (начиная от смартфонов, заканчивая всякими радиоприемниками и военным оборудованием).

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

Автор выше говорил про HPC - для этого рейтинг очень даже адекватный.

Нет. FAAGN может занять все места одновременно. Просто на своих продакшен кластерах.

Да, даже Яндекс легко может занять первое или около того место. Если FAAGN не участвует. Тоже на своем обычном продакшен кластере.

Но никого из них нет. Значит рейтинг очень узкий и специфический. Клуб тех кому это интересно или зачем-то нужно.

Для проверки себя оцените количество серверов в одном датацентре Яндекса. Количество серверов в одном датацентре Гугла получить из этой цифры можно легко. По разнице количества этажей в этих датацентрах.

Нет. FAAGN может занять все места одновременно. Просто на своих продакшен кластерах.

HPС - достаточно определенный класс задач со своими узкими требования. Туда продакшн кластера IT компаний не попадают в принципе. Как и задачи, которые там типично гоняются, без адаптации (читай переписывания с применением других подходов) на не-HPC системах запустить не получится.

Но никого из них нет. Значит рейтинг очень узкий и специфический. Клуб тех кому это интересно или зачем-то нужно.

И это так, но обсуждение то про HPC идет, а это очень специфический и действительно узкий рынок. Там свои принципы построения систем, своя специфика написания ПО, своя специфика задач.

Для проверки себя оцените количество серверов в одном датацентре Яндекса. Количество серверов в одном датацентре Гугла получить из этой цифры можно легко. По разнице количества этажей в этих датацентрах.

А это не имеет значения, их датацентры призваны решать другие задачи и поэтому не оцениваются критерями HPC-систем.

Да прямо на этом сайте есть про обычные облака https://www.top500.org/news/fugaku-holds-top-spot-exascale-remains-elusive/

Outside of this, we saw quite a few instances of Microsoft Azure and Amazon EC2 Cloud instances fairly high on the list. Pioneer-EUS, the machine to snag the No. 24 spot and the No.27 Pioneer-WUS2, rely on Azure. The Amazon EC2 Instance Cluster at No. 41 utilizes Amazon EC2.

Это сделал не Амазон, а их клиент. Без доступа к dom0, всей сети, всему железу и прочим хакам возможным на железе.

Нет никакого специфично железа. По крайней мере массово. У всех x86/arm и видеокарты. И датацентры строят все одинаково. 10Гбит сеть с простроенная по принципам крупных датацентров это лучшее что сейчас возможно. Сейчас потихоньку 100Гбит в мир идет. И тоже в обычных датацентрах.

Все остальное уже просто хуже. По любой характеристике. (кроме распила бабла, вот тут типовое решение гораздо хуже выходит)

НЛО прилетело и опубликовало эту надпись здесь

Открываем обычную википедию https://en.wikipedia.org/wiki/InfiniBand И видим примерно те же скорости которые дает типовая 100Гбит оптика.

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

НЛО прилетело и опубликовало эту надпись здесь

Примерно те же скорости между двумя узлами и примерно ту же скорость обмена информацией внутри супера — не одно и то же, если что. Вы на 100 GB сможете организовать сеть, в которой 50% узлов передают одновременно данным другим 50% узлов без задержек и падения скорости?

По поводу точных цифр не уверен, но примерно да. Вероятно все таки поменьше, но не настолько как выдумаете.

Там много одновременно передавать можно. Типовая архитектура сети в датацентре много чего позволяет. Вот тут, например, хорошее описание. Как сейчас сети строятся. https://habr.com/ru/company/yandex/blog/550298/

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

Что-то дешевле типового промышленного решения? И не хуже по характеристикам? Все строители ДЦ быстро переключатся на более выгодное решение. И оно тут же станет типовым промышленным решением.

НЛО прилетело и опубликовало эту надпись здесь

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

То что вы говорите было востребовано лет 10 назад. Во времена массовых гигабитных сетей. Сейчас во времена массовых 100 гигабитных сетей это все стало не нужно. Массмаркет достиг достаточного качества чтобы вытеснить все остальное.

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

НЛО прилетело и опубликовало эту надпись здесь

У биткоина одновременно сошлись звезды. Абсолютная простота и неизменность алгоритма.

В реальном мире алгоритмы гораздо сложнее и изменчивее. Аналитики подумали, поменяли формулу ипопросили внести изменения. Такое раз в полгода-год везде бывает. Все асики выкидываем и заказываем новые? Ну так себе план.

Там где эти звезды сходятся, например декодирование/кодирование h.264, используют специфичные и очень массовые схемы. У компьютера общего назначения такое не пройдет.

Это сделал не Амазон, а их клиент. Без доступа к dom0, всей сети, всему железу и прочим хакам возможным на железе.

  1. Касательно места №27 - посмотрие что такое "NDv4" инстансы в Azure и чем они отличаются от "просто облака". TLDR (если не хотите сами искать) это специальные инстансы под HPC, задизайненные с учетом требований данной отрасли, это не на обычных Compute инстансах делается.

  2. Касательно Amazon'а - история чуть другая, это уже чуть ближе, как минимум тем что это те же самы инстансы, но тут посмотрите на разницу 40-ого места где расположился HPC поверх Amazon EC2 с тем что в топ10, по производительности.

Надеюсь после этого, вопросы о том почему делать HPC поверх облаков это не очень хорошая идея - отпадут.

Нет никакого специфично железа. По крайней мере массово. У всех x86/arm и видеокарты. И датацентры строят все одинаково. 10Гбит сеть с простроенная по принципам крупных датацентров это лучшее что сейчас возможно. Сейчас потихоньку 100Гбит в мир идет. И тоже в обычных датацентрах.

Не совсем, в топе - специфичное железо. Дальше от типичных датацентров это отличается как миниму интерконнектами. Вот Вы говорите про 100 гбит в секунду в обычных датацентрах, а посмотрите какие интерконнекты были в HPC в 18 году (подсказка: 200 Гбитные Infiniband'ы, а сейчас уже 400 гбитные предлагают). Посмотрите на latency по infiniband по сравнению с обычными сетями.

Принцип построения систем отличается, потому что в разных ситуациях важны разные вещи., толкьо и всего. У, как это модно называть, гиперконвергентных компаний требования где намного более выгодно (если ты крупный) взять что-то что можно легко заменить и что можно покупать в масштабах намного больших, чем у HPC, а заодно с меньшими требованиями и к задержке и к надежности всей системы. Для них - нормально когда у тебя что-то случилось и датацентр немного отключился на денек-другой, или когда у тебя компоненты выходят из строя каждый день (нормально пока поддерживается общая емкость системы). Для HPC - такое недопустимо, зато допустимо потратить больше денег и времени на строительство системы, которая на минимальной площади при минимальных энергозатратах способна в долгосрочном периоде гонять условную задачу по свертке белка с гарантией на получение результата. На это влияют прежде всего задачи которые там крутятся и люди, которые эти задачи там реализуют (не надо считать, что ученые - хорошие программисты или что в научных центрах много хороших и умных людей, которые смогут организовать адекватные по надежности системы вычислений поверх commodity hw со всеми его недостатками)

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

А вот что людям проще отвалить кучу бабла за менее эффективную и более дорогую систему с которой проще обращаться это беда. Отдать контракт тому же Амазону. Их инженеры с радостью все поддержат и даже софт напишут по ТЗ от ученых, если надо. Выйдет дешевле в итоге.

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

Смотрите, вы заявляете что все отлично, я правильно Вас понял? Если да, то расскажите, почему разница между топ1 и hpc поверх амазона в 44 раза (по реальной производительности)?

А вот что людям проще отвалить кучу бабла за менее эффективную

Сравните показатель theoretical peak и наблюдаемое в linpack по top500. Посчитайте для топ1 и для амазона.

Потом посчитайте стоимость того кластера на амазоне. Посмотрите на стоимость сопоставимых по производительности HPC кластеров. Потом попробуйте получить допустим в 5 раз более производительный кластер от амазона.

Их инженеры с радостью все поддержат и даже софт напишут по ТЗ от ученых, если надо.

Покажите пожалуйста, где такая услуга у Амазона и сколько она стоит?

Смотрите, вы заявляете что все отлично, я правильно Вас понял? Если да, то расскажите, почему разница между топ1 и hpc поверх амазона в 44 раза (по реальной производительности)?

Потому что так сделали. Кэп. Посмотрите начало ветки.

Это место доказывает что архитектура ДЦ Амазона подходит для гоняния этих тестов. Они (Амазон) не заняли там все места просто потому что не хотят. Серверов и ДЦ у них хватит.

Потом посчитайте стоимость того кластера на амазоне. Посмотрите на стоимость сопоставимых по производительности HPC кластеров. Потом попробуйте получить допустим в 5 раз более производительный кластер от амазона.

Покажите пожалуйста, где такая услуга у Амазона и сколько она стоит?

Это не для обычного человека. И даже не для обычного юрлица. Прайс никто писать на такое не будет, потому что смысла нет. Объявляем тендер, приглашаем поучаствовать. Амазон, Оракл, МС и тому подобных. Они с радостью придут со своими инженерами серверами и предложениями. Тендеры обычно открытые, если их прилично будет то и средняя цена сформируется.

Прайс по итогу выйдет меньше чем строить что-то кастомное. Считаем первоначальную плату за запуск + плату на обслуживание за все годы работы. Срок службы закладываем около 10 лет. Дальше уже дешевле выкинуть и построить заново, чем поддерживать устаревшее.

Они (Амазон) не заняли там все места просто потому что не хотят. Серверов и ДЦ у них хватит.

Я так и не увидел доказательств того, что это возможно.

Прайс по итогу выйдет меньше чем строить что-то кастомное. Считаем первоначальную плату за запуск + плату на обслуживание за все годы работы.

Жду сравнение цены типичного тендера на подобные услуги (допустим выигранное амазоном) с ценой на создание и поддержание кластера. Раз сказали что открытые - легко будет найти и показать.

Я так и не увидел доказательств того, что это возможно.

Вот же сделали. Сделал не Амазон. Значит это был не bare metal и не весь ДЦ.

Outside of this, we saw quite a few instances of Microsoft Azure and Amazon EC2 Cloud instances fairly high on the list. Pioneer-EUS, the machine to snag the No. 24 spot and the No.27 Pioneer-WUS2, rely on Azure. The Amazon EC2 Instance Cluster at No. 41 utilizes Amazon EC2.

Это говорит нам что архитектура Амазона подходит для запуска этого теста. Это просто факт. Тест был запущен, отработал и показал разумные циферки. Дальше тупо накидываем ядра/видеокарты и вперед.

157 тысяч ядер. Допустим по сотне ядер на сервер (это вероятно заниженная, но реальная оценка) Это всего полторы тысячи серверов. Амазон х10 выдаст легко в любом своем ДЦ. Добавляем что на современных серверах скорее всего больше 100 ядер и получаем совсем топ результат.

Жду сравнение цены типичного тендера на подобные услуги (допустим выигранное амазоном) с ценой на создание и поддержание кластера. Раз сказали что открытые - легко будет найти и показать.

За конкретикой идите к своему сенатору, или кто там деньги на такие стройки распределяет. Случайный человек в интернете вам покажет только общие соображения.

Массовое - всегда дешевле отдельной разработки.

Амазон понимает в содержании железа и проектировании ДЦ. И точно сделает это дешевле чем кто угодно другой. За исключением таких же монстров.

Гос и около заказы конторы вроде Амазона берут с радостью и активно торгуются друг с другом.

Итого нет ни одной причина почему у Амазона такое будет дороже чем кастомная разработка от людей которые понятия не имеют как дешево строить и обслуживать ДЦ.

Вот же сделали. Сделал не Амазон. Значит это был не bare metal и не весь ДЦ.

Так а где доказательство, что это не предел возможного-то? Я пока все равно не вижу.

Это говорит нам что архитектура Амазона подходит для запуска этого теста.

Для запуска теста подходит моя кофемашина (если там получить рута), чисто теореически. Или raspberry pi. Вопрос в том что ты будешь получать когда начнешь это все масштабировать, а потом вопрос в цене на решение.

Добавляем что на современных серверах скорее всего больше 100 ядер и получаем совсем топ результат.

Если вы немного покопаетесь по сайту амазона, вы без труда найдете точный ответ на то сколько у них ядер в серверах (а заодно какие частоты у них, кстати не забывайте, если будете смотреть по vCPU виртуальных, что надо чиселку там делить на 2, чтобы получить ядра, впрочем в тех местах где сказано сколько ядер на сервер об этом будет явно сказано под звездочкой). Это не сложно сделать, не надо будет спекулировать о том что у них есть, а чего нету. Проведите исследование, удивитесь немного.

За конкретикой идите к своему сенатору, или кто там деньги на такие стройки распределяет. Случайный человек в интернете вам покажет только общие соображения.

То есть это все домыслы? А как же ваши слова тут: "Тендеры обычно открытые". Это буквально значит что цена на тендер и условия будут известны даже Вам, если Вы поищите. Так что будьте добры, давайте без домыслов, пройдемся по фактам. Сначала с Вас такой тендер с ценой от амазона, потом продложим.

Так а где доказательство, что это не предел возможного-то? Я пока все равно не вижу.

Простите, какое доказательство вы хотите? Цифры говорят что было использовано заметно меньше полного ДЦ, я бы сказал что даже меньше 10% от полного ДЦ. Компьютерные системы такого уровня маштабируются только горизонтально. И иногда вертикально, наращивая этажи в ДЦ. Почему эту систему нельзя отмаштабировать совершенно непонятно. Все данные говорят что это можно сделать.

Для запуска теста подходит моя кофемашина, чисто теореически. Или raspberry pi. Вопрос в том что ты будешь получать когда начнешь это все масштабировать, а потом вопрос в цене на решение.

Вы же видели этот тест? С настройками для этого топа. Ну хотя бы чуть-чуть? Он опенсорс, можно смотреть. Вы его на кофемашине не запустите. И даже на малине не запустите.

То есть это все домыслы? А как же ваши слова тут: "Тендеры обычно открытые". Это буквально значит что цена на тендер и условия будут известны даже Вам, если Вы поищите. Так что будьте добры, давайте без домыслов, пройдемся по фактам. Сначала с Вас такой тендер с ценой от амазона, потом продложим.

Вы потеряли контекст. Перечитайте еще раз. Я процитирую сам себя:

Объявляем тендер, приглашаем поучаствовать. Амазон, Оракл, МС и тому подобных. Они с радостью придут со своими инженерами серверами и предложениями. Тендеры обычно открытые, если их прилично будет то и средняя цена сформируется.

Видите слово если?

Сейчас это довольно закрытая область где все держатся непонятно за что. За воздух. На этом можно осваивать огромные суммы. ТОП, круто, модно, свои сервера, науку двигаем. Ну как тут денег не выдать?

Нужно чтобы институты и ученые поняли что не надо за железки держаться, и начали давить на эффективность. Пусть ДЦ строят и обслуживают те кто это умеют. Это эфективнее. А институтам нанять разработчиков с уровнем кандидата наук в предметной области и уйти в типовые облака (сразу замечу что очередь разработчиков желающих поработать выстроится сразу, зарплату можно меньше чем в Гугле ставить. заметно меньше. науку продвигать люди хотят больше чем очередной джейсон перекладывать).

Эффективность всех рассчетов всего сразу возрастет. И денег меньше тратится будет, что тоже приятно. Есть и минус. Меряться больше нечем будет. У всех все одинаковое. Платим - получаем циферку.

Видите слово если?

А я прошу не среднюю цену, а пример одного такого. В общем все еще жду пример такого тендера.

Эффективность всех рассчетов всего сразу возрастет. И денег меньше тратится будет, что тоже приятно.

На это тоже жду доказательства.

Без примера и цифр не вижу смысла дальше продолжать беседу, в рамках домыслов можно вывести что угодно и как угодно, реальным оно от этого не станет.

> Разница по лейтенси и в 4 раза по скорости это тьфу же. Написать софт чуть-чуть по другому и все хорошо будет.

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

В качестве примера можете покопаться в scalapack, узнаете много нового.

top500 - он не про мультимедиа, а про научные вычисления. Это, в основном, плавучка. Мультимедиа - это целочисленные вычисления. Серверные ускорители для этого самого есть у, например, Xilinx и Intel. Правда, это сочетанные DSP+FPGA решения, афаик.

Плюс есть много разных чудес, где требуется большая пропускная способность, типа высокопроизводительного Data Acquisition. Например, в церне еще в конце нулевых, афаик, речь шла о десяткаях терабайтов сырой информации с детекторов в секунду - и эти терабайты нужно прожевать и отфильтровать мусор еще до того, как их отправят в хранение и реальную обработку. Надо бы поискать, как там выходили из положения, емнип, там до ASICов дело доходило.

top500 - он не про мультимедиа, а про научные вычисления. Это, в основном, плавучка. Мультимедиа - это целочисленные вычисления. Серверные ускорители для этого самого есть у, например, Xilinx и Intel. Правда, это сочетанные DSP+FPGA решения, афаик.

Вы определитесь, Вы про мультимедия или HPC. Если про HPC то top500 ровно про них.

Касательно мультимедия - на бытовом уровне ты найдешь DSP в некоторых бытовых устройствах (скорее всего разборав электропианино или купив полупроф звуковую карту). В остальном - какие-то совсем специализированные задачи. А что касается ускорителей мультимедия - популярные алгоритмы все таки предпочитают реализовывать в железе (у многих чипов есть те или иные ускорители видео кодирования и декодирования, например).

Плюс есть много разных чудес, где требуется большая пропускная способность, типа высокопроизводительного Data Acquisition.

Опять же это не имеет отношения к HPC как к области. Это отдельный свой вид задач и своих систем для решения. CERN действительно делал свои железки для своих целей (у них там по презентациям сырых данных с датчиков только на LHC - сотни тысячи террабит в секунду и десятки миллионов датчиков, это требует своих особых подходов). Но судя по их докладам (это один пример где есть информация о железе, так у них доклады почти по каждой отдельной системе есть) уже в хранении и обработке (кроме первоначальной фильтрации) нет ничего выдающегося - обычные сервера на Xeon'ах, без доп ускорителей. Что в общем и понятно, потому что масштабы такие, что легкодоступное железо выиграет у специализированных решений по общей цене обслуживания.

>Вы определитесь, Вы про мультимедия или HPC. Если про HPC то top500 ровно про них.

Я про HPC на целочисленных данных. Куда, в том числе, входят различные методы обработки картинок.

> В остальном - какие-то совсем специализированные задачи.

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

> А что касается ускорителей мультимедия - популярные алгоритмы все таки предпочитают реализовывать в железе

Железные реализации очень негибкие. Сейчас везде стараются засунуть если не процессор, то хотя бы FPGA.

Я про HPC на целочисленных данных. Куда, в том числе, входят различные методы обработки картинок

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

Картинки скорее будут на видеокартах или процессорах общего назначения гонять сейчас.

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

Есть, я выше написал об этом.

А в ДЦ найти их будет крайне сложно.

Железные реализации очень негибкие. Сейчас везде стараются засунуть если не процессор, то хотя бы FPGA.

Для частых задач - в самый раз.

Для более редких - процессоры, да, или ускорители конкретных частых операций (см все ускорители для нейронок).

Давайте вы будете говорить в общепринятых терминах

HPC, согласно общепринятым терминам, про вычислительные системы, намного превосходящие по мощности обычный ПК. Я специально поискал, прежде чем писать. Системы из top500 - это лишь один из вариантов, научная разновидность. Это не единственно возможный вариант.

А в ДЦ найти их будет крайне сложно.

Смотря в каком. Посмотрите на линейку серверных продуктов Xilinx, для начала.

HPC, согласно общепринятым терминам, про вычислительные системы, намного превосходящие по мощности обычный ПК.

Читая Википедию, читайте дальше первого предложения пожалуйста.

Смотря в каком. Посмотрите на линейку серверных продуктов Xilinx, для начала.

Как я сказал - в типичном.

Я не имею привычки пользоваться википедией в поиске определений.

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

Я не имею привычки пользоваться википедией в поиске определений.

В таком случаи в Вашем источнике читайте его целиком. А если то что Вы процитировали иесть полное - найдите более адекватный источник.

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

В сетевом оборудовании специализированный ASIC и процессор общего назначения для всего что не реализовано в железе.

Имею привычку пользоваться адекватными источниками и читать целиком. Серьезно, не надо меня учить, что такое HPC, уж в этом я разбираюсь точно не хуже вас.

В сетевом оборудовании специализированный ASIC и процессор общего назначения для всего что не реализовано в железе

https://docs.broadcom.com/doc/87842-PB

что такое HPC, уж в этом я разбираюсь точно не хуже вас.

Раз разбираетесь, то зачем продолжаете натягивать сову на глобус?

https://docs.broadcom.com/doc/87842-PB

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

Раз разбираетесь, то зачем продолжаете натягивать сову на глобус?

Вот из-за того, что разбираюсь, и пользуюсь термином так, как пользуюсь.

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

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

Судя по вашему тексту, надежды на дальнейшей продуктивный разговор я не имею, поэтому разговор сворачиваю.

Вот из-за того, что разбираюсь, и пользуюсь термином так, как пользуюсь.

Потому что разбираетесь, поэтому пользуетесь термином не так как это принято в IT среде? Ну что поделать.

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

Судя по вашему тексту, надежды на дальнейшей продуктивный разговор я не имею, поэтому разговор сворачиваю.

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

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

Но соглашусь с Вами в том, что продуктивный разговор в такой ситуации не возможен.

Потому что разбираетесь, поэтому пользуетесь термином не так как это принято в IT среде? Ну что поделать.

HPC в понимании "массо-параллельные вычисления на плавучке 64+ бит с широким интерконнектом" - это вообще не из массового IT, потому что там это практически не нужно. Это из околонаучных и инженерных применений и за их пределами встречается крайне редко, навскидку разве что в GIS и то не факт. Я вообще плохо понимаю, как в x86 попал высокопроизводительный тракт широкой плавучки, потому что в 90+ применениях из 100 он глубоко избыточен.

Именно поэтому top500 не про IT в целом и тащить его терминологию в IT неразумно, железячные компании типа оракла и гугла трактуют HPC в расширенном смысле, а для суперкомпьютерных вычислений нужно использовать какие-то уточнения.

Чип я привел как опровержение конкретного утверждения что в сетевом оборудование все, что не в железе, делается на процессоре общего назначения. Это не так. Бывает там и DSP и железячное ускорение look-up tables, и интегрированные FPGA и много всякого.

Судя по последним статьям и веяниям в разработке процессоров для России, на мой взгляд, можно выделить три варианта развития:

  1. Упрощение и специализация архитектуры e2k для DSP и других подходящих областей применения, а также для военных заказчиков.

  2. Разработка процессоров Elbrus ARM для коммерческого использования.

  3. Разработка нового процессора на базе RISC-V общего назначения.

Вариант 1 желательно развивать с точки зрения независимости от других архитектур и политических решений, но не замахиваться на что-то большее и рекламировать несбыточное "нанотехнологичное" будущее. Необходимо также оценить перспективы вариантов 2 и 3, и возможно выбрать из этих вариантов единственный. Важно иметь одну открытую архитектуру для использования всего многообразия open-source софта и иметь минимум два направления для обеспечения конкуренции центров разработки.

П. 2 - это процессор Байкал. П.3 - Syntacore (теперь Yadro).

А вот что делать с п.1 - вопрос дискуссионный. DSP у нас делается другими разработчиками и тащить туда e2k смысла нет как по мне.

Ну мне кажется Вы сужаете проблематику. В РФ есть не только Эльбрус. Есть еще НИИСИ с Комдивами (вполне себе собственное MIPS64 ядро), Есть Модуль (тоже с собственнsv MIPS32ядром) для космоса делают. У них есть и решения на базе покупных ARM ядер. Есть еще Элвис (https://habr.com/ru/company/embox/blog/329170/) тоже с ARM ядрами. Есть Байкал-Электроникс (https://habr.com/ru/company/embox/blog/567782/) я уже не говорю об DSP решениях например multiclet (https://habr.com/ru/company/embox/blog/265059/) и решениях с микроконтроллерами. Поэтому на мой взгляд не нужно выбирать между вариантами 2 и 3, а еще больше развивать экосистему. С необходимостью развития Эльбрусов полностью согласен, только на мой взгляд нужно определиться с их нишей и развивать полезные качества и развивать экосистему. Кстати у МЦСТ есть собственные RISC ядра (SPARC) вполне себе хорошие для своего класса задач (даже в таблице он присуствует Эльбрус-R2000) Зачем спрашивается Elbrus ARM.

Согласен, выпускаются варианты процессоров, в основном для специализированного применения. Однако отсутствуют внятные (пускай даже с учетом дотаций) предложения по технике общего назначения. Если была бы возможность заменить при желании например, часть офисных ПК и занять пускай 0,1% рынка, то это было бы настоящим успехом. Почему для данного сценария выглядят перспективно ARM ядра - из-за их широкой поддержки (большей, чем у остальных упомянутых архитектур) и ARM64EC (для Windows).

ARM64EC (для Windows).

Ой ну вот приехали, вбухиваем миллиарды в развитие собственных процессоров, для того чтобы запускать на них закрытый проприетарный не свой код и платить за это деньги? По вашему китайцы тоже для своих ПК рассматривали Windows? Или Вы считаете что для 0.1% рынка жизнено важна поддержка Windows, в которую прийдется самим вкладываться, Майкрософт такие объемы не заинтерисуют.
И это я уже не говорю, о проблеме развития экосистемы для решения предназначеных для него задач, ведь только создание процессора, это пусть большая и сложная часть работы, но далеко не единственная.

Прошу прощения, что врываюсь в дискуссию. Но по каким признакам multiclet это DSP?

Во первых, они себя сами так позиционировали. Исторически это была технология для слуховых аппаратов с низким потреблением. А потом уже появились какие то идеи по применению.
Я же имел в виду что это не процессор общего назначения, но имеет право на существование в определенных сегментах. Например подход когда обсчитывают параллельно много ядер сейчас во всю применяется в GPU

ИМХО вариантов всего 2:
1. Продолжаем изобретать колесо и впаривать его по госзаказу, потому что по доброй воле никто не купит.
2. Готовимся к новой «холодной войне», изоляции и идем в разнос, т.е. повторяем подвиг AMD фрезеруем условный Ryzen 5xxx под электронным микроскопом, делаем «красный» клон на каком-нибудь 200нм техпроцессе и показываем кузькину мать фак Западу вообще и копирастам правообладателям в частности.
делаем «красный» клон на каком-нибудь 200нм техпроцессе
и получаем производительность как у Pentium 3. Занятная получится кузькина мать, особенно когда придется по трое суток ждать, пока базы в 1С прогружаются.
НЛО прилетело и опубликовало эту надпись здесь

Скорее России никто оборудование такого же уровня (не говоря про лучше) не продаст, а если и продадут, то можно посмотреть сколько времени взлетал (хотя, кстати, взлетел ли?) 65нм техпроцесс в РФ.

НЛО прилетело и опубликовало эту надпись здесь

Я не был бы так уверен, что на это закладываются. На старых техпроцессах заказывают потому что на них очередь ожидания из крупняка уже постепенно заканчивается и там можно получить готовое изделие за разумное время, а не когда-нибудь года через 3-4.

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

НЛО прилетело и опубликовало эту надпись здесь

И все равно Вы преувеличиваете значимость и ценность России в данном контексте. Надо понимать что в ситуации если Россия решит поссорится с Европой и США, то и сотрудничество с Россией для Китая обернется кучей санкций. Как рынок сбыта США и Европа куда более ценны для Китая, чем Россия (Россия по сути маленькая страна, притом беднее чем та же условная Германия, а значит и покупательная способность ниже).

И Вы забываете, что если допустим будет такой сценарий что России будет закрыт доступ к TSMC cовсем, то у нее и выбора особо не будет кроме как продолжать сотрудничество с Китаем, а значит тому какие-то поблажки делать и смысла нет, все равно у партнера не будет другого выбора.

Меня-то зачем агитировать?
клон на каком-нибудь 200нм техпроцессе
Увеличиваем размер в 10 раз и получаем кристалл 10x10 см, с тепловыделением как у печки?
Ядерная зима близко.

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

А лицензии где брать?
А где китайцы взяли? Что-то купили, что-то подсмотрели, что-то скоммуниздили, в результате уже имеют более-менее свой процессор. Не удивлюсь, если лет через 5 начнут конкурировать за low-сегмент SoHo.
У китайцев как раз лицензии на х86 честно купленные, ни один юридический комар носа не подточит.
Вы вряд ли погружались в проверку юридической чистоты китайского процессора, так что можете лишь предполагать, как и я. Впрочем, речь о другом: если партия скажет надо — что китайцы, что мы сделаем, как — уже второй вопрос. В тех же условиях изоляции вопросы лицензионной чистоты будут не 33-ми, а просто никакими.
Китайцы купили фирму VIA, у который в 1990-х была честная лицензция на x86.

Они не покупали VIA, а по контракту сделали с ними совместное предпоятие.

VIA в 99-ом купила Cyrix (то что от них осталось) у National Semiconductor, который купил Cyrix как компанию несколькими годами ранее, и лицнезию на x86 и на еще пачку патентов и технологий VIA получила именно от них (там по сути была покупка IP, так как инженеры в оснвном разбежались уже к тому моменту). Вообще история x86 до середины 2000-х была похожа местами на санта-барбару, ее довольно интересно почитать.

Вы вряд ли погружались в проверку юридической чистоты китайского процессора, так что можете лишь предполагать, как и я.
В нее погружалось достаточно много людей, в том числе юристов Intel и AMD. И отчёты об этих погружениях доступны.

У китайцев есть 2 x86-совместимых процессора:

  1. Zhaoxin - это совместное предпрятие с VIA, у которой есть лицензия с правой помощи разработки другим (еще со времен как они купили Cyrix, который очень щедрую лицензию получил, кажется, в 80х от интела, как и AMD впрочем)

  2. Hygon - это совместное предприятие с AMD, про него уже были упоминания в этом треде.

Оба - лицензионно чистые.

И я скажу еще и в этом треде - не надо переоценивать китайцев в плане того на что они готовы пойти. Также как не надо недооценивать последствия шага "партия сказала сделать нелецензионный клон x86" для них и их взаимоотношения с другими странами.

Да что ж на меня так все набросились за китайцев? ;) Ну честно купили — так купили, возможно, как возможно, что-то и не вполне купили. Я ж их не осуждаю, а хвалю. И не надо тыкать в меня лицензией из 90-х, они выпустили не 8088, а вполне себе актуальный процессор. Для внутреннего потребления — сойдет, если партия сказала «импортозамещение» — НИОКР ответит: сделаем! А насколько их волную «последствия» мы уже видели на примере 5G: если это вопрос принципиальный, китайцы упрутся рогом.

30 примерно лет назад участвовал в решении задачи по геометрическому преобразованию картинки. Делать это надо было быстро и мы взяли VLIW приставку к компу Электроника 60, предназначенную для БПФ, заменили ПЗУ с микрокодом на быстрое ОЗУ и... работало это быстрее БЭСМ-6. Вывод по VLIW процессорам следующий - для специфических задач их реальное быстродейстродействие может быть прекрасно (если необходимую математику загружать, как микрокод), ну а для серверной ОС и стандартных задач не подойдет.

30 лет назад даже "спектрум" работал быстрее БЭСМ-6)

Понимаю, что вы больше словца красного ради спектрум приплели, но все же оригинальный спектрум использовал крайне примитивный z80, который был медленней бэсм-6, по крайней мере по рабочей частоте. :-))

Вообще, сравнивать БЭСМ-6 со Спектрумом — дело неблагодарное, но если брать 1991-й год, тогда уже были прокачанные клоны спектрумов с процессором на частоте 7МГц. Простые операции (пересылка данных, сравнение, арифметика регистр-регистр) z80 выполнял за четыре такта, т.е. быстродействие его на них составляло 1.75 млн операций/с. Если верить Вики, быстродействие БЭСМ-6 составляло 1 млн операций/с, правда, не указано, каких.
Так что формально может быть и быстрее. С другой стороны, у z80 это 8-битные операции, а БЭСМ-6 имела 48-битное слово, и нативно умела в вещественную арифметику.
Я думаю, там в память упрётся. Разные источники пишут, что считывание из ОЗУ на ферритовых кольцах занимает от 10 до 25мкс.

Вообще, сравнивать БЭСМ-6 со Спектрумом — дело неблагодарное

Согласен, сравнение телеприставки с большой машиной смешно.

прокачанные клоны спектрумов с процессором на частоте 7МГц.

Но сравнивать модификации начала 90-х с машиной середины 60-х не менее странно. Давайте для приличия возьмем оригинальный процессор Z80 конца 70-х, имевший частоту в 2-3 МГц.

Возможно ли на суперкомпьютере оптимизировать бинарный код под VLIW так, чтобы решить указанные в статье проблемы с ручной доводкой всего софта? Большую часть ПО достаточно перекомпилировать, скажем, раз в год (или в месяц, если патчи безопасности регулярные нужны), возможно, с генерацией достаточно оптимального кода справится один из топовых российских суперкомпьютеров (на процессорах Интел). Идея очевидная, но почему-то нигде не разбирается, осуществимо ли это.

>> на суперкомпьютере оптимизировать

Чтобы что-то оптимизовать на супер-компьютере, вначале надо написать оптимизированный софт для супер-компьютера (т.к. производительность суперкомпьютеров сейчас преимущественно достигается через SIMD/GPGPU).

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

Если кратко, то это утопия

А как же CI/CD с компиляцией раз в год?

Именно это и делают в DSP. А для процессора общего назначения, тем более в многозадачной ОС - как вы это себе представляете?

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

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


Но они могут служить для массового производства российской вычислительной техники для держсектора.
Как по мне это идеальный кандидат чтобы заменить банальные кучи рабочих станций для разного рода структур вроде вояк/милиции/бти и прочее и прочее.

Да, это все равно выйдет дороже чем просто купить базовые компы на пентиуме/рязань3. Но зато есть и плюсы:
1) часть денег остается в стране
2) в стране поддерживаются и создаются специалисты высокого уровня

Есть конечно минусы, и их немало:
1) впереди все еще немалое количество софта, которое придется оптимизировать/портировать
2) это просто дороже (хотя наверно этот пункт нужно ставить первым)

Но это все перекрывается двумя главными проблемами:
1) МЦСТ работает по модели «только держзаказы, на частных клиентов плевать»
2) МЦСТ к ит-сообществу/энтузиастам развернуто попой, в результате не использует довольно большой пласт мотивированной и практически бесплатных (для них) мозгов, по-сути добровольно отказывась от отличного буста для продвижения и совершенствования их продукции

ИТОГ: как это не странно, но главный тормоз для Эльбрусов — действия и стратегия руководства МЦСТ.

П.С. это все мое неспециализированное ИМХО, я вполне могу ошибаться или что-то недопонимать.
ИТОГ: как это не странно, но главный тормоз для Эльбрусов — действия и стратегия руководства МЦСТ.


Руководство МЦСТ не раз давало понять, что всей политикой заправляет главный заказчик, у которого нет ни малейшего желания делать Эльбрус полностью открытым и привлекать сообщество к решению задачь (создание того-же оптимизирующего компилятора в замен lcc). Свои задачи они решают, на остальных — класть болт. Ситуация с «туманом» вокруг микропроцессоров Эльбрус очень выгодна главному заказчику.

Там набор факторов. С одной стороны МЦСТ это де факто - советское НИИ. Т.е. есть объективные проблемы с пониманием того, как работать в нынешних условиях, и желанием работать над продвижением своих продуктов. ОКРы сдаются - и хорошо.

С другой стороны есть понимание, что Эльбрус принципиально проигрывает. Отсюда дополнительный набор действий по наведению тумана.

МЦСТ обеими руками за то, что бы сделать Эльбрус полностью открытым и привлечь всех желающих к разработке софта (компиляторов, математических и прочих библиотек), но главный заказчик — против такого подхода. Так как вся работа ведется на деньги заказчика, то ничего поделать с таким решением нельзя.

Тут 2 момента.

Во-первых постоянные кивания "на заказчика" и рассказы про "обеими руками за"- это, скажем так, не совсем правда.

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

С одной стороны МЦСТ это де факто - советское НИИ. Т.е. есть объективные проблемы с пониманием того, как работать в нынешних условиях, и желанием работать над продвижением своих продуктов. ОКРы сдаются - и хорошо.

Повеселило. В нынешних условиях это как? Существенная часть продуктов работается по схеме тяп-ляп и в продуктив, и побольше хайпа. Откуда столько негатива к планомерной рутинной работе. Продвигать продукт возможно они и хотят (и нет такого разработчика, который не хотел бы широкого распространения своего детища), но есть объективные проблемы:

  1. Начиная с первого появления живых образцов, вокруг архитектуры клубится негатив со стороны "разбирающейся в теме общественности". Сражаться с ветряными мельницами в виде людей, которым и интелов с армами вполне достаточно - глупо. В МЦСТ явно есть на что потратить деньги без попыток снизить кислотность общественной среды.

  2. Отсутствует образ будущего со стороны государства и "общественности". Что нужно от машины на горизонте 10-15 лет, куда стремиться. На рынке, где архитектура Эльбруса всюду инородна нет смысла заниматься активным продвижением, поскольку на данный момент сам процессор страдает от бича российской действительности, когда нужно уметь и нашим и вашим, и Intel-ом прикинутся и быть не интелом, для всяких спец-контор.

  3. Существует заказчик (как говорят), которого процессор устраивает, так зачем распылять силы на продвижение, если можно их сосредоточить на продукте. Динамика прироста возможностей, у процессора вполне нормальная.

ИМХО, Эльбрус адекватный процессор, с вполне хорошей производительностью. Для разработки топовых процессоров способных тягаться с гигантами нужно ни одно уцелевшее неведомо как советское НИИ, хоть как-то причастное к изготовлению СБИС, а комплекс этих самых НИИ и опытно-производственная база, чтобы не нужно было на Тайване за 100500 регулярно дорожающих денег заказывать опытные образцы для натурных испытаний. Нужна политика партии на развитие своего, а не нынешнее "импортозамещение", где большая часть всего для галочки. Ну и образ будущего, когда все понимают, что мы строим и спланировано движутся к поставленной цели. Необходимость тратить транзисторы на транслятор в процессоре идёт из принятого ещё в 70-тые курса на облегчение цельнодратия с прогрессивных и умных американцев их прогрессивного и умного софта. Мы ж не можем у нас совок и лапки... Ну и для того, чтобы продукт вывести не через 30 лет, а сильно раньше. Когда у нас будет гордость и желание обеспечивать себя ПО, а не тырить или закупать заморское чудо чудесное, в товарных объёмах, тогда и достоинства Эльбруса раскроются, а влияние недостатков будет уменьшено. Хороший пример - Японцы, у которых две тяжёлые машины от фуджика собраны на своём, не так чтобы хайповом, процессоре. На АРМ-е, когда это не было ещё так модно и Спарке, который не особо признан в HPC.

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

Хотеть чего-то мало - надо ещё уметь, я как раз про это.

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

Китайцы в 90 делали дрянь, сейчас они делают нам почти всё чем мы пользуемся. Чтобы делать хорошо, нужно учиться. А учиться без проб и ошибок не выйдет. Чтобы оригинальная архитектура давала производительность на уровне мировых аналогов, нужно производство и разработку на уровне мировых аналогов. Где это взять, если не развивать самим? Кто даст технологии мирового уровня, какой дебил добровольно отдаст своё конкурентное преимущество в капиталистическом мире. Долго учится, подглядывая у лучших, а потом сразу сделать шедевр, который их всех затмит - такое бывает только в сказках. Совершенство - тяжёлый труд нескольких поколений, когда на старте имеем дрянь, которая со временем становится совершенней. Эльбрус стартовал с высокой базы, и сразу стал не полным дерьмом, а вполне рабочей вещью. Дальше совершенствование, ввод дополнительных блоков, улучшающих подклассы задач, сопроцессоров, и возможно вынос транслятора x86 в отдельный чип, а лучше постепенно от него отказываться в подлинейке моделей. Но это работа на будущее, а пока пользуемся тем, что имеем, и судорожно придумываем, что нам нужно в будущем, чтобы определить приоритеты развития платформы. Просто "сделайте нам как у них, только у вас, и также быстро" это не вектор развития, это констатация его отсутствия.

Эта статья и есть про то, где были сделаны ошибки и как их исправлять. Надо не "делать как у них" , а делать правильно, вне зависимости, делают у них так или по-другому. У нас же законы физики при пересечении границы не меняются. А упорствовать в своих заблуждениях - это и есть верный путь к провалу. Пусть будет дерьмово, зато не как у всех! Странная логика.

В статье поются дифирамбы Out of Order, который стал источником уязвимостей, с которыми крайне сложно бороться, а выключение его на превращало камень в тыкву. Причём проблемными оказывались и ARM и x86. Нужно ли нам в это болото?

а делать правильно

Никто не знает как правильно, поэтому слабые духом делают так же. Процессоры, которые пошли этим же путём, мы знаем, это и Байкалы. Мне кажется второй Байкал от МЦСТ будет лишним для рынка России, не отличающегося масштабами. А SPARC и собственный VLIW вполне хорошие запасные варианты.

И ещё раз. Да, я согласен, что Эльбрус для задач общего назначения странен. И не за счёт VLIW, а за счёт того, что там всё плохо с переключением задач. Как говорилось на какой-то конференции, она там крайне дорога. Я не думаю, что он пойдёт в массы. Скорее в массы пойдёт вполне предсказуемый Байкал, поскольку АРМ-ом и MIPS сейчас никого не удивишь. Эльбрус - это специальные и большие супер машины и числодробительные ускорители, там как кажется его удастся раскрыть. Но нет у нас сейчас даже намёков на интерес к таким машинам. А когда появится МЦСТ уже сдохнет и разложится. Поэтому пытаются найти нишу для архитектуры, с надеждой на светлое будущее.

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

В статье поются дифирамбы Out of Order, который стал источником уязвимостей, с которыми крайне сложно бороться, а выключение его на превращало камень в тыкву.

Все таки речь о неправильной его реализации конкретно интел, а не неправильном подходе. Большая часть проблем, например, обошла АМД вообще или бессмысленны на практике.

Ну вообще, проблему качественно разработали и досталось всем. AMD не исключение. Intel просто перегнул палку с оптимизациями. Другое дело, что с OoO сложно что-то сделать в подобных сценариях атак, поскольку есть общий кеш и исполнение кода, из будущего уже в настоящем. Чтобы качественно закрыть все возможности атак, нужно либо предисполнение делать на другом наборе кешей, либо эти кеши как-то особо закрывать, что явно угробит весь профит от данного предисполнения...

назови архитектуру, где Out of Order не имеет возможности организовать коллизии? как указал a0fs — если делать правильно — проще Out of Order вообще не реализовывать — дешевле и надёжнее.

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

НЛО прилетело и опубликовало эту надпись здесь

Дак вот в этом и шутка, что в 90х китайцы делали дрянь потому что не могли и не умели другого. Но даже в 90х после развала СССР в России было кому и где делать хорошие вещи, но почему-то не смогли.

Наверно потому что сказали нафига надо, мы у партнёров всё купим. И партнёры уверенно кивая, помогли с переходом.

совершенно непонятно, на основе чего вы делаете такие заверения на тему того, что там в головах у МЦСТ

На основе того, что я 10 лет отработал в МЦСТ разработчиком и присутствовал при такого рода обсуждениях внутри МЦСТ.

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

Единственный недостаток, если его можно таковым считать - зависимость от ARM. Но сейчас как раз поднимает голову RISC-V. Он уже начинает ставиться в микроконтроллеры, и на руки людям приходят первые образцы процессоров для рабочих станций.

К сожалению, в России разработки микропроцессоров на архитектуре RISC-V сейчас не ведутся. Да, есть пара фирм (почему-то зарегистрированных на Кипре) занимающихся изобретением своих софт-ядер RISC-V, но это не микропроцессор и тем более не высокопроизводительный. Я думаю, что с RISC-V у нас получится как всегда — через лет 5-7 властьимущие очнутся и начнут размахивать шашками, но будет поздно. Вместо того, что бы прямо сейчас возглавить разработку RISC-V и быть в авангарде, мы будем долго и упорно тащить всё своё наследие в виде Эльбрусов и прочих очень спецефических разработок, пока это наследие не потопит нас.

Вы видимо не в курсе, но российская компания "Ядро" (которая до этого скупила российского разработчика RISC-V ядер компанию Syntacore) начала разработку собственных процессоров на архитектуре RISC-V. Причем инженерные образцы процессоров для ПК и ноутбуков должны выйти уже в следующем году, а в 2023 они обещают уже 48-ядерный серверный процессор с частотой 3 ГГц.

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

Вы сначала требования по импортозамещению почитайте в 719ПП, а потом уже бросайтесь такими тезисами.

Нет у Yadro никаких проблем - все сделано и делается с полным соблюдением всей нормативки.

Нет у Yadro никаких проблем — все сделано и делается с полным соблюдением всей нормативки.

Постановление правительства РФ номер 1746

с 1 января 2021 г. соблюдение процентной доли стоимости использованных при производстве иностранных комплектующих изделий — не более 35 процентов цены товара, включая обязательное применение в продукции центрального процессора, удовлетворяющего требованиям к интегральной схеме первого уровня или интегральной схеме второго уровня, предъявляемым в целях ее отнесения к продукции, произведенной на территории Российской Федерации;

Процессор IBM, стоящий в СХД, закупку которой отменили, никак не является отечественным, и попасть в реестр отечественной продукции легально СХД на таком процессоре не могла.

Так что неправда ваша про полное соблюдение всей нормативки.

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

То что попало в реестр - живет там год. Потом повторная сертификация по новым правилам.

Так более понятно, спасибо.

Вообще мне так и не понятно с чего пошла это волна.

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

Что интересно, охапку фидбеков в свою сторону что "это заказная статья от Галицкого" я уже получил. Т.е. показательно, в каких категориях они сразу мыслят.

Кстати, хотел спросить, а причём здесь Галицкий?)) Он как-то аффилирован с Ядром? И какой Галицкий, тоже можно уточнить, а то я минимум двоих знаю))

А кто такой Галицкий?

Статья, насколько знаю не то что заказная - а скорее без fact-check вышла. Кто эту волну пустил я знаю совершенно точно (да все знают уже в рынке). Но не скажу) Мы на уровень кидания какулами в публичном поле не опускаемся.

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

Я тоже не знаю)))

И я имел в виду не эту статью, а статью в Известиях о том что нас откуда-то выпилили и прочее. Про Вашу статью я вообще ни слова не сказал.

Прошу прощения если Вам так показалось.

Ок, понятно, спасибо за пояснение

ЦИПР 2021. "В дискуссии принял участие Александр Галицкий, основатель и управляющий партнер венчурного фонда Almaz Capital Partners, советник премьера Михаила Мишустина по проблемам электронной промышленности. " Основатель Elvis.

Ну ок, и причём здесь Ядро и RISC-V? Элвис же делает ARM чипы, да и у них другая ниша, они на рынок GP CPU по-моему не претендуют.

Основатель Elvis.
Во-первых, основатель Элвиса — Петричкович.
Во-вторых, Элвис не занимается ни RISC-V, ни какими-то процессорами, конкурирующими с Эльбрусом.
Это что-то новое, посмотрим во что выльется. Спасибо за ссылку на новость.

Вот тут чутка больше подробностей: 3dnews.ru/1044326/rosteh-sozdast-otechestvennie-protsessorina-arhitekture-riscv-dlya-noutbukov-i-serverov
Нацеливаются на 8 ядерный RISC-V на частоте 2ГГц. Cобираются потратить 18 млрд руб. Не плохое начало, если слова дойдут до дела.

Цитата:
Ожидается, что первые 60 тыс. систем на новых процессорах будут отправлены заказчикам к 2025 году, что означает, что производство непосредственно процессоров начнётся примерно в 2023 году. Следовательно, на разработку отводится примерно два года. Для решения на открытой архитектуре — это вполне приемлемое время, хотя отладка всегда чревата массой сюрпризов

И мы примерно представляем, в каких статьях УК эти "сюрпризы" давно описаны.

Ни в каких. Разработка SoC происходит за собственные средства, а не за какой-то госНИОКР (как у нас водится).

А что то там Ростех или еще кто-то коммитится под объемы закупок оборудования (хотя это все ОБС на самом деле) - это совершенно другая история.

Мы не играем в прямое гос-деньги в виде НИОКР по которому мы что-то кому-то обязаны сделать. И не играем в прямые гос. контракты. Потому что да - часто люди за это попадают в тюрьму.

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

Тогда я рад за вас. Потому что я был на одной из ведущих выставок электроники - где Россия построила целый павильон. Куча дядек в дорогих костюмах и скучающие девочки модельной внешности. Какие-то видавшие виды платы под стеклом, которые нельзя посмотреть вблизи - а по поводу характеристик "инженер только что здесь был, наверное отошел на пару минут". Инженера я так и не дождался ни в этот день ни в следующий, на электронные письма ни одна из представленных компаний не ответила.
А в соседнем зале выставлялась российская компания (не афиширующая этот факт), занимающаяся решениями на базе западных SoC - у них на стенде были одни инженеры, и туда было не протолкнуться.

Мы пытаемся построить нормального российского продуктового вендора глобального масштаба.

Это одна из основных целей компании.

Да - нам это сложно с учетом геополитических реалий, российских реалий и всего остального.

Но не надо экстраполировать на нас скажем, практики, которые применяют другие компании в России.

Но не надо экстраполировать на нас скажем, практики, которые применяют другие компании в России.
Это довольно сложно после того, как узнаешь, что конечный бенефициар компании — Алишер Усманов.

Ну и что?

Известный олигарх выкупил у НКК потенциально выгодный актив. Вы же не думаете что он тут у нас между паяльных станций ходит?

Структурам Усманова много чего принадлежит.

Нам тут ни холодно ни жарко от сего знания. Раньше принадлежали Калинину, сейчас Усманову, завтра он нас кому нить продаст или не продаст. Калинина я видел один раз в жизни, Усманов вообще где-то там в другой галактике.

Между ним и нами 100500 компаний еще посередине.

Где блин Усманов и где RISC-V. Будьте реалистами в конце концов.

Вы же не думаете что он тут у нас между паяльных станций ходит?
У вас между паяльных станций — вряд ли. А вот поужинать с Чемезовым, чтобы он подтвердил, что Ростех у вас купит что-то — вполне.

Где блин Усманов и где RISC-V. Будьте реалистами в конце концов.
Где Усманов и где многомиллиардные контракты на СХД? Да очень близко. Или вы считаете, что он вас купил, а дальше пальца о палец не ударит, чтобы отбить инвестиции?

Да пусть ударяет - лишь бы на пользу шло.

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

Мы (инженера) это делаем.

Потом сэйлы это продают.

Или Вы думаете мы сидим такие - ай, дядя АБУ ща все порешает - а мы на 3Д принтере щас напечатаем тут что нить и продами за бешбабло. Вы это так себе представляете? Нафига нам тогда было тут городить крупнейший центр разработок для этого? Можно было студента нанять чтобы он в кикаде че-то рисовал и документашку по ГОСТ лепил - и так сойдет.

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

Ну во-первых "нас" оно не особо заботит. Моральных страданий мы по этому поводу не испытываем. Вы вот правда меня, инженера пытаетесь попрекать тем кому принадлежит мой работодатель? Может бы у меня тут в России обширный выбор и я такой - ой фу к Усманову не пойду, к Фролову не пойду, в ДЕПО не пойду. Ну вот давайте ткните пальцем в ту самую светлую и честную компанию.

Во-вторых все кому-то принадлежат. У всех есть бенефицары которые имеют доступ не то что к Чемезову, но и к тому кого нельзя называть. Жизнь такая.

В-третьих - если олигарх решил прокачать российское IT а не очередную яхту - это же прекрасно.

Вы вот правда меня, инженера пытаетесь попрекать тем кому принадлежит мой работодатель?
Нет, конечно нет. Все моральные выборы, мнимые или настоящие — полностью ваше дело. Я говорил о другом.

Напоминаю, с чего начался наш диалог:
— не надо экстраполировать на нас скажем, практики, которые применяют другие компании в России.
— Это довольно сложно после того, как узнаешь, что конечный бенефициар компании — Алишер Усманов.

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

А я вам говорю — не важно, как у вас обстоят дела на самом деле (я вот знаю, что нормально) — вам все равно никто не поверит сходу. Это печально, но так работает репутация. В данном случае — репутация Усманова.

Поэтому люди непременно будут на вас экстраполировать все кхм принятные в России практики ведения бизнеса, пока вы не докажете обратное — и даже после этого.

Ну... нам же главное чтоб клиенты поверили, а они все таки мыслят другими категориями.

Еще главное чтобы наши будущие сотрудники поверили и пришли к нам. Но у нас нет проблем с репутацией на рынке труда. Yadro по совокупности факторов (оплата, отношение к сотрудникам, развитие, устойчивость) очень хороший работодатель.

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

НЛО прилетело и опубликовало эту надпись здесь

В данный момент у нас политика - не пиариться в интернете.

Я даже наверняка что-то нарушаю, поддерживая этот диалог.

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

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

Ну они ж не на этом горят, а на том что берут на себя обязательства, которые не могут исполнить.

Вот что глобально изменится для нашей компании если мы начнем тут или на СуН раз в неделю выкладывать статейки как мы задорно пилим и дебажим железки и какие они клевые.

Люди, которые принимают решения о закупке оборудования не делают это почитывая интернет. У них другие критерии. Вы ж не будете принимать решение потратить несколько ярдов почитав развлекательный контент?

PR в соцсетях и СМИ - это скорее работа кадры. Чтобы люди читали сами про себя где-то и радовались, гордились там и прочее.

Лично я считаю что нужно это делать, но у руководства другое мнение. Ну и им скорее всего виднее - они не вчера с ветки спрыгнули.

Ну они ж не на этом горят, а на том что берут на себя обязательства, которые не могут исполнить.
Есть и такие, которые говорили «зачем нам пиариться, нас госзаказчик и так купит». А потом неожиданно выяснилось, что не купит. И что разработчики приборов знают про старые разработки, и помнят, что «компания Х» — выпускает какое-то говно мамонта, устаревшее много лет назад. А дальше все, ты можешь двадцать раз сделать что-то хорошее, но в систему поставят изделия лучше пиарящихся конкурентов, которые ничем не лучше, но на слуху. А потом и ОКР перестали давать — потому что зачем давать ОКР на разработки мамонтова говна?

Люди, которые принимают решения о закупке оборудования не делают это почитывая интернет.
Они довольно часто имеют тенденцию прислушиваться к мнению своих читающих интернет инженеров. Да и сами читают — я проверял своими статьями. И благодарности получал, и по шапке — напрямую от разнообразного высокого начальства, и своего, и чужого.

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

Ну Вы путаете теплое с мягким.

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

А второй момент, что мы же не делаем там платы, заказные разработки и прочее. Мы делаем продукт - сервер там, хранилка. И даже на самом деле уровнем выше - мы делаем решения. То есть к нам приходит там... ритейл и говорит - сделайте чтобы у нас маркетинговые кубы быстро крутились (это от балды абстрактный пример). Мы можем туда ставить свое оборудование, можем ставить OEM (которым нас тоже не забывают попрекать) - это уже более низкий уровень представления, вторичный.

К нам нельзя прийти и купить наш кабельный PCIe адаптер или плату свича или материнскую плату или что-то еще из 300+ запиленных электронных модулей. Нам нет нужды ходить в разработчиков - мы сами разработчики конечных изделий.

А касательно репутации на рынке труда. Информация о численности - скорее всего тайна, я цифру не скажу. Но Yadro уже достаточно крупная компания, а рынок кадров - маленький. Мы уже года 3-4 как не стартап, а очень крупный инженерный центр. Поэтому все кто находится в зоне нашего кадрового интереса - в основном уже прекрасно все знают. Мы эту работу на зачетку как раз проводили когда писали статьи на Хабр, ходили в социальные группы разработчиков и прочее - как раз для этого. Сейчас у нас очень много инженеров - они общаются в своих кругах, приводят к нам своих бывших коллег, рассказывают остальным как им у нас живется и эта машина в принципе едет сама.

Поэтому не нужно сомневаться в нашей возможности что-то запилить - будь-то аппаратура или процессор. Задизайнить мы можем все что угодно - все риски тут только в коммерческой целесообразности а не технической способности.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Это на самом деле не так просто как кажется - взять и написать.

Щас попробую сформулировать. С точки зрения хардверщика (программисты немного в другом мире - поэтому я вот только за своих).

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

И вот приходит маркетинг - и у нас начинаются просто страдания - ну о чем вообще писать. В итоге выдумывается какая +/- более менее понятная тема - и мы пишем, долго и мучительно. Потом это все естественно цензурируется (не сильно - на пару процентов может), разбавляется юмором, картинками и постится. Вот блин делать эту процедуру на регулярной основе для нас, инженеров - это адский ад. Поэтому как только маркетинг перестал к нам с этим ходить - мы перестали этим заниматься. Если б был такой инженер у нас кому это нравится делать (ну бывают такие) - это одно. У нас таких нет. Для нас такая деятельностью - это сродни наказанию.

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

Я на потоке занимаюсь электроникой уже больше 15 лет из них почти 10 - HPC а потом серверами и хранилками. Одна машина за другой, нон-стопом. Для меня это не какой-то вызов - а обычная рутина. IBM, Intel, AMD, Эльбрус - да пофигу. Очередная мамка, очередной набор бакплейнов, разеров и прочего. Машинист в метро водит поезд, а я делаю вычислительные системы. Для меня не существует таких вещей, которые мне было бы интересно обсуждать с широкой публикой. И большинство хардверщиков - они именно такие.

И у нас еще прикольно - средняя продолжительность активного проектирования - полгода, потом следующая машина. У военных так вообще тьма - у них там проекты по 10-15 лет.

Такая работа - она только со стороны кому-то кажется какой-то особенной.

ну то есть ваша работа не вызывает у вас особого интереса? «могу копать, могу не копать».
ИМХО это грустно.


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

Не надо все сводить к бинарным опциям интересно / не интересно.

Интересно ли мне читать публикации Богатина и других экспертов по Signal Integrity - да интересно.

Ковырять какие-то новые системы проектирования и моделирования - интересно.

Дебажить интересно и драйвово. Особенно ценен момент когда железо оживает - он очень эмоциональный.

Но нет никакого интереса читать там... очередной даташит на очередной чип, срисовывать очередной рефдизайн или трассить очередную плату - а это 95% работы хардверщика.

Если обобщить - то как и в любой работе - интересно делать и узнавать что-то новое, развиваться.

Причем DDR5 вместо DDR4, PCIe Gen4 вместо Gen3, Intel вместо IBM - это не что-то новое.

А повторять из раза в раз одни и те же действия с вариативностью деталей - как это может быть интересным?

Я знаю например коллегу, который в какой-то момент сменил работу, потому что ему хотелось ходить в другой офис, другим маршрутом и общаться с другими людьми. Чел 25 лет в отрасли и знает и умеет по ходу вообще все. Наша профессия не столь динамична - законы физики как появились так и не менялись с тех пор. Книжки 1980х выпуска до сих актуальны и годны для самообразования. А бэкграунд в 10-15 лет вполне себе релевантен при трудоустройстве.

Просто надо правильно понимать контекст ситуации.

Тут не то, что государство дало денег Yadro и написало там ТЗ на процессор, количество патентов рабочих мест и прочего.

А Yadro (возможно, так пишут в синусе) пришло и спросило - если мы это сделаем (компьютер, планшет итд) - Вы будете это покупать?

Статья об Эльбрусе, а не о Байкале.

Если Вы не поняли смысл статьи, то я поясню. Российское государство пытается сейчас пропихнуть Эльбрус как ЦПУ общего назначения (читай — микропроцессор для десктопов). Автор статьи показывает, что архитектура VLIW — ущербна и не пригодна для такого применения.

Вы точно мне это хотели написать? Я то всё понял и с автором согласен, я отвечал комментатору, который предлагал использовать Эльбрусы в гос секторе в качестве АРМ, но Байкал-М для этих целей явно лучше.

Идеальный вариант - это вложить силы в разработку нормального RISC/CISC процессора. Теоретически, это могут сами же МЦСТ и сделать. И не мучать несчастных пользователей и не вкладывать деньги туда, куда заведомо понятно что не надо.

А вам-то какая разница? Вы хотите такой заказ получить или что?

За державу обидно.

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

По существу есть возражения?

а как же! Начиная с названия: откуда вообще идея, что Эльбрус должен конкурировать в сегменте процов общего назначения?

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

Я хочу чтобы в моей стране были высокохтенлогичное актуальное производство.

и чем ты готов пожертвовать ради этого?

Из чего предлагается выбирать?

Для начала частью налогов и времени.

Интересно насколько сейчас в принципе реальна перспектива создания своей RISC/CISC архитектуры, не беря уже имеющиеся типа ARM, SPARC или MIPS. Ведь любая платформа, будь она хоть state of the art без софта обречена, а софт это как минимум более-менее мейнстримовая операционка и компилятор.

Наверное, ARM было бы оптимальным решением. Но там легко могут организовать проблемы с лицензией. Поэтому, в плане открытости и независимости, на данный момент наиболее перспективным выглядит RISC-V. Но с другой стороны, это ещё очень сырая архитектура.

С чего бы RISC-V сырая архитектура? Под нее уже есть высокопроизводительные решения серверного класса, и софта уже выше крыши. Прямо сегодня RISC-V способен достойно конкурировать с ARM вообще в любой нише.

И какие есть решения серверного класса на RISC-V? Векторный iset устаканили?

P.S. Я как бы двумя руками за RISC-V, но сравнивая состояние экосистемы того же ARM и RISC-V, думаю что слово "сырая" тут вполне применимо.

Например, есть представленные на прошлой неделе ядра серии Performance от SiFive. Или 1000-ядерный ML-чип от Esperanto. Сравнивая состояние экосистем, я вижу, что до ARM осталась буквально пара лет. И до RISC-V ноутбуков, вероятно, тоже.
А число произведенных RISC-V чипов попроще уже перевалило за миллиард.

Чипы от SiFive ещё слабые и крайне далеки от серверного рынка. На прошлой неделе получил их плату HiFive Unmatched и имел возможность немного потестить (будет время опубликую результаты). 1000-ядерный ML чип от Эсперанто это вообще другая история, это не general-purpose CPU, там Minion-core вообще in-order.

Ну и как я выше написал, даже векторный Iset ещё не устаканился.

Чипы от SiFive ещё слабые и крайне далеки от серверного рынка.
P550 выглядит вполне нормально. Или, скажем, SCR7 от Синтакора.

1000-ядерный ML чип от Эсперанто это вообще другая история, это не general-purpose CPU, там Minion-core вообще in-order.
Так прямо сейчас огромный кусок серверных задач — это машинлернинг, отсюда и такой пример.

P550 выглядит вполне нормально. Или, скажем, SCR7 от Синтакора.

Это всё ещё далеко до серверных решений, хотя дорога верная

Так прямо сейчас огромный кусок серверных задач — это машинлернинг, отсюда и такой пример.

Мы всё же говорим именно о general-purpose CPU и серверных чипах в этой нише. Давайте ML сюда не примешивать, это сильно отдельный топик.

P550 выглядит вполне нормально. Или, скажем, SCR7 от Синтакора.

Давайте посмотрим что известно про P550:

  1. SPECint2006 - 8.65/GHz, это примерно на 30% лучше чем у Cortex A75. Вспомним про сервеный арм в лице Neoverse N1 у которого SPECint2006 - ~14.2/GHz (37 на одно ядро на частоте 2.6 ГГц)

  2. С SPECfp все менее понятно становится, в презентации SiFive было только "114% от Cortex A75", а именно FP пилили больше всего (35% прирост при переходе на A76, например и еще какой-то прирост у Neoverse'а)

  3. До 4 ядер в кластере. У того же Neoverse - до 128.

  4. Планируемые частоты - 2.4 ГГц на 7нм. Смотрим что у того же neoverse - 2.6 для заметно большего числа ядер.

  5. Там по прежнему нет SIMD. Собственно его нет, потому что спека еще не финализирована.

  6. Я где-то недалеко говорил про особенности реализации работы с кэшом из кода в RISC-V (она отсутствует), это тоже создаст определенные проблемы в реальном мире. Притом в этот раз - нерешаемые без использования непереносимых кастомных расширений производителя ядра (если он вообще их реализовал).

Затем вспоминаем, что с момента доступности IP до его внедрения проходит минимум 1.5-2 года, что косвенно можно увидеть в планах интела по выпуску их Horse Creek в конце 22 или начале 23 года. То есть суммарно P550 выглядит как мощный мобильный процессор, но никак не как серверный. Не хватает и масштабируемости по ядрам в рамках одного кластера и по производительности на 1 поток недотягивает до ARMов. И главное - на серверном рынке ему бы пришлось конкурировать с Neoverse N2, если бы он туда позиционировался.

Касательно Syntacore SCR7 он совсем простенький же, это по сути проц уровня Raspberry Pi 3 (4.00 Coremark/MHz, 3.0 DMIPS/MHz, по Coremark'ам мне честно лень на 3-ей малине гонять бенчмарк ради комментария, но в интернете пишут про 5 Coremark/MHz что примерно соответствует тому что я помню, по DMIPS - все чуть хуже, там примерно 2.1-2.2, у A55 должно быть 2.6, у старенького A57 уже 4.0+), то есть ядро там примерно на уровне Cortex-A53 (где-то чуть хуже, где-то чуть лучше, но одного класса). Цифры по SCR7 я взял из их презентации на RISC-V Forum от декабря 2018 года. То есть по производительности это уровень чипов в домашних роутерах (при условии что сеть хорошо реализована и сетевуха много на аппаратном уровне делает) или телеприставок (если есть нормальный видеодекодер), но никак не ноутбука и тем более не сервера.

Но RISC-V развивается и это прекрасно. Со временем он действительно станет достаточно хорошим, чтобы применяться в серверах. Просто это будет не сегодня и не завтра и не в ближайшие пару лет.

ИМХО всё-таки не «сырая», а молодая и дерзкая динамично развивающаяся.

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

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

>С чего бы RISC-V сырая архитектура? и софта уже выше крыши.
Рано называть платформу развитой тогда когда, например, тот же OpenJDK доступен только в виде интерпретатора Zero
https://github.com/openjdk/jdk/tree/master/src/hotspot/cpu

даже для того Эльбруса запилен JIT-порт

PHP тоже доступен только как интерпретатор: https://wiki.php.net/rfc/jit#proposal

c .NET Core все глухо

А вот с JS v8 jit-движком v8 получше - несколько месяцев назад добавлена поддержка risc-v

Путь к развитой платформе:
-Собрать ядро линукс, сишку, cpp, системные библиотеки
- DOOM!!! https://twitter.com/ultraembedded/status/1284515315062317061

Сейчас вы находите здесь -> - портировать основной тулчейн: JS, JVM, PHP, .NEt Core, Python ( сюда же основные модули, которые использует каждый первый питонист - numpy, pandas, ...)
...
- PROFIT!11


Строго говоря risc-v находится чуть дальше - в стадии оптимизации этого тулчейна по скорости.

civil@debian:~$ uname -m
riscv64
civil@debian:~$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20201224] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> a = np.arange(15).reshape(3, 5)
>>> a
array([[ 0,  1,  2,  3,  4],
       [ 5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14]])
>>> a.shape
(3, 5)
>>> a.ndim
2
>>> a.dtype.name
'int64'
>>> a.itemsize
8
>>> 

То есть все как выше - местами нет JIT, но постепенно и он появляется. А касательно .NET Core - он все таки не так популярен на линуксе и кому очень надо - по-прежнему есть mono, который на risc-v как-то уже работает.

Интересно насколько сейчас в принципе реальна перспектива создания своей RISC/CISC архитектуры,
Это можно сделать. Вопрос в том, нужно ли. И этот вопрос вдвойне актуален с учётом существования открытой и отлично проработанной RISC-V.
Вы с такой болью пишете про «проёб… средства», когбуд-то не понимаете, что процессор, это не только ядро, а ещё и множество IP блоков, DDR4, PCI, IO, Кеш, куча всего и всё это разрабатывается коммандой Эльбрус и легко лицензируется другим прозводителям, а так же поддерживается не зависимо от любых санкций. Специализированное ПО и рабочие, стоят так же очень дорого и им всё равно процессор какой архитектуры делать. Фактически, очень многое из сделанного, это уже идеально вложенные силы в разработкую любого нормального процессора. И зачем тогда бучу поднимать?

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

Это логика из разряда "ну мы же старались".

Давайте все эти знания и наработки команда МЦСТ применит для разработки Sparc V9 или RISC-V процессора? Они же архитектурно независимы.

Насколько достоверна ваша информация о том, что DDRC (а также его PHY часть) , например , для Э-8СВ разработан в МЦСТ?

Ну завязывайте чушь пороть, надоело

>Идеальный вариант - это вложить силы в разработку нормального RISC/CISC процессора
А разве распространенные архитектуры сами же не попали в тупик - процессоры вынуждены иметь в своем составе набор сопроцессоров на все случаи жизни и даже стали появляться чипы со встроенными ПЛИС(!)
Хватит ли ресурсов у отечественных чип-мейкеров тянуть эту мету GP CPU, чтобы оставаться конкурентными?

Сопроцессоры и т.д. предназначены для ускорения отдельных видов workload'ов. Но какой смысл об этом сейчас говорить, если мы пока не сделали конкурентного GP CPU, для работы которого и так хватает кучи типичных нагрузок прямо сейчас в дата центрах и рабочих станциях пользователей

У vliw процессора есть все же один плюс — в нем невозможно спустя годы найти грабли вроде spectre и meltdown.
Ошибку оптимизации в компиляторе все же проще исправить.
А вот на виртуализации все видимо еще хуже, т.к. компидятор не может знать, когда гипервизор решить прервать исполнение кода одной гостевой ос, и передать другой.

Почему же невозможно? Вполне.

В этой статье я вижу антологию домыслов. Начиная с того, что основным критерием перспективности процессоров здесь подразумевается показатель "Ватт/гигафлопс". Кто решил, что это так? Непонятно.

И заканчивая поиском заговоров в типовой схеме b2b приобретения изделий. К слову, Oracle работает так же, по запросу, продавая свои БД, бесплатная ознакомительная версия у них появилась относительно недавно, и она не содержит всех коммерческих фич вообще.

Очень хотелось бы в следующей статье увидеть факты, исследования и отсылки на авторитетные мнения.

Здесь нет обсуждения вопроса, как правильно вести бизнес. Только техническая сторона вопроса. Критерий перспективности является то, в каких нишах Эльбрус технически может быть конкурентен. Собственно я показал, что и по абсолютной производительности, и по энергоэффективности процессоры на базе VLIW проигрывают архитектурам RISC/CISC.

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

Сколько в итоге будет отставание производительности на практике - 20% 40%? Это все ерунда, уже давно никто не ускоряет задачи вертикальным масштабированием single core, single thread

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

К счастью, вне зависимости от того, что себе там думают интернет-эксперты, "Эльбрус" развивается и будет развиваться дальше

И про числодробилки, и про тестирование на практических задачах, а не на синтетических тестах,

как раз синтетику vliw может молотить хорошо, а вот с практическими задачами всё хуже


и про то, что вертикальное масштабирование уже давно не основной вариант.

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

Что игнорирую? На базах данных Эльбрус также Интелам существенно уступает, на хабре были статьи с результатами. Горизонтальное масштабирование работает и там, и там. Только если у вас в обоих случаях по условных 32 ядра, только производительность каждого ядра в 3 раза выше, то и производительность системы в 3 раза выше.

Полнофункциональные версии СУБД Oracle уже даже не помню сколько лет как можно скачать с их сайта, безо всяких ограничений, создав себе учетку за пару минут.

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

Там нет ни RAC, ни Oracle Streams/GoldenGate, ни AdvancedQueueing, ни Flashbacks, ни Report Services, ни монитора, даже embedded java нет. Про APEX не помню, есть ли, возможно, тоже нет. В общем, можно длинный список перечислить, чего там нет

Вы что-то путаете.
www.oracle.com/database/technologies/oracle-database-software-downloads.html#19c
Вот пример под Linux — 19.3 — Enterprise Edition. Там есть все опции. Спокойно скачивается, безо всякого «запроса».
А вы явно говорили про Express Edition, её тоже можно скачать.

Это Express? Знатно потерял время с ней, когда после первого раза выяснилось, что там не было UTF-8. В более новых вроде добавили, но несовместимость разных версий дампов с СУБД - отдельная шутка.

Дело в том, что Armmaster и есть авторитетное мнение. Если мне не изменяет склероз, он портировал QEMU, чтобы тот мог эмулировать эльбрус.

Не, QEMU я не портировал))

Я делал бинарку под Эльбрус, а потом ещё под Arm и не только.

Eltechs Exagear?

Да

Круто!)

Сорян(

бинарку

Трансляцию?

Начиная с того, что основным критерием перспективности процессоров здесь подразумевается показатель "Ватт/гигафлопс". Кто решил, что это так? 

вся индустрия? Масштабировать процессоры вширь все давным-давно научились, и по сути всё упирается либо в производительность однопоточки, либо в энергоэффективность. Ну, есть еще конечно финансовые критерии, но они у относительно штучных эльбрусов в еще большем дне чем перф/ватт.

Стрёмная какая статья, а местами вообще дичь. Это же насколько часто при разработке программисты смотрят ассемблерный код чтобы понять, что пошло не так? Есть компилятор, который должен делать код - это его работа. В дебаггере тоже всё на уровне языка программирования. Программисту надо в своём языке разбираться и логическую модель приложения сделать на нём. Сишники и те раз в год в ассемблер залезают, остальным-то зачем это? Проблемы у эльбрусов такие видятся - закрытость в целом и недоступность для разработчиков-энтузиастов банально по цене.

С современными компиляторами очень даже приходится смотреть на ассемблер, т.к. нет уверенности, что компилятор "понял" как правильно оптимизировать код. Да, это требуется не так часто, и в основном только для тех, кто ведёт разработку на низкоуровневых языках. А ведут её преимущественно из-за скорости работы кода на этих языках. И если вдруг программа не выдаёт ожидаемой скорости, то рано или поздно (когда выверил все алгоритмы) добираешься до ассемблера и начинаешь искать в нём проблемы.

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

В статье, кстати, не упоминается тот факт, что подавляющее большинство пользовательских разработок в последние лет 10-15 ведется на интерпретирующих языках высокого уровня (Perl, php, Python, scala/java), статическое предсказание в данном случае не возможно от слова «совсем». Аналогичная ситуация с компилирующими языками типа rust и go — никто не будет создавать для этих языков оптимизирующий компилятор для всей линейки микропроцессоров Эльбрус. Даже если Эльбрус станет полностью открытым, его доля в мировом масштабе на столько мала, что разработчики языка rust никогда не узнаю о существовании такой архитектуры, а даже если и узнают — где они найдут высококлассных специалистов по VLIW, что бы создать оптимизирующий компилятор? Вероятно, что Google (создатель go) сможет потянуть такую задачу, но зачем ему весь этот гимор? В общем, полностью поддерживаю лейтмотив статьи — Эльбрус, как ЦПУ общего назначения это тупик при любых раскладах. Удел Эльбруса это числоробилка в узкоспециализированных задачах.

Как раз у языков с jit компиляторами есть шансы. Статический анализ и перекомпиляция кода идет в рантайме. Можно оптимизировать на основе реальной статистики выполнения.

Но кто напишет такой jit компилятор непонятно. Это сложно, долго и очень дорого.

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

Зачем для каждого?

Есть типовой подход: Компилируем каждый язык в один и тот же байт код, который и передаем одному jit компилятору.

Если коротко, то не всё так просто.

А кто говорил про просто? Это хотя бы реально. В отличии от "написать хороший jit компилятор для каждого языка"

Боюсь, чтобы достичь перфа, этим всё и закончится.

Ну и не решит это проблем глобально. Т.е. можно какие-то углы срезать, но в итоге обычным архитектурам всё равно будем проигрывать существенно.

Мир как-то живет менее чем с десятком JIT компиляторов и ничего. Наверно даже штук 5 всего массовых.

Даже нейтив компиляцию по этому же пути стали делать llvm и больше ничего не нужно.

Я бы думал только в эту сторону для чего угодно нового. Может быть я не прав, но выглядит как самое перспективное направление. И гораздо дешевле компиляторов полного цикла.

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

В общем случае - да. Но большинство вычислений в Python делается через нативные numpy/scipy и прочие Tensorflow - которые сами по себе что-то вроде виртуального языка для обработки матриц.

Ага. Пересадить «каждый» язык на общий бэкенд… ради Эльбруса, который практически нельзя купить, тем более за границей.

Квалификация специалиста до определенной степени может компенсировать недостатки архитектуры. Чтобы писать быстрый код под Эльбрус нужно знать его (Эльбруса) преимущества и недостатки. Не лезть туда, где заведомый проигрыш, совершенствоваться там, где есть выигрыш и думать, что можно сделать в "середине". Если архитектура - "проблемная", то и подготовить для нее специалистов - сложнее. А подготовить спецов это тоже дорогое удовольствие. Та самая "колоссальная работа".

Рассуждая так, примерно в 2017-м я попытался в своем ВУЗе протолкнуть идею создания курса с идеей - "Мы лучше всех умеем писать под Эльбрус" (в смысле с учетом всех особенностей Эльбруса). Были и люди, кроме меня, готовые это все делать в ВУЗе. Вышел на контакт с МЦСТ, получил понимание и поддержку (насколько это возможно для МЦСТ). Подписали декларацию о намерениях. Все уперлось в то, кто: МЦСТ или ВУЗ предоставит ресурсы (4-х проц. сервер) для разработки и проведения курса. В 2019-м я почти получил машину. Но в конце все-же сорвалось. И с тех пор ситуация не изменилась. Максимум, чем я тут смог помочь отечественному производителю, это отфильтровать и направить к настоящему времени в МЦСТ 3-х студентов, которые загорелись от меня идеей работать именно с Эльбрусами. Как-бы и винить тут особо некого. У каждого своя правда. Но правда и в том, что ситуация с ПО для Эльбрусов и специалистов, которые под него могут писать эффективный код, как мне представляется, с 2017-го лучше не стала.

Вот сейчас выделяют средства на разработку процессоров и "обвязки". Это - хорошо. Но может что-то надо выделить и на подготовку отечественных специалистов для работы с отечественным оборудованием? Чтобы они в ВУЗах уже с ними знакомились, а не с Microsoft? То, с чем ты раньше познакомился, то и будет сидеть "глубже". Пусть Эльбрус - это специфична техника. Это просто означает, что специфичные курсы для Байкала должны быть во всех ВУЗах с IT-специальностями, а для Эльбрса не во всех, а в нескольких, достаточных для заполнения специалистами ниши, которая может быть занята Эльбрусами и этим специалистам дать работу. Какое-никакое, а комьюнити начнет формироваться. А то ведь на 30-е июня 2021 г. форум Эльбруса ( https://forum.elbrus.ru/ ) с 2016 г. имел такие характеристики: Всего сообщений: 185 • Всего тем: 49 • Всего пользователей: 264. 37 сообщений в год, 3 сообщения в месяц. За месяц ситуация "изменилась": Всего сообщений: 187 • Всего тем: 50 • Всего пользователей: 270. Думаю, рыночными механизмами эту ситуацию не изменить. От теплого к холодному энергия передается только с помощью работы, а сама - никак. Дорогу осилит идущий :)

Ну и наконец, не массовая ниша это не плохо. Например, ПО проектирования цветных революций (предполагаю, что такое есть) вряд-ли обсчитывают на компьютерах общего пользования. Против такого ПО должно быть "контрПО" не уступающее по производительности, иначе можно опоздать с контрдействиями. Цена ошибки (поражения) здесь в принципе равна цене всего производства универсальных процессоров. Потому как поражение равно закрытию всего этого производства и универсальных процессоров и специфичных. Поэтому, думаю, нужны Эльбрусы и те, кто на них умеет эффективно писать не смотря на ограничения архитектуры. И направление это надо развивать "не смотря на". А массовым, ну... пусть Байкал будет. В общем я за появление курсов по изучению и Эльбрусов и Байкалов в ВУЗах (а может и школах) страны! :)

Например, ПО проектирования цветных революций (предполагаю, что такое есть) вряд-ли обсчитывают на компьютерах общего пользования
А, кстати, почему? Если это большие системы линейных или дифференциальных уравнений, то быстрее их считать на видеокартах (общего пользования!) а не каких-то специализированных чипах, которых 1000 штук на всю страну.
НЛО прилетело и опубликовало эту надпись здесь
Выше товарищ говорил конкретно про Эльбрус, а Эльбрус это совсем не ASIC. Вот мне и интересно, какая такая специфика должна быть, чтобы Эльбрус был быстрее лучших GPU и CPU общего назначения.
И да, насколько помню из рассказов, вроде как в своё время одна небольшая троичная машинка щелкала дифуры не хуже, чем более «крутые» большие двоичные) Но это может быть и байкой
В годах 60-х это могло быть и не байкой, что какие-то умельцы придумали что-то уникальное и крутое. Но сейчас все алгоритмы хорошо изучены и всем известны. Поэтому рулит грубая сила: гигагерцы и нанометры, а что там — троичная логика или двоичная, не так важно.
НЛО прилетело и опубликовало эту надпись здесь
Мне показалось, что фразочка про «цветное ПО» и «своевременные контр-меры» — домашняя заготовка, нацеленная на политиков, которые в вычислениях не понимают, зато распоряжаются бюджетом. Если это не так, нужно пояснение для технарей. Если так, пояснение не требуется.
НЛО прилетело и опубликовало эту надпись здесь
единственные задачи, под которые нам точно нужны хоть какие-то свои решения — это всякие моделирования атомного оружия
Для меня это не очевидно. Сколько нужно Эльбрусов, чтобы заменить одну NVidia RTX 3090? И есть ли смысл менять (кроме распила денег, конечно)?
НЛО прилетело и опубликовало эту надпись здесь
На чём считать? На «компьютерах общего пользования», от которых почему-то хочет уйти автор комментария.
НЛО прилетело и опубликовало эту надпись здесь
Я хочу сказать, что суперкомпьютер на Эльбрусах не имеет смысла. Если не согласны, приведите пример реализованного или планируемого проекта. Посмотрим, сколько у него ядер, терафлопс. Сравним с обычной обывательской RTX 3090
НЛО прилетело и опубликовало эту надпись здесь
Если основная числомолотилка — GPU, то вообще без разницы, на чём строить хост. Хоть на Xeon-ах, хоть на Байкалах. А то ведь автор выше написал:
Поэтому, думаю, нужны Эльбрусы и те, кто на них умеет эффективно писать не смотря на ограничения архитектуры. И направление это надо развивать «не смотря на». А массовым, ну… пусть Байкал будет
Это мне и не понятно (понятно, с т.з. освоения бюждета, но не более).
НЛО прилетело и опубликовало эту надпись здесь
Если вопрос только в интерконнекте, то почему Эльбрус? На Байкалах его нельзя сделать? Я задавал вопросы по посту AamSpace (что именно Эльбрус спасение, а не ничто другое), а вы уводите тему в сторону.
НЛО прилетело и опубликовало эту надпись здесь

Мне кажется, из контекста очевидно. Или по-вашему надо каждый раз перечисляя то на чем делаются вычислений указывать все, вплоть до марки топлива на электростанции? (вашу логику можно дальше легко развить - вы не указали блок питания, чем питать будете? А еще не указали кабель питания. А еще - откуда появляется электричество, а потом откуда оно появляется там и так до бесконечности).

НЛО прилетело и опубликовало эту надпись здесь

Из контектста, человек утверждает, что можно либо на одном видике считать что-то

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

В итоге, вы оба вдвоём утверждаете, что в любых расчётах и пересылках данных подобные параметры не важны или что?

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

Я не очень понимаю ни его, ни ваши тезисы.

Мой тезис в том, что Вы ведете себя некрасиво, по отношению к @qw1 (на самом деле и к другим собеседникам в других тредах), потому что придираетесь к формулировке, вместо того чтобы задавать правильные вопросы.

Пример тут "без процессора и чипсета — я так и не понял." (заметьте, что я отвечаю ровно на это сообщение, а не на другие в треде) - это и есть буквоедство, но вместо "ок, а какую конфигурацию сервера вы предлагаете использовать?" вы выдали именно то что я процитировал.

Так что хочу дать непрошенный совет - не делайте так, это выглядит очень неприглядно и негативно влияет на развитие дискуссии (сводит ее дальше, извините, в срач).

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

Ибо я так и не добился ответа, как же именно вы будете организовывать работу вашей железке в сферическом вакууме, который мне навязывают для обсуждения вместо ответа на том, как в реальности будет это всё работать.

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

НЛО прилетело и опубликовало эту надпись здесь

Так вопрос в каком именно железе она воткнута? В обычный декстоп? А как тогда данные сливаются и пересылаются друг другу?

Так пишите эти вопросы явным образом @qw1с которым вы общаетесь на эту тему. Не юлите фразами подобными той, что я привел.

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

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

То есть то, что человек до этого прямо сравнил расчёт на процессоре с расчётом чисто на видике вы проигнорировали?

Да, проигнорировал, потому что для продолжения дискуссии можно было бы ожидать от Вас вопросы по существу, а не попытку придраться к словам.

Итого, очередная демагогия, когда на аргументы одной стороны кладётся болт, ибо надо облить другую сторону.

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

НЛО прилетело и опубликовало эту надпись здесь

Я ему прямо задавал вопросы. Я ему криво задавал вопросы, я ему уже начал аналогии приводить. Как ещё мне задать ему вопросы, что б он на них начал отвечать, а не рассказывать про рассчёт на одном видике 3090, которая порвёт все суперы, вставленная в обычный домашний комп?

На момент когда я Вам там отвечал я не видел никаких корректно заданных вопросов. О чем Вам и было сказано.

Юлит здесь конкретно один чел, а вы его пришли защищать, не прочитав даже ветку и вырывая один коммент из всего треда.

Перечитайте внимательно что я сказал. И прекращайте уже приписывать то, что я не говорил (либо давайте пруф о том что я его защищал, хинт: указание на проблемы коммуникации с Вашей стороны не являются защитой другой стороны).

Я уже указал, что попытка аннулировать тезис тем, что вы не хотите на него отвечать не означает, что там был вопрос не посуществу.

А я повторю, кажется в третий раз: мне все равно был ли там вопрос по существу или нет. Я читал вашу переписку, следил за ней и заметил что Вы делаете некорректные высказывания в отношении своего оппонента, на что обратил Ваше внимание. Было бы такое с его стороны - этот тред я бы вел с ним.

То, что лично вы тоже делаете вид, что не понимаете вопрос — ну, это ваше дело.

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

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

А Вы уверены, что достигаете именно такого результата не только с Вашей точки зрения? Мне вот со стороны кажется, что это Вы начинаете разводить демагогию, в которой обвиняете других.

А тут приходите вы с «лень всё читать» и начинаете учить меня, как я должен общаться с известным мне списком демагогов, которые ведут себя раз за разом одинаково.

А Вы предлагаете ничего не делать, если мне очевидно что в таком ключе Вы только разводите срач? Но если Вы не готовы поменять свой стиль поведения, то заставить это сделать я Вас конечно же не могу.

Например, ПО проектирования цветных революций (предполагаю, что такое есть) вряд-ли обсчитывают на компьютерах
Вы разве не знаете? Оно на чипах из вакцин от ковида считается.

Пишем интерпретатор, берем третью проекцию Футамуры, получаем компилятор. Собственно, GraalVM уже умеет это делать. Постоянное профилирование кода и перекомпиляция по его результатам идут в комплекте. Проблема в том, что все это целиком выглядит как долгострой, и непонятно, когда можно будет использовать в продакшене. Хотя некоторые куски проекта уже допилили и используют в openjdk.

А были чем-то похожие идеи. Даже две реализации. Правда там решили не для языков делать, а делать бинарную трансляцию (с анализом, оптимизациями на лету и проичими плюшками) на уровне firmware.

Онда попытка была для x86 - процессор назывался Transmeta Crusoe. Про него можно почитать в том числе и бенчмарки (про тот же совет гонять их несколько раз, чтобы транслятор прогрелся). Собственно идея была хорошая, была воспринята с энтузиазмом, но процессоров от Трансметы очень давно не видно, потому что оказалось все не так радужно.

Вторая попытка была для ARM - назывался процессор nVidia Tegra K1 64-bit (ядро называлось Denver), которое потом даже получило некоторое развитие. Они про микроархитектуру писали мало, по сути есть только статья на anandtech про планшет на первом поколении этой тегры (Nexus 9 Review), статья на anandtech про Xavier (Investigating NVIDIA's Jetson AGX) и доклад на IEEEевской конференции (Denver: Nvidia's First 64-bit ARM Processor), за paywall'ом, про первое поколение архитектуры. Они продержались дольше, сделали несколько поколений своей архитектуры, но во всех случаях по эффективности она уступала ARM'овским Cortex'ам (у Xavier производительность получилась чуть лучше чем у Cortex A75 при значительно большем энергопотреблении и большей площади чипа). И хоть официально они ее и не хоронили, но следующие поколения своих процессоров будут делать уже на обычных Cortex'ах.

Аналогичная ситуация с компилирующими языками типа rust и go — никто не будет создавать для этих языков оптимизирующий компилятор для всей линейки микропроцессоров Эльбрус.

Rust уже есть на e2k. Хотя ещё есть что улучшать.

https://ce.mentality.rip/z/KTWsvd

И какова эффективность кода полученного таким компилятором? Для Эльбруса есть почти все, что можно скомпилировать из C/C++. Главный вопрос — создание оптимизирующих компиляторов, а не просто чтоб было для галочки.

Там используется бекенд компилятора lcc (того самого, что компилирует C/C++), так что в идеале должен получится такой же эффективный код, но на данный момент это не совсем так. Как я уже написал выше, есть что улучшать.

Бэкенд llvm вряд ли сможет хорошо соптимизировать код под Эльбрус.

LLVM ничего не знает про e2k. В LLVM просто трансляция из LLVM IR в EIR, а дальше работает lccrt.

А, я lсс как llvm прочитал, был неправ.

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

Если какой-то язык прям по команде интерпретирует, там про производительность речь не идёт вообще (я таких и не знаю)

Bash же

В том-то и и дело что вынуждуют, путем насильственного пропихивания серверов на Эльбрусах в госструктуры, и удивляются почему написанный ранее код не справляется с задачей — ведь Эльбрусы они крутые числобробилки, от их внедрения все должно только улучшиться! :)

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

В Go поддержка новых архитектур это инициатива общественности. Недавно было одобрено добавить поддержку loongarch64 для новых китайских процессоров. Патчи уже полетели. Так что, если будет желание и ресурсы, поддержка будет. Google здесь вообще не при чем.

По идее добавить новую архитектуру в Go не очень сложно, но вот оптимизацию хорошую сделать, это будет не просто. В Go так же важна и скорость компиляции, он работает, как интерпретатор по скорости. Нажал выполнить, и можно смотреть результат, а не собирать проект часам, как на многих других языках. Проблемы есть, но они решаемы ИМХО, было бы желание.

Эльбрус своими ногами растет еще из времен СССР. Скорее всего, когда запретили проводить испытания ядерного оружия, потребовался вычислительный кластер, для расчета имитации ядерных испытания. Если мы будем исходить из сугубо прикладной задачи имитационного моделирования, то архитектура VLIW подходит как раз отлично. Написали одну программу, запустили ее, и пусть пару недель вычисляет. После развала СССР оставшиеся чертежи решили реанимировать, так получился Франкенштейн под гордым названием - Эльбрус. Изначально все задумывалось для совершенно других задач, а нынешние политики решили, что и так сойдет.

Удел Эльбруса это числоробилка в узкоспециализированных задачах

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

Во первых советские эльбрус-1/2 были суперскалярными ОоО циск архитектурами.

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

И повидимому в связи с этим решили сделать эльбрус-3 на подобии машины карцева, которая те же 2оп делала простым указанием алу0,алу1 и была гораздо энергоэффективней.

Честно говоря не понимаю эти постоянные кивания на военных, интернет и gps создавались для военных целей как это мешает их использовать в гражданской сфере?

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

"Честно говоря не понимаю эти постоянные кивания на военных, интернет и gps создавались для военных целей как это мешает их использовать в гражданской сфере?"

Абсолютно согласен с автором поста о бессмысленности и бесперспективности использования процессора Эльбрус для гражданской сферы. Подходы к построению систем для военных и граждан принципиально различаются. По факту у нас работает только два пути: изначально разработано для военной сферы, и только ими же и используется; разработано для гражданской сферы, с изменениями и дополнениями используется в военной сфере. Процессоры Intel установлены на множестве военной техники, телескоп Хаббл летает с процессором Intel Pentium 4 на борту. Это конечно же не те процессоры, которые установлены в миллионах домашних ПК, а доработанные с учетом надёжности и защиты для военной сферы. Аргументы про разработку Интернет и GPS не имеют никакого отношения к данной теме, по следующим причинам:

1) Это американская история успеха, и к российским реалиям она не имеет никакого отношения. Подобных примеров для СССР или РФ я не знаю, если Вы знаете, с удовольствием об этом услышу от Вас.

2) Интернет это не товар или даже не услуга, а проект и чертеж. Его никто не производит, его не нужно каким то образом поддерживать.

3) С GPS такая же история, это не товар, а услуга. В вашем смартфоне установлен совсем другой чип, и он принципиально отличается от чипов которые используют военные.

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

В целом согласен, но я бы сделал такую поправку:

Военная технология взлетает в гражданской сфере только в том случае, когда она передаётся другой компании, с другой бизнес-моделью. Та же МЦСТ заточена на гос. кормушку и по-другому работать не сможет. А вот когда технологию (тот же GPS) принимает компания (производитель смартфонов), которая знает, как её успешно продать людям, только тогда возникает успех.
Стрёмная какая статья, а местами вообще дичь.

Важная и правильная статья.

Программисту надо в своём языке разбираться и логическую модель приложения сделать на нём.

Да, если только его совсем не волнует достижение оптимальной производительности.

Сишники и те раз в год в ассемблер залезают, остальным-то зачем это?

Странно, я как сишник смотрю в ассемблер каждый день.
Как вы предлагаете разбираться с крешдампами?
Там код оптимизированный и дебаггер не показывает переменные и прочее.
А у Эльбруса всё максимально заинлайнено и раскрыто.

Как бы я об этом и написал как раз - большинство программистов в ассемблер не лазят. А без этого вы на Эльбрусе перформанса не получите. Что и является большим недостатком. Этому приличная часть статьи посвящена

"Это же насколько часто при разработке программисты смотрят ассемблерный код чтобы понять, что пошло не так?"

Вы не поверите...

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

Сделать процессор для массового рынка очень сложно. Лучше уж начать с универсальных процессоров для военных, для гос-датацентров, и уж тогда смотреть в сторону массового рынка

Чем гос-датацентр отличается от обычного датацетра? Там программы работают не на java, python, PHP, go? Или может им Oracle/Postgres не нужен?

Тем, что оплачивается из чужих карманов, а значит - эффективность не важна.

Медленные? - добавим ещё стоек. Горячие? - побольше кондеев. Не взлетело? - выделим ещё денег на очередную итерацию.

Им нужна сертификация, и ради сертификации какого-нибудь ФСТЭК или ФСБ они готовы жертвовать эффективностью. Плюс у них вполне определенный стэк, возможно им оракл и не нужен, и не будет нужен. И они могут крутить одну версию СУБД годами, особенно если это изолированные контуры.
Тоже самое и с военными - они могут позволить переплачивать за отечественные процессоры, могут свои программы под него собирать и разрабатывать.
А обычный потребитель зачем будет покупать отечественный процессор, на котором не всё запускается, и который еще и стоит дороже?

И как итог получаем неэффективный и вероятно дырявый софт в госсекторе и около.

Неэффективный потому что особый стек, древние версии, деньги не считают. Смысла и способа делать эффективно нет.

Уязвимости хорошо находятся и исправляются в открытых и массово используемых экосистемах. В закрытых и никому не нужных, за исключением госов и военных, экосистемах уязвимости могут жить годами и десятилетиями. Никто не заинтересован в их поиске и исправлении. При этом потенциальный противник спокойно купит/украдет весь софт и железо этой экосистемы и запустит туда хороших пентестеров. Он заинтересован в поиске уязвимостей.

Зато все сертификаты будут идеальные. Тут возразить нечего.

Это точно то чего мы хотим добиться?

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

США на зря отдаёт военные разработки корпорациям. Микрософт самые известные. Я не думаю что они ради госконтрактов используют что-то совсем особое вместо своих типовых решений.

Гостайна в 21 веке? Которая влезет на любой носитель или облако? Вы сами-то верите что она продержится дольше одной недели? Типичная security though obscurity. Вроде все уже в курсе что это не работает?

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

По-вашему выходит, что у США все системы открытые? О чем тогда говорил Сноуден, PRISM, вот это вот всё? Да и тот же Майкрософт вполне может работать на оборонных заказов без опубликования детальной информации. У нас же тоже все эти системы разрабатывают какие-то приближенные НПО (возможно, наполовину государственные, наполовину родственников генералов).

Гостайна в 21 веке продолжает работать, потому что уже 10 лет мы не знаем, что там в АНБ происходит, например, а кода PRISM до сих пор не нашли. В конце концов, никто не хочет быть осужденным за шпионаж за то, что выложил секретные документы в облако.

Я не сталкивался с российскими сертификатами, но могу допустить, что там действительно очковтирательство и просто кормушка для приближенных.

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

Где вы прочитали про все открытое? Я писал про стандартные. Стандартные для МС, например. Они достаточно велики чтобы их внутренние стандарты были хороши.

Вы же понимаете разницу между крупнейшей корпорацией и карманной конторой? По уровню разработки, внутренних инструментов, разработчиков и всего такого?

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

Ну то есть вы верите в security through obscurity . Это печально. Нет ни одной причины в это верить в 2021 году.

Так задача создать уникальный процессор просто не нужна. Надо купить/взять что-то типовое и делать. Арм, Риск5 отличные кандидаты.

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

В реальной жизни невозможно статически проанализировать код настолько, чтобы максимально плотно упаковать широкие команды.

Я бы сказал, что сама по себе статическая оптимизация и упаковка команд — тупиковое направление. Например, в реальных сценариях время доступа к памяти недетерминировано, время выполнения некоторых команд (например, деление) тоже может различаться. И если процессор с OoO выполнением команд сможет эту ситуацию быстро разрулить, то VLIW будет просто ожидать.


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

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

Ок. Примените теперь рассуждения для такой практической задачи, как сравнение строк.

while(*s1 && *s2) { // вероятность цикла > 0.5
  if(*s1 != *s2) // вероятность неравенства > 0.5
   return false;
  s1++; 
  s2++;
}
return true;

Вероятность цикла всегда больше, в т.ч. и для сравнения строк, потому что на практике строки как правило не пустые. Вероятность сравнения на равенство стремится к нулю, на неравенство к единице — потому что две произвольные ячейки памяти скорее всего не равны. Вообще, вероятность прямого (неинвертированного) срабатывания if с простым условием, а также блока case в switch в среднем меньше 0.5, потому что это как правило обработка особых случаев, которые мы «выхватываем» из множества всех возможностей (и соответственно else — больше 0.5). Для компилятора нет никаких проблем оценить вероятность сложносоставного условия на основе предположений о вероятностях простых условий, входящих в сложное.

Вы только что убили производительность кода сравнивающего почти всегда одинаковые строки. Да, такой код есть и его много.

Вы одновременно убили производительность сравнения строк размером в 1-2 символа. Такой код тоже есть и его тоже много.

С учетом что это библиотечная функция поправить это простым способом невозможно. Остается или мириться или писать неприятные костыли с протекающими абстракциями.

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

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


А вот процессоры с предсказанием ветвлений такого недостатка лишены. После нескольких итераций на реальных данных предсказатель делает вывод и следует ему. Код в итоге получается одинаково эффективный как для только коротких строк, так и для длинных с одинаковым префиксом.

Да, пожалуй вы правы.
Ну если в программе есть обычный цикл, то вероятность повторения итерации все равно выше чем вероятность выхода из цикла
Слишком грубое предположение. Современный Intel может выучить, что вот конкретно в этом цикле — всегда 5 итераций, и на 6-ю уже не делать спекулятивного повтора. А данные изменятся — переучится на другое число. Или выучить, что конкретно этот IF срабатывает каждый 4-й раз (не такое уж редкое дело).

В Эльбрусе нет предсказателя переходов (хотя есть статьи, где это пробовали делать).

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

Собираются в следующую версию архитектуры v7 (Эльбрус-32С) воткнуть предсказатель переходов.

может у вас сохранились где-нибудь ссылки на эти статьи? Буду признателен за такую информацию.

Спасибо.

  • Дополнительная нагрузка на кэш данных в следствие спекулятивного исполнения кода

Так и на распространенных архитектурах спекулятивные вычисления неявно задействуют кэш, отсюда как раз и произрастает Meltdown.

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

Официальная инфа от МЦСТ такова: В следующей версии архитектуры v7 должен быть предсказатель переходов.

Если она официальная, то есть что-то публичное, подтверждающее данное утверждение?

Разговоры о branch predictor'e в Эльбрусе ходили в МЦСТ давно. Но там возникнет большая проблема с совместимостью со старым кодом.

Ведь казалось бы, если вы хотите продавать свои процессоры, надо их максимально пиарить и первые партии раздавать чуть ли не бесплатно. А тут такие бюрократические препоны.

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

Изначально всё было нацелено на широкий рынок. Была знаменитая статья в 99-ом в Microprocessor Report про Эльбрус. А получилось так, как получилось

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

Это то, с чего e2k начинался.

Безотносительно Эльбруса хотелось бы заметить, что скорость мейнстримных general purpose CPU, достигаемая за счёт branch prediction и спекулятивного исполнения, имеет "обратную сторону", являясь неисчерпаемым источником различных мелтдаунов.

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

Принцип Неуловимого Джо.

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

Уязвимости такого рода не являются неизлечимой болезнью спекулятивного выполнения. Никто не мешает отслеживать спекулятивно загруженные линии кеша и инвалидировать их, если выполнение пошло не по той ветке. Точно так же, как инвалидируются спекулятивные действия с регистрами. Да, на это надо добросить немного транзисторов. Этого не делали, потому что казалось, что нет большого вреда от того, что больше данных попадёт в кеш. Если это внести в требования к микроархитектуре — что спекулятивные действия не должны быть видимы в кеше — это несложно реализовать.

Я ещё слышал, что ещё у нас делают мультклеточную архитектуру. С ней тоже всё не радужно?

Мультиклет это не general-purpose CPU. Т.е. совсем другая история, не связанная с обсуждаемым топиком.

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

Было бы неплохо поправить немного таблицу с процессорами. У Itanium​ 9760 всего 8/16 ядер/потоков, предсказатель ветвления и своеобразное OoOE. Он довольно сильно отличается от Эльбрусов.

Да, спасибо, таблицу поправил. Что касается различий Итаниума и Эльбруса - про это я особо оговорился в п. 2. Но на общие выводы это не влияет.

Но на общие выводы это не влияет.

На мой взгляд влияет. IA-64 как-то можно сравнивать с e2k только до появления Poulson, но только если код собирается с -march=nativeдля IA-64. Как минимум не стоило подгребать их под одну гребёнку в сравнении с OoOE x86.

И в чём на ваш взгляд ключевое отличие последних Itanium от Эльбрус, что принципиально менят описанную картину?

Часть я уже упомянул выше, но повторюсь для полноты картины.

  • Многопоточность.

  • Тактовая частота.

  • Предсказатель ветвлений.

  • Аппаратный префетчер.

  • Наличие FMA.

  • Ну и вишенка на торте, своеобразное OoOE.

В Эльбрусах что-то отсутствует или сделано иначе (в основном в сторону статического/программного решения), а это сказывается на транзисторном бюджете и TDP. И это не говоря уже о технических возможностях реализовать это в аппаратуре.

Определённо e2k и IA-64 имеют много общего, но в то же время они очень разные. Что-то из этого списка можно реализовать в e2k, что-то уже реализовано, а реализация чего-то ещё превратит в рудимент добрую часть ISA. :)

  1. Многопоточность это просто фишка, которая не ускоряет исполнение в single thread, а просто позволяет чуть более эффективно использовать ресурсы CPU. Добавление её в Эльбрус никак не поменяет всё то, что написано

  2. Тактовая частота это как раз вопрос вылизывания дизайна во многом. Ну и к архитектурным вещам она не не относится напрямую. А косвенные проблемы с частотой у Итаниума и Эльбруса те же.

  3. Предсказатель ветвлений - действительно важная вещь. Она в каких-то моментах поможет, но глобально ничего не изменит. Есть статья от МЦСТ, где они делали предсказатель и в итоге перф получился даже немного хуже (но вроде энергоэффективность подросла).

  4. Префетчер - тоже важный момент, но опять-таки, кардинально ничего не изменит в выводах. Более того, префетчер вносит динамику в планирование задержек и по сути противоречит идее статического планирования.

  5. FMA это просто команда. И в Эльбрусе FMA есть конечно же, причём что-то порядка 6 в такт.

  6. А вот и вишенка на торте)) Ну т.е. давайте скажем честно - по итогу развития линейки Итаниум инженерам стало понятно, что чтобы выжимать перформанс - надо делать ОоОE. Но скрещивать ежа с ужом оказалось больно и сложно и в итоге от развития этой линейки отказались. Что и является признанием тупиковости такого вектора развития general purpose CPU. Я ж на самом деле ни какой-то мега секрет или откровение в статье открыл. В общем-то изложенный вывод - это давно понятный в индустрии результат, ставший известным лет 15 так назад.

В итоге я, честно говоря, не вижу, в чём погрешил перед истиной, обобщив проблемы VLIW на Итаниум. Различия, конечно же, есть. Но они принципиально картины не меняют.

  1. Многопоточность — это в первую очередь T*S, где T кол-во потоков и S размер архитектурного состояния. Когда у вас 16/32 GPR/VFPR это может и не проблема, но вот когда 128/128 в IA-64 или 256 в e2k (и это ещё не всё архитектурное состояние), то дело уже не настолько просто. Опять таки больше транзисторов, но в статье вы этот аспект Itanium'a не упоминаете в контексте простого VLIW процессора, а он не такой уж и простой.

  2. Тактовая частота — это комплексная проблема поиска оптимального соотношения производительности, энергопотребления, стоимости разработки и тд. Я думаю не надо напоминать какие затраты идут на R&D в Intel и МЦСТ. Да и Itanium на этот момент фактически уже был похоронен. Упомянутый в статье 9760 из 2017 года, это освежённый Poulson из далёкого уже 2012 года. Мне очень сложно представить Э8С с тактовой частотой около 3ГГц, не только потому, что он на ней банально не заработает, а потому что он переплюнет всех остальных по энергопотреблению. Это к вопросу об энергоэффективности. Что-то мне подсказывает, что оба этих производителя не делали на этом слишком большой акцент в этих микроархитектурах.

  3. Предсказатель ветвлений из упомянутой статьи разрабатывался для сокращения энергопотребления в мобильном Э1С+. Процессоры из статьи явно не из этой категории.

  4. Смотря какая политика в планировании используется. Если планировать для ситуаций когда ядро всегда получает данные из L1d, то это имеет смысл. Насколько мне известно по умолчанию (без PGO) в lcc именно такая политика для неспекулятивных обращений.

  5. FMA ­— это обычно комплексная комбинаторная логика, что означает больше транзисторов. В приведённом Э8С это ещё не реализованно, а Э16С ещё даже нет в серийном производстве. В Poulson это 2 FMAC на ядро, а в Э16С будет 6 векторных FMAC на ядро.

  6. Я вам скажу больше, вы путаете такие понятия как VLIW и ISA заточенная под статическое планирование (не обязательно VLIW). IA-64 (изначально) и e2k заточены под статическое планирование. Но VLIW в IA-64 используется потому, что размер инструкции ~43 бита. Согласитесь, 43 бита не умещаются в 32, а в 64 будет слишком много неиспользованных. Если же абстрагироваться от кодирования, то сама идея EPIC очень плохо ложится не только на статическое, но и на динамическое планирование, это что-то среднее. Банально в OoOE не нужны стоп биты, то есть в Poulson эта информация рудимент прошлого (хотя и может упрощать переименование регистров), а для статического планирования это не подходит при изменении конфигурации микроархитектуры. E2k в этом плане более последователен, но со своими крайностями. Если же вернутся к OoOE в Itanium, то это не про dataflow как обычно принято, а про перемещение инструкций в конец очереди если её операнды не готовы в момент запуска. Грубо говоря, пока процессор ждёт 200 тактов данных из памяти, он всё это время "теребонькает" очереди. Опять таки, это лишнее энергопотребление, не говоря уже про необходимость переименования регистров. Опять таки, нужно больше золота транзисторов.

Если же подвести итоги, то на этом фоне микроархитектуры Эльбрусов выглядят очень очень плохо. Например в 9760 32 Мб L3, а в Э8С всего 16 Мб. Хотя то что физдизайн у Эльбрусов оставляет желать лучшего отнюдь не новость. Делать из этого далекоидущие выводы как минимум глупо на мой взгляд. Лучше было бы сравнивать Itanium'у с x86 тех годов, но опять таки с учётом специфичности IA-64.

Но в одном я с вами полностью согласен, что e2k слишком переусложнён, что и тянет его на дно из-за невозможности адекватно реализовать всё в аппаратуре.

На мой взгляд, наиболее разумное применение VLIW для in-order CPU в Denver от Nvidia. Скажем так, это современных взгляд на in-order VLIW без классических недостатков и развитие идей заложенных в Crusoe от Transmeta.

Надеюсь мой пост не получился слишком перегруженным.

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

Но потом вы сделали ошибку упомянув Itanium в статье. ;)

Все эти архитектурные споры вечны. Как говорит один умный человек: "It depends". Ну а через какое-то время потомкам приходится жить с тем, что было важно тогда в прошлом, вне зависимости о какой бы архитектуре мы сейчас не говорили. :)

ИМХО практика — главный критерий, если бы у итаника был хоть какой-то шанс, его бы не потопили.

Это всё из разряда: "Если бы у бабушки были...".

Я не хочу быть адвокатом ни для Intel, ни для МЦСТ, и топлю за объективную оценку ситуации. Но позволю обратить внимание на то, что у всех архитектур разные стартовые позиции, что может сильно сказаться на их успешности. Микроахитектура спокойно может быть OoOE, даже для того же IA-64. То есть вопрос не столько в том, что это RISC/CISC/VLIW/etc, а в самом дизайне ISA и насколько он удачен. Но не достаточно просто быть лучше. Рынок обчыно инертен и не любит сильных потрясений. Лучше всего когда появляется новая ниша и её удаётся быстро занять, но это происходит не часто. Itanium свою нишу не нашёл, а и IA-64 была не такой уж хорошей. Это камень в огород плотности кода у этой архитектуры.

Не надо делать поспешных выводов и экстраполировать опыт Х на все Y.

в Итаниуме был spill/fill регистров в память, автоматическое переименование регистров. Это разве есть в Эльбрусе?

Итаниум изначально был совсем не айс. Полсоны по производительности были OK, но было уже поздно.

В Эльбрусе всё это тоже есть

Не вижу в статье серьезных аргументов против архитектуры e2k. Складывается такое ощущение, что автору просто нравится устаревшая архитектура x86 и он ее всячески защищает.


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


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


Я также замечу, что в последнее время перестали расти частоты процессоров. Значит, нужно проектировать архитектуру под "медленные" процессоры и искать выигрыш в чем-то другом — например, в большем распараллеливании. Традиционные программы, где команды выполняются по очереди, больше не ускорить. Прирост, который дает Out-of-order execution и спекулятивное выполнение, тоже ограничен, и нужны новые подходы. За счет Ooo вы можете выполнить 3-4 операции за такт при удачном стечении обстоятельств, но не больше. Если вы хотите выполнять вычисления быстрее, вы должны либо иметь множество ядер (десятки-сотни) и многопоточную программу, либо придумать способ выполнять за один такт множество команд — 10, 20, 30.


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


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


Объективно я вижу два недостатка у Эльбруса:


  • непредсказуемость времени обращения к памяти может остановить конвейер. Наверняка с этим что-то можно сделать. Ведь такая же непредсказуемость есть и в Интеловских процессорах И они точно так же могут остановиться. А в Эльбрусах, как я помню, есть возможность фоновой предзагрузки данных из памяти.
  • отсутствие поддержки Эльбруса в JIT-компиляторах. Браузеры на лету компилируют JS-код в ассемблер, регулярные выражения компилируются в ассемблер, ява-код компилируется, базы данных компилируют код. И все они не поддерживают Эльбрус.

При этом, я вижу определенную несправедливость. Вышел Мак на ARM — переоцененное, бесполезное, не нужное железо с проприетарным закрытым софтом по завышенной цене. И все спешат адаптировать свои программы под него, выполняя бесплатно работу для самой богатой корпорации в мире. А для нашего Эльбруса никто ничего адаптировать не хочет.


При этих недостатках, у Эльбруса много хороших решений. Глупо было бы терять эти наработки.


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


Проблема в том, что своя архитектура означает портирование всего стэка софта, необходимого пользователям. А это колоссальные затраты

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


"Жирный" код, ведущий к повышенным кэш-миссам кода

Та же проблема есть в интеловских процессорах. Если процессор выполняет 4 инструкции за такт, он должен успевать подкачивать эти 4 инструкции.


Дополнительная нагрузка на кэш данных в следствие спекулятивного исполнения кода

Та же проблема есть у Интела.


Фактическая непереносимость кода между версиями процессора

Не вижу проблемы перекомпилировать код. Современные ОС вроде nix позволяют выполнить компиляцию из исходников и установку программы одной командой.

Нет проблем писать многопоточку для х86. Есть проблема писать эффективную многопоточку.

Эффективно утилизировать ядра тяжело, но и задачи такой не стоит. Если каждое ядро дает +50% производительности это уже отлично.

Я сам пишу на языке по мнению большинства плохо подходящего для написания многопоточности(С++) и не испытываю особых проблем чтобы эту многопоточность использовать.

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

Кроме x86 есть ARM и совсем свежий и открытый RISC-V например.

…я вижу определенную несправедливость. Вышел Мак на ARM…

И каждый желающий его может купить и софт писать. А с учетом, что дебиан давно и прекрасно работает на Арм (и 15 лет назад работал, помнится, я на армовском роутере даже PostgreSQL запускал и систему документооборота на Tcl, все работало без ошибок, хотя и медленно), никакой проблемы с софтом нет.

…по завышенной цене…

По сравнению со стоимостью эльбрусов - дешевле пареной репы.

…для нашего Эльбруса никто ничего адаптировать не хочет.

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

«Жирный» код, ведущий к повышенным кэш-миссам кода
Та же проблема есть в интеловских процессорах. Если процессор выполняет 4 инструкции за такт, он должен успевать подкачивать эти 4 инструкции.
Вы не понимаете проблему. Допустим, у вас есть абсолютно последовательный код (а это не такая редкость, тот же CRC32 не распараллелишь), например
X = ((A+B)*C+D)*E
Так называемая «широкая команда» Эльбруса должна выполнять в одной команде до 6 независимых операций. Но в первой «широкой команде» вы делаете только A+B, во второй *C, и т.д., забивая остальные 5 слотов арифметики NOP-ами, т.е. раздувая код пустыми операциями.
Не вижу проблемы перекомпилировать код. Современные ОС вроде nix позволяют выполнить компиляцию из исходников и установку программы одной командой
Проблема в том, что современный капиталистический мир насквозь проприетарный, и вам никто исходников не даст. А если попросите вендора перекомпилить код под ваш новый проц, так он денег попросит за поддержку, а то и вовсе окажется, что год назад обанкротился.
НЛО прилетело и опубликовало эту надпись здесь
Не вижу в статье серьезных аргументов против архитектуры e2k.

Ой, всё. Ваши аргументы — не аргументы!(с)

х86… очень плохо подходит для современных процессоров

Смешно, учитывая что на этой архитектуре созданы самые быстродействующие процессоры в мире.

Любая новая архитектура, спроектированная с учетом параллелизации, будет лучше интеловской.

История показывает что это не так.
Как и delay слоты это вынос попытка выноса микроархитектурных детали в архитектуру является глубокой ошибкой. Софт нужно будет пересобирать под каждый процессор.
На новых чипах старый код выполняется неэффективно.

За счет Ooo вы можете выполнить 3-4 операции за такт при удачном стечении обстоятельств, но не больше.

M1 декодирует 8 команд, а выполнять из ROB может ~17 штук за такт.

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

OoO движок выполняет все инструкции до которых можно дотянутся пока данные из памяти идут. В M1 буфер переупорядочивания отслеживает 630 инструкций.
www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2

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

А где её нет?

Вышел Мак на ARM — переоцененное, бесполезное, не нужное железо с проприетарным закрытым софтом по завышенной цене.

Ахаха. Ну надо же какое нелепое и бессмысленное зубоскальство. По какой шкале вы «ненужность» замеряли? Для сотен миллионов людей железо крайне полезное и нужное.
Всего-то процессор с самым быстрым однопотоком ever.

проприетарным закрытым софтом

Особенно ОС и компилятор.
opensource.apple.com
github.com/llvm/llvm-project

И все спешат адаптировать свои программы под него, выполняя бесплатно работу для самой богатой корпорации в мире.

Как же так? Ведь быть такого не может? :)
Всего-то лучший процессор для ноута, не имеющий конкурентов.

А для нашего Эльбруса никто ничего адаптировать не хочет.

Эльбрус это у вас образчик открытости и полезности :)
И особенно образчик доступности.
Не, я бы конечно купил Эльбрус без того пистолета у виска, но кто ещё?
Более того, с Эльбрусом приходилось работать.

При этих недостатках, у Эльбруса много хороших решений. Глупо было бы терять эти наработки.

Какие? Архитектуру нужно было закопать и забыть ещё в нулевые.

Идея сделать сложный компилятор вместо сложного процессора однозначно хороша.

Хороша ложка к обеду.
А идея это давно устарела. Как показывает практика, «умный» компилятор сделать невозможно даже при неограниченных ресурсах.
Процессор со статическим планированием может эффективно работать только со статической памятью никогда не сможет эффективно выполнять сложный код. Удел VLIW — это DSP. Адекватные люди его так и используют.

Не вижу колоссальных затрат в запуске компилятора

Ну возьмите и портируйте туда языки программирования с JIT. Пара пустяков, да?

Если процессор выполняет 4 инструкции за такт, он должен успевать подкачивать эти 4 инструкции.

Нет проблем подкачивать инструкции. На х86 Fetch получает 16/32 байта каждый такт из кэша.
Но то что выполняется в цикле, обычно лежит в МОП-кэше, откуда достаётся по 6 инструкций (Sandy Bridge+).

travisdowns.github.io/blog/2019/06/11/speed-limits.html

Не вижу проблемы перекомпилировать код. Современные ОС вроде nix позволяют выполнить компиляцию из исходников и установку программы одной командой.

Ясно, понятно.
Весь бизнес Интел построен на том, что «не нужно перекомпилировать код».
Вы его перечеркнули одним высказыванием.

Юзверь ведь захочет ждать несколько часов/дней, пока соберётся какой-нибудь Chromium на его машине.
Или разраб захочет держать шесть дистрибутивов каждой версии софта под каждую версию Эльбруса, который есть у нескольких человек в мире. Так держать!

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

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

С учётом inline вызов функции выкидывается и оставшаяся целочисленная операция сложения(которая будет осуществляться в регистрах) - это действительно почти везде 1 такт.

Боюсь, вы были невнимательны при чтении статьи. Речь о том, сколько будет выполняться тело цикла, если не удалось подставить функцию (например, она в другом модуле компиляции). Или вы считаете Эльбрус настолько отстающим, что у него одно целочисленное сложение занимает 17 тактов?

К сожалению, только вы не поняли, что значит разница между inline & VLIW - и, пожулайста, адресуйте своё непонимание к автору статьи.

Действительно, не понимаю, как можно сравнивать inlining и VLIW. Подстановка функции - это техника оптимизации, работает под любую архитектуру, в том числе VLIW, в том числе Эльбрус.

И этот вопрос я адресую именно вам, потому что автор верно понял мой первый вопрос и ответил на него, а подмена понятий началась у вас.

Вы точно не так поняли написанное или, может, вообще в теме не разбираетесь...

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

А вот при отсутствии инлайна как Эльбрус, так и Интел сильно просядут и даже в Интел вряд ли будет 1 такт.

Разве спекулятивное исполнение не позволит интелу и без, и с инлайном сразу начать выполнение следующей итерации?

Ну начать може и сможет, в зависимости от того, как организован цикл. Но все равно всё встанет на инкременте переменной, потому что это зависимость между итерациями.

Это если есть инкремент, ну ок. А в чем тогда разница с VLIW? Он же тоже упрется в инкремент. Если компилятор не раскрутит цикл, то получится все так же одна итерация за раз. А если раскрутит, то тут и интел неплох будет.

У Эльбруса в архитектуре есть поддержка циклов, так что в счетчик не упрётся.

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

Виртуальную функцию заинлайните?
Сколько может трекать ОоО, столько итераций и будет выполняться за такт.
В общем случае инкремент ограничит время выполнения скалярного кода до не более чем 1 итерации за такт.
Если это является препятствием, можно цикл раскрыть.
(и то, если компилятор не раскрутит цикл).

Звучит как угрозакак будто раскрутка ухудшит ситуацию.

но далеко не каждый цикл можно раскрутить

Тогда и на Эльбрусе с этим ничего не поделаешь.

А вот при отсутствии инлайна как Эльбрус, так и Интел сильно просядут и даже в Интел вряд ли будет 1 такт.

Интел сильно не просядет. Время увеличится только на пролог/эпилог функции.
Сall/ret эффективно занимают 0 тактов благодаря предсказателям и аппаратному стеку возврата.

У Эльбруса в архитектуре есть поддержка циклов, так что в счетчик не упрётся.

И что? Счётчик циклов позволит выполнять несколько широких команд за такт? Или несколько итераций внутри широкой команды?

В общем старания ваши и товарища sabubu выше, непонятны.
E2K изначально спроектирован так, чтобы быть низкочастотным, неповоротливым процессором, который может эффективно выполнять только распараллеливаемые циклы без переходов.
C современными микроархитектурами его сравнивать нельзя и я даже не говорю о векторных ISA типа ARM SVE.
Это как сравнивать каменный топор с современным.

>Или несколько итераций внутри широкой команды?

Именно так, наслаиваясь. Конвейерная обработка циклов. Может как-то еще хитрее можно выполнять, но это уже не в моей текущей компетенции.

Именно так, наслаиваясь. Конвейерная обработка циклов.

Поддержка (софт)конвейеризации циклов это костыль, который сделан чтобы компенсировать зависимости инструкций внутри одной итерации цикла.
OoO движок может «наслаивать» десятки итераций, а не 2-3.

Когда уже ясно, что из системы команд уже практически всё выжато.

Что выжато? Если смотреть источник повышения производительности, хорошая система команд даёт 5% производительности, а 95% даёт хорошая микроархитектура. Через пару лет OoO будут иметь окно переупорядочивания в 1000 инструкций, вместо 630 сейчас.
За такт может выполняться не 17, как сейчас, а больше инструкций, а уж найти их процессору в этом окне гораздо проще, чем в исходной программе компилятору.
Поймите, ISA это просто API. Внутренности процессора могут быть устроены как угодно.

А мне непонятны старания людей, пытающихся доказать, что за CISC/RISC будущее.

Людей, которые видят, что ваш воображаемый мир Очень Длинных Розовых Пони плохо соотносится с объективной реальностью?

PS: Не только будущее, но и настоящее.
НЛО прилетело и опубликовало эту надпись здесь

А мне непонятны старания людей, пытающихся доказать, что за CISC/RISC будущее. Когда уже ясно, что из системы команд уже практически всё выжато.

Когда уже ясно, что из системы команд уже практически всё выжато

разумеется, прогресс идёт не в системе команд, а в отвязке системы команд от реального процессора.

Определенно за ними будущее, раз на горизонте нет ничего близко, что может их заменить. А прогресс весь идет в микроархитектуре. В систему команд добавляются лишь специализированные инструкции под шифрование, сжатие, ML тот же. Сейчас большой упор делается не на совершенствование ядер, а на обвязку, потому что там основные ботлнеки. Тут у нас HBM как процессорный кэш, 3d stacking, всяческие тайлы и чиплеты, интерконнекты на подложке вроде infinity fabric, интерконнекты на уровне системы вроде CXL, новые интерфейс для оперативной памяти. Процессоры нынче уперлись в скорость подсистемы памяти и кэши, это самое узкое место. Никакая новая система команд это не изменит.

В случае инлайна Эльбрус сможет выполнять сразу несколько итераций цикла за такт, а вот интел не больше одной
Не понимаю, как это. Если в цикле есть зависимость следующей итерации от предыдущей, никакая магия VLIW тут не спасёт. Если же задача хорошо распараллеливается, типа скалярного произведения для умножения матриц, тут последняя версия AVX будет умножать по 8 double за раз, а не по 6, как в «широкой команде».

6 векторов по 128 бит в последних Э.

Вот ссылка на ролик из поста с таймкодом на нужный слайд презы МЦСТ
https://youtu.be/Jwt5mSmtoXA?t=3010

Не указаны, какие именно операции можно делать со 128-битными значениями. Может, только сложение 4*fp32, или 2*fp64. А может, вообще только integer арифметика, как у первых Pentium MMX ))

Странно, что они так шифруются и никакой информации не выдают.

Ой, как хорошо, что вы вспомнили AVX. Это же такие general-purpose инструкции! Еще хуже, чем VLIW ) Интересно, зачем они появились в процессорах? Может потому, что в системе команд не хватало параллелизма?

И нет, в Эльбрус гораздо меньше поводов упереться, потому что у него есть аппаратная поддержка выполнения циклов. Некая конвейеризация. Он может наслаивать итерации друг на друга.

Эту конвейерезацию должен сделать компилятор, и это не всегда возможно. В проце с OoO конвейеризация работает всегда автоматически.

Ой, как хорошо, что вы вспомнили AVX. Это же такие general-purpose инструкции! Еще хуже, чем VLIW )
Настолько general-purpose, что c/c++ компиляторы полностью заменили FPU на векторные регистры, да ещё агрессивно циклы разворачивают
Интересно, зачем они появились в процессорах? Может потому, что в системе команд не хватало параллелизма?
Ой, что делают, гады! В свои плохие процессоры тащат то, что позволит им вырваться вперёд! Это же нечестно!!!
Особо смешно, что судя по тестам Sandy Bridge скорее всего всё равно будет заметно быстрее, даже если тестовые приложения откомпилить вообще без SSE/AVX.
НЛО прилетело и опубликовало эту надпись здесь
Экий юношеский максимализм :)

Представьте, что у вас есть суперскаляр мечты: конвеер на 4096 одновременно выполняемых команд, идеальный предсказатель ветвлений, идеальный префетчер, OoO глубиной 65536 и т.д.

Но! Этот суперскаляр 8-битный. А мы молотим длинные числа, чтобы перемножить пару чисел, надо сделать 32 коротких умножения. И тут один инженер выдвигает гениальную идею: а что если регистры сделать 16-битными. Это же незадорого вдвое ускорит нам сложение, и вчетверо ускорит умножение. И тут появляетесь вы и начинаете их учить уму-разуму: фу-фу-фу, это что, ваш Суперскаляр зашёл в тупик? Вы что, не можете докинуть 8-битных исполнительных модулей и улучшить конвеер? Не-не-не, ни в коем случае не делайте 16-битные вычислители.

Это примерно то же самое, что вы сейчас про SIMD.
НЛО прилетело и опубликовало эту надпись здесь
Если мы начинаем туда интегрировать элементы "влив"(т.е. явный параллелизм), то это ничто иное как принятие несостоятельности суперскаляра как такового.

а как же simd?

НЛО прилетело и опубликовало эту надпись здесь
Проблема суперскаляра не в суперскаляре, а в говнокоде который на нём пускают
Кто делает «говнокод»? Компиляторы или люди? Если люди, то не «говнокод» — это то, что идеально исполняется на процессоре, или легко читается/понимается другими людьми?
Ширина операций никак не связана со свойствами влива/суперскаляра. Поэтому попытка провалилась
Нет, это вы ничего не поняли. SIMD — это не VLIW!

Во-первых, SIMD — это попытки ввести в архитектуру тип данных, с которым нативно оперирует программа. Если 3d-редактор работает с векторами (x,y,z,w) и матрицами 4x4, то введение SIMD-регистров на 4 double с действиями над ними, полезными для предметной области, это и есть перестройка АЛУ под задачи предметной области, а не какой-то там VLIW.

Во-вторых, введение SIMD нахаляву даст нам хороший прирост производительности, если прямое развитие упёрлось в предел (это не значит, что суперскаляр плохой, любая технология упирается, иначе бы рост был до бесконечности), потому что это шаг в сторону. Если вы из-за каких-то религиозных соображений не приемлете такой шаг, это просто глупо.
Суперскаялар предполагает(да и это прямо выводится из ваших рассуждения), что суперскаляр состоятелен сам по себе
Где вы это увидели? Приведите цепочку рассуждений, с цитатами. Моя позиция такая, что если текущее развитие суперскаляра упёрлось в 150 условных попугаев на ватт, а развитие VLIW упёрлось в 120, то боттлнеки можно легко снять, введя в архитектуру гибридные элементы и получить сразу 200 попугаев. А вы хотите вечно сидеть на 150? Или с болью выжимать из старых идей ещё по капле, до 160 и 130 соответственно, зато не поступиться «чистотой».
НЛО прилетело и опубликовало эту надпись здесь

У суперскаляра нет ни одного преимущества перед вливом. Поэтому никаких 160/130 там нет. Просто начните влив понимать правильно. Влив - это класс архитектур с явным параллелизмом. Т.е. это не-скалярные архитектуры. И осознайте, что он может делать всё тоже самое, только лучше.

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

НЛО прилетело и опубликовало эту надпись здесь
Планирование борется в основном с легаси-вендорлок-дерьмом, а так же с неоднородностью памяти. Но эти проблемы порождены самим суперскаляром
Про память вы уже не первый раз пишете. Мне интересно, как вы себе представляете идеальную организацию памяти.
НЛО прилетело и опубликовало эту надпись здесь
Я хотел поподробнее, тип памяти, количество, расположение.
Например, «128 Гигабайт SRAM на кристалле у каждого ядра». Только сколько это будет стоить?
НЛО прилетело и опубликовало эту надпись здесь
По идее, вы должны понимать, что многоуровневая память — компромис между скоростью доступа, объёмом и ценой. Но мне всё больше кажется, что здесь вы чтобы троллить )))
НЛО прилетело и опубликовало эту надпись здесь
Т.е. мы имеем многоуровневую физическую память в одноуровневым адресспейсом. Я же предлагаю многоуровневаю с многоуровневым.

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

НЛО прилетело и опубликовало эту надпись здесь

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


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

НЛО прилетело и опубликовало эту надпись здесь
Делают компилятор люди, которые являются жертвами школы суперскаляра. Компилятор еж пытается с этим бороться.
Ничего не понял. Компилятор пытается бороться со своими создателями?
SIMD — это не VLIW!
Это влив
Никакой «влив» будь то эльбрус, либо итаник вливами не являются, номинально
Жесть. Сначала у вас SIMD это VLIW, затем Эльбрус это не VLIW ))
Симды — это развитие векторных процессоров. Векторные процессоры это противоположность скалярным. Основным их свойством является параллельная обработка данных
И отсюда вы делаете вывод, что SIMD это VLIW. Это ошибочный вывод. Потому что VLIW и векторный процессор — это про разное.
Оно даст не на халяву. Это так же несостоятельные рассуждения. Вектор стоит столько же, сколько и несколько отдельных скаляров
Значит, вы не понимаете профита от SIMD. А профит в том, что в программе есть типичные действия, такие как сложение или ужножение векторов. И их можно делать одной инструкцией, экономя на размере кода. Никакой VLIW не позволяет добиться этой цели, потому что во VLIW сложение каждого компонента с каждым надо запрограммировать, и это занимает место в коде.

Приведите цепочку рассуждений с цитатами, где вы бы выступали за синергию подходов
Так с самого начала
Ой, что делают, гады! В свои плохие процессоры тащат то, что позволит им вырваться вперёд! Это же нечестно!!!
Если вы не поняли, это ваши проблемы

У суперскаляра нет ни одного преимущества перед вливом
На моих типичных задачах нет параллелизма: обход дерева в глубину, вычисление CRC, кодирование-декодирование Хаффмана, парсеры текстов, компиляторы. VLIW тут будет как собаке 5-я нога, потому что параллелизма нет, и 90% мощностей тупо не будет задействовано. Но для вас эти задачи мусор и говнокод.
Единственное что он не может — это исполнять скалярное легаси-вендорлок-дерьмо
Удачи вам на задачах моделирования погоды, ядерных взрывов и прочих уравнениях мат. физики. А мне процессор не для этого нужен.
НЛО прилетело и опубликовало эту надпись здесь
Делают говнод люди, которые являются жертвами школы суперскаляра
Ну ясно. То есть люди должны писать под процессор, а не в терминах предметной области. Но это очень дорого. А потому у нас везде будет «говнокод». И нужны процессоры, которые хорошо это прожуют.
Вот симд это влив(как то, чем он является). Эльбрус — это влив(как то, чем является). Эльбрус это не влив(как неверное обывательское представление о вливе)
Хватит! VLIW — это широкая команда, EPIC — явный параллелизм. Ну вот просто по определению этих буковок. Если вы будете продолжать писать vliw вместо epic, придётся делать эти замены при чтении. Но тогда отвечать я вам не смогу — не буду же я эти замены делать, чтобы лично вам было удобно читать в ваших терминах, а не общепринятых.
Влив и векторный процессор — это про одно и тоже. Про явный параллелизм. Скаляр же про неявный
Подмена терминов, выше уже писал, что я об этом думаю.
Во-вторых зачем вам тогда суперскаляр? Суперкаляр это как раз таки про параллелизм
90% мощностей тупо не задействовано. Чушь потому что 90% мощностей суперскаляра на этом говнокоде так же задействовано не будет
На моих не параллельных задачах суперскаляр иногда выискивает резервы для параллелизма, и иногда это выстреливает. Дополнительно получить 20-40% ускорения — почему бы и нет?
То, о чём я говорил выше, а именно: «задачи мусор и говнокод», когда я говорил о том, что говнокод это именно решение задачи. Это обычная попытка снять с себе ответственность. Если проще, то человек заявляет «нет плохих реализаций — это всё просто следствие задач», что, очевидно, противоречит наблюдаемой реальности
Чушь. Хотите сказать, что сможете написать кодер Хаффмана для вашего VLIW/EPIC, который бы загрузил полезными действиями все исполнительные модули на 100%?
НЛО прилетело и опубликовало эту надпись здесь
Дальше нужно объяснять?
Не нужно. Всё что нужно, я понял ))
НЛО прилетело и опубликовало эту надпись здесь
Пытался, когда думал, вы серьёзно. А вы тут просто рофлите, выдавая нечто несуразное и ждёте, когда все вам наперебой кинуться доказывать, что белое это белое, а чёрное это чёрное )))
НЛО прилетело и опубликовало эту надпись здесь

Кстати, судя во всему этот персонаж ботвы с собой нагнал. Потому как как-то яро начали минусовать мои ответы ему, а его плюсовать.

Простите, что врываюсь в вашу почти приватную дискуссию, но не могу удержаться и задам вопрос: А почему Вы уверены, что причина в мифических ботах, а не в Вашей манере вести беседу? Тут в комментариях люди до сих пор не очень любят, когда какой-то недавно зарегистрированный человек оставляет комментарии формата "очевидно вы все не правы" и всячески пытается выставить что вокруг только он один в белом плаще, еще и используя переходы на личности.

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

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

НЛО прилетело и опубликовало эту надпись здесь

Любимые оправдания ботов. Какая манера? Где манера? Почему у него её нет?

То есть я Вам хотел помочь объяснив в чем Ваша проблема и я за это еще и бот? Отлично, спасибо.

Какая манера? Просто - Вы хамите людям, пишите так, словно Вы звезда уровня мировой величины и Ваши слова истина не требующая доказательств. Почему у него (кстати у кого?) ее нет - я не знаю, не ко мне вопрос.

Почему минусовали/плюсовали именно мои ответы ему/его ответы мне? Почему плюсовали откровенное вранье, которое проверяется про ctl+f за пару секунд? Почему в принципе плюсовали не читая?

За Вашу манеру выражаться и полное отсутствие доказательств.

А т.е. кумоство? Да, высокий уровень для технического ресурса.

Странные выводы из моего сообщения, но нет, не кумовство, а не любят людей которые с порога хамят.

Показывайте такие комментарии.

Про "очевидно" с Вашей стороны:

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

Хотите больше? два

Про "один я в белом плаще": раз, два, три

Меня удивляет эти бригада поддержки, которая прибегает и сообщает "ненужно аргументации уровня "очевидно"", но при этом пишет:

См. этот комментарий. Впрочем от меня Вам это будет последний коммент, так что можете не распаляться на ответ.

Естественно нет. Ну и да, где пруфы того, что использовал я, а не он? Идите объясняйте его факапы.

Ну раз нет, то нет. Потом только не удивляйтесь что вас будут считать за человека, который не разбирается примерно ни в чем. Если Вас это устраивает - кто я такой чтобы Вас останавливать?

К тому же тут Вы извратили смысл сказанного мною. Я Вас не обвинял, а намекал на то чтобы Вы пересмотрели Вашу дискуссию с другими об определениях и подкрепили Ваши определения ссылками (обязанность доказывать по правилам хорошего тона лежит таки на Вас, если Ваша цель обсудить, а не развести полемику). Но в плане доказательства что Вы использовали я воспользуюсь Вашим же приемом и скажу что Ваше "Естественно нет" исходя из правил русского языка можно трактовать как то, что Вы понимаете что используете изобретенные Вами термины (по контексту), так что Вы сами только что признались.

И жду, чтобы вы написали каждому, кто называл итаник/эльбрус вливов ту же самую херню. Или только клоунада?

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

За сим оставлю Вас наедине с этим новоприобретенным знанием. Все таки это не вежливо в технической (и даже псевдотехнической) дискуссии объяснять людям за что им сыплются минусы. Хотите продолжить - добро пожаловать в личку, я Вам там постараюсь подробнее объяснить почему я считаю, что в Ваших минусах виноваты Вы, а не мифические боты.

P.S. Предполагаю, что Ваш следующий ответ тоже ничего конструктивного кроме перехода на личности или попыток пояснить почему "очевидно" и "стою в белом плаще" это нормально и единственно верно, а я не прав (без доказательств естественно) содержать не будет. Но приятно удивлюсь, если Вы таки воспримите что я Вам сказал и поменяете свой стиль общения в этом тредике.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
> Мы видим здесь какие-то пруфы? Какие-то рассуждения о том как мы к этому приходим? Нет. Это просто пустое заявление.

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

У вас почти в каждом комментарии про мнение оппонента написано «чушь», «мусор», «рак» и т.д. Безаппеляционная уверенность в своей правоте, не свойственная думающим людям.

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

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

Да нет, сидит (по крайенй мере сидел) в телеграме, все так же вопит про методички и блеющих скриптодетей

НЛО прилетело и опубликовало эту надпись здесь

Удачи вам на задачах моделирования погоды, ядерных взрывов и прочих уравнениях мат. физики.

Число дробилки векторизируются. Не вижу тут проблем, их даже не гпу считают часто.

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

Нет, это не влив.


VLIW — архитектура процессора с несколькими вычислительными устройствами и явное указание процессору, какие инструкции должны выполняться параллельно. Суперскалярность же — это неявная параллельность (впрочем, вы это и сами понимаете).


SIMD в x86 не обладает признаками влива. Да, поначалу может показаться, что мы явно указываем сделать несколько операций параллельно, и потому это должно быть VLIW. Но нет, это одна команда, которая задействует одно векторное вычислительное устройство и потому является одной операцией над вектором. К слову, скалярные операции работают на тех же самых векторных устройствах и по факту являются просто подмножеством векторных.


Так что ваше заблуждение: вы классифицируете SIMD как VLIW по признаку параллельного выполнения операций. На самом же деле VLIW — это параллелизм по признаку параллельного задействования вычислительных устройств.


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


С небольшой натяжкой можно классифицировать SIMD как VLIW на первом Zen, в котором имелись только 128-битные векторные вычислители, и использование 256-битных команд требовало задействования сразу двух устройств. То есть можно работать с данными как используя 128-битный SSE, так и 256-битный AVX, и при этом в теории не должно быть разницы в производительности.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Этот суперскаляр 8-битный. А мы молотим длинные числа, чтобы перемножить пару чисел, надо сделать 32 коротких умножения. И тут один инженер выдвигает гениальную идею: а что если регистры сделать 16-битными.

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

Прежде всего, вы согласны, что чем длиннее нативное процессорное слово, тем быстрее работает длинная арифметика?

Согласны, что умножение 32x32 можно расписать как 16 умножений 8x8 и кучу сложений? Согласны, что часть умножений и сложений при этом можно делать параллельно?

Мой пример о том, что некий суперскаляр с высоким параллелизмом и 8-битными блоками умножения мог бы справиться с умножением 32x32, и все его хитрости типа параллелизма и OoO были бы в этой задаче востребованы. Но гораздо проще ввести блок 32-битного умножения.

Аналогично, у нас есть задачи (сложение/умножение векторов, например), которые можно писать обычным скалярным кодом, и процессор может его пытаться параллелить. Но есть предел наращивания производительности таким путём. Проще ввести специальную инструкцию, что и делает SIMD.

Кому проще? Получается вы предлагаете реализовать новую инструкцию в железе? Или на уровне микрокода?

В железе, иначе не получить нужное ускорение.
fpu не существует в amd64. Там есть только тормозная эмуляция fpu.

Ахах. Что, прямо на интах, как в 80-е?

Симд это элементы явного параллелизма. Они как раз говорят о неспособности неявного конкурировать с янвым в этих задачах.

SIMD это лёгкая возможность добавить явного параллелизма, не теряя «неявного». Это говорит лишь о том, что расширить ALU проще и эффективнее чем добавить ещё несколько независимых юнитов.
Ахах. Что, прямо на интах, как в 80-е?

Нет. Через микрокод. Из-за этого latency у команд FPU выше, чем у аналогичных команд SSE/AVX.

Нет, не из-за этого, а из-за того, что x87 (мы же про него говорим? потому что FPU это и x87, и SSE/AVX тоже) работает с 80-ти битными регистрами, в то время как SSE/AVX с 32/64.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Это не спасёт и суперскаляр.
Ага. Потому что я комментирую вот эту ерунду:
В случае инлайна Эльбрус сможет выполнять сразу несколько итераций цикла за такт, а вот интел не больше одной

Да, я хотел чтобы статья была максимально простая. Иначе если уйти в технику, там вообще мало кто понимать начнёт, да и по объёму очень много получится. Но какие-то конкретные вещи я может потом распишу, если будет интерес у публики.

Что касается одного такта на других архитектурах. Там всё упрётся в количество инструкций перехода, которые конвейер может переварить за такт (но 2 там минимум должно быть) и скорость фетчинга кэш-линий. Последнее в современных Интелах решится кэшем микроопераций. Ну т.е. я прямо не проверял, но почти уверен, что будет 1-2 такта на топовых моделях.

сейчас проверил, на i5-3570 1ккк циклов выполняются за ≈1.9 с против ≈1.6 с у заинлайненной функции.
разница примерно на такт. это, конечно, не «итерация цикла будет занимать ~1 такт», но всё равно очень впечатляет.

 i5-3570 всё же чип 9-летней давности и не топовой линейки. И я не помню, был там кэш микроопераций уже или нет. Но идейно понятно, что там происходит. Просто для x86 с OoO это просто вопрос, нужно ли добавить ещё транзистров, чтобы съедать такой код за такт. А на Эльбрусе если компилятор не справился - то всё, 17 тактов и никуда не деться.

i5-3570 всё же чип 9-летней давности и не топовой линейки. И я не помню, был там кэш микроопераций уже или нет.

проверил на xeon 6144 (≈1.9 с и ≈1.5 с соответсвенно), ryzen 5950x (≈1.3 с и ≈0.4 с).
у древнего i5, получается, самые маленькие потери от отсутствия инлайна.


update: о, нашёл, у scalable второго поколения (4214) фактически нет разницы между не-инлайн и инлайн версиями, ≈1.85 с и ≈1.9 с (разница того же порядка, что и разброс между последовательными запусками).


P. S. только не уверен, что этот пример что-то показывает, есть сомнения, что процессор на реальном коде сможет «закэшировать» вызов функции.

Вы заставили меня дойти до компа ))

Значит сдаётся мне, что вы скомпили код с опцией -O0, а это не то, что мы хотим мерять. Надо подать -O2.

Функцию get_inc_val надо  с помощью атрибута __attribute__ ((noinline)) указать как не подлежащей инлайну в случае тестирования с вызовом (иначе компилятор её насильно заинлайнит)

Для тестирования случая с инлайном я в цикл добавил asm("nop"); иначе компилятор просто свернёт цикл.

В итоге оба случае на моей машине Intel Core i5-7500 3.4 GHz работают ~0.3c.

нет, собирал с -O3.


давайте ассемблерные варианты сравним


вариант без inline:


.L2:
        xorl    %eax, %eax
        call    get_inc_val@PLT
        cltq
        addq    %rax, %rbp
        cmpq    %rbx, %rbp
        jle     .L2

вариант с inline (тут я использовал volatile, чтобы компилятор не выбросил цикл совсем, так что появился «лишний» код, без него, теоретически, должно быть быстрее):


.L5:
        movq    8(%rsp), %rax
        addq    $3, %rax
        movq    %rax, 8(%rsp)
        movq    8(%rsp), %rax
        cmpq    %rdx, %rax
        jle     .L5

У вас в первом варианте функция вообще через PLT вызывается, а во втором со стэком идёт работа, что явно не -O3 (или volatile к такому привёл). Сейчас приведй пример ассемблера, который у меня получился.

У вас в первом варианте функция вообще через PLT вызывается

да, я её поместил в отдельный .c файл.


или volatile к такому привёл

да, я же про это написал

Так, со временем кода с вызовом я наврал . Там компилятор разобрался, что значение в вызове не меняется и просто убрал его из цикла. Я добавил asm ("nop") в код функции, в итоге получил ~1с.

Дизасм кода с инлайном (0.3 с) :

main:
...
 4f8:        90                           nop
 4f9:        48 83 e8 01                  sub    $0x1,%rax
 4fd:        75 f9                        jne    4f8 <main+0x8>

Дизасм кода без инлайна (~1с):

0000000000000630 <get_val>:
 630:        90                           nop
 631:        b8 01 00 00 00               mov    $0x1,%eax
 636:        c3                           retq  

main:
...
 500:        31 c0                        xor    %eax,%eax
 502:        e8 29 01 00 00               callq  630 <get_val>
 507:        48 01 c2                     add    %rax,%rdx
 50a:        48 81 fa ff c9 9a 3b         cmp    $0x3b9ac9ff,%rdx
 511:        76 ed                        jbe    500 <main+0x10>

Тут в глаза бросается, что у нас не очень оптимально цикл получился во втором случае (2 лишних операции + 16 байтную границу кода пересекли 2 раза, не считая call, а это лишние ifetch). Но дальше ковыряться с компилятором мне лень, считаем что в таком случае работаем 3 такта. Можно потестить на топовых Интелах, там фронтенд шире и по идее должен всё скушать за 1-2 такта.

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

НЛО прилетело и опубликовало эту надпись здесь
Таким образом мы получаем минимум 2-3 инструкции

даже так, согласитесь, это очень немного.
тут рядом для эльбруса озвучили 17 тактов на call/ret.

НЛО прилетело и опубликовало эту надпись здесь
Перечитайте ещё раз. Это самый минимум в вырожденно-лучшем случае

перепроверил на свежую голову: привёл ассемблерный код к одному виду, получил разницу 3-5 тактов на цикл (в зависимости от процессора) на коде с call/ret и без него.

НЛО прилетело и опубликовало эту надпись здесь

За последние 10 лет процессоры принципиально не ускорились. И это и есть основная проблема SSOoO - их дальше становится нецелесообразно ускорять.

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

Ничего себе растет. Вы помните, как росла производительность лет 20 назад? А что сейчас? Почему тогда мне особо не на что поменять процессор 10-летней давности за разумные деньги? Да даже за неразумные я получу максимум 50% прироста на ядро. И это за 10 лет? Это шутка такая? А до недавнего выхода zen 3 и этого не было. У Интел с Core 2000 где-то по Core 8000 вообще прирост был мизерный.

Некоторые специалисты вообще говорят, что график роста переломился в 2006 году (собственно, и неспециалисту это наглядно видно на графике). А второй раз году в 2011.

У вас было два тезисе. «За последние 10 лет процессоры принципиально не ускорились» если у вас настолько большие запросы, то наверное не ускорились. Я по графикам вижу постоянный рост от поколения в поколение, плюс повышение числа ядер. Можно спокойно периодически менять проц и видеть серьезный прирост.
Второй тезис — «их дальше становится нецелесообразно ускорять». Это просто неправда. Производительность растет, микроархитектура постоянно оптимизируется.

>микроархитектура постоянно оптимизируется
каждая следующая оптимизация в среднем дает меньше прироста и стоит дороже. Висящие на нижних ветках фрукты собраны. Дальше станет только хуже.

>у вас настолько большие запросы
Очень даже обычные. Ну серьезно, какому пользователю есть смысл покупать процессор процентов на 30 быстрее за немалые деньги?
И от числа ядер далеко не все задачи выигрывают. Вообще рост числа ядер как раз от сложности дальше ускорять одно ядро.

Вот расскажите, какие вы видите пути существенного ускорения SSOoO процессоров?

Почему тогда мне особо не на что поменять процессор 10-летней давности за разумные деньги? Да даже за неразумные я получу максимум 50% прироста на ядро. И это за 10 лет?

Если вспомнить, что их этих 50% львиная доля приходится на последние 2-3 года, то всё не так уж плохо.
Ну и непонятно, почему вы сбрасываете со счетов многоядерность. Рост частоты не может быть бесконечным, с ростом ipc тоже не всё просто, так что основной вектор развития сейчас — рост числа ядер, тут пока всё хорошо. Да, требуется поддержка со стороны софта, но она неизбежно будет всё лучше и лучше.

> она неизбежно будет всё лучше и лучше

Это говорят уже 15 лет. И все равно приходится продолжать говорить. Потому что многопоточная обработка порой очень сложно даётся.

Это говорят уже 15 лет

и все 15 лет идёт увеличение числа ядер на декстопах, телефонах и т. п.

Вот телефоны здесь вообще не к месту. В телефонах главный ограничивающий фактор — энергопотребление. По мере повышения энергоэффективности процессоров росло значение IPC, и пока ещё есть куда двигаться дальше в этом направлении.


Так, за последние 10 лет производительность на ядро для мобильных процессоров выросла почти на порядок, тогда как для десктопных процессоров — в полтора-два раза.

но и число ядер в телефона за те же 10 лет увеличилось на порядок, было бы странно наращивать их число, если софт не умел использовать более одного ядра

НЛО прилетело и опубликовало эту надпись здесь

Последние 10 лет производительность процессоров растёт как раз за счёт улучшения микроархитектуры. Хотя , конечно же, рост там не такой, как в 90-х и начале 2000-х

Вот именно, за 10 лет получили 50% прироста. И какой ценой? Это говорит о том, что пора что-то менять. Например, систему команд с последовательной на явно параллельную.

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

Они умеют извлекать очень мало параллельности. К тому же, зачем ее извлекать, когда ее можно явно закодировать?

А то как-то странно получается, что мы пишем алгоритм (может даже в какой-то степени параллельный) на последовательном языке, потом процессор пытается извлечь параллелизм, и потом он же пытается заретайрить инструкции последовательно. Хотя можно было бы тут везде иметь слово "параллельно".

Весь код можно поделить на «классический последовательный» — это работа GUI (диспетчеризация вызовов), чек-суммы, сортировки, кодирование-декодирование Хаффмана и т.п.
И на «числомолотилки».

В первом случае «извлечь параллелизм» можно неглубокий, максимум на конструкциях типа (x+1)*(y+1), и там за 20-30 лет процессоры прекрасно справляются через OoO.
Это в 1990-х было сакральной идеей, что в выражении (x+1)*(y+1) компилятор должен указать порядок вычислений, сейчас это не актуально.

Во втором случае, с числомолотилками, хорошо справляется SSE/AVX.

Я не понимаю, почему вы хотите принципиально разные задачи обрабатывать единообразно. Понятно же, что специализированное решение будет быстрее, чем пытаться натянуть один VLIW на все случаи.

На столько умеют, что пришлось придумывать AVX512.

Они умеют извлекать очень мало параллельности. К тому же, зачем ее извлекать, когда ее можно явно закодировать?

Потому что в огромном количестве случаев её нельзя "закодировать", т.к. не хватает информации для статического анализа.

На столько умеют, что пришлось придумывать AVX512.

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

>Там проблема в том, что он не всегда может эффективно использовать её. Поэтому, чем городить огород в микроархитектуре и тратить на это много транзисторов и энергии, проще сделать новые архитектурные расширения.

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

>параллельность, которую эксплуатирует AVX512, процессор вообще говоря видит

что-то я сомневаюсь, что процессор видит на 16 инструкций вперед, да еще и налету. А если предсказатель ошибётся, сколько тогда будет стоить эта ошибка? За 1 такт же он не сможет 16 инструкций заново проанализировать.

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

Я написал совершенно другое - то, что используется более эффективный подход. Просто нет смысла городить огород ради специфических задач, где AVX512 даёт реальный привар. На большинстве кода от него толку ноль

что-то я сомневаюсь, что процессор видит на 16 инструкций вперед

Правильно сомневаетесь, он видит вперёд примерно на 100 инструкций.

А если предсказатель ошибётся, сколько тогда будет стоить эта ошибка?

Цена ошибки предсказателя сильно зависит от микроархитектуры, но можете считать что она ~20 тактов. Но там, где используется AVX512, считайте что ошибок предсказателя не бывает.

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

Я прикинул для Арм64 на Cortex-A77 по данным отсюда, для кода, скомпилированного в моей голове с -О0:


                   # pipeline | latency / throughput 
                   #           (такты / количество подходящих пайплайнов)
// while (a < 10000) {
0:  CMP X1, #10000 // I | 1 / 3
    BGE 1f         // B | 1 / 2
// a += get_inc_val()
    BL get_inc_val // B | 1 / 2
    ADD X1, X1, X0 // I | 1 / 4
    B 0b           // B | 1 / 2
// }
1:  ...

Первые 2 инструкции не паралеллятся, так как BGE ждёт результатов CMP. А вот BGE и BL похоже сработают одновременно на пайплайнах B0 и B1 (при необходимости результат второй будет отброшен), ADD будет их ждать, и выполнится одновременно с последней B, а CMP следующей итерации, соответственно, ждет ADD. Итого получается 3 такта на собственно итерацию цикла, плюс сколько-то внутри функции.


Но кажется можно сэкономить еще такт, введя дополнительный счетчик, чтобы CMP не ждал результата в X1 (думаю что компилятор так и сделает, но проверять лень):


    ...
    MOV X2, #10000
0:  BLE 1f          // B | 1 / 2
    BL get_inc_val  // B | 1 / 2
    ADD X1, X1, X0  // I | 1 / 4
    SUBS X2, X2, X0 // I | 1 / 3
    B 0b            // B | 1 / 2
1:  ...

То что вне цикла неинтересно, BLE и BL заходят в B0 и B1 параллельно, ADD и SUBS тоже параллелятся и заходят в 2 разных пайплайна I, B выполняется одновременно с ними, итого всего 2 такта.

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

  1. Архитектура VLIW "плоха": менее производительна чем RISC/CISC и не энергоэффективна.

  2. Оригинальные процессорные архитектуры разрабатывать вовсе не следует.

Выше уже справедливо заметили, что в области специализированных процессоров первое положение полностью безосновательно. Но специализация может быть достаточно широкой. Возьмем, к примеру, VLIW-процессор 2018 года от Kalray для задач Embedded HPC, Networking, Storage. Что он собой представляет: 16 nm, 85 64-bit VLIW-ядер, энергопотребление 5-15W. Тактовая частота (1.2 Ghz) этого процессора даже ниже, чем у современных "эльбрусов", но, очевидно, это еще ни о чем не говорит, правильно?

Почитайте того же Д. Паттерсона -- он считает VLIW-архитектуры вполне перспективными и для будущих domain specific architectures. Даже в популярной архитектуре RISC-V нашлось место стандартному VLIW-расширению.

И я уже не говорю о том, что сама классификация RISC/CISC уже сильно устарела. Есть хорошая фраза в одной недавней статье: "CPUs are gradually becoming sets of discrete accelerators around a shared register file".

По поводу целесообразности создания собственных архитектур. Работа в проекте по созданию процессора с оригинальной архитектурой -- это ценнейший практический опыт для представителей целого ряда редких профессий (RTL-дизайнеры, топологи, компиляторщики, ...). Это важно и для развития академических исследований. В мире количество экзотических процессорных архитектур только растет. Из свежего могу, к примеру, вспомнить Ascenium Aptos и Tenstorrent Tensix. В целом, отмена закона Деннарда, замедление выполнения закона Мура -- побуждают искать новые решения в области процессорных архитектур. Современные технологии компиляции и средства разработки компиляторов (те же LLVM/MLIR) сильно снижают остроту проблемы "процессор-то мы спроектируем, а где оптимизирующий компилятор взять".

Уверен, что заметка получилась бы лучше, если бы автор сконцентрировался исключительно на критической оценке "эльбрусов" в конкретной области их применения.

Вообще-то в заголовке чётко написано про "general purpose CPU". То, что VLIW может быть неплох в каких-то специализированных применениях - спору нет, никто про это не говорил, вы невнимательно статью прочитали.

Что касается "ценнейшего" опыта. Ценнейший практический опыт - это когда вы создаёте продукт, конкурирующий с последними Интелами. А для этого надо уметь проектировать сложную микроархитектуру процессора. А в случае Эльбруса как раз этот момент не развивается - парадигма другая. А создать собственную архитектуру я могу на коленке за вечер под пиво. В этом нет никакой особой научной ценности на самом деле.

Имело бы смысл упомянуть о современных применениях VLIW, чтобы не было вопросов к уровню компетентности автора. Вы же в тексте просто "поставили крест" на архитектуре. Это относится и к весьма наивному разделению на CISC (x86) и RISC (ARM). Я, конечно, могу предполагать, что Вы в таком ключе пишете, рассчитывая на аудиторию, не вникающую в подобные тонкости, но, все же.

А вот реакция на мои слова о "ценнейшем опыте", как мне показалось, получилось чрезмерной. Уже достаточно давно процессоры не принято разрабатывать "на коленке за вечер под пиво". Мне кажется, Вы здесь поторопились с ответом и, на самом деле, вполне в курсе понятий design space exploration, compiler-in-the-loop, hardware/software codesign. Процессор со статическим параллелизмом -- как раз очень интересный объект научного исследования на компиляторную тематику. По мотивам "эльбрусов" мне вспоминается несколько вполне приличных научных статьей, диссертаций и даже стартапов международного уровня.

Ещё можно добавить доведение продукта до конечного потребителя. То, что может использовать «баба Маша», и то, что находится в лабораториях — это совершенно разные вещи. Это тоже очень ценный опыт.
Имело бы смысл упомянуть о современных применениях VLIW

Например какие?
Остались только DSP-хи TMS или Hexagon.
Из CPU общего назначения и GPU VLIW давно выкинули.

Мне нравится VLIW сам по себе. Руками на асме набивать слоты — это классно.
Но я реалист и понимаю что это нежизнеспособная технология за пределами DSP.

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

«Весёлый рисёрч». Пусть таким и остаётся.

>Ценнейший практический опыт - это когда вы создаёте продукт, конкурирующий с последними Интелами.

Приравнивание последних интелов с эльбрусами с его бюджетом равным бюджету на дизайн наклеек этих самых современных чипов выглядит как скрытая реклама Эльбрусов)

Что касается «ценнейшего» опыта. Ценнейший практический опыт — это когда вы создаёте продукт, конкурирующий с последними Интелами.


Это опыт мирового уровня. Вроде как больше нет нигде VLIW в железе в качестве «general purpose CPU». Это громадный спектр проблем, которые доходят даже до уровня «техподдержка в Astra Linux».

Этот опыт открывает возможность создания и развёртывания каких-то других совершенно не RISC/CISC архитектур — мы же надеемся, что текущее состояние процессоростроения — это не конец развития.

Наша страна редко где находится на переднем крае. И будет очень жалко лишиться такого опыта со всех точек зрения.

С таким подходом мы никогда не будем делать процессоры мирового уровня. Вообще, умение признавать ошибки - это залог успешного развития.

Он уже мирового уровня. Никто больше не делает универсальные VLIW процессоры.

Да, сейчас эта ветка выглядит менее перспективно, чем ведущие RISC/CISC. Но отставание-то, положа руку на сердце, невелико (на уровне софта даже 4 раза в скорости процессора почти не чувствуется — почти всегда можно что-то оптимизировать на порядок).

А самое главное — нельзя класть все яйца в одну корзину. И тут РФ вносит свой, пусть и не очень большой, но настоящий вклад в мировое процессоростроение, поддерживая маргинальную ветвь, которая в перспективе может выстрелить.
Никто больше не делает универсальные VLIW процессоры.
Паровозы тоже больше никто не делает. Потому что появились превосходящие их решения.

А самое главное — нельзя класть все яйца в одну корзину.
Вот чего, а корзин с микропроцессорами в РФ с десяток. Есть микроархитектурные разработки MIPS, SPARC, power, RISC-V, кварк, кролик… да даже 32-битная версия mcs-96 есть. Плюс пачка спецвычислителей — ELcore, neuromatrix, комдив-128, мультиклет, IVA.
На фоне этого разнообразия Эльбрус выделяется исключительно агрессивным маркетингом, а не какими-то выдающимися ноу-хау.
Эльбрус — это, всё-таки, уникальная экосистема, доведённая до потребителя (я участвую в проекте ALT, который работает на e2k). То есть, это не просто набор инструкций и какое-то количество камней, это ещё компетенции по созданию универсального АПК (аппаратно-программного комплекса).

Эти компетенции не ограничиваются МЦСТ, есть ещё масса других контор, других людей.

Все остальные микроархитектуры не имеют вот этой сквозной экосистемы внутри РФ. Они требуют внешних специалистов.

Кстати, RISC-V вроде как ещё не имеет серийного десктопа, ждём с нетерпением. А MIPS/SPARC уже давно не имеют серийного десктопа (поэтому у меня дома стоит SunBlade пятнадцатилетнего возраста).
Все остальные микроархитектуры не имеют вот этой сквозной экосистемы внутри РФ.
КОМДИВ имеет.
MIPS умер.

Если MIPS умер, тогда Эльбрус вообще не родился.

MIPS умер.
MIPS — возможно, а КОМДИВ — нет.
И вокруг него прямо сейчас имеется достаточно «компетенций по созданию универсального АПК (аппаратно-программного комплекса).»
В частности, ПК на КОМДИВе я видел своимии глазами еще лет пять назад.
Насколько это перспективная история — другой вопрос. Но ваша фраза «Все остальные микроархитектуры не имеют вот этой сквозной экосистемы внутри РФ. Они требуют внешних специалистов» по состоянию на сегодня не является правдой.

Цимес в том что весь перечисленный зоопарк не обладает стеком унникального софта как intel и arm, они все вместе с эльбрусом могут рпассчитывать максимум на открытое ПО под линукс и ПО от отечественных разработчиков, никакой риск-5 который по скорости будет максимум как эльбрус, не поможет, никто на него не перенесет ни кады ни сапры его самого будут проектировать на интеле а путину чемезов представит очередной планшет, только уже с третьегномом если его к тому времени портируют с полноценной графикой. Это максимум что будет через 5лет, очередной никому не нужный процессор без софта.

Надо все силы киидать в софт, переносить всё необходимое спо под эльбрус, допиливать трансляцию x86, чтоб где это безальтернативно, он мог интел заменить.

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

Элвису пусть делает ускорители потокового видео и прочего, модуль тензорные ядра и всех объеденить в группу чтоб использовали наработки друг друга и свободно лицензировались.

риск-5 который по скорости будет максимум как эльбрус
Расскажите об этом Apple M1 и AWS Graviton.

и всех объеденить в группу чтоб использовали наработки друг друга и свободно лицензировались
АХАХАХАХАХАХАХАХ

СЧАСТЬЯ ВСЕМ, ДАРОМ И ЧТОБЫ НИКТО НЕ УШЕЛ ОБИЖЕННЫМ
Такого примерно у вас уровня рассуждения. Жаль только к реальности они имеют примерно ноль отношения.

Ты в барнауле живешь, ау. Причем здесь эпл или гравитон?

Риск-5 это система команд, простая, последовательная, сама она дает только бинарную совместимость (с кое как портированным на нее спо, лол) все что нужно для ее эффективного исполнения необходимо разрабатывать с нуля. Хотя бы на уровне кортексов не самых новых, а уж что бы их переплюнуть и подобраться ближе к интел/амд надо перейти на кастомный физ. дизайн. Уверен в 2ггц 12нм восьмиядернике все будет и физдизайн и кокаин и шлюхи. И все на частные деньги - 18млрд даст частная компания ростех а 5млрд ядро возьмет кредитом во внешэкономбанке у шувалова, и на госзакупках в школы и куда то там еще отобъют, все честно рыночно, интел напрягся.

все что нужно для ее эффективного исполнения необходимо разрабатывать с нуля
Далеко не с нуля.

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

О, кастомный дизайн - лженаучный миф капитализма https://www.electronicdesign.com/technologies/analog/article/21807187/11-myths-about-custom-silicon

А под светлым знаменем risc-v пролетарии всех стран объединятся и пойдут в светлое будущее. Уже тысячи компаний обратили на него свой пристальный взор и нет никаких сомнений, товарищи, что это будущее вот вот наступит. Нет, мы уже в нем живем, прямо сейчас. Предлагаю единогласно проголосовать "ЗА". Похлопаем.

Дада, я именно об этом — вы настолько не понимаете, о чем речь, что прислали мне ссылку на рассказ «чем заказная ASIC лучше FPGA», а не на что-то имеющее отношение к кастомному физдизайну. Собственно, по ссылке вообще никакой физдизайн не упоминается ни разу.
В следующий раз, пожалуйста, больше внимания уделяйте фактам, а не своему феерическому сарказму. А то может случиться, что в Барнауле это вы живёте, а не собеседник.

Это что, шутка? Кто вообще на серьезных щах будет доказывать что кремний лучше чем фпга.

Полагал ты скажешь что нибудь типа реклама компаний которые на кастомных блоках бабки дела делают но отрицания вообще не ожидал. https://www.asicnorth.com/offerings/

ASIC North will work with your design team to create and verify a custom Intellectual Property (IP) block design. We have years of experience developing IP blocks such as biomedical sensor interfaces, voltage references, multiple A/D and D/A converters architectures, RFID circuits, IoT components and more.

We will also generate a complete set of IP deliverables (*.v, *.lib, *.lef, etc) which allow you to easily integrate the IP into your ASIC design.

И чтоб совсем уж поставить точку в вопросе:

https://www.eng.uwo.ca/people/wwang/ece616a/616_extra/notes_web/1_dintro.pdf

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

Полагал ты скажешь что нибудь типа реклама компаний которые на кастомных блоках бабки дела делают
Я сам работаю в такой компании, если что.

Только вот кастомные блоки не имеют отношения к кастомному физдизайну цифровой части чипа. Он всегда делается автоматизированно. А то, о чем вы говорите — это типичнейшая разработка IP-блоков под конкретного заказчика. Принципиально такие блоки ничем не отличаются по качеству от IP-блоков более широкого применения, если только у заказчика нет каких-то очень специфических нужд. И в случае с цифровыми чипами блоки (кроме памятей и mixed-signal) поставляются в виде RTL-кода, а физдизайн делает сам заказчик.

А вы все ещё не понимаете сути собственной фразы про кастомный, напоминаю, ФИЗдизайн. Поэтому и мешаете с ним в кучу совершенно не связанные вещи.

Я обычный человек и говорю так как понятно мне и таким же как я. Под физ.дизайном я в данном контексте подразумеваю дизайн транзисторных блоков/элементов а не какой то логики. То что это в какой то там среде проектировщиков считается оскарблением меня не касается, завтра придет дядя вася с паяльником и скажет что ФИЗ это когда ты вот руками берешь травишь, паяешь, дорожки чертишь и у них в мастерской за такие ошибки вообще убивают сразу же.

Ещё в первой статье выше (которая якобы про фпга), содержит раздел про Analog-Digital Mixed дезигн - оно? Как бы там нибыло я подразумеваю разработку специальных блоков под разные устройства, не может это не давать прирост.

Вон мцст сделали кастом дизайн кешей у них поместилось 1мб L2 на ядро вместо прежних 512к. Сразу же вспоминаются интел и амд середины нулевых, у амд и полноценный четырехядерник и мму в кристалле но кэш 300кб на ведро и слив интелу с кэшами полтора три мегабайта.

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

Под физ.дизайном я в данном контексте подразумеваю дизайн транзисторных блоков/элементов а не какой то логики.
А логика по-вашему не из транзисторов делается?

Ещё в первой статье выше (которая якобы про фпга), содержит раздел про Analog-Digital Mixed дезигн — оно?
Нет, не оно. Фраза про «надо перейти на кастомный физдизайн, чтобы догнать Интел» говорит о ручном рисовании топологии именно цифровых блоков — в противовес автоматизированной разводке, которая применяется на самом деле. А дизайн аналоговых и mixed-signal блоков в любом случае ручной и в любом случае не влияет на производительность цифровой логики. Вот и получается ровно то, о чем я сказал — вы услышали где-то мантру про то, что нужен кастомный физдизайн, а что она означает, толком не понимаете. И тот, от кого вы ее услышали — тоже не очень понимал.

Вон мцст сделали кастом дизайн кешей у них поместилось 1мб L2 на ядро вместо прежних 512к.
Это хорошо и правильно, но не имеет отношения к «кастомному физдизайну». Все, сто разумно делать руками и делать самостоятельно — в Эльбусах уже делается именно так, и никаких огромных резервов для повышения производительности в этой части нет уже давно.

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

Я, в отличие от вас, профессионал не в хамстве, а в разработке микросхем. И поэтому довольно хорошо себе представляю, кто, как и на чем проектирует Эльбрусы — и знакомых в отрасли порядочно, и публикуется в профильных изданиях МЦСТ очень много.

Мне кажется Вы не очень понимаете что такое risc-v и сколько людей и компаний его развивают. Одно из преимуществ тут в том, что на него сейчас активно смотрят множество компаний во всем мире и активно портируют под него софт (преимущества открытой ISA и относительно доступных dev-плат, которые и дешевле Эльбруса и в отличии от него можно купить в интернете). Просто для справки - сейчас на risc-v работает примерно 95% пакетной базы debian unstable. Просто из коробки, только добавь свое ядро (если плата в mainline не поддерживается):

civil@debian:~$ apt-cache show gnome-shell | head -n 3
Package: gnome-shell
Architecture: riscv64
Version: 40.2-1

А насколько оно хорошо работает - зависит графики. К сожалению на девайсе что у меня нет 3D ускорителя, а только с 2D графикой и llvmpipe'ом далеко не уедешь в плане десктопа.

никакой риск-5 который по скорости будет максимум как эльбрус

Более чем спорное утверждение, с учетом того что Байкал-М1 уже в целом догнал или даже перегнал Эльбрус, по производительности на МГц у даже некоторые российские компании (см. cloudbear BI-674) показывают лучше результаты (понятно что надо ждать реальных изделий, но нет причин полагать что они окажутся сильно хуже, чем заявленное). Так что если даже просто лицензировать их ядро - будет уже строго лучше. И я молчу о ядрах от SiFive, которые бывают еще быстрее.

Надо все силы киидать в софт, переносить всё необходимое спо под эльбрус

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

И да, я писал выше в том числе про детские болезни risc-v, и я по-прежнему уверен что ARM в текущий момент лучше как краткосрочный путь развития. Но тем не менее risc-v куда более перспективная штука, нежели Эльбрус.

для моторолы68k в дебиане наверное пакетов еще больше и что? либреофис запущеный на "правильном процессоре" майкрософт офисом не станет.  Эльбрус лучше потому что мцст контролирует систему команд, патенты с ней связанные, систему прерываний, всю платформу. Имеет ядерщиков, библиотечников и компиляторщиков. Охват базового стека софта и полный контроль железа приблежает на одну ступеньку к таким компаниям как интел и нвидиа, про которых кто бы что не говорил но их железо ставят в серьезные системы, а в амд только школьники гоняют в киберпанк и майнят. Тот же майор может позвонить в мцст и сказать: "на ведомственном сайте ок а на котиках вконтакте проседает производительность в браузере сделайте что нибудь" и мцст выделит специалиста заниматься этим делом либо знает кому передать на аутсорс, а что скажет байкал или синтакор? "пишите в мазилу в багзиллу или nekonekonyan -у в гит ижуи, мы  к софту который на нашем железе работает не имеем отношения"? Сопровождение нужного тебе софта и помощь от сообщества ты не получишь нахаляву, все равно требуется чью то еще отдельно покупать.  Свободное от патентов ISA - это не спо и не свободное железо даже, его нельзя взять себе как нельзя взять себе питон или с++, это стандарт только языка железа. я не слышал аргументов в духе "зачем делать раст если есть го", или "зачем делать свифт если есть котлин". или вот зачем эплу понадобился Obj-c вместо плюсов? Да потому что у них было иное виденье ООП и оно лучше реализовывало те задачи, которые эпл реализовали в своей ос и ее api.  Примут ли в риск-5 расширения касающиеся ускорения российских криптоалгоритмов, или там тензорных для росатома или двигателистов? Никогда, а вот aes или sha1024 я уверен вполне. Про безопасные режимы даже говорить бессмысленно, нужна ли нам не удобная под наши задачи, а некая "стандартизированная" какими то джонами система команд? Я не вижу в этом плюсов, одни минусы.  Отпортировать весь стек СПО и протолкнуть арч в апстримы это дело наживное, хоть и не простое в случае с эльбрусами тупо в силу того что это в первую очередь теговая и стековая архитектура, что создает проблемы в адаптации низкоуровневых приложений, ну и влив мешает портированию компиляторов. Но зато все знают что е2k это е2k, семейство процессоров с конкретной архитектурой а не подмножество с вольным набором расширений. 

НЛО прилетело и опубликовало эту надпись здесь
Тот же майор может позвонить в мцст и сказать: «на ведомственном сайте ок а на котиках вконтакте проседает производительность в браузере сделайте что нибудь»
Как у нас решаются проблемы, я скорее поверю в то, что пользователь, который запостил злополучного тормозящего браузер котика, поедет в Магадан валить лес. Ну а что, диверсия против православной архитектуры, не иначе.

для моторолы68k в дебиане наверное пакетов еще больше и что?

Во первых не важно сколько для моторолы68k, важно что больше чем на Эльбрус в данном случаи. Притом всего за пару лет.

Ну к тому же не больше, больше только на ppc и мажорных архитектурах. Под m68k собрано где-то 85% пакетной базы деба.

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

Первая часть как раз еще один минус Эльбруса. Не такой важный как качество архитектуры конечно, но следующий за этим. А почему? Да потому что монополия на архитектуру ведет к текущей ситуации, когда все закрыто донельзя и никто не спешит открываться.

А ядерщики-библиотечники-компиляторщики могли бы с тем же успехом пилить под RISC-V или ARM, был бы тот же эффект.

Охват базового стека софта и полный контроль железа приблежает на одну ступеньку к таким компаниям как интел и нвидиа

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

а в амд только школьники гоняют в киберпанк и майнят. 

Вопрос на засыпку: сколько из мажорных игроков (топ10 например) на рынке облачных вычислений не предоставляют решений на AMD?

Тот же майор может позвонить в мцст и сказать: "на ведомственном сайте ок а на котиках вконтакте проседает производительность в браузере сделайте что нибудь" и мцст выделит специалиста заниматься этим делом либо знает кому передать на аутсорс

Не вижу почему была бы такая уверенность. МЦСТ выделит специального человека, который объяснит товарищу майору в очередной раз, что это все авторы ВК или браузера, а не они виноваты, так как принципиально вопрос они решить не смогут.

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

Так ровно потому что разработка и сопровождение это тяжкий труд и стоит фокусироваться на том, что действительно работает как положено. Представь себе, какая помощь была бы всем, если бы компиляторщики МЦСТ вкладывались бы в развитие того же risc-v? Ну или в софт, который правда нужен заказчику. Сейчас этот ресурс тратится впустую.

Примут ли в риск-5 расширения касающиеся ускорения российских криптоалгоритмов, или там тензорных для росатома или двигателистов? Никогда, а вот aes или sha1024 я уверен вполне.

В данном случаи за такой уверенностью должна быть какая-то фактическая база. Собственно почему Вы так уверены, что не примут? Это впрочем касается всего Вашего поста.

Отставание огромно и они в рамках данной VLIW архитектуру непреодолимо. Это то, что я показываю в статье. А то, что делаете вы - это кормите обещалками людей, заведомо вводя их в заблуждение.

Да начхать на эти 10 раз максимум. Впрочем там нет 10 раз, там есть ну 2-4.

Если вам начхать, то это не значит, что другим тоже

"Даже в популярной архитектуре RISC-V нашлось место стандартному VLIW-расширению. "

не могли бы Вы дать ссылку на содержание этого расширения?

С удовольствием! Информация есть в документе The RISC-V Instruction Set Manual (https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf). См. раздел Supporting VLIW encodings. Он начинается со следующего абзаца:

"Although RISC-V was not designed as a base for a pure VLIW machine, VLIW encodings can be added as extensions using several alternative approaches. In all cases, the base 32-bit encoding has to be supported to allow use of any standard software tools".

Мне известно о существовании нескольких академических RISC-V VLIW-процессоров, но, в целом, разумеется, типичный современный VLIW-ускоритель удобнее добавлять к RISC-V-ядру отдельно.

Как Вы и сами видите , в архитектуре RISC-V нет ничего про VLIW кроме пары общих фраз. Так можно добавить какие угодно расширения.

Жаль разочаровывать, если Вы ожидали увидеть там скрытый намек на "Эльбрус" или Itanium.

Авторы RISC-V не верят в перспективы VLIW в области GPP, об этом они неоднократно заявляли. Как и большинство специалистов сегодня, Хеннесси с Паттерсоном разделяют мнение, что VLIW-архитектуры замечательно себя показывают в области предметно-ориентированных ускорителей и в этом отношении RISC/CISC им, в целом, не конкуренты.

Перед авторами RISC-V стояла непростая задача обеспечения точек роста новой архитектуры. Поэтому в RISC-V стандартизированы возможности расширения команд, добавления специализированных ускорителей. Естественно, речь не идет о "каких угодно расширениях" (это самое "что угодно" добавляется в отдельные ускорители) и, в частности, вы не найдете в документе ничего о TTA, Dataflow или каких-нибудь CGRA.

По какой причине возник небольшой, укладывающийся в одну страницу, раздел VLIW-расширения? Думаю, авторы предполагали возможность реализации простых компактных вариантов в духе 2-issue in-order.

Вы меня не разочаровали. Я просто хотел чтобы Вы сами уточнили , что у RISC-V ничего про VLIW нет :) Просто из вашего прежнего комментария можно было сделать вывод, что у RISC-V есть какое-то VLIW расширение подобно V,P,B и т.д.

Автор смешал тёплое с мягким. Он объявил бесперспективной конкретную разработку, а в реальности оспаривает лишь технологию, задействованную в данной разработке.

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

Далее рассмотрим конкретнее некорректность претензий автора именно к технологии VLIW.

Проблема в том, что своя архитектура означает портирование всего стэка софта, необходимого пользователям

Разумеется, это не так. Портированию подлежит лишь то, что скомпилировано под конкретную архитектуру. Но мир развивается, и равитие несёт нам свободу от монополий. Есть всем известные примеры языков, компилируемых в байт-код или же в оптимальный машинный код, но на этапе исполнения. Если автор обратит внимание на эти всем известные подходы, то "проблема" с портированием моментально испарится. Останется только осилить базовые библиотеки на компилируеммом в байт-код языке, что бы не плакать о "невозможности портировать" что-то чужое.

Да, к сожалению мы не можем делать аналог x86.

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

VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам

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

Пришедший указатель или сложная работа с памятью - и вы не можете спланировать Load выше операции Store (и наоборот)

Здесь всё зависит от объёма памяти и количества вычислений на этапе компиляции. У процессора, который в железе реализует то же самое, и памяти и вычислений на порядки меньше. Но автор настаивает на своём, забывая об очевидных возражениях.

Но при компиляции без профиля установить какие циклы горячие невозможно.

Опять же здесь стоит напомнить о технологиии, которая существует уже лет 25. Называется она "just in time" компиляция. И профиль там, безусловно, есть. А вот значимость, придаваемая автором данной проблеме, явно завышена. В целом статья демонстрирует именно произвольно надёрганный набор из ряда типичных возражений сторонников традиционного подхода, но ни в коем случае не демонстрирует системность подхода и уж тем более, какие-то расчётные или статистические выкладки.

В то же время классические RISC/CISC архитектуры с OoO автоматически оптимизируют и конвейеризируют любой исполняемый код.

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

Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать ~1 такт, не отличаясь принципиально от случая, если инлайн сработал.

Если что-то не заинлайнено компилятором, то это что-то, по мнению автора, автоматически заинлайнится процессором. А теперь вспомним про различие в количестве доступной памяти и вычислительных циклов между полноценным компилятороми и ограниченным в этом всём процессором. Вопрос - кто сможет оптимизировать лучше?

В то же время на Эльбрусе одна итерация данного цикла будет занимать порядка 17 тактов.

Ну это же классическая манипуляция с указанием на худший вариант против лучшего. Автор берёт VLIW и предполагает, что он совсем тупой и ничего не умеет. Потом он берёт обычный процессор и предполагает, что он умеет абсолютно всё. А затем автор сравнивает два таких варианта. И, о чудо, внезапно побеждает именно идея автора о превосходсьтве "белой расы".

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

Как может быть недоступно то, что доступно процессору с его крошечными мозгами, полноценному компилятору с его доступом к гигабайтам памяти и десятку ядер при компиляции?

Ему доступно еще одно измерение — время. Компилятор при всех своих гигабайтах и десятках ядер не может ни при каких условиях узнать во многих случаях, куда пойдет ветвление, куда пойдет джамп, где будет зависимость между инструкциями, а где не будет. Это динамические характеристики, которые проявляются только в процессе выполнения кода. Поэтому мы видим, что все процы общего назначения имеют предсказатели, OoO, кучу другой «магии» и эти блоки постоянно оптимизируются и улучшаются, давая серьезный прирост в IPC, а VLIW может справляться только с примитивным векторным кодом. Итаниум был просто самый громкий пример, но тупиковость этого подхода всем давно известна и понятна, поэтому никто больше не пытается ткать VLIW куда попало. Всему свое место и для VLIW это место совсем не центральный процессор ПК.

Ирония в том, что именно ваш пост набит необоснованными заявлениями. Статья автора это просто ликбез на тему архитектур с перечислением общеизвестных фактов. Какие еще расчеты и статистика? Можете конечно не верить, но сами тогда и ищите расчеты, раз вам очевидные вещи кажутся неправдой.

Спасибо за ответ. Я просто даже не знал, как прокомментировать такой поток мыслей. Это надо брать человека, сажать рядом за стол с ручкой и листочком и начинать с объяснения азов.

Компилятор при всех своих гигабайтах и десятках ядер не может ни при каких условиях узнать во многих случаях, куда пойдет ветвление,

Так и процессор не может узнать, пока не вычислит значение, от которого зависит ветвление. И вынужден угадывать ветвление по предыдущему опыту.


где будет зависимость между инструкциями

Это как раз известно еще на этапе компиляции.

Так и процессор не может узнать, пока не вычислит значение, от которого зависит ветвление. И вынужден угадывать ветвление по предыдущему опыту.

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

Это как раз известно еще на этапе компиляции.

А если адрес динамически вычисляется? Компилятор в любом случае должен быть более консервативен в своих оптимизациях и догадках о коде. Даже на уровень языка (C/C++ и их тонна UB) приходится вон костыли выносить, чтобы развязать ему руки хоть немного.
Так и процессор не может узнать, пока не вычислит значение, от которого зависит ветвление. И вынужден угадывать ветвление по предыдущему опыту.

Разница в том, что процессор может менять свои предположения о ветвлении на лету, подстраиваясь под данные.

>> Компилятор при всех своих гигабайтах и десятках ядер не может ни при каких условиях узнать во многих случаях, куда пойдет ветвление

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

Что такое предсказание ветвлений? Направления два - исполнение сразу по двум ветвям и сбор статистики. Эти функции в обычных процесорах реализованы в железе. Для VLIW ровно эти же функции ничто не мешает реализовать в виде наполнения пустующих слотов в потоке инструкций. То есть в обоих случаях предсказание будет. А если оба случая эквивалентны по имеющейся информации, но один из случаев всё же более качественно оптимизирован за счёт привлечения полноценного компилятора, то кто же выиграет? И вот таких элементарных вещей вы не понимаете?

Что такое предсказание ветвлений? Направления два - исполнение сразу по двум ветвям и сбор статистики.

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

НЛО прилетело и опубликовало эту надпись здесь

Не простаивают. Для этого суперскаляры делают OoO и SMT. Как раз VLIW будет простаивать. Либо он будет стоять ждать результата условия, либо тупо тратить ресурсы на бесполезные вычисления. И то и другое плохо. По этой причине всегда и везде код с условиями на VLIW всеми силами выпиливается какими угодно костылями. Хороший пример GPU, где условия смерти подобны были. Не знаю как сейчас с тех пор, как от VLIW даже они отказались.

Помочь может нормальная isa и нормальный код. В нормальном коде при наличии нормальной isa 95% ветвлений выпиливаются.

Ну в теории много чего возможно, а практика показывает, что ни кода такого, ни ISA такой нет. Вам выше уже все объяснили. Суперскалярные процессоры придумали для выполнения реального кода, а не теоретизирования как все было бы хорошо будь у нас идеально оптимизированный под архитектуру код.

Даже на х86 один cmov позволяет выпилить чуть ли не половину ветвлений.

И ухудшить этим производительность. На практике cmov имеет неочевидные последствия. Вот вам авторитетный источник с описанием проблемы https://www.agner.org/optimize/optimizing_assembly.pdf и почему на деле предсказание и спекулятивное выполнение скорее всего будет быстрее.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Нет никакой чуши. Просто вместо ссылки на документ надо приводить из него выдержки, а не безапелляционно утверждать, что cmov — говно:


The advantage of a conditional move is that it avoids branch mispredictions. But it has the disadvantage that it increases the length of a dependency chain, while a predicted branch breaks the dependency chain. If the code in example 9.9c is part of a dependency chain then the cmov instruction adds to the length of the chain. If the same code is implemented with a conditional jump as in example 9.9b and if the branch is predicted correctly, then the result does not have to wait for b and c to be ready. It only has to wait for either d or e, whichever is chosen. This means that the dependency chain is broken by the predicted branch, while the implementation with a conditional move has to wait for both b, c, d and e to be available. If d and e are complicated expressions, then both have to be calculated when the conditional move is used, while only one of them has to be calculated if a conditional jump is used.


As a rule of thumb, we can say that a conditional jump is faster than a conditional move if the code is part of a dependency chain and the prediction rate is better than 75%. A conditional jump is also preferred if we can avoid a lengthy calculation of d or e when the other operand is chosen.

НЛО прилетело и опубликовало эту надпись здесь
Здесь всё зависит от объёма памяти и количества вычислений на этапе компиляции. У процессора, который в железе реализует то же самое, и памяти и вычислений на порядки меньше

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

НЛО прилетело и опубликовало эту надпись здесь
Для начала — неявная неоднородная память это рак

ну… может быть. но мы уже привыкли к гигабайтам (десяткам, сотням) ram. и многоуровневые кэши.


предлагаете руками управлять загрузкой данных в кэш?


и да, память — это половина проблемы. вторая половина — когерентность кэшей между ядрами, атомарные операции с мьютексами. тут куда бежать?


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

насколько я представляю, являются. и код «рыхлый» получается, и предсказание ветвлений пока только в планах…


Но у суперскаляра есть smt и решает эту проблему. smt это источник полностью независимых друг от друга цепочек

и это да, кто же спорит.


Оно есть даже на мусорном суперскаляре типа х86.

ну я бы не стал называть x86 мусорным. у кого-то производительность на такт заметно лучше?

НЛО прилетело и опубликовало эту надпись здесь

Есть золотое правило: критикуете — предлагайте альтернативу. Что предлагаете вместо кэшей? Чем так плох x86, если под капотом все равно работает микрокод? Ну кроме убогого кодирования системы команд.

НЛО прилетело и опубликовало эту надпись здесь
Я предложил — многоуровневую память. Практически так с кешами и работают, если мы говорим о какой-то производительности. Зачем за давать вопросы на которые я уже давал ответ?

Нет, вы не давали ответов. Пока что ваши комментарии выглядят как лозунг: давайте не будем делать плохо, а сделаем хорошо. Где детали реализации?


Как я понимаю, вы хотите память вместо кэша. Фактически, это явная адресация быстрой кэш-памяти. Вместо того, чтобы просто решать какую-то задачу, программисту придётся тратить адовое количество ресурсов на реализацию механизмов памяти из медленной памяти в быструю и обратно. Значит, будет больше говнокода, и работать он будет медленнее, чем на неэффективных (по вашему мнению) архитектурах.


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


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

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

НЛО прилетело и опубликовало эту надпись здесь

Отлично, мы пришли к явной однородной адресации памяти. Для одноядерного процессора — норм. Но что предлагаете делать для многоядерных процессоров, разделяющих общую память? Согласовать доступ к памяти между ядрами вы никак не сможете, и поэтому время доступа к памяти будет недетерминированным. А это уже задержки при явном параллелизме.


А что делать с виртуальной памятью? При таком подходе мы не сможем позволить процессору запинаться на page fault при обращении к памяти.


Какой код, чего делать? Что это значит? Откуда он(код) взялся? На что это ответ? Как он связан с цитатой?

Я к тому, что невозможно на практике сбалансированно загружать все вычислительные устройства.

НЛО прилетело и опубликовало эту надпись здесь
Какой-нибудь атомарный доступ к общей памяти детерминирован.

А, собственно, почему? Память у нас медленная, работает по принципу "вас много, а я одна", даже одно ядро может полностью утилизовать её пропускную способность. Если 16 ядер одновременно захотят прочитать данные из памяти, то их хотелки будут обрабатываться по очереди. Немного улучшит эту ситуацию использование многоканального доступа и интерливинга.


И это я ещё не затронул тему примитивов синхонизации, lock-free контейнеров.

НЛО прилетело и опубликовало эту надпись здесь

Браво!

Но при компиляции без профиля установить какие циклы горячие невозможно.
Опять же здесь стоит напомнить о технологиии, которая существует уже лет 25. Называется она «just in time» компиляция. И профиль там, безусловно, есть
Как вы себе это представляете? В каждую ф-цию (а вдруг она станет «горячей» в будущем), вокруг каждого ветвления, добавить немного диагностического кода, который будет жрать такты, регистры и memory traffic? (куда-то все эти логи писать надо)
А потом, когда приложение поработало (сколько? 2 секунды или 2 минуты?), перекомпилируем часть функций, удаляя из них тормозную диагностику? А вдруг ситуация изменится, диагностику надо всегда оставлять, и она будет хорошо так тормозить.

Да, примерно так это и работает. Оверхед на профайлинг порядка единиц процентов, если я ничего не путаю.

Профилирование не удаляется никогда. Пошел другой паттерн данных и код оптимизировался под него.

tiered compilation и деоптимизация это все умеет. JVM и вроде .net core их поддерживают.
Ну то есть ф-ция типа
int next(int a) { return a+1; }

у такого JIT не 2 инструции, а сколько?

Она просто заинланится.

JIT компиляторы сложные и навороченные. Такими простыми штуками вы их не обманете.

А если ф-ция виртуальная?

В Джаве все функции виртуальные. И ничего, отлично инлайнятся. Не вижу проблем.

Так они инлайнятся в большинстве случаев из-за того, что они все виртуальные. jit знает, какие не перегружены в наследниках, т.е. виртуальность избыточна. А если ф-ция сделана виртуальной, чтобы вызываться по разным адресам в одном и том же цикле, например
foreach (shape in shapes) n += shape->getVerticesCount();
тут никакой компилятор ничего сделать не сможет.

Если у вас на самом деле разные типы с разными реализациями getVerticesCount внутри shapes , то компилятор ничего не сможет сделать и будет все честно вызывать. Увы, вам не повезло.

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

Если внезапно прилетели разные типы с разными реализациями, а до этого тысячи раз были одинаковые кидаем исключение и откатываемся на неоптимизированный вариант

Мне просто интересно, реально ли jit на такое способен. Внутри одной ф-ции могут быть десятки виртуальных вызовов, если пример реальный, а не модельный.

Да. Определять конкретные реализации и убирать виртуализацию он умеет.

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

Писать горячий код в рассчете на инлайн надо небольшими функциями. Коллекции с разными типами и разными реализациями функций в горячем коде могут сильно навредить производительности. И так по всему стеку вызовов горячего кода.

А еще неплохо бы посмотреть нет ли подходящей функции в jdk с аннотацией IntrinsicCandidate. Вероятно она будет быстрее чем любые твои старания. Там люди постарались и заранее все сильно оптимизировали уровнем ниже.

Если внезапно прилетели разные типы с разными реализациями

Вот подтверждения этого я не смог найти. В моем понимании, она опирается на иерархию классов, и если есть несколько реализаций, то оптимизация не применяется никогда. Действительно ли JVM может спекулятивно делать оптимизации и если вдруг что-то некорректное, то откатываться назад? Это ж получается нужно в оптимизированный вариант проверки вставлять, что мы вызвали заинлайненный метод не того класса.

В оптимизированном коде совершенно точно есть проверки и сбор статистики. JIT же работает на статистике. Ее в любом случае надо собирать постоянно и обновлять код если все пошло не так.

Проверки с медленной веткой срабатывающей раз на миллион вызовов это нормально. Пресказатель ветвлений cpu делает такую проверку почти бесплатной. Или вообще бесплатной.

Лично копаться в оптимизациях для меня перебор. Оно того стоит если ты разработчик JIT, Спринга и подобного, или от большой любви к ассемблеру. Я статьями ограничиваюсь. Или видео каким интересным по теме.

НЛО прилетело и опубликовало эту надпись здесь

Вот как напишут хороший jit для Эльбруса без рассчета на предсказатель ветвлений тогда и приходите со статьей с описанием. С удовольствием почитаю и даже попробую, если не очень дорого будет.

Я немного знаю только про то как он работает на процессорах с предсказанием.

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

У эльбруса проблемы с джитом из за своей процедурной безопасности и стековости. Джит подразумевает что безопасность обеспечивается его рантаймом, а машине безопасной быть не нужно, так как это тоже забирает эффективность/скорость. В принципе у них же есть небезопасный режим для совместимости с интелом, не знаю почему они его не хотят использовать для рантайм языков а заставляют портировать в обычный режим с его защищенными стеками, либо может там дофига делов с тем что бы увязать все это в ядре ОС.

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

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

Мы тут про jit говорим. Ему ориентироваться на предсказатель ветвлений и генерировать код где этот предсказатель покажет всю свою силу милое дело.

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

И опять jit же. Процессору поступает самый обычный нативный код. Байткод обрабатывается компилятором. При чем тут процессор непонятно. Нужно "всего лишь" написать оптимальный jit комплятор под Эльбрус.

Ему ориентироваться на предсказатель ветвлений и генерировать код где этот предсказатель покажет всю свою силу милое дело.

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

Процессору поступает самый обычный нативный код. Байткод обрабатывается компилятором. При чем тут процессор непонятно.

Байткод исполняется в виртуальной машине (виртуальном процессоре) который рабортает поверх настоящего, это такая схема работы. А эльбрусу надо полностью всю программу снизу доверху, а то еще и из дополнительных файлов, и строить оптимальное исполнение

Нужно "всего лишь" написать оптимальный jit комплятор под Эльбрус.

Проблема в том джиты для языков уже написаны, ты можешь только в них добавить поддержку своей архитектуры, но качественно поддержать все возможности эльбруса в них не получится так как изменения сумарно потянут на отдельный джит. Представляешь себе V8 в котором 100мб исходников для всех архитектур и 100мб персоонально для эльбруса. Врядли такое произойдет, надо либо держать форк согласованый с основной веткой либо написать свой отдельный vm/jit не связанный с конкретным языком а во все проекты протолкнуть поддержку его представления.

Это и c++ умеет, для этого jit не обязателен.
С той разницей, что JVM сможет девиртуализацию выкинуть, если условия изменятся. Например будет загружена новая сборка, которая поменяет иерархию классов и оптимизация станет не валидной.
Для C++ это эквивалентно пересборке бинарника с влюченной link-time optimization.

Не эквивалентно. Пересборка вообще за рамками этого обсуждения находится. JVM все делает в рантайме.

При чем тут пересборка? При первой компиляции джит генерирует что-то типа

void Foo(object bar) {  
  if (bar is ConcreteBar) { goto BarFooImpl }   
  goto RecompileFooForDynamicObject
}


при первом вызове виртуальной функции он генерирут только код для единственного реального типа который туда попал. Дальше пока туда попадает объект этого же типа все идёт по шорткат пути на конкретный невиртуальный импл. Как только нам в функцию передали какую-то другую реализацию то все это добро перекомпилируется в честный вызов виртуальной функции.

Можно почитать интереснее, как устроено и какие бенефиты дает. https://shipilev.net/jvm/anatomy-quarks/16-megamorphic-virtual-calls/

Подробностей реализации я не знаю. Думаю найти будет несложно. Сам факт, что такое есть и вовсю используется уже очень давно. Вот например фейсбук про свой кастомный PHP рантайм пишут research.fb.com/wp-content/uploads/2018/04/hhvm-jit-a-profile-guided-region-based-compiler-for-php-and-hack.pdf Тоже PGO в рантайме делается.
Мне интересно, какой конкретно код будет добавлен профайлером.
Чтобы оценить, сколько информации можно так собрать и какой оверхед.
А если код типа
for (int i = 0; i < 256; i++) {
    if (i%4 == 1) printf("%d", i);
}

Процессор поймёт, какой паттерн срабатывания IF и сделает предсказание только на каждую 4-ю итерацию.
А jit-компилятор как будет этот паттерн определять? Писать лог за каждый IF, а другой поток это всё параллельно анализирует?

Это статический компилятор сделает в компаил тайме, тупо тебе принты с нужными патернами в стопочку напишет и все.

В динамических языках как правило работа с массивом переменной длинны и вызовом юзерской функции переданной аргументом и все это jit в рантайме ловит и оптимизирует в том числе используя инлайн.

НЛО прилетело и опубликовало эту надпись здесь

Так же как статический, но у джита обычно ограниченный набор времени и ресурсов (в отличие от аот который может хоть год компилировать если ему нужные флаги подсунуть).

Я пытаюсь сконструировать случай, когда статическое планирование не работает.
Вот, например
for (int i = 0; i < 256; i++) {
    if (a[i] > 0) printf("%d", i);
}
при входном массиве a (полученным из места, к которому компилятор не имеет доступа):
int a[256];
for (int i = 0; i < 256; i++) a[i] = i % 4;

Процессор с динамическим планированием может понять, что каждый 4-й переход срабатывает.

Если мы как люди можем это заметить, значит мы можем заставить машину сделать так же. Весь вопрос в том, какой бюджет транзисторов (в случае ЦПУ) или времени (в случае джита) у нас есть и влезаем вы в него или нет.

В современных жвмах (и вроде clr) бюджет такой, что мы можем в фоне собирать статистику и оптимизировать "достойные" методы подобным образом.

Ну а бюджет ЦПУ на это дело тоже известен и судя по тому что я слышал про интеловские процы последних поколений там просто чудо какие паттерны он умеет замечать. Каким образом, правда, мне не очень понятно. Но, достаточно утонченная технология неотличима от магии, так что приму как данность нашего мира, что это есть.

Каким образом, правда, мне не очень понятно
Нейросети и машинное обучение. Видел публикации, что AMD и Qualcomm это используют.
Весь вопрос в том, какой бюджет транзисторов (в случае ЦПУ) или времени (в случае джита)
С транзисторами понятно. А вот jit как работает… Сбор статистики не бесплатен. И чем больше собираем, тем сильнее тормозит код, который больше всего выполняется. Особенно статистика переходов. Это каждый branch надо обвешивать логированием?

Семплирующий профайлер не очень дорог. На горячем и уже оптимизированном коде можно спокойно собирать статистику раз в тысячи, а то и миллионы, вызовов. И что-то делать только если оно изменилось.

Время реакции на измерение паттерна данных у Джавы не очень быстрое. (Субъективное наблюдение. По хорошему тут мерять надо, но это статья по объему)

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

void ex(int arr[], const int idx[], const int isz)
{
  for (int n = 0; n < isz; n++)
     arr[idx[n]] += n;
}

Поздравляю, мы не можем статически предсказать куда проходит запись может быть все пишут в один элемент массива а может быть в один элемент тут несколько раз запись проходит, и поэтому мы не можем спекулятивно (заранее) загружать значения из arr, а это значит что надо ждать пока загрузится idx[n] и потом только arr[ idx] и причем мы не можем параллельно итерации обрабатывать, так как вдруг следующая пишет туда же.

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

Но даже в этом случае умный компилятор+адекватный программист эффективнее внеочередных костылей. Компилятор видит что ничего не мешает пихнуть указатели на один и тот же массив и картина обработки массива резко меняется, и можно подготовить код на оба случая если программист не запретил рассматривать такие случаи всякими там рестриктами и ассертами. Можно ловить пересечения сравнивая адреса и сопоставляя предикаты, в конце концов программист видя что компилятор слишком замороченый код генерит, разделит циклы, отсортирует сгруппирует а компилятору останется только развернуть итерации.

во вторых твой код как раз заставляет дристать под себя предсказатель переходов
Это почему? Предиктор Intel в моём примере понимает, что выполняется только каждый 4-й переход и перестаёт делать ошибки через некоторое время обучения.
и рекламирует условное исполнение через флаги или через предикаты (без разницы) которые целиком ориентированы на подстановку компилятором
Не понимаю, откуда компилятор узнает содержимое массива a (допустим, оно генерируется внешней программой). И как тут помогут предикаты, предикаты могут выполнить printf по условию?

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

Компилятор в случае с амд атлоном с дедовским предсказателем, может развернуть цикл на несколько итераций вперед чтоб хотя бы помочь суперскаляру загрузки/сравнения запускать параллельно, так как он видит что они ни от чего не зависят. В случае с эльбрусом компилятор вовсе знает сколько длится подготовки переходов и загрузки, пока готовится конвеер с функцией принт, он может сравнить уже заранее подгруженный a[i] > 0, запустить загружаться a[i+1] условно выполнить подготовленный print ? p1 и перейти в следующую итерацию.

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

Собственный процессор - это прежде всего информационная безопасность. На этом фоне всё остальное уходит на второй план.

Угу… Работающий на пиратском варианте линукса (хотя надо посмотреть видео, может они как-то наконец-то решили эту проблему?). Хотя да, если ради информационной безопасности еще и интеллектуальную собственность отменить — много народа скажет спасибо.

p.s. для «пиратскости» ключевой признак — не деньги (как следует из пропаганды копира… правообладателей), а (не)соблюдение лицензионных договоров (в т.ч. ими же самими).

Пиратский линукс? Вы сейчас серьёзно? :)

МЦСТ ловили на том, что они бинари распространяли без доступа к исходному коду (даже по запросу), что было нарушением GPLv2

И? Какие последствия?

НЛО прилетело и опубликовало эту надпись здесь

Вот сейчас очень смешно было...

НЛО прилетело и опубликовало эту надпись здесь
Ну так в гражданско-правовой сфере кто-то должен озаботиться защитой своих прав для начала. Например, потребовать запрета распространения содержащей контрафакт продукции хотя бы.

А для привлечения МЦСТ и/или должностных лиц к административной ответственности скорее всего потребуются ОРМ, т.к. «в открытом доступе» достаточной информации о подробностях сделок, включавших поставку эльбрусОС, недостаточно для однозначного заключения, был там в каждом конкретном случае линукс контрафактным или нет.

Т.к. признаки осуществления приготовлений к нарушению прав есть, но этого достаточно лишь для гражданско-правового процесса, для административной ответственности нужно незаконное использование.
И такое уже тоже было в российской судебной практике: habr.com/ru/post/357544

Тогда уж надо все "информационно безопасные" чипы на производство на 90нм Микрона переводить. Но всё же печатается на Тайванях. И в проектировании отказаться от Синопсисов и Каденсов. И сторонние IP блоки не использовать (а МЦСТ их использует).

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

конкурентноспособные, на мировом уровне а лучше даже выше

О как. В каком сегменте конкурировать станем? :)

Ну если дальше упираться в VLIW, то точно ни в каком не будем.

Тогда в России и индустрия появится. И тогда вопрос с "информационной безопаснотью" и "импортозамещением" решится сам собой.

Жаль только — жить в эту пору прекрасную
Уж не придется — ни мне, ни тебе

производство на 90нм Микрона переводить.
А оно заработало?

Честно говоря, не знаю актуальное состояние. Как минимум, что-то на 90нм делали. Ну вот будет повод довести до ума техпроцесс

Если бы гораздо более очевидные и существенные проблемы с ИБ были бы решены - можно было бы заниматься и безопасностью процессоров, но...

>Микропроцессоры архитектуры Эльбрус (e2k) - это абсолютно аутентичная разработка компании МЦСТ, основанная на предыдущем опыте создания линейки Эльбрусов 1/2/3 ещё в СССР.

Именно, т.е. многопроцессорные симметричные системы высокой надежности с развитой операционной системой написанной на языке высокого уровня, повторная входимость кода и пр. Для поддержки языка высокого уровня (Эль78) на уровне машинных команд (безадресных, работающих со стеком) аритектура подходит, навеяна вероятно Burroughs D825.

Широкий формат команд вероятно получается при машинной интерпретации на уровне микрокода безадресных стековых команд cpu. Такое впечатление, что при микропроцессорной реализации этой архитектуры (несомненно интересной но слегка реликтовой) под управлением Linux, все это совершенно не оправдано, цель непонятна. Если бы к примеру ставилась цель совместимости, возрождения/развития уникального sw написанного для Эльбрусов 1/2/3, понять было бы можно конечно.

Проблему VLIW архитектур можно обосновать просто, почти математически. VLIW имеет фиксированное окно, в которое должны уложиться элементарные шаги алгоритма по принципу максимального заполнения окна. Незаполнение окна вызывает потерю эффективности.

Но всегда найдутся такие алгоритмы, количество шагов которых будет либо короче, либо не кратно размеру фиксированного окна, а следовательно, алгоритмы будут выполняться неэффективно.

VLIW иходно предназначалась для узкой ниши - DSP, MATRIX, VECTOR, Image/Video Processing часто при hand-writen / hand-optimized коде "горячих" мест. Но в качестве General Purpose вычислителя (в особенности при компиляции) архитектура VLIW обречена проигрывать RISC.

AMD в Graphics Core Next с ее RISC SIMD (SIMT) ушли от VLIW SIMD (TeraScale) еще в 2010х. Этот уход вызван анализом результатов симуляции.

>VLIW иходно предназначалась для узкой ниши ...

именно, плюс большой опыт использования horizontal microcode в супер компьютерах, каковыми и должны были быть Эльбрус 1/2/3, если правильно помню, примерно так там и было сделано исполнение команд cpu

"Эльбрус" исходно экономически был обоснован не как General Purpose процессор, всё это обросло вокруг проекта уже позже. Так что если такое утверждение положено в название статьи, то оно изначально с изъяном.

Эльбрус обосновывался как процессор для ВПК. Для работы в составе радаров. Радары это задачи DSP. Это определило выбор VLIW архитектуры.

Большинство компилируемых синтетических тестов из CISC/RISC мира не отражают реальную пиковую производительность VLIW архитектур.

Реальность с Эльбрусом такова:

  1. Исходно, приоритетной задачи создать general purpose процессор не стояло.

  2. Было понимание, что создать General Purpose процессор превосходящий мировые многолетние разработки за адекватное время/деньги вряд ли возможно. Собирались создать именно специальный процессор, для специальных применений.

  3. Процессор требовался на самом деле преимущественно для ВПК (DSP, обработка радарных сигналов в реальном времени), это налагало определенные требования.

  4. Именно это (классически) определило выбор VLIW. Попутно, спроектировать производительный VLIW проще (а значит реально по деньгам и срокам). Но это налагает требования к написанию для него кода. Обычные general-purpose тесты реально достижимую производительность процессора не покажут.

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

  6. Именно это (п.5) определил широкое обсуждение "Эльбруса" общественностью (например эту статью). В противном случае это был бы просто очередной микропроцессорный комплект №XXXX о котором мало кто знает.

Реальность такова, что в середине 90-х бытовало мнение, что VLIW как general purpose CPU крайне перспективен. Поэтому появились Итаниум, Трансмета, Эльбрус. Время показало, что мнение было ошибочным. Эльбрус изначально планировался именно как перспективный general purpose CPU.

и да, и нет, примерно как Burroughs, многоцелевой, в том числе для реального времени, но без жестких требований

ps

про VLIW в те благословенные времена никто не догадывался, думали скорее в терминах horizontal microcode, VLIW стали обсуждать в районе Эльбрус 3, если не позже, как обычно imho

Эльбрус 3 это конец 80-х. И давайте наше обсуждение сведём всё же к VLIW. Иначе если мы тут начнём выяснять за EPIC, horizontal microcode и т.д., обсуждение укатится в сторону религиозных споров.

нет вопросов, только Эльбрус 3 в конце 80х в железе и близко не было (по памяти)

Эльбрус 3 был сделан в районе ~90-го года что-то в порядке одного экземпляра и насколько он был работоспособен данные расходятся. Но вроде как идеи оттуда перекочевали в e2k. Я, ясное дело, свечку не держал, всё со слов старших товарищей.

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

>3. Процессор требовался на самом деле преимущественно для ВПК (DSP, обработка радарных сигналов в реальном времени), это налагало определенные требования.

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

Похоже вам поставили минус за раскрытие военной тайны.

>Радары это задачи DSP.

в те времена были специализированные процессоры, DSP это IC которых и близко не было с нужным быстродействием и уровнем интеграции

>Это определило выбор VLIW архитектуры.

интересные фантазии, про VLIW даже Joseph Fisher узнал слегка позже

Основной тезис статьи, а именно

процессорная платформа, которая претендует стать массовой и конкуретной на рынке десктопных и серверных процессоров, не может быть VLIW архитектурой

конечно правильная, но устаревшая лет на 20. Именно тогда и следовало бы выбирать "правильную" архитектуру на основе озвученных автором тезисов. Причём, как мы теперь знаем, названием этой "правильной" архитектуры -- это первые 3 буквы из имени автора. Но 20 лет назад OoO там не было. А когда появилась, то по этому пути пошёл Байкал, но тоже не особо преуспел, и это даже если не принимать во внимание судьбу Опанасенко.

В любом случае, обстоятельства сложились по-другому, и все последние четверть века МЦСТ "пилили" свою собственную e2k, прекрасно зная о её принципиальных недостатках (собственно, в статье так и написано). И по самым скромным оценкам на это уже потрачено несколько сотен миллионов долларов гос.финансирования. Кому именно автор теперь предлагает сказать сакраментальное: "Работа проделана большая, так дело не пойдёт" (с) ?

С другой стороны, вынесенный в название тезис "тупик для развития отечественной линейки general-purpose CPU" вообще с правильным тезисом мало связан, поскольку как минимум предполагает, что существует какой-то нетупиковый путь "развития отечественной линейки general-purpose CPU". Причём автор его знает. Очень интересно было бы чтобы он с нами поделился этим видением.

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

Конечно можно рассмотреть и технические аспекты статьи. Например, автор конечно очень правильно разделил "архитектуру" и "микроархитектуру". И даже указал, что RISC/CISC победил благодаря развитию микроархитектуры. Но почему-то забыл даже упомянуть (а хотелост бы обсудить), что микроархитектура e2k со времён известной статьи в MPR претерпела лишь косметические изменения.

Короче, тут в комментариях мы вряд ли сумеем конструктивно продвинуться в данном вопросе "Тупик или не тупик?". Может, перейти в известную ветку на ixbt, в которой e2k уже более 20 лет обсуждается?

но устаревшая лет на 20

вполне современный тезис, в свете описанного в самом начале статьи

Причём, как мы теперь знаем, названием этой "правильной" архитектуры -- это первые 3 буквы из имени автора

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

Причём автор его знает. Очень интересно было бы чтобы он с нами поделился этим видением.

Если будет - отдельной статьёй.

Иначе где вообще гарантия, что цели Yadro чем-то отличаются от целей МЦСТ

Гарантий нет, но это не повод оставлять всё как есть

Но почему-то забыл даже упомянуть (а хотелост бы обсудить), что микроархитектура e2k со времён известной статьи в MPR претерпела лишь косметические изменения

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

Может, перейти в известную ветку на ixbt, в которой e2k уже более 20 лет обсуждается?

Спасибо - не надо.

вполне современный тезис, в свете описанного в самом начале статьи

я как раз не собирался обвинять Вас в ангажированности, и потому наоборот, изначально хотел отделить "современность" дискуссии "VLIW vs [RC]ISC" от её "своевременности". Про второе, естественно, согласен. Ибо в концепции "сквозных проектов" надо найти потребителей, которые будут готовы через 3 года купить разработанное на эти самые "крупные инвестиции". А Эльбрусы покупать никто не готов (тут выше писали о каком-то "главном заранее удовлетворённом заказчике", но это всё из области тех мифов, отсутствие которых -- это главное, что проимпонировало мне в Вашей статье). А из тех причин, по которым потребители не готовы покупать Эльбрусы, "уникальность архитектуры" конечно самая простая, понятная, и никак не устранимая за предлагаемые сроки и деньги. Но я надеялся, что статья не только об этом.

Нет, я не утверждаю, что ARM - это правильная архитектура.

я наверное не очень внятно тут сформулировал: это я утверждал, что с технической точки зрения, ставка на ARM у Байкал Электроникс была правильной. Но, как бы то ни было, уверенно превзойти e2k по производительности Байкал-M удалось пока только в JS. Как это объяснить в рамках Вашего правильного тезиса? Вы же о производительности писали? Не о других свойствах Байкалов (в том числе и -T), которые позволяют легко обыгрывать Эльбрусы в тех немногочисленных тендерах, что удалось провести?

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

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

Гарантий нет, но это не повод оставлять всё как есть

Вы считаете, что "сквозные проекты" имеют хоть один шанс не "просквозить как фанера над Парижем" в очередной раз? Ответьте пожалуйста, я перенесу Ваш ответ в нашу "вечную" ветку, и через 3-4 года мы узнаем были ли Вы правы или нет. Там за 20 лет уже много таких предсказаний накопилось...

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

да, это я пропустил --- упоминание действительно есть. Хотя с этим я бы как раз поспорил. Микроархитектура в том же Итаниум развивалась вполне себе в тренде, о чём Вам уже написали. Однако суть в том, что в e2k она не развивалась (даже не важно по каким именно причинам, например, там не только OoO нет, но даже аппаратного префетча), потому "Эльбрус это просто старые процессоры" --- это не совсем миф. IMHO конечно.

Как это объяснить в рамках Вашего правильного тезиса?

Я не буду придираться, что Байкал-М обошёл Эльбрус не только в JS, т.к. вопрос по сути совершенно правильный. Ответ на него лежит на поверхности - Байкал-М это чип с энергопотреблением в 3 раза меньше, чем Эльбрус. Байкал-М это ванильная имплементация архитектуры Cortex-A57, вообще говоря ориентированной на сегмент носимых устройств. Проще говоря, микроархитектура там не особо оптимизирована и урезана для снижения энергопотребления. Если же ваша цель - максимальный перформанс, то можно разработать микроархитектуру, которая будет больше потреблять энергии, но цифры бенчмарков там будут существенно выше. Посмотрите, например, цифры того же Apple M1 для примера

с Вами вообще в первый раз общаюсь

вообще говоря, мы с Вами лично знакомы

Вы считаете, что "сквозные проекты" имеют хоть один шанс не "просквозить как фанера над Парижем" в очередной раз?

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

Однако суть в том, что в e2k она не развивалась

Опять-таки, строго говоря, она развивалась. Проблема в том, что любые серьёзные изменения в микроархитектуре сразу приводят к изменениям в архитектуре почти всегда - и далее как следствие переработка всего системного софта и перекомпиляция кода. Поэтому существенных изменений старались избегать, ибо такой цикл повторять никто в МЦСТ в здравом уме не захочет.

существует какой-то нетупиковый путь «развития отечественной линейки general-purpose CPU»

В случае МЦСТ это был Sparc. Был.

Микроархитектура в том же Итаниум развивалась вполне себе в тренде, о чём Вам уже написали.

Потому что Itanium это не ванильный VLIW, а EPIC, который проектировался с возможностью эффективно выполнять софт на новых процессорах.
Бандлы из трёх инструкций короткие, в отличии от VLIW, которые обычно делают подлиннее.
Poulson выполнял уже 4 бандла за такт, имел coarse-grained SMT и т.д.

Короче, тут в комментариях мы вряд ли сумеем конструктивно продвинуться в данном вопросе «Тупик или не тупик?». Может, перейти в известную ветку на ixbt, в которой e2k уже более 20 лет обсуждается?

VLev, вы прекрасно знаете что слово "конструктивно" в случае ixbt не может быть применено.
Пороховая бочка, доверха набитая хейтерьём, которое переклинивает от слова «отечественный». Особенно иммигрантов из Штатов и Израиля, c одной стороны и людей с синдромом ПГМ с другой :)

пока не очень понимаю как мне формулировать свои мысли, чтобы Вы не обиделись

Там я стараюсь не обижать даже упёртых эльбрусофилов…

Человек с ixbt зашёл в барна хабр(с)

В случае МЦСТ это был Sparc

нелюбимое дитя.

Потому что Itanium это не ванильный VLIW, а EPIC

на самом деле я был бы совсем не против развития микроархитектуры Эльбруса и по пути "ванильного VLIW". Собственно, даже у Бабаяна была большая программа развития микроархитектуры. То, что озвучивалось -- удвоение числа вычислительных кластеров.

Пороховая бочка, доверха набитая хейтерьём, которое переклинивает от слова «отечественный»

надеюсь, это Вы про "Политику" пишете, а не про тематические разделы. Наша ветка в "процессорах" находится, н никого там от её названия не клинит.

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

Человек с ixbt зашёл в барна хабр(с)

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

надеюсь, это Вы про «Политику» пишете, а не про тематические разделы.

Нет, я пишу про «Отечественные микропроцессоры. Состояние и перспективы».
Правда я уже давно туда не заходил, но не думаю что что-то изменилось.
Неужели вы даже но названию стран не опознали «пациентов»? :)

ну Ok. Констатирую, что моя жалкая попытка заманить автора в нашу ветку провалилась :(

Каждый волен заблуждаться, в том числе и автор. Тем не менее, автору хотелось-бы посоветовать:
1. Как можно меньше уподобляться эмигрантам/ренегатам ругая "Alma Mater".
2. Тщательнее и глубже изучить состояние дел (в том числе проблемы и недостатки) других "правильных" (микро)архитектур, чтобы избежать использования ошибочных доводов.

Хочется посоветовать давать поменьше пустых советов, особенно когда их у вас не справшивают

Как можно меньше уподобляться эмигрантам/ренегатам ругая «Alma Mater».
Это что-то из серии «о мертвых или хорошо, или никак»? Кто же ещё сможет качественно и конструктивно разобрать недостатки, как не люди, хорошо и глубоко знакомые с предметом обсуждения?

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

Это сарказм такой про автора статьи?

Ходить на работу 10 в организацию, заниматься бинарной трансляцией, не хватать звезд с неба, выгореть и разочароваться - это примерно совсем не то, что вы подразумеваете.

Я ничего не подразумеваю. Мой пост был ровно о том, что пытаться запрещать кому-то что-то говорить — это цензура, а цензура — недопустима.

Достаточно показательно, что вы сразу пропустили этап хоть какой-то технической дискуссии и сразу перешли на личности, приводя аргументы в стиле "автор дурак! не верьте ему!".

Что касается ваших пространных рассуждений о звёздах, выгорании и разочаровании (про выгорание особенно смешно в контексте стиля работы в МЦСТ ). Вы вряд ли в теме вопроса, т.к. мы лично не знакомы, а пересказ чьих-то мнений из третьих рук дело достаточно скользкое и необъективное априори. Но могу сказать, что если мы сейчас углубимся в данную тему, то там у меня есть запас "окуительных" историй, которые смоют в трубу последние остатки мифа о великих МЦСТ. Мне кажется, это заведомо не в ваших интересах.

Поэтому, я могу вам предложить ограничиться чисто технической дискуссией. И в данном плане я предлагаю пригласить звёзд МЦСТ (хоть всех сразу) и устроить публичную дискуссию по данному топику (RISC/CISC vs VLIW). А там и посмотрим, кто чего стоит на самом деле.

Рекомендую не-предвзято перечитать мой первый комментарий.

Ваш первый комментарий - это пустое надувание щёк. Вам нечего сказать по существу, но пытаетесь что-то из себя изобразить.

"Уважаемый", с такими "позывами к дискуссии" вам - к малахову.

Но таки в чем-то соглашусь - и первого (моего) комментария было слишком много как для самой статьи, так и для комментариев/ответов.

О, ну конечно. Очередной непризнанный гений снизошёл до нас но вступить в дискуссию не смог - корона помешала.

Вы остыньте, а уж потом переходите на измерение корон.

Хомячки опять негодуют в карму!
Ножкой топ - не пущать, такскаать, нельзя такие комбинации букв слагать, наверное.
А как там было?... саморегуляция, но от хомячков ничего не устоит!
Короче, спать не могу ;)

Тем не менее, занимательно что аффтар сумел убедить аудиторию что он (внезапно) прям-таки в теме проблематики, светоч в перспективах развития "микроархитектур", а его мнение авторитетно и достойно внимания ;)
Не доронин, но явно с задатками для "хабра-пипл хавает".
Хорошо что ничего, по большому счету, от этого НЕ зависит = бальзам.

Сам-то кто? Ой, бросьте - уже 20 лет как читать разучился и мимо-крокодил.

Заказал попкорна смотреть как YADRO(включая все хвосты ибм) и Huawei(включая все приобретения) огородят от госзаказа к концу года.

Мне интересно, а какие перспективы развития у x86 и ARM, например? AVX1024 что ли? :)

AVX1024 что ли? :)

Ага. С 6-байтным префиксом RVEX и 4-байтными опкодами.

Ага. А сколько там каналов памяти потребуется, мне даже думать не хочется ))

Мне интересно, а какие перспективы развития у x86 и ARM, например? AVX1024 что ли? :)
А какие перспективы у Эльбруса? Сейчас в широкой команде 6 слотов. Чтобы увеличить пропускную способность, увеличат до 16? Причём на обычных последовательных задачах (gui, архиваторы, драйверы) в команде будет 2-3 выполняемые инструкции, а остальные NOP-ы, потому что параллелизма не нашли.
Перспективы развития определяются спросом и предложением.
Причём тут SIMD набор?
Впрочем на ARM векторный набор с переменной длиной слова вплоть до 2048 бит.
developer.arm.com/documentation/102476/0001/Introducing-SVE

Интересная статья, видно, что у автора наболело, да и он действительно представляет о чем пишет. Но вот по отдельным моментам есть вопросы.

  1. Несколько забываем о легаси. Т.е. да, Эльбрус со своими VLIW заморочками не идеален, но он есть. И он может исполнять х86 код здесь и сейчас. Для любых других архитектур придется пересобирать софт или запускать под эмулятором. А х86 под эмулятором даже на х86 это туго, молчу уж про RISC, в качестве хост системы.

  2. Таблица про сравнение архитектур: частоты/tdp и т.д. Во-первых в ней не хватает столбца производительность. Толку с 5ГГц на проце, если он все время с заблокированным конвейером и ждет данных?. Во-вторых. Сами данные в таблице:

    1. Первые две строки: у Xeon почти в полтора раза меньше транзисторов (раз уж вы именно их используете в качестве основы для сравнения площади, а не саму площадь), частота меньше на +-20%, но TDP только на 12% больше. Так ли плох Итаниум?

    2. По Эльбрусам вообще завал - СПАРК аж в 7 раз меньше, и по частоте быстрее только на треть, зато по TDP VLIW больше только в 2 раза. Так, получается, VLIW очень даже неплох?

    Умолчим про то, что сравнивать TDP только по количеству транзисторов не совсем корректно, все же есть памяти, а они тоже едят и очень немало...

Что до вывода: а какое решение вы предлагаете? Купить лицензию на х86? Малореально, да и в текущей ситуации не факт, что перспективно. MIPS уже нельзя назвать перспективным, к сожалению. Перспективы ARM тоже не совсем ясны, RISC-V пока только развивается, хотя направление интересное, но серьезных процессоров на нем я пока не видел.

  1. Эльбрус запускает x86 код через бинарную трансляцию. Ничто не мешает делать также на любой другой архитектуре.

  2. Есть миллион факторов, которые влияют на приведённые цифры. Например, у Спарка выше частота, а значит выше напряжение питания, а TDP зависит от этого квадратично. Плюс на SOC'e Эльбруса есть много всякой периферии и т.д., которые в обычном режиме особо ничего не потребляют. Ну и т.д. и т.п. Эта таблица была приведена лишь для того, чтобы показать, что чипы VLIW от одних и тех же производителей уступают по частотам их RISC конкурентам. Производительность проца - это грубо микроархитектурная скорость + частота. И VLIW проигрывает и там, и там. Ну и по ней также видно, что энергоэффективности там нет (если бы частота была ниже, но и TDP ниже, можно было бы утверждать, что "зато он более энергоэффективен").

Что касается решения - у меня есть своё мнение, но это тема для отдельной статьи, т.к. это куда более дискуссионный вопрос. Здесь я хотел лишь показать проблемы VLIW и то, что он заведомо проигрывает любой RISC/CISC архитектуре при прочих равных.

Я так, мимо крокодил.
Но однажды я два дня курил официальную документацию на Cortex-A. (интересовало в первую очередь исполнение из тесносвязанной памяти, кэширование, сколько там АЛУ, и прочее)
Ребят, камон, полезную работу выполняет не процессор, а весь компьютер. И где там бутылочные горлышки сразу совсем не понятно. В частности, я пришел к выводу, что системная шина (шины) сложнее и противнее в разработке чем вычислительное ядро. Как еще объяснить что MIPS лицензировало её у АRM? Да и полной документации на неё нет в открытом доступе. А ведь это целый «интернет» с пакетной передачей данных.
Или вот взять такие аппаратные блоки как USB или PCIe. Это также огромная огромная работа, которая влияет на производительность всего компьютера.
Короче я считаю что Эльбрус это как Жигули (новые Lada) собственной разработки. Нужно хоть чем-то заниматься чтобы не похоронить конструкторскую школу. Очень важно уметь доводить работу до конца, а не быть специалистом по фрагментарным знаниями
В процессе разработки компьютеров необходимо решать очень много задач, которые не упираются только в архитектуру процессора.
Всё быстро развивается и мы можем попасть в совсем другую реальность. Прямо сейчас я пишу с компьютера в 48 ядер и 96Гигабайт. Вы уверены что то что вы описываете будет важно, если вдруг ядер у всех будет по 4800?
я считаю что Эльбрус это как Жигули (новые Lada) собственной разработки. Нужно хоть чем-то заниматься чтобы не похоронить конструкторскую школу
Почему бы не делать вместо «Жигулей» нормальные процессоры? Конструкторская школа — она не только в МЦСТ, она ещё в десятке других мест в России развивается, и в некоторых случаях с как минимум не меньшим успехом.
да нет никаких других мест. Этож референсные дизайны от вендоров, где ты можешь (в зависимости от типа лицензии) максимум поменять периферийные блоки. Мы же сейчас не про микроконтроллеры? Большинство также это только прототипы на ПЛИС без воплощения в чипе.
Проблема референсных дизайнов, если отбросить политику, это то чем тебя ограничили буржуинские менеджеры по продажам. Например у Cortex-M0 раньше нельзя было заявлять частоту выше 48 МГц.
Я как-то читал статью про разработку вакцины Спутник-Ви. Что я прочитал между строк — предыдущие вакцины формально сделали, но никуда не успели с внедрением, а зато последняя выстрелила за счет того что руку набили.
Так и с Эльбрусием. При необходимости можно заменить ядро на Risc-V. Это будет, вероятно, только процентов 5 от всех работ где компетенцию уже наработала.
Другое дело что, как понимаю, сейчас большая интрига. Куча контор влошилась в Эльбрусий, а государство их кинуло. Вероятно сейчас отечественность будет доказываться наличием внутри отечественного контроллера, который будет мигать светодиодами, а внутри будет Интел.
Референсные дизайны от вендоров? Нет никаких других мест?
Вы сейчас довольно серьезно обидели как минимум НИИСИ и Синтакор, а как максимум ещё Элвис, Модуль и IVA. Все они ведут собственные микроархитектурные разработки вещей совсем не микроконтроллерного уровня.
«Пусть расцветают сто цветов.»

Уважаемый Vlev выше написал

И по самым скромным оценкам на это уже потрачено несколько сотен миллионов долларов гос.финансирования.


Сотня миллионов долларов — это примерно стоимость квартир в одном доме типа «корабль» в Москве. Да хоть миллиард пусть потрачен, это немного на масштабах страны. В конце-концов, государств со своей школой микропроцессоростроения очень мало.
Дайте мне тысячу рублей? Вам несложно, а государств, в которых мне дают тысячу рублей, очень мало.
НЛО прилетело и опубликовало эту надпись здесь
Вот из этого и других ваших аргументов следует, что у нас с вами принципиально разное понимание экономической сущности государства РФ. Насколько я понимаю, пожалуйста поправьте меня, если я неправ, вы полагаете, что на разработку Эльбруса будут затрачены деньги, дополнительно отобранные у нас с вами.

С моей (и, кажется, ув. Am0ralist) точки зрения, деньги у нас отнимут в любом случае налогами. То есть, эту тысячу у меня уже забрали. А дальше уже есть несколько вариантов — либо их потратят на понты в виде очередной яхты/недвижимости, либо на МЦСТ. Вот второй вариант меня устраивает несравнимо больше.

Да, разумеется, у меня есть знакомые в науке, сидящие на грантах, лучше бы моя налоговая тысяча пошла им. Но такого выбора у меня нет.
Это как в анекдоте «папа, ты теперь пить будешь меньше? нет, доча, это вы с мамой будете меньше есть».

То есть траты на яхты/виллы никуда не денутся, а вот деньги, ушедшие в МЦСТ, могли бы уйти в школы или на ремонт дорог.
либо их потратят на понты в виде очередной яхты/недвижимости, либо на МЦСТ. Вот второй вариант меня устраивает несравнимо больше.
А если два варианта — это Эльбрус и какой-то другой более перспективный процессор?
НЛО прилетело и опубликовало эту надпись здесь
Вы рады?
Да, рад.
НЛО прилетело и опубликовало эту надпись здесь
Ну, с учетом, что проект выглядит именно распильным по тому количеству процессоров, которые получит государство в итоге.
А что, Эльбрусов или Байкалов предполагается больше?
НЛО прилетело и опубликовало эту надпись здесь
Зато на то, что вам типа нравится потратят больше денег, чем на то, что вам не нравится и это — гуд по вашему.
Начнем с того, что на выделенные оллайтм на Эльбрус деньги спроектировать нормальный процессор в принципе было невозможно. Деньги, которые предполагается потратить на процессор от Yadro, хотя бы примерно соответствуют реальной стоимости подобного проекта.

А когда выделяются копейки, которых еле хватает на поддержание штанов и зарплаты, это плохо вне зависимости от того, о чем конкретно идет речь.
НЛО прилетело и опубликовало эту надпись здесь

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

Это неизвестно. Но сейчас судя по тому, что МЦСТ проигрывает контракты Байкал, последних было произведено больше, ну или как мимнимум, их смогли поставить в нужных количествах. А Байкал-Т так вообще можно в магазине купить, жаль что он уже никому не нужен.

Что касается Syntacore + Yadro, так они планируют окучить совсем другую область. МЦСТ при должном финансировании и т.д. к 25-му году смогли бы предоставить 32С, который в любом случае будет производительнее запланированного RISC-V (тут я конечно из новостей информацию беру).

Вобщем двоякое ощущение, с одной стороны я скептически отношусь к МЦСТ и VLIW, но с другой, они хоть что-то показывают реальное, пригодное для серверного применения. Как бы за двумя зайцами не погнаться...

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

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

Ни мы, ни вы выбором этих вариантов не занимаемся. А по-факту, я значительно более пессимистичен — только возможность натуральной войны заставляет хоть как-то тратиться не только на яхты.

ну вообще эти самые то ли 360, то ли 270млрд руб уже выделены. Если их не раздадут разработчикам микроэлектроники -- они просто уйдут в бюджет. Причём на данный момент озвучено всего 12 сквозных проектов. С ограничением по максимальной стоимости. То есть денег ещё есть на несколько проектов.

Так что если надо -- подавайте заявку. Я вот не очень понимаю почему не подают...

Линус Торвальдс согласен с автором статьи (правда, он пишет про итаник):


static instruction scheduling is a monumentally bad idea. It's stupid beyond words, unless you're doing the tiniest of microcontrollers or DSP's. Doing it for a processor design that was supposed to take over the server world? Unbelievably stupid.

https://www.realworldtech.com/forum/?threadid=193189&curpostid=193515

Да, спасибо, я кстати забыл про этот поста Линуса. Он пишет здесь не просто про Итаник, а про то, что даже Итаник ( который типа не просто VLIW, но ещё и EPIC, что в идеале должно давать больше гибкости) уступает процам с OoO. Заметьте, Линус - это тот человек, который 6 лет в Трансмете делал индустриальный VLIW процессор. Т.е. он один из немногих людей, который не просто рассуждает теоретически, а реально поел все реальные проблемы с перфом лопатой. Неудивительно, что наше мнение с ним в данном вопросе совпало ))

где антагонисты утверждают, что Эльбрус это просто старые процессоры Итаниум с переклеенными шильдиками,

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

Люди считают какие-то байты, такты, деньги, производительность - кому это всё интересно? Идея Эльбруса всегда была в одном - чтобы в случае полномасштабной войны, санкций, перекрытия вообще всех границ и поставок остаться ну хоть с каким-нибудь процессором, ОС, софтом. Пусть в 10х медленнее мировых аналогов, но всё-таки на нём можно будет запустить какую-то программу расчётов чего-небудь, связи, офисный пакет, и т.д. Никто никогда не собирался конкурировать с х86 или arm. Конкурировать собирались только с ситуацией "в стране не осталось компьютеров вообще" и у этой ситуации вполне себе Эльбрусом выиграли.

А что мешает клонировать ARM? И остаться в случае войны со своими процессорами, но кучей написанного софта.

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

При этом всём вполне может быть, что стратегия "скопипастить arm" тоже на всякий случай лежит в ящике, это ведь сделать можно в любой момент, там ведь всё на виду лежит.

НЛО прилетело и опубликовало эту надпись здесь
А зачем нарушать лицензию? Нельзя, как apple, заплатить 1 раз за неограниченное право на ARMv8, например?
НЛО прилетело и опубликовало эту надпись здесь
Китайцам зен1 продали с «исходниками», или фотошаблоны?
Потому как если с исходниками (как в случае с ARMv8), то никакой проблемы, что ARMv9 не продадут. Можно самостоятельно развивать v8
НЛО прилетело и опубликовало эту надпись здесь
То есть эти делать можешь, а развивать — нет
Как так? А если в криптографии (или ещё где-то) ошибка? Исправить нельзя?
НЛО прилетело и опубликовало эту надпись здесь

А тут можно не думать, а почитать что говорилось в новостях:

AMD reached out and clarified that it did not transfer the RTL to the JV, but JV can modify some parts of the design to customize the chips for the China market. AMD isn't being more specific about the licensed technologies. Sources close to the matter tell us that while some portions of the core can be modified, other parts cannot.

Так не в России же он делается, а на Тайване. Так что в этом смысле никакой разницы.
чтобы в случае полномасштабной войны, санкций, перекрытия вообще всех границ и поставок остаться ну хоть с каким-нибудь процессором
… производимым на Тайване?
А сетевой контролёр и прошивку HDD/SSD (ну и сами HDD/SSD) в Эльбрус компьютере кто сделал??

Отличная статья про эти процы.
Но большинство комментариев здесь похожи на какие-то философские рассуждения "а вот если так сравнивать, то было бы вот так". Хотя автор вроде развёрнуто изложил всю базовую ущербность VLIW. И вообще эта статья является отличным пособием "вы никогда не заработаете денег на VLIW"...

VLIW не виноват :)

А как вы смотрите на развитие VLIW и OoO (с его тратами топлива на динамическую оптимизацию снова и снова) не в вакууме без ограничений, а в рамках мировой повестки борьбы с глобальным потеплением?
Вот реальный пример того, где это уже вылилось в реальные нормативные акты:
https://habr.com/ru/news/t/569888/

при определенных вложениях есть ли у VLIW перспективы обойти прочие подходы пусть и не в производительности однопотока, а в плане Вт/попугай?

Ерунда это полная. Любой КАМАЗ выделяет больше тепла и CO2, чем стойка в дата-центре, а потому, если глобально подходить к проблеме потепления, с них надо начинать оптимизацию.

Не говоря уже о всяких металлургических производствах и т.п.

Только в каких-то узких нишах, и то не факт. OoO не так уж много стоит пауэра, если цель - снизить потребление.

При динамической JIT компиляции проблем с инлайнингом и вообще глубоким анализом алиасинга нет. А если пишешь на си - ну - страдай и оптимизируй руками.

Зачем своя микроархитектура? Чтобы не быть зависимым от "партнера", который хочет тебя извести. Если бы в мире был коммунизм, можно было не ставить дверей и открыто обмениваться знаниями. Как номенклатура СССР решила покупать в купе со станками и импортные ЭВМ ч софтом (IBM, DEC, прочие), то не убили бы собственное вполне конкурентоспособное, более того, перспективные направления развития ВТ и кибернетики. Решили: зачем "геморрой", как Вы сказали, если можно купить готовое или лицензию? Эффект будет таким же, как если всю жизнь пользоваться шпаргалками и ненаучиться мыслить самостоятельно. Это выстрел даже не в ногу, это выстрел в голову. А теперь поздно пить боржоми и сорить деньгами, теперь именно что геморрой и нужен, свой путь (тем более что западный уже тупиковый, зачем догонять?). Но не деньгами решать проблему, потому что набегут разного рода жулики и казнакрады, а перспективамт стать долговременным лидером отрасли. Пусть академические инстититуты на кафедрах ломают голову. В том числе и над разработкой фундаментальных основ и прикладных технологий интегральный процессов, конструкции и принципов действия средств тиражирования. Неужели остались люди, кто хочет только нахапать и беспечно прожигать жизнь, и не интересно быть не только свидетелем, но и творцом нашего общего будущего?

Пусть академические инстититуты на кафедрах ломают голову.
Так уже все равно разработано в НИИСИ РАН и производится серийно. Прсто с меньшей помпой, чем Эльбрусы.

В целом согласен с автором.

Но есть нюанс. Сейчас и в ближайшие 5 лет Эльбрус это самый производительный отечественный процессор. С 16С, который вроде как вот-вот уже будет доступен, нечего сравнить. Байкал-М - заурядный ARM, который больше подходит для эмбеддед и тонких клиентов. Есть конечно надежда, что их планы сбудутся и они выпустят 48 ядерный Байкал-S. КОМДИВ-64 - это тоже сугубо встраиваемые системы. Поэтому 16С безальтернативен как для тех кого поставили в позу импортозамещения, так и для тех кто хочет на этом заработать, но при этом требуется производительность: СХД, СУБД, миникластеры числодробилки и т. д. И, возможно в этих областях, он ещё долго будет существовать и развиваться.

Как general-purpose Эльбрус видят только его создатели, которые в лице А. Кима, постоянно устраиваю плач Ярославны, о том как их зажимают, не пишут в контрактах ISA E2K, отдают Байкалы в РЖД. А государство похоже не видит его таковым в силу разных причин, будь-то создание видимости конкуренции, лавирование между заинтересованными лицами и т. д. Да и те же госконторы будут его саботировать в тех областях где ему есть адекватная замена и цена.

В будущем, в качестве ISA хотелось бы видеть развитие RISC-V, т.к. при всех недостатках, она сможет покрыть задачи от микроконтроллеров до серверов. Ну и второе направление - это конечно развитие переферии. 100 Гбит/с сетевя карта с offload (TX/RX, TLS, iSCSI, NFS, RDMA) дорогого стоит. Ну и конечно формировать некий альянс отечественных производителей с кросслицензированием и т.д.

Ну так выпускали бы быстрый Эльбрус-E2K и одновременно с ним быстрый Эльбрус-SPARC и не было бы этих проблем, казалось бы. Или они как раз боятся прямого столкновения с Fujitsu, когда на одинаковой архитектуре сравнения микроархитектур не удастся скрыть?

Т.е. всё-таки "русский итаник". Ровно те же проблемы, которые были у Итаниума - перекладывание головной боли на компилятор, отсутствие нормального быстрого компилятора, своя архитектура с вытекающим из этого куцым юзерспейсом за который надо бороться.

НЛО прилетело и опубликовало эту надпись здесь

Я думаю что проблема именно в том, как они развивают

  • Максимально закрытые спецификации

  • Весь софт пишут сами, минимально взаимодействуя с OpenSource сообществами. Хотя могли бы компилятор сделать на llvm, окрыть всем, и получить как встроенные в llvm плюшки, так и сами делать vliw оптимизации в OpenSource

  • Усложненный доступ к документации и рабочим экземплярам

  • Не предлагают лицензировать архитектуру другим организациям

  • Не проводят CusDev. Например - если эта штука хорошо молотит числа, то может быть нужно позиционировать его для нейросетевых применений, сделать соответствующие версии PyTorch, TensorFlow.

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

на месте госзаказчиков я бы выбирал Байкал-S или RISC-V варианты

Я бы тоже, но их пока не существует.

В свое время, когда в СССР было принято решение в пользу серии ЕС ЭВМ, для военных оставили линейку БЭМС-Эльбрус. Эльбрус тоже был тогда жутко дорог, потому что выпускался поштучно. Были предложения использовать Эльбрус и в промышленности, чтобы увеличить объемы производства и тем самым уменьшить себестоимость. Но эти планы не были приняты, что по моему было правильно. Может и в нынешней ситуации, не стоит из Эльбруса делать универсальный процессор. Заказчики Эльбруса - военные. Вот пусть они и работают с ним. А что касается дороговизны Эльбруса, так военная техника всегда будет дороже гражданской.

Вот сравнение самых топовых решений процессоров на базе VLIW-архитектур от Intel и МЦСТ с их RISC/CISC аналогами

Это не срачегенно, надо было табличку Radeon vs GeForce сделать, тем более там как раз вроде бы идеальный случай для VLIW - и рассчеты максимально однообразные, и код компилируется на машине пользователя при уже, потенциально, известных данных.

Кстати, неизвестность реальных данных и какие куски станут горячими - это для C++, а вот для всё более и более модных виртуальных JIT-машин (.NET, JVM, потенциально даже и LLVM) это уже не аргумент.

r0 нельзя использовать в одной ШК сразу для трех операций, второй пример ассемблера демонстрирует так называемый конвейризованный цикл - аппаратную фичу эльбруса которая позволяет обращаться к массиву данных минуя кэш не используя обычные лоады/сторы а используя мувы из буфера подкачки.

Конечно без инлайна функции это не работает так как вызовы в конвейризованных циклах не допускаются и будет обычный цикл как на интеле с прыжком наверх - и чё? В чем недостаток, я не понял.

Как и не понял что там и где у тебя в коде нельзя проанализировать, где в чем тупик.

Понял только что ассемблер сложный-нипанятный а в документацию посмотреть хотя бы перед написанием статьи мы не умеем.

В общем статья уровня школьник для школьников пересказал какие то тезисы из интернета и приправил своей безграмотной отсебятиной.

  1. Конечно же можно r0 использовать для нескольких операций в одной ШК. Пример этого кода мной просто скопипастен отсюда

  2. Что касается инлайна, по моему я достаточно доступно изложил, в чём проблема - если в Эльбрусе не сработал инлайн, то у вас исполнение итерации цикла увеличивается с 1 такта (это если конвейеризация сработала) до 17. В то время как на том же Интеле увеличение будет до 2-3х тактов, как мы тут в коментах немного уточнили

Остальные ваши напрыги я смысла коментировать не вижу

>Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать ~1 такт, не отличаясь принципиально от случая, если инлайн сработал.  В то же время на Эльбрусе одна итерация данного цикла будет занимать порядка 17 тактов.

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

Ваш комент явно говорит о том, что вы не поимаете ни как это работает на Эльбрусе, ни как не Интеле.

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

[случайно отправилось - продолжение]

из реального кода, то там всё было бы гораздо труднее для понимания.

Дальше. У Эльбруса подготовка для перехода обычного занимает 5 тактов, return - 7. Вызов call мешает вам вынести подготовку регистра ctpr из цикла. Поэтому вы вынуждены будете сделать подготовку и ждать 5 тактов для вызова call, потом 7 тактов для return и ещё 5 тактов на переход на голову цикла. Отсюда минимум 17 тактов итерация.

В Интеле же весь этот код превратится просто в линейку add - mov-cmp , т.к. jmp-call-ret бранч предиктор просто сожрёт и выбросит (там есть некоторые накладные расходы, но они небольшие и требуют более глубокого погружения в детали работы процессора, здесь это неважно для понимания)

Тем не менее, примеры из реального кода были бы намного более интересны и содержательны (естественно, на горячих циклах). Можно справедливо допустить, что появление других операций приведёт к изменению поведения компилятора и отказу от подстановки функции. Но это приведёт и к увеличению наполненности ШК. Так что возникает вопрос: сохранится ли отставание в более сложном примере? Уверен, оно наоборот сократится.

К тому же, Эльбрус невозможно рассматривать в отрыве от конкретного компилятора. Не скажу, что это хорошо, это создаёт определённые неудобства разработчикам. Тем не менее, есть факт: при использовании различных версий компилятора ощущаются существенные различия. От версии 1.23 до 1.26 наблюдается улучшение производительности, в частности, от подстановок функций, которые раньше не происходили. Насчёт более ранних версий не знаю, не использовал, может быть, там не было видимого роста.

Потом следует отметить, что ваш пример показывает, с какими проблемами можно столкнуться из-за отсутствия предсказателя переходов. Точно так же можно привести альтернативный пример: условный переход в цикле. Традиционно компиляторы под x86-64 генерируют код с переходом. Ручное переписывание с заменой условного исполнения на арифметические операции позволяет добиться кратного ускорения. С другой стороны, из-за предикатного исполнения на Эльбрусе такой проблемы нет. И ни один из этих примеров не показывает явного преимущества одной архитектуры над другой.

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

Тем не менее, примеры из реального кода были бы намного более интересны и содержательны

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

Так что возникает вопрос: сохранится ли отставание в более сложном примере? Уверен, оно наоборот сократится.

Оно сократится, но сохранится. Этот пример призван показать, что на том коде, который компилятор не смог соптимизировать, производительность VLIW падает куда более драматично, чем на RISC/CISC. А в реальных сложных проектах это будет происходить сплошь и рядом.

Ручное переписывание с заменой условного исполнения на арифметические операции позволяет добиться кратного ускорения. С другой стороны, из-за предикатного исполнения на Эльбрусе такой проблемы нет.

Добиться кратного ускорения на x86 в таком случае можно только если бранч предиктор часто ошибается в таком коде. А это крайне редкий случай. Что касается Эльбруса - предикатный код может сгладить проблему наполненности ШК, но надо понимать, что такой подход всё равно уступает OoO с бранч предиктором, где просто исполнятся только те команды, которые нужно. А Эльбрусу всё равно придётся дожидаться статически спланированных инструкций по критическому пути. Ну и для хорошего предикатного кода нужен хороший профиль, что тоже часто непременимо.

Кажется, появление предсказателя переходов решит определённый пласт проблем.

Согласен, что набор проблем решит. Но останутся другие. Я, кстати, про Итаниум недаром в статье упомянул. Там бранч предиктор был (и вообще там VLIW-архитектура изначально более гибкая). Но он всё равно по итогу существенно проигрывал x86.

Это, безусловно, так, с той лишь поправкой, что они потребовали бы куда более глубоких знаний для восприятия статьи

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

Э нет, уважаемый, подготовка перехода происходит ДО входа в цикл, а попутно еще надо проверить условие вообще входа в цикл, в самом цикле подготовку каждую итерацию не делают, уж если не хватило конвеера для функции (хотя как раз три то и хватает - цикл+функция+выход из цикла) проще непосредственный бранч/вызов делать.

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

У оутофордеров нет такого режима, у них бранч - раз инструкция - два инструкция - сравнение каких-то операндов - хоп джамп в тот же бранч, процессор даже не знает что он в цикле работает, эльбрус делает так же в самых глухих случаях типа while (ptr1 != NULL) он не отличается (с точки зрения процессора) от обычной процедуры и вызовы из нее делаются хоть куда. У интела будет колл и мов константы у эльбруса подготовленный кол и add литерал с r0, хочешь показать пример на котором эльбрус обсирается так хоть у знающих людей спрашивай совета перед тем как что то объяснять на глупых примерах. В данном примере эльбрус скорее потому что его компилятор будет этот цикл оптимизировать, тогда как гцц на*уй выкинет вообще и вставит загрузку константы.

Премного уважаемый, не могли бы прекратить нести полную околесицу?

подготовка перехода происходит ДО входа в цикл

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

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

В таком цикле можно сделать вызов, но надо будет самостоятельно сохранить/восстановить всё нужное состояние не переживающее вызовы.

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

Прыжки на начало цикла без подготовок работают только в loop_mode инструкциях, просто потому что (не знаю как это работает) они в конвеере не опустошаются а мотаются бесконечно пока не переключишься. В иных случаях после каждого вызова/перехода надо готовить конвейер заного, но это не значит что нельзя сделать подготовку ДО потом прыгнуть в цикл вызвать подготовленный CALL вернуться и тут же его опять начать готовить вместе со сложением и прочим до возврата в начало цикла, так как это все в рамках одной процедуры которая задается процедурным окном о каких таких исключениях речь я не понимаю.

У интела пайплайн в два три раза длиннее кстати, какой там нахрен один такт при переходах.

Ну и алу все конечно тоже конвейризованные, конечно можно r0 на считывание всем заюзать, тут я тупанул.

Я с ваами сам отупел уже

Мне кажется, что мы тут не при чём.

Прыжки на начало цикла без подготовок работают только в loop_mode инструкциях, ...

Нет, вы опять несёте какую-то пургу.

Я бы не хотел ссылаться на авторитетность, но я один из тех кто написал эмулятор для e2k и имею определённое представление о том как он работает.

Давайте вы прекратите распространять нелепицу и вводить в заблуждение тех, кто не согласен с автором?

Можете не утруждать себя ответом, т.к. я на него не отвечу.

Да вижу.

Один писал эмулятор команд суперскаляра для эльбруса пришел к выводу что раз в ассемблере х86 микрокода и пайплайна не видно значит там такой проблемы нет, а декодируется исполняется,конвейризируется и инлайнится там все так же как в компиляторе и все за один такт а то и меньше.

Второй поверх суперскаляра городил явно управляемую машину и пришел почему то к выводу что на целевой машине тоже при переходах все откидывается и берется со стека, а порядок исполнения интеловский ассемблер не позволяет нарушать и поэтому это проблема эльбруса что он не позволяет силами x86 isa реализовать какие то свои причуды с порядком исполнения действий с операндами. А пайплайн это что то из мифологии и 6 тактов подготовка просто потому что глупые люди делали надо просто прыжок делать за один такт и всё, как на умных интелах.

Так и живем.

Вы сначали написали глупости про r0, теперь пишите ерунду про подготовки в Эльбрусе. Вам верно заметили что из цикла в данном случае ничего вынести нельзя будет, т.к. подготовка не переживёт call.

Автор утверждает, будто VLIW при тех же нанометрах имеют более высокое тепловыделение и больше транзисторов.
И приводит в пример Intel​ Xeon​ Processor E3-1290, у которого объем кэша 8Мб в сравнении с Итаником 2017г, у которого этого кеша 32Мб

После такой ловкости рук все остальные сентенции вызывают мало доверия.
Хотя в статье и есть достоверные сведения, но по своей направленности она явно ангажирована. По сути, лайт-вариант антиэльбрусовских пасквилей образца начала нулевых, авторство которых принадлежит одному деятелю родом с Незалежной, известному под ником matik
Судя по всему, Yadro перехватила все контракты на лисковые хранилища под закон Яровой. При том, что в их хранилищах используются Интелы.
Отсюда и обещания по скорому созданию своего варианта Risc-V, отсюда и подобные статьи

Так у этого Intel'a и TDP почти в 2 раза меньше по сравнению с Итаниумом 4-х ядерным. При существенно более высокой частоте. Выше есть сравнение 32MB Итаниума и 20MB x86 и ситуация там схожая.

Невозможно найти абсолютно одинаковые примеры 2х процессоров, есть куча нюансов. И данная таблица в первую очередь показываюе, что VLIW процессоры не достигают топовых частот аналогов RISC/CISC, т.е. проигрывают не только по микроархитектурной скорости, но и по частотам. Энергоэффективность это я написал вдогонку, но это косвенно вытекает из приведенных цифр. И кстати, большое количество кэша на Итаниуме - это следствие недостатков VLIW, о которых я выше писал. Т.е. RISC/CISC здесь имеет преимущество, т.к. ему нужно меньший размер кэшей для достижение хорошей производительности - т.е. это опять-таки снижает энергоэффективность VLIW.

Большая проблема приведённой в статье таблицы — это перечисление характеристик конкретных выпущенных процессоров. Вы берёте конкретные модели и обобщаете их опыт на весь подход. Данные образцы отстают, но является ли это свойством архитектуры на базе VLIW? А как же вопрос затраченных на разработку ресурсов. Неудача гиганта уровня Intel заставляет задуматься, но весьма вероятно, что из-за отсутствия быстрого успеха они потом вкладывали в IA-64 меньше, чем в x86. А исходная неудача IA-64 — это, естественно, сумма факторов, недостатки VLIW в которой сыграли не в первую очередь.

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

Очевидно, что мне нужно было продемонстрировать проблему на каких-то конкретных примерах (и мне кажется, я привёл достаточно честное сравнение). Иначе бы данная статья превратилась бы в научную монографию в несколько сот страниц. Конечно, всегда можно сказать - "а вот на самом деле просто туда недостаточно вложились" и доказать или опровергнуть такой тезис будет практически невозможно. Но т.к. я достаточно много занимался разработкой компилятора под Эльбрус, то прекрасно понимаю, что проблемы VLIW достаточно фундаментальны. И данное мнение разделяют многие люди из индустрии. Собственно, в данной статье хотелось на каком-то базовом уровне проблемы осветить. Насколько получилось - судить читателям.

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

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

На Западе гонялись за Гигагерцами и догнали их. А у Эльбруса с оптимизированной логикой не получилось, про то и статья

у нас оптимизировали логику так, что процессор считает гораздо больше данных при меньшей частоте
Вообще нет. Если бы все было так, как вы говорите, то «оптимизированную логику» можно было бы просто разогнать до той же частоты, что и плохую логику конкурентов, и получить огромное преимущество в производительности.
НЛО прилетело и опубликовало эту надпись здесь
Ну пять — это, допустим, перебор, но до двух с половиной с полутора «оптимизированную логику» не должно составлять труда разогнать)
НЛО прилетело и опубликовало эту надпись здесь

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

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

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

"Эксперты" там, конечно, местами такого наговорили...

А если вы уже смотрели и не очень сложно — можете вкратце пересказать, о чем там вообще речь?

основные утверждения:


  1. эльбрус — уникальная архитектура, которая обеспечивает непревзойдённую производительность на такт и у которой большое будущее, скоро все страны будут стоять в очереди за процессорами (нет, хотя бы в этой статье много написано);
  2. собственный дизайн процессора обеспечивает независимость от санкций (скорее нет; это только один из элементов, пусть и очень крутой, гигантского пазла, который не «работает» пока не собран целиком);
  3. использование процессоров собственной разработки — ключевой момент в обеспечении информационной безопасности (я не эксперт в безопасности, но считаю, что нет);
  4. risc-v — это низкопроизводительные процессоры, которые не смогут в обозримом будущем конкурировать с лидерами рынка и даже с эльбрусом (нет)
Спасибо большое за выжимку!

Довольно странный опус (с кучей самоповторений разными словами), о том что:

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

  2. Новые правила импортозамещения в плане вычислительной техники неадекватны и позволяют читерить поставив пару российских светодиодов назвать сервер российским (не возьмусь судить, так как не читал оригиналы постановлений)

  3. На risc-v есть только слабые процессоры для IoT, неспособные запустить линукс и вообще не более 450 МГц, а его прям сразу уже тянут в сервера (и это не так, у того же sifive'а есть платы заметно мощнее, да и даже у Syntacore пару лет назад были ядра в разы более мощные, чем там говорилось)

  4. OpenSource сущее зло, потому что весь контролируется корпорациями, а значит не свободен, а если не контролируется, то убивает инженерную школу так как не позволяет определять курс (думаю очевидно, почему это не так и те кто так говорил не знают что такое OpenSource).

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

Спасибо большое за выжимку!
Лучшая часть: «приказ 66 в star wars — это о ссылка к приказу 66 Совмина СССР об отказе от собственных архитектур компьютеров и копированию западных». Остальное видео в целом примерно того же уровня.
Автор не отличает архитектуру от системы команд, а систему команд от микроархитектуры.

ну так пипл-то хавает, почитайте комментарии.

(имеются в виду комментарии к видео, конечно)

Дело в том, что VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением.

Не все с этим согласны. У ребят получилось совсем наоборот. Выигрыш VLIW от 1.2 до 1.57 раз против пятиступенчатого конвеера на, по сути, одной и той же архитектуре RISC-V.

У ребят получилось совсем наоборот.

Не все согласятся, что получившееся у ребят является VLIW.

Во-первых, здесь имеется динамическое планирование (см. Scheduler).

Во-вторых, динамическое разруливание конфликтов по данным (см. Hazard Unit).

В-третьих, а чем этот процессор принципиально отличается от multiple-issue superscalar?

В-четвертых, а кто из этих малюток RISC-V, с которыми они сравнивают, является Out-of-Order? Гугл утверждает, что Kronos и NeoRV32 являются in-order, а PicoRV32 вообще не конвейеризированный, DarkRiscV имеет трехстадийный конвейер, так что тоже без OoO.

Прочитайте статью, пожалуйста, прежде чем отвечать. Некрасиво получатеся.

здесь имеется динамическое планирование

«implementing a VLIW architecture based on that ISA is the lack of a powerful compiler to schedule original instructions in accordance with the VLIW instruction format»
«We design a simple instruction scheduler to exploit the parallelism potential of sequentially original instructions dynamically.»
Если коротко и по-русски, то они реализовали динамическое планирование в связи с отсутствием компилятора, который должен был бы осуществлять статическое планирование.

кто из этих малюток RISC-V, с которыми они сравнивают

Ни с одной из этих малюток они свой дизайн не сравнивают. Явно же написали:
«we design a single-issue pipelined five-stage 32-bit RISC-V architecture»
«The architecture’s ALU supports the same integer and floating-point instructions with the same latencies»
То бишь, по сути то же ядро, с тем же планировщиком, но с пятиступенчатым конвеером.

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

Если коротко и по-русски, то они реализовали динамическое планирование в связи с отсутствием компилятора, который должен был бы осуществлять статическое планирование.

Если коротко и по-русски, то можно ли относить к VLIW архитектуру с динамическим планированием и динамическим разрешением конфликтов? Имхо, нет. Они в своей работе упоминают гибрид VLIW и Superscalar под названием DISVLIW. Вот это, пожалуй, оно и есть.

Ни с одной из этих малюток они свой дизайн не сравнивают. Явно же написали:
«we design a single-issue pipelined five-stage 32-bit RISC-V architecture»
«The architecture’s ALU supports the same integer and floating-point instructions with the same latencies»
То бишь, по сути то же ядро, с тем же планировщиком, но с пятиступенчатым конвеером.

В исходном комменте, вы ссылаетесь на эту статью, утверждая, что не все согласны, что VLIW уступает в производительности ОоО CISC/RISC. Между тем, в статье нет сравнения с ОоО-архитектурами. Следовательно, ссылка не состоятельна, она не демонстрирует выигрыша VLIW против ОоО. Это не значит, что вы не правы, просто эта статья не подтверждает этого никак.

можно ли относить к VLIW архитектуру с динамическим планированием и динамическим разрешением конфликтов

Боюсь, это риторический вопрос. У ребят просто не было выбора, так как написать компилятор для VLIW архитектуры слишком трудоемко. IMHO, это получилось очень хорошее приближение. Причем совершенно корректное, так как возможности оптимизации статического планирования в компиляторе намного выше, чем простейшего динамического на FPGA.

нет сравнения с ОоО-архитектурами

Это только Ваше предположение. Такие подробности в статье опущены.

Это не значит, что вы не правы,

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

Это только Ваше предположение. Такие подробности в статье опущены.

Там приводится сравнение в производительности с процессорами, которые не являются ОоО, о чём я писал выше.

Причем совершенно корректное, так как возможности оптимизации статического планирования в компиляторе намного выше, чем простейшего динамического на FPGA.

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

Там приводится сравнение в производительности с процессорами, которые не являются ОоО, о чём я писал выше.

Я этого не вижу. Процитируйте, пожалуйста. Мы вообще об одной и той же статье говорим?
обсуждалось выше [...] динамическому планировщику видна занятость ресурсов в динамике

Обсуждать можно сколько угодно. А экспериментальных измерений на одном и том же FPGA я не видел. Опять жду пруфа.

Я этого не вижу. Процитируйте, пожалуйста. Мы вообще об одной и той же статье говорим?

Табличка сравнения из вашей статьи: https://ieeexplore.ieee.org/mediastore_new/IEEE/content/media/6287639/8948470/9200617/nguye.t4-3024851-large.gif

По ссылкам можно убедиться, что ни один из них не ОоО.

NeoRV32

PicoRV32

DarkRiscV

Kronos Risc V

Обсуждать можно сколько угодно. А экспериментальных измерений на одном и том же FPGA я не видел. Опять жду пруфа.

В качестве экспериментального пруфа ограничусь упоминанием того, что большинство современных General Purpose процессоров являются суперскалярами с ОоО, а не VLIW. Если бы на статике можно было далеко уехать, на ней бы уезжали и не городили динамический огород.

Табличка сравнения из вашей статьи

Вы явно статью не читали. Табличка служит, в первую очередь, для сравнения их суперскалярного ядра с прочими.
При этом они явно пишут:
«However, our design recognizes a few tradeoffs. First, as stated in the Synthesis Results section, the instruction scheduler consumes substantial hardware utilization. The instruction scheduler is simple to utilize less hardware than other modules. Second, scheduling eight sequential instructions from the fetch stage requires one extra clock cycle for each scheduling turn. This requirement increases program execution time, indicating that IPC is slightly degraded. Our VLIW core still achieves higher IPC compared with existing open-source RISC-V cores at the expense of hardware resource, as presented in Table 4.»

В качестве экспериментального пруфа

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

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

Простите, но там указаны оба их ядра, и их не-VLIW ядро ни разу не суперскалярное, с IPC-то ниже единицы и single-issue.

Пруф? Я не понимаю ход Вашей логики.
С чего Вы взяли, что их ядро не поддерживает параллелизм на уровне инструкций. Что-то мне подсказывает, что без этого оно проиграло бы VLIW в разы, а не в десятки процентов. Или Вы пользуетесь иным определением суперскалярности?
Синоним Superscalar — это Multiple Issue.
А у них — Single Issue
Ни с одной из этих малюток они свой дизайн не сравнивают. Явно же написали:
«we design a single-issue pipelined five-stage 32-bit RISC-V architecture»
«The architecture’s ALU supports the same integer and floating-point instructions with the same latencies»
То бишь, по сути то же ядро, с тем же планировщиком, но с пятиступенчатым конвеером.

Как раз тем это исследование меня и заинтересовало, что тут сравниваются процессоры с одинаковой (насколько это вообще возможно) микроархитектурой
То есть, они взяли своё ядро, без OoO, без всяких плюшек «больших» процессоров (типа переименования регистров), с 5-ступенчатым конвеером, и стали думать, как его ускорить. Сделали инструкцию в 8 раз шире и получили прирость 20-50%. Ну разумеется, какой-то прирост они должны были получить в ответ на увеличенный транзисторный бюджет. Но это не даёт ответа на главный вопрос: а какой бы они прирост получили, если бы пошли не в сторону VLIW, а в сторону мейнстрима: длиннее конвеер, горизонт декодирования команд на 300 шагов вперёд, спекулятивное выполнение, предсказание ветвлений, OoO.

Это и было бы аргументом в ответе на вопрос
VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением
А не то, что они сделали.
они взяли своё ядро, без OoO

Есть ли в их ядре OoO или нет — я не знаю. Дайте пруф, откуда Вы это взяли, пожалуйста.
не даёт ответа на главный вопрос: а какой бы они прирост получили, если бы пошли не в сторону VLIW, а в сторону мейнстрима

Да, я не вижу ответа на этот вопрос ни в этой статье, ни в какой-либо другой. А мой уровень навыков работы с FPGA не позволяет провести такой эксперимент. То бишь, вопрос остается открытым.
Дайте пруф, откуда Вы это взяли, пожалуйста.
Вам выше дали пруф того, что ни одно из использованных в статье открытых ядер не имеет OoO. Или вы решили проигнорировать набор ссылок?
Вам выше дали пруф того, что ни одно из использованных в статье открытых ядер не имеет OoO

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

Я по прежнему жду пруф на то, что именно дизайн суперскалярного ядра выполненого авторами статьи на FPGA не является OoO.

Пруф в том, что их ядро имеет singe-issue в названии, за такт выдается на исполнение не более одной инструкции, и количество инструкций за такт (IPC) меньше единицы. У суперскаляра оно > 1 и multiple issue.

Спасибо. С этим утверждением согласен. Параллельно у них выполняются пять инструкций, но без OoO.
Но их издержки («scheduling eight sequential instructions from the fetch stage requires one extra clock cycle for each scheduling turn») тоже следует учитывать.

Не считая того, что компилятор может позволить себе менять порядок выполнения инструкци в почти неограниченном горизонте, чего не скажешь про аппаратный OoO планировщик.
Мне бы не хотелось приобрести процессор, у которого производительность заявлена на 500 попугаев, в реальности он выдаёт только 100, потому что «очень сложно написать компилятор». И у этих ребят из статьи так и получилось. Выходит, что проблемы с компиляторами это особенность VLIW и её нельзя игнорировать.
Да, я не вижу ответа на этот вопрос ни в этой статье, ни в какой-либо другой

Хорошо, тогда зачем на этот вопрос вы ответили: «У ребят получилось совсем наоборот» со ссылкой на статью. Может, вы что-то другое имели ввиду, но прозвучало так, что вы нашли в статье отрицательный ответ, и вам бросились все доказывать, что в статье нет ответа.
Я имел в виду только то, что утверждение
VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением

является ГИПОТЕЗОЙ. И строго оно НЕ ДОКАЗАНО.
Ссылка на статью сбивает с толку. Зачем она, если не подтверждает и не опровергает оспариваемое утверждение.
Она напрямую оспаривает утверждение, переводя его в статус гипотезы, а вовсе не доказанного факта.

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

Она напрямую оспаривает утверждение, переводя его в статус гипотезы, а вовсе не доказанного факта.

Так в статье же нет ОоО, а гипотеза/утверждение про ОоО.

Вы можете доказать, что OoO даёт больший прирост производительности, чем явное параллельное выполение N операций в VLIW? Особенно на сравнимом количестве транзисторов на кристалле и максимально схожей микроархитектуре. Я таких экспериментальных доказательств не видел.
А вот в истории уже была конкуренция между IA-64 (VLIW) и x86-64. И основным фактором проигрыша IA-64 считается вовсе не производительность.
И основным фактором проигрыша IA-64 считается вовсе не производительность.

а что же? вот гуглоперевод из немецкой википедии:


Performance comparison with Power7 and Xeon
According to measurements ("benchmarks") from 2010 with Itanium 9350, the CPU is clearly behind the current Power7 family from IBM and also behind the current Xeon CPUs in the SPEC comparison of the CINT 2006 rate and the CFP 2006 rate from Intel (for better comparability, the Power7 test results were standardized to 8 computing cores [2] ).


HP Integrity BL860c i2 (1.73 GHz / 24 MiB Quad-Core Intel Itanium 9350 ): CINT-2006 rate: 134; Cores: 8; CPUs: 2; Date: March 2010
HP Integrity BL860c i2 (1.73 GHz / 24 MiB Quad-Core Intel Itanium 9350 ): CFP-2006 rate: 136; Cores: 8; CPUs: 2; Date: March 2010
IBM BladeCenter PS702 Express ( Power7, 3.0 GHz, 8 core estimated): CINT 2006 rate: 260; Cores: 8; CPUs: 1; Date: April 2010
IBM BladeCenter PS702 Express ( Power7, 3.0 GHz, 8 core estimated): CFP-2006 rate: 215; Cores: 8; CPUs: 1; Date: April 2010
Fujitsu PRIMERGY BX620 S5 (Intel Xeon E5540, 2.53 GHz): CINT-2006 rate: 214; Cores: 8; CPUs: 2; Date: September 2009
Fujitsu PRIMERGY BX620 S5 (Intel Xeon E5540, 2.53 GHz): CFP-2006-Rate: 166; Cores: 8; CPUs: 2; Date: September 2009

Вики, как всегда, в своем репертуаре. Сравнение 65нм с 45нм. Ну так и без указания архитектур и процессоров было изначально понятно, что 45нм техпроцесс выиграет у 65нм )))

производительность на гигагерц у зиона оказалась выше.
разве техпроцесс позволяет улучшить IPC?

является ГИПОТЕЗОЙ. И строго оно НЕ ДОКАЗАНО.

ИМХО это демагогия. строго не доказано и что человек не может полететь просто усилием мысли.

спекулятивное выполнение

Это даже в Эльбрусе есть.

Вам собственно уже ответили, но на правах автора резюмирую.

Эти ребята мечтают о PhD и высоком индексе Хирше, поэтому им необходимо писать статьи. Пятиступенчатый single-issue конвейер - это классика от Паттерсона из начала 80-х. После этого индустрия столкнулась с проблемами роста производительности такого подхода, стала популярна идея VLIW и 90-ые ознаменовались попытками сделать хорошие чипы на базе такой архитектуры, столкнулись с проблемами, которые я в статье упомянул, а потом просто в итоге был сделан ОоО где-то в начале 2000-х и вопрос с тех пор по сути закрылся.

Т.е. данная статья не имеет отношения к моему утверждению. Они сравнивались с простейшим in-order чипом, а у меня речь о современных ОоО процессорах.

В данной статье высказано достаточно обоснованное мнение, что VLIW рано хоронить. Не более того.

Мне никаких ссылок на иные экспериментальные исследования не привели. А толкать гипотезы — это явно в стиле демагогии, а не технической дискуссии.
Лично меня никто не убедил, что OoO на этапе компиляции (не ограниченный по глубине, теоретически, ничем) хуже, чем OoO аппаратный (всегда ограниченный длиной конвеера).

На сегодня имеем откровенно финансовую проблему VILW — стоимость компиляторов для них существенно превышает стоимость аппаратного решения OoO. Потому что компилятор для каждого ядра надо писать свой.

А если завтра появятся средства автоматизации написании эффективно оптимизирующих компилятров для VLIW хотя бы из LLVM, то все гипотезы будут или подтверждены, или опровергнуты экспериментами. Куда более дорогими и качественными, чем уже произведенные.

В статье высказано лишь то, что можно сделать VLIW лучше, чем single issue in-order процессор. А мы говорим про OoO процессоры. Это совершенно разные вещи.

Что касается экспериментальных исследований и т.д. Они все давно проведены. Результатом является результаты на бенчмарках VLIW архитектур и современных OoO процессоров. Можете взять цифры Spec'ов от МЦСТ, потом зайти на spec.org и посмотреть на результаты современных процов. Даже если мы отнормируем на частоту, разница там будет в разы для single thread performance.

Можете взять цифры Spec'ов от МЦСТ

Ну пожалуйста, не надо демагогии. Оптимизация для Эльбрусов ныне на уровне плинтуса.

Например:
«Обход элементов списка представляет собой цикл с рекуррентностью (зависимостью между итерациями) вида p=p->next, иными словами, адрес, по которому производится чтение на текущей итерации, зависит от результата чтения на предыдущей итерации.

При таком обходе темп перебора элементов списка не превышает 1 элемент на время доступа в L1$. Например, для процессора Е8С этот темп в 24 раза (!) меньше максимально возможного»

Каким образом можно проводить эксперименты, если уже доказано, что эффективность оптимизации компилятором для Эльбрусов существенно уступает любому конкуренту?
Каким образом можно проводить эксперименты, если уже доказано, что эффективность оптимизации компилятором для Эльбрусов существенно уступает любому конкуренту?
А сложности с компилятором — это тоже принципиальное свойство VLIW и плата за упрощение хардвера. Так что тут все честно.
Что честно? То что сейчас, пока сложности с компилятором не имеют рентабельных методов решения, VLIW проигрывает? А с этим разве кто-то спорит?
Но я уже приводил пример выше с ДВС и электромобилями. Вы в XX веке тоже утверждали бы, что электромобили нужно похоронить? )))

Вы вообще уже не понимаете, что пишете. Данный абзац просто описывает проблему зависимости инструкций чтения друг от друга при обходе списка. И о сложностях для Эльбруса в таких случаях. Качество компилятора тут совершенно непричём. На x86 в gcc будет то же самое (просто x86 сгладит проблемы ввиду наличия продвинутой микроархитектуры с префетчем аппаратным)

Собственно, вы сейчас пытаетесь уйти куда-то в сторону. Я вам по существу ответил. Если вас ответ не устраивает- это уже не ко мне.

Отлично понимаю. По ссылке утверждается, что продвинутый компилятор, благодаря поддержке в Эльбрус спекулятивных операций с отложенным прерыванием, вполне мог бы выполнить обход списка в 24(!) раза быстрее, чем текущая реализация.
Где я ухожу в сторону?

Там нет такого утверждения, это вы выдумали.

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

Спекулятивные операции имеют несколько другую цель. Но давайте я тут не буду устраивать лекции по архитектуре e2k. В конце концов, для этого есть сотрудники МЦСТ, можете у них проконсультироваться.

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

Если не знаете, зачем утверждать? Вот я могу утверждать, что рекурсивные запросы к БД (а ведь это и есть по сути обход по списку!) нередко оптимизируются на порядок, а то и два, по сравнению с подходом «в лоб». Для примера, hierarchyid тип данных в MS SQL.

Я знаю, потому и утверждаю. Если вы не понимаете сути предмета - это ваши проблемы.

Ясно, понятно. Если для вас не очевидно то, о чём написал комментатор выше, думаю, мы не придём к консенсусу.
Ну зачем Вы так? Или Вы не в курсе, что слово «очевидно» является ключевым признаком демагогии и потому в технических дискуссиях не может употребляться?
x86 сгладит проблемы ввиду наличия продвинутой микроархитектуры с префетчем аппаратным

Спекулятивные операции имеют несколько другую цель

Вы утверждаете, что спекулятивные операции не могут выполнять функции префетча?

"Спекулятивных операций с отложенным прерыванием" - о которых вы тут написали, это совсем иное, чем префетч. И префетч - это отдельный вопрос. Перестаньте заниматься демагогией.

С какого перепугу это не предзагрузка?
«Встроенная функция __builtin_prefetch() позволяет заблаговременно подкачать данные в кэш-память. Подкачивается целая порция кэш-строк — 64 байта.»
«При использовании __builtin_prefetch() в ассемблере можно увидеть спекулятивное чтение, но не в регистр назначения, а в empty»

Перестаньте заниматься демагогией.

Жду извинений.
Здесь в документации термин «спекулятивное чтение» применён ошибочно. Спекулятивное — значит, процессор делает эту операцию до того, как станет известно, нужна ли она, в предположении, что операция будет нужна.

__builtin_prefetch() же генерирует обычную инструкцию чтения, которая выполняется в своём порядке появления в коде. С какого перепугу это чтение «спекулятивное»?
По определению в словаре
Базируется на предположении.

Спекулятивное — значит, процессор делает эту операцию до того, как станет известно, нужна ли она, в предположении, что операция будет нужна


«6.4.3. Спекулятивный режим

Для повышения параллелизма на уровне операций часто бывает полезно начать выполнять операцию до того, как станет известно, нужно ли было выполнять эту операцию. В случае, если операция может привести к прерыванию (например, чтение из памяти по недопустимому адресу, или деление на 0), такое преждевременное исполнение может привести к некорректному аварийному выходу из программы. Для того, чтобы решить эту проблему, в архитектуре «Эльбрус» допускается выполнение операций в режиме отложенного прерывания, также называемом спекулятивным режимом исполнения операции.»

Вы, похоже, не понимаете идеологии VLIW. Одна машинная команда уже содержит в себе N инструкций. И если в текущий момент исполнения программы не все N инструкций можно выполнить, вместо простоя исполнительного блока можно сделать что то из предположения (speculative). Например, загрузить блок данных в кэш.
Зачем вы процитировали кусок мануала спекулятивного режима, когда речь о prefetch?
И если в текущий момент исполнения программы не все N инструкций можно выполнить, вместо простоя исполнительного блока можно сделать что то из предположения (speculative). Например, загрузить блок данных в кэш
О какой загрузке вы тут говорите? Откуда должен взяться адрес для загрузки?
Потому что в VLIW предварительная выборка реализуется именно спекулятивным выполнением команд. В частном случае — загрузкой в кеш блока при указании целевого регистра empty.
Про адрес вы вопрос проигнорировали, а он был важным, чтобы вы разобрались, какую нелепость пытались выдать о простое исполнительного блока.
Потому что в VLIW предварительная выборка реализуется именно спекулятивным выполнением команд. В частном случае — загрузкой в кеш блока при указании целевого регистра empty
Очень интересно. __builtin_prefetch() компилируется в обычную команду чтения памяти ld.s
По вашему, любое явное чтение памяти можно назвать спекулятивным, или только чтение в регистр empty?
Про адрес вы вопрос проигнорировал

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

Нет, конечно. В команду спекулятивного чтения, что я и процитировал выше. Мало ли, вдруг содержимое регистра, содержащего этот адрес все же изменится в ходе исполнения программы, а текущее содержимое содержит некорректный адрес. Это не должно приводить к аварийному завершению программы.
Я пытаюсь указать вам на ошибку в этом заявлении:
Вы, похоже, не понимаете идеологии VLIW. Одна машинная команда уже содержит в себе N инструкций. И если в текущий момент исполнения программы не все N инструкций можно выполнить, вместо простоя исполнительного блока можно сделать что то из предположения (speculative). Например, загрузить блок данных в кэш
Идеология явного планирования такова, что на все операции в ширикой команде (ШК) хватает исполнительных блоков, за этим следит компилятор, когда компонует инструкции в широкую команду. Одна из этих команд — загрузка данных для prefetch. Тут нет никаких «если», все инструкции ШК начинают выполняться одновременно.
Как это никаких «если», когда именно этим руководствуется компилятор формируя широкую команду из N инструкций? Если можно выполнить спекулятивную операцию — хорошо. Если и это не возможно, то какие-то из N операций вообще окажутся NOP.
вы же пишете
Одна машинная команда уже содержит в себе N инструкций. И если в текущий момент исполнения программы не все N инструкций можно выполнить, вместо простоя исполнительного блока можно… например, загрузить блок данных в кэш

Нельзя вместо простоя исполнительного блока выполнить то, чего нет в ШК. А исполнительных модулей на все инструкции ШК точно хватает, об этом позаботился компилятор.
И в чем противоречие? Почему на этапе компиляции нельзя предусмотреть выполение вместо простоя спекулятивной операции?
А исполнительных модулей на все инструкции ШК точно хватает, об этом позаботился компилятор.

По ссылке, которую я приводил выше, даже примеры есть детальные, когда для конкретного кода ширина команды избыточна и востребована спекулятивная операция. Причем дающая существенный прирост производительности. Прочто читайте пруфы и не будете позориться публично, как сейчас.
Об этом я писал выше, что мы никогда не придём к консенсусу. Для меня ясно, что вы не разбираетесь в предмете, выдёргиваете рандомные ссылки, чтобы лишь бы что-то ответить и не потерять лицо (перед кем?). Вам же кажется, что то же самое я делаю. Предлагаю на этом закончить.
Если при обуждении Эльбрус Вы отказываетесь даже почитать его документацию, гордо утверждая, что она ошибочная и Вы лучше знаете Эльбрус и VLIW, чем его разработчики — это, IMHO, диагноз )
Ну пожалуйста, не надо демагогии. Оптимизация для Эльбрусов ныне на уровне плинтуса.

Например:
«Обход элементов списка представляет собой цикл с рекуррентностью (зависимостью между итерациями) вида p=p->next
Очень интересно. Вы говорили, что проблема VLIW в компиляторах. Вы ожидаете, что появится компилятор, который самостоятельно заменит односвязный список на массив и перепишет алгоритмы? И тогда VLIW себя покажет…
Я ничего не ожидаю. Я этого не исключаю, пока не доказано обратное. Разницу замечаете?
А вот многие здесь утвердают то, что НЕ ДОКАЗАНО, а является лишь гипотезой. Разницу замечаете?
Кстати, эту гипотезу несложно доказать, если она верна.

Берёте и вручную пишете код, который на эльбрусе ускорит обход списка в 24 раза, раз компилятор не справляется. Если вы не умеете в ассемблер, можете поискать непредвзятого спеца, который разбирается и спросить, представляет ли он хотя бы теоретически, как такое сделать.
Я не собираюсь тут доказывать какие-либо гипотезы. Я призываю только не возводить гипотезы в ранг доказанных теорем или экспериментально подтвержденных теорий.
Лично меня никто не убедил, что OoO на этапе компиляции (не ограниченный по глубине, теоретически, ничем) хуже, чем OoO аппаратный (всегда ограниченный длиной конвеера).

  1. OoO на этапе компиляции ограничен возможностями предсказания. если процессор оптимизирует «по факту», то компилятор этого сделать не может.
    запустили код на машине с другими таймингами памяти — и как это это сможет учесть компилятор? да или просто сегодня на соседнем ядре работает задача, которая вымывает l3-кэш, тайминги обращения к памяти «съехали», заранее оптимизированный VLIW-код будет страдать;
  2. как скрестить VLIW и SMT?
    тут уже говорили, что многие задачи сами по себе не особо параллелизуются, что с ОоО в процессоре, что с VLIW-компилятором IPC получается низким. SMT может кардинально улучшить ситуацию, при этом есть слухи, что скоро в x86 появится SMT4 (у в powerpc ЕМНИП и SMT8 давно есть).
Ладно там другие тайминги, код можно перекомпилировать при замене оборудования.
Что делать с тем, что предсказатель суперскаляра подстраивается под обрабатываемые данные и, если сжимаем архиватором файл из нулей, через несколько десятков/сотен итераций процессор подстроится под данные.

Тут обычно говорят про PGO, но это значит, что разработчик должен профилировать код ровно на тех данных, которые есть у клиента. А если характер данных меняется, кто будет код перекомпилировать…
если характер данных меняется, кто будет код перекомпилировать

На SQL серверах эту проблему ведь смогли решить, адаптируя компиляцию запросов на лету, в соответствии с текущими статистиками. Я ни в коем случае не пытаюсь утверждать, что и тут именно такой подход даст плоды. Я только указываю на то, что мы просто не знаем сейчас всех возможных методов оптимизации VLIW. Слишком мало эта проблема изучалась в научных кругах, по причине низкой востребованности вплоть до настоящего времени.
Я понимаю, что вы не хотите окончательно ставить крест на VLIW, пока нет строго формального доказательства, что он тупиковый путь. Опыт, примеры из индустрии — ничего не доказывают формально. Нужно продолжать пытаться, вкидывать миллиарды денег и всё такое, а вдруг взлетит, так? А за чей счёт банкет, вас не волнует.
Не ставить крест и финансировать развитие — это очень разные вещи. Опять по примеру выше. Сначала появились электромобили и только через несколько десятков лет — автомобили с ДВС. Следует ли считать, что это поставило крест на электромобилях? Или все же это было временным явлением?

Под «не ставить крест» я имею в ввиду примерять новые научные и инженерные разработки к VLIW, проверяя, не смогут ли они обеспечить кардинальный толчок развития для него.
Под «не ставить крест» я имею в ввиду примерять новые научные и инженерные разработки к VLIW, проверяя, не смогут ли они обеспечить кардинальный толчок развития для него.
Это вполне можно делать в рамках малобюджетных университетских RnD, а не в рамках дорогостоящего серийного производства и принудительного внедрения продуктовых чипов. Нормальный и принятый во всем мире путь — университеты разрабатывают новые подходы и прикидывают их эффективность, а потом все самое лучшее забирается индустрией и коммерциализируется.
Можно. Но опять, обращаясь к примеру с электромобилями и автомобилями с ДВС, хочу обратить внимание, что электромобили последние полтора века производились серийно. Просто долгое время имели довольно узкую нишу (электрокары, электропогрузчики и т.п.). То есть, сто лет назад Вы бы призывали вообще отказаться от серийного производства электромобилей в пользу автомобилей с ДВС?

«Нормальный и принятый во всем мире путь» — это коммерческий риск. Чем больше возможная прибыль, тем выше вероятность провала. Тот же VLIW не раз коммерциализировлся (Transmeta, IA-64, некоторые GPU). Я слишком плохой коммерсант, чтобы давать рекомендации об опраданности рисков. Но успешные рисковые разработки в IT не редкость. Так же как и провальные.
Просто долгое время имели довольно узкую нишу (электрокары, электропогрузчики и т.п.). То есть, сто лет назад Вы бы призывали вообще отказаться от серийного производства электромобилей в пользу автомобилей с ДВС?
Никто не призывает забыть VLIW, он себя коммерчески успешно показывает в DSP. Речь тут о GP CPU, то бишь ниша автомобилей на общественных дорогах.
Опытные электромобили для общественных дорог разрабатывались регулярно различными производителями все последние полтора века. И у меня почему то есть уверенность в том, что результаты этих разработок оказались в итоге востребованы в последствии. Вы считаете иначе?

Эльбрус и в СХД показывает себя совсем неплохо. Вполне могу представить его востребованность для специфичных серверных задач. А вот для десктопа он явно сейчас проигрывает. На настоящий момент для десктопа я обеими руками за RISC-V.
В СХД не нужны процессорные мощности. Поэтому туда может подойти и RISC-V, чтобы увеличить объём партии и уменьшить себестоимость. Вывод: Эльбрусы в СХД не нужны.
В СХД не нужны процессорные мощности.

Это идиоты Intel® Xeon® E5-2697-v4 18 core processors в СХД ставят? Или Вы все же погорячились? )))
Да, холодные медленные Xeon-ы на 2.3-2.8GHz. Не топовые 5-гигагерцовые.
Производители СХД достаточно консервативны. Уверяю Вас, не пройдет и двух-трех лет, как и эти CPU Вы увидите в СХД. На данный момент требования клиентов к производительности СХД заметно превышают возможности их производителей.
«Нормальный и принятый во всем мире путь» — это коммерческий риск.
Поэтому такого рода вещи и поручают университетам: они могут развивать даже ошибочные теории до момента, пока не станет ясно, работает, или нет, не неся при этом финансовых потерь.
А потом успешные идеи коммерциализируются.
Вы вообще читаете, что я пишу?
Опытные электромобили для общественных дорог разрабатывались регулярно различными производителями все последние полтора века. И у меня почему то есть уверенность в том, что результаты этих разработок оказались в итоге востребованы в последствии. Вы считаете иначе?


Ответьте на прямой вопрос. Без демагогии. Или проведем анализ, сколько опытных автомобилей за эти полтора века было произведено университетами, а сколько производителями?
Вы явно путаете фундаментальные исследования с отработкой технологии.
Или проведем анализ, сколько опытных автомобилей за эти полтора века было произведено университетами, а сколько производителями?
Сколько опытных материалов для аккумуляторов было разработано в университетах, а сколько — автопроизводителями?
Если Вы не демагог, то ответьте сначала на мой вопрос, который Вы уже дважды проигнорировали. В противном случае прощаюсь.
Разумеется, прототипы автомобилей в основном разрабатывают автоконцерны, тут с вами нельзя не согласиться.

Но вы привели неверную аналогию, о чем я и написал сообщением выше. Верная аналогия фундаментальных микроархитектурных исследований — не менее фундаментальные материаловедческие исследования, а не прототипы авто.
По такой логике, все языки программирования должны создаваться исключительно в университетах. Но на практике, Mozilla, Google, Microsoft, JetBrains — все что-то изобретают и пытаются ввести это в продакшн.
Язык программирования — это аналог прототипа автомобиля или прототипа процессора. Наш же разговор начался с исследования того, можно ли ускорить VLIW. Такого рода исследования в нормальной ситуации — удел университетов или специальных RnD отделов в коммерческих компаниях. Но никак не хорошее место для многолетней проверки одной новой идеи прямо в продакшене.
Если продолжать аналогию с электромобилями, попытки толкать сейчас VLIW в серию, всё равно что выпускать и продавать электромобили в 1980-х.

Оно должно вызреть и когда дозреет, само всплывёт наверх и станет модной хайповой темой. Может, до расцвета VLIW надо подождать ещё 20 лет, а может 50 или 500.
выпускать и продавать электромобили в 1980-х.

Но это же делали! Просто электромобили имели довольно узкую нишу в виде электрокаров и электропогрузчиков. И если бы это не делали, то нынешний рывок производства электромобилей мог и не состояться, а растянуться еще на долгие десятилетия.
ответил выше
Просто электромобили имели довольно узкую нишу в виде электрокаров и электропогрузчиков. И если бы это не делали, то нынешний рывок производства электромобилей мог и не состояться, а растянуться еще на долгие десятилетия.

вот именно, что электрокары делали потому, что это было выгодно, а не чтобы доказать перспективность электротранспорта.


то же самое и с vliw — оно используется там, где оно уместно. и ещё в эльбрусе.

Публикации

Истории