Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> Если серьезно, то управление виртуальной памятью двольно дорого. C>C чего бы? Управление VM — это по сути просто записи в таблицы.
Начнем с того, что все управление виртуалкой осуществляется из нулевого кольца. А сам переход в него из пользовательского режима уже занятие не дешовое. Потом обработка исключения дело не дешовое...
В общем, это вопрос не ко мне. У нас тут на сайте есть Алекс Федотов и другие орлы которые тебе это смогут объяснить на высоком техническом уровне. А я просто знаю, что оно не дешево. И знаю, что в МС специально добивались, чтобы сборка мусора была дешевле обработки сбоя доступа к странице. Иначе можно было бы забить на все и жить на виртуалке.
C>Обработку страничных ошибок можно тоже значительно ускорить (до C>нескольких тысяч тактов — никакому GC такое и не снилось).
Охринительная ссылка — "sun"..."solaris"... И размеры массивов как раз для разговора о ЖЦ (от 50 метров). И время просто выдающееся (от 3 секунд). Речь идет об управлении объектами размер которых порой составляет несколько десятков байт (от двенадцати). И о времени имеряемом микросекундами.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Начнем с того, что все управление виртуалкой осуществляется из нулевого > кольца. А сам переход в него из пользовательского режима уже занятие не > дешовое. Потом обработка исключения дело не дешовое...
Кстати, до меня только сейчас дошло — можно ведь (в случае вектора)
просто явно коммитить память без всяких страничных исключений.
> В общем, это вопрос не ко мне. У нас тут на сайте есть Алекс Федотов и > другие орлы которые тебе это смогут объяснить на высоком техническом > уровне. А я просто знаю, что оно не дешево. И знаю, что в МС специально > добивались, чтобы сборка мусора была дешевле обработки сбоя доступа к > странице.
Добавьте: в операционной системе Windows в 32-битном режиме.
> C>Обработку страничных ошибок можно тоже значительно ускорить (до > C>нескольких тысяч тактов — никакому GC такое и не снилось). > Какие десятки тактов? Преключение в нулевое кольцо вроде как уже сотни > тактов.
Я вообще-то написал слово "тысяч". Кстати, где-то видел исследование о
системе управления VM из обычного пользовательского режима. Там вообще
все в сотни тактов укладывалось.
> C>На эту тему были неплохие исследования (могу поискать на ACM). А вот > C>реализация вектора: > C>http://developers.sun.com/solaris/articles/virtual_memory_arrays.html > Охринительная ссылка — "sun"..."solaris"... И размеры массивов как раз > для разговора о ЖЦ (от 50 метров). И время просто выдающееся (от 3 > секунд). Речь идет об управлении объектами размер которых порой > составляет несколько десятков байт (от двенадцати). И о времени > имеряемом микросекундами.
Ну так никто вроде бы никто не собирается на каждый объект делать
обращение к менеджеру виртуальной памяти.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> Начнем с того, что все управление виртуалкой осуществляется из нулевого >> кольца. А сам переход в него из пользовательского режима уже занятие не >> дешовое. Потом обработка исключения дело не дешовое... C>Кстати, до меня только сейчас дошло — можно ведь (в случае вектора) C>просто явно коммитить память без всяких страничных исключений.
Здравствуйте, VladD2,
GN>>Даже если всё будет распологаться не в стеке, а в куче — не будет фрагментации, и создание + удаление останутся так же почти бесплатны, поскольку порядок этих операций гарантирован.
VD>Не, батенька. Только стэк практически беслатен. А куча всегда платна. Это и вылет за пределы кэша, и синхронизация.
В данном случае я говорю о создании в куче автоматических объектов. С вылетами за кеш всё тоже самое, что и со стеком (а что, стек не имеет таких проблем?). С синхронизацией теоретически проблем тоже может не быть, если компилятор потрудится для каждого треда свою кучу создать (как и стек). В общем-то деление на стек и кучу довольно условное и объясняется в случае x86 наличием аппаратной поддержки (указатель всегда хранится в esp), но никто (кроме здравого смысла) не мешает хранить в другом регистре постоянный указатель на кучу.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>В данном случае я говорю о создании в куче автоматических объектов. С вылетами за кеш всё тоже самое, что и со стеком (а что, стек не имеет таких проблем?). С синхронизацией теоретически проблем тоже может не быть, если компилятор потрудится для каждого треда свою кучу создать (как и стек). В общем-то деление на стек и кучу довольно условное и объясняется в случае x86 наличием аппаратной поддержки (указатель всегда хранится в esp), но никто (кроме здравого смысла) не мешает хранить в другом регистре постоянный указатель на кучу.
В описанном тбой варианте. Новая куча не отличается от стэка. Так что смысла в ней нет. Используй стэк.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В описанном тбой варианте. Новая куча не отличается от стэка. Так что смысла в ней нет. Используй стэк.
У кучи больше возможностей для роста — она не обязана быть непрерывной (в реально ли сделать фрагментированный стек в неуправляемых языках?). Она может использоваться вместо стека для того, что бы избежать проблем, о которых писал Кодт здесь
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>У кучи больше возможностей для роста — она не обязана быть непрерывной
Стэк тоже не обязан. Более того в Сингулярити он может состоять измножества сегментов.
GN>(в реально ли сделать фрагментированный стек в неуправляемых языках?).
Неуправляемые языки меня мало трогают. Но в принципе... а почему бы и нет?
GN> Она может использоваться вместо стека для того, что бы избежать проблем, о которых писал Кодт здесь
Здравствуйте, Cyberax, Вы писали:
C>Кстати, до меня только сейчас дошло — можно ведь (в случае вектора) C>просто явно коммитить память без всяких страничных исключений.
1. Все равно не быстро.
2. Это применимо только когда размер массива сильно вызодит за 4-8 килобайта. А это столь редкий случай, что и говорить о нем нет смысла.
C>Добавьте: в операционной системе Windows в 32-битном режиме.
Думашь 64-битном будет положительная разница? Или типа Линукс круче?
По информации из отчета по Сингулярити стоимость вызова API-функции в рзных ОС такова:
Cost (CPU Cycles)
Singularity FreeBSD Linux Windows
ABI call 87 878 437 627
Ну, а в рамках одного процесса это вообще 1-5 циклов процессора. Так что можно казать, что скорее всего во всех ОС аппоратной защитой памяти (на современных процессорах).
C>Я вообще-то написал слово "тысяч". Кстати, где-то видел исследование о C>системе управления VM из обычного пользовательского режима. Там вообще C>все в сотни тактов укладывалось.
А, ну, ну. Просто чистый вызов в нулевое кольцо уже по 500 циклов. А там еще работы немеряно.
C>Ну так никто вроде бы никто не собирается на каждый объект делать C>обращение к менеджеру виртуальной памяти.
Вот для этого и делают шустрые ЖЦ.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2,
GN>>У кучи больше возможностей для роста — она не обязана быть непрерывной
VD>Стэк тоже не обязан. Более того в Сингулярити он может состоять измножества сегментов.
Я знал, что будет именно такой ответ
Очень многое зависит от среды выполнения.
GN>>(в реально ли сделать фрагментированный стек в неуправляемых языках?).
VD>Неуправляемые языки меня мало трогают. Но в принципе... а почему бы и нет?
Да... но после некоторых размышлений о "деталях", появляются мысли о переходе на управляемые языки
Как альтернативу можно рассматривать воплощение в железе — поддержка виртуальной памяти давно есть, стек\куча требуют почти теже механизмы. Но это очень дорого в настоящий момент. Ну и языки всё равно там будут управляемые, только не виртуальной машиной, а реальной.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
VladD2 wrote: > > Думашь 64-битном будет положительная разница? Или типа Линукс круче? > По информации из отчета по Сингулярити <отчета%20по%20Сингулярити> > стоимость вызова API-функции в рзных ОС такова: > > Cost (CPU Cycles) > Singularity FreeBSD Linux Windows > ABI call 87 878 437 627
В MS-DOS'е стоимость системного вызова могла бы быть еще меньше.
VladD2 wrote: > > Pzz>В MS-DOS'е стоимость системного вызова могла бы быть еще меньше. > > Ее там вообще небыло. В прочем как и защиты, процессов, многопоточности, > безопасности...
Кстати, сисколл у MS-DOS'а был очень дорогим, причем, в общем-то, безо
всякой видимой причины...
Здравствуйте, Pzz, Вы писали:
Pzz>Кстати, сисколл у MS-DOS'а был очень дорогим, причем, в общем-то, безо Pzz>всякой видимой причины...
У ДОС-а небыло никаких "сисколлов". Он пользовался стандартными прерываниями процессора. ДОС резервировал Int 21h. А то что некоторые функции могли выполняться по пол часа это уже другой разговор.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Pzz>В MS-DOS'е стоимость системного вызова могла бы быть еще меньше. > Ее там вообще небыло. В прочем как и защиты, процессов, многопоточности, > безопасности...
В Singularity ее тоже нет. Она полагается лишь на статическую проверку
кода, которая не будет работать в случае unsafe'а.
VladD2 wrote: > C>Кстати, до меня только сейчас дошло — можно ведь (в случае вектора) > C>просто явно коммитить память без всяких страничных исключений. > 1. Все равно не быстро. > 2. Это применимо только когда размер массива сильно вызодит за 4-8 > килобайта. А это столь редкий случай, что и говорить о нем нет смысла.
Не сказал бы. Вообще, для размеров от 0 до 128 байт можно нормально
сделать аллокаторы, работающие с фиксироваными списками. Они будут
работать примерно со скоростью GC (скорее всего можно будет найти тесты
где будет побеждать GC и где будут побеждать аллокаторы).
Так что интересен как раз диапазон 128 байт — 4 Кбайт. GC на этом
диапазоне не особо эффективен — нужно слишком много всего копировать.
Ручной менеджмент тоже не особо эффективен.
На ACM видел исследования систем управления памятью как раз для этого
случая — рассматривался механизм использования страниц по 512 байт
вместо 4Кб.
> C>Добавьте: в операционной системе Windows в 32-битном режиме. > Думашь 64-битном будет положительная разница? Или типа Линукс круче? > А, ну, ну. Просто чистый вызов в нулевое кольцо уже по 500 циклов. А > > там еще работы немеряно.
Во-первых, Линукс действительно круче (я говорю только про ядро).
Во-вторых, есть способы уменьшить оверхед системных вызовов в разы —
посмотрите на микроядерные ОС (тот же Hurd), там стоимость системного
вызова намного меньше.
> C>Ну так никто вроде бы никто не собирается на каждый объект делать > C>обращение к менеджеру виртуальной памяти. > Вот для этого и делают шустрые ЖЦ.
А еще для этого делают нормальные аллокаторы.
Cyberax wrote: > > Во-первых, Линукс действительно круче (я говорю только про ядро). > Во-вторых, есть способы уменьшить оверхед системных вызовов в разы — > посмотрите на микроядерные ОС (тот же Hurd), там стоимость системного > вызова намного меньше.
На микроядрас стоимость "полезного" системного вызова (т.е., не того
низкоуровнего, которое представляет микроядро, типа послать сообщение
факловой системе, а семантически сравнимого с сисколом традиционного
ядра) обычно выше, чем в случае монолитного ядра. Микроядро в таких
системах мало чего делает, лишь координирует работу отдельных частей
системы и это, естественно, добавляет определенный overhead.
На hurd я бы ссылаться не стал, больно уж он мертвый. Но говорят, MacOS
X имеет такую же архитектуру: POSIX-like система, сделанная на основе
микроядра Mach3. Так что при желании можно попробовать поискать цифры
про MacOS.
Здравствуйте, Cyberax, Вы писали:
>> Pzz>В MS-DOS'е стоимость системного вызова могла бы быть еще меньше. >> Ее там вообще небыло. В прочем как и защиты, процессов, многопоточности, >> безопасности... C>В Singularity ее тоже нет. Она полагается лишь на статическую проверку C>кода, которая не будет работать в случае unsafe'а.
Почитай про идею SIP и вообще про задачи ОС и исследования. Тогда может быть желание говорить об unsafe пропадет само собой. Собственно сам первод SIP — "софтовая иззоляция процессов" говорит сам за себя.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>По информации из отчета по Сингулярити стоимость вызова API-функции в рзных ОС такова: VD>
VD> Cost (CPU Cycles)
VD> Singularity FreeBSD Linux Windows
VD>ABI call 87 878 437 627
Если под этим понимается вызов ядра, то:
на неуправляемых системах происходит переход между кольцами аппаратной защиты, что само по себе довольно дорого. (по тем же причинам в ОС используют софтверное переключение задач, а не аппаратное)
Разница в цифрах между FreeBSD\Linux\Windows, по-видимому происходит из-за различных методик верификации передаваемых в ядро аргументов. Эта цифра скорее говорит о том, что где-то проверки делают более "тщательно" либо кто-то просто оптимизировал это дело.
В Singularity аппаратная защита теряет смысл — вот и "оптимизация" — просто исключили лишнее звено. Проверки передаваемых аргументов можно тоже упростить, они судя по всему и в других местах проверяются. Поэтому и разница на порядок. Обычным системам здесь никак не выиграть, выполнять весь код в одном кольце для них защиты смерти подобно.
Остаётся открытым вопрос — насколько практически надёжную защиту сможет дать Singularity?
Теоретические выкладки мало интересны, Java VM как известно ужасно дырява, а Janus у меня вчера без видимых оснований выдал AV при дуступе к 0му адресу
Хотя никто не мешает добавить и аппаратные кольца защиты — запас есть.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
