Re: Есть ли будущее у Native Code?
От: jazzer Россия Skype: enerjazzer
Дата: 22.06.09 16:54
Оценка: 1 (1) +18 -1 :))) :)))
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?

Нет.

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?

Нет.

C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Нет.


З.Ы. Теперь согласные/несогласные могут ставить плюсики либо мне, либо WolfHound-у
P.P.S. На самом деле, осталось еще 6 вариантов ответа...
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 22.06.09 15:55
Оценка: +2 -4 :))) :))) :))) :))
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?

Да.

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?

Да.

C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Да.

Но не скоро.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Есть ли будущее у Native Code?
От: Chrome  
Дата: 22.06.09 15:53
Оценка: :))) :))) :)
Или его со временем полностью вытеснит верифицируемый промежуточный код?
Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
Re: Есть ли будущее у Native Code?
От: Sheridan Россия  
Дата: 16.09.09 09:05
Оценка: -5 :))
Приветствую, Chrome, вы писали:

C> Или его со временем полностью вытеснит верифицируемый промежуточный код?

C> Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
C> Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Надеюсь я до этого кошмара не доживу.
avalon 1.0rc2 rev 300, zlib 1.2.3
build date: 19.08.2009 14:13:36 MSD +04:00
Qt 4.5.2
Matrix has you...
Re[13]: Есть ли будущее у Native Code?
От: jedi Мухосранск  
Дата: 23.06.09 16:51
Оценка: +3 -1
G>"сила" шахматного алгоритма зависит от реализации оценки позиции и алгоритма перебора вариантов ходов, ковыряние с битами в таких алгоритмах противопоказано. Наносекундные вычисления с битами вероятнее всего незаметны будет.

Спасибо, рассмешил.
Меня вот удивляет откуда такие знатоки всего беруися?

На всякий случай. Товарища Мистика я знаю лично и знаком с его реальными результатами в написании движков (в частности, очень неплохого шашечного).
А Вы, товавищ gandjustas, чем прославились на этом поприще?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[17]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 10:58
Оценка: -3 :)
Здравствуйте, Sinclair, Вы писали:

S>Но, к примеру, в x86 ассемблере никаких "переменных" нет. Есть регистры и стек; компилятор генерирует исключительно обращения к ним.


В школу! В первый класс!!!


// комментарии мои - DP

handle  dw      ? // это что такое  ?
infobyt db      ? // а это ?
line    db      320 dup (?) // а это массив, к твоему сведению
linesiz dw      ?
stepsiz dw      ?
palette db      768 dup (?)
parseg  dw      ?
palsiz3 dw      ?
showit  db      ?
txtsize dw      ?
vs      db      ?
        .code
        mov     ax,ds
        push    ax
        mov     ax,@data
        mov     ds,ax


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

Извини, но после этого никакие вопросы, связанные с работой на уровне ниже ЯВУ обсуждать с тобой смысла не имеет.


S>Поясняю: даже если объект иммутабельный, в R/O память его положить нельзя. Ну, разве что ты собрался выделять по 4к на каждый экземпляр.


Обоснуй. Кто мне мешает там кучу завести ? Тот факт. что объекты не изменяются, не значит, что их нельзя удалять, вести список свободных блоков и т.д хоть по схеме CRT heap, хоть по схеме .Net heap.

>Потому, что в отличие от константы, значение immutable объекта может не быть доступно на момент старта программы.


И не надо. Его туда (в R/O) должен помещать специальный конструктор или new или вместе

immutable Type a = new immutable Type(...);

> И, в отличие от константы, иммутабельный объект не существует неограниченно долго.


И что с того ? См. выше — никто не мешает его удалять. Это будет делать его delete/деструктор в C++ или GCImmutable в .Net.

S>С точки зрения аппаратуры, место, занятое иммутабельным объектом, всё же выступает в роли lvalue — в него сначала присваивают некоторое значение, потом сколько-то раз им пользуются, а потом повторно используют это же место под другие объекты (потому, что аппаратуры с неограниченным объемом storage еще не придумали).


Совершенно верно.

S>Использование аппаратной защиты для обеспечения иммутабельности на реальной аппаратуре просадит производительность.


Нет. Я уже тысячу раз объяснял — проверки записи в процессоре аппаратны и делаются всегда при записи.


>А, главное, не даст никакого выигрыша даже на "идеальной" аппаратуре, где запрет записи делается бесплатно с гранулярностью до байта.


А зачем тебе доступ с этой гранулярностью ? Никаких проблем и сейчас нет.

А хочешь, я тебе секрет открою? В С++ есть иммутабельный объект. Защищается именно механизмом страничной защиты. Догадался, о чем речь идет ?

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

S>Я уже понял, что ты воспринимаешь ровно один уровень абстракции. Ни подняться выше, ни спуститься ниже ты не хочешь. Ок, это твой свободный выбор, добровольное самоограничение.

Мне уровни абстракции нужны в этих рассуждениях , как корове седло. Оставь их для других случаев, там я могу их обсуждать. А здесь я одно утверждаю — что ни делайте, какие средства ни придумывайте, но пока аппаратура нынешняя. все равно вы мимо этого слоя не пройдете. Вот и все.
With best regards
Pavel Dvorkin
Re[24]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 25.06.09 11:41
Оценка: -1 :)))
Здравствуйте, Sinclair, Вы писали:

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

S>>как вариант — поддержка всех этих конструкций на уровне байткода. их не так много, а выигрыш должен быть заметным.
S>За счёт чего? Выигрыш может случиться только за счёт отказа от других инструкций, которые теперь не нужно будет верифицировать.

большинство циклов — foreach. проход по коллекциям, массивам итд. верифицировать такое в разы проще, чем ковырять то, во что оно в итоге развернется. ну и оставшийся один из тысячи обычный цикл, где по логике программы действительно надо перебрать все индексы, будет верифицирован как обычный цикл.
Re[9]: Есть ли будущее у Native Code?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.10.09 14:59
Оценка: 7 (2) +1
Здравствуйте, WolfHound, Вы писали:

WH>>>Управляемые системы позволят от этой нашлепки избавиться.

G>>Правда штоли . А язык С, и прочие языки высокого уровня, значит, принципиально недостаточно портабелены, чтобы "от этой нашлепки избавиться"?
WH>А ты что не знал?
WH>Доказательство простое и совершенно не опровержимое: Если бы они были достаточно портабельны то эта нашлепка бы не появилась.

Угу. Так же как и доказательство того, что ты инопланетянин.

Дано: 2+2=5.
Отсюда неопровержимо следует, что 2 = 1. Вы и инопланетянин — вас двое. 2 = 1 — вы одно и то же лицо.

G>>Как все невероятно просто у вас. "Просто" описать "модель нового процессора". Ты когда нибудь портабельную ОСь под новый проц и борду портировал? Попробуй, увлекательнейшее занятие. Про разработку процессоров я уж и не спрашиваю .

WH>А давай ты сравнишь эти затраты хотя бы с простой перекомпиляцией всего софта в мире под новый процессор и доставкой бинарников пользователям, а если учесть что очень большое количество софта так просто под новый процессор не перекомпилировать (привет языкам "высокого" уровня типа С/С++) то

А давай ты сам займешься глупостями, которые выдумаваешь, вместо того, чтобы предлагать это мне? Это справедливо. Как-никак никого кроме тебя в мире не волнует проблема перекомпиляции всего софта в мире под новый процессор. Ведь новые процессора по большей части волшебным образом совместимы по системе команд со старыми.

WH>Даже переход на x86-64 был тем еще приключением.


WH>Не смотря на то что винда64 появилась быстро пользоваться ей было невозможно очень долго ибо не было драйверов (вот скажи мне зачем драйверу устройства знать систему команд CPU?), эмуляторы CDROM'ов тоже не работали (этим тоже система команд CPU должна быть до лампочки),... даже не весь прикладной софт работал не смотря на то что винда запускала его в режиме совместимости.


И почему это в макоси нет таких проблем, интересно? Наверное, они в Купертино что-то не так делают, и уж явно курят что-то менее забористое, чем в MS, раз обошлись без выдумок в духе Singularity.

И у IBM с их серверами на базе Power тоже проблема отсутствует, почему-то. WTF?

И у DEC с их Alpha почему-то все в порядке было с переходом. Ну не чудеса-ли?

WH>И это не вспоминая про такие вещи как надежность и безопасность управляемого софта.


При чем тут ОСь-то, а? Пускайте себе свой "супернадежный управляемый софт" как пользовательские процессы — руки прочь от процессоров и оперсистем Для обеспечения надежности оси достаточно запускать драйверы и сервисы в рамках отдельных процессов, и оптимизировать архитектуру проца под микроядра. Все.

Так скорее всего и сделают, как только данная проблема станет кого-либо по серьезному волновать — не будут производители микроэлектроники полагаться на изобретение единственной компании. Как в свое время оптимизировали исполнительный конвейр под С++, добавив, к примеру, предсказание косвенных переходов.

Волнует же данная проблема в настоящий момент по большей части embedded-разработчиков, причем в специфических областях — космос, медицина, военщна, и прочее. Танненбаум уже проблемой занялся, к примеру — именно в этом ключе.

G>>Это да. Зато с несуществующей пока пригодной к "продакшну" осью, о которой ты говоришь — любой фокус пройдет . То, что еще не работает толком — всегда обладает чудесными свойствами, это ж всем известно.

WH>Ты можешь ехидничать сколько влезет но от фундаментальных проблем классического подхода твое ехидство не спасет.

Причина моей иронии в том, что "фундаментальные проблемы классического подхода" существуют по большей части в твоем воображении. Как и их воображаемое решение.

Чтобы понимать "фундаментальность" проблем, и видеть пространство возможных решений вместо одного (что необходимо для осмысленного, а не фанбойского анализа альтернатив), надо знать элементарные принципы устройства аппаратуры и иметь опыт работы с железом. Уметь цитировать материалы по singularity из сети для этого недостаточно.
Re[22]: повтор
От: IID Россия  
Дата: 01.07.09 08:33
Оценка: 6 (2) +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Тебе же тут уже объяснили — не работайте под админом. Кстати, как ты собираешься устроить эту самую эскалацию для процесса броузера, если он (под Вистой) запущен хоть и от админа, но без админских прав ? (т.е с юзеровскими правами) Это тоже очень интересно бы знать

WH>>>Через переполнение буфера например.Что думаешь в WinAPI ни одного нет?

PD>Пожалуйста, подробности того, как это может произойти. То есть ты переполнишь буфер, а результат — эскалация привилегий для процесса броузера. Win API для запущенных процессов изменить токен в плане добавления прав не дает.


Всё не так. Эскалация привелегий происходит с помощью атаки на процесс, работающий с нужными привелегиями. Например:

[Атака на службы]
Есть много сервисов, исполняющихся с повышенными привелегиями. Эти сервисы обрабатывают запросы менее привелегированных процессов. (Собственно они и существуют для этих целей, чтобы не вынуждать конечное приложение иметь слишком много полномочий.) Через LPC/RPC, ага. Если в таком сервисе есть уязвимость — теоретически можно сформировать запрос, который приведёт к исполнению кода злоумышленника. Причём необязательно код должен содержаться в самом запросе. Это актуально при атаке на внешние системы. Для локальных атак вполне достаточно, скажем, заставить процесс загрузить специально подготовленную DLL и привет. И даже не обязательно переполнять буфера. Достаточно криво написанной службы, которую можно "обмануть". Очень многие программисты пишут код откровенно халатно, не обращая внимание на безопасность. Им бы надо руки отрубать, а не придумывать очередные памперсы (а теперь новые! с выводом типов и запахом банана! тьфу!)

[Атака на драйвера]
Соответственно драйвера тоже умеют обрабатывать запросы от юзермодного кода. Вкратце: драйвер создаёт устройство и символическую ссылку на него. После этого юзермодный код может попытаться открыть устройство (через CreateFile). Из открытого устройтсва можно читать/писать (если драйвер сообщил что он это умеет) и отправлять I/O команды (через DeviceIoControl). На объект устройства ставятся (при создании) нужный набор ACL-ей, и система сама проверит права доступа при открытии устройства. Надо ли говорить, что доморощенные драйверописатели на это кладут с пробором ? Ну а дальше начинаются старые знакомые атаки, эквивалентные акакам на службы. Только кроме парочки LPC/RPC + конфигурационные параметры, добавляется вектор ReadFile/WriteFile/DeviceIOControl.
kalsarikännit
Re[14]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 07:15
Оценка: 4 (1) +2
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Может, тебе основы организации компьютера почитать ? Чтобы понять, что независимо от языка, при выполнении программы дело закончится некими действиями с блоками памяти ? По крайней мере до тех пор, пока вместо ОП не появятся аппаратно реализованные абстракции твоего любимого языка.
А зачем мне про это читать? Это ты всё время путаешь уровни абстракции.
Вот ты говоришь:

дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.

Ты здесь под программой что имеешь в виду? Исходную программу, или её некоторое воплощение в код реальной машины?

Большинство программистов таки понимают первое. В таком контексте, переменная (storage) — это чисто математическая абстракция, которая применяется при описании семантики языков программирования. Не всех, разумеется, а только некоторого подмножества императивных.
Опять же, намекну, что даже императивному языку не обязательно оперировать переменными. К примеру, HPGL без них прекрасно обходится, являясь, в сущности, взрослым развитием языка LOGO.

Но дальше ты говоришь про "выполнение программы". Тут как бы ты перепрыгиваешь на уровень ниже — там от программы почти ничего не остаётся. Да, там есть что-то вроде "блоков памяти" (ну, то есть даже внутри "аппаратной машины" всё еще есть разные уровни абстракции; на более высоких есть только регистры ЦПУ, память и порты, а на более низких видны все детали буферов, защёлок и прочих потрохов различных устройств). Но никаких переменных к этому моменту уже не остаётся.

И нас как раз очень-очень мало* интересует вопрос о том, какой процент блоков памяти перезаписывается при выполнении программы.

Иммутабельность переменных не имеет к этому никакого отношения. Я в очередной раз попробую открыть тебе америку: даже самая императивная программа на языке вроде C++ при компиляции на время переводится в SSA форму. Это как раз та форма, где каждая переменная получает значение ровно один раз, становясь, таким образом, иммутабельной. И уже из этой формы оптимизатор получает необходимый набор низкоуровневых манипуляций с регистрами и памятью.

(*) Точнее, нас интересует этот и прочие вопросы. Но он интересует нас в отрыве от исходной программы. Мы хотим, чтобы исходная программа была
а) как можно понятнее (чтобы меньше был шанс сделать в ней ошибку, и больше был шанс ошибку найти)
б) как можно короче (чтобы меньше было места сделать ошибку)
в) как можно менее навязчивой в описании того, какие именно операции мы хотим от железки — чтобы развязать руки оптимизатору.

Вот пункт в как раз и есть про оптимизацию. Начинающим программистам кажется, что самый дружественный к оптимизации язык — это такой, на котором можно делать ассемблерные вставки. Неа. Самый дружественный — это такой, в котором нельзя делать ассемблерные вставки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Есть ли будущее у Native Code?
От: jedi Мухосранск  
Дата: 23.06.09 17:07
Оценка: +2 -1
Здравствуйте, gandjustas, Вы писали:

J>>На всякий случай. Товарища Мистика я знаю лично и знаком с его реальными результатами в написании движков (в частности, очень неплохого шашечного).

J>>А Вы, товавищ gandjustas, чем прославились на этом поприще?
G>Я тоже написал шашечный движок, еще классе в восьмом или девятом. И что?

Поздравляю. Видимо на этом основании Вы сделались абсолютным знатоком во всех без исключениях областях человеческой деятельности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[12]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 12:56
Оценка: 1 (1) +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ты сначала разберись, чем отличается виртуальная память от физической (включая своп),

Я это понимаю не хуже тебя.

PD>чтобы не говорить такое.

Какое такое?

PD>То, о чем ты говоришь, есть управление физической памятью в ОС, своп файл и RAM исключительно под ее контролем, я туда никак из 3 кольца попасть не могу. А сборка мусора есть действие исключительно в виртуальной памяти процесса.

Почему исключительно?

PD>А если не секрет, как из программы 3 кольца узнать, как давно мы не обращались к этой странице ?

А ей и не надо.
Хачим ОСь и вперед.
Мир одной виндой не ограничен.

PD>Юмор могу и оценить, но честное слово, кончай высказываться по вопросам, в которых ты не разбираешься! У тебя есть области, в которых ты разбираешься неплохо, зачем тебе лезть туда, где ты ничего не понимаешь и говорить чепуху ?

А может это ты не понимаешь?

PD>И все же, если в формуле для корней квадратного уравнения я напишу sqrt(b*b+4*a*c), какие зависимые типы это отловят ? А может, мне именно так и надо ?

Я не сказал все.
Я сказал многое.

PD>Да все можно — в теории.

Почему в теории?
Языки с зависимыми типами делают это на практике.

PD>И твоя тотально управляемая ОС в теории тоже не так уж плоха. Как идея. Но реально тебе накидали немало возражений (DMA, текстуры, внешние устройства), могу еще и свое добавить — CUDA, там надо резидентную память иметь.

Только куберакс сам признал что там все будет не хуже чем сейчас...

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

Единственное что нужно изменить в современном железе это добавить IOMMU.
Все!
А его уже добавляют...

PD>А ты чем заплатишь ? Некоторой (и то в теории, никто же не проверял) надеждой на улучшение надежности программ, которые не будут лезть куда не надо ?

Ну почему же в теории?
Даже тупая жаба и та демонстрирует вполне себе приличные результаты.

PD>И ради этого переписать все ПО, переделать всю аппаратуру ? И ради этого миллиарды долларов ? Не дадут.

ПО можно переделывать постепенно. Ведь можно начать с относительно небольших ниш.
Тем более что начать можно даже не с полноценной ОС, а с виртуальной машины типа жабы. А когда программ будет достаточно можно уже и в полноценную ОС превращаться. Да и смешанный вариант тоже доступен.
Железо подойдет современное.
Даже без IOMMU но тогда периферии придется доверять. В прочем в современных ОС ей и так доверяют.

PD>Именно. Я же об этом и говорю. Разные есть задачи. А машина одна

А процессор один.
Ты сказать то что хотел?
Что нештатные ситуации обрабатывать не надо?

PD>Так разные же есть задачи. Вот ты писал, как говоришь, числодробилки. Там констант много было ? Как бы все не кончилось 4 константами — 0 , 1 pi и e

Числомолотилки прекрасно пишутся на функциональщине при наличии оптимизатора.
А есть и более интересный базис.
Абстрактная сетевая машина называется.
Одно из свойств этого базиса частичные вычисления, а это ключ к очень мощной оптимизации.
Другое замечательное свойство это независимость результата от порядка вычислений, а это ключ к распараллеливанию.

А еще у меня есть чувство что сплав АМС и зависимых типов будет практически идеальным базисом для произвольных DSL.

PD>Так, стоп. Под переменными я имею в виду отнюдь не описания

PD>List* pL;
PD>безусловно формально одна переменная, но в действительности их тут столько, сколько полей у всех элементов списка.
И чё?
У меня и в таком свете переменных мало.

PD>Я с немерле не знаком, поэтому спорить не буду. Но по существу, думаю, они и там есть, хотя формально, может, и нет.

Не надо думать. Надо знать.
Вот например простенький оптимизатор без единой переменной.
  partial internal class Optimizer
  {
    public static CanInline(name : string, grammar : Grammar) : bool
    {
      def canInline(rule, recRules)
      {
        match (rule : Rule)
        {
        | Call(name)               =>
          if (recRules.Contains(name))
            false;
          else
            canInline(grammar.GetRule(name), recRules.Add(name));
        | Choice(rules)            => rules.ForAll(rule => canInline(rule, recRules));
        | Sequence(rules)          => rules.ForAll(rule => canInline(rule, recRules));
        | Capture(_, rule)         => canInline(rule, recRules);
        | RepeatMin(_, rule)       => canInline(rule, recRules);
        | RepeatMinMax(_, _, rule) => canInline(rule, recRules);
        | Not(rule)                => canInline(rule, recRules);
        | And(rule)                => canInline(rule, recRules);
        | Chars                    => true;
        | ExtensionPoint           => true;
        }
      }
      canInline(grammar.GetRule(name), Set().Add(name));
    }

    public static OptimizeRule(rule : Rule, grammar : Grammar) : Rule
    {
      def optimize(_ : Rule)
      {
      | Choice(rules) =>
        def rules = rules.Map(optimize);
        def rules = rules.Map(fun(_)
        {
        | Rule.Choice(rules) => rules;
        | rule => [rule];
        });
        def rules = rules.Flatten();
        def catChars(_)
        {
        | Rule.Chars([chars1]) :: Rule.Chars([chars2]) :: rules =>
          catChars(Rule.Chars([chars1.Sum(chars2)]) :: rules);
        | rule :: rules =>
          rule :: catChars(rules);
        | [] => [];
        }
        def rules = catChars(rules);
        match (rules)
        {
        | [rule] => rule;
        | _      => Rule.Choice(rules);
        }

      | Sequence(rules) =>
        def rules = rules.Map(optimize);
        def rules = rules.Map(fun(_)
        {
        | Rule.Sequence(rules) => rules;
        | rule => [rule];
        });
        def rules = rules.Flatten();
        def catChars(_)
        {
        | Rule.Chars(chars1) :: Rule.Chars(chars2) :: rules =>
          catChars(Rule.Chars(chars1.Append(chars2)) :: rules);
        | rule :: rules =>
          rule :: catChars(rules);
        | [] => [];
        }
        def rules = catChars(rules);
        match (rules)
        {
        | [rule] => rule;
        | _      => Rule.Sequence(rules);
        }

      | RepeatMin(min, rule)         => Rule.RepeatMin(min, optimize(rule));
      | RepeatMinMax(min, max, rule) => Rule.RepeatMinMax(min, max, optimize(rule));

      | Not(Not(rule))         => optimize(Rule.And(rule));
      | And(Not(rule))         => optimize(Rule.Not(rule));
      | Not(And(rule))         => optimize(Rule.Not(rule));
      | And(And(rule))         => optimize(Rule.And(rule));
      | Not(rule)              => Rule.Not(optimize(rule));
      | And(rule)              => Rule.And(optimize(rule));

      | Capture(name, rule)    => Rule.Capture(name, optimize(rule));
      | Chars as rule          => rule;
      | ExtensionPoint as rule => rule;

      | Call(name)             =>
        if (CanInline(name, grammar))
          optimize(grammar.GetRule(name));
        else
          Rule.Call(name);
      }
      optimize(rule);
    }
  }

Написать это короче практически невозможно.

PD>В конце концов по существу переменная (в широком смысле слова) — это некий блок памяти, содержимое которого может изменяться (а константы — не может).

А не надо мыслить блоками памяти.
Похоже ты опять спутал теплое с мягким.
Модель языка в рамках которой идут рассуждения о программе и то во что программа транслируется для исполнения на конкретном железе.
Так вот в моделях многих языков такого понятия как блок памяти не существует.

PD>А как это в языке оформлено — это уже от языка зависит. И такие переменные есть в любой программе на любом языке, иначе что это программа делает-то ?

См код выше.
Скока там переменных?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 05:01
Оценка: 1 (1) +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Опять двойка по ассемблеру. Подумай, не может ли состояние стека измениться вообще без выполнения каких бы то ни было команд

Конечно же может. Но к модели "память/регистры" это по-прежнему ничего не добавляет.

PD>В общем, все что я сказал про изменение атрибутов страницы с R/O на R/W и обратно, полностью отменяется. Не надо атрибуты вообще менять, никогда. Никаких вызовов VirtualProtect. Страница должна всегда находиться в R/O состоянии. Так что все функции, которые попытаются изменить объект, гарантированно провалятся.


PD>Остается маленький вопрос — а как же конструктор-то сможет в таком случае объект создать или операция newconst его разместить ? Решение чрезвычайно простое и элегантное. Конструктор и newconst (и только они!, ну еще, если надо, деструктор и deleteconst )будут работать с этой страницей по другому виртуальному адресу, с атрибутами R/W. При этом операция newconst будет возвращать R/O адрес в качестве адреса этого объекта, поэтому все функции будут работать с ним по R/O. А конструктор будет преобразовывать R/O адрес в R/W адрес и работать без всяких проблем. Все!!!

Осталось только гарантировать, что никто другой не станет обращаться к этим R/W страницам.

PD>В C# куча нефрагментирована, поэтому delta будет абсолютной константой. В Win32 если делать эту кучу так же, как и существующие, куча будет фрагментированной, поэтому вместо простого прибавления delta придется устроить чуть-чуть более сложный механизм (список из этих delta для отдельных фрагментов кучи)


PD>Константный конструктор может ничем не отличаться от обычного. Впрочем, лучше если он проверит, не делается ли при конструировании константы попытки записать в нее указатели на другие неконстантные объекты.

Толково придумано. Я бы не допёр. (с).

PD>Плата за решение.


PD>1. Дополнительный PTE на каждую страницу. Это 4(8) байт на 4096 байт, то есть 0.1-0.2%.

PD>2. Сокращается доступный размер адресного пространства. В пределе, если все 2 GB юзеровского пространства будут заняты этой константной кучей, мы будем иметь реально только 1GB. Но это уж слишком нереальная ситуация, в нормальной практике дополнительный расход будет несколько процентов. А уж в Win64 это вообще не будет иметь никакого значения — там сколько ни бери, все равно останется море.
PD>3. Дополнительные расходы по времени — одна операция сложения
Ок. А теперь давай посчитаем выгоды, и сравним их с программно-immutable объектами.
Ну и попробуем понять, чем же это всё таки отличается от immutable-типов. Заметь, что ты не собираешься менять статус объекта в течение всего времени его жизни — он рождается константным и остаётся константным. Такие свойства как раз характерны для типов.
Теперь возьмем два объекта одного класса (в терминах С++), которые отличаются только тем, как распределены — один при помощи твоей злой магии, другой нормальным образом.
Чем они отличаются в программе? Тем, что на одном из них вызов части методов будет гарантированно вызывать AV — как у тебя в setx.
Наверное, лучше было бы сделать так, чтобы компилятор не давал делать такие вызовы, не так ли? Зачем компилировать заведомо некорректную программу?

Ок, мы, в принципе, можем попробовать описать эту абстракцию в С++ при помощи механики const, хотя я не уверен, что оператор new имеет право возвращать такой указатель. Но это уже, в некотором смысле, дело техники. По крайней мере, у нас "забесплатно" будет два подтипа для каждого класса — один const, другой mutable. У одного из них часть методов запрещены.

Но это нам по-прежнему ничего не даст. Как я уже объяснял, правила совместимости типов в С++ реализованы крайне неудачно. Если я пишу
void IWantToBenefitFromImmutability(const int& shouldntChange)
{
}

, то никаких обязательств на вызывающего я не накладываю. Как мне потребовать, чтобы в меня передавали исключительно RO объекты?
Получается, что нужен какой-то другой язык. В котором правила совместимости типов жестче. Или не пользоваться зависимыми типами из С++, а вместо этого описывать иммутабл-тип руками для каждого конкретного случая (как и сделано в дотнете).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Есть ли будущее у Native Code?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.10.09 13:31
Оценка: 1 (1) +1
Здравствуйте, WolfHound, Вы писали:

T>>Виртуальная память влияет на производительность, накладные расходы в железе для неё минимальны (для реализации SPARC v8 под названием Leon3 и для известных мне вариантов MIPS — примерно размер регистрового файла, который сам ~10% от площади ядра микропроцессора). Для x86 успешное обновление TLB при промахе занимает ~400 тактов, для MIPS — ~40.

WH>Экономия ~10% от площади ядра микропроцессора и 0 тактов вместо от 40 до 400.
WH>Так и запишем.

Еще запиши, не забудь.
1) Упомянутое ядро MIPS без без кэшей и FPU, от которого отсчитан данный процент занимает примерно миллиметр площади на 130 нм. Пусть два. Миллиметр кристалла имеет себестоимость порядка 6 центов. И это для fabless компании — крупняку это стоит еще дешевле.
2) Промах в кэш TLB случается достаточно редко. Ты будешь экономить от 40 до 400 тактов на каждые несколько миллионов тактов, преведенные внутри циклов. Размер данного кэша специально выбирается так, чтобы промах не имел значения, прикинь, какая неожиданность?

Ага, прям так и запиши.

WH>>>Да и сам процессор можно сделать без лишних заморочек типа слоя совместимости с x86.

T>>А это-то здесь при чём?
WH>Ну при том что сейчас очень много процессоров с этой нашлепкой.
WH>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.

И даже в этом ты ошибся . Мне из достоверных источников известно, что у thesz iMac на базе PowerPC G5.

WH>Управляемые системы позволят от этой нашлепки избавиться.


Правда штоли . А язык С, и прочие языки высокого уровня, значит, принципиально недостаточно портабелены, чтобы "от этой нашлепки избавиться"?

WH>Ибо в случае с управляемой ОС нужно будет просто описать модель нового процессора.


Как все невероятно просто у вас. "Просто" описать "модель нового процессора". Ты когда нибудь портабельную ОСь под новый проц и борду портировал? Попробуй, увлекательнейшее занятие. Про разработку процессоров я уж и не спрашиваю .

WH>И весь софт стразу на нем заработает.

WH>С нативными ОС такой фокус не пройдет.

Это да. Зато с несуществующей пока пригодной к "продакшну" осью, о которой ты говоришь — любой фокус пройдет . То, что еще не работает толком — всегда обладает чудесными свойствами, это ж всем известно.
Re[2]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 07:34
Оценка: +1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Осталось выяснить разновидность этого самого промежуточного кода. Минимум два непримиримых кандидата на престол у нас уже есть — CLR и JVM. Так что, ИМХО, если кто-то кого-то и вытеснит, то точно не в ближайшее время.

Ни тот и ни другой.
У них система типов мягко говоря слабовата.
В ядре ОС без зависимых типов делать нечего.

C>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?

ГВ>Скорее нет, чем да.
А нафига оно надо если будет программная изоляция?

C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

ГВ>Нет, не утратит. ИМХО, по одной простой причине — в виртуальных адресных пространствах, в принципе, можно запустить хоть вагон управляемых ОС (каждой по сегменту и пусть никто не уйдёт огорчённым). Хотя, конечно, эти подходы можно и смешивать до определённой степени — т.е., управляемая ОС сможет запускать много чего Native.
Оно будет нужно только для того чтобы во всяких вмварях легаси запускать.
А для чего еще?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 10:47
Оценка: :))
Здравствуйте, 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) А. Эйнштейн
Re[8]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 12:56
Оценка: -1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>То есть ты хочешь сказать, что вирусы в состоянии нарушить аппаратную защиту защищенного режима, и , работая в 3 кольце, получить доступ к страницам, для которых U/S == 0 ? Расскажи , как это делают вирусы, мне это очень интересно

Да мне плевать как. Главное что вирусы пролезают в ядро не смотря на аппаратную защиту.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 13:03
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

WH>Да мне плевать как. Главное что вирусы пролезают в ядро не смотря на аппаратную защиту.


Ты хоть разберись, от чего эта аппаратная защита. Она имеет такое же отношение к вирусам, как я к китайскому императору.
With best regards
Pavel Dvorkin
Re[5]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 13:25
Оценка: +1 :)
Здравствуйте, WolfHound, Вы писали:

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


M>>Моему извращенному уму нативный код писать проще и приятнее.

WH>А мне нет ибо нативность отбирает кучу умственных ресурсов на вопросы не связанные непосредственно с задачей.

M>>А верифицируемость накладывает кучу ограничений, которые надо потом думать, как разрулить.

WH>Какие конкретно ограничения?

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

Например, я хочу хранить некоторые данные как последовательность заканчивается нулевым символом. Так мне удобнее всего в данном случае. Но, соотвественно, код, который берет по одному символу пока не наткнется на нулевой, уже не будет безопасным. И т. п. Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.
Re[8]: Есть ли будущее у Native Code?
От: IID Россия  
Дата: 24.06.09 07:19
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

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


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


PD>>>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.

WH>>Расскажи это писателям вирусов...

PD>То есть ты хочешь сказать, что вирусы в состоянии нарушить аппаратную защиту защищенного режима, и , работая в 3 кольце, получить доступ к страницам, для которых U/S == 0 ? Расскажи , как это делают вирусы, мне это очень интересно


Он гонит Вирусы всегда лезли в ядро через софт. Устанавливаясь драйвером, например. Или записывая себя с существующие драйвера. Или переключаясь в режим супервизора сервисом ОС (в 9x, привет WinCIHу).

Хотя, на самом деле, есть ошибки в процессорах, позволяющие влезть в SMM. Правда, для этого сначала надо получить права супервизора. (Вернулись к тому, с чего начали). К тому же дальше PoC публикаций это не пошло, баги аффектятся к ограниченному кругу моделей, вендоры в курсе и баги уже исправили.
kalsarikännit
Re[16]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 08:38
Оценка: -2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вряд ли. Иначе зачем ерунду пишешь ?

Ерундой она кажется только тем кто за деревьями не видит леса.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 04:38
Оценка: -2
Здравствуйте, Sinclair, Вы писали:

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

PD>>А поподробнее можно ? Вот передаем некоей Win API не тот буфер, не того размера. Насильно передаем. Объясни, что же будет.
S>Странно, что такие простые вещи нужно объяснять. Ищем уязвимость в существующем софте (как правило, она состоит именно в переполнении буфера), при помощи чего вызываем исполнение злонамеренного кода в контексте доверенного процесса.

Если в существующем софте есть ошибка, то все возможно. Но по постингу WolfHound можно понять так, что достаточно переполнить буфер , и мы попадем в страницы, находящиеся под контролем системы. А причина банальная — он не вполне понимает отличие виртуальной памяти от физической, он считает, что если выйти за пределы страницы, то мы попадем на соседнюю страницу физической памяти, которая может принадлежать системе
With best regards
Pavel Dvorkin
Re[31]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 11:35
Оценка: -1 :)
Здравствуйте, Sinclair, Вы писали:

S>Которая сначала "от языка не зависит, так как реализована на чисто Win API", а потом сразу же "речь идет о необходимости добавить кое-что для этой цели в язык".


Я думал, ты умнее.
With best regards
Pavel Dvorkin
Re[2]: Есть ли будущее у Native Code?
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 16.09.09 11:57
Оценка: :))
Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Chrome, вы писали:


C>> Или его со временем полностью вытеснит верифицируемый промежуточный код?

C>> Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
C>> Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

S>Надеюсь я до этого кошмара не доживу.


Мой минус прошу воспринимать как "нет, ты ДОЖИВЕШЬ до этого кошмара!"

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[8]: Есть ли будущее у Native Code?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.10.09 13:48
Оценка: +2
Здравствуйте, Gaperton, Вы писали:

WH>>Ну при том что сейчас очень много процессоров с этой нашлепкой.

WH>>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.

G>Кстати, по странному стечению обстоятельств процы с "этой нашлепкой" частенько стоят дешевле и работают быстрее, чем процы без нее. Представляешь, неувязочка какая получается. Вот, к примеру, компы Apple при переходе на Intel с Power стали внезапно быстрее раз в 5. Боюсь, данная нашлепка не мешает разработчикам процессоров из Intel и AMD. Они хорошие танцоры, видать.


Они простенький такой (по сравнению с остальным фаршем) блок внедряют в декодер команд, в самом начале конвейера, который преобразует х86 в нормальный трехадресный код. И весь основной конвейер у таких процессоров построен примерно на тех же принципах, что и конвейер RISC-процессора. Данная технология уже в течении десятка лет отработана, научились делать очень хорошо.

Оверхэд по площади — смешной для суперскалярного проца на 6 каналов арифметики, а производительность, как ни парадоксально, при таком подходе выше. А знаешь, почему? CISC код более компактен, чем RISC, что снижает требования к пропускной способности памяти, размеру кэшей, итд. А именно это — узкое место в настоящее время.

Вот так вот жизнь необычно устроена.
Re[21]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 04:27
Оценка: 6 (1)
Здравствуйте, Sinclair, Вы писали:

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


PD>>То-то, по утверждению Нортона, того, кто исключил стек из архитектуры IBM-360, "сослали во внутрифирменный аналог Сибири". Подумай, добавляет он или нет.

S>Не добавляет.

Опять двойка по ассемблеру. Подумай, не может ли состояние стека измениться вообще без выполнения каких бы то ни было команд

PD>>См. выше. Да, это некоторая проблема, я ее вижу. Но не нерешаемая.

S>Решение — в студию. Хотя бы набросок.

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

В общем, все что я сказал про изменение атрибутов страницы с R/O на R/W и обратно, полностью отменяется. Не надо атрибуты вообще менять, никогда. Никаких вызовов VirtualProtect. Страница должна всегда находиться в R/O состоянии. Так что все функции, которые попытаются изменить объект, гарантированно провалятся.

Остается маленький вопрос — а как же конструктор-то сможет в таком случае объект создать или операция newconst его разместить ? Решение чрезвычайно простое и элегантное. Конструктор и newconst (и только они!, ну еще, если надо, деструктор и deleteconst )будут работать с этой страницей по другому виртуальному адресу, с атрибутами R/W. При этом операция newconst будет возвращать R/O адрес в качестве адреса этого объекта, поэтому все функции будут работать с ним по R/O. А конструктор будет преобразовывать R/O адрес в R/W адрес и работать без всяких проблем. Все!!!

Таким образом, остается только иметь механизм , позволяющий для данной страницы с атрибутом R/O и виртуальным адресом pHeapRO, создать новый виртуальный адрес pHeapRW, который через механизм трансляции адреса показывает на ту же физическую страницу, только с атрибутами R/W. Иными словами, завести еще один PTE для некоторой страницы.

Для страниц, выделенных с помощью VirtualAlloc, я способа такое сделать в Win32 не знаю, думаю, что его нет. Но задача элементарно решается с помощью memory-mapped файлов, причем собственно файл и не понадобится, так как делать все можно на swap-файле (первый параметр CreateFileMapping должен быть INVALID_HANDLE_VALUE)

Вот вполне работающий пример


#include "stdafx.h"
#include "windows.h"
int delta; // реально нужен класс HeapManager, который будет хранить в себе эту delta в том числе
const int heapsize = 1024 * 1024;


class A{
    int x;
public:
    void Ctor(int _x) // только имитация. В действительности будет, конечно, несколько сложнее
    { 
        char* pWriteTo = (char*) this + delta;
        *((int*)pWriteTo) = _x;
    }
    void setx(int _x) 
    { 
        x = _x;
    }
    int getx()
    {
        return x;
    }
};

int _tmain(int argc, _TCHAR* argv[])
{
    HANDLE hMapping = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, heapsize,NULL);
    char* pHeapRW = (char*)MapViewOfFile(hMapping, FILE_MAP_WRITE, 0, 0, heapsize);
    char* pHeapRO = (char*)MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, heapsize);
    delta = pHeapRW - pHeapRO;

        // все вышенаписанное, конечно, в класс HeapManager

    A* pA = (A*) pHeapRO; // прототип выделения памяти в куче, то есть операции newconst. Я просто беру начало кучи
    pA->Ctor(100); // прототип вызова конструктора
    int y = pA->getx(); // эту функцию можно вызывать, она объект не изменяет. Хотя явно const в ней специально не написано
    pA->setx(99); // а эту нельзя, здесь AV

    // очистка и обработка ошибок опущены

    return 0;
}



В C# куча нефрагментирована, поэтому delta будет абсолютной константой. В Win32 если делать эту кучу так же, как и существующие, куча будет фрагментированной, поэтому вместо простого прибавления delta придется устроить чуть-чуть более сложный механизм (список из этих delta для отдельных фрагментов кучи)

Константный конструктор может ничем не отличаться от обычного. Впрочем, лучше если он проверит, не делается ли при конструировании константы попытки записать в нее указатели на другие неконстантные объекты.

Плата за решение.

1. Дополнительный PTE на каждую страницу. Это 4(8) байт на 4096 байт, то есть 0.1-0.2%.
2. Сокращается доступный размер адресного пространства. В пределе, если все 2 GB юзеровского пространства будут заняты этой константной кучей, мы будем иметь реально только 1GB. Но это уж слишком нереальная ситуация, в нормальной практике дополнительный расход будет несколько процентов. А уж в Win64 это вообще не будет иметь никакого значения — там сколько ни бери, все равно останется море.
3. Дополнительные расходы по времени — одна операция сложения
With best regards
Pavel Dvorkin
Re[9]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 16:35
Оценка: 5 (1)
Здравствуйте, WolfHound, Вы писали:

Ок, постараюсь описать суть проблемы. У каждого шахматного движка есть такой параметр, как размер хэша. Это то количество памяти, которое движку разрешено выделить пользователем для своих нужд. Например, при я хочу анализировать позицию одновременно двумя движками, поэтому я выделяю каждому из них по 512 Мб. Движки начинают работу и за пару секунд забивают хэш разными позициями, которые они включили в дерево перебора. Все позиции могут самым разным образом ссылаться друг на друга и вообще представляют собой достаточно запутанный клубок. После того, как хэш позиций заполнен, начинается вторая часть: движок определяет те позиции, которые считает неактуальными, и удаляет их из хэша. Потом продолжает анализ. И так много-много раз.

В случае GC подобную схему я вижу, например, только в такой реализации: время от времени я спрашиваю GC о том, какой размер памяти выделен динамически. Как только он превышает некоторое критическое значение, я должен освободить неактуальные позиции. Т. е. сделать их недостижимыми. Т. е. обнулить все ссылки на них. После этого я вызываю метод GC который бы форсировал освобождение кучи. Тут, конечно, возможны утечки: например я не сделал объект недостижимым и его не освободил GC. Но, главное, я очень сомневаюсь, что работа GC в таком режиме будет сопоставима по скорости с ручной работой.

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

Где у меня неправильные представления?
Re[6]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 04:31
Оценка: 3 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.
Это всё малоинтересно. С точки зрения пользователя, самое страшное уже произошло — в коде оказалась ошибка, и запрошенную операцию выполнить не удалось. То, что ядро системы продолжает успешно работать, никому (кроме авторов ядра) неинтересно*. Это и есть та причина (а вовсе не производительность), по которой обеспечение иммутабельности переменной при помощи аппаратной защиты никому не нужно.
Интересно иметь до начала выполнения программы гарантии того, что даже и попыток выполнить недопустимую операцию не будет.

(*) — нет, я понимаю, что бывают ситуации, когда в одной среде выполняются приложения с разными классами требований. Грубо говоря, не хочется, чтобы управление впрыском в двигатель заткнулось от того, что отвалился MP3-плеер. Но аппаратная защита всего лишь спасёт управление впрыском от ошибок в плеере; спасти управление впрыском от ошибок в управлении впрыском она не может. А вот статическая верификация — может. А то вон Титаник был оборудован превосходной аппаратной защитой от затопления — даже лобовое столкновение с айсбергом не утопило бы его; пострадала бы только носовая часть. И где теперь Титаник? А вот система, которая бы гарантировала отсутствие столкновений с айсбергами, позволила бы вовсе отказаться от дорогостоящих внутренних переборок, сократив вес и расход топлива
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 08:34
Оценка: 1 (1)
Здравствуйте, Курилка, Вы писали:

К>Зависимые типы они круты, безусловно, но вот, а какие ещё проблемы может дать "нехороший" код, которые зависимые типы должны по идее разрешить, кроме порчи памяти? В голову пока приходит только захват ресурсов (в т.ч. памяти), который будет мешать другим процессам (и ядерным возможно).

Я склоняюсь к мнению что примитивом общения между процессами должны быть каналы аля сингулярити.
Собственно зависимыми типами можно проверять что протокол отработан верно и что канал будет непременно закрыт.
Плюс можно доказывать отсутствие циклов и прочих задержек в критичных по времени местах.
И много чего еще что так с ходу не придумать.
Да и просто устранение проверок времени исполнения мягко говоря лишним не будет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 19:24
Оценка: 1 (1)
T>>Виртуальная память влияет на производительность, накладные расходы в железе для неё минимальны (для реализации SPARC v8 под названием Leon3 и для известных мне вариантов MIPS — примерно размер регистрового файла, который сам ~10% от площади ядра микропроцессора). Для x86 успешное обновление TLB при промахе занимает ~400 тактов, для MIPS — ~40.
WH>Экономия ~10% от площади ядра микропроцессора и 0 тактов вместо от 40 до 400.
WH>Так и запишем.

Вдогонку.

TLB обеспечивает 99%+ попаданий. 64 удреса страницы * 4KБайт на страницу — 256КБайт. Итого, на одно обращение расход времени из-за TLB у MIPS с его 40 тактами < 0.4 такта.

При промахе в L1 кэш задержка в ~5-15 тактов. Размеры L1 << размеры памяти, покрываемой TLB. L1 кэш менее эффективен.

Иными словами, ты можешь устранить TLB, но тогда тебе придётся делать что-то наподобие Fault-tolerant typed assembly language для защиты от кратковременных сбоев. А для его нормальной работы требуется суперскалярность и регистровый файл побольше, что не отставать от обычной железки. Кстати, расходы у FTTAL примерно в районе 30%.

Запиши эти новые факты и подумай снова.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 10:07
Оценка: 1 (1)
Здравствуйте, Mystic, Вы писали:


M>Я не говорю, что написать производительный движок под .NET в принципе нельзя. Сделать можно, но при этом наблюдается очень неприятный эффект: работая с абстрактными структурами я должен постоянно как бы компилировать возникающий код и смотреть, а что получится на более низком уровне. Все это делает работу менее удобной. Иногда я должен

M>в верифицируемом коде использовать всякие трюки, как-то GlobalPositions[GlobalPositions[CurrentIndex].Next], вместо CurrentPosition->Next.
Ты можешь определить эти методы в самой структуре (массив,индекс), аля курсор.
например

    internal struct Bookmark<K, V>
    {
        internal LeafPage<K, V> _page;
        internal int _index;

        public bool IsNull
        {
            get { return _page == null; }
        }

        public bool Next()
        {
            _index++;
            if (_index >= _page.Count)
            {
                if (_page.NextPage == null)
                    return false;
                else
                {
                    _index = 0;
                    _page = _page.NextPage;
                }
            }
            return true;
        }

        public bool Prior()
        {
            _index--;
            if (_index < 0)
            {
                if (_page.PriorPage == null)
                { return false; }
                else
                {
                    _page = _page.PriorPage;
                    _index = _page.Count - 1;
                }
            }
            return true;
        }

        public bool Selected
        {
            get
            {
                return ((_page != null) && (_page.Count > 0) && (_index >= 0)
                        && (_index < _page.Count));
            }
        }

        public bool Delete()
        {
            if ((_page.Count > BTConst.MidlCount) && (_index > 0))
            {
                if (_index == (_page.Count - 1))
                {
                    _page.Count--;
                    _page.PageItems[_index] = KeyValuePair<K, V>.default;
                    if (_page.NextPage != null)
                    {
                        _page = _page.NextPage;
                        _index = 0;
                    }
                }
                else
                {
                    _page.Count--;
                    Array.Copy(_page.PageItems, _index + 1, _page.PageItems,
                    _index, _page.Count - _index);

                    _page.PageItems[_page.Count] = KeyValuePair<K, V>.default;
                }

                return true;
            }
            else
                return false;
        }

        public V Value
        {
            get { return _page.PageItems[_index].Value; }
            set { _page.PageItems[_index].Value = value; }
        }

        public K Key
        {
            get { return _page.PageItems[_index].Key; }
        }
    }
и солнце б утром не вставало, когда бы не было меня
Re[18]: Есть ли будущее у Native Code?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.06.09 10:17
Оценка: 1 (1)
Здравствуйте, Mystic, Вы писали:

M> Разработка специального DSL для записи алгоритмов такого рода будет достаточно трудоемкой задачей.


Ну да, если трудно мыслить в терминах не битхаков, то задачка та еще. А так — разработка DSL под узкую задачу тем проще, чем задачка уже.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re: Есть ли будущее у Native Code?
От: Sorantis Швеция  
Дата: 22.06.09 19:38
Оценка: +1
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?

Зависи от ОС.

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?

Зависи от ОС.

C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Зависи от ОС.
As long as there is life, there is hope
Re[3]: Есть ли будущее у Native Code?
От: jazzer Россия Skype: enerjazzer
Дата: 23.06.09 03:28
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

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


J>>P.P.S. На самом деле, осталось еще 6 вариантов ответа...


PD>Больше. Я на один из вопросов ответил "Не знаю"


Иди и без родителей не возвращайся!
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 08:04
Оценка: :)
Здравствуйте, blackhearted, Вы писали:

C>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?

B>Осталось его весь верифицировать
Не позволить портить чужие данные это вообще примитив. С этим даже жаба и .НЕТ справляются.
А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 10:32
Оценка: :)
Здравствуйте, jedi, Вы писали:

J>А в аппаратной чати не бывет багов?


А это просто за пределами обсуждения темы ОС. Если там есть баги (до сих пор багов, связанных с защищенным режимом вроде не было), то надо исправлять процессор, а это не наша тематика.
With best regards
Pavel Dvorkin
Re[6]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 10:54
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.

Расскажи это писателям вирусов...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 13:13
Оценка: +1
Здравствуйте, ili, Вы писали:

ili>эмн... тут вы мои слова неверно поняли, или я не яно выразился ))) фактически это я и имел ввиду — в результате все равно получается нативник.

Очень важная поправка: Верифицированный нативник.

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

Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

ИМХО тут весьма неоднозначно подразумевается именно аппаратная защита.

ili>колесо тоже когда-то деревянным было, сейчас железные с резиновой обкладкой предпочитают вот только колесо от этого колесом быть не прекратило.

С доказательствами по аналогии иди в другое место.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 14:51
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

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


M>>Точнее номер первого установленного бита.

S>Наверное проще создать аналог BitArray над массивом Uint64

BitArray не нужен. Шахматная доска содержит 64 клетки. Таким образом UInt64 мне вполне достаточно, обобщать шахматы на доски других размеров я не собираюсь. Просто, во-первых, их много (на шахматную позицию надо битовая маска пешек, коней, слонов, ладей, ферзей и всех фигур и все за белых и черных + заполняемость хеша позиций на современных машинах порядка нескольких миллионов позиций в секунду). Во-вторых, эта операция при генерации ходов на вес золота.
Re[12]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 16:14
Оценка: :)
Здравствуйте, Mystic, Вы писали:

G>>>>Так напиши тоже самое без указательной магии на C#, в чем проблема?

M>>>Проблема в том, что я хочу видеть в машинном коде BSR и BSF.
G>>Это действительно проблема. Только это проблема в тебе, а не в .NET или еще чем-то.

M>Может быть и во мне, но сильных шахматных движков, написанных на .NET, я не знаю...

Наверное потому что их никто не делает.

"сила" шахматного алгоритма зависит от реализации оценки позиции и алгоритма перебора вариантов ходов, ковыряние с битами в таких алгоритмах противопоказано. Наносекундные вычисления с битами вероятнее всего незаметны будет.
Re[5]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 23.06.09 21:46
Оценка: :)
Здравствуйте, WolfHound, Вы писали:


C>>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?

B>>Осталось его весь верифицировать
WH>Не позволить портить чужие данные это вообще примитив. С этим даже жаба и .НЕТ справляются.
WH>А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить...

Ну вот С++ на зависимых типах построен, однако через Си-касты и прочие xxx_cast<> все это обходится легко. Для написания того же банального GC необходимы аналогичные способы реинтерпретации памяти... Так что насчет "всё проверить" очень спорно, разве что лишь имеется ввиду проверить "все остальное".
Re[10]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 10:23
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну сделать, чтобы программа не падала, не так уж сложно — SetUnhandledExceptionFilter, и формально она не упадет, а закончится корректно.

А еще можно сделать бесплатную сборку мусора в С.
Знаешь как?
Запускаем программу на 64х битной системе.
Вся неиспользуемая память будет навсегда оседать в свопе.
Далее смотрим если в свопе лежит страница к которой не обращались неделю значит она не нужна и выкидываем ее.


PD>А если ты имеешь в виду, чтобы в ней не было ошибок — "программа, свободная от ошибок есть абсрактное теоретическое понятие", и это для меня сомнению не подлежит.

Тут согласен.

PD>Можешь сделать, чтобы не было доступа куда не надо, модификации чего не надо, но если вместо плюса в ней минус, то это отловить тебе никто не поможет.

А тут не совсем.
Зависимые типы могут очень много чего ловить.

PD>Имеешь право хотеть. Заодно создай себе гарантии, что все прочие exception тоже никогда возникать не будут. Теоретически это, наверное, возможно, практически не существует и едва ли интересно.

Чтобы совсем не было исключений не получится. Но вот убить почти все исключения можно.

PD>Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.

Когда я писал числомолотилки то меня тоже мало заботили нештатные ситуации ибо в числомолотилках они почти не встречаются.
А вот шаг в сторону и приплыли.

PD>>>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.

S>>Мы — нет. В твоих задачах плата, скорее всего, будет перевешивать выручку.
PD>Вот именно. +1
Приехали. Ты уже сам с собой споришь...

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

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

PD>И дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.

Не мы, а вы!
У меня в программах переменных весьма не много даже если приходится писать на С++.
А если я пишу на немерле то там на сотни строк кода может не быть ни одной переменной.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 10:27
Оценка: +1
Здравствуйте, swined, Вы писали:

S>достаточно скомпилить вирус "косячным" компилятором, чтобы убить незащищенную систему с легкостью.

Недостаточно. Код просто не пройдет верификацию и все. И никаких прав не хватит чтобы его запустить.

S>runtime либо, как минимум, deployment-time проверки все равно должны присутствовать, иначе вирусописателям будет только проще.

Ну так проверки времени установки и будут. А вот проверки времени исполнения будут практически полностью устранены зависимыми типами.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 10:30
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну сделать, чтобы программа не падала, не так уж сложно — SetUnhandledExceptionFilter, и формально она не упадет, а закончится корректно.

PD> А если ты имеешь в виду, чтобы в ней не было ошибок — "программа, свободная от ошибок есть абсрактное теоретическое понятие", и это для меня сомнению не подлежит.
Я уже заметил, что для тебя статистические вещи малопонятны.
PD>Можешь сделать, чтобы не было доступа куда не надо, модификации чего не надо, но если вместо плюса в ней минус, то это отловить тебе никто не поможет.
Я, в общем-то, согласен и на 99%.

PD>Имеешь право хотеть. Заодно создай себе гарантии, что все прочие exception тоже никогда возникать не будут. Теоретически это, наверное, возможно, практически не существует и едва ли интересно.

Видишь ли, уровень безошибочности, достижимый при помощи K&R С, был достигнут уже давно. И мне как раз неинтересно рассуждать на тему "а потому работай-не работай, всё едино".
Мне интересно думать на тему "а что еще можно улучшить?"

PD>Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.

Просто в твоих задачах, значит, эти ситуации малосущественны.

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

Да ладно! Это ты как считал?
PD>И дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.
Гм. Как бы так тебе объяснить... Ты под термином "программа" всё время подразумеваешь "программа на языке С".
В лучшем случае — "алгоритм", то есть Тьюринговский формализм программирования. Это только один, и очень узкий взгляд. Как ты, возможно, знаешь, любой алгоритм можно выразить не только в виде программы для машины Тьюринга, но и в виде частично вычислимых функций. А там, извини, никаких переменных вовсе нет. Поэтому то, что вы имеете в программе намного больше переменных — это лично ваша заслуга, а отнюдь не неотъемлемое свойство самих программ
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 24.06.09 12:51
Оценка: :)
Что-то мы начали подпевать друг другу.
Re[17]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 13:52
Оценка: :)
Здравствуйте, thesz, Вы писали:

T>http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.64

Статейка как я понимаю платная...
Даже мой любимый обесплатниваетель http://scholar.google.com/ что-то не помогает.

T>Аж до экспоненциальной сложности доходит для определённых логик.

Да и причем тут Unrestricted Hierarchical State Machines ?
Вот скажем взяли программу на хаскеле.
Рассахарили, вывели все типы,...
И результат сбросили в бинарник.
Лично я не вижу ни одной причины по которой верификация этого бинарника требовала бы отличное от O(N) время.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 03:33
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>В конце концов по существу переменная (в широком смысле слова) — это некий блок памяти, содержимое которого может изменяться (а константы — не может). А как это в языке оформлено — это уже от языка зависит. И такие переменные есть в любой программе на любом языке, иначе что это программа делает-то ?

Может, тебе что-то из основ программирования почитать? Ну, чтобы знать, что далеко не все языки программирования оперируют абстракциями типа "блок памяти".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 03:33
Оценка: +1
Здравствуйте, Mystic, Вы писали:
M>Аппаратную независимость можно достичь и на уровне исходников. По крайней мере принципиальных отличий байт-кода от исходников нет. По идее один и тот же C# код должен компилироваться в один и тот же байт-код. Так что большой разницы нет, то ли я получу байт-код, то ли я получу код на C#. Так что претензии больше не к самой идее JIT, а к требованию верифицируемости кода. Да, верификация нужна больше в тех случаях, когда код запускается без моего ведома, как, например, скрипты на странице. Но в этом случае, по большому счету, и не нужна производительность. А если я скачал программу из интернета, я доверяю ее автору. Откомпилировал да запустил, и на верификацию плевать. И пример больше иллюстрировал тот факт, что разрабатывать неверифицированный код в некоторых случаях проще.
Пример иллюстрировал тот факт, что ты привык применять определённые средства, совершенно неудобные для твоей задачи. Но ты привык это делать настолько хорошо, что теперь тебе сложно воспринять более простые вещи. Верификация кода не имеет к твоим проблемам никакого отношения. Да, наверное, MSIL не лучший язык для записи твоих задач. Но и ассемблер — тоже. По-хорошему, это должен быть DSL, который очень компактно и понятно отражает суть алгоритма. А упаковка алгоритма в битхакинг — дело компилятора.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 08:56
Оценка: +1
Здравствуйте, swined, Вы писали:
S>кстати да, каким бы компактным не был верификатор, в нем могут быть ошибки. хардварная защита как-то понадежней будет.
Ты полагаешь, что хардварная защита разрабатывается сверхлюдьми?
Не волнуйся. В случае, если в верификаторе ошибка (а его текст очень невелик)
S>ссылочку на способы такой верификации не дашь? мне все это пока представляется как статический анализ, который нифига не выполним за O(N).
Гм. Почитай, что ли, как работает дотнетовый верификатор. В джаве, афаир, тоже есть аналогичный верификатор. Там всё очень просто — накладываются некоторые ограничения на программы, и из "проблемы останова" мгновенно получаем линейную задачу.
S> причем, для native-кода он будет еще медленнее из-за отсутсвия высокоуровневых конструкций типа foreach, вместо которого пришлось бы разбирать обычный цикл и проверять его на выход за границы.
Гм. Во-первых, для native-кода верификатор построить нельзя. Иначе бы он давно уже существовал.
Во-вторых, "высокоуровневые конструкции" к верификатору никакого отношения не имеют. Я, наверное, тебя удивлю, но инструкции foreach в MSIL нету. Сплошные conditional jump-ы.

Речь идет вот о чём: верификатор проверяет исключительно типобезопасность. То есть после проверки мы знаем, что никакая инструкция программы не станет обращаться с объектом типа A как с объектом несовместимого с ним типа B.
Подчеркну: это то, что уже есть.
То, чего нету — это богатой системы типов, которая влияет на понятие "совместимости" во фразе выше.
Например, более мощная система типов, чем в CLR, позволила бы устранить само понятие NullReferenceException, благодаря тому, что NotNullable типы отделялись бы от Nullable. При этом сам верификатор изменять бы было совершенно ненужно: тот же самый код за те же самые O(N) обнаруживал бы все нарушения. В случае, если ты захакал компилятор, конечно — потому что в противном случае тебе бы компилятор с самого начала сказал "извини, чувак, но длину от возможно-null строки я тебе вычислять не дам".

Более мощная система типов позволила бы за те же деньги отлавливать ошибки типа "незаескейпленная строка". Или "хранение секретных данных в незашифрованном виде". Или "обработка занимает больше тактов, чем можно".

И это только то, что я понимаю своим невооруженным мозгом. Более продвинутые чуваки утверждают, что типами можно описать еще более сложные штуки — типа отсутствия race condition и прочие пряники.

Да, конечно, это всё никак не поможет Павлу Дворкину. Потому что у него не так страшно получить противоречивую спецификацию (что как раз и может обнаружить верификатор), как получить некорректную непротиворечивую (потому что это как раз никакой верификатор не заметит).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 09:06
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Блин, тебе хочется хлеба и зрелищ? Ну давай покажи как можно в ОбЩЕМ случае. Заодно список языков с примерами.

Сначала пойми что такое зависимые типы. После чего вопросы у тебя отпадут сами собой.
А заниматься твоим образованием у меня нет никакого желания.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 25.06.09 09:14
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Ты полагаешь, что хардварная защита разрабатывается сверхлюдьми?


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

S>Не волнуйся. В случае, если в верификаторе ошибка (а его текст очень невелик)


так что же будет в этом случае?

S>Гм. Почитай, что ли, как работает дотнетовый верификатор. В джаве, афаир, тоже есть аналогичный верификатор. Там всё очень просто — накладываются некоторые ограничения на программы, и из "проблемы останова" мгновенно получаем линейную задачу.


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

S>Гм. Во-первых, для native-кода верификатор построить нельзя. Иначе бы он давно уже существовал.


так что же тогда предлагается верифицировать? как я смогу использовать бинарь слитый из интернетов с непонятных варез-сайтов? или придется городить ms signed software, drm и прочую хрень созданную для того, чтобы у меня работало только три программы, две из которых — пасьянс?

S>Во-вторых, "высокоуровневые конструкции" к верификатору никакого отношения не имеют. Я, наверное, тебя удивлю, но инструкции foreach в MSIL нету. Сплошные conditional jump-ы.


однако перед генерацией IL'а они есть, чем сильно помогают компилятору.

S>Речь идет вот о чём: верификатор проверяет исключительно типобезопасность. То есть после проверки мы знаем, что никакая инструкция программы не станет обращаться с объектом типа A как с объектом несовместимого с ним типа B.

S>Подчеркну: это то, что уже есть.

а толку? как ты будешь проверять те же массивы на границы?

S>То, чего нету — это богатой системы типов, которая влияет на понятие "совместимости" во фразе выше.

S>Например, более мощная система типов, чем в CLR, позволила бы устранить само понятие NullReferenceException, благодаря тому, что NotNullable типы отделялись бы от Nullable. При этом сам верификатор изменять бы было совершенно ненужно: тот же самый код за те же самые O(N) обнаруживал бы все нарушения. В случае, если ты захакал компилятор, конечно — потому что в противном случае тебе бы компилятор с самого начала сказал "извини, чувак, но длину от возможно-null строки я тебе вычислять не дам".

отделение nullable от not nullable только сократит количество ошибок, но не избавит от них полностью. что мне мешает иметь nullable string, который абсолютно легален в логике программы, и иногда считать его длину?

S>Более мощная система типов позволила бы за те же деньги отлавливать ошибки типа "незаескейпленная строка". Или "хранение секретных данных в незашифрованном виде". Или "обработка занимает больше тактов, чем можно".

S>И это только то, что я понимаю своим невооруженным мозгом. Более продвинутые чуваки утверждают, что типами можно описать еще более сложные штуки — типа отсутствия race condition и прочие пряники.

а где бы почитать об этом?
Re[21]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 10:39
Оценка: +1
Здравствуйте, swined, Вы писали:
S>т.е. заменить хардварные проверки верификацией для существующего софта не удастся
Конечно.
S>и мы обсуждаем тут сферических коней?
Нет, кони уже бегут, избы вполне горят.
S>либо компилятор заенфорсит меня написать проверку перед вызовом (он и сейчас так может),
Сейчас он не может избавить тебя от проверок там, где проверять не надо.
В частности, если у тебя есть две гарантированно NonNull-string на входе, то Concat от них тоже вернёт nonNull. И проверять это уже не надо.
S> либо получается та же фигня Option[String].getLength(), кидающий NullReferenceException, когда в нем нет ненулевой строки.
Нет. Никаких exception. Вся фишка — именно в том, чтобы зависимые типы выводились сами. В результате у тебя чётко оговорены места, где Nullable string превращается в NonNullable стринг. А не минное поле, где любой вызов может внезапно бросить NRE.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: в добавление
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 10:56
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Мне бы твои проблемы

Я думаю, что от моих проблем ты загнёшся.
PD>В том-то и дело, что на основании простейших примеров вы беретесь делать выводы для сложных алгоритмов. А если я неправильно реализовал потому что и сам не понимаю, как тут правильно из-за сложности алгоритма, превышающншл (допустим) мои способности ?
Какая разница, по какой причине ты реализовал "неправильно"? Если "неправильно" — это неконсистентно, то всё обнаружится статической проверкой.

А про "неправильно" в смысле "не решает нужную задачу" я тебе уже ответил: это тебе никакая математика не посчитает.

PD>Математически обнаружимая... Да, в твоем примере это сойдет. На тебе иной пример — ядро Windows. Спроектируй его в основных чертах и попробуй потом математически обнаружить, а мы посмотрим

Ну не странно ли, что для всяческих ОС ядер таки доказывают различные свойства при помощи различных theorem prover-ов?

S>>А вот это — тоже вполне себе разрешимая задачка. Если среда умеет выводить и проверять контракты на вычислительную сложность, то ты можешь очень быстро увидеть, где именно боттлнек, еще до запуска профайлера.

PD>Что я слышу !!! Без профайлера, оказывается, можно. Правда, если среда умеет... А если я сам умею (я могу оценить алгоритм на выч.сложность или уж совсем никак не могу ? — тогда что ?
Ну, так ты, наверное, и по регистрам можешь переменные вручную распределить. Но зачем, если компилятор это делает за тебя?
PD>Вроде кто-то утверждал, что надо именно только с профайлером и никак иначе
Есть некоторые нюансы. В частности, автоматически выведенным оценкам производительности я доверяю как-то больше, чем твоим. Из-за сложности алгоритма, превышающншл (допустим) твои способности.

А в общем, из оценки сложности оценить где будет реальный боттлнек далеко не всегда возможно.

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

Поэтому выведение контрактов на сложность не заменит профайлер, а всего лишь будет ему помогать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 12:31
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>В Cayenne, Agda и тп нет оператора casetype. Поэтому ты не можешь типы в Cayenne, Agda и тп не могут зависеть от значений времени выполнения.

Тут я немного криво выразился.

T>А вот связать значения из типов со значениями времени выполнения путём доказательств возможно.

Я именно это и имел в виду.

T>И в C++ тоже (хотя и не очень уверен).

Я в свое время изучил все возможные метаизвращения на С++ но не вижу никакой возможности сделать что-то подобное тому что может агда.
На С++ не сделать ничего типа:
mult : ∀i , j , k : Nat ⇒ Matrix i j → Matrix j k → Matrix i k

При условии что i, j и k не известны на этапе компиляции.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 26.06.09 07:32
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Если в существующем софте есть ошибка, то все возможно. Но по постингу WolfHound можно понять так, что достаточно переполнить буфер , и мы попадем в страницы, находящиеся под контролем системы. А причина банальная — он не вполне понимает отличие виртуальной памяти от физической, он считает, что если выйти за пределы страницы, то мы попадем на соседнюю страницу физической памяти, которая может принадлежать системе

Опять фантазируешь на тему того что я что-то не понимаю.
Просвещайся http://en.wikipedia.org/wiki/Buffer_overrun
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 08:08
Оценка: +1
Здравствуйте, WolfHound, Вы писали:
WH>Еще раз: В С++ нет зависимых типов. Пожалуйста не разводи путаницу.
Некоторое подмножество-то есть.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 26.06.09 09:37
Оценка: -1
Здравствуйте, minorlogic, Вы писали:

WH>>А верифицируемый код дает.

M>Не вижу способа который мог бы дать.
M>Уверен что ошибаешься.
M>И тут ошибаешся.
Все ясно. С верой спорить бесполезно.
Отправляйся к Дворкину.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 10:59
Оценка: +1
Здравствуйте, WolfHound, Вы писали:
S>>Вручную-то всё возможно.
WH>Сразу после того как ты на С++ реализуешь статическую проверку
Еще раз: я не говорю, что эта задача разрешима на С++. Можно решить только её подзадачу — когда i, j и k известны на этапе компиляции.
А вот на Паскале невозможно решить и эту, значительно более простую подзадачу.
На дотнете невозможно решить задачу, которую я привёл.

Поэтому не надо видеть мир исключительно в чёрно-белом свете.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 11:08
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

Все skipped ибо схоластика. Кроме одного.

PD>>Вот и расскажи, как ты это можешь до запуска определить. А еще скажи, как ты это сможешь до запуска определить, если этот несчастный флаг окажется параметром командной строки или будет вводиться с консоли во время исполнения


Вот на этот вопрос когда ответишь, тогда и будем говорить насчет возможности верификации правильности программ до исполнения. Хоть на С++, хоть на C#, хоть на чем ином.
With best regards
Pavel Dvorkin
Re[30]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 11:33
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот на этот вопрос когда ответишь, тогда и будем говорить насчет возможности верификации правильности программ до исполнения. Хоть на С++, хоть на C#, хоть на чем ином.
Этот вопрос и есть схоластика. Ты не в состоянии привести пример задачи, где это нужно. Слив засчитан.

Заодно засчитаем и слив про пример применения твоей новоизобретённой техники.
Которая сначала "от языка не зависит, так как реализована на чисто Win API", а потом сразу же "речь идет о необходимости добавить кое-что для этой цели в язык".

Вот показал бы предлагаемые дополнения в язык — сам бы увидел, что с ними никакая аппаратная защита не нужна.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 21.10.09 10:20
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

[]

PD>То-то, по утверждению Нортона, того, кто исключил стек из архитектуры IBM-360, "сослали во внутрифирменный аналог Сибири".


ИМХО: Не знаю, что там Нортон утверждал и когда, но в начале 60 годов за предложение резервировать часть такого дорогого ресурса (на тот момент), как память под стек при загрузке кода, сослали бы точно.
Re[7]: Есть ли будущее у Native Code?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.10.09 13:40
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Ну при том что сейчас очень много процессоров с этой нашлепкой.

WH>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.

Кстати, по странному стечению обстоятельств процы с "этой нашлепкой" частенько стоят дешевле и работают быстрее, чем процы без нее. Представляешь, неувязочка какая получается. Вот, к примеру, компы Apple при переходе на Intel с Power стали внезапно быстрее раз в 5. Боюсь, данная нашлепка не мешает разработчикам процессоров из Intel и AMD. Они хорошие танцоры, видать.
Re[11]: Есть ли будущее у Native Code?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.10.09 14:20
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?


К примеру, в процессорах ARM есть специальные инструкции, предназначенные для сохранения 8 регистров сразу. Применются много где — и в коде переключения контекста, и в коде банального memcpy.

К примеру, в процессорах ARM есть специальное расширение системы инструкций NEON — применяется при сигнальной обработке и в мультимедийных кодеках. Библиотеки пишутся ручками на ассемблере.

Это будет касаться практически всех application-specific инструкций, которыми нашпигованы системы команд многих современных процессоров. Также, это касается интерфейсного кода с разного рода сопроцессорами (при их наличии). Про мультимедийные и DSP процессора я вообще молчу.

G>В Singularity они необходимость ассемблера обошли таким образом: коду драйвера передается экземпляр класса, который отвечает за всю низкооуровневую работу (обращения к этому классу вполне могут компилиться в нужный нативный код).


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

Подстава с применением managed кода здесь не в классах, а в том, что многие безобидные на вид периферийные устройства требуют реакции на прерывания в условиях жесткого реального времени — и это при том, что требования real-time не распространяются на всю систему. Простейший пример — большинство видеоконтроллеров в бытовой электронике требуют от драйвера реакции на каждый полукадр, причем — в жестко отведенное временное окно. А некоторые их них требуют тщательной оптимизации интерфейсного кода.

G>Почему нельзя будет для других архитектур процессоров сделать другие классы, наследники какого-либо базового?


Есть еще причины. Например, потому, что далеко не все процессоры устроены одинаково. Посмотри внимательно на архитектуру Blackfin — в качестве примера, на что это может быть похожа популярная архитектура.

Ты скажешь — а нафига брать такую экзотику, у нас на десктопах такого нет? Дык видишь ли, если развить эту мысль — у нас на десктопах вообще ничего нет, кроме х86, и тогда вообще не вполне понятно, нафига нужен машиннонезависимый байткод.
Re[9]: Есть ли будущее у Native Code?
От: CreatorCray  
Дата: 22.10.09 05:49
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>А что будет если ребятам из интела дать возможность сделать такую систему команд которую они захотят?

А они уже давно сделали
Погугли про Itanium
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.06.09 16:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

WH>Да.
Скорее всего нет. Ибо виртуализация.
Но для разработки ОС такой механизм применяться не будет.
Re[3]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 22.06.09 16:53
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Скорее всего нет. Ибо виртуализация.

Ну да... разве что для всяких там вмварей чтобы легаси гонять.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Есть ли будущее у Native Code?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.06.09 20:52
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?


Осталось выяснить разновидность этого самого промежуточного кода. Минимум два непримиримых кандидата на престол у нас уже есть — CLR и JVM. Так что, ИМХО, если кто-то кого-то и вытеснит, то точно не в ближайшее время.

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?


Скорее нет, чем да.

C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?


Нет, не утратит. ИМХО, по одной простой причине — в виртуальных адресных пространствах, в принципе, можно запустить хоть вагон управляемых ОС (каждой по сегменту и пусть никто не уйдёт огорчённым). Хотя, конечно, эти подходы можно и смешивать до определённой степени — т.е., управляемая ОС сможет запускать много чего Native.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 22.06.09 21:59
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?


Нет.

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?


Нет.

C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?


Нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 02:37
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?


Нет.


C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?


Нет.


C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?


Не знаю. Совместное адресное пространство было уже (Win16), ничего хорошего из этого не вышло. Однако даже отвергнутые идеи имеют иногда способность возвращаться . В ближайшем будущем все же нет.
With best regards
Pavel Dvorkin
Re[2]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 02:38
Оценка:
Здравствуйте, jazzer, Вы писали:

J>P.P.S. На самом деле, осталось еще 6 вариантов ответа...


Больше. Я на один из вопросов ответил "Не знаю"
With best regards
Pavel Dvorkin
Re[2]: Есть ли будущее у Native Code?
От: Chrome  
Дата: 23.06.09 07:21
Оценка:
Здравствуйте, Sorantis, Вы писали:

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


C>>Или его со временем полностью вытеснит верифицируемый промежуточный код?

S>Зависи от ОС.

C>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?

S>Зависи от ОС.

C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

S>Зависи от ОС.

А что именно зависит от ОС?
Вроде современные распространенные ОС по перечисленным аспектам похожи как капли воды
— выполняют native code
— используют виртуальные адресные пространства для изоляции процессов
— имеют ядро и соответственно переключения в режим ядра
Re[2]: Есть ли будущее у Native Code?
От: Chrome  
Дата: 23.06.09 07:23
Оценка:
Здравствуйте, thesz, Вы писали:

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


C>>Или его со временем полностью вытеснит верифицируемый промежуточный код?


T>Нет.


C>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?


T>Нет.


C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?


T>Нет.


Интереснее было бы услышать аргументы, а не авторитетное мнение.
Re[2]: Есть ли будущее у Native Code?
От: Chrome  
Дата: 23.06.09 07:28
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


C>>Или его со временем полностью вытеснит верифицируемый промежуточный код?


PD>Нет.

Даже в случае проектируемой с нуля какой нибудь будущей ОС?

C>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?


PD>Нет.

А зачем оно будет нужно?


C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?


PD>Не знаю. Совместное адресное пространство было уже (Win16), ничего хорошего из этого не вышло. Однако даже отвергнутые идеи имеют иногда способность возвращаться . В ближайшем будущем все же нет.


Верифицируемый код не позволяет портить чужие данные. Что еще нужно?
Re[3]: Есть ли будущее у Native Code?
От: blackhearted Украина  
Дата: 23.06.09 07:36
Оценка:
Здравствуйте, Chrome, Вы писали:


C>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?


Осталось его весь верифицировать
Re[2]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.06.09 07:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

А есть уже практическое применение Singularity, хотя бы как Оберон систем
и солнце б утром не вставало, когда бы не было меня
Re[3]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 08:01
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>А есть уже практическое применение Singularity, хотя бы как Оберон систем

Не думаю ибо эта ОС изначально задумывалась исключительно как эксперимент.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Есть ли будущее у Native Code?
От: Курилка Россия http://kirya.narod.ru/
Дата: 23.06.09 08:20
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


C>>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?

B>>Осталось его весь верифицировать
WH>Не позволить портить чужие данные это вообще примитив. С этим даже жаба и .НЕТ справляются.
WH>А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить...

Зависимые типы они круты, безусловно, но вот, а какие ещё проблемы может дать "нехороший" код, которые зависимые типы должны по идее разрешить, кроме порчи памяти? В голову пока приходит только захват ресурсов (в т.ч. памяти), который будет мешать другим процессам (и ядерным возможно).
Re[4]: Есть ли будущее у Native Code?
От: meowth  
Дата: 23.06.09 08:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


S>>А есть уже практическое применение Singularity, хотя бы как Оберон систем

WH>Не думаю ибо эта ОС изначально задумывалась исключительно как эксперимент.

OS Inferno изначально не задумывалась, как эксперимент. Работает, применяется (по крайней мере, на сайте так)
Re[4]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.06.09 09:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Не думаю ибо эта ОС изначально задумывалась исключительно как эксперимент.

Да уж отстал от жизни, уже Midori появилась
http://www.nestor.minsk.by/kg/2008/32/kg83205.html
и солнце б утром не вставало, когда бы не было меня
Re[3]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 09:06
Оценка:
Здравствуйте, Chrome, Вы писали:

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


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


C>>>Или его со временем полностью вытеснит верифицируемый промежуточный код?

T>>Нет.

Промежуточный код требует накладных расходов — например, профилирование для JIT имеет O(размер программы) накладных расходов (точки съёма времени).

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

C>>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?

T>>Нет.

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

C>>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

T>>Нет.

Это следствие из двух предыдущих пунктов.

C>Интереснее было бы услышать аргументы, а не авторитетное мнение.


Я посмотрел на пару первых ответов, и решил, что так и надо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 09:17
Оценка:
Здравствуйте, thesz, Вы писали:

T>Промежуточный код требует накладных расходов — например, профилирование для JIT имеет O(размер программы) накладных расходов (точки съёма времени).

А что обязательно постоянно профилировать?
ИМХО это опциональная возможность причем далеко не факт что вообще полезная.
Да и кросскомпиляцию никто не отменял.

Какие еще накладные расходы придумаешь?
А если есть наличие зависимых типов и как следствие кучи доказательств того что во многих местах проверки времени исполнения не нужны.

T>Эти расходы удорожают массовые встраиваемые системы, например, автомобильные.

Или наоборот за счет того что можно например отказаться от виртуальной памяти?
Да и сам процессор можно сделать без лишних заморочек типа слоя совместимости с x86.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 09:50
Оценка:
Здравствуйте, 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)
Re[3]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 10:17
Оценка:
Здравствуйте, Chrome, Вы писали:

C>>>Или его со временем полностью вытеснит верифицируемый промежуточный код?


PD>>Нет.

C>Даже в случае проектируемой с нуля какой нибудь будущей ОС?

Только если эта ОС будет работать на некотором верифицируемом интеллектуальном процессоре

C>>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?


PD>>Нет.

C>А зачем оно будет нужно?

За тем же, зачем и сейчас. См. ниже.


C>>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?


PD>>Не знаю. Совместное адресное пространство было уже (Win16), ничего хорошего из этого не вышло. Однако даже отвергнутые идеи имеют иногда способность возвращаться . В ближайшем будущем все же нет.


C>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?


Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ? В то время как в модели user/superwisor это решено аппаратно.
With best regards
Pavel Dvorkin
Re: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 10:23
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Взял на себя смелость устроить 3 голосования по этим вопросам.

http://rsdn.ru/poll/2390.aspx
Автор: Pavel Dvorkin
Дата: 23.06.09
Вопрос: Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

http://rsdn.ru/poll/2389.aspx
Автор: Pavel Dvorkin
Дата: 23.06.09
Вопрос: Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?

http://rsdn.ru/poll/2388.aspx
Автор: Pavel Dvorkin
Дата: 23.06.09
Вопрос: Есть ли будущее у Native Code? Или его со временем полностью вытеснит верифицируемый промежуточный код?
With best regards
Pavel Dvorkin
Re[4]: Есть ли будущее у Native Code?
От: jedi Мухосранск  
Дата: 23.06.09 10:27
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

C>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?


PD>Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ? В то время как в модели user/superwisor это решено аппаратно.


А в аппаратной чати не бывет багов? В конце концов алгоритмы, зашитые в железе тоже верифицируются каким-то софтовым верификатором (я не в курсе, но думаю где-то так и есть).
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[4]: Есть ли будущее у Native Code?
От: Chrome  
Дата: 23.06.09 10:30
Оценка:
C>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?

PD>Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ? В то время как в модели user/superwisor это решено аппаратно.


а где гарантии, что код, исполняемый в режиме ядра не содержит ошибок?
код верификатора все же покомпактней будет.
Re[5]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 10:34
Оценка:
Здравствуйте, Chrome, Вы писали:

C>а где гарантии, что код, исполняемый в режиме ядра не содержит ошибок?


Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.
With best regards
Pavel Dvorkin
Re[2]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 10:37
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Взял на себя смелость устроить 3 голосования по этим вопросам.


PD>http://rsdn.ru/poll/2390.aspx
Автор: Pavel Dvorkin
Дата: 23.06.09
Вопрос: Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

PD>http://rsdn.ru/poll/2389.aspx
Автор: Pavel Dvorkin
Дата: 23.06.09
Вопрос: Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?

PD>http://rsdn.ru/poll/2388.aspx
Автор: Pavel Dvorkin
Дата: 23.06.09
Вопрос: Есть ли будущее у Native Code? Или его со временем полностью вытеснит верифицируемый промежуточный код?


Черт! Поставил "показывать результаты только проголосовавшим", а в итоге не смог их сам посмотреть. Обычно я в мной созданных голосованиях не голосую, а тут пришлось
With best regards
Pavel Dvorkin
Re[6]: Есть ли будущее у Native Code?
От: jedi Мухосранск  
Дата: 23.06.09 10:40
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


J>>А в аппаратной чати не бывет багов?


PD>А это просто за пределами обсуждения темы ОС. Если там есть баги (до сих пор багов, связанных с защищенным режимом вроде не было), то надо исправлять процессор, а это не наша тематика.


Исправлять софт дешевле... Именно по этой причине мы до сих пор имеем generic-purpose процессоры, а не специализированные под работу в инете, редактирование документов и раскаладывание косынки
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[7]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 10:52
Оценка:
Здравствуйте, jedi, Вы писали:

J>Исправлять софт дешевле...


Последний раз ИМХО исправляли одну из первых версий 386, в которой был какой-то баг в чем-то, связанном с плавающей точкой. С тех пор я не помню об ошибках в процессорах, требовавших их замены.


>менно по этой причине мы до сих пор имеем generic-purpose процессоры, а не специализированные под работу в инете, редактирование документов и раскаладывание косынки


Нет. не поэтому. А потому, что я не намерен уставлять свою квартиру/офис кучей системных блоков — один для работы в инете, другой для редактирования документов, третий для расчета зарплаты, а четвертый для косынки, и связывать их друг с другом кабелями для того, чтобы передать текст , полученный из инета, в текстовый редактор
With best regards
Pavel Dvorkin
Re[4]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 10:52
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ?

bootstrap сводит эту вероятность практически к нулю.
И даже если что-то проскочит обновить софт куда как проще чем обновить железо.

PD>В то время как в модели user/superwisor это решено аппаратно.

А где гарантия что нет ошибки в железе?
В любом случае гранулярность железной защиты всегда будет ниже плинтуса.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Есть ли будущее у Native Code?
От: jedi Мухосранск  
Дата: 23.06.09 11:11
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет. не поэтому. А потому, что я не намерен уставлять свою квартиру/офис кучей системных блоков — один для работы в инете, другой для редактирования документов, третий для расчета зарплаты, а четвертый для косынки, и связывать их друг с другом кабелями для того, чтобы передать текст , полученный из инета, в текстовый редактор


Не надо воспринимать все так юуквально Посмотри на свой телефон, КПК или электронную читалку. Стоит тот же самый general-purpose процессор — ARM или что еще. А различия девайсов — в периферии и софте.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[7]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 11:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.

WH>Расскажи это писателям вирусов...

То есть ты хочешь сказать, что вирусы в состоянии нарушить аппаратную защиту защищенного режима, и , работая в 3 кольце, получить доступ к страницам, для которых U/S == 0 ? Расскажи , как это делают вирусы, мне это очень интересно
With best regards
Pavel Dvorkin
Re[5]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.06.09 11:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

PD>>В то время как в модели user/superwisor это решено аппаратно.

WH>А где гарантия что нет ошибки в железе?

http://rsdn.ru/forum/philosophy/3439203.1.aspx
Автор: Pavel Dvorkin
Дата: 23.06.09
With best regards
Pavel Dvorkin
Re[7]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 11:47
Оценка:
T>>Виртуальная память влияет на производительность, накладные расходы в железе для неё минимальны (для реализации SPARC v8 под названием Leon3 и для известных мне вариантов MIPS — примерно размер регистрового файла, который сам ~10% от площади ядра микропроцессора). Для x86 успешное обновление TLB при промахе занимает ~400 тактов, для MIPS — ~40.
WH>Экономия ~10% от площади ядра микропроцессора и 0 тактов вместо от 40 до 400.
WH>Так и запишем.

Ты говоришь о полном и безоговорочном доказательстве всего на свете.

В этом случае, конечно, нативный код отомрёт.

WH>>>Да и сам процессор можно сделать без лишних заморочек типа слоя совместимости с x86.

T>>А это-то здесь при чём?
WH>Ну при том что сейчас очень много процессоров с этой нашлепкой.
WH>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.

Дома у меня есть PowerPC. Так что вероятность всего 2/3 (работа, дом и дом).

WH>Управляемые системы позволят от этой нашлепки избавиться.

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

Да, соглашусь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 12:16
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?


Моему извращенному уму нативный код писать проще и приятнее. А верифицируемость накладывает кучу ограничений, которые надо потом думать, как разрулить.
Re: Есть ли будущее у Native Code?
От: ili Россия  
Дата: 23.06.09 12:31
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?


а хто будет исполнять этот промежуточный код? еще одна виртуальная машина? а за ней еще одна? вещь в себе какакя-то =)
пока железо не будет позволять таких финтов, никуда нативники не денуться
хотяяя... он и тогда никуда не денется, просто он будет нативным не для x86 а для SkyNet или T-800 на худой конец ))

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?


х\з... а какие тут накладные расходы, и на столько ли они существенны, что пенальти превышает бенефиты такого подхода?

C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?


да куда она денется?... изолировать их все равно надо, а какими механизмами — вопрос отдельный.
Re[8]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 12:34
Оценка:
Здравствуйте, thesz, Вы писали:

T>Ты говоришь о полном и безоговорочном доказательстве всего на свете.

А все на свете и не нужно.
Достаточно доказать что не будет проездов по памяти и гонок.
А для этого даже зависимые типы приплетать не нужно.

Если приплести зависимые типы то можно на корню убить юнит тесты. Ибо зависимые типы позволяют доказать куда больше чем юнит тесты могут протестировать.

Единственное с чем будут проблемы это с тем как доказать что модель процессора которую использует бекенд соответствует реальному процессору.
К счастью это довольно не большое количество полностью декларативного кода.

Ну и конечно нужно IOMMU с защитой иначе через DMA периферия сможет наломать дров.

T>Дома у меня есть PowerPC. Так что вероятность всего 2/3 (работа, дом и дом).

Ладно. Про маки я забыл.
Но сколько этих маков? Процентов 10? Или меньше?

В любом случае возможность менять систему команд процессора ИМХО дорогого стоит.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 12:41
Оценка:
Здравствуйте, thesz, Вы писали:


WH>>ИМХО это опциональная возможность причем далеко не факт что вообще полезная.

T>Вот и ответ на "полное вытеснение нативного кода". Там, где это полезно, то лучше использовать нативный код.
А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?
Re[4]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 12:44
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Моему извращенному уму нативный код писать проще и приятнее.

А мне нет ибо нативность отбирает кучу умственных ресурсов на вопросы не связанные непосредственно с задачей.

M>А верифицируемость накладывает кучу ограничений, которые надо потом думать, как разрулить.

Какие конкретно ограничения?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 12:47
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


C>>а где гарантии, что код, исполняемый в режиме ядра не содержит ошибок?


PD>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.


А еще лучше когда эта попытка не допускается верификатором (который может быть запущен один раз), и работает все без аппаратных проверок.
кроме того, может вообще не быть API которое позволяет лезть в чужой процесс. (хотя как там debug сделать — не знаю).
Re[2]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 12:49
Оценка:
Здравствуйте, ili, Вы писали:

ili>а хто будет исполнять этот промежуточный код? еще одна виртуальная машина? а за ней еще одна? вещь в себе какакя-то =)

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

ili>пока железо не будет позволять таких финтов, никуда нативники не денуться

Железо только упростится.
Например нашлепка x86'ой совместимости пропадет.

ili>х\з... а какие тут накладные расходы, и на столько ли они существенны, что пенальти превышает бенефиты такого подхода?

А у аппаратной защиты есть преимущества по сравнению с программной?
Огласите весь список пожалуйста.

ili>да куда она денется?... изолировать их все равно надо, а какими механизмами — вопрос отдельный.

Программными.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 12:59
Оценка:
WH>>>ИМХО это опциональная возможность причем далеко не факт что вообще полезная.
T>>Вот и ответ на "полное вытеснение нативного кода". Там, где это полезно, то лучше использовать нативный код.
G>А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?

На 99%.

Один процент на то, что потребуется ассемблер. А он потребуется.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Есть ли будущее у Native Code?
От: ili Россия  
Дата: 23.06.09 13:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


ili>>а хто будет исполнять этот промежуточный код? еще одна виртуальная машина? а за ней еще одна? вещь в себе какакя-то =)

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

эмн... тут вы мои слова неверно поняли, или я не яно выразился ))) фактически это я и имел ввиду — в результате все равно получается нативник.

ili>>пока железо не будет позволять таких финтов, никуда нативники не денуться

WH>Железо только упростится.
WH>Например нашлепка x86'ой совместимости пропадет.

да прекрасно, что я против что ли? я же сказал, что в итоге, нативник останется, только он уже может не быть нативником х86.

ili>>х\з... а какие тут накладные расходы, и на столько ли они существенны, что пенальти превышает бенефиты такого подхода?

WH>А у аппаратной защиты есть преимущества по сравнению с программной?
WH>Огласите весь список пожалуйста.

ili>>да куда она денется?... изолировать их все равно надо, а какими механизмами — вопрос отдельный.

WH>Программными.

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

колесо тоже когда-то деревянным было, сейчас железные с резиновой обкладкой предпочитают вот только колесо от этого колесом быть не прекратило.
Re[8]: Есть ли будущее у Native Code?
От: WFrag США  
Дата: 23.06.09 13:37
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Последний раз ИМХО исправляли одну из первых версий 386, в которой был какой-то баг в чем-то, связанном с плавающей точкой. С тех пор я не помню об ошибках в процессорах, требовавших их замены.


Если отбросить последние два слова, то багов без фиксов хватает. Хотя бы даже если смотреть по документику. Какие из них можно (и можно ли) использовать для прорыва в 0-вое кольцо — я не знаю, может и никакие.
Re[8]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 13:47
Оценка:
Здравствуйте, thesz, Вы писали:

WH>>>>ИМХО это опциональная возможность причем далеко не факт что вообще полезная.

T>>>Вот и ответ на "полное вытеснение нативного кода". Там, где это полезно, то лучше использовать нативный код.
G>>А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?

T>На 99%.


T>Один процент на то, что потребуется ассемблер. А он потребуется.

Ну создателям singularity пока не потребовался. Есть вероятность что и в дальнейшем не потребуется.
Re[6]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 13:52
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами. У меня есть память, я к ней обращаюсь как хочу. Захочу, прочитаю из нее указатель, захочу прочитаю из нее целое значение.

Зачем читать целое как указатель или указатель как целое?

M>Записи с вариантами и т. п.

Ты про алгебраические типы? http://en.wikipedia.org/wiki/Algebraic_data_type

M>Попытка начать писать тот же шахматный движок под .NET быстро натолкнулась на то, что без постоянного использования unsafe крайне проблематично выделить под хэш фрагмент памяти, разбить его на блоки одинакового размера, представить его в виде списка свободных блоков. Вместо того, чтобы за пять секунд написать то, что я хочу, я вынужден тратить уйму времени на вопросы не связанные непосредственно с задачей.

Зачем весь это ужос?
Чем System.Collection.Generic.Dictionary<Key, Value> не подошол?

M>Например, я хочу хранить некоторые данные как последовательность заканчивается нулевым символом.

Зачем?

M>Так мне удобнее всего в данном случае. Но, соотвественно, код, который берет по одному символу пока не наткнется на нулевой, уже не будет безопасным.

Зачем нужен такой код?
Чем не устраивает fold?

M>И т. п. Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.

А чем не подходит x & ~(x — 1)?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 14:00
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами.

Очень зря.

M>У меня есть память, я к ней обращаюсь как хочу. Захочу, прочитаю из нее указатель, захочу прочитаю из нее целое значение. Записи с вариантами и т. п.

Вдвойне зря.

M>Попытка начать писать тот же шахматный движок под .NET быстро натолкнулась на то, что без постоянного использования unsafe крайне проблематично выделить под хэш фрагмент памяти, разбить его на блоки одинакового размера, представить его в виде списка свободных блоков. Вместо того, чтобы за пять секунд написать то, что я хочу, я вынужден тратить уйму времени на вопросы не связанные непосредственно с задачей.

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

M>Например, я хочу хранить некоторые данные как последовательность заканчивается нулевым символом. Так мне удобнее всего в данном случае. Но, соотвественно, код, который берет по одному символу пока не наткнется на нулевой, уже не будет безопасным. И т. п.

Опять проблема неверного уровня абстракции.
Тебе ведь на самом деле не важно каким образом представлен конец последовательности в алгоритме, главное то что он вообще есть.


M>Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.

Оптимальность ассемблерного кода очень сильно зависит от процессора. А формула a&0x1 или a&0x80 может компилироваться хоть в AND, хоть BT, хоть еще во что-то, что является оптимальным по мнению компилятора (а он гораздо лучше знает).
Кроме того если копилятор в нативный код (JIT) выбирает оптимизации в зависимости от текущего процессора, то более высокоуровневый код в среднем будет более оптимальным, чем написанный на ассемблере.
Re[6]: Есть ли будущее у Native Code?
От: Mr.Cat  
Дата: 23.06.09 14:00
Оценка:
Здравствуйте, Mystic, Вы писали:
M>Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами.
Ну будет у тебя верифицированная работа с битовым массивом (матрицей, кубом?). Делов-то.
Re[6]: Есть ли будущее у Native Code?
От: jedi Мухосранск  
Дата: 23.06.09 14:03
Оценка:
Здравствуйте, Mystic, Вы писали:

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


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


M>>>Моему извращенному уму нативный код писать проще и приятнее.

WH>>А мне нет ибо нативность отбирает кучу умственных ресурсов на вопросы не связанные непосредственно с задачей.

M>>>А верифицируемость накладывает кучу ограничений, которые надо потом думать, как разрулить.

WH>>Какие конкретно ограничения?

M>Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами. У меня есть память, я к ней обращаюсь как хочу. Захочу, прочитаю из нее указатель, захочу прочитаю из нее целое значение. Записи с вариантами и т. п. Попытка начать писать тот же шахматный движок под .NET быстро натолкнулась на то, что без постоянного использования unsafe крайне проблематично выделить под хэш фрагмент памяти, разбить его на блоки одинакового размера, представить его в виде списка свободных блоков. Вместо того, чтобы за пять секунд написать то, что я хочу, я вынужден тратить уйму времени на вопросы не связанные непосредственно с задачей.


Это решается кастомными аллокаторами памяти. К сожаления, тот же .NET (наколько я знаю) такой возможности пока не предоставляет. Но тут надо померять, может и со стандартным все будет пучком

M>Например, я хочу хранить некоторые данные как последовательность заканчивается нулевым символом. Так мне удобнее всего в данном случае. Но, соотвественно, код, который берет по одному символу пока не наткнется на нулевой, уже не будет безопасным.


Мммм. А зачем? Чем хранение длины хуже?

M> И т. п. Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.


if ((x & 0x01) != 0) — я уверен — компилятор разберется. Самая элементарная оптимизация, ее умели еще компиляторы 70-ых.

P.S. Но в целом я согласен, хотелось бы иметь возможность дешево кастить сырую память к value-типам без лишних копирований (тут правда надо подумать, как себя вести если структура содержит ссылки). Или это уже можно и я чего-то не знаю?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[7]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 14:11
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


G>Просто ты пытаешься программировать на уровне абстракции ниже, чем предоставляет .NET, от этого и проблемы.

Да, я пытаюсь программировать на том уровне абстракции, на котором мне удобнее

M>>Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.

G>Оптимальность ассемблерного кода очень сильно зависит от процессора. А формула a&0x1 или a&0x80 может компилироваться хоть в AND, хоть BT, хоть еще во что-то, что является оптимальным по мнению компилятора (а он гораздо лучше знает).

На самом деле речь идет о BSR и BSF. Вряд-ли компилятор цикл for преобразует в BSR, не говоря уже о более оптимальном

static const FLD LSB_Magic[64] = 
{
   A8, B4, E1, H5, E8, B2, E2, G5,
   D8, H4, F7, G2, A7, E3, C3, F5,
   C8, C4, F1, C7, E7, A3, G6, F3,
   H8, D4, G1, E6, B6, E4, H1, E5,
   B8, A4, F8, D1, C1, G7, B7, B1,
   A2, D7, D2, H6, A1, F6, C6, H3,
   G4, G8, H7, C2, F2, A5, H2, D6,
   D3, A6, B5, B3, G3, C5, D5, F4
};

#define pop_lsb(x)  pop_lsb_inner(&x)

static inline FLD pop_lsb_inner(U64* pb)
{
   if (*pb == 0)
      return NF;

   U64 lsb = *pb ^ (*pb - 1);
   unsigned int foldedLSB = ((int) lsb) ^ ((int)(lsb>>32));
   int ind = (foldedLSB * 0x78291ACF) >> (32-6); // range is 0..63

   *pb &= ~lsb;
   return LSB_Magic[ind];
}
Re[7]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 14:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


M>>Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами. У меня есть память, я к ней обращаюсь как хочу. Захочу, прочитаю из нее указатель, захочу прочитаю из нее целое значение.

WH>Зачем читать целое как указатель или указатель как целое?

Хотя бы для экономии.

M>>Записи с вариантами и т. п.

WH>Ты про алгебраические типы? http://en.wikipedia.org/wiki/Algebraic_data_type

Да, об этом. На также и об эффективной их реализации

M>>Попытка начать писать тот же шахматный движок под .NET быстро натолкнулась на то, что без постоянного использования unsafe крайне проблематично выделить под хэш фрагмент памяти, разбить его на блоки одинакового размера, представить его в виде списка свободных блоков. Вместо того, чтобы за пять секунд написать то, что я хочу, я вынужден тратить уйму времени на вопросы не связанные непосредственно с задачей.

WH>Чем System.Collection.Generic.Dictionary<Key, Value> не подошол?

Основная проблема производительность. Выделение/освобождения памяти для объектов фиксированного размера сводится к нескольким ассемблерным командам. Вторая проблема в том, что дерево позиций представляет собой более взаимосвязанную структуру. Когда хэш позиций заполняется больше определенного значения, его нужно чистить. Ну и проще удалить объект из двусвязного списка, чем искать, в каких списках он присутсвует, и оттуда удалять. Плюс заботится о том, чтобы все ссылки на этот объект обнулились, а то он, не освободится...

M>>И т. п. Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.

WH>А чем не подходит x & ~(x — 1)?

Точнее номер первого установленного бита.
Re[7]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 14:35
Оценка:
Здравствуйте, jedi, Вы писали:

J>Это решается кастомными аллокаторами памяти. К сожаления, тот же .NET (наколько я знаю) такой возможности пока не предоставляет. Но тут надо померять, может и со стандартным все будет пучком

Кастомный аллокатор небезопасно...

M>>Например, я хочу хранить некоторые данные как последовательность заканчивается нулевым символом. Так мне удобнее всего в данном случае. Но, соотвественно, код, который берет по одному символу пока не наткнется на нулевой, уже не будет безопасным.

J>Мммм. А зачем? Чем хранение длины хуже?
Небольшая оптимизация. Но даже хранение длины не сделает код безопасным.

M>> И т. п. Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.

J>if ((x & 0x01) != 0) — я уверен — компилятор разберется. Самая элементарная оптимизация, ее умели еще компиляторы 70-ых.
Я имел в виду индекс бита. Желательно с одновременным установлением его в нуль. Типа получаем номер бита из битборда, как во всех генераторах ходов.

J>P.S. Но в целом я согласен, хотелось бы иметь возможность дешево кастить сырую память к value-типам без лишних копирований (тут правда надо подумать, как себя вести если структура содержит ссылки). Или это уже можно и я чего-то не знаю?
Re[7]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 14:36
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

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

M>>Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами.
MC>Ну будет у тебя верифицированная работа с битовым массивом (матрицей, кубом?). Делов-то.
А если он содержит ссылки внутри себя? Плюс потеря производительность на дополнительных проверках...
Re[8]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.06.09 14:41
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Точнее номер первого установленного бита.

Наверное проще создать аналог BitArray над массивом Uint64
и солнце б утром не вставало, когда бы не было меня
Re[8]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 14:56
Оценка:
Здравствуйте, Mystic, Вы писали:

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


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


G>>Просто ты пытаешься программировать на уровне абстракции ниже, чем предоставляет .NET, от этого и проблемы.

M>Да, я пытаюсь программировать на том уровне абстракции, на котором мне удобнее
ты демонстрируешь парадокс блаба. Тебе кажется что удобнее, потому что ты не имеешь опыта написания на высоком уровне абстракции.

M>>>Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.

G>>Оптимальность ассемблерного кода очень сильно зависит от процессора. А формула a&0x1 или a&0x80 может компилироваться хоть в AND, хоть BT, хоть еще во что-то, что является оптимальным по мнению компилятора (а он гораздо лучше знает).
M>На самом деле речь идет о BSR и BSF. Вряд-ли компилятор цикл for преобразует в BSR, не говоря уже о более оптимальном


M>
M>//код скипнут


Так напиши тоже самое без указательной магии на C#, в чем проблема?
Re[9]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 14:57
Оценка:
G>>>А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?
T>>На 99%.
T>>Один процент на то, что потребуется ассемблер. А он потребуется.
G>Ну создателям singularity пока не потребовался. Есть вероятность что и в дальнейшем не потребуется.

Создатели сингулярности пока запустили её только на десятке машин с одной системой команд.

Есть практически 100% вероятность, что когда они запустят на нескольких разных архитектурах, да ещё и с разными требованиями (от микроконтроллера до суперкомпьютера, как на Линуксе), им понадобится ассемблер.

Что-то у меня двойственное впечатление складывается от твоих вопросов. Похоже, тебя интересует не чьё-то мнение, а исключительно своё.

Вот этот вопрос, вопрос про типы
Автор: gandjustas
Дата: 19.06.09
в ветке про TDD. Везде сценарий один и тот же: "x?", мой "y." и твой "а нифига, всё равно x." Без каких-либо признаков даже поверхностных размышлений.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 15:10
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>ты демонстрируешь парадокс блаба. Тебе кажется что удобнее, потому что ты не имеешь опыта написания на высоком уровне абстракции.


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

G>Так напиши тоже самое без указательной магии на C#, в чем проблема?


Проблема в том, что я хочу видеть в машинном коде BSR и BSF.
Re[10]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 15:35
Оценка:
Здравствуйте, thesz, Вы писали:

G>>>>А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?

T>>>На 99%.
T>>>Один процент на то, что потребуется ассемблер. А он потребуется.
G>>Ну создателям singularity пока не потребовался. Есть вероятность что и в дальнейшем не потребуется.

T>Создатели сингулярности пока запустили её только на десятке машин с одной системой команд.

T>Есть практически 100% вероятность, что когда они запустят на нескольких разных архитектурах, да ещё и с разными требованиями (от микроконтроллера до суперкомпьютера, как на Линуксе), им понадобится ассемблер.
А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?
В Singularity они необходимость ассемблера обошли таким образом: коду драйвера передается экземпляр класса, который отвечает за всю низкооуровневую работу (обращения к этому классу вполне могут компилиться в нужный нативный код).
Почему нельзя будет для других архитектур процессоров сделать другие классы, наследники какого-либо базового?

T>Что-то у меня двойственное впечатление складывается от твоих вопросов. Похоже, тебя интересует не чьё-то мнение, а исключительно своё.

T>Вот этот вопрос, вопрос про типы
Автор: gandjustas
Дата: 19.06.09
в ветке про TDD. Везде сценарий один и тот же: "x?", мой "y." и твой "а нифига, всё равно x." Без каких-либо признаков даже поверхностных размышлений.

Я вроде написал что "есть вероятность", а не то что я "стопудово уверен, а кто не согласен идут в жопу"
Re[10]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 15:42
Оценка:
Здравствуйте, Mystic, Вы писали:

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


G>>ты демонстрируешь парадокс блаба. Тебе кажется что удобнее, потому что ты не имеешь опыта написания на высоком уровне абстракции.


M>Писать программы для работы с базами данных на более высоком уровне абстракции---пожалуйста. Шахматный движок---увольте, мне удобнее его писать на чистом С. Нет, я допускаю, что я не умею пользоваться высокими абстракциями. Для меня это в случае разработки шахматного движка это программирование шиворот навыворот: я знаю как должен выглядеть код на самом низком уровне, и начинаю мыслить о том, как бы мне написать высокоуровневую абстрактную конструкцию, чтобы она скомпилировалась во что-то очень близкое к тому, что я ожидаю...

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

G>>Так напиши тоже самое без указательной магии на C#, в чем проблема?

M>Проблема в том, что я хочу видеть в машинном коде BSR и BSF.
Это действительно проблема. Только это проблема в тебе, а не в .NET или еще чем-то.
Re[11]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 15:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну тогда пиши код на низкоуровневом языке, и инвокай его из высокоуровневого, раз тебе так тяжело работать с абстракциями.


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

Моему извращенному уму нативный код писать проще и приятнее.


G>>>Так напиши тоже самое без указательной магии на C#, в чем проблема?

M>>Проблема в том, что я хочу видеть в машинном коде BSR и BSF.
G>Это действительно проблема. Только это проблема в тебе, а не в .NET или еще чем-то.

Может быть и во мне, но сильных шахматных движков, написанных на .NET, я не знаю...
Re[8]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 23.06.09 16:02
Оценка:
Здравствуйте, Mystic, Вы писали:

WH>>Зачем читать целое как указатель или указатель как целое?

M>Хотя бы для экономии.
Экономии чего?

WH>>Ты про алгебраические типы? http://en.wikipedia.org/wiki/Algebraic_data_type

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

M>Основная проблема производительность.

А конкретно?

M>Выделение/освобождения памяти для объектов фиксированного размера сводится к нескольким ассемблерным командам.

Так с ГЦ та же фигня

M>Вторая проблема в том, что дерево позиций представляет собой более взаимосвязанную структуру. Когда хэш позиций заполняется больше определенного значения, его нужно чистить.

А что метод Clear уже отменили?

M>Ну и проще удалить объект из двусвязного списка, чем искать, в каких списках он присутсвует, и оттуда удалять.

Чё? Как связано удаление из одного списка и из нескольких?

M>Плюс заботится о том, чтобы все ссылки на этот объект обнулились, а то он, не освободится...

ГЦ работает не так. Обнулять все ссылки не нужно. Достаточно чтобы объект не был достижим.
В любом случае и в нативе нужно заботиться о том чтобы на мертвый объект не было ссылок иначе
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Есть ли будущее у Native Code?
От: Klapaucius  
Дата: 23.06.09 16:33
Оценка:
Здравствуйте, Mystic, Вы писали:

MC>>Ну будет у тебя верифицированная работа с битовым массивом (матрицей, кубом?). Делов-то.

M>А если он содержит ссылки внутри себя?

Битовый массив?

M>Плюс потеря производительность на дополнительных проверках...


Она зависит от системы типов и вообще информации о семантике, доступной для компилятора.
Какие нужны дополнительные проверки, чтобы получить индекс первой единицы в битовом массиве?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[13]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 16:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>"сила" шахматного алгоритма зависит от реализации оценки позиции и алгоритма перебора вариантов ходов, ковыряние с битами в таких алгоритмах противопоказано. Наносекундные вычисления с битами вероятнее всего незаметны будет.


Насколько я знаю, во всех сильнейших движках используется генератор ходов на основе bitboard. Васик, когда начал писать свою рыбу, первым делом переписал фруктовский движок на битборды. Разве только Fritz их не использует. Сравни по производительности:

1) Берем битовый маску пешек.
2) Делаем AND с битовой маской всех полей, кроме вертикали "а"
3) Сдвигаем битовую маску на 7
4) Делаем AND с битой маской фигур соперника

И мы получили сразу половину взятий пешками.

Аналогично

1) Берем битовую маску ладей
2) Получаем номер поля idx первой ладьи
3) Сдвигаем битовую маску всех фигур на 1 + idx & 0x38, и берем младшие шесть бит результата. Получаем mask
4) По таблице получаем все возможные ходы ладьи по горизонтали.

Оценка позиции играет большую роль, но не менее важна скорость перебора + отсечение вариантов. Плюс многие функции оценки позиции проще выполнять на bitboard-ах, например, является ли пешка проходной это всего лишь один AND.
Re[9]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 16:52
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Какие нужны дополнительные проверки, чтобы получить индекс первой единицы в битовом массиве?


Да никаких не надо, надо выполнить одну ассемблерную команду.
Re[10]: Есть ли будущее у Native Code?
От: Klapaucius  
Дата: 23.06.09 16:59
Оценка:
Здравствуйте, Mystic, Вы писали:

K>>Какие нужны дополнительные проверки, чтобы получить индекс первой единицы в битовом массиве?

M>Да никаких не надо, надо выполнить одну ассемблерную команду.

И что в принципе мешает VM сгенерировать как раз эту команду?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[14]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 17:03
Оценка:
Здравствуйте, Mystic, Вы писали:

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


G>>"сила" шахматного алгоритма зависит от реализации оценки позиции и алгоритма перебора вариантов ходов, ковыряние с битами в таких алгоритмах противопоказано. Наносекундные вычисления с битами вероятнее всего незаметны будет.


M>Насколько я знаю, во всех сильнейших движках используется генератор ходов на основе bitboard. Васик, когда начал писать свою рыбу, первым делом переписал фруктовский движок на битборды. Разве только Fritz их не использует. Сравни по производительности:


M>1) Берем битовый маску пешек.

M>2) Делаем AND с битовой маской всех полей, кроме вертикали "а"
M>3) Сдвигаем битовую маску на 7
M>4) Делаем AND с битой маской фигур соперника

M>И мы получили сразу половину взятий пешками.


M>Аналогично


M>1) Берем битовую маску ладей

M>2) Получаем номер поля idx первой ладьи
M>3) Сдвигаем битовую маску всех фигур на 1 + idx & 0x38, и берем младшие шесть бит результата. Получаем mask
M>4) По таблице получаем все возможные ходы ладьи по горизонтали.

M>Оценка позиции играет большую роль, но не менее важна скорость перебора + отсечение вариантов. Плюс многие функции оценки позиции проще выполнять на bitboard-ах, например, является ли пешка проходной это всего лишь один AND.


Это все понятно. Только накладные расходны на ручную реализацию bsr в данном случае окажутся пренебрежительно малы. А битовые операции и так есть.
Re[14]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 17:05
Оценка:
Здравствуйте, jedi, Вы писали:

G>>"сила" шахматного алгоритма зависит от реализации оценки позиции и алгоритма перебора вариантов ходов, ковыряние с битами в таких алгоритмах противопоказано. Наносекундные вычисления с битами вероятнее всего незаметны будет.


J> Спасибо, рассмешил.

J>Меня вот удивляет откуда такие знатоки всего беруися?

J>На всякий случай. Товарища Мистика я знаю лично и знаком с его реальными результатами в написании движков (в частности, очень неплохого шашечного).

J>А Вы, товавищ gandjustas, чем прославились на этом поприще?
Я тоже написал шашечный движок, еще классе в восьмом или девятом. И что?
Re[11]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 17:07
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


K>>>Какие нужны дополнительные проверки, чтобы получить индекс первой единицы в битовом массиве?

M>>Да никаких не надо, надо выполнить одну ассемблерную команду.

K>И что в принципе мешает VM сгенерировать как раз эту команду?


Это претензия больше к текущему состоянию дел. Принципиальной проблемы добавить некоторую функцию FirstOne, и чтобы VM знала, что эта функция кодируется одной командой нет.
Re[8]: Есть ли будущее у Native Code?
От: Mr.Cat  
Дата: 23.06.09 17:12
Оценка:
Здравствуйте, Mystic, Вы писали:
M>А если он содержит ссылки внутри себя? Плюс потеря производительность на дополнительных проверках...
Полагаю, принципиально возможно совместить высокоуровневые возможности с битоковырянием.
Обрати внимание на bitc, возможно, тебе будет интересно.
Re[16]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 17:12
Оценка:
Здравствуйте, jedi, Вы писали:

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


J>>>На всякий случай. Товарища Мистика я знаю лично и знаком с его реальными результатами в написании движков (в частности, очень неплохого шашечного).

J>>>А Вы, товавищ gandjustas, чем прославились на этом поприще?
G>>Я тоже написал шашечный движок, еще классе в восьмом или девятом. И что?

J>Поздравляю. Видимо на этом основании Вы сделались абсолютным знатоком во всех без исключениях областях человеческой деятельности.

Естественно, а как же иначе.
Re[15]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 23.06.09 17:26
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это все понятно. Только накладные расходны на ручную реализацию bsr в данном случае окажутся пренебрежительно малы. А битовые операции и так есть.


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

На счет "пренебрежимо мало"... 64-битный bsf выполняется за 9 тактов. При генерации ходов FirstOne и LastOne вызывается довольно-таки часто. В целом я слышал цифру порядка единиц процентов по сравнению с тем волшебным кодом, что я приводил.
Re[3]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 23.06.09 18:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Осталось выяснить разновидность этого самого промежуточного кода. Минимум два непримиримых кандидата на престол у нас уже есть — CLR и JVM. Так что, ИМХО, если кто-то кого-то и вытеснит, то точно не в ближайшее время.

WH>Ни тот и ни другой.
WH>У них система типов мягко говоря слабовата.
WH>В ядре ОС без зависимых типов делать нечего.

Ну тогда у нас все уже есть — это obj-файлы.

Мне вообще JVM и .Net кажутся временным финтом несколько в сторону из-за слабости возможностей последних.
Re[11]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 18:47
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


---------------------------
G>>>>>А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?
T>>>>На 99%.
T>>>>Один процент на то, что потребуется ассемблер. А он потребуется.
G>>>Ну создателям singularity пока не потребовался. Есть вероятность что и в дальнейшем не потребуется.
---------------------------

T>>Создатели сингулярности пока запустили её только на десятке машин с одной системой команд.

T>>Есть практически 100% вероятность, что когда они запустят на нескольких разных архитектурах, да ещё и с разными требованиями (от микроконтроллера до суперкомпьютера, как на Линуксе), им понадобится ассемблер.
G>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?

Оптимизированный код? Самотестирование?

G>В Singularity они необходимость ассемблера обошли таким образом: коду драйвера передается экземпляр класса, который отвечает за всю низкооуровневую работу (обращения к этому классу вполне могут компилиться в нужный нативный код).

G>Почему нельзя будет для других архитектур процессоров сделать другие классы, наследники какого-либо базового?

Потому, что низкий уровень бывает разный.

Ты, например, как много "низкого уровня" написал за свою жизнь?

T>>Что-то у меня двойственное впечатление складывается от твоих вопросов. Похоже, тебя интересует не чьё-то мнение, а исключительно своё.

T>>Вот этот вопрос, вопрос про типы
Автор: gandjustas
Дата: 19.06.09
в ветке про TDD. Везде сценарий один и тот же: "x?", мой "y." и твой "а нифига, всё равно x." Без каких-либо признаков даже поверхностных размышлений.

G>Я вроде написал что "есть вероятность", а не то что я "стопудово уверен, а кто не согласен идут в жопу"

Я там выше выделил заинтересовавший меня кусок диалога.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 18:57
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Создатели сингулярности пока запустили её только на десятке машин с одной системой команд.

T>>>Есть практически 100% вероятность, что когда они запустят на нескольких разных архитектурах, да ещё и с разными требованиями (от микроконтроллера до суперкомпьютера, как на Линуксе), им понадобится ассемблер.
G>>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?
T>Оптимизированный код?
Погагаю что к тому времени оптимизация для одного процессора отомрет как класс.

T>Самотестирование?

Самотестирования без ассемблера невозможно? Или что-то конкретное имеется ввиду?

T>Потому, что низкий уровень бывает разный.

T>Ты, например, как много "низкого уровня" написал за свою жизнь?
Немеряно, хотя низкий уровень бывает разный
Re[8]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 23.06.09 19:01
Оценка:
Здравствуйте, thesz, Вы писали:

T>Ты говоришь о полном и безоговорочном доказательстве всего на свете.

T>В этом случае, конечно, нативный код отомрёт.

Нативный/ненативный не столь интересный выбор как защищенная/плоская память. Никакие доказательства не спасают в случае аппаратного сбоя (бит в памяти или в регистре проца не так переключился). В случае защищенной памяти "умрет" лишь процесс, которому не повезло. На машинах потребительского класса подобные сбои происходят постоянно.

Возвращаясь к первому выбору: некий обощенный объектный формат (типа некоего "крутого" obj-формата) — было бы неплохо, а вот runtime jit-compilation — вовсе не факт, ибо если на конце всей цепочки и так будет нативный код, то длину этой цепочки в наиболее частых сценариях необходимо укорачивать.
Re[9]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 19:11
Оценка:
Здравствуйте, vdimas, Вы писали:

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


T>>Ты говоришь о полном и безоговорочном доказательстве всего на свете.

T>>В этом случае, конечно, нативный код отомрёт.

V>Нативный/ненативный не столь интересный выбор как защищенная/плоская память. Никакие доказательства не спасают в случае аппаратного сбоя (бит в памяти или в регистре проца не так переключился). В случае защищенной памяти "умрет" лишь процесс, которому не повезло.

А если этот процесс в ядре, то будет синий экран. Тоже самое для плоской памяти. Попадет ошибка на ядро — смерть и перезагрузка, попадет на другой процесс — умрет процесс с CoreCorruptedException или станет неправильно работать.
Сбои ведь происходят в физической памяти, а не в виртуальной.
Кстати при микроядерной архитектуре гораздо меньше вероятность завалить всю систему такой ошибкой.

V>На машинах потребительского класса подобные сбои происходят постоянно.

А есть статистические данные? Сколько ошибок в секунду\час\год на средней машине?

V>Возвращаясь к первому выбору: некий обощенный объектный формат (типа некоего "крутого" obj-формата) — было бы неплохо, а вот runtime jit-compilation — вовсе не факт, ибо если на конце всей цепочки и так будет нативный код, то длину этой цепочки в наиболее частых сценариях необходимо укорачивать.

Уже сейчас для .NET есть ngen, который позволяет jit-ить сборки при установке, хотя это не всегда выгодно, зачастую jit в рантайме может оптимизировать лучше.
С другой стороны у ngen время работы не сильно ограничено, поэтому он вполне может делать довольно серьезные оптимизации.
Re[13]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 19:13
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


T>>>>Создатели сингулярности пока запустили её только на десятке машин с одной системой команд.

T>>>>Есть практически 100% вероятность, что когда они запустят на нескольких разных архитектурах, да ещё и с разными требованиями (от микроконтроллера до суперкомпьютера, как на Линуксе), им понадобится ассемблер.
G>>>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?
T>>Оптимизированный код?
G>Погагаю что к тому времени оптимизация для одного процессора отомрет как класс.

"Жаль только, жить в этом мире прекрасном,
Уж не придётся ни мне, ни тебе."

Или как там у поэта.

Юникс уж переносили-переносили, да так без ассемблера и не обошлись. А уж суперкомпьютеры без ассемблера вообще никуда.

T>>Самотестирование?

G>Самотестирования без ассемблера невозможно? Или что-то конкретное имеется ввиду?

Ну, проверь регистры процессора без ассемблера.

T>>Потому, что низкий уровень бывает разный.

T>>Ты, например, как много "низкого уровня" написал за свою жизнь?
G>Немеряно, хотя низкий уровень бывает разный

Если ты про тесты там, где могут быть типы, то склонен верить безоговорочно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 19:14
Оценка:
Здравствуйте, vdimas, Вы писали:

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


T>>Ты говоришь о полном и безоговорочном доказательстве всего на свете.

T>>В этом случае, конечно, нативный код отомрёт.
V>Нативный/ненативный не столь интересный выбор как защищенная/плоская память. Никакие доказательства не спасают в случае аппаратного сбоя (бит в памяти или в регистре проца не так переключился). В случае защищенной памяти "умрет" лишь процесс, которому не повезло. На машинах потребительского класса подобные сбои происходят постоянно.

Последнее, конечно, преувеличение, но согласен.

V>Возвращаясь к первому выбору: некий обощенный объектный формат (типа некоего "крутого" obj-формата) — было бы неплохо, а вот runtime jit-compilation — вовсе не факт, ибо если на конце всей цепочки и так будет нативный код, то длину этой цепочки в наиболее частых сценариях необходимо укорачивать.


И тут не могу не согласиться.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.09 20:16
Оценка:
Здравствуйте, thesz, Вы писали:

T>Юникс уж переносили-переносили, да так без ассемблера и не обошлись.


T>Ну, проверь регистры процессора без ассемблера.


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

А вот для драйверов устройств и прикладного кода ассемблер и нативный код вовсе нобязателен.

T>А уж суперкомпьютеры без ассемблера вообще никуда.

Re[15]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.06.09 20:42
Оценка:
T>>А уж суперкомпьютеры без ассемблера вообще никуда.
G>

Именно-именно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 23.06.09 21:32
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Сбои ведь происходят в физической памяти, а не в виртуальной.


Смотря какой код/данные пострадали: пользовательские или ядерные.


G>Кстати при микроядерной архитектуре гораздо меньше вероятность завалить всю систему такой ошибкой.


Пофиг вид архитектуры, если "зараженному" коду видна вся плоская память.

V>>На машинах потребительского класса подобные сбои происходят постоянно.

G>А есть статистические данные? Сколько ошибок в секунду\час\год на средней машине?

У меня еще не было компа, чтобы он в нашей жаре летом не сбоил хотя бы раз в неделю.


V>>Возвращаясь к первому выбору: некий обощенный объектный формат (типа некоего "крутого" obj-формата) — было бы неплохо, а вот runtime jit-compilation — вовсе не факт, ибо если на конце всей цепочки и так будет нативный код, то длину этой цепочки в наиболее частых сценариях необходимо укорачивать.

G>Уже сейчас для .NET есть ngen, который позволяет jit-ить сборки при установке, хотя это не всегда выгодно, зачастую jit в рантайме может оптимизировать лучше.

Это проблемы ngen-а, а не здравого смысла.

G>С другой стороны у ngen время работы не сильно ограничено, поэтому он вполне может делать довольно серьезные оптимизации.


Именно, но инфраструктуры вокруг ngen никакой пока мест. Деплоить выгодней в "объектном" формате, т.к. он более переносим и краток, но запускать надо уже нативный, и как правильно было замечено — хорошо оптимизированный код. Сейчас такой сценарий в общем случае недостижим при использовании того же Click-Once.
Re[7]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 23.06.09 21:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Я склоняюсь к мнению что примитивом общения между процессами должны быть каналы аля сингулярити.

WH>Собственно зависимыми типами можно проверять что протокол отработан верно и что канал будет непременно закрыт.

Тут зависимые типы не причем, достаточно строгой типизации. А насчет "закрыт" — пусть этим подсистема общения занимается.

WH>Плюс можно доказывать отсутствие циклов и прочих задержек в критичных по времени местах.


В общем случае не можно. Можно лишь специальным образом организованные рекурсии таким способом ограничивать. И то, более-менее доступно это пока лишь в С++, а в остальных местах на уровне игр и экспериментов.
Re[9]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 23.06.09 22:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

PD>>То есть ты хочешь сказать, что вирусы в состоянии нарушить аппаратную защиту защищенного режима, и , работая в 3 кольце, получить доступ к страницам, для которых U/S == 0 ? Расскажи , как это делают вирусы, мне это очень интересно

WH>Да мне плевать как. Главное что вирусы пролезают в ядро не смотря на аппаратную защиту.

Они могут туда пролезть, только предварительно проинсталлировав себя в систему (что не требует уровня ядра) и загрузившись как один из системных файлов при последующей загрузке OC. Отсюда мораль: не сидите в и-нете под админскими правами.
Re[5]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 23.06.09 22:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А мне нет ибо нативность отбирает кучу умственных ресурсов на вопросы не связанные непосредственно с задачей.


Боюсь, нативность тут не при чем. Если ты .Net имеешь ввиду, то это речь о библиотеках и ГЦ, которые могут быть ортогональны вопросу нативности.
Re[5]: Есть ли будущее у Native Code?
От: ili Россия  
Дата: 24.06.09 05:22
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


ili>>эмн... тут вы мои слова неверно поняли, или я не яно выразился ))) фактически это я и имел ввиду — в результате все равно получается нативник.

WH>Очень важная поправка: Верифицированный нативник.

гут. согласен. но:

Или его со временем полностью вытеснит верифицируемый промежуточный код?

т.е. я правильно понял, что мы сошлись на мнении, что нативник останется, но (может) будет верифицированным?

WH>

WH>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

WH>ИМХО тут весьма неоднозначно подразумевается именно аппаратная защита.

ИМХО нет. в вопросе вообще ничего не говорится о способах реализации этой изоляции.

но, давате расставим точки над i. ввиду того, что не сказано иного, я предполагаю, что речь идет о самых распространенных платформах — x86 & Windows NT 5.

х86 использует сегментацию памяти, дискрипторы сегментов храняться в таблицах, нас интересуют две из них это GDT — глобальная таблица дескрипторов и LDT — локальная таблица дескрипторов. глобальная таблица — одна, локальных может быть много. таким образом, процессор дает возможность изоляции виртуальной памяти через отдельные LDT для каждого процесса.
сам по себе процессор ничего не изолирует, пользоваться этой возможностью или нет — вопрос к операционной системе.

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

WH>С доказательствами по аналогии иди в другое место.

на сколько мне известно аналогия может служить источником выдвижения гипотиз, но никак не доказательств.

я же ее использовал как вполне (ИМХО конечно) сходний пример с поставленными автором топика вопросами.

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

разделение режжимов ядра и прикладного\пользовательского — тоже, как минимум это защита операционной системы и ее данных. прикладной программист туда случайно не залезет и ничего не грохнет, ИМХО уже это оправдывает все накладные расходы (которые по сути то не так уж и велики, я вот от них еще никогда не страдал, и людей которые страдали — не знаю). опять таки детали реализации в данном случае ИМХО не суть важны. важно само явление.

про изоляцию приложений при помощи виртуального адресного пространства — собственно говорил выше. так или иначе, но оно все равно надо, как минимум для того, чтобы прикладной программист случайно не запорол память соседнего процесса. про детали равлизации вообще выше.
Re[10]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 05:22
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Да никаких не надо, надо выполнить одну ассемблерную команду.

Хм. И насколько она будет быстрее, чем вот такой код:
public static int RightMostBitNumber(long seq)
{
    if ((seq & 0x1) == 0x1)
    {
            // special case for odd v (assumed to happen half of the time)
            return 0;
    }
    else
    {
        var c = 1;
        if ((seq & 0xffffffff) == 0)
        {
            seq >>= 32;
            c += 32;
        }
        if ((seq & 0xffff) == 0)
        {
            seq >>= 16;
            c += 16;
        }
        if ((seq & 0xff) == 0)
        {
            seq >>= 8;
            c += 8;
        }
        if ((seq & 0xf) == 0)
        {
            seq >>= 4;
            c += 4;
        }
        if ((seq & 0x3) == 0)
        {
            seq >>= 2;
            c += 2;
        }
        c -= (int) seq & 0x1;
        return c;
    }
}

?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.06.09 05:36
Оценка:
Здравствуйте, ili, Вы писали:

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

А разве кто-то говорит что нативный код куда-то денется?
Вроде как говорят что программисту не придется нативный код писать.

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

Если статически доказано, что не может программа ничего плохо сделать, то и не нужна защита.

ili>ИМХО уже это оправдывает все накладные расходы (которые по сути то не так уж и велики, я вот от них еще никогда не страдал, и людей которые страдали — не знаю).

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

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

Если при компиляции доказано что он не может это сделать, то рантаймовые проверки не нужны.
Re[10]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 06:25
Оценка:
Здравствуйте, Mystic, Вы писали:


M>В случае GC подобную схему я вижу, например, только в такой реализации: время от времени я спрашиваю GC о том, какой размер памяти выделен динамически. Как только он превышает некоторое критическое значение, я должен освободить неактуальные позиции. Т. е. сделать их недостижимыми. Т. е. обнулить все ссылки на них. После этого я вызываю метод GC который бы форсировал освобождение кучи. Тут, конечно, возможны утечки: например я не сделал объект недостижимым и его не освободил GC. Но, главное, я очень сомневаюсь, что работа GC в таком режиме будет сопоставима по скорости с ручной работой.

Мое мнение, что при работе с большим количеством однотипных объектов, проще работать с ними как с массивом структур, по аналогии с кучей на массиве сос писком свободных позиций (либо если нет удалений то последняя заполненая позиция), а ссылка представляет собой структуру и ссылки на массив и индекс в этом массиве. (При отходе с объектов на структуры выигрыш 12 байт)
Так снимается нагрузка с GC, а сами эти массивы используй как пул для повторного использования.
и солнце б утром не вставало, когда бы не было меня
Re[7]: Есть ли будущее у Native Code?
От: ili Россия  
Дата: 24.06.09 06:33
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


G>А разве кто-то говорит что нативный код куда-то денется?

G>Вроде как говорят что программисту не придется нативный код писать.

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

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

G>Если статически доказано, что не может программа ничего плохо сделать, то и не нужна защита.

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

G>Накладные расходы — огромные, переключение контекста из пользовательского режима в режим ядра — совсем недешевая операция.


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

G>Даже в существущих ОС есть тененция выноса больше кода в режим пользователя, чтобы уменьшить переключения контекста.


готов принять это как аргумент, только имея перед глазами метрики.

G>Если при компиляции доказано что он не может это сделать, то рантаймовые проверки не нужны.


защита-то никуда в этом случае не делась, она просто обеспечивается другим механизмом. о чем я и талдычу.
Re[14]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 06:40
Оценка:
Здравствуйте, thesz, Вы писали:

T>Ну, проверь регистры процессора без ассемблера.


Кстати http://rsdn.ru/article/singularity/singularity.xml#EFG
Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?

там идет речь об ассемблере, но типизированном.


Очевидно, что обеспечение безопасности кода крайне существенно. В настоящее время Singularity полагается на проверку исходного и промежуточного кода компилятором. В будущем типизированный ассемблер (Typed Assembly Language, TAL) позволит Singularity проверять безопасность скомпилированного кода. TAL требует, чтобы исполняемый модуль программы предоставлял доказательства своей типобезопасности (что в случае безопасных языков может делаться компилятором автоматически). Проверка корректности таких доказательств и того, что они применимы для инструкций в исполняемом модуле – прямолинейная задача для простого верификатора из нескольких тысяч строк кода. Такая стратегия сквозной проверки исключает компилятор – большую, сложную программу – из проверенной основы Singularity. Верификатор должен быть тщательно продуман, реализован и проверен, но эти задачи вполне выполнимы благодаря его простоте и размеру.

и солнце б утром не вставало, когда бы не было меня
Re[8]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.06.09 06:40
Оценка:
Здравствуйте, ili, Вы писали:

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


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


G>>А разве кто-то говорит что нативный код куда-то денется?

G>>Вроде как говорят что программисту не придется нативный код писать.

ili>скажите, когда вы в последний раз писали нативный код? уже чертову уйму лет нативный код генерят компиляторы.

Вы пишите нативный код на C\C++\Delphi

G>>Накладные расходы — огромные, переключение контекста из пользовательского режима в режим ядра — совсем недешевая операция.


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

ili>повторюсь, я с проблемами такого рода не сталкивался, о чем честно и не скрывая сказал, т.е. мои выводы основаны на моем опыте.
С метриками туго, так как почти нет реализаций без разделения user\kernel.
В доках по Singularity есть тесты некоторого функционала, можно там посмотреть.
Re[9]: Есть ли будущее у Native Code?
От: ili Россия  
Дата: 24.06.09 07:00
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Вы пишите нативный код на C\C++\Delphi


Машинный код (также употребляются термины собственный код, или платформенно-ориентированный код, или родной код, или нативный код — от англ. native code) — система команд (язык) конкретной вычислительной машины (машинный язык), который интерпретируется непосредственно микропроцессором или микропрограммами данной вычислительной машины.

писать нативный код, это, писать бинарник. на C\C++\Delphi вы пишите на C\C++\Delphi — а их компиляторы герерят нативный код, или объектные модули

.Net компиляторы генерят PE код, который потом CLR компилит в нативник, который и исполняется процессором.

G>С метриками туго, так как почти нет реализаций без разделения user\kernel.

G>В доках по Singularity есть тесты некоторого функционала, можно там посмотреть.

будет время — поищу...
Re[8]: Есть ли будущее у Native Code?
От: IID Россия  
Дата: 24.06.09 07:03
Оценка:
Здравствуйте, thesz, Вы писали:

WH>>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.


T>Дома у меня есть PowerPC. Так что вероятность всего 2/3 (работа, дом и дом).


Гы, а у меня два x86 компа дома, два компа на Z-80, два на 6502, один на К1801ВМ1 и ещё один — двухпроцессорный на КМ1801ВМ2.
kalsarikännit
Re[5]: Есть ли будущее у Native Code?
От: IID Россия  
Дата: 24.06.09 07:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ?

WH>bootstrap сводит эту вероятность практически к нулю.
WH>И даже если что-то проскочит обновить софт куда как проще чем обновить железо.

PD>>В то время как в модели user/superwisor это решено аппаратно.

WH>А где гарантия что нет ошибки в железе?

Обновление микрокода в процессоре решает!
kalsarikännit
Re[14]: Есть ли будущее у Native Code?
От: CreatorCray  
Дата: 24.06.09 08:11
Оценка:
Здравствуйте, jedi, Вы писали:

J> Спасибо, рассмешил.

J>Меня вот удивляет откуда такие знатоки всего беруися?
Дык а он у нас тут местный "знаток" всего на свете. Особенно в КСВ.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 09:02
Оценка:
Здравствуйте, vdimas, Вы писали:

WH>>А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить...

V>Ну вот С++ на зависимых типах построен,
Чё?!
В С++ нет зависимых типов.

V>Для написания того же банального GC необходимы аналогичные способы реинтерпретации памяти... Так что насчет "всё проверить" очень спорно, разве что лишь имеется ввиду проверить "все остальное".

А что по твоему разработчик ГЦ будет ручками память ковырять?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 09:05
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Тут зависимые типы не причем, достаточно строгой типизации.

Какой типизации?

V>А насчет "закрыт" — пусть этим подсистема общения занимается.

Какая еще система? Кто этой системе скажет что канал больше не нужен?

V>В общем случае не можно.

Можно. Учи матчасть.

V>Можно лишь специальным образом организованные рекурсии таким способом ограничивать. И то, более-менее доступно это пока лишь в С++, а в остальных местах на уровне игр и экспериментов.

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 09:13
Оценка:
Здравствуйте, IID, Вы писали:

IID>Он гонит Вирусы всегда лезли в ядро через софт. Устанавливаясь драйвером, например. Или записывая себя с существующие драйвера. Или переключаясь в режим супервизора сервисом ОС (в 9x, привет WinCIHу).


Мне-то ты зачем это объясняешь ? . Ему объясни. Хотя сомневаюсь, что это получится — если человек в состоянии назвать MySQL дисковой подсистемой, то объяснять дальше бесполезно
With best regards
Pavel Dvorkin
Re[6]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 09:16
Оценка:
Здравствуйте, ili, Вы писали:

ili>т.е. я правильно понял, что мы сошлись на мнении, что нативник останется, но (может) будет верифицированным?

Нативник останется только деталью реализации.
Он никому кроме ВМ не будет виден. Так же как и сейчас никто не видит то что делает JIT.

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

Вот только ты не сможешь загрузить из интернета нативный код и запустить его.
Можно загрузить только промежуточный верифицируемый код из которого будет сделан нативный на месте.
Те никакого распространения программ в виде нативных бинарников не будет это и есть смерть нативного кода.

ili>разделение режжимов ядра и прикладного\пользовательского — тоже, как минимум это защита операционной системы и ее данных. прикладной программист туда случайно не залезет и ничего не грохнет, ИМХО уже это оправдывает все накладные расходы (которые по сути то не так уж и велики, я вот от них еще никогда не страдал, и людей которые страдали — не знаю). опять таки детали реализации в данном случае ИМХО не суть важны. важно само явление.

Еще раз автор вопроса весьма не однозначно имел в виду аппаратную изоляцию, а не изоляцию вообще.

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

Если весь код верефицируемый то программист физически даже если очень сильно захочет не сможет ничего запороть даже в своем процессе не говоря уже про соседний.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 09:28
Оценка:
Здравствуйте, WFrag, Вы писали:

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


PD>>Последний раз ИМХО исправляли одну из первых версий 386, в которой был какой-то баг в чем-то, связанном с плавающей точкой. С тех пор я не помню об ошибках в процессорах, требовавших их замены.


WF>Если отбросить последние два слова, то багов без фиксов хватает.


А я совсем не случайно их написал.


>Хотя бы даже если смотреть по документику. Какие из них можно (и можно ли) использовать для прорыва в 0-вое кольцо — я не знаю, может и никакие.


Если бы они были, боюсь, пришлось бы заменять процессоры — их немедленно использовали бы всякие вирусописатели.
With best regards
Pavel Dvorkin
Re[9]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 09:30
Оценка:
Здравствуйте, IID, Вы писали:

IID>Он гонит Вирусы всегда лезли в ядро через софт.

Бла-бла-бла. Пользователю все равно ибо вирус пролез.
И никакая аппаратная защита не помогла.

С программной изоляцией такого не случится благодаря значительно более мелкой гранулярности проверок и значительно более широкому классу этих проверок.
В отличии от аппаратной защиты которая контролирует чтение/запись/исполнение с гранулярностью 4К программная защита контролирует работу с каждым битом проверяя практически произвольные правила.
Скажем переполнение буфера, гонки и многое другое можно полностью устранить.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Есть ли будущее у Native Code?
От: Воронков Василий Россия  
Дата: 24.06.09 09:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

G>>Скорее всего нет. Ибо виртуализация.

WH>Ну да... разве что для всяких там вмварей чтобы легаси гонять.

Не очень разбираюсь в этом вопросе, честно говоря, но разве аппаратная поддержка виртуализации не избавляет от необходимости делать изоляцию адресного пространства ручками?
Re[7]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 09:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

PD>>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.
S>Это всё малоинтересно. С точки зрения пользователя, самое страшное уже произошло — в коде оказалась ошибка, и запрошенную операцию выполнить не удалось. То, что ядро системы продолжает успешно работать, никому (кроме авторов ядра) неинтересно*.

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

>Это и есть та причина (а вовсе не производительность), по которой обеспечение иммутабельности переменной при помощи аппаратной защиты никому не нужно.

S>Интересно иметь до начала выполнения программы гарантии того, что даже и попыток выполнить недопустимую операцию не будет.

Ха! А гарантии , что файл на диске есть, ты не хочешь ? Почему же тебя уставивает FileNotFoundException (и другие), но не устраивает AccessViolationException ? А меня оба устраивают, в обоих случаях это может быть либо ошибкой с необходимостью завершения , либо ситуацией, требующей обработки с продолжением.


S>(*) — нет, я понимаю, что бывают ситуации, когда в одной среде выполняются приложения с разными классами требований. Грубо говоря, не хочется, чтобы управление впрыском в двигатель заткнулось от того, что отвалился MP3-плеер. Но аппаратная защита всего лишь спасёт управление впрыском от ошибок в плеере; спасти управление впрыском от ошибок в управлении впрыском она не может. А вот статическая верификация — может.


Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.
With best regards
Pavel Dvorkin
Re[10]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 09:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>С программной изоляцией такого не случится благодаря значительно более мелкой гранулярности проверок и значительно более широкому классу этих проверок.

WH>В отличии от аппаратной защиты которая контролирует чтение/запись/исполнение с гранулярностью 4К

Все, теперь все стало ясно. Вирусы пролезают в нулевое кольцо из-за того, что защита поставлена не каждому байту, а всем 4К одинаковая
With best regards
Pavel Dvorkin
Re[11]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 24.06.09 09:49
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Так снимается нагрузка с GC, а сами эти массивы используй как пул для повторного использования.


И про это я думал... Тут ньюансов два: в пуле можно выделять объекты разных структур, если они имеют одинаковый размер. Во-вторых, работа с индексами вместо указателей будет менее удобна, как по мне. Плюс вопрос с производительностью (выход за пределы диапазона).

Я не говорю, что написать производительный движок под .NET в принципе нельзя. Сделать можно, но при этом наблюдается очень неприятный эффект: работая с абстрактными структурами я должен постоянно как бы компилировать возникающий код и смотреть, а что получится на более низком уровне. Все это делает работу менее удобной. Иногда я должен
в верифицируемом коде использовать всякие трюки, как-то GlobalPositions[GlobalPositions[CurrentIndex].Next], вместо CurrentPosition->Next.
Re[8]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 09:56
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Не ядро системы, а сама система, равно как и все прочие приложения. Только нарушитель изгоняется. И мне как пользователю этой машины это очень даже интересно — я вовсе не хочу после каждого падения программы нажимать на Reset. Не хочу обратно в ДОС

Гм. Это опять "мы хотим, чтобы не было богатых" против "дедушка хотел, чтобы не было бедных".
Ты хочешь, чтобы упавшая программа не могла сломать еще не упавшие (и дать им упасть самостоятельно), а мы хотим, чтобы программы вообще не падали.

PD>Ха! А гарантии , что файл на диске есть, ты не хочешь ?

Хочу. И есть способ построить систему, которая гарантирует мне отсутствие FileNotFoundException в принципе. Потому как в ней не предусмотрен способ обращаться к несуществующим файлам.

PD>Почему же тебя уставивает FileNotFoundException (и другие), но не устраивает AccessViolationException ?

Меня устраивают все они, но я хочу минимизировать объем кода, связанного с обработкой нештатных ситуаций. Просто потому, что их всегда гораздо больше, чем штатных.
PD>А меня оба устраивают, в обоих случаях это может быть либо ошибкой с необходимостью завершения , либо ситуацией, требующей обработки с продолжением.

S>>(*) — нет, я понимаю, что бывают ситуации, когда в одной среде выполняются приложения с разными классами требований. Грубо говоря, не хочется, чтобы управление впрыском в двигатель заткнулось от того, что отвалился MP3-плеер. Но аппаратная защита всего лишь спасёт управление впрыском от ошибок в плеере; спасти управление впрыском от ошибок в управлении впрыском она не может. А вот статическая верификация — может.


PD>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.

Мы — нет. В твоих задачах плата, скорее всего, будет перевешивать выручку.
А про ограниченность — мы же вроде в этой ветке говорим о будущем? Ну так почему бы нам не захотеть доказательства всё более сильных утверждений о наших программах?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 09:58
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все, теперь все стало ясно. Вирусы пролезают в нулевое кольцо из-за того, что защита поставлена не каждому байту, а всем 4К одинаковая

А ты что не знал?
Переполнили буффер и вперед.
В случае с системой типов типа жабы будет исключения и вирус никуда не полезет.
В случае применения зависимых типов программа не скомпилируется пока не напишешь так что переполнений гарантировано не будет и вирус снова не у дел. Причем без единой проверки во время работы программы. Все компилятор поймает.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 10:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Гм. Это опять "мы хотим, чтобы не было богатых" против "дедушка хотел, чтобы не было бедных".

S>Ты хочешь, чтобы упавшая программа не могла сломать еще не упавшие (и дать им упасть самостоятельно), а мы хотим, чтобы программы вообще не падали.

Ну сделать, чтобы программа не падала, не так уж сложно — SetUnhandledExceptionFilter, и формально она не упадет, а закончится корректно. А если ты имеешь в виду, чтобы в ней не было ошибок — "программа, свободная от ошибок есть абсрактное теоретическое понятие", и это для меня сомнению не подлежит. Можешь сделать, чтобы не было доступа куда не надо, модификации чего не надо, но если вместо плюса в ней минус, то это отловить тебе никто не поможет.


PD>>Ха! А гарантии , что файл на диске есть, ты не хочешь ?

S>Хочу. И есть способ построить систему, которая гарантирует мне отсутствие FileNotFoundException в принципе. Потому как в ней не предусмотрен способ обращаться к несуществующим файлам.

Имеешь право хотеть. Заодно создай себе гарантии, что все прочие exception тоже никогда возникать не будут. Теоретически это, наверное, возможно, практически не существует и едва ли интересно.

PD>>Почему же тебя уставивает FileNotFoundException (и другие), но не устраивает AccessViolationException ?

S>Меня устраивают все они, но я хочу минимизировать объем кода, связанного с обработкой нештатных ситуаций. Просто потому, что их всегда гораздо больше, чем штатных.

Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.

PD>>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.

S>Мы — нет. В твоих задачах плата, скорее всего, будет перевешивать выручку.

Вот именно. +1

S>А про ограниченность — мы же вроде в этой ветке говорим о будущем? Ну так почему бы нам не захотеть доказательства всё более сильных утверждений о наших программах?


Под ограниченностью я имею в виду, что вы накладываете серьезные требования на иммутабельные типы, а поэтому большинство типов таковыми не будет. И дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.
With best regards
Pavel Dvorkin
Re[8]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 10:06
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Не ядро системы, а сама система, равно как и все прочие приложения. Только нарушитель изгоняется. И мне как пользователю этой машины это очень даже интересно — я вовсе не хочу после каждого падения программы нажимать на Reset. Не хочу обратно в ДОС

А ДОСа не будет. Система будет более устойчивой чем сейчас.
Если в неком процессе будет ошибка то можно просто прибить этот процесс и все.
Система как работала так и будет работать.
Причем это касается не только рядовых процессов как в венде, а всех включая драйверы.

S>>Интересно иметь до начала выполнения программы гарантии того, что даже и попыток выполнить недопустимую операцию не будет.

PD>Ха! А гарантии , что файл на диске есть, ты не хочешь ?
Лично я хочу но не очень понятно как этого добиться.

PD>Почему же тебя уставивает FileNotFoundException (и другие), но не устраивает AccessViolationException ?

По тому что от FileNotFoundException не избавится, а вот без AccessViolationException можно спокойно жить.

PD>А меня оба устраивают, в обоих случаях это может быть либо ошибкой с необходимостью завершения , либо ситуацией, требующей обработки с продолжением.

Второе нужно только менеджеру памяти ОС.

PD>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите

Чем конкретно мы за нее платим?
Отказом от С++? Ну да и хрен бы с ним.

PD>и слишком она ограничена.

А конкретно?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 24.06.09 10:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Все, теперь все стало ясно. Вирусы пролезают в нулевое кольцо из-за того, что защита поставлена не каждому байту, а всем 4К одинаковая

WH>А ты что не знал?
WH>Переполнили буффер и вперед.
WH>В случае с системой типов типа жабы будет исключения и вирус никуда не полезет.
WH>В случае применения зависимых типов программа не скомпилируется пока не напишешь так что переполнений гарантировано не будет и вирус снова не у дел. Причем без единой проверки во время работы программы. Все компилятор поймает.

достаточно скомпилить вирус "косячным" компилятором, чтобы убить незащищенную систему с легкостью. runtime либо, как минимум, deployment-time проверки все равно должны присутствовать, иначе вирусописателям будет только проще.
Re[8]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 10:27
Оценка:
PD>Не ядро системы, а сама система, равно как и все прочие приложения. Только нарушитель изгоняется. И мне как пользователю этой машины это очень даже интересно — я вовсе не хочу после каждого падения программы нажимать на Reset. Не хочу обратно в ДОС

Для этого есть SIPы http://rsdn.ru/article/singularity/singularity.xml#EYC
Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?
и солнце б утром не вставало, когда бы не было меня
Re[11]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 24.06.09 10:38
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


M>>Да никаких не надо, надо выполнить одну ассемблерную команду.

S>Хм. И насколько она будет быстрее, чем вот такой код:
...
S>?

Девять тактов против пяти условий (первое условие можно смело выкинуть, потому что в большинстве битовых масок поле A1 будет сброшено) а в худшем случае еще десять битовых операций... При чем худший случай совсем не теоретический (например, в начальной позиции маска черных ладей равна 0x8100000000000000). И по алгоритму мы вначале получаем индекс первой ладьи, сбрасываем его и получаем индекс второй...

Чтобы было понятно, как будет использоваться этот код, приведу фрагмент обычного кода генерации ходов:

uint64 bitboard = GetRooks(); // Получение ладей (аналогично слоны, ферзи и кони)
while (bitboard) 
{
  // Получаем первую ладью и одновременно очищаем этот бит в bitboard
  from = ExtractFirstOne(bitboard); 

  // Тут скрыто много ньюансов, но AttacksRook возвращает битовую маску полей, куда может походить ладья
  // Если используются повернутые битовые маски, то хранится bitboard всех фигур не только в обычном порядке A1, B1, C1, ...
  // Но и в порядке A1, A2, A3, ..., A8, B1, ..., что позволяет получить поля, куда может пойти ладья, по таблице
  // Аналогично работает и для слонов (там используются bitboard-ы, повернутые на 45 и 135 градусов, как-то 
  // A8, A7, B8, .... A1, B2, C3, ... Для коней все проще, можно заранее посчитать битовую маску куда он может 
  // прыгнуть для каждого поля.
  moves = AttacksRook(from, OccupedSquares); 

  // Ну и дальше просто. Пока есть куда пойти
  while (moves)
  {
    // Получает первое поле
    to = ExtractFirstOne(moves);

    // Делаем ход
    DoMove(from, to);
  }
}


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

Ну а к сведению, наиболее близок по производительности этот
Автор: Mystic
Дата: 23.06.09
вариант, но... Я такой код только содрать могу...
Re[14]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 24.06.09 10:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Недостаточно. Код просто не пройдет верификацию и все. И никаких прав не хватит чтобы его запустить.


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

S>>runtime либо, как минимум, deployment-time проверки все равно должны присутствовать, иначе вирусописателям будет только проще.

WH>Ну так проверки времени установки и будут. А вот проверки времени исполнения будут практически полностью устранены зависимыми типами.

бтв, как ты смотришь на необходимость длительной и ресурсоемкой верификации перед каждой установкой каждой программы?
Re[13]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 24.06.09 10:52
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Ты можешь определить эти методы в самой структуре (массив,индекс), аля курсор.

S>например

Даже если отбросить вопросы производительности, оперировать напрямую с указателями мне просто удобнее по той причине, что об этом просто не надо задумываться.
Re[11]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 11:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>А еще можно сделать бесплатную сборку мусора в С.

WH>Знаешь как?
WH>Запускаем программу на 64х битной системе.
WH>Вся неиспользуемая память будет навсегда оседать в свопе.

Ты сначала разберись, чем отличается виртуальная память от физической (включая своп), чтобы не говорить такое. То, о чем ты говоришь, есть управление физической памятью в ОС, своп файл и RAM исключительно под ее контролем, я туда никак из 3 кольца попасть не могу. А сборка мусора есть действие исключительно в виртуальной памяти процесса.

WH>Далее смотрим если в свопе лежит страница к которой не обращались неделю значит она не нужна и выкидываем ее.


А если не секрет, как из программы 3 кольца узнать, как давно мы не обращались к этой странице ? Мне это очень интересно знать Более того, мне вообще интересно знать, как я смогу найти эту страницу в своп-файле из приложения 3 кольца ? Где она хранится — я узнать вообще-то могу и ее атрибуты тоже, только для этого надо в нулевое кольцо как-то перебраться, а это только вирусы, по твоему мнению, умеют, а я их не пишу . Драйверы, конечно, могут это сделать, только вот у них , кроме того, что они в нулевом кольце работают, есть масса других отличий от процесса — ну хотя бы то, что им до моей виртуальной памяти дела никакого нет, поскольку выполняются они отнюдь не в контексте моего процесса, возможно.

WH>


Юмор могу и оценить, но честное слово, кончай высказываться по вопросам, в которых ты не разбираешься! У тебя есть области, в которых ты разбираешься неплохо, зачем тебе лезть туда, где ты ничего не понимаешь и говорить чепуху ?

PD>>А если ты имеешь в виду, чтобы в ней не было ошибок — "программа, свободная от ошибок есть абсрактное теоретическое понятие", и это для меня сомнению не подлежит.

WH>Тут согласен.

PD>>Можешь сделать, чтобы не было доступа куда не надо, модификации чего не надо, но если вместо плюса в ней минус, то это отловить тебе никто не поможет.

WH>А тут не совсем.
WH>Зависимые типы могут очень много чего ловить.

И все же, если в формуле для корней квадратного уравнения я напишу sqrt(b*b+4*a*c), какие зависимые типы это отловят ? А может, мне именно так и надо ?

PD>>Имеешь право хотеть. Заодно создай себе гарантии, что все прочие exception тоже никогда возникать не будут. Теоретически это, наверное, возможно, практически не существует и едва ли интересно.

WH>Чтобы совсем не было исключений не получится. Но вот убить почти все исключения можно.

Да все можно — в теории. И твоя тотально управляемая ОС в теории тоже не так уж плоха. Как идея. Но реально тебе накидали немало возражений (DMA, текстуры, внешние устройства), могу еще и свое добавить — CUDA, там надо резидентную память иметь. И т.д. И практически чтобы твою идею о тотальном управлении реализовать, нужен иной процессор, иная периферия, в общем, глобальная революция. Революции не так уж плохи, но надо отдавать себе отчет, во имя чего ее будут делать, тратить миллиарды долларов. Во имя перехода от ужасной 16-битной модели к нормальной 32-битной — да. Во имя перехода от нормальной 32-битной модели, но ограничения которой начинают мешать, к 64-битной — да ,хотя, кстати, так и не перешли до сих пор. А ты чем заплатишь ? Некоторой (и то в теории, никто же не проверял) надеждой на улучшение надежности программ, которые не будут лезть куда не надо ? И ради этого переписать все ПО, переделать всю аппаратуру ? И ради этого миллиарды долларов ? Не дадут.

PD>>Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.

WH>Когда я писал числомолотилки то меня тоже мало заботили нештатные ситуации ибо в числомолотилках они почти не встречаются.
WH>А вот шаг в сторону и приплыли.

Именно. Я же об этом и говорю. Разные есть задачи. А машина одна

PD>>>>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите и слишком она ограничена.

S>>>Мы — нет. В твоих задачах плата, скорее всего, будет перевешивать выручку.
PD>>Вот именно. +1
WH>Приехали. Ты уже сам с собой споришь...

Почему ? Я согласен, что плата за иммутабельные объекты в моих задач слишком большая, и, как говорит Антон, перевесит выручку. В чем я себе противоречу ?

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

WH>Ты просто привык к императивному базису и ничего другого не понимаешь.
WH>А у тех кто понимает большинство типов именно такими и будут.

Так разные же есть задачи. Вот ты писал, как говоришь, числодробилки. Там констант много было ? Как бы все не кончилось 4 константами — 0 , 1 pi и e

PD>>И дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.

WH>Не мы, а вы!
WH>У меня в программах переменных весьма не много даже если приходится писать на С++.

Так, стоп. Под переменными я имею в виду отнюдь не описания

List* pL;

безусловно формально одна переменная, но в действительности их тут столько, сколько полей у всех элементов списка.

WH>А если я пишу на немерле то там на сотни строк кода может не быть ни одной переменной.


Я с немерле не знаком, поэтому спорить не буду. Но по существу, думаю, они и там есть, хотя формально, может, и нет.

В конце концов по существу переменная (в широком смысле слова) — это некий блок памяти, содержимое которого может изменяться (а константы — не может). А как это в языке оформлено — это уже от языка зависит. И такие переменные есть в любой программе на любом языке, иначе что это программа делает-то ?
With best regards
Pavel Dvorkin
Re[14]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 11:11
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Даже если отбросить вопросы производительности, оперировать напрямую с указателями мне просто удобнее по той причине, что об этом просто не надо задумываться.

А кто же обещал простых путей? За определенные удобства в одном нужно платить выкрутасами в другом (происходит ломка). Но это тоже интересно, плюс изменение мышления.
Пока, что JIT далек от совершенства. Но все течет,все меняется и у манагед в перспективе аппаратная независимость на уровне байт кода.
Да еще плюс ParallelFx
и солнце б утром не вставало, когда бы не было меня
Re[11]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 11:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>Ну сделать, чтобы программа не падала, не так уж сложно — SetUnhandledExceptionFilter, и формально она не упадет, а закончится корректно.

PD>> А если ты имеешь в виду, чтобы в ней не было ошибок — "программа, свободная от ошибок есть абсрактное теоретическое понятие", и это для меня сомнению не подлежит.
S>Я уже заметил, что для тебя статистические вещи малопонятны.

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

PD>>Можешь сделать, чтобы не было доступа куда не надо, модификации чего не надо, но если вместо плюса в ней минус, то это отловить тебе никто не поможет.

S>Я, в общем-то, согласен и на 99%.

Я так думаю, что придется на 100%. Потому что этот плюс там не по ошибке, а мне именно так и надо, как выяснилось

PD>>Имеешь право хотеть. Заодно создай себе гарантии, что все прочие exception тоже никогда возникать не будут. Теоретически это, наверное, возможно, практически не существует и едва ли интересно.

S>Видишь ли, уровень безошибочности, достижимый при помощи K&R С, был достигнут уже давно. И мне как раз неинтересно рассуждать на тему "а потому работай-не работай, всё едино".
S>Мне интересно думать на тему "а что еще можно улучшить?"

Многое можно улучшить, хотя при чем тут K&R — неясно. Но то, что вы улучшаете (index out of range, access violation и т.д.) есть маленький-маленький процент от числа всевозможных ошибок при мало-мальски серьезном алгоритме. Поэтому мне и не кажется серьезным такая забота об этих мелочах. Серьезные вещи вы все равно не улучшите, так как неформализуемо это (см. пример с плюсом-минусом, а это самый примитивный из тех, что я могу придумать)

PD>>Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.

S>Просто в твоих задачах, значит, эти ситуации малосущественны.

Да.

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

S>Да ладно! Это ты как считал?

Я никак не считал, но приведи мне эти самые иммутабельные типы в нынешней библиотеке. String, DateTime... сколько еще покажешь общеупотребимых ?

PD>>И дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.

S>Гм. Как бы так тебе объяснить... Ты под термином "программа" всё время подразумеваешь "программа на языке С".

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


S>В лучшем случае — "алгоритм", то есть Тьюринговский формализм программирования. Это только один, и очень узкий взгляд. Как ты, возможно, знаешь, любой алгоритм можно выразить не только в виде программы для машины Тьюринга, но и в виде частично вычислимых функций. А там, извини, никаких переменных вовсе нет. Поэтому то, что вы имеете в программе намного больше переменных — это лично ваша заслуга, а отнюдь не неотъемлемое свойство самих программ


См. мой ответ WolfHound в самом конце.
With best regards
Pavel Dvorkin
Re[9]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 11:29
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Не ядро системы, а сама система, равно как и все прочие приложения. Только нарушитель изгоняется. И мне как пользователю этой машины это очень даже интересно — я вовсе не хочу после каждого падения программы нажимать на Reset. Не хочу обратно в ДОС

WH>А ДОСа не будет. Система будет более устойчивой чем сейчас.
WH>Если в неком процессе будет ошибка то можно просто прибить этот процесс и все.

И сейчас можно.

WH>Система как работала так и будет работать.


И сейчас работает.

WH>Причем это касается не только рядовых процессов как в венде, а всех включая драйверы.


Да, вот тут ты прав. Жаль, что идея 4 колец не реализовалась. Драйверы ИМХО не должны бы быть в нулевом кольце, а должны бы в 1-м. Тогда при ошибке в драйвере ядро могло бы его прибить. В общем, модель 80286. Но не пошло.

S>>>Интересно иметь до начала выполнения программы гарантии того, что даже и попыток выполнить недопустимую операцию не будет.

PD>>Ха! А гарантии , что файл на диске есть, ты не хочешь ?
WH>Лично я хочу но не очень понятно как этого добиться.

А зачем ? Что все же плохого просто в том, чтобы проверить наличие файла ?

PD>>Почему же тебя уставивает FileNotFoundException (и другие), но не устраивает AccessViolationException ?

WH>По тому что от FileNotFoundException не избавится, а вот без AccessViolationException можно спокойно жить.

И что ? Что вы все эти пустяки раздуваете до немыслимых размеров , а потом борьбу с ними представляете как чуть не главное в программировании. Ну пустяки это же все. Мелочи.

PD>>А меня оба устраивают, в обоих случаях это может быть либо ошибкой с необходимостью завершения , либо ситуацией, требующей обработки с продолжением.

WH>Второе нужно только менеджеру памяти ОС.

При чем тут менеджер памяти ОС, когда я говорю о произошедшем в моем процессе исключении, которое я хочу обработать (SEH) и продолжать. А тебе известно, что я могу вполне сознательно допускать Access Violation, ибо он часть логики моей программы и именно этого я и хочу ? Посмотри у Рихтера, там это обсуждается (в разделе по управлению виртуальной памятью). И вообще ты про резервирование и коммитирование слышал, чем отличаются, понимаешь ?

PD>>Да я не против самой идеи статической верификации. Но ИМХО слишком дорого вы за нее платите

WH>Чем конкретно мы за нее платим?
WH>Отказом от С++? Ну да и хрен бы с ним.

PD>>и слишком она ограничена.

WH>А конкретно?

Давай так. Я не имею времени обсуждать все это с тобой и Антоном одновременно. Либо вы скооперируйтесь, либо смотри мои ответы не только в ответе тебе. Я ему ответил.
With best regards
Pavel Dvorkin
Re[12]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 11:34
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Все, теперь все стало ясно. Вирусы пролезают в нулевое кольцо из-за того, что защита поставлена не каждому байту, а всем 4К одинаковая

WH>А ты что не знал?
WH>Переполнили буффер и вперед.

Да ну ? А можно поподробнее, как это можно переполнить буфер и проникнуть таким образом в нулевое кольцо ? Можно примерчик кода 3 кольца ? Или это только вирусописатели умеют так буфер переполнять ?
With best regards
Pavel Dvorkin
Re[15]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 24.06.09 11:46
Оценка:
Здравствуйте, Serginio1, Вы писали:

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


S>Пока, что JIT далек от совершенства. Но все течет,все меняется и у манагед в перспективе аппаратная независимость на уровне байт кода.


Аппаратную независимость можно достичь и на уровне исходников. По крайней мере принципиальных отличий байт-кода от исходников нет. По идее один и тот же C# код должен компилироваться в один и тот же байт-код. Так что большой разницы нет, то ли я получу байт-код, то ли я получу код на C#. Так что претензии больше не к самой идее JIT, а к требованию верифицируемости кода. Да, верификация нужна больше в тех случаях, когда код запускается без моего ведома, как, например, скрипты на странице. Но в этом случае, по большому счету, и не нужна производительность. А если я скачал программу из интернета, я доверяю ее автору. Откомпилировал да запустил, и на верификацию плевать. И пример больше иллюстрировал тот факт, что разрабатывать неверифицированный код в некоторых случаях проще. Ну и, собственно говоря, непонятно, почему верифицированный код должен вытеснить неверифицированный?
Re[13]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 24.06.09 12:15
Оценка:
В дополнение.

Я тебе серьезно советую — разберись наконец, чем виртуальная память отличается от физической , и кто чем управляет. Не в твоей гипотетической управляемой ОС, а в Windows. Ты их просто-напросто путаешь, а поэтому пишешь такое, что ни в какие ворота не лезет.
With best regards
Pavel Dvorkin
Re[16]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 12:19
Оценка:
Здравствуйте, Mystic, Вы писали:

Скорость компиляции подготовленного кода выше (плюс верифицированного), а по сути созвучна с переносимости на уровне исходников.
А по поводу, что проще никто и не спорит. Но когда разговор идет об отказоустойчивости, то верификации стоит уделить больше внимания. В свое время Оберон системы много здесь обсуждались, причем достаточно надменно, затем появилась сингулярити и тон уже сильно изменился. Для разных задач нужны различные инструменты. Хотя для мобильных устройств на первоначальном этапе, верифицированый код может дать множество бенефитов (оберон системы для беспилотных аппаратов работают).
По аналогии сборками Линукс на исходниках.
и солнце б утром не вставало, когда бы не было меня
Re[15]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 13:02
Оценка:
Здравствуйте, swined, Вы писали:

S>ты же сам сказал, что верификацией должен заниматься компилятор.

Ага. Компилятор из промежуточного кода в нативный...

S>компилятор работает не на твоей машине

frontend да.
А вот backend на моей.

S>и слитый из интернетов бинарь может содержать все, что угодно.

Если он содержит что-то не правильное он просто не пройдет верификацию.

S>бтв, как ты смотришь на необходимость длительной и ресурсоемкой верификации перед каждой установкой каждой программы?

Конечно отрицательно.
Он кто сказал что она будет длительной и ресурсоемкой?
Время верификации O(N) от размера программы.
Да и O там весьма маленькое.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 13:06
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Чтобы было понятно, как будет использоваться этот код, приведу фрагмент обычного кода генерации ходов:

Тебе нужен не индекс последнего бита, а индексы всех установленных битов.
А это уже решается по другому.
Нужно составить таблицу в которой записаны индексы установленных битов в байте.
Потом просто разбиваешь Int64 на байты и...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 13:20
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

WH>>А ДОСа не будет. Система будет более устойчивой чем сейчас.

WH>>Если в неком процессе будет ошибка то можно просто прибить этот процесс и все.
PD>И сейчас можно.
WH>>Система как работала так и будет работать.
PD>И сейчас работает.
Я жэто все к тому что ДОСа не получится.

PD>Да, вот тут ты прав. Жаль, что идея 4 колец не реализовалась. Драйверы ИМХО не должны бы быть в нулевом кольце, а должны бы в 1-м. Тогда при ошибке в драйвере ядро могло бы его прибить. В общем, модель 80286. Но не пошло.

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

WH>>Лично я хочу но не очень понятно как этого добиться.

PD>А зачем ? Что все же плохого просто в том, чтобы проверить наличие файла ?
Чтобы не забыть проверить и не придумывать потом что делать если его таки нет.
Пойми одну простую вещь: Гарантировать отсутствие проблема гораздо лучше чем решать последствия проблемы.

PD>И что ? Что вы все эти пустяки раздуваете до немыслимых размеров , а потом борьбу с ними представляете как чуть не главное в программировании. Ну пустяки это же все. Мелочи.

Избавление от всех исключений не вызванных внешними факторами мелочи?
Проверка кода на уровне до которого юниттестам как до пекина раком мелочи?
Уничтожение вирусов мелочи?
...
Фигасе у тебя мелочи.

PD>При чем тут менеджер памяти ОС, когда я говорю о произошедшем в моем процессе исключении, которое я хочу обработать (SEH) и продолжать.

А у меня этого исключения гарантированно не будет.

PD>А тебе известно, что я могу вполне сознательно допускать Access Violation, ибо он часть логики моей программы и именно этого я и хочу ?

А нахрена оно тебе нужно? Что это за логика такая?

PD>Посмотри у Рихтера, там это обсуждается (в разделе по управлению виртуальной памятью). И вообще ты про резервирование и коммитирование слышал, чем отличаются, понимаешь ?

Не хуже тебя.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 13:23
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да ну ? А можно поподробнее, как это можно переполнить буфер и проникнуть таким образом в нулевое кольцо ? Можно примерчик кода 3 кольца ? Или это только вирусописатели умеют так буфер переполнять ?

А сразу в нулевое кольцо и не надо.
Сначала вломились в какой нибудь браузер.
Потом устроили эскалацию привилегий.
Потом поставили драйвер.
...

В управляемой ОС все останется на стадии не смогли вломиться в браузер.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 24.06.09 13:25
Оценка:
S>>бтв, как ты смотришь на необходимость длительной и ресурсоемкой верификации перед каждой установкой каждой программы?
WH>Конечно отрицательно.
WH>Он кто сказал что она будет длительной и ресурсоемкой?
WH>Время верификации O(N) от размера программы.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.64

Аж до экспоненциальной сложности доходит для определённых логик.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 13:26
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я тебе серьезно советую — разберись наконец, чем виртуальная память отличается от физической , и кто чем управляет. Не в твоей гипотетической управляемой ОС, а в Windows. Ты их просто-напросто путаешь, а поэтому пишешь такое, что ни в какие ворота не лезет.

Я это прекрасно знаю.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 24.06.09 13:32
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Потом просто разбиваешь Int64 на байты и...


Это сможет как-то соперничать по скорости. И то надо измерить как, потому что BSF/BSR будет все равно быстрее. И еще нужно ломать голову над тем, чтобы сделать запись такой же выразительной. Во-вторых, тот магический код, что я приводил
Автор: Mystic
Дата: 23.06.09
, требует восемь операций + обращение к таблице без всяких условий, думаю, что он будет быстрее.
Re[17]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 13:32
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>А по поводу, что проще никто и не спорит. Но когда разговор идет об отказоустойчивости, то верификации стоит уделить больше внимания. В свое время Оберон системы много здесь обсуждались, причем достаточно надменно, затем появилась сингулярити и тон уже сильно изменился.

А что в оберон системах уже завелся верифицируемый код?
А может там появились зависимые типы?
Или они наконец избавились от идиотской идеи одного логического пространства на всех?
А может они еще и от глобальных переменных избавились?

S>Для разных задач нужны различные инструменты.

Для чего конкретно не подходит верифицируемый код?

S>Хотя для мобильных устройств на первоначальном этапе, верифицированый код может дать множество бенефитов

1)Для любых.
2)На всех этапах.

S>(оберон системы для беспилотных аппаратов работают).

Это настолько тепличная среда что обсуждать тут нечего.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 13:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

S>>А по поводу, что проще никто и не спорит. Но когда разговор идет об отказоустойчивости, то верификации стоит уделить больше внимания. В свое время Оберон системы много здесь обсуждались, причем достаточно надменно, затем появилась сингулярити и тон уже сильно изменился.

WH>А что в оберон системах уже завелся верифицируемый код?
На уровне комплятора. Там манагед языки
WH>А может там появились зависимые типы?
Дай ссылки на зависимые типы, а тупой найти не могу.
WH>Или они наконец избавились от идиотской идеи одного логического пространства на всех?
WH>А может они еще и от глобальных переменных избавились?
Ну идея SIP практически та же, но не знаю ка в обероне с изоляцией процессов. Опять же Exchange Heap
имеет место жить. Ну и последующие Оси должны все же сильно отличатся от того, что сделал Вирт с сотоварищами, при скудном финансировании,
и теоретической базы. От простого к сложному.
S>>Для разных задач нужны различные инструменты.
WH>Для чего конкретно не подходит верифицируемый код?
Надо говорить об эффективности на конкретном временном отрезке.

S>>Хотя для мобильных устройств на первоначальном этапе, верифицированый код может дать множество бенефитов

WH>1)Для любых.
WH>2)На всех этапах.

Которых еще не существует. А двигаться лучше от простого к сложному, тем более уже есть в этом направлении наработки.

S>>(оберон системы для беспилотных аппаратов работают).

WH>Это настолько тепличная среда что обсуждать тут нечего.
Работающая, но по 3 рубля.
и солнце б утром не вставало, когда бы не было меня
Re[19]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 14:02
Оценка:
Здравствуйте, Serginio1, Вы писали:

WH>>А что в оберон системах уже завелся верифицируемый код?

S> На уровне комплятора. Там манагед языки
И как защититься от скаченного с инета скомпилированного хрен знает кем бинаря?

WH>>А может там появились зависимые типы?

S>Дай ссылки на зависимые типы, а тупой найти не могу.
Уже давал. http://en.wikipedia.org/wiki/Dependent_type
Ты ветку не читаешь что-ли?

WH>>Или они наконец избавились от идиотской идеи одного логического пространства на всех?

WH>>А может они еще и от глобальных переменных избавились?
S>Ну идея SIP практически та же,
Нет у оберонщиков SIP. Совсем нету.

S>но не знаю ка в обероне с изоляцией процессов.

Никак.

S>Опять же Exchange Heap имеет место жить.

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

S>Ну и последующие Оси должны все же сильно отличатся от того, что сделал Вирт с сотоварищами, при скудном финансировании, и теоретической базы. От простого к сложному.

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

WH>>Для чего конкретно не подходит верифицируемый код?

S> Надо говорить об эффективности на конкретном временном отрезке.
Отрезке чего?

S> Которых еще не существует. А двигаться лучше от простого к сложному, тем более уже есть в этом направлении наработки.

Какие? Только не надо про совершенно непотребную оберон ось.

S>>>(оберон системы для беспилотных аппаратов работают).

WH>>Это настолько тепличная среда что обсуждать тут нечего.
S> Работающая, но по 3 рубля.
Чё?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 24.06.09 14:11
Оценка:
T>>http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.64
WH>Статейка как я понимаю платная...

Там есть download/cached.

WH>Даже мой любимый обесплатниваетель http://scholar.google.com/ что-то не помогает.


T>>Аж до экспоненциальной сложности доходит для определённых логик.

WH>Да и причем тут Unrestricted Hierarchical State Machines ?
WH>Вот скажем взяли программу на хаскеле.
WH>Рассахарили, вывели все типы,...
WH>И результат сбросили в бинарник.
WH>Лично я не вижу ни одной причины по которой верификация этого бинарника требовала бы отличное от O(N) время.

Какая верификация?

Отсутствие деления на 0? Отсутствие зацикливания? Отсутствие утечек памяти?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 14:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>А может там появились зависимые типы?

S>>Дай ссылки на зависимые типы, а тупой найти не могу.
WH>Уже давал. http://en.wikipedia.org/wiki/Dependent_type
WH>Ты ветку не читаешь что-ли?
Спасибо незаметил. Прочитал, вспомнил Хаскель, каррирование, но понял не всё


S>>Ну и последующие Оси должны все же сильно отличатся от того, что сделал Вирт с сотоварищами, при скудном финансировании, и теоретической базы. От простого к сложному.

WH>Тут не финансирование виновато.
WH>Тут мозг нужен чтобы понять что и как надо делать. И главное как не надо.
Зато появилась практическая база, и понимание ккак делать нельзя.
WH>>>Для чего конкретно не подходит верифицируемый код?
S>> Надо говорить об эффективности на конкретном временном отрезке.
WH>Отрезке чего?
Пока нет этих ОСей, говорить даже об эффективности не приходится.
Хотя теоретически всё выглядит ооочень привлекательно.
S>> Которых еще не существует. А двигаться лучше от простого к сложному, тем более уже есть в этом направлении наработки.
WH>Какие? Только не надо про совершенно непотребную оберон ось.
Нет я про Midori. Оберон только как предтеча впервые мною услышанной.
Не любишь ты Вирта. Лучше что то делать, чем ничего.
S>>>>(оберон системы для беспилотных аппаратов работают).
WH>>>Это настолько тепличная среда что обсуждать тут нечего.
S>> Работающая, но по 3 рубля.
WH>Чё?

Раки крупные по пять рублей, но вчера, а сегодня мелкие, но по три рубля

и солнце б утром не вставало, когда бы не было меня
Re[19]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 14:24
Оценка:
Здравствуйте, thesz, Вы писали:

T>Какая верификация?

T>Отсутствие деления на 0? Отсутствие зацикливания? Отсутствие утечек памяти?
Отсутствие нарушения типизации. Этого достаточно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Есть ли будущее у Native Code?
От: dr.Chaos Россия Украшения HandMade
Дата: 24.06.09 14:33
Оценка:
Здравствуйте, vdimas, Вы писали:


V>У меня еще не было компа, чтобы он в нашей жаре летом не сбоил хотя бы раз в неделю.


[offtop]
У меня таких целых 3 . Причём один из них работает 24/7.
[/offtop]
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[21]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 15:00
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Спасибо незаметил. Прочитал, вспомнил Хаскель, каррирование, но понял не всё

Причем тут хаскель и каррирование я так и не понял.

S> Зато появилась практическая база, и понимание ккак делать нельзя.

У меня это понимание появилось просто при чтении описания модели ОС. Так что я бы это дело зарубил бы еще до начала разработки как бесперспективное занятие.
А вот у обиронщиков оно так и не появилось.

WH>>Какие? Только не надо про совершенно непотребную оберон ось.

S>Нет я про Midori. Оберон только как предтеча впервые мною услышанной.
А что про эту самую мидори известно?
Ну кроме того что мелкософт всеравно не пустит ее в продакшен.

S> Не любишь ты Вирта.

А за что его любить?

S>Лучше что то делать, чем ничего.

Распил грантов это не хорошее занятие.

S>

S> Раки крупные по пять рублей, но вчера, а сегодня мелкие, но по три рубля

И при чем тут это?
На беспилотниках настолько тепличные условия что там что угодно заработает.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 24.06.09 15:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


T>>Какая верификация?

T>>Отсутствие деления на 0? Отсутствие зацикливания? Отсутствие утечек памяти?
WH>Отсутствие нарушения типизации. Этого достаточно.

Рекомендую загрузить в ghci следующее:

dup a = (a,a)

dup4 = dup . dup . dup . dup

dup16 = dup4 . dup4 . dup4 . dup4

dup64 = dup16 . dup16 . dup16 . dup16

dup256 = dup64 . dup64 . dup64 . dup64

dup1024 = dup256 . dup256 . dup256 . dup256

dup4096 = dup1024 . dup1024 . dup1024 . dup1024 

dupVeryVeryVeryBig = dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     id


Всё ещё O(N)?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 15:55
Оценка:
Здравствуйте, thesz, Вы писали:

T>Рекомендую загрузить в ghci следующее:

хъ
T>Всё ещё O(N)?
Тут ты специально вырастил тип просто ацкого размера.
И таки да относительно размера этого типа таки O(N).
Но как часто на практике выращивают такие ацкие типы?
Думаю никогда.
В прочем думаю можно пройтись по доступным хаскелевским программам и посчитать размеры типов.
Но лично я сильно сомневаюсь что найдутся типы больше чем dup4 . dup4
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 16:26
Оценка:
Здравствуйте, WolfHound, Вы писали:


S>> Зато появилась практическая база, и понимание ккак делать нельзя.

WH>У меня это понимание появилось просто при чтении описания модели ОС. Так что я бы это дело зарубил бы еще до начала разработки как бесперспективное занятие.
WH>А вот у обиронщиков оно так и не появилось.
Только по времени на сигулярити ушло немало.
Значит их удовлетворяет для их задач.
WH>>>Какие? Только не надо про совершенно непотребную оберон ось.
S>>Нет я про Midori. Оберон только как предтеча впервые мною услышанной.
WH>А что про эту самую мидори известно?
WH>Ну кроме того что мелкософт всеравно не пустит ее в продакшен.

http://pcportal.org.ru/forum/37-100-1

Эксперты ИТ-рынка связывают большие надежды с внедрением этой системы особенно на мобильных устройствах благодаря встроенному механизму контроля энергопотребления. Модульность Midori также позволит разрабатывать программы, независимые от технических характеристик устройств. Так, например, для "тонких клиентов" станут актуальными заложенные в Midori принципы "облачных вычислений" (cloud-computing) и хранения данных в интернете. В этом случае, по мнению Брайана Мэддена (Brian Madden), на компьютер не нужно будет устанавливать много ПО — необходимые сетевые сервисы в основном уже будут существовать в Сети.

и солнце б утром не вставало, когда бы не было меня
Re[12]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 17:29
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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

Это твоё право. Но очень зря. Потому что обращая внимание на непонятные тебе вещи, ты бы смог сделать свои программы лучше. Помнишь, мы обсуждали длины строк? Статистически 99% строк в природе оборудованы длиной от момента своего рождения. Игнорирование этого факта приводит к чудовищно неэффективным алгоритмам на строках.
При этом аргумент в пользу игнорирования ровно один: "а вдруг там не будет длины".

PD>Я так думаю, что придется на 100%. Потому что этот плюс там не по ошибке, а мне именно так и надо, как выяснилось

Я имею в виду, что я согласен на инфраструктуру, которая ловит 99% ошибок. Это в 100 раз сократит мне время отладки.
Понятно, что никакая математика не сможет сказать, соответствует ли спецификация задаче. А вот проверить соответствие программы спецификации очень даже можно.

PD>Многое можно улучшить, хотя при чем тут K&R — неясно. Но то, что вы улучшаете (index out of range, access violation и т.д.) есть маленький-маленький процент от числа всевозможных ошибок при мало-мальски серьезном алгоритме.

Ты опять говоришь про вчерашний день в контексте дня завтрашнего. Посмотри на Code contracts по поводу того, что доступно уже сегодня. И это — промышленный уровень; а в research лежит еще больше готовых образцов.

PD>Поэтому мне и не кажется серьезным такая забота об этих мелочах. Серьезные вещи вы все равно не улучшите, так как неформализуемо это (см. пример с плюсом-минусом, а это самый примитивный из тех, что я могу придумать)

Придумывание контрпримеров — это хорошо. Это правильно. Но начиная примерно с 90го года рулят алгоритмы, которые затачиваются не на максимальное быстродействие в самом хреновом случае, а на максимальное среднее быстродействие с учётом реальной статистики. Именно поэтому смоллтоковые программы с (о, ужас!) биндингом по имени метода рвут C++ программы, скомпилированные старыми компилерами. Несмотря на биндинг по номеру слота.

PD>>>Меня это мало интересует. Меня гораздо больше интересует суть алгоритма, чем нештатные ситуации. Их обработка в конечном счете пишется в большинстве случаев почти не думая, а сколько там будет строк — мне все равно, я и так знаю, что я на это потрачу намного меньше времени, чем на собственно решение задачи.

S>>Просто в твоих задачах, значит, эти ситуации малосущественны.

PD>Да.


PD>Я никак не считал, но приведи мне эти самые иммутабельные типы в нынешней библиотеке. String, DateTime... сколько еще покажешь общеупотребимых ?

Uri. Regex. Дело не в этом — ты же считаешь, что это связано с какими-то "ограничениями". Хотелось бы аргументов на эту тему.

PD>Нет. Я, кстати, отнюдь не С-шник по первому языку. И мне язык в данном случае безразличен, правда, ограничусь императивными.

Да не безразличен тебе язык. Ты мыслишь императивными, причём построенными по одной и той же модели с минимальными синтаксическими различиями.

PD>См. мой ответ WolfHound в самом конце.

Ок, посмотрим.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 24.06.09 20:49
Оценка:
T>>Рекомендую загрузить в ghci следующее:
WH>хъ
T>>Всё ещё O(N)?
WH>Тут ты специально вырастил тип просто ацкого размера.
WH>И таки да относительно размера этого типа таки O(N).
WH>Но как часто на практике выращивают такие ацкие типы?
WH>Думаю никогда.
WH>В прочем думаю можно пройтись по доступным хаскелевским программам и посчитать размеры типов.
WH>Но лично я сильно сомневаюсь что найдутся типы больше чем dup4 . dup4

В принципе, ты прав. Типы экспоненциального размера встречаются редко, поскольку о них же рассуждать человеку. Это я больше для демонстрации самого факта сложности проверки алгоритмом W.

Но они могут быть и достаточно большими. Например, для одной моей программы требуется -fcontext-stack=100, то есть, она совершает не менее 100 шагов упрощения типов вычислениями над ними с семействами типов (type families). Проверка типов занимает заметное время порядка 30 секунд.

Вот.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 01:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Я тебе серьезно советую — разберись наконец, чем виртуальная память отличается от физической , и кто чем управляет. Не в твоей гипотетической управляемой ОС, а в Windows. Ты их просто-напросто путаешь, а поэтому пишешь такое, что ни в какие ворота не лезет.

WH>Я это прекрасно знаю.

Вряд ли. Иначе зачем ерунду пишешь ?
With best regards
Pavel Dvorkin
Re[14]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 01:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А сразу в нулевое кольцо и не надо.

WH>Сначала вломились в какой нибудь браузер.
WH>Потом устроили эскалацию привилегий.
WH>Потом поставили драйвер.

Тебе же тут уже объяснили — не работайте под админом. Кстати, как ты собираешься устроить эту самую эскалацию для процесса броузера, если он (под Вистой) запущен хоть и от админа, но без админских прав ? (т.е с юзеровскими правами) Это тоже очень интересно бы знать
With best regards
Pavel Dvorkin
Re[15]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 02:59
Оценка:
Здравствуйте, swined, Вы писали:
S>ты же сам сказал, что верификацией должен заниматься компилятор. компилятор работает не на твоей машине и слитый из интернетов бинарь может содержать все, что угодно.
Нет, это ты путаешь. Верификатор — совершенно отдельная штука. Его нужно делать как можно более компактным, потому что его верификация выполняется вручную. Вручную верифицировать огромный компилятор ты запаришься.
S>бтв, как ты смотришь на необходимость длительной и ресурсоемкой верификации перед каждой установкой каждой программы?
Верификация делается за O(N), где N — размер программы
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 05:38
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>То, о чем ты говоришь, есть управление физической памятью в ОС, своп файл и RAM исключительно под ее контролем, я туда никак из 3 кольца попасть не могу. А сборка мусора есть действие исключительно в виртуальной памяти процесса.

WH>Почему исключительно?

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

PD>>А если не секрет, как из программы 3 кольца узнать, как давно мы не обращались к этой странице ?

WH>А ей и не надо.

Ты же мне предлагал это сделать

WH>Хачим ОСь и вперед.


А подробности опять-таки можно ? Какие файлы, как именно. Как к этому WFP отнесется ?

Каждый раз, когда ты очередную химеру предложишь, я тебя прошу о деталях немного сказать. А в ответ мне новую химеру предлагаешь. Может, все же удостоишь рассказать что-нибудь ?



PD>>И твоя тотально управляемая ОС в теории тоже не так уж плоха. Как идея. Но реально тебе накидали немало возражений (DMA, текстуры, внешние устройства), могу еще и свое добавить — CUDA, там надо резидентную память иметь.

WH>Только куберакс сам признал что там все будет не хуже чем сейчас...

Все же, что с CUDA делать-то будешь ? Мне резидентную память для нее вынь да положь!


PD>>И ради этого переписать все ПО, переделать всю аппаратуру ? И ради этого миллиарды долларов ? Не дадут.

WH>ПО можно переделывать постепенно. Ведь можно начать с относительно небольших ниш.

А ОС тоже постепенно будешь переделывать ? Превратим Windows в управляемую систему ? Не выйдет. А существующее ПО куда ?

WH>Тем более что начать можно даже не с полноценной ОС, а с виртуальной машины типа жабы. А когда программ будет достаточно можно уже и в полноценную ОС превращаться.


VM Java существует полтора десятка лет и до сих пор ни в какую ОС не пыталась превратиться, по крайней мере на x86.


WH>Железо подойдет современное.


CUDA ?

WH>Даже без IOMMU но тогда периферии придется доверять. В прочем в современных ОС ей и так доверяют.


PD>>Именно. Я же об этом и говорю. Разные есть задачи. А машина одна

WH>А процессор один.
WH>Ты сказать то что хотел?
WH>Что нештатные ситуации обрабатывать не надо?

Можно ссылку, где это я сказал ? Или это твои домыслы ?

PD>>Так разные же есть задачи. Вот ты писал, как говоришь, числодробилки. Там констант много было ? Как бы все не кончилось 4 константами — 0 , 1 pi и e

WH>Числомолотилки прекрасно пишутся на функциональщине при наличии оптимизатора.




WH>А есть и более интересный базис.

WH>Абстрактная сетевая машина называется.
WH>Одно из свойств этого базиса частичные вычисления, а это ключ к очень мощной оптимизации.
WH>Другое замечательное свойство это независимость результата от порядка вычислений, а это ключ к распараллеливанию.

Ох! Тихий ужас. Не зная сути задач, не зная их потребностей предлагать какое-то распределенное решение...

WH>Вот например простенький оптимизатор без единой переменной.


<skipped>

WH>Написать это короче практически невозможно.


А меня мало интересует, короче или длинее.

PD>>В конце концов по существу переменная (в широком смысле слова) — это некий блок памяти, содержимое которого может изменяться (а константы — не может).

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

Совершенно верно. В моделях языка не существует. Но выполняется этот код не в модельной среде, а на конкретной машине. У этой машины линейное (скорее всего) адресное пространство. Память, иными словами. И все твои абстракции в конечном счете превращаются в эти презренные блоки памяти. Так что я просто говорю о том, что из твоих модельных соображений получается в конечном счете. И от этого никуда не деться — до тех пор, пока твои абстракции не будут реализованы аппаратно, то есть вместо ОП мы будем иметь какой-то набор аппаратных то ли ArrayList, то ли LinQ моделей, то ли еще чего-то...

PD>>А как это в языке оформлено — это уже от языка зависит. И такие переменные есть в любой программе на любом языке, иначе что это программа делает-то ?

WH>См код выше.
WH>Скока там переменных?

Нет, ты никак понять меня либо не хочешь, либо не можешь.

Последний аргумент (ибо дискуссию в этой ветви я прекращаю). Я иногда позволяю себе давать советы и рекомендации в форуме .Net, хотя я отнюдь не специалист в ней. Когда там особенности языка или библиотек обсуждаются, я молчу — некомпетентен. Но когда там обсуждается нечто такое, что требует выхода на уровень ниже (Win API) — я иногда свои советы даю, и не без успеха. И с таким же успехом я могу их дать в форуме , например, по FoxPro, которуя я совсем не знаю. Один раз я видел пример для FoxPro с вызовом средств Win API, так что я знаю, что это возможно. Все. Этого вполне достаточно, чтобы я мог давать советы в этой части. Есть базис, есть надстройка. Можно бы это наконец понять...
With best regards
Pavel Dvorkin
Re[13]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 06:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>В конце концов по существу переменная (в широком смысле слова) — это некий блок памяти, содержимое которого может изменяться (а константы — не может). А как это в языке оформлено — это уже от языка зависит. И такие переменные есть в любой программе на любом языке, иначе что это программа делает-то ?

S>Может, тебе что-то из основ программирования почитать? Ну, чтобы знать, что далеко не все языки программирования оперируют абстракциями типа "блок памяти".

Может, тебе основы организации компьютера почитать ? Чтобы понять, что независимо от языка, при выполнении программы дело закончится некими действиями с блоками памяти ? По крайней мере до тех пор, пока вместо ОП не появятся аппаратно реализованные абстракции твоего любимого языка.
With best regards
Pavel Dvorkin
Re[11]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 07:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Да, вот тут ты прав. Жаль, что идея 4 колец не реализовалась. Драйверы ИМХО не должны бы быть в нулевом кольце, а должны бы в 1-м. Тогда при ошибке в драйвере ядро могло бы его прибить. В общем, модель 80286. Но не пошло.

WH>Ага. По тому что тормозило...

Нет, не поэтому. Потому что сегментная модель неудобна для реализации.

PD>>А зачем ? Что все же плохого просто в том, чтобы проверить наличие файла ?

WH>Чтобы не забыть проверить и не придумывать потом что делать если его таки нет.

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

WH>Пойми одну простую вещь: Гарантировать отсутствие проблема гораздо лучше чем решать последствия проблемы.


В теории да. В реальности — просто не выйдет.

PD>>И что ? Что вы все эти пустяки раздуваете до немыслимых размеров , а потом борьбу с ними представляете как чуть не главное в программировании. Ну пустяки это же все. Мелочи.

WH>Избавление от всех исключений не вызванных внешними факторами мелочи?

Всех ? А ну-ка, избавь меня от FloatOverflowException или ZeroDivideException? При одних данных умножение/деление работает, при других — exception. Или это внешние факторы ?

Не всех, а только некоторых — IndexOutOfBounds, AccessViolation и т.п. Вот от этого еще можно надеяться. А это для меня истинно мелочи.


WH>Проверка кода на уровне до которого юниттестам как до пекина раком мелочи?


Да. И юниттесты меня также мало интересуют. У меня свои тесты были, их не сгенерируешь, их получить надо, и было их примерно 100 тысяч.

WH>Уничтожение вирусов мелочи?


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


PD>>При чем тут менеджер памяти ОС, когда я говорю о произошедшем в моем процессе исключении, которое я хочу обработать (SEH) и продолжать.

WH>А у меня этого исключения гарантированно не будет.

PD>>А тебе известно, что я могу вполне сознательно допускать Access Violation, ибо он часть логики моей программы и именно этого я и хочу ?

WH>А нахрена оно тебе нужно? Что это за логика такая?
PD>>Посмотри у Рихтера, там это обсуждается (в разделе по управлению виртуальной памятью). И вообще ты про резервирование и коммитирование слышал, чем отличаются, понимаешь ?
WH>Не хуже тебя.

А если не хуже меня, зачем вопрос задаешь насчет того, для чего надо допускать Access Violation и что это за логика такая ? Я же тебе написал про Рихтера, мог бы и посмотреть. Более того, если бы ты и впрямь знал это — у тебя такого вопроса даже не могло бы возникнуть, это же азбука.

Ладно, приведу кусок из Рихтера сам. Не для тебя — так для других может быть полезно

///////////////////////////////////////////////////////////////////////////////////////////////////////////////
Let's pretend you're implementing a spreadsheet application that supports 200 rows by 256 columns. For each cell, you need a CELLDATA structure that describes the contents of the cell. The easiest way for you to manipulate the two-dimensional matrix of cells would be to declare the following variable in your application:

CELLDATA CellData[200][256];

If the size of a CELLDATA structure were 128 bytes, the two-dimensional matrix would require 6,553,600 (200 × 256 × 128) bytes of physical storage. That's a lot of physical storage to allocate from the paging file right up front for a spreadsheet, especially when you consider that most users put information into only a few spreadsheet cells, leaving the majority unused. The memory usage would be very inefficient.

So, historically, spreadsheets have been implemented using other data structure techniques, such as linked lists. With the linked-list approach, CELLDATA structures have to be created only for the cells in the spreadsheet that actually contain data. Since most cells in a spreadsheet go unused, this method saves a tremendous amount of storage. However, this technique makes it much more difficult to obtain the contents of a cell. If you want to know the contents of the cell in row 5, column 10, you must walk through linked lists in order to find the desired cell, which makes the linked-list method slower than the declared-matrix method.

Virtual memory offers us a compromise between declaring the two-dimensional matrix up front and implementing linked lists. With virtual memory, you get the fast, easy access offered by the declared-matrix technique combined with the superior storage savings offered by the linked-list technique.

// далее пропущены детали

There are four methods for determining whether to commit physical storage to a portion of a region:

// пропущены первые 3 метода. ниже все выделенное — мной (PD)

Use structured exception handling (SEH)—the best method . SEH is an operating system feature that causes the system to notify your application when certain situations occur. Essentially, you set up your application with an exception handler, and then, whenever an attempt is made to access uncommitted memory, the system notifies your application of the problem. Your application then commits the memory and tells the system to retry the instruction that caused the exception. This time the memory access succeeds, and the program continues running as though there had never been a problem. This method is the most advantageous because it requires the least amount of work from you (meaning less code) and because your program will run at full speed. A complete discussion of the SEH mechanism is saved for Chapters 23, 24, and 25. The Spreadsheet sample application in Chapter 25 illustrates exactly how to use virtual memory as I've just described
With best regards
Pavel Dvorkin
Re[7]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 25.06.09 07:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить...

V>>Ну вот С++ на зависимых типах построен,
WH>Чё?!
WH>В С++ нет зависимых типов.

Не ожидал от тебя такого заявления.
Ты точно знаешь, о чем говоришь?

V>>Для написания того же банального GC необходимы аналогичные способы реинтерпретации памяти... Так что насчет "всё проверить" очень спорно, разве что лишь имеется ввиду проверить "все остальное".

WH> А что по твоему разработчик ГЦ будет ручками память ковырять?

Не важно чем, если есть ср-ва прочитать/записать хотя бы байт из/в произвольного участка памяти, то вся безопасность и доказуемость сразу улетучивается.
Re[9]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 25.06.09 07:11
Оценка:
Здравствуйте, WolfHound, Вы писали:


V>>В общем случае не можно.

WH>Можно. Учи матчасть.

Блин, тебе хочется хлеба и зрелищ? Ну давай покажи как можно в ОбЩЕМ случае. Заодно список языков с примерами.

V>>Можно лишь специальным образом организованные рекурсии таким способом ограничивать. И то, более-менее доступно это пока лишь в С++, а в остальных местах на уровне игр и экспериментов.

WH>

А я тебе на С++ покажу.
Re[12]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 25.06.09 07:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В случае применения зависимых типов программа не скомпилируется пока не напишешь так что переполнений гарантировано не будет и вирус снова не у дел.

WH>Причем без единой проверки во время работы программы. Все компилятор поймает.

Все эти возможности доступны и сейчас в том же С++, однако не особо народ юзает. Не подскажешь, почему?
Re[15]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 07:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

PD>>Может, тебе основы организации компьютера почитать ? Чтобы понять, что независимо от языка, при выполнении программы дело закончится некими действиями с блоками памяти ? По крайней мере до тех пор, пока вместо ОП не появятся аппаратно реализованные абстракции твоего любимого языка.
S>А зачем мне про это читать? Это ты всё время путаешь уровни абстракции.
S>Вот ты говоришь:
S>

дело здесь не в будущем, а в существе — мы все же в программе имеем намного больше переменных, чем констант, пусть и временно живущих.

S>Ты здесь под программой что имеешь в виду? Исходную программу, или её некоторое воплощение в код реальной машины?

Разумеется, второе. На языке могут быть явно описаны переменные или константы. На языке (вполне традиционном) они могут быть заданы неявно или сгенерированы компилятором

int i = 2*2;

и в рабочем коде нет 2, а есть 4, ибо это сделано на этапе компиляции. Хотя я 4 не заводил.

В языке может вообще не быть переменных. Он может быть некоего описательного типа, при этом переменные генерируются компилятором/средой выполнения. Но они все равно есть.


S>Большинство программистов таки понимают первое. В таком контексте, переменная (storage) — это чисто математическая абстракция, которая применяется при описании семантики языков программирования. Не всех, разумеется, а только некоторого подмножества императивных.


Как большинство понимает — это мне сейчас не так важно. Напомню, речь шла о константных и неконстантных объектах. Сгенерировал ли их компилятор по некоему явному описанию или же завел их так, что я их и не вижу в своем коде — они все равно либо константны, либо нет. Проще говоря, эти блоки памяти будут изменяться или нет. Если будут — их нельзя в R/O память. Если не будут — можно. Все.

S>Но дальше ты говоришь про "выполнение программы". Тут как бы ты перепрыгиваешь на уровень ниже — там от программы почти ничего не остаётся. Да, там есть что-то вроде "блоков памяти" (ну, то есть даже внутри "аппаратной машины" всё еще есть разные уровни абстракции; на более высоких есть только регистры ЦПУ, память и порты, а на более низких видны все детали буферов, защёлок и прочих потрохов различных устройств). Но никаких переменных к этому моменту уже не остаётся.


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


S>Вот пункт в как раз и есть про оптимизацию. Начинающим программистам кажется, что самый дружественный к оптимизации язык — это такой, на котором можно делать ассемблерные вставки. Неа. Самый дружественный — это такой, в котором нельзя делать ассемблерные вставки.


With best regards
Pavel Dvorkin
Re[16]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 25.06.09 08:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

кстати да, каким бы компактным не был верификатор, в нем могут быть ошибки. хардварная защита как-то понадежней будет.

S>>бтв, как ты смотришь на необходимость длительной и ресурсоемкой верификации перед каждой установкой каждой программы?

S>Верификация делается за O(N), где N — размер программы

ссылочку на способы такой верификации не дашь? мне все это пока представляется как статический анализ, который нифига не выполним за O(N). причем, для native-кода он будет еще медленнее из-за отсутсвия высокоуровневых конструкций типа foreach, вместо которого пришлось бы разбирать обычный цикл и проверять его на выход за границы.
Re[13]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 08:13
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


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

S>Это твоё право. Но очень зря. Потому что обращая внимание на непонятные тебе вещи, ты бы смог сделать свои программы лучше.

Вряд ли. Во всяком случае следуя твоим советам — с точностью до наоборот

>Помнишь, мы обсуждали длины строк? Статистически 99% строк в природе оборудованы длиной от момента своего рождения.


У тебя. А у меня нет.

>Игнорирование этого факта приводит к чудовищно неэффективным алгоритмам на строках.


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


S>При этом аргумент в пользу игнорирования ровно один: "а вдруг там не будет длины".


Нет, аргумент другой — а нужна ли там длина ? От ответа все и зависит.

S>Я имею в виду, что я согласен на инфраструктуру, которая ловит 99% ошибок. Это в 100 раз сократит мне время отладки.


Каких ошибок ? IndexOutOfRange — для меня мелочи. AccessViolation — тоже. А вот FloatOverflow отловишь ? ZeroDivide ? И т.д.

Ты действительно отловишь даже не 99, а 100% ошибок, но только для 1% возможных ошибок.

PD>>Поэтому мне и не кажется серьезным такая забота об этих мелочах. Серьезные вещи вы все равно не улучшите, так как неформализуемо это (см. пример с плюсом-минусом, а это самый примитивный из тех, что я могу придумать)

S>Придумывание контрпримеров — это хорошо. Это правильно.

Поздравляю тебя с тем, что ты это понял


>Но начиная примерно с 90го года рулят алгоритмы, которые затачиваются не на максимальное быстродействие в самом хреновом случае, а на максимальное среднее быстродействие с учётом реальной статистики.


А при чем тут самый плохой случай ? Где я говорил, что оптимизирую именно под самый плохой ? Опять передергиваешь.



PD>>Я никак не считал, но приведи мне эти самые иммутабельные типы в нынешней библиотеке. String, DateTime... сколько еще покажешь общеупотребимых ?

S>Uri. Regex. Дело не в этом — ты же считаешь, что это связано с какими-то "ограничениями". Хотелось бы аргументов на эту тему.

А еще , пожалуйста , можешь ? Ну хоть 10% от общего числа классов иммутабельно ? Вот тебе и ответ насчет ограничений — они в том. что таких классов исчезающе мало. Константные типы редки по смыслу самому. А вот константные экземпляры — бога ради, любого типа. Создали однажды и менять не нужно — вот он и константный.

PD>>Нет. Я, кстати, отнюдь не С-шник по первому языку. И мне язык в данном случае безразличен, правда, ограничусь императивными.

S> Да не безразличен тебе язык. Ты мыслишь императивными

Совершенно верно. По причине императивности устройства, которое все это исполнять будет (процессор+память). Вот когда процессор будет функциональным, а память реализует физически абстракции некоего языка. тогда я изменю свой подход. А пока за всеми языками я вижу то, во что они превращаются при исполнении. И чем меньше там лишнего, тем лучше.

>причём построенными по одной и той же модели с минимальными синтаксическими различиями.


Тоже верно. По причине минимальных синтаксических различий (точнее, их отсутствия) у того, кто все это исполнять будет — см. чуть выше.
With best regards
Pavel Dvorkin
Re[13]: в добавление
От: Pavel Dvorkin Россия  
Дата: 25.06.09 08:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я имею в виду, что я согласен на инфраструктуру, которая ловит 99% ошибок. Это в 100 раз сократит мне время отладки.


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

InvalidImpementationException. Алгоритм правильный и хороший, но реализовал я его неправильно и из-за этого ничего не работает
InvalidAlgorithmException. Алгоритм мне казался правильным, но увы, в нем не все верно или вообще неверно, и из-за этого ничего не работает
TooSlowCodeException Алгоритм правильный, работает верно, но очень уж медленно, а это для меня все равно , что не работает вообще — все равно заказчик его не примет



Вот на это я 99% времени и трачу. А на выход индекса за пределы массива я трачу 0.1%. Пишите код так, чтобы не выходил, вот и все.
With best regards
Pavel Dvorkin
Re[23]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 08:35
Оценка:
Здравствуйте, thesz, Вы писали:

T>Но они могут быть и достаточно большими. Например, для одной моей программы требуется -fcontext-stack=100, то есть, она совершает не менее 100 шагов упрощения типов вычислениями над ними с семействами типов (type families). Проверка типов занимает заметное время порядка 30 секунд.

Я можно подробнее?
Нет ли там выкрутасов аля шаблонная метамагия в С++?
И не будет ли это все сильно проще при наличии зависимых типов?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 08:38
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тебе же тут уже объяснили — не работайте под админом. Кстати, как ты собираешься устроить эту самую эскалацию для процесса броузера, если он (под Вистой) запущен хоть и от админа, но без админских прав ? (т.е с юзеровскими правами) Это тоже очень интересно бы знать

Через переполнение буфера например.
Что думаешь в WinAPI ни одного нет?
И если ты так думаешь то на каком основании?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 08:39
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>В языке может вообще не быть переменных. Он может быть некоего описательного типа, при этом переменные генерируются компилятором/средой выполнения. Но они все равно есть.

Еще раз: при этом никакие переменные не генерируются. Ну, то есть, в частных случаях — да. Например, в дотнете есть понятие "locals", т.е. локальные переменные. И они таки да — генерируются компилятором (причём не обязательно каждой переменной исходного кода соответствует отдельный слот в таблице locals, и наоборот).
Но, к примеру, в x86 ассемблере никаких "переменных" нет. Есть регистры и стек; компилятор генерирует исключительно обращения к ним.

PD>Как большинство понимает — это мне сейчас не так важно. Напомню, речь шла о константных и неконстантных объектах. Сгенерировал ли их компилятор по некоему явному описанию или же завел их так, что я их и не вижу в своем коде — они все равно либо константны, либо нет. Проще говоря, эти блоки памяти будут изменяться или нет. Если будут — их нельзя в R/O память. Если не будут — можно. Все.

Это всё так же далеко от правильного понимания. Ты опять путаешь "константы" и "иммутабельные объекты".
Поясняю: даже если объект иммутабельный, в R/O память его положить нельзя. Ну, разве что ты собрался выделять по 4к на каждый экземпляр. Потому, что в отличие от константы, значение immutable объекта может не быть доступно на момент старта программы. И, в отличие от константы, иммутабельный объект не существует неограниченно долго.
С точки зрения аппаратуры, место, занятое иммутабельным объектом, всё же выступает в роли lvalue — в него сначала присваивают некоторое значение, потом сколько-то раз им пользуются, а потом повторно используют это же место под другие объекты (потому, что аппаратуры с неограниченным объемом storage еще не придумали).
Использование аппаратной защиты для обеспечения иммутабельности на реальной аппаратуре просадит производительность. А, главное, не даст никакого выигрыша даже на "идеальной" аппаратуре, где запрет записи делается бесплатно с гранулярностью до байта.

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

Я уже понял, что ты воспринимаешь ровно один уровень абстракции. Ни подняться выше, ни спуститься ниже ты не хочешь. Ок, это твой свободный выбор, добровольное самоограничение.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: в добавление
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 08:56
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>InvalidImpementationException. Алгоритм правильный и хороший, но реализовал я его неправильно и из-за этого ничего не работает

Ну, во многих случаях InvalidImplementation сводится к InconsistentImplementation. Это уже математически обнаружимая ошибка. Например, вычисление среднего не от всех переданных аргументов.

PD>InvalidAlgorithmException. Алгоритм мне казался правильным, но увы, в нем не все верно или вообще неверно, и из-за этого ничего не работает

Это да. Если вместо алгоритма вычисления среднего арифметического ты вычислил среднее геометрическое — никакая магия не спасёт.
PD>TooSlowCodeException Алгоритм правильный, работает верно, но очень уж медленно, а это для меня все равно , что не работает вообще — все равно заказчик его не примет
А вот это — тоже вполне себе разрешимая задачка. Если среда умеет выводить и проверять контракты на вычислительную сложность, то ты можешь очень быстро увидеть, где именно боттлнек, еще до запуска профайлера.
PD>Вот на это я 99% времени и трачу. А на выход индекса за пределы массива я трачу 0.1%. Пишите код так, чтобы не выходил, вот и все.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 09:04
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Не ожидал от тебя такого заявления.

V>Ты точно знаешь, о чем говоришь?
Да. А ты точно не знаешь что такое зависимые типы ибо в С++ их нет.
В С++ типы не могут зависит от данных полученных во время работы программы.

V>Не важно чем, если есть ср-ва прочитать/записать хотя бы байт из/в произвольного участка памяти, то вся безопасность и доказуемость сразу улетучивается.

ХА! Эти средства использует кодогенератор генерирующий код по верифицированной модели.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 09:07
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Все эти возможности доступны и сейчас в том же С++, однако не особо народ юзает. Не подскажешь, почему?

Ты хочешь сказать что для любой программы на С++ можно доказать что она нигде не проедется по памяти?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 09:14
Оценка:
Здравствуйте, swined, Вы писали:

S>кстати да, каким бы компактным не был верификатор, в нем могут быть ошибки. хардварная защита как-то понадежней будет.

А в хардварной защите ошибок быть не может?
Тем более что верификатор сам себя проверить может что снижает вероятность ошибки до нуля.
Можно даже написать 2 или более верификаторов каждый из которых будет проверять как себя так и всех остальных.
В этом случае ошибка вообще хрен проскочит.

S>ссылочку на способы такой верификации не дашь? мне все это пока представляется как статический анализ, который нифига не выполним за O(N).

У нас в бинарнике что?
Типизированный код.
И верификация сводится к банальной проверки того что все типы совпадают.
А это O(N).

S>причем, для native-кода он будет еще медленнее из-за отсутсвия высокоуровневых конструкций типа foreach, вместо которого пришлось бы разбирать обычный цикл и проверять его на выход за границы.

Так и не надо заниматься фигней и верифицировать нативный код.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 25.06.09 09:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Тем более что верификатор сам себя проверить может что снижает вероятность ошибки до нуля.


верификатор не проверит логику.

WH>У нас в бинарнике что?

WH>Типизированный код.

типизированный? в бинарнике? там же просто куча процессорных инструкций перекладывающих байты

WH>Так и не надо заниматься фигней и верифицировать нативный код.


а что еще с ним делать, если нет другого?
Re[19]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 09:34
Оценка:
Здравствуйте, swined, Вы писали:

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

Тут пожалуй нужно спросить у thesz но мне почему то кажется что на практике дело без программных верификаторов этих проверок не обходится...

S>дык оно же поймает ничтожно малую часть возможных проблем.

В случае с системой типов .NET да. А вот в случае с более умной системой типов поймает куда больше.
Давать эту ссылку мне уже надоело http://en.wikipedia.org/wiki/Dependent_type

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

Нативный? Никак. Те вообще никак.

S>или придется городить ms signed software, drm и прочую хрень созданную для того, чтобы у меня работало только три программы, две из которых — пасьянс?

Нет. Если все бинари будут представлять из себя верефицируемый промежуточный код то нет.
Достаточно чтобы бинарь верификацию прошол.

S>>Во-вторых, "высокоуровневые конструкции" к верификатору никакого отношения не имеют. Я, наверное, тебя удивлю, но инструкции foreach в MSIL нету. Сплошные conditional jump-ы.

S>однако перед генерацией IL'а они есть, чем сильно помогают компилятору.
Это ты сказал от полного незнания того как это все работает.

S>а толку? как ты будешь проверять те же массивы на границы?

Зависимые типы.

S>отделение nullable от not nullable только сократит количество ошибок, но не избавит от них полностью. что мне мешает иметь nullable string, который абсолютно легален в логике программы, и иногда считать его длину?

Отсутствие nullable string.
Вместо nullable будет что-то типа
variant Option[T]
{
| Some { value : T }
| None
}

И соответственно будет Option[String]. И длину у этого дела посчитать невозможно пока не достанешь строку из данного варианта.

S>а где бы почитать об этом?

Давать эту ссылку мне уже надоело http://en.wikipedia.org/wiki/Dependent_type
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 09:36
Оценка:
Здравствуйте, swined, Вы писали:

WH>>Тем более что верификатор сам себя проверить может что снижает вероятность ошибки до нуля.

S>верификатор не проверит логику.
Логика проверена системой типов.

S>типизированный? в бинарнике? там же просто куча процессорных инструкций перекладывающих байты

Ты на бинарники программ под .NET или жабу посмотри да.

WH>>Так и не надо заниматься фигней и верифицировать нативный код.

S>а что еще с ним делать, если нет другого?
Друго нет только в твоем воображении.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 09:40
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

Хотел написать большой развернутый ответ но понял что бесполезно.
Ибо объяснять что либо человеку который не может выйти за приделы одного уровня абстракции совершенно бесполезно.
На этом разговор с тобой закончил.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 09:47
Оценка:
Здравствуйте, swined, Вы писали:
S>так что же будет в этом случае?
Мы просто выпустим к нему апдейт

S>так что же тогда предлагается верифицировать? как я смогу использовать бинарь слитый из интернетов с непонятных варез-сайтов? или придется городить ms signed software, drm и прочую хрень созданную для того, чтобы у меня работало только три программы, две из которых — пасьянс?

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

S>однако перед генерацией IL'а они есть, чем сильно помогают компилятору.

А причём тут компилятор? Он верификацией не занимается. Его работа — всего лишь породить корректный IL.

S>а толку? как ты будешь проверять те же массивы на границы?

RTFM.

S>отделение nullable от not nullable только сократит количество ошибок, но не избавит от них полностью.

Это полностью избавит от ошибок NullReferenceException.
S>что мне мешает иметь nullable string, который абсолютно легален в логике программы, и иногда считать его длину?
То, что null стринг не имеет длины по определению. В хорошем языке ты не сможешь написать просто int HalfLength(string a) {return a.Length}
Ты будешь обязан либо писать
int HalfLength(string a)
{
    if (a != null)
    {
        return a.length;
    }
}

(и компилятор трахнет тебя за not all paths return a value), либо писать
int HalfLength([NotNull] string a)
{
    return a.length;
}

И тогда компилятор будет трахать того, кто пытается вызывать HalfLength на нуллабл-строке.
S>а где бы почитать об этом?
Ну, в этом форуме много про это пишут.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 09:47
Оценка:
Здравствуйте, swined, Вы писали:
S>типизированный? в бинарнике? там же просто куча процессорных инструкций перекладывающих байты
Поэтому у бинарников, где "просто куча процессорных инструкций перекладывающих байты" и нет будущего.
S>а что еще с ним делать, если нет другого?
Придумывать другой. В сингуларити, например, нет никакого нативного кода, кроме 1 килобайта в недрах ядра. Для неё "слить из интернета" можно только промежуточное представление.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 25.06.09 09:48
Оценка:
T>>Но они могут быть и достаточно большими. Например, для одной моей программы требуется -fcontext-stack=100, то есть, она совершает не менее 100 шагов упрощения типов вычислениями над ними с семействами типов (type families). Проверка типов занимает заметное время порядка 30 секунд.
WH>Я можно подробнее?
WH>Нет ли там выкрутасов аля шаблонная метамагия в С++?

Есть.

WH>И не будет ли это все сильно проще при наличии зависимых типов?


Шаблоны и есть зависимые типы.

Поэтому заметно проще не будет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[17]: Есть ли будущее у Native Code?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 25.06.09 09:51
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Пример иллюстрировал тот факт, что ты привык применять определённые средства, совершенно неудобные для твоей задачи. Но ты привык это делать настолько хорошо, что теперь тебе сложно воспринять более простые вещи. Верификация кода не имеет к твоим проблемам никакого отношения. Да, наверное, MSIL не лучший язык для записи твоих задач. Но и ассемблер — тоже. По-хорошему, это должен быть DSL, который очень компактно и понятно отражает суть алгоритма. А упаковка алгоритма в битхакинг — дело компилятора.


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

EYE_CAR
  ..
  .*.

EYE_2x3
  .*.
  .*.


Соответственно по этому исходники генерируется функция

  int AnalyzeEye(const Bitgoban* eye_mask, Bitgoban* critical_points)
  {
  ...
  }


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

По поводу использования DSL для конкретной задачи написания шахматного движка... Как по мне, для этой задачи лучше всего подходит C. И так считают разработчики многих сильнейших движков. Разработка специального DSL для записи алгоритмов такого рода будет достаточно трудоемкой задачей. К тому же производительность достаточно важна, так что полностью абстрагироваться от низкого уровня вряд ли получится. И задача разработки такого DSL получится в чем-то даже сложнее исходной задачи. Плюс весь комплекс сопутствующих инструментов: отладка, профайлер и т. п.
Re[25]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 09:57
Оценка:
Здравствуйте, thesz, Вы писали:

T>Шаблоны и есть зависимые типы.

Я бы не стал называть шаблоны С++ зависимыми типами.
Ибо как ни крути, а типы в С++ не могут зависеть от значений полученных по время исполнения программы.

T>Поэтому заметно проще не будет.

А можно посмотреть на код? Если не секрет конечно. Можно по почте.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 25.06.09 10:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Нативный? Никак. Те вообще никак.


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

WH>Это ты сказал от полного незнания того как это все работает.


тут считают подругому. аналогичные оптимизации делаются и для foreach чуть более очевидным образом.

WH>И соответственно будет Option[String]. И длину у этого дела посчитать невозможно пока не достанешь строку из данного варианта.


либо компилятор заенфорсит меня написать проверку перед вызовом (он и сейчас так может), либо получается та же фигня Option[String].getLength(), кидающий NullReferenceException, когда в нем нет ненулевой строки.
Re[20]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 25.06.09 10:09
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Мы просто выпустим к нему апдейт


но будет поздно

S>Предлагается выкинуть понятие "бинаря, слитого с непонятных варез-сайтов". Сливать можно будет только verifyable код, очевидно.


S>А причём тут компилятор? Он верификацией не занимается. Его работа — всего лишь породить корректный IL.


он знает о коде гораздо больше верификатора, этим можно было бы воспользоваться.
Re[20]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 25.06.09 10:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Логика проверена системой типов.


возможно зависимые типы действительно так хороши, но разве можно ими бизнес-логику проверить полностью?

WH>Ты на бинарники программ под .NET или жабу посмотри да.


это малая часть всех запускаемых бинарников.

WH>Друго нет только в твоем воображении.


мифические ненативные программы с верифицируемым байткодом это хорошо, но хочется, чтобы работали и другие, уже существующие. ты же не предлагаешь все переписать с нуля на жаве и дотнете?
Re[20]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 25.06.09 10:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Поэтому у бинарников, где "просто куча процессорных инструкций перекладывающих байты" и нет будущего.


но пока у них есть настоящее и с этим ничего не сделать.

S>Придумывать другой. В сингуларити, например, нет никакого нативного кода, кроме 1 килобайта в недрах ядра. Для неё "слить из интернета" можно только промежуточное представление.


надеюсь, что когда эта система получит хоть какое-то распространение, под нее будет достаточно программ.
Re[15]: в добавление
От: Pavel Dvorkin Россия  
Дата: 25.06.09 10:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>InvalidImpementationException. Алгоритм правильный и хороший, но реализовал я его неправильно и из-за этого ничего не работает

S>Ну, во многих случаях InvalidImplementation сводится к InconsistentImplementation. Это уже математически обнаружимая ошибка. Например, вычисление среднего не от всех переданных аргументов.

Мне бы твои проблемы В том-то и дело, что на основании простейших примеров вы беретесь делать выводы для сложных алгоритмов. А если я неправильно реализовал потому что и сам не понимаю, как тут правильно из-за сложности алгоритма, превышающншл (допустим) мои способности ? Математически обнаружимая... Да, в твоем примере это сойдет. На тебе иной пример — ядро Windows. Спроектируй его в основных чертах и попробуй потом математически обнаружить, а мы посмотрим

PD>>InvalidAlgorithmException. Алгоритм мне казался правильным, но увы, в нем не все верно или вообще неверно, и из-за этого ничего не работает

S>Это да. Если вместо алгоритма вычисления среднего арифметического ты вычислил среднее геометрическое — никакая магия не спасёт.

Если бы так просто было...

PD>>TooSlowCodeException Алгоритм правильный, работает верно, но очень уж медленно, а это для меня все равно , что не работает вообще — все равно заказчик его не примет

S>А вот это — тоже вполне себе разрешимая задачка. Если среда умеет выводить и проверять контракты на вычислительную сложность, то ты можешь очень быстро увидеть, где именно боттлнек, еще до запуска профайлера.

Что я слышу !!! Без профайлера, оказывается, можно. Правда, если среда умеет... А если я сам умею (я могу оценить алгоритм на выч.сложность или уж совсем никак не могу ? — тогда что ? Вроде кто-то утверждал, что надо именно только с профайлером и никак иначе
With best regards
Pavel Dvorkin
Re[21]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 10:39
Оценка:
Здравствуйте, swined, Вы писали:
S>он знает о коде гораздо больше верификатора, этим можно было бы воспользоваться.
Нет. Это создаст уязвимость среды исполнения.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 10:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Тебе же тут уже объяснили — не работайте под админом. Кстати, как ты собираешься устроить эту самую эскалацию для процесса броузера, если он (под Вистой) запущен хоть и от админа, но без админских прав ? (т.е с юзеровскими правами) Это тоже очень интересно бы знать

WH>Через переполнение буфера например.

А поподробнее можно ? Вот передаем некоей Win API не тот буфер, не того размера. Насильно передаем. Объясни, что же будет.
With best regards
Pavel Dvorkin
Re[26]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 25.06.09 10:59
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


T>>Шаблоны и есть зависимые типы.

WH>Я бы не стал называть шаблоны С++ зависимыми типами.
WH>Ибо как ни крути, а типы в С++ не могут зависеть от значений полученных по время исполнения программы.

Это зависит.

В Cayenne, Agda и тп нет оператора casetype. Поэтому ты не можешь типы в Cayenne, Agda и тп не могут зависеть от значений времени выполнения.

А вот связать значения из типов со значениями времени выполнения путём доказательств возможно. И в C++ тоже (хотя и не очень уверен).

T>>Поэтому заметно проще не будет.

WH>А можно посмотреть на код? Если не секрет конечно. Можно по почте.

Пожалуй, показать не смогу.

Части я тут выкладывал (чуть выше было), это всё, что я могу показать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 11:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>Хотел написать большой развернутый ответ но понял что бесполезно.

WH>Ибо объяснять что либо человеку который не может выйти за приделы одного уровня абстракции совершенно бесполезно.
WH>На этом разговор с тобой закончил.

Да, так лучше.
With best regards
Pavel Dvorkin
Re[22]: Есть ли будущее у Native Code?
От: swined Россия  
Дата: 25.06.09 11:10
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>>он знает о коде гораздо больше верификатора, этим можно было бы воспользоваться.
S>Нет. Это создаст уязвимость среды исполнения.

как вариант — поддержка всех этих конструкций на уровне байткода. их не так много, а выигрыш должен быть заметным.
Re[17]: в добавление
От: Pavel Dvorkin Россия  
Дата: 25.06.09 11:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>Мне бы твои проблемы

S>Я думаю, что от моих проблем ты загнёшся.

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

S>Какая разница, по какой причине ты реализовал "неправильно"? Если "неправильно" — это неконсистентно, то всё обнаружится статической проверкой.


Не смеши.

S>А про "неправильно" в смысле "не решает нужную задачу" я тебе уже ответил: это тебе никакая математика не посчитает.


PD>>Математически обнаружимая... Да, в твоем примере это сойдет. На тебе иной пример — ядро Windows. Спроектируй его в основных чертах и попробуй потом математически обнаружить, а мы посмотрим

S>Ну не странно ли, что для всяческих ОС ядер таки доказывают различные свойства при помощи различных theorem prover-ов?

Угу. А потом тестируют ее сначала у себя (альфа), потом тестируют всем миром бету, потом тестируют всем миром RC, потом тестируют всем миром релиз и пишут хотфиксы и SP. Из чего ясно, какова цена всем этим theorem prover-ов.

S>>>А вот это — тоже вполне себе разрешимая задачка. Если среда умеет выводить и проверять контракты на вычислительную сложность, то ты можешь очень быстро увидеть, где именно боттлнек, еще до запуска профайлера.

PD>>Что я слышу !!! Без профайлера, оказывается, можно. Правда, если среда умеет... А если я сам умею (я могу оценить алгоритм на выч.сложность или уж совсем никак не могу ? — тогда что ?
S>Ну, так ты, наверное, и по регистрам можешь переменные вручную распределить. Но зачем, если компилятор это делает за тебя?

Могу. Не буду, пока не понадобится. Но при чем здесь это ? Ты же так меня за профайлер агитировал и вдруг сам себе противоречишь. Может, все же объяснишь это противоречие ?

PD>>Вроде кто-то утверждал, что надо именно только с профайлером и никак иначе

S>Есть некоторые нюансы.

Ах, все же есть нюансы. Явный прогресс. Еще некоторое время, и ты начнешь понимать, что не все с профайлером делается.


>В частности, автоматически выведенным оценкам производительности я доверяю как-то больше, чем твоим.


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

>Из-за сложности алгоритма, превышающншл (допустим) твои способности.


Да, это возможно. Но и тут есть всякие методики, начиная с банальностей (оптимизируйте внутренний цикл), кончая совсем не тривиальными (учет когерентности кэша, выравнивания данных и т.п. ). Но вообще да, я не бог, могу и ошибиться. Профайлер поможет мне эти ошибки найти — я его роль вовсе не отрицал. Но если я априорно заложил o(n^6) там где надо o(n^3) — он не поможет. Впрочем, я тебе это уже не раз говорил.

S>А в общем, из оценки сложности оценить где будет реальный боттлнек далеко не всегда возможно.


Совершенно верно. Не всегда. Но из этого отнюдь не следует, что всегда невозможно.

S>Потому, что равномерных распределений входных данных в природе не бывает. Это ты всегда начинаешь плеваться, когда тебя спрашивают "нет ли у исходной матрицы каких-либо особенностей, благодаря которым её обработку можно было бы ускорить". А умные люди строят, к примеру, оптимизаторы SQL запросов на эмпирическом знании о том, что, к примеру, частоты реальных данных подчиняются распределению Зипфа.


Так, я уже не в состоянии следить за растеканием твоих мыслей по древу. Приписанное мне бог знает из каких соображений намерение плеваться по поводу особенностей матрицы (интересно, где я плевался на сей счет, ссылочку не дашь ?) ты начинаешь опрвергать какими-то примерами из SQL. Давай уж одно из двух — либо я буду плеваться на SQL, либо приводи примеры из матриц.
With best regards
Pavel Dvorkin
Re[23]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 11:30
Оценка:
Здравствуйте, swined, Вы писали:
S>как вариант — поддержка всех этих конструкций на уровне байткода. их не так много, а выигрыш должен быть заметным.
За счёт чего? Выигрыш может случиться только за счёт отказа от других инструкций, которые теперь не нужно будет верифицировать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 11:30
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

S>>Но, к примеру, в x86 ассемблере никаких "переменных" нет. Есть регистры и стек; компилятор генерирует исключительно обращения к ним.


PD>В школу! В первый класс!!!

Да, по запарке написал "стек" вместо памяти. В том смысле, что сам по себе стек ничего нового к модели "регистры+память" не добавляет, это просто CISC-шорткат для инструкций косвенной адресации.

PD>Обоснуй. Кто мне мешает там кучу завести ?

Флаг R/O, надо полагать.
PD>И не надо. Его туда (в R/O) должен помещать специальный конструктор или new или вместе
А специальный конструктор будет Волей Божьей работать, или как?
PD>immutable Type a = new immutable Type(...);
Ага. Надо полагать, это будет разворачиваться в псевдокод "снять защиту со страницы; положить данные; вернуть защиту на страницу".
В середине этого все остальные объекты в пределах этой же страницы будут точно так же изменчивы. Упс, дыра получилась.
S>>Использование аппаратной защиты для обеспечения иммутабельности на реальной аппаратуре просадит производительность.
PD>Нет. Я уже тысячу раз объяснял — проверки записи в процессоре аппаратны и делаются всегда при записи.
Это-то да, но стоимость переключения флагов страницы при вызовах конструктора/деструктора куда денется?
PD>А зачем тебе доступ с этой гранулярностью ? Никаких проблем и сейчас нет.
Я показал проблему выше. Может быть, у неё есть какое-то очевидное решение?

PD>А хочешь, я тебе секрет открою? В С++ есть иммутабельный объект. Защищается именно механизмом страничной защиты. Догадался, о чем речь идет ?

Надо полагать, ты про нулевой адрес.

PD>Мне уровни абстракции нужны в этих рассуждениях , как корове седло. Оставь их для других случаев, там я могу их обсуждать. А здесь я одно утверждаю — что ни делайте, какие средства ни придумывайте, но пока аппаратура нынешняя. все равно вы мимо этого слоя не пройдете. Вот и все.

С тем же успехом можно утверждать, что и мимо микрокода пройти нельзя. Тем не менее, ты совершенно спокойно его игнорируешь в своих рассуждениях, несмотря на его принудительное наличие между тобой и кремнием.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 11:47
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А поподробнее можно ? Вот передаем некоей Win API не тот буфер, не того размера. Насильно передаем. Объясни, что же будет.
Странно, что такие простые вещи нужно объяснять. Ищем уязвимость в существующем софте (как правило, она состоит именно в переполнении буфера), при помощи чего вызываем исполнение злонамеренного кода в контексте доверенного процесса.
Напрямую лезть в нулевое кольцо этому коду не надо — ему достаточно инсталлировать в систему драйвер, оставаясь в рамках третьего кольца. После ближайшего рестарта (или даже без него) система самостоятельно запустит нужный код в нулевом кольце, рядом со всеми остальными драйверами.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 12:04
Оценка:
Здравствуйте, swined, Вы писали:
S>большинство циклов — foreach. проход по коллекциям, массивам итд. верифицировать такое в разы проще, чем ковырять то, во что оно в итоге развернется. ну и оставшийся один из тысячи обычный цикл, где по логике программы действительно надо перебрать все индексы, будет верифицирован как обычный цикл.
Ты, по-моему, чего-то не понимаешь. Совершенно неважно, сколько там foreach. Верификация того, "во что оно в итоге развернётся" уже занимает O(N). Что ты собрался ускорять?
Устранять проверки границ в случае, если foreach шарашит по массиву?

Ну так этим занимается JIT, который работает уже после верификатора.

Хочешь математически доказать, что обращений за границы не будет вообще никогда-никогда, а не только в случае for (var i=0; i< a.Length; i++)?
Для зависимых типов это возможно — но выигрыш в производительности будет недостаточно большим.
Фишка в том, что для успешного вывода типов нужна "хорошая" алгебра, которая была бы замкнута относительно заметного количества операций.
В частности, с Null/Notnull это так.
Легко ввести тип "чётное число" по тем же причинам.
А вот ввести тип "валидный аргумент операции myArray[i]" — тяжело. Потому, что любая арифметика выводит значение за пределы этого типа.
И тебе, соответственно, придётся делать проверки при каждой операции.
То есть index++, index+=2, index*=2 и так далее будут бросать OutOfRangeException.
Стоимость этой лишней проверки будет пренебрежимой только если удастся объединить её с проверкой условия выхода из цикла, и если обращений к массиву внутри цикла достаточно много.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 25.06.09 12:41
Оценка:
Здравствуйте, swined, Вы писали:

S>большинство циклов — foreach. проход по коллекциям, массивам итд. верифицировать такое в разы проще, чем ковырять то, во что оно в итоге развернется. ну и оставшийся один из тысячи обычный цикл, где по логике программы действительно надо перебрать все индексы, будет верифицирован как обычный цикл.

Вопиющая безграмотность.
Пожалуйста больше не рассуждай на тему верификации.
Ссылки для самообразования я уже не раз давал.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 13:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


S>>>Но, к примеру, в x86 ассемблере никаких "переменных" нет. Есть регистры и стек; компилятор генерирует исключительно обращения к ним.


PD>>В школу! В первый класс!!!

S>Да, по запарке написал "стек" вместо памяти. В том смысле, что сам по себе стек ничего нового к модели "регистры+память" не добавляет, это просто CISC-шорткат для инструкций косвенной адресации.

То-то, по утверждению Нортона, того, кто исключил стек из архитектуры IBM-360, "сослали во внутрифирменный аналог Сибири". Подумай, добавляет он или нет.

PD>>Обоснуй. Кто мне мешает там кучу завести ?

S>Флаг R/O, надо полагать.

Не помешает. Его снимут, запишут и поставят. Тут другие проблемы есть — во время этой операции страница не R/O. Да, тут не очевидно, но решение ИМХО найти можно. Тем более в вашей .Net. Она же не может туда обратиться по ошибке, она же не может куда попало обращаться по определению. Что же касается C++ — да, возможны проблемы, но это те же проблемы, что и сейчас. И сейчас некорректный указатель может все испортить, и тут тоже сможет.

PD>>И не надо. Его туда (в R/O) должен помещать специальный конструктор или new или вместе

S>А специальный конструктор будет Волей Божьей работать, или как?

Нет, на базе команд процессора x86 или иного

PD>>immutable Type a = new immutable Type(...);

S>Ага. Надо полагать, это будет разворачиваться в псевдокод "снять защиту со страницы; положить данные; вернуть защиту на страницу".
S>В середине этого все остальные объекты в пределах этой же страницы будут точно так же изменчивы. Упс, дыра получилась.

См. выше. Да, это некоторая проблема, я ее вижу. Но не нерешаемая.

S>>>Использование аппаратной защиты для обеспечения иммутабельности на реальной аппаратуре просадит производительность.

PD>>Нет. Я уже тысячу раз объяснял — проверки записи в процессоре аппаратны и делаются всегда при записи.
S>Это-то да, но стоимость переключения флагов страницы при вызовах конструктора/деструктора куда денется?

См. мой тест где-то в прошлой дискуссии, я проверял работу VirtualProtect, получилось примерно миллион в секунду. Да, вызов ядра обычно медленный, но не в данном случае. Тут не задействуется драйвер, просто-напросто в PTE изменяется один (или 2 в x64) бит(а).


PD>>А хочешь, я тебе секрет открою? В С++ есть иммутабельный объект. Защищается именно механизмом страничной защиты. Догадался, о чем речь идет ?

S>Надо полагать, ты про нулевой адрес.

Нет. Этот иммутабельный объект — секция кода . Что не мешает ее менять, но тогда включится автоматом write on copy механизм.

PD>>Мне уровни абстракции нужны в этих рассуждениях , как корове седло. Оставь их для других случаев, там я могу их обсуждать. А здесь я одно утверждаю — что ни делайте, какие средства ни придумывайте, но пока аппаратура нынешняя. все равно вы мимо этого слоя не пройдете. Вот и все.

S>С тем же успехом можно утверждать, что и мимо микрокода пройти нельзя. Тем не менее, ты совершенно спокойно его игнорируешь в своих рассуждениях, несмотря на его принудительное наличие между тобой и кремнием.

Все, что ниже ассемблера — не мое дело, ибо мне не подвластно. Для схемотехника — можно, но я им не являюсь.
With best regards
Pavel Dvorkin
Re[28]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 25.06.09 13:28
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


T>>В Cayenne, Agda и тп нет оператора casetype. Поэтому ты не можешь типы в Cayenne, Agda и тп не могут зависеть от значений времени выполнения.

WH>Тут я немного криво выразился.

Я тоже не подкачал, надо отметить.

T>>И в C++ тоже (хотя и не очень уверен).

WH>Я в свое время изучил все возможные метаизвращения на С++ но не вижу никакой возможности сделать что-то подобное тому что может агда.
WH>На С++ не сделать ничего типа:
WH>
WH>mult : ∀i , j , k : Nat ⇒ Matrix i j → Matrix j k → Matrix i k
WH>

WH>При условии что i, j и k не известны на этапе компиляции.

Хорошо, C++ вычеркиваем.

В моей программе как раз что-то наподобие mult. Правда, i,j и k имеют значения из множества типов, составляемых из data Z и data S n.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 13:46
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>То-то, по утверждению Нортона, того, кто исключил стек из архитектуры IBM-360, "сослали во внутрифирменный аналог Сибири". Подумай, добавляет он или нет.

Не добавляет.

PD>Не помешает. Его снимут, запишут и поставят. Тут другие проблемы есть — во время этой операции страница не R/O.

Именно об этом я и писал.

PD>Да, тут не очевидно, но решение ИМХО найти можно. Тем более в вашей .Net. Она же не может туда обратиться по ошибке, она же не может куда попало обращаться по определению.


Правильно. А зачем тогда взводить R/O, если мы по определению не можем обращаться куда попало?

PD>Что же касается C++ — да, возможны проблемы, но это те же проблемы, что и сейчас. И сейчас некорректный указатель может все испортить, и тут тоже сможет.

Совершенно верно. Именно поэтому аппаратная защита — сакс. Там, где она поможет, она не нужна. А там, где нужна — она не поможет.

PD>См. выше. Да, это некоторая проблема, я ее вижу. Но не нерешаемая.

Решение — в студию. Хотя бы набросок.
PD>См. мой тест где-то в прошлой дискуссии, я проверял работу VirtualProtect, получилось примерно миллион в секунду. Да, вызов ядра обычно медленный, но не в данном случае. Тут не задействуется драйвер, просто-напросто в PTE изменяется один (или 2 в x64) бит(а).
Ок. А скорость вызова конструктора в дотнет не мерил? Каковы будут накладные расходы при вызове VirtualProtect на каждый чих? Хоть при "деструкторе" и не надо будет её вызывать отдельно, но быстродействие кучи всё же снизится.

PD>Нет. Этот иммутабельный объект — секция кода . Что не мешает ее менять, но тогда включится автоматом write on copy механизм.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 25.06.09 14:58
Оценка:
S>Правильно. А зачем тогда взводить R/O, если мы по определению не можем обращаться куда попало?

Теория это одно, практика — с кратковременными сбоями аппаратуры, — это другое.

PD>>Что же касается C++ — да, возможны проблемы, но это те же проблемы, что и сейчас. И сейчас некорректный указатель может все испортить, и тут тоже сможет.

S>Совершенно верно. Именно поэтому аппаратная защита — сакс. Там, где она поможет, она не нужна. А там, где нужна — она не поможет.

Чтобы не повторяться: http://rsdn.ru/forum/philosophy/3440056.1.aspx
Автор: thesz
Дата: 23.06.09
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 03:02
Оценка:
Здравствуйте, thesz, Вы писали:

T>Теория это одно, практика — с кратковременными сбоями аппаратуры, — это другое.

Не очень понял про кратковременные сбои.

T>Чтобы не повторяться: http://rsdn.ru/forum/philosophy/3440056.1.aspx
Автор: thesz
Дата: 23.06.09

Не понял, какое отношение кэширование имеет к аппратной изоляции.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 05:01
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если в существующем софте есть ошибка, то все возможно. Но по постингу WolfHound можно понять так, что достаточно переполнить буфер , и мы попадем в страницы, находящиеся под контролем системы.
Нет. По постингу WolfHound понятно, что переполнение буфера — основная уязвимость, через которую происходит эскалация привилегий.
PD>А причина банальная — он не вполне понимает отличие виртуальной памяти от физической, он считает, что если выйти за пределы страницы, то мы попадем на соседнюю страницу физической памяти, которая может принадлежать системе
Очень сомневаюсь, что WolfHound так считает. И уж тем более, что он незнаком с архитектурой памяти на x86. Не надо заведомо принимать своих собеседников за идиотов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 05:09
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Очень сомневаюсь, что WolfHound так считает. И уж тем более, что он незнаком с архитектурой памяти на x86. Не надо заведомо принимать своих собеседников за идиотов.


За идиота я никого не принимаю, но судя по его дискуссии со мной в последние дни, он элементарно не понимает некоторые базовые принципы.
With best regards
Pavel Dvorkin
Re[23]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 05:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>Опять двойка по ассемблеру. Подумай, не может ли состояние стека измениться вообще без выполнения каких бы то ни было команд

S>Конечно же может. Но к модели "память/регистры" это по-прежнему ничего не добавляет.

К модели не добавляет. А вот к утверждению "это просто CISC-шорткат для инструкций косвенной адресации" еще как добавляет.

PD>>В общем, все что я сказал про изменение атрибутов страницы с R/O на R/W и обратно, полностью отменяется. Не надо атрибуты вообще менять, никогда. Никаких вызовов VirtualProtect. Страница должна всегда находиться в R/O состоянии. Так что все функции, которые попытаются изменить объект, гарантированно провалятся.


PD>>Остается маленький вопрос — а как же конструктор-то сможет в таком случае объект создать или операция newconst его разместить ? Решение чрезвычайно простое и элегантное. Конструктор и newconst (и только они!, ну еще, если надо, деструктор и deleteconst )будут работать с этой страницей по другому виртуальному адресу, с атрибутами R/W. При этом операция newconst будет возвращать R/O адрес в качестве адреса этого объекта, поэтому все функции будут работать с ним по R/O. А конструктор будет преобразовывать R/O адрес в R/W адрес и работать без всяких проблем. Все!!!

S>Осталось только гарантировать, что никто другой не станет обращаться к этим R/W страницам.

В .Net вы гарантируете, что никто без unsafe не сможет вообще никуда в неположенное место обращаться. Так что уж позаботьтесь о том, чтобы только реализация константных конструкторов могла туда обращаться. В конце концов этих самих адресов я в .Net вообще не вижу. они там внутри где-то. Ну и манипулируйте ими корректно.
Ну а в С++, конечно, никто такой гарантии не даст, но это обычная проблема — никто же не даст гарантии, что кто-то просто левым способом не испортит вполне обычную переменную.

PD>>В C# куча нефрагментирована, поэтому delta будет абсолютной константой. В Win32 если делать эту кучу так же, как и существующие, куча будет фрагментированной, поэтому вместо простого прибавления delta придется устроить чуть-чуть более сложный механизм (список из этих delta для отдельных фрагментов кучи)


PD>>Константный конструктор может ничем не отличаться от обычного. Впрочем, лучше если он проверит, не делается ли при конструировании константы попытки записать в нее указатели на другие неконстантные объекты.

S>Толково придумано. Я бы не допёр. (с).

PD>>Плата за решение.


PD>>1. Дополнительный PTE на каждую страницу. Это 4(8) байт на 4096 байт, то есть 0.1-0.2%.

PD>>2. Сокращается доступный размер адресного пространства. В пределе, если все 2 GB юзеровского пространства будут заняты этой константной кучей, мы будем иметь реально только 1GB. Но это уж слишком нереальная ситуация, в нормальной практике дополнительный расход будет несколько процентов. А уж в Win64 это вообще не будет иметь никакого значения — там сколько ни бери, все равно останется море.
PD>>3. Дополнительные расходы по времени — одна операция сложения
S>Ок. А теперь давай посчитаем выгоды, и сравним их с программно-immutable объектами.
S>Ну и попробуем понять, чем же это всё таки отличается от immutable-типов. Заметь, что ты не собираешься менять статус объекта в течение всего времени его жизни — он рождается константным и остаётся константным. Такие свойства как раз характерны для типов.

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

S>Теперь возьмем два объекта одного класса (в терминах С++), которые отличаются только тем, как распределены — один при помощи твоей злой магии, другой нормальным образом.

S>Чем они отличаются в программе? Тем, что на одном из них вызов части методов будет гарантированно вызывать AV — как у тебя в setx.

Совершенно верно. Он неизменяем.

S>Наверное, лучше было бы сделать так, чтобы компилятор не давал делать такие вызовы, не так ли? Зачем компилировать заведомо некорректную программу?


Ну мы опять за то же. Нет, не лучше. Я тебе уже говорил — ставя иммутабельность на тип, ты подвергаешься очень серьезным ограничениям. В реальной жизни нужно иметь и переменные этого типа и константы. Со строками у вас так и получилось — string для констант, StringBiulder для переменных. Для строк это сойдет. А для других классов — нет. Вот хочу я неизменяемый ArrayList , например. То есть хочу я следующее — однажды его сконструировать из какого-то источника и никогда больше не менять. И чтобы это сделать на иммутабельных типах, тебе придется еще один класс ImmutableArrayList соорудить (ну как наследника хоть, что ли). Вас и за пару string-StringBuilder то и дело покусывают, а уж если вы все классы начнете дублировать — просто смеяться будут. А я только добавлю константный конструктор и операцию newconst (впрочем, она не к классу вообще относится), и все, но изменить его не удастся. А в конечном счете одно мне нужно — гарантировать, что он не испортится

Кстати, сейчас подумал. В С++ операция new и конструктор — это, в общем, две независимые вещи. Но в C# это по существу тандем, так что если делается newconst Type(...), то среда, распознав, что создается константа, может автоматом заставить конструктор проверять, не делается ли попыток в нем записать ссылку на неконстантный объект ( а это очень просто, как ты понимаешь — по значению адреса). Так что, возможно, даже не понадобится писать специальный константный конструктор. Но это надо додумывать как следует, гарантии, что это утверждение корректно, я не дам.


S>Ок, мы, в принципе, можем попробовать описать эту абстракцию в С++ при помощи механики const, хотя я не уверен, что оператор new имеет право возвращать такой указатель. Но это уже, в некотором смысле, дело техники.


Ну естественно, я не мог написать это на настоящем С++. Мне не годится new, даже если я ее перекрою, так как не могу же я ее двумя способами перекрыть . Мне нужна для этого модификация языка и введение операции newconst


>По крайней мере, у нас "забесплатно" будет два подтипа для каждого класса — один const, другой mutable. У одного из них часть методов запрещены.


S>Но это нам по-прежнему ничего не даст. Как я уже объяснял, правила совместимости типов в С++ реализованы крайне неудачно.


Так, стоп. Я не намерен обсуждать сейчас, что хорошо в С++ и что нет. Я предложил идею создания и размещения константых объектов, она, как ты вполне видишь, от языка не зависит, так как реализована на чисто Win API. Окружи то, что я написал, соответствующим кодом хоть на .Net, хоть на чем угодно еще и используй
With best regards
Pavel Dvorkin
Re[24]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 05:56
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

S>>Ну и попробуем понять, чем же это всё таки отличается от immutable-типов. Заметь, что ты не собираешься менять статус объекта в течение всего времени его жизни — он рождается константным и остаётся константным. Такие свойства как раз характерны для типов.


PD>Да, конечно. Собственно говоря, имеем 2 одинаково устроенные кучи — для констант и переменных. Перенесение из одной в другую — только через полное клонирование.


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

HeapManager.SetMutable();
// теперь меняй их как хочешь
HeapManager.SetImMutable();
// все, они опять закрыты

А может, и не бесполезная. В .Net куча одна, а в Win32 их много можно создать. Ну вот и создадим кучу констант, которые, если быть честным, не то чтобы уж совсем константы, но 99% времени должны быть неизменяемыми, а изменяться могут только в строго определенных местах, в особых местах, когда, скажем, замораживаются все остальные потоки. А в другой такой куче то же самое, но места другие
With best regards
Pavel Dvorkin
Re[24]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 06:26
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Опять двойка по ассемблеру. Подумай, не может ли состояние стека измениться вообще без выполнения каких бы то ни было команд
S>>Конечно же может. Но к модели "память/регистры" это по-прежнему ничего не добавляет.
PD>К модели не добавляет. А вот к утверждению "это просто CISC-шорткат для инструкций косвенной адресации" еще как добавляет.
И что именно оно добавляет к этому утверждению? Что там такого происходит со стеком, что невыразимо в терминах inc ESP и mov? Ты блин как прапорщик: "не из дерева, а из того же материала". Я советую тебе научиться отличать знание от понимания.

PD>>>В общем, все что я сказал про изменение атрибутов страницы с R/O на R/W и обратно, полностью отменяется. Не надо атрибуты вообще менять, никогда. Никаких вызовов VirtualProtect. Страница должна всегда находиться в R/O состоянии. Так что все функции, которые попытаются изменить объект, гарантированно провалятся.


PD>>>Остается маленький вопрос — а как же конструктор-то сможет в таком случае объект создать или операция newconst его разместить ? Решение чрезвычайно простое и элегантное. Конструктор и newconst (и только они!, ну еще, если надо, деструктор и deleteconst )будут работать с этой страницей по другому виртуальному адресу, с атрибутами R/W. При этом операция newconst будет возвращать R/O адрес в качестве адреса этого объекта, поэтому все функции будут работать с ним по R/O. А конструктор будет преобразовывать R/O адрес в R/W адрес и работать без всяких проблем. Все!!!

S>>Осталось только гарантировать, что никто другой не станет обращаться к этим R/W страницам.

PD>В .Net вы гарантируете, что никто без unsafe не сможет вообще никуда в неположенное место обращаться. Так что уж позаботьтесь о том, чтобы только реализация константных конструкторов могла туда обращаться. В конце концов этих самих адресов я в .Net вообще не вижу. они там внутри где-то. Ну и манипулируйте ими корректно.

Еще раз, медленно повторяю: поскольку мы уже гарантировали отсутствие обращений в неположенные места, никаких VirtualProtect не надо. Зачем заниматься этим онанизмом?
Это же индусокод:
public int SuperSafeLength(string a)
{
  if (string.IsNullOrEmpty(a)) // return -1 for empty strings
      return -1;
        
    if (a == null)
      return -1;  // return -1 for null strings
        
    try 
    {
      return a.Length;
    }
    catch (NullRefernceException) // we must return -1 for null strings!!!
    {
      return -1;
    }
}

PD>Ну а в С++, конечно, никто такой гарантии не даст, но это обычная проблема — никто же не даст гарантии, что кто-то просто левым способом не испортит вполне обычную переменную.
Я тебе об этом и пишу. В одном мире эта идея бессмысленна, в другом — бесполезна. Что не мешает ей оставаться красивой, как произведение программерского искусства

S>>Наверное, лучше было бы сделать так, чтобы компилятор не давал делать такие вызовы, не так ли? Зачем компилировать заведомо некорректную программу?

PD>Ну мы опять за то же. Нет, не лучше.
А можно пример, в котором компилируемость невалидной программы позволит получить хоть какие-то преимущества?

PD>Я тебе уже говорил — ставя иммутабельность на тип, ты подвергаешься очень серьезным ограничениям. В реальной жизни нужно иметь и переменные этого типа и константы.

Павел, ты просто, похоже, не понимаешь, что такое "тип". Еще раз, медленно пишу, читай не торопясь: у тебя есть экземпляр a, класса A. Но у этого экземпляра запрещено вызывать метод A::setx(). Почему ты так настойчиво хочешь считать, что тип этого экземпляра — такой же, как и у экземпляра b? Ведь у экземпляра b можно вызывать метод setx()! С точки зрения математики, теории типов, да и просто здравого смысла a имеет совсем другой тип, чем b — у них разные контракты.

PD> Со строками у вас так и получилось — string для констант, StringBiulder для переменных. Для строк это сойдет. А для других классов — нет. Вот хочу я неизменяемый ArrayList , например. То есть хочу я следующее — однажды его сконструировать из какого-то источника и никогда больше не менять. И чтобы это сделать на иммутабельных типах, тебе придется еще один класс ImmutableArrayList соорудить (ну как наследника хоть, что ли).

Павел, ты по-прежнему не понимаешь, что такое "иммутабельность". Если ты хочешь "однажды его сконструировать из какого-то источника и никогда больше не менять" — это доступно тебе и так. Конструируй и не меняй, делов-то! В С++ ты даже можешь навесить на указатель/ссылку const, чтобы не забыть свои планы "не менять", и заодно получить дополнительную гарантию "и чтобы никто его не менял".

А вот если я "хочу получить сконструированный кем-то другим объект, который никто не может менять" — упс, облом. А это и есть иммутабельный тип, а вовсе не то убогое подмножество его функциональности, которое ты пытаешься выдать за реализацию.

PD>Кстати, сейчас подумал. В С++ операция new и конструктор — это, в общем, две независимые вещи. Но в C# это по существу тандем,

В С# это по существу две совершенно независимые вещи. К моменту начала инициализации, объект уже размещён (и его VMT сконструирована). То, что в языке нет отдельного оператора new, не влияет на эту семантику.
PD>так что если делается newconst Type(...), то среда, распознав, что создается константа, может автоматом заставить конструктор проверять, не делается ли попыток в нем записать ссылку на неконстантный объект ( а это очень просто, как ты понимаешь — по значению адреса).
Еще раз: поскольку ситуации, когда иммутабельный объект в течение своей жизни внезапно становится мутабельным, не бывает, то никакого смысла откладывать проверку до рантайма нет. Достаточно проверять всё статически.
PD>Ну естественно, я не мог написать это на настоящем С++. Мне не годится new, даже если я ее перекрою, так как не могу же я ее двумя способами перекрыть .
Запросто — сделаешь ему фейк-параметр синглтон-типа PD::ReadOnly и дело в шляпе.
PD>Мне нужна для этого модификация языка и введение операции newconst
Модификация языка потребуется для того, чтобы я мог написать
int SafeStringProcessor(immutable &std::string)
{
  
}

и иметь гарантии того, что никто снаружи не подсунет мне переменную типа string.

PD>Так, стоп. Я не намерен обсуждать сейчас, что хорошо в С++ и что нет. Я предложил идею создания и размещения константых объектов, она, как ты вполне видишь, от языка не зависит, так как реализована на чисто Win API. Окружи то, что я написал, соответствующим кодом хоть на .Net, хоть на чем угодно еще и используй

Павел, твоя идея просто не работает. Вот напиши мне пример функции, которая требует константный объект, сконструированный за её пределами.
На любом языке — С, С#, С++, Pascal.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 06:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

Спасибо за конструктивную критику. Пожалуй, я эту задачу модифицирую и дам в следующем году студентам в качестве одного из упражнений по Win32. В сущности тот, кто найдет и реализует ее решение, можно считать, идею виртуальной памяти и ее механизмы знает
With best regards
Pavel Dvorkin
Re[25]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 07:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

PD>>>>Опять двойка по ассемблеру. Подумай, не может ли состояние стека измениться вообще без выполнения каких бы то ни было команд
S>>>Конечно же может. Но к модели "память/регистры" это по-прежнему ничего не добавляет.
PD>>К модели не добавляет. А вот к утверждению "это просто CISC-шорткат для инструкций косвенной адресации" еще как добавляет.
S>И что именно оно добавляет к этому утверждению? Что там такого происходит со стеком, что невыразимо в терминах inc ESP и mov?

Изменение стека помимо исполнения команды, являющейся шорткатом и т.д.

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


Ну опять ты... Надоело.

PD>>В .Net вы гарантируете, что никто без unsafe не сможет вообще никуда в неположенное место обращаться. Так что уж позаботьтесь о том, чтобы только реализация константных конструкторов могла туда обращаться. В конце концов этих самих адресов я в .Net вообще не вижу. они там внутри где-то. Ну и манипулируйте ими корректно.

S>Еще раз, медленно повторяю: поскольку мы уже гарантировали отсутствие обращений в неположенные места, никаких VirtualProtect не надо. Зачем заниматься этим онанизмом?

Что за чушь ? Я же вроде ясно написал — никаких VirtualProtect не надо. Ты идею понял или нет ?

S>Это же индусокод:


Отправлен к индусам.

PD>>Ну а в С++, конечно, никто такой гарантии не даст, но это обычная проблема — никто же не даст гарантии, что кто-то просто левым способом не испортит вполне обычную переменную.

S>Я тебе об этом и пишу. В одном мире эта идея бессмысленна, в другом — бесполезна.

Ну-ну

>Что не мешает ей оставаться красивой, как произведение программерского искусства


S>>>Наверное, лучше было бы сделать так, чтобы компилятор не давал делать такие вызовы, не так ли? Зачем компилировать заведомо некорректную программу?

PD>>Ну мы опять за то же. Нет, не лучше.
S>А можно пример, в котором компилируемость невалидной программы позволит получить хоть какие-то преимущества?

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

PD>>Я тебе уже говорил — ставя иммутабельность на тип, ты подвергаешься очень серьезным ограничениям. В реальной жизни нужно иметь и переменные этого типа и константы.

S>Павел, ты просто, похоже, не понимаешь, что такое "тип". Еще раз, медленно пишу, читай не торопясь: у тебя есть экземпляр a, класса A. Но у этого экземпляра запрещено вызывать метод A::setx(). Почему ты так настойчиво хочешь считать, что тип этого экземпляра — такой же, как и у экземпляра b? Ведь у экземпляра b можно вызывать метод setx()! С точки зрения математики, теории типов, да и просто здравого смысла a имеет совсем другой тип, чем b — у них разные контракты.

Меня эта схоластика мало интересует. Тип в данных рассуждениях — это просто тип в смысле языка, а это понятие 100% конкретное. Тот факт, что для некоторых экземпляров этого типа вызов некоторого метода будет работать, а для некоторых нет — это и есть мое утверждение. Философские рассуждения о том, что есть тип меня сейчас мало интересуют.

S>А вот если я "хочу получить сконструированный кем-то другим объект, который никто не может менять" — упс, облом.


Это почему же ? Если этот кто-то другой лежит в пределах моего процесса — ничего нового, если он сконструировал этот объект как константу. Если за пределами процесса — тогда вопрос, как он его передал — как константу или нет. Ничего нового.



S>Еще раз: поскольку ситуации, когда иммутабельный объект в течение своей жизни внезапно становится мутабельным, не бывает, то никакого смысла откладывать проверку до рантайма нет. Достаточно проверять всё статически.


Ладно, хватит. Либо ты не понял, либо из принципа делаешь вид, что не понял.

S>Павел, твоя идея просто не работает. Вот напиши мне пример функции, которая требует константный объект, сконструированный за её пределами.

S>На любом языке — С, С#, С++, Pascal.

Я тебе 10 раз повторял — речь идет о необходимости добавить кое-что для этой цели в язык.
With best regards
Pavel Dvorkin
Re[23]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 26.06.09 07:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Получается, что нужен какой-то другой язык. В котором правила совместимости типов жестче. Или не пользоваться зависимыми типами из С++, а вместо этого описывать иммутабл-тип руками для каждого конкретного случая (как и сделано в дотнете).

Еще раз: В С++ нет зависимых типов. Пожалуйста не разводи путаницу.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Есть ли будущее у Native Code?
От: minorlogic Украина  
Дата: 26.06.09 07:59
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?

Обязательно вытеснит, но не обязательно верифицмруемый.

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?

Обязательно вытеснит, по крайней мере из прикладного кода.

C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Будет зависит от програмного и софтового окружения.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 26.06.09 08:03
Оценка:
Здравствуйте, minorlogic, Вы писали:

C>>Или его со временем полностью вытеснит верифицируемый промежуточный код?

M>Обязательно вытеснит, но не обязательно верифицмруемый.
А на кой черт нужен не верифицируемый промежуточный код?
Это же не имеет никакого смысла.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 08:08
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>И что именно оно добавляет к этому утверждению? Что там такого происходит со стеком, что невыразимо в терминах inc ESP и mov?
PD>Изменение стека помимо исполнения команды, являющейся шорткатом и т.д.
Чего? Что такое "изменение стека"?

PD>Что за чушь ? Я же вроде ясно написал — никаких VirtualProtect не надо. Ты идею понял или нет ?

Я — понял. Я не понял зачем она. У нас уже гарантируется отсутствие попыток записи в иммутабл объект. Зачем еще RO флаги?

PD>А можно способ привести, с помощью которого для серьезной программы определяется, что валидно, а что нет ? Только не слова, а ссылку на реальный софт, которому я свою программу подсуну, а она пусть и скажет.

Ничего не понимаю. Вот ты привёл пример программы:
int _tmain(int argc, _TCHAR* argv[])
{
    HANDLE hMapping = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, heapsize,NULL);
    char* pHeapRW = (char*)MapViewOfFile(hMapping, FILE_MAP_WRITE, 0, 0, heapsize);
    char* pHeapRO = (char*)MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, heapsize);
    delta = pHeapRW - pHeapRO;

        // все вышенаписанное, конечно, в класс HeapManager

    A* pA = (A*) pHeapRO; // прототип выделения памяти в куче, то есть операции newconst. Я просто беру начало кучи
    pA->Ctor(100); // прототип вызова конструктора
    int y = pA->getx(); // эту функцию можно вызывать, она объект не изменяет. Хотя явно const в ней специально не написано
    pA->setx(99); // а эту нельзя, здесь AV

    // очистка и обработка ошибок опущены

    return 0;
}

Она гарантированно невалидна — ты вызываешь в ней AV. Зачем ждать её запуска, если я и так могу сказать, что AV будет? Это должно быть ошибкой компиляции. Способ обнаружить это — очень простой: в месте вызова смотрим, какого типа pA, и определяем, можно ли для этого типа делать этот вызов. Тебя, я надеюсь, не удивляет, что компилятор пресекает попытки вызова private мемберов? А ведь тоже можно было бы эмулировать модификатор private при помощи аппаратной защиты. Я уверен — тебе не составит труда построить такой оператор newprivate, который подправит нужным образом значения слотов VMT.

PD>Меня эта схоластика мало интересует. Тип в данных рассуждениях — это просто тип в смысле языка, а это понятие 100% конкретное. Тот факт, что для некоторых экземпляров этого типа вызов некоторого метода будет работать, а для некоторых нет — это и есть мое утверждение. Философские рассуждения о том, что есть тип меня сейчас мало интересуют.

Это не схоластика. const int& — по-твоему схоластика? Ничего, что это другой тип, чем mutable int& ?

S>>А вот если я "хочу получить сконструированный кем-то другим объект, который никто не может менять" — упс, облом.

PD>Это почему же ? Если этот кто-то другой лежит в пределах моего процесса — ничего нового, если он сконструировал этот объект как константу.
Еще раз, пишу медленно: как ты обеспечишь выполнение этого "если"?

PD>Ладно, хватит. Либо ты не понял, либо из принципа делаешь вид, что не понял.

Это ты не понял. Мне твоя идея понятна на 100%, ничего в ней военного нет.
PD>Я тебе 10 раз повторял — речь идет о необходимости добавить кое-что для этой цели в язык.
Ну покажи пример того, о чём я говорю, на гипотетическом языке, в который это "кое-что" добавлено.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 08:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>>>И что именно оно добавляет к этому утверждению? Что там такого происходит со стеком, что невыразимо в терминах inc ESP и mov?
PD>>Изменение стека помимо исполнения команды, являющейся шорткатом и т.д.
S>Чего? Что такое "изменение стека"?

PD>>Что за чушь ? Я же вроде ясно написал — никаких VirtualProtect не надо. Ты идею понял или нет ?

S>Я — понял. Я не понял зачем она.

Тьфу, черт! Вчера я предложил эту функцию использовать. Сегодня я отменил это предложение. Его больше нет. А мне в ответ — зачем она тут ? Как с тобой разговаривать-то ?


S>Ничего не понимаю. Вот ты привёл пример программы:


<skipped>

S>Она гарантированно невалидна — ты вызываешь в ней AV.


А откуда это тебе известно, если не секрет ? Это я тебе сказал. А мог бы и не сказать. Вот теперь забудь, что я тебе это сказал и докажи, что она невалидна. Автоматически. А хочешь, я ее мигом валидной сделаю (правда, она при этом перестанет делать то, для чего она написана). Для этого надо всего лишь FILE_MAP_READ на FILE_MAP_WRITE поменять, и будет 2 проекции, обе R/W, и никакого AV.

>Зачем ждать её запуска, если я и так могу сказать, что AV будет?


Вот и расскажи, как ты это можешь до запуска определить. А еще скажи, как ты это сможешь до запуска определить, если этот несчастный флаг окажется параметром командной строки или будет вводиться с консоли во время исполнения

Чепуху говорить не надо.

Все остальное skipped, поскольку надоело.
With best regards
Pavel Dvorkin
Re[25]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 26.06.09 08:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>Еще раз: В С++ нет зависимых типов. Пожалуйста не разводи путаницу.

S>Некоторое подмножество-то есть.
Если так рассуждать то в любом статически типизированном языке есть некоторое подмножество
Как ты собираешься на С++ выразить
mult : ∀i , j , k : Nat ⇒ Matrix i j → Matrix j k → Matrix i k

при условии что i, j и k не известны на этапе компиляции?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Есть ли будущее у Native Code?
От: minorlogic Украина  
Дата: 26.06.09 08:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


C>>>Или его со временем полностью вытеснит верифицируемый промежуточный код?

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

Посмотри LLVM
http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine

Думаю там можно найти и описание мотивации к созданию.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[28]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 09:00
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тьфу, черт! Вчера я предложил эту функцию использовать. Сегодня я отменил это предложение. Его больше нет. А мне в ответ — зачем она тут ? Как с тобой разговаривать-то ?
Нормально разговаривать. Например, попробовать всё-таки понять, какой именно выигрыш даст защита памяти (неважно, через вызов VirtualProtect или через аргумент FILE_MAP_READ) программе, про которую еще до запуска известно, что она не станет пытаться менять константные объекты.

PD>А откуда это тебе известно, если не секрет ? Это я тебе сказал. А мог бы и не сказать. Вот теперь забудь, что я тебе это сказал и докажи, что она невалидна.

PD>Автоматически.
Это понятно, что для твоей программы ничего доказать нельзя. Ну, потому что она написана на языке, который не позволяет выразить ничего полезного про иммутабилити.
И как раз в этом проблема и есть: ну сделал ты этот объект в защищенном регионе, и что с того? Какую пользу ты с этого получишь?
Ты же за пределами своего _tmain() не имеешь права полагаться на неизменность этого объекта. А именно это-то и нужно! Самой _tmain от неизменности *pA пользы нет. Польза была бы неким алгоритмам, в которые _tmain этот pA отдаёт.

PD>А хочешь, я ее мигом валидной сделаю (правда, она при этом перестанет делать то, для чего она написана). Для этого надо всего лишь FILE_MAP_READ на FILE_MAP_WRITE поменять, и будет 2 проекции, обе R/W, и никакого AV.

Не, не хочу.

>>Зачем ждать её запуска, если я и так могу сказать, что AV будет?


PD>Вот и расскажи, как ты это можешь до запуска определить. А еще скажи, как ты это сможешь до запуска определить, если этот несчастный флаг окажется параметром командной строки или будет вводиться с консоли во время исполнения

PD>Чепуху говорить не надо.
Вот это полностью применимо к предыдущей фразе. Павел, ты не виляй, ты покажи пример реальной проблемы, которую ты решаешь вот этой своей загогулиной. Покажи реальный пример, где константность либо неконстантность создаваемого объекта действительно может определяться в рантайме, "параметром командной строки".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 09:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Если так рассуждать то в любом статически типизированном языке есть некоторое подмножество

Ну конечно же не в любом. Скажем, в Паскале нельзя взять, к примеру, тип "ссылка на А" и получить из него тип "константная ссылка на А".
Способы конструирования типов на С++, конечно же, не шибко развиты, но всё-таки они есть.

WH>Как ты собираешься на С++ выразить

WH>при условии что i, j и k не известны на этапе компиляции?
Никак не собираюсь. Поскольку язык статически типизирован, то и типы у него будут полностью статическими. Так что все зависимости тоже будут статически резолвится.
Увы, Павел не может понять даже такие, статически зависимые типы. Несмотря на то, что в его любимом языке они есть.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 26.06.09 09:06
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Посмотри LLVM

M>http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine
Я видел.

M>Думаю там можно найти и описание мотивации к созданию.

Бекенд для компилятором. Чисто чтобы каждый раз не писать кодогенератор и оптимизатор.
Проблема в том что LLVM не дает качественного улучшения программ.
А верифицируемый код дает.
Более того благодаря тому что для верифицируемого кода доступно множество доказательств его еще и оптимизировать можно сильнее.
Не говоря уже о том что верифицируемый код гораздо проще транслировать в разные волшебные базисы в которых легко делается суперкомпиляция.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Есть ли будущее у Native Code?
От: minorlogic Украина  
Дата: 26.06.09 09:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

M>>Думаю там можно найти и описание мотивации к созданию.

WH>Бекенд для компилятором. Чисто чтобы каждый раз не писать кодогенератор и оптимизатор.

Мне кажется основной мотив это переносимость и универсальность.

WH>Проблема в том что LLVM не дает качественного улучшения программ.

Не вижу способа который мог бы дать.

WH>А верифицируемый код дает.

Не вижу способа который мог бы дать.


WH>Более того благодаря тому что для верифицируемого кода доступно множество доказательств его еще и оптимизировать можно сильнее.

Уверен что ошибаешься.

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

И тут ошибаешся.

Преимущество неверифицируемого байт кода в том, что на его основе можно сделать в том числе и верефицируемый байт код. А наоборот нельзя, не потеряв производительность.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[27]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 26.06.09 09:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну конечно же не в любом. Скажем, в Паскале нельзя взять, к примеру, тип "ссылка на А" и получить из него тип "константная ссылка на А".

В паскале просто нет константности.
Но и в С++ это никакой не зависимый тип.
Это просто привидение к интерфейсу содержащему только не меняющие состояния методы.
Не более того.
Те это легко выражается на любом языке где есть интерфейсы. Хоть на C# хоть на Java.

S>Способы конструирования типов на С++, конечно же, не шибко развиты, но всё-таки они есть.

Нет.

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

Так в том то и прикол зависимых типов что зависимости времени исполнения проверяются статически.
Если же система типов не может проверять согласованность значений времени исполнения статически то она не содержит зависимых типов.
Система типов С++ не может делать таких проверок. А Agda, Epigram и некоторые другие могут.

S>Увы, Павел не может понять даже такие, статически зависимые типы. Несмотря на то, что в его любимом языке они есть.

Он вообще ничего что выходит за рамки WinAPI понять не может.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 09:34
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Преимущество неверифицируемого байт кода в том, что на его основе можно сделать в том числе и верефицируемый байт код.

Сильное утверждение. Хотелось бы как-то его доказать. Ну или хотя бы намекнуть, к примеру, как сделать на основе "неверифицируемого байт-кода x86" "верифицируемый байт-код x86".

M> А наоборот нельзя, не потеряв производительность.

Это еще более сильное утверждение. Его бы тоже хотелось доказать. Ну или хотя бы увидеть набросок соображений, по которым верифицируемый код обязан быть менее производительным, чем неверифицируемый.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Есть ли будущее у Native Code?
От: minorlogic Украина  
Дата: 26.06.09 09:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


M>>Преимущество неверифицируемого байт кода в том, что на его основе можно сделать в том числе и верефицируемый байт код.

S>Сильное утверждение. Хотелось бы как-то его доказать. Ну или хотя бы намекнуть, к примеру, как сделать на основе "неверифицируемого байт-кода x86" "верифицируемый байт-код x86".
Я такого не утверждал , как пример
из "неверифицируемого байт-кода x86" "верифицируемый байт-код JAVA".

M>> А наоборот нельзя, не потеряв производительность.

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

Ок, не буду обобщать. Вполне возможно что удасться с будущими верефицируемыми кодами и желехом.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[7]: Есть ли будущее у Native Code?
От: minorlogic Украина  
Дата: 26.06.09 09:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>>>А верифицируемый код дает.

M>>Не вижу способа который мог бы дать.
M>>Уверен что ошибаешься.
M>>И тут ошибаешся.
WH>Все ясно. С верой спорить бесполезно.
WH>Отправляйся к Дворкину.

Можно я попрошу модераторов забанить тебя за хамство? С чего ты взял что я собирался с тобой спорить?
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[23]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 26.06.09 10:23
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


T>>Теория это одно, практика — с кратковременными сбоями аппаратуры, — это другое.

S>Не очень понял про кратковременные сбои.

Сбои, не связанные с постоянно присутствующим дефектом в аппаратуре. Например, скачок напряжения. Или выброс радиации.

T>>Чтобы не повторяться: http://rsdn.ru/forum/philosophy/3440056.1.aspx
Автор: thesz
Дата: 23.06.09

S>Не понял, какое отношение кэширование имеет к аппратной изоляции.

Там оценка расходов на аппаратную изоляцию, на кэширование и на защиту от сбоев с помощью TAL.

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

Она дорога для переключения между областями защиты. Копать надо в этом направлении, по-моему.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[28]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 10:25
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>В паскале просто нет константности.
И много чего еще. К примеру, нет типа "ссылка". Нет типа "указатель на член".

WH>Те это легко выражается на любом языке где есть интерфейсы. Хоть на C# хоть на Java.

Ну, я бы не сказал, что это "легко" выражается. Тебя не затруднит показать мне, каким образом ты автоматически сгенерируешь этот "интерфейс, содержащий не меняющие состояния методы"?
Вручную-то всё возможно.
WH>Нет.
Откуда же тогда берутся типы? По-моему, они всё таки конструируются.

S>>Увы, Павел не может понять даже такие, статически зависимые типы. Несмотря на то, что в его любимом языке они есть.

WH>Он вообще ничего что выходит за рамки WinAPI понять не может.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 26.06.09 10:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну, я бы не сказал, что это "легко" выражается. Тебя не затруднит показать мне, каким образом ты автоматически сгенерируешь этот "интерфейс, содержащий не меняющие состояния методы"?

S>Вручную-то всё возможно.
Сразу после того как ты на С++ реализуешь статическую проверку
mult : ∀i , j , k : Nat ⇒ Matrix i j → Matrix j k → Matrix i k

при условии что i, j и k не известны на этапе компиляции.

Всякие там агды и эпиграмы справляются с этим на раз.

И вообще это твое утверждение что в С++ есть зависимые типы вот ты его и доказывай.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.09 10:42
Оценка:
Здравствуйте, thesz, Вы писали:
T>Сбои, не связанные с постоянно присутствующим дефектом в аппаратуре. Например, скачок напряжения. Или выброс радиации.
Это я понимаю. Я не понимаю, чем бит RO в таблице страниц спасает от скачков радиации, по сравнению с софтной верификацией корректности.

T>Там оценка расходов на аппаратную изоляцию, на кэширование и на защиту от сбоев с помощью TAL.

А защиты от сглаза там случайно не встроено?
T>В переводе на русский язык, аппаратная изоляция не столь дорога, как кажется. Я имею в виду код, выполняющийся внутри одной области защиты.
T>Она дорога для переключения между областями защиты. Копать надо в этом направлении, по-моему.
Ну, так в эту сторону и копают.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 26.06.09 11:48
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

T>>Сбои, не связанные с постоянно присутствующим дефектом в аппаратуре. Например, скачок напряжения. Или выброс радиации.
S>Это я понимаю. Я не понимаю, чем бит RO в таблице страниц спасает от скачков радиации, по сравнению с софтной верификацией корректности.

Итак, ты точно знаешь, что a[i]=10 корректно.

Это дело разворачивается в
    ldi r1,a
    shl r2,r10,2 # r10 - i, int a[...]
    ldi r3, 10
    add r4,r1,r2
    st (r4),r3


Пять команд.

При выполнении любой из них может возникнуть сбой, который может привести к ошибке (либо прямо здесь, в st, либо позже).

Что ты предлагаешь делать, чтобы код a[i]=10 остался корректным с большой вероятностью для существенной вероятности сбоя в одной команде?

Что произойдёт, если у нас ошибка в случае с аппаратной защитой памяти современного типа.

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

Только прошедшая через всё это ошибка, оказавшаяся только в потоке вычислений, имеет шанс попасть в данные, доступные другим процессам.

T>>Там оценка расходов на аппаратную изоляцию, на кэширование и на защиту от сбоев с помощью TAL.

S>А защиты от сглаза там случайно не встроено?

Я, что, провоцирую ёрничанье?

T>>В переводе на русский язык, аппаратная изоляция не столь дорога, как кажется. Я имею в виду код, выполняющийся внутри одной области защиты.

T>>Она дорога для переключения между областями защиты. Копать надо в этом направлении, по-моему.
S>Ну, так в эту сторону и копают.

По-моему, вариант с защитой памяти и тут будет полезен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 26.06.09 12:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Если в существующем софте есть ошибка, то все возможно. Но по постингу WolfHound можно понять так, что достаточно переполнить буфер , и мы попадем в страницы, находящиеся под контролем системы. А причина банальная — он не вполне понимает отличие виртуальной памяти от физической, он считает, что если выйти за пределы страницы, то мы попадем на соседнюю страницу физической памяти, которая может принадлежать системе

WH>Опять фантазируешь на тему того что я что-то не понимаю.
WH>Просвещайся http://en.wikipedia.org/wiki/Buffer_overrun

PD>Тебе же тут уже объяснили — не работайте под админом. Кстати, как ты собираешься устроить эту самую эскалацию для процесса броузера, если он (под Вистой) запущен хоть и от админа, но без админских прав ? (т.е с юзеровскими правами) Это тоже очень интересно бы знать

WH>Через переполнение буфера например.Что думаешь в WinAPI ни одного нет?
With best regards
Pavel Dvorkin
Re[21]: повтор
От: Pavel Dvorkin Россия  
Дата: 26.06.09 13:06
Оценка:
Сорри, отослал, не дописав.

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


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


PD>>>Если в существующем софте есть ошибка, то все возможно. Но по постингу WolfHound можно понять так, что достаточно переполнить буфер , и мы попадем в страницы, находящиеся под контролем системы. А причина банальная — он не вполне понимает отличие виртуальной памяти от физической, он считает, что если выйти за пределы страницы, то мы попадем на соседнюю страницу физической памяти, которая может принадлежать системе

WH>>Опять фантазируешь на тему того что я что-то не понимаю.
WH>>Просвещайся http://en.wikipedia.org/wiki/Buffer_overrun

PD>>Тебе же тут уже объяснили — не работайте под админом. Кстати, как ты собираешься устроить эту самую эскалацию для процесса броузера, если он (под Вистой) запущен хоть и от админа, но без админских прав ? (т.е с юзеровскими правами) Это тоже очень интересно бы знать

WH>>Через переполнение буфера например.Что думаешь в WinAPI ни одного нет?

Пожалуйста, подробности того, как это может произойти. То есть ты переполнишь буфер, а результат — эскалация привилегий для процесса броузера. Win API для запущенных процессов изменить токен в плане добавления прав не дает. Вызовов для замены токена у процесса нет. Так что Win API попросту это не умеет делать. А вот если, переполнив буфер, мы попадем на другую страницу, а она окажется системной, да нам удастся на нее записать, тогда да, можно и данные ядра изменить, в том числе и объект токен.

Но не сможем мы на эту страницу записать. Ибо переполнив буфер мы попадем на соседнюю страницу виртуальной памяти , но отнюдь не физической. И натворить дел мы можем таким образом только у себя в виртуальном адресном пространстве.
With best regards
Pavel Dvorkin
Re[22]: небольшое добавление
От: Pavel Dvorkin Россия  
Дата: 26.06.09 13:36
Оценка:
Если в этом примере заменить

HANDLE hMapping = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, heapsize,NULL);

на

HANDLE hMapping = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, heapsize, AnyUniqueString);

то мэппинг будет именованный, а значит, может быть доступен другим процессам. При этом разные процессы могут делать его view по-разному, один — R/O, другой — R/W. Таким образом один процесс, например, может рассматривать некие данные как константы, в то время как другой — как переменные. Или оба как константы. Или еще как. Разумеется, если реализовать такое, то эту кучу надо сделать отдельной , специально для этих разделяемых переменных/констант. Передавать их из процесса в процесс не надо — они уже переданы, то есть автоматом присутствуют в обоих процессах. Естественно, для доступа к ним теперь нужна синхронизация, впрочем, это уже банальности.
With best regards
Pavel Dvorkin
Re[11]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 02.07.09 16:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

V>>Блин, тебе хочется хлеба и зрелищ? Ну давай покажи как можно в ОбЩЕМ случае. Заодно список языков с примерами.

WH>Сначала пойми что такое зависимые типы. После чего вопросы у тебя отпадут сами собой.
WH>А заниматься твоим образованием у меня нет никакого желания.

Если ты считаешь, что в С++ не реализована система зависимых типов, то ты не знаешь, о чем речь. Так что возвращаю твой "лозунг" относительно образования.

В любом случае, если быть ближе к делу, просто покажи хоть на каком-нибудь ЯП вот это ограничение рекурсии на зависимых типах (пусть даже в твоем понимании зависимых типов). А я тебе на С++ аналог покажу.
Re[8]: Есть ли будущее у Native Code?
От: gear nuke  
Дата: 04.07.09 09:25
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Последний раз ИМХО исправляли одну из первых версий 386, в которой был какой-то баг в чем-то, связанном с плавающей точкой.


Скорее, это был первый Pentium. Современные процессоры по-видимому слишком сложны для верификации, поскольку содержат не только массу документированных errata, но и некоторые проблемы с дизайном начинают всплывать только в последнее время (см например эксплуатацию TLB вshadow walker)
.
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
Re[13]: Есть ли будущее у Native Code?
От: gear nuke  
Дата: 04.07.09 12:26
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да ну ? А можно поподробнее, как это можно переполнить буфер и проникнуть таким образом в нулевое кольцо ?


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

При этом аппаратная защита не затрагивается

PD> Можно примерчик кода 3 кольца ? Или это только вирусописатели умеют так буфер переполнять ?


здесь DoS. Запуск кода в свободном доступе найти сложно, но описаний много здесь
.
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
Re: Есть ли будущее у Native Code?
От: minorlogic Украина  
Дата: 04.07.09 12:31
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Почему такое ограниченное к-во сценариев ?

а LLVM ?
http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine

LLVM can replace most of the "lower levels" of the GCC toolchain, offering more aggressive optimization of GCCs three address code intermediate form (IF). LLVM supports a language-independent instruction set and type system. Each instruction is in static single assignment form (SSA), meaning that each variable (called a typed register) is assigned once and is frozen. This helps simplify the analysis of dependencies among variables. LLVM allows code to be compiled statically, as it is under the traditional GCC system, or left for late-compiling from the IF to machine code in a just-in-time compiler (JIT) in a fashion similar to Java.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[6]: Есть ли будущее у Native Code?
От: gear nuke  
Дата: 04.07.09 14:29
Оценка:
Здравствуйте, IID, Вы писали:

IID>Обновление микрокода в процессоре решает!


И отсюда следует, что такой процессор интерпретирует "нативный код" Осталось только залить туда другую ВМ с верификатором...
.
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
Re[7]: Есть ли будущее у Native Code?
От: IID Россия  
Дата: 17.07.09 09:10
Оценка:
Здравствуйте, gear nuke, Вы писали:

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


IID>>Обновление микрокода в процессоре решает!


GN>И отсюда следует, что такой процессор интерпретирует "нативный код" Осталось только залить туда другую ВМ с верификатором...


В общем случае не следует. Например — ПЛИС нифига не интерпретирует. Но перезалить прошивку в неё можно.
kalsarikännit
Re[11]: Есть ли будущее у Native Code?
От: Denom Украина  
Дата: 16.09.09 08:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А если я пишу на немерле то там на сотни строк кода может не быть ни одной переменной.

что пишешь, если не секрет?
... << RSDN@Home 1.2.0 alpha 4 rev. 1181>>
Re[10]: Есть ли будущее у Native Code?
От: Dufrenite Дания  
Дата: 28.09.09 15:15
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>И что ? Что вы все эти пустяки раздуваете до немыслимых размеров , а потом борьбу с ними представляете как чуть не главное в программировании. Ну пустяки это же все. Мелочи.


Узкий специалист в тяжелой форме.
Re[21]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 21.10.09 11:21
Оценка:
Здравствуйте, kig, Вы писали:

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


kig>[]


PD>>То-то, по утверждению Нортона, того, кто исключил стек из архитектуры IBM-360, "сослали во внутрифирменный аналог Сибири".


kig>ИМХО: Не знаю, что там Нортон утверждал и когда, но в начале 60 годов за предложение резервировать часть такого дорогого ресурса (на тот момент), как память под стек при загрузке кода, сослали бы точно.


А объяснить -1?
Re[2]: Есть ли будущее у Native Code?
От: Plague Россия 177230800
Дата: 21.10.09 11:41
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Надеюсь я до этого кошмара не доживу.


Почему кошмар?
Это же розовые сны опенсорса! или нет?
Re[8]: Есть ли будущее у Native Code?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.10.09 13:32
Оценка:
Здравствуйте, thesz, Вы писали:

T>Да, соглашусь.


Рановато, ИМХО .
Re[9]: Есть ли будущее у Native Code?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.10.09 13:34
Оценка:
Здравствуйте, IID, Вы писали:

WH>>>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.


T>>Дома у меня есть PowerPC. Так что вероятность всего 2/3 (работа, дом и дом).


IID>Гы, а у меня два x86 компа дома, два компа на Z-80, два на 6502, один на К1801ВМ1 и ещё один — двухпроцессорный на КМ1801ВМ2.


И что, это годные, хорошие компы — ты с этих компов можешь писать в RSDN?
Re[8]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 21.10.09 14:33
Оценка:
Здравствуйте, Gaperton, Вы писали:

WH>>Управляемые системы позволят от этой нашлепки избавиться.

G>Правда штоли . А язык С, и прочие языки высокого уровня, значит, принципиально недостаточно портабелены, чтобы "от этой нашлепки избавиться"?
А ты что не знал?
Доказательство простое и совершенно не опровержимое: Если бы они были достаточно портабельны то эта нашлепка бы не появилась.

G>Как все невероятно просто у вас. "Просто" описать "модель нового процессора". Ты когда нибудь портабельную ОСь под новый проц и борду портировал? Попробуй, увлекательнейшее занятие. Про разработку процессоров я уж и не спрашиваю .

А давай ты сравнишь эти затраты хотя бы с простой перекомпиляцией всего софта в мире под новый процессор и доставкой бинарников пользователям, а если учесть что очень большое количество софта так просто под новый процессор не перекомпилировать (привет языкам "высокого" уровня типа С/С++) то
Даже переход на x86-64 был тем еще приключением.
Не смотря на то что винда64 появилась быстро пользоваться ей было невозможно очень долго ибо не было драйверов (вот скажи мне зачем драйверу устройства знать систему команд CPU?), эмуляторы CDROM'ов тоже не работали (этим тоже система команд CPU должна быть до лампочки),... даже не весь прикладной софт работал не смотря на то что винда запускала его в режиме совместимости.

И это не вспоминая про такие вещи как надежность и безопасность управляемого софта.

G>Это да. Зато с несуществующей пока пригодной к "продакшну" осью, о которой ты говоришь — любой фокус пройдет . То, что еще не работает толком — всегда обладает чудесными свойствами, это ж всем известно.

Ты можешь ехидничать сколько влезет но от фундаментальных проблем классического подхода твое ехидство не спасет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 21.10.09 15:03
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Кстати, по странному стечению обстоятельств процы с "этой нашлепкой" частенько стоят дешевле и работают быстрее, чем процы без нее. Представляешь, неувязочка какая получается. Вот, к примеру, компы Apple при переходе на Intel с Power стали внезапно быстрее раз в 5. Боюсь, данная нашлепка не мешает разработчикам процессоров из Intel и AMD. Они хорошие танцоры, видать.

Отличный образец демагогии.
Ты сравниваешь работу разных людей. Единственный вывод который можно сделать из этого сравнения это то что у разработчиков Power руки кривее чем у ребят из интела.
А что будет если ребятам из интела дать возможность сделать такую систему команд которую они захотят?
1)Я конечно в разработки процессоров мало что понимаю но что-то мне подсказывает что уменьшение длинны конвейера (а именно это произойдет при выкидывании нашлепки) скажется на производительности в лучшую сторону.
2)Есть у меня такое чувство что и в основном процессоре тоже можно будет выкинуть какую ни будь фигню которая нужна только устаревшим командам.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Есть ли будущее у Native Code?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.10.09 15:10
Оценка:
Здравствуйте, Gaperton, Вы писали:

WH>>>>Управляемые системы позволят от этой нашлепки избавиться.

G>>>Правда штоли . А язык С, и прочие языки высокого уровня, значит, принципиально недостаточно портабелены, чтобы "от этой нашлепки избавиться"?
WH>>А ты что не знал?
WH>>Доказательство простое и совершенно не опровержимое: Если бы они были достаточно портабельны то эта нашлепка бы не появилась.

G>Угу. Так же как и доказательство того, что ты инопланетянин.


G>Дано: 2+2=5.

G>Отсюда неопровержимо следует, что 2 = 1. Вы и инопланетянин — вас двое. 2 = 1 — вы одно и то же лицо.

Это доказательство, кстати, основано на классическом доказательстве Бертрана Рассела. Он однажды примерно таким образом продемонстрировал собеседнику, что их ложных посылок следует все, что угодно, доказав, что он — Папа Римский.

Ничего личного, bro. Ты первый начал . Показать, где у тебя ложная посылка? Или сам найдешь?
Re[9]: Есть ли будущее у Native Code?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.10.09 15:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

G>>Кстати, по странному стечению обстоятельств процы с "этой нашлепкой" частенько стоят дешевле и работают быстрее, чем процы без нее. Представляешь, неувязочка какая получается. Вот, к примеру, компы Apple при переходе на Intel с Power стали внезапно быстрее раз в 5. Боюсь, данная нашлепка не мешает разработчикам процессоров из Intel и AMD. Они хорошие танцоры, видать.


WH>Отличный образец демагогии.


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

WH>Ты сравниваешь работу разных людей. Единственный вывод который можно сделать из этого сравнения это то что у разработчиков Power руки кривее чем у ребят из интела.


Нормальный человек не будет делать выводов касательно качеств разработчиков из IBM. Хотя бы потому, что кроме Intel и IBM есть SUN и AMD. А в недавнем прошлом — процы делали HP (PA-RISC), DEC (Alpha), Silicon Graphics (MIPS), короче, хренова туча народу, всех не упомнишь.

Нормальный человек сделает из этого сравнения вывод, что поддержка систем команд х86/CISC не оказывает никакого значимого отрицательного влияния на производительность процессоров, так же как система команд в стиле RISC — положительного. Все определяют в большей степени особенности микроархитектуры, а не ISA.

К сведению — чтобы еще немного усложнить картину, приблизив ее к реальной — система команд Power сложна, она скорее CISC, чем RISC. То же самое касается ARM — это далеко не чистый RISC, там достаточно сложных CISC инструкций и кажется есть какой-то кривой не RISC-овый метод адресации.

И он будет прав в этом выводе. Доминируют другие факторы.

WH>А что будет если ребятам из интела дать возможность сделать такую систему команд которую они захотят?


Они делают именно такую систему команд, которую хотят. Они даже в шейдерных процессорах перспективных 3D контроллеров хотят x86. Читай ниже.

WH>1)Я конечно в разработки процессоров мало что понимаю но что-то мне подсказывает что уменьшение длинны конвейера (а именно это произойдет при выкидывании нашлепки) скажется на производительности в лучшую сторону.


Глубина конвейера не сократится. Декодер команд ты никуда не выкинешь — единственная разница будет в том, что декодер будет выплевывать одну трехадресную микрокоманду в конвейер вместо группы, как это происходит сейчас, и станет чуть-чуть меньше площадью — от туда уйдут конечные автоматы, реализующие трансляцию x86 в трехадресный микрокод.

Учитывая возросший размер исполняемого кода, и, как следствие — требования к пропускной способности памяти и размеру кэшей, после твоей модификации для выполнения той же работы (CISC-код заметно компактнее, чем RISC — я наблюдал до 2-х раз, сравни размеры бинарей для SPARC и x86), эффект будет отрицательным, а не положительным.

WH>2)Есть у меня такое чувство что и в основном процессоре тоже можно будет выкинуть какую ни будь фигню которая нужна только устаревшим командам.


x86 сразу же транслируются в ту систему команд, которая удобна разработчикам ядра, дружище. Как только декодируется. Честно. На первых же стадиях конвейра. Практически нечего выкидывать.
Re[10]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 21.10.09 15:41
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Угу. Так же как и доказательство того, что ты инопланетянин.

G>Дано: 2+2=5.
G>Отсюда неопровержимо следует, что 2 = 1. Вы и инопланетянин — вас двое. 2 = 1 — вы одно и то же лицо.
Просто отвергать то что тебе не нравится это так просто...

G>А давай ты сам займешься глупостями, которые выдумаваешь, вместо того, чтобы предлагать это мне? Это справедливо.

Ты сказал что портирование ядра ОС это охренеть как сложно. Я просто сказал что придется сделать при смене системы команд в случае с классическим подходом.
Кстати портирование ядра в случае с классическим подходом тоже нужно...

G>Как-никак никого кроме тебя в мире не волнует проблема перекомпиляции всего софта в мире под новый процессор.

А кто тебя назначил представителем всего мира?

G>Ведь новые процессора по большей части волшебным образом совместимы по системе команд со старыми.

1)Как ты верно заметил по большей части.
2)Вынужденны быть совместимы из-за мегатонн легаси кода.

G>И почему это в макоси нет таких проблем, интересно?

А ты сравни количество софта и железа под макось и под винду. Теперь сравни какой процент софта и железа контролируют мелкософт и яблочники.
Все еще не понимаешь?

G>И у IBM с их серверами на базе Power тоже проблема отсутствует, почему-то. WTF?

G>И у DEC с их Alpha почему-то все в порядке было с переходом. Ну не чудеса-ли?
Тут ситуация еще более тепличная чем у яблочников.

G>При чем тут ОСь-то, а?

Так безопасность она либо везде либо нигде.
Других вариантов нет.

G>Пускайте себе свой "супернадежный управляемый софт" как пользовательские процессы — руки прочь от процессоров и оперсистем

Процессоры управляемым ОС до лампочки.
А вот почему нельзя сделать управляемой саму ОС не понятно.
Вот скажи мне чем статически типизированный (я бы даже сказал жестоко типизированный ну там зависимые типы итп) эрланг хуже для разработки ядра ОС и драйверов чем С?

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

руки прочь от процессоров

Для управляемых ОС процессор трогать не надо

G>Волнует же данная проблема в настоящий момент по большей части embedded-разработчиков, причем в специфических областях — космос, медицина, военщна, и прочее. Танненбаум уже проблемой занялся, к примеру — именно в этом ключе.

Вот меня как пользователя это все тоже волнует.
Меня достал спам, вирусы, видиоплееры вылетающие из-за битого ролика, BSOD на ровном месть,...
Я конечно понимаю что большинству пользователей внушили что иначе быть не может но ведь это не так.

G>Причина моей иронии в том, что "фундаментальные проблемы классического подхода" существуют по большей части в твоем воображении. Как и их воображаемое решение.

Ага а то что виндой64 можно было начать пользоваться только через год после ее появления мне приснилось да?

G>Чтобы понимать "фундаментальность" проблем, и видеть пространство возможных решений вместо одного (что необходимо для осмысленного, а не фанбойского анализа альтернатив), надо знать элементарные принципы устройства аппаратуры и иметь опыт работы с железом. Уметь цитировать материалы по singularity из сети для этого недостаточно.

Ты пока что кроме откровенной демагогии не сказал ничего.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 21.10.09 17:08
Оценка:
Здравствуйте, Gaperton, Вы писали:

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

Объясни пожалуйста вот такой факт:
#include <windows.h>
#include <iostream>

struct Timer
{
    Timer()
    {
        QueryPerformanceFrequency((LARGE_INTEGER*)&freq_);
    }
    void Reset()
    {
        QueryPerformanceCounter((LARGE_INTEGER*)&begin_);
    }
    double GetTime()
    {
        QueryPerformanceCounter((LARGE_INTEGER*)&end_);
        return double(end_ - begin_) / freq_;
    }
private:
    __int64 begin_, end_, freq_;
};

int main()
{
    const int count = 1000000000;
    Timer t;
    t.Reset();
    __asm
    {
        push ecx
        mov ecx, count
l1:
        loop l1
        pop ecx
    }
    std::cout << t.GetTime() << std::endl;
    t.Reset();
    __asm
    {
        push ecx
        mov ecx, count
l2:
        dec ecx
        jnz l2
        pop ecx
    }
    std::cout << t.GetTime() << std::endl;
    t.Reset();
    return 0;
}

2.278
0.451337

Процессор Intel Core 2 Quad
Каким образом 2х байтовый loop оказался в 5 раз медленней чем 3х байтовая связка из dec и jnz?
Как это вяжется с твоей теорией что нашлепка не влияет на производительность?
Что мешало внутри процессора произвести трансляцию loop в dec и jnz?
Может тут не все так просто как ты пытаешься представить?

G>Нормальный человек

Можешь не стараться. Такими дешевыми трюками меня из себя не вывести.

G>не будет делать выводов касательно качеств разработчиков из IBM.

Почему?

G>Хотя бы потому, что кроме Intel и IBM есть SUN и AMD. А в недавнем прошлом — процы делали HP (PA-RISC), DEC (Alpha), Silicon Graphics (MIPS), короче, хренова туча народу, всех не упомнишь.

И что?

G>Нормальный человек сделает из этого сравнения вывод, что поддержка систем команд х86/CISC не оказывает никакого значимого отрицательного влияния на производительность процессоров, так же как система команд в стиле RISC — положительного. Все определяют в большей степени особенности микроархитектуры, а не ISA.

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

G>Они делают именно такую систему команд, которую хотят. Они даже в шейдерных процессорах перспективных 3D контроллеров хотят x86. Читай ниже.

А можно ссылку на то чем конкретно они мотивировали именно x86?

G>Учитывая возросший размер исполняемого кода, и, как следствие — требования к пропускной способности памяти и размеру кэшей, после твоей модификации для выполнения той же работы (CISC-код заметно компактнее, чем RISC — я наблюдал до 2-х раз, сравни размеры бинарей для SPARC и x86), эффект будет отрицательным, а не положительным.

Да ради байта. Я же не против того что коды команд будут разного размера. Проблема же не в наличии dec rx который сразу же транслируется в sub rx rx 1 проблема в наличии всякого тормозного хлама типа loop.

G>x86 сразу же транслируются в ту систему команд, которая удобна разработчикам ядра, дружище. Как только декодируется. Честно. На первых же стадиях конвейра. Практически нечего выкидывать.

Чтобы убедится в этом придется читать исходники.
У тебя случайно исходники свежих интеловских процессоров не завалялись?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.10.09 17:30
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


T>>Да, соглашусь.


G>Рановато, ИМХО .


У меня есть соображения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.10.09 18:54
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


G>>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?


G>К примеру, в процессорах ARM есть специальные инструкции, предназначенные для сохранения 8 регистров сразу. Применются много где — и в коде переключения контекста, и в коде банального memcpy.

G>К примеру, в процессорах ARM есть специальное расширение системы инструкций NEON — применяется при сигнальной обработке и в мультимедийных кодеках. Библиотеки пишутся ручками на ассемблере.

Ну это все говорит только о слабости компиляторов\оптимизаторов. Косвенно о слабости языков разработки.

G>>В Singularity они необходимость ассемблера обошли таким образом: коду драйвера передается экземпляр класса, который отвечает за всю низкооуровневую работу (обращения к этому классу вполне могут компилиться в нужный нативный код).


G>Подстава с применением managed кода здесь не в классах, а в том, что многие безобидные на вид периферийные устройства требуют реакции на прерывания в условиях жесткого реального времени — и это при том, что требования real-time не распространяются на всю систему. Простейший пример — большинство видеоконтроллеров в бытовой электронике требуют от драйвера реакции на каждый полукадр, причем — в жестко отведенное временное окно. А некоторые их них требуют тщательной оптимизации интерфейсного кода.

А причем тут managed код? Разве нельзя обеспечить жесткий реалтайм в таких условиях?
Singularity заявлена как реалтайм система, правда непонятно какой там реалтайм.

G>>Почему нельзя будет для других архитектур процессоров сделать другие классы, наследники какого-либо базового?

G>Есть еще причины. Например, потому, что далеко не все процессоры устроены одинаково. Посмотри внимательно на архитектуру Blackfin — в качестве примера, на что это может быть похожа популярная архитектура.
К несчастью я писал на blackfin (и на других процессорах от Analog Devices). Я например не вижу причин по которым что-либо будет плохо работать на blackfin.
Кстати .NET Microframewok уже есть на этих процессорах.
Re[10]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.10.09 20:26
Оценка:
WH>>1)Я конечно в разработки процессоров мало что понимаю но что-то мне подсказывает что уменьшение длинны конвейера (а именно это произойдет при выкидывании нашлепки) скажется на производительности в лучшую сторону.
G>Глубина конвейера не сократится. Декодер команд ты никуда не выкинешь — единственная разница будет в том, что декодер будет выплевывать одну трехадресную микрокоманду в конвейер вместо группы, как это происходит сейчас, и станет чуть-чуть меньше площадью — от туда уйдут конечные автоматы, реализующие трансляцию x86 в трехадресный микрокод.

Глубина конвейера сократится.

Декодирование команды в современных x86 делается в пять этапов, что ли. Больше трёх, это точно.

G>Учитывая возросший размер исполняемого кода, и, как следствие — требования к пропускной способности памяти и размеру кэшей, после твоей модификации для выполнения той же работы (CISC-код заметно компактнее, чем RISC — я наблюдал до 2-х раз, сравни размеры бинарей для SPARC и x86), эффект будет отрицательным, а не положительным.


Beyond Architecture. Система команд load-store, длина команд варьируется. Декодирование делается в один такт. 30-40 процентов сокращения объёма кода.

http://www.beyondsemi.com/page/products/processor_cores
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.10.09 20:48
Оценка:
G>Они простенький такой (по сравнению с остальным фаршем) блок внедряют в декодер команд, в самом начале конвейера, который преобразует х86 в нормальный трехадресный код.

Коллеги по Prosoft жалуются, что им пришлось использовать китайский клон x86. Он был сделан на китайском же варианте какого-то RISC, с нашлёпкой в виде декодера x86 команд.

Так вот, им пришлось отыскать и обойти в ПО плавающую ошибку в этом процессоре — pop ss иногда срабатывал неправильно.

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

G>И весь основной конвейер у таких процессоров построен примерно на тех же принципах, что и конвейер RISC-процессора.


Сложней. Тебе нужны ещё блоки переименования регистров туда и обратно.

G>Оверхэд по площади — смешной для суперскалярного проца на 6 каналов арифметики, а производительность, как ни парадоксально, при таком подходе выше.


Если ты посмотришь на floorplan любого x86, то там здоровенную часть будет занимать x87, хотя даже 2xdouble должно быть в районе, не знаю, миллиметров 16 по площади. А x87 занимает десятки.

Всё потому, что надо переводить из стековой системы команд в регистровую.

G>А знаешь, почему? CISC код более компактен, чем RISC, что снижает требования к пропускной способности памяти, размеру кэшей, итд. А именно это — узкое место в настоящее время.


http://sourceforge.net/mailarchive/forum.php?thread_name=200609161650.k8GGoBSr028429%40pandora1.cs.utsa.edu&amp;forum_name=math-atlas-devel

I've been puzzling over why the best Core2 code uses only 8 active registers,
where the best AMD can use all 16. Dean sent in the missing piece, by
pointing to this technical info goldmine:
http://www.agner.org/optimize/

Turns out that the weakest link on Core2 (and, I think, pretty much all
Intel procs) is the decode step. When you use registers the registers greater
than 7 (eg., %xmm8), this adds a byte to all such operations. 8 output
registers give you only a few instructions that require larger storage,
resulting in ATLAS's kernel using 114 bytes for a given iteration of
the kernel loop. This is important, because this is two 64-byte gulps by
the decoder. Once you add another register as output, this increases the
computation to 3 windows, which apparently is the killer.

Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Есть ли будущее у Native Code?
От: CreatorCray  
Дата: 22.10.09 07:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Объясни пожалуйста вот такой факт:

WH>Каким образом 2х байтовый loop оказался в 5 раз медленней чем 3х байтовая связка из dec и jnz?
Исключительно потому, что LOOP не изменяет флаги вообще. Дальше сам думай.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Есть ли будущее у Native Code?
От: IID Россия  
Дата: 22.10.09 08:09
Оценка:
Здравствуйте, Gaperton, Вы писали:

IID>>Гы, а у меня два x86 компа дома, два компа на Z-80, два на 6502, один на К1801ВМ1 и ещё один — двухпроцессорный на КМ1801ВМ2.


G>И что, это годные, хорошие компы — ты с этих компов можешь писать в RSDN?


С x86 конечно, без проблем Что же касается раритетов... Да, это годные, хорошие компы. Только не понятно как "годность" компа коррелирует с писательством в RSDN Эти компы решают свои задачи ничуть не хуже чем 20-27 лет назад. Современное же железо, строго говоря, эти задачи на 100% решить не может, даже учитывая эмуляцию:
— Отсутствие софта. Да, софт можно написать заново. Но покуда это не будет сделано — задача не решается.
— Ошибки и недочёты в эмуляторах. Буквально месяц назад добавил поддержку аппаратного скроллинга ATM-Turbo2 в эмулятор Spectrum-а unreal. Ковыряние в сорцах эмулятора показало, что многие вещи делаются ужасно неточно и различие с реальным железом будет. Возможно, будет даже фатальным (например чёрный экран или экран с мусором вместо картинки).
— Принципиальная несовместимость железа. Например, PC-шный контроллёр FDD сходит с ума при попытках прочитать защищённые диски ZX-Spectrum. Софт с такого диска ни в одном эмуляторе не прочтётся. А, значит, и не запустится.
kalsarikännit
Re[12]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 22.10.09 09:48
Оценка:
Здравствуйте, CreatorCray, Вы писали:

WH>>Каким образом 2х байтовый loop оказался в 5 раз медленней чем 3х байтовая связка из dec и jnz?

CC>Исключительно потому, что LOOP не изменяет флаги вообще. Дальше сам думай.
И как это опровергает утверждение о вредности устаревших систем команд?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 22.10.09 09:51
Оценка:
Здравствуйте, kig, Вы писали:

kig>>ИМХО: Не знаю, что там Нортон утверждал и когда, но в начале 60 годов за предложение резервировать часть такого дорогого ресурса (на тот момент), как память под стек при загрузке кода, сослали бы точно.


kig>А объяснить -1?


Памяти ни больше, ни меньше не станет, если частью ее оперировать по стековому механизму. Кроме того, для загрузки кода стек не используется — при чем тут код ?
With best regards
Pavel Dvorkin
Re[23]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 22.10.09 11:33
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


kig>>>ИМХО: Не знаю, что там Нортон утверждал и когда, но в начале 60 годов за предложение резервировать часть такого дорогого ресурса (на тот момент), как память под стек при загрузке кода, сослали бы точно.


kig>>А объяснить -1?


PD>Памяти ни больше, ни меньше не станет, если частью ее оперировать по стековому механизму. Кроме того, для загрузки кода стек не используется — при чем тут код ?


Речь о физической памяти? Если о ней — точно больше не станет.
Или речь о механизме виртуальной памяти? Если о ней, боюсь на момент запуска железячного проекта 360 о ней если и говорили, то только в академических кругах. А при отсутствии механизма виртуализации памяти, при загрузке на выполнение кода необходимо в физической памяти зарезервировать место под стек заданной глубины. А если учесть, что в 360 одновременно могло исполняться 15 заданий (+ сам супервизор), резервирование памяти под стек для заданий при запуске в общем случае понижали общую пропускную способность системы.
Что бы не было недопонимания — под заданием подразумевается код, исполняющийся под конкретным (!=0x0) ключом защиты в PSW.
Re[24]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 22.10.09 12:48
Оценка:
Здравствуйте, kig, Вы писали:

kig>Речь о физической памяти? Если о ней — точно больше не станет.

kig>Или речь о механизме виртуальной памяти?

Виртуальной памяти в первых версиях OS/360 (MFT, MVT) не было. Впервые появилась ИМХО в OS/SVS для 370.
With best regards
Pavel Dvorkin
Re[25]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 22.10.09 14:13
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


kig>>Речь о физической памяти? Если о ней — точно больше не станет.

kig>>Или речь о механизме виртуальной памяти?

PD>Виртуальной памяти в первых версиях OS/360 (MFT, MVT) не было. Впервые появилась ИМХО в OS/SVS для 370.


После появления 370 с аппаратной поддержкой механизма виртуализации памяти первой ОС, которая этот механизм пользовала — была MVS/370 (70 год). А в 72 IBM выкатила сразу четверку — OS/VS1 (наследник MFT), SVS aka OS/VS2R1 (наследник MVT), DOS/VS (наследник DOS/360) и VM/370.

Ну а по поводу стека сказать что-нибудь?
Re[26]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.10.09 12:51
Оценка:
Здравствуйте, kig, Вы писали:

kig>После появления 370 с аппаратной поддержкой механизма виртуализации памяти первой ОС, которая этот механизм пользовала — была MVS/370 (70 год). А в 72 IBM выкатила сразу четверку — OS/VS1 (наследник MFT), SVS aka OS/VS2R1 (наследник MVT), DOS/VS (наследник DOS/360) и VM/370.


Все верно. После. А при проектировании 360 его "сослали". 370 еще не было.

kig>Ну а по поводу стека сказать что-нибудь?


Да то же самое. Не было тогда еще никакой виртуальной памяти, в 1964 году, когда первые модели 360 появились. И аппаратной поддержки не было, ты сам об этом пишешь. Если же говорить вообще о системе с ограниченной памятью — так в IBM PC на базе 80286 виртуальная память была (на основе LDT-GDT), хотя объем памяти был 1 Мб, как правило. Это не мешало выделить под стек свой сегмент размером не более 64 Кб. И стеки эти у разных задач (в смысле задач процессора 80286, которые реально в Windows 3.1 не использовались) были свои.
With best regards
Pavel Dvorkin
Re[27]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 26.10.09 14:47
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


kig>>После появления 370 с аппаратной поддержкой механизма виртуализации памяти первой ОС, которая этот механизм пользовала — была MVS/370 (70 год). А в 72 IBM выкатила сразу четверку — OS/VS1 (наследник MFT), SVS aka OS/VS2R1 (наследник MVT), DOS/VS (наследник DOS/360) и VM/370.


PD>Все верно. После. А при проектировании 360 его "сослали".


Если при проектировании сослали, где же стек в 360?

kig>>Ну а по поводу стека сказать что-нибудь?


PD>Да то же самое. Не было тогда еще никакой виртуальной памяти, в 1964 году, когда первые модели 360 появились. И аппаратной поддержки не было, ты сам об этом пишешь. Если же говорить вообще о системе с ограниченной памятью — так в IBM PC на базе 80286 виртуальная память была (на основе LDT-GDT), хотя объем памяти был 1 Мб, как правило. Это не мешало выделить под стек свой сегмент размером не более 64 Кб. И стеки эти у разных задач (в смысле задач процессора 80286, которые реально в Windows 3.1 не использовались) были свои.


Как то ты на 80286 переключился... Мы говорим вообще о системах с ограниченной памятью, или о 360, за "которую сослали"?

Так то же самое говоришь? Сравни — из первых трех продаваемых моделей — страшая из них — 40 могла иметь аж до 256 Кб. Память до 1 Мб появилась только в самых дорогих 65 и 75 моделях (конец 65 — начало 66). Вот здесь характерное замечание по поводу оперативной памяти уже более поздней эпохи (начало 70-х):

One interesting thing you might add to your 360/30 info is that in the early 70's a company in Edina Minnesota, Fabri-tek, manufactured core memory for IBM computers. 32K was about $40,000 dollars.


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

В MFT надо было сразу резервировать, сколько тебе памяти под задание отводить — и в этом случае, что стек, что не стек, память на задание сразу "кушалась". Запрос на динамическое выделение памяти возвращал адрес из остатка резерва — по сути куча на задание.

В MVT ситуация была другая. В ней, в отличии от MFT, было не только переменное кол-во разделов под задание, но и заказывать надо было возможный максимальный размер памяти на задание, который выделялся не сразу. И запрос на динамическое выделение памяти возвращал адрес из общей кучи, которая управлялась супервизором. Естественно, с учетом аппаратной защиты супервизор выделял память для каждого задания с наименьшей атомарность == странице (оффтоп: в PL/1 для этого был свой манагер памяти).

А теперь представь, как в MVT изменилось бы поведение, при многозадачной пакетной обработке, если бы при запуске задания необходимо было бы сразу резервировать непрерывное пространство памяти под стек. Как бы уменьшилась общая пропускная способность системы. Что для повышения пропускной способности необходимо было бы учеличивать общий объем оперативной памяти. И при этом не забудь учесть эпоху — стоимость памяти на начало проектирования и переспектив ее понижения. Кто тогда делал прогнозы, что стоимость оперативной памяти через 20 лет рухнет на порядки? Что те шкафы, которая и была ОП в 360, превратиться в сборку нескольких кристаллов (PC/AT)?
Re[28]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 27.10.09 05:06
Оценка:
Здравствуйте, kig, Вы писали:


kig>>>После появления 370 с аппаратной поддержкой механизма виртуализации памяти первой ОС, которая этот механизм пользовала — была MVS/370 (70 год). А в 72 IBM выкатила сразу четверку — OS/VS1 (наследник MFT), SVS aka OS/VS2R1 (наследник MVT), DOS/VS (наследник DOS/360) и VM/370.


PD>>Все верно. После. А при проектировании 360 его "сослали".


kig>Если при проектировании сослали, где же стек в 360?


Так зато и сослали, что не заложил


PD>>Да то же самое. Не было тогда еще никакой виртуальной памяти, в 1964 году, когда первые модели 360 появились. И аппаратной поддержки не было, ты сам об этом пишешь. Если же говорить вообще о системе с ограниченной памятью — так в IBM PC на базе 80286 виртуальная память была (на основе LDT-GDT), хотя объем памяти был 1 Мб, как правило. Это не мешало выделить под стек свой сегмент размером не более 64 Кб. И стеки эти у разных задач (в смысле задач процессора 80286, которые реально в Windows 3.1 не использовались) были свои.


kig>Как то ты на 80286 переключился... Мы говорим вообще о системах с ограниченной памятью, или о 360, за "которую сослали"?


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

kig>Так то же самое говоришь? Сравни — из первых трех продаваемых моделей — страшая из них — 40 могла иметь аж до 256 Кб. Память до 1 Мб появилась только в самых дорогих 65 и 75 моделях (конец 65 — начало 66). Вот здесь характерное замечание по поводу оперативной памяти уже более поздней эпохи (начало 70-х):


Да, знаю. Джермейна я еще не забыл


kig>А теперь вернемся к началу 60 годов, операционках для 360 и стеку.


kig>В MFT надо было сразу резервировать, сколько тебе памяти под задание отводить — и в этом случае, что стек, что не стек, память на задание сразу "кушалась". Запрос на динамическое выделение памяти возвращал адрес из остатка резерва — по сути куча на задание.


kig>В MVT ситуация была другая. В ней, в отличии от MFT, было не только переменное кол-во разделов под задание, но и заказывать надо было возможный максимальный размер памяти на задание, который выделялся не сразу.


Сразу он выделялся. Команду DA я хорошо помню. Да и как можно не сразу выделить при отсутствии виртуальной памяти ? куда потом расширять ? Не было там перераспределения памяти. А вот число разделов, да, было переменным.

Вот, кстати (выделено мной)

It treated all memory not used by the operating system as a single pool from which contiguous "regions" could be allocated as required by an indefinite number of simultaneous application programs. This scheme was more flexible than MFT's and in principle used memory more efficiently, but was liable to fragmentation — after a while one could find that, although there was enough spare memory in total to run a program, it was divided into separate chunks none of which was large enough.[2]

http://en.wikipedia.org/wiki/OS/360#cite_note-AuslanderJaffeIBMVSOSsDAT-1

Если бы можно было выделять не непрерывные участки — какая такая фрагментация могда бы мешать ?

>И запрос на динамическое выделение памяти возвращал адрес из общей кучи, которая управлялась супервизором.


Хм. Если бы это было так, то неизбежно память выделялась бы задаче кусками, фрагментами. Но я прекрасно помню, что по команде DA показывался адрес начала и размер, то есть один кусок.

>Естественно, с учетом аппаратной защиты супервизор выделял память для каждого задания с наименьшей атомарность == странице (оффтоп: в PL/1 для этого был свой манагер памяти).


Не помню про страницы, ИМХО их не было вообще. Были какие-то блоки с ключами защиты. Впрочем, не помню точно.

kig>А теперь представь, как в MVT изменилось бы поведение, при многозадачной пакетной обработке, если бы при запуске задания необходимо было бы сразу резервировать непрерывное пространство памяти под стек. Как бы уменьшилась общая пропускная способность системы. Что для повышения пропускной способности необходимо было бы учеличивать общий объем оперативной памяти. И при этом не забудь учесть эпоху — стоимость памяти на начало проектирования и переспектив ее понижения. Кто тогда делал прогнозы, что стоимость оперативной памяти через 20 лет рухнет на порядки? Что те шкафы, которая и была ОП в 360, превратиться в сборку нескольких кристаллов (PC/AT)?


Поскольку память выделялась отдельным непрерывным участком, от того, что к части ее доступ был бы по стековому механизму, ничего в плане потребностей по памяти не изменилось бы.
With best regards
Pavel Dvorkin
Re: Есть ли будущее у Native Code?
От: TimurSPB Интернет  
Дата: 27.10.09 20:54
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Вопрос из серии:
Есть ли будущее у программистов, или их вытеснит искусственный интеллект?
Make flame.politics Great Again!
Re[29]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 29.10.09 16:08
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

[]

kig>>В MVT ситуация была другая. В ней, в отличии от MFT, было не только переменное кол-во разделов под задание, но и заказывать надо было возможный максимальный размер памяти на задание, который выделялся не сразу.


PD>Сразу он выделялся. Команду DA я хорошо помню.


Да. Ты прав. Разделяемая память только в MVS появилась, но там уже виртуальная память была.
Так что все соображения по поводу стека и резервирования памяти снимаются

PD>Да и как можно не сразу выделить при отсутствии виртуальной памяти ? куда потом расширять ? Не было там перераспределения памяти. А вот число разделов, да, было переменным.


Ниже.

PD>Вот, кстати (выделено мной)


PD>It treated all memory not used by the operating system as a single pool from which contiguous "regions" could be allocated as required by an indefinite number of simultaneous application programs. This scheme was more flexible than MFT's and in principle used memory more efficiently, but was liable to fragmentation — after a while one could find that, although there was enough spare memory in total to run a program, it was divided into separate chunks none of which was large enough.[2]


PD>http://en.wikipedia.org/wiki/OS/360#cite_note-AuslanderJaffeIBMVSOSsDAT-1


PD>Если бы можно было выделять не непрерывные участки — какая такая фрагментация могда бы мешать ?


>>И запрос на динамическое выделение памяти возвращал адрес из общей кучи, которая управлялась супервизором.


PD>Хм. Если бы это было так, то неизбежно память выделялась бы задаче кусками, фрагментами. Но я прекрасно помню, что по команде DA показывался адрес начала и размер, то есть один кусок.


Для того, что бы реализовать такой механизм (алгоритм), ничего придумывать. Он уже в MVT был. По сути, тот же, который выделяет непрерывные участки под разделы. И потом смежные "дырки" схлопывает в непрерывный участок. Правда, это бы еще больше увеличило фрагментацию памяти.

>>Естественно, с учетом аппаратной защиты супервизор выделял память для каждого задания с наименьшей атомарность == странице (оффтоп: в PL/1 для этого был свой манагер памяти).


PD>Не помню про страницы, ИМХО их не было вообще. Были какие-то блоки с ключами защиты. Впрочем, не помню точно.


Были. По 2К (возможно на старших моделях — по 4К. В 370 — точно по 4К).

[]

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


Да. Согласен.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.