gear nuke wrote:
>
> Если под этим понимается вызов ядра, то:
> на неуправляемых системах происходит переход между кольцами аппаратной
> защиты, что само по себе довольно дорого. (по тем же причинам в ОС
> используют софтверное переключение задач, а не аппаратное)

А никто не напомнит, сколько там тактов нужно Пентиуму, чтобы
переключиться с 3-го кольца на нулевое при вызове через call gate?

VladD2 wrote:
> Почитай про идею SIP и вообще про задачи ОС и исследования. Тогда может
> быть желание говорить об unsafe пропадет само собой. Собственно сам
> первод SIP — "софтовая иззоляция процессов" говорит сам за себя.
Какая разница как оно называется? Оно может работать по определению
только с safe-кодом.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 wrote:
> Сигулярити и есть ОС в которой вызов сделан самым дешевым (на порядок
> дешевле чем в любой другой ОС с защитой). О чет ты пыташся сказать то?
В Сингулярити все работает в нулевом кольце, так что там нечем особо
гордиться. Есть определенные подходы, позволяющие значительно ускорить
обработку сисколов и в обычных ОС с аппаратной защитой.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Pzz, Вы писали:

Pzz>А никто не напомнит, сколько там тактов нужно Пентиуму, чтобы
Pzz>переключиться с 3-го кольца на нулевое при вызове через call gate?

А где колгейты используются?
В NT — int gate, что по скорости немного быстрее, поскольку far call на каждый параметр ещё время тратит.
В доках от Intel информации не видел, но процессор должен не мало проделать при переключании, ту же IDT обработать. Речь уже не о тактах идёт.
486 тратил 77+4*кол-во_параметров на CALL через шлюз. INT — 71. IRET — 36.
Вряд ли что-то сильно изменилось на новых комнях, SYSENTER не зря добавили (в XP она и используется). Как там себя конвеер ведёт не знаю, наверняка сбрасывается заодно с некоторыми кешами -> дополнительные потери. И это всё ещё без учёта затрат на диспетчер.
Хорошо бы это померить, но плохо представляю, как получить приемлимую точность

Кстати, когда-то читал, во FreeBSD (? точно не уверен) хотели использовать DMA для копирования больших кусков памяти — оказалось медленно.

В общем, тенданция пугающая — hardware sux

gear nuke wrote:
>
> Pzz>А никто не напомнит, сколько там тактов нужно Пентиуму, чтобы
> Pzz>переключиться с 3-го кольца на нулевое при вызове через call gate?
>
> А где колгейты используются?
> В NT — int gate, что по скорости немного быстрее, поскольку far call на
> каждый параметр ещё время тратит.
> В доках от Intel информации не видел, но процессор должен не мало
> проделать при переключании, ту же IDT обработать. Речь уже не о тактах идёт.
> 486 тратил 77+4*кол-во_параметров на CALL через шлюз. INT — 71. IRET — 36.
> Вряд ли что-то сильно изменилось на новых комнях, SYSENTER не зря
> добавили (в XP она и используется). Как там себя конвеер ведёт не знаю,
> наверняка сбрасывается заодно с некоторыми кешами -> дополнительные
> потери. И это всё ещё без учёта затрат на диспетчер.
> Хорошо бы это померить, но плохо представляю, как получить приемлимую
> точность

OK. И какова доля этих потерь на фоне всех остальных затрат на обработку
сискола?

> Кстати, когда-то читал, во FreeBSD (? точно не уверен) хотели
> использовать DMA для копирования больших кусков памяти — оказалось медленно.

В PC нет быстрого DMA (я не имею ввиду busmastering, который
осущствляется всякими там контроллерами — как его использовать для
передачи из памяти в память, не очень понятно).

Кроме того, передача на самом деле нужна не из памяти в память, а из
кеша в кеш. Использование DMA, это явно плохая идея.

Здравствуйте, gear nuke, Вы писали:

GN>Остаётся открытым вопрос — насколько практически надёжную защиту сможет дать Singularity?

Думаю на 99%.

GN>Теоретические выкладки мало интересны, Java VM как известно ужасно дырява, а Janus у меня вчера без видимых оснований выдал AV при дуступе к 0му адресу

Незнаю что ты имешь в виду под жудкой дырявостью Явы. Попробуй завалить ее используя только компилятор Явы, а мы поглядим.

Что касается Януса, то в нем неуправляемого кода пожалуй что больше чем управляемого. Это и Джэт, и Интернет Эксплорер, и куча интеропа. В Сингулярити все прикладные процессы (а скорее всего и остальные) будут управляемыми и безопасными.

GN>Хотя никто не мешает добавить и аппаратные кольца защиты — запас есть.

