Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 2, Пользователей: 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 4 [5] 6 ... 15 16 17 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| Jurik |
| ||
 ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | Глаза не боятся .. Но слава богу есть хоть сколь нибудь адекватное понимание объема работы. По этому я и говорю - если есть желающие давайте. Хоть на уровне проекта может появится ОС созданная в России  Не очередная сборка Линукс а своя ОС... | ||
| Наверх | | ||
| Dron |
| ||
   ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | А ты начни... Кстати ты пока никаких реальных предложений тоже не внес... идея разумная а что дальше? Можем поговорить и про конкретные API... Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Hmmm |
| ||
  ID пользователя #719 Зарегистрирован: Среда 09.08.2006 11:29Местонахождение: Москва Сообщений: 108 | А в чем проблемы? Есть Linux, есть FreeBSD, есть Open Solaris, это из крупных, тех что помельче вообще как звезд на небе. Системы уже работающие и с исходниками. Взять и написать "добавку" предоставляющую дополнительный интерфейс, назвать ее JurikThreads например. Если ядро мешает - подковырять его в нужном направлении. Куча рутины уже сделана. Короче было бы желание. | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2Dron Предлагаю на рассмотрение идею применения .NET подобной системы. основной язык разработки ПО C#. Системное ПО (драйвера, сервисы и т.д.) можно то же писать используя С# используя соотв. разроботанные интерфейсы и API для написания низкоуровневого ПО. Прлблем по моему принципиальных нету ? Windows Service в конце концов без проблем пишутся на C#. Каак кто смотрит на то что бы основные задачи решались мощностью API а не языка ? 2Hmmm тогда нверное логичне взять какую либо ОС с микроядерной архитектурой. Mach\Hurd\Minix ... правда по моему в Minix потоков нету ? | ||
