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

EP>Вкратце:
EP>есть byte[] bigBlock; и есть List<byte[]> smallBlocks;
EP>На каждой итерации вечного цикла bigBlock пересоздается с размером большим на единицу, начиная с 16 MiB,
EP>а в smallBlocks добавляется new byte[90000].
EP>После приёма OOM выводится количество занимаемых мебибайт блоками в smallBlocks.
EP>Вроде бы не слишком сложная задача для нормального аллокатора, но у автора получилось всего-навсего 20MiB.

Я про эту проблему раз пять сказал.

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

Большие объекты везде создают проблемы, вообще везде. На плюсовых программах я пофиксил OOM раз в десять больше, чем в дотнете, при том что дотнетом занимался несравнимо больше.

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

EP>>Вот, почему бы было сразу не сказать, что векторо-фобия это что-то личное Ikemefula, и все остальные с ним не согласны? Типа "мы сишарписты ребята плечисты, мы не боимся списков мясистых"
EP>>>>Или например вот эти пользователи тоже не разобрались, наговаривают наверное?
S>>>Почему наговаривают? Частично исправлено в 4.0, полностью — в 4.5. Другое дело, что грабли разбирались неоднократно.
EP>>Ну то есть они правы в том что боятся LOH?
I>С таким подходом смело можно сказать, что в С++ боятся

Ну по стартовому сообщению, вот это:

Более того, очень осторожно нужно быть со скрытыми массивами, например в инвокейшнлистах и тд и тд. Казалось бы — сделали N подсписчиков, что тут такого ?

кроме как фобией не назовёшь
Неужели в твоих "инвокейшнлистах" десятки миллионов подписчиков? Или хотя бы десятки тысяч?

Да, и кстати, если не нравиться grow-factor 2, то почему бы не попросить насяльника изменить на что-нибудь меньше золотого сечения? Или хотя бы добавить ручку для контроля?

I>Эдак выходит что С++ просто рассадник фобий, ибо на каждый пример из списка можно найти вагоны воплей "... не работает ! Всё пропало !!! просрали полимеры !!!!111расрас"

То есть ты проводишь параллель между своим отношением к List'у вот с такими воплями?

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

EP>Я читал статью, и понял что происходит — вроде же очевидно по моему сообщению
По ёрническому тону и чрезмерным обобщениям типа "боятся они теперь больших объектов как огня" — не совсем очевидно.

EP>Я даже несколько тестов привёл, которые показывают что такой сценарий спокойно разгуливается нормальным аллокатором — например в C++ VS2005, и в C# VS2012 — эти примеры ты пропустил?
Оно и в дотнете три года как разруливается, но разборки-то продолжаются Ещё раз, чтобы отхватить описанные грабли, нужно:

1. Не читать Рихтера и ко. Статьи про опасность засорения gen 2 aka mid-life crisis выходят регулярно начиная с 2003го (это я раньше не искал).
2. Аллоцировать с достаточно большой частотой короткоживущие массивы всё возрастающих размеров вперемешку с мелкими массивами.
3. Запустить на x86.

Если человек натолкнулся на такое поведение — он скорее всего изучит наконец матчасть. Всяко полезнее, чем холиварить на 15 страниц по мелочам

EP>Естественно есть варианты обхода такого косяка аллокатора, я даже в конце сообщения один из вариантов показал:

Кстати, по поводу боязни растущих векторов — если заменить List<byte[]>, на List<byte>, и соответственно добавлять в него всё что раньше было в блоках — байт за байтом — то даже на VS2005 получается достичь "фантастических" 511MiB, потому что будут не тысячи LO, а всего два

EP>Но ты также его проигнорировал.
Тут нечего игнорировать Проблема — не в количестве LO, а в некорректной стратегии переиспользования свободных фрагментов кучи. Если религия не запрещает — можно самому увеличивать list.Capacity и занять заметно больше "фантастики" в 511 мб. Наконец, нормальные люди, если уж припёрло, просто находят (или пишут) свой ChunkedList и не парятся вообще.

EP>P.S. Я правильно понимаю, что вот это:

Вы хоть чуть-чуть разберитесь, перед тем как писать.