На фиг они там не упали. Весь смысл в том, что без них прекрасно можно обойтись.

Здравствуйте, Cyberax, Вы писали:

C>VladD2 wrote:
>> Почитай про идею SIP и вообще про задачи ОС и исследования. Тогда может
>> быть желание говорить об unsafe пропадет само собой. Собственно сам
>> первод SIP — "софтовая иззоляция процессов" говорит сам за себя.
C>Какая разница как оно называется? Оно может работать по определению
C>только с safe-кодом.

Вот именно, по определению. Точнее по спецификации. И ни с каким другим.
Так что не нужно даже обсуждать что будет в случае если повсеместно начнет использоваться unsafe.

Здравствуйте, Cyberax, Вы писали:


C>В Сингулярити все работает в нулевом кольце, так что там нечем особо
C>гордиться.

Я бы как раз скзал, что там очень даже есть чем гордиться. Именно то, что система надежность которой выше чем у современных ОС не нуждается в аппоратной защите и прекрасно работает в нулевом кольце — это очень нехилое достижение.

C> Есть определенные подходы, позволяющие значительно ускорить
C>обработку сисколов и в обычных ОС с аппаратной защитой.

Ага. А в рельных ОС их неиспользуют по морально-этическим соображениям.

VladD2 wrote:
> C>В Сингулярити все работает в нулевом кольце, так что там нечем особо
> C>гордиться.
> Я бы как раз скзал, что там очень даже есть чем гордиться. Именно то,
> что система надежность которой выше чем у современных ОС не нуждается в
> аппоратной защите и прекрасно работает в нулевом кольце — это очень
> нехилое достижение.
Это еще кучу лет назад было в MS-DOS в программах на Бейсике

> C> Есть определенные подходы, позволяющие значительно ускорить
> C>обработку сисколов и в обычных ОС с аппаратной защитой.
> Ага. А в рельных ОС их неиспользуют по морально-этическим соображениям.
Нет, используются. Но пока это работы исследовательского характера —
например в одной работе предлагалось складывать вызовы сисколов в
расшареную память, которую читает системный сервер. То есть вызов
выглядит просто как копирование аргументов в shared-сегмент.

Сервер (в другом процессе) это замечает, обрабатывает вызов и кладет
туда же ответ. Получается очень хорошая экономия тактов на
Hyper-threading-процессорах.

Учитывая грядущее распространение двухядерных процессоров может быть
эффективным запускать системный процесс в виде потока на одном ядре, с
котороым пользовательский процесс на другом ядре общается с помощью
аппаратного FIFO.

Пока все это находится в процессе исследования, так что в обычных ядрах
появится еще не скоро (хотя во всяких Hurd'ах уже применяются подобные
схемы). Но способы потенциально в разы сократить время все же есть.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Pzz, Вы писали:

Pzz>OK. И какова доля этих потерь на фоне всех остальных затрат на обработку сискола?

Это могут быть величины одного порядка.

Если говорить о выделении памяти, то в лучших случаях на выделение достаточно единиц тактов. А не сотен, как при вызове ядра.

Pzz>передача на самом деле нужна не из памяти в память, а из кеша в кеш.

Не могу понять выделенное.
Если копируется память, то она копируется *по определению*

Pzz>Использование DMA, это явно плохая идея.

Он может разгрузить CPU, помимо всего прочего.

В общем-то DMA влюбом случае сейчас не имеет смысла — шина памяти всё равно слишком узкая, при правильном подходе, CPU её прокачает без проблем, ещё и ждать будет.

Здравствуйте, VladD2,

GN>>Остаётся открытым вопрос — насколько практически надёжную защиту сможет дать Singularity?

VD>Думаю на 99%.

Всё понятно. Если драйвер не работает в 1 сдучае из 1000000, значит он не работает совсем.
К безопасности требования ещё строже, с такими цифрами это значит: "заходите добры люди, берите что хотите"

VD>Незнаю что ты имешь в виду под жудкой дырявостью Явы.

Я в общем-то тоже не знаю. Но жаба у меня на всякий случай выключена в браузерах, как советую те, кто знает.

VD>Попробуй завалить ее используя только компилятор Явы, а мы поглядим.

Боюсь у меня на это много времени уйдёт, может быть даже несколько лет. А у кого-то уйдёт пара часов. Вот они-то и представляют опасность.

Эти цифры мало о чём говорят, но они есть:

Results 1 — 10 of about 126,000 for JVM exploit. (0.04 seconds)

Results 1 — 10 of about 83,300 for JRE exploit. (0.04 seconds)

