Здравствуйте.
Решил открыть ветку для обсуждения возможности проектирования новой ОС (уже смишно, 99% после этих строк ушли пить пиво ). Некоторое время читал и писал программы накопились идеи. Выложил для апробирования. Если не совсем всё тухло то выложу на сайт. А то как известно — гладко было на бумаге… И так приступим:
Зачем собственно нужна ещё одна ОС?
Есть Windows различных версий который удобен и прост, мощности которого хватает подавляющему большинству пользователей. Есть различные вариации Linux и Unix. Есть масса экспериментальных, академических и узкоспециализированных ОС. Зачем ещё одна? Просто для того, что бы сделать? Чем же не устраивают существующие ОС? Что ещё можно улучшить? Масса вопросов. Я постараюсь дать на них ответы. По моему мнению современные ОС страдают от нескольких вещей:
• Низкий КПД от использования аппаратных ресурсов
• Различные проблемы существующих ОС, порожденные от необходимости в обратной совместимости
• Огромные размеры и требования к аппаратным ресурсам (MS Vista хочет 4ГБ… нда…)
• Трудности в быстром создании высокоэффективных программ с оптимизацией по коду
Основная идея
Не уверен, что именно я знаю, что хотят пользователи, но всё же рискну. Пользователь (в т.ч. программист, так как он то же своего рода пользователь) хочет видеть гибкую, устойчивую, удобную в использовании при разработке программ, по максимуму использующую свободные аппаратные ресурсы, ОС.
На данный момент большое количество разнообразного компьютерного оборудования использую всё более производительные универсальные(!) вычислительные процессоры и собственную ОЗУ которые можно использовать не только по прямому назначению. Например, современный графический адаптер может обрабатывать подпрограммы с большей скоростью fpu чем центральный процессор. Так же современные графические карты имеют до 1 ГБ ОЗУ 90% которого, при отсутствии запущенных ресурсоемких приложений с 3D графикой, не используется вообще. Так же всё более универсальные процессоры и собственная ОЗУ используются современными мощными звуковыми и сетевыми картами, RAID контроллерами и др. Обычная современная ОС к сожалению не умеет в автоматическом режиме использовать эти аппаратные ресурсы как либо иначе кроме как по прямому назначению для ускорения соответствующим образом написанных программ. Большинство времени, которое пользователь проводит за компьютером, эти аппаратные ресурсы используются по минимуму.
Идея состоит в том, что бы расмотреть возможность проектирования(!а не реализации
компонентной ОС с микроядерной архитектурой, прозрачно от пользователя и разработчика ПО по максимуму использующую имеющиеся в компьютере аппаратные ресурсы. Желательно что бы при разработке программ для данной ОС разработчик использовал бы простой ОО язык высокого уровня, а вся роль оптимизации по коду и распределению выполнения задач на аппаратных ресурсах вычислительной системы будет отводится ОС.
В существующих ОС этого сделать практически невозможно(?) или крайне сложно по двум причинам. Отсутствие необходимой драйверной модели для устройств. Специальным образом разработанная драйверная модель может дать возможность оборудованию сообщать о своих вычислительных возможностях, количеству свободной ОЗУ, получать на исполнение код. Остается только 1 вопрос – как оборудование совершенно разной архитектуры и с различным набором команд может подписываться и брать на выполнение требуемый код реализующий какую либо функциональность? Например, какие либо одинаковые расчеты по кодированию данных теоретически мог бы обработать установленный в системе ЦП, процессор графической карты и процессор аудио карты. Все эти процессоры имеют разную архитектуру, возможности, эффективность, набор команд(порой уникальный и недокументированный) и так далее. Как сделать так, что бы некий менеджер распределения вычислений мог исходя из ситуации использования аппаратных ресурсов одни и те же расчеты передавать совершенно разному по природе оборудованию? Решение по моему существует.
Необходимо что бы на самом низком логическом уровне библиотек ОС находились примитивы с реализацией необходимой функциональности. После установки соответствующего драйвера для вычислительного устройства поставщик оборудования мог бы инсталлировать в ОС дополнительную реализацию примитива, оптимизированную для выполнения на своем оборудовании используя данный драйвер. Например, вычисление hash кода в реализации примитива поставляемым с ОС по умолчанию может быть по написана на языке высокого уровня без оптимизации. Вместе с ЦП Intel Core 2 Duo фирма Intel может предоставить свою реализацию данного примитива используя специфику своего ЦП (расширения SSE, MMX и так далее). Компания NVidia может предоставить свою реализацию данного примитива используя специфику своего GPU. Менеджеру распределения вычислений останется только использовать наиболее подходящий в данный момент или сразу несколько реализаций этих примитивов, что бы передать эти вычисления установленному в конкретный компьютер аппаратному обеспечению.
Используя данный подход разработчик ПО будет освобожден от:
• необходимости детального изучения процессорных архитектур
• используемого оборудования, написание оптимизированного кода
• аппаратной зависимости от того оборудования под которого он оптимизировал программу
и т.п. но при этом будет использовать всю их мощь с оптимизацией по коду и использованием альтернативного аппаратного обеспечения благодаря соответствующим реализациям программных примитивов и менеджеру распределения вычислений.
Если будет разработано большое количество подобных примитивов, то нет никаких принципиальных проблем передавать на исполнения отдельные задачи на компьютеры одной сети тем самым в автоматическом режиме распределяя нагрузку на аппаратные ресурсы компьютеров всей локальной сети.
О принципах обратной совместимости:
Не использовать обратной совместимости с другими ОС кроме как в случаях, когда это не будет негативным образом сказываться на построении новой ОС. Современные виртуальные машины великолепно справляются с задачей запуска одной ОС поверх другой. С небольшой потерей в производительности и с возможностью задействовать, в том числе, ускорители 3d графики (VMWare Fusion 2). Нет никаких принципиальных ограничений что бы виртуальная машина не могла бы использовать все возможности гостевой ОС в том числе 3D графику, 3D звук, USB устройства и так далее. Фактически нет необходимости пробовать создать что либо имеющее обратную совместимость с другими ОС, теряя во многом из за этого при проектировании своей.
И так подытожим:
Минусы существующих ОС (не все эти минусы обязательно одновременно присутствуют во всех ОС):
• Низкий КПД от использования аппаратных ресурсов вычислительной техники (как локальной системы так и аппаратных ресурсов систем сетевой среды)
• Сложность в быстрой разработке качественного и функционального ПО
• Высокие затраты на оптимизацию ПО под конкретное аппаратное обеспечение
• Высокие системные требования к аппаратным ресурсам, особенно к ОЗУ
• Различные проблемы, порожденные необходимостью обратной совместимости
Основная задача проектируемой ОС, как мне видится, состоит в том что бы отвечать следующим требованиям:
• Высокая отказоустойчивость (следствие использования микроядерной архитектуры)
• Высокий КПД от использования аппаратных вычислительных средств
• Нацеленность на существующие и перспективные аппаратные средства
• Высокая модульность и гибкость архитектуры ОС
• Максимальные возможности от концепции распределенных вычислений
При проектировании необходимо определиться на какие аппаратные средства будет рассчитана ОС. Какие устройства, протоколы, интерфейсы и т.д. она поддерживать НЕ будет как устаревшие.
Определиться с выбором существующего или спроектировать новый язык программирования. По моему есть смысл использовать язык со строгой типизацией вроде C#. Реализация всей системной функциональности, требуемой к примеру, для написания драйверов и т.д., для которой средств подобного языка может не хватить, можно располагать на уровне библиотек ОС и предоставлять к данным функциям достаточный для любых целей интерфейс. Благодаря выбору подобного языка со строгой типизацией и защитой на уровне компиляции можно будет использовать плоскую модель памяти и вообще меньше заморачиваться (привет Singularity!).
Реализовать большое количество небольших по объему но подходящих с точки зрения временных затрат на переключение режима и контекста процессора различные программные примитивы (математические, графические, звуковые, кодирования данных, и т.д.) для использования программистами через API ОС. Производитель оборудования может поставлять со своим вычислительным устройством (CPU, GPU…) свои наборы реализаций примитивов с оптимизацией под свое оборудование. Менеджер использования оборудования будет выбирать наиболее оптимальный с точки зрения производительности реализацию примитива с соответствующей функциональностью. Например, если GPU и CPU реализуют посредствам своих оптимизированных библиотек одну и ту же функциональность менеджер распределения вычислений может выбирать наиболее быстрое/наименее загруженное устройство. Драйвер устройства должен сообщать ОС о степени своей готовности, пиковой производительности, объему свободной памяти и т.д. ОС может иметь бенчмарк для оценки реальной производительности и сравнения производительности оборудования выполняющих конкурирующие реализации примитивов. В соответствии с тестами, ОС может выставить приоритет использования оборудования для выполнения различных реализаций примитивов. Таким образом, несмотря на то что прикладной программист не будет использовать в своих программах низкоуровневый код, сохраняя тем самым полную совместимость программы со всем комплексом аппаратных средств и платформ поддерживаемых ОС, программы будут оптимизированы с точки зрения эффективного выполнения на используемом в данных момент оборудовании. Следующий эффект от данного подхода будет заключаться в упрощении реализации функциональности программ и меньших временных затратах на её разработку.
Возможно, многие задачи не будут решаться быстрее силами альтернативного оборудования. Но многим задачам в большинстве случаев их использования нет необходимости в большой скорости выполнения. К примеру: процессам с низким приоритетом, задачам декодирования звуковых и видео данных для мультимедиа проигрывателей, реализация крипто примитивов, реализация примитивов сжатия данных, обработка потока данных перед чтением/записью данных на ПЗУ или относительно медленные коммуникационные интерфейсы. Данным подходом мы не только не замедлим выполнения подавляющего большинства операций, а некоторых ускорим на порядок, но и высвободим ресурсы ЦП для выполнения более приоритетных задач требующих меньшего времени отклика. Из данного подхода распределения вычислений проистекает множество последствий.
• Отсутствие жесткой необходимости в использовании одного типа архитектуры вычислительного процессора при работе ОС
• Высокая утилизация мощностей имеющихся в системе аппаратных ресурсов
• Глубокая оптимизация по коду независимо от типа ПО используя при разработке язык высокого уровня
• Высвобождение ресурсов основных ЦП
• Прозрачное распределение вычислений как между оборудованием одной ВС так и между разными ВС ЛВС
Например, появится возможность добавить PCI-E карту с ЦП с архитектурой PowerPC или MIPS (не важно), и при соответствующих драйверах и оптимизированных реализаций примитивов под данное аппаратное обеспечение система АВТОМАТИЧЕСКИ будет использовать эти ресурсы для распределения вычислений при решении задач наравне с использованием архитектуры x86. Мощные сетевые контроллеры (взять хотя бы далеко не новый Intel с RISK процессором i960) фактически могут выполнять задачи не свойственные обязательно работе сетевого интерфейса, когда его загруженность не велика.
Система может распределять вычисления по альтернативному оборудованию в автоматическом режиме, используя приоритеты процессов, приоритеты выполнения реализаций примитивов, в указанном пользователем приоритете и т.д.
Исходя из этого ситуация в идеале может развиваться следующим образом:
• Производители оборудования будут заинтересованы в создании аппаратного обеспечения снабженного более универсальными процессорами
• Отпадает явная необходимость использования только одной архитектуры процессора в вычислительной системе
• Возрастает конкуренция между разработчиками аппаратного обеспечения. Будет мало просто продавать узкоспециализированное железо. Необходимо будет снабжать его соответствующими драйверами и реализациями примитивов исходя из требований пользователя.
• У производителей появляется возможность вывести на рынок конкурирующие архитектуры процессоров, не требуя от пользователя менять архитектуру компьютера
Сейчас данные преимущества можно получить лишь отчасти. Конечно, можно использовать некий аппаратный ускоритель-адаптер на универсальном ЦП (к примеру PowerPC) но он опять таки выполняет ускорения лишь узконаправленного назначения используя соответствующие модели драйверов.
В остальном данная ОС может использовать классические подходы. При разработке просто можно учесть все плюсы и минусы текущих наработок в ОС, не тормозить развитие системы проблемами с обратной совместимостью, выбирать подходы исходя из свойств современного и перспективного аппаратного обеспечения (многоядерные процессоры, универсальная архитектура процессоров дополнительных адаптеров, и т.д.).
Есть подозрения что существуют следующие риски:
• высокая нагрузка на шину и память из за интенсивного IPC
• высокая сложность в реализации планировщика
• высокие накладные расходы для данной схемы распределения вычислений
• более высокое время отклика от альтернативных микропроцессоров
• недетерминированное время завершения задачи при распределении её на другие устройства подобным образом
• незначительный выигрыш от применения данной схемы распределения вычислений
• незначительный выигрыш от применения данной схемы распределения вычислений относительно затрат на накладныe расходы
В общем это всё разные отрывки размышлений ... хочется узнать логично ли всё это ?
Хотелось бы услышать внятные комментарии и не крики и ругань
Вполне допускаю что в чем то не прав...
Жду комментариев и живого обсуждения!
Юра!
Универсальный клей может склеить всё — дерево, резину, etc.
Угадайте, почему же, несмотря на обилие универсальных клеев (как дорогих, так и дешевых), до сих пор существуют такие казалось бы рудименты как столярный клей, резиновый клей, etc?
