дичь какая-то

Минимальная дефрагментация это чтобы всё было максимально плохо, тебе qt уже мало для этого?

#define менеджер памяти.

Минимальная дефрагментация это сильно.

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

Я не понимаю, то ли я непонятно задал вопрос

Ты спросил какую-то дичь. Возможно, ты хотел сказать «фрагментация» вместо «дефрагментация», но даже в этом случае получается дичь.

Непонятно задал вопрос.

Пятница в воскресенье? Выдыхай, бобёр, выдыхай.

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

зачем над чем-то еще, когда есть это?

Ты спросил какую-то дичь. Возможно, ты хотел сказать «фрагментация» вместо «дефрагментация», но даже в этом случае получается дичь.

Допускаю, что слово фрагментация я могу неправильно использовать. Но на счет фразы «менеджер памяти», вот ссылка на википедию, что это такое: https://ru.wikipedia.org/wiki/Менеджер_памяти И дальше, я делаю программу, в которой заметил, что очередным препятствием повышения производительности это дефрагментированная память. Вместо встроенного переделал на свой простенький, и там такая же картина.

Возьмите для примера сделайте программку, которая сначала выделит несколько гигов памяти блоками по килобайт (и забивайте ее скажем -1), а потом распустит. По «системному монитору» можно увидеть, что где то половина от распущенной памяти осталась за программой. Но это не беда, если дальнейшие выделения будут блоками такого же размера. А если они разные и их каждый раз много, то неиспользуемая но зарезервированная память будет расти, пока не наступит полный конец.

у меня в программе наибольшие затраты идут на дисковые операции

ну так и оптимизируй дисковые операции, че ты полез (походу) свой аллокатор писать?

в том числе кэша операционки

определи, плз, еще и это понятие

Но на счет фразы «менеджер памяти», вот ссылка на википедию, что это такое: https://ru.wikipedia.org/wiki/Менеджер_памяти

Ты скорее говоришь об аллокаторе.

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

Все современные аллокаторы сопротивляются фрагментации, но любой из них можно вогнать в нее. Смотри на паттерны выделения памяти в своей программе. Заменить аллокатор можно, но нет гарантий, что это поможет.

паттерны выделения памяти

нет у меня «паттернов» (предполагаю что подразумевается «закономерностей») выделения памяти. Программа по сбору мат статистики, нужен доступ до случайных данных, и все данные в памяти не помещаются. Решение есть свое, но не идеальное. Хочу посмотреть как это решают другие.

нет у меня «паттернов» (предполагаю что подразумевается «закономерностей») выделения памяти.

Если их нет - значит, тебе невозможно помочь.

Хочу посмотреть как это решают другие.

Делают mmap и не заморачиваются.

дефрагментация - это вообще как связано с менеджером памяти?
или ты про операции realloc?

возможно ты не понимаешь что такое RAM https://en.wikipedia.org/wiki/RAM это буквально Random-access memory

в такой памяти абсолютно не важна фрагментация, у тебя любой участок памяти доступен одинаково быстро

извращения на уровне ассемблера чтоб писать линейно с адреса по адрес будут работать только «без ОС»...и это бред какойто

бредовая тема на самом деле

тред не читал

Для интро

https://www.quora.com/In-memory-management-while-using-the-best-fit-first-fit...

Wrong :)

У тебя в любом случае есть некоторые шаблоны выделения (просто ты о них не знаешь). Не бывает абсолютно uniform распределения в реальной жизни.

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

prove it

Паттерны есть в любой программе кроме искусственных примеров с вызовами malloc(rand()). Изучай задачу лучше.

Любая игровая сонсоль система с фиксированным объёмом памяти, которого совсем не хватает.

Я понимаю, что ты сейчас сидишь в кресле перед камином, куришь сигару, потягиваешь виски. Посмеиваешься над нами, не понимающими в разработке под консоли ровным счётом ничего. Не планируешь говорить ничего конкретного, просто бросаешь отрывистые замечания «Wrong :)»

Продолжай в том же духе. :)

