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

PD>

PD>...
PD>

какой ужасный код.

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

EP>Почему бы и нет
capcityТак и я о том же Тту вроде есть ребята, которые с комитетом общаются, думаю, они и эту флудильню проглядывают. Я-то как-то с комитетом не накоротке ;(

M>>Дека не гарантирует непрерывности куска памяти, а вектор гарантирует. В данном случае деке пофигу, но если непрерывность критична (насчет .Net не знаю) — то ой.

EP>Непрерывность вектора действительно иногда бывает полезна сама по себе. Но чаще она полезна просто как самый быстрый кусок данных.
EP>Ikemefula вроде говорил что у него где-то на .net с vector-like были проблемы, да причём такие, что он теперь векторов как огня боится. Вот я и удивляюсь — почему в .net нет стандартной деки (или всё-таки есть?).
Ну, я начало уже не помню, я встрял, когда спор достиг определенного накала

M>>>>Мой результат такой (код в конце):

EP>Это возможность убрать ~49 первых реаллокаций и убедится что дело не в них. (с обсуждения этих реаллокаций как раз и начинался этот топик)
См. выше
Я влез на разборках по фрагментации.
Мой тест #1 сказал, что можно выделить одномоменто в свежей программе 1900Мб. Ты этот момент пролистал не глядя?
Не совсем понял, как одномоментная аллокация памяти поможет опровергнуть гипотезу, что фрагментация мешает?

EP>>>Допустим для x64 — ты какой бы порог взял? Для некоторых приложений 1.1 после 500MB было бы слишком тормозно.
M>>Ну, для 64 бит пока вроде не проблемы фрагментации АП как класса задач А для 32 — да, тормозно, но ковыляло бы

EP>Я думал мы тут уже не об фрагментации говорим, а об свободной памяти — она ведь не бесконечна. И точно такая же проблема возможна и на x64, кстати, как раз потому, что дело не во фрагментации.
Ну, кто о чем, я о фрагментации вроде
На 64х битах можно в 99.9(9)% задач говорить о бесконечной памяти (вернее, о бесконечном АП), и проблема фрагментации тут не стоит.

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

M>>>>> Вышенаписанное вообщем-то подтверждает точку зрения Ikemefula, что некоторые менеджеры памяти для C++ не совсем совершенны.
EP>>>>В твоём примере как раз видно, что если и есть фрагментация, то мизерная. Теоретический потолок — 2GiB/2.5, причём это без dll'ек, без стэка и т.п.
EP>>>>Посмотри, например, по каким адресам у тебя dll'ки загрузились, куда .exe, где стэк находится и т.п
M>>>Мизер не мизер, но память делит как минимум на две половины, из которых целое не склеить.
EP>>Это не фрагментация.
EP>>Фрагметация — это пример который приводил Ikemefula раньше — там где посредине АП есть что-то небольшое, что мешает выделить большой кусок.
M>Я вроде под фрагментацией тоже самое и подразумеваю. Или не?

Ты про что именно?

EP>>Тут же просто нехватка памяти. Если бы те ~50 аллокаций что были у тебя действительно фрагментировали бы кучу — то аллокация сфейлилась бы гораздо раньше.
M>Вопрос насколько они кучу сфрагментировали, может совсем чуть-чуть, только в серединке

Они-то могли и сильно сфрагментировать, но твой первый пример, за который уцепился Ikemefula, этого не показывал.

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

EP>>Это возможность убрать ~49 первых реаллокаций и убедится что дело не в них. (с обсуждения этих реаллокаций как раз и начинался этот топик)
M>См. выше
M>Я влез на разборках по фрагментации.
M>Мой тест #1 сказал, что можно выделить одномоменто в свежей программе 1900Мб. Ты этот момент пролистал не глядя?
M>Не совсем понял, как одномоментная аллокация памяти поможет опровергнуть гипотезу, что фрагментация мешает?

Речь про самый первый пример. Если в него добавить reserve — это не будет единственной аллокацией, так как там дальше идёт цикл push_back'ов.
И если с предварительным reserve'ом в ~690MB, он не сможет сделать аллокацию при следующем capacity grow — то это будет означать что пример не годится для демонстрации фрагментации.
+ желательно вывести адрес первого reserve'а, чтобы убедится что этот кусок не по середине (у меня он начинается где-то в районе первых 20MB)

EP>>>>Допустим для x64 — ты какой бы порог взял? Для некоторых приложений 1.1 после 500MB было бы слишком тормозно.
M>>>Ну, для 64 бит пока вроде не проблемы фрагментации АП как класса задач А для 32 — да, тормозно, но ковыляло бы
EP>>Я думал мы тут уже не об фрагментации говорим, а об свободной памяти — она ведь не бесконечна. И точно такая же проблема возможна и на x64, кстати, как раз потому, что дело не во фрагментации.
M>Ну, кто о чем, я о фрагментации вроде
M>На 64х битах можно в 99.9(9)% задач говорить о бесконечной памяти (вернее, о бесконечном АП), и проблема фрагментации тут не стоит.

Допустим есть 10GiB свободной памяти, до куда примерно дорастёт вектор на push_back'ах, при 1.5x capacity grow rate?

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

I>А почему на три надо помножать, если добавляем по одному байту ?

vdimas ошибся, помножать надо на меньшее, но это просто в stl такая стратегия к выделению памяти — при невозможности добавить элемент выделяется память N*k, где N — размер исходного множества, k — некий коэффициент, выбранный эмпирически, вроде это 1.5 обычно. Но памяти нужно при этом 2.5, так как 1 занят исходными данными.

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

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

M>>Я вроде под фрагментацией тоже самое и подразумеваю. Или не?

EP>Ты про что именно?

Ну, вроде пока про фрагментацию памяти, но уже не совсем уверен

EP>>>Тут же просто нехватка памяти. Если бы те ~50 аллокаций что были у тебя действительно фрагментировали бы кучу — то аллокация сфейлилась бы гораздо раньше.
M>>Вопрос насколько они кучу сфрагментировали, может совсем чуть-чуть, только в серединке

EP>Они-то могли и сильно сфрагментировать, но твой первый пример, за который уцепился Ikemefula, этого не показывал.
Ну, а я то тут при чем?

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

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

M>>Я признаться, тоже не понял, как VirtualAlloc поможет. Тут скорее нужен свой аллокатор с использованием memory mapped files.

E>Я же уже писал.
E>Есть два эффекта.
E>1) Когда куче не хватает памяти, она кусает по VA ещё сегмент, в котором проолжает нарезать блоки, потом ещё сегмент, ещё сегмент и т. д. Трудность в том, что эти сегменты трудно освобождать, так как надо понять, что там нет занятых блоков...

