Здравствуйте, Sinclair, Вы писали: S>Гм. Модель памяти в шарпе не включает в себя ни страниц, ни подкачки. Именно поэтому программу можно исполнять на любой технологической базе, в том числе и на сегментной модели памяти, и на flat модели с подкачкой. Всеми вопросами исполнения new A() занимается рантайм.
Ааа. Это Вы к фразе. Pzz> А для автоматического управления по-моему ничего более удобного, чем плоская память с постраничной подкачкой, еще не изобрели.
Здравствуйте, TarasCo, Вы писали:
TC>Что будет через 10-15 лет:
Поживем-увидим. Я на всякий случай этот месадж в избранное добавлю, через 10 лет апнем темку ))) Хотя есть у меня ощущение, что вы сейчас стебётесь.
TC>1) Один процесс — одна операционная система. Куча операционных систем будет жить на одном гипервизоре.
А нафига, собственно, козе баян? Давайте забудем на некоторое время про серверные платформы (там, где это надо — оно применяется), и подумаем об обычных десктопах. Какая на десктопе принципиальная разница: несколько однозадачных ОС, по одному процессу на каждую или одна многозадачная с изолированными процессами? Изолированные процессы — это же тоже виртуализация, только не на уровне ОС, а на уровне процесса, и для изоляции процессов также существуют и развиваются аппаратные средства.
TC>2) Системы с управляемым кодом TC>3) Это все будет скомбинировано ( так и будет, не сомневайтесь ). В итоге на вашей станции будет несколько микроядер, ориентированных на различные задачи — графика, интернет, работа с дисковыми массивами.
В любом случае придется организовывать взаимодействие между процессами, запущенными под разными ядрами (игры ведь на дисковый массив устанавливать будете?). Так что в итоге Ваш десяток ядер будет завязан друг на друга, и вы получите те же яйца, вид сбоку: микроядерную архитектуру.
Все, что Вы предлагаете — это микроядерная архитектура, где микроядро реализовано аппаратно: гипервизор Ваш и будет микроядром, отвечающим за изоляцию и взаимодействие серверов (которые Вы обозвали ядрами), каждый из которых обслуживает одного клиента (приложение), а, может, и не одного. Будет ли такая архитектура удачнее, чем продукт 10-15-ти летней эволюции Linux/Windows и аппаратных средств — увидим.
TC>Чего не будет: TC>1)Гигантских "изолированных" плоских виртуальных моделей памяти,
А какая модель памяти в приложении будет? Мы тут только что говорили, что плоская модель вполне состоятельна.
TC>которые надо постоянно свопить, защищать с помощью всяких DEP и.т.д
Не будет подкачки? Т.е у нас будут терабайты супербыстрой супердешевой памяти?
TC>2)Вытесняющей многозадачности, с этими бесконечными ( по сравнению со временем выполнения инструкции ) слайсами и постоянными загрузками и выгрузками контекстов и полной индифферентности к реальному времени.
А какая будет многозадачность? Или Каждому процессу по процессору?
TC>3)Драйверов, которые могут в любой момент уронить все систему или сожрать все память
Что будет управлять периферией?
TC>4)Вирусов и антивирусов в том виде, как он существуют сейчас
А это-то каким боком? Похоже, что Вы реально стебётесь.
C>Делись. Новый scheduler в Линуксе для переключения учитывает реальную статистику использования процессора, а не количество слайсов, например.
В висте тоже. Учитывается время, потраченное обработчиками прерываний в контексте текущего потока и прочие системные мудрости. Т.е планировщик смотрит, сколько сам поток работал и в соответствии с этим принимает справедливое решение .
Но это все, лишь доказательство моих слов. Архитектурные близнецы Linus и Windox достигли всего, что можно было выжать из этой архитектуры. Уже начинается погоня за копейками. А ведь система могла бы без всякий переключений и синхронизаций просто тупо дергать за различные маленькие тупенькие, написанные на управляемом коде, объектики и не тормозить ВООБЩЕ. Вершина и конец изолированных адресных пространств процессов — это наличие кучи различных методов, как это дело обойти, которые предоставляет сама же система!!! Эта такая компьютерная коррупция — закон, что дышло .
Здравствуйте, Sinclair, Вы писали:
S>Нет, аппаратная защита придумана чтобы нельзя было нарушить изоляцию. И проблема не в размере программ, а в стоимости аппаратной изоляции: она становится барьером к дальнейшему росту производительности.
Изоляцию можно делать либо с помощью аппаратной защиты, либо чисто в софтварии. Совсем ее не делать нельзя, вы согласны?
Так вот, по-моему очевидно, что если использовать аппаратную поддержку, то производительность всяко будет больше, чем если не использовать.
Pzz>>Обратите внимание, что если в языке нет указателей и адресной арифметики, то и managed код не нужен. S>Обрати внимание, что если в языке нет указателей и адресной арифметики, то это — управляемый язык.
Ocaml — это управляемый язык?
Pzz>>Ручное управление памятью явно уходит в прошлое. S>Пока что этого не видно.
Видно. Языки более высокого уровня, чем C++, имеют явную тенденцию в первую очередь избавить программиста именно от ручного выделения/освобождения памяти.
Pzz>> А для автоматического управления по-моему ничего более удобного, чем плоская память с постраничной подкачкой, еще не изобрели. S>Автоматическое управление подразумевает отсутствие таких понятий, как страница и подкачка. Автоматика — это A a = new A(); и всё.
Автоматика, это когда вы имеете дело со значениями, а о том, где их разместить, заботятся за вас . new это уже ручной режим.
Но суть не в этом. Страницы/подкачка у нее под капотом. Прикладному программисту этого не видно.
S>На мой непросвещенный взгляд, в приведенной статье речь не об этом. Слайсы никуда не делись — убрали только непрерывное пробуждение системы даже если все потоки сделали sleep(). S>Если в системе больше активных потоков, чем есть ядер в процессоре, то в любом случае придется их переключать — именно об этом говорит Тарас.
Тогда я не очень понимаю, о чем говорит Тарас. Надо ли его понимать в том духе, что параллельные вычисления (в виде явных потоков) нас покунут? Или он хочет сказать, что нас ждет революция в области скедулеров?
Pzz>>Драйвер корневой файловой системы, или диска на котором живет эта файловая система, в случае падения все равно сломает всю систему, даже если его изолировать. S>Нет конечно. В хорошо изолированной системе падение драйвера корневой файлухи лечится перезапуском драйвера.
А что будет при этом с открытыми файлами?
S>Падение диска — более редкая штука; но изолированную систему не сломает и оно — просто придется откатиться к предыдущему save point.
Падение и перезапуск диска IMHO проще обработать прозрачно для приложений, чем падение файловой системы.
S>>Если в системе больше активных потоков, чем есть ядер в процессоре, то в любом случае придется их переключать — именно об этом говорит Тарас.
Pzz>Тогда я не очень понимаю, о чем говорит Тарас. Надо ли его понимать в том духе, что параллельные вычисления (в виде явных потоков) нас покунут? Или он хочет сказать, что нас ждет революция в области скедулеров?
Да, революция. Сейчас шедулер построен по принципу полной независимости от кода. И правильно. Он ему не может доверять — код то сцука опасен . Поэтому он сам переключает потоки на основе самых общих представлениях о них. Если шедулер будет доверять коду ( а код у нас управляемый — читай, ему можно доверять ), возможны настолько гибкие алгоритмы разделения процессорного времени, что мне даже не придумать с ходу .
А самое главное, потоки то вообще зачем нужны? Кто-нибудь может привести пример, зачем нужен поток, который тянется многие секунды и переживает тысячи переключений контекста? Практически все задачи можно разбить на последовательность мелких задачек, которые при условии что они работают в системе с управляемым кодом могут выполняться в едином аппаратном контексте процессора и памяти. Возьмите гуйню — поток спит, иногда выполняет коротенькие операции с оконной подсистемой. Зачем тут именно поток, со своим стеком? Единственный класс задач, где требуется именно потоки в нашем традиционном понимании — это длительные вычисления. Так может для них просто написать классик, который будет эмулировать традиционную многопоточность?
Здравствуйте, TarasCo, Вы писали:
TC>А ведь система могла бы без всякий переключений и синхронизаций просто тупо дергать за различные маленькие тупенькие, написанные на управляемом коде, объектики и не тормозить ВООБЩЕ.
Хорошо. Вот тебе псевдокод на некоем управляемом языке:
Thread t1 = new Thread(LargePrimeComputer.Compute);
Thread t2 = new Thread(LargePrimeComputer.Compute);
t1.Join();
t2.Join();
Как идеологически правильная ОС распределит процессорное время между этими задачами, если их больше, чем процессоров?
Здравствуйте, TarasCo, Вы писали:
TC>А самое главное, потоки то вообще зачем нужны? Кто-нибудь может привести пример, зачем нужен поток, который тянется многие секунды и переживает тысячи переключений контекста? Практически все задачи можно разбить на последовательность мелких задачек, которые при условии что они работают в системе с управляемым кодом могут выполняться в едином аппаратном контексте процессора и памяти. Возьмите гуйню — поток спит, иногда выполняет коротенькие операции с оконной подсистемой. Зачем тут именно поток, со своим стеком? Единственный класс задач, где требуется именно потоки в нашем традиционном понимании — это длительные вычисления. Так может для них просто написать классик, который будет эмулировать традиционную многопоточность?
Поздравляю, ты изобрел Erlang. Только для этого совсем не нужен управляемый код.
Здравствуйте, TarasCo, Вы писали:
TC>Но это все, лишь доказательство моих слов. Архитектурные близнецы Linus и Windox достигли всего, что можно было выжать из этой архитектуры. Уже начинается погоня за копейками. А ведь система могла бы без всякий переключений и синхронизаций просто тупо дергать за различные маленькие тупенькие, написанные на управляемом коде, объектики и не тормозить ВООБЩЕ.
Я уже как-то писал как можно сделать очень дешовое переключение между контекстами. Оно может быть лишь чуть медленнее обычного вызова функции.
Здравствуйте, Pzz, Вы писали:
Pzz>Изоляцию можно делать либо с помощью аппаратной защиты, либо чисто в софтварии. Совсем ее не делать нельзя, вы согласны?
Не согласен, можно, если статически доказано, что выполняемый код не портит чужую память.
Здравствуйте, TarasCo, Вы писали:
TC>Да, революция. Сейчас шедулер построен по принципу полной независимости от кода. И правильно. Он ему не может доверять — код то сцука опасен . Поэтому он сам переключает потоки на основе самых общих представлениях о них. Если шедулер будет доверять коду ( а код у нас управляемый — читай, ему можно доверять ), возможны настолько гибкие алгоритмы разделения процессорного времени, что мне даже не придумать с ходу .
Управляемому коду можно доверять в том плане, что он сам себе по памяти не проедется. Но в том плане, что он не задумал недоброе, ему доверять нельзя. Иначе нужен не только управляемый код, а еще и управляемые разработчики и управляемые пользователи
Придумайте хоть один алгоритм для скедулера, который 1) имеет практический смысл 2) implementable в принципе 3) не implementable из-за того, что код не managed. Тогда будет от чего отталкиваться в разговоре.
TC>А самое главное, потоки то вообще зачем нужны?
Потому, что многим кажется, что так думать проще, чем в стиле конечного автомата.
А переключалку потоков можно и в user space вынести. Не так уж ей и много надо от операционной системы.
Здравствуйте, Ночной Смотрящий, Вы писали:
Pzz>>Изоляцию можно делать либо с помощью аппаратной защиты, либо чисто в софтварии. Совсем ее не делать нельзя, вы согласны?
НС>Не согласен, можно, если статически доказано, что выполняемый код не портит чужую память.
Во-первых, в общем случае эта задача по-видимому алгоритмически неразрешима.
Во-вторых, программа может не портить чужую память, и при этом быть вредной. Например, она может открывать документы, и заменять приличные слова на неприличные. Я не могу придумать компьютерно-проверяемый формальный критерий, позволяющий отличить такую программу от программы, которая делает с документами что-то полезное.
Во-третьих, возникает организационный аспект. Когда пользователь ставит программу на систему, откуда система знает, что для этой программы что-то там статически доказано? Очевидно, что эта задача разрешима только если ввести обязательное гослицензирование всех поставщиков программ. Я не хотел бы жить в таком мире
Roman Odaisky пишет: > > Здравствуйте, Impuls, Вы писали: > > TC>>>Столлман повеситься > > _>>Это приказ? > > I>Нет , наверное предсказание > > Глагол употреблен или в инфинитиве, или в повелительном наклонении, но > никак не в личной форме.
Да там то ли точки посередине, то ли скобок вокруг слов не хватает
Pzz пишет: > > Во-третьих, возникает организационный аспект. Когда пользователь ставит > программу на систему, откуда система знает, что для этой программы > что-то там статически доказано? Очевидно, что эта задача разрешима > только если ввести обязательное гослицензирование всех поставщиков > программ. Я не хотел бы жить в таком мире
Если из дистрибутива, то подпись дистростроителя, если чужая — то из
исходников собрать.
Здравствуйте, OCTAGRAM, Вы писали:
>> А статически доказывать тоже самому, из исходников?
OCT>А в чём проблема? Если ограничиться доказательством целостности, обычно OCT>там несложные проверки, и для всего есть готовые инструменты.
Проблема в том, что большинству людей программы нужны, чтобы поставить и пользоваться, а не статически доказывать.
Я уж не говорю о том, что доказать можно (да и то под вопросом, поскольку по-моему это эквиавалентно доказательству завершения алгоритма за конечное число шагов, что для Тьюринг-полных машин является алгоритмически неразрешимой задачей), что программа не убъет саму себя. То, что она не убъет что-то еще, не в следствии ошибки, а по злому умыслу, доказать невозможно. Хотя статически проверенная программа наделает гадостей с особой надежностью
Pzz пишет: > > Здравствуйте, OCTAGRAM, Вы писали: > >> > А статически доказывать тоже самому, из исходников? > > OCT>А в чём проблема? Если ограничиться доказательством целостности, обычно > OCT>там несложные проверки, и для всего есть готовые инструменты. > > Проблема в том, что большинству людей программы нужны, чтобы поставить и > пользоваться, а не статически доказывать. >
"Статически доказывать" — часть сборки из исходников. Если из исходников
не собирать, то возможен вариант TAL — Typed Assembly Language, когда к
бинарному коду прилагаются аннотации, по которым можно проверить
сохранение целостности запускаемой программы.
> Я уж не говорю о том, что доказать можно (да и то под вопросом, > поскольку по-моему это эквиавалентно доказательству завершения алгоритма > за конечное число шагов, что для Тьюринг-полных машин является > алгоритмически неразрешимой задачей), что программа не убъет саму себя.
Обычно рассматривают не все допустимые варианты ассемблерных извращений,
а некоторое высокоуровневое подмножество программ. Для Oberon–2 можно
проверить неиспользование псевдомодуля System, для Ады запустить
gnatcheck или AdaControl. Аналогично в любом другом языке. Только и всего.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Pzz пишет: >> >> А статически доказывать тоже самому, из исходников?
OCT>А в чём проблема? Если ограничиться доказательством целостности, обычно OCT>там несложные проверки, и для всего есть готовые инструменты.
kochetkov.vladimir пишет: > > Здравствуйте, OCTAGRAM, Вы писали: > > OCT>Pzz пишет: >> > >> > А статически доказывать тоже самому, из исходников? > > OCT>А в чём проблема? Если ограничиться доказательством целостности, обычно > OCT>там несложные проверки, и для всего есть готовые инструменты. > > А если я не верю производителю?
.
.
