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

I>>>А ты читай, в самом начале говорится про .Net 4, более того, там указано, что вижла была 2010 бета 2.
EP>>Ну значит всё ещё хуже, и хотя тест VS2010 выше показал небольшое улучшение (почти всю память смогла выделить только аж VS2012), видимо на реальных приложениях было всё ещё печально
I>А ты думал я тебе сказки рассказываю ?

Тут половину топика пытались выяснить в чём же корни векторо-фобии.
Когда же я сделал тесты которые показывали что вероятной причиной является кривой аллокатор в старых версиях, а не List сам по себе — прибежали C#'исты с криками о том, что я даже чуть-чуть не разбираюсь, нужно читать доки, что проблема давно обкостылевается, и вообще не в теме

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

I>>Так здесь совсем другое, вот класс хештейбла, он спокойно войдет в LOH при определнном размере

EP>Весь хештейбл, или только массив?

Массив конечно, он в памяти отдельно будет.

EP>Как часто в LOH будут находится обычные классы/структуры, а не какие-нибудь массивы?

Всегда Есть ряд специальных классов инстанцы которых нельзя двигать, их рантайм помещает в лох. НО ! таких экземпляров совсем мало в общем количестве.

I>>Ты лучше сразу напиши, с чем ты не согласен, а то я устал уже. Если вставка-удаление в деку хуже константы, то дека никому не нужна.

EP>Тем не менее проблему аллокации array-like данных в условиях фрагментации она решает

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

Я например посмотрел, какие операции занимают больше всего времени и оказалось, что ElementAt(index) можно пренебречь по сравнению с удалением-добавлением по индексу, а больше всего времени занял Contains. Так что выбор был совсем не велик.
С чунками как в деке из стл , если двигать только один чунк, то в среднем на элемент будет пол-размера чунка перемещений. Для коллекции в миллион элментов это дает несколько миллиардов перемещений, поверь, это очень неприятная вещь, ибо таки операции идут чуть не все время.

Вобщем дека выходит какой то сомнительной структурой, слишком специализированой, что бы тащить её в стандартную либу. Так что считаю одно обвинение с Микрософта надо снять

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

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

"Ящетаю полне можно создать" это слишком сильное утверждение, что бы принимать на веру. В сингулярити есть про это дело что нибудь или где ?

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

I>Я например посмотрел, какие операции занимают больше всего времени и оказалось, что ElementAt(index) можно пренебречь по сравнению с удалением-добавлением по индексу, а больше всего времени занял Contains. Так что выбор был совсем не велик.
[...]
I>Вобщем дека выходит какой то сомнительной структурой, слишком специализированой, что бы тащить её в стандартную либу. Так что считаю одно обвинение с Микрософта надо снять

У тебя недержание контекста?

Есть List. На кривом аллокаторе его использовать трудно — так?
Нужно его заменить на аналог, менее чувствительный к фрагментации, причём так чтобы сложность основных операций была не хуже. И это один из use-case'ов std::deque
Если твой алгоритм не вставлял/удалял данные в середину List'а — то почему он вдруг начнёт это делать с декой?

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

EP>Тут половину топика пытались выяснить в чём же корни векторо-фобии.

Нету никакой фобии, этот лист используется чуть не в каждом методе. Более того, его при всем желании невозможно избежать. Поэтому, считаю, дотнетчики обязаны знать тонкости и особенности такого часто используемого класса, даже если эти тонкости вылазят в виде проблем только в небольшом количестве приложений.

EP>Когда же я сделал тесты которые показывали что вероятной причиной является кривой аллокатор в старых версиях, а не List сам по себе — прибежали C#'исты с криками о том, что я даже чуть-чуть не разбираюсь, нужно читать доки, что проблема давно обкостылевается, и вообще не в теме

Лист сам по себе кривой до безобразия, а GC не идеален, только и всего.

Скажем, 10 лет назад у сиплюсников было стойкое мнение, что динамическая аллокация это очень медленно и проблемно. Но это же не значит, что и сейчас так же. А вот мифы до сих пор ходят. Забавно наблюдать как очередной бывший сиплюсник начинает бороться с new

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

EP>>Ну вот например соединение с базой данных — эта такая абстракция которая течёт из native'а?
K>На мой взгляд — да.

