Операционные системы – кризис прагматизма

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

Одно из возможных мнений современного прагматика от мира разработки программного обеспечения лучше всех не так давно высказал, как ни странно, знаменитый Дональд Кнут – представитель академической школы и, что бы кто ни говорил, все-таки один из самых знаменитых программистов (если за мерку известности принять значимость и распространение хотя бы одной авторской программы). В интервью с Эндрю Бинстоком (InformIT) менее года назад Дональд Кнут более чем резко высказался о факторе, который считается сегодня одним из главных мотивов, побуждающих искать новые архитектурные решения на уровне операционных систем (перевод не дословный, но полностью сохраняющий смысл): «...Мне кажется, что в большей или меньшей степени, но у разработчиков аппаратных средств иссякли идеи и они пытаются переложить ответственность за сохранение в будущем действенности закона Мура на плечи программистов, причем делают это с помощью разработки машин, которые демонстрируют прирост производительности всего на нескольких ключевых тестах!.. Продолжу свою мысль – за последние 50 лет я написал более тысячи программ, и многие из них были весьма солидного размера. Сейчас не могу сказать, что хотя бы пять из них можно усовершенствовать за счет мультипроцессорности или многоядерности».

Давайте подумаем о том, что именно мог хотеть сказать Дональд Кнут. И что именно он сказал. Для этого вспомним закон Амдала, который почему-то не очень любят упоминать, когда речь идет о битве за работоспособность закона Мура с применением «многоствольного» оружия с ограниченной скорострельностью каждого «ствола» (аналогии – штуки очень опасные, и данный случай не исключение).

Итак, закон Амдала гласит – если некоторая часть всей задачи может быть решена только не поддающейся распараллеливанию последовательностью операций, то максимальный прирост производительности за счет использования вычислителя параллельной архитектуры c процессорами по сравнению с классической однопроцессорной машиной не может превышать значения

Следует особо подчеркнуть, что это фундаментальное ограничение устанавливает максимально возможный прирост производительности. Что для прагматика означает – такой, который невозможно достичь на практике. И самое интересное в законе Амдала – зависимость максимального прироста производительности для задач с некоторым известным значением нераспараллеливаемой части вычислительного процесса от увеличения числа процессоров. Например, для задачи, всего 40% кода которой (α = 0,4) не допускает распараллеливания, картина выглядит, мягко говоря, не многообещающей (рис. 1).

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

Соответственно, сразу напрашивается самый неприятный вопрос – а есть ли у нас формальные способы оценки этой самой цифры, позволяющие на самом раннем этапе проектного процесса (например, на этапе постановки задачи) с какой-то степенью уверенности ответить на крайне неприятные вопросы. А именно – есть ли нам смысл тратиться на параллельную реализацию нашей будущей программы? Получим ли мы существенный выигрыш в производительности при ее исполнении параллельными (многоядерными) вычислителями, которые станут массовыми ко времени завершения нашего проекта? Вопросы эти на самом деле вовсе не игрушечные или потешные. Разработка параллельных программ заданного уровня качества (пусть это условный термин, но он интуитивно понятен и не ограничивается только количеством дефектов) – удовольствие не из дешевых. И далеко не быстрое. Иными словами – занятие с двумя большими факторами риска (деньги и время) в условиях неопределенности. Эмпирически получены даже не оцен-ки, а некоторые основания для уверенности в правоте принятого решения о распараллеливании кода будущего проекта для определенных классов задач (реалистичной 3D-графики, моделирования систем, описываемых дифференциальными уравнениями, ряда численных методов etc).

Так что Дональд Кнут хоть и чрезмерно строг, но во многом все-таки справедлив. И хоть это, безусловно, интересное занятие – чтение новостей о 100-ядерных процессорах, спешить кричать «ах!» не стоит. Потому что совершенно непонятно пока, что именно с этим «ах!» делать. Причем вся проблема как раз и заключается в вопросе «что именно с этим делать?», потому как на вопрос «как именно делать?» ответы ищутся и, похоже, уже находятся. Поэтому вполне возможно, что реалистичный 3D-интерфейс в виде смазливой и болтливой девушки к... обычной и с обычной скоростью работающей утилите поиска в тексте с помощью регулярных выражений – ближайшее будущее. Архитектуру ведь надо использовать на все 100%? Надо. И пока что развитие пользовательских интерфейсов всех массовых операционных систем убеждает в том, что такое допущение вовсе не настолько глумливое, каким кажется. Несмотря на это, мы все же немного поговорим о том, какими именно представляют себе разработчики новых ОС те механизмы, с помощью которых мы в ближайшем будущем сможем еще намного быстрее не совсем понятно что.

