Сравнение производительности Эльбрус-8С с Intel и AMD

Nvidia TITAN V
6144 - 7450 Гфлопсов
12288 - 14899 Гфлопсов одинарной точности

при векторных вычислениях

Вот тут и собака зарыта. Векторные вычисления бывают только в каких-нибудь видео кодеках.

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

ракетными ЦЕЛЯМИ

это что такое за ракетные цели?! прямо глаза режет такая фраза

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

Да и ещё в догонку: - Исполнение двоичных кодов в системе команд Intel х86 и х86-64 с помощью динамической трансляции без перекомпиляции программ.

- Расширенный температурный диапазон от −60 до +85 градусов.

КАРЛ! от -60 до +85!!!!

zabudkin

Основная особенность линейки отечественных процессоров «Эльбрус»

— заложенный в архитектуру принцип явного параллелизма операций, он даёт возможность выполнять на каждом ядре >>>>>до 25 операций за один машинный такт<<<<<<, что обеспечивает высокую производительность при умеренной тактовой частоте;

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

А вот из описания архитектуры:

Процессор может детектировать независимые операции и запускать их параллельно (суперскалярность) и даже менять их порядок (внеочередное исполнение). Однако динамический анализ зависимостей и поддержка внеочередного исполнения имеет свои ограничения: лучшие современные процессоры способны анализировать и запускать >>>до 4-х команд за такт<<<<. Кроме того, соответствующие блоки внутри процессора потребляют заметное количество энергии.

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

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

с помощью динамической трансляции

С потерей (или недополучением, ведь исходный код не оптимизрован под vliw) производительности...

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

даёт возможность

Есть большая разница между «возможностью» и применимостью этой возможности на практике, смекаешь?

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

ракетными ЦЕЛЯМИ

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

-----------

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

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

zabudkin

А в Itanium этого всего не было?

с помощью динамической трансляции

С потерей (или недополучением, ведь исходный код не оптимизрован под vliw) производительности...

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

-----

Так я и говорю о том, что Вы все почему-то упёрлись в х86! У Эльбруса своя архитектура, надо смотреть что она может, а то, что х86 может выполнять, так это просто ФИЧА.

zabudkin

Нет, «всё» не «работает параллельно». Чисто физически тебе нужно сначала знать X и Y, прежде чем посчитать X*Y, это никак не обходимая проблема и потому такие архитектуры ни годны нигде кроме узких ниш.

даёт возможность

Есть большая разница между «возможностью» и применимостью этой возможности на практике, смекаешь?

--------

Вы видимо плохо знаете русский технический язык. Даёт возможность - это и есть факт наличия этой возможности.

zabudkin

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

А т.е. ещё и своя ОС + весь свой рынок ПО, ну что же, удачи, через 100 лет примерно сможете десятку написать и половину всего ПО которое сейчас есть в мире. Ну и Intel + GPU рвёт как тузик грелку всё это.

Нет, ты плохо знаешь, что для «параллельности» она должна изначально присутствовать в вычислениях, а я тебе пытаюсь это объяснить.

Ну я бы так не сказал. Те же нейросети отлично параллелятся и нужны сейчас почти везде.

Что 22нм? Я же и говорю, что 22нм делают не в России, а на Тайване. А в России завод, который планировал сделать 22нм – банкрот. Возможно из-за санкций.

Нет, «всё» не «работает параллельно». Чисто физически тебе нужно сначала знать X и Y, прежде чем посчитать X*Y, это никак не обходимая проблема и потому такие архитектуры ни годны нигде кроме узких ниш.

------------

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

За один такт выполнятся максимум 25(33) инструкции.

Да, надо оптимизировать и писать именно под Эльбрус, я именно про это и пишу, а не про х86.

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

А т.е. ещё и своя ОС + весь свой рынок ПО, ну что же, удачи, через 100 лет примерно сможете десятку написать и половину всего ПО которое сейчас есть в мире. Ну и Intel + GPU рвёт как тузик грелку всё это.

-----------

Нет, я к тому, что Эльбрус имеет смысл ТОЛЬКО В СПЕЦИАЛИЗИРОВАННОМ ПО, для госнужд например, для оборонки, но не для дома. Вот я о чём. А тут вся речь про Эльбрус свялась к его применению дома :)

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

