>M$ выдала на публику творение своего R&D департамента. Народ обсуждает, читает, тратит время на компиляцию .. в обще не Ъшничает ...

народ как раз исключительно Ъшничает, как это ни прискорбно

>народ как раз исключительно Ъшничает, как это ни прискорбно

и правильно ... да же JIT не удосужились положить ... типа оптимизацию делает компилятор (в x86 код) => заранее закладывается невозможность использования сторонних средств разработки ... и вкусностей JIT

>и правильно ... да же JIT не удосужились положить ... типа оптимизацию делает компилятор (в x86 код) => заранее закладывается невозможность использования сторонних средств разработки ... и вкусностей JIT

и на кой чёрт там JIT ?

Оптимизирующий компилятор ... bartok.exe ... слопал 300 метров памяти и не подавился ... мдя ...

Сингулярити - это такая шутка, которая может только на моно прилож^Wскрипты запускать.

Короче, такая же херня, как и операционка на яве с „JVM в микроядре”.

> Каких уязвимостей, если там можно выполнять только байт-код?

а для ворда/экселя на vba тоже вирусы писать нельзя?

Я один вспомнил старинную игрушку Core Wars? Помните, в общую память запускаются два червя и начинают изменять значения ячеек памяти, чтобы истребить противника?

> а для ворда/экселя на vba тоже вирусы писать нельзя?

Дер люжа пердю-пердю? Сравни модель безопасности Inferno и модель безопасности ворда/экселя. VBAшные вирусы by design имеют доступ и к ФС, и ещё много куда.

Потом, много ли ты знаешь уязвимостей, которые позволяют выполнить произвольный код с помощью специально сформированного вордового документа. Это при насквозь дырявом формате файлов, когда-то заточенном под прямое копирования с диска в память и обратно. Для XML-ного opendoc вообще таких уязвимостей не было. Ну вот и инферновская VM достаточно хорошо защищена от выполнения произвольного кода, уж получше, чем нынешние ядра.

не нравится мне тенденция развития винды, да и вообще их идеи этого "развития" - типа фигли, мощности дохрена у нас, правда? ну тогда давайте, ляпаем один api, поверх него ещё api, поверх него ещё api, и т.д...

не могу сказать, что глупость, во всём свои плюсы, но вообще-то неприятно. мне это напоминает реализацию типа integer в оракле... (кто не знает - хранится оно там как пакованная строка, и все операции реализованы программно в десятичной системе счисления...)

а представьте, если что-нибудь такое заполонит рынок, и сделают специальные процессоры под это дело со встроенным аппаратным чем-нибудь вроде DRM-а или обязательной подписи или ещё какого-нибудь говна? я тогда, нах, в монахи уйду ))) это фантазия, конечно )))

короче хорошо что есть свободное ПО, из ситуации, к которой идёт дело, это, блин, единственный выход.

>не нравится мне тенденция развития винды, да и вообще их идеи этого "развития" - типа фигли, мощности дохрена у нас, правда? ну тогда давайте, ляпаем один api, поверх него ещё api, поверх него ещё api, и т.д...

>короче хорошо что есть свободное ПО, из ситуации, к которой идёт дело, это, блин, единственный выход.

бугагагага, в gnu/linux не лучше сейчас

>Единое адресное пространство - значит один процесс может писать в данные другого процесса?

С точки зрения процессора -- да, но так как нативный код в идеале полностью под контролем (генерируется VM), то реализовать эту возможность у тебя не выйдет.

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

мда, вендекапец либо уже близок как-никогда, либо микромягкие чего-то замышляют

от небесного явления доской ^W определениями не отгородишься. SIP это тоже процесс, сингулярити -- тоже микроядро.

>>> ни разу она не микроядерная >>Похоже, что все-таки микроядерная: http://ru.wikipedia.org/wiki/Ядро_(операционной_системы) >в Singularity нет процессов в классическом смысле (там SIP'ы), потому данное определение к ней неприменимо

у тебя кривое определение. Определения SIP , процессов и микроядра в студию.

микроядро:= http://en.wikipedia.org/wiki/Microkernel

"A microkernel is a minimal computer operating system kernel which, in its purest form, provides no operating-system services at all, only the mechanisms needed to implement such services, such as low-level address space management, thread management, and inter-process communication (IPC). "

Singularity:= 1.управление адресным пространством есть? есть, для изоляции непроверенного на типобезопасность кода и для уникальных адресных пространств ( docs/Design Notes/SDN4 Process Model.pdf). 2. нити есть, 3. IPC есть

значит, микроядро.

теперь, SIP - это тоже процессы.

SIP :=ftp://ftp.research.microsoft.com/pub/tr/TR-2005-135.pdf

" SIPs are the OS processes on Singularity. All code outside the kernel executes in a SIP. SIPs differ from conventional operating system processes in a number of ways:"

