Здравствуйте, Erop, Вы писали:
E>Если ты такой умный, ты сам мог провести эти тесты ПРАВИЛЬНО, а ещё в 2002-м там или 2003-м или когда у тебя проблемы с ООМ под С# начались? Мог разобраться с ними и придумать адекватную замену листу...
Ты не волнуйся — все проблемы вовремя решались, в том числе и в 2003м
E>Евгений сейчас за два дня разобрался в проблеме лучше вас двоих обоих "спецов" по шарпу, что лично меня немного удивляет, однако, и как бы намекает...
Здравствуйте, Erop, Вы писали:
E>2) Что бы разобраться в этой проблеме сообществу шарпистов понадобилось 10 лет и решение нашлось в целом вообще в духе платформы, типа пусть авторы рантайма и фиксят, а пока некоторый класс алгоритмов юзать поостережёмся
Судя по форумам, сообществу плюсовиков еще предстоит разобраться с указателями.
E>Если она в чём-то не точна, то ты можешь её уточнить, показать КАК ЕЩЁ решали проблему РАНЬШЕ, например...
Есть мнение, что смысла объяснять нет, ибо ты как то по особенному читаешь, кусочками, небось разные алгоритмы пробуешь, то с конца, то с начала, то с середины, то через фразу. Правильное дело — алгоритмы надо постоянно прокачивать.
Здравствуйте, Erop, Вы писали:
I>>Типичный сценарий — удалить надо 1000...100000 элементов по индексу. Если структура линейная, то это фейл с лагами чуть не в минутах. Я на этом сэкономил с 6 часов до 5 минут, одной только декой.
E>И при чём тут дека, фрагментация и GC?
Предлагаешь менять одну структуру на другую не глядя на другие проблемы, чисто руководствуясь соображениями о прекрасном ?
Здравствуйте, Ikemefula, Вы писали:
I>А зачем комуто говорить, если я сам перечислил ?
Имя, сестра, имя!!!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
НС>>Офигеть. А можно логическую цепочку, которая привела тебя к такому выводу? E>Так никто так и не назвал ЧТО ОН ИСПОЛЬЗОВАЛ в качестве такой коллекции...
Ты на вопрос можешь ответить?
E>Вот ты, например, что использовал?..
Здравствуйте, Erop, Вы писали:
E>И при чём тут дека
Мне вот тоже интересно. В исходной задаче смысла в ней 0, там LinkedList за глаза. А использовать ее для борьбы с фрагментацией VA вместо массива — как то уж очень жестко.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ты на вопрос можешь ответить?
Я же ответил.
Был задан прямой вопрос, что делали, если таки нужны были боьлшие непрерывные куски памяти, например в алгоритме требовались большие списки с доступом по индексу?
В ответ на этот простой вопрос было написано много всякого разного, что коротко можно передать так, что так делать вообще-то лучше не надо, но если уж приходится, то проблему решали каждый раз по месту и творчески.
Из чего я и делаю вывод, что никакого внятного общепринятого масштабируемого решения, не выработали...
Кстати, что бы опровергнуть этот ой вывод, вполне достаточно таки выкатить это внятное, общепринятое масштабируемое решение...
E>>Вот ты, например, что использовал?.. НС>Для чего?
Всё для того же. В алгоритме нужен большой вектор с доступом по индексу, но GC на таком листе дохнет из-за неудачной политики работы своего аллокатора больших объектов. Что в таком случае дылал лично ты, например? Или общего рецепта нет и каждый раз надо смотреть по месту?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Мне вот тоже интересно. В исходной задаче смысла в ней 0, там LinkedList за глаза. А использовать ее для борьбы с фрагментацией VA вместо массива — как то уж очень жестко.
Почему её жёстко использовать вместо массива, если шарповый аллокатор тупит на больших блоках?
Что там так уж "жёстко" на твой взгляд?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Пока что удалось выяснить что E>1) дотнетовский аллокатор вообще очень плохо совместим с большими кускам памяти, в отличии от кучи других аллокаторов. Не в последнюю очередь и потому, что он вообще неправильно с большими объектами работает.
Ошибка уже в первом пункте
Я наверно раза четыре написал, что шансы получить OOM в реальном приложении именно из-за фрагментации кучи стремятся к 0. Но даже этот 0 обходится элементарно — переходом на x64, обновлением фреймворка, или (наконец) изучением матчасти.
Дотнет (как и любой другой фреймворк/язык) имеет свою область применимости. Основные области для дотнета сейчас — энтерпрайз, сайты, мобильные приложения и (в следовом количестве) десктопный софт. Именно под них и затачивается рантайм/BCL/etc. Появляются новые требования, например, от разработчиков azure и мобильного софта — допиливается и сама платформа. Нет требований и ресурсов на их реализацию — никто и не шелохнётся.
Итак, раз уж мы говорим за 10 лет — где хоть одна статья с описанием нерешаемых проблем, вызванными особенностями LOH? Только плиз, написанная нормальным разработчиком со знанием матчасти, а не "Вау, мы поломали дотнет!"
P.S. Судя по вот этому:
На кой ему вообще сдались LOH? Зачем он АП пачками ест? Ну да это всё лирики, таки надо констатировать что тот дотнетовский аллокатор, который работает сейчас в программах у пользователей -- УГ
в ходе обсуждения проблему раздули до размеров мамонта.
Во-первых, аллокатор LOH принципиально ничем не отличается от аллокаторов в других языках — та жа куча + free list. Т.е. "На кой ему вообще сдались LOH? Зачем он АП пачками ест?" ровно с теми же основаниями можно спрашивать у c++
Во-вторых, реализация CLR (начиная со второго фреймворка) позволяет заменять отдельные части рантайма (аллокатор памяти/запуск потоков, GC, JIT итд) вплоть до написания своего clr-хоста. Например, в составе дотнета ещё с 1 фреймворка поставляется 2 gc — server и desktop. Т.е. чисто технически изменить логику аллокатора (и вообще его заменить) — проблем нет. И, если уж это было бы серьёзной проблемой — было бы пофикшено ещё в ранних бетах/ctp. Как появились ресурсы — поправили, но обратного переноса (с clr4 на clr2) не было по одной простой причине — MS не тратит ресурсы на добавление новых фич в старые версии продуктов. Политика.
E>А так, спасибо за инфу. Я раньше не думал, что идеология платформы столь сильно парализует волю разработчиков под неё E>Или это всё-таки отбор?
Не, это наброс.
Здравствуйте, Sinix, Вы писали:
E>>1) дотнетовский аллокатор вообще очень плохо совместим с большими кускам памяти, в отличии от кучи других аллокаторов. Не в последнюю очередь и потому, что он вообще неправильно с большими объектами работает.
S>Ошибка уже в первом пункте S>Я наверно раза четыре написал, что шансы получить OOM в реальном приложении именно из-за фрагментации кучи стремятся к 0. Но даже этот 0 обходится элементарно — переходом на x64, обновлением фреймворка, или (наконец) изучением матчасти.
В смысле "ошибка" Так етсь таки проблемы с фрагментацией LOH или нет?
S>Итак, раз уж мы говорим за 10 лет — где хоть одна статья с описанием нерешаемых проблем, вызванными особенностями LOH? Только плиз, написанная нормальным разработчиком со знанием матчасти, а не "Вау, мы поломали дотнет!"
Ты всё время тут пытаешься найти какие-то за и против шарпа. А мне это не интренесно, IMHO, это просто инструмент со своим кругом задач. И всё. Мне интересно, как решали таки проблему с плохой работой аллокатора больших объектов? Судя по гуглению форумов всяких, проблема таки была, а хорошего решения я не нашёл, в смысле при гуглении. И тут никто не сказал ничего кроме двух
1) перейти на х64
2) перейти на новый рантайм.
Ну, то есть решение и отладку проблемы разработчики пререложили на всторов рантайма. Так же, например, пользователи ворда не бросаются чего-то там допиливать в ворде, что бы оно не падало на больших документах, а обновляют ворд, например. Это не говорит о тех или иных людях чего-то плохого или хорошего, это просто другой подход, скорее всего он оправдан экономически и всё такое.
Но просто сама по ссебе разница в подходах тоже, похоже есть, и она забавная.
S>Во-первых, аллокатор LOH принципиально ничем не отличается от аллокаторов в других языках — та жа куча + free list. Т.е. "На кой ему вообще сдались LOH? Зачем он АП пачками ест?" ровно с теми же основаниями можно спрашивать у c++
В С++ популярные под виндой аллокаторы большие объекты сразу по VirtualAlloc выделяют, без пачек, и сразу же по virtualFree освобождают, тоже без пачек...
S>Не, это наброс.
Ну воздержись от набросов, и пиши конструктивно, чё...
Хотя в КСВ может это и лишнее...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>В смысле "ошибка" Так етсь таки проблемы с фрагментацией LOH или нет?
На практике за 10 лет не встречал ни разу. Как добиться — в курсе, но зачем так делать — ума не приложу
E>Ты всё время тут пытаешься найти какие-то за и против шарпа.
Да ладно Пролистай последние 2 страницы
шарповый аллокатор тупит на больших блоках
...
тот дотнетовский аллокатор, который работает сейчас в программах у пользователей -- УГ
...
Евгений сейчас за два дня разобрался в проблеме лучше вас двоих обоих "спецов" по шарпу
...
У тебя недержание контекста? Есть List. На кривом аллокаторе его использовать трудно — так?
...
прибежали C#'исты с криками о том, что я даже чуть-чуть не разбираюсь, нужно читать доки, что проблема давно обкостылевается
Это _я_ пытаюсь найти за и против?
E>Мне интересно, как решали таки проблему с плохой работой аллокатора больших объектов? Судя по гуглению форумов всяких, проблема таки была, а хорошего решения я не нашёл, в смысле при гуглении. И тут никто не сказал ничего кроме двух E>1) перейти на х64 E>2) перейти на новый рантайм.
... 3. Использовать постоянный (кратный) размер блоков
4. Избегать лишних аллокаций
Ну так это общие (заведомо рабочие) рекомендации. Чтобы посоветовать что-то более конкретное, нужно лезть и разбираться. Причём разбираться придётся долго и нудно, на реальном приложении и с профайлером памяти, ну, или хотя бы с дампом+windbg. Ну и сама проблема достаточно редкая. Быстро погуглил, получил:
1. А может ли оно упасть?
However, after my last post last night, I decided to bite the bullet and test this vigorously. I left a small program running overnight which continually allocated large byte arrays on multiple threads. The idea is that if LOH fragmentation was a concerned, then the program would eventually crash with OutOfMemory exception as a result of massive fragmentation. To my great surprise it didn't. It ran for about 5 hours. My servers assuming its reasonably active, are not going to generate that many buffers in month. More telling, the working set of the application stayed stable. I can only assume that LOH fragmentation is an old problem or MS foresaw this an specifically optimized for large byte arrays since its so ubiquitous in the framework. So it seems its been a non-issue from the start.
2. OutOfMemoryException при попытке запихнуть большой лог в список. Чёрт его знает, как автор этого добился, в топике подробностей нет. Единственная мысль — в списке были большие структуры и человек словил ограничение в 2гб на размер массива.
Собственно, всё
E>Ну, то есть решение и отладку проблемы разработчики пререложили на всторов рантайма. Так же, например, пользователи ворда не бросаются чего-то там допиливать в ворде, что бы оно не падало на больших документах, а обновляют ворд, например.
Эмм, ну а как поступают нативщики, если их не устраивает выхлоп текущей версии компилятора притом что в следующей оно уже исправлено? Переписывают?
E>В С++ популярные под виндой аллокаторы большие объекты сразу по VirtualAlloc выделяют, без пачек, и сразу же по virtualFree освобождают, тоже без пачек...
Так и LOH делает примерно так же — резервируется сегмент (сегменты) АП и затем по мере необходимости или освобождаются, или переиспользуются. Собственно, в 1.0 и использовался malloc. Вся проблема — в не совсем корректном поиске свободных фрагментов в нескольких очень частных сценариях. Но даже для таких извратов (если иначе никак) были предусмотрены костыли. Я где-то выше уже приводил ссылку:
In CLR 2.0 we added a feature called VM Hoarding that may be applicable if you are in a situation where segments (including those for both the large and small object heaps) are frequently acquired and released. To specify VM Hoarding, you specify a startup flag called STARTUP_HOARD_GC_VM via the hosting API (see go.microsoft.com/fwlink/?LinkId=116471). When you specify this, instead of releasing empty segments back to the OS, the memory on these segments is simply decommitted and put on a standby list. The segments on the standby list will be used later to satisfy new segment requests. So next time I need a new segment, I'll use one from this standby list if I can find one that's big enough.
Note that this isn't done for the segments that are too large. This feature is also useful for applications that want to hold onto the segments that they've already acquired, like some server apps that seek to avoid fragmentation of the VM space as much as they can so that they don't cause out-of-memory errors
Здравствуйте, Erop, Вы писали:
E>В смысле "ошибка" Так етсь таки проблемы с фрагментацией LOH или нет?
Проблемы есть и было сказано, когда и при каких условиях они возникают.
S>>Итак, раз уж мы говорим за 10 лет — где хоть одна статья с описанием нерешаемых проблем, вызванными особенностями LOH? Только плиз, написанная нормальным разработчиком со знанием матчасти, а не "Вау, мы поломали дотнет!"
E>Ты всё время тут пытаешься найти какие-то за и против шарпа. А мне это не интренесно, IMHO, это просто инструмент со своим кругом задач. И всё. Мне интересно, как решали таки проблему с плохой работой аллокатора больших объектов? Судя по гуглению форумов всяких, проблема таки была, а хорошего решения я не нашёл, в смысле при гуглении. И тут никто не сказал ничего кроме двух E>1) перейти на х64 E>2) перейти на новый рантайм.
Естетсвенно, т.к. в общем случае задача нерешаема. Точно так же и в С++ — ты можешь накидать аллокаторы, но все равно для каждой стратегии аллокации будет худший сценарий, который и даст фрагментацию.
E>В С++ популярные под виндой аллокаторы большие объекты сразу по VirtualAlloc выделяют, без пачек, и сразу же по virtualFree освобождают, тоже без пачек...
Это никакого отношения к фраментации АП не имеет. Я показал два сценария, в которых твой VirtualAlloc ничем не помогает.
Здравствуйте, Sinix, Вы писали:
S>На практике за 10 лет не встречал ни разу. Как добиться — в курсе, но зачем так делать — ума не приложу
Ну, то есть, на практике этот острый угол просто обходят, в том числе и избегая индексируемых по числу больших коллекций. Я так тебя и понял. Прямого способа пофиксить косяк аллокатора на практике, как я понял, не применяют.
S>
S>шарповый аллокатор тупит на больших блоках
S>...
S>тот дотнетовский аллокатор, который работает сейчас в программах у пользователей -- УГ
Дык тупит и УГ же, если есть большие списки. Мало того, сама MS это признала и в текущей версии рантайма поправила, но у пользователей большинство программ пока что ещё на старом рантайме же?..
Если тебе обидно читать про неудовлетворительную работу аллокатора больших блоков в дотнете, как про УГ, то прошу прощения, не дума, что кто-то так трепетно к нему относится. Я не специально, Термин НРАББ тебя устроит?
S>
S>Евгений сейчас за два дня разобрался в проблеме лучше вас двоих обоих "спецов" по шарпу
Это про этих двух конкретных людей написано. И да, походу таки лучше.
S>
S>У тебя недержание контекста? Есть List. На кривом аллокаторе его использовать трудно — так?
S>...
S>прибежали C#'исты с криками о том, что я даже чуть-чуть не разбираюсь, нужно читать доки, что проблема давно обкостылевается
Это вообще не мои реплики... И я с ними если и согласен по сути, то не особо по форме. S>Это _я_ пытаюсь найти за и против?
Твоего текста в процитированном нет. Но ты, как адекватный знаток платформы мог бы просто внести ясность по сути вопроса, а не рассказывать, что кто-то там зря разными шарпами компилировал, вместо того, что бы строчку в манифесте менять.
Хотя мне так кажется, что это не ты рассказывал.
В общем и в целом, я не знаю, возможно я что-то обидное нечаянно сказал, но суть всё равно свелась к двум тезиса.
1) АББРН
2) Эту проблему обходили выбирая другие алгоритмы/платформы, а не коллекции.
S>... 3. Использовать постоянный (кратный) размер блоков
Да, грануляция, я про то и говорил с самого начала. Только это хорошо бы, что бы поддерживалось таки в контейнере самом. Как называется аналог листа, но с грануляцией размеров буфера?
Ну и вторая беда, насколько я понял, как работал АББ раньше, даже грануляция ему поможет не так сильно, как могла бы. S>4. Избегать лишних аллокаций
Это, скорее всего, просто отсрочит взрыв.
S>Эмм, ну а как поступают нативщики, если их не устраивает выхлоп текущей версии компилятора притом что в следующей оно уже исправлено? Переписывают?
Кто как. Проблемы тоже разные бывают, но в целом да, есть группы, корторые фиксят такого рода баги задолго до того, как протормозятся авторы компилятора...
Ну, в некоторые компиляторы, опять же, можно патчи свои предлагать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
S>>На практике за 10 лет не встречал ни разу. Как добиться — в курсе, но зачем так делать — ума не приложу E>Ну, то есть, на практике этот острый угол просто обходят, в том числе и избегая индексируемых по числу больших коллекций. Я так тебя и понял. Прямого способа пофиксить косяк аллокатора на практике, как я понял, не применяют.
Нет его, прямого способа. Не существует.
E>Дык тупит и УГ же, если есть большие списки. Мало того, сама MS это признала и в текущей версии рантайма поправила, но у пользователей большинство программ пока что ещё на старом рантайме же?..
Подфиксить можно только кое что. В общем случае проблема нерешаема.
E>В общем и в целом, я не знаю, возможно я что-то обидное нечаянно сказал, но суть всё равно свелась к двум тезиса. E>1) АББРН E>2) Эту проблему обходили выбирая другие алгоритмы/платформы, а не коллекции.
Здравствуйте, Sinix, Вы писали:
E>>>>Пока что удалось выяснить что E>>>>1) дотнетовский аллокатор вообще очень плохо совместим с большими кускам памяти, в отличии от кучи других аллокаторов. Не в последнюю очередь и потому, что он вообще неправильно с большими объектами работает. S>>>Ошибка уже в первом пункте E>>В смысле "ошибка" Так етсь таки проблемы с фрагментацией LOH или нет? S>На практике за 10 лет не встречал ни разу. Как добиться — в курсе, но зачем так делать — ума не приложу
Так в чём ошибка? В том что это неправда, или в том что ты этого не встречал?
E>>Ты всё время тут пытаешься найти какие-то за и против шарпа. S>Да ладно Пролистай последние 2 страницы S>
шарповый аллокатор тупит на больших блоках [...]
S>тот дотнетовский аллокатор, который работает сейчас в программах у пользователей -- УГ
Правда же
S>
У тебя недержание контекста? Есть List. На кривом аллокаторе его использовать трудно — так?
Тебе форма не нравится? Так это обращение к Ikemefula — он вообще-то заслужил
S>
прибежали C#'исты с криками о том, что я даже чуть-чуть не разбираюсь, нужно читать доки, что проблема давно обкостылевается
S>Вы хоть чуть-чуть разберитесь, перед тем как писать.
а в чём именно не разобрался так и не сказал
S>Это _я_ пытаюсь найти за и против?
Мы тут не пытаемся найти минусы/плюсы разных языков/сред, а обсуждаем конкретную проблему.
S>1. А может ли оно упасть? S>2. OutOfMemoryException при попытке запихнуть большой лог в список. Чёрт его знает, как автор этого добился, в топике подробностей нет. Единственная мысль — в списке были большие структуры и человек словил ограничение в 2гб на размер массива.
Оба сообщения датируются 2012 годом, как минимум .NET 4.0 (в которой ситуация с аллокацией чуть лучше чем в предыдущих) уже доступна.
Кстати, там советы вида:
>The only way that I know of is Object Pooling, I know that it can be a pain in the rear(not the word I wanna choose), but it is an option.
[...]
>You could cap the size of the packets below the 80k limit. Then your buffers won't go on the LOH. Weigh up the speed gains from packets >80k against the need to specifically manage all the large objects.
Здравствуйте, Erop, Вы писали:
S>>На практике за 10 лет не встречал ни разу. Как добиться — в курсе, но зачем так делать — ума не приложу E>Ну, то есть, на практике этот острый угол просто обходят, в том числе и избегая индексируемых по числу больших коллекций. Я так тебя и понял. Прямого способа пофиксить косяк аллокатора на практике, как я понял, не применяют.
Неа. Именно что не встречал, т.е. не было необходимости обходить. "Прямые" способы (включая флаг VM hoarding для самых отчаянных) я уже приводил раза три, не меньше. Пока возражения сводятся к "не верю, проблема должна быть"
E>Дык тупит и УГ же, если есть большие списки. Мало того, сама MS это признала и в текущей версии рантайма поправила, но у пользователей большинство программ пока что ещё на старом рантайме же?..
1. Давай наконец пример, только реальный, а не из разряда "подстелил соломки потому что прочитал про фрагментацию".
2. Ок, в четвёртый раз: если написать софт, который
a. работает исключительно под x86
b. всё время аллоцирует короткоживущие массивы всё увеличивающегося размера
c. вперемешку аллоцирует долгоживущие массивы
— то да, благодаря фрагментации можно получить out of memory exception. Если любое из этих условий не соблюдается — исключения не будет. На практике этот сценарий крайне маловероятен, во всяком случае я не встречал упоминаний кроме как в контексте "не делайте так, будет плохо". Как дошли руки — грабли убрали, но это не значит что сценарий выше стал "хорошим" — мы по-прежнему засоряем АП и нагружаем GC.
E>Это вообще не мои реплики... И я с ними если и согласен по сути, то не особо по форме.
В курсе Имел в виду общую атмосферу в ветке, благодаря ей "Ты всё время тут пытаешься найти какие-то за и против шарпа" смотрится особенно шикарно Надо было уточнить сразу, согласен
E>Твоего текста в процитированном нет. Но ты, как адекватный знаток платформы мог бы просто внести ясность по сути вопроса, а не рассказывать, что кто-то там зря разными шарпами компилировал, вместо того, что бы строчку в манифесте менять.
Эмм? Я про "строчку в манифесте" точно не писал, вы там запутались уже
S>>... 3. Использовать постоянный (кратный) размер блоков E>Да, грануляция, я про то и говорил с самого начала. Только это хорошо бы, что бы поддерживалось таки в контейнере самом. Как называется аналог листа, но с грануляцией размеров буфера?
Обычно зовётся paged list или chunked list. Из готовых есть BigList в PowerCollections, в своё время писал аналог, но не из-за LOH — нужны были эффективные immutable-списки. Может есть ещё что-то, но вспомнить не могу.
E>Ну и вторая беда, насколько я понял, как работал АББ раньше, даже грануляция ему поможет не так сильно, как могла бы.
Угу, частично фрагментация АП оставалась.
S>>4. Избегать лишних аллокаций E>Это, скорее всего, просто отсрочит взрыв.
Неа. В единственном критичном примере именно куча мусора с всё увеличивающимся размером и вызывает фрагментацию LOH.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
S>>На практике за 10 лет не встречал ни разу. Как добиться — в курсе, но зачем так делать — ума не приложу
EP>Так в чём ошибка? В том что это неправда, или в том что ты этого не встречал?
Все аллокаторы плохо совместимы с большими кусками данных Проблема с большими кусками данных в общем случае не решаема при фиксированом АП.
EP>Кстати, там советы вида: EP>
>>The only way that I know of is Object Pooling, I know that it can be a pain in the rear(not the word I wanna choose), but it is an option.
EP>[...]
>>You could cap the size of the packets below the 80k limit. Then your buffers won't go on the LOH. Weigh up the speed gains from packets >80k against the need to specifically manage all the large objects.
EP>Что скорее подтверждает выводы озвученные Erop'ом
С большими списками есть одна проблема — в них много элементов В частности, это означает что потерь памяти будет слишком много.
Скажем в моем приложении в самых тяжелых случаях по 30млн объектов. Это значит, в кратце, что 240мб будет потрачено, если все эти объекты заменить на Object, то есть, ни грамма пользовательских данных.
Вы же с Егором хотите как то под особым углом посмотреть, так что бы проигнорировать все особенности GC как инструмена вообще, без привязки к дотнету, а потом сделать вывод : "Сообщество шарпистов ..."
Вроде ясно было показано, что проблема
1. свойственна для любого GC
2. не-GC аллокатора так же свойственна
А все ваши басни про VirtualAlloc только подкрепляют уверенность, что вы оба совершенно не в теме
Здравствуйте, Sinix, Вы писали:
S>>>... 3. Использовать постоянный (кратный) размер блоков E>>Да, грануляция, я про то и говорил с самого начала. Только это хорошо бы, что бы поддерживалось таки в контейнере самом. Как называется аналог листа, но с грануляцией размеров буфера? S>Обычно зовётся paged list или chunked list. Из готовых есть BigList в PowerCollections
BigList это аналог std::map<std::size_t, T>, с O(log(N)) random access. А нужен именно аналог листа, чтобы после замены не выросла сложность алгоритма
Здравствуйте, Sinix, Вы писали:
S>Неа. Именно что не встречал, т.е. не было необходимости обходить. "Прямые" способы (включая флаг VM hoarding для самых отчаянных) я уже приводил раза три, не меньше. Пока возражения сводятся к "не верю, проблема должна быть"
VM hoarding только чуток оттянет конец
В фиксированом АП проблема не в общем случае не решается, хоть GC, хоть дефолтный С++ хип, хоть приседания с VirtualAlloc