EP>ты написал сгоряча, и никаких аргументов в поддержку своих слов привести не можешь?
Ну блин... тема жёвана-пережёвана кучу лет уже, и по серьёзности сопоставима с "табы vs пробелы", "как использовать c# без дотнета", "а-а-а-а, ФП не позволяет мутабельные переменные" или "перекрёстные ссылки в c++ — это печаль и плохо". У любого, кто вплотную сталкивался с сборкой мусора при ограниченном АП, куда больше вопросов насчёт засорения старшего поколения, вот это иногда действительно проблематично разруливать.

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

EP>Ну по стартовому сообщению, вот это:
EP>

EP>Более того, очень осторожно нужно быть со скрытыми массивами, например в инвокейшнлистах и тд и тд. Казалось бы — сделали N подсписчиков, что тут такого ?

EP>кроме как фобией не назовёшь

Это необходимое зание инструмента с которым работаешь. А то можно и дальше пойти — "аккуратная работа с указателями" == "фобия", "правильное использование смартпоинтеров == фобия".

EP>Неужели в твоих "инвокейшнлистах" десятки миллионов подписчиков? Или хотя бы десятки тысяч?

Я уже раз пять давал ответ.

EP>Да, и кстати, если не нравиться grow-factor 2, то почему бы не попросить насяльника изменить на что-нибудь меньше золотого сечения? Или хотя бы добавить ручку для контроля?

Я этот же вопрос задавал, если ты читать конечно умеешь.

I>>Эдак выходит что С++ просто рассадник фобий, ибо на каждый пример из списка можно найти вагоны воплей "... не работает ! Всё пропало !!! просрали полимеры !!!!111расрас"

EP>То есть ты проводишь параллель между своим отношением к List'у вот с такими воплями?

Не я, а ты.

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

EP>>Вкратце:
EP>>есть byte[] bigBlock; и есть List<byte[]> smallBlocks;
EP>>На каждой итерации вечного цикла bigBlock пересоздается с размером большим на единицу, начиная с 16 MiB,
EP>>а в smallBlocks добавляется new byte[90000].
EP>>После приёма OOM выводится количество занимаемых мебибайт блоками в smallBlocks.
EP>>Вроде бы не слишком сложная задача для нормального аллокатора, но у автора получилось всего-навсего 20MiB.
I>Я про эту проблему раз пять сказал.

Я видел. Но ты вроде ничего сказал про то, что в VS2010 и VS2012 с этим намного лучше. Или я пропустил?
Мои примеры показывают то, что в первую очередь проблема в плохом аллокаторе. Который уже пофиксили (по крайней мере для этого сценария).
И многие могли приобрести фобии больших объектов после того как обожглись ими на старых версиях.

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

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

EP>Я видел. Но ты вроде ничего сказал про то, что в VS2010 и VS2012 с этим намного лучше. Или я пропустил?

Конкретно в одном сценарии лучше, но есть и другие.

EP>Мои примеры показывают то, что в первую очередь проблема в плохом аллокаторе. Который уже пофиксили (по крайней мере для этого сценария).

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

EP>И многие могли приобрести фобии больших объектов после того как обожглись ими на старых версиях.
EP>

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

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

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

EP>>Я читал статью, и понял что происходит — вроде же очевидно по моему сообщению
S>По ёрническому тону и чрезмерным обобщениям типа "боятся они теперь больших объектов как огня" — не совсем очевидно.

Весь топик про то, "какие опасные List'ы". Я в своём сообщении попытался разобраться в чём же дело.
Вполне вероятно, что дело было в плохом аллокаторе.

S>Оно и в дотнете три года как разруливается, но разборки-то продолжаются

Так разборки начали .NET'чики с боязни больших объектов и List'ов. Видимо они не в курсе что разруливается — пришлось самому пример делать

S>Ещё раз, чтобы отхватить описанные грабли, нужно:
S>Если человек натолкнулся на такое поведение — он скорее всего изучит наконец матчасть. Всяко полезнее, чем холиварить на 15 страниц по мелочам

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

S>Тут нечего игнорировать Проблема — не в количестве LO, а в некорректной стратегии переиспользования свободных фрагментов кучи. Если религия не запрещает — можно самому увеличивать list.Capacity и занять заметно больше "фантастики" в 511 мб.

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