То есть в чудесном управляемом мире с эльфами и единорогами, в языках достаточно широкого назначения не будет таких объектов как DBConnection, так как это всё от native'а?

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

Подобие счётчика ссылок?

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

I>Лист сам по себе кривой до безобразия,

Подробнее.

I>а GC не идеален, только и всего.

Да причём тут идеален-неидеален, нормальные алгоритмы аллокации известны уже десятки лет

I>Скажем, 10 лет назад у сиплюсников было стойкое мнение, что динамическая аллокация это очень медленно и проблемно.

Зависит от политики аллокации. Но, даже при использовании самой быстрой, это всё равно косвенно бьёт по производительности — так как добавляет лишние индерекции в данные

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

EP>У тебя недержание контекста?

EP>Есть List. На кривом аллокаторе его использовать трудно — так?

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

EP>Нужно его заменить на аналог, менее чувствительный к фрагментации, причём так чтобы сложность основных операций была не хуже. И это один из use-case'ов std::deque
EP>Если твой алгоритм не вставлял/удалял данные в середину List'а — то почему он вдруг начнёт это делать с декой?

Формально ты прав, если нет удалений-вставок, то будет не хуже. А если есть — мало чем лучше выйдет.

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

I>>Лист сам по себе кривой до безобразия,

EP>Подробнее.

Что, опять ? grow factor фиксирован, это практически преступление.

I>>а GC не идеален, только и всего.

EP>Да причём тут идеален-неидеален, нормальные алгоритмы аллокации известны уже десятки лет

Это и есть — неидеален. Джава та же намного старше дотнета, а особо ничем и не лучше, только что либ в ней больше. В кое каких сценариях ГЦ у ней быстрее, но в целом сливает дотнету.

С питоном — тоже самое. С джаваскриптом — снова тоже самое.


EP>Зависит от политики аллокации. Но, даже при использовании самой быстрой, это всё равно косвенно бьёт по производительности — так как добавляет лишние индерекции в данные

При этом, уже 10 лет назад GC на ряде сценариев обгонял дефолтный плюсовый. Статьи на этм сайте смотри.

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

I>>>Лист сам по себе кривой до безобразия,
EP>>Подробнее.
I>Что, опять ? grow factor фиксирован, это практически преступление.

В реализациях STL он тоже фиксирован, и причём в разных библиотеках он разный — и как-то векторо-фобии не наблюдается

I>Джава та же намного старше дотнета, а особо ничем и не лучше, только что либ в ней больше. В кое каких сценариях ГЦ у ней быстрее, но в целом сливает дотнету.
I>С питоном — тоже самое. С джаваскриптом — снова тоже самое.

Интересно будет прогнать тот же тест.

EP>>Зависит от политики аллокации. Но, даже при использовании самой быстрой, это всё равно косвенно бьёт по производительности — так как добавляет лишние индерекции в данные
I>При этом, уже 10 лет назад GC на ряде сценариев обгонял дефолтный плюсовый. Статьи на этм сайте смотри.

Цена аллокации это часть проблемы — другая часть это косвености в данных. И надо не забывать, что в C++ проектах аллокаций на порядки меньше.
И да, GC'шный аллокатор может обогнать стандартный C++ на аллокациях, так как он заточен под другое. Но он также платит передвижением объектов за скорость аллокации.
А в LOH'е захотели и скорость, и без дефрагментации, за что и поплатились (точнее поплатились пользователи). Кстати, в тех версиях в которых начали фиксить аллокатор — LO аллоцируются в разы дольше (видно на глаз, но не замерял).

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

EP>В реализациях STL он тоже фиксирован, и причём в разных библиотеках он разный — и как-то векторо-фобии не наблюдается

Фобия это когда список используется повсеместно ? Странная у тебя терминология.

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

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

Насчёт Сингуларити не знаю, я глубоко в неё не вникал.
А способов сделать можно предложить несколько. Например, отдельный постоянно работающий поток, который постоянно отслеживает специальным образом помеченные объекты, владеющие ресурсами, которые нужно быстро освободить. Примерным аналогом может служить поток финализации. Да, этот способ далеко не идеален, и накладен с точки зрения производительности. Но я говорю лишь о теоретической возможности, и только для прикладного кода, где производительностью можно поступиться во имя удобства.

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

