Вопросы истории: UNIX, Linux, BSD и другие

Федорчук Алексей Викторович

Сами по себе процессоры Power4 (как и пришедшие им на смену Power5) ориентировались на индустриальный сектор. Однако на базе их были созданы процессоры G5 – сердце тогдашних Mac’ов, имевших, в том числе, и двухъядерный вариант.

Правда, пользователям PC’шек (а мы говорим в основном о них) от этого было бы ни холодно, ни жарко. Однако здесь «камнестроители» не заставили себя ждать: и AMD, и Intel очень быстро анонсировали, а затем и воплотили в реальность, свои двухъядерные решения, стоимость которых вполне вписывалась в рамки

«суперкомпьютера для народа». По крайней мере, в лице лучших его представителей.

Так что пользователи оказались перед выбором между традиционными одноядерными процессорами с большей тактовой частотой или процессорами двухъядерным – с меньшей (если оставаться в рамках одного бюджета). Как я уже говорил, рост тактовых частот упёрся в потолок целесообразности: сколь бы велик он ни был (а тут имелся ещё и потолок технологический), адекватного прироста производительности он уже за собой не влёк. Но могли ли пользователи рассчитывать на хоть какой-то выигрыш в производительности от многоядерности?

Софтверная перспектива

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

Во-вторых, неизбежны были потери быстродействия за счет «накладных расходов» – согласования операций, выполняемых на разных процессорах.

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

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

Решение проблем многозадачности на «железном» уровне было задачей производителей аппаратуры. А вот минимизация же «накладных расходов» и распараллеливание задач относились уже к сфере разработчиков софта, в первую очередь – системного. Хотя в последнем случае роль создателей программ прикладных ничуть не меньше. Ну а эффективное использование достижений тех и других – это уже вахта пользователей.

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

Ведь что происходит на типичной пользовательской UNIX? На ней постоянно что-то компилируется, архивируется и разархивируется, кодируется и декодируется, бэкапится и восстанавливается. И все

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

Так что вырисовывалась заманчивая картина – все это изобилие параллельно работающих задач выполнять действительно параллельно, раскидав по разным процессорам. Дело оставалось за малым – воплотить её в кодах.

Изначально создатели UNIX (и ранних его клонов) ни о какой многопроцессорности не помышляли. И один из краеугольных камней его идеологии – концепция монолитных процессов, выполняемых на одном процессоре квазипараллельно, за счет квантования времени, – казалось бы, препятствует реализации распараллеливания задач по разным «камням».

Тем не менее, когда многопроцессорные серверы и рабочие станции стали реальностью в индустриальном секторе, в дополнение концепции процесса была создана и концепция т.н. нитей, или потоков (threads). Это – части процесса, выполняемые параллельно и почти независимо друг от друга (в том числе и на отдельных процессорах), разделяющие, тем не менее, ресурсы составленного из них процесса. То есть собственного контекста, в том числе и отдельного пространства памяти, они не имеют, почему носят ещё и имя легковесных процессов (light weight process) – обычные UNIX-процессы в этом случае можно называть «тяжелыми».

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

Как уже говорилось, проблема мультипроцессорности встала в первую очередь в индустриальном секторе. Где по ряду причин (в том числе и исторических) традиционно преобладали проприетарные представители UNIX-семейства. И разработчики последних доблестно эту проблему разрешили. Можно спорить, где она была решена лучше, где – не так хорошо, однако общепризнанно: масштабируемость многие годы был главной отличительной чертой (и главным козырем) и AIX от IBM, и Solaris от Sun, и прочих их братьев-конкурентов.

Свободные UNIX-совместимые ОС, как мы помним по первой статье цикла, разрабатывались преимущественно или в университетско-академической среде, или просто энтузиастами-любителями, как правило, на подручном оборудовании. Среди которого многопроцессорные суперкомпьютеры встречались не так уж и часто (солнце народной мультипроцессорности ещё не показало из-за горизонта своих первых лучей). И потому долгое время поддержка многопроцессорности была слабой стороной и Linux, и BSD-систем (по крайней мере, для платформы Intel и совместимых).