Как ни странно, но ориентировочно с 2003 г. основным источником новых операционных систем является самая, пожалуй, прагматичная программистская компания в мире. Да, речь идет о Microsoft. Знаменитой своим подчеркнутым прагматизмом и неспешностью по отношению к включению «необкатанных» инноваций в массовые продукты. Точнее, о ее исследовательских подразделениях Microsoft Research. Три крупных исследовательских проекта ключевого системного ПО меньше чем за шесть лет – это не шутка. Больше того, это вообще в своем роде исключение из правил. Причем речь идет о проектах совершенно новых, созданных с нуля операционных систем, не оставшихся на бумаге, а доведенных до статуса «полностью работоспособный прототип».

Закон Амдала в действии

Первой в этой цепочке, в чем-то, возможно, отражающей черты будущего, располагается, естественно, ОС Singularity. Эта система распространяется на основании лицензии MSR-LA с открытыми исходными текстами и доведена в прошлом году до вполне работоспособной версии 2.0. Лицензия либеральна и имеет ярко выраженный исследовательский характер в том смысле, что допускает практически все что угодно некоммерческое вплоть до распространения системы на сопровождающих книги носителях информации. Совершенно замечателен тот факт, что Singularity, создание которой началось за несколько лет до упомянутого выше интервью Дональда Кнута, подчеркнуто и как будто нарочито соответствует его резким словам в адрес разработчиков аппаратных средств. Точнее, даже не так. Создатели идей и кода Singularity словно бросили вызов расписавшимся в бессилии «железячникам» и в полной мере попытались принять на себя всю ответственность за сохранение закона Мура. Singularity, если можно так сказать, сугубо программная операционная система, не требующая традиционной аппаратной поддержки для решения ключевой задачи ОС – защиты множества исполняемых процессов друг от друга. Впрочем, система не исключает и возможности специфической аппаратной поддержки, радикально отличающейся от известных традиционных решений. В некоторых крупных чертах Singularity очень похожа на ставшую уделом маргиналов и утонченных эстетов от программирования систему Forth. В первую очередь в том, что и Singularity, и Forth являются неразрывно взаимосвязанными гибридами собственных специфических языков программирования и ОС. Для реализации Singularity был создан диалект C# – Sing#, позволяющий с минимумом дополнительных языковых конструкций удобно писать весьма выразительный параллельный код. С вечной головной болью всех «параллельщиков» – разделяемыми областями памяти с совместным доступом – идеологи проекта поступили радикально. А именно, принципиально отказались от такой возможности. Что, естественно, потребовало массы логично следующих из этой конструктивной особенности проектных решений (в том числе и отказа от традиционных методов защиты процессов друг от друга). Основная абстракция Singularity – программно изолированный объект (несмотря на слово «process» в аббревиатуре SIP). Изоляция здесь означает собственное уникальное адресное пространство, недоступное прочим объектам. Объекты-SIP могут обмениваться данными посредством каналов связи со строго заданными протоколами и типами данных. Обо всяких очевидных для современных технологий программирования нюансах (типа сборщиков мусора) есть смысл сказать только, что они в системе реализованы. Кое-что менее очевидное надо подчеркнуть. Например, тот факт, что уникальность адресных пространств объектов-SIP принципиально исключает возможность обмена адресами памяти (в идеале – из-за полной бесполезности, в реальности несовершенных реализаций системы – из-за возможности нарушения ее нормальной работы). И, естественно, низкую «стоимость» (в вычислительных терминах) всех ключевых системных операций. В принципе, этих сведений о Singularity вполне достаточно для того, чтобы понять – эта ОС очень похожа на... доведенный до уровня основного компонента системного ПО многопроцессорного вычислителя аналог среды программирования C# или Java, со своей специфической виртуальной машиной, runtime, библиотеками и т. д. По сути, это одно из вполне возможных направлений развития ОС – доведение виртуализированной (с собственной виртуальной машиной и JIT-компилятором) системы программирования до уровня автономной системы, максимально использующей возможности многопроцессорных архитектур. Этакий последователь Forth в 2010-x годах. В пользу такого решения говорит и то, что параллельное программирование требует адекватных языковых инструментов, соответствующих возможностям 8- и 16-ядерных процессоров в той же степени, в какой в свое время язык Forth соответствовал возможностям 8- и 16-битовых микропроцессоров. Ну и само собой, этот последователь предусматривает доведение идей объектно-ориентированного программирования до уровня идеала, с подлинной, исключающей любые обходные пути, инкапсуляцией, и с семантическим, а не синтаксическим механизмом обмена сообщениями между объектами.