EP>То есть в чудесном управляемом мире с эльфами и единорогами, в языках достаточно широкого назначения не будет таких объектов как DBConnection, так как это всё от native'а?

Такие объекты будут, но если вся среда управляемая, то такой объект вполне может удаляться автоматически и детерминированно.


EP>Подобие счётчика ссылок?

Да, как вариант это может быть счётчик ссылок.

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

НС>Офигеть. А можно логическую цепочку, которая привела тебя к такому выводу?
Так никто так и не назвал ЧТО ОН ИСПОЛЬЗОВАЛ в качестве такой коллекции...

Вот ты, например, что использовал?..

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

I>Кроме того, там где нужны большие вектороподобные коллекции, C# гарантировано сливает нативным плюсам в большинстве сценариев. Подумай головой — дотнетчики они почти все бывшие плюсовики, что еще они могли заюзать ?

Ну, то есть, ты хочешь сказать, что если в задаче возникали большие массивы, то её просто писали на плюсах и всё?

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

I>Не нужно ничего билдить в разных вижлах, правишь манифест, а билди хоть вижлой 2002го года один раз на все случаи жизни.

I>Какие еще у тебя вопросы ?

Если ты такой умный, ты сам мог провести эти тесты ПРАВИЛЬНО, а ещё в 2002-м там или 2003-м или когда у тебя проблемы с ООМ под С# начались? Мог разобраться с ними и придумать адекватную замену листу...

Евгений сейчас за два дня разобрался в проблеме лучше вас двоих обоих "спецов" по шарпу, что лично меня немного удивляет, однако, и как бы намекает...

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

I>Типичный сценарий — удалить надо 1000...100000 элементов по индексу. Если структура линейная, то это фейл с лагами чуть не в минутах. Я на этом сэкономил с 6 часов до 5 минут, одной только декой.

И при чём тут дека, фрагментация и GC?

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

I>А ты думал я тебе сказки рассказываю ?

Лично я с самого начала предполагал, что какая-то проблема есть, но ты либо неточно описываешь механизм её возникновения, либо не точно понимаешь её причины сам.

Пока что удалось выяснить что
1) дотнетовский аллокатор вообще очень плохо совместим с большими кускам памяти, в отличии от кучи других аллокаторов. Не в последнюю очередь и потому, что он вообще неправильно с большими объектами работает. На кой ему вообще сдались LOH? Зачем он АП пачками ест? Ну да это всё лирики, таки надо констатировать что тот дотнетовский аллокатор, который работает сейчас в программах у пользователей -- УГ

2) Что бы разобраться в этой проблеме сообществу шарпистов понадобилось 10 лет и решение нашлось в целом вообще в духе платформы, типа пусть авторы рантайма и фиксят, а пока некоторый класс алгоритмов юзать поостережёмся

На крайнк, если никак не обойтись, всегда мона на С++ сделать, где таких проблем нет, так как там народ с аллокаторами на короткой ноге, а в шарпе с аллокаторами мутить -- не барское типа дело.

Вот пока что такую картину вы с НС сложить смели своими показаниями и соображениями.

Если она в чём-то не точна, то ты можешь её уточнить, показать КАК ЕЩЁ решали проблему РАНЬШЕ, например...
А так, спасибо за инфу. Я раньше не думал, что идеология платформы столь сильно парализует волю разработчиков под неё
Или это всё-таки отбор?

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

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

НС>>Офигеть. А можно логическую цепочку, которая привела тебя к такому выводу?
E>Так никто так и не назвал ЧТО ОН ИСПОЛЬЗОВАЛ в качестве такой коллекции...

А зачем комуто говорить, если я сам перечислил ?

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

I>>Кроме того, там где нужны большие вектороподобные коллекции, C# гарантировано сливает нативным плюсам в большинстве сценариев. Подумай головой — дотнетчики они почти все бывшие плюсовики, что еще они могли заюзать ?

E>Ну, то есть, ты хочешь сказать, что если в задаче возникали большие массивы, то её просто писали на плюсах и всё?

Если совсем плохо, то и так.