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

I>>

I>>Error: bad allocation

I>>"не дохнет" это оно ?

V>Дык, область в 2 гига кончилась. Как и должно быть. 680*3=x. )))

Протри глаза — 3 никак не может быть. Куда делось АП ?

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

V>Как пример boost::pool. Хотя и до него подобный вид аллокаторов — самый что ни на есть популярный в плюсах. Самое главное — он на заметно эффективнее даже управляемого GC. Вряд ли ты найдешь сейчас хоть одну плюсовую контору, где бы не использовали страничные аллокаторы и пулы объектов на них.

Про что и речь — сейчас почти любой проект на С++ это в т.ч. написание всевозможных аллокаторов.

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

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

Возможно... Но мне даже трудно представить задачу, когда нам нужно десятки/сотни миллионов элементов в линейном массиве.

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

I>>>

I>>>Error: bad allocation

I>>>"не дохнет" это оно ?
V>>Дык, область в 2 гига кончилась. Как и должно быть. 680*3=x. )))
I>Протри глаза — 3 никак не может быть. Куда делось АП ?

В GCC grow factor как раз 2, так что на реаллокации получается 3x

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

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

V>Возможно... Но мне даже трудно представить задачу, когда нам нужно десятки/сотни миллионов элементов в линейном массиве.

Не нужно ни десятков, ни сотен, часто хватает и 100 тыс и даже менее. LOH очень часто сильно ограничен в размере по естетсвенным причинам. Имеющиеся дыры в нем как правило небольшого размера. Вроде есть десяток хипов LOH, суммарно это 160 мб, что очень много вообще говоря, но в каждом из хипов непрерывного участка будет не более 10мб а то и меньше.
Для хештейблов например это вообще ни о чем.

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

I>>Протри глаза — 3 никак не может быть. Куда делось АП ?

EP>В GCC grow factor как раз 2, так что на реаллокации получается 3x

Шота я не пойму, grow factor меняется в зависимости от требуемого аргумента — то 1.5, то 2

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

I>>>Протри глаза — 3 никак не может быть. Куда делось АП ?
EP>>В GCC grow factor как раз 2, так что на реаллокации получается 3x
I>Шота я не пойму, grow factor меняется в зависимости от требуемого аргумента — то 1.5, то 2

grow factor может быть разным в разных реализациях. В исходном примере торчат следы как MSVC(много), так и GCC(мало).
И нет ничего трагичного в том, что vdimas назвал цифру соответствующую GCC, а не MSVC — это не так сильно влияет на пример

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

I>То есть, VirtualAlloc никак не помогает. Ровно тот же результат можно получить если выделять память сразу одним куском в 2гб и потом нарезать его на хипы для больших и малых объектов.

То есть VA -- это ШТАТНЫЙ в WinApi аллокатор АДРЕСНОГО ПРОСТРАНСТВА,.. Оно умеет не тока закомиченную память выдавать, но и зарезервированную, то есть АП как оно есть.
Поэтому чем меньше у тебя будет прослоек между твоим аллокатором памяти, в случае аллокации больших кусков, и аллокатором АП, тем меньше шансов нарваться на фрагментацию АП НЕ ПО ДЕЛУ...

I>Все что дает VirtualAlloc это быстродействие.
Мальчик, иди, отсюда. Не, прапвда, ты вот правда думаешь, что если кусануть по VA сразу полгига памяти, а потом её там распределять как-то, то это будет медленнее, чем вызывать VA?

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

Итак, до какого размера списка байтов можно в него пихать байты, что бы не парится о фрагментации?
До мегабайта можно? А до 10? А до 100?

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

I>Не нужно ни десятков, ни сотен, часто хватает и 100 тыс и даже менее.

Во-о-о-от, началась конкретка. Я верноп онимаю, что 100 тысяч элементов -- это полмегабайта памяти?
Или речь о элементах по килобайту каждый?..

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

I>>Не нужно ни десятков, ни сотен, часто хватает и 100 тыс и даже менее.

E>Во-о-о-от, началась конкретка. Я верноп онимаю, что 100 тысяч элементов -- это полмегабайта памяти?

Эта конкретика уже в пятый раз приводится.

E>Или речь о элементах по килобайту каждый?..

Читай внимательно.

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

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