Танненбаум, "Современные операционные системы" := "Процессом является исполняемая программа, включая текущие значения PC, регистров и переменных" (стр.97) "процесс-- это программа в момент выполнения" (стр. 59)

шикарно, да? вот тебе ещё:

"процессом является следующая последовательность действий: программист читает рецепт, смешивает продукты и печет торт" <..> "процесс -- это активность некоторого рода".

Ну и где эти 2 последних определения противоречат? от того, что в микроядре Сингулярити разделение процессов сделано частично во время компиляции частично в рантайме, они не перестают быть процессами. От того что нитки (необязательно все, см. SDN4 Process Model.pdf) могут исполняться в одном адресном пространстве, они не перестают быть процессами -- изоляция сделана во время компиляции, разделением на интерфейсы

не надо прятаться за канонические определения и пороть чушь вроде "определение не применимо", а надо смотреть по сути, как оно тут реализовано. От того, что процессы назовёшь "командами тредов", а модули ядра -- сервисами/менеджерами, суть не изменится.

>За счет этого про идее должна вырости производительность -- процессору нет надобности переключать контексты задач, сбрасывая при этом какие-то кэши, делать проверки доступа к памяти, и.т.д. Передача какого-то буффера между процессами, например, -- это просто передача ссылки на массив. Не надо копировать, не надо отображать.

Без JIT плохо будет жить, а в нем будут дырки точно.

>не надо прятаться за канонические определения и пороть чушь вроде "определение не применимо", а надо смотреть по сути, как оно тут реализовано. От того, что процессы назовёшь "командами тредов", а модули ядра -- сервисами/менеджерами, суть не изменится.

erlang тогда был бы гораздо лучше для этого.

>Без JIT плохо будет жить, а в нем будут дырки точно.

Будут латать. В процессорах вон тоже дыры бывают :)

> Будут латать. В процессорах вон тоже дыры бывают :)

А смысл переносить это на уровень VM, когда ту же песню можно замутить без него?

> Единое адресное пространство - значит один процесс может писать в данные другого процесса?

контролируемо, управляемо (конкретный интерфейс каналамов/протоколов, выполнением управляемого кода, контролируемой выдачей указателей на ресурсы) читать раздел публикации по теме http://en.wikipedia.org/wiki/SASOS

> А смысл переносить это на уровень VM, когда ту же песню можно замутить без него?

Во-первых, на уровне VM это можно сделать эффективнее. Во-вторых, процессоры можно _сильно_ упростить. Заодно и похоронить наконец x86, лол.

>Во-первых, на уровне VM это можно сделать эффективнее. Во-вторых, процессоры можно _сильно_ упростить. Заодно и похоронить наконец x86, лол.

Нет, эффективние на x86 камне оно не станет. Процессоры упрощать, куда? Затачивать исключительно под эту VM? x86 не похоронят еще долго, но может же человек мечтать :-)

>А смысл переносить это на уровень VM, когда ту же песню можно замутить без него?

А смысл? Насколько я понимаю, тут VM нужна по большому счету лишь для перевода байткода в нативный, хранение каких-то метаданных. Плюс еще сборка мусора, но насколько я понимаю, GC -- это важный момент безопасности кода.

>erlang тогда был бы гораздо лучше для этого.

ну в общем, да. Процесс = нити+контекст процесса(общая память+структуры "ядра" с состоянием процесса) +общий интерфейс управления процессами. Если есть унифицированный общий интерфейс, то это процесс, не важно как он физически реализован, хоть конечными автоматами, хоть аппаратно, хоть программно.

>ну в общем, да. Процесс = нити+контекст процесса(общая память+структуры "ядра" с состоянием процесса) +общий интерфейс управления процессами. Если есть унифицированный общий интерфейс, то это процесс, не важно как он физически реализован, хоть конечными автоматами, хоть аппаратно, хоть программно.

Ну да и кластеризацию можно накинуть, одна ОС на несколько компьютеров, вот это песня :-)

> Нет, эффективние на x86 камне оно не станет. Процессоры упрощать, куда? Затачивать исключительно под эту VM? x86 не похоронят еще долго, но может же человек мечтать :-)

Сказал, как отрезал. А обосновать? Почему не станет, почему не надо упрощать процессоры, почему x86 не похоронят? Внемлю, отче.

>Нет, эффективние на x86 камне оно не станет.

Почему? Java процессоры, например, показали неэффективность прямого исполнения байт-кода. JIT оказался выгоднее.

Конечно, сама по себе VM может выиграть за счет какой-то специально поддержки со стороны процессора (например, быстрые forwarding pointers для GC)

>Процессоры упрощать, куда?

