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

C>А почему "в сад" должен отправляться D, а не C#?
По тому что C# (если не использовать конструкцию unsafe которая на практике нафиг не упала) в отличии от D safe.

C>У них (как и у приложений для разработчиков) немного другой фокус. Корпоративные приложения используются для обеспечения работы компании и обычно неважно, что они занимают на 30Мб больше памяти — прибыль для корпорации важнее.
Допустим появились два приложения одно чуть быстрее, ест меньше памяти и иногда падает и второе чуть медленней, ест несколько больше памяти и работает стабильно.
Теперь нужно учесть что фичи во второе приложение будут добавлять быстрее да и немногочисленные ошибки долго жить не будут.
А теперь учтем что второе приложение появилось на пол года год раньше...
Как ты думаешь куда в конце концов уйдут пользователи?
Еще учти что процессоры все мощьнее и памяти все больше и она постоянно дешевеет.

C>А зачем вообще нужен .NET?
Чтобы проще и быстрее создовать болие качественные программы.

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

C>Kluev wrote:
>> C>Сингулярити не позволяет НАПРЯМУЮ использовать:
>> C>1. Машинный код и языки компилирующие в него.
>> C>2. Ручное управление памятью.
>> C>3. Виртуальную память (хотя, возможно, и добавят).
>> А файлы она в память умеет отображать?
C>Нет, так как защиты памяти там нет (все в нулевом кольце сидит и
C>работает с физическими адресами).

И в чем кайф? Отсуствие оверхеда на переходы kernespace-userspace и переключения контекстов.

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

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

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

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

C>>Kluev wrote:
>>> C>Сингулярити не позволяет НАПРЯМУЮ использовать:
>>> C>1. Машинный код и языки компилирующие в него.
>>> C>2. Ручное управление памятью.
>>> C>3. Виртуальную память (хотя, возможно, и добавят).
>>> А файлы она в память умеет отображать?
C>>Нет, так как защиты памяти там нет (все в нулевом кольце сидит и
C>>работает с физическими адресами).

В догонку к предыдущему сообщению.
Такая поделка будет работать если все обьекты имеют размер не более 1 страницы памяти (4-8к). В противном случае кода все зафрагментируется, получится так что памяти полно, а выделить большой кусок нельзя. Ну и кому нужно такое счастье?

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

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

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

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

C>Лично в моем проекте такие ошибки не создают ну абсолютно никаких проблем.
Ну и хорошо. Рад лично за тебя.


>> От ошибок в логике никто не застрахован, но их труднее сделать и они
>> быстрее всплывают.
C>Вот как раз обращения по неверному адресу всплывают сразу при тестировании.
Это если они простые. Если логика сложная (куча объектов, многопоточность),
то не сразу понятно есть ли там текущая память, это может и не сразу проявиться.

>> ИМХО Будет работать в своей виртуальной машине под управляемой ОС.
>> Как сейчас DOS и Win16 приложения.
C>При миграции DOS->Windows можно было использовать старый код без особых
C>проблем. В данном случае старый код придется переписать полностью весь.
Ты недооцениваешь развитие систем виртуализации.
Тот же DOS Extended mode ведь эмулируется?