Да нет, тут сложнее. Напишет он или нет, и если напишет , то что именно — этого я не знаю. Но для него код действительно ужасный. Вот если бы я употребил бы template, перегрузил бы какие-то операторы, сделал бы какой-нибудь итератор, прицепил xyz_ptr и zyx_cast и т.д. — тогда его бы устроило. А когда пишется просто и коротко — это ужасно.

Что тут поделаешь... Я все же останусь с таким стилем кода, он меня еще никогда не подводил. А они пусть пишут все свои примочки, без них им никуда.

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

E>>Я верно понимаю, что 100 тысяч элементов -- это полмегабайта памяти?
I>Читай внимательно.

То есть в С# проблема уже полметра ОЗУ подряд выделить? IMHO это просто тупо неработоспособно. Я не верю, что всё так плохо. Это же ни "Унесённые ветром", ни "Войну и мир" даже в масив букв не положить же

Люди, сведующие в вопросе, Ikemefula точно не преувеличивает гнилось платформы?..

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

I>>То есть, VirtualAlloc никак не помогает. Ровно тот же результат можно получить если выделять память сразу одним куском в 2гб и потом нарезать его на хипы для больших и малых объектов.

E>То есть VA -- это ШТАТНЫЙ в WinApi аллокатор АДРЕСНОГО ПРОСТРАНСТВА,..

Аллокатор адрессного пространства это шедевр

>Оно умеет не тока закомиченную память выдавать, но и зарезервированную, то есть АП как оно есть.

Аллокатор подразумевает ,что когда тебе нужен ресурс новый или старый закончился, аллокатор навыделяет тебе еще этого самого русурса.
Как это можно сделать — не совсем ясно. Наверное это будет так — есть окно от 1гб до 1.1гб, надо выделить 200мб, аллокатор адрессного пространства довыделит 100мб и опаньки — в окно 100мб размещаем 200мб данных, только байты будут нумероваться не целыми числами, а дробными

E>Поэтому чем меньше у тебя будет прослоек между твоим аллокатором памяти, в случае аллокации больших кусков, и аллокатором АП, тем меньше шансов нарваться на фрагментацию АП НЕ ПО ДЕЛУ...

То есть, VirtualAlloc ни при чем, т.к. это же можно повторить и без него, а именно с помощью конкретного сценария управления хипом.

I>>Все что дает VirtualAlloc это быстродействие.
E>Мальчик, иди, отсюда. Не, прапвда, ты вот правда думаешь, что если кусануть по VA сразу полгига памяти, а потом её там распределять как-то, то это будет медленнее, чем вызывать VA?

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

E>Собственно тебе ужо всё показали, рассказали и книжки нужные читать послали до полного просветления.

"аллокатор АДРЕСНОГО ПРОСТРАНСТВА"

E>Так что тему помогает там VA фрагментации или мешает закрыть, каждый останется при свом мнении, у кого подкреплённом тестами и знаниями, а у кого всякими там соображениями, не суть, и вернуться к тобой же созданному топику.

Ты так и не показал, как VirtualAlloc поможет в приведеных мною сценариях

E>Итак, до какого размера списка байтов можно в него пихать байты, что бы не парится о фрагментации?
E>До мегабайта можно? А до 10? А до 100?

Все ответы уже дадены — зависит от свободных окон в адресном пространстве.

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

E>>>Я верно понимаю, что 100 тысяч элементов -- это полмегабайта памяти?
I>>Читай внимательно.

E>То есть в С# проблема уже полметра ОЗУ подряд выделить? IMHO это просто тупо неработоспособно. Я не верю, что всё так плохо. Это же ни "Унесённые ветром", ни "Войну и мир" даже в масив букв не положить же

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

С этими приложениями точно так же как и в С++ — выюзаешь или фрагментируешь всю память, а потом, внезапно, "войну и мир" на массив букв не разложить.

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

I>Аллокатор адрессного пространства это шедевр
Ну в целом да, это они в WinApi прикольно прдумали...
Или ты это подкалываешь просто?
Тогда что, по твоему, делает VA, когда ты его зовёшь для reserve?..
Разве не аллокирует для твоих нужд часть АП?..

