Здравствуйте, eao197, Вы писали:
E>QNX -- это ОС реального времени со всеми своими заморочками. Не факт что под нее будет удобно обычный софт писать.
А какие у ОСРВ заморочки, кроме снижения средней производительности? ИМХО, там всё то же, только приходится платить за детерменированность временных характеристик при худшем случае снижением производительности в среднем. Как-никак, это дополнительный функционал, а он за бесплатно не бывает.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, McSeem2, Вы писали:
E>QNX -- это ОС реального времени ... А вот MINIX -- это обычный Unix, но ориентированный на отказоустойчивость.
AS>>Еще раз. Я прощу тебя привести пример успешных ОС, построенных на управляемых средах, то, что имеет свойство называться управляемые системы. По крайней мере, я понял тебя именно так, думаю, все, кто это прочитает, поймут так же. WH>Если бы я хотел написать ОС то я бы написал ОС. Система это совокупность программных и аппаратных решений.
AS>>Пусть подписывает. WH>Ну и зачем тогда эта подпись вобще нужна?
_Возможность_ отсекать _потенциально_ опасный код. Т.е. не намеренно опасный, а являющийся таковым случайно — те самые банальные ошибки переполнения буфера.
AS>>На этот код в любом случае будет накладываться все то же ограничение, что и сейчас. Дополнительная информация нужна для определения "безопасности" нативного кода и решения, можно ли его загружать в текущем контектсе. WH>И толку от такой проверки если она легко может быть фальсифицирована? AS>>Загрузка на исполнение — ничего страшного не случится. WH>Да ну? То-то у меня из-за одного кривого драйвера винда переодически в синий экран вываливается. AS>>А вот если убитый IL загрузить в сингулярити — будет большой бабах. Ага? WH>Я вот не слышал о том чтобы .НЕТ или жаба пропускали невалидный байткод.
Ну так это пока никому не надо? Ты готов дать гарантию, что это невозможно, если кому то очень понадобится?
AS>>Дополнительный лейер в виде IL. Если ты сможешь в IL задавать различные опции, влияющие на генерацию нативного кода, то ты потеряешь переносимость, да и смысл самого IL. Ну как мне еще это объяснить кроме как попросить тебя почитать про внутреннее устройство той же вин2к? Посмотри, как там это сделано, сколько оптимизировано просто _руками_. Прочитай, например, про префетч у Свена Шрайбера. WH>Ссылки есть?
Есть книга "Недокументированные возможности Windows 2000"... стр.109. Вообще, может и можно что в интернет найти — ключевые слова OMAP, pdb. Мне не удалось с первой попытки, придется тебе просто поверить, что оно там есть либо достать книгу Еще, если интересно, можно почитать про SYSCALL\SYSENTER, про оптимизацию обработки прерываний в многопроцессорном кернеле... В общем то, много чего интересного, что совсем непросто будет реализовать только на IL — очевидно, опять потребуется использование неуправляемого кода, а следовательно, опять потенциальные проблемы, которые даже не будут зависеть от компилятора в IL\из IL.
AS>>Если новая система будет поддерживать виртуализацию — это не проблема. Поставь на xp64 wmware и наслаждайся старыми приложениями почти с той же производительностью. А если поддержка виртуализации будет аппаратной? Ведь то, как это сделано сейчас — просто магия. Я для интереса пробовал разобраться — там СТОЛЬКО всего... WH>А если виртуализация будет основана на IL то никакой магии не нужно.
Магии не нужно на нормальном железе. Где оно, вот вопрос. И почему за почти 30 лет х86 этим никто не озаботился?
AS>>Получаем экзешник размером 2 (!!) кб и занимающий в воркинг сете 148 кб. Итого — приведенные в статье цифири есть БРЕД. Нормально замерить память, занимаемую приложением, можно только посмотрев то, что оно аллоцирует при помощиу VirtualQueryEx (и тут значения что для моего примера в 2кб, что для исходного в 40 кб будут очень близки — с точностью до разницы в размере бинарников). Заметь, в отличие от авторов статьи, я привел конкретные примеры, конкретные опции, сказал, что и где смотреть. Какие нафиг результаты после такого, ты о чем? Господа даже не потрудились разобраться, что они измеряют и как. Извини, но это не дело. WH>Ладно уел. Вот только ты забыл про WH>
WH>>Кстати они сами сказали что не гонялись за производительностью. Так что там скорей всего можно еще будь здоров как все разогнать.
Ага. А теперь посмотри статью:
Если цель Singularity – надежность, почему эта статья содержит измерения производительности? Ответ прост: эти цифры демонстрируют, что предлагаемая нами архитектура не только не вредит производительности, но зачастую работает так же, как обычные системы, а то и быстрее. Другими словами, это практическая основа, на которой можно строить систему.
С другой стороны, в этой статье никак не отражена наша цель – повышение надежности. Измерить этот аспект системы существенно сложнее, чем производительность. У нас пока нет результатов для Singularity.
Итого — тестов надежности нет (и почему то у меня ощущение, что если бы они и были, то в том же духе, что и тесты производительности. Интересно, почему у меня такое ощущение ). Обсуждать можно только то, что нам известно. Так шта не обессудь. Про надежность мы наши позиции уже выразили, позиции сторон не позволяют найти точки соприкосновения. А вот с производительностью вроде должно быть более объективно — ан нет.
WH>>>Так вот если компилятор ЯВУ сгенерирует не верный IL то этот IL просто пошлют куда подальше. AS>>Ты готов подписаться под этими словами? Один известный товарищ уже говорил, что перейти в ринг 0 под winnt невозможно без драйвера. Возможно, и способов уже известно несколько. WH>Если компилятор IL будет доказан математически, а это возможно.
Аналогично я могу сказать, что можно доказать математически устойчивость абстрактного процессора. Доказательства возможности доказательства есть? Очень бы хотелось хотя бы общие положения. Наконец кто-то решил задачу многокритериального поиска за приемлемое время.
WH>>>Те ничто не мешает IL'у работать с тойже скоростью что и С++, а то и большей ибо доступны болие злые оптимизации из-за того что IL ограничен. AS>>Ты готов под этим подписаться? WH>Единственная проблема это есть некоторые проверки которые не устранить. Вот только съедают они очень мало. А во всем остальном можно оптимизировать не хуже чем С++. Болие того если подстраиваться под текущий процессор то...
А что мешает в абстрактную неуправляемую систему включить компилятор (как это сделано в юникс). Да и более того, кернел винды и сейчас содержит оптимизации под различные виды процессоров, да и HALы для них тоже различны... В общем то, повторюсь, ну никак я не вижу тут необходимости лишней прослойки в виде IL, уж извини. Наверное я тупой
Ты мне вот что скажи. Из IL возможно полностью восстановить семантику и синтаксис любого исходного кода или нет (я не имею ввиду вплоть до названий переменных\классов\функций)? Про декомпиляторы я слышал\читал, но пробовать вживую не довелось.
AS>>>>так и из-за наличия некоторых знаний о способах оптимизации ядра NT, которые просто невозможно применить в данном случае. WH>>>А именно? Только ты учти что эта система совсем не НТ. AS>>Я уже про часть из них говорил. WH>А почему их невозможно применить в сингулярити говорил?
Потому что необходимо знание
1. Почему выполняется данная оптимизация (специфично для архитектуры платформы)
2. Каким образом выполнять данную оптимизацию (опять же специфично для архитектуры платформы)
3. Оптимально выполнить данную оптимизацию, (очевидно, итеративный процесс с промежуточными тестами).
Безусловно, какие то мелкие оптимизации можно будет сделать и тут, но полностью (учитывая что в сингулярили микрокернел) — на мой взгляд, просто невозможно.
Здравствуйте, Andrew S, Вы писали:
AS>_Возможность_ отсекать _потенциально_ опасный код. Т.е. не намеренно опасный, а являющийся таковым случайно — те самые банальные ошибки переполнения буфера.
Для этого придется написать доказавальщик который работает с учетом указателей и реинтерпритации памяти.
А это задаче ИМХО вобще не разрешимая.
К тому же зачем нам нужно отсекать только не намеренные косяки?
AS>Ну так это пока никому не надо? Ты готов дать гарантию, что это невозможно, если кому то очень понадобится?
Для жабы и .НЕТ нет ибо на сколько мне извесно их оптимизаторы математически не доказываются.
WH>>Если компилятор IL будет доказан математически, а это возможно. AS>Аналогично я могу сказать, что можно доказать математически устойчивость абстрактного процессора. Доказательства возможности доказательства есть? Очень бы хотелось хотя бы общие положения. Наконец кто-то решил задачу многокритериального поиска за приемлемое время.
Тут нужно различать систему которая ищет доказательства и систему которая проверяет доказательства.
Те искать доказательства будет программист при помощи своей квантовой нейросетки которая иногда сбоит. А проверять будет машина вероятность сбоя которой практически равена нулю. Re[5]: Процессор для safe OS
AS>А что мешает в абстрактную неуправляемую систему включить компилятор (как это сделано в юникс). Да и более того, кернел винды и сейчас содержит оптимизации под различные виды процессоров, да и HALы для них тоже различны... В общем то, повторюсь, ну никак я не вижу тут необходимости лишней прослойки в виде IL, уж извини. Наверное я тупой
IL позволяет создать кучу языков под платформу не заморачиваясь генерацией машинного кода.
Болие того иногда прикладным программам нужно создавать код на лету и с IL это сделать на порядки проще чем возится с чемто другим. Про прямую генерацию машинного кодя я вобще молчу.
AS>Ты мне вот что скажи. Из IL возможно полностью восстановить семантику и синтаксис любого исходного кода или нет (я не имею ввиду вплоть до названий переменных\классов\функций)? Про декомпиляторы я слышал\читал, но пробовать вживую не довелось.
Reflector востанавливает код почти один в один. Правда он заточен на C# и близкие к нему языки (VB.NET, Delphi.NET...) так что на nemerle он иногда затыкается ибо не может перевести сложный match в конструкции C#. Но если бы он был заточен на немерле то востанавливал бы и его хотя это намного сложнее ибо семантика языка плохо ложится на IL.
В любом случае спецификация IL такова что он в любом случае типизированный. Болие того проверка типизации производится за один проход по IL и алгоритм там настолько примитивный что накосячить практически не возможно.
Кстати я считаю что MSIL не самй подходящий промежуточный язык. Уж слишком бедны его возможности. К тому же мелкосов пошол по пути x86 напихав в IL кучу всякой дряни.
Тем не мение если кое что вычистить, кое что добавить то промежуточный язык для абстрагирования от платформы это то что нужно. И будет уже не важно что у нас за камень x86, alpha, sparc или что-то еще.
AS>Потому что необходимо знание AS>1. Почему выполняется данная оптимизация (специфично для архитектуры платформы)
Прошивается в компилятор для данной платформы. AS>2. Каким образом выполнять данную оптимизацию (опять же специфично для архитектуры платформы)
Опять же прошивается в компилятор. AS>3. Оптимально выполнить данную оптимизацию, (очевидно, итеративный процесс с промежуточными тестами).
Вот разработчики компилятора пусть и проводят итерации.
Вобщем тут нужно просто создать протокол общения между процессами и реализовать его как следует для каждой платформы.
AS>Безусловно, какие то мелкие оптимизации можно будет сделать и тут, но полностью (учитывая что в сингулярили микрокернел) — на мой взгляд, просто невозможно.
Ну без микроядра говорить о надежной системе вобще не стоит. Ибо если сбойнет драйвер режима ядра то все полутит к чертовой бабушке. А в микроядерной архитектуре полетит только этот драйвер который можно перезапустить.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Кстати я считаю что MSIL не самй подходящий промежуточный язык. Уж слишком бедны его возможности. К тому же мелкосов пошол по пути x86 напихав в IL кучу всякой дряни.
Ну как тогда коррелируется это с твоим предыдущим высказыванием о том, что оптимизация и платформенная независимость там на высоте? Если бедны, значит, и оптимизация не может быть удовлетворительной.
WH>Тем не мение если кое что вычистить, кое что добавить то промежуточный язык для абстрагирования от платформы это то что нужно. И будет уже не важно что у нас за камень x86, alpha, sparc или что-то еще.
Ну а почему тот же С++ (или скажем так, промежуточные состояния компиляции с него) не может быть таким промежуточным языком? Платформенно-зависимых вещей в нем ведь тоже нет, типобезопасность при желании может быть на высоте (и уж компилятор точно в состоянии это проверить). Зачем обязательно тащить какой то IL, когда можно все делать на уровне исходников? Опять же для меня совсем не очевидны преймущества GC перед обычным менеджером памяти. Где то он выигрывает, где то — проигрывает. В общем, все совсем неоднозначно. Зачем опять динамическая компиляция, когда достаточно сделать это один раз, как в том же линуксе? В общем, много зачем...
AS>>Получаем экзешник размером 2 (!!) кб и занимающий в воркинг сете 148 кб. Итого — приведенные в статье цифири есть БРЕД. Нормально замерить память, занимаемую приложением, можно только посмотрев то, что оно аллоцирует при помощиу VirtualQueryEx (и тут значения что для моего примера в 2кб, что для исходного в 40 кб будут очень близки — с точностью до разницы в размере бинарников). Заметь, в отличие от авторов статьи, я привел конкретные примеры, конкретные опции, сказал, что и где смотреть. Какие нафиг результаты после такого, ты о чем? Господа даже не потрудились разобраться, что они измеряют и как. Извини, но это не дело. WH>Ладно уел.
Кстати, вот еще один аргумент, который ну совсем разрушает эти измерения (в т. ч. и мои, хотя они лишь были для демонстрации неправильности подхода). Дело в том, что занимаемое процессом виртуальное адресное пространство не есть показатель (в отличие от сингулярити, где виртуальное == физическое). Надо считать _физические_ страницы памяти, которые выделены под уникальные для процесса операции — его код и данные. Поскольку в NT и в линуксе\Free реализован подход, когда одинаковые модули разделяют код (насчет данных сейчас не помню, но и их часть, кажется тоже) — в общем, все, что в PE на уровне lazy copy on write — т.е. для dll создается копия физической страницы (которая отображает на тот же виртуальный адресс процесса, что и старая) только после ее (страницы) изменения. Поскольку такие изменения в системных библиотеках не происходят, то большинство даже из максимального воркинг сета — это собственно, общий код для всех процессов.
Вот, кстати, из статьи:
В Singularity мы надеемся добиться совместного использования доступных только для чтения страниц, содержащих код исполняющей системы среди сходных процессов, уменьшить потребление памяти и ускорить создание процессов.
Т.е. они говорят что "а мы вот еще лучше сделаем, чем даже сейчас". А при том совершенно умалчивают о том, что, собственно, в приведенных результатах (если были бы приведены не воркинг сета, а закоммиченных для приложения страниц) для других систем бОльшая часть кода\данных _уже_ реализована как совместное использование библиотек. Т.о. приведенные изменения даже _теоретически_ ничего показать адекватного не могут, вот такие пироги. Все, что из них видно — каким образом работает менеджер памяти, обеспечивая префетч для виртуальных (а иногда и физических, но когда каких — непонятно) страниц по своим внутренним соображениям. Это, кстати, к вопросу о специалистах, которые писали эту статью. Тут явно или намернно умалчивают, либо просто не понимают, о чем речь. Как сказал адонтз — в топку такие тесты. Однозначно.
Здравствуйте, Andrew S, Вы писали:
AS>Ну как тогда коррелируется это с твоим предыдущим высказыванием о том, что оптимизация и платформенная независимость там на высоте? Если бедны, значит, и оптимизация не может быть удовлетворительной.
Бедность я имел в виду в том смысле что он не держит функциональщину. Те вобще нет никаких способов выразить замыкания, нет понятия неизменяемого объекта и тп.
AS>Ну а почему тот же С++ (или скажем так, промежуточные состояния компиляции с него)
Те IL? AS>не может быть таким промежуточным языком? Платформенно-зависимых вещей в нем ведь тоже нет,
Теоритически. На практике нужно писать код ооочень осторожно чтобы это было. AS>типобезопасность при желании может быть на высоте (и уж компилятор точно в состоянии это проверить).
А это вобще мечты. Пока существуют касты отличные от dynamic_cast ни о какой типизации можно не говорить. Тоже самое касается висячих указателей и выходов за придела массива. AS>Зачем обязательно тащить какой то IL, когда можно все делать на уровне исходников?
Везде распрастронять исходники? Тем болие исходники на С++ имеют привычку компилироваться часами. AS>Опять же для меня совсем не очевидны преймущества GC перед обычным менеджером памяти. Где то он выигрывает, где то — проигрывает. В общем, все совсем неоднозначно.
Его главное преймущество это гарантированное отсутствие висячих указателей. Те не скорость, а надежность. Да и утечку памяти устроить гораздо сложнее.
Кстати в сингулярити можно делать любые ГЦ в том числе и полное отсутствие ГД для какого либо процесса в случае если память можно распределить один раз и навсегда. AS>Зачем опять динамическая компиляция, когда достаточно сделать это один раз, как в том же линуксе? В общем, много зачем...
В сингулярити компиляция происходит во время установки программы. Дальше ОС поднимает уже скомпилированный код.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Кстати в сингулярити можно делать любые ГЦ в том числе и полное отсутствие ГД для какого либо процесса в случае если память можно распределить один раз и навсегда. AS>>Зачем опять динамическая компиляция, когда достаточно сделать это один раз, как в том же линуксе? В общем, много зачем... WH>В сингулярити компиляция происходит во время установки программы. Дальше ОС поднимает уже скомпилированный код.
И опять таки упремся в проблему надежности компилятора в IL, верифайера и компилятора из IL в нативный код. Я так понял, что гарантировать достоверность результатов работы такой связки ты таки не сможешь, и что все-же возможны варианты обмана верифайера, при котором компилятор из IL в нативный код понаделает такой гадости, что сам застрелится? Если это так, тогда все "красивые" логические построения будут смыты в dev\null простой модификацией компилятора в IL. Отмазки типа "сейчас этого нет, и может быть это вообще не откомпилится", думается, в системе, где других способов защиты нет, не прокатят... Ведь сейчас просто незачем этим народу заниматься, а если будет такой лакомый кусок в виде верифайера, думаю, его быстро разломают... Ведь если математически доказать корректность не представляется возможным, то и все возможные состояния проверить тоже не удастся. В общем, очень много вопросов. И в статье, согласись, они вообще не освещены никак. И заметь, мы с тобой (по крайней мере я, поскольку не являюсь специалистом по .net), вообще говоря, не представляем всех возможных проблем надежности такого подхода. Наверняка найдутся люди, которые накидают совершенно других соображений, нежели смог придумать я, базируясь уже на конкретных знаниях технологий компиляции в\из IL, а также самого IL.
Здравствуйте, Andrew S, Вы писали:
AS>И опять таки упремся в проблему надежности компилятора в IL,
Этой проблемы не вобще. IL можно генерить как попало главное чтобы го не пропустил верифайер. AS>верифайера и компилятора из IL в нативный код.
А вот это можно даказать математически.
Тпизация это тоже доказательство правильности работы которое проверяет компилятор и/или рантайм. AS> Ведь если математически доказать корректность не представляется возможным,
Кто сказал?
Если человек придумает доказательство то компилятору останется его только проверить не забыл ли чего человек.
Скажем тот верифайр который встроен в современный .НЕТ настолько прост что его можно довольно легко доказать.
В принципе верифайр можно делать слоеным и доказывать каждый слой по отдельности.
В прочем верифайр это фигня. Доказать оптимизатор будет много сложнее хотя тоже возможно.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
AS>> Ведь если математически доказать корректность не представляется возможным, WH>Кто сказал? WH>Если человек придумает доказательство то компилятору останется его только проверить не забыл ли чего человек. WH>Скажем тот верифайр который встроен в современный .НЕТ настолько прост что его можно довольно легко доказать. WH>В принципе верифайр можно делать слоеным и доказывать каждый слой по отдельности. WH>В прочем верифайр это фигня. Доказать оптимизатор будет много сложнее хотя тоже возможно.
Вот и пример исследования по надежности — доказательство корректности оптимизатора и верифайера. И доказательноство того, что доказательства ихней надежности достоточно для обпеспечения надежности и устойчивости самой системы. Итого, если это возможно, то где они, доказательства, и в частности, в статье? И желательно, чтобы там же было обоснование невозможности сделать оного для нативного кода. Хороше обоснование, броня. Пока этого не будет — все это будет околонаучным проектом. А так ... все эти "можно, если и т.п." — вилами по воде писано. Не поверю, пока сам не увижу, не потрогаю и не пойму, почему так, а не иначе. Поинт.
WH>Тоже самое касается висячих указателей и выходов за придела массива.
(удручнно) Ну ты же грамотный человек! Не опускайся же до китайских чушков типа "девственный мел который уничтожить черви". Ты не подумай, что я на тебя наезжаю. Метафорически выражаясь, мне за даржаву обидно.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
МКП>Авторы: МКП> Михаил Купаев (перевод)
МКП>Аннотация: МКП>Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?
В любом случае тесты на производительность , выглядят мягко говоря нелепо ...
ИМХО, там всё то же, только приходится платить за детерменированность временных характеристик при худшем случае снижением производительности в среднем. Как-никак, это дополнительный функционал, а он за бесплатно не бывает. 
Еще, если интересно, можно почитать про SYSCALL\SYSENTER, про оптимизацию обработки прерываний в многопроцессорном кернеле... В общем то, много чего интересного, что совсем непросто будет реализовать только на IL — очевидно, опять потребуется использование неуправляемого кода, а следовательно, опять потенциальные проблемы, которые даже не будут зависеть от компилятора в IL\из IL.
Для косяков, ИМХО, всегда место есть.