Есть куда :) x86 -- это ужас какая сложная система. Можно сделать примитивный процессор, без сегментной модели, с простой поддержкой виртуальной памяти, без всяческих колец защит. Пусть даже и с системой команд x86.

>> Процессоры упрощать, куда?

> Есть куда :) x86 -- это ужас какая сложная система.

Ыыы... кто тебе это сказал?

> Можно сделать примитивный процессор, без сегментной модели, с простой поддержкой виртуальной памяти, без всяческих колец защит

Виртуальная память без колец защиты? o_O И хотелось бы таки услышать - насколько упростят "обычный x86" предложенные меры? Какая экономия вентилей/кремния, насколько уменьшится цена?

>Сказал, как отрезал. А обосновать? Почему не станет, почему не надо упрощать процессоры, почему x86 не похоронят? Внемлю, отче.

Эм... чистая логика, VM поверх "другого VM(хоть и аппаратного)" хуже чем просто чистый "другой VM(аппаратный)". Если дальше упрощать, то это будет уже что-то узкоспециализированное. x86 приносит огроменное бабло сейчас, есть процессоры лучше, но они опять не популярны массово.

>Есть куда :) x86 -- это ужас какая сложная система. Можно сделать примитивный процессор, без сегментной модели, с простой поддержкой виртуальной памяти, без всяческих колец защит. Пусть даже и с системой команд x86.

Т.е. спихнем это на software реализацию?

>Есть куда :) x86 -- это ужас какая сложная система. Можно сделать примитивный процессор, без сегментной модели, с простой поддержкой виртуальной памяти, без всяческих колец защит. Пусть даже и с системой команд x86.

Узкоспециализированный процессор для конкретной VM.

>Почему? Java процессоры, например, показали неэффективность прямого исполнения байт-кода. JIT оказался выгоднее.

Ну влейте в них бабла как в x86 и времени дайте ;-)

Ктонибудь вбейте костыль из осины в это .

>Ыыы... кто тебе это сказал?

Книжки умные читал.

>Виртуальная память без колец защиты? o_O

А в чем проблема? Оставить преобразование логического адреса в физический. На биты защиты забить.

>И хотелось бы таки услышать - насколько упростят "обычный x86" предложенные меры? Какая экономия вентилей/кремния, насколько уменьшится цена?

Без понятия. С точки зрения стоимости даже удорожит, ибо менять == тратить деньги. С точки зрения перформанса -- тоже хз.

> Узкоспециализированный процессор для конкретной VM.

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

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

Чтобы ускорить выполнение этого надо будет поковыряться в архитектуре процессора и пойдет "упрощение" со временем.

> Ну влейте в них бабла как в x86 и времени дайте ;-)

Проще и дешевле в Inferno какое-нибудь влить бабла.

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

С другой стороны, выкосив эти функции из процессора, он станет более специализированным, потому что обычные ОС на нем уже работать не будут :)

>Проще и дешевле в Inferno какое-нибудь влить бабла.

Вот-вот.

>Ну влейте в них бабла как в x86 и времени дайте ;-)

Java-байткод вроде как сам по себе плох для исполнения. Поэтому JIT всё равно какой-то будет. Те же яйца. Разве что в процессоре будут специфичные фишки типа forwarding pointers, может какая-нибудь теггированная память, которые ускорят VM.

> Чтобы ускорить выполнение этого надо будет поковыряться в архитектуре процессора и пойдет "упрощение" со временем.

Чего куда ускорять? Нынешние 86-е процессоры и так перед выполнением транслируют код в RISC-подобные инструкции, вот можно и избавить их от этой работы и поручить это JIT-у. Откуда взяться тормозам? Или ты думаешь, что если йабба тормозит и хавает память by design, то и любая другая VM обладает теми же свойствами?

>>Ыыы... кто тебе это сказал?

>Книжки умные читал.

Изданы книжки были примерно в 80-х, во времена RISC-революции? :D Все современные процессоры примерно одной сложности (исключением, пожалуй, является ARM), и декодер x86 CISC -> CPU-specific RISC uops не сильно увеличивает сложность процессора (и дает преимущества, кстати).

>>Виртуальная память без колец защиты? o_O

>А в чем проблема? Оставить преобразование логического адреса в физический. На биты защиты забить.

Это подразумевает софт, написанный исключительно на managed языке, и безошибочный транслятор в натив. Ну и обычное использование виртуальной памяти сильно полагается на copy-on-write, который невозможен без защиты.

>>И хотелось бы таки услышать - насколько упростят "обычный x86" предложенные меры? Какая экономия вентилей/кремния, насколько уменьшится цена?

>Без понятия. С точки зрения стоимости даже удорожит, ибо менять == тратить деньги. С точки зрения перформанса -- тоже хз.

Понятно. Выгод не видишь даже ты.

