Де використовують процесори Ельбрус

0 Comments

Легенды и мифы процессора Эльбрус в примерах

В ответ на мою статью про тупиковость развития линейки процессоров Эльбрус в качестве базовой платформы для отечественных general-purpose CPU, пользователь @alexanius (Алексей Маркин) написал свою статью-ответ, где привёл возражения моим тезисам. Дабы не превращать дискуссию в формат форумной перепалки, я попытаюсь структурировать изложенные возражения, максимально опустив малозначимые на мой взляд детали и не относящиеся к делу реплики. Также мы оставим на совести Алексея некорректные высказывания и переходы на личности. Это мишура, которая не поможет нам глубже понять суть проблемы.

Итак, если суммировать, то в моей статьей были приведены следующие недостатки Эльбруса:

  1. Слабость программной экосистемы в силу того, что архитектура очень узко используемая и нераспространённая.
  2. Проблема принципиального проигрыша RISC/CISC системам по производительности ввиду:
    1. Более низких тактовых частот дизайна VLIW процессоров
    2. Более низкой производительности микроархитектуры из-за отсутствия динамического планирования операций
    3. Дополнительного снижения производительности реальных приложений из-за сложности реализации компиляторных оптимизаций для Эльбрус

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

    Итак, давайте пройдёмся по тексту от @alexanius и по каждому из данных пунктов посмотрим, действительно ли приведённые им аргументы меняют картину.

    Слабость программной экосистемы

    Какие возражения были приведены в по данному вопросу?

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

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

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

    На текущий момент в нём портировано более 14500 пакетов

    Это прекрасно, но это мизер по сравнению с теми же ARM или RISC-V. Для RISC-V, которая фактически ещё находится в стадии своего зарождения, уже портированы популярные дистрибутивы Ubuntu, Debian, Fedora с десятками тысяч пакетов каждый, сделана поддержка в Qemu, gcc, lllvm, OpenJDK, v8 и т.д. и т.д. Т.е. уже создана экосистема, на порядок превосходящая Эльбрусовскую. В случае ARM разрыв ещё более драматичный.

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

    Простим автору его неинформированность. Система бинарной трансляции не является уникальной возможностью процессора Эльбрус. Для Arm существуют как минимум Rosetta 2 и ExaGear. Qemu имеет хоть и медленный, но зато поддерживающий широкий спектр host-архитектур движок бинарной трансляции.

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

    Проблема принципиального проигрыша Эльбрусом по производительности RISC/CISC процессорам

    Частота

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

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

    Эта фраза рассчитана на тех, кто умеет внимательно читать. В таблице приведено сравнение различных VLIW архитектур (Итаниум и Эльбрус) с аналогами RISC/CISC, разработанных на таких же техпроцессах в одних и тех же компаниях. И везде видно, что VLIW решения всегда своим конкурентам уступают по частоте. И у этого есть вполне определённая причина – особенности архитектуры у VLIW-процессоров. А конкретно для Алексея вопрос можно переформулировать следующим образом – почему Эльбрус(e2k), который постоянно выставляется как главный процессор от МЦСТ и в который вкладываются основные разработческие ресурсы, уступает по частоте процессорам линейки Sparc от МЦСТ, в которые всегда вкладывались намного меньше? Т.е. дело не в деньгах и нанометрах, а в принципиальных ограничениях VLIW-архитектур.

    В конце концов, в МЦСТ есть профильные специалисты, которые вполне профессионально могут ответить на вопрос, а какие предельные частоты достижимы на Эльбрусах семейства e2k? Я могу оценить эту цифру в диапазоне 2.5-3 ГГц. Но было бы здорово, если эксперты прокомментируют данный вопрос. Напомню, что топовые x86 процессоры преодолевают отметку в 5 Ггц.

    Микроархитектурная скорость и снижение производительности на реальных задачах

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

    В области разработки компиляторов существует целое направление, занимающееся решением именно этой проблемы — анализ указателей

    Получается ли разрывать зависимости на практике? Да, получается, много где. Более того, в Эльбрусе разрыв зависимостей возможен не только во время компиляции, но и во время исполнения. Одним из таких механизмов является DAM, позволяющий аппаратно разрывать зависимости, которые не смог порвать компилятор

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

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

    И в итоге заключает:

    только вот в реальной жизни как раз всё обычно весьма неплохо

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

    Как говорится, вместо тысячи слов – дайте код. Давайте воспользуемся любезно предоставленным Алексеем godbolt сервером и просто посмотрим, что происходит в реальности. Я зашёл в гугл, набрал в поиске «сортировка вставками github» и скопировал код с первой же ссылки в окно godbolt-сервера (только увеличил ARRAY_SIZE до 100000 для удобства запуска):

    #include #include #define ARRAY_SIZE 100000 void fill_random(int*a) < for(int i=0;i> void Sort(int*a) < int t, // временная переменная для хранения значения элемента сортируемого массива p; // индекс предыдущего элемента 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--; >> > void print_array(int*a) < for(int p=0;p> int main()

    Выставил в качестве компилятора e2k lcc 1.26.04, опции оптимизации -O4.

    Итак, что же у нас получилось? Пытливый читатель может в качестве тренировки зайти на сервер и самостоятельно оценить легкость восприятия e2k-ассемблера. Я же приведу здесь выжимку. В данном примере основной код, определяющий производительность теста – это внутренний цикл while в алгоритме сортировки (функция Sort). Для Эльбруса он выглядит вот так:

    Что мы видим? Одна итерация основного цикла занимает 13 тактов. В нём 9 семантически полезных инструкций (остальные – это специфика Эльбруса, не влияющая на реальное IPC). Т.е. IPC составляет 0.69 инструкций в такт. Эффективность использования широкой команды в данном случае очевидна – она крайне низкая. Никаких разрывов зависимостей не произошло, DAM не применился, но зато произошёл абсолютно бессмысленный инлайн функции Sort в функцию main.

    Превентивно закрою здесь все дальнейшие рассуждения на тему «но здесь же есть пересечение между load и store, поэтому там что-то не применилось!». В любом минимально реалистичном коде возникают такого, и даже более сложного рода проблемы. Здесь мы имеем практически идеальный для Эльбруса случай – никаких сторонних модулей, 40 строчек кода, регулярный проход по массиву. И даже в таком простейшем по факту случае статический анализ не смог создать оптимальный код.

    А что же происходит, например, на x86? Код основного цикла из под gcc 7.5.0 (на новых версиях gcc там вообще векторизация включается, поэтому я использовал для более равного сравнения немного более старую версию):

    .L8: mov edx, DWORD PTR [rax] cmp edx, ecx jle .L7 mov DWORD PTR [rax+4], edx mov DWORD PTR [rax], ecx sub rax, 4 cmp rsi, rax jne .L8

    В основом цикле 8 инструкций, одна итерация занимает ~3 такта, IPC 2.67 (проверено на Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz)

    В итоге, микроархитектурная скорость исполнения данного кода на x86 превышает Эльбрус в 13/3 = 4.33 раза. Т.е. во столько бы раз проиграл Эльбрус, будь он по частоте сопоставим с топовыми RISC/CISC системами.

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

    Вообще, когда говорят о производительности ВК (вычислительных комплексов), существуют общепризнанные тесты, на результаты которых принято ссылаться. Например, ни один профессионал не сошлётся на результаты теста drystone или whetstone — его просто на смех поднимут. Если мы говорим про производительность на широком круге задач, то не существует набора тестов лучше чем SPEC CPU 2017 или его более старой версии 2006 года

    Обсуждение проблемы профессионализма с сотрудниками компании МЦСТ можно начинать с вопроса публикации результатов всевозможных бенчмарков. Для примера, вот как это сделано у ваших коллег из Байкал Электроникс. А от МЦСТ для Spec CPU 2017 мы видим 2 цифры без указания каких-либо подробностей вообще, полуподпольно напечатанных в статье-ответе. Но т.к. нам не остаётся ничего другого, будем отталкиваться от тех значений, которые были приведены.

    Из результатов следует что Эльбрус 2016 года выпуска с частотой 1300 МГц работает быстрее Байкала 2019 года выпуска с частотой 1500 МГц

    Точнее, Spec CPU 2006 и Spec CPU 2017 работают быстрее на Эльбрусе, чем на Байкал-М. Но мы с вами давайте посмотрим на вопрос производительности чуть более широко. Я взял цифры из данной статьи за основу и поправил их исходя из уточнённых данных от Алексея и отчёта Байкал Электроникс. Там, где новых данных нет, всё оставил как есть:

    Whetstone MP [MWIPS]

    Linpack 100 [MFLOPS]

    Scimark 2 [Composite score]

    7zip (Comp; Decomp) (MT)

    STREAM (Copy; Scale; Add; Triad) [MB/s]

    12315; 12061; 11064; 11529

    23097; 23137; 25578; 25643

    Blender (RyzenGraphic_27) [min:sec]

    Sunspider 1.0.2 [ms]

    Что мы видим? Эльбрус существенно выигрывает у Байкал-М на тестах, на которых важна работа подсистемы памяти. Это вполне объяснимо, т.к. в Эльбрусе, чтобы нивелировать недостатки микроархитектуры ядра, приходится делать акцент на улучшении подсистемы памяти, увеличивая размеры кэшей, количество load/store операций исполняемых процессором за такт, количество каналов памяти. И не забываем, что в конце концов, Эльбрус – это изначально серверный процессор, с TDP в районе ~90 Вт, тогда как Байкал-М основан на ядре для мобильного рынка и его TDP составляет ~30Вт.

    На тестах Javascript Эльбрус существенно проигрывает Байкал-М. Опять-таки, очевидно почему – разработать хороший JS компилятор для VLIW-архитектуры задача сложная и трудоёмкая. Результат тут, как говорится, налицо (и вдогонку к вопросе об экосистеме).

    А вот со счётными бенчмарками интереснее. На простеньком Coremark Эльбрус умудрился существенно проиграть. Dhrystone/Whetstone/Blender/7zip показывают примерно одинаковые результаты. И только на Spec CPU 2006 / Spec CPU 2017 результаты Эльбруса в 1.5-2 раза выше. Но собственно, именно к этому факту мной было сказано, что цифры для Spec CPU 2006/2017 вылизывались на компиляторе многие годы. И в реальности они показывают ту пиковую производительность, которую можно на Эльбрусах достичь. Но проблема в том, что для бОльшей части остального кода такие показатели будут недостижимы, т.к. компиляторные эвристики и опции, заточенные на Spec CPU 2006/2017, там будут работать существенно хуже. В то время как для тех же RISC/CISC архитектур с ОоО разница между «наоптимизированными бенчмарками» и кодом из реальной жизни будет существенно ниже. Что мы, собственно, и видим в табличке.

    Поэтому утверждение, что даже Эльбрус-8СВ работает быстрее, чем Байкал-М, надо воспринимать с оговорками.

    Теперь давайте всё же разберёмся со Spec CPU 2017 и микроархитектурной скоростью, которую на ней показывают различные процессоры. Помним, что это – лучший бенчмарк для Эльбруса.

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

    Во-первых, целью моей статьи не было сравнение российских процессоров. То, что сейчас Эльбрус-8СВ обыгрывает по сути единственного конкурента Байкал-М (и то далеко не всегда, как мы уже увидели) само по себе мало о чём говорит. МЦСТ почти уже 30 лет разрабатывает high-performance GP CPU и бОльшую часть времени было практически единственным российским разработчиком в данной нише. Но в итоге оказалось, что первый же конкурент – компания Байкал Электроникс, которая имела нулевой опыт создания процессоров, но зато имела сложности с лицензиями, финансированием, управлением из-за проблем владельца, набила кучу шишек первого продукта, за несколько лет выдала чип, который конкурентен чипам от МЦСТ. В данный момент тот же Байкал Электроникс готовит к выпуску процессор Байкал-S, как раз предназначенный для серверного рынка. Можно грубо прикинуть производительность будущего чипа. Если Байкал-М основан на ядре Cortex-A57, то Байкал-S будет основан на Cortex-A75. С учётом роста частоты и микроархитектурной производительности, одно ядро добавит где-то в 2-3 раза Spec Rate на Spec CPU 2017. А увеличение количества ядер до 48 увеличит суммарный Spec Rate ещё примерно в 6 раз. Т.е. итоговый Spec Rate для Байкал-S будет где-то около 100 (и для SpecINT, и для SpecFP), или даже выше. А конкурент от МЦСТ новый Эльбрус-16С от текущих цифр Эльбрус-8СВ прибавит лишь 2.67 в максимуме ( В 1.33 раза вырастет частота и в 2 раза количество ядер). Итоговый Spec Rate будет в районе 28 для SpecINT и 44 для SpecFP. Вот и вся история. И причина этого в том, о чём была написана моя первая статья.

    Во-вторых, спрашивать сравнение с импортными процессорами достаточно странно, потому что ситуация там абсолютно катастрофична для Эльбруса. Но если кому-то хочется мазохизма – пожалуйста. Вот ссылка на официальные результаты бенчмарка Spec CPU 2017 для различных систем. Если мы говорим про максимальные цифры, то там есть системы со значениями больше 1000 (и для SpecINT, и для SpecFP). Для 8-ми ядерных систем (как Эльбрус-8СВ) средние значения колеблятся в районе 70-80 для SpecFP и 50-60 для SpecINT, для топовых систем подбираясь и переваливая за 100. Например, результат ASUS RS520A-E11(KMPA-U16) Server System 3.70 GHz, AMD EPYC 72F3 составляет 98 для SpecINT и 124 для SpecFP. Напомню, для Эльбрус-8СВ эти цифры 10.68 и 16.55 соответственно. Т.е. в 9 и 7.5 раз меньше на САМОМ лучшем для Эльбруса бенчмарке.

    На основе имеющихся результатов Spec CPU 2017 можно, кстати, достаточно хорошо оценить микроархитектурную скорость современных RISC/CISC процессоров. Она колеблется в среднем в диапазоне 2-3 SpecRate на один гигагерц одного ядра, переваливая за 4 для SpecFP для топовых решений (как для приведенного выше решения на базе AMD EPYC 72F3). Для Эльбруса же эта микроархитектурная скорость равна 0.9 для SpecINT и 1.4 для SpecFP.

    По итогу мы видим, что микроархитектурная скорость процессоров Эльбрус в 3-4 раза уступает современным серверным CISC-процессорам топового класса. Заметьте, эта оценка достаточно хорошо совпадает с той цифрой, которую мы получили на реальном коде с сортировкой вставками. И это ЛУЧШИЕ примеры для Эльбруса. А в реальной жизни будет множество кода, где эти значения будут ещё хуже. Т.е. даже если теоретически решить частотные проблемы Эльбруса, он будет всё равно в разы проигрывать RISC/CISC конкурентам.

    Мне кажется, после приведённых цифр и примеров, вопрос о проблемах микроархитектурной скорости Эльбруса можно закрыть – она катастрофически уступает RISC/CISC аналогам.

    Осталось только разобрать следующий пример:

    Ну что ж, давайте посмотрим реальные проекты. Вот из свеженького: «По результатам тестов можно сделать вывод о том, что процессор «Эльбрус-8СВ» успешно решает задачу построения системы хранения данных и позволяет получать достойные результаты на HDD

    Я сэкономлю время читателей и скажу кратко – приведённый тест FIO предназначен для измерения скорости работы с дисками. Производительность данного теста упирается в скорость работы самих дисков, их микроконтроллеров и подсистемы памяти процессора. Реальная вычислительная производительность процессорного ядра там неважна. Для специализированных решений для дата-центров разрабатывают системы на нишевых in-order процессорах, которые там отлично справляются. Ну и показательно, что нам сначала рассказывали про то, что Spec CPU 2006/2017 это самый показательный бенчмарк. Но когда дошло дело до сравнения, тут оказался почему-то не Spec CPU 2006/2017, а FIO.

    Трудоёмкость разработки под архитектуру Эльбрус

    Мне кажется, всё вышеизложенное достаточно ёмко описывает, какова трудоёмкость разработки под Эльбрус – она существенно выше, чем для RISC/CISC архитектур. И ввиду сложности кода ассемблера для понимания (godbolt в помощь), и ввиду сложности компилятора и необходимости постоянного анализа кода и настройки опций.

    Что же касается данного высказывания:

    Я бы мог много написать про то, что программистам неплохо бы разбираться в компьютерах

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

    но пожалуй остановлюсь на том, что автор не в курсе вектора разработок МЦСТ, и одно из направлений — это как раз отчёт о применении оптимизаций для помощи пользователю

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

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

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

    Алексей, когда вы выйдете за стены МЦСТ и обнаружите за ними реальный мир, то вы поймёте, что делать такого рода заявления – это расписаться в собственном непрофесионализме. Потому что код пишут не только великие гении и победители ICPC, а множество людей, куда менее искушённых в программировании (и таких абсолютное большинство). Потому что в крупном проекте определить какой код при какой нагрузке становится горячим зачастую непросто и требует много усилий по анализу, на которые часто просто нет времени. И хороший процессор должен уметь исполнять с приемлемой производительностью и качественный код, и не очень.

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

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

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

    Вы пытаетесь поставить под сомнение не просто вышесказанное, а мнение, сложившееся у экспертов в индустрии. Например, Линуса Торвальдса, Хеннеси и Паттерсона, и даже отец Эльбруса Б. Бабаян соответствующе высказался по поводу VLIW:

    Мы думали: ну, сделать 32 цуга – и будет у нас настоящий параллелизм! Но я допустил тогда ошибку. Я подумал, что это очень сложно, а ведь есть подход попроще – подход широкой команды. Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…

    В итоге, мы сделали широкую команду. Но не такую, как в Itanium. Itanium – это тоже полное, так сказать, недоразумение. Потому что по ширине он такой же, как суперскаляр: 6 команд. И при этом использует статическое планирование. Почему он должен быть быстрее, чем суперскаляр? Не понимаю

    Тупиковость развития VLIW-архитектур для general-purpose CPU стала понятна экспертам в индустрии ещё в середине 2000-х(а некоторым возможно и раньше). И много людей в самом же МЦСТ также прекрасно понимали (и понимают) проблему.

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

    Что такое процессор “Эльбрус”?

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

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

    Это имеет следующие плюсы в идеальных условиях открытой экономики и павших “железных занавесов”:

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

    В то же время, существуют и серьёзные недостатки:

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

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

    История появления и особенности отечественной архитектуры процессоров

    “Эльбрус” – это прежде всего название процессорной архитектуры и разработанных на её основе суперкомпьютеров. Изначально они создавались в качестве части систем ПРО по заказу военных.

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

    Разработка началась в 1973 в “Институте точной механики и вычислительной техники имени Лебедева” (ИТМиВТ) под руководством академика Всеволода Сергеевича Бурцева – учёного в области систем управления и теории конструирования универсальных ЭВМ.

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

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

    Первый Многопроцессорный вычислительный комплекс (МВК) “Эльбрус-1” был сдан в эксплуатацию в 1980 году. Он мог содержать до 10 процессоров и показывал производительность в 12 млн операций в секунду. Объём оперативной памяти составлял 64 Мбайт (или 2 20 машинных слов).

    Многопроцессорный вычислительный комплекс “Эльбрус-1”

    Но вычислительная техника развивалась семимильными шагами, и уже в 1985 году появилась следующая модификация МВК. Она получила название “Эльбрус-2” и за счёт использования новой элементной базы производительность возросла до 125 млн оп/с при объединении 10 процессоров (2 из них при этом являлись резервными). Также до 144 МБ увеличился объём оперативной памяти. “Эльбрус-2” нашёл своё применение в таких проектах:

    • РЛС “Дон-2Н” – стационарная радиолокационная станция кругового обзора, главный узел ПРО Москвы;
    • Центр управления космическими полетами;
    • Ядерный центр Арзамас-16 (ныне закрытый город Саров) – первый в СССР центр ядерных исследований, входит в структуру ГК “Росатом”;
    • Ядерный центр Челябинск-70 – ныне закрытый город Снежинск в структуре предприятий ГК “Росатом”.

    Параллельно выпускались и упрощённые версия МВК – “Эльбрус-1К2” и “Эльбрус-Б”, которые использовались для плавной замены устаревших вычислительных комплексов БЭСМ-6.

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

    На перепутье: сотрудничество с Sun Microsystems

    После распада СССР на основе коллектива ИТМиВТ в 1992 году было создано ТОО “Московский центр SPARC-технологий (МЦСТ)” (ныне АО “МЦСТ”). Новое предприятие до 1996 года сотрудничало с американской компанией Sun Microsystems, которая продвигала свои вычислительные машины с архитектурой SPARC (что и отразилось в его названии).

    SPARC (Scalable Processor ARChitecture – масштабируемая процессорная архитектура) – 32- и 64-битная открытая микропроцессорная архитектура, которая основана на сокращённом наборе команд (RISC).

    Совместная работа с крупной компанией позволила МЦСТ получить доступ к передовым технологиям процессоростроения, написания компиляторов, создания операционных систем и пр. Как следствие, вплоть до 2007 года выпускались только микропроцессоры с архитектурой SPARC и вычислительные системы на их базе: МЦСТ-R100, МЦСТ-R150, МЦСТ-R500 и МЦСТ-R500S.

    Процессор МЦСТ-R500 на базе архитектуры SPARC

    Тем не менее, данный период позволил МЦСТ удержаться “на плаву”, сохранить и дополнить научно-техническую базу, а родная архитектура при этом не была забыта.

    Возрождение: современные российские процессоры

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

    VLIW (от англ. very large instruction word – “очень длинная машинная команда”) – архитектура процессоров, при которой используются наборы сложных инструкций большой длины, выполняющихся за один такт. При этом задача их разделения на более простые команды для параллельного выполнения вычислительными модулями процессора ложится на компилятор.

    Ключевые особенности архитектуры “Эльбрус”:

    • длинные наборы команд – выполнение за один такт одновременно до 23 инструкций;
    • эмуляция архитектуры х86 – возможность запуска программного обеспечения, написанного под распространённую архитектуру х86, с помощью динамической трансляции двоичных кодов в коды процессора “Эльбрус” при минимальных потерях производительности;
    • защищённый режим исполнения программ – аппаратная проверка работы программы с памятью и межмодульная защита;
    • непересекающиеся стеки адресов – отделение стека пользовательской информации, что защищает от вирусных атак подменой адреса возврата в библиотеку;
    • отсутствие аппаратного транслятора команд – в отличие от процессоров архитектуры х86, где с помощью вшитого блока декодирования инструкций длинные команды разбиваются на короткие RISC-инструкции для каждого вычислительного модуля, эта работа производится компилятором при создании программ.

    В 2008 году начались поставки компьютеров “Эльбрус-3М” на базе процессора на обновлённой архитектуре, который обладал следующими характеристиками:

    Технологический процесс130 нм
    Тактовая частота300 МГц
    Количество ядер1
    Пиковая производительность2,4 GFLOPS в режиме 64 бит
    Кэш-память 1-го уровня64 КБ данные + 64 КБ команды
    Кэш-память 2-го уровня256 КБ
    Размеры кристалла189 мм 2
    Количество транзисторов75,8 млн
    Мощность6 Вт

    В эпоху процессоров семейства Intel Core с частотой в 3 ГГц характеристики на первый взгляд не поражают воображение, но следует помнить, что “Эльбрус” построен на совсем другой архитектуре. Благодаря своим преимуществам и использованию нестандартных наборов регистров и команд, процессоры не подвержены вирусным атакам и гарантированно не содержат бэкдоров, а при компиляции программ непосредственно под свою архитектуру показывают приличную производительность. В то же время, благодаря динамической трансляции, могут запускать ОС Windows и ПО Microsoft Office!

    Компьютеры “Эльбрус-3М” поставлялись для военной отрасли, и в качестве операционной системы использовали российскую МСВС-Э (Мобильную система Вооруженных Сил), созданную на основе Linux.

    С тех пор МЦСТ активно работал над разработкой новых процессоров по всё более современным техпроцессам и с возрастающей производительностью. По состоянию на 2020 год характеристики флагманов архитектуры “Эльбрус” выглядят следующим образом:

    Процессор«Эльбрус-4С»«Эльбрус-8С»«Эльбрус-8СВ»
    Техпроцесс65 нм28 нм28 нм
    Тактовая частота800 МГц1300 МГц1500 МГц
    Количество ядер488
    Количество операций за такт, на ядро232550
    Пиковая производительность в режиме 64 бит25 GFLOPS125 GFLOPS288 GFLOPS
    Кэш-память 1-го уровня, на ядро64 КБ данные + 128 КБ команды64 КБ данные + 128 КБ команды64 КБ данные + 128 КБ команды
    Кэш-память 2-го уровня8 МБ4 МБ4 МБ
    Кэш-память 3-го уровня16 МБ16 МБ
    Контроллер памятиDDR3-1600 ECCDDR3-1600 ECCDDR4-2400 ECC
    Площадь кристалла380 мм 2321 мм 2350 мм 2
    Количество транзисторов986 млн2,73 млрд3,5 млрд
    Мощность45 Вт80 Вт90 Вт

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

    Материнская плата с процессором “Эльбрус-8С” и южным мостом МЦСТ КПИ-2

    С ростом производительности ЦП расширились и возможности для их применения:

    • государственные учреждения и бизнес-структуры с повышенными требованиями к информационной безопасности;
    • организация многоместных рабочих мест в сфере образования, офисах и т.д.;
    • задачи шифрования с использованием ГОСТ, для которых особенно оптимизирована архитектура;
    • различные прикладные задачи, например, распознавание паспортов.

    “Эльбрус” в царстве телекоммуникаций

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

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

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

    В июне 2020 года на базе операционной системы «Альт Сервер» и программного обеспечения TrueConf MCU был создан вычислительный комплекс для видеоконференцсвязи. Он содержит “под капотом” 4 процессора “Эльбрус-8с” и обеспечивает качественную HD-видеосвязь, позволяя проводить групповые видеоконференции численностью до 150 участников.

    Схема работы терминала ВКС на базе “Эльбрус” и TrueConf MCU

    TrueConf MCU – российский классический программный транскодирующий сервер для аппаратных терминалов с широкими возможностями планирования и проведения видеоконференций.

    “Альт Сервер” – серверная ОС российского разработчика ООО “Базальт СПО” на базе ядра Linux с широкой функциональностью, оптимизированная для применения в корпоративных сетях большого масштаба.

    Благодаря тому, что используемые программные решения собраны специально под архитектуру “Эльбрус”, они работают нативно в её двоичных кодах. Такая связка получает необходимый уровень производительности при полном отсутствии возможных “закладок” – скрытно внедрённых компонентов в аппаратную или программную составляющую вычислительной техники с целью получения несанкционированного доступа к данным.

    Применение TrueConf MCU обеспечивает ряд возможностей:

    • совместимость с различными H.323 и SIP-устройствами, например, Polycom и Cisco;
    • подключение вещания от RTSP-камер в проходящую конференцию;
    • гибкое управление раскладками участников;
    • удалённое управление конференциями;
    • простая интеграция с отечественной ВКС-платформой TrueConf Server;
    • возможность записывать видеоконференции и транслировать их в Интернет в режиме реального времени.

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

    Автор: Компания TrueConf
    Издание: trueconf.ru
    Отрасль: Видеоконференцсвязь