S>Наконец, нормальные люди, если уж припёрло, просто находят (или пишут) свой ChunkedList и не парятся вообще.

О, кстати. Я спрашивал про аналог C++1998 std::deque — мне пытались впарить LinkedList

Автор: Evgeny.Panasyuk
Дата: 15.10.13

под видом деки. Может ты покажешь какую деку обычно используют в .NET — ведь должно же быть что-то стандартное, или распространённое, раз с List'ом такой ужас-ужас.

EP>>P.S. Я правильно понимаю, что вот это:
S>

S>Вы хоть чуть-чуть разберитесь, перед тем как писать.

EP>>ты написал сгоряча, и никаких аргументов в поддержку своих слов привести не можешь?
S>Ну блин... тема жёвана-пережёвана кучу лет уже, и по серьёзности сопоставима с "табы vs пробелы", "как использовать c# без дотнета", "а-а-а-а, ФП не позволяет мутабельные переменные" или "перекрёстные ссылки в c++ — это печаль и плохо". У любого, кто вплотную сталкивался с сборкой мусора при ограниченном АП, куда больше вопросов насчёт засорения старшего поколения, вот это иногда действительно проблематично разруливать.

Ещё раз, я не говорил что у проблемы нет решения. На протяжении всего топика Erop пытался выяснить, как там дела обстоят с фрагментацией, почему так боятся List'ов — вроде никто не упомянул что раньше аллокатор был ужасный, но начиная с VS2010 с фрагментацией намного меньше проблем — что собственно и показывает мой пример.
Видимо ты увидел в моём сообщении "наезд на твой любимый C#", и кинулся его защищать не разобравшись, мол проблема решается, читайте доки, да и вообще "Вы хоть чуть-чуть разберитесь, перед тем как писать."

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

EP>Весь топик про то, "какие опасные List'ы". Я в своём сообщении попытался разобраться в чём же дело.

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

S>>Наконец, нормальные люди, если уж припёрло, просто находят (или пишут) свой ChunkedList и не парятся вообще.

EP>О, кстати. Я спрашивал про аналог C++1998 std::deque — мне пытались впарить LinkedList

Автор: Evgeny.Panasyuk
Дата: 15.10.13

под видом деки. Может ты покажешь какую деку обычно используют в .NET — ведь должно же быть что-то стандартное, или распространённое, раз с List'ом такой ужас-ужас.

Стандартной нет. Я вот сам писал.

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

I>>Имена функций нужна для человека, в них и надо вкладывать смысл. Если ты пишешь c = (a + b)/2 и рядом камент "//вместо медианы берем среднее арифметическое", то тебя надо выпилить из конторы как можно раньше.

E>А мне бы вот, например, могло бы быть интересно, что рассматривались именно эти два варианта...

То есть, ты сам для себя в коде напоминалки пишешь ? А кому они нужны кроме тебя ?

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

I>То есть, ты сам для себя в коде напоминалки пишешь ? А кому они нужны кроме тебя ?
Ага, а ещё доказательства его работоспособности и т. п.
Нужно это тем коллегам, которые потом этот код поддерживают, например...
И интереснее всего мне было бы узнать, что медиану рассматривали, но отвергли именно В ЧУЖОМ коде...

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

I>>То есть, ты сам для себя в коде напоминалки пишешь ? А кому они нужны кроме тебя ?
E>Ага, а ещё доказательства его работоспособности и т. п.
E>Нужно это тем коллегам, которые потом этот код поддерживают, например...
E>И интереснее всего мне было бы узнать, что медиану рассматривали, но отвергли именно В ЧУЖОМ коде...

То есть, информации заведомо больше, чем можно поместить в коментарии ?

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

I>То есть, информации заведомо больше, чем можно поместить в коментарии ?
Что за проблемы с помещением инфы в комментарии?

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

//Используем среднее арифметическое, вместо медианы, потому, что медиану долго искать. 
//Оценку вносимой ошибки смотри в документе таком-то.

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