gear nuke wrote:
>
> Pzz>OK. И какова доля этих потерь на фоне всех остальных затрат на
> обработку сискола?
>
> Это могут быть величины одного порядка.

Могут, наверное, но не есть. Если же учесть, что сисколы, в большинстве
своем, делают чего-нибудь полезное (например, записывают данные на
диск), то overhead от перехода в другое кольцо защиты кажется уже совсем
незаметным.

> Если говорить о выделении памяти, то в лучших случаях на выделение
> достаточно единиц тактов. А не сотен, как при вызове ядра.

А при чем здесь это?

> Pzz>передача на самом деле нужна не из памяти в память, а *из кеша в кеш*.
>
> Не могу понять выделенное.
> Если копируется память, то она копируется *по определению*

Если память копируется какой-нибудь внешней прибамбасой, то происходит
следующее:
1. Скорее всего, данные в том месте, где их надо взять, недавно
подсчитаны. Значит, скорее всего, они в кеше процессора. Их надо слить
оттуда в память.
2. Далее, их надо скопировать в другое место памяти
3. И наконец, если дальше эти данные будут как-то еще обрабатываться,
они должны опять попасть в кеш процессора.

Если же мы говорим о, скажем, записи на диск, то копированые может быть
вообще не нужно. Дисковый контроллер может забрать эти данные прямо из
того места памяти, где user space process их хранит.

Здравствуйте, Pzz, Вы писали:

Pzz>>>OK. И какова доля этих потерь на фоне всех остальных затрат на обработку сискола?

GN>> Это могут быть величины одного порядка.

Pzz>Могут, наверное, но не есть.

Однако, не всё. В NT специально существует несколько отдельныех int gate. Для того, что бы убрать задержки из-за диспетчера. Некоторые структуры разделяются между ядром и юзерлендом — что бы совсем избежать оверхеда. Есть вещи, где эти несколько сотен тактов очень критичны.

Pzz>Если же учесть, что сисколы, в большинстве своем, делают чего-нибудь полезное (например, записывают данные на диск), то overhead от перехода в другое кольцо защиты кажется уже совсем незаметным.

Наличие случаев, где можно пренебречь оверхедом, не спасает остальные.

GN>> Если говорить о выделении памяти, то в лучших случаях на выделение
GN>> достаточно единиц тактов. А не сотен, как при вызове ядра.

Pzz>А при чем здесь это?

См. тему. Резервирование, коммит памяти — всё это возможно лишь через ядро. Сами эти операции не слишком дороги.

Pzz>Если память копируется какой-нибудь внешней прибамбасой, то происходит следующее:
Pzz> 1. Скорее всего, данные в том месте, где их надо взять, недавно подсчитаны. Значит, скорее всего, они в кеше процессора. Их надо слить оттуда в память.
Pzz> 2. Далее, их надо скопировать в другое место памяти
Pzz> 3. И наконец, если дальше эти данные будут как-то еще обрабатываться, они должны опять попасть в кеш процессора.

Я говорю о копировании больших объёмов, в кеш они ни как не войдут.
Если же данные только что посчитаны — их можно сразу сохранить в нужном месте.

Здравствуйте, Pavel Dvorkin, Вы писали:

А чем борландовский МП плох
http://www.rsdn.ru/article/Delphi/memmanager.xml

Автор(ы): Андрей Мистик
Дата: 21.02.2003
В данной статье я постараюсь в общих чертах описать принципы работы менеджера памяти Delphi.
Зачем это нужно? Ведь, казалось бы, работает себе и работает, зачем его трогать? Это нужно по нескольким причинам. Во-первых, никогда не помешает разбор чужого кода, особенно если это грамотный код. Это возможность научиться чему-либо новому, а также получить эстетическое наслаждение. Во-вторых, никогда не лишне поглубже разобраться в чем-то, убедиться в тех вещах, в которых вы ранее не были уверены или же, наоборот, найти слабые места, о которых вы ранее и не подозревали, чтобы в будущем писать более эффективный код.

Вернее для больших лбъектов не совсем оптимален а так ...

Здравствуйте, VladD2, Вы писали:

>>> первод SIP — "софтовая иззоляция процессов" говорит сам за себя.
C>>Какая разница как оно называется? Оно может работать по определению
C>>только с safe-кодом.

VD>Вот именно, по определению. Точнее по спецификации. И ни с каким другим.
VD>Так что не нужно даже обсуждать что будет в случае если повсеместно начнет использоваться unsafe.

Сейчас на белом коне сюда вьедет Сергей Губанов и скажет, что очередную идею сьлямзили у Оберона.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>Вот именно, по определению. Точнее по спецификации. И ни с каким другим.
VD>>Так что не нужно даже обсуждать что будет в случае если повсеместно начнет использоваться unsafe.

