Лого Сделано у нас
176

Организовано серийное производство персональных компьютеров Эльбрус-401 РС

В АО «МЦСТ» завершён цикл подготовки серийного производства отечественных персональных компьютеров Эльбрус-401 РС. В связи со снижением производственных издержек, снижена их розничная цена.

читать полностью

  • 3
    krotozer krotozer
    30.12.1622:58:09

    Архитектура и средства разработки

    * Где и как можно получить подробное справочное руководство по архитектуре и набору машинных инструкций?

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

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

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

    Изначально «Эльбрус-2000» проектировался как высокопроизводительная платформа для вычислений с плавающей запятой, и отходить от этой концепции не планируется — скорее, наоборот: как уже говорилось, следующим шагом после «8С» будет удвоение количества вычислительных блоков вещественного типа. Соответственно, основная стезя — это математические программы, научные и производственные расчёты. Специально для таких задач разрабатывается и оптимизируется библиотека алгоритмов EML (Elbrus math library), а у компилятора LCC есть особые навыки по трансформации некоторых шаблонов исходного кода в вызовы этой библиотеки.

    Другой сильной стороной является наличие большого регистрового файла, — программе в каждый момент времени доступно до 256 регистров, в том числе возможно их автоматическое переименование. Это открывает путь для очень масштабных оптимизаций. Например, в известном обзоре на CNews фигурировал тест gostcrypt (это частная реализация от одного из клиентов МЦСТ), в котором «Эльбрус-4С» на пониженной частоте обогнал Core i7-2600 почти в два раза, — тут нет никаких подтасовок, но был сделан неправильный вывод, будто причиной тому стало отечественное происхождение алгоритма ГОСТ 28147-89. На самом деле секрет успеха — в удачном сочетании структуры этого алгоритма с количественными характеристиками архитектуры E2K и качественными способностями компилятора LCC по проведению глубокой оптимизации. Компилятору удалось развернуть весь цикл преобразования одиночного блока и утрамбовать его в минимально возможный набор командных слов, обеспечив работой все имеющиеся целочисленные блоки, — вот и получился такой впечатляющий результат.

    * Как писать эффективные программы для E2K на языках C/C++ и Fortran? Есть ли учебное пособие на эту тему?

    Попытка создать руководство по архитектуре уже предпринималась, однако авторы тогда сильно углубились в описание аппаратной части, полагая, что из этого материала любой читатель сможет сделать очевидные выводы, — получилось примерно то же, что опубликовано в известной книге «Микропроцессоры и вычислительные комплексы семейства Эльбрус». Что же касается наставления для прикладных программистов, то, увы, пока что все сакральные знания хранятся только в головах сотрудников, занимающихся разработкой компилятора; иногда они делятся своими откровениями на лекциях в МФТИ, но для оформления конспектов в виде книги ещё не созрели. Тем временем в качестве отправной точки советуют почитать рекомендации для Itanium, — концептуально эта архитектура очень похожа на E2K.

    Вкратце основные приёмы можно сформулировать так.

    * Не мешать компилятору: уж если объявили функцию как встраиваемую (inline), то не забывайте включать её определение в каждый вызывающий модуль, — потому что вызов подпрограмм и возврат управления обратно являются весьма дорогими операциями на «Эльбрусе». Вообще, переход управления только тогда осуществляется почти безболезненно, когда подготовка к нему началась минимум за 4 такта заранее, поэтому, например, условные ветвления в простейших случаях автоматически заменяются на спекулятивные вычисления.

    * Помогать компилятору подсказками: помечать вероятные и редко используемые условные блоки макросами likely и unlikely, указывать ориентировочное количество итераций цикла в директиве pragma loop count, применять двухпроходную компиляцию с профилированием, когда характер нагрузки всегда однотипный.

    * Использовать семантически подходящие конструкции: компилятор скорее попытается оптимизировать цикл for, чем while, особенно если в нём замечен досрочный выход через break.

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

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

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

    * Существует ли готовый набор примеров исходного кода на языках C/C++ с ошибками обращения к памяти, чтобы продемонстрировать, как технология защищённого исполнения программ позволяет отлавливать такие ошибки на этапе компиляции и на этапе выполнения?

    Разумеется, такой набор программ есть — в составе средств регрессионного тестирования, которое проводится еженощно. Также можно использовать примеры из коллекции SAMATE американского института NIST. Однако для наглядности (по этой теме планируется написать отдельную статью), наверное, проще будет написать «однострочники», которые прицельно иллюстрируют каждую ошибку в отдельности.

    * Рассматривается ли возможность написания E2K-бэкэнда для компилятора LLVM в качестве альтернативы LCC, стремящегося походить на GCC?

    Изыскания в этом направлении проводились, естественно, однако вердикт пока был скорее отрицательным: архитектуру «Эльбрус-2000» сложно описать средствами LLVM оптимальным образом. То есть альтернативный компилятор можно было бы выпустить, но генерируемый им машинный код проигрывал бы LCC по скорости работы. Но направление не считают тупиковым, — возможно, что со временем бэкэнд к LLVM всё же будет реализован.

    * Может ли LCC выводить ошибки и предупреждения по форме, принятой у GCC, чтобы эти сообщения распознавались в среде разработки (например, Qt Creator) соответствующим образом?

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

    * Где можно получить набор средств кросс-компиляции программ для E2K из рабочей среды x86? Предусмотрен ли обратный процесс — генерирование x86-кода из среды «Эльбрус», и если да, то с помощью особой версии LCC, либо обычного GCC?

    Средства кросс-компиляции для E2K (то есть компилятор LCC, работающий на x86 Linux) предоставляются по запросу. Обратный процесс в явном виде не предусмотрен: если такое необходимо, можно запустить какую-нибудь x86-систему на «Эльбрусе» в режиме двоичной трансляции и использовать имеющийся там компилятор.

    * Какие технологии виртуализации поддерживаются на платформе «Эльбрус»?

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

    Кроме того, в этом году должны завершиться работы по созданию паравиртуализованного ядра операционной системы и механизма поддержки гипервизора KVM, а это — основной задел в архитектурно-зависимой части для развёртывания полноценной облачной инфраструктуры типа OpenStack. Тогда как прочие архитектуры при работе в среде Qemu/KVM опираются на полную виртуализацию аппаратуры, факультативно используя паравиртуальные драйверы virtio для ввода-вывода и перехват привилегированных инструкций при поддержке самого процессора, для «Эльбруса» дорабатывается архитектурно-зависимая часть KVM, чтобы обеспечить именно паравиртуальный режим работы, когда гостевая система тесно сотрудничает с гипервизором и вместо выполнения привилегированных инструкций вызывает функции hypercall API.

    * Хорошо известно, что Intel постоянно совершенствует свою архитектуру и улучшает микроархитектуру, повышая при этом производительность. Как развивается в этой части архитектура «Эльбрус»?

    Развитие движется в нескольких направлениях.

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

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

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

    • 1
      Нет аватара vladtsvs
      31.12.1600:48:04

      а вот способ кодирования инструкций в командном слове — закрытая информация по историческим причинам

      Ну все равно же среверсинжинерят как только (если) система поступит в открытую продажу. Смысл скрывать?

      • 0
        krotozer krotozer
        02.01.1702:56:37

        Оборонка. Так положено. И, да: так сложилось исторически. Рано или поздно, раскроют сами.

        Отредактировано: krotozer~03:56 02.01.17
        • 0
          Нет аватара vladtsvs
          02.01.1716:06:40

          Ну вот пока они повернуты к не-оборонке одним местом, не видать им успеха на гражданском рынке.

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

          Отредактировано: vladtsvs~17:11 02.01.17
          • 0
            krotozer krotozer
            03.01.1700:46:21

            Огромную кучу денег дайте, да перепишите правила безопасности для ВПК, тогда быстро повернутся к «не-оборонке». Если Вы заявите, что американцы быстро повернулись и бесплатно, я буду громко смеяться)

            • 0
              Нет аватара vladtsvs
              03.01.1716:48:20

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

              Американцы создали первый в мире однокристальный процессор (i4004) вообще для калькуляторов. Для того же создавался 8008. итд.

              Отредактировано: vladtsvs~18:20 03.01.17
    • 1
      Виктор Гюго Виктор Гюго
      02.01.1714:41:30

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

      Это ещё будем посмотреть. И да, в сообщество можно и нужно выходить даже с «неоптимальной скоростью работы».

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

      Развитие софта и подешевле развития железа и даёт возможность почувствовать улучшения владельцам железа без смены/докупки.

Написать комментарий
Отмена
Для комментирования вам необходимо зарегистрироваться и войти на сайт,