«Эльбрус» на Альте (Михаил Шигорин, OSSDEVCONF-2017) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) |
StasFomin (обсуждение | вклад) (Batch edit: replace PCRE (\n\n)+(\n) with \2) |
||
(не показано 36 промежуточных версий этого же участника) | |||
;{{SpeakerInfo}}: {{Speaker|Михаил Шигорин}} <blockquote> В докладе рассматривается интеграция поддержки архитектуры «Эльбрус-2000» в репозиторий проекта Сизиф, её основные этапы, задачи и текущее состояние, а также особенности архитектуры и её сравнительные возможности. </blockquote> {{VideoSection}} {{vimeoembed|235962157|800|450}} <!-- {{youtubelink|}} --> |Ky_MShm_qVc}}{{letscomment}} {{SlidesSection}} [[File:«Эльбрус» на Альте (Михаил Шигорин, OSSDEVCONF-2017).pdf|left|page=-|300px]] {{----}} == Thesis == === Состояние: 2017 === В докладе 2016 года речь шла о текущем результате в виде полутысячи альтовских пакетов, собранных нативно на рабочей станции «Эльбрус-401» в чруте под управлением ОС Эльбрус; за год произошли существенные сдвиги, позволившие задуматься над добавлением поддержки архитектуры e2k в нашу сборочницу: * «Эльбрус-401» с весны 2017 года загружен под альтом; * объём репозитория перевалил за 2500 пакетов; * собраны многие ключевые библиотеки; * введён в эксплуатацию сервер «Эльбрус-4.4». Среди заметных результатов — важные для возможности сборки целых сегментов Sisyphus библиотеки Boost и Qt5. В чисто прикладном плане за это время была обеспечена возможность применения «Эльбрус-401» под управлением ОС Альт в качестве базовой рабочей станции (несколько графических сред, включая Xfce, LXQt, MATE; браузер Firefox~ESR; разнообразные утилиты), а также развита серверная часть вплоть до поддержки функционирования в качестве контроллера домена Active Directory. === Задачи === Обозримая часть маршрута выглядит так: * базовая сборочная среда; * наработка репозитория; * развёртывание транзакционной сборочницы; * перевод в режим «догоняющей» сборки; * публикация репозитория. На сегодня мы дошли до пробного развёртывания girar-builder (системы, обеспечивающей возможность транзакционного изменения репозитория по мере новых сборок пакетов), но упёрлись в необходимость выставления существенного количества «ручек» --without/--disable, отключающих недоступную сейчас функциональность (например, сборку с ещё не собранными библиотеками). Для полноценного добавления поддержки архитектуры, тем не менее, остаётся нерешённым ряд задач технического плана. Среди них наведение порядка В силу выбранного типа архитектуры (VLIW с явным параллелизмом) характерна сравнительно невысокая скорость работы компилятора, усугубляющаяся тем, что оптимизация оптимизирующего компилятора для работы на таких платформах особенно сложна; при этом практического быстродействия достаточно для пересборки за сутки более чем 1600 пакетов на шестнадцати процессорных ядрах. По части аппаратного обеспечения (используются системы на базе микропроцессора «Эльбрус-4С») можно выделить такие особенности: * невысокая скорость работы относительно текущих x86; * хорошая перегрузочная способность (меньше «проседает»); * хорошая масштабируемость многопроцессорной системы; * поддержка больших объёмов памяти. В частности, время сборки больших проектов (ядро Linux, браузер Firefox) на четырёхпроцессорной машине уменьшалось практически линейно по сравнению с однопроцессорной. Значительный объём ОЗУ — 24 Гб штатно на рабочей станции, 96 Гб на сервере -- сильно облегчает параллельную сборку и сборку крупных пакетов, не вызывая подкачки страниц памяти с диска (на ARMv7 и~MIPS с этим было куда сложней, что лишь усугубляло недостаток производительности процессора). При этом надо понимать, что потенциальная пропускная способность интерфейсов DDR3 и~SATA2 на 4С задействована не в полной мере. Стоит отметить, что итоговая производительность системы на VLIW-архитектуре сильно зависит от того, насколько удалось реализовать параллелизм выполнения кода при его компиляции; поэтому на одном и том же ПК «Эльбрус-401» система может напоминать как Pentium~III, так и Core2 по производительности в зависимости от версии компилятора и переданных ему опций. Разумеется, порой решающее значение имеют всё-таки ручные правки кода, которые мы всё так же получаем от коллег из МЦСТ. ;Ссылки: # http://altlinux.org/ports/e2k # http://0x1.tv/20170128J # http://lvee.org/ru/abstracts/251 # http://sdelanounas.ru/blogs/96816 # http://mcst.ru {{LinksSection}} <!-- <blockquote>[©]</blockquote> --> {{fblink|1951696401750038}} {{vklink|754}} <references/> [[File:{{#setmainimage:«Эльбрус» на Альте (Михаил Шигорин, OSSDEVCONF-2017)!.jpg}}|center|640px]] {{stats|disqus_comments=3|refresh_time=2021-08-31T16:44:32.013225|vimeo_comments=0|vimeo_plays=106|youtube_comments=3|youtube_plays=884}} [[Категория:OSSDEVCONF-2017]] [[Категория:ALTLinux на Эльбрусе]] |
Текущая версия на 12:20, 4 сентября 2021
- Докладчик
- Михаил Шигорин
В докладе рассматривается интеграция поддержки архитектуры «Эльбрус-2000» в репозиторий проекта Сизиф, её основные этапы, задачи и текущее состояние, а также особенности архитектуры и её сравнительные возможности.
Содержание
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Презентация
Thesis
Состояние: 2017
В докладе 2016 года речь шла о текущем результате в виде полутысячи альтовских пакетов, собранных нативно на рабочей станции «Эльбрус-401» в чруте под управлением ОС Эльбрус; за год произошли существенные сдвиги, позволившие задуматься над добавлением поддержки архитектуры e2k в нашу сборочницу:
- «Эльбрус-401» с весны 2017 года загружен под альтом;
- объём репозитория перевалил за 2500 пакетов;
- собраны многие ключевые библиотеки;
- введён в эксплуатацию сервер «Эльбрус-4.4».
Среди заметных результатов — важные для возможности сборки целых сегментов Sisyphus библиотеки Boost и Qt5.
В чисто прикладном плане за это время была обеспечена возможность применения «Эльбрус-401» под управлением ОС Альт в качестве базовой рабочей станции (несколько графических сред, включая Xfce, LXQt, MATE; браузер Firefox~ESR; разнообразные утилиты), а также развита серверная часть вплоть до поддержки функционирования в качестве контроллера домена Active Directory.
Задачи
Обозримая часть маршрута выглядит так:
- базовая сборочная среда;
- наработка репозитория;
- развёртывание транзакционной сборочницы;
- перевод в режим «догоняющей» сборки;
- публикация репозитория.
На сегодня мы дошли до пробного развёртывания girar-builder (системы, обеспечивающей возможность транзакционного изменения репозитория по мере новых сборок пакетов), но упёрлись в необходимость выставления существенного количества «ручек» --without/--disable, отключающих недоступную сейчас функциональность (например, сборку с ещё не собранными библиотеками).
Для полноценного добавления поддержки архитектуры, тем не менее, остаётся нерешённым ряд задач технического плана. Среди них наведение порядка в имеющемся репозитории: уже произведено устранение остаточных alien-пакетов, на сейчас таковыми остались компилятор и его библиотеки, но пока остаются многие временные пакеты, формально предоставляющие недостающие требуемые где-либо зависимости или являющиеся «мостиками» при различии имён. Также продолжается сборка недостающих ключевых компонентов, что позволит продолжить включение отключенных на предыдущей стадии портирования «ручек»; всё-таки предстоит перенос остаточных «отключаторов» в конфигурацию сборщиков, так как все сто процентов доступного программного обеспечения пересобрать заведомо не получится в силу объективных различий платформ и их экосистем (например, для~e2k нет смысла собирать intel-gpu-tools).
Особенности архитектуры
Сизиф портирован на несколько аппаратных архитектур и каждая из них чем-то да выделяется; у архитектуры «Эльбрус-2000» в целом на сегодня наиболее выделяющимся отличием является отсутствие компилятора gcc -- в качестве системного компилятора применяется lcc, имеющий как неоспоримые достоинства в плане возможностей оптимизации (аналогичные выигрышу icc на x86/ia64, только более ярко выраженные), так и проблемы любого не-gcc в плане совместимости с~GNU-расширениями стандарта языка Си и конкретными опциями вызова.
В силу выбранного типа архитектуры (VLIW с явным параллелизмом) характерна сравнительно невысокая скорость работы компилятора, усугубляющаяся тем, что оптимизация оптимизирующего компилятора для работы на таких платформах особенно сложна; при этом практического быстродействия достаточно для пересборки за сутки более чем 1600 пакетов на шестнадцати процессорных ядрах.
По части аппаратного обеспечения (используются системы на базе микропроцессора «Эльбрус-4С») можно выделить такие особенности:
- невысокая скорость работы относительно текущих x86;
- хорошая перегрузочная способность (меньше «проседает»);
- хорошая масштабируемость многопроцессорной системы;
- поддержка больших объёмов памяти.
В частности, время сборки больших проектов (ядро Linux, браузер Firefox) на четырёхпроцессорной машине уменьшалось практически линейно по сравнению с однопроцессорной.
Значительный объём ОЗУ — 24 Гб штатно на рабочей станции, 96 Гб на сервере -- сильно облегчает параллельную сборку и сборку крупных пакетов, не вызывая подкачки страниц памяти с диска (на ARMv7 и~MIPS с этим было куда сложней, что лишь усугубляло недостаток производительности процессора).
При этом надо понимать, что потенциальная пропускная способность интерфейсов DDR3 и~SATA2 на 4С задействована не в полной мере.
Стоит отметить, что итоговая производительность системы на VLIW-архитектуре сильно зависит от того, насколько удалось реализовать параллелизм выполнения кода при его компиляции; поэтому на одном и том же ПК «Эльбрус-401» система может напоминать как Pentium~III, так и Core2 по производительности в зависимости от версии компилятора и переданных ему опций. Разумеется, порой решающее значение имеют всё-таки ручные правки кода, которые мы всё так же получаем от коллег из МЦСТ.
- Ссылки
- http://altlinux.org/ports/e2k
- http://0x1.tv/20170128J
- http://lvee.org/ru/abstracts/251
- http://sdelanounas.ru/blogs/96816
- http://mcst.ru
Примечания и ссылки
Plays:990 Comments:6