Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (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 ... 5 [6] 7 ... 15 16 17 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| ddc |
| ||
Free Software Zealot   ID пользователя #202 Зарегистрирован: Воскресенье 06.02.2005 09:32Местонахождение: Москва Сообщений: 189 | Jurik написал(а) ... Не вижу там третьего варианта. Можно цитатку?1 -Если ыт читал о чем я писал то как раз я и привел на рассмотрение третий вариант  )))))))Jurik написал(а) ... Я её рассматриваю. Просто без фанатизма. Почему ты упорно не хочешь рассмотреть возможность задействовать простаиваемые мощности и не получить выйгрыш от разгруженного CPU? Но это всё, конечно, моё сугубо личное мнение... | ||
| Наверх | | ||
| Jurik |
| ||
 ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2dcc Необходимо что бы на самом низком логическом уровне библиотек ОС находились примитивы с реализацией необходимой функциональности. После установки соответствующего драйвера для вычислительного устройства поставщик оборудования мог бы инсталлировать в ОС дополнительную реализацию примитива, оптимизированную для выполнения на своем оборудовании используя данный драйвер. Например, вычисление hash кода в реализации примитива поставляемым с ОС по умолчанию может быть по написана на языке высокого уровня без оптимизации. Вместе с ЦП Intel Core 2 Duo фирма Intel может предоставить свою реализацию данного примитива используя специфику своего ЦП (расширения SSE, 3DNow, MMX и так далее). Компания NVidia может предоставить свою реализацию данного примитива используя специфику своего GPU. Менеджеру распределения вычислений останется только использовать наиболее подходящий в данный момент или сразу несколько реализаций этих примитивов, что бы передать эти вычисления установленному в конкретный компьютер аппаратному обеспечению. Я предложил. ни в какой код приводить ничего автоматом приводить не надо. Поставщик ЕСЛИ ЗАХОЧЕт представит свою версию данного примитива с реализаций данной функциональности (одинаков по интерфейсу) исполняющуюся на ЕГО ОБОРУДОВАНИИИ. Вопрос только в планировщике ОС. Как он распределит примитивы разных поставщиков которые задействуют разное оборудование.! Кароче .. че я все пересказываю. Нет я понимаю может влом читать. Слушай. ну тогда не мучай вопросами. А то как то глупо получается. Если у тебя есть свое предложение как это реализовать что бы имея соотв. драйвер, соотв. устрйоство. и соотв. планировщик, исполняли на нем некий код. Не только на ЦП а на любом оборудовании которое подходит для обработки каких либо данных (пусть оно НЕ ВСЕ примитивы будет реализовывать но хоть что то). предложи свой вариант. И докажи что этот несостоятелен. <span class='smallblacktext'>[ Редактирование вторник 13.03.2007 01:25 ]</span> | ||
| Наверх | | ||
| Dron |
| ||
  ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Юрик, ты не прав... Ну во первых я считаю, что нельзя всех насильно заставить писать на C#.  это не гуманно, и такая система заранее обречена на провал. (вспомним где сейчас Блюботл?)Возможно C# и NET замечательно, но только вот не надо мне парить, что это эффективнее C или C++. Это удобнее, проще... да. и только. Кстати незабвенный Джоэл Спольский писал на эту тему... здесь. И тем более ты весьма опрометчиво говоришь, что С++ более подвержен ошибкам, нежели си.. Это лишь выдает твой непрофессионализм. Так же твой непрофессионализм выдает то, что ты заявляешь будто программы на C++ аппаратнозависимы... Я честно говоря вообще не понимаю как это у тебя GUI стал частью C#? Давно ли ты программируешь вообще? и что вообще кроме C# ты знаешь? PS: Я программирую с 88 года, мне не составит труда начать писать на C#, только пока я не вижу в этом никакой необходимости. И вообще считаю что язык программирования - это дело сугубо интимное... всмысле личное дело каждого. Система должна быть демократична, иначе она никому не будет нужна. Если вернуться к распределенным вычислениям... что же такого можно сделать на C#, чего нельзя сделать на другом языке? Мне просто не понятна такая упертость в язык. Спецификация взаимодействия компонент должна быть языконезависима! [ Редактирование вторник 13.03.2007 11:59 ] Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2Dron Я привел c# как язык. Если прочитаешь про концепцию MSIL то поймешь что там можно использовать ЛЮБОЙ язык лишь бы компилятор его генерил промежуточный код GUI является частью API .NET а у с# своего API нет. Поэтому GUI есть в каком то смысле часть c#. Я не говорил что C# эффективнее как язык. Он эффективнее с точки зрения создания программ. В плане скорости и удобства разработки. Многие концепции С и С++ просто затрудняют быструю разработку прикладных программ и являются источником ошибок который находится на уровне ЯЗЫКА! Про аппаратную зависимость С++ программ. А ты перенеси программу из Винды на Линкс или наоборот вот и посмотрим! С++ ПО переносимо только пока ты не вылазиешь за рамки С++ API которого просто ужасно недостаточно!.NET позволяет тебе использовать не 1 десяток языков. Не хочешь C# используй Cobol Паскали Басик да что угодно! Просто С# разрабатывался для .NET изначально и наиболее удобно его приводить в пример! Про ошибки ДА! С более подвержен ошибкам на чем c#! Так же как в среднем в программе на ассемблере больше ошибок чем на С! ЭТО ФАКТ! .NET и C# Я ПРИВЕЛ КАК ПРИМЕР! ХОЧЕШЬ ВОЗЬМИ КАК ПРИМЕР JAVA! ГЛАВНОЕ ЧТО БЫ БЫЛА СРЕДА ВЫПОЛНЕНИЯ И API НЕЗАВИСИМЫЙ ОТ ОС! Я пишу и на С++ .. прекрасно всё понимаю .. НО: Я тут подумал(бывает иногда) и понял .. Про кросс платформенность вообще и про с++ в частности… Любая программа не являющаяся по замыслу частью ОС должна быть кросс-платформенна. Будь то прикладное ПО, сервис или драйвер. С++ имеет свой API. Идея его API (языка С) в создании независимых от аппаратуры и железа программ. Но этого API недостаточно для создания функциональных программ. По этому прикладное ПО вынуждено даже низкоуровневые вещи использовать посредствам API OS. Включая процессы, потоки, синхронизация, IPC, API для создания драйверов. КАК ТОЛЬКО прикладное ПО начинает использовать ОС зависимый функционал, это ПО СРАЗУ становится привязанным к этой ОС. Пусть ОС содержит Ядро с небольшим API на С являющимся по сути HAL. Пусть будет ОС API на С++ которое предоставляет некий функционал для работы с процессами, потоками, синхронизацией, IPC, создания драйверов и другими API прикладного направления (может быть архитектурно на основе описанного мною подхода с использованием оптимизируемых примитивов) осуществляет вызовы к С API (HAL). С++ API же является лишь API для runtime среды. Выше должны идти платформенно-независимые runtime среды! Например .NET или Java. ПО тогда будет кроссплатформенным. Это понятно. Важно что бы на уровне ОС не было(!!!) API используемого программами НЕ ЯВЛЯЮЩИМЕСЯ частью ОС или средами для выполнения программами не являющимися частью ОС. По этой причине выходит во первых: ОС содержащие API библиотеки для прикладного ПО на С++ или С уже допускают ошибку! Я говорю с подхода платформа-независимых программ. В хорошем подходе программа должна общаться со средой (.NET, java или любой подобной абстракцией над ОС и её API). С ОС API должны лишь общаться сами среды или другая часть ОС. Что на счет драйверов? Необходимо разработать драйверную модель полностью абстрагированную от API OS! Драйвер должен быть написан для некой драйверной среды как прикладное ПО пишется для среды .NET или Java. Драйвер должен через эту среду устанавливаться и через среду (И ТОЛЬКО ЧЕРЕЗ НЕЁ!) использовать системно зависимые сущности для работы с аппаратурой. Порты ввода вывода, работа с памятью, PIO, DMA ну и так далее. Драйвер не должен вообще знать, как и каким API это реализовано относительно каждой ОС! Об этом должна знать ТОЛЬКО его runtime среда! Если на какой либо ОС присутствует эта runtime среда драйверной модели, то драйвер может быть использован! Так я вижу концепцию кросс-платформенных драйверов. Не знаю, может это и так всем понятно, может её уже предлагал кто то, но мне вот вчера вечером пришло это всё в голову. Стройной стала вся концепция. Вот вам и связка, язык а-ля .NET для ПО не являющегося частью ОС или не являющегося runtime средой. Для runtime сред и частей ОС - API C++. API C++ использует уровень HAL C. Ну и внизу немножко ассемблер - архитектурно зависимая часть. Поменяв ядро ОС и даже её API никуда не денется разработанное ПО и драйвера. Всё будет прозрачно функционировать на другой ОС где есть runtime для прикладного ПО и драйверов. Исключая ессесно случаи когда ПО взаимодействует с другим ПО которого на другой ОС нету Фуххх. Вроде видение современной ОС выдал. Если совместить с первым постом. Прошу прощения если несколько скомкано и поверхностно. Я тут пытаюсь просто предложить концептуальные подходы решение о которых принимается при проектировании. По-моему если ещё все предложат свои идейки - есть из за чего городить огород . Проект в плане с открытой документацией. А не реализацию. Почему то большинство начинает снизу. Сначала зафигачим ядро и компилятор а как там все наверху будет - насрать. Заканчивается всё на консольной однозадачной ОС я так понимаю с непонятным API <span class='smallblacktext'>[ Редактирование вторник 13.03.2007 12:18 ]</span> | ||
| Наверх | | ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Некоторые проекты вообще заканчиваются на уровне разговоров.. Дык я всеравно не понимаю нафига ограничивать то... Единственое, что должно быть - это интерфейс системы для регистрации и вызова соответствующих примитивов. на каком языке написаны примитивы - абсолютно без разницы. Ты пишешь слишком много букв... лишних букв... Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | Я предлагаю мать её концепцию. Объясняю почему С и С++ для прикладного ПО это плохо | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | Я если ты заметил щас вообще не про примитивы Я про API и драйверную модель А примитивы куда хош можно прикрутить | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | И НИКТО НИКОГО НЕ ОГРАНИЧИВАЕТ ! я же говрю .. языков реализовано под MSIL CLR дахрена .. и С++ в первую очередь И ещё не 1 десяток от фортрана до java используй что хочешь ! НИКТО НИКОГО НЕ ОГРАНИЧИВАЕТ! <span class='smallblacktext'>[ Редактирование вторник 13.03.2007 12:54 ]</span> | ||
| Наверх | | ||
| ddc |
| ||
| Free Software Zealot ID пользователя #202 Зарегистрирован: Воскресенье 06.02.2005 09:32Местонахождение: Москва Сообщений: 189 | Jurik Я это всё читал. По сути отличий от варианта интерпретируемых языков не вижу. Хотя конечно можно довести ситуацию до абсурда и превратить программы в только компановку примитивов. Но тогда система просто умрём от DLL Hell, если конечно до этого кто-то её захочет использовать - огромную, тормознутую. Смысл в такой ОС есть только для постоянно нагруженных систем, в которых стабильность, напрочь исключаемая такой компонентной моделью, критична. Но это всё, конечно, моё сугубо личное мнение... | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2dcc Ничего до обсурда доводить не надо. Прсото надо функционал не жестко вшивать в API я делать следующий уровень из примитивов которые могут быть оптимизированны! DLL Hell зависит от реализации а не от примитивов как концеции. Если делать глупо то будет dll hell. Если делать по уму в изолированных сборках или ещё как то то - никакого dll hell не будет в принципе! Я ещё раз прошу. Предложи на рассмотрение свой подход. Я свой предложил. Я считаю что пока критика если и идет то не на чем не освнованная. основанная на каких то прикидках что будет как пентиум 2 или не будет. будет огромна или не будет. Будет компонентна и стабильна или будет громоздка. Писями по воду виляно всё это. Свой вариант предлагай если хочешь. И четкое доказательство несостоятельности этого варианта с бенчмарками в студию | ||
| Наверх | | ||
| Переход на страницу 1 2 3 ... 5 [6] 7 ... 15 16 17 | |
Powered by e107 Forum System