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

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

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

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

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

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

Pzz>Я верю, когда мне сообщают простые проверяемые факты. Когда же мне сообщают выводы из них, мне хочется знать, на каком основании такие выводы были сделаны. Нормальный такой научный подход.
Вот тебе простой и проверяемый факт: В C# однопоточный код без unsafe и/или нативного кода проехатся по памяти не может.

В более совершенной системе типов можно гарантировать отсутствие рейскондишенев.

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

C>>У меня подозрение есть, что CAS нужен при наличии статических переменных.
WH>А у меня есть подозрение что статические переменные не нужны
Я полностью согласен. Без них у нас получается классическая capability-based security, для которой даже доказана невозможность несанкционированого доступа.

WH>Они вобще много чему мешают и ничего не дают.
Но тем не менее, всё равно нужны на практике. Хотя бы в виде thread-local переменных.

C>>И при этом лишиться возможности вставить хитрый трюк с менеджером памяти?
WH>А зачем?
WH>Тем более что системный менеджер памяти может хитрить так что мало не покажется.
Я всё равно умнее менеджера Ну не хочется терять дополнительную гибкость.

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

C>>Вот здесь есть: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html
WH>

"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.

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

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

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

Pzz>>Я верю, когда мне сообщают простые проверяемые факты. Когда же мне сообщают выводы из них, мне хочется знать, на каком основании такие выводы были сделаны. Нормальный такой научный подход.
WH>Вот тебе простой и проверяемый факт: В C# однопоточный код без unsafe и/или нативного кода проехатся по памяти не может.

Этому я верю, нет проблем. Неочевидным утверждением является то, что это implementable без заметного performance penalty.

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

Pzz>Этому я верю, нет проблем. Неочевидным утверждением является то, что это implementable без заметного performance penalty.
Это лишь вопрос оптимизации.
Скажем C# уже быстрее очень многих нативных компиляторов.
Факт медицинский.

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

C>Но тем не менее, всё равно нужны на практике. Хотя бы в виде thread-local переменных.
Зачем?
Не вижу смысла.

C>Я всё равно умнее менеджера Ну не хочется терять дополнительную гибкость.
А нафига она тебе?

C>В принципе, я не против гибридной системы, сочетающей достоинства обоих систем.
А есть ли достоинства у натива?
Вот в чем вопрос.

C>Т.е. нативное микроядро,
Нативность ему нафиг не упала.

C>сверхбыстрый переключатель контекстов, обычная runtime-система для обычных приложений, и общий разделяемый runtime для управляемого кода.
А нафига нам "обычные" приложения?

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

C>А как это выглядит, примерно?
Я еще недодумал несколько смежных решений.
Так что какнибудь в другой раз когда додумаю.

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

Pzz>У нас вообще тема беседы заключается в том, чего стоит защита памяти методом managed code в терминах производительности.

Pzz>То, что производительность нужна не всегда, это очевидно.

ну, я просто увидел что то что написано не правда и сказал как на самом деле

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

C>>Но тем не менее, всё равно нужны на практике. Хотя бы в виде thread-local переменных.
WH>Зачем?
WH>Не вижу смысла.
Для протаскивания вещей типа текущей локали или авторизованого пользователя через слои, которые об этом не думают.

C>>Я всё равно умнее менеджера Ну не хочется терять дополнительную гибкость.
WH>А нафига она тебе?
Для гибкости, не понятно, что ли?

C>>В принципе, я не против гибридной системы, сочетающей достоинства обоих систем.
WH>А есть ли достоинства у натива?
WH>Вот в чем вопрос.
Для хардкорной криптографии, обработки данных, работы с SIMD, и прочих CUDA — думаю, что да.

C>>Т.е. нативное микроядро,
WH>Нативность ему нафиг не упала.
Управляемость тоже. Если это настоящее микроядро — то код можно будет под микроскопом вылизать. Вон, у QNX микроядро до недавнего времени в 11Кб машинного кода укладывалось.

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

