Здравствуйте, Cyberax, Вы писали:
C>Да. Но другой вопрос: а нужно ли нам это?
Да.
C>Практически оказалось, что гранулярности с точностью до процесса нам вполне достаточно.
Ага... то-то постоянно всякие переполнения буфера находят...
C>В конце концов, в самом .NET тоже мало кто использует CAS внутри прикладного кода для чего-то своего — обычно просто есть разделение на "системный" и прикладной код.
В .NET практически 100% кода safe.
А в safe коде никаких проездов нет и быть не может.
А что касается CAS то это очередной костыль и при правильной системе типов он вобще не нужен.
C>Ну так он уже на ARMах реализован.
Еще раз прочитай то что я написал.
C>С какой строгостью?
100%
C>Тупую проверку, что они все обязательно будут под локом не считаем.
Что значит тупую проверку?
Для изменяемых данных всегда нужно проверять верность синхронизации.
Так что под твою фразу можно подвести что угодно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pzz, Вы писали:
Pzz>Ну т.е., криптографика какая-нибудь, которая сочетает замысловатые вычисления с активным использованием полувычисленного в качестве индекса в таблице, будет работать медленно, т.к. все время придется "вручную" проверять выход за границу таблицы.
С индексом размером байт по таблице из 256 элементов?
Так такая проверка устраняется на раз.
Pzz>И то же самое относится к обработке изображения и звука.
Не скажу за звук я с ним дел не имел но про обработку изображений ты гонишь.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Да. Но другой вопрос: а нужно ли нам это? WH>Да.
Ну, ты знаешь мой ответ
C>>Практически оказалось, что гранулярности с точностью до процесса нам вполне достаточно. WH>Ага... то-то постоянно всякие переполнения буфера находят...
А пофиг. Главное от них повреждения уменьшить.
C>>В конце концов, в самом .NET тоже мало кто использует CAS внутри прикладного кода для чего-то своего — обычно просто есть разделение на "системный" и прикладной код. WH>В .NET практически 100% кода safe.
Да? И ты захочешь дать какому-нибудь Silverlight-приложению доступ ко всей файловой системе?
C>>Ну так он уже на ARMах реализован. WH>Еще раз прочитай то что я написал.
Что именно?
C>>С какой строгостью? WH>100%
Я имею в виду, он будет понимать, например, самопальные механизмы синхронизации?
WH>Для изменяемых данных всегда нужно проверять верность синхронизации. WH>Так что под твою фразу можно подвести что угодно.
Объясню чуть позже, сейчас занят.
Здравствуйте, squid, Вы писали:
S>DirectShowLib это доказывает. Там ведь просто куча интерфейсов, весь код выполняется в недрах... Другое дело — писать фильтры, где будет реальная обработка видео, например. Но их никто на C# писать и не призывает.
У нас вообще тема беседы заключается в том, чего стоит защита памяти методом managed code в терминах производительности.
То, что производительность нужна не всегда, это очевидно.
Здравствуйте, Cyberax, Вы писали:
WH>>Ага... то-то постоянно всякие переполнения буфера находят... C>А пофиг. Главное от них повреждения уменьшить.
Ну ты знаешь мой ответ.
C>Да? И ты захочешь дать какому-нибудь Silverlight-приложению доступ ко всей файловой системе?
А с чего ты взял что он ее получит?
Его даже браузер не получит.
WH>>Еще раз прочитай то что я написал. C>Что именно?
Что хард будет всегда быстрее софтовых проверок.
Тем более что для того чтобы хард вобще что-то проверял с гранулярностью мельче чем процесс нужна помощь софта...
Проверки же софтовой защиты всегда тотальны. Ни один бит не пропустит.
C>Я имею в виду, он будет понимать, например, самопальные механизмы синхронизации?
Что значит самопальные?
Ручками на асме что-ли?
Так на асме тебе никто ничего писать не даст. Ибо дырища огромадная.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
C>>Я имею в виду, он будет понимать, например, самопальные механизмы синхронизации? WH>Что значит самопальные? WH>Ручками на асме что-ли? WH>Так на асме тебе никто ничего писать не даст. Ибо дырища огромадная.
Зачем на асме ? Есть дельцы которые пишут вещи вроде SuspendThread ResumeThread
Здравствуйте, DOOM, Вы писали:
DOO>Да и в книге дракона написано, что оптимизация идет на стадии кодогенерации, а не синтаксического анализа или трансляции.
Я в свое время читал про то, как оптимизация делается в gcc. Там есть несколько проходов, некоторые используют синтаксическое дерево, некоторые — RTL (грубо говоря, некий внутренний эквиавалент байт-кода). Сейчас, наверное, все уже поменялось, но вряд ли в сторону упрощения
Здравствуйте, Sinclair, Вы писали:
Pzz>>За счет чего сингулярити дает 100% гарантию? Какие при этом налагаются ограничения? S>Предлагаю пойти и прочитать одну обзорную статью про Singulrity, чтобы не задавать в тридцатый раз дурацкие вопросы.
Интересно, что никто из защитников сингулярити так и не смог ответить на этот вопрос. Из чего я делаю вывод, что он не столь уж и дурацкий.
Общий совет на будущее: не надо рекламировать технологию, про которую вы не можете в нескольких предложениях рассказать ее суть. Выглядит несерьезно.
Здравствуйте, Sinclair, Вы писали:
Pzz>>Я тогда не очень понимаю. Если я могу использовать массивы и могу вычислять индекс в массиве, каким образом статически можно доказать, что я не выскочу за пределы массива? S>Это не имеет отношения к теме. Аппаратная защита контролем границ массивов не занимается. И вряд ли когда-нибудь будет — слишком дорого.
Аппаратная защита позволяет изолировать программы друг от друга. При вылете за границы массива страдает только та программа, которая вылетела.
Если же не использовать аппаратную защиту, придется строго контроллировать вылет за границы массивов. Поэтому сравнивать эффективность аппаратной защиты с софтверной защитой памяти внутри процесса вполне уместно.
Здравствуйте, WFrag, Вы писали:
WF>В компиляторе он тоже есть, на более высоком уровне. Если ты попробуешь вызвать на объекте метод, которого у него нет, тебе компилятор об этом сразу скажет и программа не скомпилируется.
Это понятно. Но если существует более-менее надежный способ отследить выход за границу массива и т.п. путем анализа программы, я хочу об этом услышать при компиляции, а не от изумленного пользователя. Это гораздо более пристальный анализ программы, чем контроль за соблюдением интерфейсов.
Здравствуйте, Pzz, Вы писали:
Pzz>Я в свое время читал про то, как оптимизация делается в gcc. Там есть несколько проходов, некоторые используют синтаксическое дерево, некоторые — RTL (грубо говоря, некий внутренний эквиавалент байт-кода). Сейчас, наверное, все уже поменялось, но вряд ли в сторону упрощения
RTL сейчас используется для самых низкоуровневых оптимизаций — распределения регистров, распараллеливания по конвейеру и т.п.
Всё остальное делается на уровне Tree-SSA. Но код LLVM в него отображается тривиально (собственно, оно так и работает внутри).
Здравствуйте, WolfHound, Вы писали:
C>>Да? И ты захочешь дать какому-нибудь Silverlight-приложению доступ ко всей файловой системе? WH>А с чего ты взял что он ее получит? WH>Его даже браузер не получит.
Это я для примера того, что CAS в .NET уже вполне используется. Просто в ограниченном виде.
WH>Тем более что для того чтобы хард вобще что-то проверял с гранулярностью мельче чем процесс нужна помощь софта... WH>Проверки же софтовой защиты всегда тотальны. Ни один бит не пропустит.
А зачем? Лично мне вполне достаточно защиты на уровне процесса. С ограничением привиллегий процесса для предотвращения катастрофичных действий.
C>>Я имею в виду, он будет понимать, например, самопальные механизмы синхронизации? WH>Что значит самопальные? WH>Ручками на асме что-ли?
Нет.
public class BicycleMutex
{
private Object systemMutex="sdfjg";
private boolean locked;
public void lock()
{
synchronized(systemMutex)
{
locked=true;
}
}
public void unlock()
{
synchronized(systemMutex)
{
locked=false;
}
}
}
Понятно, что именно такой код — это ССЗБ, но оно может получатсья и в нормальных случаях (chain locking при работе со списками, например).
Здравствуйте, Cyberax, Вы писали:
C>Это я для примера того, что CAS в .NET уже вполне используется. Просто в ограниченном виде.
CAS в правильной системе не нужен. Его сделали мелкософты по тому что не осилили нормальную систему типов.
C>А зачем? Лично мне вполне достаточно защиты на уровне процесса. С ограничением привиллегий процесса для предотвращения катастрофичных действий.
А мне нет.
Я хочу просто взять код и просто его использовать и при этом быть уверенным что он ничего не поломает и никуда не пролезет.
C>Понятно, что именно такой код — это ССЗБ, но оно может получатсья и в нормальных случаях (chain locking при работе со списками, например).
Чё?
А то я что-то в гугле запрос подобрать не могу.
Все на производителей противоугонок для лесопедов попадаю.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pzz, Вы писали:
Pzz>Интересно, что никто из защитников сингулярити так и не смог ответить на этот вопрос. Из чего я делаю вывод, что он не столь уж и дурацкий.
Тебе уже несколько раз на него отвечали.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Это я для примера того, что CAS в .NET уже вполне используется. Просто в ограниченном виде. WH>CAS в правильной системе не нужен. Его сделали мелкософты по тому что не осилили нормальную систему типов.
У меня подозрение есть, что CAS нужен при наличии статических переменных.
C>>А зачем? Лично мне вполне достаточно защиты на уровне процесса. С ограничением привиллегий процесса для предотвращения катастрофичных действий. WH>А мне нет. WH>Я хочу просто взять код и просто его использовать и при этом быть уверенным что он ничего не поломает и никуда не пролезет.
И при этом лишиться возможности вставить хитрый трюк с менеджером памяти?
Да ни за что!
C>>Понятно, что именно такой код — это ССЗБ, но оно может получатсья и в нормальных случаях (chain locking при работе со списками, например). WH>Чё? WH>А то я что-то в гугле запрос подобрать не могу.
Вот здесь есть: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html
WH>Все на производителей противоугонок для лесопедов попадаю.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, DOOM, Вы писали:
S>>>Это не имеет отношения к теме. Аппаратная защита контролем границ массивов не занимается. И вряд ли когда-нибудь будет — слишком дорого. DOO>>Как это не имеет? Если у всех процессов общая память должны же быть гарантии, что один процесс не съест все остальные... C>А как он это может сделать?
Как-как... Прозвучало же сомнение в том, что это вообще надо делать.
Здравствуйте, Cyberax, Вы писали:
C>У меня подозрение есть, что CAS нужен при наличии статических переменных.
А у меня есть подозрение что статические переменные не нужны
Они вобще много чему мешают и ничего не дают.
C>И при этом лишиться возможности вставить хитрый трюк с менеджером памяти?
А зачем?
Тем более что системный менеджер памяти может хитрить так что мало не покажется.
WH>>А то я что-то в гугле запрос подобрать не могу. C>Вот здесь есть: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html
"chain locking": you acquire the lock of node A, then node B, then release A and acquire C, then release B and acquire D and so on.
Это в моей системе типов сделать можно.
Причем недолочить или недоразлочить тебе система типов не позволит. Ибо если что-то забудешь то просто типы не совпадут и как следствие получишь от компилятора по рукам.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
Pzz>>Интересно, что никто из защитников сингулярити так и не смог ответить на этот вопрос. Из чего я делаю вывод, что он не столь уж и дурацкий. WH>Тебе уже несколько раз на него отвечали.
Пока что мне отвечают на него в духе:
— как проверяются границы массивов?
— с помощью статического анализа
— а статический анализ как их проверяет?
— с помощью системы типов
— а система типов как проверяет?
— а система типов это гарантирует
— а за счет чего она это гарантирует?
— за счет статического анализа
Здравствуйте, Pzz, Вы писали:
Pzz>Это понятно. Но если существует более-менее надежный способ отследить выход за границу массива и т.п. путем анализа программы, я хочу об этом услышать при компиляции, а не от изумленного пользователя. Это гораздо более пристальный анализ программы, чем контроль за соблюдением интерфейсов.
1)Изумленного пользователя не будет. Ибо если в программе все типы совпали ее просто отправят на исполнение. Ауж что там соптимизировалось, а что нет пользователя волновать не будет.
2)Если захочешь посмотреть сам что удалось устранить, а что нет то никто не мешает написать оптимизатор так чтобы он делал отчет об оптимизации если его просят.
А если до пользователя дошол битый или сгенеренный хакером бинарник то система его просто не примит к исполнению.
Это сильно другой случай нежели оптимизации доступа к массиву.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