Следующий проект цепочки, ОС Barrelfish, на уровне идеи можно назвать «ОС для гетерогенного многопроцессорного персонального вычислителя». Такой вычислитель – вовсе не далекое будущее, любой из нас может обнаружить его... на своем рабочем столе. В большинстве наших компьютеров – многоядерные процессоры, графические акселераторы со своим множеством процессоров в GPU и куча всяких вовсе малозаметных вычислителей (сигнальные процессоры звукового тракта, контроллеров внешних устройств etc). Идея разработчиков Barrelfish – ОС, превращающая весь этот разнобой в слаженный хор, подчиненный решению одной задачи. Соответственно, необходимы и множество ядер ОС для каждого вычислителя, и компиляторы, позволяющие генерировать для них код, и язык, позволяющий писать максимально мобильные программы, и очень специфическая среда времени исполнения такого языка. Что очевидно, в подобной системе уникальность адресных пространств объектов или процессов – не решение разработчика, а техническое требование. Так что без механизма передачи сообщений здесь также не обойтись. Barrelfish также не «бумажный» проект, рабочий прототип этой системы уже доступен в исходных текстах. В отличие от предшественницы Barrelfish, разрабатываемая Microsoft Research в альянсе со знаменитой Швейцарской высшей технической школой Цюриха (ETH, откуда родом все детища Никласа Вирта, в том числе и ОС Oberon и Bluebottle), распространяется на основе самой либеральной лицензии BSD.

Ну и наконец, совсем «свежий» проект – ОС Helios, уточняющий очередной контур возможного будущего. По большому счету, он эволюционно продолжает главную идею Barrelfish (использовать гетерогенный многопроцессорный персональный вычислитель как единую систему), но с применением приемов, заимствованных из мира «больших» гетерогенных вычислительных кластерных систем. Если Barrelfish – это множество ядер ОС, заранее созданных и запущенных одновременно на разных вычислителях, то Helios – это динамический механизм порождения первым загруженным ядром-координатором новых ядер для всех обнаруженных вычислителей. К числу существенных, но как- будто незначительных модификаций предшественников Helios добавляет дифференциацию реализации механизма передачи сообщений, вводя понятия «близкого» и «далекого» сообщений. Если два процесса выполняются под управлением одного ядра, Helios автоматически активирует для них механизм близкого обмена сообщениями, вообще не требующий затрат на копирование данных. Во всех остальных случаях включается режим «дальней» связи с соответствующим повышением накладных затрат на доставку сообщения.

Теперь настало время поговорить о том общем, что объединяет все три проекта. Во-первых, это микроядро. Что бы ни говорили самые оголтелые фанатики, какие бы цифры ни приводили в качестве доводов, если многопроцессорность (многоядерность) как мода, тенденция и элемент окружающей действительности продержится еще несколько лет, альтернативы микроядерным ОС не будет. Увеличение числа процессоров на одном кристалле – это ведь с какого-то момента еще и неизбежное упрощение каждого из процессоров (потому что площадь кристалла – это деньги, а деньги в посткризисном мире – это критерий). Много простых процессоров – это и невозможность реализовать ряд мощных механизмов ОС, и источник колоссального снижения надежности при одновременном увеличении количества исполняемого в привилегированном режиме кода. Так что микроядерные ОС неизбежны. Если, конечно, неизбежны многоядерные архитектуры. Во-вторых, отказ от разделяемой памяти и переход к полноценному механизму передачи сообщений. Он, безусловно, является следствием из во-первых. В-третьих, рост интереса к гибридам язык-ОС, обусловленный спецификой параллельных вычислителей. В-четвертых, идеи объектно-ориентированного программирования, перенесенные на архитектурный уровень (это уже не новое явление, просто для него вечно придумывали всякие «новые» названия). Объекты, инкапсуляция и передача сообщений перестают быть синтаксическими терминами и становятся основными абстракциями и механизмами ОС.

Перефразируя некогда смешного юмориста – или наши компьютеры опять станут однопроцессорными, или эти гадания станут предсказаниями. Время покажет.