EP>>Весь топик про то, "какие опасные List'ы". Я в своём сообщении попытался разобраться в чём же дело.
I>Весь топик про конкретный список, более того, сказано что это нетипичный случай и сказано, когда выплывает проблема. Ты как то ухитряешься по особенному читать, наверное в тебя Егор вселился.

Сколько вас там? Это

Автор: Ikemefula
Дата: 09.10.13

ты писал:

I>2 паттерн ниже встречается слишком часто, при чем список часто состоит в т.ч. из структур и размеры >миллиона
I>

I>var list = new List<Item>();
I>while (condition())
I>{
I>  list.Add(current());
I>}
I>

?

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

EP>>Ну по стартовому сообщению, вот это:
EP>>

EP>>Более того, очень осторожно нужно быть со скрытыми массивами, например в инвокейшнлистах и тд и тд. Казалось бы — сделали N подсписчиков, что тут такого ?

EP>>кроме как фобией не назовёшь
I>Это необходимое зание инструмента с которым работаешь. А то можно и дальше пойти — "аккуратная работа с указателями" == "фобия", "правильное использование смартпоинтеров == фобия".
EP>>Неужели в твоих "инвокейшнлистах" десятки миллионов подписчиков? Или хотя бы десятки тысяч?
I>Я уже раз пять давал ответ.

Где?
Так сколько в твоих "инвокейшнлистах" подписчиков, что это вызывает проблему?

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

EP>Сколько вас там? Это

Автор: Ikemefula
Дата: 09.10.13

ты писал:
EP>

I>>2 паттерн ниже встречается слишком часто, при чем список часто состоит в т.ч. из структур и размеры >миллиона

?

Ты выкусываешь только удобные лично для тебя аргументы, я не раз и не два писал следующее

"Проблема актуальная для больших приложений в архитектуре навроде x86, где АП ограничено — всего 2гб, но в силу естественной фрагментации размер непрерывного отрезка АП может быть намного меньше, в 10 и более раз"

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

I>>То есть, информации заведомо больше, чем можно поместить в коментарии ?
E>Что за проблемы с помещением инфы в комментарии?

Когда ты колхозе работаешь то естественно никаких проблем нет. Многие всю жизнь сидят по ноздри в говне и намекают "а что за проблемы ?"

E>Вот, в частности, твой пример с медианой. Я так понимаю, что из кода тот факт, что медиану отвергли вообще не восстанавливается, а вот в твоём комментарии не хватает причины.
E>То есть правильный коммент был бы примерно такой:

//Используем среднее арифметическое, вместо медианы, потому, что медиану долго искать. 
E>//Оценку вносимой ошибки смотри в документе таком-то.

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

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

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

EP>Где?
EP>Так сколько в твоих "инвокейшнлистах" подписчиков, что это вызывает проблему?

Я уже давал ответ. Не умеешь читать — на кой ляд ты сюда вообще пишешь ?

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

I>"Проблема актуальная для больших приложений в архитектуре навроде x86, где АП ограничено — всего 2гб, но в силу естественной фрагментации размер непрерывного отрезка АП может быть намного меньше, в 10 и более раз"

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

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

I>>"Проблема актуальная для больших приложений в архитектуре навроде x86, где АП ограничено — всего 2гб, но в силу естественной фрагментации размер непрерывного отрезка АП может быть намного меньше, в 10 и более раз"

EP>Как показывает простейший тест естественная фрагментация стала действительно "естественной", а не следствием дубового аллокатора, только начиная с VS2012

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

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

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

I>>>"Проблема актуальная для больших приложений в архитектуре навроде x86, где АП ограничено — всего 2гб, но в силу естественной фрагментации размер непрерывного отрезка АП может быть намного меньше, в 10 и более раз"
EP>>Как показывает простейший тест естественная фрагментация стала действительно "естественной", а не следствием дубового аллокатора, только начиная с VS2012
I>Естественная фрагментация это следствтие работы системы в естественных условиях в конкретном случае: рантайм, винда, данные пользователя и тд и тд.

Опять терминологический спор. Ну ок: как показывает простейший тест естественна фрагментация стала намного благоприятней в следствии замены дубового аллокатора начиная с VS2012
Теперь списков на x86 меньше боишься?