I>Аллокатор подразумевает ,что когда тебе нужен ресурс новый или старый закончился, аллокатор навыделяет тебе еще этого самого русурса.
Ну так VA же так и делает, пока АП не закончится...

I>Как это можно сделать — не совсем ясно. Наверное это будет так — есть окно от 1гб до 1.1гб, надо выделить 200мб, аллокатор адрессного пространства довыделит 100мб и опаньки — в окно 100мб размещаем 200мб данных, только байты будут нумероваться не целыми числами, а дробными

Прости, что за бред ты тут написал? VA в WinApi умеет выделять закоммиченную память, то есть память процесса, а может резервировать АП, то есть выделять диапазоны АП, куда потом омжно память коммитить, если она ещё будет доступна, конечно. То есть имеем двухуровневую схему аллокации. Я уверен, что ты всё это знаешь, поэтому твои подколки мне не ясны.

I>То есть, VirtualAlloc ни при чем, т.к. это же можно повторить и без него, а именно с помощью конкретного сценария управления хипом.

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

I>И это очевидно вобщем то. VirtualAlloc позволяет выбирать, когда именно коммитать физическую памяти. Без этого будут приседания с виртуальной памятью в обязательном порядке.

Не понял. Когда хип выделяет память, он выделяет срузу закоммиченную же?
У нас есть два альтернативных сценария.
1) Выделить полтора гига по VA и там дальше кусать на блоки нужного размера.
2) Выделять большие блоки по отдельному VA каждый.

Ты правда думаешь, что второе быстрее?

I>Ты так и не показал, как VirtualAlloc поможет в приведеных мною сценариях
Тебе не поможет ничего, аминь. Написать не падающую по ООМ при достаточно долгой работе 32-битную программу с вектором/листом внутри в принципе невозможно, все контрпримеры -- миф.
IMHO, тут больше нечего обсуждать, ты прав и жизнь -- гавно.

I>Все ответы уже дадены — зависит от свободных окон в адресном пространстве.
О! То есть ответ такой, что ни на что нельзя надеяться... понимаю.

Давай я попробую перевести. Положим у нас есть какая-то типичная программа из нескольких компонент сляпанная, часть нативные, часть -- дотнет, или все дотнет, можно и тот и тот случай рассмотреть. Ей одномоментно не надо больше 0.5 Гига памяти никогда, например, листами какого размера ещё можно оперировать не заморачиваясь?..

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

I>Если бы ты читал внимательно, то нашел бы, что речь идет не о всех приложениях, а примерно пятой части, которая наиболее ресурсоемкая.

Это уже просто всякие истории про программирование на грани фола. Это довольно специальный случай же?
И всё равно как-то странно, что полуметра подряд не сыскать в памяти такого приложения. А как там заводятся нитки со совими стеками, например?.. Или для них таки находится место, волшебным образом?

I>С этими приложениями точно так же как и в С++ — выюзаешь или фрагментируешь всю память, а потом, внезапно, "войну и мир" на массив букв не разложить.

Ну если руки кривые, то и сам знаешь что сломать можно

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

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

I>>Если бы ты читал внимательно, то нашел бы, что речь идет не о всех приложениях, а примерно пятой части, которая наиболее ресурсоемкая.

E>Это уже просто всякие истории про программирование на грани фола. Это довольно специальный случай же?

Случай специфический, но встречается относительно часто. Я даже указал: где, когда и почему.

E>И всё равно как-то странно, что полуметра подряд не сыскать в памяти такого приложения. А как там заводятся нитки со совими стеками, например?.. Или для них таки находится место, волшебным образом?

Пол-мега может быть, а может и не быть. Именно пол-мега — это редкий случай, практически вырожденый, но я встречал и такие, при чем, что интересно, в коде 3rd party с которыми приходилось иметь дело.

I>>С этими приложениями точно так же как и в С++ — выюзаешь или фрагментируешь всю память, а потом, внезапно, "войну и мир" на массив букв не разложить.

E>Ну если руки кривые, то и сам знаешь что сломать можно

В больших приложениях, как тебе уже сообщили, АП всегда фрагментировано.

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

I>Случай специфический, но встречается относительно часто. Я даже указал: где, когда и почему.

Это понятно и где и когда и почему же. Это когда что-то тяжёлое и для этого не предназначенное тянут за каким-то хреном инпроц в свой АП...

