Тогда все нетривиальные типы надо будет требовать как IDisposable или каким-то ещё образом гвардить. Да и вообще, GC тут скорее не часть C# как языка, а элемент NET-фреймоврка. Что он будет нам вменять, то и будем вынуждены пользовать. Вон, в некоторых микроконтроллерах динамической кучи нет — вся аллокация либо на стеке (и без того небольшом), либо глобальная переменная. И живут люди ведь как-то...
Здравствуйте, Mr.Delphist, Вы писали:
MD>Тогда все нетривиальные типы надо будет требовать как IDisposable или каким-то ещё образом гвардить.
И тем не менее, это не поможет. Оператора delete в языке нету. А IDisposable.Dispose() по спецификации не имеет права убивать объект — на нём можно продолжать делать аызовы, получая ObjectDisposedException.
MD>Да и вообще, GC тут скорее не часть C# как языка, а элемент NET-фреймоврка.
Вот как раз тут он — как часть языка. C#, как и Java, очень-очень сильно завязан на GC.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Одно время ходили слухи про "M#" — микрософтовский язык с синтаксисом шарпа для системного программирования, но Хейлсберг в интервью говорил, что это глупая затея, так как язык спроектирован специально под GC.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Тогда все нетривиальные типы надо будет требовать как IDisposable
BDA>А можно пример?
Пример типа в контексте использования, имелось в виду.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Здравствуйте, 0BD11A0D, Вы писали:
BDA>>Сабж.
ЕА>Вместо до-диез получиться до-бемоль
ЕА>Одно время ходили слухи про "M#" — микрософтовский язык с синтаксисом шарпа для системного программирования, но Хейлсберг в интервью говорил, что это глупая затея, так как язык спроектирован специально под GC.
Был еще проект сингулярити http://rsdn.ru/article/singularity/singularity.xml
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, 0BD11A0D, Вы писали:
BDA>>Здравствуйте, Mr.Delphist, Вы писали:
MD>>>Тогда все нетривиальные типы надо будет требовать как IDisposable
BDA>>А можно пример?
BDA>Пример типа в контексте использования, имелось в виду.
Ну дык:
using (var c1 = new Class()) // компилятор доволен, всё хорошо
{
/* ...причиняем добро... */
} // c1 авто-диспозитсяvar c2 = new Class(); // компилятор даёт по щам - ибо как и когда диспозить будем?
MD>var c2 = new Class(); // компилятор даёт по щам - ибо как и когда диспозить будем?
MD>
Разумеется, отказавшись от GC пришлось бы на смену ему вводить ручное удаление (если не автоматом, то руками, так ведь? Тертиум-таки нон датур?). Введя ручное удаление, надо делать его обработчики (деструкторы). А вопрос был, что от языка при этом еще открутится и отвалится (подозреваю, что жопа).
Здравствуйте, Ionich, Вы писали:
I>Здравствуйте, 0BD11A0D, Вы писали:
BDA>>Сабж.
I>А зачем?
Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Разумеется, отказавшись от GC пришлось бы на смену ему вводить ручное удаление (если не автоматом, то руками, так ведь? Тертиум-таки нон датур?). Введя ручное удаление, надо делать его обработчики (деструкторы). А вопрос был, что от языка при этом еще открутится и отвалится (подозреваю, что жопа).
Да, мне тут на данную тему Objective-C вспомнился, с его двояким memory management — хочешь ref-counting юзай (и авто-удаление), хочешь всё в ручном режиме (но есть риск утчеки, т.к. всё самому надо делать). В принципе, сделать на этой идее Objective C# тоже можно
Здравствуйте, amater, Вы писали:
I>>А зачем?
A>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
Конфигурируемый во всех деталях. Per app. Но, видимо, опять какие-то параноики по соображениям безопасности запретили.
Здравствуйте, amater, Вы писали:
A>Здравствуйте, Ionich, Вы писали:
I>>Здравствуйте, 0BD11A0D, Вы писали:
BDA>>>Сабж.
I>>А зачем?
A>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
Windows — не система реального времени, зачем ей realtime gc?
Здравствуйте, gandjustas, Вы писали:
A>>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
G>Windows — не система реального времени, зачем ей realtime gc?
А как же WinCE? Под ней же тоже можно запускать .Net приложения
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, amater, Вы писали:
I>>>А зачем?
A>>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
BDA>Конфигурируемый во всех деталях. Per app. Но, видимо, опять какие-то параноики по соображениям безопасности запретили.
А сейчас деталей мало? Ты можешь в любой момент отключить GC, можешь в любой момент инициировать сборку мусора, можешь получать оповещения о приближении сборки мусора. Что тебе еще надо?
Кроме того в .NET можно вручную выделять память и обращаться ней по указателю.
Здравствуйте, Ionich, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
A>>>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
G>>Windows — не система реального времени, зачем ей realtime gc?
I>А как же WinCE? Под ней же тоже можно запускать .Net приложения
WinCE сдох давно. В WP для пользовательских приложений не поддерживает real time, нет никаких гарантий, что в приложение придет сигнал от системы в заранее определенный интервал с момента возникновения события, соответственно и realtime gc не нужен.
Здравствуйте, gandjustas, Вы писали:
BDA>>Конфигурируемый во всех деталях. Per app. Но, видимо, опять какие-то параноики по соображениям безопасности запретили.
G>А сейчас деталей мало? Ты можешь в любой момент отключить GC, можешь в любой момент инициировать сборку мусора, можешь получать оповещения о приближении сборки мусора. Что тебе еще надо?
Тут где-то лежит статья Ткачева с графиками, в которой он рассказывает, как находил точку, где GC начинает безнадежно просирать Win Heap. Не помню, переходит ли он к вопросу о скрытых параметрах, приводящих к этой картине или довольствуется констатацией. А я же говорю про конфигурирование этих параметров.
Проще говоря, если дев заранее знает, что будет работать с таким или сяким количеством объектов, GC не должен переаллоцировать память в указанных пределах. С одной стороны, возрастет скорость памятеемких приложений (в соответствии с тем графиком). С другой, простейшее приложение не будет отжирать виртуальную память. Беды в этом нет, виртуальная память — очень дешевый ресурс (это просто маркировка куска свопа), но дергать диск лишний раз не придется. Для оптимизации настроек на этапе разработки можно было бы использовать профайлер, гоняя апп с типичными данными.
Это отдельная тема (от темы последствий полного убирания GC), просто я тоже всегда считал, что если сделать GC конфигурируемым, это лучше решит те проблемы, ради решения которых предлагается отказаться от GC вообще.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
BDA>>>Конфигурируемый во всех деталях. Per app. Но, видимо, опять какие-то параноики по соображениям безопасности запретили.
G>>А сейчас деталей мало? Ты можешь в любой момент отключить GC, можешь в любой момент инициировать сборку мусора, можешь получать оповещения о приближении сборки мусора. Что тебе еще надо?
BDA>Тут где-то лежит статья Ткачева с графиками, в которой он рассказывает, как находил точку, где GC начинает безнадежно просирать Win Heap. Не помню, переходит ли он к вопросу о скрытых параметрах, приводящих к этой картине или довольствуется констатацией. А я же говорю про конфигурирование этих параметров.
Вы забываете, что GC основан на эвристиках и хорошо работает в 95% случаев. Зная эти эверистики легко придумать пример, который попадет в оставшиеся 5% и просадит быстродействие.
В реальности для этих 5% случаев вполне достаточно текущего уровня "контроля" над поведением GC.
BDA>Проще говоря, если дев заранее знает, что будет работать с таким или сяким количеством объектов, GC не должен переаллоцировать память в указанных пределах. С одной стороны, возрастет скорость памятеемких приложений (в соответствии с тем графиком). С другой, простейшее приложение не будет отжирать виртуальную память. Беды в этом нет, виртуальная память — очень дешевый ресурс (это просто маркировка куска свопа), но дергать диск лишний раз не придется. Для оптимизации настроек на этапе разработки можно было бы использовать профайлер, гоняя апп с типичными данными.
Это к настройке и алгоритмам GC вообще никакого отношения не имеет. Делайте WorkingSet побольше и GC не будет переаллоцировать страницы.
BDA>Это отдельная тема (от темы последствий полного убирания GC), просто я тоже всегда считал, что если сделать GC конфигурируемым, это лучше решит те проблемы, ради решения которых предлагается отказаться от GC вообще.
Вернемся к вопросу, где в реальных приложениях, а не искусственных примерах, вам не хватает текущих возможностей конфигурации GC?
Здравствуйте, gandjustas, Вы писали:
G>В реальности для этих 5% случаев вполне достаточно текущего уровня "контроля" над поведением GC.
Очень интересно. И как предотвратить скатывание с 30 секунд до 2.5 минут в случае, приведенном Ткачевым?
G>Это к настройке и алгоритмам GC вообще никакого отношения не имеет. Делайте WorkingSet побольше и GC не будет переаллоцировать страницы.
Я говорю про виртуальную память, к которой GC имеет самое прямое отношение. А не про Working Set. Вы, судя по всему, разницу понимаете — тогда зачем передергивать?
G>Вернемся к вопросу, где в реальных приложениях, а не искусственных примерах, вам не хватает текущих возможностей конфигурации GC?
Это методологически неправильный подход. Реальные приложения пишут на основе прототипов (искусственных примеров). Чтобы правильно выбрать технологию. Чтобы знать, что делать, если вдруг. Любая платформа полна непредвиденных сюрпризов — поэтому от предвиденных избавляются, создавая искусственные примеры.
Про именно текущие возможности я мало знаю — давно не сталкивался с дотнетом на практике. Что хотелось бы (двигать точку изгиба хоккейной клюшки по своему усмотрению), я написал. Уже сделали?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
G>>В реальности для этих 5% случаев вполне достаточно текущего уровня "контроля" над поведением GC. BDA>Очень интересно. И как предотвратить скатывание с 30 секунд до 2.5 минут в случае, приведенном Ткачевым?
Не писать такой код. В твоих приложениях есть необходимость создания 10000 объектов в цикле?
G>>Вернемся к вопросу, где в реальных приложениях, а не искусственных примерах, вам не хватает текущих возможностей конфигурации GC?
BDA>Это методологически неправильный подход. Реальные приложения пишут на основе прототипов (искусственных примеров). Чтобы правильно выбрать технологию. Чтобы знать, что делать, если вдруг. Любая платформа полна непредвиденных сюрпризов — поэтому от предвиденных избавляются, создавая искусственные примеры.
Бред какой-то. Если я делю пример, в котором вызывается создание 100500 объектов в цикле, то это вовсе не означает, что в реальном приложении будет такой цикл.
BDA>Про именно текущие возможности я мало знаю — давно не сталкивался с дотнетом на практике. Что хотелось бы (двигать точку изгиба хоккейной клюшки по своему усмотрению), я написал. Уже сделали?
Нет, конечно. .NET никогда не оптимизировался под такие примеры, не за чем. Его всегда оптимизируют под реальные сценарии.
Здравствуйте, gandjustas, Вы писали:
G>>>В реальности для этих 5% случаев вполне достаточно текущего уровня "контроля" над поведением GC. BDA>>Очень интересно. И как предотвратить скатывание с 30 секунд до 2.5 минут в случае, приведенном Ткачевым? G>Не писать такой код. В твоих приложениях есть необходимость создания 10000 объектов в цикле?
Скажем так, одно приложение, к которому я причастен, имело в этом необходимость. При скудных аппаратных ресурсах. Именно поэтому оно было написано на плюсах, хотя по моему мнению, оно бы только выиграло, если бы было написано не на этом ужасе, а на шарпе. Одного LINQ'а хватает, чтобы горькими слезами обливаться над STL/Boost. Но... те, кто его когда-то начинали, говорили — тормоз. Те, кто продолжали, говорили — как мы будем столько объектов создавать, при наших-то потребностях? Не будем? Тогда нам и на плюсах неплохо.
Из этого я сделал вывод, что профили GC очень бы поспособствовали популярности дотнета. Как видно выше по ветке, не я один. Или мне показалось, что видно.
G>>>Вернемся к вопросу, где в реальных приложениях, а не искусственных примерах, вам не хватает текущих возможностей конфигурации GC?
BDA>>Это методологически неправильный подход. Реальные приложения пишут на основе прототипов (искусственных примеров). Чтобы правильно выбрать технологию. Чтобы знать, что делать, если вдруг. Любая платформа полна непредвиденных сюрпризов — поэтому от предвиденных избавляются, создавая искусственные примеры.
G>Бред какой-то. Если я делю пример, в котором вызывается создание 100500 объектов в цикле, то это вовсе не означает, что в реальном приложении будет такой цикл.
Это означает, что программы, которые предполагают такие объемы, не пишутся на дотнете. Потому, что люди читают ту статью и понимают, что не имея средств управления GC, они пролетят с ним как фанера.
BDA>>Про именно текущие возможности я мало знаю — давно не сталкивался с дотнетом на практике. Что хотелось бы (двигать точку изгиба хоккейной клюшки по своему усмотрению), я написал. Уже сделали? G>Нет, конечно. .NET никогда не оптимизировался под такие примеры, не за чем. Его всегда оптимизируют под реальные сценарии.
Рад, что вы знаете наверняка. В МС, видимо, тоже лучше всех знают. Хотя я считаю, это просто идет вразрез с какой-нибудь безопасностью. Дотнетом там занимались большие умницы.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
G>>>>В реальности для этих 5% случаев вполне достаточно текущего уровня "контроля" над поведением GC. BDA>>>Очень интересно. И как предотвратить скатывание с 30 секунд до 2.5 минут в случае, приведенном Ткачевым? G>>Не писать такой код. В твоих приложениях есть необходимость создания 10000 объектов в цикле?
BDA>Скажем так, одно приложение, к которому я причастен, имело в этом необходимость. При скудных аппаратных ресурсах.
И от чего такая необходимость? ИМХО это ошибка проектирования, а не необходимость.
G>>>>Вернемся к вопросу, где в реальных приложениях, а не искусственных примерах, вам не хватает текущих возможностей конфигурации GC?
BDA>>>Это методологически неправильный подход. Реальные приложения пишут на основе прототипов (искусственных примеров). Чтобы правильно выбрать технологию. Чтобы знать, что делать, если вдруг. Любая платформа полна непредвиденных сюрпризов — поэтому от предвиденных избавляются, создавая искусственные примеры.
G>>Бред какой-то. Если я делю пример, в котором вызывается создание 100500 объектов в цикле, то это вовсе не означает, что в реальном приложении будет такой цикл.
BDA>Это означает, что программы, которые предполагают такие объемы, не пишутся на дотнете. Потому, что люди читают ту статью и понимают, что не имея средств управления GC, они пролетят с ним как фанера.
Объемы тут совершенно не при чем. Создание в цикле сотен тысяч объектов в цикле — в принципе плохая идея, независимо от объемов.
BDA>>>Про именно текущие возможности я мало знаю — давно не сталкивался с дотнетом на практике. Что хотелось бы (двигать точку изгиба хоккейной клюшки по своему усмотрению), я написал. Уже сделали? G>>Нет, конечно. .NET никогда не оптимизировался под такие примеры, не за чем. Его всегда оптимизируют под реальные сценарии.
BDA>Рад, что вы знаете наверняка. В МС, видимо, тоже лучше всех знают.
Они статистику анализируют.
BDA>Хотя я считаю, это просто идет вразрез с какой-нибудь безопасностью. Дотнетом там занимались большие умницы.
Какой безопасностью?
Здравствуйте, gandjustas, Вы писали:
BDA>>Скажем так, одно приложение, к которому я причастен, имело в этом необходимость. При скудных аппаратных ресурсах. G>И от чего такая необходимость? ИМХО это ошибка проектирования, а не необходимость.
Она объективная. То есть, ее причины лежали вне софта. В предметной области.
BDA>>Рад, что вы знаете наверняка. В МС, видимо, тоже лучше всех знают. G>Они статистику анализируют.
Дайте лучше сразу ссылку на техблог, почитать про сбор статистики.
G>Какой безопасностью?
Не знаю, это же предположение. Чего не коснись в дотнете, все испортили по соображениям безопасности. Поневоле начинаешь думать в эту сторону. Например, чтоб SQLCLR-триггер не мог через метаданные зарезервировать всю память.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
BDA>>>Скажем так, одно приложение, к которому я причастен, имело в этом необходимость. При скудных аппаратных ресурсах. G>>И от чего такая необходимость? ИМХО это ошибка проектирования, а не необходимость. BDA>Она объективная. То есть, ее причины лежали вне софта. В предметной области.
Неубедительно. Приведи детали.
Есть два варианта:
1) Данные приходят извне, обрабатываются порциями. Тогда в быстродействии GC нет смысла, ибо пропускная способность ограничена пропускной способностью сети.
2) Данные генерируются алгоритмом, например динамического программирования, тогда неясно зачем объекты, в этом случае надо применять структуры.
BDA>>>Рад, что вы знаете наверняка. В МС, видимо, тоже лучше всех знают. G>>Они статистику анализируют. BDA>Дайте лучше сразу ссылку на техблог, почитать про сбор статистики.
Почитай ранние посты про GC в .NET, там рассказывали про то, откуда дровишки. Но ссылки, увы, не собираю.
