Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 6, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21 |
|
<< Предыдущая тема | Следующая тема >> |
| Идея возможности проектирования ОС с высоким КПД использования аппаратных средств | ||
| Переход на страницу [1] 2 3 ... 15 16 17 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| Jurik |
| ||
 ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | Здравствуйте. Решил открыть ветку для обсуждения возможности проектирования новой ОС (уже смишно, 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) но он опять таки выполняет ускорения лишь узконаправленного назначения используя соответствующие модели драйверов. В остальном данная ОС может использовать классические подходы. При разработке просто можно учесть все плюсы и минусы текущих наработок в ОС, не тормозить развитие системы проблемами с обратной совместимостью, выбирать подходы исходя из свойств современного и перспективного аппаратного обеспечения (многоядерные процессоры, универсальная архитектура процессоров дополнительных адаптеров, и т.д.). Всё. Основную идею привел! Существуют ещё идеи, но эта основная. Именно она решит - стоит ли городить огород. Есть мысль зарегистрировать сайт для обсуждения и работы над данным проектом. Посвятить сайт вопросам проектирования(!). Именно вопросам проектирования а не реализации! «Напишем загрузчик, а там посмотрим» или «Делаем именно так, потому что Петька такой модуль быстро нам запрограммит» - это не то что бы я хотел видеть. Этого добра в сети хватает без меня. Идея состоит в том, что бы собрать на сайте для обсуждения множество грамотных людей, каждый из которых является специалистом в своей области. Обсуждая минусы и плюсы конкретных подходов в построении современной ОС хотелось бы создать четкую картину того, что реально необходимо. Я не являюсь серьезным и опытным проектировщиком ОС. У меня есть опыт разработки ПО, я в некоторой степени представляю архитектуру работы компьютера и с точки зрения ОС и с точки зрения аппаратуры. Но не более того. Именно поэтому есть идея лишь создать площадку для обсуждения, а не создавать «свой самый крутой загрузчик ОС и пару утилит на ассме к ней». Если есть желающие и идея не является бредом то буду рад всем и любой помощи! Жду комментариев и живого обсуждения! Юра! | ||