| Наверх | | ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Почему именно C#? Вообще не понимаю причин, побудивших тебя сразу называть язык. API - для начала не должно зависеть от языка. PS: Лично я не знаю C#, и NET тоже не знаю. Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2Dron По многим прчинам. Что это современный мощный язык это понятно. Потому что называя C# я сразу имел ввиду .NET похожий API (С# язык от API неотделим). ещё потому что это стандарт, наглухо компонентный подход, генерирует промежуточный код который может генерить много какой язык, строгая типазация из чего вытекает например упрощенная работа с памятью (указателей нет в safe коде, по моему в singulrity даже без виртуальной памяти для процессов обошлись ..память вся плоская .. типобезопасность на уровле концепции языка... могу что то путать...) ... и так далее. Не использовать же в проектироумой современной ОС даже к примеру С++. Уже есть более современный язык. Куда более удобный, более ОО и не менее мощный. Ваши предложения ? <span class='smallblacktext'>[ Редактирование понедельник 12.03.2007 17:55 ]</span> | ||
| Наверх | | ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Ось под NET - это конечно хорошая шутка... Почти то же самое, что и JavaOS. Когда речь идет о распределенных вычислениях, Разговор про указатели опять таки некорректен. Ибо передавать указатели по сети - бессмысленно. Следовательно не понятно зачем вычеркивать все что есть, ради новомодного NET? ИМХО надо максимально использовать все имеющиеся наработки... C++ и C - замечательные языки. Вообще я все веду к тому, что язык - это лишь средство... не надо средство возвеличивать до основы основ. PS: Тем более что речь шла про высокий КПД... это у NET то высокий КПД? ассемблер!  Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| ddc |
| ||
Free Software Zealot  ID пользователя #202 Зарегистрирован: Воскресенье 06.02.2005 09:32Местонахождение: Москва Сообщений: 189 | Jurik написал(а) ... Я такого не говорил. Однако, если архитектуры процессоров в системе несовместимы, остаются два варианта:Незнаю почему ты упорно думаешь что универсальный = x86 1. Та же фигня, что и с CUDA - каждое приложение запускается либо на одном процессоре, либо на другом. Никакого динамического разделения нагрузки. 2. Архитектурно-зависимый интерпретатор одного и того же языка на каждом процессоре. Тогда при определённых задачах система может оказаться чуть-чуть быстрее классической. Но в большинстве случаев она будет медленней, причём зачастую - намного. Jurik написал(а) ... Всё равно, что про SSE3 говорить, что это универсальный набор инструкций...(читай про шейдеры 4.0) Jurik написал(а) ... Ещё раз: само по себе это ничего не доказывает.По поводу его универсальности см. ниже и до кучи на нем реализован движок физических расчетов. Jurik написал(а) ... Цифры? Нет? Ну извините, голосовным утверждениям не верю.А по скорости .. я бы не стал называть это 486 Jurik написал(а) ... И что? Это тоже само по себе ни о чём не говорит. А если учитывать, что G80 аппаратно ускоренно обрабатывает много инструкций, можно предположить, что большая часть чипа (а именно всё кроме его 8 (?) ядер и контроллера памяти) просто простаивает большую часть времени при любой степени нагрузки.Кол-во транзисторов в G80 в более чем в 2 раза превосходит Core 2 duo Jurik написал(а) ... Вот это ты лучше вообще больше не повторяй. Не бывает "внутри" RISC. Есть инструкции, которые принимает процессор, и продукты их обработки. i386 тоже не все инструкции в лоб считал.И ещё. x86 это вообще интерфейс оставленный для совместимости и больше ничего. Внутри давно уже RISK а может и VLIW. Кстати говоря, по сути это утверждение тоже не верно, потому как помимо пресловутых µ-ops (буду пользоваться этим словом, поскольку Intel внятного названия так и не придумала) есть ещё инструкции SSE*, которые не бьются, а обрабатываются с аппаратным ускорением. Т.е. 32 (?) бита + 128 бит. Уже не RISC. Jurik написал(а) ... Уже смешно. Погугли по ключам VLIW и EPIC. Т.е. формально он конечно VLIW, но по сути он работает по-другому.VLIW всего лишь один из подходов к архитектуре CPU и кстати живет и здравствует (Intel Itanium). Jurik написал(а) ... Дело не в Transmeta, и даже не в архитектуре. Дело в том, что самой по себе красивой идеи недостаточно.По одной Transmeta как то судить о целом подходе в архитектуре CPU... Jurik написал(а) ... Сами авторы бенчмарка говорят о том, что реализация FFT, используемая для Xeon, сама по себе слабей. Ты бы ещё сравнил скорость сборки экспериментального кода на CUDA'вском компиляторе и GCC4 под linux 0.01... Если так нужны бенчмарки и рабочие прототипы и работающих движков фикизи на 3д ускорителях мало, и недостаточно NVidia CUDA, сложно нарыть в сети, то вот :http://gamma.cs.unc.edu/GPUFFTW/results.html Но это всё, конечно, моё сугубо личное мнение... | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2dcc 1 -Если ыт читал о чем я писал то как раз я и привел на рассмотрение третий вариант  )))))))2-Я привел более чем понятные данные. не верить твое право. . Можешь дальше утверждать что в FP CPU бытрее GPU. Флаг в руки . При таком подходе ещё что то доказывать считаю глупым 3 - ДА ДА! именно бывает ВНУТРИ RISK ! Иба есть decoer x86 инструкций. Он декодирует из CISC в RISK и фигачит. И SSE не обрабабывается с аппаратным ускорением Ты этого не говори ни у AMD ни у Intel в процах НЕТ БЛОКА SSE! И про FFT реализаци. Я ничего не знаю конечно о слабой реализации под Xeon но и под Athlon она то же слабая? и прям в 8 раз хуже ? а по сравнению с G80 я уверен раз в 20 слабее... и всё из за недостатка оптимизации под CPU ? смешно .. )))Я привел тебе данные и результаты тестирований. Статьи и мнения. Ты что привел в доказательство ? НИ ЧЕ ГО.Так или иначе во многих задачах GPU или другие устрйоства могут бысть БЫТРЕЕ CPU. Но дело даже не в быстрее а в распределении вычислений. ПРОЗРАЧНОМ. Почему ты упорно не хочешь рассмотреть возможность задействовать простаиваемые мощности и не получить выйгрыш от разгруженного CPU? <span class='smallblacktext'>[ Редактирование понедельник 12.03.2007 22:58 ]</span> | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2Dron Про c# я ещё в статье указал. Так как .NET это компилятор его КПД зависит от качества компилятора. Так как это MSIL компилятор получает возможность оптимизировать под используемый CPU. Да у него высокий КПД. Вообще с этим подходом у .NET API замечательный. Удобный просто прелесть. Совершенно прозрачная работа с компонентами. Я не говорил что ядро должно быть на .NET. В этом смысле никакой javaOS и .NETOS я не предлагаю. Пусть ядро будет на С и ассемблере. Основываясь на подходах .NET я предллагаю писать ПО для ОС а не саму ОС Он не новомоден. Ему уже лет 5? Уже вышел c# версии 2.0. Он удобен (сборка мусора, все сущности - объекты!, вроде как невозможно переполнение буфера), быстр, отлично подходит из за MSIL. Он гораздо больший ОО чем С++! MSIL код так большой плюс вообще. В плане возможностей с оптимизацией. Ещё в отличие от С и С++ ПОЛНАЯ кроссплатформенность. Под другой архитектурой (CPU а не API) прогу запускешь - так тебе её JIT на лету перекомпайлил и в кэш сборок бинарник оптимизированный кинул. Даже и не паришся с перекомпиляцией. С С++ замечательные языки. Правда устарели во многом. Удобство не то. То что пишется на c# за неделю на С++ пишется за месяц и ещё ошибок в 10 раз больше . C# на порядок удобнее и изящнее чем с++. С создавался как замена ассемблеру. это обстракция над железом. это не язык высокого уровня. что угодно но не язык высокого уровня в современном понимании. К нему припаяли классы. Учень много появилось дублирующих сущностей. работа с указателями, возвращаемые коды... Средства ОС отделены от него нафиг! есть свой API но неприменно нужно пользоваться API ОС в современной жизни (кроме простых консольных приложений). Он не имеет понятия о таких необходимых в современной ОС вещх как многопоточность, многопросеццность, IPC. Синхронизация потоков. GUI. там ничего этого нет в помине. Когда пишешь прогу под ОС она становится НЕПЕРЕНОСИМА на другую ОС если круто не морочится. фактически надо переделывать ПО. даже низкоуровневые сущности ОС не могут быть управляемы на уровне языка! Короче ..я немного щас пьян. в общем что у него куча минусов это детский сад. эжто и так понятно. С# же совмещен с API которое содержит в себе всё необходимо в современной ОС, это обстракция не над железом а над ОС. Над API OS если хотите. ПО созданное на C# переносимо куда угодно где есть СРЕДА .NET (среда исполнения C# кода и API вызовов). Программа получается на 100% отвязанна от операционки. В любой ос ты по одному принципу работаешь. Многопоточность, IPC, ООП во всем, API для работы с GUI да что угодно. всё это часть ЯЗЫКА. он естественнен. Там нет дублирования на разных уровнях. там 1 уровень. И тебе язык и среда и API. java это интерпритатор а .NET компилятор. так что сравнение не то. У тебя есть причиты не использувать удобства и мощь .NET подхода? В общем я не претендую на то что бы .NET подход был эсклюзивен для перспективной ОС (в плане API) но то что ПРИКЛАДНОЕ По должно писаться на нем или на подобном языке это факт. Ниже может быть уровень C++ API OS которое реализует средства ОС типа потоки, задачи, GUI.... Ниже уровень С API которое будет просто абстрагировать железо... Понятно что часть ОС должна быть обязательно на низкоуровневым языке. Вопрос в том должна ли она содержать API... надо рассматривать все эти подходы. Если кроме safe c# ничего нету то можно не боясь реализовывать плоскую модель памяти для всех процессов как в singularity... вообщем хз... предлагайте вырианты на рассмотрение... Прошу прощения что увлекся. Я просто не расмтриваю проект как низкоуревневую чать. Как там ядро реализует ту или иную функциональность и так далее. Я смотрю на всё с верху.. с простого ..с концептуального. <span class='smallblacktext'>[ Редактирование вторник 13.03.2007 02:27 ]</span> | ||
| Наверх | | ||
| Переход на страницу 1 2 3 4 [5] 6 ... 15 16 17 | |
Powered by e107 Forum System