>> C>Трассировка стека замечательно делается и без .NET, причем еще со времен
>> C> 70-х годов (core dump'ы).
>> Core Dump, если я правильно понимаю, снимок памяти процесса в тот
>> момент, когда он упал.
>> Ковырять его — удовольствие, я думаю, много ниже среднего .
C>Ага. Ведь приходится запускать отладчик и открывать его. А потом в
C>отладчике смотреть на все эти stacktrace'ы для всех потоков, фреймы
C>функций, значения локальных переменных.
Это если отладочная информация есть
+ прежде чем программа упадет она может так в памяти накосячить
что потом попробуй восстанови последовательность событий.

>> C> На Винде есть:
>> C>http://www.codeproject.com/debug/XCrashReportPt4.asp
>> Ага, если сам стек не запорчен, что сделать проще простого:
C>А это находится при первом тестировании с включеной проверкой стека. Или
C>с включеным Rational Purify.
А если выскочило после тестирования (без проверки стека)?

>> Адрес возврата запорчен и переход происходит непонятно куда
>> (точнее внизу видно, что на 0x0000024 ),
>> а так этим и злоумышленники пользуются.
C>И это элементарно отслеживается кучей тулзов.

>> Это здесь ошибку просто найти, а если между объявлением массива и его
>> использованием много кода?
C>Берется Purify или Valgring (намного лучше, но не работае на Винде) и
C>находится за минуту.

C>Вдобавок, Valgrind еще умеет и места race condition'ов находить в
C>многопоточных программах.
Да здорово, я не спорю.
Сам использую подобные инструменты.

Но дело в том, что все это используется во время отладки, а потом всего этого нет.
Бывает, что и в Debug и Release работает по-разному один и тот же код.

Если бы все было так неплохо, так Microsoft бы пачками патчи не выпускал.

>> C>2. Крупных десктопных приложений.
>> В Visual Studio 2005 много .NET кода (7,5M LOC):
>> здесь <http://weblogs.asp.net/JackieG/archive/2006/03/17/440456.aspx&gt;.
C>Ну не являются средства разработки приложениями для обычных конечных
C>пользователей.
Так тут были слова "крупный десктопный".

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

C>Lloyd wrote:
>>> > В Java и .NET перешли на JIT модель.
>> C>В Java — уже на HotSpot.
>> А в чем отличие HotSpot-а от JIT-а?
C>HotSpot производит постоянный мониторинг кода и производит адаптивную
C>оптимизацию. То есть один и тот же код может быть JIT-скомпилирован
C>несколько раз.
Ну я это понимаю как вариацию JITа.
Кстати по подобной схеме работает также Python Psyco.
А в общем виде это называется Dynamic recompilation.

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

C>Андрей Хропов wrote:
>>> > А как виртуальныя машина отменяет разнообразие языков? Единственное что
>>> > правильная ВМ отменяет всякие низкоуровневые языки которые не
>>> > контролируют то что делает программист. Но вот нужны ли такие языки?
>> C>Нужны.
>> Но для небольшого числа применений (в ядре ОС и драйверах).
C>А так же в:
C>1. Desktop-приложениях (оффисы, браузеры и т.п.)
C>2. Требовательных приложениях (CAD-системы, графические редакторы и т.п.)
C>3. Мелких утиллитах.
На данный момент — да.
Оверхед, привносимый .NET не позволяет его использовать в требовательных приложениях
(Я не представляю себе требования к памяти Photoshop на .NET ).
Но тем не менее в принципе, с развитием управляемых сред и появлением соответствующих ОС
ситуация может измениться.
Технологии компиляции развиваются, Java HotSpot в некоторых случаях уже может работать наравне с (или немногм уступая) C++ по скорости (см. здесь).
Я еще слышал, что планируют объекты, адрес которых никуда не передается, размещать в стеке.
Так что все это развивается.

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

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

C>>А почему "в сад" должен отправляться D, а не C#?
WH>По тому что C# (если не использовать конструкцию unsafe которая на практике нафиг не упала) в отличии от D safe.

C>>У них (как и у приложений для разработчиков) немного другой фокус. Корпоративные приложения используются для обеспечения работы компании и обычно неважно, что они занимают на 30Мб больше памяти — прибыль для корпорации важнее.
WH>Допустим появились два приложения одно чуть быстрее, ест меньше памяти и иногда падает и второе чуть медленней, ест несколько больше памяти и работает стабильно.

А давай лучше наоборот, первое и быстрое и не падает, а второе раз в полчаса демонстрирует стек и отправляет комп в глубокий swap
По моему личному опыту использования декстопных приложений их глюкавость практически не коррелирует с тем на чем программа написана, сталкивался и java приложениями с выше описанным поведением и С++ не разу не падал, и даже хуже того почему то написаные на питоне программы тоже бывают практически безглючными (а тут из динамики такое страх делают).

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

И тут тоже все не так однозначно, бывает и наооборот и нередко.

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

K>И в чем кайф? Отсуствие оверхеда на переходы kernespace-userspace и переключения контекстов.

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

K>В классических осях все просто, когда основная программа зафрагментировала все адрессное простарнство своего процесса, запускаем дополнительный процесс в котором можно хоть целый гиг неперывным куском хапнуть и он делает то что нужно. А тут что получается кто не успел тот опоздал? По сценариям доса шагают товарищи, кто первый загрузился тому и тапки?

Да... срочно читать про дефрагментирующие сборщики мусора.

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

K>А файлы она в память умеет отображать?
А зачем?

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

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

C>>Kluev wrote:
>>> C>Сингулярити не позволяет НАПРЯМУЮ использовать:
>>> C>1. Машинный код и языки компилирующие в него.
>>> C>2. Ручное управление памятью.
>>> C>3. Виртуальную память (хотя, возможно, и добавят).
>>> А файлы она в память умеет отображать?
C>>Нет, так как защиты памяти там нет (все в нулевом кольце сидит и
C>>работает с физическими адресами).

Еще раз в догонку.
Имхо, разделение системы на юзер-спейс и кернел-спейс, где каждый процесс получает свои законные 2 Гига (или другой обьем в зависимотси от архитектуры) является самым оптимальным решением. Все остальные поделки без виртуальной памяти нежизнеспособны или применимы в ограниченных условиях. Т.е. такие оси не универсальные. Имхо, в МС просто изобрели велосипед 40 летней девности для поездки по старым граблям.

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

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

FR>И тут тоже все не так однозначно, бывает и наооборот и нередко.
Это смотря кто пишет. Если комманды сравнимой квалификации то будет именно так как я описал. А если комманды разной квалификации то сранения теряет смысл.

Kluev wrote:
> В догонку к предыдущему сообщению.
> Такая поделка будет работать если все обьекты имеют размер не более 1
> страницы памяти (4-8к). В противном случае кода все зафрагментируется,
> получится так что памяти полно, а выделить большой кусок нельзя. Ну и
> кому нужно такое счастье?
Не совсем — там можно компактифицировать кучу с помощью GC. Так что
проблема фрагментации, в принципе, решается.

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


K>В догонку к предыдущему сообщению.
K>Такая поделка будет работать если все обьекты имеют размер не более 1 страницы памяти (4-8к). В противном случае кода все зафрагментируется, получится так что памяти полно, а выделить большой кусок нельзя. Ну и кому нужно такое счастье?

Там вроде общесистемный GC, так что проблем с фрагментацией не должно быть.

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

K>Еще раз в догонку.
K>Имхо, разделение системы на юзер-спейс и кернел-спейс, где каждый процесс получает свои законные 2 Гига (или другой обьем в зависимотси от архитектуры) является самым оптимальным решением. Все остальные поделки без виртуальной памяти нежизнеспособны или применимы в ограниченных условиях. Т.е. такие оси не универсальные. Имхо, в МС просто изобрели велосипед 40 летней девности для поездки по старым граблям.
Про 64х битное адресное пространство расказывать надо?

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

K>>В классических осях все просто, когда основная программа зафрагментировала все адрессное простарнство своего процесса, запускаем дополнительный процесс в котором можно хоть целый гиг неперывным куском хапнуть и он делает то что нужно. А тут что получается кто не успел тот опоздал? По сценариям доса шагают товарищи, кто первый загрузился тому и тапки?

WH>Да... срочно читать про дефрагментирующие сборщики мусора.

И в чем выигрыш по сравнению с виртуальной памятью? Системе постоянно приходится физически перемещать большие обьемы памяти с места на место

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

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

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

FR>>И тут тоже все не так однозначно, бывает и наооборот и нередко.
WH>Это смотря кто пишет. Если комманды сравнимой квалификации то будет именно так как я описал. А если комманды разной квалификации то сранения теряет смысл.

Для рынка не теряют.
И зависит не только от квалификации но и от опыта команд и их (не)желания переучиватся.

Андрей Хропов wrote:
> C>И что? Я не понимаю почему все должны от этого петь и танцевать.
> Ты любишь глючные программы?
Нет, поэтому пользуюсь безглючными.

> Ты любишь тратить дополнительное время на отладку?
Я на C++ отлаживаю не медленнее, чем на C#.

> Ок, ты гуру, и у тебя таких проблем нет,
> но это не значит что их не внесет при сопровождении другой человек.
Valgrind/Purify — и 99% проблем нет. Остальной 1% я согласен терпеть.

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

> C>*Лично в моем проекте* такие ошибки не создают ну абсолютно никаких
> проблем.
> Ну и хорошо. Рад лично за тебя.
Я тоже. Поэтому мне и не хочется, чтобы ради Гашиш Кумаров мне пришлось
писать исключительно "безопасный" код.

> C>Вот как раз обращения по неверному адресу всплывают сразу при
> тестировании.
> Это если они простые. Если логика сложная (куча объектов, многопоточность),
> то не сразу понятно есть ли там текущая память, это может и не сразу
> проявиться.
См. Rational Purify/Valgrind. Да стандартный трюк (заполнение
освобожденной памяти числом 0xDEADBEEF) вылавливает практически все промахи.

> C>При миграции DOS->Windows можно было использовать старый код без особых
> C>проблем. В данном случае старый код придется переписать полностью весь.
> Ты недооцениваешь развитие систем виртуализации.
> Тот же DOS Extended mode ведь эмулируется?
Я говорю не про _исполнение_, а про _переиспользование кода_.

> C>Ага. Ведь приходится запускать отладчик и открывать его. А потом в
> C>отладчике смотреть на все эти stacktrace'ы для всех потоков, фреймы
> C>функций, значения локальных переменных.
> Это если отладочная информация есть
А она должна быть у разработчика. И даже если нет — берем исходники
зарелизеной версии, компилим — и получается отладочная инфа.

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

>> > Ага, если сам стек не запорчен, что сделать проще простого:
> C>А это находится при первом тестировании с включеной проверкой стека. Или
> C>с включеным Rational Purify.
> А если выскочило после тестирования (без проверки стека)?
Если на моей машине — запускаю программу под Purify и смотрю. Если у
заказчика — воспроизвожу и смотрю.

А вообще, можно просто не пользоваться опасными функциями.

> Но дело в том, что все это используется во время отладки, а потом всего
> этого нет.
> Бывает, что и в Debug и Release работает по-разному один и тот же код.
Purify/Valgrind замечательно работают и с релизными версиями (я запускал
Oulook под Purify когда писал MAPI Storage).

> Если бы все было так неплохо, так Microsoft бы пачками патчи не выпускал.
Ну так не надо на лидера по глючности равняться.

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

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

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

K>>>В классических осях все просто, когда основная программа зафрагментировала все адрессное простарнство своего процесса, запускаем дополнительный процесс в котором можно хоть целый гиг неперывным куском хапнуть и он делает то что нужно. А тут что получается кто не успел тот опоздал? По сценариям доса шагают товарищи, кто первый загрузился тому и тапки?

WH>>Да... срочно читать про дефрагментирующие сборщики мусора.

K>И в чем выигрыш по сравнению с виртуальной памятью? Системе постоянно приходится физически перемещать большие обьемы памяти с места на место

От задачи зависит, на некторых есть выигрыш на других наоборот.

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

WH>>Это смотря кто пишет. Если комманды сравнимой квалификации то будет именно так как я описал. А если комманды разной квалификации то сранения теряет смысл.

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

FR>и их (не)желания переучиватся.
Вот те которые не желают переучитваться (не буду показывать пальцем но тут таких много) и тормозят процесс...

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

WH>>Да... срочно читать про дефрагментирующие сборщики мусора.
K>И в чем выигрыш по сравнению с виртуальной памятью? Системе постоянно приходится физически перемещать большие обьемы памяти с места на место
Не большие и не постоянно. К томуже виртуальное адресное пространство никто не отменял. Те на 32х битной системе мы имем 4 гига на всех.
Кстати программы которым надо гиг непрерывного адресного пространства большая редкость.

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