>Чего куда ускорять? Нынешние 86-е процессоры и так перед выполнением транслируют код в RISC-подобные инструкции, вот можно и избавить их от этой работы и поручить это JIT-у.

Вот, уже есть что подкрутить.

>Откуда взяться тормозам?

Ну если перенести всю логику на vm, то это еще надо посмотреть как оно будет.

>Или ты думаешь, что если йабба тормозит и хавает память by design, то и любая другая VM обладает теми же свойствами?

Какие у нас еще есть приличные VM?

ПЕРЕИМЕНУЙТЕ

Статью переименуйте, что ли.

Freeware ОС на .NET здесь не место.

>Изданы книжки были примерно в 80-х, во времена RISC-революции? :D Все современные процессоры примерно одной сложности (исключением, пожалуй, является ARM), и декодер x86 CISC -> CPU-specific RISC uops не сильно увеличивает сложность процессора (и дает преимущества, кстати).

Речь шла не только о трансляторе команд.

>Это подразумевает софт, написанный исключительно на managed языке, и безошибочный транслятор в натив.

Ты хоть новость-то читал? Да, именно это допущение и берется.

>Ну и обычное использование виртуальной памяти сильно полагается на copy-on-write, который невозможен без защиты.

Что значит -- обычное? fork -- это, что-ли, обычное? Я виртуальную память только для "свопа" и "оставил".

>Понятно. Выгод не видишь даже ты.

В смысле -- даже я? Я-то как раз относительно далек от всего этого, поэтому может и не вижу. К разработке процессоров отношения не имею.

>йабба тормозит и хавает память by design,

Тормозит и жрет память Java из-за криворуких программеров и сложившейся традиции писать приложения используя не менее 20 слоев абстракции. GC, метаданные, нативный код, и.т.д, конечно, тоже память кушает, но не то чтобы сильно много.

линупс

гы кучка ламеров обсуждают то, о чём не имею ни малейшего представления

>>>Виртуальная память без колец защиты? o_O

>>А в чем проблема? Оставить преобразование логического адреса в физический. На биты защиты забить.

>Это подразумевает софт, написанный исключительно на managed языке, и безошибочный транслятор в натив

не факт. Если бы была аппаратная поддержка тегированной памяти в одном едином адресном пространстве, и управлять корректной выдачей тегов, есть доступ к ресурсу="указатель с соотв. тегом валиден", то можно было бы прозрачно отобразить существующую схему туда. Загружены процессы в разные адресные пространства = загружены в одно, но с разными тегами, нужна mmap память = даём двум процессам одинаковую ссылку с новым тегом, на который есть права у обоих процессов.

> Ну и обычное использование виртуальной памяти сильно полагается на copy-on-write, который невозможен без защиты.

тут да, с тегами то-то ничего красиво не придумывается.

>> Это подразумевает софт, написанный исключительно на managed языке, и безошибочный транслятор в натив.

> Ты хоть новость-то читал?

Конечно. И не только ее ;)

> Да, именно это допущение и берется.

Опасное допущение, ИМХО.

>>Ну и обычное использование виртуальной памяти сильно полагается на copy-on-write, который невозможен без защиты.

>Что значит -- обычное? fork -- это, что-ли, обычное?

В Unix - да, обычное. Но вообще я имел в виду любое совместное использование кода.

>>Понятно. Выгод не видишь даже ты.

>В смысле -- даже я?

Ты сказал, что x86 есть куда упрощать. Если ты при этом имел в виду "упрощать есть куда, но смысла никакого нет" - что ж, я тебя не так понял.

> Если бы была аппаратная поддержка тегированной памяти в одном едином адресном пространстве, и управлять корректной выдачей тегов, есть доступ к ресурсу="указатель с соотв. тегом валиден", то можно было бы прозрачно отобразить существующую схему туда. Загружены процессы в разные адресные пространства = загружены в одно, но с разными тегами, нужна mmap память = даём двум процессам одинаковую ссылку с новым тегом, на который есть права у обоих процессов.

У одного из нас в голове крутая каша из теговой архитектуры, мандатной (capability-based) архитектуры и классической архитектуры с виртуальной памятью.

>Конечно. И не только ее ;)

Ну тогда откуда такие вопросы? Речь идет только о теоретических плюсах Singularity.

>В Unix - да, обычное. Но вообще я имел в виду любое совместное использование кода.

Кстати, у нас же одно адресное пространство (см. допущение выше). Смысл виртуальной памяти в таком случае -- только для "свопа".

>Ты сказал, что x86 есть куда упрощать. Если ты при этом имел в виду "упрощать есть куда, но смысла никакого нет" - что ж, я тебя не так понял.

Я сказал, что есть куда, но имеет ли смысл это делать в долгосрочной перспективе (когда Singularity захватит мир :) ) -- я хз. В короткосрочной -- естественно, нет.