| Наверх | | ||
| Dron |
| ||
   ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Очень много буков... но я их почти все прочитал... честно... Вообще ИМХО время однопользовательских операционных систем прошло... пришло время распределенных... Но вот с распределенными у нас проблема. Windows по определению не умеет распределяться, поскольку вырос из доса... Юникс распределяется, только весьма тяжелым образом.. Недавно где-то поднимался вопрос на тему: Почему много ядерные системы теряют так много. (порядка 40% на ядро... ИМХо все просто... потому, что все системы родились из многопроцессорности а не6 из многопоточности.. То есть грануляция задач не достаточно велика для того, чтобы эффективно использовать мощность оборудования. То, что делают аппаратчики - это костыли... Почему AMD64 не обеспечивает прорыв... да потому, что на старых костях растет... то есть те же 32 бита, вид сбоку.. Не будет разницы в скорости, если шина та же... В остальном твои мысли очень правильные... Я думаю впонлне аналогично... Нет смысла свопится на диск, если под рукой есть неиспользуемые (при условии обычной оффиной графики) 128-256 мег видеопамяти... Та же самая фигня с GPU-шными мощностями... Если они не используются (для 3D графики) то их сам Бог велел юзать... проблема в том, что не для всех задач они подходят. (Вообще я приношу свои извенения за гон... тока что прошел праздник 8-е марта... я немного не в себе... но за свои слова я почти всегда отечаю  )Блин, сходил отлить, потерял нить разговра... придется все перечитывать... Дык это... суть в том, что сама организация системы должна быть посроена на распределенных принципах. то бишь почти все операции должны быть децентрализоваными. не многу не вспомнить своего кумира - Джоэла Спольского... Ссылка То есть распределение задач должно быть мелко модульным, а не крупно модульным, как сейчас... Ибо все современные архитектуры произрастают из процессов. Соответственно и эффективность использования архитектуры возрастет. Микроядра - естественно рулят, но пока не одной юзабельной реализации микроядер не существует. Так что пространства для сомореализации полно... дерзаем! За нами будующее. PS: В пятницу, когда я приду на работу, я буду более вменяем. заранее всем мои извинения. PPS: Всех женщин с праздником. Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Freeman |
| ||
| ID пользователя #3 Зарегистрирован: Четверг 01.07.2004 14:57Сообщений: 207 | Шекспир написал(а) ... Жизнь - это сказка в пересказе глупца. Она полна трескучих слов и ничего не значит. Много умных слов ни о чём. Хочешь сказать, что сделал аналитику по проблеме? Молодец, возьми с полки пирожок. А дальше? | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2Freeman: Что ж все такие злые то ? я попытался хотя бы предложить на рассмотрение способ удобного автоматического прозрачного для разработчика ипользования всех аппаратных ресурсов компьютера. Завидно что ли ? Если есть мысли в слух. У вас есть чем возразить конкретно ? что конкретно не так можете сформулировать ? а то трепаться все горазды. Я попытался предложить конкретный подход . Вы можете конкретно описатье го минусы ? Проблемы из за падения скорости от ещё более интенсивного использвоания IPC или нагрузке на ОЗУ? Маленький выйгрыш или что ? или вы ничего не можете даже сказать толкового ? <span class='smallblacktext'>[ Редактирование четверг 08.03.2007 02:52 ]</span> | ||
| Наверх | | ||
| k0l0b0k |
| ||
 ID пользователя #265 Зарегистрирован: Четверг 07.04.2005 14:48Местонахождение: Great Dnepr Сообщений: 36 | Вашим словами да по вендорам помазать. Идея, имхо, хорошая, кпд современных ОС далек от идеала... но. есть 2 большие проблемы - необходимость поставки спец-драйверов от производителя (тот же линукс по сей день не поддерживается многими). И сложновато все это в реализации будеть. Ой как сложновато. У меня вопросик - для прикладного приложения распределение ресурсов будет полностью прозрачным или нет? P.S. В Microsoft Research далеко не дураки сидят. И поучиться у них есть чему. Вот правда инфы про Singularity маловато. | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | to k0l0b0k: Да! в этом и соль идеи что бы для прикладного программера и прикладного ПО соответственно ВСЁ это было СОВЕРШЕННО ПРОЗРАЧНО! ОС бы сама выбирала наиболее подходящию реализацию примитива на момент его вызова. <span class='smallblacktext'>[ Редактирование четверг 08.03.2007 00:08 ]</span> | ||
| Наверх | | ||
| ddc |
| ||
Free Software Zealot  ID пользователя #202 Зарегистрирован: Воскресенье 06.02.2005 09:32Местонахождение: Москва Сообщений: 189 | Непонятно, откуда растёт оптимизм. Если бы GPU были настолько универсальными, для них были бы свободные драйверы под любую ОС. Если бы система решала, какую память и какой процессор ей выбирать, то она бы бивала половину своего времени на выявление скоростных характеристик и загруженности имеющихся связок процессор-память, а вторую пловину времени - на выявления требований задачи по этим показателям. Написал бы ещё, но извините - экстремально лень. Но это всё, конечно, моё сугубо личное мнение... | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | to dcc: нет оптимизма по поводу универсальности GPU .. есть четкое понимаение что NV80 есть практически универсальный проц который по некоторым задачам даст фору любому ЦП В РАЗЫ! почитай подробнее если хочешь.. например про расчет FFT средстами GPU через D3D шейдеры... про Nvidia CUDA ... Современные микропроцессоры всё более универсальны и тьнденция такова что будут ещё более универсальны .. к примеру что от ATI что от Nvidia ... прочитайте про шейдеры 4.0 ... прочитайте о мнении что внутри этих GPU щас куча похожых на x86 процов ... так или иначе универсальных микропроцессоров в оборудовнии много а используются они как узкоспецилизарованные чуть ли не исключитеьно как dsp ... и дальше будет ещё круче ... нет мазы выпускать под каждую задачу спец. микропроцессор есть маза наляпать нбольшое количество моделей процов и вешать на нах соответсвющую микропрограмму и вот вам ускоритель чего либо .. а есть идея через ОС их юзать по полной при чем прозрачно .. валить на них задачи хотя бы не требующие минимального времени отклика (читай задачи с низким приоритетом) | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | кстати перед тем как задавать вопрос откуда мнение что они универсальны полезно почитать о них ... а по поводу их скорости в некоторых вычислениях... запустите 3D угрушку с аппаратным и програмный рендерингом и почувствуйте разницу .. пример не самый прямой но если есть понимание того что из себя представляют GPU последнего поколения то более чем очевидно желание и возможность использовать их мощ для самых разных задач ... порой на тему FP блоков в современных GPU... <span class='smallblacktext'>[ Редактирование четверг 08.03.2007 00:40 ]</span> | ||
| Наверх | | ||
| Freeman |
| ||
| ID пользователя #3 Зарегистрирован: Четверг 01.07.2004 14:57Сообщений: 207 | Jurik написал(а) ... я попытался хотя бы предложить на рассмотрение способ удобного автоматического прозрачного для разработчика ипользования всех аппаратных ресурсов компьютера. Сказано ведь - молодец. Это хотел услышать? Я подобной проблематикой занимаюсь уже 5-й год, и за это время понял простую вещь: все идеи, пусть и хорошие - пустой звук и профанация, если нет возможности привлечь для их реализации средства (людей и/или деньги). Jurik написал(а) ... У вас есть чем возразить конкретно ? Почитай Раскина. Или Шекспира, на крайняк. | ||
| Наверх | | ||
| Переход на страницу [1] 2 3 ... 15 16 17 | |
Powered by e107 Forum System