I>Пол-мега может быть, а может и не быть. Именно пол-мега — это редкий случай, практически вырожденый, но я встречал и такие, при чем, что интересно, в коде 3rd party с которыми приходилось иметь дело.

А зачем ты лез в АП столь плотно заоптимизированного кода?

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

I>>Аллокатор адрессного пространства это шедевр
E>Ну в целом да, это они в WinApi прикольно прдумали...
E>Или ты это подкалываешь просто?
E>Тогда что, по твоему, делает VA, когда ты его зовёшь для reserve?..
E>Разве не аллокирует для твоих нужд часть АП?..

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

I>>Аллокатор подразумевает ,что когда тебе нужен ресурс новый или старый закончился, аллокатор навыделяет тебе еще этого самого русурса.
E>Ну так VA же так и делает, пока АП не закончится...

Ты путаешь адресное пространство и память. Когда процесс создан, не надо в нем выделять АП, его винда для тебя выделила — 2гб. Делай с ним что хочешь.

E>Прости, что за бред ты тут написал? VA в WinApi умеет выделять закоммиченную память, то есть память процесса, а может резервировать АП, то есть выделять диапазоны АП, куда потом омжно память коммитить, если она ещё будет доступна, конечно. То есть имеем двухуровневую схему аллокации. Я уверен, что ты всё это знаешь, поэтому твои подколки мне не ясны.

Резервировать АП != выделять АП.

E>В смысле? Если весь код в твоей прогамме, включая системыне вызовы, а так же загрузчик DLL'ек, выделялка стеков для нитей, отображалка файлов на память и т. д. будут выделять для своих нужд диапазоны АП через твой хип, то да...
E>при этом ещё сам твой хип не должен будет вносить излишней фрагментации в АП, то есть кусать диапазоны АП не пачками, а сразу всё АП брать под своё управление.

Системные пусть живут сами по себе. А вот приложение может выделять как угодно.

E>Не понял. Когда хип выделяет память, он выделяет срузу закоммиченную же?
E>У нас есть два альтернативных сценария.
E>1) Выделить полтора гига по VA и там дальше кусать на блоки нужного размера.
E>2) Выделять большие блоки по отдельному VA каждый.

E>Ты правда думаешь, что второе быстрее?

Ты лучше читать попробуй. Опохмеляться давно начал ?

I>>Ты так и не показал, как VirtualAlloc поможет в приведеных мною сценариях
E>Тебе не поможет ничего, аминь. Написать не падающую по ООМ при достаточно долгой работе 32-битную программу с вектором/листом внутри в принципе невозможно, все контрпримеры -- миф.

И долго ты до этого доходил ?

I>>Все ответы уже дадены — зависит от свободных окон в адресном пространстве.
E>О! То есть ответ такой, что ни на что нельзя надеяться... понимаю.

Разумеется.

E>Давай я попробую перевести. Положим у нас есть какая-то типичная программа из нескольких компонент сляпанная, часть нативные, часть -- дотнет, или все дотнет, можно и тот и тот случай рассмотреть. Ей одномоментно не надо больше 0.5 Гига памяти никогда, например, листами какого размера ещё можно оперировать не заморачиваясь?..

Не знаю. 0.5 гига это смотря как выделялось. Иногда сверх этого можно выделить всего 300мб, а иногда и до 400-600, а иногда и больше гига. Иногда — 0. Вот такой вот парадокс. Если вообще все хорошо — то как в С++, исключая 200мб — издержки на все менеджед расходы.

Ты пойми простую вещь — нативные модули едят АП, нативные функции едят АП, сборки едят АП, джыт ест АП, GC сам ест АП, нативные потоки едят АП, CRL и тот ест АП, интероп снова ест АП.
Поэтому для большого х32 приложения, где все намешано, больше чем на 1гб памяти под твои объекты можно не надеяться, хотя все АП 2гб. Дальше надо вычитать все издержки на фрагментацию и имеющиеся расходы. Что в итоге — не ясно.

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

I>Про что и речь — сейчас почти любой проект на С++ это в т.ч. написание всевозможных аллокаторов.

Кстате, страничный аллокатор или пул объектов — неплохая тестовая задачка для студента или вчерашнего студента. Как раз ему на час-другой работы.

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