C>>сверхбыстрый переключатель контекстов, обычная runtime-система для обычных приложений, и общий разделяемый runtime для управляемого кода.
WH>А нафига нам "обычные" приложения?
1) Legacy. Ни куда от него не деться.
2) Скорость.

C>>Я просто точно помню, что там был сценарий, когда наивная проверка блокировок не срабатывает. Сейчас попробую вспомнить его
WH>Попробуй.
Пробую. Один сценарий уже нашёл Вечером на свежую голову напишу.

C>>А как это выглядит, примерно?
WH>Я еще недодумал несколько смежных решений.
WH>Так что какнибудь в другой раз когда додумаю.

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

C>Для протаскивания вещей типа текущей локали
Так и запишем: Для объезда кривой архитектуру путем еще большего скривления архитектуры.
Вот скажи нахрена тебе локаль в коде который не занимается юзер интерфейсом?

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

C>>>Я всё равно умнее менеджера Ну не хочется терять дополнительную гибкость.
WH>>А нафига она тебе?
C>Для гибкости, не понятно, что ли?
Не понятно.

C>Для хардкорной криптографии, обработки данных, работы с SIMD, и прочих CUDA — думаю, что да.
А я думаю что нет.

C>Управляемость тоже. Если это настоящее микроядро — то код можно будет под микроскопом вылизать. Вон, у QNX микроядро до недавнего времени в 11Кб машинного кода укладывалось.
Так пусть его еще и верификатор повылизывает.

C>Скажем, драйвер видеокарты с ускорителем смысла писать на управляемом коде нет.
C>А вот драйвер клавиатуры вполне нормально как раз на управляемом коде можно написать.
А чем драйвер видюхи хуже чем драйвер клавиатуры?

C>1) Legacy. Ни куда от него не деться.
Тут можно просто завиртуалить.
Причем когда процессоры наконец забъют на x86 можно будет софтварно код JIT'ить.

C>2) Скорость.
Ой не факт.
Пока что тот же C# сливает только там где нужно исползовать те же SMID и только по тому что JIT не обучен.
Если обучить то будет примерно то же самое.

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

C>>Для протаскивания вещей типа текущей локали
WH>Так и запишем: Для объезда кривой архитектуру путем еще большего скривления архитектуры.
WH>Вот скажи нахрена тебе локаль в коде который не занимается юзер интерфейсом?
Банально ошибку "нарушена ссылочная целостность" сформировать из БД. Да много где так оно нужно по мелочам, особенно в существующем коде.

C>>или авторизованого пользователя через слои, которые об этом не думают.
WH>Пусть думают. Ибо иначе получаем дырявое решето типа современного софта ничиная с ОСей и заканчивая браузерами.
На самом деле, скажем, для всяких серверов — это достаточно нормальное решение. Связывание с контекстом транзакции в app-сервере — это вообще классика.

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

C>>Для гибкости, не понятно, что ли?
WH>Не понятно.
Для игрушки написать свой GC, например, чтобы не тормозило в ненужные моменты. И т.п.

C>>Управляемость тоже. Если это настоящее микроядро — то код можно будет под микроскопом вылизать. Вон, у QNX микроядро до недавнего времени в 11Кб машинного кода укладывалось.
WH>Так пусть его еще и верификатор повылизывает.
Он там особо многого не даст. Проверить, что обращения к массивам всегда защищены — это даже на С++ можно без проблем.

C>>А вот драйвер клавиатуры вполне нормально как раз на управляемом коде можно написать.
WH>А чем драйвер видюхи хуже чем драйвер клавиатуры?
Драйверу видюхи нужно заниматься очень большим количеством магии в секунду — работой в нескольких адресных пространствах, работой с аппаратными регистрами и т.д. Посмотри какой-нибудь открытый видеодрайвер на досуге.