Ну ты бывало мне уже доказывал, что я не прав, когда я был 100% уверен что я прав
Но тут ты точно не прав

VA, если я не ошибаюсь, возвращает адрес (в АП процесса) для запрошенного куска памяти. Она может не коммитить, а только резервировать физическую память (или не?). Но как VA может помочь с проблемой фрагментации АП, я как говорится, не догоняю.

А, да. Рихтера читал, Руссиновича со вторым евреем читал, все трое на полке пылятся (где читать, на какой странице, если что?); применял полученные знания в работе, в разных проектах, вроде все работало, но все равно тебя не могу понять

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

I>>>Своим примером ты показал, что VirtualAlloc ничем не помогает, а помогает grow factor 1.5 и то, слабовато, т.е. все равно всё сдохло. То есть, все работает, как и должно.
M>>А ты покажи, как GC на раз решает проблемы

I>Это не интересно, как GC перемещает объекты. Интереснее, как можно выделить 20мб и при этом GC не сможет выделить ни байта, хотя свободной памяти будет ажно 20гб

Ну это level 2, так то. Твой GC level 1 проходит?
Даешь примеры, когда GC уделывает стандартный MSVS2005 runtime heap manager!

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

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

E>>>ну, например, как ты думаешь, если вот тупо взять и написать на плюсах std::vector<char> и начать в него добавлять по одному, миллион символов добавить удостся?..

M>>А ты этим что хотел доказать?

E>Я задал вопрос, я, например, думал и думаю, что метров до 100 можно не парится, потом могут начаться варианты...

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

А по существу — с мыслью, обозначенной чуть выше без сарказма, я вполне согласен. Мои тесты на скорую руку вроде показывают, что не парится можно примерно до 500мб. Плюс-минус немножко. А если больше, то там и танцев с бубнами будет больше. Когда и как часто надо дергать за Dispose-костыли, апологеты GC нам тут конечно ничего не скажут, это не в их интересах

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

V>Не факт. Периодически или же при невозможности найти подходящий непрерывный кусок памяти менеджер хипа занимается поиском и склейкой прилегающих пустых областей.

Это где такое? В CLR для LOH этого пока нет, а в С++ это просто невозможно без замены ссылок на спецконструкции, которые можно отслеживать. Или речь про склейку прилегающих блоков? Если последнее, то это не спасает.

V>В общем, если будешь добавлять по 1-му символу в сишный вектор, то ничего военного не произойдет. Никакой дефрагментации. Освобождаемые предыдущие блоки памяти будут представлять собой непрерывный кусок незанятого места.