ANS>Сейчас на белом коне сюда вьедет Сергей Губанов и скажет, что очередную идею сьлямзили у Оберона.

Идея типобезопасности скорее слямзена у Паскаля. А еще точнее у какого-нибудь Лиспа, так как он появился лет эдак на 20 раньше.

А вообще, это очень старый флэйм. Реальных прорывов и революций в компьютерной индустрии очень не много. И в большинстве случаев они проходят незаметно. Только спустя годы народ анализируя сделанное понимает, что имел место прорыв. Ну, а польза от прорывов появляется только когда множество иноваций собирается воедино в неком продукте полезном для общества. Так что Sun, IBM и MS делают очень полезную работу. Они берут те самые старые идеи и воплощают их на практике. Это тоже требует немалых умстевнных усилий и финансовых затрат. За что им огромное спасибо.

Здравствуйте, Cyberax, Вы писали:

C>Это еще кучу лет назад было в MS-DOS в программах на Бейсике

В ДОС-е Бэйсик не был типобезопасным языком, не поддерживал идею процессов, изолляции, потоков, надежности и т.п. Так что о чем речь не очень ясно.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, VladD2,

GN>>>Остаётся открытым вопрос — насколько практически надёжную защиту сможет дать Singularity?

VD>>Думаю на 99%.

GN>Всё понятно. Если драйвер не работает в 1 сдучае из 1000000, значит он не работает совсем.

Процент в данном случае означет не процент отказов, а процент случаев когда Сингулярити позволит создать надежную систему. В том смысле, что всегда найдутся требования котоыре будут не выполнипы в рамках выбранного подхода.

Что до надежности драйверов, то тут ОС в общем-то не причем. Драйвер — это программа. Если в ней ошибка, то проблемы неизбежны. Другое дело что Сингулярити может сделать в этом случае. А сможет она не мало. 1. Изалировать остальной код ОС и пользовательские процессы от сбойного драйвера. 2. Позволить перезапустить драйвер и востановить состояние (оно же не разделяется с драйвером, так что это будет не сложно). 3. Предоставить средства проверки корректности окружения, что позволит избежать проблем вроде несовместимости версий и т.п.

Собственно все это точно больеш чем у Виндовс и Линукс. Одним словом микроядерная ОС с малым оверхэдом.

GN>К безопасности требования ещё строже, с такими цифрами это значит: "заходите добры люди, берите что хотите"

Я не знаю о чем ты тут рассуждашь. Современные ОС имеют куда более плачевные показатели и по безопасности и по надежности.

GN>Я в общем-то тоже не знаю. Но жаба у меня на всякий случай выключена в браузерах, как советую те, кто знает.

Это перестраховка.

GN>Боюсь у меня на это много времени уйдёт,

Думаю, это вообще не выйдет.

VladD2 wrote:
> C>Это еще кучу лет назад было в MS-DOS в программах на Бейсике
> В ДОС-е Бэйсик не был типобезопасным языком
Ладно-ладно, заменим на Паскаль.

> не поддерживал идею процессов, изолляции, потоков, надежности и т.п. Так что о чем речь не
> очень ясно.
Вообще-то Erlang уже в начале 90-х поддерживал все это. Там еще вдобавок
была поддержка hotswap для работающего кода (с автоматическим
распространением обновлений по графу зависимостей).

Было бы намного интереснее, если бы МС с его ресурсами попробовал
исследовать как можно изменить аппаратную защиту так, чтобы
managed-языки более удачно в нее вписывались. А тот факт, что без
аппаратной защиты все работает намного быстрее — это давно известно.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Вообще-то Erlang уже в начале 90-х поддерживал все это. Там еще вдобавок
C>была поддержка hotswap для работающего кода (с автоматическим
C>распространением обновлений по графу зависимостей).

Насколько моне извесно, Erlang работает поверх некоторой ОС. Опять же если тут проводить аналогии, то это будет скорее первые Лисп-машины и Оберон-ОС.

C>Было бы намного интереснее, если бы МС с его ресурсами попробовал
C>исследовать как можно изменить аппаратную защиту так, чтобы
C>managed-языки более удачно в нее вписывались. А тот факт, что без
C>аппаратной защиты все работает намного быстрее — это давно известно.

Тебе не кажется странным предлагать софтовой компании заниматься исследованиями в процессоростроении? Они занимаются исследованиями в области ОС. И как я понимаю, ОС не затачивается на отдельную архитектуру.

Собственно то что они делают очень даже разумно и востребовано. К сожалению идею микроядра и безопсности засунули в задний проход. И слова о том, что железо видите ли тормозит является плохой отмазкой.