C>>1) Legacy. Ни куда от него не деться.
WH>Тут можно просто завиртуалить.
WH>Причем когда процессоры наконец забъют на x86 можно будет софтварно код JIT'ить.
Ну завиртуализировал. Что дальше? Нужно будет давать им доступ до файловой системы хоста, части устройств. Вот тут-то и получится, что мы снова изобретём мою гибридную схему.

WH>Пока что тот же C# сливает только там где нужно исползовать те же SMID и только по тому что JIT не обучен.
WH>Если обучить то будет примерно то же самое.
Не будет. В GCC оно уже несколько лет умеет SIMD использовать. Результаты — далеко не блестящие.

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

C>Банально ошибку "нарушена ссылочная целостность" сформировать из БД.
Это уровень UI.
Внутри программы должен гулять структуированный объект по которому на уровне UI можно сформировать сообщение на любом языке.

C>Да много где так оно нужно по мелочам,
Где?

C>особенно в существующем коде.
Ага в кривом коде.
Ибо если бы он был прямым то это было бы не нужно.

C>На самом деле, скажем, для всяких серверов — это достаточно нормальное решение. Связывание с контекстом транзакции в app-сервере — это вообще классика.
И? Нафига тут статические переменные?

C>Для игрушки написать свой GC, например, чтобы не тормозило в ненужные моменты. И т.п.
Ты это серьезно?

C>Он там особо многого не даст. Проверить, что обращения к массивам всегда защищены — это даже на С++ можно без проблем.
Ну это если его на жабке писать.
А с более другими системами типов можно еще много чего проверить.

C>Драйверу видюхи нужно заниматься очень большим количеством магии в секунду — работой в нескольких адресных пространствах, работой с аппаратными регистрами и т.д. Посмотри какой-нибудь открытый видеодрайвер на досуге.
И зачем тут натив?

C>Не будет. В GCC оно уже несколько лет умеет SIMD использовать. Результаты — далеко не блестящие.
Есть еще Интеловский компилятор.

Да и сама по себе идея SMID какаято странная.
Особенно при приближении chip multithreading'а.

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

Pzz>Тем не менее, FAQ про DirectShow есть вопрос, будет ли DirectShow доступен через managed код. Ответ — "нет", по причинам произвидительности. Я думаю, это честный ответ.

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

Доступ к DirectShow из managed кода давно есть — через упомянутую managed библиотеку, которая инкапсулирует COM Interop. Иначе и не получится, т.к. DirectShow состоит из кучи нативных COM компонентов, а реализовывать 'a "Managed DirectShow" platform' у MS планов нет, о чем там и говорится.

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

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

Pzz>А так, я вообще с симпатией отношусь ко всяким там теоретическим игрушкам. Plan9, Inferno, Singularity. Haskell опять же. Уважаю, да. Я не какой-нибудь там мракобес . Мелкософт уважаю немного меньше, потому что я не слышал до сих пор, чтобы что-нибудь заметное в computer science из них вывалилось.

В MS работает S.P.Jones, из которого кое-что вываливалось.

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

C>>Это я для примера того, что CAS в .NET уже вполне используется. Просто в ограниченном виде.
WH>CAS в правильной системе не нужен. Его сделали мелкософты по тому что не осилили нормальную систему типов.

Какая связь между CAS и системой типов?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Какая связь между CAS и системой типов?
Прямая.
Тупая система типов .NET не может запретить кому попало лезть куда попало по этому ей нужен CAS.
Более умная система типов может.
И как следствие ей CAS не нужен.

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

C>>Банально ошибку "нарушена ссылочная целостность" сформировать из БД.
WH>Это уровень UI.
WH>Внутри программы должен гулять структуированный объект по которому на уровне UI можно сформировать сообщение на любом языке.
Так где оно может возникнуть — может не быть возможности найти слой UI.

