Comments 633
На одном дыхании. Просто великолепно.
Одно беспокоит: про неудачи в космосе говорить запретили, как бы после таких статей не запретили говорить о неудачах в процессорах.
Интересно другое - если @alexanius настолько не разбирается в теме обсуждения - зачем он вообще писал на такую горячую тему.
Далеко не всегда люди могут адекватно оценить свой уровень компетентности. Дело в том, что в МЦСТ большинство сотрудников не имеют опыта работа где-либо, кроме МЦСТ. Это приводит к крайне узкому восприятию реальности. Алексей просто не имеет серьёзного опыта работы с современными OoO процессорами. Поэтому по сути вся его статья - это рассуждения про Эльбрус. Но я же писал не просто про Эльбрус, а про то, что такой подход заведомо хуже RISC/CISC. А насколько такой подход лучше Алексей просто не осознал ещё - банально не сталкивался. Кстати надеюсь, данная статья в этом поможет
Забавны рассуждения о RISC/CISC vs VLIW тем, что Intel дошёл до AVX512 в архитектуре, гетерогенных ядер ИИ, отдельных ядер обработки видео 8К (привет 15-gen). И вишенкой на торте выглядит AVX10 для E-ядер который по сути 256 bit но инструкции 512 bit перенаправит на большие ядра.
Ну и Thread Director пиши туда же.
Так что у Intel треш происходит покруче любого VLIW.
Одно беспокоит: про неудачи в космосе говорить запретили, как бы после таких статей не запретили говорить о неудачах в процессорах.
Бери шире - запретить говорить о любых неудачах в импортозамещении!
С них, блин, станется действовать по принципу "если о проблеме никто не говорить, значит - её нет"!
Где запретили говорить о неудачах в космосе?
П Р И К А З Ы В А Ю:
утвердить прилагаемый Перечень сведений в области военной, военно-технической деятельности Российской Федерации, которые при их получении иностранным государством, его государственными органами, международной или иностранной организацией, иностранными гражданами или лицами без гражданства могут быть использованы против безопасности Российской Федерации.
34.Сведения о целевых программах Государственной корпорации по космической деятельности «Роскосмос», их финансовом и материально-техническом обеспечении, сроках их выполнения.
37.Сведения о проблемах, в том числе финансово-экономических, сдерживающих развитие Государственной корпорации по космической деятельности «Роскосмос» в одной или нескольких областях деятельности.
Пока только проект, но все шансы быть подписанным у него есть.
Это касается работников Роскосмоса, или сторонние наблюдатели не могут опубликовать статью по сведениям из Роскосмосом лично открытых источников?
Ну, у нас же судят за разглашение государственной тайны не имеющих к ней допуска людей? Так и тут. Роскосмос спокойно что-то напишет, а потом какого-нибудь несчастного, перепечатывающего эту новость во вконтактике, осудят. Палки-то фсб-шникам тоже надо как-то зарабатывать. Плюс лишний способ всяких недовольных гонять.
Если вы про Грабовского, то он, будучи сотрудником Центра геодезии и картографии по меньшей знал, чтО он продаёт. И справедливости ради, суд учёл, что карты попали к поисковику, а не за рубеж, поэтому срок был условным.
Теперь нельзя говорить о проблемах Роскосмоса, космической ядерной энергетике, квантовых и AI-технологиях и длинном ряде других вещей. В том числе по ряду пунктов указа нельзя распространять сведения, уже находящиеся в открытом доступе.
Да, не зря такие компании как Интел тратят каждый год миллиарды долларов на разработку процессоров. Видимо они пришли к тому, что имеют путем реального опыта при использовании интеллектуального труда лучших специалистов в мире так еще и затрачивая миллиарды. Думаю при возможности они также могли бы параллельно разработать лучшую архитектуру процессора, если бы это было возможно, что возможно и было сделано не однократно.
Вообще, вместо споров лучше просто приводить сравнения близких по нанометрам, тдп и транзисторам(и прочим основным параметрам) процессоров и сразу станет ясно кто прав и эти сравнения уже были на хабре не в пользу Эльбруса.
интел тащит за собой весь багаж совместимости x86... что может в итоге его и утопить (остановить развитие архитектуры по производительности), но в то же время именно совместимость с предыдущим софтом и привело к доминированию x86 архитектуры в начале гонки и убрало всех конкурентов, напомню, что изначально х86 была открыта до 80486 (или даже до пентиума, не помню точно)...
В контексте VLIW у Интела была показательная история - Итаниум. Туда были вложены огромные ресурсы, которые в итоге себя не оправдали. Так что опыт Интел подтверждает то, что написано в данной статье.
У Интел также был x86, в который было вложено еще больше средств. А еще был у АМД мегакостыль пол названием amd64, который прижился.
Но ведь процессоры VLIW существуют (не знаю насколько коммерчески успешны). Получается у них есть какая-то ниша, просто Эльбрус лезет не в ту?
Можете перечислить VLIW-процессоры общего назначения, которые вы знаете? А потом сможете перечислить все живые VLIWы какие знаете? Собственно в этих перечислениях и будет ответ на ваш вопрос.
Вы в статье приводите ссылку на Бабаяна. Так там Бабаян поясняет, почему Itanium не взлетел — потому что мог в параллель выполнять лишь 6 команд, как и суперскалярные процессоры Intel и AMD. Но, в отличие от них, требовал статического планирования. Соответственно, не мог с ними конкурировать. И дальше Бабаян поясняет, что потому в Эльбрус и была заложена потенциальная возможность исполнять по 20+ команд за такт.
Ну и вы ссылаетесь на то, что Бабаян был в курсе, что VLIW-архитектура не оптимальна. Но там он прежде всего рассуждает, что суперскаляр не оптимален, что достиг своего предела. Что поэтому они сделали VLIW, который тоже не оптимален. А оптимален явный параллелизм, который надо теоретически прорабатывать — причём это потребует не только другой архитектуры железа и других операционных систем, но и других языков программирования.
Явный параллелизм у нас и так есть — ГПУ есть в каждом компьютере, и что? Много у нас разработчиков под это дело?
Вся индустрия больших игр? Специалисты по машинному обучению?
Как только выяснилось, что можно решать задачи линейной алгербы, так сразу специалисты и появились. С GPU вопрос только один: как данные запихать в матрицы. Шейдеры - тоже дело довольно известное.
Это не React/Javascript/Typescript, но всякий любопытный программист хотя бы пробовал соответствующие инструменты.
Индустрия больших игр и разработчики машинного обучения — это и есть "немного", может 1% от общего числа программистов.
Вы недооцениваете масштаб индустрии!
1% от всех программистов это уже достаточно много. 2% - крупная ниша. 3% полноценная ветвь индустрии. На хабре полно людей, которые имели дело с играми, машинным обучением или векторными инструкциями, в том числе ваш покорный слуга.
доминирование CUDA среди озвученных выше специалистов по машинному обучение
Ну так это и есть новый популярный язык программирования и парадигма.
Системные же программисты (на C, C++, Rust и даже Go), к примеру, регулярно пользуются если не ассемблером, то встроенными компиляторными функциями для оптимизизации своих библиотек при помощи векторных вычислительных устройств (simd). По определению системщиков не может быть много, конечно, но мы все пользуемся плодами их трудов (например, в рамках glibc или каких-нибудь roaring bitmaps).
Конечно, интерфейсов на js надо сделать больше, чем программок на си или cuda.
Ну жизнь так устроена, что в любой заданный момент времени всем кажется, что все ниши заняты и никто уже ничего не сделает нового.
Количественные изменения накапливаются... а потом - бам! - и AMD снова на коне. Рр-р-р-р-раз! - и вычисления из CPU переезжает в GPU.
Впрочем это все скучная болтовня. На практике Эльбрус никакой не новый, а история его подхода уже лет 30 как с переменным успехом тянется, и успехов у МЦСТ хватает, что бы там не говорили сторонники глобализма в микроэлектронике.
Так там Бабаян поясняет, почему Itanium не взлетел — потому что мог в параллель выполнять лишь 6 команд
Бабаян там явным образом говорит о несостоятельности VLIW подхода, фразой "Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…"
Дальше итаниум он приводит как ещё одно подтверждение, что даже у конкурентов не вышло. Не надо вырывать фразы из контекста, иначе смысл их теряется.
Вы говорите о том, что не стоит вырывать слова из контекста, но Бабаян там прежде говорит о несостоятельности суперскалярности — а автор статьи именно суперскалярность указывает как правильную альтернативу VLIW. Так что если не вырывать из контекста, то нужно все три полюса дать — и что суперскалярность плохо, поскольку лишь 6 команд в такт, и что VLIW плохо, потому что статическое планирование, а хорошо — полностью параллельный процессор с параллельным языком программирования.
но Бабаян там прежде говорит о несостоятельности суперскалярности
Только это уже не контекст (контекстом конкретной фразы является мнение про VLIW, суперскаляр выпадает из него, также как выпадают идеи куда двигаться дальше), но так да, он там рассказывает свое мнение. Конкретно важный в рамках всего спора вокруг МЦСТ момент в том, что Бабаян разочаровался в VLIW (как в реализации Эльбруса, так и в реализации Itanium).
Бабаян там явным образом говорит о несостоятельности VLIW подхода,
фразой "Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…"
Под несостоятельностью "VLIW подхода" он имеет в виду сугубо статичность аппаратуры, это даже не в плане in-order vs out-of-order, а в плане того что как сейчас в эльбрусе все шесть практически универсальных ALC вынуждены вставать на ожиданиях данных или чего то еще дружной командой, синхронно, потому что широкие команды подразумевают такую синхронизацию - вот это он называет под минусом широкой команды.
Но прошу обращаю внимание именно широкую команду он считает плохой а не эльбрус. Вот что он предлагает сейчас: динамические стрендыпо сути те же ALC и каждый стренд в своем кластере с дубликатом регистрового файла (привет эльбрус). Строгое in-order исполнение, никакого бранчпредиктора, код для стрендов готовит компилятор, контекстная безопасность (аkа "Безопасный режим"). Все по сути то же самое, все все что в каком то виде уже было в эльбрусах 1-2-3 - вот тебе развитие, никакого тупика в развитии родных идей Бабаян не видит.
Но прошу обращаю внимание именно широкую команду он считает плохой а не эльбрус
Вы так говорите как будто Эльбрус не широкая команда. Перечитайте еще раз что конкретно написано, там банально исходя из правил русского языка негативно высказано и про Эльбрус в частности и про VLIW в целом. Если хотите с этим поспорить - говорите об этом с Бабаяном.
Но прошу обращаю внимание именно широкую команду он считает плохой а не эльбрус. Вот что он предлагает сейчас
убил почти два часа, послушал лекцию. ни одного слова в поддержку vliw там не нашёл.
Все по сути то же самое, все все что в каком то виде уже было в эльбрусах 1-2-3 — вот тебе развитие, никакого тупика в развитии родных идей Бабаян не видит.
и какое это имеет отношение к сегодняшнему эльбрусу?
Статьи любопытные пишете, вот еще бы убрать переходы на личности…
Дабы не превращать дискуссию в формат форумной перепалки, я попытаюсь структурировать изложенные возражения, максимально опустив малозначимые на мой взляд детали и не относящиеся к делу реплики. Также мы оставим на совести Алексея некорректные высказывания и переходы на личности. Это мишура, которая не поможет нам глубже понять суть проблемы.
Зачем тут все это? Речь о процессорах или задача натыкать оппонента носом? А смысл? Даже если написать, что Земля круглая, найдутся несогласные - проверено :) - только какой смысл с ними спорить.
Я не смог удержаться в паре мест от шпилек, виноват. Но с другой стороны, Алексей местами такое пишет, что волосы немного дыбом становятся.
На мой взгляд, тактовая частота процессора в последние годы превращается в такую же уловку маркетологов, как мегапиксели и 50-кратный зум в цифровых фотоаппаратах. Производительность процессора определяется тем, сколько команд он может выполнить за один так. Если МЦСТ удастся разработать более производительную архитектуру, то она может сгладить или вовсе нивелировать отставание в тактовой частоте. За примерами далеко ходить не надо - Apple выпустила свой процессор A1, который при более низкой частоте, чем у Интел, достиг сравнимой и даже местами большей производительностью, по крайней мере, в синтетических тестах.
Почитайте внимательно статью. В том-то и дело, что Эльбрусу не удается даже выполнить больше инструкций за такт, по сравнению с CISC процессорами.
Так главный вывод данной статьи как раз в том, что архитектура Эльбрус проигрывает по производительности в 3-4 раза своим RISC/CISC конкурентам.
Слежу за дискуссией с вашей первой статьи, но вынужден обратить ваше внимание, на то, что вы делаете суждение без описания условий. Метод научного спора так не работает.
Я скажу, что Мерседес быстрее УАЗ, а мне предложат продемонстрировать это в болотах под Нижним, где Мерседес даже с дороги не сможет съехать.
Еще пример: Маск о том, что давление в камере сгорания двигателя Рэптор выше, чем у РД-180, т.е. они превзошли РДшки. Но Лавочки уточнил, что Маск сравниваем давление в совершенно разных по типу топлива двигателях и сравнение не корректно. Еще пример: нет никакого смысла говорить что дизельный двигатель лучше, только потому что там компрессия выше.
Описанное вами может быть правдой применительно к конкретным условиям. Нельзя заявлять, что "Эльбрус проигрывает в 3-4 раза" не указав названия конкурентов с идентичным тех процессом, схожей сферой применения (т.е. какие задачи должно решать устройство) и набор тестов, в котором вы сравниваете.
Ваши заявления носят именно такой характер, это не самый продуктивный спор.
Нельзя заявлять, что «Эльбрус проигрывает в 3-4 раза» не указав названия конкурентов с идентичным тех процессом, схожей сферой применения (т.е. какие задачи должно решать устройство) и набор тестов, в котором вы сравниваете.Так вот же в статье, от слов «Как говорится, вместо тысячи слов – дайте код» идет подробное описание условий тестов.
А в ответной статье идет опровержение, причем на более прикладном (привязанном к целевой задаче уровне). Это называется диалог, понимаете? Нельзя вбрасывать фразу без контекста - это теряет смысл. "Водород лучше кислорода!" - эта фраза не имеет смысла, т.к. в дыхательном процессе именно кислород выступает окислителем (забирает электрон с митохондрий) и без него никак, а самый распространенный элемент во вселенной - это водород. Я обращаю ваше внимание на то, что приводя любую гипотезу - нужно давать контекст. Иначе с равным успехом можно заявить, что Apple m1 полная ерунда по сравнению с Эльбрусом, т.к. плохо считает математику.
Без проблем! Эльбрус намного медленнее во всех условиях, с которыми сталкиваются обычные корпоративные и индивидуальные потребители. Вот и всё.
Потенциально (всего лишь теоретически) Эльбрус лучше в некоторых математических вычислениях, то есть в очень нишевой зоне, которую, я уверен, никогда коммерчески не монетизируешь. Госзаказ, конечно, спасёт, но обычным клиентам Эльбрус не нужен и даже вреден, потому что - опять же - у него другая архитектура. Точка
Эльбрус лучше в некоторых математических вычислениях, то есть в очень нишевой зоне
Даже в таких зонах будет напрашиваться сравнение с различными ускорителями и другими системами, рассчитанными на эти задачи.
в некоторых математических вычислениях, то есть в очень нишевой зоне, которую, я уверен, никогда коммерчески не монетизируешь.Оно прекрасно монетизируется, DSP процессоров пруд пруди. Но душа требует свершений, а не скучной обработки видео.
Только фишка в том, что Эльбрус - это не процессор для корпоративных и индивидуальных потребителей. Его пробуют протащить в эту нишу, но Эльбрус, в первую очередь нужен военным, чтобы ставить в умное оружие. А там основные задачи как раз математические, да ещё и такие под которые Эльбрус специально проектировался.
Статья, конечно, интересная, но Эльбрусы проектировались не для того, чтобы пузырьком сортировать, а для рассчётов траекторий, обработки сигналов радаров и для всякого такого. И они с этим задачами прекрасно справляются.
Да, наверное, на широкий рынок Эльбрусы тащить не особо разумно. Но с другой стороны, у многих организаций просто нет выбора. Да, Эльбрус будет считать в несколько раз медленней x86, но это, всё равно, в миллион раз быстрее человека, и всё равно, это нужно в производстве. Ну, будем ждать рассчёта движения фрезы для станка с ЧПУ не минуту, а 10 минут, и что?
Байкалы нельзя считать конкурентами Эльбрусам, потому что там лицензионные ядра, и условия лицензий могут ограничивать применение в военной сфере или обработке гостайны.
Можно, наверное, запустить программу разработки своего ooo-ядра. Но ooo-процессоры очень (прям ОЧЕНЬ-ОЧЕНЬ) сложные. Их дебажить сложно. Стоимость разработки будет астрономическая. Они небезопасны (meltdown-ы всякие). Есть у них свои недостатки.
Как-то так... Сырая производительность не всегда является основным критерием при принятии решений. Автомобильный рынок, кстати, хорошая метафора. На нём востребованы не только Порше да Лэнд Крузеры, на Ниву тоже есть большой спрос. Не, конечно, в Ниве можно найти уйму недостатков, но машина позволяет решать людям их задачи. Так чего ещё надо?
К процессорам тоже, мне кажется, надо как-то проще относиться. Если Эльбрус решает задачи заказчиков, так и прекрасно, пусть решает. На этом всём спросе от заказчиков растут специалисты, устанавливаются кооперационные связи (не ядром единым же жив процессор), накапливаются компетенции и опыт. Это всё нужно и полезно.
Я не очень понимаю, в чём тут проблема? Государство хочет снизить свою зависимость от иностранных компаний. И это одно из тех немногих начинаний правительства РФ, которые народ горячо поддерживает. Собственно, на текущий момент ничего, кроме Эльбруса, не может решить эту задачу. Да, архитектура не самая лучшая, да, производительность не на всех задачах выдающаяся, но задачи решать можно, и это главное в текущий момент.
Стратегически верным решением было бы не лишение МЦСТ финансирования, а финансирование разработчиков альтернативных архитектур, потому что они без госзаказа тоже не конкурентоспособны на рынке. Ну, и за это финансирование требовать открытости и публичности.
У нас же наблюдается, и не только в государстве, а вообще в умах обывателей, странное желание сложить все яйца исключительно в одну корзину. Либо Эльбрус, либо не Эльбрус (вместо Эльбруса можно поставить любую другую архитектуру процессора, модель смартфона, операционную систему или язык программирования), третьего не дано. В итоге, вместо того, чтобы выступать перед государством единым фронтом, разработчики тратят силы на грызню друг с другом. Это путь в никуда и постоянную зависимость от внешнего рефери: раз сами не можем договориться, то придётся брать чужое решение. Возможно, именно это произошло в СССР, когда было принято решение клонировать западную микроэлектронику и отказаться от собственных разработок.
Простите, какой народ это поддерживает? Есть польза для страны, а польза для народа и к сожалению то что делается для пользы страны как правило оказывается во вред народу. Увы, я ставлю личное выше общественного.
Насчет пользы для страны тут тоже можно спорить.
И чем вредит народу разработка Эльбрусов? Тем, что создаёт площадку для образования и развития соответствующих компетенций у инженеров? Процессор - это, ведь, не только собственно микроархитектура ядра, это ещё и дофига производственных, образовательных и исследовательских процессов, которые имеет смысл поддерживать, если мы хотим давать каждой конкретной личности из народа больше вариантов развития.
Процессор — это, ведь, не только собственно микроархитектура ядра, это ещё и дофига производственных, образовательных и исследовательских процессовВ России в активной разработке находится больше десяти линеек микропроцессоров и микроконтроллеров. Чем МЦСТ лучше других? Только более хайповой задачей?
Но господдержки не хватает на всех, и давая деньги МЦСТ вместо, скажем, разработчиков навигационных чипов, автоэлектроники или силовых транзисторов на сложных полупроводниках, Минпромторг приносит больше вреда, чем пользы.
Вообще-то МЦСТ как раз и обвиняет Минпромторг в закапывании Эльбрусов и ориентации на лоббистов от крупного капитала.
Эльбрусы или другие процессоры, производимые в стране и, желательно, на основе контролируемой архитектуры и микроархитектуры нужны не для повсеместного внедрения а только в критически важных областях, где информационная безопасность и гарантированная работоспособность важнее, чем некоторый проигрыш в производительности.
Однако, новое постановление правительства, подготовленное Минпромторгом вводит весьма слабые критерии (т.н. балльную систему) того, что считать российским - и вот уже компы Аквариус на Intel 10-го поколения волне себе российские. При прочих равных (соответствие ограничениям и ТЗ на закупку), контракт на госзакупки получает тот, кто предложит меньшую цену. Ну а поскольку сборочное и перемаркировочное производство существенно дешевле, оно и получает преимущество.
Кстати, по поводу постановления есть вопрос: кто знает - теперь простой ноутбук/монитор в школу по госзакупкам будет не купить? Если это так, то получаем дополнительный рынок для пересборки.
Собственно, на текущий момент ничего, кроме Эльбруса, не может решить эту задачуЭто не так. Прямо сегодня для персоналок есть Байкалы. Прямо сегодня в больших количествах используются для обработки видео чипы Элвиса. Прямо сейчас есть промышленные приборы на чипах Миландра, НИИЭТ, НИИМА, НИИСИ.
У нас же наблюдается, и не только в государстве, а вообще в умах обывателей, странное желание сложить все яйца исключительно в одну корзину.Оно наблюдается в основном в умах фанатов Эльбруса, поминутно, как вы выше, объявляющих МЦСТ единственными спасителями отечества и игнорирующих при этом всю остальную российскую микроэлектронику. А самые сильные конкурентные стороны российской микроэлектроники — вовсе не микропроцессоры.
В итоге, вместо того, чтобы выступать перед государством единым фронтом, разработчики тратят силы на грызню друг с другомПотому что государственных денег на всех не хватает.
Это не так. Прямо сегодня для персоналок есть Байкалы. Прямо сегодня в больших количествах используются для обработки видео чипы Элвиса. Прямо сейчас есть промышленные приборы на чипах Миландра, НИИЭТ, НИИМА, НИИСИ.
Прямо сейчас оборонке и некоторым госкорпорациям нужны процессоры для проведения инженерных и физических рассчётов. Эльбрусы им нужны, в первую очередь, именно для этого. Можно из чипов Элвиса собрать кластер для расчётов методом конечных элементов? Из процессоров Миландра можно? Я не знаю ответа, я спрашиваю. Я знаю, что из E2K кластеры собирают и успешно на них считают. Из Байаклов, наверное, теоретически, можно их собирать, но я не видел таких решений. А на Эльбрусах они есть.
Потому что государственных денег на всех не хватает.
Так поэтому надо объединяться и трясти больше денег, потому что деньги у государства есть и много (посмотрите на статистику по неиспользуемым остаткам бюджета), желания вкладывать их в дело - нет. А от грызни за те крохи, что предлагаются сейчас, никакой пользы не будет. Во всём мире именно так корпорации пилят бюджеты, почему мы должны быть святее Папы Римского?
Прямо сейчас оборонке и некоторым госкорпорациям нужны процессоры для проведения инженерных и физических рассчётовИ им на самом деле прекрасно подходят чипы Intel и IBM, а Эльбрусы им навязывают. Не то, чтобы это было плохо, но не надо путать причину и следствие.
Я не знаю ответа, я спрашиваюТак может быть, перед тем, как утверждать, что Эльбрусу в России нет альтернатив, стоит уточнить актуальный статус этих альтернатив? А то в реальности получится, что главное преимущество Эльбруса — хороший пиар.
Так поэтому надо объединяться и трясти больше денегВсе очень хорошо знают ответ на вопрос «что делать?», мало кто готов говорить о том, «кто виноват?»
Приходите работать в любую из сотни российских микроэлектронных компаний менеджером по GR и начинайте трясти у государства больше денег. Я пробовал, получается обычно не очень)
Да никто им ничего не навязывает. Они просто купить не могут чипы IBM и Intel. Санкции США работают. Нужны очень хитрые схемы, чтобы добыть это оборудование. При чём США постоянно обрубает каналы поставки и выписывает огромные штрафы и тюремные сроки посредникам. Вспомните недавний скандал с Т-Платформой. Эти процессоры IBM и Intel достаются по высокой цене, не только денежной. Выгоднее, безопаснее и надёжнее иметь собственное решение.
Навязывают другим госструктурам.
Государство хочет снизить свою зависимость от иностранных компаний
Завязывая производство на тайваньскую TSMC?
А есть другие варианты? Вы рассуждаете как-то идеалистически. У государства есть конкретная возможность часть бюджета на информационные технологии отдать местным разработчикам, тем самым поддержать развитие микроэлектроники в стране. Это лучше, чем ничего.
- аргумент
- опровержение
- ну и что?
не конструктивно получается.
тем самым поддержать развитие микроэлектроники в стране
А разве у нас только МЦСТ делает микроэлектронику?
На самом деле я не вижу ничего плохого в производстве чего-либо на мощностях любых компаний, но меня печалит, что это:
- называют импортозамещением (тем самым снижением зависимости)
- тратят мои налоги на бесполезную дорогую игрушку
а для рассчётов траекторий, обработки сигналов радаров и для всякого такого
Но это совершенно не означает что он в этом хорош :) Более того, Тогда, когда он для этого проектировался, возможно это так и было, но уж точно не сейчас.
Да, Эльбрус будет считать в несколько раз медленней x86, но это, всё равно, в миллион раз быстрее человека
У нас сейчас стоит выбор или Эльбрус или на счетах ?
Байкалы нельзя считать конкурентами Эльбрусам, потому что там лицензионные ядра, и условия лицензий могут ограничивать применение в военной сфере или обработке гостайны.
Интересная конструкция - строить Утверждение, на предположении.
на Ниву тоже есть большой спрос. Не, конечно, в Ниве можно найти уйму недостатков, но машина позволяет решать людям их задачи. Так чего ещё надо?
Только вот за Ниву не просят как за Лендкрузер 300, только по этому он имеет покупателя. Давайте, продайте Ниву за 12 лямов, я на вас посмотрю.....
Хотя постойте, можно же принять закон и запретить продавать внедорожники кроме Нивы, и тогда можно будет из за 12 продать....
Не это ли нам предлагают на рынке процессоров ?
Но это совершенно не означает что он в этом хорош :) Более того, Тогда, когда он для этого проектировался, возможно это так и было, но уж точно не сейчас.
Он достаточно для этого хорош. Он решает боевые задачи. Можно ли решать боевые задачи лучше? Лично я не знаю. Я не знаю, какие требования к ним предъявляют. Может быть, там нужна абсолютная предсказуемость времени обработки сигнала, жёсткое реальное время, тогда все out-of-order решения автоматически отпадают.
У нас сейчас стоит выбор или Эльбрус или на счетах ?
Перед некоторыми организациями стоит именно такой выбор. Или все уже забыли историю с Иранской ядерной программой и Stuxnet?
Только вот за Ниву не просят как за Лендкрузер 300 ...
Я имел в виду, что требования у заказчиков к продуктам могут быть совершенно разные. Кроме того, не известно, сколько будет стоить OoOE-процессор отечественной разработки. Это очень дорогое удовольствие по транзисторному бюджету.
На логарифмической линейке перечисленные вами задачи тоже решаются - раз вам все равно, что считать долго, почему же вы с компьютера в интернете сидите, а не траектории на линейке сейчас считаете? А я лучше на нормальном интеле или амд интерферограммы спутниковые посчитаю, это терабайты и десятки терабайт данных обработать требует, вы с линейкой или эльбрусом можете и не начинать… Военным, кстати, интерферограммы тоже нужны - это и рельеф, и устойчивость территорий, и всякие скрытые сооружения найти можно.
Надеюсь, Вы просто передёрнули по привычке, а не всерьёз считаете, что задачи, которые можно решать на Эльбрусе, можно решать и на логарифмической линейке. Как нам в статье показывают, разница в производительности между Эльбрусом и процессором от Intel не на десятки порядков, а всего лишь в разы. И это терпимая разница для многих приложений. Кроме того, я думаю, что как раз на задачах обработки сигналов Эльбрус будет выигрывать у Intel. Во-первых, Эльбрус именно под такие задачи и проектировался, и для него написаны вручную оптимизированные библиотеки математических функций, выполняющиеся с полной загрузкой ФУ. Да и есть мировой опыт, самые быстрые DSP - это именно VLIW-процессоры.
Это вы передергиваете - пока вам не напишут интерферометрический пакет, вам будет все едино, что эльбрус, что счеты. Вы код хоть одного продукта для разворачивания интерферометрической фазы видели? Вот попробуйте для них написать под эльбрус «вручную оптимизированные библиотеки математических функций, выполняющиеся с полной загрузкой ФУ», прежде чем утверждать, что это плевое дело. Там итерационные растровые алгоритмы, это вам не быстрое преобразование фурье написать. А я, знаете, ни одного подобного пакета с поддержкой эльбрусов не видел.
Кроме того, я думаю, что как раз на задачах обработки сигналов Эльбрус будет выигрывать у Intel.
У Интела-то выиграет, а у вот у других DSP — интересно было бы посмотреть на сравнение.
го пробуют протащить в эту нишу, но Эльбрус, в первую очередь нужен военным, чтобы ставить в умное оружие. А там основные задачи как раз математические, да ещё и такие под которые Эльбрус специально проектировался.Для этих математических задач у военных есть комдив-128, элкор и нейроматрикс. Все они, что характерно, сопроцессоры в гетерогенных СнК с «обычным» управляющим ядром. А вот с подтвержденными случаями использования процессоров «Эльбрус» в ВПК, кажется, напряженка. SPARC от МЦСТ — да, но то SPARC.
Байкалы нельзя считать конкурентами Эльбрусам, потому что там лицензионные ядра, и условия лицензий могут ограничивать применение в военной сфере или обработке гостайны.У Байкалов и Эльбрусов примерно одни и те же покупные периферийные блоки с одинаковыми лицензиями. Наверняка, кстати, ограничивающими применение в военной сфере. Так что тут никакой разницы нет.
Можно ли на Комдив-128, Элкор или НейроМатрикс запустить Linux или Windows? Насколько я понимаю, это всё системы типа микроконтроллеров. Наверное, их можно поставить на "изделие" для выполнения полётной программы, но для подготовки полётных заданий нужны совсем другие вычислительные мощности.
Я не очень понимаю, какое подтверждение Вам нужно. Но могу посоветовать посетить НСКФ, там показывают технику, в которой стоят Эльбрусы 2k.
У Байкалов и Эльбрусов примерно одни и те же покупные периферийные блоки с одинаковыми лицензиями. Наверняка, кстати, ограничивающими применение в военной сфере. Так что тут никакой разницы нет.
А можно об этом подробнее? Про Байкалы я знаю, что таков стратегический план развития: лицензировать всё и по максимуму, чтобы как можно скорее выйти на рынок потребительского оборудования, вроде информационных киосков, терминалов оплаты или планшетов для школьников. С Эльбрусами, вроде, стратегия противоположная, и, насколько я понял (могу ошибаться) из докладов и разговоров, контроллеры памяти они сами разрабатывали.
Можно ли на Комдив-128, Элкор или НейроМатрикс запустить LinuxДа, на всех трёх. А также ОС реального времени.
Насколько я понимаю, это всё системы типа микроконтроллеров.Вы неправильно понимаете. Это системы типа мощных многоядерных процессоров для обработки больших массивов информации.
для подготовки полётных заданий нужны совсем другие вычислительные мощностиВы просто не понимаете, о чем говорите, и на каких процессорах на самом деле «готовятся полётные задания».
А можно об этом подробнее? Про Байкалы я знаю,Можно. Цитирую статью «Реализация каналов оперативной памяти DDR4 микропроцессора „Эльбрус-8С2“ за авторством Юрлина С В., опубликованную на конференции МЭС в 2016 году:
В кристалле микропроцессора „Эльбрус-8С2“ используется физический уровень DDR4 multiPHY фирмы Synopsys.
Файл статьи доступен в proceedings конференции, все желающие могут проверить самостоятельно. Поэтому, повторюсь, с точки зрения защиты от санкций преимуществ у Эльбруса ровно ноль. Просто в МЦСТ не очень любят говорить на эту тему, потому что она ломает их импортозаместительную риторику, а в Байкале к этому относятся спокойно, потому что это часть их стратегии.
Извините что вмешиваюсь, но физический уровень это по сути аналоговая часть контроллера памяти, он очень специфичен для конкретного тех. процесса и фабрики. Разрабатывать его самим было бы совершенно безумной идеей, по сложности и стоимости сопоставимой с разработкой самого процессора. Тем более что МЦСТ никогда не занимались аналоговым дизайном. Цифровая часть контороллера памяти это собственная разработка. И в целом когда говорится о том что в эльбрусе стоят иностранные IP блоки это чаще всего относится к именно к физ. уровню. Если мне не изменяет память, то в первом КПИ было покупные PCIE, USB и SATA, но вроде бы их потом заменили на блоки собственной разработки (исключая физ. уровень естественно).
Разрабатывать его самим было бы совершенно безумной идеейА тогда нечего говорить про безопасность, отсутствие закладок и преимущества над пользователями лицензионных архитектур, если все общение с памятью идет через американский хардмакро, о внутренностях которого МЦСТ не имеет ни малейшего понятия.
Разрабатывать его самим было бы совершенно безумной идеей, по сложности и стоимости сопоставимой с разработкой самого процессора.Другие российские разработчики делают физуровень DDR. Я например его делал десять лет назад. Не DDR4 конечно, но и не вчера.
Можно было бы заказать дизайн физуровней в России, а не купить у Синопсиса. А так получается, что на словах все Лев Толстой, а когда за эти слова надо отвечать, получается «было бы совершенно безумной идеей».
Какие российские разработчики микропроцессоров сами делают физуровень DDR4? Подозреваю что никакие. Может они еще и компиляторы памяти для своих микропроцессоров пишут? Эльбрус в плане иностранного IP содержит разумный минимум. Была бы фабрика на Микроне - и этого бы не было. Если сравнивать с Байкалом - кроме тех же памятей и физуровня будет ещё и ядро. И если физ. уровень ещё теоретически можно проверить на безопасность, то ядро - увы.
Какие российские разработчики микропроцессоров сами делают физуровень DDR4?DDR3 делают. Будет задача сделать DDR4 и деньги на ее решение — можно будет сделать DDR4.
Может они еще и компиляторы памяти для своих микропроцессоров пишут?Компиляторы памяти пишут сами и продают другим российским компаниям как минимум НИИСИ и Альфачип. Причем при необходимости — существенно более сложные компиляторы радстойкой памяти. Российские разработчики вооьзе очень много всякого интересного умеют.
. И если физ. уровень ещё теоретически можно проверить на безопасность, то ядро — увы.Проверить физуровень DDR4 на безопасность ничуть не проще, чем процессорное ядро. А может даже и сложнее, потому что он, в отличие от процессора, умеет взаимодействовать с аналоговым сигналами.
Это совершенно разные компетенции - аналоговый дизайн и разработка микропроцессоров. За много денег можно что угодно сделать, это я понимаю, можно и в МЦСТ отдел аналогового дизайна оганизовать, но зачем? Кстати кто делает DDR3 вы так и не сказали.
Альфа-Чип это Моторола, потом Фрискейл, потом ON Semi, так что российский он с большой натяжкой. А НИИСИ для TSMC-шного техпроцесса компиляторы делает 7nm? И как там с плотностью?
В физуровне сильно меньше транзисторов и они больше по размерам. Хотя признаюсь что в поиске закладок в физуровнях я не специалист. Физ. уровни всё равно все покупают.
Физ. уровни всё равно все покупают.«Все так делают» и «сложно и дорого» — не ответ.
Всем сложно и дорого, однако у других российских компаний (например, у НИИСИ и Элвиса) хватает денег и желания делать все части чипа самостоятельно в тех проектах, где это нужно.
А одновременно покупать хардмакро в США и говорить про безопасность от закладок — это ничем не прикрытое лицемерие.
Вы так и не привели ни одного конкретного примера продукта, сопоставимого по производительности и проектным нормам с Эльбрусом, разработанного без иностранных IP. Только общие слова про НИИСИ и Элвис. Ну типа у нас есть такие приборы, вот это всё. Причём, заметьте, я нисколько не умаляю заслуг этих уважаемых компаний, но при текущем положении дел с точки зрения замещения импортных IP Эльбрус смотрится довольно достойно. Его проблема уж точно не в этом.
Я говорил о том, что Эльбус с phy от Synopsys ничуть не безопаснее Байкалов и что если в чипе есть хотя бы один американский хардмакро, все остальное его содержимое уже не важно — безопасности от закладок нет.
А вы на это отвечаете «все так делают». Но во-первых, не все так делают, во-вторых, другие, кто так делает, не трубят на всех перекрестках про защищённость от закладок, а в-третьих, безотносительно того, что делают другие, Эльбрус с американскими хардмакро небезопасен. Ваше «смотрится достойно» — это как сорта свежести рыбы или «немножко беременна». Тут абсолютно бинарная ситуация: иностранные IP у вас в чипе или есть, или нет. В Эльбусе они есть.
А в России есть компетенции по разработке недостающих блоков, и если кому-то нужно реальное, а не дутое импортозамещение, то деньги, потраченные на покупку блоков у Synopsys, стоило бы потратить на аналогичную разработку в России. И тогда уже говорить какие-то слова про безопасность и доверенность.
Ну вот смотрите, зайдём с другой стороны. Чисто формально, с точки зрения текущего законодательства, Эльбрус отечественный. Не вижу причин не использовать это в маркетинге. И как бы никто не запрещает тому же Ядру к примеру тоже назвать себя отечественным.
Вашу пуританскую позицию можно доводить до абсурда. Давайте тогда считать отечественным только то, что произведено на отечественном оборудовании, с использованием отечественных компонентов и материалов и т.п. Тут не сорта свежести рыбы, а Ахиллес и черепаха. Можно за ней гоняться бесконечно или в какой-то момент сказать что мы достаточно близко. И меряться кто ближе, кто дальше и в каких случаях что использовать.
Нет, не давайте.
Чисто формально, с точки зрения текущего законодательства, Эльбрус отечественный. Не вижу причин не использовать это в маркетингеС этим не вижу ни единой проблемы. Поддержка отечественного разработчика — это хорошо и правильно. Проблема — в заявлениях о безопасности и защищённости от закладок, которые, мягко скажем, не соответствуют действительности.
И меряться кто ближе, кто дальше и в каких случаях что использовать.Вполне нормальный подход, даже Минпромторг различает отечественные чипы первого и второго класса (произведенные в РФ и за границей). И я, кстати, полностью поддерживаю фаблесс дизайн чипов второго класса и их последующее производство на лучших мировых фабриках — только так можно сохранять и развивать компетенции в разработке.
Но надо адекватно оценивать недостатки такого подхода и таких чипов, не врать о них своим пользователям и уж тем более не озвучивать как преимущества над конкурентами то, что на самом деле преимуществом не является.
Давайте наверное закругляться с этим спором. Ваша позиция касаемо закладок:
Эльбрус ничем не лучше Байкала так как тоже содержит иностранные IP блоки (PHY и памяти).
Моя позиция:
Риски при использовании Эльбруса значительно ниже т.к. ядро самописное и можно провести аудит исходного кода. В случае Байкала очевидно нет. Остальные позиции по IP одинаковые.
Интересный вопрос, искать ответ на который мне лень. Есть подозрение что МЦСТ говорит об отсутствии закладок в ядре, а не в микропроцессоре. В ядре как раз иностранных IP нет.
Есть подозрение что МЦСТ говорит об отсутствии закладок в ядре, а не в микропроцессоре.О нет, МЦСТ говорит именно о том, что в других процессорах закладки могут быть, а у них — не могут. И эта позиция, озвученная, например в недавнем интервью господина Кима, является сознательным обманом, не больше и не меньше. Или, что еще хуже, сознательным самообманом.
Можно сколько угодно говорить про защищенные режимы, разделение памятей и много уровней стеков безопасности, но зачем они все, если вся информация, попадающая во внешнюю память или приходящая из внешней памяти, по пути проходит через черный ящик, о внутреннем устройстве которого вы не имеете никакого представления?
При использовании Эльбруса можно провести аудит исходного кода. В случае Байкала очевидно нет.В случае Байкала вполне можно получить исходный код ядра и провести его аудит. Это исключительно вопрос денег.
В ядре как раз иностранных IP нетУ нашей крепости три стены, которые мы построили сами, поэтому риски проникновения врагов через четвертую стену, которую мы купили прямо у них, значительно ниже, чем у наших соседей, которые купили у врагов две стены, а не одну. Так как мы купили только одну стену, мы чувствуем себя в полной безопасности.
В случае Байкала вполне можно получить исходный код ядра и провести его аудит. Это исключительно вопрос денег.
Нет, нельзя. Если только вы не планируете выкупить Арм со всеми потрохами, но даже в этом случае см. export control. Давайте будем реалистами.
У нашей крепости три стены, которые мы построили сами, поэтому риски проникновения врагов через четвертую стену, которую мы купили прямо у них, значительно ниже, чем у наших соседей, которые купили у врагов две стены, а не одну. Так как мы купили только одну стену, мы чувствуем себя в полной безопасности.
Соседи живут в крепости, построенной врагами. А так да, мы будем чувствовать себя в большей безопасности, а у купленной стены поставим сторожа. Если этот самый PHY умеет подменять данные так чтобы конторольные суммы сходились, тогда лучше сразу сдаться.
Нет, нельзя. Если только вы не планируете выкупить Арм со всеми потрохами
Можете доказать, что нельзя без покупки ARM?
Соседи живут в крепости, построенной врагами. А так да, мы будем чувствовать себя в большей безопасности, а у купленной стены поставим сторожа.
Продолжая такую аналогию - вы всего лишь проектируете помещение, используя уже предоставленный список материалов, притом строят стены тоже внешние подрядчики, да и САПР импортный (делается чип на TSMC, используя их библиотеки и иностранный САПР). Поставленный сторож тоже будет импортным, к слову (как и его будка и ружжо). Можно разве что разобрать здание по кирпичикам и раскрошить кирпичики, но потом надо будет все изучать под микроскопом, чтобы точно убедится что ни на каком этапе не было включено в проект чего-то странного (а то поди докажи что это арматура в стенах, а не хитроумное устройство для ослабления конструкции или подрыва всего здания или что арматура не будет выполнять роль антенны).
Если этот самый PHY умеет подменять данные так чтобы конторольные суммы сходились, тогда лучше сразу сдаться.
Технически что ему помешает так делать?
Нет, нельзя. Если только вы не планируете выкупить Арм со всеми потрохами, но даже в этом случае см. export control. Давайте будем реалистами.Давайте вы будете реалистом и узнаете от меня, что покупка исходного кода ядра — вполне обычная практика, и это стоит разумных денег. В частности, «Миландр» в 2008 назад купил несколько ядер ARM в исходных кодах — ровно для того, чтобы провести его аудит и поставить в продукты двойного назначения.
Соседи живут в крепости, построенной врагами.Нууу, с этой точки зрения Эльбрус тоже на Тайване произведен. А соседи из Байкала просто купили у врагов больше стенок, но собрали их тоже сами.
Если этот самый PHY умеет подменять данные так чтобы конторольные суммы сходились, тогда лучше сразу сдаться.Зачем так? Можно например полностью отключаться навсегда при поступлении определенной комбинации данных.
Давайте вы будете реалистом и узнаете от меня, что покупка исходного кода ядра — вполне обычная практика, и это стоит разумных денег. В частности, «Миландр» в 2008 назад купил несколько ядер ARM в исходных кодах — ровно для того, чтобы провести его аудит и поставить в продукты двойного назначения.
Попробуйте купить что-нибудь более производительное, например большое ядро А класса в исходниках и будете неприятно удивлены. Есть разные уровни экспортного контроля. Да и правила с 2008 года поменялись, сами знаете из-за чего.
Нууу, с этой точки зрения Эльбрус тоже на Тайване произведен. А соседи из Байкала просто купили у врагов больше стенок, но собрали их тоже сами.
Не, они купили сам замок и стены вокруг него и ров. Ну собрали сами, это да. А насчёт производства - если враги имеют такой технический уровень что могут вставить закладку в GDS, да ещё и так чтобы скан-тесты не попортить, да ещё и быстро, то опять же лучше сразу сдаться в связи подавляющим техническим превосходством противника.
Зачем так? Можно например полностью отключаться навсегда при поступлении определенной комбинации данных.
Ну можно, но только это сразу заметят. Можно ЭМ волной весь Эльбрус сжечь, это тоже закладка? Незаметно воровать планы мобилизации из военкомата в Архангельской области и прочую секретную информацию не получится.
Попробуйте купить что-нибудь более производительное, например большое ядро А класса в исходниках и будете неприятно удивлены. Есть разные уровни экспортного контроля. Да и правила с 2008 года поменялись, сами знаете из-за чего.В покупке/продаже больших ядер вы, судя по профилю, понимаете несколько больше меня, так что спорить не буду. Но на ARM мир не заканчивается. Собственно, все разговоры про перспективность RISC-V ведутся ровно для того, чтобы самостоятельно сделать подходящие исходники, совместимые со всем разрабатываемым большим всемирным коммьюнити софтом.
враги имеют такой технический уровень что могут вставить закладку в GDSДавайте так: я вообще не верю в то, что закладки реальны и в частности также, как и вы, не верю в то, что их можно вставить в GDS в процессе приемки оного GDS фабрикой. Но мы сейчас обсуждаем не то, что мы с вами думаем, а патриотическую риторику и лежащие под ней объективные основания или их отсутствие.
Ну можно, но только это сразу заметят.Так это один из самых часто упоминаемых сценариев — «в случае войны американцы просто отключат все импортные чипы в российской военной технике».
Я весьма положительно отношусь к RISC-V в России в контексте последних событий. Но. Надо быть осторожными в своих ожиданиях. Почему-то у многих здесь в комментариях такая мысль проскакивает, что как только мы похороним Эльбрус и сменим его на RISC-V так сразу всё наладится, все магазины будут завалены дешёвыми отечественными процессорами, Интел подвинется и вот это всё. Здесь у меня есть большие сомнения. Я подозреваю что конкурировать Ядро сможет только в нашем российском междусобойчике. Да и Ядро это тоже понимает судя по тёркам с МЦСТ. Кроме того я не вижу причин по которым их продукция могла бы стоить сильно дешевле МЦСТ-шной. Объёмы будут примерно те же т.к. рынок мал. Выход на мировой рынок с конечной продукцией очень сомнителен (впомним как Т-Платформы в свое время попали под санкции, да и репутация у нашей страны так себе). Стоимость разработки будет сравнима с Эльбрусом скорее всего при похожем тех процессе и производительности. Возможно лет через 5-7 отечественный RISC-V обгонит Эльбрус по параметрам, но на такой долгий срок сложно предсказывать. По цене - скорее всего будет стоить слегка дешевле, по доступности - скорее всего будет более доступен. Хотя у Э. конечно есть фора.
В целом касаемо Ядра - история до боли напоминает Байкал. В какой-то момент компания производитель оборудования решает войти на рынок разработки своих собственных микропроцессоров. Добываются деньги - много денег, от роснано ли или от кого ещё. Сманиваются люди из более зрелых компаний, большими зарплатами или обещаниями преспектив. Даётся много обещаний. Дальше начинаются проблемы т.к. микроэлектроника это дорогое удовольствие, сроки постоянно двигаются, контракты срываются, часть инженеров уходит. В результате обещаного прорыва нет. И мы получаем еще одного разработчика российских микропроцессоров. Или не получаем - если денег не хватило.
Я прекрасно знаю ребят которые работают в Байкале (в свое время я отказался от их щедрого предложения, ещё в те времена когда они обитали в районе Юго-Западной кажется). Я прекрасно знаю ребят которые перешли в Ядро сейчас из того же МЦСТ. Я пересекался с бывшими сотрудниками Синтакора. Все отличные инженеры и всё у них получится, но факт в том что у МЦСТ уже есть большой задел в разработке (как бы тут не утверждали обратное) и чтобы конкурировать с ними потребуется два-три поколения микропроцессоров от Ядра т.е. 5-7 лет. И хорошо бы если бы на это хватило денег.
Только фишка в том, что Эльбрус - это не процессор для корпоративных и индивидуальных потребителей.
Это расходится с заявлениями мцст, его изначально позиционировали как убийцу интела.
Эльбрус, в первую очередь нужен военным, чтобы ставить в умное оружие
Есть доказательства? А то в соседних темах жаловались что радстойкий на российских фабриках был сделан один раз и все. Тут ключевой вопрос будет что там с защитой от ЭМИ. Ну и в общем вопрос в каких установках у военных Эльбрус, который не sparc.
Плюс военные получают весь тот же набор проблем что и гражданские. А там возникнет вопрос, а не лучше ли взять решение от Элвиса.
то в соседних темах жаловались что радстойкий на российских фабриках был сделан один раз и все.Он не радстойкий. Радстойких чипов МЦСТ вообще не бывает.
его изначально позиционировали как убийцу интела.
В области импортозащемления он вполне себе убийца интела. Правда, он не всегда может занять место убитого, но это нюансы.
В области импортозащемления он вполне себе убийца интела
Беда в том, что его позиционировали как убийцу интела еще до того, как импортозамещение стало модным. А в той области, уж извините, и комдив на 800 мгц - убийца, так уж она сформирована.
Ну, будем ждать рассчёта движения фрезы для станка с ЧПУ не минуту, а 10 минут
Опять же, это расчёты и матан, здесь вполне может быть и 30 секунд у Эльбруса. Именно в этом случае статический анализ может дать преимущества над динамикой. Простые, хорошо прогнозируемые условия цикла и при этом тело цикла нагружено операциями. А в другом углу ринга — типичные «бизнес-задачи». В той же сортировке вставками нет никаких особых вычислений, по сути всего одна операция сравнения, зато есть много не предсказуемых на этапе компиляции переходов.
Вот и противоречите сами себе: "Эльбрус медленнее во всех" и "Эльбрус лучше".
Давайте рассуждать логически: при разработке архитектуры Эльбрус и построенного на ней одноименного решения Эльбрус были использованы определенные ФТ. ФТ определяют профиль устройства и его целевые показатели. По соответствию ФТ разрабатывается ПИМИ и проходят приемо-сдаточные мероприятия. Именно так (с поправкой на регион рождения) создаются любые устройства, и даже в Intel или nVidia.
Если мы хотим сказать, что Эльбрус не соответствует поставленным изначально ФТ - то давайте так и говорить. И приведем соответствующие тесты, в которых это докажем.
Но если мы хотим сказать, что на Эльбрусе плохо работает мобильный PUBG - то это вопрос либо к тому, кто это портировал, либо к самой идее "Зачем это делать?".
А далее мы приходим к вопросу: "Что для вас - обычный клиент?" Это человек/организация покупающая процессор для какой цели? Ходить в интернет? - Эльбрус вполне потянет браузер на Астра-Линукс. Открыть офисный пакет? Потянет. Запустить 1с? Потянет. Так где же та критичность для "Обычного клиента" о которой вы говорите?
Видите ли, давление это показатель, который непосредственно определяет тягу. При прочих равных, само собой. А тяга это не вторичный показатель, как компрессия у дизеля, а один из основных. Так что само по себе сравнение по этому показателю очень даже корректно, если мы понимаем, что он нам дает, и понимаем, что это не единственный показатель (как это бывает в большинстве случаев сравнения сложных систем).
Вы дали мотивированное возражение - именно это я имел ввиду! Тогда контр-аргумент: а почему товарищ Маск сравнивает тягу Рэптора (новейший двигатель, еще не видевший пусков) с устаревшим РД-180, а не с новым РД-181? Ведь у РД-181 тяга выше Рэптора и РД-181 летает уже 5 лет. Видите? Снова не совсем честное сравнение выходит. Также и в полемике про Эльбрус - сравнивают не по целевым показателям. Это как сравнивать производительность супер-компьютера с RTX3090 в игре Киберпанк, а потом заявить что раз СК проиграл RTX, то СК не нужен.
с устаревшим РД-180, а не с новым РД-181?
Я в двигателях конечно ничего не понимаю, но кажется Вы перепутали РД-180 с чем-то еще. Он слишком отличается и от РД-181 и от Раптора чтобы их напрямую сравнивать (у РД-180 тяга выше в несколько раз, но тяга к массе намного хуже).
Касательно цифр - у РД-181 тяга 2090 кН, у Раптора в тестах 2200 кН.
Про давление в камере - опять же посмотрев на характеристики - скорее всего раптор сравнивают с рд-180 потому что у рд-180 оно выше чем у рд-181, чисто интересный показатель с точки зрения прочности материалов.
Буду признателен если Вы расширите мой кругозор и поясните где ошибка.
Эльбрус - сравнивают не по целевым показателям. Это как сравнивать производительность супер-компьютера с RTX3090 в игре Киберпанк, а потом заявить что раз СК проиграл RTX, то СК не нужен.
Дело в том что Эльбрус рекламируют как убийцу интела и процессор общего назначения еще с момента как его начали проектировать. Это автоматически делает любые прикладные задачи его целевыми задачами. И на практике выясняется что там он себя показывает не очень здорово.
На вопросы о каких-то более целевых задачах - ответов тоже не очень много звучит (полистайте эту тему, вопрос задавался многократно тут, а вот внятных ответов как не было, так и нет)
Из Вики на английском:
Raptor / Performance Thrust ~185 tf (1.81 MN; 410,000 lbf) for Raptor 1
RD-181 / PerformanceThrust (vac.)2.09 MN (470,000 lbf) at 100% throttle
1.81MN против 2.09MN у РД-181
Вы прекрасно проиллюстрировали мой довод, что Эльбрус сравнивали с чем-то совершенно не сопоставимым по задачам или целевым показателям.
И я не разу не слышал рекламу Эльбруса, как "убийцу Интел". Возможно вы путаете с Байкалами? Процессоры Байкал-М действительно сопоставляли с Интел.
P.S. Нашел запись с "Эльбрус Тех Дэй" 2021, где демонстрировали 10х - кратное превосходство над Интел.
https://www.youtube.com/watch?v=19N7QSQ9aE0&ab_channel=MaximGorshenin
Performance Thrust ~185 tf (1.81 MN; 410,000 lbf) for Raptor 1
Вы читайте внимательнее, там есть во первых ссылочки, на твитты заверявшие 225 tf, а также есть внизу табличка где 2200 кН против 2090 кН у РД-181.
Так что читайте пожалуйста внимательнее то, на что ссылаетесь. Ну то есть да, вы кажется нашли опечатку в википедии, это конечно хорошо, но вы можете ее же цифры и проверить, благо для большинства из них указан источник.
Вы прекрасно проиллюстрировали мой довод, что Эльбрус сравнивали с чем-то совершенно не сопоставимым по задачам или целевым показателям.
В каком месте?
Меряться Твитами мистера Маска - это Вы конечно "здорово" (читать - не научно) придумали.
Если позволите, то введу Вас в контекст. У двигателя семейства Raptor (на данный момент не-летавшие прототипы, если не считать "подскока" Стархупер) есть несколько серий.
Серия 1, она же просто Raptor, имеет официальные ТТХ по тяге в 185 тон. Именно эти данные и указаны в Вики в описании устройства. Это не опечатка.
Серия 2, она же Raptor v2.0 - это прототип перспективной версии, которая на стенде показала параметры от 90т до 225т.
В чем отличия? В том, что для двигателя важна тяга выдаваемая на промежутке времени, а не на пиковом значении. В момент отжига двигателя (обязательный процесс поверки каждого двигателя) фиксируется именно этот параметр.
Вы же ссылаетесь на пиковое значение стендового прототипа, которое зафиксировано Твитом мистера Маска.
Со всем уважением к мистеру Маску, но для меня это аргументы уровне "на заборе мелом написано".
Что же касается того, что вы подтвердили мой тезис - это как раз о том, что давление в камере сгорания позволяет судить о прочности камеры, а не тяги двигателя.
На этом дискуссию предлагаю завершить - не хочется обсуждать серьезные вещи на основе Твитов.
Меряться Твитами мистера Маска - это Вы конечно "здорово" (читать - не научно) придумали.
Тут какое дело - SpaceX - публичная компания, мистер Маск отвечает головой перед инвесторами за то что пишет касательно SpaceX и их продуктов. То есть если он соврал в твитте - это может грозить ему лично большим штрафом или уголовкой (вы в соседнем треде правильно упоминали Theranos, там собственно текущие суды над основателями идут, упрощенно, за введение инвесторов в заблуждение). Поэтому не понимаю почему это не может являться надежным источником информации.
Серия 1, она же просто Raptor, имеет официальные ТТХ по тяге в 185 тон. Именно эти данные и указаны в Вики в описании устройства. Это не опечатка.
Вы сослались на википедию. Википедия пишет про 185 тс ссылаясь на твитт маска, заявляющий "225 тс".
Если есть более официальное место - можете просто на него дать ссылку и поправить википедию (указав корректный источник и/или исправив цифру).
Вы же ссылаетесь на пиковое значение стендового прототипа, которое зафиксировано Твитом мистера Маска.
А где в его твитте это написано?
Более того - как понять на какое значение ссылается табличка про РД-181? (вопрос совсем серьезный, потому что на википедии пруф-линки дохлые)
Ну вот, вы снова подменяете понятия. Мистер Маск не отвечает головой. Фактически за публичную ложь он отвечает только своим постом в компании и вероятными штрафом. Именно так было в истории, когда он спровоцировал рост акций Теслы заявлением "Tesla Go-Private". Капиталисты врали, врут и будут врать. В капиталистической системе продаются "обещания", а не реальность. Так устроена система.
Я сослался на Википедию, а на Твит сослались вы. Я вам уточнил контекст, в котором нужно читать Твиты, исключительно в целях вашего информирования.
На что ссылается табличка РД-181(193) я вам обязательно найду. Но не сейчас.
Фактически за публичную ложь он отвечает только своим постом в компании и вероятными штрафом
Зависит от масштаба лжи, вплоть до уголовного преследования.
Я сослался на Википедию, а на Твит сослались вы.
Вы сослались на табличку на вики, которая ссылается на твитт, я лишь прошёл по ссылке проверить правильность данных.
Более того, я уже указал ранее ссылкой, что на той же странице есть вторая табличка где значения другие. Вы её проигнорировали.
Я вам уточнил контекст, в котором нужно читать Твиты, исключительно в целях вашего информирования.
Извините, но я не вижу причин доверять вашим заявлениям, так как я уже указал вам на несоответствия в вашем же источнике информации.
Вы точно умеете работать с источниками?
Ловите выдержку из цитируемого научного источника о ТТХ РД181:
https://www.elibrary.ru/download/elibrary_26239199_97622506.pdf
Искренне надеюсь на обретение вами адекватности в ведении диалога. Всех благ.
SpaceX — публичная компания
Нет, она лично Маска. Акции нигде не торгуются.
Я почему-то думал что торгуется. В общем принципиально картины не меняет - есть инвестеры кроме Маска, за распространение ложных сведений будет ответственность как перед инвестерами, так и вплоть до уголовной.
за распространение ложных сведений будет ответственность как перед инвестерами
А какая связь между твиттером и инвесторами? В частных компаниях владельцы информацию не из Интернета получают, а, к примеру, через отчеты назначенных директоров.
И раз уж мы об этом говорим, то проведу небольшой ликбез. К торгуемым на биржах компаниям применяются свои правила. Такие компании обязаны периодическои публиковать определенного формата отчеты, которые и должны соответствовать каким-то требованиям. В твиты эти отчеты, очевидно, не поместятся.
А какая связь между твиттером и инвесторами? В частных компаниях владельцы информацию не из Интернета получают, а, к примеру, через отчеты назначенных директоров.
Небольшой ликбез - когда C-level пишет или говорит что-то публично это считается авторитетным заявлением и за ложь в них он несет такую же ответственность как за ложь в официальной отчетности. На самом деле не только про C-level речь, но чем ниже должность и вовлеченность человека в бизнес, тем больше свободы в высказываниях позволяется. У Маска, как основателя, свободы в высказывании таких вещей самый минимум, иначе есть неиллюзорный шанс повторить судьбу Теранос в будущем, если вдруг на практике это не реализуется.
И раз уж мы об этом говорим, то проведу небольшой ликбез. К торгуемым на биржах компаниям применяются свои правила.
И опять же за определенные публичные высказывания торгуемой на бирже компании тоже могут настучать по шапке, там это чуть проще, так как показать связь с манипуляцией ценой на акции чуть проще, чем доказать введение инвесторов в заблуждение. Но разница не принципиальная.
когда C-level пишет или говорит что-то публично это считается авторитетным заявлением и за ложь в них он несет такую же ответственность как за ложь в официальной отчетности
Я просто хочу указать, что в публичных компаниях есть документы, к которым выдвигаются жесткие требования. Например, как здесь https://ir.bumble.com/. Это прогнозы, status quo, ретроспектива и так далее. Аналогичные сайты есть у других компаний. Конечно же, директор в такой компании должен вести себя соответственным образом.
Это нужно, чтобы информировать потенциальных держателей акций о ситуации в компании.
А вот закрытые компании таких документов не публикуют, а их владельцы делают в определенных рамках что хотят. Можно, конечно, подать на CEO в суд (а в Штатах вообще можно подавать в суд по поводу и без), но вероятность последствий тут небольшая - и у Маска их особо не было.
Я просто хочу указать, что в публичных компаниях есть документы, к которым выдвигаются жесткие требования.
Само собой, это достаточно очевидная вещь.
Конечно же, директор в такой компании должен вести себя соответственным образом.
А вот тут уже не совсем очевидный момент - директор должен вести себя соответствующим образом даже не в публичной компании. Я повторюсь уже в который раз - даже если компания закрытая, но директор соврал в публичном заявлении - он может понести ответственность за это, вплоть до уголовной. Это будет сложнее доказать, чем манипуляцию цен на акции, но вполне возможно, особенно если события повторяются периодически. Собственно когда CEO публикует такие цифры у себя в твиттере, скорее всего он видел бумажку где эти цифры были продемонстрированы, это достаточно разумное предположение, если конечно человек не мазохист и не хочет в будущем слегка присесть.
А почему только в последние годы?
Интел сами это уже проходили во времена пентиума 4 и особенно прескотта. Там частоты уже вплотную подбирались к 4 ГГц. Потом был сильный откат по частоте, когда перешли к архитектуре кор. Кор была и быстрее и куда холоднее.
У амд тоже всегда в те времена частоты были очень маленькие, поэтому они ввели рейтинг процессора. Какой нибудь амд атлон 64 с частотой 1800 МГц имел индекс атлон 64 3000 и был на уровне или быстрее пентиума 4 с реальной частотой 3000.
Архитектура NetBurst с лозунгом «покупают мегагерцы» смотрит на этот коммент назидательно!
UPD. Надо обновлять комменты перед написанием. Особенно если отходил на полдня…
Производительность данного теста упирается в скорость работы самих дисков, их микроконтроллеров и подсистемы памяти процессора. Реальная вычислительная производительность процессорного ядра там неважна
Это не совсем так, производительность процессорного ядра имеет значение, т.к. тестируются синдромные рэйды (в данном случае 6й рэйд) и производительность процессорного ядра влияет на расчет синдромов.
На мой взгляд, использование производительности SDS в качестве примера производительности эльбруса несколько нерелевантно, хотя бы тем, что в случае sds код вручную векторизован и оптмизирован под этот самый эльбрус.
И везде видно, что VLIW решения всегда своим конкурентам уступают по частоте. И у этого есть вполне определённая причина – особенности архитектуры у VLIW-процессоров. А конкретно для Алексея вопрос можно переформулировать следующим образом – почему Эльбрус(e2k), который постоянно выставляется как главный процессор от МЦСТ и в который вкладываются основные разработческие ресурсы, уступает по частоте процессорам линейки Sparc от МЦСТ, в которые всегда вкладывались намного меньше? Т.е. дело не деньгах и нанометрах, а в принципиальных ограничениях VLIW-архитектур.
А если спидометр у одной машины размечен в милях в час, а у другой в км/ч, это значит что первая машина впринципе не может ехать так же быстро как вторая? Вы говорите о принципиальной разнице в архитектурах процессоров, но при этом предлагаете сравнивать тактовые частоты - как-то странно выглядит.
Нет, это сравнение одних и тех же км/ч, но в одном случае это речное судно, а во втором автомобиль. Сделать автомобиль ездящий на скорости 100 км/ч значительно проще чем аналогичное судно. Да, на судно можно загрузить больше груза тем самым скомпенсировав его меньшую скорость (числодробительные задачи по типу БПФ), но большую часть времени пользователям достаточно багажника (код с сильными внутренними зависимостями), либо они заказывают перевозку ж/д транспортом (массивный параллелизм на GPU).
Продолжая аналогию:
Только на практике выяснится что производитель разместил слишком много кресел, которые не получается забить даже на половину, но из-за этого места для грузов тоже не осталось. А с машиной напротив - к ней цепляют прицеп и тот же объем пассажиров и груза все равно перевозят быстрее.
Но при этом у нас остаётся потенциальная возможность перепаковать груз (новым lcc) таким образом, чтобы он размещался на креслах. И тогда его можно будет перевозить на уже купленном речном судне быстрее, чем на машине с прицепом.
Проблема только в том, что возможность очень теоретическая и потенциальная и не любой груз вообще влезет на кресла.
И продолжая аналогию - если река немного сезонно пересохла то с речным судном все по-прежнему будет плохо. А автомобиль в случае заборов на одной дороге достаточно легко найдёт альтернативный маршрут и все равно окажется быстрее.
Но нет же, разная архитектура команд дает разницу в реальных вычислениях за такт, впрямую сравнивать циферки некорректно, вы в своем примере сравниваете как раз производительность в задаче (перемещение определенного груза на определенное расстояние за определенное время). Вы сравниваете с какой скоростью может перемещать определенный груз определенный механизм, а не на каких оборотах работает у этого механизма двигатель.
Ну если совсем грубо качество архитектуры = частота*ipc
И то и то в статье у эльбруса рассмотрено. И то и то хреновое. Что вам не нравится?
Ровно то что я и написал, мне не нравится аппеляция к цифрам в показателях тактовых частот
Есть ощущение что меня не правильно поняли: я не защищаю ни чью позицию, я только указываю что прямое сравнение циферок выглядит плохо. Можно сравнивать производительность на задачах. Не понял пчм если, допустим, у человека отличная статья, но где-то написано что 2+2=5 (без развернутых пояснений к этому тезису) то указать автору на странность ситуации вызывает такую бурную реакцию.
IPC у VLIW сильнее зависит от компилятора. На оптимизирующие компиляторы C для x86 было потрачено огромное количество ресурсов, чего нельзя сказать про Эльбрусы. Чтобы скомпенсировать это неравенство, имеет смысл приложить максимум усилий разработчика теста для увеличения IPC путём подсказок компилятору и переписыванию некоторых кусочков кода вручную.
На оптимизирующие компиляторы C для x86 было потрачено огромное количество ресурсов, чего нельзя сказать про Эльбрусы.
Не факт. LLVM относительно новый, с фокусом на множество языков и архитектур, 4сли смотреть на его развитие, то можно заметить что огдостаточно быстро достиг 90% скорости gcc (да, остальные 10% были трудными и заняли годы), в то же время llc делают лет 20 на практике (не тратя много сил на фронтэнд, он же там покупной), а если считать теоретические изыскания то лет 30. Притом это была команда full time разработчиков.
Чтобы скомпенсировать это неравенство, имеет смысл приложить максимум усилий разработчика теста для увеличения IPC путём подсказок компилятору и переписыванию некоторых кусочков кода вручную.
Только в реальной жизни разработчики крайне редко хотят таким заниматься (это будут буквально единицы людей). Так что для создания ситуации из реальной жизни ничего как раз компенсировать не нужно.
LLVM относительно новый, с фокусом на множество языков и архитектур, 4сли смотреть на его развитие, то можно заметить что огдостаточно быстро достиг 90% скорости gcc (да, остальные 10% были трудными и заняли годы), в то же время llc делают лет 20 на практике (не тратя много сил на фронтэнд, он же там покупной), а если считать теоретические изыскания то лет 30. Притом это была команда full time разработчиков.
Если вы знакомы с историей компиляторов, то знаете, что 80% производительности от LLVM/GCC для ограниченного набора архитектур может сделать единственный увлеченный энтузиаст за год-два. Пример - qbe. Или изолированная команда исследователей (libfirm).
Реальная же борьба в компиляторах уже давно идет за последние 1-3%. Более того, LLVM только в последние 3-4 года стал сравним с GCC, и это при том, что в LLVM вкладывают средства такие гиганты как Apple и Google. Сотни людей делали научные карьеры на исследованиях в этом фреймворке.
И все равно GCC поддерживает больше архитектур и во многих бенчмарках опережает LLVM.
Команда же llc никогда даже рядом не стояла ни с LLVM, ни с GCC по вложенным человеко-годам.
Если вы знакомы с историей компиляторов, то знаете, что 80% производительности от LLVM/GCC для ограниченного набора архитектур может сделать единственный увлеченный энтузиаст за год-два.
Но дело в том, что в случаи с llc мы не видим хорошей работы даже в 80% случаев.
Более того, LLVM только в последние 3-4 года стал сравним с GCC, и это при том, что в LLVM вкладывают средства такие гиганты как Apple и Google.
А это уже немного подмена понятий начинается, к сожалению. Потому что компаний конечно много вкладывает деньги и силы, но каждая компания заинтересована в узком круге задач, который некорректно обобщать на C + оптимизации под x86, о которых сейчас речь.
Сотни людей делали научные карьеры на исследованиях в этом фреймворке.
Я вот затрудняюсь сказать что именно сотни, но десятки точно делали (опять же если мы выделяем общие оптимизаторы в бэкэнде). Вопрос только в другом - сколько из этих исследований реально были воплощены в жизнь (многие исследовательные работы так и остаются исследовательскими работами, к сожалению).
Команда же llc никогда даже рядом не стояла ни с LLVM, ни с GCC по вложенным человеко-годам.
Если сравнивать весь llc со всем llvm - не буду спорить, но речь идет о том чтобы выделить только оптимизатор под 1 архитектуру (e2k и x86 соответственно) и попытаться сравнить времязатраты на тот и другой в человекогодах.
Во-первых, хочу заметить, что полемические приемы автора мягко говоря сомнительны. Все эти заходы вроде "Алексей, дело в том, что жизни всё устроено так...". И далее следует довольно наивный нарратив на тему о том, как же жизнь устроена по мнению автора. Причем, в таком тоне, как будто тут вещает если не Сократ, то как минимум Мишель Фуко. Автор даже не профессор философии и не доктор экономических наук. Так не слишком ли много он на себя берет, начиная рассуждать в таком тоне на подобные темы?
Теперь, по сути вопроса. Все претензии сводятся к банальному батлу VLIW vs RISC. Уже столько копьев сломано на этой теме, причем, экспертами такого уровня, что надо обладать немалой смелостью (или глупостью), чтобы после всех мудрецов высказавшихся за и против, начать на голубом глазу безапелляционным тоном тут "учить" про превосходство RISC перед VLIW. Причем все аргументы давно уже высказаны, разобраны и изучены - ничего нового автор в эту полемику не привносит. Поневоле вспоминается классическое: "Солдаты! Вы знаете, что я вам могу сказать, и я знаю, что вы мне можете ответить."
На мой взгляд, рассудить этот спор может только практика. Пока у МЦСТ получилось выкатить на рынок рабочие сервера на архитектуре Эльбрус и провести ряд реальных внедрений. Это аргумент гораздо более сильный, чем все гипотетические рассуждения, который дает объективный повод для осторожного оптимизма касательно будущего VLIW вообще и Эльбруса в частности.
На мой взгляд, рассудить этот спор может только практика. Пока у МЦСТ получилось выкатить на рынок рабочие сервера на архитектуре Эльбрус и провести ряд реальных внедрений. Это аргумент гораздо более сильный, чем все гипотетические рассуждения, который дает объективный повод для осторожного оптимизма касательно будущего VLIW вообще и Эльбруса в частности
А где логическая связь между первой частью (выкаткой рабочих решений) и оптимизмом? Факт наличия продаж и внедрений ознает только то, что был факт продаж и внедрений (плюс в копилку маркетолог) и это никоим образом не говорит о качестве архитектуры или ее будущем. Посмотрите на пример Itanium'а, который продавался, но при этом является эталонным примером того что VLIW нечего ловить в GP CPU (и по заявлениям alexanius'а Эльбрус не во всем бы обогнал итаниум при равных частотах).
Логическая связь между "выкаткой рабочих решений" и осторожным оптимизмом по поводу "будущего" Эльбрусов на мой взгляд очевидна. Если процессоры производятся, поставляются и эксплуатируются, то есть обоснованная надежда, что эта тенденция продолжиться. У Итаниума не получилось. Да, это тоже довод. Но не фатальный, IMHO.
Я не готов ввязываться в холивар VLIW vs RISC. Скажу только, что я в курсе кто и как высказался - об это много писали даже и здесь на хабре. Я свое отношение уже высказал выше: повторять все аргументы с обеих сторон не вижу смысла.
Логическая связь между "выкаткой рабочих решений" и осторожным оптимизмом по поводу "будущего" Эльбрусов на мой взгляд очевидна. Если процессоры производятся, поставляются и эксплуатируются, то есть обоснованная надежда, что эта тенденция продолжиться.
На тему очевидности я не согласен. Также как не согласен что корректно распространять "процессор производится" на "повод для осторожного оптимизма касательно будущего VLIW вообще и Эльбруса в частности."
Для оптимизма, как мне кажется, нужно наличие объективных преимуществ, а иначе это легко может оказаться просто безысходностью со стороны заказчика (обязан покупать то, что не нравится). Более того хотите немного переиначу ваш аргумент, как пример недопустимости аналогии?
Пессимизма касательно будущего Эльбруса и VLIW в частности добавляет то, что МЦСТ до сих пор производит SPARCи (r2000) и то что известные военные комплексы с Эльбрусами основаны на SPARCах. Это очевидно означает неуверенность разработчика и заказчика в будущем VLIW процессоров.
Надеюсь такая аналогия покажет объясняет, почему Ваш вывод не очевиден?
Нет, не покажет и не объясняет. То, что МЦСТ производит что-то еще никак не отменяет того факта что им удалось вывести на ранок и внедрить продукты на архитектуре Эльбрус. В любом случае, вы имеете право на свое мнение. Я останусь при своем. А время покажет, загнутся ли эльбрусы или же их производство будет нарастать. Я бы скажем купил акции МЦСТ сейчас.
им удалось вывести на ранок
Даже к этому есть вопросы. Потому что свободной продажи по сути нет, а количество заказов процессоров (и соответственно очереди за ними) остаются огромными.
Я останусь при своем.
Да, само собой. Просто решил указать что у вас в логической цепочке есть ошибка и такой переход недопустим.
Нет, вы не нашли ошибки в моей логике, а лишь рассказали о том, что "вам кажется".
На ошибку в вашей логике я указал как раз вам. И это действительно логическая ошибка, а не "так кажется".
Нет, вы не нашли ошибки в моей логике
Не соглашусь. Ваша логическая ошибка в том что вы приравниваете наличие каких-то продаж к шансу на светлое будущие, полностью игнорируя техническую составляющую и то что даже у плохих товаров случаются продажи.
а лишь рассказали о том, что "вам кажется".
Можно цитату, это доказывающую?
На ошибку в вашей логике я указал как раз вам
И на это, можно, пожалуйста, цитату? Не помню чтобы вы указывали на какую-либо ошибку в логике.
Позвольте заметить, что используя метод от обратного к вашему утверждению: "у плохих товаров случаются продажи" можно ли утверждать, что: "у хороших товаров продажи не случаются"? Буду признателен, если вы придете пример отличного товара, который не имел продаж.
Считаю, что наличие продаж (неважно каким методом обеспеченных) - это позитивный знак для любого начинания в целом, нежели "классные технические перспективы" и полное отсутствие продаж. Вспомним историю Theranos? За технику отвечал целый лауреат премии Шао в области молекулярной биологии. Супер перспективно и технически обоснованно (на допустимом в тот момент уровне).
Позвольте заметить, что используя метод от обратного к вашему утверждению: "у плохих товаров случаются продажи" можно ли утверждать, что: "у хороших товаров продажи не случаются"?
Метод "от обратного" обычно применяется в математике. Укажите пожалуйста что позволило вам сделать выводы, что я говорю в математическом поле?
Я, например, не считаю что спор выше можно к таковому отнести, а значит "от обратного" не применимо напрямую к фразам (и более того, это тоже будет примером подмены совпадения на следствие, как делал человек, с которым я дискутировал).
Считаю, что наличие продаж (неважно каким методом обеспеченных) - это позитивный знак для любого начинания в целом, нежели "классные технические перспективы" и полное отсутствие продаж. Вспомним историю Theranos? За технику отвечал целый лауреат премии Шао в области молекулярной биологии. Супер перспективно и технически обоснованно (на допустимом в тот момент уровне).
Theranos хороший пример того, что продажи и перспективы - вещи не связанные друг с другом (потому что у них как раз продажи были, а вот технология отсутствовала даже в теории, на момент продаж).
Вы запутались. Вернее перепутали математику и логику.
Метод Доказательство «от противного» (contradictio in contrarium), или апагогическое косвенное доказательство, — вид доказательства, при котором «доказывание» некоторого суждения (тезиса доказательства) осуществляется через опровержение отрицания этого суждения — антитезиса. Этот способ доказательства основывается на истинности закона двойного отрицания в классической логике.
Метод применяется в математике, но никоим образом не является следствием математики.
Софистика здесь ни к чему, т.к. я прекрасно понимаю о чем речь и вам меня не запутать.
Theranos - я вам привел в пример о том, что не всегда серьезные технологические обоснования (как в случае обоснование автора заметки о тупиковости VLIW архитектуры в сравнении с RISC) приводят к успешности проекта. Современный капиталистический рынок живет по принципу "fake it till you make it", а факт продаж является главным мерилом потенциала проекта. Капитализация компании на любых раундах венчура строится на продажах или ожидании продаж. Поэтому для меня очень странным является факт отрицания значимости продаж Эльбруса в признании перспектив этой платформы.
Скажите пожалуйста, какие из военных комплексов используют SPARC?
Я скажу даже больше. "У Итаниума не получилось" в первую очередь не по техническим, а по, кхм, "маркетинговым" причинам что-ли. Когда эпичный переход HP (а Itanium по большому счёту только HP и двигало) на Itanium только начался, я работал в компании, которая эксплуатировала сервера на ВСЕХ более менее распространённых в то время процессорных архитектурах, и в которую HP сами подогнали свои новенькие сервера "для портирования решения". А чуть позже работал в самой HP. И после неё в Sun. Так что я знаком с восприятием решений на Itanium со всех сторон - и производителя, и конкурента производителя, и пользователей, и своим внутренним, и ближайших коллег, и широкого круга IT-профессионалов. Я не помню, что бы я испытывал проблемы в производительности решения на Itanium или мне кто-то со стороны указал на явный провал "в цифрах". Стоящие рядом 2 сервера HP, один на PA-RISC, второй на Itanium, одного класса и поколения в практичекси идентичной конфигурации, давали идентичные цифры, что в чистой производительности БД, что в терминах конечной производительности приложения. Ключевым было недоверие пользователей, активно подогреваемое ВСЕМИ конкурентами, к тому, что HP (и Intel) имеет силы и главное желание/волю, поддерживать и развивать архитектуру Itanium на каком-то вменяемом уровне в какой-то вменяемой перспективе.
один на PA-RISC
Не очень удачный пример. Отношение к PA-RISC даже в то время было не очень и люди не особо его любили (и видели мало перспектив у платформы).
Во-первых, не сталкивался с таким мнением. Ни у коллег, ни сам так не считал. Единственная "лёгкая неприязнь" к PA-RISC была только у тех, кто был фанатом Alpha и считал, что выбирая из Alpha и PA-RISC выбор нужно было делать в пользу Alpha.
Во-вторых, как это опровергает тот факт, что между PA-RISC и Itanium в серверах одного поколения и класса не было принципиального отрыва/отставания в производительности "конечного приложения"? Хорошо, давайте возьмём более широко - в сопоставимых конфигурациях поздние Alpha, ранние Itanium и современные им PA-RISC, Power и SPARC давали сходные цифры в терминах производительности конечного приложения. Из стройного ряда не выпадал никто. Даже x86 можно было довести до сопоставимых цифр тюнингом ядра и правильным выбором файловой системы для БД. Классы приложений, которые я имел счастье "сравнивать" своими руками - банковские системы и биллинговые системы сотовых операторов.
Во-первых, не сталкивался с таким мнением.
Я не слышал о PA-RISC ничего хорошего от людей, которые писали этот самый софт. Его ругали за странность архитектуры и то что это делало написание производительного кода крайне затруднительной.
Даже x86 можно было довести до сопоставимых цифр тюнингом ядра и правильным выбором файловой системы для БД.
Вот это кстати куда ближе к причине провала Itanium'а, PA-RISC'а и прочих. Зачем брать дорогое специализированное и очень закрытое железо (привязывая по сути себя к его производителю), когда есть дешевый и относительно открытый x86? Тем более не забывайте что Итаниум должен был выйти в 1998 году изначально, а вышел по факту в середине 2001.
Я не слышал о PA-RISC ничего хорошего от людей, которые писали этот самый софт.
Не знаю, у меня противоположный экспириенс, ни каких специфических жалоб. 5 лет работы в разработчике банковского софта.
Зачем брать дорогое специализированное и очень закрытое железо (привязывая по сути себя к его производителю), когда есть дешевый и относительно открытый x86?
В те времена, когда был "рассвет" "дорогого, специализированного закрытого железа" x86 мог предложить только работу с entry level нагрузкой. Максимум 4 процессора в системе, как следствие ограничение на объёмы оперативной памяти, детские болезни ядра Linux - слабые диспетчеры задач, ввода/вывода, убогие ФС и менеджеры томов, отсутствие или зачаточное состояние асинхронного и прямого дискового io и т.п..
Скажу больше, если бы не провал Itanium (повторюсь, больше "ментальный", чем технический), после которого HP вынужден (!) был дрейфовать в сторону x86 и тянуть x86 за уши в enterprise, x86 так и остался бы в entry level - mid range, тогда как в high end до сих пор рулили бы разные RISC-и. Хотя, как побочный эффект, Linux, может быть, был бы более "вылизан" для entry level.
Максимум 4 процессора в системе, как следствие ограничение на объёмы оперативной памяти, детские болезни ядра Linux - слабые диспетчеры задач, ввода/вывода, убогие ФС и менеджеры томов, отсутствие или зачаточное состояние асинхронного и прямого дискового io и т.п..
Смотрите, если мы говорим о timeline'е, то Merced вышел в 2001 году, через год вышел Itanium 2, но уже в 2003 году AMD представила x86-64 и Opteron'ы которые умели в 8-и процессорные системы и умели в много памяти. Таймлайн сам по себе был очень жесткий и не в пользу Итаниума.
Еще не стоит забывать что начало 2000-х как раз момент становления FAANG'а и им сопутствующих как IT компаний, которые изначально избрали подход в покупке commodity железа за дешево и делать ПО с учетом особенностей таких решений. Как раз эти моменты очень сильно перекроили рынок, потому что крупный Enterprise может и хотел себе привычное большое железо, но появилось много мелких игроков, которые умели использовать дешевое железо для достижения результата. И по объему продаж и прибыльности вскоре "много мелких" оказалось лучше чем "мало огромных".
А в какой момент, можно сказать, HP сдались и опустили руки? По косвенным признакам они еще в 2008 году платили интелу за разработку и выпуск новых моделей, то есть явно до 2008 года (включительно) считали что шансы есть.
В общем не знаю, кажется что это все таки технический провал в первую очередь, и связанный с тем что x86 оказался неплох и доступен (дешевое TCO), в то время как для специализированных процессоров практически не осталось места (сейчас те же банки постепенно уходят спокойно в облака на x86 со своих дорогих железок).
Вы противоречите сам себе. С одной стороны утверждая что с выходом Opteron в 03 году Iyanium-у "настал капец", а с другой стороны подтверждая. что запрос клиентов на Itanium в 08 у HP был таков, что бы склонить их к целесообразности разработки нового поколения Itanium.
В 03 году Opteron, конечно, вышел, и, спасибо плотному сотрудничеству с Sun, умел в 8-сокетные сервера, но ещё несколько лет не было нормальных программных решений (ОС, СУБД и т.д.), которые позволяли бы эффективно такие системы использовать. Да и стоимость таких серверов ничем не уступала стоимости Itanium/PA-RISC/Power/SPARC серверов. Всё "бодание" x86 vs не-x86 шло в плоскости 2-сокетных машин и "умения в горизонтальное масштабирование".
Победа x86 в итоге свершилась не по технологическим, не по экономическим, а по, скорее, "политическим" причинам. Например, "смерть" SPARC в "борьбе" с x86 является следствием подковёрных игр представителей высшего менеджмента Oracle борьбе за "трон" (пост CEO) при грядущем "отходе от дел" Ларри Эллисона.
Про "банки уходят в облака" отдельно улыбнуло. Прям "табор уходит в небо". :) Не пересказывайте эту байку представителям российских и немецких финансовых структур, что бы не попасть в неловкую ситуацию.
Вы противоречите сам себе. С одной стороны утверждая что с выходом Opteron в 03 году Iyanium-у "настал капец",
Во первых я не говорил что настал капец, а я говорил что это был жесткий тайминг и весомый кусок преимуществ испарился.
а с другой стороны подтверждая. что запрос клиентов на Itanium в 08 у HP был таков, что бы склонить их к целесообразности разработки нового поколения Itanium.
Во вторых я ничего не говорил про запрос клиентов у HP. Более того, насколько я знаю, публично количество клиентов на Итаниумы у HP в 2008 году неизвестно. Так что это можно использовать как подтверждение веры HP в платформу, но не более того.
В 03 году Opteron, конечно, вышел, и, спасибо плотному сотрудничеству с Sun, умел в 8-сокетные сервера, но ещё несколько лет не было нормальных программных решений (ОС, СУБД и т.д.), которые позволяли бы эффективно такие системы использовать.
Windows Server 2003 x64 вышел примерно в том же году, Linux в amd64 научился практически сразу (с софтом да, где-то год-полтора еще надо было потерпеть). Тем более это открывало простор для горизонтального масштабирования в рамках виртуальных машин на одном сервере, если уж очень хотелось "здесь и сейчас"
Да и стоимость таких серверов ничем не уступала стоимости Itanium/PA-RISC/Power/SPARC серверов
К сожалению я недостаточно хорошо помню цены на 8-и сокетные сервера в те времена, а также довольно плохо помню цены и на итаниумы со спарками. Поэтому с одной стороны не готов Вам верить на слово (как минимум потому что на рынке commodity серверов всегда были игроки второго и третьего эшелона, которые продавали железо качеством похуже, но и значально дешевле чем HP и прочие крупные товарищи).
Например, "смерть" SPARC в "борьбе" с x86 является следствием подковёрных игр представителей высшего менеджмента Oracle борьбе за "трон" (пост CEO) при грядущем "отходе от дел" Ларри Эллисона.
Извините, но смерть SPARC случилась по факту раньше чем Oracle купил SUN. Посмотрите на доли на рынке и на revenue в период до января 2010 года (момент окончания покупки SUN'а).
Если вкратце, то начиная с 2004 года SUN выпускает x86 сервера, потому что доля на рынке начинает падать (хотя выручка все еще растет). В 2007 году SUN уже не первые на рынке, а всего лишь третьи по выручке и 6-ые по доле.
То есть к моменту покупки их Oracle'ом там никакого доминирования не было уже годы. На тот момент (если посмотреть) x86 владел уже половиной рынка серверов, а доля SPARCов из года в год только падала. (если что я понимаю что по хорошему надо еще отдельно смотреть на доли SPARC-решений от Fujitsu, но они в целом вели себя также как SUN, а прям полноценный таймлайн делать это очень много кропотливой работы)
В общем и целом у SUNа было все плохо еще когда он был SUN'ом. Так что не вижу как борьба за власть в Oracle могла повлиять.
Про "банки уходят в облака" отдельно улыбнуло. Прям "табор уходит в небо". :) Не пересказывайте эту байку представителям российских и немецких финансовых структур, что бы не попасть в неловкую ситуацию.
Так а где байка то? Вбейте в поиск:
Deutsche Bank signs cloud deal
HSBC Cloud Strategy
Goldman Sachs Cloud
JPMorgan Chase cloud
Это только про крупные, которые заявили о заключении контрактов предполагающих миграцию критичных для банка систем в облака. В целом почитайте тот же forbs с их аналитикой или аналитику от accenture (прошу прощения что не оригинальный язык, искал информацию про российские банки).
Если выкатить на рынок по принципу "а ежели кто не купит - тому отключим газ вообще больше ничего не дадим купить" - то да, это воистину гениальный маркетинговый ход. Гениальнее только анекдотичное(ли?) изображение Северной Кореи, когда за спиной у покупателя стоят пара автоматиков, чтобы покупатель не передумал.
И это не говоря уж о том, что они продают серверы с официальным пиратским софтом на нём! Это что ж получается, отечественное импортозамещение зиждется на банальной краже чужой интеллектуальной собственности?
А чему вы удивлены? В СССР целые институты сидели и препарировали под микроскопами зарубежные микросхемы, чтобы потом сделать отечественные аналоги . Из-за неизбежных ошибок нужны были годы, чтобы эти аналоги приемлемого качества изготовить и все равно по размеру и характеристикам они уступали оригиналам. А с копированием ПО и Китай втянулся в ту же игру и Россия.
Угу, советские микросхемы - самые мобильные микросхемы в мире: 6 ножек и 4 ручки для удобства переноски!
Но в советское время, во-первых, не всё скопитыренное было спирачено - кое-что просто не защищалось на тот момент, а во-вторых - местами напоминает нынешний тыринг из опенсорса, что символично. Ну ладно, каперство - это пиратство, поощряемое государством, в некоторым смысле тырят друг у друга все.
Но пиратить то, что и так отдают бесплатно - это уже перебор.
Да я вовсе не про законность или мораль, а про то, что такое пиратство заставляет безнадежно отставать. Даже с пиратством опен сорс кода - чем сильнее кодовая база отличается от оригинала, тем дороже и сложнее все это поддерживать и обновлять из основной ветки, что приводит ко все большему отставанию от апстрима. Вот, скажем, китайцы с их (еще недавно) безграничными трудовыми ресурсами копию Amazon AWS запустили - алибаба клауд, так там сортировка файлов в юникодной американской локали оказалась ну дико странная, так что все операции с сортировкой файлов возвращают непредсказуемый результат. Может, уже починили, но суть копирования с доработкой и поддержки получившегося франкенштейна понятна.
Даже с пиратством опен сорс кода - чем сильнее кодовая база отличается от оригинала, тем дороже и сложнее все это поддерживать и обновлять из основной ветки, что приводит ко все большему отставанию от апстрима.
Почему иногда проще и дешевле отдать что-то в апстрим, чем иметь секс с поддержкой этого самостоятельно...
В этом смысле да, согласен.
Пока у МЦСТ получилось выкатить на рынок
На рынок? Честно-честно?
Пока у МЦСТ получилось выкатить на рынок рабочие сервера на архитектуре Эльбрус…
На моей памяти полемике про Эльбрусы уже больше 20 лет. И вы знаете, за все это время я не видел ни одного эльбруса. Вот и с интел и амд и армами и микроконтроллерами всякими - пожалуйста, работал и работаю, а эльбрусов как не было, так и не видно даже на горизонте. Так что про рынок здесь говорить не приходится вовсе, какое-то очень нишевое решение и автор пытается как раз показать, почему. Ах да, в новостях недавно снова видел, что десктоп «для всех» на эльбрусе вышел - так на сайте заявленного в новости производителя написано, это они госконтракт на его разработку получили, скоро начнут делать. И так все 20+ лет.
и еще лет 20 будут так же говорить, если, конечно, ничего кардинально
не поменяется
Помню смотрел теледачу в 90-х на центральном канале (долгую). Ведущий, два академика и Бабаян. Обсуждали развитие микропроцессоров.
Как сейчас помню заявление Бабаяна на всю страну: пройдет каких-то 5 лет и наш Эльбрус появится в каждой семье (не дословно).
Периодически похожие заявления от новых "Эльбрусовцев" я слышу каждые пять лет. И 15 лет назад были заявления, что "вот-вот" появятся в магазинах. Смешно … Хотя конечно же, грустно. Веры в него давно уже нет, хотя в некоторых военных НИИ на них какие-то поделки демонстрируют.
На рынке ничего не присутствует. Не читая Хабр узнать об Эльбрусе почти невозможно. Платить деньги за рабочую станцию на Эльбрусе некуда и незачем.
Очень это похоже на "Вы не понимаете, это другое". После нескольких адекватных коментариев очень разочарован нахлынувшими "солдатами отечественного", которые статью похоже не поняли от слова совсем.
Страну любите, но глупость порицайте.
Как Вы насчитали 13 тактов? Это же VLIW, там несколько конвейеров и несколько команд делаются за такт. В этом их фишка.
Про неоптимальность VLIW и сложность компилятора, Вы спросите у тех, кто работал с dsp серии c6000 от ti. Конечно, есть нюансы, но вполне не плохие молотилки для обработки данных.
Также не понял, почему тактовая частота для VLIW ниже, чем для RISC. Но это вопрос, скорее, не автору статьи. Надо будет почитать.
Соглашусь, что такая архитектура хорошо работает под определённые задачи. Тот же диспетчер задач в ОС будет постоянно сбрасывать конвейер или дожидаться опустошения. Здесь не хватает host процессора, который будет подготавливать и распределять данные для VLIW блоков.
Компилятор кстати помогает считать такты. Если убрать галочку в Filter->Comments, то между ШК будет комментарий с тактами.
Несколько конвейеров тут значения не имеют.
Вам верно подсказали - можете включить разметку тактов, там всё указано.
Ну так привели бы в статье такты и как их считали.
Вы просто не работали с такой архитектурой, если просто суммируете такты.
Вы просто очередной неуч, который пишет непойми что. Я 10 лет разрабатывал бинарку под Эльбрус и считаю производительность и такты для него с закрытыми глазами. Если бы я тут ещё и такие нюансы разбирал, как считать такты, статья бы в монографию превратилась. В конце концов можете обратиться к сотрудникам Мцст, которым доверяете. Они подтвердят, что цифры абсолютно верные
Ну тогда помогите неучу найти истину: как в VLIW цикл может выполняться за 13 тактов, если там 6 блоков с командами? Или там конвейер на 2 такта?
Нет, там в некоторых ШК стоят операции nop с циферкой, означающей сколько тактов после исполнения данной ШК процессор должен побулькать в ожидании результатов. Если вы все суммируете, то получите 13 тактов
Тогда тут уже проблема компилятора, что он не смог развернуть код, чтобы уложить в конвейер.
Всегда пожалуйста. Что касается проблем компилятора - так в этом и вся сол - не справляется он. Нельзя только статическим анализом адекватно разрешить все зависимости, возникающие в коде
Ну, ti много сил вложил в компилятор. Получился не плохой. Но все равно приходилось подсказывает с помощью pragma.
Тут вопрос в развитии компилятора. Сама архитектура процессора вполне достойная.
А рисовать самому графы и оптимизировать конвейер на ассемблере дело неблагодарное.
Ну, ti много сил вложил в компилятор. Получился не плохой.
Вот вот. Сил вложено много, и все равно приходится местами что-то делать ручками. И все равно разные бенчмарки последних лет говорят о том, что где-то С66х проигрывают SIMD GPCPU, где-то они проигрывают спецускорителям, где-то FPGA, где-то GPU, причем это все речь идет о достаточно удобных приложениях, не то что "вместо мучений с DSP будем мучиться с FPGA". Это конечно не означает смерть DSP, наоборот, они цветут и пахнут, но речь о том, что широкая команда еще не синоним успеха во всем. В чем-то конкретном - да.
Тут вопрос в развитии компилятора. Сама архитектура процессора вполне достойная.Ненененене, в случае VLIW эти вещи предельно плотно взаимосвязаны, и разделять ни в коем случае нельзя, а то получится классическое «к пуговицам претензии есть?»
Пользователю не важно, по какой именно причине его софт работает медленно, и продукт на рынке — это не железка, а железка с софтовой экосистемой.
первое хотя бы теоретически имеет перспективы быть исправленным, с вторым, очевидно, грустнее.
Я там сделал в тексте ремарку по данному поводу - там проблема в том, что есть зависимость между load и store, похоже из-за этого там в компиляторе весь анализ отвалился. Ну и плюс в реальности без понимания, какой код реально горячий, очень сложно хорошо код оптимизировать (это к рассказам Алексея про чудесные эвристики).
В общем, навскидку, этот цикл можно соптимизировать где-то до 7-8 циклов. Наверное, можно даже подумать о большем (у меня есть идеи, но их надо проверять), но это точно в реальной жизни фиг применишь. Только ручная оптимизация по факту. Как в Spec2006/2017 для Эльбруса ))
В общем там ниже написали, что если вместо -O4 подать -O2 (не спрашивайте меня в чём логика), то цикл соптимизируется намного лучше (как раз таким он навскидку должен был быть на мой взгляд). Это уже ближе к теор максимуму. Там 6 тактов получилось.
лучшее, что у меня получилось на x86 — 2 такта на цикл на epyc'е 7453 и xeon'е 4214.
i5-3570 ≈2.6, как и в статье, ryzen 5950x ≈4.5 (!?!)
2 это норм, где-то тут мы уже должны упираться на современных серсверных процах. Но красота ОоО в том, что можно ещё добавить транзисторов и можно сделать, например, 1.5. Или даже ещё лучше. Просто тут уже начинаются трейдофы, насколько в реальной жизни это будет полезно с учётом затраченных транзисторов и пауэра. Поэтому там польза от уменьшения нанометров есть - можно добавить транзисторов и ещё улучшить микроархитектуру. А во VLIW от этого толку никакого. Т.е. дальше разрыв по микроархитектурной скорости будет только расти
Спасибо за пояснение.
считаю производительность и такты для него с закрытыми глазами
Ты молодец, но ты забываешь что это именно эльбрусовская система команд тебе это позволила сделать. Для интела ты свой навык применять не можешь, ты не видишь микрокод и не знаешь что внутри происходит: https://godbolt.org/z/qaxdEeGo6 10~13 тактов интел тратит, никакие не три. Хватит людям в уши лить.
Мне для этого не нужен никакой микрокод. Я просто запустил и перфом снял все метрики. Там получается ровно 3 такта. Возьмите и проверьте.
А теперь включи оптимизации как в статье (-O2 или выше), выбери компилятор как в статье (gcc 7.5, а не кланг) и внезапно получишь во-первых ассемблерный листинг как в статье (а не колбасу на 30+ инструкций), а во-вторых - не поверишь, 2-4 такта на итерацию. Ну ты понял наверное. Прям как в статье.
https://godbolt.org/z/KE5hqjsqP
Ну и плавающие 2-4 такта - это на godbolt. На реальном железе с +/- стабильной нагрузкой у меня 1.7-1.8 тактов. Zen 2
А теперь включи оптимизации как в статье (-O2 или выше), выбери компилятор как в статье (gcc 7.5, а не кланг) и внезапно получишь во-первых ассемблерный листинг как в статье (а не колбасу на 30+ инструкций), а во-вторых - не поверишь, 2-4 такта на итерацию.
Он же ОоО суперскаляр, у него все есть в железе и ему не нужно полагаться на компиляторы как какой нибудь там тупиковый VLIW. Они вон все ненадежные: https://godbolt.org/z/8qe454f4z компиляешь с максимальными оптимизациями -O3 а результат хуже чем с -O2 в два раза - 3.3 такта против 1.75
Гораздо проще и лучше транзисторов еще там сям приляпывать и вообще выкинуть компиляторы как класс на свалку истории. Пользователь только спасибо скажет, раньше одним и тем же процессором приходилось обходится по несколько лет, а теперь скажет с предвкушением откладываю на осенний сезон аппаратных обновлений.
Не уверен, что в этом есть смысл, но все же отвечу на это ёрничанье по существу, насколько это возможно.
https://godbolt.org/z/8qe454f4z компиляешь с максимальными оптимизациями -O3 а результат хуже чем с -O2 в два раза - 3.3 такта против 1.75
Если внимательно посмотреть, то можно заметить, что ассемблерный код сортировки для -О2 и -О3 одинаковый. Отличается только код print_array, выполнение которого не замеряется. Так что разброс значений объясняется не ненадежностью чего бы то ни было, а банально плавающей нагрузкой на сервера godbolt и и/или выполнением кода разными машинами. Да, такое бывает. Поэтому мерять производительность чего угодно на shared хостинге (и даже на VPS) - изначально глупая затея. Приводить результаты этих измерений в качестве аргумента, когда они отличаются даже не на порядок, а всего на 1,5 такта - затея еще более глупая.
Он же ОоО суперскаляр, у него все есть в железе и ему не нужно полагаться на компиляторы как какой нибудь там тупиковый VLIW.
Соломенное чучело уничтожено! Поздравляю!
такая архитектура хорошо работает под определённые задачи
С этим вообще никто не спорит - например ISP (процессоры ввода с сенсора изображений) умеют делать довольно сложные вычисления с большой скоростью и параллельно - разные стадии алгоритма над последовательными кадрами. Но как GP CPU они никуда не годятся.
разные стадии алгоритма над последовательными кадрами.
Только по какому-то очень жесткому алгоритму, они же друг к другу прибиты намертво на этапе компиляции. Синхронизация разных потоков - очень нетривиальная задача для программиста, компилятор тут не поможет. Скорее VLIW подойдет для синхронной обработки каналов многоканального DSP.
По этому на видеокартах это не прижилось.
Но даже на DSP это просится как сопроцессор.
Только по какому-то очень жесткому алгоритму
Да, сканирование сенсора же идет постоянно - и кадры "образуются" один за другим. Ко всем применяется одна и та же последовательность преобразований, для изменения "значительных" параметров вроде разрешения или частоты кадров - большинство систем сенсор-ISP надо "остановить" и перезапустить с новыми настройками.
Первая часть про военные цели и FFT - это по-моему очевидно.
>Когда-нибудь в мемуарах выяснится
Так вроде это особым секретом и не является, не?
>Я думаю, что уже надо остать от Эльбруса
Напомню с чего начался нынешний сыр-бор: в Минпромторге решили внимательно подумать над целесообразностью дальнейшего финансирования разработки Эльбруса, после чего МЦСТ начало публично жаловаться на "подрыв доверия" и захотело введения госплана. Разумеется, конкуренты делающие ставку на ARM/RISC-V начали активно суетиться в надежде отъесть кусок бюджетного пирога выделяемого на МЦСТ.
Теперь вопрос: кто на ваш взгляд имеет больше перспектив на хоть какой-то рыночный успех Эльбрус или разработки на основе ARM/RISC-V, особенно учитывая культуру тотальной закрытости первого? Иначе говоря, к Эльбрусу никто бы не приставал если бы МЦСТ разрабатывало его за собственный, а не государственный счёт.
Благо не Эльбрусом единым и в России есть компании обладающие компетенцией в разработке ARM и RISC-V процессоров.
>Обрезать в ноль финансирование МЦСТ тоже не следует.
Так никто вроде и не говорит что нужно МЦСТ банкротить прям завтра. Но вот касательно того что на него стоит делать основную ставку (как было до сих пор), тут возникают большие вопросы.
>Ну потому что 100% существует ниша, где VLIW будет справляться лучше чем GPCPU.
Проблема в том, что эта ниша (в моём понимании) чрезвычайно мала. VLIW тут с одной стороны сильно зажат SIMD инструкциями и GPU, а с другой технологией внеочередного исполнения, которое в некотором смысле является "автоматическим" VLIW реализуемым самим железом, а не компилятором.
VLIW должно сидеть в виде сопроцессора, а загрузкой в него программ должен заниматься ЦП.
Что-то мне кажется, вы сейчас изобрели Cell Broadbane Engine Architecture
Этакую ромашку, с центральным процессором-диспетчером, и (ЕМНИП) 6 "периферийными процессорами". Вот только в реале он умер ещё раньше Итаниума.
https://en.wikipedia.org/wiki/Cell_microprocessor_implementations#Prospects_beyond_45_nm
И думаю, по той же причина общая, у Cell и у VLIW: "протечка абстракции" микроархитектуры в архитектуру, и в результате программирование становится привязано к данному конкретному железу и бесполезно для остальных процессоров, сегодняшних и будущих. В век, когда борются за loose coupling даже программных блоков внутри одной программы, такая жёсткая привязка к железу становится "ядром каторжанина", за исключением специальных ниш - таких как драйверов и firmware, которые по определению привязаны к железу.
Sony/IBM попытались стандартизировать эти "лепестки", но... их просто слишком мало. В отличие от Intel Xe/Knights или как их там, где счёт шёл на десятки, и видеокарт - где на сотни, на Cell даже одного десятка не было. А для какой-нибудь программы на Erlang с несколькими тысячями потоков быстрее основной процессор переключать по наборам переменных, чем бесконечно перезагружать сторонние, которых всего-то пол-десятка. А сделать хоть Cell хоть VLIW на сотни физически одновременных параллельных потоков исполнения - нереально.
А ещё, пожалуй, до них можно вспомнить ARM, а точнее концепцию Transputer. Тоже красивая в теории идея, элегантная до боли, и "не взлетает".
Собственно, "канальныe процессоры" IBM 360 такими и были, интерфейсом подключения железа и не более того. Также можно вспомнить, что в IBM PC AT был отдельный процессор для клавиатуры, но никто туда не пытался вкрячить DOS и программы же. Внутри видеокарт, сетевых карт, винчестеров - там тоже процессоры есть, но никто их как GP не рассматривает (разве что всякие спецслужбы/вирусописатели).
Подобная архитектура не только не умерла - но и активно развивается. В современных SoC - есть несколько "обычных" ядер (часто разных), ISP для обработки изображения с камер, GPU, NNPU, baseband и так далее.
В Raspberry Pi GPU даже "главнее" и именно он занимается инициализацией и управлением всей системой - но это исключение, только подтверждающее правило - никто специализированные сопроцессоры как GP не рассматривает, их внутренняя архитектура "заточена" под какие-то узкоспециальные вычисления. А GP, в том числе управление всем этим зоопарком - удел "обычных" ядер.
Это другая архитектура, не Cell. Это как архитектура 8086 - с дополнительным сопроцессором 8087 для конкретной узкой функции и ни для чего другого. Кстати, в оригинальном предложении Интел были и другие сопроцессоры (8089), просто IBM не стала их покупать.
никто специализированные сопроцессоры как GP не рассматривает, их внутренняя архитектура "заточена" под какие-то узкоспециальные вычисления
Вот именно поэтому эта архитектура, которую вы описываете, подобна 8086, и а вовсе не Cell, где "периферийные" процессоры были одинаковые и должны были выполнять основную работу.
Для типового же заточенного на конкретную функцию сопроцессора типа 8087 или звукового AC'97 DSP - VLIW просто напросто избыточен. Не нужны там его возможности GP, независимо от эффективности. Сопроцессор должен быть максимально эффективен в своей конкретной функции, а "неэффективную гибкость" оставить центральному процессору.
Elbrus же - это VLIW общего назначения. Не заточенный на, например, трансформацию 3D-каркасов, или сжатие MPEG4. Поэтому идея "Эльбрусы как сопроцессоры" - это будет повторение именно Cell. Не взлетит. А сделать на основе ядра e2k узкофункциональный и маленький блок типа какого-нибудь AES-NI/Padlock тоже не получится.
С другой стороны — на этом продолжает существовать тонкий слой инженеров, которые умеют делать архитектуру, организовывать выпуск, добиваться какого-то выхода годного и т.д.
Вы понимаете, что это утверждение основано скорее на пропаганде МЦСТ?
В России есть несколько успешных разработчиков железа: НИИСИ с КОМДИВами, Синтакор с Risc-v, Миландр с кучей разных чипов, Байкал Электроникс с Байкал-Т и Байкал-М, Элвис с их процессорами... Вы правда считаете что экспертиза существует и культивируется только в МЦСТ?
Когда-нибудь в мемуарах выяснится, что ноги его растут из военных разработок, где не было разговора про GP computation, а надо было бесконечно крутить заранее известный алгоритм
Для начала хочется выяснить где вообще в ВПК применяется Эльбрус для вычислений. А то известно про Эльбрус-90Микро который SPARC - что он стоит в ракетных комплексах и прочих интересных местах.
Ну он применяется не только в ВПК, пк на Эльбрусах используются в РЖД, и из личного опыта, на НИИ Восход, которая разрабатывает и содержит ЦОД с Государственной системой паспортно-визовых документов нового поколения (ПВДНП) — это той самой, на которой будут крутиться новые паспорта. Еще есть несколько гос. компаний и вроде то ли вузов, то ли школ, где их используют. Эльбрусы там показывают себя весьма достойно.
Ну он применяется не только в ВПК
В комменте выше речь, как я понял, про "изначально делалось для ВПК". Отсюда и вопрос к автору - где именно они в ВПК?
пк на Эльбрусах используются в РЖД
А их точно закупили?
Эльбрусы там показывают себя весьма достойно.
Мне кажется, "весьма достойно" должно сопровождаться цифрами. Например сколько удалось сэкономить на TCO по сравнению с x86?
должно сопровождаться цифрами
В этом докладе были некоторые цифры http://0x1.tv/20181012BC , но в целом - сильно сэкономили, потому что до альтернатива была в сверхдорогих решениях от IBM, и чтобы сползти с них, использовалось "импортозамещение".
Разумеется, с рыночным небрендовым x86 по TCO вряд ли реально сравниваться, я не видел таких сравнений.
В этом докладе были некоторые цифры http://0x1.tv/20181012BC , но в целом - сильно сэкономили, потому что до альтернатива была в сверхдорогих решениях от IBM, и чтобы сползти с них, использовалось "импортозамещение".
Это смотрел, очень сильно удивлялся (в плохом смысле) качеству анализа. Если прям по пунктам:
Сами нагрузки достаточно смешные (я про 20 ТБ данных и 4 ТБ базы, как и 40 тысяч запросов в сутки)
Из цифр только "год обслуживания менйфрейма стоит как 130 серверов на Эльбрусах". Они не учитывают стоимость эксплуатации (электричество не бесплатное, адаптация кода под новую архитектуру не бесплатная и т.п.). Про это был слайд, но автор доклада его к сожалению пропустил.
Непонятно почему рассматривались только Эльбрусы, а не, например, сервера на x86 (притом даже брендовые). Как раз при таком редизайне системы напрашивается сравнение Эльбрус vs x86
Отсутствует какой либо анализ системы с точки зрения надежности данных. Но тут авторам benefit of a doubt дается и допустим их все устраивает. Но в рамках таких докладов интересно было бы услышать проводились ли сравнения касательно гарантий доставки сообщений, поведения системы в рамках нештатных ситуаций и т.п., потому что естественным образом IBMовский софт и аналоги обеспечивают немного разные гарантии для разных ситуаций и самое интересное в редизайне архитектуры приложения - как с этими несоответствиями поступили авторы. Точнее есть только про PostgreSQL и то что отказались от двухфазных транзакций, что намекает что консистентность данных стала в итоге хуже, но этому уделено слишком мало внимания.
p.s. собственно автор сказал что x86 лучше в рамках ответов на вопросы ("если взять современный процессор, то там 16 ядер на борту и 3 ГГц, естественно чудес не бывает"), то есть получится что цифрами не подтверждается, а мнением докладчика - опровергается.
Все так. Ну тогда было время такое, «мода на импортозамещение», что даже вот этот доклад пришлось сильно заманивать выступить, и мягко дорабатывать. Ну и даже затащить стек ява+постгрес, и чтобы на этом что-то шевелилось (проблемы с нативными хешами на яве, спинлоки в пг) — было как бы ну если не подвиг, то саксесс-стори.
Теперь же, если мне в на ревью попадутся рассказы о реализованных на Э. инфосистемах, то, конечно, буду требовать раскрытия этих вопросов.
На НСКФ (год не помню) показывали цифровой тактический командный пункт на Эльбрусах. Такой грузовик, в который собирается информация со всего поля боя.
А для Эльбруса нет profile guided optimization? Это могло бы частично исправить беды статической оптимизации. Кончено, ценой заметного усложнения процесса разработки, но кому нужна производительность осилили бы.
Есть.
Если он ещё и работает :), то часть жалоб эту статьи не в тему. По крайней мере ассемблер стоило попробовать получить с PGO.
Это каким образом, если никакой возможности получить код и запустить его на Эльбрусе у меня нет?
Что касается PGO - так только на это и расчёт, профиль сильно помогает Эльбрусу. Но во-первых, цифры Spec CPU 2006/2017 Алексей наверняка привёл с профилем (он же не написал точно, но зная, как в МЦСТ всё меряют, подозреваю, что это именно так). А во-вторых, в реальных проектах почти никто с профилем не собирает. Это большая дополнительная нагрузка по сбору профиля и перекомпиляции, и поддержке всего этого хозяйства. Да и часто профиль мало помогает, но это уже тема для отдельных статей.
Интереса ради, не могли бы вы пересобрать код с pgo? Всё-таки она в мейнстрим хоть и медленно, но входит.
UPD. Пардон, вопрос конечно же адресуется @alexanius
Это вы загнули. В реальных проектах очень много кто собирает с профилем даже для x86. Когда нужна производительность, затраты окупаются.
Есть, но с некоторыми тонкостями. Недавно был доклад альтов → http://0x1.tv/20210617J
Статья хорошо читается для непосвященных, но не объясняет почему у Эльбруса нет перспектив. Не понятно откуда автор взял предельную частоту в 2.5-3.0 ГГц. Каким образом VLIW препятствует наращиванию частоты? Возможность работы Интела на 5ГГц - это прежде всего многолетний опыт и деньги, а не формат команд.
Приведенные в начале статьи проблемы - это текущие проблемы, которые решаются.
На счет сложностей с динамическими языками согласен, тут проявляются преимущества OoO.
P.S. До выхода Apple M1 на форумах многие "кричали" что ARM не может быть высокопроизводительным, но M1 на 3.2 ГГц превзошел x86 на 4.5ГГц.
я конечно не эксперт, но:
1)архитектура влияет на частоты. Я уже не помню конкретные примеры, но разные процессоры на одном техпроцессе показывают разные частоты. И дело не в напряжении\ТДП. Даже статью про это читал но почему так уже не помню.
2)
а)не видел выкриков о том, что ARM не может быть высокопроизводительным. Видел сообщения о том, что хз можно ли ARM сделать высокопроизводительным. Типа "вот здесь есть проблемы, решаемые или нет-хз.
б)М1 превзошёл x86 на 4.5ггц (не утверждаю, но и не возражаю) Вот только превзошёл не ARM а узкоспециализированные ускорители вычислений в M1. С точки зрения энергоэффективности решение огонь. А вот с производительностью.... возникают провалы в задачах которые не ускорены. Для ноутбука провалы не столь катастрофичны. А вот сможет ли такой подход сработать в hi-end PC-смотри п 2а
Тут вся проблема в скорости света,
Слишком маленькая она, поэтому чем короче синхронные участки процессора тем большей частоты можно достигнуть, накой нибудь 4004 выполненный по новейшему техпроцессу и на 11 ГГц будет работать.
Зы у vliw в этом плане особых недостатков нет если не намудрили с конвейерами
влияет, скорость света - это предел распространения эм волны, для меди 23см на 1нс, для 10Ггц на размере чипа 10мм сигнал инвертируется, синхронность развалится, для примера на ПЛИС постоянная проблема протащить сигнал через кристалл
Ваше заявление звучит примерно как «скорость света ограничивает предельную скорость современных пассажирских самолётов». Вообще да, но на самом деле — нет.
вы путаете теплое с мягким (макро с самолётами и микро мир с электронами), если вам нужно передать сигнал через весь кристалл размером 10-20мм при частоте 10Ггц (реальная нормальная частота), и при этом обеспечить синхронность выполнения, вы вынуждены будете вставлять промежуточные регистры, так как только задержка распространения составит сотню пикосекунд. Это без учёта емкостей, которые так же есть в схеме.
Скорость света фундаментальный фактор ограничения производительности синхронных схем в общем и процессоров в частности.
ps: скажу банальную истину, что скорость света в принципе фундаментальная постоянная одна из шести и считать, что она не влияет по меньшей мере наивно.
если вам нужно передать сигнал через весь кристалл размером 10-20мм при частоте 10ГгцТо вам стоит попробовать посчитать длинную линию, которая получается, и понять, что скорость света ни при чем, а промежуточные регистры нужны для того, чтобы не драйвить RLC, а не потому, что скорость света что-то ограничивает.
Скорость света фундаментальный фактор ограничения производительности синхронных схем в общем и процессоров в частности.Да конечно. Только современные процессоры от этого ограничения очень и очень далеко, поэтому никакого практического влияния оно не оказывает.
давайте посчитаем длинную линию:
скорость света в меди 2.3*10^8м/с или 2.3*10^11мм/с, что даёт поворот фазы на 180 градусов уже на около 10мм расстояния, если вы попробуете сделать push eax, а потом pop eax на процессоре, а кэш у вас отнесен на 5мм, то вероятно биты придут уже перепутанные и вы должны будете поставить условный nop, что бы дождаться, пока сигнал дойдёт до кэша и вернётся обратно
вот что сказал Мур в одном из своих интервью
"I remember we had Stephen Hawking, the famous cosmologist, in Silicon Valley one time. He gave a talk, and afterward he was asked what he saw as the limits to the integrated circuit technology.
Now this is not his field, but he came up with two things: the finite velocity of light and the atomic nature of materials."
"Помню, однажды в Кремниевой долине у нас был Стивен Хокинг, знаменитый космолог. Он выступил с докладом, а затем его спросили, в чем, по его мнению, есть пределы технологии интегральных схем.
Это не его область, но он предложил две вещи: конечная скорость света и атомарная природа материалов. И я думаю, что он прав. Сейчас мы очень близки к атомному ограничению. Мы используем всю возможную скорость, но скорость света ограничивает производительность. Это основы, и я не понимаю, как мы когда-нибудь сможем их обойти. И в следующей паре поколений мы будем прямо против них."
https://spectrum.ieee.org/gordon-moore-the-man-whose-name-means-progress
а кэш у вас отнесен на 5ммто удельное сопротивление меди 0,01707 Ом·мм²/м, то есть линия длиной 5 мм, толщиной 10 нм и шириной 50 нм будет иметь сопротивление порядка 2 кОм и паразитную емкость под пикофараду, что даст нам даже на модели RC-цепи с локализованными параметрами задержку в 2 нс, а в реальности еще больше, и это при условии, что у вас выход логического вентиля вообще сможет драйвить такого монстра (а он не сможет).
Так что я не понимаю, о каких вообще 10 ГГц вы говорите, если вы в такой ситуации и 200 МГц не сможете в кремнии иметь.
В каких задачах возникают провалы? Только если векторизованный код с AVX512.
Какие, например, узкоспециализированные ускорители вычислений в M1? И как они влияют на высокую скорость работы JDK, 7zip, Safari и прочих приложений?
возможно мне стоило выразиться мягче, не как провал, а как производительность ниже ожидаемой по заявлениям на презентации.
Я обзор смотрел по выходу m1, результаты запомнил, конкретные тесты\блоки нет. Мне техника apple неинтересна. ЕМНИП там было ускорение редактирования видео.
возможно мне стоило выразиться мягче, не как провал, а как производительность ниже ожидаемой по заявлениям на презентации.
Да в общем-то нет, как заявляли что будет холоднее и быстрее - так примерно и вышло.
Я обзор смотрел по выходу m1, результаты запомнил, конкретные тесты\блоки нет. Мне техника apple неинтересна. ЕМНИП там было ускорение редактирования видео.
Вот не только в редактировании было. По факту прирост был везде. Естественно в плане видеокодирования - аппаратные блоки сыграли свою роль, но вот прирост в скорости работы браузера - чисто за счет микроархитектуры. Также и в других задачах, типа компиляции и даже, как ни странно, в обработке фото (фотшопы, лайтрумы и прочие capture one на M1 везде где не задействован GPU работают быстрее чем старые Macbook Pro 16" на Intel'ах, но вот где GPU-интенсивные задачи, там они проседают).
Собственно гипотеза "да это все из-за ускорителей" была в начале, пока была доступна только официальная презентация (в ней упор был на видеоредакторе сделан), но этот миф развенчали как только у людей устройства появились на руках.
Вот только превзошёл не ARM а узкоспециализированные ускорители вычислений в M1
Это миф кстати. Специализированных ускорителей там не так много и их наличие не объясняет почему он быстрее, например, в компиляции софта.
Память распаяна на плате и быстрая. С одной стороны - не апгрейднешь через пару лет. С другой стороны - купишь новый ноут. С третьей - получилось показать огромную производительность.
Распаянная память свойство многих ноутбуков и на скорость это не так чтобы сильно влияет на производительность. Apple ее вообще на ту же подложку что и чип разместила, но не очень понятно как это влияет на производительность (тайминги памяти не публикуются же, а частоты вполне обыденные для LPDDR4X, ничего особенного в них нет). Плюс память - не является акселератором как таковая.
И везде видно, что VLIW решения всегда своим конкурентам уступают по частоте.
Ну такое себе. Вы вспомните ещё "перфоманс рейтинг", которые для атлонов вводили, когда у них частоты были меньше, чем у пентиумов.
Ну такое себе.
В статье же отдельно разобран про IPC и про мегагерцы.
Тут и IPC хуже получается (в среднем) и частоты ниже - то есть не взять ни тем, ни другим.
IPC хуже получается
На конкретном примере в конкретной версии компилятора. Но всё же надо понимать, что в случае с x86 — это фактически потолок, обусловленный железом, а для e2k — это вопрос оптимизации на стороне компилятора.
Само собой, другие проблемы от этого не уходят. Закрытая архитектура, закрытый компилятор и сложности с доступом к оборудованию явно никак не помогают развитию.
Автор делает довольно большой акцент в сравнении на частоту, хотя сам же говорит, что частота определяется архитектурой. И не упоминает, например, что x86 не будет работать на 5ГГц, если его загрузить операциями AVX-512.
Ну достигают и достигают, а дальше что? Graviton, если не ошибаюсь, максимальную частоту имеет те же 2.5-3ГГц и при меньшем TDP.
IPC — это тоже довольно размытая метрика. Инструкции разные бывают. Операции над целыми числами и над числами с плавающей точкой могут разными блоками выполняться и одних за такт может выполниться больше, чем других. А есть ещё SIMD и прочие интересные вещи.
Я не говорю, что автор не прав, но такое ощущение, что он почему-то на МЦСТ зуб точит и точно так же срезает углы в удобном ключе, оставляя полуправду, как это делал автор предыдущей статьи. Только наоборот.
На конкретном примере в конкретной версии компилятора. Но всё же надо понимать, что в случае с x86 — это фактически потолок, обусловленный железом, а для e2k — это вопрос оптимизации на стороне компилятора.
Теоретически? Да, конечно, компилятор повлияет. Практически? Компилятор делают около 20 лет (если не больше), результат до сих пор плачевный.
Автор делает довольно большой акцент в сравнении на частоту, хотя сам же говорит, что частота определяется архитектурой. И не упоминает, например, что x86 не будет работать на 5ГГц, если его загрузить операциями AVX-512.
Потому что на самом деле будет, но и время и частота зависят от модели цпу и длительности нагрузки. Современные десктопные CPU при нагрузке не более чем на 4 ядра совсем не сбрасывают частоты под avx-512, а при полной нагрузке сбрасывают до 4.8 ГГц. То есть ограничение связано в первую очередь с удержанием процессора в пределах заявленного TDP. К тому же в примере автор исключал векторизацию специально.
IPC — это тоже довольно размытая метрика. Инструкции разные бывают. Операции над целыми числами и над числами с плавающей точкой могут разными блоками выполняться и одних за такт может выполниться больше, чем других. А есть ещё SIMD и прочие интересные вещи.
Так посмотрите еще раз что привел автор. Он привел и количество тактов на итерацию (эта величина не зависит от частоты) и количество инструкций за такт (как мерило эффективности). По сути автор показал что:
Цикл выполняется дольше (в тактах)
Количество инструкций больше
Темп выполнения инструкций ниже
Тактовая частота ниже
Да, это не общий случай (то есть будут задачи где у Эльбруса будет высокий IPC), но это обычный ничем не примечательный цикл, подобные которому будут встречаться повсеместно в реальной жизни.
срезает углы в удобном ключе, оставляя полуправду
Автор скорее срезает углы в местах где объяснение простой вещи потянет на двухчасовую лекцию (например про частоты для VLIWов), что не совсем хорошо если честно, но я не знаю как иначе кроме как оставлять эти вещи на откуп читателям.
Хотелось бы, чтобы Эльбрус вышел на коммерческий рынок. Только на госзаказах не выжить.
Похоже пора снова доставать попкорн :)
с учётом того, что производительность современных процессоров уже упёрлась в потолок и замещается многоядерностью, то будут выигрывать архитектуры, мне так видится, что ARM уже догоняет x86, другие архитектуры подтягиваются и интересно, как всё будет выглядеть в пределе...
можно ли уже спрогнозировать этот предел производительности одного ядра для каждой архитектуры? (графики там может какие есть?)
В какой потолок упёрлась? Каждое поколение пользовательских процов всё ещё наращивает производительность отдельно взятого ядра в том числе.
незначительно, я связан с задачами ориентированными на однопроцессорные вычисления, в частности трассировка ПЛИС, так вот с 2010 года скорость трассировки зависит только от частоты ядра, на текущий момент частота ядра уперлась где-то в 5ГГц и соответственно проекты как комплились 60 минут в 2012 году, так и компилятся чуть быстрее скажем около 40минут. Рост в моих задачах составил менее 2х раз, хотя количество ядер возросло это да... И да для конкретно задач у нас производительность семейств для i3, i5, i7 и i9 пропорционально только скорости одного ядра, а частота работы все же ограничена... это я к чему? есть шанс у конкурентов ARM, A1 и остальных догнать по производительности x86 архитектуру и частично её заместить её, а та архитектура, что будет изначально более производительная при одних и тех же технологиях может чуть вырваться вперед...
я совершенно не могу понять, почему трассировку ПЛИС не вынесли на GPU, это должно было на порядок сократить время на перекомпиляцию... но, к сожалению, Quartus (тот же intel, какая ирония...) компилит все только на одном ядре проца игнорируя GPU...
GPU не спасут, потому что значительная часть вещей в этих алгоритмах параллелится либо плохо, либо никак.
Можно поподробнее, кто там куда уперся? Вон у AMD их Zen 3 в конце 2020 года увеличил IPC в среднем на 19% по сравнению с Zen 2 июля 2019. При сохранении TDP, техпроцесса и прочего. Разница в частоте тоже в пределах 0.1-0.2ггц
я как и любой другой могу только рассуждать исходя из своего видения, в частности для наших задач применим только Intel, потому что AMD при тех же задачах проигрывает от 20% и более. Задача - компиляция под ПЛИС, которая занимает очень много времени - часы. К сожалению, она не занимает все ядра, а только одно ядро. Последние тесты по части выбора процессора мы проводили в 2020 году, AMD проигрывало и значительно, если в это году Zen 3 будет лучше, то это отлично. В наших очень специфических задачах мы видим, что зависимость только от частоты ядра и производителя (архитектуры).
опять же предположу, что есть взаимное влияние тестов на направление оптимизации процессоров, в частности процы профилируют, что бы они получали большее количество попугаев на этих самых тестах, что не меняет производительность на прикладных задачах.
Максим, спасибо за статью. Но у меня остался один вопрос. Как то так получилось, что буквально месяц назад, в одну бессонную ночь, ко мне пришли флешбеки из конца 90х - начала 2000х. Как раз у университете учился. И тогда на "широкую команду" чуть ли не молились, предрекая ей светлое будущие. Которое не наступило. И вот в разговоре самого с собой, решил проанализировать ситуацию. Пришел к выводу, что VLIW, помимо расхода памяти, что критично но не фатально, просто не может в нормальную JIT компиляцию, на которой базируется почти вся современная инфраструктура прикладного программирования. Но вот чего не могу понять, так это ограничений на максимальную тактовою частоту. Упрощенно, VLIW процессор - это набор относительно простых IP ядер на стероидах. Ни модуля предсказаний, ни сложного дешифратора команд там нет. По сути, сама команда описывает что то вроде "подключи вход А АЛУ1 к Р1, вход Б к Р2, выход к Р3 и выполни операцию сложения". Конечно, не все так просто, но в целом - смысл такой, или я не прав? Вот что ограничивает частоту? У меня только одна мысль - сложность или невозможность реализации относительно длинного и эффективного конвейера + жесткая связь с компилятором для его эффективной утилизации. Просто интересно мнение специалиста.
сложность или невозможность реализации относительно длинного и эффективного конвейераЭто правильная мысль. Если начинать делать конвейер глубже, то паковать команды в пачки станет сложнее, и производительность упадет. А с неглубоким конвейером нельзя наращивать частоту.
Спасибо за уточнение. Да, часто так бывает, что на бумаге все гладко, а мелкие нюансы портят всю картину. Прискорбно, что столько усилий, можно сказать, пропадают зря, но не могу с Вами не согласиться. Порой дешевле и разумней вовремя "закопать стюардессу". Возможно, даже не закапывать, а, снова же, на мой взгляд, немного упрощенный VLIW неплохо бы чувствовал себя в специализированных системах жесткого реального времени. Где важна не супер производительность, а детерминированное время исполнения инструкций. И да, а что там с асинхронными прерываниями? Как процессор "узнает", когда разорвать команды и перейти в обработчик? Прошу прощения за терминологию, не процессоростроитель, но если RISC/CISK, пусть внутри и разгребает поступающие команды на микро операции, он "знает", что вот этот "mov" пришел последним, далее как разработчик микроархитектуры решит, флашить конвертер и выполнять прерывание или отработать то, что есть, параллельно загружая код обработчика в кэш, то как понимаю, в VLIW, допустим, условный "LD" может начаться, а завершиться через 50 - 100 тактов, и где рвать выполнение программы - неизвестно...
VLIW действительно хорошо себя чувствует в задачах ввода и обработки данных - допустим, преобразования того, что передает сенсор камеры - в привычное нам изображение. Но это в устоявшемся режиме - после каждого запуска вычислений ему нужно "разогнаться". И, разумеется - никаких прерываний, переключения контекстов и так далее.
1000 извинений, был крайне не внимателен и перепутал Вас с автором поста... Не судите строго. Просто в предыдущих публикациях от Вас было тоже много дельных комментариев, и при первом взгляде на ник, как то вырвалось "arm", но это уже моя профдеформация...
В вопросах частоты, я, к сожалению не эксперт (моя область компетенции это компиляторы, архитектуры и микроархитектуры). Из того, что я вынес из общения с экспертами - проблема в более коротком размере конвейера, его ширины и необходимости уметь быстро передавать через байпасы значения в большое количество портов и для большого количества регистров. Из-за этого в Эльбрусе, например, есть 2 кластера внутри одной ШК, между алу которых нет байпасов.
Спасибо за ответ и 1000 извинений, понимаю, что не булькают, перепутал ответ пользователя "amartology" с Вашим. И предыдущий комментарий был адресован Вам. Максим, Валерий, извините, впредь буду внимателен и не идентифицировать пользователя по первой букве ника...
Verbrennen und vernichten
Verhütung verboten
Verstreuen sie Gebote
Verfolgung verkünden
Vergebung der Sünden
Verbreiten, sich vermehren
Im Namen des Herren
Саруман и Саурон.
Очень удобно, ага.
В общем очередной распил эти все "ответы интЫлам и амудэ"
Кстати со сложностью ассемблера не соглашусь. Он необычный, кого-то можно даже удивить им, но можно ли сравнить его с ассемблером x86 и сказать что он заметно сложнее? По-моему опыту с ними двумя как-то нет. Сложно для этого писать компилятор, конечно. А куда без компиляторов денешься...
Я знаю ассемблер e2k и x86 примерно на одинаковом уровне. Так вот, чтобы найти код горячего цикла в приведённом в статье примере мне пришлось потратить минут 10. А для x86 где-то 10 секунд. Тут можно в теории устроить такого рода эксперимент более массово. Но давайте объективно, мне кажется результат предсказуем.
В примере результата компиляции под e2k широких команд 6 (широкие команды выполняются за такт, в ассемблере они в фигурных скобках, согласно мануалу), а не 13. Отсюда, неверный вывод, что это займет 13 тактов (должно быть 6).
Хотя у x86 получается всего 8 операций, скорее всего он выполнит их быстрее, чем за 8 тактов. Так что примерно паритет, Эльбрус чуть проиграет из-за более низкой частоты.
Но эти числа (6 и 8) слишком маленькие, чтобы делать какой-то далеко идущий статистический вывод. Хотелось пример хотя бы немного сложнее.
Да и в целом в статье много сумбура и манипуляций
Нет, 13. Вы не учли операции nop, которые приводит к исполнению процессором пустых тактов. Посмотрите внимательно на ассемблер приведённых ШК
Да, вы правы, спасибо за подсказку. Действительно nop-ы добавляют 7 тактов. Судя по всему, они используются для какой-то синхронизации load-store.Тема nop-ов для синхронизации в e2k мало где прояснена, и требуется дополнительный анализ, насколько это влияет.
Впрочем, в других примерах https://ce.mentality.rip/ выдает меньше задержек nop-ами, например, для процедуры Sort 28 задержек nop на 36 широких команд (против 7 на 6). Так что по-прежнему кажется, что стоит проанализировать код посложнее, прежде чем сделать выводы
Цифры Spec'ов и других бенчмарков, как мне кажется, достаточно красноречиво показывают, что происходит на "коде посложней"
Отсюда, неверный вывод, что это займет 13 тактов (должно быть 6).
Кому должно?
Даже как-то забавно, как несколько человек, которые в первый раз увидели E2K асм (а может и вообще), начинают «учить» эксперта, который с ним как бы годы проработал :)
Судя по всему, они используются для какой-то синхронизации load-store.Не знаю как у Эльбруса, а у VLIW процессоров в целом не любят делать интерлоки, поэтому нопы нужны для корректности выполнения. Таким образом задача отслеживания конфликтов в конвейере перекладывается на компилятор.
ECE 4750 Computer Architecture; Topic 13: VLIW Processors
стр.5
Constant operation latencies are specified
• Architecture requires guarantee of:
– Parallelism within an instruction => no cross-operation RAW check
– No data use before data ready => no data interlocks Я смотрю, вы дописали комментарий. В x86 эти 8 операций исполнятся за 3 такта. В статье же всё подробно разобрано
Спасибо за статью. Очень интересно и познавательно. Слежу за развитием.
Я думаю, что ладно бы с ней с производительностью - вы сделайте платформу доступной любому желающему, а энтузиасты найдутся и портируют что надо и напишут новое и оптимизируют. Проблема Эльбруса - проблема его доступности.
А кто-то занимается в отечестве RISC-V? Просто как по мне открытая архитектура даёт массу возможностей пользоваться чужим опытом. Что как по мне позволяет экономить на человеческих ресурсах у нас ведь не так много специалистов чтобы тянуть архитектуру процессора с нуля а вместе с ней и софтверную часть.
Абсолютно верная мысль. В России я знаю 2 компании, разрабатывающих Risc-v ядра - это Syntacore и CloudBear. Я упоминал про них в своей статье про пути развития отечественных процессоров
Есть мировой рекорд "максимальная частота компьютерного процессора", который, вроде как, все еще принадлежит AMD FX 8,429 ГГц. Ну и кто скажет,что данный процессор производительней современных?
Половина данной статьи посвящена как раз описанию того, насколько Эльбрус проигрывает по микроархитектурной скорости и почему
Кажется, людей немного коробит форма подачи: тон/текст создают впечатление, как будто вы подразуемеваете связь "раз частота ниже, значит, процессор медленнее" (что, как вы сами понимаете, не является правдой само по себе без каких-то оговорок и уточнения). Если бы была пара предложений в духе "производительность процессора складывается из частоты и instructions per cycle, давайте посмотрим, почему там и там всё плохо у Эльбруса" (максимально утрированно), восприятие было бы лучше.
А разве это не так? Причём борьба не только за гранты и субсидии, но и за административный ресурс для устранения конкурентов хотя бы с доли рынка.
Как говорится, с автоматом и любым процессором - можно продать больше, чем просто с хорошим или даже отличным процессором.
Конечно грустно... А может еще ж и скандально стать, поскольку без официально спиратченного софта (это каперство такое, что-ли?) на нём нативно собранные приложения не работают.
Но это проблема потенциально решаемая (говорят, что дело в закрытости системы команд - если "хозяина" убедить, то проблему решить можно), а вот архитектурные особенности уже без "автоматчиков за спиной у покупателей" труднее объехать.
И вместо поливания грязью друг друга было бы неплохо организовать что-то что подталкивало бы к творчеству.С одной стороны, людей много, а денег мало, и грызня неизбежна. С другой стороны, уже через месяц будет конференция «Микроэлектроника», на которой соберутся практически все российские разработчики процессоров.
Обзорное заседание № 2
«Проблемные вопросы и актуальные задачи создания перспективных
отечественных вычислительных комплексов и ЭКБ для их реализации»
Модераторы:
Горбунов Максим Сергеевич (НИЯУ МИФИ)
Хренов Григорий Юрьевич (АО «Байкал Электроникс»)
Докладчики:
1. Хренов Григорий Юрьевич (АО «Байкал Электроникс»)
2. Бычков Игнат Николаевич (АО «МЦСТ»)
3. Аряшев Сергей Иванович (ФГУ ФНЦ НИИСИ РАН)
4. Редькин Александр Николаевич (ООО «Синтакор»)
5. Мякочин Юрий Олегович (АО ПКК «Миландр»)
Эксперты:
Мохнаткин Алексей Эдуардович (АО НТЦ «Модуль»)
Осипенко Павел Николаевич (ООО «ИВА ТЕХНОЛОДЖИС»)
Семилетов Антон Дмитриевич (АО НПЦ «ЭЛВИС»)
Козлов Александр Владимирович (ООО «КЛАУДБЕАР»)
Формат научной/индустриальной конференции гораздо больше способствует продотворной работе, чем формат срача в интернете.
К сожалению, это тоже ничего не изменит.
Тут уже говорилось, что главное не в "крутой" архитектуре. Выигрывают простота, массовость (дешевизна), доступность - открытость, масштабируемость (в т.ч. отсутствие технологического тупика) и т.п. "Простой" Ethernet обошел намного продвинутые сетевые технологии, включая ATM, IBM совместимость и х86 похоронили куда более совершенные технологии. Не "крутизна", а оптимальность технологии - главное (оптимальность по указанным критериям, включая цену).
Но и оптимальность технологии - тоже вторично. Важнее не научная конференция, а "государева воля", т.е. реальная, а не провозглашаемая (показушная) промышленная политика государства. Текущая власть этого (развития) не хочет \ не может. Было много провальных проектов "народный телевизор", "народный автомобиль" и т.п. Народный (отечественный) микропроцессор \ компьютер - это реальность (это далеко не технологическая проблема), но не с текущими правителями. Вопрос технологий вторичен, поэтому "сушите весла". Наивно думать, что какая-то конференция изменит политику, ведущуюся на протяжении 30-ти лет.
Да, по обсуждать на хабре VLIW vs RISC - интересно, но нужно понимать, что текущая политическая система не совместима с научно-техническим прогрессом (НТП), включая микроэлектронику. Это правительство максимум на что способно - подобные проекты "завалить деньгами", что периодически и делает, только это не помогает. Хотелось бы оценить, сколько денег похоронили в Эльбрус, насколько понимаю - "денег не жалели" (считать нужно и все субподряды, особенно НИОКР, где головняки - военные институты).
В НТП первичны не технологии и деньги (в стране любые бюджеты легко и быстро разворовываются), а грамотная политика, включая контроль и ответственность чиновников. Утвержденная правительственная программа, кажется 2015 года, включала к 2020-му какое-то безумное количество внедрённых Эльбрусов. Где они? Только на бумаге остались.
Независимо от теоретических недостатков\преимуществ VLIW для процессоров общего назначения, "Эльбрус" был бы значительно успешней если бы разработчик открыл бы архитектуру и обеспечил бы программистов полноценными инструментами разработки и качественной документацией.
Это все есть. Еще и консультации живых экспертов обеспечиваются.
Сейчас заглянул на сайт производителя (очень винтажный), там документацию найти невозможно. Почему я могу за секунду найти исчерпывающую информацию по системе команд и устройству x86, ARM, MIPS, RISC-V, SPARC и прочим без ухищрений?
Спасибо "Яндексу", нашел статью от 2020 года, где рассказали что МЦСТ открыл доки. Там же была ссылка на Руководство по эффективному программированию на платформе «Эльбрус»". В разделе "Статьи". И это всё? Для самого завалящего китайского процессора есть десятки даташитов, мануалов, Application Note, Whitepaper, SDK и примеры в репозиториях. Даже неловко как-то. Эльбрус недружелюбен к разработчику и неконкурентоспособен ни производительностью, ни ценой, ни удобством использования. Единственный механизм его продаж это прямое принуждение государственным лобби.
Создаётся впечатление, что МЦСТ существует в каком-то своём ограждённом от внешнего мира пузыре, как будто они не в курсе общепринятых в индустрии практик, и им кажется, что это норм. Как какой-нибудь советский НИИ не был (и не мог быть) в курсе международных стандартов и практик. Что довольно странно, учитывая их тесные связи (хоть и в прошлом) с Sun Microsystems, отраженные даже в их названии.
Ну они в принципе и выросли из ведомственного НИИ, с единственным заказчиком в лице государства. Коммерческие контракты в 90х это досадное недоразумение которое они рады забыть побыстрее.
МЦСТ не понимает что качественная и доступная докуменация важнее чем "комментарии живых экспертов". Доки это то что позволяет студенту в Австралии написать свой RISC-V, студентке в Венгрии написать свой компилятор под RISC-V да так, что программа, скомпилированная вторым, запустится на первом без проблем, хотя эти двое никогда не встречались и не консультировались.
Подменять экспертами доки это всё равно что вместо чертежа на производство отправлять гонца, который на словах и на пальцах расскажет как точить вал для турбины.
С точки зрения разработки и производства — архитектура принадлежит кому то в МЦСТ и выпускать эмуляторы, аналогичные по архитектуре процессоры и так далее — незаконно?
С точки зрения разработки системного ПО — ассемблер не предоставляется вообще, предоставляется не полный с ограничениями, ..? Возможно ли создание своего компилятора (технически, юридически) под данную архитектуру?
С точки зрения разработки прикладного ПО — доступность SDK, компиляторов, инструментария, эмуляторов, ...?
Архитектура закрыта. Её принадлежность на самом деле вопрос не очень понятный. Но давайте считать, что она принадлежит МЦСТ
В принципе, с точки зрения легальности, нет особых проблем разрабатывать системный софт, включая эмуляторы, компиляторы и т.д. Проблема в том, что в ситуации закрытости архитектуры и отсутсвия необходимой документации - это в действительности нереально. Именно поэтому разработкой системного софта по факту занимается только само МЦСТ (ну плюс тех, кого МЦСТ напрямую под это наняло)
Это объёмный вопрос. Главная проблема тут на мой взгляд - это банальная невозможность просто взять и купить Эльбрус - его нет в свобоной продаже. Понятно что в такой ситуации развивать экосистему прикладного ПО сложно. Какое-то прикладное ПО есть. Компилятор предоставляется МЦСТ. Дебаггеры, перфы и пр. - что-то есть, но я не могу сказать, насколько оно адекватно по функционалу и надёжности. Симуляторов насколько я знаю в открытом доступе нет. Внутри МЦСТ есть свои симуляторы, но они вроде не доступны вовне.
Простим автору его неинформированность .... Для Arm существуют .... ExaGear
А вот это очень странно. Вы сами-то пробовали поискать, что это за такой ExaGear? У меня все результаты поиска выходят либо на eltechs.com, либо на elbrus-technologies.com
Эльбрус Технологии — это молодой высокотехнологичный стартап по разработке программного обеспечения
Наш проект — это двоичный транслятор, позволяющий запускать приложения для обычных настольных ПК и процессора x86 на энергоэффективных процессорах ARM без каких-либо изменений.
Вы уверены, что ни вы лично, ни @alexanius не знаете разработчиков ExaGear даже и лично? Название, если не попытка выехать на чужом хайпе, как бы символизирует...
Я не очень понял суть претензии. Я являлся CTO компании Эльбрус Технологии и являюсь непосредственным разработчиком и архитектором ExaGear. Вполне очевидно, что я понимаю о чём идёт речь.
В статье про это ни слова же, откуда остальные могут знать, что вы знаете (но не говорите) ?
Но тем лучше.
Я правильно понимаю, что название вызвано тем, что ядро ET составили люди, ушедшие из МЦСТ ?
Если да, то
такая информация напрямую относится к теме разговора и должна быть упомянута в статье
такая информация должна быть распространена среди "оставшихся в МЦСТ", и в том числе Алексея: это ненормально если в МЦСТ не знают о технологиях/компаниях отпочковавшихся от МЦСТ
Мне казалось (и сейчас так кажется), что данный вопрос не имеет отношения к теме дискуссии. Иначе у нас тут будут исторические опусы, а не техническое обсуждение.
Что касается:
такая информация должна быть распространена среди "оставшихся в МЦСТ", и в том числе Алексея: это ненормально если в МЦСТ не знают о технологиях/компаниях отпочковавшихся от МЦСТ
Вряд ли эту претензию можно адресовать лично мне. Но тем не менее, в МЦСТ многие люди вполне в курсе об Элтехе, и сдаётся мне, что Алексей тоже.
данный вопрос не имеет отношения к теме дискуссии
В идеальном мире - да. И в этом идеальном мире вы бы не проезжались по "неинформированности" вашего оппонента. Оставили бы это целиком за скобками статьи.
Но раз уж вы решили проехаться по нему лично, то IMHO сказав А, говорите и Б.
Или не упоминать вообще, или с конкретикой достаточной, для конкретного обсуждения.
>> информация должна быть распространена среди "оставшихся в МЦСТ"
Вряд ли эту претензию можно адресовать лично мне.
Да, к вам другая претензия: что упомянув в статье историю с Э.Т. косвенно, вы не проговорили, чем конкретно Алексей вас "удивил". А конкретно эта - к МЦСТ в целом и Алексею, как его части.
все статьи прочитал, но т.к. не являюсь специалистом в микроархитектурах, прокомментировать технические моменты не могу... и кто прав не знаю...
но вот то, что я почерпнул из ваших комментариев, сложилось у меня в какую-то неприятную картинку...
т.е. Вы 10 лет тренировались на кошечках в МЦСТ, делая двоичный транслятор, а потом ушли, унесли с собой кошечек и стали публично топить бывшего работодателя, продвигая "свой" продукт на конкурирующей платформе?
Ничего против Вас не имею, просто сложилось такое вот мнение на основе прочитанного... наверное Вы этого не хотели, когда писали все свои статьи и комментарии..
Вы 10 лет тренировались на кошечках в МЦСТ, делая двоичный транслятор, а потом ушли, унесли с собой кошечек
А вот тут подробнее, каких именно кошечек они унесли?
Они украли программу-транслятор и продают Хуавею контрафакт? А где тогда суды? Может быть хотя бы по торговой марке "Эльбрус" суды были?
А по умолчанию это: "работал мужик землекопом 20 лет, накачал на руках огромные бицепсы. А потом уволился и пошёл копать ямы в другом месте. И бицепсы свои, сволось, с собой унёс, а должен был работодателю отдать!
P.S. А если оторваться конспироложить, то может быть им этим транслятором, например, долги по з/п выплатили за 10 лет, например. Или сказали им "ваш транлятор - дерьмо, нам такого не надо, мы сделаем другой хороший! ах не надо, тогда мы его сами продвинем!" и разошлись, каждый со своими игрушками. И ещё можно вариантов напридумывать, на любой вкус, в которых никакой "кражи кошечек" не будет.
продвигая "свой" продукт на конкурирующей платформе?
Забавно, что напрямую они не конкурируют. А может быть и вообще, если в ExaGear сохранили/восстановили поддержку e2k, пусть непублично.
Это как если Microsoft или RedHat начнёт откровенно топить Alpha или ARM или SPARC, например, вместо захвата его, как потенциального рынка.
На основе имеющихся результатов Spec CPU 2017 можно, кстати, достаточно хорошо оценить микроархитектурную скорость своременных RISC/CISC процессоров. Она колеблется в среднем в диапазоне 2-3 SpecRate на один гигагерц одного ядра, переваливая за 4 для SpecFP для топовых решений (как для приведенного выше решения на базе AMD EPYC 72F3). Для Эльбруса же эта микроархитектурная скорость равна 0.9 для SpecINT и 1.4 для SpecFP.
Посмотрел результаты Spec CPU 2017 китайского процессора Kunpeng 920.
Для Kunpeng 920 эта "микроархитектурная скорость" получается
0.96 для SpecINT
0.79 для SpecFP.
А значит Эльбрус выигрывает у Kunpeng по этой характеристике для SpecFP.
Про частоту. Kunpeng - 2.6 GHz на техпроцессе 7 нм, а Эльбрус - 2.0 GHz на 16 нм. А на одинаковых 7 нм у них было бы почти равенство по частоте.
Или для другого нового китайского процессора Loongson 3A5000 заявили про 80 в SPEC CPU2006 для всего процессора, что на уровне Эльбрус-8С.
Так все "неамериканские" альтернативные процессоры все еще сильно уступают процессорам AMD и Intel. Но среди этих "альтернативщиков" цифры производительности у Эльбруса не такие провальные. А для FP у Эльбруса вполне приличная производительность на ядро.
Спасибо за интересный комментарий. Давайте на его примере разберём, в чём тут нюансы.
Kunpeng 920 - это процессор, у которого на одном чипе собрано 128 ядер. Чтобы такое сделать, надо иметь очень оптимизированные по TDP ядра, иначе вы не влезете в теплопакет. Для Huawei это лишь второй чип в серии, основанный изначально на Cortex-A57 если мне не изменяет память (т.е. как Байкал-М). Поэтому там просто пожертвовали определёнными вещами в пользу TDP, т.к. не было достаточно времени и опыта всё это вылизывать. В Kunpeng 920 всего лишь 2 FPU юнита, когда как в Эльбрусе их 6. И поэтому современных Эльбрусов поставить на чип 128 ядер нереально - слишком большое TDP.
Но проблемы Kunpeng как раз просто решаются - добавляются новые FPU юниты, оптимизируется микроархитектура. Следующая модель Kunpeng уже достигнет показателей в нижней границе текущих SpecRate для современных x86 (рост микроархитектурной скорости будет примерно таким же, как у Байкал Электроникс при переходе с Байкал-М на Байкал-S, ну может чуть меньше, т.к. что-то в Kunpeng 920 они всё же опимизировали). У Эльбруса же нет никаких перспектив роста, кроме увеличения частоты и размеров кэшей. Микроархитектура там жёстко приколочена к архитектуре и её переделка фактически будет означать создание новой архитектуры.
Ну т.е. случай Kunpeng'a это просто вопрос развития и оптимизации, если кратко. А у Эльбруса это потолок.
Вы хотя бы уточнили информацию и характеристики про главный процессор компании Huawei.
Процессор Kunpeng 920 - это 64 ядра, а не 128. И там три кристалла в каждом процессоре Kunpeng 920, как показали на cайте wikichip.
Так для Эльбруса на 7 нм тоже можно разработать аналогичные два кристалла по 32 ядра. Это вопрос финансирования разработки. И даже можно вписать все это в нужное потребление.
Да, у Эльбрусов есть потолок по производительности, но этот потолок выше нынешних неамериканских альтернативщиков по FP, хотя и ниже по INT. И этот микроархитектурный уровень Эльбруса те "альтернативщики" превзошли только сейчас, а микроархитектура Эльбрус существует 15 лет, почти не меняясь.
Если кому-то здесь нужен относительно высокий уровень производительности FP без использования американских процессоров, то ставка на Эльбрусы была вполне оправдана какое-то время.
Для Байкал-S воспользовались топовыми мировыми наработками ядер ARM Cortex, и поэтому Байкал-S выиграет у нового Эльбрус-16С, который базируется на разработках и идеях 20-летней давности. Но те же китайцы пока не имеют таких совершенных ядер, как Cortex и Neoverse. И поэтому отставание от китайцев у Эльбруса не такое большое, как отставание от Intel, AMD и ARM.
Да, про количество ядер согласен ( у них просто базовая версия сервера идёт с 128 ядрами, я поэтому постоянно путаю, 64 или 128).
Но все рассуждения о микроархитектуре Kunpeng и её развитии остаются в силе.
Huawei закрыли доступ на новый техпроцесс, и поэтому никакого развития линейки Kunpeng больше нет.
А Эльбрус есть только на старых техпроцессах, где ограничены возможности.
Наиболее близкий аналог для Эльбруса - это Loongson. У них тоже своя архитектура и микроархитектура. И новый серверный процессор Loongson - это аналог Эльбрус-16С. У них по 16 ядер. У Loongson - 12 нм, Эльбрус - 16 нм. Производительность в среднем тоже схожая. При этом китайцы постоянно улучшали и развивали свои ядра Loongson уже 20 лет. И эти китайцы в итоге сейчас вышли на уровень Эльбруса. Они чуть сильнее в INT, но слабее в FP.
Есть высшая лига производителей, которая получает новые техпроцессы, новейшие ядра, и большие объемы производства. А есть вторая лига, которая получает старые техпроцессы и не самые оптимальные ядра. Байкалу из высшей лиги досталось хорошее ядро A75. Поэтому они сделают рывок в новом Байкал-S. Но остальные самостоятельные игроки второй лиги не имеют такого преимущества из-за хорошего ядра.
В рамках "второй лиги" будут и все разработки на RISC-V. Там же уже есть еще Sparc от МЦСТ. Но такие процессоры RISC-V и Sparc все равно будут уступать в несколько раз представителям "высшей лиги". А значит не смогут конкурировать на равных с лучшими процессорами.
А Эльбрус - это нестандартное решение на VLIW, что дает перекос в сторону более высокой производительности FP в ущерб производительности INT, что и отличает их от всех других представителей "второй лиги".
risc-v и Sparc все равно будут уступать в несколько раз представителям «высшей лиги».Почему? ARM же не уступает х86. Это не вопрос системы команд, это вопрос выделенных на разработку микроархитектуры ресурсов.
ARM перестал уступать x86 потому что Intel задержал ввод в производство следующего техпроцесса в то же время, когда TSMC сделали правильную ставку на EUV и смогли внедрить более тонкий техпроцесс.
Других тут секретов нет. В наши дни в реализации процессоров принципиальной разницы между x86 и Arm уже давно нет.
Хотя x86, конечно, это довольно мерзкий набор инструкций.
ARM перестал уступать x86 потому что Intel задержал ввод в производство следующего техпроцесса в то же время, когда TSMC сделали правильную ставку на EUV и смогли внедрить более тонкий техпроцесс.Вы сейчас тактично умолчали о существовании производимых на TSMC AMD Ryzen.
У них не последний техпроцесс. 7нм против 5нм у apple, что только подтверждает мою мысль.
Вчера не было возможности нормально отписаться, пардон.
Итак.
Процесс есть, конечно же, у TSMC, а не у AMD. И TSMC последний процесс (5нм) продали Apple, а не столь богатая AMD пока использует позапрошлогодний 7нм техпроцесс TSMC с кусками 12нм от GlobalFoundries.
И сразу выясняется, что полноценные мощные ядра настольных AMD Ryzen работают так же, как мобильные ядра в Apple M1 с обрезанным теплопакетом.
С другой стороны, Intel выбрасывает безумные деньги в свои процессоры, но ничто не помогает ей в соревновании с AMD и Apple - техпроцесс отстает.
Тут, конечно, и талантливые инженеры, и все такое, но на первом месте стоит именно техпроцесс, позволяющий запихать больше логики в тот же квадратный мм.
Да, техпроцесс важен для таких применений, и для любой компании, занимающейся производством мощных микропроцессоров, разумно вкладываться в меньшие проектные нормы, но техпроцесс не является панацеей. Можно получать значительное преимущество за счёт архитектуры, используя одну и ту же технологию.
Можно получать значительное преимущество за счёт архитектуры, используя одну и ту же технологию.
При прочих равных разница действительно может проявиться. Помните, как продавали RISC в 80-ые? Простые инструкции позволяют делать быструю реализацию. Скажем, на 5% при прочих равных CISC-процессор проигрывает RISC-процессору.
Но история показала, что увеличение транзисторного бюджета и доступного теплопакета в полтора-два при переходе на более тонкий техпроцесс позволяет, к примеру, удвоить кэши на чипе. Или реализовать эмуляцию нужных инструкций. Или добавить вычислительных устройств - векторных ли, VLIW или еще каких.
Вот wikichip пишет, что при переходе с техпроцесса TSMC N7 (AMD Ryzen) на N5 (Apple M1) плотность размещения транзисторов увеличивается в 1.84 раза.
То есть при прочих равных можно пихнуть настолько больше памяти в чип, что конкретный набор инструкций вообще никакой роли не играет. Apple вот решила одновременно и тепла меньше выделять, и производительность нарастить.
Другими словами, дискуссия о производительности должна сводиться к техпроцессу.
Вот еще раз ваши слова:
Можно получать значительное преимущество за счёт архитектуры, используя одну и ту же технологию.
Реально почти никогда не бывает так, что соревнуются строго наборы инструкций и их реализации. Выигрывает тот, кто получил более тонкий техпроцесс.
Дискуссию про VLIW, RISC, CISC иже с ними ведется разработчиками процессоров не первое десятилетие. Что @Armmasterсовершенно верно заметил, так это тот факт, что после коллапса Itanium консенсус в области гласит: VLIW/EPIC это не перспективно, а перспективно RISC с расширениями в форме всяких там наборов векторных инструкций (SSE и компания).
Это может быть верно, может верно не быть. Я же готов утверждать, что это не важно.
Концепции это просто концепции, на практике же многие микроархитектуры, в том числе ARM или x86, эволюционируют. x86 начиналась как CISC, но со временем стала реализовываться как эмуляция на микрокоде. Монопольный доступ к последнему техпроцессу Intel обеспечивал (до недавних пор) этому неуклюжему набору инструкций абсолютное превосходство в производительности. В следствие чего CISC, считающийся архаизмом уже лет тридцать как, продавался без каких-либо проблем.
Почему так? Потому что практически важен только один параметр: объем производства чипа. Объем определяет цену производства. Цена, в свою очередь, через продажи определяет объем. Главный провал Intel последних десятилетий это не несчастный Itanium, а упущенный в пользу ARM рынок носимых устройств. Что в долгосрочной перспективе привело к появлению конкурентов с доступом к нужному техпроцессу.
Еще раз. Конкретный набор инструкций не так важен, как объем производства.
При неоходимости любой набор инструкций (в стиле CISC, векторные инструкции, VLIW/EPIC, бла-бла-бла) можно эмулировать микрокодом (см. эмуляцию AVX512 у AMD) и всякими там железными ускорителями. Важней продать как можно больше процессоров, что позволит снизить цену отдельного чипа.
И в этом смысле Эльбрус - та же история CISC. Он может быть хорош для вычислительных задач, и не очень хорош для более общих программ. Такие вещи важны только нам, программистам.
Но экономика полупроводникового производства имеет свои законы. И разработчики Эльбруса, как мне кажется, их вполне осознают: в масштабах нашего локального рынка только они сейчас имеют хоть какой-то объем, что позволяет показывать разумную цену отдельно взятого устройства.
PS мои слова подтвердит масса канувших в Лету процессоров, наборы инструкций которых концептуально давали 100 очков вперед x86: Motorola, Sparc, POWER, Alpha...
разработчики Эльбруса их правильно осознают — здесь сомнительно.
Очень даже осознают! МЦСТ лично платит тем больше за каждый напечатанный процессор, чем меньше партия.
достаточно хорошей, чтобы сравняться даже со средненькой, но мировой.
Не уверен, что в данном случае вообще идет речь о "сравняться". Я под прошлой статьей уже объяснял кому-то, что техпроцессов последних даже у Интела уже несколько лет как нет, и еще не факт, что появится. В вопросах производительности техпроцесс важней архитектуры. И никто никому этот самый техпроцесс не дает, а то и явно запрещает (см., к примеру, историю с Huawei).
Повторю свой тезис еще раз: любое конкретное решение в вопросах производительности процессоров не так важно, как использованный при производстве техпроцесс.
МЦСТ лично платитПлатит МЦСТ или бюджет Российской федерации?
техпроцессов последних даже у Интела уже несколько лет как нетОни есть у AMD.
Повторю свой тезис еще раз: любое конкретное решение в вопросах производительности процессоров не так важно, как использованный при производстве техпроцесс.Важна не архитектура и даже не техпроцесс. Важна софтовая экосистема. И все разговоры о прекращении изобретения велосипеда в пользу других решений — они в первую очередь про то, чтобы делать что-то, для чего не нужно писать весь софт самостоятельно.
Платит МЦСТ или бюджет Российской федерации?
Это вы к какому именно моему замечанию комментарий добавили? :-) Как МЦСТ, так и любые их конкуренты, будут питаться прежде всего из бюджета, что очевидно. Соревноваться на глобальном рынке с китайцами и китайе-тайваньцами бесполезно, очевидно же.
Важна не архитектура и даже не техпроцесс. Важна софтовая экосистема. И все разговоры о прекращении изобретения велосипеда в пользу других решений — они в первую очередь про то, чтобы делать что-то, для чего не нужно писать весь софт самостоятельно.
И тут мы вот-вот придем к мысли о том, что ничто и никому не нужно, потому что китайцы и так сделают лучше и дешевле :-)
Но если серьезней, то да, важно абсолютно все. С точки зрения производительности - техпроцесс. С позиции пользователей - софт. И даже критики не могут поспорить с тем, что в МЦСТ делают вполне достойный компилятор.
В статье речь шла о производительности, но не упоминался техпроцесс, именно поэтому я тут постарался раскрыть эту тему: разница в наборе инструкций делает 5% разницы в производительности, а вот техпроцесс - 30%.
Меня смущает в позиции противников Эльбруса следующее. 50 лет назад были в моде CISC с их почти высокоуровневым ассемблером. 35 лет назад - RISC. 25-30 лет назад появились векторные процессоры и VLIW. 20 лет назад EPIC пришел на смену VLIW, и появились GPU.
Создавай вы новый процессор 35 лет назад, то он был бы примитивным RISC. 20-25? Имел был VLIW или EPIC черты. 10? RISC + векторные инструкции + элементы VLIW.
Популярные наборы инструкций общего назначения вроде архаичных x86 и немолодых уже ARM реально содержат всю эту историю. Внутреннее устройство этих железок не отличается в практическом смысле. RISC-V, ARM, x86, MIPS... Оно все сводится к транзисторному бюджету (= техпроцесс), куда укладываются или не те же самые вычислительные устройства.
Так какая разница? Сегодня ветер дует в сторону ARM, завтра еще куда-нибудь. Мы каждый раз будем выбрасывать деньги на очередную моду?
Мы каждый раз будем выбрасывать деньги на очередную моду?Есть мнение, что на разработку процессора Байкал-М было потрачено радикально меньше времени и денег, чем на Эльбрусы, а результат как минимум не хуже. А если так, то зачем тратить больше?
Есть мнение
Существует много мнений. :-) Вот вы, к примеру, считаете, что разрабатывать самостоятельный набор инструкций - дело неблагородное.
на разработку процессора Байкал-М было потрачено радикально меньше времени и денег, чем на Эльбрусы
А я вот считаю, что МЦСТ за эти деньги проделали огромную работу, причем как техническую, так и организационную. А еще я тут много писал о том, что конкретный набор инструкций на фоне экономических аспектов производства процессоров играет в вопросах производительности незначительную роль.
МЦСТ сделали процессор, компилятор, портировали ОС и прикладной софт. Софт работает приемлемо быстро. Это уже очень и очень много.
Предвидеть же появление всяких там OpenPower, OpenMIPS и RISC-V в свое время они никак не могли, да и с реализацией это бы никак не помогло.
Взамен же предлагается закрытый Arm (ну или несуществующее Yadro), да еще и в исполнении конторы, которая не всегда справлялась с политическими и экономическими проблемами.
На мой взгляд дешевле и развивать имеющийся набор инструкций вкупе с компилятором, тем более что боги компиляторостроения утверждают, что за совместной разработкой компиляторов и железа будущее.
Но это всего лишь мое мнение, которое есть.
МЦСТ сделали процессор,
Точнее - два. SPARC и E2K
компилятор, портировали ОС и прикладной софт.
То, что можно было бы не делать, потому что под SPARC оно уже было
Это уже очень и очень много.
В смысле академического результата и прокачивания скиллов - да.
В смысле получения практически полезного результата - весьма дорогостоящее изобретение велосипеда с квадратными колёсами, который будет "приемлемо быстро" ездить по специальным дорогам, если их для него везде построить. Это результат? Да. Большой? ДА! Но полезный ли, если можно было бы тупо и скучно клепать гладкие дороги и велосипеды с круглыми колёсами?
> На мой взгляд дешевле и развивать имеющийся набор инструкций вкупе с компилятором
Ну так МЦСТ с этого и начинал. Релизовывал "имеющийся" SPARC под которые были компиляторы и коммерческие и GCC, и именно это сейчас собираются делать Байкал и Синтакор (только не со SPARC'ом, а с другими ISA).
Но они решили "пойти своим путём". Причём в эпоху усыхания, когда усыхают и вымирают даже когда-то вполне успешные Alpha-SPARC-MIPS-PowerPC. Они решили "в одну харю" развернуть общемировую тенденцию. Безумству храбрых поём мы песню.
Предвидеть же появление всяких там OpenPower, OpenMIPS и RISC-V в свое время они никак не могли
Они могли бы их cоздать на базе своей E2K и быть первыми. Нужно было "скрестить" широко известные концепции коммерческих SIG (тот же PowerPC alliance) и GPL/BSD. Если уж решили перечеркнуть общемировой опыт и сделать революцию - то надо тогда делать революцию.
Или они (плюс государство) могли бы выкупить у Sun все нужные права на SPARC, в том числе даже и с самой компанией.
Или они (плюс государство) могли бы выкупить у Sun все нужные права на SPARC, в том числе даже и с самой компанией.
тут уж какой-то опель не дали купить, а вы замахнулись на покупку спарка
(речь не про то, что опель дороже, а про передачу технологий; хотя, если подумать, в автопроизводсте тоже куча технологий есть, которые могут быть использованы и военными)
Мне как-то смешно спорить с родительским комментарием: купи то, купи это, сделай открытым, и все это - 20 лет назад. Есть вещи, которые не продаются. Sun не продала был Sparc полностью. И сама Sun, очевидно, нам не продалась бы.
История с опелем была, кстати, до Мюнхенской речи и 2008 года, то есть в эпоху дружбы-жевачки. Про сейчас даже говорить не приходится.
Есть вещи, которые не продаются. Sun не продала был Sparc полностью.Система команд SPARC — опенсорсная. Не надо ничего покупать, можно просто взять задаром.
Вы про этот Sparc, который open? и который года четыре был закрыт Ораклом?
Вот был бы успех...
тут уж какой-то опель не дали купить
А есть где почитать про "не дали купить" это?
А то я поискав нашел случай 2009 года про попытку купить Опель консорциумом из канадской Magna и Сбербанка, а потом на базе документов из wikileaks уже в 2011 году стало известно что сделка сорвалась потому что потенциальные покупатели хотели позже продать заводы российскому государственному автопроизводителю, что вкупе с рестуктуризацией GM позволило им выбить гос поддержку и опель стало продавать не нужно.
Это в общем и целом не звучит как "не дали купить", причины были сугубо внутри GM.
Или они (плюс государство) могли бы выкупить у Sun все нужные права на SPARC, в том числе даже и с самой компанией.Зачем что-то выкупать? Система команд SPARC — опенсорсная.
>Повторю свой тезис еще раз: любое конкретное решение в вопросах производительности процессоров не так важно, как использованный при производстве техпроцесс.
именно, ключевые на данный момент вещи техпроцесс, и экосистема
объём производства Эльбрусов за всё время их существования был озвучен в прошлом году Кимом: 20 тысяч единиц.
Новости этго года существенно ничего не поменяли, навскидку:
Автору респект за его 3 последних статьи.
У Эльбруса, на самом деле, есть только одна проблема - он не нужен. Причем не нужен он в первую очередь своим создателям. Если посмотреть на RISC-V, то популярность она набрала не по команде какого-то лидера, а из-за фактически бесплатных камней, с ARM было примерно то же самое. Цена решает. Если бы создателям Эльбруса он был нужен, то мы бы уже видели его везде, на диджикее бы продавались отладочные платы по цене в десяток баксов за штуку, было бы куча акций, по которым его можно было бы получить бесплатно (как было с младшими армами), одноплатники с ним шли бы для обучения. Производительность не имеет решающего значения, значение имеет цена и доступность. А Эльбрус фиг купишь, значит он нужен ради распила.
Не могу пройти мимо. По моему, вы в статье немного манипулируете, рассчитывая на то, что читатель не сможет разобраться и поверит вам на слово. Вы сравниваете 2 примера кода сортировки и пытаетесь на их примере показать недостатки архитектуры VLIW в сравнении с архитектурой Интел. Что динамическое планирование, осуществляемое процессором Интел, эффективнее статического планирования компилятором.
Но код этого не показывает.
Действительно, в коде процессора Эльбрус мы видим много NOP'ов:
- 2 ненужных NOP в начале цикла. Это, очевидно, ошибка компилятора, так как никакой нужды в них нету. Их нужно вынести за цикл.
- 2 NOP после операции чтения из памяти
- 3 NOP после сдвоенной операций записи в память
В то же время процессор Интел выполняет итерацию за 3 такта. Процессор Интел, видимо, не делает пауз после операции работы с памятью (если бы он делал, он бы не уложился в 3 такта). Также, я подозреваю, он делает спекулятивную запись в память (которая будет отменена при выполнении перехода jle .L7).
Последние 5 NOP вставлены не из-за того, что архитектура VLIW или статическое планирование плохи. Нет, они вставлены из-за того, что в Эльбрусе медленная подсистема работы с памятью. Он, получается, не умеет быстро читать данные и быстро записывать, и, видимо, не умеет записывать спекулятивно.
Но это не недостаток архитектуры VLIW или статического планирования. Это недостаток конкретного процессора Эльбрус. Архитектура VLIW не запрещает и не мешает вам сделать работу с памятью/кешем быстрой. А статическое планирование позволяет уложить цикл в 3 такта.
Если бы у нас был процессор, который быстро работает с памятью, то этот цикл можно было бы статически скомпилировать в 3 такта:
L1: mov edx, [rax] | tmp = rax + 4 | cmp rsi, rax | подготовка перехода к L8
L2: (спекулятивно) mov [tmp], edx | cmp edx, ecx | jne .L8 | подготовка перехода к L7 и к L1
L3: (спекулятивно) mov [rax], ecx | jle .L7 else jmp .L1 | (спекулятивно) sub rax, 4
То есть, в теории архитектура VLIW и статическое планирование позволяют достичь той же производительности, что и Интел. А если бы процессор позволил нам совместить в одной команде cmp с jmp и делать 2 операции записи за такт, то может быть этот цикл можно было бы ужать и в 2 такта.
Да, сложно сделать такой компилятор. Но сделать аналогичный "оптимизатор" в железе может быть еще сложнее и дороже.
Далее, про Интел. Архитектура x86 это как раз слабое место Интел. Эта архитектура была придумана для 16-битного процессора, а часть команд в ней (вроде add bl, al) вообще была введена для совместимости с 8-битным 8080. То есть, эта архитектура содержит 50-летнее легаси, разрабатывалась для медленных процессоров без распараллеливания операций, без кеша.
Соответственно, любая более новая архитектура будет лучше, чем у Интел. То, что Интел при плохой архитектуре показывает такую производительность, говорит лишь о таланте их инженеров и огромном количестве вложенных в разработку средств.
Приводить как пример хорошей архитектуры Интел нельзя. Это пример, как плохая архитектура может быть коммерчески успешной.
Что касается "сложности" ассемблера. Я это вообще не считаю недостатком. Если мы можем упростить процессор путем усложнения ассемблерного кода, то это однозначно выигрыш. Так как написать код дешево, просто и быстро, а проектировать железо дорого и сложно.
Ну и еще одна мысль. Допустим, Интел потратил миллиард долларов и сделал быстрый процессор. А мы потратили 10 миллионов и сделали процессор в 5 раз медленнее. Но в пересчете на затраченный доллар мы выиграли в 20 раз.
Приводить как пример хорошей архитектуры Интел нельзя. Это пример, как плохая архитектура может быть коммерчески успешной.
Мне вот всегда непонятны были эти теоретизирования. Какая разница сколько там легаси. Если оно не мешает, то плевать. А оно не мешает, судя по постоянному росту IPC и суммарной производительности чипов. Пусть хоть еще 50 лет пилят. А что до новой архитектуры. Есть мнение, что набор инструкций не имеет ровным счетом никакого значения. Если посмотреть на лучших представителей, микроархитектура у них у всех одинаковая. Включая новенький М1. То, что они гоняют разные инструкции поверх нее, никак в этом всем не прослеживается. Человечество достигло пределов того, что оно может выжать в микроархитектуре обычными средствами. Оно достигло пределов того, что можно упаковать в кристалл. Поэтому сейчас в индустрии идет качественный переход. Сейчас правит балом техпроцесс, интерконнекты и упаковка. 3d stacking, тайлы, чиплеты — вот будущее индустрии, а не арм или x86. Достаточно посмотреть презентации интел, тсмц, амд на прошейдшей пару недель назад hot chips.
Ну и еще одна мысль. Допустим, Интел потратил миллиард долларов и сделал быстрый процессор. А мы потратили 10 миллионов и сделали процессор в 5 раз медленнее. Но в пересчете на затраченный доллар мы выиграли в 20 раз.
Клиентам до этого никакого дела. Интел может сколько угодно тратить. Важно, что он быстрый и просит за это немного денег. Пусть хоть трилионы тратят, это их дело.
>Ха-ха-ха.
В сегодняшних условиях многомесячных очередей на доступ к мощностям кремниевых фабов, подход к проектированию чипов с вынесением из кремния всего чего можно на сторону софта смотрится все более разумным
Если бы у нас был процессор, который быстро работает с памятью
Если бы у нас была быстрая память
Первая цитата о медленно работающем с памятью процессоре, а ваша цитата о медленной памяти. Это же разные вещи.
Может об отсутствии тех самых костылей для компенсации работы с медленной памятью?
Но в пересчете на затраченный доллар мы выиграли в 20 разМожно ещё бесплатно ничего не делать. Или бесплатно взять готовый опенсорсный восьмибитный микроконтроллер, так мы в пересчёте на потраченный доллар вообще всех обгоним. Клиенты только вряд ли будут рады восьмибитному микроконтроллеру вместо серверного процессора.
2 ненужных NOP в начале цикла. Это, очевидно, ошибка компилятора, так как никакой нужды в них нету. Их нужно вынести за цикл
Это не ошибка. Это необходимость выдержать задержку в 3 такта от чтения из памяти значения в r0 до его использовании в операции cmplesb
Нет, они вставлены из-за того, что в Эльбрусе медленная подсистема работы с памятью
Нет, подсистема работы с памятью в Эльбрусе как раз отличная. Nop вставлены для того, чтобы выдержать задержку в 3 такта от чтения из памяти до его использования (считаем, что попали в L1). Это вполне стандратная задержка для процессоров, на более высоких частотах она может увеличиваться до 4-х.
Остальной ваш поток сознания, уж извините, даже комментировать не хочу. Начните изучения вопроса хотя бы с классики: Хеннеси&Паттерсон , Computer Architecture: A Quantitative Approach
Это не ошибка. Это необходимость выдержать задержку в 3 такта от чтения из памяти значения в r0 до его использовании в операции cmplesb
Предположу, что имелось в виду, что "sufficiently smart compiler" обязан был начать чтение из памяти за 3-10 тактов ДО начала цикла, а в дальнейшем - на предыдущей итерации цикла. Регистровый файл же огромный (на x86 тоже, только он скрыт позади registry mapping). Надеюсь, move регистр-регистр на e2k почти бесплатный? В общем то же, что на "обычных" процессорах делают OoO и предиктор обращения к памяти. Ведь в этом же и идея VLIW, вынести эти хитрости в компилятор? и тогда недоработки компилятора - это такая же ошибка системы, как кривая работа OoO и кэша в "пентиуме".
Кстати, а что будет в случае cache miss, когда "nop 2" окажется по определению недостаточным? Остановка всего конвейера? Но тогда почему бы ровно так же не останавливать конвейер на операциях cache/register без явного nop? Или в случае cache miss процессор отработает заказанные "три такта" и дальше почешет, не дожидаясь прогрузки из ОЗУ ?
Предположу, что имелось в виду, что "sufficiently smart compiler" обязан был начать чтение из памяти за 3-10 тактов ДО начала цикла
Предполагать можно много чего, наверное. Вообще, этот цикл компилятор плохо соптимизировал, на самом деле. Как тут уже выснили, если его скомпилить с -O2 (sic!), там лучше намного получается. Но это всё как раз хорошо демонстрирует реальные проблемы статического планирования, а не как эт овыглядит в бравурных реляциях от МЦСТ.
Кстати, а что будет в случае cache miss, когда "nop 2" окажется по определению недостаточным?
Да, весь конвейер будет булькать
Но тогда почему бы ровно так же не останавливать конвейер на операциях cache/register без явного nop?
В общем случае как-то так можно делать, но там исторически не всегда был scoreboarding (т.е. аппаратура не гаранировала доставку корректного результата если задержка не выдержана программно), плюс вроде это иногда может увеличивать задержки. В любом случае, по перфу это никак положительно не скажется.
Ну "sufficiently smart compiler" давно уже стало мемом. Кроме прочего ещё и потому - что чем "умнее" компилятор, тем он тормознее, и тем длиннее цикл разработки, которые в случае всяких интерпретируемых LISP-оподобных вообще делается в REPL-режиме кусками по одной строке.
И да, если два гиганта HP+Intel не смогли за десятилетия это сделать совместно, даже с привлечением Microsoft и GCC, то... Elbrus должен иметь огромное самомнение, чтобы надеяться это сделать. Ну или даже и не собираться делать это на самом деле.
В любом случае, по перфу это никак положительно не скажется.
Гипотетически может сказаться. Просто выйдет некий улучшенный Elbrus 2030 в котором будет предиктор обращения к памяти, и окажется что загрузка там занимает уже не три такта, а один. Но поскольку "nop 2" прибит гвоздиком - увы, процессор будет тупо ждать давно приехавшее значение.
Ведь что интересно, VLIW по идее это как раз процессор для компиляторов, для VM, JIT и вот это вот всё. Для компиляции "по месту" под конкретное железо (как Transmeta). Как всякие OpenCL и прочие шейдеры на видеокартах. Иначе это в самом деле не имеет смысла. Казалось бы эльбрусовцам надо не C++ вылизывать, а как раз JS, JVM, .Net, Parrot и всякие тензоры... А C++/Fortran/Pascal выедет на интринзиках и инлайнящихся полу-ассемблерных библиотеках типа Intel TBB, если это кому-то в самом деле сильно понадобится
Поясните по поводу «NOP 2 прибит гвоздиком». Если загрузка занимает 1 такт, то зачем NOP 2? Или речь о том, что с использованием предсказателя обращений памяти загрузка занимает от 1 до 3 тактов и всё равно придётся вставлять NOP 2 на всякий случай? Но что мешает вместо NOP 2 добавить команду, взаимодействующую с этим самым предсказателем?
Поясните по поводу «NOP 2 прибит гвоздиком»
Открываете статью, смотрите распечатку кода, порождённого компилятором Эльбрус C++ для процессора Эльбрус, видите там команду nop 2.
Если загрузка занимает 1 такт, то зачем NOP 2?
Вопрос к МЦСТ, разработчику компилятора Эльбрус C++ для процессора Эльбрус
с использованием предсказателя обращений памяти загрузка занимает от 1 до 3 тактов и всё равно придётся вставлять NOP 2 на всякий случай
Она УЖЕ вставлена. Появится предсказатель или нет, но команда nop 2 уже записана компилятором в исполняемый код программы.
Но что мешает вместо NOP 2 добавить команду, взаимодействующую с этим самым предсказателем?
Добавить куда? В процессор? да хоть команду "сварить кофе" добавьте. Команда nop 2 УЖЕ вставлена в программу и там останется.
История RISC/CISC и x86 показывает, что идёт положительная обратная связь. Компиляторы не умеют использовать сложные команды; процессоры начинают вылизывать простые команды, оставляя сложные для галочки (они работают, но работают дольше, чем аналогичный десяток простых команд); компиляторы теперь даже если научатся - не хотят использовать сложные (и медленные) команды.
Плюс к тому, программа, не работающая на процессорах купленных в прошлом году, обычно никому не нужна.
Поэтому пока все уже выпущенные процессоры Эльбрус не окажутся на свалке - компиляторы будут добавлять стандартный nop 2, а не какие-то новомодные нововведения, совместимые с тремся с половиной компьютерами. И даже когда появятся новые компиляторы (за новые деньги и с новыми ошибками) - никто не бросится бесплатно пересобирать старые программы. А если кто и пересоберёт, никто не бросится их обновлять.
Всё, nop 2 - это всерьёз и надолго.
P.S. на самом деле "команду, взаимодействующую с этим самым предсказателем" даже добавлять не надо. Это уже будет предательство теоретической частоты VLIW. Предсказатель же должен быть в "умном калькуляторе", а не "в кремнии". Надо просто использовать два регистра, вместо одного, и грузить значение ДО начала цикла, а после начала - в ПРЕДЫДУЩЕЙ итерации. Но сама МЦСТ "не шмогла", а другим даже и позволять не собирается. А учитывая так себе опыт HP+Intel+Microsoft, у которых ресурсов было несравнимо больше, то и надежд не много.
Ну вот в ветке ниже (https://habr.com/ru/post/576420/comments/#comment_23456356) оказалось, что NOP 2 гвоздиком не прибит и что это не «всерьёз и надолго» — что при других настройках происходит компиляция всего цикла в одну широкую команду.
при других настройках происходит компиляция всего цикла в одну широкую команду.
Внутреннего цикла, ценой разрастания внешнего. И как скомпилировал, так и прибьет гвоздями до следующей перекомпиляции.
В итоге можно попытаться костылями (там в общем из треда-то следует что это не ошибка компиляции, а осознанное взвешенное решение для общего случая) сделать лучше в тестовом примере, испортив жизнь во всех других случаях (так как, строго говоря, разрастется внешний цикл в разы). Поэтому выводы человек выше делает верные, просто Вы недочитали что говорили в тредике.
что при других настройках происходит компиляция всего цикла
Других настроек не будет. Просто вот вообще не будет.
Закажите у Майкрософта собрать вам Windows 95 компилятором Visual C++ 2020 в 64-битах со всеми инструкциями процессоров 2015-2021 годов.
Потом расскажите, какой был ценник и заплатили ли вы его.
Повторяю:
Поэтому пока все уже выпущенные процессоры Эльбрус не окажутся на свалке - компиляторы будут добавлять стандартный nop 2, а не какие-то новомодные нововведения, совместимые с тремся с половиной компьютерами. И даже когда появятся новые компиляторы (за новые деньги и с новыми ошибками) - никто не бросится бесплатно пересобирать старые программы. А если кто и пересоберёт, никто не бросится их обновлять.
Заодно сравните популярность настольных и серверных Линуксов, собираемых из исходных текстов (Gentoo, LFS и аналоги/производные), и Линуксов, раздаваемых в виде "прибитым гвоздиком" собранных кем-то где-то бинарных файлов.
*** Если бы у нас был процессор, который быстро работает с памятью, то этот цикл можно было бы статически скомпилировать в 3 такта: ***
Дык вот тут-то и самое-самое слабое место VLIW!
VLIW хорошо работает константной латентностью памяти!
Но в современных процессорах доступ к памяти может длиться от 2 тактов (scratch memory внутри процессора) до 200 тактов (промах L1 и L2 кэшей). В таких условиях OoO может работать, а вот комбинация VLIW, даже с хорошим комплятором - не очень.
Интел не делает пауз, потому что он OoO. В этом и смысл всего цикла статей.
Архитектура X86 под собой имеет какую-то хитрую и быструю микроархитектуру, которая и позволяет ей идти вровень с более новыми конкурентами (ARM).
Сложность ассемблера - не недостаток, пока можно достаточно оптимизировать программы не заглядывая в ассемблер. (Когда я оптимизирую код на java или js, ассемблер мне вообще не нужен, а скорость примерно сравнима с C++). Судя по всему, у VLIW ручная оптимизация дает до 10 раз выигрыша, этим сложно пренебречь.
Если вы бежите марафон за 2 часа, а я иду за 10 часов, это ничего не говорит про эффективность на "затраченный доллар".
2 ненужных NOP в начале цикла. Это, очевидно, ошибка компилятора, так как никакой нужды в них нету. Их нужно вынести за цикл.
2 NOP после операции чтения из памяти
3 NOP после сдвоенной операций записи в память
Вот оно чё(с)
У вас почти получилось «поучить» не только автора, но ещё и его оппонента компиляторы писать!
Сколько лет вы программируете на ассемблере E2K? Хотя бы 1 секунда есть?
Если посмотреть на конец цикла, имеем
{
ct %ctpr1 ? ~%pred0
}
{
nop 2
disp %ctpr1, .L636
ldw,0 %dr10, %dr3, %r0
}
Вы уверены, что disp %ctpr1 можно выполнять сразу после операции перехода?
Их нужно вынести за цикл.
С какой целью? НОПы не являются вычислениями.
Я уже давал ссылку вашим коллегам — «учителям».
www.csl.cornell.edu/courses/ece4750/handouts/ece4750-T13-vliw-processors.pdf
VLIW Compiler Responsibilities
• Schedules to maximize parallel
execution
• Guarantees intra-instruction parallelism
• Schedules to avoid data hazards (no
interlocks)
– Typically separates operations with explicit NOPsОн, получается, не умеет быстро читать данные и быстро записывать, и, видимо, не умеет записывать спекулятивно.
Эльбрус умеет не только записывать спекулятивно, но и зачитывать.
Если бы у нас был процессор, который быстро работает с памятью, то этот цикл можно было бы статически скомпилировать в 3 такта:
L1: mov edx, [rax] | tmp = rax + 4 | cmp rsi, rax | подготовка перехода к L8
L2: (спекулятивно) mov [tmp], edx | cmp edx, ecx | jne .L8 | подготовка перехода к L7 и к L1
L3: (спекулятивно) mov [rax], ecx | jle .L7 else jmp .L1 | (спекулятивно) sub rax, 4
Что, если я вам открою маленькую тайну — в процессорах Интел латентность чтения данных из кэша составляет 5 тактов, т.е. ещё больше чем на Эльбрусе. Вы шокированы?
То что вы тут понаписали, невозможно исполнить на in-order процессоре за 3 такта.
«cmp edx, ecx | jne .L8» может быть выполнена на х86 в одном такте только потому, что macro fusion объединит две операции в одну. Иначе будет задержка по данным.
Так как написать код дешево, просто и быстро, а проектировать железо дорого и сложно.
Это утверждение не соответствует действительности.
Писать код долго и дорого.
По факту сделать процессор за 500 миллионов дешевле и быстрее чем тупо пересобрать и оптимизировать весь софт. Потому что никто не будет этого делать.
Но в пересчете на затраченный доллар мы выиграли в 20 раз.
На соревнованиях по бегу, Леонид Ильич занял второе место, а американский президент пришел предпоследним(с)
Писать код долго и дорого.По факту сделать процессор за 500 миллионов дешевле и быстрее чем тупо пересобрать и оптимизировать весь софт. Потому что никто не будет этого делать.
Эти слова надо золотом выбить на Красной площади.
К сожалению, я не очень хорошо акцентировал данную мысль в статьях, что является упущением
В случае "ведомственного НИИ" это не так.
Тут вопрос в масштабируемости/тиражируемости и "размазывании" капитальных инвестиций по тысячам/миллионам/миллиардам единиц товара.
Если бы программы и процессоры изготавливались одинаковыми тиражами, то процессор был бы несравнимо дороже. В конце концов, для выпуска новой версии программы нужны минуты/часы, а новой версии процессора "от Verilog'a до коробки в магазине" ?
Поэтому, если есть изолированная структура, которая сама себе делает процессоры и сама себе пишет программы, то внутри неё всё именно так: процессор менять долго и дорого, а софт - быстро и дешёво. МЦСТ+ВПК например именно такие, во всяком случае так о себе традиционно думают.
Проблема именно в переходе к "глобальному рынку", когда процессоры делают десяток вендоров тиражами от 100К, а программы пишут не только гиганты типа Microsoft, но и безымянные анонимы на коленке (любой веб-мастер делая страничку сложнее визитки делает программу тиражом один экземпляр). И всех их просто перечислить даже не получится, не то что принудить переписать программу.
Соответственно, люди "внутри" и "снаружи" пузыря действительно просто не понимают друг друга.
Ещё аналогия - Япония. По всей стране проходит раскол, две разные системы электрообеспечения. Казалось бы дел на одни сутки, "дать приказ" и в "день М" лишняя система выключается и вся страна строем переходит на одну. А вот хрен, десятилетия проходят - ничего не меняется.
Ещё одна аналогия, военная "манчестерская" шина. В её варианте MIL-STD - полно бесплатных документов и толстых учебников хоть от Боинга. В российском - 30 страничек ГОСТа, за которые ещё и заплатить надо. Один из этих миров явно вывернут наизнанку, но в каждом из зазеркалий наверняка искренне уверены, что правильно именно у них.
Вы уверены, что disp %ctpr1 можно выполнять сразу после операции перехода?
Конечно можно, в чем проблема? Мало тог, оно и выполняется сразу в следующем такте, nop 2 стоит для следующей команды, которая очевидно использует результат ldw,0 %dr10, %dr3, %r0
Это утверждение не соответствует действительности. Писать код долго и дорого. По факту сделать процессор за 500 миллионов дешевле и быстрее
Вы бредите, даже в той же мцст разработкой софта (всего - библиотеки, компиляторы дистрибутив) занимается 20 человек, а железом 200. Во вторых какая бы железка не была, хоть за 100 хоть за 500 миллионов, под нее все равно придется софт портировать и ускорять под новые инструкции, автоматом к процессору ничего не прилогается.
Вы бредите, даже в той же мцст разработкой софта (всего - библиотеки, компиляторы дистрибутив) занимается 20 человек, а железом 200
Вы так говорите, как будто МЦСТ тут вообще показательные. К тому же еще вопрос, точно ли вы правы про 20 человек и 200 и распределение задач? Откуда у вас инфа?
Во вторых какая бы железка не была, хоть за 100 хоть за 500 миллионов, под нее все равно придется софт портировать и ускорять под новые инструкции, автоматом к процессору ничего не прилогается.
То есть если сделать armv8.2 (или rv64g, как удобнее) совместимый процессор, то на нем ничего не запустится и софт на него придется портировать? Расскажите почему так?
Тут столько светлых голов высказалось. Для меня как эльфы про магию. А меня вот что огорчило в Эльбрусе: не то что он медленее древних интелов, и не цена. А вот дайте свежие libc gcc qt и ядро линукса!. Мне вот все равно что там внутри за магия.
По итогу все равно получилась перепалка, да ещё и на очень странную тему сравнения массовых коммерчески доступных процессоров с тем, что существует только в бенчмарках, документах и может быть где то в госзаказах.
Но стратегия всего этого вполне понятна: в какой то момент отечественные процы станут единственно доступными, и вот тогда народу придется заняться портированием и изучением чудного ассемблера и забыть про сравнение с х86
Поясните дилетанту: VLIW делает вжух выдаёт высокий IPC, если хорошо отработал компилятор: полностью заполнил команду и предсказал обращение к памяти. Такие вопросы:
Насколько это реально при разработке софта, если его писать под Эльбрус? Решается ли проблема деньгами, или там куча вещей, который даже теоретически неразрешимы?
Помечтаю: допустим, в МЦСТ признали, что запуск имеющегося софта на Эльбрусах невозможен с заявленной эффективностью, сделали язык, который лучше ложится на архитектуру, и транслятор из С и плюсов в этот язык со статическим анализатором aka рекомендательной системой для ручного допиливания. Такое в хоть теории реально? Какой выигрыш в производительности относительно х86/ARM должен быть, чтобы гиганты озаботились допиливанием софта под новую инфраструктуру?
В общем случае это теоретически неразрешимо. Для определённого класса задач - возможно (т.е. микроархитектурная скорость на них будет стремиться к ОоО процессорам, разница будет минимальной). Но класс таких задач очень узкий.
Давайте я просто скажу, что это всё нереально на практике. Ну т.е. в теории можно говорить о том, что хорошо бы иметь какой-то супер-пупер язык, в котором будет параллельность заложена на уровне каких-то концепций. Но это золотой Грааль индустрии на протяжении десятилетий, а воз и ныне там. Ну и под такие языки уже понятно, какие архитектуры можно создавать. Там есть подходы, куда более перспективные, чем современный Эльбрус.
Спасибо. Я сосредоточенно пытаюсь понять, сколько правды было в презентациях, начиная с Бабаяна, и правда ли надо закапывать стюардессу (как будто это от меня зависит).
Насколько много задач, в которых VLIW быстрее ОоО, как когда-то обещалось? Грубо говоря, имеет ли смысл строить суперкомпьютеры-числомолотилки на Эльбрусах или ставить VLIW-сопроцессоры, как Интел ставил FPGA.
Жаль, я думал, что Erlang, Oz и Lucid сделали достотаточно много шагов в сторону "параллельного программирования без боли".
VLIW теоретически не может обогнать OoO, только к нему приблизиться ( ну вернее я могу написать синтетику, где это не так, но если мы говорим именно о реальном коде и классах задач - это именно так). Здесь речь может идти только о том, насколько он отстаёт. В хороших случаях, где по факту работа ОоО не нужна, а компилятор всё смог статически разрешить, мы можем говорить о том, что машинерия ОоО нам не нужна и её можно выбросить, чтобы она не жрала мощность. Ну т.е. где-то в таком разрезе можно искать ниши для VLIW. Но это точно не GP CPU вцелом.
К сожалению, это не так.
Т.е. конкуренция была изначально для равной частоты не про выигрыш по OPs, а по энергоэффективности и площади кристалла?
Ну сложно сказать что там считали изначально. Видимо, были разные мнения. По-крайней мере сам Бабаян когда двигал концепцию Эльбруса в 90-х говорил именно о большей производительности, т.е. о лучших OPs в вашей терминологии.
А есть ли тут противопоставление? Если вы в какой-то момент ограничены энергоэффективностью и площадью - то как раз выигрыш в них приводит к выигрышу по OPs. Можно добавить блоков-исполнителей, можно добавить кэша, можно поднять частоту в пределах "теплового конверта", можно просто поставить 2-3-4 процессора, и т.д.
В общем-то RISC vs CISC изначально как раз был об этом. Давайте выкинем из процессора "умные" вещи, а освободившееся "место" займём усилением "числодробилки". VLIW в части "машинерия ОоО нам не нужна" - это в каком-то смысле продолжить эту тенденцию. Но оказалось (для "обычных" задач), что в данном случае это уже слишком много экономии, золотую середину перепрыгнули.
Трудоёмкость разработки под архитектуру Эльбрус, ввиду высокой сложности ассемблера широкой команды и необходимости постоянно проводить анализ кода и его изменение для достижения приемлемых цифр производительности (в Эльбрусе без этого никак, т.к. здесь если компилятор не справился, то аппаратура не подстрахует. А не справляться компилятор будет постоянно по вполне объективным причинам)
Мне не совсем понятно. Вы хотите сказать, что аппаратура успешно оптимизирует код, а компилятор тот же самый код соптимизировать не в состоянии?
В итоге, микроархитектурная скорость исполнения данного кода на x86 превышает Эльбрус в 13/3 = 4.33 раза. Т.е. во столько бы раз проиграл Эльбрус, будь он по частоте сопоставим с топовыми RISC/CISC системами.
Опять не совсем понятно. Я конечно не специалист в этой области, но насколько мне известно код x86 в современных микропроцессорах декодируется в некоторый внутренний микрокод, который затем оптимизируется и выполняется.
В Эльбрусе же такого не происходит и VLIW-команда сама по себе является аналогом такого вот внутреннего микрокода.
Но тогда ваше сравнение получается некорректным.
Поправте, пожалуйста, если я ошибся.
Мне не совсем понятно. Вы хотите сказать, что аппаратура успешно оптимизирует код, а компилятор тот же самый код соптимизировать не в состоянии?
Да
Опять не совсем понятно. Я конечно не специалист в этой области, но насколько мне известно код x86 в современных микропроцессорах декодируется в некоторый внутренний микрокод, который затем оптимизируется и выполняется
Само по себе не так важно, в какой микрокод и как что-то оттранслировалось. Важно по итогу с какой скоростью мы этот код исполняем. Здесь приведено сравнение, что одну итерацию цикла на Эльбрусе мы исполняем 13 тактов, а на x86 только 3. Т.е. по итогу время исполнения всей задачи будет отличаться на 13/3 = 4.33 раза при условии, что частота Эльбруса будет равна частоте x86. Т.е. таким образом мы рассчитываем микроархитектурную скорость каждого процессора.
Да
Звучит примерно как: аппаратура успешно декодирует видео, а совтферно это сделать нереально. Неужели аппартные оптимизации сделать проще, чем аналогичные компиляторные?
Само по себе не так важно, в какой микрокод и как что-то оттранслировалось. Важно по итогу с какой скоростью мы этот код исполняем. Здесь приведено сравнение, что одну итерацию цикла на Эльбрусе мы исполняем 13 тактов, а на x86 только 3. Т.е. по итогу время исполнения всей задачи будет отличаться на 13/3 = 4.33 раза при условии, что частота Эльбруса будет равна частоте x86. Т.е. таким образом мы рассчитываем микроархитектурную скорость каждого процессора.
Хорошо. Но тогда получается, что вы пытаетесь сравнивать принципиальные характеристики архитектур сравнивая конкретных представителей этих архитектур и возможности конкретных компиляторов.
Ваше утверждение доказывает, что обсуждаемый Эльбрус медленее Core I5, но не доказывает, что VLIW процессоры принципиально медленнее OoO процессоров.
А можно какие-то примеры на конкретном алгоритме/задаче? Мол вот считаем то то то, и вот тут процессор на основе такой то информации, которая берется отседова, может сделать круто.
Не спора ради, я вам верю, но пока неполучается в голове конкретнее представить.
Самое простое - это проблема перестановки обращений в память. Представьте, у вас есть 2 указателя, которые пришли откуда-то сверху. По одному вы делаете store, а потом по второму load. В общем случае, эти обращения в память могут пересекаться и компилятор их не может переставить. В рантайме же процессор сразу вычисляет адреса (чтобы эти обращения в память физически выполнить) и просто проверяет, пересекаются ли они или нет. Если нет, то просто load пооднимает выше store и никаких проблем.
Неужели аппартные оптимизации сделать проще, чем аналогичные компиляторные?
Зачастую да
Хорошо. Но тогда получается, что вы пытаетесь сравнивать принципиальные характеристики архитектур сравнивая конкретных представителей этих архитектур и возможности конкретных компиляторов.
А вы как себе представляете обобщенное сравнение? Естественно, идёт демострация на конкретных примерах. А обобщение основано на том, что в нише GP CPU все VLIW процессоры по итогу умерли. Описанные здесь проблемы достаточно общие для них всех, хотя есть, конечно же, нюансы.
/Выставил в качестве компилятора e2k lcc 1.26.04, опции оптимизации -O4.
Там лучше было выбрать не -O4, а обычный -O2. И количество тактов в цикле сокращается примерно в 2 раза.
Ха-ха, и ведь правда)
Ну согласитесь, ситуация, когда для получения самого лучшего результата надо вместо -O4 поставить -O2, это достаточно странно. Понятно, что об этом догадаться невозможно. Уж скорее я бы подумал подать какие-то доп опции. Проще всего прагмой цикл подсветить, наверное.
Это кстати, хорошо демонстрирует проблемы компилятора. Ну и все рассказы про супер-пупер эвристики про инлайн и горячие функции - тоже.
А еще это доказывает, что все еще есть значительный потенциал улучшения производительности Эльбруса за счет компилятора.
Если компилятор сейчас плохой, то после его исправления реальная производительность Эльбруса улучшится и в реальных нагрузках, и во всяких тестах типа того же SPEC2017.
Нет, это не так. На Spec2017 у Эльбруса таких проблем нет (вернее, цифры, которые Алексей привёл, они получены для ситуации, когда все такого рода проблемы решены). Потому что именно на Spec2006/2017 всё и вылизывалось. Именно поэтому я привёл сравнения микроархитектурной скорости и на спеках, потому что это близко к теоретическому максимуму Эльбруса (и про это вообще много в статье написано).
А данный пример просто показывает, что будет происходить на реальных задачах пользователей, на которые эвристики, подстроенные под Spec'и, не заточены.
Не думаю, что они хорошо работают с кодом SPEC, если они прокололись даже на таком простом коде.
Делаем простой эксперимент. Выносим один главный внутренний цикл в отдельную функцию, и в итоге одна итерация там исполняется за 2 такта:
while(p >= 0 && a[p] > t)
{
a[p + 1] = a[p];
a[p] = t;
p--;
}.L19:
{
loop_mode
ldw,3,sm %dr0, %db[3], %b[0]
cmplesb,4,sm %b[4], %r1, %pred0
subd,5,sm %db[3], 0x4, %db[1]
}
{
loop_mode
alc alcf=1, alct=1
abn abnf=1, abnt=1
abp abpf=1, abpt=1
ct %ctpr1 ? ~%pred1 && %NOT_LOOP_END
staaw,2 %b[6], %aad0[ %aasti1 + _f32s,_lts0 0x4 ] ? ~%pred1
staaw,5 %r1, %aad0[ %aasti1 ] ? ~%pred1
incr,5 %aaincr1
}Можно сделать вывод, что компилятор не умеет хорошо оптимизировать вложенные циклы. Или он ожидает, что вложенный цикл будет коротким.
В итоге можно получить ускорение в 6.5 раза от первоначального варианта: 13 тактов / 2 такта = 6.5.
Ну я не думаю, я знаю. В МЦСТ анализом спеков по факту отдельные люди специально занимались и занимаются. Это их работа. Вся отчётность по улучшению компилятора она на Spec'и ориентирована.
А вот что происходит при попадании в реальный мир - мы видим. Собственно, мои тезисы про сложность оптимизации про Эльбрус - они про это. Придётся потом на простейших примерах сидеть и смотреть, что компилятор там наделал.
Но в качестве некоторого предела по архитектурной скорости - Spec'и дают хороший ориентир. Сильно лучше там не будет.
И согласитесь, если компилятор пилили 20+ лет, а он в таких примерах лажает - наверное, это неспроста. Наверное , есть объективные проблемы.
Вот мы получили три разных реальных результата для одного и того же кода на Эльбрусе:
13 тактов для -O4
7 тактов для -O2
2 такта, если просто вынести главный цикл в отдельную функцию.
Такой же разброс возможен и на реальном коде, и на коде SPEC.
Но минимальный результат в 2 такта оказался в 1.5 раза лучше вашего x86, который ~3 такта. И этот результат на Эльбрусе можно получить. Хотя неизвестно, что там будет, когда закончится кэш. Без подкачки будет плохо.
Поэтому основные выводы в статье можно пересмотреть. Потенциал VLIW Эльбруса на таком коде достаточно хороший. Компилятор подкачал.
Не могу не заметить, что разговор о производительности на примере сортировки вставками всё ещё оторван от реальности: если это будет узкое место, то, наверное, начать стоит с выбора другого алгоритма. Но раз уж заговорили о нём, то предлагаю не останавливаться на достигнутом.
Очень похоже, что Вы правильно определили, что "компилятор ожидает, что вложенный цикл будет коротким". Это ошибка с его стороны, которая лечится достаточно просто, хоть и затрагивает мелкую модификацию исходника: перед циклом while следует добавить #pragma loop count(1000).
Дальше можно заметить, что в программе все обращения в память соблюдают выравнивание. В этом случае следует добавить опцию компиляции -ffast (да, для Эльбруса это такой же важный шаг, как просто компиляция с включением оптимизаций). Посмотрим на результат:
.L38:
{
loop_mode
alc alcf=1, alct=1
abn abnf=1, abnt=1
abp abpf=1, abpt=1
ct %ctpr1 ? ~%pred3 && %NOT_LOOP_END
staaw,2 %b[16], %aad1[ %aasti2 + _f32s,_lts0 0x4 ] ? ~%pred3
cmplesb,4,sm %b[10], %r2, %pred0
staaw,5 %r2, %aad1[ %aasti2 ] ? ~%pred3
incr,5 %aaincr2
movaw,1 area=0, ind=0, am=1, be=0, %b[0]
}В итоге вышел всего лишь один такт и даже успешно сработал механизм подкачки данных. Кстати, @alexanius давал в своей статье ссылки на ситуации, когда показано "микроархитектурное превосходство" Эльбруса, но в этой статье такая информация была проигнорирована.
В итоге вышел всего лишь один такт и даже успешно сработал механизм подкачки данных.
Хорошо бы проверить исполнение на реальном железе Эльбруса с разными размерами массива.
Ожидаю два потенциальных подвоха:
1) как работает подкачка за пределами границ кэша 64 KB, 512 KB, и 16 MB для Эльбрус-8C.
2) потенциальный конфликт между операциями чтения и записи. Они же читают и записывают одни и те же области (строки кэша) одновременно. A значит буферы подкачки, кэш L1 и кэш L2 должны работать синхронно, и разрешать все возможные конфликты. Хотя кэш L1 тут вообще не будет работать в этом варианте с одним тактом?
Если по результатам реального исполнения там действительно будет один такт на итерацию, тогда признаем полную победу Эльбруса.
Кстати внутри цикла есть одна лишняя операция записи, которую можно вынести за пределы цикла в исходном коде. Но она особо не мешает. Пусть будет.
Согласен, без проверки никуда. Поэтому берём машины на базе Эльбрус-8С @ 1.2 ГГц с 1 и 4 процессорами (дальше уточнять не буду, но результат не отличается существенно). Позволю себе для начала полениться и замерить только на массиве из 100000 элементов, как предложено в статье (это около 390 КБ). Это будет полностью честный замер скорости работы предложенной функции сортировки.
Исходный код для замера, реализация Sort по ссылке выше
#include<stdlib.h>
#include<stdio.h>
#include <sys/time.h>
#define ARRAY_SIZE 1000000
void fill(int*a)
{
for(int i=0;i<ARRAY_SIZE;i++)
{
a[i]=ARRAY_SIZE - i;
}
}
void Sort(int*a);
void print_array(int*a, int n)
{
printf("%d \n",a[n]);
}
int main()
{
int n;
scanf("%d", &n);
int*array=(int*)malloc(ARRAY_SIZE*sizeof(int));
fill(array);
struct timeval start, end;
gettimeofday(&start, NULL);
Sort(array);
gettimeofday(&end, NULL);
double time = (double)(end.tv_usec - start.tv_usec) / 1000000 + (double)(end.tv_sec - start.tv_sec);
printf("\t%3.6f s\n", time);
print_array(array, n);
return 0;
}
Массив заполнен в порядке убывания элементов, значит, количество внутренних итераций будет порядка 100000 * 100000 \ 2. Прогон занимает 4.214 с. Итого получается 4.214 * 1200000000 / 100000 / 50000 = 1.0136 — тот самый один такт.
Чтобы дождаться квадратичной сортировки при большем размере массива, нужно много терпения, так что упрощаем тест. Удаляем внешний цикл, массив заполняем по возрастанию, в конце ставим один минимальный элемент (будем вставлять его на правильную позицию внутренним циклом while). Ставим количество элементов 200000000 (760 МБ) и запускаем. Отрабатывает за 0.214 с, то есть 1.284 такта на одну итерацию.
Для пытливых читателей пересчитаем показатель IPC: не меньше 7 полезных инструкций на один такт.
А точно все полезны?
alc — продвинуть счётчик цикла
ct — передача управления, здесь же скрыта ещё одна булева операция (&&)
staaw — 2 записи значений в память
movaw — пересылка значения из буфера APB в регистр
cmplesb — сравнение
Насчёт остальных надо думать:
abn и abp — продвинуть базу вращения числовых и предикатных регистров, соответственно — позволяет наслаивать итерации друг на друга
И ещё скрыты инструкции работы с APB, обеспечивающие подкачку данных.
ещё неплохо бы сделать тест в несколько потоков.
Массив заполнен в порядке убывания элементов, значит, количество внутренних итераций будет порядка 100000 * 100000 \ 2
сделал так же, как ни странно, в сравнении с рандомным массивом скорость на amd заметно выросла, на intel такого эффекта нет.
#include<stdlib.h>
#include<stdio.h>
#include <time.h>
#define ARRAY_SIZE 100000
void fill_random(int *a)
{
for (int i = 0; i < ARRAY_SIZE; i++) {
// a[i]=rand();
a[i] = ARRAY_SIZE - i;
}
}
long long Sort(int *a)
{
int t, // временная переменная для хранения значения элемента сортируемого массива
p; // индекс предыдущего элемента
long long loops = 0;
for (int c = 1; c < ARRAY_SIZE; c++) {
t = a[c]; // инициализируем временную переменную текущим значением элемента массива
p = c - 1; // запоминаем индекс предыдущего элемента массива
while (p >= 0 && a[p] > t) // пока индекс не равен 0 и предыдущий элемент массива больше текущего
{
a[p + 1] = a[p]; // перестановка элементов массива
a[p] = t;
p--;
loops++;
}
}
return loops;
}
int main()
{
int *array = (int *) malloc(ARRAY_SIZE * sizeof(int));
fill_random(array);
struct timespec t1, t2;
clock_gettime(CLOCK_MONOTONIC, &t1);
long long loops = Sort(array);
clock_gettime(CLOCK_MONOTONIC, &t2);
long long diff =
(t2.tv_sec - t1.tv_sec) * 1000000000LL + t2.tv_nsec - t1.tv_nsec;
printf("time diff: %lld, loops: %lld, ns per loop: %f\n", diff, loops,
(float) diff / loops);
return 0;
}
gcc -O3 -fno-tree-vectorize sort.c -o sortgcc10
запускал так:
for A in $(seq 1 28); do (/tmp/sort; /tmp/sort > /dev/null; /tmp/sort > /dev/null; /tmp/sort > /dev/null) & done; sleep 0.1; grep MHz /proc/cpuinfo | sort -n | tail -n 5запускаем параллельно 28 экземпляров (по числу физических ядер), смотрим реальную частоту по 5 самым быстрым ядрам.
cpu MHz : 3226.754
cpu MHz : 3227.287
cpu MHz : 3230.192
cpu MHz : 3230.470
cpu MHz : 3232.329
time diff: 1995516528, loops: 4999950000, ns per loop: 0.399107
time diff: 1997393819, loops: 4999950000, ns per loop: 0.399483
time diff: 1998150716, loops: 4999950000, ns per loop: 0.399634
time diff: 1998434435, loops: 4999950000, ns per loop: 0.399691
time diff: 1998937994, loops: 4999950000, ns per loop: 0.399792
time diff: 1999094619, loops: 4999950000, ns per loop: 0.399823
time diff: 2001473480, loops: 4999950000, ns per loop: 0.400299
time diff: 2002159156, loops: 4999950000, ns per loop: 0.400436
time diff: 1999375411, loops: 4999950000, ns per loop: 0.399879
time diff: 2002017186, loops: 4999950000, ns per loop: 0.400407
time diff: 2001638683, loops: 4999950000, ns per loop: 0.400332
time diff: 2005858784, loops: 4999950000, ns per loop: 0.401176
time diff: 2004424449, loops: 4999950000, ns per loop: 0.400889
time diff: 2007775374, loops: 4999950000, ns per loop: 0.401559
time diff: 2015514825, loops: 4999950000, ns per loop: 0.403107
time diff: 2014485385, loops: 4999950000, ns per loop: 0.402901
time diff: 2015924989, loops: 4999950000, ns per loop: 0.403189
time diff: 2017793263, loops: 4999950000, ns per loop: 0.403563
time diff: 2021251438, loops: 4999950000, ns per loop: 0.404254
time diff: 2023331732, loops: 4999950000, ns per loop: 0.404670
time diff: 2028663031, loops: 4999950000, ns per loop: 0.405737
time diff: 2038935097, loops: 4999950000, ns per loop: 0.407791
time diff: 2044060154, loops: 4999950000, ns per loop: 0.408816
time diff: 2049224409, loops: 4999950000, ns per loop: 0.409849
time diff: 2095822443, loops: 4999950000, ns per loop: 0.419169
time diff: 2094855735, loops: 4999950000, ns per loop: 0.418975
time diff: 2117641268, loops: 4999950000, ns per loop: 0.423532
time diff: 2121754599, loops: 4999950000, ns per loop: 0.424355cpu MHz : 3355.194
cpu MHz : 3355.319
cpu MHz : 3355.873
cpu MHz : 3357.993
cpu MHz : 3359.138
time diff: 1552150588, loops: 2491977701, ns per loop: 0.622859
time diff: 1550847665, loops: 2491977701, ns per loop: 0.622336
time diff: 1552203054, loops: 2491977701, ns per loop: 0.622880
time diff: 1553759274, loops: 2491977701, ns per loop: 0.623504
time diff: 1555947478, loops: 2491977701, ns per loop: 0.624383
time diff: 1554742037, loops: 2491977701, ns per loop: 0.623899
time diff: 1554169199, loops: 2491977701, ns per loop: 0.623669
time diff: 1558235232, loops: 2491977701, ns per loop: 0.625301
time diff: 1563261775, loops: 2491977701, ns per loop: 0.627318
time diff: 1562793237, loops: 2491977701, ns per loop: 0.627130
time diff: 1565279126, loops: 2491977701, ns per loop: 0.628127
time diff: 1563496328, loops: 2491977701, ns per loop: 0.627412
time diff: 1567524053, loops: 2491977701, ns per loop: 0.629028
time diff: 1568694393, loops: 2491977701, ns per loop: 0.629498
time diff: 1572017556, loops: 2491977701, ns per loop: 0.630831
time diff: 1574035617, loops: 2491977701, ns per loop: 0.631641
time diff: 1573849729, loops: 2491977701, ns per loop: 0.631567
time diff: 1576040531, loops: 2491977701, ns per loop: 0.632446
time diff: 1574525289, loops: 2491977701, ns per loop: 0.631838
time diff: 1577963870, loops: 2491977701, ns per loop: 0.633218
time diff: 1582952383, loops: 2491977701, ns per loop: 0.635219
time diff: 1592553376, loops: 2491977701, ns per loop: 0.639072
time diff: 1595359814, loops: 2491977701, ns per loop: 0.640198
time diff: 1597090117, loops: 2491977701, ns per loop: 0.640893
time diff: 1596593427, loops: 2491977701, ns per loop: 0.640693
time diff: 1617982126, loops: 2491977701, ns per loop: 0.649276
time diff: 1698739526, loops: 2491977701, ns per loop: 0.681683
time diff: 1759858552, loops: 2491977701, ns per loop: 0.706210при запуске в один поток немного быстрее:
time diff: 1745296583, loops: 4999950000, ns per loop: 0.349063
time diff: 1436000292, loops: 2491977701, ns per loop: 0.576249Чтобы дождаться квадратичной сортировки при большем размере массива, нужно много терпения, так что упрощаем тест. Удаляем внешний цикл, массив заполняем по возрастанию, в конце ставим один минимальный элемент (будем вставлять его на правильную позицию внутренним циклом while). Ставим количество элементов 200000000 (760 МБ) и запускаем. Отрабатывает за 0.214 с, то есть 1.284 такта на одну итерацию.
не можете привести получившийся код? чтобы можно было запустить его на x86 и быть уверенным, что сравниваем апельсины с апельсинами.
Без проблем. Функцию (не)сортировки я уже привёл ссылкой на Compiler Explorer (проверив, что внутренний цикл остался без изменений после того, как исчез внешний). Соответственно, при сравнении с x86 придётся тоже проверить, что внутренний цикл сохраняется в неизменном виде.
А вот так замерял:
#include<stdlib.h>
#include<stdio.h>
#include <sys/time.h>
#define ARRAY_SIZE 200000000
void fill(int*a)
{
for(int i=0;i<ARRAY_SIZE;i++) {
a[i] = i + 1;
}
a[ARRAY_SIZE - 1] = 0;
}
void Sort(int*a);
void NotSort(int*a);
void print_array(int*a, int n)
{
printf("%d \n",a[n]);
}
int main()
{
int n;
scanf("%d", &n);
int*array=(int*)malloc(ARRAY_SIZE*sizeof(int));
fill(array);
struct timeval start, end;
gettimeofday(&start, NULL);
NotSort(array);
gettimeofday(&end, NULL);
double time = (double)(end.tv_usec - start.tv_usec) / 1000000 + (double)(end.tv_sec - start.tv_sec);
printf("\t%3.6f s\n", time);
print_array(array, n);
return 0;
}
Удаляем внешний цикл, массив заполняем по возрастанию, в конце ставим один минимальный элемент (будем вставлять его на правильную позицию внутренним циклом while). Ставим количество элементов 200000000 (760 МБ) и запускаем. Отрабатывает за 0.214 с, то есть 1.284 такта на одну итерацию.
А эта потеря скорости происходит только после 16 MB из-за медленной памяти?
Получается примерно 4 ГБ/c на чтение и 4 ГБ/c на запись. Но в буферы подкачки нужно читать заранее, чтобы побороть большую латентность памяти, которая примерно 100 нс, а это примерно 120 слов (или 480 байт) в том коде.
Чтобы лучше проверить пиковую скорость буфера префетча у Эльбруса, можно заменить там 32-битные числа на 64-битные, чтобы память нагружалась в два раза быстрее. И проверить ту функцию для разных размеров массива: до 16 MB и после.
Фактически этот код измеряет скорость сдвига memmove() массива на 4 или 8 байт, но с дополнительной проверкой значений элементов массива, которая никогда не срабатывает. В случае реального массива проверка сработает тоже только через много итераций.
Массив заполнен в порядке убывания элементов
а на случайном наборе из 100000 какой результат?
Реальность для Эльбруса наступит тогда, когда на нём сборка AOSP начнётся. Что там будет по перфу мне даже представить страшно.
А сейчас, чтобы простейшую сортировку, надо исходники править
Это ошибка с его стороны, которая лечится достаточно просто, хоть и затрагивает мелкую модификацию исходника
Ну вот и началось - без правки исходников никуда
Кстати, @alexanius давал в своей статье ссылки на ситуации, когда показано "микроархитектурное превосходство" Эльбруса, но в этой статье такая информация была проигнорирована.
Серьёзно? И где же там такое показано?
Как стакан наполовину пуст и полон одновременно, так же и в этих обсуждениях нет чёткой истины. Нет, править исходники в общем случае не нужно. Да, если нужно здесь и сейчас быстро — можно дописать pragma. Да, это ошибка в компиляторе. Досадно, что она есть. Информация о ней уже доведена до МЦСТ, в новых версиях проблему обещают исправить и нам править ничего не придётся.
Я понимаю, что Вы взяли первый попавшийся код специально, чтобы продемонстрировать проблемы. Но, на мой взгляд, этот пример всё ещё не несёт никакой прикладной ценности — я запускал сортировку 100000 элементов (всего лишь 390 КБ) на Эльбрус-8С и i7-9700K. Итоговая разница времени выполнения у них 2 раза. При этом выполнение 2-4 секунды является безобразно долгим что на одном, что на другом. Если в этом месте в программе проблема, то править исходники нужно в любом случае — переписыванием алгоритма сортировки на более быстрый. Так что этот пример показывает, какой код не надо писать в реальных программах и какие проблемы могут быть у компилятора. Но он никак не показывает того, что Вы заявляете (якобы отставание в микроархитектурной скорости). Кстати, сейчас при обучении программированию всё чаще используются методы "стимулирования к написанию хорошего кода", например, системы ejudge с контролем времени выполнения. Не уложился в 1 секунду из-за медленного алгоритма или его плохой реализации (даже на x86) — получи линейкой по пальцам штраф на несколько баллов и оценку ниже. Вряд ли неоптимальные алгоритмы или реализации можно считать нормальным явлением в местах, где реально требуется производительность :)
Вообще, вся эта ветка комментариев началась с опровержения тезиса о плохой "микроархитектуре". Согласитесь, в данном контексте он опровергнут. Да, к компилятору оказалось много вопросов и претензий, но не к "микроархитектуре".
Серьёзно? И где же там такое показано?
Там дана ссылка на мою статью, в которой рассказано об эффективности реализаций ГОСТ алгоритмов симметричного шифрования на Эльбрусе. Да, речь идёт о конкретной задаче, но пока все разговоры идут только на примерах конкретных задач.
Я понимаю, что Вы взяли первый попавшийся код специально, чтобы продемонстрировать проблемы
Я его взял, потому что он крайне показателен.
Вообще, вся эта ветка комментариев началась с опровержения тезиса о плохой "микроархитектуре". Согласитесь, в данном контексте он опровергнут
Уж извините, но вся данная ветка для меня как раз доказывает, насколько мой тезис верен. Но честно говоря, я уже настолько утомился доказывать достаточно очевидные на мой взгляд вещи, что пусть каждый делает дальнейшие выводы сам. В конце концов, сделать правильные выводы из статей куда важнее МЦСТ, чем мне. Лично для меня это в общем-то чисто академические споры.
Там дана ссылка на мою статью, в которой рассказано об эффективности реализаций ГОСТ алгоритмов симметричного шифрования на Эльбрусе
Вы взяли, и руками наоптимизировали какой-то код под e2k. Какой в итоге - непонятно. Что получилось в ассемблере в итоге - непонятно. Что пускалось на x86 - непонятно. И предлагаете, чтобы я на это ссылался. Причём в вашей же статье есть ссылка на куда более печальные для Эльбруса результаты на том же алгоритме, где он на ядро Комдиву проиграл в 2 раза.
Просто я подозреваю, что на том же x86 если пооптимизировать, можно также существенно результаты увеличить. Так что ваша претензия не принимается.
Я уже выше написал - есть достаточно фундаментальные вещи, определяющие производительность. В пределе они будут стремиться к количеству АЛУ юнитов. Главная проблема Эльбруса в этом треде как раз и продемонстрирована - без серьёзной оптмизации он не может приблизиться к своим максимальным цифрам, в то время как RISC с ОоО делает это намного лучше, что мы и видим. Для архитектуры, внедряемой в масштабах всей страны - это приговор.
Вы взяли, и руками наоптимизировали какой-то код под e2k. Какой в итоге - непонятно. Что получилось в ассемблере в итоге - непонятно. Что пускалось на x86 - непонятно.
Понимаю Ваш обоснованный скептицизм. К сожалению, нужно быть достаточно глубоко в теме, чтобы в деталях понимать, о каких именно реализациях идёт речь в статье. В статье есть ссылки на материалы, по которым можно со всем разобраться и даже повторить результаты, но это требует больших затрат времени и сил.
Ассемблер и, тем более, исходники у нас в России никто не показывает. Можно сказать, специфика разработки СКЗИ. Но вкратце могу рассказать следующее: под x86 используются написанные руками ассемблерные реализации, зарекомендовавшие себя как самые быстрые. Они превосходят выдаваемое компиляторами где-то на 10% (это к тому, что дальше пооптимизировать вряд ли получится). Под e2k я реализовал то же самое на Си с использованием интринсиков и получил отличный результат. Пробовал на ассемблере писать, но тут я отставал от компилятора. Я считаю, что это вполне корректное сравнение уровня микроархитектуры: что в одном, что в другом случае мы берём вручную оптимизированные реализации.
Понимаю Ваш обоснованный скептицизм
Ну вот видите. О чём тогда спорить
Я считаю, что это вполне корректное сравнение уровня микроархитектуры
Нет, это не так. Микроархитектура это намного большее, чем вручную наоптимизированные реализации. Тем более, в случае вашего алгоритма есть очень много "но", которые мне просто не хочется даже поднимать в онлайне.
В первом приближении что-то об микроархитектуре может сказать SpecCPU2017, по-крайне мере, вас поймут. Алексей из МЦСТ именно поэтому на SpecCPU2017 упор и делал. Хотя и в случае Эльбруса SpecCPU2017 тоже несколько обманчив.
Ассемблер и, тем более, исходники у нас в России никто не показывает.
Когда пишешь статью об оптимизации и сравнении и не показываешь исходники - сводит на нет полезность статьи и по сути статья ничем не отличается от фразы "мы что-то потестировали и что-то получили".
Ознакомьтесь, пожалуйста, с научными работами, ссылки на которые приведены в статье. Нигде в них нет исходного кода, но есть описание алгоритма, достаточное для понимания. Школьник повторить не сможет, но всем заинтересованным это не мешает воспроизводить результаты и использовать идеи.
Не надо пенять на научные работы плохого качества. То что в России в целом отсутствует культура написания научных работ (и публикаций результатов изысканий) не значит что это нормальная практика и так надо делать.
Простите, но звучит как очень слабое оправдание. Так что я продолжу настаивать что либо не пишите статью, либо выкладывайте нормально результаты.
Я его взял, потому что он крайне показателен.
честно говоря, я не понял, что он показал в итоге )
ну да, компилятор под эльбрус сыроват, но уже то, что оптимальный код существует (и даже оптимальнее, похоже, в пересчёте на такт, чем для x86) — это уже говорит, что этот пример не подходит для иллюстрации плохой производительности на такт эльбруса.
Он показал, что даже на простейшем коде без игр с компилятором и правки исходников мы не можем получить нормальный перформанс.
Данный пример хорошо иллюстрирует то, что будет происходить в реальности, а не на красивых презентациях от МЦСТ.
ну игры с компилятором тут не выглядят какими-то запредельными. так, небольшие игрочки )))
если серьёзнее, именно на этом примере вполне верится, что компилятор могут быстро пофиксить.
ну игры с компилятором тут не выглядят какими-то запредельными. так, небольшие игрочки )))
Ну да. А теперь представьте то же самое на коде сложных приложений и на триллионах строк из реальной жизни.
если серьёзнее, именно на этом примере вполне верится, что компилятор могут быстро пофиксить
Ну т.е. на компиляторе, который разрабатывался 20+ лет и в который вложено сотни человеко-лет разработки, приходится фиксить случай простейшей сортировки? Нет подозрения, что здесь есть подвох?
Там не проблема пофиксить, если знать, что этот цикл самый горячий. А это неизвестно без профиля или подсказки. Проблема в том, что такого рода оптимизация может легко дать серьёзную деградацию, если, например, внутренний цикл имеет обратную дугу с вероятностью 0.5, например. Отсюда основная проблема в данном случае. Этот пример был ответом на рассказы, что "в реальном коде всё довольно неплохо".
Можно дальше приводить примеры, где всё плохо будет даже с тряской опций и ручными оптимизациями. Но для этого нужен уже доступ к машине, чтобы результаты нормально чекать, а не игрушки вроде годболта. И главное, зачем, если на простейших случаях такие проблемы.
Там не проблема пофиксить, если знать, что этот цикл самый горячий. А это неизвестно без профиля или подсказки. Проблема в том, что такого рода оптимизация может легко дать серьёзную деградацию, если, например, внутренний цикл имеет обратную дугу с вероятностью 0.5, например
вы именно про этот случай или вообще? если про этот — хотелось бы деталей, как так может получиться.
Но для этого нужен уже доступ к машине, чтобы результаты нормально чекать, а не игрушки вроде годболта
ЕМНИП доступ по ssh получить не проблема.
всё-таки, я считаю, что невозможность качественной кодогенерации под vliw в случае использования «обычного» кода — это принципиальный момент.
если это действительно так, то эльбрус надо закапывать, если всё-таки не так — пусть живёт )
вы именно про этот случай или вообще?
вообще, это же принципиальная проблема. такая оптимизация внутрененнего цикла небесплатна - она стоит многих тактов подготовки, которые вы можете лицезреть на приведенном примере
если про этот — хотелось бы деталей, как так может получиться
Конкретно в этом случае у вас итерация внешнего цикла начинает работать 30+ тактов. Это цена, которую вы заплатили за оптимизацию внутреннего цикла. Ну а теперь представьте, что мы во внутреннем цикле почти не крутимся, а в реальности работаем почти всегда во внешнем.
ЕМНИП доступ по ssh получить не проблема.
нет, это проблема. да и как я уже написал выше, столько времени я тратить не готов уже. По-моему, я привёл более чем убедительные аргументы. если кого-то они не устраивают или хочется в чём-то доразбираться - пожалуйста, получайте доступ и разбирайтесь
всё-таки, я считаю, что невозможность качественной кодогенерации под vliw в случае использования «обычного» кода — это принципиальный момент.
Совершенно с вами согласен. Об этом и статья.
если это действительно так, то эльбрус надо закапывать, если всё-таки не так — пусть живёт )
в теории можно попытаться найти какую-то нишу, например, для HPC кластеров, где мы будем плавучку долбить и там в общем потратить время на оптимизацию кода в целом обычный подход. Но люди должны понимать, на что они идут. Потому что не все HPC на Эльбрус хорошо лягут, всё равно
Конкретно в этом случае у вас итерация внешнего цикла начинает работать 30+ тактов. Это цена, которую вы заплатили за оптимизацию внутреннего цикла. Ну а теперь представьте, что мы во внутреннем цикле почти не крутимся, а в реальности работаем почти всегда во внешнем.
ИМХО это чуть ли не самый важный момент во всём обсуждении, а он спрятан где-то в глубюине комментариев.
то есть проблема, если я вас правильно понял, была не в том, что оптимизатор плохо оптимизировал, а в том, что он не так оптимизировал (исходил из неверных предположений о профиле исполнения кода), а цена ошибки гораздо больше, чем у x86.
мне, как человеку далёкому от эльбрусов, это совершенно неочевидно.
Конечно же - он не знает профиля (да даже если знает, там есть другие проблемы, но Бог с ними). Поэтому он не знает, как ему лучше соптимизировать и получается то, что мы видим. А аппаратура тут не подстрахует.
Мне казалось, я это достаточно подробно в обеих статьях объяснял. Видимо, не достаточно хорошо получилось.
К примеру, если мне сейчас поставить ПК на базе топжыр Эльбруса, то он так и останется стоять в углу, т.к. нужный мне софт для работы на него точно не портировали и врядли портируют вообще, а запускать под СБК задачи, которым надо кучу памяти и кучу ядер, желательно ещё на высокой частоте работающих — это так себе, вариант пригодный только на случай, когда «за доллар будут давать по морде».
Как инженеру-алгоритмисту мне этот подход не нравится (в случе сферической программы в вакууме она должна быть вылизана и т.д. — ну чем не идеал для VLIW компилятора)
а я наоборот с годами начал понимать, что из всех вариантов кода надо выбирать самый читаемый, а применение оптимизаций, усложняющих код, должно быть только там, где оно уместно.
2 такта (и даже меньше) получается и на современных x86, вон выше перемеряли. И под него тоже можно начать код переписывать, исходя уже из микроархитектуры конкретного проца.
Тут же всё просто фундаментально - есть количество вычислительных устройств, чем больше мы их используем, тем лучше. Если каким-то образом (потрясти опциями компилятора, переписать код и т.д.) сделать так, чтобы компилятор смог разобраться, разорвать нужные зависимости и применить необходимые оптимизации - то в пределе на Эльбрусе вы придёте к тому, что ОоО получает автоматом.
Поэтому если вы можете потрясти опциями и переписывать код - то получаете то, что в вашем примере
Если только первое (и заточить оптимизации) - цифры Spec2017
В реальной жизни, когда нет ни того, ни другого - получаете то, что я показал в статье.
Ну согласитесь, ситуация, когда для получения самого лучшего результата надо вместо -O4 поставить -O2, это достаточно странно. Понятно, что об этом догадаться невозможно.
Странная? Странная! Кто бы мог подумать, что то же самое происходит на x86. Встаёт вопрос, почему Вы в одном случае выбираете -O2, а в другом -O4, хотя для lcc заявляется примерно аналогичное gcc поведение для уровня -O2 и включение агрессивных платформо-зависимых оптимизаций с -O3. Честно говоря, я всё больше начинаю думать, что Вы проверили все эти комбинации, а в публикацию пустили наиболее выгодный для Вас вариант.
Автор комментария, на который вы ссылаетесь, либо вообще не имеет понятия, что он делает и что измеряет, либо очень умело притворяется. Не повторяйте его ошибок.
Не нужно быть экспертом, чтобы увидеть, что GCC выдает абсолютно одинаковый ассемблерный код сортировки и с -О2, и с -О3. Разница в измерениях объясняется тем простым фактом, что godbolt - это и близко не инструмент для проведения каких бы то ни было бенчмарков.
Я, кстати, не могу не отметить, что от Вас поступило 2 наиболее интересных дополнения к статье (про микроархитектурную скорость Kunpeng'ов и про компилирования с -O2) .
Если для вас актуально, напишите мне в личку, я пришлю приглашение на Хабр
Для меня как-то оба ассемблера малопонятны. Но если выучить ключевые слова, то скорее всего оба станут одинаково понятными. Что такого мы должны оценить на godbolt, можете пояснить?
Что означают 6 пар фигурных скобочек в ассемблере эльбруса? И как вы посчитали 13 тактов?
послушайте, я в первый раз увидел ассемблер эльбруса, и ответы именно на эти вопросы мне кажутся очевидными: фигурные скобки используются для удобной записи широкой команды, всё внутри них — это одна команда, которая должна выполняться за один такт, команд 6, итого 6 тактов. однако, в некоторых из команд стоят nop'ы, на которых набегает ещё 7 тактов, думаю, это ожидание данных из памяти.
почему их так много и как получилось, что тот же компилятор с другим настройками генерирует рабочий код в котором на цикл приходится один такт — это уже надо разбираться.
А мне вот как-то совсем не очевидно, что 3 нопа - это 7 тактов. Да и почему эти нопы находятся не в отдельных фигурных скобках, если представляют собой отдельный такт?
А мне вот как-то совсем не очевидно, что 3 нопа — это 7 тактов
после каждого нопа есть число, означающее сколько тактов надо подождать.
Да и почему эти нопы находятся не в отдельных фигурных скобках?
думаю, дело в экономии места, vliw код и так достаточно «пухлый», что является проблемой. выгоднее прицепить этот nop к какой-то команде.
Тогда следующий вопрос: какой смысл начинать исполнение с двух нопов?
выше было написано, не знаю, насколько это правда )
https://habr.com/ru/post/576420/#comment_23454006
Кто производит чипы сетевого контролёра и прошивки к ним?
Кто производит чипы HDD/SSD и прошивки к ним?
Потом смотрим на цену получившихся решений и понимаем, что эти решения пойдут только для военных дел и супер-параноиков типа Сноудена.
я вообще не понимаю этих разговоров о закладках. да, для облачного хостера, который запускает сторонний код, уязвимости в железе вроде spectre могут быть опасны.
мне кажется, что для условной задачи обсчёта данных с радаров подразумевается, что компьютер не подключен к публичным сетям, на нём запускается только доверенное ПО. и т.д., и т.п.
как при таких вводных злоумышленник сможет в час X включить рубильник, запускающий закладки — ума не приложу.
Ну, к примеру, ходят слухи, что ПВО можно выключить.
А еще в Иране "ломались" микроконтроллеры, использованные в важнейшей для них ядерной программе.
Да что там, одно сообщение на мобильный телефон может дать полный контроль над трубкой. Мало ли где этот мобильник потом окажется, вдруг, в полезном месте вроде кармана солдата на посту.
Intel так вообще прямо в чипсеты вшивает процессоры, работающие даже без питания.
Какая-нибудь гадость на компьютере программиста, перепрошивающего контроллер. Гадость по таймеру что-то делает... Мир полон дивных и удивительных вещей.
Или, как шутят, "если вы параноик, то это не значит, что за вами не следят".
про пво — да, не удивлюсь, если в dsp могут быть закладки.
ну так, надеюсь, именно эту часть мы используем свою.
в случае ирана там был обычный вирус под windows, который удачно удалось внедрить.
разработчики эльбруса говорят о качественной эмуляции x86, так что стой тот сименсовский (или чей там это был?) софт управления на эльбрусе в режиме эмуляции x86, вирус точно так же запустился бы.
а вот то, что вирус смог добраться до машин, управляющих ключевой инфраструктурой — явное разгильдяйство.
и, опять же, там была целенаправленная атака. собственная архитектура по большому счёту от этого не защищает (или вы думаете, что у американских военных до сих пор нет описания системы команд эльбруса, а то и рабочих экземпляров?)
«процессоры, работающие без питания» — очевидный бред.
да, me есть, но как вы собираетесь слать команды в случае изолированного контура — вопрос.
мобильник у солдата — да, проблема. начать с того, что у него его вообще не должно быть, но чем дальше, тем нереальнее это выглядит.
только причём тут эльбрус?
и т.д., и т.п.
«процессоры, работающие без питания» — очевидный бред.
у них могут быть отдельные батарейки. Ну и Intel ME вполне себе работает, например, во всяких там спящих режимах.
только причём тут эльбрус?
чем больше сделано дома, тем меньше возможности для таких вот странных ситуаций, когда что-то вырубается по скрытому таймеру
Хотя, конечно, полностью все сделать на базе сложно. Но хоть что-то (и довольно много).
чем больше сделано дома, тем меньше возможности для таких вот странных ситуаций, когда что-то вырубается по скрытому таймеруНеверно. Верно так: «пока вообще все не сделано дома, есть шанс для таких странных ситуаций»
Одно дело с позиции безопасности - обычный Intel или Arm, совершенно другое - третья архитектура. Безопасники в таких случаях говорят про attack surface и стремятся ее, поверхность, уменьшить.
Хотя, конечно, полностью все сделать на базе сложно. Но хоть что-то (и довольно много).
ну так я не спорю. только серверный процессор собственной архитектуры, который de facto мы не можем производить внутри страны, — явно очень трудоёмкий путь, при этом выхлоп в плане защиты от закладок для меня совершенно неочевиден; ИМХО от закладок нужно защищаться совсем по-другому (изолированные контуры, отказ от запуска недоверенного кода, и т.п.)
Максим, добрый день.
Я всего лишь на одну вещь внимание обращу. Вы пишете:
Что мы видим? Одна итерация основного цикла занимает 13 тактов. В нём 9 семантически полезных инструкций (остальные – это специфика Эльбруса, не влияющая на реальное IPC). Т.е. IPC составляет 0.69 инструкций в такт. Эффективность использования широкой команды в данном случае очевидна – она крайне низкая. Никаких разрывов зависимостей не произошло, DAM не применился, но зато произошёл абсолютно бессмысленный инлайн функции Sort в функцию main.
Вот здесь Вам наглядно показали что на самом деле для Эльбруса IPC составляет 7 инструкций на такт, или 1.84 такта на итерацию. Это при сравнении с приведённым Вами интеловским IPC 2.67 и примерно 3 такта на итерацию.
Для того чтобы статья была более честной и объективной, считаю что необходимо сделать дополнение к данной статье с указанием этих цифр. Ведь мы же говорим о перспективности и микроархитектурной скорости, а тут сразу виден потенциал платформы.
С уважением, Маркин Алексей.
векторизовать — использовать simd? можете привести пример кода?
мне пришлось отключить simd, тот код с simd, что генеририрует gcc100, работает в зависимости от процессора так же, или заметно медленнее «наивного».
То-то и оно. Почему-то люди считают, что руками наоптимизировать цикл для Эльбруса это нормально, а для x86 gcc -O3 и пойдёт. Но всё же это не главная проблема. Главная - это то, что без ручных настроек и допилок кода Эльбрус сильно деградирует по перформансу, в отличие от RISC/CISC. А это фаталити на широком рынке.
Максим, но ведь ваш тезис был про принципиальную невозможность оптимизировать программу лучше, чем на суперскалярных x86-процессорах. А оказалось, что это можно сделать — и получается почти вдвое быстрее. Обнаружилась проблема в компиляторе — ну так пусть исправляют.
у вас разные трактовки "про принципиальную невозможность"
вы сейчас говорите про "возьмём 10 академиков и 100 процессоров, сформируем из них институт, и он будет 10 лет писать одну программу"
а он говорит про "ООО 'три директора и два программиста', из которых один уже уволился, а другой студент на испытательном сроке 'за еду', и которым нужно каждые два месяца новую версию программы на рынке продавать"
Одну единственную программу вылизать под Эльбрус++, ради одного единственного рекламно-пропагандисткого шоу, да, можно. Реальный массовый рынок - нет.
Подождите, но ведь исходный тезис был в том, что «Эльбрус» принципиально неулучшаем и что он будет работать принципиально хуже процессоров Intel и AMD. А тут вдруг оказалось, что предложенный цикл сортировки компилируется в одну широкую команду. Ну так можно признать, что исходный тезис ложен или нельзя? А дальше давайте клясть недоработанный компилятор и закрытость системы команд. Я вот с вами наперебой готов это всё клясть — но после того, как признаем, что ложен исходный тезис про неспособность статического планирования «Эльбруса» достичь эффективности выше суперскалярного процессора.
Исходный тезис остаётся - VLIW принципиально хуже RISC/CISC подхода. Потому что наоптимизировать руками можно всё, что угодно. Куда более сложное hw затачивают руками.
Данный пример просто явно показывает, что мы даже простейший код в виде сортировки не можем эффективно без участия человека соптимизировать. На чуть более широких тестах - Spec2017 мы уже видим проигрыш в 3-4 раза современным процам. А на ещё более широком наборе задач - разрыв усугубится. Да о чём мы говорим - на Coremark'е Эльбрус умудрился проиграть Байкалу. Как предлагается такую архитектуру внедрять массово на предприятия? Для меня ответ очевиден. И в статьях я постарался донести суть проблемы.
принципиально неулучшаем
...в рамках сложившейся индустрии и сложившегося рынка "ширпотреба" компьютеров и программ. Вы меняете тезис. Меняете в нём условия.
Может ли человек летать? Да может, купил билет на самолёт и полетел. Значит ли это, что потерявшийся на необитаемом острове человек может улететь. По вашему - да значит, меняем условия задачи, из "шляпы фокусника" достаём аэропорт, кассу и кошелёк с деньгами - и полетели.
А дальше давайте клясть недоработанный компилятор
В реальном мире он НИКОГДА не будет доработан.
Ну или может быть, лет через 50, если вам от практических вопросов хочется улитеть в стратосферу теории.
Как MULTICS, который когда-то считался запредельно сложным, а сегодня меньше даже MINICS'a не то что Linux/Windows.
Но MULTICS не вернулся к жизни, хотя его фанаты считают все UNIXы абортированными уродцами, и даже написали эпохальную книгу про это (hacker's jargon dictionary).
Если лет через 50 кто-то когда-то сможет сделать практически применимый для многозадачных ОС и многопоточных программ общего назначения VLIW-компилятор, Эльбруса там всё равно уже не будет.
и закрытость системы команд
Это только крышка в гвоздь гроба. Система команд Itanium была открыта, ресурсов у HP+Intel+Microsoft+Linux/GCC было на порядки больше. Всё равно не выжили.
Т.е. в случае гипотетического МЦСТ-для-всех-потребителей, закрытость команд - это просто овердоз уже смертельно больного наркомана. Без него результат тот же, просто не так быстро.
А второй гвоздь, что не смотря на примеры более-менее жизнеспособных Transmeta и Radeon МЦСТ с упорством зомби долбятся в C++, вмеcто JIT-компиляторов (JS, C#, JVM, etc, а также OpenCL/CUDA/DirectCompute), где у них были бы шансы.
ложен исходный тезис про неспособность статического планирования «Эльбруса» достичь эффективности выше суперскалярного процессора
На чисто расчётной задаче, без ветвлений, тем более без многопоточности, тем более без каких либо других задач, кроме "числогрызки" - может. Возьмут "10 академиков и 100 профессоров" и они за 10 лет на ассемблере напишут идеальный алгоритм для этих данных на этом процессоре.
Правда, за это время те же данные уже 10 лет как обсчитают на ферме примитивных x86 или ARM, но медальки академики получат, за повторение того же результата 10 лет спусти.
Правда, за это время МЦСТ выпустить другой процессор, на котором этот код станет неоптимальным, и придётся его выкидывать им начинать с нуля.
Правда, даже у лучшем случае результат этот работы будет невозможно применить к чем-то другому, к любой другой задаче. Чисто одноразовое усилие. Как у Дугласа Адамса, считали триллионы лет, потратили полностью звезду, и насчитали "42". Величайший академический результат с околонулевым влиянием на реальный мир.
оказалось, что это можно сделать — и получается почти вдвое быстрее
Оно не получается вдвое быстрее. Потому что тем же самым (оптимизацией под машину) можно заняться и на x86. В этом и заключается постоянный подлог.
но ведь ваш тезис был про принципиальную невозможность оптимизировать программу лучше, чем на суперскалярных x86-процессорах.
Мой тезис был про то, что невозможно статически компилятору всё разобрать и в пределе это всегда уступает динамическому планировищику.Мы не можем достичь максимальной производительности на практике. Наоптимизировать всегда что-то можно. Но надо понимать, насколько такой подход применим на массовом рынке. И вы опять забываете, что это простейший идеальный пример для Эльбруса. А в реальной жизни вам даже ручная оптимизаация не поможет. Тут в комментах мы это уже обсудили. Представьте, у вас вероятноть обратной дуги во внутреннем цикле - 0.7 например. А внешний - основной. Сколько тогда будет работать предложенный выше оптмизированный код?
Этот же пример был приведен не для того, чтобы показать, что Эльбрус никак не может его соптимизировать. А для того, чтобы опровергнуть утверждения Алексея что "в реальности всё неплохо". Перечитайте все статьи внимательно на данный счёт.
Обнаружилась проблема в компиляторе — ну так пусть исправляют
Ну вот вам самому-то не смешно? 20+ лет делаем компайлер, а он простейший код в несколько строк не может скомпилить. Сколько ждать тогда, 100 лет?
К тому же я написал, что здесь нет никакой ошибки компайлера. Это типичная лапша от МЦСТ, которой они кормят людей уже 20+ лет, обещая что "ещё немного, ещё чуть-чуть". Без профиля тут непонятно, как оптимально соптимизировать. Отсюда и все проблемы. А с профилем будут другие примеры и другой класс проблем.
Ну займитесь оптимизацией под x86 — покажите, что можно сделать быстрее, чем на «Эльбрусе». Вы просто сменили тему разговора — в данном примере ваш тезис про неэффективность «Эльбруса» не оправдался. Можно это признать? А после признания говорить уже о том, что компилятор нехорош, что его долго пилили и всё равно он не может сходу определить горячий цикл и правильно его оптимизировать. Я тут вас абсолютно поддержу — это недоработка программистов. И в тезисе про закрытость системы команд поддержу.
Я просто не понимаю этого нежелания признать, что пример получился не вполне в тему исходного тезиса статьи. Вы же даже приписку к статье не хотите сделать, что вот при таких-то настройках оно компилируется более эффективно, чем на x86. Это же неправильно. И ваши оппоненты укажут на это нежелание как на вашу ангажированность. Вы делаете свою статью подударной.
А после признания говорить уже о том, что компилятор нехорош, что его долго пилили и всё равно он не может сходу определить горячий цикл и правильно его оптимизировать. Я тут вас абсолютно поддержу — это недоработка программистов
уверены, что это недоработка программистов? на мой взгляд задача в общем случае выглядит если не совсем нерешаемой, то близкой к этому.
Это же тоже надо подтверждать фактами. А то выглядит, как будто решаема лишь задача создания продвинутого суперскалярного RISC-V процессора фирмой Yadro. Но как по мне, решаемость этой задачи тоже надо очень сильно доказывать.
А то выглядит, как будто решаема лишь задача создания продвинутого суперскалярного RISC-V процессора
эта задача, очевидно, решаема, некоторое количество коммерчески-успешных процессоров, думаю, появится в ближайшие несколько несколько лет.
будет ли среди них отечественный — не знаю, но мне это кажется не настолько нереальным, как превращение эльбруса в коммерчески-успешный проект.
Но как по мне, решаемость этой задачи тоже надо очень сильно доказывать.
Этот вопрос существует только у людей, далеких от индустрии процессоров. Нет никакой принципиальной проблемы в решаемости этой задачи. Все RISC/CISC архитектуры по сути своей одинаковы. Вопрос только в том, хватит ли технических компетенций у конкретного коллектива разработчиков, чтобы решить эту задачу.
А то выглядит, как будто решаема лишь задача создания продвинутого суперскалярного RISC-V процессора фирмой Yadro. Но как по мне, решаемость этой задачи тоже надо очень сильно доказывать.А что там доказывать? Разными российскими компаниями разработаны десятки процессоров самой разной сложности. Почему вы считаете, что ещё одна компания не справится с ещё одним процессором?
Ну нет же - я вам выше написал ответ. Вы просто не поняли, в чём главная суть статьи. Этот пример отличный показатель проблем Эльбруса. Если вы этого не видите - я ничего не могу поделать
Это не недоработка программистов - это принципиальный недостаток архитектуры, что она без ручной оптмизации не может работать эффективно. Сколько раз я должен написать этот тезис? Он же и есть главный во всех статьях об Эльбрусе.
Вы выдвинули тезис и подтвердили его примером. Ваш пример опровергли. Какие у вас адекватные варианты действий:
Признать, что пример неудачный, но тезиса это не отменяет. Привести пример получше или что-то получше примеров вообще.
Отказаться от тезиса.
Показать, что опровержение несостоятельно, и ваш пример всё-таки иллюстрирует ваш тезис, а не обратный.
Менять тему - ответ неадекватный. Хотя в статье действительно есть другие тезисы. Но смещать фокус к ним, игнорируя проблемный, как оказалось тезис о принципиальной ограниченности микроархитектуры, - это попытка замыливания вместо нормальной дискуссии.
Откройте мою первую статью, самое начало. Что там написано? Вот есть пример простого цикла, внутри call, работаем 1 такт и там и там, всё хорошо. Т.е. микроархитектурная скорость равна, как и по результатам ручной оптимизации цикла из данной статьи. Что происходит, если call не заинлайнился? В x86 мы начинаем работать 3 такта, в e2k 17. Что мне на это ответили? Это синтетический пример, в реальности супер-пупер анализ и эвристики и всё хорошо, покажите реальный пример. Я его показал, как все эти супер пупер эвристики работают. Т.е. в рельности мы не можем код нормально соптимизировать. И это и есть принципиальная проблема микроархитектура. Это главный тезис.
Перечитайте внимательно обе статьи и не надо свои фантазии выдавать за мои тезисы и тем более выдвигать какие-то претензии, не разобравшись в вопросе до конца.
Центральный тезис этой статьи - микроархитектура Эльбруса принципиально плоха - не может исполнять код эффективно. Подкреплено это примером когда Эльбрус исполняет код неэффективно. Однако, вам со всей очевидностью показывают, что по крайней мере в этом случае, проблема в компиляторе. Вместо того, чтобы это признать, вы начинаете ссылаться на что-то ещё. Т.е. неявно признаёте, что пример неудачный и ваш тезис он не подтверждает. В явном же виде вы просто переходите на личности.
Это неадекватное поведение в дискуссии.
Нет Алексей, это всё в пользу бедных (мы в той ветке всё предметно обсудили). В этом и заключается главная проблема Эльбруса - потенциале, который на деле недостижим. Вы мне рассказывали, как супер-пупер эвристики могут со всем разобраться, а я вам привёл простейший пример, где все ваши рассуждения идут прахом. И именно по этому поводу я написал в самой первой статье:
Собственно говоря, именно с вышеуказанными проблемами связаны те многочисленные истории, когда пользователи Эльбруса, получив возможность скомпилировать и запустить своё ПО на данном железе, часто с первого раза получают удручающие результаты. Потому что если на небольших бенчмарках или тем более Spec2006/2017 (которые вылизывали 20+ лет) компилятор худо-бедно справляется и может сгенерировать близкий к оптимальному код, то на реальных проектах он уже не справляется, а т.к. аппаратура тут подстраховать не может, то производительность падает в разы. И начинается долгая история про то "как правильно переписать код проекта, чтобы lcc смог скомпилировать оптимальный код".
И дальше:
Поэтому оно старается фильтровать потенциальных клиентов, чтобы в случае возникновения перформанс проблем привлечь своих специалистов, которые могут разобраться в проблемах и с помощью правильных опций, допилок компилятора или переписывания горячего кода "под Эльбрус" улучшить производительность пользовательских задач. Но масштабируемость такого подхода, думаю, всем понятна.
Вот именно это мы здесь и увидели. Пришлось руками лезть в функцию сортировки, чтобы её наоптимизировать. Это можно делать в каких-то очень узких применениях. Но такая архитектура не имеет никаких шансов на широком рынке.
И вы должны понимать одну очень простую вещь. Всё, что я написал - это просто констатация факта. По-большому счёту от моих статей ничего не изменится в плане будущего Эльбруса - оно было предрешено уже в середине 2000-х. И прошлый начальник вашего же отдела ушёл в 2010-ом по той самой причине - не видел перспектив у Эльбруса, прекрасно понимая, что нереально создать такой компилятор, который требуется. А идею развиваться в сторону линейки Sparc руководство МЦСТ не поддержало. Т.е. уже в районе 2010-го многим в самом МЦСТ всё написанное стало понятно. И если честно, я пишу данные статьи скорее для вас. Потому что в МЦСТ есть инженерный потенциал, который, будучи направленным в правильное русло, может достичь выдающихся результатов. Но чем дольше вы бьётесь в стену Эльбруса, тем больше уходит время. Надеюсь, точка невозврата ещё не пройдена. Но принимать решения и что-то менять надо прямо сейчас.
Ради интереса прогнал бенчмарк сортировок на Эльбрус-8СВ и на примерно самом последнем Xeon. Кратко:
при выравнивании частоты Эльбрус-8СВ примерно равен по скорости Xeon Gold 5317 (последнее третье поколение Xeon Scallable на Ice Lake);
есть неожиданности/странности: quick sort существенно быстрее на e2k, а radix sort наоборот (буду смотреть как будет время);
сделав мелкую правку получил +10% на двух моих сортировках.
В текущем виде использованный бенчмарк, разными алгоритмами, по 1000 раз сортирует 42000 64-битных целых и выводит затраченное время в us.
Если не ошибаюсь, исходный вариант этого бенчмарка сделал Christopher Swenson работая в Google. Я же только добавил свои сортировки (yysort1 и yysort2) и расширил паттерны данных, ну и что-то по-мелочи. Кроме полностью случайного паттерна есть и другие (весьма важные). Исходники бенчмарка не являются образцом (он сугубо утилитарный), но "в принципе" пользоваться можно. Также стоит отметить, что большинство алгоритмов сортировки "допилено" до неплохого уровня, а не просто скопипащены из учебника.
С управлением частотой на Штеуде, откровенно говоря, я замучился. Специально брал процессоры на 3ГГц, чтобы включать управление частотой и гонять бенчмарки на удобном ровном/круглом значении. Но пока так и не получилось заставить всё ядра работать на нужной частоте (похоже что постоянная работа на 3 ГГц - это вранье/маркетинг, а реальный стабильный максимум только 2800 МГц).
Поэтому я сделал проще - сровнял Xeon 5317 по частоте с Эльбрус-8СВ, т.е. задал частоту 1500 Mhz: sudo cpupower frequency-set --min 1500MHz --max 1500MHz и прогнал бенчмарк.
Intel(R) Xeon(R) Gold 5317 CPU @ 1500 ГГц + gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1):
Running tests with random:
extra.h yysort1_int64 - ok, 2081347.0 usec
extra.h yysort2_int64 - ok, 2164745.0 usec
extra.h radix_sort7_int64 - ok, 343104.0 usec
sort.h tim_sort - ok, 3609279.0 usec
sort.h quick_sort - ok, 2775912.0 usec
extra.h std_sort_int64 - ok, 2446849.0 usec
extra.h std_stable_int64 - ok, 2670384.0 usec
sort.h heap_sort - ok, 2207371.0 usec
sort.h merge_sort - ok, 3295311.0 usec
sort.h shell_sort - ok, 4344429.0 usec
sort.h merge_sort_in_place - ok, 3130430.0 usec
sort.h grail_sort - ok, 3710524.0 usec
sort.h sqrt_sort - ok, 3189873.0 usec
stdlib qsort - ok, 4313366.0 usec
...
Эльбрус-8СВ @ 1500МГц + lcc:1.25.17:May-16-2021:e2k-v5-linux
Running tests with random:
extra.h yysort1_int64 - ok, 2312807.0 usec
extra.h yysort1_int64 - ok, 1807040.0 usec <<< после мелкой доработки
extra.h yysort2_int64 - ok, 2377249.0 usec
extra.h yysort2_int64 - ok, 1871099.0 usec <<< после мелкой доработки
extra.h radix_sort7_int64 - ok, 1153812.0 usec
sort.h tim_sort - ok, 3497091.0 usec
sort.h quick_sort - ok, 1691747.0 usec
extra.h std_sort_int64 - ok, 2788794.0 usec
extra.h std_stable_int64 - ok, 2760324.0 usec
sort.h heap_sort - ok, 3661523.0 usec
sort.h merge_sort - ok, 4256854.0 usec
sort.h shell_sort - ok, 3922864.0 usec
sort.h merge_sort_in_place - ok, 3830613.0 usec
sort.h grail_sort - ok, 4839326.0 usec
sort.h sqrt_sort - ok, 3508976.0 usec
stdlib qsort - ok, 7311078.0 usec
...
Символами <<< помечены результаты после небольшой экспериментальной правки.
Соответственно, у Эльбрусов я не вижу особых/неустранимых проблем с производительностью, но вижу отсутствие принципиальных проблем с безопасностью.
вижу отсутствие принципиальных проблем с безопасностью.1) Является ли принципиальной проблемой с безопасностью то, что весь обмен данными с памятью идет через IP-блок американской компании Synopsys?
2) Более ли безопасен Эльбрус, чем Байкал, если вышеуказанный блок у них одинаковый?
3) Есть ли у вас какие-то подтверждения крайне спорного тезиса по ссылке, о том, что «в RISC-V нет ничего хорошего/перспективного при выходе за рамки ниши микроконтроллеров и устройств класса IoT.»
Эти блоки от Synopsys (вроде-бы) крутили-вертели и заглядывали во все гейты...
Но тут речь о другом - у Эльбрусов адреса возврата и данные/аргументы не смешаны в одном стеке. Поэтому большинство атак через переполнение буфера, двойное освобождение и ROP не могут эксплуатироваться. Это не означает что Эльбрусы "не пробиваемы", но всякие болден-RISC-и, прочие MIPSы, ARMы и x86 - буквально решето в сравнении с e2k.
Да, Spectre/Meltdown тоже нет, и я уверен что не появятся в v7 (седьмой версии архитектуры), в том числе, благодаря нашим "позитивным" советам.
Что касается тезиса "в RISC-V нет ничего хорошего/перспективного при выходе за рамки ниши микроконтроллеров и устройств класса IoT", то как в анекдоте про "два штуки/килограмма нифига" - если кто-то считает что такое хорошее/перспективное есть, то пусть покажет или просто использует "это" на всю катушку.
вроде-быХорошее уточнение. Жаль, что подтверждений этому тезису у вас нет. И не будет, потому что задача «крутили-вертели и заглядывали во все гейты» большого хардмаркро блока, от которого вам точно не дают схематик и не факт, что дают GDSII, на актуальных для Эльбруса проектных нормах сопоставима по сложности и стоимости со всей остальной разработкой процессора. И не факт, что в России вообще имеется техническая возможность это сделать.
если кто-то считает что такое хорошее/перспективное есть, то пусть покажет или просто использует «это» на всю катушку.Я таких стартапов в США знаю штук пять наверное. Через пять лет Эльбрус будет пытаться конкурировать не с Intel, а с ними. Или с теми российскими процессорами, которые воспользуются результатами работы этих стартапов.
Не-не...
1. Через 5 лет ВТБ будет судиться с "ядрёным синкакором" в надежде вернуть остатки от 9-и ярдов, после того как Штеуд добавит декодер инструкций болден-риска в свои ядра...
2. Эльбрусы увеличат производительность в 3-5 раз: вдвое за счет роста частоты, а остальное за счет предсказателя переходов "с друзьями", ну и немного добавит компилятор.
За второй пункт готов поспорить на "ящик хорошего пива/коньяка", или (например) на 1 ETH.
За второй пункт готов поспорить на «ящик хорошего пива/коньяка», или (например) на 1 ETH.Готов поспорить на 1 ETH, что через пять лет Эльбрусы все так же будут содержать американские IP-блоки неизвестного содержания.
Хм, а где и как (через чье плечо) вы увидели "IP-блоки неизвестного содержания" в e2k или в Байкалах?
Или в том смысле что Synopsys и/или МЦСТ публично не отчитались за содержание?
Или что "для безопасности" нужно вытравить весь "ихний/буржуйский верилог"?
Вообще вы за что: открытые ядра, обмен/покупку IP, fair use/provide или железный занавес?
(вопрос риторический)
Тем не менее, аргумент безопасности "достаточно железобетонный".
Поэтому альтернатив e2k в области ответственных применений нет, ибо два стека и т.д. и т.п.
Соответственно, будет тираж, более приемлемая цена и ресурсы на разработку.
А в целом, "болден-риск" - смешно/прикольно, конечно.
Хм, а где и как (через чье плечо) вы увидели «IP-блоки неизвестного содержания» в e2k или в Байкалах?В том смысле, что эти блоки поставляются как хард макро, и МЦСТ не имеет понятия и возможности проверить, нет ли у этих блоков каких-то недокументированных возможностей. Информация о том, что используются именно хардмакро от Синопсис, публична.
Или в том смысле что Synopsys и/или МЦСТ публично не отчитались за содержание?
Вообще вы за что: открытые ядра, обмен/покупку IP, fair use/provide или железный занавес?Я за глобализацию микроэлектроники и за отсутствие лицемерия в импортозамещении.
Я за глобализацию микроэлектроники и за отсутствие лицемерия в импортозамещении.
а что вы под "глобализацией" понимаете? Это ведь противоположность импортозамещения. "Либо крестик снимите, либо..." (с)
а что вы под «глобализацией» понимаете? Это ведь противоположность импортозамещения. «Либо крестик снимите, либо...»Так я против импортозамещения в его нынешнем российском виде.
Глупо заниматься заведомо бесплодной конкуренцией с Intel и вливать в нее огромные по российским меркам деньги. Глупо ссориться со всем миром, из-за этого не иметь доступа к нормальному технологическому оборудованию для своих фабрик и жить в постоянном страхе «а что если США велят TSMC перестать работать с Россией» и «а где достать американские спецстойкие компоненты для спутников».
Импортозамещение здорового человека — это драйвер экономики, когда создаются продукты, конкурентоспособные на мировом рынке и способные не только вытеснить конкурентов с внутреннего рынка с помощью господдержки, но и занять долю конкурентов в мире. Конечной целью импортозамещения должен быть высокотехнологичный экспорт.
Завод «Микрон» получает 20% выручки от экспорта автомобильных и силовых чипов. Вот их надо поддерживать и помогать им заместить компоненты Bosch, из-за дефицита которых простаивает АвтоВАЗ.
Syntacore продает свои процессорные ядра за границу — вот их и надо поддерживать, потому что инженерные компетенции в России еще есть, в отличие от современных фабрик.
А Эльбрус на мировом рынке имеет ровно ноль перспектив и никогда не сможет реально конкурировать ни с Intel, ни с AMD, и вся его поддержка — это чисто политическая история напополам с распилом бюджетных денег в виде контрактов на поставки ПК в госструктуры. Никакой экономической отдачи от вложенных в развитие Эльбруса денег никогда не получится.
Так я против импортозамещения в его нынешнем российском виде.
Ну так с этого надо было дискуссию начинать, и этим же заканчивать! Вы не считаете необходимым делать отечественные процессоры общего назначения, потому что Intel, AMD и прочие уже всё на эту тему сделали.
О чем тогда вообще речь?
Вы не считаете необходимым делать отечественные процессоры общего назначения, потому что Intel, AMD и прочие уже всё на эту тему сделали.Не так. Я не считаю необходимым делать отечественные процессоры ради их отечественности. Если кто-то может сделать чип, который будет конкурентоспособен и по характеристикам, и по цене — вперед. Например, Байкалы с этой точки зрения выглядят интереснее Эльбрусов.
О чем тогда вообще речь?О том, что на бессмысленные потуги по созданию российских процессоров общего назначения тратятся бюджетные деньги, которые могли бы быть потрачены с большей для российской экономики пользой.
как-то не бьются полученные результаты с упоминаемыми в статье результатами spec cpu 2017.
пробовали запустить во много потоков?
что-то «крутили» в опциях компиляции?
Хм, а разве не очевидно что эти сортировки работают в один поток?
Все опции и скрипты сборки доступны в исходниках. Поэтому повторить/воспроизвести элементарно (просто `git clone` + `make`). Самое сложное, наверное, выровнять частоту ЦПУ или вручную отмасштабировать результаты.
Хм, а разве не очевидно что эти сортировки работают в один поток?
очевидно. не очевидно, что при запуске нескольких инстансов производительность останется прежней.
Поэтому повторить/воспроизвести элементарно (простоgit clone+make).
это-то я сделаю, только для x86. проверить для эльбруса сложнее.
Самое сложное, наверное, выровнять частоту ЦПУ или вручную отмасштабировать результаты.
с этим я проблем не вижу. смотрим реальную частоту после запуска теста. опыт показывает, что если нет проблем с охлаждением, то частота особо не меняется, так что можно её считать постоянной.
смотрим реальную частоту после запуска теста. опыт показывает, что если нет проблем с охлаждением, то частота особо не меняется, так что можно её считать постоянной.
Переключение частоты - это определенная процедура, которая требует времени. Поэтому, чтобы результаты бенчмарка были корректными (не искаженными), частота вообще не должна переключаться - не важно в минус (из-за перегрева) или в плюс (из-за появившейся вычислительной нагрузки).
Кроме этого, без отдельных "приседаний", нет гарантий что процесс/тред не будет мигрировать между ядрами. Поэтому требуется либо выставлять affinity, либо (что удобнее) добиться одинаковой частоты на всех ядрах. Вот последнее у меня пока не получилось сделать (некогда и пока нет большой необходимости этим заниматься).
при выравнивании частоты Эльбрус-8СВ примерно равен по скорости Xeon Gold 5317
И толку от таких достижений? Если эльбрус не может работать на тех же частотах, на которых может интел, то грош цена этим результатам. Максимальные частоты это такая же часть микроархитектуры и эльбрусы, судя по всему, физически не способны забраться выше, а интел с амд могут. Поэтому тестировать нужно не на одинаковых частотах, а на максимальных. А если прямо совсем честно хочется, то в рамках одного теплового пакета.
похоже что постоянная работа на 3 ГГц - это вранье/маркетинг
Если у матери нормально реализована схема питания и все хорошо с охлаждением, то все будет работать стабильно. 3ГГц это вообще базовая частота. Если он на ней не работает, то у вас что-то очень плохое с платформой. По факту, этот процессор на одноядерной нагрузке будет стабильно держать турбо частоты, т.е. 3.6ГГц. Любые иные результаты это повод для беспокойства.
И толку от таких достижений?
За в ~1000 раз меньшие деньги (в сравнении с бюджетом штеуда) сделан процессор, который:
- Примерно не позволяет вскрыть систему со стороны 99.99% хакеров. Грубо говоря, примерно "не пробиваем" в сравнении с Intel/AMD, ARM, болден-RISC и прочими MIPS-ами.
- При необходимости может быть переведен на другой тех-процесс и изготовлен внутри страны.
- Позволяет решать все требуемые задачи.
то в рамках одного теплового пакета.
Хм, так посчитайте, в моём понимании как-раз получается паритет.
если у матери нормально реализована схема питания и все хорошо с охлаждением, то все будет работать стабильно. 3ГГц это вообще базовая частота. Если он на ней не работает, то у вас что-то очень плохое с платформой. По факту, этот процессор на одноядерной нагрузке будет стабильно держать турбо частоты, т.е. 3.6ГГц. Любые иные результаты это повод для беспокойства.
Все-таки посоветую изучить матчасть, как именно и что там переключается/регулируется, и воздержаться от ненужных пояснений.
Конкретно в моём случае я не исключаю багов ядра и/или BIOS (теоретически могут быть прописываться не совсем те установки, что заданы). А нагрузку одно ядро конечно держит, но для многих (других моих) бенчмарков нужна стабильная и одинаковая частота на всех ядрах всех сокетов.
За в ~1000 раз меньшие деньги (в сравнении с бюджетом штеуда) сделан процессор, который:
Намного медленнее конкурентов, имеет устаревшую и неоптимальную для кода общего назначения архитектуру, не имеет нормальной поддержки со стороны софтовой экосистемы. А конечному клиенту нет никакого дело до бюджета, важна цена продукта. Она у интела низкая. На этом продукт уже закопан, но да ладно.
Примерно не позволяет вскрыть систему со стороны 99.99% хакеров. Грубо говоря, примерно «не пробиваем» в сравнении с Intel/AMD, ARM, болден-RISC и прочими MIPS-ами.
Голословное утверждение с учетом всех входных данных, что нифига он не сделан на своих мощностях и с применением только своей логики.
При необходимости может быть переведен на другой тех-процесс и изготовлен внутри страны.
И станет еще более ущербным как процессор общего назначения.
Позволяет решать все требуемые задачи.
Он позволяет решить только одну задачу — обеспечить импортозамещение. Все остальные задачи его конкуренты решают намного лучше.
Хм, так посчитайте, в моём понимании как-раз получается паритет.
Не получается. У процессоров термопакет в районе 150Вт. Только вот в рамках этого пакета интел работает на 3ГГц на всех ядрах, что оставит эльбрус далеко позади.
Все-таки посоветую изучить матчасть, как именно и что там переключается/регулируется, и воздержаться от ненужных пояснений.
Не нужно мне этих советов, я прекрасно и так знаю, как там что переключается. Оно работает как я написал — базовая частота, ниже которой проц в максимальной нагрузке в нормальных условиях не опускается. И турбо частота, до которой одно ядро может прыгать. Буст всех ядер у этого процессора это 3.4ГГц. Это базовая спека интела. Дальше дело за вендорами, которые запросто могут выходить за ее пределы и бустить процессор еще выше. Если процессор работает ниже спеки, то платформа говно и, по сути, не может работать с этим процессором, посему он должен быть исключен из ее списка поддерживаемых процессоров.
нужна стабильная и одинаковая частота на всех ядрах всех сокетов.
Кто это сказал? Если глянуть тот же SPEC CPU, то никто там частоты не фиксирует. Управление питанием это такая же часть микроархитектуры и нынче чрезвычайно важная. Для бенчмарков надо не частоты лочить, а несколько раз их прогонять как это делается в том же SPEC CPU.
Кто это сказал? Если глянуть тот же SPEC CPU, то никто там частоты не фиксирует. Управление питанием это такая же часть микроархитектуры и нынче чрезвычайно важная. Для бенчмарков надо не частоты лочить, а несколько раз их прогонять как это делается в том же SPEC CPU.
Более того - я не просто так в прошлом посте просил дать SPEC Power, который как раз фокусируется на энергоэффективности. Там умение менять частоту одно из основополагающих.
Но вообще типично еще используют прогрев и условно первые несколько итераций не засчитывают в общий зачет.
В целом к бенчмаркам человека выше есть ряд вопросов. Нарпимер что он меряет с размером массива в 42 тысячи элементов (и почему 42 тысячи это хорошее число?). Есть у меня предчувствие, что все упрется в L2 кэш (который при зарезании частот до 1.5 ГГц будет рабоать как ни странно на 1.5 ГГц) и у кого latency выше тот и победит (например из x86 скорее всего в топе окажется Sandy Bridge старенький, насколько я помню у него кэш чуть-чуть побыстрее как раз), если только компилятор совсем плохой код не сгенерировал. Впрочем надо конечно разобрать бенчмарк и посмотреть, но немного ради спора лень это проделывать (подожду мнения и доказательства от автора). Правда мне кажется автор обиделся за то что его второй аккаунт забанили.
Если процессор работает ниже спеки, то платформа говно и, по сути, не может работать с этим процессором, посему он должен быть исключен из ее списка поддерживаемых процессоров.
Не обязательно. Мог ошибиться сборщик системы или эксплуататор (перегрев VRM платы может вызывать троттлинг процессора, а это может быть вызвано тем что эксплуататор допустим поставил систему в закрытый шкаф рядом с трубой горячей воды или еще чем-нибудь подобным). По хорошему систему надо сдать по гарантии (если не сам собирал, если сам - долго и нудно дебажить в чем проблема).
Как выше упомянуто, этот "бенчмарк" - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42. Никакого отношения к размеру кэшей, e2k и т.п. этот код и константы в нём не имеют (кроме последнего экспериментального коммита).
Для всего остального есть/доступны исходники, берите пробуйте опровергнуть и т.п. Может действительно у меня проблемные/замедленные процы или матплата, а для Эльбруса припасено ведро жидкого азота ;)
---
Да и все ядра обоих 5317 получилось запустить на 3 ГГц. Причина соскока на 2800 была в одной из ~20 опций BIOS в X12DPi-NT6 и (видимо, всё-таки) неточности, из-за которой некоторый захардкоженный/дефолтовый суммарный бюджет по частоте на все ядра был меньше чем 3000*12 на сокет.
И вы проигнорировали половину того, что я сказал. Но, впрочем, ожидаемо. Уровень теста зато понятен.
Причина соскока на 2800 была в одной из ~20 опций BIOS в X12DPi-NT6 и (видимо, всё-таки) неточности, из-за которой некоторый захардкоженный/дефолтовый суммарный бюджет по частоте на все ядра был меньше чем 3000*12 на сокет.
Ну вот видите, а вы уже пытались обвинять интел, даже не разобравшись в вопросе.
Хм, этот «тест» - просто набор общеизвестных алгоритмов сортировки, подобранных и допеределанных сотрудником Google (в смысле понимаю, что я вам не авторитет). В основном он для сравнения этих сортировок между собой, в тех условиях и с теми параметрами, которые нужны запускающему.
Соответственно, было показано, что при работе на одной частоте, Эльбрус-8СВ и новейший Intel Xeon Gold 5317 выполняют некий одинаковый запрограммированный набор действий (1000 повторов каждой сортировки на 42 тысячах 64-битных элементах) за примерно равное время.
Если вы хотите выяснить что-то еще, опровергнуть результаты, либо показать что они почему-то некорректны или несостоятельны — так делайте/показывайте/доказывайте.
Ну вот видите, а вы уже пытались обвинять интел, даже не разобравшись в вопросе.
Пардон, так как-раз таки я разобрался в вопросе, написал об этом и (даже, вынужденно) оформил еще один багрепорт в поддержку Supermicro.
Теперь, похоже, Ваша очередь «разобраться в вопросе».
в смысле понимаю, что я вам не авторитет
Да не, в том что это алгоритмы сортировки и что они работают у вас пока еще есть benefit of a doubt в этом. На авторитетов можно не ссылаться, а то начинает напоминать карго культ немного.
в тех условиях и с теми параметрами, которые нужны запускающему.
Ну я вам, как выбравшему тест, задал несколько вопросов. Получил на них ответы? Нет. Это достаточно, на мой взгляд, очерчивает уровень в первую очередь вашего понимания что вы делаете. А за сим дальнейший разговор теряет смысл. Разберетесь в вопросе достаточно чтобы обосновано дискутировать - можно будет продолжить.
Пардон, так как-раз таки я разобрался в вопросе, написал об этом и (даже, вынужденно) оформил еще один багрепорт в поддержку Supermicro.Теперь, похоже, Ваша очередь «разобраться в вопросе».
Так я ссылаюсь на ваш же пост раньше, где вы заявляли
похоже что постоянная работа на 3 ГГц - это вранье/маркетинг, а реальный стабильный максимум только 2800 МГц
И порадовался за Вас, что Вы наконец-то разобрались в мат. части в этом вопросе и понадеялся что больше не будет голословных обвинений.
Теперь буду ждать когда вы освоите мат часть теста, который сами же предложили в достаточно мере.
Ну я вам, как выбравшему тест, задал несколько вопросов. Получил на них ответы? Нет. Это достаточно, на мой взгляд, очерчивает уровень в первую очередь вашего понимания что вы делаете. А за сим дальнейший разговор теряет смысл. Разберетесь в вопросе достаточно чтобы обосновано дискутировать - можно будет продолжить.
Хм, не увидел вопросов на которые не было-бы ответов и/или стоило-бы отвечать отдельно или еще раз. Но давайте пройдемся вместе:
Почему 1.5 ГГц?
Как указал в самом начале - чтобы выровнять частоту с Эльбрус-8СВ. Но, видимо, стоило подробнее пояснить, что базовая частота Xeon 5317 равна 3000 МГц и удобна тем, что ровно вдвое больше частоты Эльбрус-8СВ. Соответственно, 1500 было выбрано как удобно/равное значение после неудачи с переключением Xeon на его родные 3 ГГц.
Наверно стоило как-то обозначить, что сравнивается эффективная/наблюдаемая "скорость архитектур", как если-бы они (были сделаны по одному техпроцессу и) работали на одинаковой частоте. Но вроде-бы это и так понятно из контекста производимых действий и начала текста.
Почему 42 тысячи это хорошее число?
Собственно, я же уже отвечал "этот бенчмарк - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42". Проще говоря, такой размер сортируемого массива просто подходит (вроде-бы очевидно?) для сравнения скорости сортировок между собой и просто остался в исходниках с его предыдущего использования.
Еще у вас были упоминания про управление частотой в тестах на энерго-эффективность - но я сравнивал/оценивал другое.
Упоминание про "прогрев" и отбрасывание первых итераций - тоже не релевантно, так как при фиксированной частоте и замере по wall clock первая итерация растворяется в 1000 повторений.
Да, и на всякий - при переключении Xeon на 3 ГГц время работы бенчмарка уменьшает вдвое с точностью до погрешности. Можно было-бы добавить эти результаты, но в них нет ничего нового/интересного.
Но вроде-бы это и так понятно из контекста производимых действий и начала текста.
Тогда Вы не поняли вопрос. Переформулирую - какой в этом смысл?
Изменение частоты имело бы смысл, если бы у Эльбрусов была бы перспектива достичь 3 ГГц вот прям в ближайшем будущем без микроархитектурных изменений. Такой перспективы нет, значит занижение частоты не имеет смысл, так как, как ни странно, микроархитектура на нее влияет напрямую.
То есть уже один момент где сравнение заведомо некорректно.
Собственно, я же уже отвечал "этот бенчмарк - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42". Проще говоря, такой размер сортируемого массива просто подходит (вроде-бы очевидно?) для сравнения скорости сортировок между собой и просто остался в исходниках с его предыдущего использования.
Прочитайте, пожалуйста, мой вопрос повнимательнее. К сожалению для качественного сравнения "потому что 42" не является достаточным ответом.
Я напомню - я пытаюсь понять какую конкретно часть аппаратуры вы тестируете (чтобы понимать ожидаемое). Потому что пока что ваш пример очевидно может показать проблемы с оптимизацией кода на стороне компилятора (тут то что нужно делать изменение чтоб получить +10% - показательно, но нет объяснений почему тот же самый код что на Эльбрусах не был проверен на интеле). Почему это важно? Потому что Вы привели тест в рамках рассуждений о микроархитектурной скорости, значит нужно обоснование что тест является показательным и будет показывать сильные и/или слабые стороны архитектуры.
С подходом, отрицающим объяснения и попыток докопаться до сути тест не имеет никакого теоретического или практического смысла. Почему? Представим себе гипотетическую ситуацию что вы тестируете по факту скорость работы кэша (комбинированно throughput + latency), в таком случаи у вас практически любая железка, включая простой in-order risc-v или arm (кстати тоже было бы неплохо проверить Ваш тест) будет давать крайне схожие результаты, если компилятор конечно делает хоть какие-то оптимизации, на базе этого строить какие либо выводы будет невозможно.
Еще у вас были упоминания про управление частотой в тестах на энерго-эффективность - но я сравнивал/оценивал другое.
Я не говорил что вы сравниваете что-то в таком духе, я это использовал только в рамках указания другому человеку что есть другие способы получить разумные и даже повторяемые результаты без отключения энергосбережения.
Но такое сравнение было бы интересно, потому что, как ни странно, электричество это важная статья расходов какого-нибудь ЦОДа и если у тебя есть железка которая выдает X попугаев потребляя Y Ватт, и другая железка, выдающая X*2 попугаев потребляя те же Y Ватт, это очень весомый довод в пользу железки №2 даже если она стоит вдвое дороже (на горизонте типичной эксплуатации железа, затраты на электроэнергию выйдут на первое место, помноженное на десятки тысяч серверов это составит уже нехилую такую сумму). Но корректное тестирование железа в таком режиме уже не так просто реализовать (нужно как минимум уметь понимать свое энергопотребление, а по хорошему вообще отдать это на откуп внешнего устройства, которое на выходе даст лог за время проведения теста). И такое я вполне требую от людей из МЦСТ, как от компании (и требовал бы от тестовых лабораторий и прочих журналистов, в это влезших), но Вы вроде бы в категорию "человек из МЦСТ" не попадаете?
Упоминание про "прогрев" и отбрасывание первых итераций - тоже не релевантно, так как при фиксированной частоте и замере по wall clock первая итерация растворяется в 1000 повторений.
Оно также имело смысл для другого человека в первую очередь. Но для Вас оно имеет тот смысл, что во время первых нескольких итераций частота ядра успеет подняться до стабильного уровня и достаточно откинуть первые несколько значений чтобы избавиться от негативного эффекта скейлинга частоты, то есть не обязательно фиксировать ее на одном уровне. Да, зафиксировать базовую частоту проще, особенно когда не хочется разбираться в том как работают режимы энергосбережения, но это даст тоже слегка искаженные результаты относительно реального мира (и это придется учитывать всем кто читает такого рода тесты).
Это ещё один миф. По ссылке написана очередная дичь для домохозяек
Ну это уже перебор, или клоунада какая-то.
Вы как "специалист" утверждаете что на e2k все уязвимости (или большинство, или какая-то существенная часть, или хотя-бы одна...) эксплуатируются также легко как на x86 или болден-RISC?
Может покажите хоть один пример, либо концепт?
Для любой известной уязвимости, или гипотетической, на ваш выбор.
Так сказать, покажите мастер-класс домохозяйкам из Positive Technologies?
Клоунада - это вся та статья, на которую вы дали линк, а особенно указанный вами комментарий Леонида Юрьева, включая:
Фактически RISC-V — это недопеределанная система команд по мотивам MIPS для применения в простых, низкопроизводительных и дешевых процессорах
Однако, если же на основе ISA RISC-V пытаться делать универсальный высокопроизводительный процессор, то почти все ухищрения системы команд RISC-V начнут работать в минус
Но здесь есть и обратная сторона — пересаживаясь на готовые решения неизбежно теряешь собственные компетенции и возможность выбора в дальнейшем
У RISC-V плохо с безопасностью (поверхностью атаки), а в сравнении с «Эльбрусами» – плохо кошмарно, принципиально и неустранимо
Кроме этого, для достижения высокой производительности предполагается использование внеочередного и спекулятивного исполнения инструкций, что (мягко говоря) закладывает фундамент для уязвимостей класса Meltdown/Spectre/L1TF/ZombieLoad
Всё это бредни человека, не разбирающегося в процессорах и плохо понимающего в их безопасности и уязвимости. И где он работает - в PT, Интел, АМД или у Господа Бога мне абсолютно всё равно.
А теперь по поводу отсутствия проблем безопасности в Эльбрусе. Основа работа VLIW для достижения производительности - это спекулятивное исполнение инструкций. Поэтому он легко может спекулятивно исполнять команды по различным веткам, включая load. Откройте мой пример и посмотрите в код. Load операции с признаком "sm" - это они. Например:
ldw,0,sm %dr0, %dr3, %r7Если этого не делать, там деградация по перфу будет ещё в разы. Поэтому весь потенциал для набора проблем аля Spectre/Meltdown там есть. Хоть и при отсутствии branch predictor'а, но суть та же. И я где-то видел выступление того же Трушкина, где он аккуратно наличие проблемы признавал.
Просто при закрытости и малодоступности архитектуры никто Эльбрус на предмет реальных проблем особо не тестил. А если это сделать - там наверняка вагон проблем вылезет. Понятно же, где слабые места и куда копать. Плюс в Эльбрусе были ошибки в аппаратуре, которые при неудачной последовательности байт вообще машину клали. Не знаю, какова актуальная ситуация, но подозреваю что Errata там очень приличная и с неприятными сюрпризами.
Вся "безопасность" Эльбруса - это отдельный стэк вызовов и тэги. Про тэги можно пока забыть - это специальный режим, работоспособность которого непонятна и в продакшене они не используются - это только для каких-то специальных применений.
А выделенный стэк вызовов даёт защиту от типичных атак переполнения стэка. Но во первых, в типичных стэковых машинах эта проблема частично решается наличием nx-бита. А во-вторых - атака через стэк вызовов это только часть огромного числа вариантов атак. Поэтому по факту Эльбрус лишь снимает потенциальный риск эксплуатирования уязвимости с переполнением стэка. Это хорошо, но глобально проблем не снимает.
Кстати, а на сколько вообще критичны эти уязвимости? У меня сложилось впечатление, что похоже на вирусы на линуксе: они есть, но надо еще постараться чтобы это просто сработало, даже запуская собственноручно.
У вас зашкаливает апломб, самоуверенность и стремление выдать желаемое за действительное.
Однако, вот должен признать, что я сам себя «подловил». Конкретно, в одном из моих ответов есть фраза: «Да, Spectre/Meltdown тоже нет», что не соответствует действительности, в той полноте смысла как это читается. На Эльбрусах всех актуальных версий (3, 4, 5, 6) можно вызвать спекулятивную загрузку в кэш, а пока не доказано обратное (т. е. пока не опубликованы результаты подобных исследований) действительно нельзя говорить что Spectre/Meltdown отсутствуют.
Думаю всем понятно, что соответствующие дизайнерские решения были заложены в актуальные версии архитектуры Эльбрус до раскрытия информации о Meltdown/Spectre, и без какой-либо экспертизы/оценки возможных проблем (в кулуарах, ваш покорный слуга, предупреждал о потенциальных проблемах из-за спекулятивного выполнения еще лет 15 назад, но к e2k это вообще никак не относится).
На данный момент мне не известно о том, чтобы кто-то завершил работу по более-менее полноценному исследованию этой проблемы в Эльрусах, включая Positive Technologies. Но в соответствии с общепринятыми правилами и практиками, раскрываться такая информация будет после реализации всех необходимых защитных мер в софте и «раскатки» этих патчей у пользователей/заказчиков.
Тем не менее, проблемы типа Spectre/Meltdown есть примерно во всех актуальных процессорах со спекулятивным выполнением. Можно предполагать, что основные игроки будут как-то решать проблему, но где заявления что проблемы будут устранены в такой-то версии или к такой-то дате?
Возвращаясь к Эльбрусам - еще в начале 2018 года обсуждались варианты защиты и мной (и, вероятно, кем-то еще) был предложен достаточно очевидный и приемлемо надежный способ защиты от «спекулятивных проблем» в последующих версиях архитектуры. Соответственно, мне сложно поверить, что в v7 эта проблема сохранится.
Поэтому, у текущих Эльбрусов со Spectre/Meltdown не хуже чем у Intel/AMD и далее по списку. В следующих версиях Эльбрусов, уверен что этой проблемы не будет.
---
Теперь давайте вернемся к моим «бредням» в комментарии к статье Касперской и Ашманова:
Утверждается что у RISC-V нет преимуществ при выходе из low-end сегмента с переходом в high-end. Ну а какие технические/технологические преимущества, скажем в сравнении с MIPS64 или AARCH64? Простота декодера тут уже особой роли не играет и x86 хорошо это подтверждает. Как где-то уже мелькало — покажите эти преимущества, либо просто используйте их если они есть.
Сравнивается текущая «поверхность атаки» RISC-V и Эльбрусов. Тут у E2K действительно неоспоримое, сравнительно «непробиваемое» преимущество, ибо раздельные стеки для адресов возврата и данных примерно отсекают все сценарии атак через переполнение буфера на стеке и атаки с использованием ROP.
Это не значит что Эльбрусы не уязвимы, но значит что подавляющее большинство атак не реализуемо или крайне затруднено, и что вероятность эксплуатирования уязвимостей существенно меньше. Сформулировать это в виде четкой, достоверной и полезной метрики не возможно, ибо недостаточно статистики и мало самих Эльбрусов. Но можно переформулировать так — практика показывает, что почти любая система на x86/ARM/MIPS (и RISC-V как подвид MIPS) имеет уязвимости эксплуатируемые через ROP. А вот на Эльбрусах эксплуатирования подобных дыр пока не было.
Утверждается что RISC-V предполагает спекулятивное выполнение в высокопроизводительных ядрах и этим закладывает фундамент для Spectre-подобных уязвимостей. Мне по-прежнему не известна информация противоречащая этому тезису, ровно как и ничего не известно о проработки в RISC-V вариантов более-менее гарантированной защиты от Spectre, как это происходит сейчас с e2k.
----
Теперь по остальным вашим аргументам.
при закрытости и малодоступности архитектуры никто Эльбрус на предмет реальных проблем особо не тестил
Ну вот как-бы начинаем, и другого пути нет, кроме как вникнуть и проверить. Но не нужно смешивать заведомо известные принципиальные проблемы в архитектурах x86/ARM/MIPS и болден-RISC с еще не найденными проблемами Эльбрусов. Ну или другими словами — в Эльбрусах искать надо, а там вон бери и взламывай (наблюдаем регулярно).
в Эльбрусе были ошибки в аппаратуре, которые при неудачной последовательности байт вообще машину клали.
Ошибки в аппаратуре были и есть у всех. Буквально у всех, всегда и с самыми разными последствиями, из которых зависание — очень даже безобидно. Глядя в Errata иногда не понятно как оно вообще живет, а тут просто зависания. Премировать надо, если молчаливых багов нет.
Про тэги можно пока забыть - это специальный режим, работоспособность которого непонятна и в продакшене они не используются - это только для каких-то специальных применений.
Так а в чем проблема, что там «непонятно», или просто не пользовались? Конечно работа в 128-битном режиме доставляет, накладные расходы и отсутствие привычных вольностей с указателями. Но используется там где нужно/затребовано.
А выделенный стэк вызовов даёт защиту от типичных атак переполнения стэка… ...Поэтому по факту Эльбрус лишь снимает потенциальный риск эксплуатирования уязвимости с переполнением стэка. Это хорошо, но глобально проблем не снимает.
Эмм, в сухом остатке:
ваше владение темой недостаточно, а рассуждения достаточно ошибочны и опровергаются (в частности и в том числе) CVE-сводками.
полной гарантии никто дать не может, т. е. двойной стек и всё остальное не означает неуязвимость Эльбрусов.
незащищенность Эльбрусов может показать какое-нибудь пробитие, либо какой-то анализ показывающий потенциальную возможность/концепт эксплоита.
Пока «на руках» мы имеем множественные разнообразные примеры эксплуатации дыр на всех популярных архитектурах, и ни одного показанного практического пробития двойного стека Эльбруса, даже без использования тегов.
ни одного показанного практического пробития двойного стека Эльбруса, даже без использования тегов.А кто-то пробовал вообще? Ну то есть давайте сравним масштаб усилий, потраченных на взлом х86 и на взлом Эльбрусов. А то пока что Эльбрус выглядит как неуловимый Джо.
Взломов и утечек может и не было, но на кошельках пользователей облаков проблемы legacy-архитекур точно отразились:
www.opennet.ru/opennews/art.shtml?num=55186
Предложенные методы позволили поднять производительность обработчика JSON на основе библиотеки libreactor в окружении Amazon EC2 (4 vCPU)…
Отключение защиты от уязвимостей, вызванных спекулятивным выполнением инструкций. Использование параметров при загрузке ядра «nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off» позволило поднять производительность на 28%, а пропускная способность возросла с 347k req/s до 446k req/s
Видно, что для некоторых сценариев из-за заплаток от дыр в оптимизаторах на чипе придется увеличивать бюджеты на хостинг, т.к. нужно больше узлов для достижения прежнего уровня производительности. А на Э же вовсе невозможна эксплуатация уязвимостей этих оптимизаторов ввиду их отсутствия как таковых.
Вот видите. Вы сначала утверждали, что принципиальных проблем с безопасностью нет на Эльбрусе, а оказалось, что они всё-таки есть.
Остальные ваши измышления мне просто неинтересно комментировать. Могу лишь посоветовать перечитать мою статью про то, каким должен быть отечественный процессор. Часть ответов на ваши вопросы там есть.
Если же вы действительно хотите квалифицированных ответов и дискуссии, а не просто доказать какую-то религиозную позицию, то можно с оказией обсудить это в оффлайне в рамках какого-нибудь мероприятия.
Хм, эка Вы повернули ;) Конечно можете тут крутить/вертеть слова как хотите, в том числе и мои осторожно-аккуратные формулировки о (не)эксплуатируемости Specte-подобных проблем на Эльбрусах (требуется ждать завершения работ и раскрытия информации).
От советов перечитывать и дальше получать "квалифицированные" ответы я вежливо откажусь, и подведу черту чтобы не тратить время:
1. В Эльбруса со Spectre не хуже чем в любых других процессорах со спекулятивной загрузкой. А в следующей версии архитектуры этих проблем не будет. Тогда как намерения Intel/AMD по устранению не декларированы, а в участники RISC-V (видимо) вообще не считают это проблемой.
2. В Эльбрусе отдельный стек для адресов возврата, плюс возможность использовать теги и расширенные указатели для дополнительной защиты. Поэтому риски эксплуатации ROP, включая ошибки записи за пределы буфера, double-free и use-after-free кардинально ниже.
3. У RISC-V как ISA нет значимых технических/технологических преимуществ при переходе в сегмент высокопроизводительных ЦПУ.
Хм, эка Вы повернули ;) Конечно можете тут крутить/вертеть слова как хотите, в том числе и мои осторожно-аккуратные формулировки о (не)эксплуатируемости Specte-подобных проблем на Эльбрусах
Я не знаю, что можно перевернуть в вашей же фразе:
Вам на пальцах показали, что это не так. А вы вместо того, чтобы признать ошибочность данного высказывания, начинаете вилять пятой точкой.
Ну а черт в виртуальном пространстве вы можете рисовать сколько угодно. Толку то.
Вы не владеете темой, но продолжаете изображать специалиста и гнуть свою линию, неся при этом ерунду.
1. Эксплуатация Spectre/Meltdown требует локального доступа. А на Эльбрусах дополнительно еще и возможности конструировать нативный исполнимый код (в памяти или в файлах), так как JIT-ов примерно нет.
2. Уязвимости связанные с выходом за пределы буфера и использованием ROP могут эксплуатировать удаленно достаточно часто. Но на Эльбрусах вероятность их эксплуатации кардинально ниже из-за двойного стека. Причем это без учета возможности использования защиты «тегами», которая может быть использована только в процессах подверженных рискам атаки.
3. Соответственно, на Эльбусах относительно легко защититься от Spectre/Meltdown просто адекватным системным администрированием (например, хотя-бы убрать компиляторы и запретить взводить eXecute бит у файлов). Вероятность же удаленной эксплуатации Spectre/Meltdown через ROP стремиться к нулю. Причем всё это без учета противодействия Spectre/Meltdown со стороны ядра ОС.
Поэтому, я действительно вижу отдельные недостатки, но не вижу принципиальных проблем с безопасностью Эльбрусов, особенно в сравнении с x86, ARM, MIPS и болден-RISC (aka RISC-V).
3. У RISC-V как ISA нет значимых технических/технологических преимуществ при переходе в сегмент высокопроизводительных ЦПУ.Недостатков по сравнению с другими RISC тоже нет, а значит процессоры на ней тоже можно делать.
Отдельно, кстати, хочу заметить, что тон, которым вы говорите о RISC-V, вообще не способствует восприятию вас как человека, способного к конструктивной дискуссии. Дешевое хамство вообще никому не делает чести, а вы даже великое слово «болген» не утруждаетесь правильно писать)
Думается мне дело в том, что в последние месяцы благодаря поднятому МЦСТ сотоварищи шуму по поводу проекта изменения 719 постановления RISC-V обрел в глазах скажем так патриотической общественности ореол чего-то вражеского.
Вот тут можно глянуть пример такой натурально пропаганды. В прочем не советую, напрасно потраченный час времени.
«болген» - это, конечно, просто одна из опечаток (привык к высокому разрешению и мелкому шрифту, а зрение уже подводит - не замечаю).
Что касается тона и термина "Болден-RISC", то в этой шутке есть доля правды. Конечно, с одной стороны, хорошо что есть открытые ISA, IP и целые ядра. Но нас ждет зоопарк ядер не меньший чем зоопарк дистрибутивов Linux, и проблема зависимостей (привет nmp), как по IP, так и по программному коду.
Открытость ISA, расширяемость и доступность готовых IP, приводит к появлению массы как стартапов, так и отделов разработки собственных ЦПУ со "стартаперским духом" — когда важно быстро-быстро показать первый результат, а какие-то неудобные вопросы/проблемы замести под ковер с обещанием "потом всё порешаем, когда доплывём".
Среди таких вопросов — небезопасность RISC-V. Конечно RISC-V нельзя назвать более дырявым чем другие ISA в своих сегментах. Но для меня несколько странно/неожиданно, что в RISC-V бережно сохранено всё необходимо для эксплуатации всех традиционных ошибок/дыр.
Да, пожалуй, у меня есть определенное "профессиональное искажение". Тем не менее, свободно-бесплатная раздача ISA и ядер с явными (бережно сохраненными) проблемами с безопасностью — всё-таки начинает выглядеть как сыр в мышеловке.
При этом я (пока) не встречал человека на позиции ЛПР, который-бы понимал все сложности и проблемы связанные с управлениями этими зависимостями, и уже планировал бизнес-процессы и жизненный цикл устройств/продукции с учетом необходимости отслеживания ошибок/проблем/уязвимостей и (соответственно) необходимости обновлений и замены/отзыва проблемных устройств.
Так вот, совокупность всего вышеописанного, вместе с создаваемым хайпом, позволяю себе называть "Болден-RISC".
(думаю стоит написать статью с освещением всех этих вопросов).
Тем не менее, свободно-бесплатная раздача ISA и ядер с явными (бережно сохраненными) проблемами с безопасностью — всё-таки начинает выглядеть как сыр в мышеловке.Так идея состоит в том, что если вам важна скорость — вы садитесь и пишете свое быстрое ядро RISC-V, а если важна безопасность — то садитесь и пишете безопасное. И в том, и в другом случае вы получите и нужные вам свойства, и совместимость с широким пулом софта.
Открытость экосистемы, разумеется, имеет свои минусы, но какой-то конкурент ARM нужен, и вот такой способ его создать оказался самым лучшим — в отличие от не справившихся с задачей MIPS, SPARC и иже с ними.
Кроме того, бОльшая открытость как раз дает доступ к ловле дыр бОльшему количеству людей, что тоже в конечном итоге хорошо.
Немного смешались мухи и котлеты.
Вы говорите об «опциональной» безопасности конкретных реализаций ядер. В частности, например, о выключении/блокировании спекулятивной загрузки для предотвращения Spectre/Meltdown. Понятно что «так можно делать», в том числе решать/выбирать для каждого конкретного ядра (модели ЦПУ).
А я писал про проблемы ISA как таковой — сохранено всё необходимое для ROP и эксплуатации записи за границы буфера. Здесь нельзя реализовать каких-либо эффективных мер/механизмов без нарушения бинарной совместимости с ISA (Intel делал несколько подходов).
Хотя, теоретически, можно «форкнуть» и сделать RISC-6, поправив Spectre и остальные недопеределки (вот, если-бы Yando взялось, то я бы помог...).
Коллега посоветовал уточнить/пояснить "пару моментов" в моём обосновании небезопасности/нелюбви к RISC-V и фразе «бережно сохранено всё необходимое для ROP». Не думаю, что этот комментарий прочитает больше чем несколько человек, но считаю написать стоит.
Суть в том, что в RISC-ах в явном виде в аппаратуре нет стека "как на x86". Стек специфицируется/реализуется на уровне ABI посредством назначения ролей регистрам и соглашения о вызове функций, а инструкции push, pop, call и ret отсутствуют на уровне аппаратуры в явном виде и являются макросами и/или псевдоиструкциями. Программное обеспечение может реализовать поверх ISA один, два или сколько угодно стеков. Поэтому предъявлять претензии к набору команд RISC-V по поводу одного стека необоснованно — вроде-бы всё верно, но...
Собственно говоря, программно реализовать два стека, т.е. отделить данные (и потенциально уязвимые буфера на стеке) от адресов возврата, можно на всех архитектурах (имеющих косвенную адресацию), включая x86, ARM, MIPS и т.д. Принципиально ничего невыполнимого нет (но будут нюансы), разница только в объеме накладных расходах, трудоёмкости и (не)привязке к возможностям и/или контролю аппаратуры.
Если возможно программно реализовать два стека на чуть менее чем любой архитектуре ЦПУ и это, прежде всего, связано со сменой ABI, то «количество стеков» — это атрибут ABI? Либо ABI (может именно этот аспект) является какой-то значимой частью архитектуры как экосистемы?
Говоря что у RISC-V один стек, я знаю о возможности его разделить сугубо программно сменой ABI. Однако, если смотреть на «экосистему архитектуры» RISC-V:
представлен только «одностековый» вариант ABI и всей экосистемы;
явно определено
reg(sp) == reg(x2), push/pop в/из RAS дляjalr;нет упоминания о втором
spдля передачи большого кол-ва аргументов и хранения локальных данных, отдельно от RAS;для разделения стеков требуется специфицировать ABI, поправить компилятор(ы)/toolchain и доперепортировать софт.
Поэтому я критикую RISC-V как одно-стековую архитектуру подверженную ROP: не предусмотрено какое-либо разрешение/запрещения переходов/возвратов к командам, нет само-синхронизации кодирования команд переменной длины.
С другой стороны, на x86 тоже можно сменить ABI, разделить стек, многократно снизив этим риск эксплуатации уязвимостей. Подобное разделение приведёт к некоторой потери плотности кода, в основном из-за заметы push на mov [reg + offset] при подготовке/передачи аргументов. Но для рынка это давно табу из-за слома совместимости и необходимости допиливать тонны софта.
AMD разрабатывали AMD64 как расширение ISA более 20 лет назад, думая о time-to-market и минимизации непохожести с x86_32. Ожидаемо, что тогда не думали про два стека. Но с RISC-V принципиально иначе: потеря эффективности минимальная (занимаем один регистр), а слома ABI вообще могло не быть.
Поэтому мне не ясны (не очевидны) причины, по которым для RISC-V специфицировано только «одностековое» ABI и «бережно сохранено всё необходимое для ROP и эксплуатации традиционных ошибок выхода за пределы буфера на стеке».
Поэтому мне не ясны (не очевидны) причины, по которым для RISC-V специфицировано только «одностековое» ABI и «бережно сохранено всё необходимое для ROP и эксплуатации традиционных ошибок выхода за пределы буфера на стеке»
Ответ достаточно очевиден на мой взгляд - это не является такой проблемой, как вы пытаетесь представить. У вас профессиональная девиация, вы думаете, что проблема переполнения это такая супер важная вещь, но индустрия в целом смотрит на это несколько иначе. И переусложнять всю инфраструктуру, чтобы менеджить 2 стэка ради достаточно призрачных бенефитов никто особого смысла не видит.
Давайте я спрошу простую вещь - чем 2 стэка лучше решения, когда у нас весь код в исполняемом файле замаплен с аттрибутами rx, а стэк выделен как rw ?
В зависимости от вашего ответа я могу подробнее ответить на более частные вопросы.
... индустрия в целом смотрит на это несколько иначе...
Индустрия занимающаяся обеспечением безопасности, либо вынужденная ей заниматься, имеет мнение отличное от прочих «индустрий».
https://www.securitylab.ru/news/519772.php и т.д. и т.п.
Давайте я спрошу простую вещь - чем 2 стэка лучше решения, когда у нас весь код в исполняемом файле замаплен с аттрибутами rx, а стэк выделен как rw ?
Если стек адресов возврата отделен от стека используемого для передачи параметров и размещения локальных данных функции (автоматических переменных в терминах С), то ошибка приводящая к записи за пределы локального буфера не позволит переписать адрес возврата (если только не переписать всю память между стеками и т.п.). Аналогично нет возможности непосредственно подготовить в стека адресов возврата массив адресов для ROP.
При использовании ROP код в памяти не переписывается (может быть только для чтения). Инструкции с адресов стека не выполняются (NX не имеет значения). ALSR может быть не эффективен, если через "читающее переполнение" удаётся прочитать кадры стека до генерации ROP-инъекции и т.д. и т.п.
Но это не даёт гарантии, ибо (в общем случае) возможны более сложные многоэтапные атаки, начинающиеся с перезаписи указателей на стеке и/или других данных в других места. Тем не менее, разделение стеков существенно (в разы) затрудняет доведение атак до финала и снижает риски эксплуатации уязвимостей.
В зависимости от вашего ответа я могу подробнее ответить на более частные вопросы.
Давать мне какие-либо ответы и/или пояснения не надо.
Индустрия занимающаяся обеспечением безопасности, либо вынужденная ей заниматься, имеет мнение отличное от прочих «индустрий».Эта индустрия существенно меньше «прочих индустрий», поэтому ее потребности разработчики удовлетворяют не в первую очередь. Вполне обычная ситуация. Тем более, вы сами описали несколько способов обхода проблемы, а значит вам не критично, чтобы эти проблемы решала за вас система команд процессора.
Уж извините, но не пишите если не в теме.
Эта индустрия существенно меньше «прочих индустрий»
Относительно небольшой размер индустрии безопасности == Относительно небольшое количество пожарных.
поэтому ее потребности разработчики удовлетворяют не в первую очередь.
Снижение рисков эксплуатации уязвимостей являются потребностью потребителей/пользователей, а не "разработчиков" в индустрии ИБ (для ИБ как-раз наоборот, чем больше потенциальных дыр/угроз, тем больше бюджет).
...вы сами описали несколько способов обхода проблемы,
Не обхода проблемы, а потенциального/гипотетического обхода защиты при наличии других ошибок/недостатков в ПО и/или железе.
Если же под одним из "способов обхода проблемы" подразумеваете смену ABI, то это примерно равнозначно повторному портированию ПО. Соответственно, это должно быть сделано до начала широкого использования архитектуры, либо станет невозможным как в случае с x86.
а значит вам не критично, чтобы эти проблемы решала за вас система команд процессора.
Не "нам", а для безопасности данных/процессов/пользователей.
Не "не критично", а существенно снижает риски, но не даёт полной гарантии, ибо её нельзя дать из-за ненулевой вероятности реализации сложной атаки с участием других ошибок/уязвимостей/недостатков.
Не "решала за нас проблемы", а чтобы система команд не имела очевидных брешей в безопасности, которые в случае с RISC-V заботливо сохранены.
---
В целом похоже на ситуацию с прививкам. Озвучиваем "так небезопасно, нужна <прививка>", а в ответ весь набор аргументов антиваксеров.
Давать мне какие-либо ответы и/или пояснения не надо.
Непонятно, зачем тогда вы тут всё это пишите. Тем более спустя столько времени. Ну хорошо, раз вам ответов не надо, я тогда закончу свою мысль, начатую в прошлом посте, а дальше уже сами разбирайтесь.
Собственно, это то, что я ожидал от вас услышать:
Но это не даёт гарантии, ибо (в общем случае) возможны более сложные многоэтапные атаки, начинающиеся с перезаписи указателей на стеке и/или других данных в других места. Тем не менее, разделение стеков существенно (в разы) затрудняет доведение атак до финала и снижает риски эксплуатации уязвимостей
Т.е. разделение стэков усложняет возможность атаки, но не даёт гарантий всё равно. Но точно также работают современные схемы защиты с запретом на исполнение стэка, например. Т.е. они тоже существенно усложняют такого рода атаки. А т.к. они проще в реализации, их и используют, ибо зачем городить огород с разделением стэков, если принципиально это ситуацию не меняет.
И коли на то уж пошло, в Эльбрусе точно также нет полной гарантии от атаки переполнения стэка. Т.к. так или иначе любая машина может считывать данные из стэка данных, которые могут потом попасть в IP. Например, я могу нарисовать схему хоть и трудно исполнимой, но в принципе вполне реальной атаки с переполнением стэка для Эльбруса. Можете поупрожняться и попробовать придумать такую атаку сами.
Непонятно, зачем тогда вы тут всё это пишите.
Может показаться, что я специально провоцирую Вас выставлять напоказ некомпетентность и "умение" притягивать аргументы за уши (примерно как в вашем крайнем ответе).
Но на самом деле, я даю пояснение к своей позиции/тезисам и отвечаю на те вопросы, которые, как мне кажется, этого заслуживают.
а в участники RISC-V (видимо) вообще не считают это проблемой.
А должны? Это головная боль тех, кто делает конкретную реализацию микроархитектуры, а не авторов ISA.
У RISC-V как ISA нет значимых технических/технологических преимуществ при переходе в сегмент высокопроизводительных ЦПУ.
Она в целом не лучше и не хуже остальных RISC ISA. 64-разраядное расширение есть, векторные тоже. А учитывая что внутри даже x86 в некотором роде RISC то проблема становится совсем уж какой то надуманной.
первый же конкурент - компания Байкал Электроникс, которая имела нулевой опыт создания процессоров, но зато имела сложности с лицензиями, финансированием, управлением из-за проблем владельца, набила кучу шишек первого продукта, за несколько лет выдала чип, который конкурентен чипам от МЦСТ.
Но ведь Байкал не разрабатывал микроархитектуру, а просто купил готовые ядра. Так что сравнение некорректно.
И там, и там — процессор.
Если так рассуждать, то можно сразу купить готовый процессор. Результат тот же.
А если кто-то решил пойти более сложным путем, а на выходе получил примерно такой же результат — разве это проблема конкурентов?
Здесь уже вопрос целеполагания. Если цель просто любым путем получить процессор то, очевидно, самый короткий и оптимальный путь это купить готовое серийное изделие. Если цель в разработке технологии и получения компетенций в разработке процессоров, то нужно проектировать их самостоятельно, ядро уж точно нужно делать самим, а остальное, на первое время можно и покупать, если на все сразу не хватает ресурсов.
Если цель в разработке технологии и получения компетенций в разработке процессоров,Навыки не могут быть целью. Конечная цель — всегда какой-то продукт. Цель импортозамещения — получить продукты в ситуации, когда «самый короткий и оптимальный путь это купить готовое серийное изделие» не работает по политическим причинам.
ядро уж точно нужно делать самим, а остальное, на первое время можно и покупать, если на все сразу не хватает ресурсов.Так наоборот — именно ядро надо первое время покупать, пока на все сразу не хватает ресурсов
Я программирую на питоне, поэтому архитектура процессора и компилятор его сишного интерпретатора для меня очень далеки. Но узнать, есть ли разница в скорости исполнения какого-нибудь рандомного скрипта на питоне на эльбрусах, байкалах и тех же интелах похожих характеристик - вот это интересно. Есть ли такие таблички с результатами тестов?
Эльбрус 2С+ в 30 раз медленнее на 1 поток
Эльбрус 1С+ в 12,5 раз медленнее на 1 поток
Эльбрус 4С в 15,5 раз медленнее на 1 поток
Эльбрус 8С в 9 раз медленнее на 1 поток
Эльбрус 8СВ в 7,8 раз медленнее на 1 поток
Эльбрус 2С+ в 58 раз медленнее на всех потоках
Эльбрус 1С+ в 25 раз медленнее на всех потоках
Эльбрус 4С в 13,5 раз медленнее на всех потоках
Эльбрус 8С в 4,2 раза медленнее на всех потоках
Эльбрус 8СВ в 3,8 раза медленнее на всех потоках
Плюс на x86 иногда можно взять вместо cpython'а pypy и получить небольшой прирост скорости, а вот на Эльбрус его никто не портировал. Да, юз-кейс не очень распространенный, но тем не менее местами в production'е используется (соответственно разницу можно еще примерно на 10 умножать если брать pypy @ x86 и cpython на эльбрусе).
Pypy почти никогда взять не получается, ибо какие-то зависимости на нем работать не будут. Мне вот интересно можно ли cython использовать с Эльбрусом? И какой прирост будет?
Насчет прироста не очевидно, но пользовать в теории можно, так как cython работает через компиляцию в промежуточный код на C.
Pypy почти никогда взять не получается, ибо какие-то зависимости на нем работать не будут.
У меня опыт обратный, почти что ни имело смысл брать - все работало адекватно и местами давало нужное время чтобы сделать более правильное решение. Так что скорее зависит от области и конкретных задач.
Мне вот интересно можно ли cython использовать с Эльбрусом?
Cython же, если я все еще правильно помню, это чуть ли не путь по-умолчанию для создания C-extention'ов для питона и тот же SciPy на нем (а еще все биндинги к сишным библиотекам, которые народ делал до рассвета cffi)? Так что если я помню правильно то было бы странно видеть проблемы в этом месте и было бы еще страннее заявлять наличие работающего питона если cython не работает.
Тогда уж портировать HotSpot JVM и jython
Кроме того, надо помнить, что у CPython используется One True Single Global Lock на все мало-мальски чувствительные операции.
При этом как минимум два человека делали многопоточный Питон с раздельными "маленькими" блокировками. Но это портило производительность на малопоточных программах и их правки откатывали.
Учитывая же VLIW - блокировка конвейера на глобальном локе блокирует сразу все "мини-инструкции" всех "широких бандлов". В отличие от OoO, где команды "узкие" и даже среди них можно найти хотя бы некоторые, независящие от этого лока, которые можно пропустить "вперёд очереди".
И вообще интересно, как будет в случае Эльбруса смотреться спинлок-цикл, и его взаимодействие с такими же спинлок-циклами по тому же барьеру на соседних ядрах? Если ядро не способно просто само для себе вовремя загрузить значение из памяти, без помощи nop'ов от компилятора, тот как можно надеяться на эффективное разруливание конкуренции за атомарный барьер нескольких ядер/потоков?
Вообще, интересно даже стало, как там в целом у VLIWов с атомарными инструкциями...
а мне кажется достаточно одной статьи про эльбрус, большего не нужно,
учитывая распространенность и востребованность...
Я бы с удовольствием узнал, что ОоО ядро от Синтакор делает цикл
.L13:
lw a4,-4(a5)
ble a4,a3,.L17
sw a4,0(a5)
sw a3,-4(a5)
addi a5,a5,-4
bne a0,a5,.L13не хуже Эльбруса и Интела. Думаю у будущей надежды российской электроники есть хотя бы одно рабочее ядро чтобы проверить эту горе-сортировку :)
Отличная мысль. Если у Миландра есть ОоО ядро , то и их результат тоже было бы приятно увидеть :)
Все RISC/CISC архитектуры по сути своей одинаковы. Вопрос только в том, хватит ли технических компетенций у конкретного коллектива разработчиков, чтобы решить эту задачу.
мне понравилась эта ваша мысль т.к. я склонен считать, что не только выбор архитектуры имеет значение, но и прикрепленный к архитектуре человек :) Отсюда и желание поскорее увидеть результат других работников.
Это безусловно, но это общий принцип, работающий в любой области человеческой деятельности. Мы всё же обсуждаем здесь процессорную специфику. А поскорее пощупать результаты работы других коллективов конечно же хочется. Даёшь больше отечественных процессоров, хороших и разных!))
В качестве начальной точки отсчета могу предложить результат работы собственного варианта RISC-V. Обычный in-order , 1 или иногда 2 команды за такт. 9 ступеней конвейера. R32GC. 30 человеко дней работы коллектива из одного человека в течение новогодних и майских каникул в рамках расширения кругозора и собственной компетенции. Затраты - 0 рублей 0 копеек.
Результат работы цикла сортировки 5 тактов на цикл. Стандартный компилятор. -О2. Лучше чем у Эльбруса, если неправильно подбирать ему опции компиляции :) Временная диаграмма работы прилагается. Кто обгонит - тому проставляю чай.
С этим,я думаю, никто не спорит. Суть обсуждения в том, каким он должен быть.
Далее:
В России ограниченный ресурс для разработки микроархитектуры с динамическим распараллеливанием инструкций, Россия просто не потянет и никогда не сможет отладить такой процессор,
Это не так. Это вполне подъёмная задача.
или свой VLIW процессор принципиально в 5 раз медленне с непонятным для людей ассемблером и вечной ручной оптимизацией приложений, или ничего
Это ложная дихотомия. Как я уже сказал, нет никаких принципиальных проблем сделать нормальный ОоО проц.
прийдется разрабатывать свою микроархитектуру с динамическим распараллеливанием инструкций, что в свою очередь невозможно - см. пункт 2.
Это возможно и более того, уже делается.
Купить лицензию на ARM с уже готовой микроархитектурой с динамическим распараллеливанием инструкций (как у Apple), не хватит денег
Эта лицензия легко продаётся. У Байкала она есть, например.
Проблема в том, что МЦСТ закрыл все, что только можно закрыть, не раздает компиляторы и эмуляторы, не продает машины
Это уже большой отдельный разговор - методы ведения бизнеса от МЦСТ. Очевидно, что даже при отсутствии технических проблем, такой подход оставляет мало шансов для широкого распространения процессора Эльбрус.
Если это не измениться, то эльбрус умрет, так и не родившись
Он уже умер. Мои статьи никак на этот факт не влияют, а лишь объясняют - почему.
Время всё покажет.
МЦСТ пользовалось тем, что 20 лет они были де факто единственными, кто делал процы с прицелом на гражданский high-end рынок (а коллектив там пришёл с ИТМиВТ, т.е. это ещё несколько десятилетий опыта). 10 лет назад появился Байкал и первые же их процессоры уже составили конкуренцию. Сейчас появились Syntacore, Ядро, Cloudbear и вой пошёл на всю Россию - спасите, хулиганы рынка решают. Вот и вся история.
Не просто "хулиганы рынка лишают", а явные попытки дискредитировать идеи конкурентов на базе вырванных из контекста цитат (там товарищ Трушкин в телеграмме мини-опус в формате "ну вы понимаете" писал как раз недавно, про OpenPower и risc-v, такой что за это прям стыдно)
Ну они довыступались до того, что мне пришлось взяться за перо. Настолько их заявления не этичны и непрофессиональны.
А почему начиная с Itanium Poulson число инструкций увеличили с 6 до 12 Doubled issue width (from 6 to 12 instructions per cycle) ?
Для повышения перформанса, вестимо. Больше операций в такт - больше потенциальный перф
Начиная с Эльбруса 16С, делают точно тоже самое
Вроде там не меняли количество ALU
В среднем по статистике в коде все равно нет больше 6 инструкций между условными переходами. Это им что-то даст
Это в среднем, а на плавучих циклах это не так. Плюс переходы можно сливать под предикатом в теории
Хотя все равно при компиляции lcc -O4 -fast -march=elbrus-v6, я не вижу в ассеблере широких инструкций больше чем по 6
Ну так там 6 ALU, поэтому и нет больше
Мнение интересное, но есть пара фактических ошибок:
В России ограниченный ресурс для разработки микроархитектуры с динамическим распараллеливанием инструкций, Россия просто не потянет и никогда не сможет отладить такой процессор
Эльбрус на текущий момент чуть ли не более сложный, чем многие OoO процессоры. Там в общем свои проблемы возникают чтобы архитектура как-то масштабировалась, и это все решается не так чтоб просто. Посмотрите на принципиальную его схему. В общем нету там "в 100 раз проще". Увы. К тому же людей способных написать уникальный быстрый компилятор очень не факт что больше, чем тех кто способен разработать быстрый процессор.
то все равно, чтобы быть на хорошем уровне производительности, прийдется разрабатывать свою микроархитектуру с динамическим распараллеливанием инструкций, что в свою очередь невозможно - см. пункт 2. Купить лицензию на ARM с уже готовой микроархитектурой с динамическим распараллеливанием инструкций (как у Apple), не хватит денег, не позволит гордость, и это уже не будет своим процессором - противоречит пункту 1.
Посмотрите на Cloudbear с их OoO risc-v, посмотрите на то что в презентациях показывал Syntacore в 2018 году.
Чтобы в типичных юзерских задачах обогнать Эльбрус не нужна мегапроизводительность, достаточно иметь что-то уровня Cortex-A72 на той же частоте, а это очень достижимо (а проблемы в плавучке решались бы хорошо проработанным внешним акселератором, раз уж все равно руками оптимизировать, который, кстати, был бы как раз относительно простым).
Касательно же ARM и лицензирования - производительности Apple M1 у них конечно нет, но Neoverse N1/N2 лицензировать вполне по силам и по кошельку было бы. Собственно у Байкала следующие продукты будут на Cortex-A73 и позже на A75, они конечно помедленее, но если выйдут в срок то отставание по микроархитектуре от текущего bleeding edge сильно сократят. Впрочем посмотрите сравнение результатов Эльбруса с теми же A73 или A75 в имеющихся известных тестах. Там опять же не так все плохо.
и никаких перепалок не будет.
Перепалки идут в первую очередь от неверного позиционирования. Процессор для военных? Да пожалуйста, никого не волнует ни закрытость, ни скорость (это проблемы заказчика). А вот как только он пошел в "да мы сейчас все импортозаместим на него" так начинаются проблемы, потому что он в пользовательских задачах уступает телефону 5-и летней давности.
Имея IP ядра от Cloudbear, этого не получиться.
Не менее чем с Эльбрусами. Собственно шансов у Syntacore и Cloudbear чуть больше на практике. По сути они за пару лет сделали то, на что МЦСТ потратили 30 лет, это, кажется, о чем-то да говорит.
Не совсем понимаю как Гипотеза Коллатца относится к развитию решений, если честно.
А про продукт - так они и развивают собственно говоря. Просто как продукты стали достаточно взрослые и о них начали говорить, то другая сторона решила что ей надо начать защищать свои контракты (интересно, с чего бы это, если у них такие сильные позиции?)
Если сами Syntacore и Cloudbear уверенны в своем продукте, то пусть берут кредит в банке и развиваются.Они собственно так и делают. Но как только они об этом объявили, на них пошла волна «да ничего они не сделают никогда» и «да ваш риск5 — неспособное говно».
Но как только они об этом объявили, на них пошла волна «да ничего они не сделают никогда» и «да ваш риск5 — неспособное говно».
Сейчас дно упорно пробивают новой риторикой: "да это все для инклюзивности, ну вы понели, да?" (последний на текущий момент пост в официальном телеграмм-канале МЦСТ)
Не говорит. На том же самом 32нм техпроцессе Core i7 EE достигали 4 ГГц (не-HEDT Core i7 достигали 3.9 ГГц, Xeon'ы - 4.0 если E3, 3.9 если E5)
Я же для этого специально привёл табличку в самой первой статье, где процы VLIW/не VLIW от одних производителей и на одних нанометрах. И там видно, насколько vliw'ы проигрывают. Та же МЦСТшная серия R (Спарковских процессоров) частоту имеет бОльшую, хотя это гадкий утёнок всегда был, пилили вполноги, а основные силы шли в Эльбрус. Там есть достаточно фундаментальные проблемы, почему это так, но без глубоких специальных знаний это непросто воспринять. Поэтому мне кажется такая табличка по факту намного показательнее для не экспертов в области
Не то что бы я был сторонником или фанатом Эльбрусов и VLIW, скорее наоборот, мне это привели как аргументы в другом месте и я задумался об обоснованности конкретно этого пункта статьи.
что у VLIW 2,66 против 3,1 на всех ядрах у аналогичного по ядрам x86 (3.8 насколько я понимаю в разгоне на одно ядро)
Тут важный момент в том, что ядро x86 разгоняется до 3.8, а на 3.1 для всех ядер чип работает из-за ограничений по пауэру. В то же время для Итаниума 2.66 это максимум, который выжали инженеры, т.е. там не в пауэр упирались.
Ведь если VLIW перевести допустим на 7 нм то и частота тоже повысится с этих 2,66 на 32 нм
Частота сейчас просто так уже не повышается с переходом на новый техпроцесс. Это видно на примере стагнации роста частоты на тех же x86.
Отставание конкретно Эльбруса тут вполне можно объяснить нехваткой ресурсов его разработчиков
Это универсальная отмазка, которой можно объяснить любые недостатки.
Можно перейти к обсуждению чуть более технических моментов, объясняющих, почему на Эльбрусе частота принципиально ниже. Например, там 8 стадий конвейера (и это нельзя поменять без полной переделки архитектуры). А в современных ОоО процессорах порядка 20. Почему во втором случае частота получается в среднем выше, надеюсь, понятно.
8 стадий конвейера - очередной миф, почему-то активно всеми распространяемый. Для целочисленной операции 13 стадий и вряд ли найдётся операция с меньшим числом. Вот официальный источник: http://mcst.ru/files/60f6d2/1adece/616a5e/eb0728/tvgi.431281.028re.pdf
Да, тут с замечанием согласен. Просто в куче презентаций (от того же Бабаяна, например) и даже учебных материалах говорится про 8-ми стадийный конвейер, поэтому мне эта цифра в память запала. Но сейчас пригляделся - 8-тактов это до E0 , а дальше идут стадии для своих пайплайнов.
Но сути проблемы это не меняет. Т.е. увеличивать количество стадий нельзя просто так. Проблема кучи портов для передачи результатов через байпассы тоже остаётся (и насколько я понимаю, она ключевая для роста тактовой частоты)
Тут важный момент в том, что ядро x86 разгоняется до 3.8, а на 3.1 для всех ядер чип работает из-за ограничений по пауэру. В то же время для Итаниума 2.66 это максимум, который выжали инженеры, т.е. там не в пауэр упирались.
Вот это момент, который явно нуждается в гораздо более подробном раскрытии. Так у Itanium энергопотребление даже больше чему у Xeon (170 против 150) и невольно возникает вопрос — может он тоже просто по энергопотреблению зашкалил?
Я не специалист по проектированию процессоров, но краткая логика из статьи про «У Эльбрус 1,5ГГц на 28 нм и следовательно больше 2,5 — 3 быть не может» не выглядит убедительной для стороннего наблюдателя. Если у Эльбрусов теоретический предел в два раза выше результата на 32 нм, то почему у VLIW вообще теоретический предел не может быть выше в два раза результата Itanium на 32 нм?
И особенно с учетом того что 5ГГц на x86 — это результат для одного ядра, а при загрузке всех ядер получаются цифры близкие к 3-3,5.
Я предполагаю, что скорее всего вы что-то иное имели в виду и там какие-то технические обоснования, но со стороны для неподготовленного читателя выглядит именно так.
Я попробовал примерно обрисовать проблемы в соседней ветке. Не совсем точно но все таки (повторю оттуда - точное объяснение это около трети курса цифровой схемотехники и еще немного знаний из смежных областей, впрочем можете попробовать приобрести какую-то часть самостоятельно - для этого хватит FPGA и желания поедалть на нем всякого разного, например попроходить курсы по дизайну микросхем, благо их в открытом доступе полно)
К тому же про 3-3.5 ГГц на все ядра вы не совсем правы (я тоже пояснил почему не стоит смотреть на базовую частоту у современных процессоров). Хотя тут повторюсь - вот у меня Ryzen 3900X в десктопе, у него базовая 3.8, буст 4.6. На все ядра он работает на 4.2 и на практике до базовой никогда не опускается. Без какого либо разгона и модификаций (если заморочится можно поднять частоту на все ядра еще чуть-чуть). У интелов современных также - у десктопных i9-10900k официальный all-core boost - 4.9 ГГц, при Turbo в 5.3, а базовая при этом 3.7 (такие параметры если мат плата умеет в thermal velocity boost и вся система имеет хорошую систему охлаждения)
Параметр базовой частоты в первую очередь важен для систем лимитированных чем-либо внешним (например системой охлаждения, притом как процессора, так и системы питания на мат плате или просто зарезанными лимитами на общее энергопотребление системы). И второй момент тут юридический - падение частоты под нагрузкой ниже базовой являются гарантийным случаем, в то время как Turbo частота в 5.3 ГГц жарким летом в плохопроветриваемом помещении на штатном кулере - не гарантируется.
Вот это момент, который явно нуждается в гораздо более подробном раскрытии
Ну да. Я много раз про это написал, что тут надо углубляться в технику. Причём хорошо бы это уже сделал человек, непосредственно занимавшийся вытягиванием частоты у VLIW. Всё же мой стек компетенций лежит выше, я не настолько хорошо понимаю эту проблему, чтобы подробно объяснять её другим.
но краткая логика из статьи про «У Эльбрус 1,5ГГц на 28 нм и следовательно больше 2,5 — 3 быть не может»
Всё же в статье нет такой логики. В статье логика в том, что мы сравниваем аналогичные VLIW и RISC/CISC системы и видим, что VLIW по частоте уступает. На базе этого (и со сссылкой на нераскрытые технические причины этого) делается утверждение, что по частотам VLIW проигрывает.
Тем не менее разрыв уже гораздо меньше чем у Эльбрус с его 1.5.
Тут тоже есть своя цена - вы не забывайте о том что TDP Itanium'а практически вдвое больше (170 Вт против ~90-100 у Эльбруса). Это как минимум. Во вторых тут опыт и умение инженеров Intel, которые архитектуру вылизывали максимально.
если вообще не остановился, у тех же Epyc на 7 нм максимальная частота те же 4 ГГц, а базовая в районе 2-3
Не очень понятно почему Вы взяли не более близкий по параметрам Ryzen 5950X (с его теоретической частотой в 4.9 и практическими 5.05-5.1 на 1 ядро без разгона со стороны пользователя), а Epyc? Ну или почему не посмотрели на тот же Xeon W-1390P (5.3 GHz - альтернативно можно взять Core i9-10900k, если конечно хочется) как доказательство того, что частота меняется не сильно?
По поводу частоты важным является ответ на вопрос "что же ее ограничивает?" - к сожалению тут полноценный ответ это примерно треть курса цифровой схемотехники с хорошим шансом влезть в соседствующие разделы физики (физики полупроводников, например, но не только). Очень упрощенно - ограничивающими факторами являются и тепловыделение и дизайн схем. Не любая схема у которой есть пространство по TDP сможет разогнаться до больших частот (простым языком можно сослаться на английскую вики).
И в связи с этим начинаются приколы (очень упрощенно) - время выполнения инструкции будет ограничено самым медленным куском команды (в то время как OoO процессор теоретически может загрузить), чем более параллельная схема тем больше сложности идет в шедулер, тем меньше получится частота (1 цикл работы для всей схемы будет занимать больше времени), длинное слово повышает тербования к подсистеме кэша и памяти (чем менее плотный код будет, тем важнее будет подсистема памяти), большой кэш тоже сложнее масштабировать по частоте (притом первого уровня сложнее). И чем больше проблем из списка ты будешь решать тем ближе придешь к OoO RISC процессору.
В то же время для x86 у тебя ограничение по питанию (кстати не очень верно брать просто базовую частоту, у каждого CPU своя формула в зависимости от типов нагрузки и типа процессора - некоторые десктопные могут держать буст частоту на всех ядрах при достаточном охлаждении, или могут сбрасывать частоты только в каких-то определенных задачах, например SIMD нагрузка, но обычно тоже не до базовой частоты).
Не очень понятно почему Вы взяли не более близкий по параметрам Ryzen 5950X (с его теоретической частотой в 4.9 и практическими 5.05-5.1 на 1 ядро без разгона со стороны пользователя), а Epyc? Ну или почему не посмотрели на тот же Xeon W-1390P (5.3 GHz — альтернативно можно взять Core i9-10900k, если конечно хочется) как доказательство того, что частота меняется не сильно?
Сравнивать одноядерную загрузку с многоядерной тоже не совсем корректно. Со стороны можно задаться вопросом — если Эльбрус ограничен архитектурой в 3ГГц (цифра из статьи) а x86 ограничен уже тепловыделением на многоядерную загрузку в районе 3,5 то так ли велика разница?
Само собой это не касается других проблем VLIW, это уже отдельный разговор.
а x86 ограничен уже тепловыделением на многоядерную загрузку в районе 3,5 то так ли велика разница?
Вы делаете мне грустно тем, что проигнорировали важные вопросы и примерно 3/4 комментария, в том числе на этом фокусирующихся.
Перечитайте еще раз, пожалуйста, что я написал. Более того - я совсем не понимаю откуда вы берете упорно 3.5 ГГц, когда для Intel'а есть понятия Single core boost, All Core boost, AVX2 Boost, AVX512 Boost и все это даст разный набор множителей в разных ситуациях, притом ни в одной из них он не опустится до base.
Высокие тактовые частоты достигаются более детальным уровнем проектирования микросхемы (full custom design). Никакие архитектуры здесь вообще непричем. На примере процессоров ARM нетрудно заметить что на тех же 16nm типичные частоты у них ~2Ггц, на 7-5нм уже подобрались к 3Ггц. И эльбрус и доступные на рынке ARM процессоры делаются из стандартных ячеек/блоков фабрики, а так высоких частот не достичь.
Никакие архитектуры здесь вообще непричем
Кажется, тут нужно предоставить доказательство этому утверждению.
Странно что здесь никто не вспомнил новые процессоры от IBM с базовой частотой 5ГГц
ARM делаются под совершенно другое энергопотребление, раз так в 10 ниже
Они это достигают размером самого ядра, которое даже на крошечном по десктопным меркам кристалле 10% занимает если не меньше. В армах нет сложных технологий отключения кэшей/конвееров как в интелах, и этим они с эльбрусом одинаковые, у них есть рабочие частоты и рабочее напряжение 0.8-1.2V, которое даже на старых 45нм интелах позволяло работать на 1,5-3,0Ггц а на армах и эльбрусах только 800-1500Мгц на более тонких техпроцессах. Мотивация впрочем у них разная, у эльбрусов маленькие бюджеты и сроки, можно сказать чисто чтоб люди на работу ходили, студентов в средах проектирования работать учили, и раз в год-два чем то отчитывались сдавали "изделие" которое положат на полку и дадут задание на новое. У армов же рыночек порешал что дешевые массовые чипы за 10-20 долларов предпочтительнее более проработанных за 40-60 долларов. Вот и всё.
никто не вспомнил новые процессоры от IBM с базовой частотой 5ГГц
Еще в бородатые времена читал на Tom's Hardware (а может кстати и на хабре, не помню уже) что наращивание частоты упирается в скорость переключения транзисторов, 5Ггц для них предел и IBM работает над созданием новых которые позволят наращивать дальше вплоть до 10Ггц.
Но в статье пишут про 7nm Samsung так что врядли это та самая революция которую нам обещали. Ну и конечно же 960Мб L4 и 256Мб L3 впечатляет.
Вот и всё.
Когда утверждаете что-то, расходящееся с общепринятым пониманием, неплохо бы приводить доказательства собственным словам. Впрочем вы еще про прошлый пост не ответили про независимость частот от архитектур мне и соседнему комментатору про готовые блоки.
наращивание частоты упирается в скорость переключения транзисторов, 5Ггц для них предел
Для силиконовых транзисторов скорость переключения составляет десятки, а то и за сотню Гигагерц (в зависимости от). А всякие SiGe вообще дают ещё больше, но это будем считать экзотика. Наращивание частоты упирается не только в скорость переключения, а сложность логики и как следствие количество этих самых переключений, которые надо надёжно осуществить за такт. И с этим как раз у VLIW проблема - есть критические цепи, которые не позволяют увеличивать частоту
Я же постоянно привожу простой вопрос "на подумать" - почему Мцстшный спарк с первого раза на 28нм 2ГГц, а Эльбрус на тех же 28нм 1.5ГГц, и это со второго раза (с первого 1.2 ГГц) ? Вот именно поэтому
у VLIW проблема - есть критические цепи, которые не позволяют увеличивать частоту
АМД видимо не знали про критические цепи, поэтому у их видеокарт на VLIW частоты были раза этак в 2-3 выше чем у конкурента. И это же не значит что у нвидиа архитектура не позволяла сделать частоты выше, им теплопакет не позволял и жирный размер субядер (у амд под 500-1k на кристалл влазило, у нвидии сотня, максимум две). Пример АМД показателен еще и тем, что первые поколения этой архитектуры (R2000/3000) не давали впечатляющих результатов мягко говоря, но амд продолжала работать дорабатывать архитектуру, кодогенератор, пока в итоге не оказалось что middle-end радеон на уровне или даже обгоняет топ нвидии, и разрыв этот сохранялся вплоть до перехода на GCN. От влив ушли потому что для GPGPU старые ядра не подходили, создавать новый VLIW писать под него и добавлять поддержку в свободное ПО это конечно весело и увлекательно, но амд живет в условиях рынка который диктует свои правила.
Я же постоянно привожу простой вопрос "на подумать" - почему Мцстшный спарк с первого раза на 28нм 2ГГц,
Ну он во первых относится к поколению Э-8СВ на что как бы намекает контроллер памяти DDR4-2400 и дата выхода 2019г. Ну а в пятых-десятых это гораздо более простой и дохленький процессор уровня какого нибудь Cortex-A53 в китайфонах если не проще, при этом 1600Мгц версия 25Вт, а 2Ггц 35Вт вот и весь секрет. Кстати о кортексах - а какие критические цепи байкалу помешали сделать нормальные частоты "не как у эльбруса"? Сослаться на экономию энергии не выйдет ибо 8ядер и 10Гбит эзернет явно не для планшетов решение. Про обещаный серверный 2Ггц RISC-V на 16нм через пять лет вообще промолчу.
АМД видимо не знали про критические цепи, поэтому у их видеокарт на VLIW частоты были раза этак в 2-3 выше чем у конкурента.Вы же понимаете, что у видеокарты гораздо более предсказуемый поток инструкций, и там вероятность сброса длинного конвейера радикально меньше, чем у процессора общего назначения? В видеокарте-VLIW наращивать глубину конвейера действительно ничего не мешает.
Про обещаный серверный 2Ггц RISC-V на 16нм через пять лет вообще промолчу.А в чем проблема? Такие штуки наверное пять или шесть стартапов по всему миру собираются сделать к этому времени.
Вот буквально вчера пришли новости от том, что европейский университетский серверный проект получил первые сэмплы RISC-V чипов на 1 ГГц на 28 нм процессе.
Вы же понимаете, что у видеокарты гораздо более предсказуемый поток инструкций, и там вероятность сброса длинного конвейера радикально меньше, чем у процессора общего назначения? В видеокарте-VLIW наращивать глубину конвейера действительно ничего не мешает.
Там человек фактически неправ даже (есть разница в 2 раза, но в пользу RISC чипа от nVidia, а не как он пытается выставить). Так что и дальше аргументы у него все такого же уровня, к сожалению.
АМД видимо не знали про критические цепи, поэтому у их видеокарт на VLIW частоты были раза этак в 2-3 выше чем у конкурента.
Вы доказательство то приводите, а то я открыл табличку с характеристиками карт и вижу что R2900 XTX - по Core Clock'ам обгоняли на 10%, а по Shader Clock'у отставали в 2 с небольшим раза от GeForce 8800 Ultra (напомню что VLIWовость в первую очередь относилась к унифицированным шейдерным ядрам, а не к TMU и прочей обвязке, а тут у nVidia в те времена частоты были 1.5 ГГц, в то время как у AMD частота была 743 МГц), имея при этом более современный техпроцесс (80нм TSMC против 90нм TSMC у nVidia).
Отлистываю потом в последнее поколение - fermi у нвидии (GTX 580) 772 МГц частоту ядра имел (по прежнему для шейдерных процессоров нужно было умножать на 2, то есть 1544 МГц в итоге), у AMD их Terascale - 880 МГц (6970). Как-то, извининте, на 2-3 раза совсем не тянет. Так что, извольте, не вводить людей в заблуждение. В последнем поколении техпроцесс был одинаковый - 40 нм и там и там.
Пример АМД показателен еще и тем, что первые поколения этой архитектуры (R2000/3000) не давали впечатляющих результатов мягко говоря, но амд продолжала работать дорабатывать архитектуру, кодогенератор, пока в итоге не оказалось что middle-end радеон на уровне или даже обгоняет топ нвидии, и разрыв этот сохранялся вплоть до перехода на GCN
Тут Вы фактически тоже не правы. AMDшный 6970 который был одночиповым топом, отставал почти во всех играх где была высокая шейдерная нагрузка от GTX 580 (не сильно, процентов на 5, но тем не менее).
Почитайте тесты тех (к сожалению на ixbt графики на флеше, но выводы те же что у anandtech) времен. Его плюс был цена - которая была между GTX 570 и GTX 580, но при этом карта позиционировалась как топ, а на топ она недотягивала (не забываем что в моде были еще и двухчиповые топы в те времена, но на них можно не смотреть в контексте разговора про частоты)
Про Compute вы тоже не совсем правы. В OpenCL средние карты от AMD обгоняли топы nVidia, это как раз одна из причин почему nVidia поработала позже над Kepler и Maxwell именно в разрезе Compute производительности. Но вот реализовать пиковые 2.7 ТФлопс на амдшках было крайне сложно и в реальном мире получалось как попало все (были тесты как по ссылке где AMD рвали нвидию в клочья и где производительность была близка к теоретически достижимой, но в ряде тестов эффективность архитектуры заметно падала и они начинали резко отставать от нвидии).
Давайте Вы все таки возьмете за правило давать доказательства своих слов, ладно? А то пока что вы тотально ошибаетесь в каждом посте за последние несколько дней.
что у нвидиа архитектура не позволяла сделать частоты выше
Опять же - кажется это Ваша задача доказать что это так. Пока у всех Tesla/Fermi частоты были порядка 600-800 МГц (удвоенные для шейдерных процессоров соответственно) и даже разгон не позволял прям принципиально поменять картину: игнорируя TDP стабильная работа была возможна на 850-860 МГц при хорошем охлаждении и без повышения напряжения на чипе. В свете этого - мне кажется нужно доказательство что архитектура позволяла больше.
От влив ушли потому что для GPGPU старые ядра не подходили
От VLIW ушли потому что на бумаге он был крут, и если разработчик действительно заморочился и писал на AMD IL то получался хороший результат (по сути ручная оптимизация кода так как ближе к железу чем AMD IL не было возможности опуститься). Но людям хотелось портируемости решений, а значит языки более высокого уровня, а вот код просто скомпилированный выполнялся почему-то не очень эффективно, особенно если там было много ветвлений (а это как раз то время когда начался активный переход на DX 10 и 11, с более сложными шейдерами, в том числе и появление вычислительных шейдеров в DirectX сказалось на развитии карт). То есть причины те же что автор озвучивает в статье против General Purpose CPU для VLIWов - без ручной оптимизации получается фигня какая-то.
Высокие тактовые частоты достигаются более детальным уровнем проектирования микросхемы (full custom design). Никакие архитектуры здесь вообще непричем.
Высокие тактовые частоты делаются не кастомным дизайном, а более длинным конвейером, который вполне себе имеет отношение к микроархитектуре и к тому, что загрузить длинный конвейер командами в RISC довольно просто, а во VLIW гораздо сложнее. Именно поэтому делать очень длинные конвейеры во VLIW бессмысленно, и поэтому же не получается поднять тактовую частоту.
И эльбрус делаются из стандартных ячеек/блоков фабрикипогодите, так они что же, покупают у фабрики RTL-код своих ядер? Вам самому не смешно такое писать?
Легенды и мифы процессора Эльбрус в примерах