Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Serginio1, Вы писали:
S>>А есть уже практическое применение Singularity, хотя бы как Оберон систем WH>Не думаю ибо эта ОС изначально задумывалась исключительно как эксперимент.
OS Inferno изначально не задумывалась, как эксперимент. Работает, применяется (по крайней мере, на сайте так)
Здравствуйте, Курилка, Вы писали:
К>Зависимые типы они круты, безусловно, но вот, а какие ещё проблемы может дать "нехороший" код, которые зависимые типы должны по идее разрешить, кроме порчи памяти? В голову пока приходит только захват ресурсов (в т.ч. памяти), который будет мешать другим процессам (и ядерным возможно).
Я склоняюсь к мнению что примитивом общения между процессами должны быть каналы аля сингулярити.
Собственно зависимыми типами можно проверять что протокол отработан верно и что канал будет непременно закрыт.
Плюс можно доказывать отсутствие циклов и прочих задержек в критичных по времени местах.
И много чего еще что так с ходу не придумать.
Да и просто устранение проверок времени исполнения мягко говоря лишним не будет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Не думаю ибо эта ОС изначально задумывалась исключительно как эксперимент.
Да уж отстал от жизни, уже Midori появилась http://www.nestor.minsk.by/kg/2008/32/kg83205.html
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Chrome, Вы писали:
C>Здравствуйте, thesz, Вы писали:
T>>Здравствуйте, Chrome, Вы писали:
C>>>Или его со временем полностью вытеснит верифицируемый промежуточный код? T>>Нет.
Промежуточный код требует накладных расходов — например, профилирование для JIT имеет O(размер программы) накладных расходов (точки съёма времени).
Эти расходы удорожают массовые встраиваемые системы, например, автомобильные.
C>>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы? T>>Нет.
Эти расходы можно свести к минимуму. Например, программа на машине динамического потока данных может выполняться параллельно с обновлением TLB по ошибке обращения к памяти.
C>>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства? T>>Нет.
Это следствие из двух предыдущих пунктов.
C>Интереснее было бы услышать аргументы, а не авторитетное мнение.
Я посмотрел на пару первых ответов, и решил, что так и надо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Промежуточный код требует накладных расходов — например, профилирование для JIT имеет O(размер программы) накладных расходов (точки съёма времени).
А что обязательно постоянно профилировать?
ИМХО это опциональная возможность причем далеко не факт что вообще полезная.
Да и кросскомпиляцию никто не отменял.
Какие еще накладные расходы придумаешь?
А если есть наличие зависимых типов и как следствие кучи доказательств того что во многих местах проверки времени исполнения не нужны.
T>Эти расходы удорожают массовые встраиваемые системы, например, автомобильные.
Или наоборот за счет того что можно например отказаться от виртуальной памяти?
Да и сам процессор можно сделать без лишних заморочек типа слоя совместимости с x86.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, thesz, Вы писали:
T>>Промежуточный код требует накладных расходов — например, профилирование для JIT имеет O(размер программы) накладных расходов (точки съёма времени). WH>А что обязательно постоянно профилировать?
Я думаю, что желательно.
WH>ИМХО это опциональная возможность причем далеко не факт что вообще полезная.
Вот и ответ на "полное вытеснение нативного кода". Там, где это полезно, то лучше использовать нативный код.
Это просто ещё один полутон в радуге.
WH>Да и кросскомпиляцию никто не отменял.
Последнее означает "нативный код".
Не будешь же ты держать на микроконтроллере компилятор и компилировать программу при загрузке.
WH>Какие еще накладные расходы придумаешь?
Да уже имеющихся достаточно.
T>>Эти расходы удорожают массовые встраиваемые системы, например, автомобильные. WH>Или наоборот за счет того что можно например отказаться от виртуальной памяти?
Виртуальная память влияет на производительность, накладные расходы в железе для неё минимальны (для реализации SPARC v8 под названием Leon3 и для известных мне вариантов MIPS — примерно размер регистрового файла, который сам ~10% от площади ядра микропроцессора). Для x86 успешное обновление TLB при промахе занимает ~400 тактов, для MIPS — ~40.
Так что для RISC процессоров расходы на виртуальную память не такие уж и большие. А для систем с большим ILP, например, WaveScalar, обновление TLB может происходить без остановки вычислений в целом. Как и переключение задач.
WH>Да и сам процессор можно сделать без лишних заморочек типа слоя совместимости с x86.
А это-то здесь при чём?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Chrome, Вы писали:
C>>>Или его со временем полностью вытеснит верифицируемый промежуточный код?
PD>>Нет. C>Даже в случае проектируемой с нуля какой нибудь будущей ОС?
Только если эта ОС будет работать на некотором верифицируемом интеллектуальном процессоре
C>>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
PD>>Нет. C>А зачем оно будет нужно?
За тем же, зачем и сейчас. См. ниже.
C>>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
PD>>Не знаю. Совместное адресное пространство было уже (Win16), ничего хорошего из этого не вышло. Однако даже отвергнутые идеи имеют иногда способность возвращаться . В ближайшем будущем все же нет.
C>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?
Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ? В то время как в модели user/superwisor это решено аппаратно.
Здравствуйте, Chrome, Вы писали:
C>Или его со временем полностью вытеснит верифицируемый промежуточный код? C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы? C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
Взял на себя смелость устроить 3 голосования по этим вопросам.
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?
PD>Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ? В то время как в модели user/superwisor это решено аппаратно.
А в аппаратной чати не бывет багов? В конце концов алгоритмы, зашитые в железе тоже верифицируются каким-то софтовым верификатором (я не в курсе, но думаю где-то так и есть).
C>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?
PD>Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ? В то время как в модели user/superwisor это решено аппаратно.
а где гарантии, что код, исполняемый в режиме ядра не содержит ошибок?
код верификатора все же покомпактней будет.
Здравствуйте, jedi, Вы писали:
J>А в аппаратной чати не бывет багов?
А это просто за пределами обсуждения темы ОС. Если там есть баги (до сих пор багов, связанных с защищенным режимом вроде не было), то надо исправлять процессор, а это не наша тематика.
Здравствуйте, Chrome, Вы писали:
C>а где гарантии, что код, исполняемый в режиме ядра не содержит ошибок?
Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.
Черт! Поставил "показывать результаты только проголосовавшим", а в итоге не смог их сам посмотреть. Обычно я в мной созданных голосованиях не голосую, а тут пришлось
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, jedi, Вы писали:
J>>А в аппаратной чати не бывет багов?
PD>А это просто за пределами обсуждения темы ОС. Если там есть баги (до сих пор багов, связанных с защищенным режимом вроде не было), то надо исправлять процессор, а это не наша тематика.
Исправлять софт дешевле... Именно по этой причине мы до сих пор имеем generic-purpose процессоры, а не специализированные под работу в инете, редактирование документов и раскаладывание косынки
Здравствуйте, thesz, Вы писали:
WH>>А что обязательно постоянно профилировать? T>Я думаю, что желательно.
Зачем?
Можно ли за счет этого получить реальное ускорение на реальных задачах по сравнению с хорошим статическим оптимизатором?
А если этот оптимизатор еще и магию применять умеет типа перевода программы в АМС и обратно?
WH>>ИМХО это опциональная возможность причем далеко не факт что вообще полезная. T>Вот и ответ на "полное вытеснение нативного кода". Там, где это полезно, то лучше использовать нативный код.
Не понял. Ты что нативный код хотспотить собрался?
WH>>Да и кросскомпиляцию никто не отменял. T>Последнее означает "нативный код".
Но этому коду уже не нужна никакая защита.
Он доказано корректен.
T>Не будешь же ты держать на микроконтроллере компилятор и компилировать программу при загрузке.
Вон в телефоны уже далеко не первый год и жабу и .НЕТ вмести JIT'ом запихивают и ничего.
Ставить в бортовой компьютер в автомобиля что-то мельче тоже не имеет смысла. Ибо и GPS хочется, и музыку послушать, и...
Или ты имеешь в виду что-то еще более микро? Но чем дальше тем менее микро становится это самое микро...
Ну а для совсем микро есть кросскомпиляция.
WH>>Какие еще накладные расходы придумаешь? T>Да уже имеющихся достаточно.
Каких? Та назвал только профилирование которое нафиг не нужно.
Вон в жабе оно есть и что-то как-то оно этой самой жабе не сильно помогает работать быстрее чем .НЕТ в которое его нет.
T>Виртуальная память влияет на производительность, накладные расходы в железе для неё минимальны (для реализации SPARC v8 под названием Leon3 и для известных мне вариантов MIPS — примерно размер регистрового файла, который сам ~10% от площади ядра микропроцессора). Для x86 успешное обновление TLB при промахе занимает ~400 тактов, для MIPS — ~40.
Экономия ~10% от площади ядра микропроцессора и 0 тактов вместо от 40 до 400.
Так и запишем.
WH>>Да и сам процессор можно сделать без лишних заморочек типа слоя совместимости с x86. T>А это-то здесь при чём?
Ну при том что сейчас очень много процессоров с этой нашлепкой.
Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.
Управляемые системы позволят от этой нашлепки избавиться.
Ибо в случае с управляемой ОС нужно будет просто описать модель нового процессора.
И весь софт стразу на нем заработает.
С нативными ОС такой фокус не пройдет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, jedi, Вы писали:
J>Исправлять софт дешевле...
Последний раз ИМХО исправляли одну из первых версий 386, в которой был какой-то баг в чем-то, связанном с плавающей точкой. С тех пор я не помню об ошибках в процессорах, требовавших их замены.
>менно по этой причине мы до сих пор имеем generic-purpose процессоры, а не специализированные под работу в инете, редактирование документов и раскаладывание косынки
Нет. не поэтому. А потому, что я не намерен уставлять свою квартиру/офис кучей системных блоков — один для работы в инете, другой для редактирования документов, третий для расчета зарплаты, а четвертый для косынки, и связывать их друг с другом кабелями для того, чтобы передать текст , полученный из инета, в текстовый редактор
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ?
bootstrap сводит эту вероятность практически к нулю.
И даже если что-то проскочит обновить софт куда как проще чем обновить железо.
PD>В то время как в модели user/superwisor это решено аппаратно.
А где гарантия что нет ошибки в железе?
В любом случае гранулярность железной защиты всегда будет ниже плинтуса.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.
Расскажи это писателям вирусов...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет. не поэтому. А потому, что я не намерен уставлять свою квартиру/офис кучей системных блоков — один для работы в инете, другой для редактирования документов, третий для расчета зарплаты, а четвертый для косынки, и связывать их друг с другом кабелями для того, чтобы передать текст , полученный из инета, в текстовый редактор
Не надо воспринимать все так юуквально Посмотри на свой телефон, КПК или электронную читалку. Стоит тот же самый general-purpose процессор — ARM или что еще. А различия девайсов — в периферии и софте.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно. WH>Расскажи это писателям вирусов...
То есть ты хочешь сказать, что вирусы в состоянии нарушить аппаратную защиту защищенного режима, и , работая в 3 кольце, получить доступ к страницам, для которых U/S == 0 ? Расскажи , как это делают вирусы, мне это очень интересно