C>>Да много где так оно нужно по мелочам,
WH>Где?
Я люблю делать софт красиво, и у меня в системе "ни одного гвоздя" — в смысле в программе нет ни одной статической переменной.

Точнее, есть одна — последнее зафокусированое окно. Оно нужно для того, чтобы показать в случае чего диалог с ошибкой.

C>>особенно в существующем коде.
WH>Ага в кривом коде.
WH>Ибо если бы он был прямым то это было бы не нужно.
Да я не спорю. Но кривой код — это часть жизни.

C>>На самом деле, скажем, для всяких серверов — это достаточно нормальное решение. Связывание с контекстом транзакции в app-сервере — это вообще классика.
WH>И? Нафига тут статические переменные?
Не совсем статические, а thread-local.

C>>Для игрушки написать свой GC, например, чтобы не тормозило в ненужные моменты. И т.п.
WH>Ты это серьезно?
А почему нет? Вот сейчас написал для программы на С++ свой упаковывающий GC. Аж посмотреть приятно.

C>>Он там особо многого не даст. Проверить, что обращения к массивам всегда защищены — это даже на С++ можно без проблем.
WH>Ну это если его на жабке писать.
WH>А с более другими системами типов можно еще много чего проверить.
Лучшая идея тут — доказать корректность ядра. Это должно быть как раз в пределах реального (http://www.cse.unsw.edu.au/~kleing/papers/os-overview.pdf).

C>>Драйверу видюхи нужно заниматься очень большим количеством магии в секунду — работой в нескольких адресных пространствах, работой с аппаратными регистрами и т.д. Посмотри какой-нибудь открытый видеодрайвер на досуге.
WH>И зачем тут натив?
Там слишком много низкоуровневых трюков. Типа получения адреса с регистра и разыменование по нему данных в основной памяти.

C>>Не будет. В GCC оно уже несколько лет умеет SIMD использовать. Результаты — далеко не блестящие.
WH>Есть еще Интеловский компилятор.
Однофигственно.

WH>Да и сама по себе идея SMID какаято странная.
WH>Особенно при приближении chip multithreading'а.
"chip"=="cheap"? Идея SIMD вполне нормальная — мы выполняем операции сразу с вектором значений.

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

C>Так где оно может возникнуть — может не быть возможности найти слой UI.
Значит пользователь его не увидит.
И как следствие локаль не нужна.

C>>>Да много где так оно нужно по мелочам,
WH>>Где?
C>Я люблю делать софт красиво, и у меня в системе "ни одного гвоздя" — в смысле в программе нет ни одной статической переменной.
Тебе не нужно.
Мне не нужно.
И вобще хорошие программисты както без них всегда обходятся.
Спрашивается нафига козе баян если мы без этого баяна можем доказывать кучу замечательных теоремм?

C>Точнее, есть одна — последнее зафокусированое окно. Оно нужно для того, чтобы показать в случае чего диалог с ошибкой.
Это зависит исключительно от дизайна GUI.
Уверен можно и без этого.

C>Да я не спорю. Но кривой код — это часть жизни.
А кто спорит.
Другое дело что возможность запретить довольно большому классу кривостей компилироваться то код станет прямее.

C>Не совсем статические, а thread-local.
Один хрен.

C>А почему нет? Вот сейчас написал для программы на С++ свой упаковывающий GC. Аж посмотреть приятно.
А жабу взять не проще?

C>Лучшая идея тут — доказать корректность ядра. Это должно быть как раз в пределах реального (http://www.cse.unsw.edu.au/~kleing/papers/os-overview.pdf).
Лучше доказать все что вобще можно доказать.

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

C>"chip"=="cheap"?
Нет.
http://developers.sun.com/solaris/articles/chip_multi_thread.html

C>Идея SIMD вполне нормальная — мы выполняем операции сразу с вектором значений.
А нафига?
Операция над вектором из N элементов занимает примерно столько же транзисторов сколько возможность спарить N операций по одному элементу. Или я не прав?

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

C>>Так где оно может возникнуть — может не быть возможности найти слой UI.
WH>Значит пользователь его не увидит.
WH>И как следствие локаль не нужна.
Надо же что-то пользователю показать перед тем как рухнуть полностью.

WH>И вобще хорошие программисты както без них всегда обходятся.
WH>Спрашивается нафига козе баян если мы без этого баяна можем доказывать кучу замечательных теоремм?
Я ещё о другом подумал. Ладно, убрали статические переменные. Вместо них везде передаётся структура AppContext со свойствами типа currentLocale, authorizedUser, ...

Но что делать, если я захочу передать ссылку на эту структуру "враждебному" коду? Просто так её передавать нельзя.

C>>Точнее, есть одна — последнее зафокусированое окно. Оно нужно для того, чтобы показать в случае чего диалог с ошибкой.
WH>Это зависит исключительно от дизайна GUI.
WH>Уверен можно и без этого.
Можно. Но получается уже некрасиво — нужно вводить искусственный менеджер окон

C>>Не совсем статические, а thread-local.
WH>Один хрен.
Угу.

C>>А почему нет? Вот сейчас написал для программы на С++ свой упаковывающий GC. Аж посмотреть приятно.
WH>А жабу взять не проще?
Не проще. Было бы проще — прикрутил бы какой-нибудь Питон через boost::python.

C>>Лучшая идея тут — доказать корректность ядра. Это должно быть как раз в пределах реального (http://www.cse.unsw.edu.au/~kleing/papers/os-overview.pdf).
WH>Лучше доказать все что вобще можно доказать.
Там не так уж много нужно доказать, на самом деле.

C>>"chip"=="cheap"?
WH>Нет.
WH>http://developers.sun.com/solaris/articles/chip_multi_thread.html
Ага, понял — то о чём я не так давно поспорил с Gaperton'ом

C>>Идея SIMD вполне нормальная — мы выполняем операции сразу с вектором значений.
WH>А нафига?
WH>Операция над вектором из N элементов занимает примерно столько же транзисторов сколько возможность спарить N операций по одному элементу. Или я не прав?
Не прав. Векторные операции существенно дешевле за счёт того, что последовательность команд имеет существенно больше степеней свободы, чем одна фиксированная команда. Тут самый экстремальный пример — это видеокарты.

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

C>Надо же что-то пользователю показать перед тем как рухнуть полностью.
Пользователю можно что-то показать только на уровне UI. А на уровне UI у нас есть локаль.

C>Я ещё о другом подумал. Ладно, убрали статические переменные. Вместо них везде передаётся структура AppContext со свойствами типа currentLocale, authorizedUser, ...
Ой не факт что ее везде нужно передовать.
К тому же опять нафига тебе currentLocale?

C>Но что делать, если я захочу передать ссылку на эту структуру "враждебному" коду? Просто так её передавать нельзя.
Ну так не передавай.
Передай урезанный по самые не балуйся контекст и все.

C>Можно. Но получается уже некрасиво — нужно вводить искусственный менеджер окон
Как по мне слова "статическая переменная" и "красиво" совершенно не совместимы.

C>Не проще. Было бы проще — прикрутил бы какой-нибудь Питон через boost::python.
А что ты там такое делаешь?

C>Не прав. Векторные операции существенно дешевле за счёт того, что последовательность команд имеет существенно больше степеней свободы, чем одна фиксированная команда.
Re[16]: Nehalem

Автор: Gaperton
Дата: 14.06.08

C>Тут самый экстремальный пример — это видеокарты.
С видюхами все несколько сложнее.
Там куча очень специализированных конвееров. Кешей итп.

А в случае когда есть выбор между одним элементом который умножает 2 пары чисел и 2мя элементами каждый из которых умножает одну пару чисел ИМХО разници практически нет.
Хотя тут нужно спросить железячников.