Это только если такая работа — единственная активность в процессе.

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

M>А по существу — с мыслью, обозначенной чуть выше без сарказма, я вполне согласен. Мои тесты на скорую руку вроде показывают, что не парится можно примерно до 500мб

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

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

M> Вышенаписанное вообщем-то подтверждает точку зрения Ikemefula, что некоторые менеджеры памяти для C++ не совсем совершенны. Но чтобы он не слишком радовался своей правоте, предлагаю ему привести аналогичные тесты его любимого языка с его любимым GC, чтобы было о чем дальше дискутировать.

Я так понимаю, примерно 100% вновь присоединившихся чуть выше по нитке даже не читают. Тогда напомню тебе, что речь изначально шла про проблемы именно в дотнете, а про С++ разговор зашел, потому что Ероп начал рассказывать, что в С++ таких проблем нет.

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

EP>3. показать лёгкость замены вектора на деку (которой afaik нет в стандартном .net'е)

Есть. LinkedList называется.

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

M>> Вышенаписанное вообщем-то подтверждает точку зрения Ikemefula, что некоторые менеджеры памяти для C++ не совсем совершенны. Но чтобы он не слишком радовался своей правоте, предлагаю ему привести аналогичные тесты его любимого языка с его любимым GC, чтобы было о чем дальше дискутировать.

НС>Я так понимаю, примерно 100% вновь присоединившихся чуть выше по нитке даже не читают. Тогда напомню тебе, что речь изначально шла про проблемы именно в дотнете, а про С++ разговор зашел, потому что Ероп начал рассказывать, что в С++ таких проблем нет.

Ну да, плюс-минус, но 100% не читают

Т.е. в дотнете проблемы есть, в плюсах нет?
о чем речь шла изначально, факт на лице, как говорят.

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

M>Т.е. в дотнете проблемы есть, в плюсах нет?

Проблемы есть и там и там. В дотнете их чуть меньше, потому что фрагментирует память только LOH, остальные кучи дефрагментируются.

M> о чем речь шла изначально, факт на лице, как говорят.

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

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

НС>Это покуда у тебя тесты. А как реальное приложение с кучей разных активностей, да если оно еще и многопоточное, то печаль начинается от объемов на порядок ниже.
Печаль начинается еще раньше, ретроспективно понимаешь, что выбор C# был не самой хорошей идеей, но что уж поделать

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

EP>>3. показать лёгкость замены вектора на деку (которой afaik нет в стандартном .net'е)

НС>Есть. LinkedList называется.

Может LinkedList есть, а легкости замены нет? ж)

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

M>Ну ты бывало мне уже доказывал, что я не прав, когда я был 100% уверен что я прав
M>Но тут ты точно не прав

Ну всё бывает...

M>VA, если я не ошибаюсь, возвращает адрес (в АП процесса) для запрошенного куска памяти. Она может не коммитить, а только резервировать физическую память (или не?). Но как VA может помочь с проблемой фрагментации АП, я как говорится, не догоняю.

Всё так, а помогает он потому, что это такой ОТДЕЛЬНЫЙ аллокатор для больших блоков АП, используемый для этой цели ВСЕМИ аллокаторами в программе.
Виндовые кучи используют такую политику, и с-рантаймовская, тоже, так что авторам всех остальных аллакаторов под винду, тоже стоит ей следовать. Для мне удивительно будет, если окажется, что дотнетовский аллокатор так не делает.

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

M>А, вот я и добрался до ответа на мой первый ответ в этой теме По пути правда потестил на скорую руку очевидные варианты, ну, просто, чтоб закрыть лишние ветки флейма

M>А по существу — с мыслью, обозначенной чуть выше без сарказма, я вполне согласен. Мои тесты на скорую руку вроде показывают, что не парится можно примерно до 500мб. Плюс-минус немножко.

У тебя в тесте слишком стерильная ситуация. Всего один аллокатор и очень простая прога без сторонних DLL там всяких, привязанных к каким-то адресам загрузки, например, да и вектор тоже всего один и большой блок памяти тоже. В реальности вся эта штука не настолько хорошо работает, но до 100 метров на блок точно можно не парится. До 400, если ситуация не слишком нагруженная, и просто не фрагментировать АП попусту. Дальше ужо тонцы
Меня поразило тут то, что I. считает вектор нереально дорогим по памяти, мне кажется, что он преувеличивает

M>А если больше, то там и танцев с бубнами будет больше. Когда и как часто надо дергать за Dispose-костыли, апологеты GC нам тут конечно ничего не скажут, это не в их интересах

Ну это ещё и надо узнать же перед тем, как сказать

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