Ну а как я тебе докажу что на «памяти то не завезли» люди не «делают mmap и не заморачиваются»? Я знаю 2 игровых проекта у которых свои аллокаторы: оба используют SmallBlockAllocator, у одного BestFit для медиум блока и страничный аллокатор на 500+кб.

Ну а как я тебе докажу что на «памяти то не завезли» люди не «делают mmap и не заморачиваются»?

А откуда в разговоре вообще появились «памяти не завезли » и консоли? В хедпосте - обычная убунта, дальше - «сбор мат. статистики» (ХЗ что это, но явно не игра на консоли).

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

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

не заработает на виндавсе

CreateFileMapping+MapViewOfFile

у тебя любой участок памяти доступен одинаково быстро

Хрен там. Кеши и readahead сильно уменьшают время доступа если в данные ходить линейно.

В оперативной памяти есть readahead?

Это уже отдельный код.

В процессорах есть prefetch.

prefetch явно делается программистом.

Hardware prefetch делается самим процессором.

Это уже отдельный код.

Достаточно сделать обёртку, в которой спрятать платформо-зависимый код. Или воспользоваться готовой обёрткой, например, из Boost.

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

Возможно я что-то путаю с префетчем или подгрузкой из флеша в некоторых МК.

возможно ты не понимаешь что такое RAM https://en.wikipedia.org/wiki/RAM это буквально Random-access memory

К фрагментации памяти ведет постоянное ее выделение и высвобождение кусками разными размерами, и в результате на 10Гб выделенной памяти система затрачивает 11Гб или больше. В моем случае система/Qt почему-то 10Гб полезной памяти зафрагментировала на 20Гб за несколько часов работы программы, а дальше закончилась оперативка и все стало бесконечно долго. Заменив вызовы на свой самопальный простенький «аллокатор» я решил эту проблему, и сверх выделения у меня сейчас расходуется не более 10% оперативки как фрагментированные. Суть что в нем я использую разные пулы под разные размеры выделения и плюс немного для хранения инфы о выделенном куске памяти. Предполагаю, что это в Qt «аллокатор» такой кривой, а не системы Ubuntu.

По-моему это тупо мемори лик. Или там по странице на каждые полтора байта аллокаций?

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

Overcommit?

в Qt «аллокатор» такой кривой

В Qt нет своего аллокатора.

С чего бы?

Что-то отсюда наверно :

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-...

Это вообще другое.

По-моему это тупо мемори лик.

Тогда бы эта проблема осталась бы при замене на свой аллокатор. У меня все четко, столько то объектов выделено, столько то распущено, суммарный объем посчитан.

В Qt нет своего аллокатора.

Согласен, эта проблема malloc от gcc. Это выделение не от системы, т.к. система выделяет блоками кратными степени двойки, (это предположение, которое можно увидеть из выполнения команды sudo slabtop)

slabtop

Это данные по внутриядерному аллокатору. К пользовательским программам он как-то побоку. Там sbrk и mmap.

что я прочитал, мои глаза

как 10гб могут превраться в 20гб

в оперативной памяти нет файловой системы, если простейшие адреса(пусть даже которые зеркалятся ОС это пол магабайта потребляет)

у тебя банальная утечка памяти, ни QT ни убунта ни оперативная памяти тут не причем

ты вбил себе в голову полный бред и сам себя в нем убеждаешь

то что ты описал «как думаешь» такое физически невозможно

Не «адреса», а страницы по 4килобайта или больше.

Исхожу из того, что у тебя выполняется статистическая обработка большого массива данных. Сколько исходных данных (в процентах) от объема оперативки на рабочей станции? Сколько результирующих данных? И для полноты, сколько памяти требуется алгоритмам для обработки (тут стоит указать какую-нибудь оценку сверху на основе N некоторого количества входных данных)?

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

Нужно больше подробностей.

PS «дефрагментация» == «де-фрагментация» == «избавление от фрагментации» == «избавление от негативного явления, вызыванного дроблением памяти на мелкие участки, приводящего к затруднению при выделение больших непрерывных областей памяти» (в случае RAM)

дичь какая-то

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