Комментарии 86
Интересно, здесь только я вижу, что система на процессоре интел раз в 30 быстрее?
По другим тестам тоже некоторые результаты вот никак не соответствуют сделанным в статье выводам…
Действительно, тут разница в 30 раз – но разных «по набивке» процессоров – разное количество ядер, разная частота. Для корректного сравнения возможностей мы приводили к показателю Transactions-per-second в перерасчёте на 1 ядро частотой 1 ГГц.
Добавьте тогда, сколько стоит 1 ядро частотой 1 ГГц эльбруса и интела? По производительности уже все понятно, спасибо.
поскольку со стороны противника тоже автоматы заряжания
Нет у противников автоматов заряжания. У противников +1 член экипажа и заряжание происходит вручную.
Abrams M1 — заряжающий
Challenger 2 — заряжающий
Leopard 2 — заряжающий
Ну и с «другой» стороны:
T-72 — автомат заряжания
T-80 — автомат заряжания
T-90 — автомат заряжания
нет автомата заряжания — так есть противотанковый комплекс в засаде.
а оно вот оно как))
«А там точно нет закладок?» — чтобы точно ответить на этот вопрос про любую железку иностранного происхождения, рано или поздно надо сделать её самомуНу сделали, и какой сейчас точный ответ?
В ПЛИС запихнуть закладку намного сложнее, почти нереально, а выявить её легче. К тому же производитель ПЛИС знать не знает, для чего конкретно будет использована произведённая им партия — эти чипы слишком универсальны, на них можно строить всё — от процессора до майнера крипты.
Покупаем ПЛИС за рубежом, а прошивку и разрабатываем, и прошиваем уже в собственной стране, где всё это можно проконтролировать.
это делать процессоры на ПЛИС
Только процессоры будут очень медленные -- мегагерц 500.
Хотя Вы правы — вероятно за этим будущее. На Интелах с Эльбрусами отрисовывать ПЛИС, а остальное — микроустройства узкого назначения.
Не вижу причин приводить тесты к "1 ядро 1 ГГц", пока Эльбрус не достигает тех же частот, что Интел, чтобы не получить смягчающий фактор в сторону Эльбруса величиной до 5. После этого интерпретация тестов как "медленнее в 1.6 раза" превращается в замеренные "медленнее в 10-30 раз" и всё встает на место. Работать будет, но половину программистов придется переучивать, чтобы не городили слои абстракций высотой с Вавилонскую башню (и это будет хорошо, но когда ещё это будет...).
В большинстве современных бизнес-систем максимальная производительность процессора не является лимитирующим фактором. В инфраструктурах, использующих виртуализацию, например, применяют коэффициенты, определяющие, условно говоря, между сколькими разными приложениями будет делиться одно процессорное ядро. И вот именно для подобных систем подход "1 ядро 1 ГГц" вполне оправдан.
Или другой пример. Все задачи одного небольшого офиса сейчас вполне может обслуживать один сервер средней мощности. Но это не отказоустойчиво, поэтому серверов ставим два или, лучше, три, чтобы кворум соблюдался. И в таком разрезе не важно, какие серверы мы поставим - просто интелы будут загружены в среднем на 10-20% общей мощности, а Эльбрусы - на 50-70%.
В небольшом офисе три сервера никто ставить не будет — тупо бюджета не хватит. Так что сервер будет один, Интел, загруженный на 60%, а на Эльбрусе всё будет тормозить втрое против Интела, и понадобится три сервера, чтобы завести эту самую нагрузку.
Кстати об интелах — VMware на эльбрусе работает?
И в таком разрезе не важно, какие серверы мы поставим — просто интелы будут загружены в среднем на 10-20% общей мощности, а Эльбрусы — на 50-70%.
И насколько будет дороже решение на Ээльбрусах?
С одной стороны вы приводите пиковые ФЛОПсы как показатель, с другой стороны у вас производительность "не лимитирующий фактор". Вы уж определитесь.
Попытки замазать провал производительности Эльбрусов пересчетами равных частот заранее обречены на провал. Эльбрус как и его старший брат Итаниум никогда не достигнет высоких частот независимо от техпроцесса из за немасштабируемой по частоте архитектуре. Невозможно синхронизировать огромные RF на высоких частотах. Нет. Никак. Совсем.
В чем смысл пересчёта производительности на 1 ядро на частоте 1ГГц? Похоже на попытку хоть как-то подмогнуть Эльбрусу, но даже это не помогло.
Для того чтобы оценить разницу в производительности архитектур с разными подходами без учета частоты/нм?
Потешить себя. Но по факту требуется максимальная производительность на объем в стойке за минимальные деньги.
Какой толк от пересчета, если в итоге потребуется 10 серверов ставить, а не 1.
Предположим, чисто гипотетически, запретят поставлять в РФ процессоры (оборудование) Intel и AMD. Все грязно выругаются и переедут в заграничные ЦОДы. Все кроме гос.органов и АСУ — им деваться некуда. И тогда выбор будет между не работающими системами или системами с 10 серверами. Выбор по-моему очевиден.
Да! Нам, бизнесу.
Да на случай чего мы уйдем за бугор и с нами нужно считаться иначе уйдем быстрее. Неожидано да?
органы на бу интелах поживут за 3 копейки
А если не криворукие уроды пишущие кривой код то core2duo коих мильярд на бу будет достаточно для обычных pc, неожиданно да?
Основное что не обеспечивают эльбрусы это обеспечение дешовых, но мощных вычислительных мощностей.
Не работающие системы, это вопрос изоляции этих приложений от мира.
Вот вам пример «нового» и свежего железа за ~100к (1.3k $) 6ое поколение интелов! И это свежак, вам придется еще пучек пересогласований пройти т.к. в проекте будет что-ндь на 3570.
И практически все АСУ на этом — где-то больше, где-то меньше.
2. Хотелось бы понять требования основные
Корпус+процессор+мелочевка в вашей сборке стоят 20 000р т.е. 35 000р с мамкой где-то
Единственное предраться можно к мамке, аля требований com портов и кол-ва USB
Но скажем эти требования добиваются при использовании переходников
Я вот никак и не прикаких не вижу стоимости в 100т.р кроме как заточить под откат
В общем, что хотел донести — Эльбрус, это нишевый продукт, для АСУ и прочих гос-оборон-заказов и не надо пытаться его проецировать на какой-нибудь high load. Не, ну серьезно, есть камазы, а есть болиды F1, разные конструкции, разное назначение, разные заводы.
АСУ ТП это пример систем где правило
максимальная производительность на объем в стойке за минимальные деньги.
не работает.
АСУ ТП очень консервативно, там нафиг не нужны мощности, но нужна надежность т.к. срок эксплуатации некоторых систем составляет 30 лет. И да, есть объекты на которых крутится ПО если не 90, но начала нулевых — и всех все устраивает.
Сертификация и прочие штуки тоже жрут деньги. Вы не можете придти и сказать вот новый i7, он лучше i3-5ого поколения. Потому что первый же вопрос будет — а вы его протестировали на ЭМС, сейсмику, климатику? А ПО? Совместимо или мамой кленетесь? И это совершенно нормальные вопросы когда вы запускаете системы которые должны работать автономно, долго и отказ которых может привести к техногенной катастрофе или наоборот спасти человеческие жизни. В общем это вам не Хоум Ассистант на RPi поднять.
1. АСУ это какой % рынка?% от чего? от продаж? от оборота? от количества? В любом случае рынок достаточный чтобы в него тяжело было влезть — циска вот пыжится уже который год, а результат примерно как 5 лет назад.
Никаких вам 10к лет нет!
Да сертификация этого оборудования увеличивает его цену с 35 тысяч до 100т, и мы не поймем в чем суть такого удорожания кроме как попытка нажиться
Так же мы, общественность, охреневаем когда сравнивают эльбрус с Intel заявляя что в каких-то синтетических тестах эльбрус сильно быстрее интел. Потом оказывается что это если бы интел был 1герцовый о прочая ересь. Это сплошная спекуляция!
весь маркетинг эльбруса в корне неверный!
Это основная мысль которую хотел донести.
вам, общественности, никто эльбрусы не предлагает покупать вместо интелов
не говоря уже о том, что так-то вы многовато на себя берёте, говоря за общественность
Был разработан эльбрус- он оказывается существенно медленнее Intel.
Как пример Apple- она разработала M1 и вполне спокойно его сравнивает с intel без прохладных историй и сравнений на 1ггц.
И я абсолютно уверен, что если в параметры сравнения добавить ещё цену- то выяснится что Эльбрусы абсолютно неконкурентоспособны.
и при чём здесь apple? вы в этой статье где-то увидели МЦСТ, хвастающуюся достижениями? человеку попал в руки комп, он его потестировал и результатами поделился
Адекватнее пересчитывать производительность на Вт, если прямо хочется эффективность архитектур сравнить.
«частота это часть микроархитектуры» — тут путанница в терминологии. Мироахитектура Intel Xeon 6230 и, например, микроархитектура Intel Xeon E5-2680 — это разные микроархитектуры. Хотя и то и другое — микроархитектура CISC (или RISC — кому как больше нравится:)
Учитывая, что Эльбрусы печатаются по техпроцессу 28нм — им есть куда расти (Эппл уже скупает на корню процесс 2нм). Вместе с миниатюризацией вырастет и частота.
Речь именно о микроархитектуре. Она очень даже влияет на частотные пределы процессора. Техпроцесс тоже и не обязательно его толщина, т.к. их тоже под разные задачи делают. Интелы вон на своем древнем техпроцессе спокойно гоняют 5ГГц+, а амд на топовом техпроцессе не удается это до сих пор. Тоже самое было во времена пентиумов 4 и атлонов xp.
А если серьезно — где то в интернете встречал информацию, эльбрус выдал бОльшую производительность в расчете на ватт (по сравнению с интелами).
>>Производительность на Вт интересна, по большому счету, только майнерам.
Враньё или некомпетентость.
Разработчики все никак не могут понять, что VLIW не подходит для процессоров общего назначения
Нет чтоб послушать экспертов из интернета и просто взять и зделоть Ryzen X Black Edition от которого любой код будет ссаться AVXами сам по себе, без программистов.
Тесты которые не дошли до конца на Intel платформе и заявления про нестабильность Linux дистрибутивов для x86 вымораживает еще больше. И как весь мир на них живет…
На основании этих двух фактов, я не доверяю этому тестированию абсолютно, хотя Эльбрусы считаю несомненным достижением и вцелом за попытку его потестировать конечно спасибо.
Идея оценки конкретных приложений в этом смысле гораздо интереснее. Правда pgbench это тоже, скорее, синтетический тест.
Абсолютное большинство представленных на рынке процессоров, включая процессоры наиболее распространённых семейств х86-64 и ARM, используют архитектуру RISC
считается, что х86-64 использует архитектуру CISC - Complex Instruction Set Computer
хотя, конечно, бытует мнение, что благодаря заимствованию идеи и подходов в современных реалиях разница RISC и CISC размыта практически до состояния её отсутствия
Легально можно запускать всё, что позволяет лицензия. У перечисленного в статье софта с этим всё нормально.
В общем случае — запускать можно всё, что было легально введено в гражданский оборот. А вот ввести ЭльбрусОС легально в гражданский оборот как раз лицензия не позволяет. Ибо действует принцип «не можете предоставить сорсы — не имеете права распространять — а если нет права распространять, то и копию нельзя легально ввести в гражданский оборот». А кое-какие сорсы предоставить не могут, хотя и обязаны по лицензии.
Так что не всё, что бесплатно — не является интеллектуальной собственностью…
По словам разработчиков, модификации подвергались только ассемблерные вставки, т.к. они, очевидно, процессорно-зависимые.
Более сложный вариант объяснения — т.к. распространяют модифицированное ядро линукса — должны именно сами дать сорсы этого ядра вместе с модификациями, без отсылок на то, что они (за исключением маааленькой штучки, которую мы вам не дадим) есть где-то на kernel.org. Не делают так — значит, нарушают лицензию, значит, теряют право на распространение, значит, переданная кому-то копия линукса лицом, не имевшим право на её распространение — не вводилась законно в гражданский оборот, то есть контрафактная.
Видите ли, лицензия ядра Линукса специально написана так, чтобы не давать делать на его базе закрытые вещи, даже в небольшой части. Не можете выполнить условия лицензии (а насколько я понимаю, разработчик ЭльбрусОС не не хочет, а именно не может — из-за закрытости нативных инструкций процессора Эльбрус) — пишите своё ядро, кто не даёт?..
И обращаю внимание — речь не идёт об абстрактной «ЭльбрусОС», речь идёт от конкретном экземпляре ЭльбрусОС. Легальность разных экземпляров будет разной.
Всё, что находится «внутри» организации-разработчика — абсолютно легально, он имеет право делать что угодно у себя.
Проблема возникает только в случае, если он передаёт копию ЭльбрусОС какому-то другому лицу.
Так что еще раз обращаю внимание — если что-то опенсорс и бесплатно, это совершенно не означает, что это общественное достояние, а не объект интеллектуальной собственности.
А может быть они и дают?
Тем кому сами дали бинарники? Всему интернету — они не обязаны давать.
Тут надо КРОК спросить скорее — им исходники дали? А возможность запросить и получить — у них есть?
Ему из «НОРСИ-ТРАНС» железку дали, для опытов. Оно конечно возможно, что Норси-Трансу всё дали.
Правда, тут начинаются настоящие нюансы… Лицензия запрещает накладывать на распространяемый код ограничения, отличные от установленной самой лицензией, вплоть до автоматического аннулирования предоставленной распространителю лицензии за такие действия. А тут мало того, что распространение сопряжено с дополнительными условиями получателю о нераспространении кода, и что «сорсы по запросу» — это уже нарушение лицензии, так разработчик еще и открыто заявил, что исходного кода ядра даст не всем, кому даст сорсы ЭльбрусОС (а там и без ядра наверняка полно софта под GPL-лицензией)…
Так что, даже если в узком круге ограниченных ведомств лицензия и не нарушается (всё равно не проверить), то на «гражданском» рынке это появиться легально не может в принципе в настоящее время.
Странно, уже не первый раз вижу что якобы "внутри x86_64 RISC-ядро", но не вижу никаких доказательств или ссылок. Видимо, фанаты RISC специально распускают ложные слухи. В RISC-архитектуры, как правило, команды имеют похожую структуру и длину, и похожий процесс их выполнения. x86_64 под это определение не попадает — это CISC-процессор.
Также, не написано — выполнялись ли тесты, используя нативный код для Эльбруса, или в режиме эмуляции x86?
VLIW — очень интересная идея. Но, что огорчает, это то, что у процессора Эльбрус из-за этого получаются очень жирные команды — до 64 байт! Наверно, это создает большую нагрузку на кеш и относительно медленную память? Также, интересно, что у него очень много регистров (256, по моему) — по идее, это бы должно давать экономию при работе с локальными переменными.
Что касается производительности, то тут чудес ждать не стоит — техпроцесс у Эльбруса довольно крупный и быстро работать не может.
И, конечно, исходники ОС надо выложить. Какой позор — российский процессор работает на ворованном коде.
Странно, уже не первый раз вижу что якобы «внутри x86_64 RISC-ядро», но не вижу никаких доказательств или ссылок. Видимо, фанаты RISC специально распускают ложные слухи. В RISC-архитектуры, как правило, команды имеют похожую структуру и длину, и похожий процесс их выполнения. x86_64 под это определение не попадает — это CISC-процессор.
Речь обычно о том, что x86 процы делят инструкции на µop, которые раз как раз походят на RISC. А так, грань между RISC и CISC давно стерта и спор этот имеет не более чем академический интерес.
При этом «Эльбрусы» работают явно медленнее из-за того, что софт написан не для VLIW, требующей совершенно другого подхода и дисциплины кода, и компиляции.
А для vliw - это как? Чтобы данные лежали ровными массивчиками, везде руками были расставлены префетчи, циклы имели статические границы и никаких вызовов функций по указателю? Век вроде 21й на дворе
А для vliw - это как?
Думаю, речь в исходной цитате о режиме совместимости, линуксы и виндоусы скомпилены ведь под х86/64, а не под vliw эльбрус. В результате там работает механизм двоичной трансляции, когда инструкции динамически парсятся во vliw, а оно небыстрое и главное неэффективное. В 21м веке, если следите, интеловский Itanium уже затонул на этом.
Чтобы данные лежали ровными массивчиками, везде руками были расставлены префетчи, циклы имели статические границы и никаких вызовов функций по указателю?
Почти так, только не руками. Существенное отличие VLIW от всяких x86/CISC в том, что VLIW очень сильно полагается на статическое планирование команд (это когда компилятор всё раскладывает так, чтобы конвейер и ресурсы процессора были задействованы максимально эффективно), в то же время в х86 и прочих хорошо прокачано динамическое планирование исполнения команд (все эти спекулятивные исполнения), когда почти всё эффективно разруливается железом в рантайме по ситуации. В результате без норм компилятора vliw неэффективен.
Я думаю, что все, что тут тестировалось, скомпилировано под e2k, а не в режиме двоичной трансляции работает. Я читал руководство по эффективному программированию под Эльбрус (если честно, субъективно довольно красиво у них организован регистровый файл, подготовка переходов, режим спекулятивности и предикатного исполнения), и примерно представляю, что такое vliw. Комментарий о другом был. Что нужно не заставлять программистов "писать под vliw" (с ручной расстановкой префетчей, например), а процессор/компилятор допиливать, чтобы он нормально жевал современный код, с кучей мелких объектов, косвенных вызовов (привет, аппаратный предсказатель переходов!) и короткими базовыми блоками. Числодробилки, под которые Эльбрус вроде должен бы быть эффективен (но это тоже не совсем так, видел статью, где есть сравнение на программах численного моделирования, и там эльбрус тоже совсем не айс, даже в пересчете на ядро*гигагерц), сейчас пишут на GPU, и это правильно.
Эльбрусу сильно не хватает аппаратного планировщика, предсказателя переходов, и аналога HyperThreading - он, если честно, прямо просится, но я слабо себе представляю, как он может быть реализован на процессоре со статическим планированием исполнения.
Что нужно не заставлять программистов "писать под vliw" (с ручной расстановкой префетчей, например), а процессор/компилятор допиливать, чтобы он нормально жевал современный код, с кучей мелких объектов, косвенных вызовов (привет, аппаратный предсказатель переходов!) и короткими базовыми блоками.
С этим соглашусь лишь частично. Даже без привязки к Эльбрусам суть архитектуры VLIW в том, чтобы переложить всё планирование на софт и программиста, и этим максимально упростить/удешевить железо. Как только появляются все эти планировщики и спекулятивное выполнение в железе, преимущества VLIW сходят на нет и это перестаёт быть VLIW. Но соглашусь с тем, что компилятор для VLIW должен быть совсем конфеткой.
так они и появляются в железе потому, что целую гору оптимизаций иначе как на уровне железа не получится сделать. Простой пример, есть 2 инструкции, одна пишет в память, другая читает. Интел видит, что операнды (=адреса памяти) у них разные, значит можно выполнить одновременно, переставить их и т.д, короче независимость инструкций для него налицо. А компилятор эльбруса видит 2 указателя, из одного читают, в другой пишут, и поди докажи, что они не равны, особенно если указатели из разных единиц трансляции, так что в одну широкую команду он не сможет их запихнуть просто так, и будет вынужден генерить дополнительный if, задействовать предикатное исполнение и тд, на что будут теряться такты, и не факт, что выигрыш будет того стоить. Или косвенный вызов - до того, как из кэша придет адрес перехода, интел смотрит в предсказатель переходов и видит, что с вероятностью 99% прыгнем туда-то, и начинает подкачивать код, исполнять его спекулятивно. Компилятор эльбруса за косвенный вызов может заглянуть только будучи JIT-ом или имея профиль выполнения (что, ну скажем, так себе), в противном случае придется подождать подкачки адреса из кэша/памяти, и только потом подкачки кода и исполнения.
Вы всё правильно пишете, но каждому инструменту своё место. Если нужен CISC, то надо принять неизбежную сложность и пилить его изначально, с динамическим планированием и всем прочим, если же выбран VLIW, то надо принять необходимость мириться со статическим планированием и тем, что оно уступает динамическому планированию даже в теории, зато существенно упрощает железо. Имхо, выбор типа архитектуры -- это одно из самых первых и основополагающих решений при проектировании процессора и хот-фиксами такое не правится ну никак, с другой стороны, каждый тип архитектур имеет свои плюсы и минусы. В случае Эльбруса было бы интересно почитать обоснование, почему был выбран именно VLIW.
это не отменяет того, что HyperThreading в эльбрусе нужен) в итаниуме, кстати, был.
Прикольно, не знал, и правда был в последних версиях. А ссылки на детальную архитектуру случаем не найдется? Интересно, что у них там за монстр получился в результате в последних итаниумах.
ссылки нету( Но вангую, что HT для vliw не должен сильно отличаться. Укорачиваем вдвое широкую команду, чтобы потом из двух сделать одну (инструкции в них независимы по определению), добавляем в ядро второй MMU, второй набор регистров состояния потока, флаговый регистр, ну и регистровый файл надо как-то тоже распилить надвое - и вроде как должно заработать.
С нетерпением жду когда 1С запилят под Эльбрус, чтоб скрепно было.
Тесты «Эльбрус» для энтерпрайз-приложений: а они в порядке для догоняющих