Утрируя, представь такую ситуацию: вычисление X, Y и X*Y не влезает в одну инструкцию. Занавес, приходится генерировать несколько инструкций, состоящих из одной операции и кучи заглушек. А всяких примочек, ускоряющих такой код в эльбруе нет, а в x86 куча...

Это рассуждения немного уровня «В огороде бузина, а в Киеве — дядька». Для нейросеток делают специальные ASIC, я уверен, они для этого быстрее эльбруса.

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

Для нейросеток делают специальные ASIC

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

Если интелю кастрировать все то, с чем связаны Meltdown и прочее, то его дутая производительность упадет прилично.

• Заплатки от spectre и ко влияют только на скорость системных вызовов, а не вычислительного кода.
• В 9900KS залатали аппаратно и производительность не упала, скорость сисвызовов не хуже, чем на 3900X.

кроме Meltdown, Spectre есть еще TLBleed и в целом понимание того, что если вы хотите безопасности - отключайте нахрен гипертрединг. В 9900KS «милая, я все починил!»? Ок. Поживем - увидим.

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

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

-------

Ну вот, Эльбрус потому и не такой «производительный» :)

А может и не потому, тк его неуязвимость не доказана...

А может и не потому, тк его неуязвимость не доказана...

------

Нет ни одной доказанной неуязвимости НИ ОДНОГО ПРОЦЕССОРА.

Эльбрус прошёл проверки разных госорганов России, и мне как-то им НЕ доверять оснований нет. Напомню, Эльбрус был и до 1991 года и до его перехода в ЗАО.

А наши ГосОрганы пока справляются, армия существует, техника ездит, ракеты летают, радары и спутники свою задачу выполняют.

А Вы верьте в процессоры на архитектурах CISC, RISC, MISC и их гибриды.

X86 тоже небось проходил проверки американских госорганов...

VLIW (англ. Very Long Instruction Word — «очень длинная машинная команда») — архитектура процессоров с несколькими вычислительными устройствами. Характеризуется тем, что одна инструкция процессора содержит несколько операций, которые должны выполняться параллельно.

По сути является архитектурой CISC со своим аналогом спекулятивного исполнения команд, только сама спекуляция выполняется во время компиляции, а не во время работы программы, из-за чего уязвимости Meltdown и Spectre невозможны для этих процессоров. Компиляторы для процессоров этой архитектуры сильно привязаны к конкретным процессорам. Например, в следующем поколении максимальная длина «очень длинной команды» может из условных 256 бит стать 512 бит, и тут приходится выбирать между увеличением производительности путём компиляции под новый процессор и обратной совместимостью со старым процессором. Опять же, Open Sourсe позволяет простой перекомпиляцией получить программу под конкретный процессор.

Примеры архитектуры: Intel Itanium, Эльбрус-3.

zabudkin

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

28, а не 22 нм

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

-----------------

Архитектура не позволяет :)

Специалисты различают архитектуру процессора и микроархитектуру процессора.

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

Микроархитектура процессора — это, грубо говоря, внутренняя схема устройства процессора, в том виде, в каком её видят разработчики процессоров.

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

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

К этой категории относятся МЦСТ «Эльбрус», КМ211, Мультиклет и ряд других архитектур.

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

МЦСТ Эльбрус — российская архитектура, российская микроархитектура.

Сильные стороны:

распараллеливаемые военные/научные/инженерные вычисления с плавающей точкой (возможный пример использования: геологоразведка); аппаратные особенности, позволяющие реализовывать высокозащищённые системы.

Слабые стороны:

отставание от «переднего края» по технологиям формирования физического уровня (процессор 8С сформирован по техпроцессу 28 нм, например); отсутствие компилятора gcc для платформы e2k, закрытость оптимизирующего компилятора lcc и набора архитектурнозависимых правок на системное ПО (по состоянию на осень 2018 года).

Мифы:

«Эльбрусы трудно продвигать за рубежом» — эльбрусы не продаются за рубеж, для международных поставок сперва потребуется разрешить имеющиеся проблемы совместимости с GPL и формальной засекреченности системы команд; «под Эльбрус нет софта» — есть и в количестве тысяч пакетов системного и прикладного ПО под GNU/Linux, на базе которого и создана штатная ОС Эльбрус (OSL); «софтвер на Эльбрус с Linux переносится простой перекомпиляцией» — любые программы, закладывающиеся на расширения gcc или особенности архитектуры (SSE/AVX/NEON, например), приходится так или иначе адаптировать либо вовсе переписывать (как вышло с Java); «взяли бы и сделали x86» — архитектура больше не лицензируется, единственным вариантом является покупка компании с лицензией на руках (например, VIA); в МЦСТ это прекрасно понимали и пошли путём обеспечения программной совместимости, что вылилось в разработку слоя бинарной совместимости (rtc/lintel). По состоянию на осень 2018 года выпущено несколько тысяч экземпляров процессоров «Эльбрус», что в значительной мере обуславливает высокие цены на сами процессоры и системы на их основе; тем не менее и они дешевеют со временем, например, «Эльбрус 801-РС» при выходе имел ценник в 350 тыс.руб., сейчас он доступен юр. лицам уже по 300 тыс.руб. Динамично развивается программная экосистема — например, уже доступны ОС Эльбрус, КПДА Нейтрино-Э, ОС Альт. [4]

МЦСТ SPARC — российская реализация международной архитектуры SPARC на базе российской микроархитектуры.

архитектуру ПК с одним или несколькими очень быстрыми ядрами и кучей медленных

Собственно, Интел это уже разрабатывает. Год-два подожди.

Из-за багов в процессоре, не связанных со спекулятивным исполнением, как минимум уже были возможности Denial-of-Service. Не вижу, как именно архитектура может такого не позволять.

архитектуру ПК с одним или несколькими очень быстрыми ядрами и кучей медленных

Собственно, Интел это уже разрабатывает. Год-два подожди.

----

Интересно, и как они синхронизировать собираются медленные с быстрыми? Точнее, быстрые с медленными? Чем иметь 20 медленных, не проще ли иметь 1 обычный? Я себе слабо представляю, чтобы в ближайшие 15-30 лет, разработчики писали бы что-то, что учитывало бы эти 20 физ.потоков, по потоку на каждый медленный проц, чем 20 потоков на одном проце.

Из-за багов в процессоре, не связанных со спекулятивным исполнением, как минимум уже были возможности Denial-of-Service. Не вижу, как именно архитектура может такого не позволять.

----

пруф можно на Denial-of-Service на Эльбусе?

Можно пруф на его отсутствие?

Чем иметь 20 медленных, не проще ли иметь 1 обычный?

Не проще, энергоэффективность же.

как они синхронизировать собираются медленные с быстрыми

В смысле? Как сейчас arm мучает биг.литтл? Так и тут наверное.
Загугли Intel Lakefield.

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

Даже круче, как ты себе представляешь, что код ОТ НЕСКОЛЬКИХ ПРОЦЕССОВ упакуется в одну дляинную команду? На x86 несколько процессов полностью загружают все блоки ядра.

Можно пруф на его отсутствие?

----- пруф на отсутствие Daniel of service Эльбруса? Вы угораете? :) Я задал Вам вопрос, дайте мне ссылку, что на Эльбрусе это есть, подколол Вас.

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

Вы очень глупо выглядите :)

Ясно, пошли манявры.

В безопасности подход таков, что всё уязвимо по-умолчанию.

Чем иметь 20 медленных, не проще ли иметь 1 обычный?

Не проще, энергоэффективность же.

--------

А зачем гонять 1 обычный проц на все 100%? Такого уже давно как правило нет.

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

Даже круче, как ты себе представляешь, что код ОТ НЕСКОЛЬКИХ ПРОЦЕССОВ упакуется в одну дляинную команду? На x86 несколько процессов полностью загружают все блоки ядра.

-----

Вы не в теме.

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

Или ты не понял, что я про DoS самого процессора, ммм? Неудобная последовательность команд вещала сам процессор.

Манявры продолжались.

Я достаточно в теме, чтобы видеть, когда жино пытаются наебать.

Или ты не понял, что я про DoS самого процессора, ммм? Неудобная последовательность команд вещала сам процессор.

------

Боже мой :) Сгинь нечистый, сгинь! :))) В библиотеку!!!!

https://www.cvedetails.com/cve/CVE-2017-7262/

Ну что, клован?