Пожалуй, главным результатом публикации этого обзора, — помимо собственно ознакомления общественности с первыми независимыми впечатлениями от нового компьютера, — стало желание самой фирмы МЦСТ раскрыть побольше подробностей, устранить возникшие недоразумения и ответить на вопросы, поднимаемые в статье и в комментариях к ней. Некоторые из этих вопросов настолько фундаментальны, что заслуживают по отдельной статье каждый, и потому требуют серьёзной проработки. Сейчас же мы рассмотрим те из них, которые лучше всего укладываются в формат интервью.
Содержание
- Общие моменты
- Производство и продвижение
- Поддержка пользователей
- Аппаратное обеспечение
- Операционная система
- Прикладное программное обеспечение
- Архитектура и средства разработки
- Двоичная трансляция x86-кода
- Измерение производительности
Общие моменты
Чтобы правильно понимать позицию фирмы МЦСТ по нижеизложенным воспросам, необходимо представлять себе её прошлое, настоящее и планы на будущее, — в отрыве от этого контекста некоторые факты могут выглядеть странно.
Исторически, основными заказчиками и потребителями продукции МЦСТ были силовые структуры. Ассортимент и объёмы производства были ограниченными, каждый компьютер был на учёте, каждого покупателя знали в лицо, образно говоря. При такой модели сбыта было необходимым и достаточным выпускать в оборот только хорошо отлаженные и сертифицированные системы, под которые прицельно затачивалось прикладное программное обеспечение. Каждый клиент требовал персонального подхода — квалифицированных консультаций при выборе оборудования и его последующей эксплуатации, в том числе с выездом сервисного инженера на место установки (в любую точку необъятной части суши, а также на море). То есть «махровый энтерпрайз», разве что со своей спецификой.
Сейчас МЦСТ очень хочет выйти на гражданский рынок — сначала в корпоративный сектор, который всё-таки ближе к текущему опыту, а затем и в потребительский сегмент, то есть к самым широким массам. Понятное дело, что если бизнес-клиенты ещё хоть как-то готовы нести дополнительные траты (но не такие, конечно, какие готовы нести традиционные заказчики МЦСТ), особенно когда ясны преимущества выбора в пользу дорогого эксклюзива, то рядовой человек голосует кошельком за самые доступные товары, соглашаясь на менее высокое качество продукции и порой полное отсутствие поддержки со стороны производителя. А ещё простые люди жаждут всего нового — подавай им удвоение количества транзисторов каждые полтора года, самую свежую версию ядра, системных библиотек и прикладных программ; и не столь важно, сколько там было устранено старых ошибок и сколько появилось новых, как сильно потяжелел софт и как он теперь тормозит на машинах предыдущего поколения.
Очевидный разрыв между желаемым и действительным прекрасно понимают в МЦСТ на всех уровнях, — ни у кого нет радужных иллюзий, что можно в один момент сорваться с места в карьер, обгоняя маститых спринтеров и бывалых марафонцев, тем более что с такими соперниками необходимо, как в известной сказке, нестись со всех ног, просто чтобы остаться на месте. Сейчас на такой рывок нет ни денег, ни производственных мощностей, ни, элементарно, кадровых ресурсов, — штат сотрудников на три порядка меньше, чем у Intel или Microsoft, а заниматься приходится всем сразу. Даже чтобы охватить коммерческие или бюджетные структуры, необходимо сначала развернуть сеть дилерских центров и ремонтных мастерских, наладить систему обучения и технической поддержки, — сейчас МЦСТ только прощупывает почву в поисках партнёров. Ну и, конечно, необходимы финансовые инвестиции: чтобы иметь возможность продавать свои компьютеры недорого, требуется снизить себестоимость производства, а это достижимо только при значительном увеличении объёмов, — получается замкнутый круг, разорвать который очень непросто.
Также присутствует понимание того, что продукция широкого потребления обязана быть настолько открытой, настолько это возможно и целесообразно: например, что в свободном доступе должна присутствовать документация, установочные дистрибутивы программного обеспечения и своевременно выпускаемые обновления для него, исходные коды этих программ, что необходима площадка для публичных консультаций и обмена опытом, учебная литература для начинающих и специалистов. Но это тоже всё не появляется само собой в одночасье, а компания пока находится в самом начале пути по завоеванию сердец и умов потенциальной клиентуры.
Поскольку отказаться от старых привычек сложно, особенно когда ещё нет практики ведения дел в совершенно иной среде, необходимо делать скидку на то, что, когда сотрудники компании отвечают на вопросы далее по тексту, то, говоря «пользователь», они зачастую всё ещё имеют в виду своего классического клиента, с которым имеется персональный контакт и прямой контракт, а зачастую ещё и дополнительное соглашение о неразглашении, — такой клиент сам не заинтересован в публичности и знает, что может рассчитывать на любой каприз за свои деньги. Но, как можно видеть по многим ответам, этот шаблон уже не рассматривается в качестве единственного. Тут тоже всё будет развиваться постепенно, шаг за шагом.
Производство и продвижение
На каком заводе производят ЦП и КПИ? В каких объёмах? Правда ли, что производство свёрнуто (приостановлено) на два года?
Секрета здесь нет: новые микросхемы сейчас производятся только в Азии. И если ставить целью всерьёз конкурировать на свободном рынке, никакой альтернативы этому пока нет. Другое дело, что тогда возникает естественный вопрос информационной безопасности в критических применениях, но для особой категории заказчиков возможно организовать производство на местных мощностях ограниченными партиями — с соответствующим уровнем цен. Первый (и успешный) проект такого рода — процессор «Эльбрус-2СМ»: его кристаллы производятся на зеленоградской фабрике «Микрон».
Выпуск микросхем не останавливается — более того, в них постоянно вносятся корректировки. Просто, по современным меркам, объёмы менее тысячи кристаллов в год считаются мелкосерийным производством, и заказ делается лишь эпизодически, круглосуточный конвейер тут не нужен.
Много процессоров на данном этапе идёт на внутренние нужды, — как обыденные, так и экспериментальные. Например, недавно был собран вычислительный комплекс из 32 модулей 1U по четыре процессора «Эльбрус-4С» в каждом — итого 512 ядер. Каждый, у кого есть интересные задачи для такой системы, может обратиться с заявкой на машинное время. (Кратко о том, какие классы программ наиболее эффективно выполняются на архитектуре E2K, и как оптимизировать свой исходный код, будет рассказано ниже, а подробнее эту тему планируется осветить в отдельной публикации.)
При каких объёмах производства удастся снизить стоимость комплекта «материнская плата + процессор» до приемлемого для широкого круга покупателей уровня? Как скоро российская электронная промышленность будет способна обеспечить такие объёмы?
Чтобы выйти на уровень около 1000 долларов, необходимо выпускать как минимум 10 тысяч готовых изделий ежегодно, а двигаться ещё дальше навстречу покупателю можно только при потоке порядка 100 тысяч изделий в год. Разумеется, всё производство тогда должно быть сосредоточено в Китае, либо отечественные фабрики должны очень хорошо поработать над удешевлением логистики и снижением себестоимости производства. Сейчас все платы производства МЦСТ монтируются на российских заводах.
При каких объёмах производства будет оправдан выпуск упрощённой версии процессора для 1-сокетных систем — без блоков межпроцессорного взаимодействия и доступа к удалённой памяти?
Даже 10 тысяч кристаллов в год не оправдают изменение топологии. Скорее будет иметь смысл избавиться от незадействованных выводов, что позволит сократить площадь подложки, но в обозримой перспективе даже это не будет себя оправдывать.
Сколько будет стоить лицензия на операционную систему, если начнутся продажи комплектующих по отдельности?
Пока что такая схема продаж не обкатана, но скорее всего будет перенят опыт коллег из «Альт Линукс», — для персонального использования цена точно не станет обременительной.
Когда ожидать готовые системы на базе «Эльбрус-8С»? Определены ли характеристики будущих процессоров? Будет ли в следующей модели 16 ядер и тактовая частота 2 ГГц, к примеру?
Предсерийные образцы однопроцессорных машин на базе «восьмёрки» можно будет увидеть уже этим летом. Следующий шаг — небольшое увеличение частоты (до 1,5 Гц) и удвоение количества вычислительных блоков с плавающей запятой, которые являются основной движущей силой этой платформы — такой процессор уже разрабатыается с рабочим названием «Эльбрус-8СВ». Процессор с 16 ядрами планируется выпустить в 2020 году.
Почему система именования аппаратных и программных средств такая запутанная?
Когда в вашем активе всего пара-тройка базовых продуктов, то разобраться в номенклатуре не составляет труда, особенно профессионалу. Сейчас, когда спектр железа и софта расширяется, когда происходит ориентация на рядового пользователя, система именований постепенно приводится к виду, понятному для неспециалиста.
Важное уточнение. Упоминать обозначение «Эльбрус-2000», равно как и аббревиатуру «E2K», в контексте современных продуктов — неправильно: официальным названием этой микропроцессорной архитектуры является «Эльбрус», без всяких суффиксов. Название «Эльбрус-2000» было выбрано для архитектуры, которую собирались реализовывать совместно с западными компаниями в 2000 г. В самом начале 1999 г. в журнале Microprocessor Report была напечатана статья с описанием архитектуры микропроцессора «Эльбрус-2000», которая на английском языке выглядела как «Elbrus-2000», а в сокращенном виде — «E2k». Нынешняя архитектура «Эльбрус» существенно доработана по отношению к той архитектуре E2k, — это уже третья версия, — поэтому использование старого обозначения не вполне корректно. Кроме того, аббревиатура E2K (с заглавной буквой «K») может трактоваться ортодоксальными компьютерщиками как 2048, что совсем уж никуда не годится.
Поддержка пользователей
Имеется ли документация в электронном виде? Планируется ли выкладывать документацию в общий доступ для свободного скачивания любым желающим (безотносительно факта покупки оборудования)?
Документацию можно скачать уже сейчас, но пока только имея ссылку, высылаемую по запросу. Однако уже в ближайшие месяцы планируется запустить сайт сообщества и технической поддержки, где вся информация будет лежать в открытом доступе. Так как речь идёт о десятках документов, это займёт какое-то время.
Планируется ли открывать багзиллу для публичного просмотра? Создавать FAQ, организовывать форум — сайт для открытого обмена опытом?
Нельзя просто взять и открыть багзиллу, где многие тикеты содержат «высоко чувствительные» сведения. Скорее всего, для широких масс будет создана отдельная багзилла, доступная для просмотра и пополнения всеми желающими. А ранее накопленный опыт по наиболее часто задаваемым вопросам будет переработан в FAQ, который также будет выложен на новом сайте поддержки. Там же будет и форум, скорее всего.
Что насчёт публикации исходных кодов адаптированного программного обеспечения и отправки патчей в апстрим того или иного проекта? Планируется ли принимать патчи от пользователей? Как насчёт поощрений за найденные уязвимости?
Исходные коды не выкладывались в публичный доступ просто потому, что сами клиенты были не публичными, и спрос среди них на исходные коды был небольшим, а кому было действительно нужно не из праздного любопытства — обращался с запросом и получал всё что надо в частном порядке. Планируется, что для массового потребителя в обозримом будущем будет создан публичный репозиторий, куда попадёт весь заимствованный код. Открывать свои собственные разработки, такие как компилятор LCC, фирма не планирует, — в конце концов, Intel C++ Compiler (а именно его МЦСТ считает своим главным соперником с точки зрения оптимизаций) тоже закрытый, и хорошо при этом себя чувствует.
Патчи от пользователей и так принимаются, — пока что тоже в частном порядке, конечно же. Как это будет выглядеть при расширении клиентской базы и всплеске внимания со стороны энтузиастов, пока представить трудно.
Отправка своих изменений авторам оригинальных проектов — несомненно полезное дело, но этим кто-то должен заниматься, к каждому проекту нужно знать подход, разбираться в особенностях культуры сообщества. Более посильной задачей представляется просто выкладывать весь код в общий доступ: если найдётся «посол доброй воли», готовый взаимодействовать с тем или иным апстримом, — что ж, замечательно. Пока что у МЦСТ такого опыта нет.
Аппаратное обеспечение
Как встроенный видеоадаптер задействовать в графическом окружении? Насколько комфортным для 2D-работы предполагается его быстродействие?
Инициировать перенастройку графического стола проще всего было бы, запустив утилиту xorg-server.postinst. Функции аппаратного 3D-ускорения у встроенного адаптера отсутствуют напрочь, а вот обычное использование приложений рабочего стола не должно вызывать никаких неудобств, — уж точно не так, как было на старых компьютерах. Наверное, надо будет записать это на видео и выложить небольшой ролик — вместо тысячи слов.
Какие дискретные видеокарты, помимо Radeon HD 6450 / R5 230, поддерживаются операционной системой? Какие функции аппаратного ускорения доступны прикладным программам через имеющийся в системе драйвер?
Поддерживается вся современная линейка Radeon, совместимая с открытым драйвером для Linux. Поскольку у nVidia в этом плане всё очень печально, их продукция не имеет поддержки в операционной системе «Эльбрус» на данный момент.
Чем можно объяснить аномально низкие показатели скорости чтения и записи твердотельного накопителя, не дотягивающие даже до номинальной полосы пропускания интерфейса SATA-2, через который он подключён?
Это известное ограничение микросхемы 1991ВГ1Я, реализующей контроллер периферийных интерфейсов (КПИ). Оптимизированный вариант контроллера (КПИ-2), в котором эта проблема решена, будет устанавливаться в системы с новыми процессорами «Эльбрус-8С» и «Эльбрус-1С+».
Зачем в составе компьютера «Эльбрус 401‑PC» имеется жёсткий диск объёмом 1 Тбайт, если он даже не настроен в операционной системе, а основной накопитель и так предоставляет немало свободного пространства?
Очевидное предназначение жёсткого диска — хранение больших объёмов данных, что востребовано текущим контингентом пользователей. То, что диск не смонтирован в системе — недоработка, но не существенная: некоторые пользователи ещё и флэш-карту переформатируют под свои нужды вместо двоичной трансляции, тут всем сразу не угодишь.
Для чего служит окраска винтового крепления твердотельного накопителя, — в качестве гарантийной пломбы или для предотвращения самооткручивания?
Действительно, краска является в первую очередь стопором. Накопитель откручивать можно — гарантии это не лишает, но если что-то сломается, то у сервисных инженеров возникнут естественные вопросы к пользователю касательно произведённых действий.
Откуда берутся идентификаторы PCI-устройств, — почему код разработчика (Vendor ID) у многих набортных устройств такой же, как у Intel?
Причина совершенно прозаическая — так операционной системе Windows в режиме двоичной трансляции проще почувствовать себя как дома. Правда, из-за своей параноидальной привязки кодов активации к используемой аппаратуре, эта «самая дружелюбная» система всё равно иногда начинает капризничать.
Где можно ознакомиться с описанием аппаратно-программного модуля доверенной загрузки «Эшелон‑Э»?
Тут имеет место недоразумение: этот продукт — чисто программный, и является лишь частным случаем обычного МДЗ «Эшелон», разработанного одноимённым научно-производственным объединением. Это средство обеспечивает доверенную загрузку компьютера, контроль целостности, идентификацию и аутентификацию пользователя до передачи управления операционной системе.
Является ли модуль удалённого управления по IPMI, предлагаемый как опция для серверов «Эльбрус-4.4», самостоятельной разработкой, или это готовый продукт иностранного производства?
Разумеется, это самостоятельная разработка, но пока ещё не готовый продукт, — модуль находится на этапе отладки.
Операционная система
Какая система обозначения версий используется для ОС «Эльбрус»?
Правильный ответ уже приводился в статье: номер версии записан в файле /etc/mcst_version. Та версия 2.2, которой комплектовались компьютеры из первой партии, на самом деле уже не актуальна — стабильной сейчас является 2.3, а на стадии релиз-кандидата находится 3.0 (с ядром 3.14).
Планируется ли выпускать регулярные обновления, которые бы устанавливались автоматически из публичного репозитория? Почему не всё программное обеспечение, установленное в системе, оформлено в виде пакетов?
Да, автоматическое обновление планируется, хотя сейчас этот процесс происходит ещё вручную по запросу. Разумеется, для этого всё программное обеспечение должно находиться под управлением менеджера пакетов, — если сейчас где-то не так, то только вследствие неотлаженности процесса сборки.
Не проще ли напрямую портировать однин из популярных Linux-дистрибутивов — например, тот же Debian?
Именно этим в данный момент и занимается одна из команд. Действительно, Debian предлагает, пожалуй, наиболее удобную инфраструктуру для создания производных дистрибутивов. Более того, у Debian сейчас самый широкий набор поддерживаемых архитектур, во всяком случае среди семейства Linux, так что создавать новые порты логичнее всего на этой базе. Однако именно процедура портирования у данного дистрибутива — не самая гладкая и систематизированная, поэтому приходится изрядно потрудиться. Зато, когда процесс будет отлажен и автоматизирован, синхронизация с мейнлайном станет [почти] незамедлительной. А вот удастся ли придать этому порту статус официального — большой вопрос.
Но перечень поддерживаемых операционных систем не планируется ограничить лишь каким-то одним вариантом. Первым делом ожидается порт ALT Linux, который в представлении не нуждается. Также ведутся работы по адаптации QNX: защищённая операционная система реального времени «Нейтрино-Эльбрус» в каком-то виде уже работает; подробности уточняйте у разработчиков в центре компетенции «СВД Встраиваемые Системы».
Насколько трудоёмко портирование ядра Linux? Почему сейчас используется ядро версии 2.6.33 — не самое новое, но и в то же время не поддерживаемое как LTS?
Процесс портирования ядра Linux на ту или иную аппаратную платформу в самом деле довольно трудозатраный, но проблема не в однократных усилиях, а в том, что каждый раз очень многое приходится начинать почти с начала, так как всё течёт, меняется и перетасовывается. Например, только-только перебрались на ядро 3.14 и начали экспериментировать с веткой 4.x — а там опять всё поменялось.
Вряд ли в обозримом будущем получится добиться принятия своего порта в мейнлайн kernel.org, когда там всё очень строго с одной стороны и довольно хаотично с другой. Поэтому наиболее вероятной перспективой видится предоставление своего ядра всем желающим для самостоятельной сборки такого дистрибутива, какой они сами захотят смастерить.
Какие версии ядра (default, nn, rt) для каких целей лучше использовать?
Для повседневных задач, очевидно, лучше всего подходит ядро по умолчанию. Ядро «nn» предназначено для сетевых маршрутизаторов — там удешевлена обработка прерываний. Ядро «rt» умеет планировать работу процессов, соблюдая ограничения по выделенным квантам времени в установленных пределах, что позволяет говорить о вычислениях в реальном времени, — не значит «быстро», но значит «предсказуемо», пусть и ценой потери производительности; при этом в системе обычно остаётся работать только ядро и целевое приложение, а также минимально необходимый набор фоновых служб.
Возможен ли быстрый перезапуск [ядра] операционной системы без повторной инициализации оборудования? Как ускорить запуск операционной системы в частности и компьютера вообще?
Быстрый перезапуск операционной системы без инициализации оборудования не предусмотрен. Ускорить инициализацию оборудования можно, во-первых, очевидными способами: например, отключив или уменьшив тайм-аут поиска серверов ATA over Ethernet, — они нужны только для загрузки по сети. Во-вторых, есть и неочевидные на первый взгляд способы: например, можно отключить очистку оперативной памяти, которая обычно выполняется в целях информационной безопасности. Ну, а ускорение запуска операционной системы путём отключения всех ненужных служб — в комментариях не нуждается.
Прикладное программное обеспечение
Для каких целей позиционируется имеющаяся сейчас версия Firefox 3.6, если с ней не совместимы многие сайты, использующие современные веб-технологии?
Актуальной версией браузера в текущем релизе операционной системы «Эльбрус» является 23.0, которая гораздо совершеннее в функциональном плане и в плане производительности. Например, тест JetStream теперь уже успешно завершается, причём со счётом 7,8 балла — не намного ниже отметки 8,2 балла, достигаемой той же версией Firefox в режиме двоичной трансляции x86, где задействован полноценный JIT-компилятор для JavaScript.
Также обкатывалась версия 31.0, но она проявила себя хуже, медленнее, и её решили не выпускать на публику. Следующей перенесённой версией будет 44.0.
Имеется ли в системе реализация отечественных криптографических алгоритмов (в том числе актуальных версий), доступная для программ на языках C/C++?
Сейчас на смену OpenSSL пришло его ответвление — LibreSSL, куда российская криптография интегрирована официально.
Чем можно объяснить низкую производительность виртуальной машины Java, продемонстрированную в различных тестах?
Пакет OpenJDK 1.6.0 был в каком-то смысле «пробой пера» — сейчас уже кипит работа над 1.7.0 и 1.8.0, где производительность удалось поднять в 3–4 раза, если судить по таким тестам, как SPECjvm2008. Но в общем случае, конечно, придётся ещё много чего оптимизировать.
Планируется ли портирование Mono или .NET в рамках ОС «Эльбрус» или иного дистрибутива?
Учитывая популярность данной технологии, это практически неизбежно. Но, принимая во внимание происходящие в данный момент перемены в отношениях Microsoft с сообществом и неопределённое будущее проекта Mono, естественным образом возникает желание чуть-чуть подождать, когда перспективы станут более чёткими, чтобы не тратить время на тупиковые ветви развития.
Пока же, если кому-то необходимо запускать дотнетовские приложения, он может воспользоваться режимом x86-трансляции. Собственно, это одно из основных назначений технологии трансляции — обеспечить совместимость на переходный период, пока программная база ещё не стала нативной. Кстати, сейчас команда МЦСТ активно работает над повышением эффективности трансляции приложений, использующих подобные just-in-time компиляторы.
Каковы перспективы у «Эльбруса» в качестве игровой платформы, учитывая, что в современных играх почти вся нагрузка ложится на видеокарту, и мощный процессор зачастую не нужен?
Этим вопросом всерьёз ещё никто не задавался. Пока что, если только игра не доступна в исходных кодах и не является по-настоящему переносимой, то единственным выходом будет запуск Windows или Steam OS в режиме двоичной трансляции, но возможны проблемы с активацией лицензий из-за особенностей привязки к оборудованию.
Архитектура и средства разработки
Где и как можно получить подробное справочное руководство по архитектуре и набору машинных инструкций?
Сейчас вся документация высылается по запросу. Но есть нюанс: набор инструкций является открытым, а вот способ кодирования инструкций в командном слове — закрытая информация по историческим причинам. Вопрос полного раскрытия архитектурных деталей неоднократно пробовали решить положительно, но пока решение не принято.
Впрочем, серьёзной практической проблемы это не представляет, так как, по мнению МЦСТ, информации в имеющейся документации достаточно даже для низкоуровневого программирования через «интринсики», а генерировать машинный код своими силами или даже писать на 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-й версии), совершенствования иерархии подсистемы памяти. При этом сохраняется совместимость с предыдущими версиями архитектуры.
- Второе направление — это совершенствование микропроцессора как системы на кристалле. По мере освоения более тонких нанометровых технологий в микропроцессорах возрастает число процессорных ядер, увеличивается число каналов доступа в память для сохранения сбалансированности микропроцессора, в отдельных случаях добавляются специализированные графические ядра и дополнительные контроллеры взаимодействия с периферийными устройствами.
Наконец, значительную роль играет совершенствование оптимизирующего компилятора, с помощью которого удаётся извлекать параллелизм программ и трансформировать код в параллельные возможности архитектуры, — как уже неоднократно подчёркивалось, компилятор фактически является частью архитектуры. Резерв способностей компилятора ещё далеко не исчерпан, МЦСТ здесь видит очень широкое поле для приложения усилий.
Двоичная трансляция x86-кода
Какие возможности и ограничения имеет двоичная трансляция?
Эта тема заслуживает рассмотрения в отдельной статье, но вкратце картина складывается следующая. Трансляция бывает двух видов — на уровне системы и на уровне приложения. В первом случае для гостевой операционной системы обеспечивается доступ ко всему аппаратному окружению компьютера, а во втором, соответственно, только выполняется передача системных вызовов из гостевой программы в ядро хозяйской системы Linux. Это можно сравнить с эмуляторами qemu-system-x86_64 и qemu-i386 соответственно, однако транслятор не занимается эмуляцией гостевого процессора, а сразу перекомпилирует гостевой машинный код в нативные инструкции своей архитектуры. Причём преобразование выполняется многократно, постепенно увеличивая степень оптимизации для наиболее часто встречающихся участков кода, а результаты сохраняются в долговременный кэш.
Транслятор уровня системы (неофициально он называется «lintel» — «эль-интел») поддерживает наборы команд x86 и x86-64, а транслятор уровня приложений («rtc», то есть run time compiler) пока совместим только с 32-битным программами, — 64-битная версия находится в стадии тестирования. Однако совместимость с архитектурой AMD64 / EM64T не означает автоматической поддержки всех новых наборов инструкций, которые можно встретить в тех или иных процессорах Intel / AMD, как то последние версии SSE, AVX, AES-NI, — соответствующие флаги в информации CPUID будут отсутствовать.
Как воспользоваться транслятором уровня системы?
Очень просто: при запуске компьютера надо указать флэш-карту в качестве загрузочного диска. Если карта оказалась пуста, либо пользователь сам стёр оттуда систему трансляции, то записать её повторно можно в любой момент, выполнив копирование образа командой dd.
Транслятор уровня системы имеет BIOS оригинальной разработки, и после запуска на экране возникает привычная всем POST-последовательность, в ходе которой можно зайти в меню настроек. Большинство этих настроек — самые обыкновенные, но есть и специфические. Например, можно очень гибко управлять идентификацией процессора по CPUID, меняя не только номер семейства и модели или отдельные флаги способностей, но и текстовое название, — это необходимо для противодействия анти-конкурентному поведению программ, собранных при помощи Intel C++ Compiler. Другая специфическая опция — прозрачное превращение SATA-контроллера в PATA, чтобы обеспечить совместимость с более широким кругом операционных систем. Но, несмотря на наличие таких «волшебных палочек», работа операционных систем, установка которых производилась на настоящей x86-машине, не гарантируется, — особенно это касается Windows с её привязкой лицензии к оборудованию и трепетным отношением к драйверу системного диска.
Как воспользоваться транслятором уровня приложений?
Ещё проще: запустив программу трансляции, передав ей путь к гостевому приложению и путь к корневому каталогу воссоздаваемого окружения. Весь вопрос в том, как сперва получить образ этого окружения. Пока что штатно поставляется только окружение x86-версии системы «Эльбрус», однако допускается использование и других. Если клиент затрудняется сформировать образ нужной системы самостоятельно, специалисты МЦСТ могут оказать необходимую помощь.
Из-под запущенного гостевого приложения (например, коммандного интерпретатора) пользователь может осуществлять запуск прочих гостевых программ — совершенно прозрачно. В один момент времени может быть запущено сразу несколько экземпляров транслятора, и каждый экземпляр может работать в своём собственном окружении; поэтому, например, можно опробовать одну и ту же версию браузера в разных дистрибутивах, или, наоборот, разные версии браузера в одной системе (пример надуманный, конечно, но суть раскрывает).
Можно встретить утверждение, что в режиме двоичной трансляции некоторые бенчмарки начинают работать даже быстрее, чем изначально собранные для E2K. Для каких классов программ и при каких условиях такое возможно?
Такое действительно возможно, например, когда нативная версия JVM или JS-движка умеет только интерпретировать пользовательский код, а сравниваемая с ней x86-версия располагает полноценным JIT-компилятором. При этом, даже не смотря на то, что имеет место многократная трансляция, — сначала выбранный для оптимизации байт-код компилируется в машинный язык x86, затем ещё через какое-то время он перекомпилируется в E2K (причём трижды, по одному разу на каждый уровень оптимизации), — всё равно итоговый выигрыш от компиляции перевешивает.
Что касается нативных программ на языках C/C++, то здесь тоже существует логическое объяснение, даже целых два. Во-первых, хоть компилятор LCC и проделывает титаническую работу по оптимизации генерируемого кода, никто не гарантирует, что какой-нибудь компилятор для x86, особенно коммерческий, не справится лучше в том или ином частном случае. Во-вторых, более вероятно, что хорошо оптимизированная программа для x86 попросту была собрана с учётом предварительного профилирования, тогда как компилятору LCC скормили голые исходники без подсказок. Но при прочих равных, конечно, нативные программы должны работать как минимум не медленнее транслируемых, — если это не так, надо отправлять баг-репорт разработчикам LCC.
Измерение производительности
По мнению специалистов МЦСТ, некоторые популярные ранее бенчмарки не могут по-настоящему раскрыть потенциал ни одной из существующих ныне платформ. Взять тот же UnixBench — при всём уважении к его почтенному возрасту, он давно устарел и одинаково не годится для любых современных процессоров и операционных систем. Оба его процессоро-зависимых теста, Whetstone и Dhrystone, практически не распараллеливаются и не подлежат хоть сколь-нибудь существенному внеочередному выполнению — хоть на архитектурах с явным параллелизмом, хоть с неявным. А остальные тесты вообще «ни о чём», вместо них лучше использовать что-то более специфическое. Единственное достоинство UnixBench — кросс-платформенность, потому его и используют до сих пор.
Не стоит также упускать из виду могучую силу профилирования. Например, показавшиеся многим подозрительно высокими результаты теста 7-Zip в обзоре CNews — это не обман, а следствие двухпроходной компиляции. Другой вопрос, насколько такая оптимизация полезна в общем случае, то есть на произвольных входных данных. По этой причине вряд ли имеет смысл профилировать все компоненты теста Pgbench, — ведь на реальных данных производительность Postgresql может оказаться совсем иной. Но в случае конкретно с 7-Zip перепроверить довольно легко: надо провести ещё один тест, подав на вход коллекцию разнообразных файлов. Проблема только в том, что если файлы не стандартизированы, то повторить тест идентичным образом у любого желающего не получится, и доверия к опубликованным результатам будет ещё меньше.
Следует отдавать себе отчёт, что синтетические бенчмарки нередко пишутся с прицелом на определённую архитектуру (в том числе потому что их авторы привыкли так мыслить), либо подгоняются под определённое сочетание аппаратуры и компилятора. Например, известный тест SPECcpu декларирует объективность и непредвзятость, однако в исходных кодах версии 2006 можно встретить комментарии, что тот или иной костыль добавлен специально для Intel C++ Compiler. Да и как тут не заподозрить влияние крупного вендора, когда из 36,6 тысяч опубликованных результатов на долю его продукции приходится 90 % записей?
Реальные прикладные программы — тоже не всегда показатель, потому что наиболее критичные участки могут быть либо полностью написаны на ассемблере x86, либо содержать много ассемблерных вставок и обращений к особым функциям (интринсикам), чему OpenSSL наглядный пример. Получается, что вылизанный до блеска машинный код сравнивается с реализацией на языке высокого уровня, основное предназначение которой — быть эталонной, а не оптимальной.
Поэтому предложение к читателям: давайте вместе подумаем, какие тесты — искусственные или приближенные к жизни — можно провести, чтобы увидеть, насколько «Эльбрус» силён в релевантных для него задачах. Не обязательно, чтобы это были готовые программы, особенно что касается математических вычислений, ведь, скажем, умножение матриц — оно и в Африке умножение матриц: сложность задачи одинакова, выполняется ли она оптимизированными библиотеками EML, BLAS / LAPACK или самописной функцией. Свои идеи оставляйте в комментариях.
Автор выражает признательность сотрудникам МЦСТ за подробные и интересные разъяснения.
Автор: Agat-Aquarius
