Memory issues

[SABROG]

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

Все-таки не понимаю чем радикально отличается clean от erase? Первый работает, второй нет.

[BRE]

2) Максимальный размер кучи определятся системой.

Максимальный размер кучи зависит от самого процесса, ограничение связано с размером адресного пространства к которому может обращаться процесс. Для 32-битной системы он составляет 4 Gb.
Под linux пользовательскому коду предоставляется 3 Gb (0x00000000-0xBFFFFFFF), 1 Gb отводиться для ядра (0xC0000000-0xFFFFFFFF).
Под вендой XP (если я правильно помню): 2 Gb - пользователь, 2 Gb - ядро.

В пользовательской адресном пространстве расположены:
* разделяемые библиотеки    (младшие адреса)
* код
* данные
* хип
* стек                                 (старшие адреса)

Т.е. чем больше кода/данных тем меньше адресного пространства остается хипу, даже если система (с учетом свопа) имеет кучу свободной памяти, больше она процессу предоставить не сможет (т.к. процесс не сможет ее адресовать).

[kuzulis]

Фон-неймановские заморочки

[Igors]

Добрый день

(просто инфа, может пригодится). Насчет блока > 1 Gb.  Ничего не меняется в 64-bits, получаю все тот же NULL. Ничего не меняется и если стоит больше памяти (я эту проблему узнал от пользователя у которого стояло восемь)

По поводу баг репорта - по-моему все-таки надо сообщить. В документации ясно сказано:

void QVector::squeeze ()
Releases any memory not required to store the items.
The sole purpose of this function is to provide a means of fine tuning QVector's memory usage. In general, you will rarely ever need to call this function.

Нам память освободить обещали? Да, обещали, более того, прозрачно намекали что, мол, и без этого освободят. Так что пусть освобождают в следующих версиях. А будут они это делать через ::realloc или еще как - это их дело.

И QVector там не один такой - все что завязано на ::realloc тоже будет так себя вести

[BRE]

По поводу баг репорта - по-моему все-таки надо сообщить. В документации ясно сказано:

void QVector::squeeze ()
Releases any memory not required to store the items.
The sole purpose of this function is to provide a means of fine tuning QVector's memory usage. In general, you will rarely ever need to call this function.

Нам память освободить обещали? Да, обещали, более того, прозрачно намекали что, мол, и без этого освободят. Так что пусть освобождают в следующих версиях. А будут они это делать через ::realloc или еще как - это их дело.

Не уверен, что это баг. Это фича, причем не Qt, а стратегии распределения памяти конкретной операционной системы.
В любом случае для выделения/перераспределения памяти будут использованы malloc и realloc, а их разработчики Qt переделать уже не смогут. (Кроме случае, если программа при старте будут откушивать всю памяти и потом сама ее распределять. Что будет совсем не гуд).

Проще не захватывать непрерывные куски памяти такого размера.

[Igors]

Проще не захватывать непрерывные куски памяти такого размера.

Это точно, но тогда надо признать: проще не использовать QVector для больших данных, т.к. QVector внутри и есть непрерывный кусок. Контейнер который бы распределял память порциями (вместо одного большого куска) был бы ОЧЕНЬ нужен/полезен. Но я такого не нашел.

[BRE]

Контейнер который бы распределял память порциями (вместо одного большого куска) был бы ОЧЕНЬ нужен/полезен. Но я такого не нашел.

QList, QMap, QHash.
А этим еще и свой аллокатор можно назначить (для повышения эффективности): std::vector, std::list, std::map, std::deque, ...

[SABROG]

Для эксперимента хотел попробовать провернуть тоже самое на std::list. Метод max_size() сказал, что я могу поместить в контейнер 357913941 итем типа int. Реально же я попытался выделить память под 100*1024*1024 итемов. В теории это не должно было занять больше 400Мб. На деле программа почему-то кушает до 1,6Гб после чего падает. А после этого компьютер начинает очень дико тормозить на любых операциях, даже если все программы позакрывать и открыть заново. Пришлось перезагружаться, на этом мои эксперименты закончились.

[BRE]

Реально же я попытался выделить память под 100*1024*1024 итемов. В теории это не должно было занять больше 400Мб.

Должно было занять больше.
std::list это список и по мимо рабочих данных (int value), в элементе для адресации списка нужен как минимум указатель на следующий элемент списка.

[Winstrol]

std::list это список и по мимо рабочих данных (int value), в элементе для адресации списка нужен как минимум указатель на следующий элемент списка.

Как и на предыдущий.

[Igors]

Контейнер который бы распределял память порциями (вместо одного большого куска) был бы ОЧЕНЬ нужен/полезен. Но я такого не нашел.

QList, QMap, QHash.
А этим еще и свой аллокатор можно назначить (для повышения эффективности): std::vector, std::list, std::map, std::deque, ...

Есть большие объемы данных, они встречаются редко (обычно 1-2 раза в задаче) но они есть. Это как правило тупенькие структурки (не бывает "много" да еще и "сложно"). Весь этот интеллект QMap, QHash мне для них совсем не нужен, мне их надо просто хранить и добавлять в хвост новые, упаковывать (лучше самому, без erase) . Иногда сортировать.

Остается QVector (обсудили) и QList - этот немного лучше. Но он бросается сразу делать new (если sizeof(T) > sizeof(void *), иначе тот же QVector) для каждого нового элемента    А это не очень подходит, да и памяти отъест.

Вот и получается - проще самопальный контейнер писать  

[BRE]

Вот и получается - проще самопальный контейнер писать 

А stl-ные контейнеры?
Быстрее и эффективней Qt-ишных. Почему не использовать их?

[SABROG]

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

С удовольствием почитал бы, почему Qtшные контейнеры хуже STL'ных. Кстати чьей реализации? Они по-разному работают с памятью.

Я не знаю, является ли QList аналогом std::list, но я четко вижу, что QList кушает как и положено не больше 500Мб при попытке поместить в контейнер ~100млн. int'ов, в то время как std::list'у при аналогичном коде не хватает 1,6Гб съеденной оперативы после чего программа падает, даже не ругнувшись в отладчик о нехватке памяти.

[BRE]

С удовольствием почитал бы, почему Qtшные контейнеры хуже STL'ных. Кстати чьей реализации? Они по-разному работают с памятью.

Не знаю где про это можно почитать, это мое мнение после тестовых прогонов.
Про QStack и std::stack разговор на crossplatform помнишь? На моей машине QStack из-за того что он реализован на базе QVector, проигрывает std::stack (сделанного на базе deque) точно не помню но примерно в 12 раз.
Недавнии тесты QMap и std::map уверенно показывают, что QMap проигрывает в скорости.
Зачем искать, что почитать - проверь сам?

Я не знаю, является ли QList аналогом std::list, но я четко вижу, что QList кушает как и положено не больше 500Мб при попытке поместить в контейнер ~100млн. int'ов,

Ты уверен?
Сегодня завтра посмотрю, но пока для меня это выглядит фантастикой. 

[BRE]

Посмотрел.

Сравнивались QList и std::deque.
В список вставлялись 100 * 1024 * 1024 элементов int.

Process 1 (QList)
Time elapsed: 3207 ms
Process 2 (std::deque)
Time elapsed: 2674 ms

QList не является связанным списком, это массив указателей на T, т.е. его прямой аналог std::vector<T*>.