Здравствуйте, 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, там рассказывали про то, откуда дровишки. Но ссылки, увы, не собираю.