Методы оптимизации памяти

[FiloXSee]

Написал статью по оптимизации памяти в программах на С++. Ее можно почитать тут:
http://itw66.ru/blog/c_plus_plus/491.html

А какие методы вы можете предложить по повышению эффективности программы, при помощи организации данных в памяти определенным образом?

[Пепел Феникса]

В третьих есть риски утечек памяти.

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

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

и что с того что они лежат не рядом?
почему медленнее, то? где обьяснения причин?(если что я знаю почему)

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

непрерывность требование массива, а если список, то там особо разницы нет(кроме жирного пункта)

Но эта проверка занимает 23-24 (указаны для процессора Cell, PS3) цикла процессора

простая проверка флага занимает 24 такта?
не знал что банальный test dword[ecx+<смещение>],0
будет так долго выполнятся...

При проходе по такой коллекции для получения каждого нового элемента будет обращение к памяти.

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

Одна только эта реорганизация

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

Работайте не с объектами а с коллекциями объектов

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

Поблочное выделение памяти

вот тут согласен(кроме использования пункта три)

[FiloXSee]

Сообщение от Пепел Феникса

непрерывность требование массива, а если список, то там особо разницы нет(кроме пункта выше в котором нет причин)

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

Сообщение от Пепел Феникса

простая проверка флага занимает 24 такта?

Проверка флага - это не долго. Долго перестраивать конвейер процессора, в случае ошибки бранч предикшена (который на PS3 и так слабый).

Сообщение от Пепел Феникса

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

Я же написал "для получения объекта", а не для его создания. Т.е. идем по массиву указателей на объекты. Чтобы проверить поле каждого объекта нужно разыменовать указатель и получить объект из памяти. Кашмис будет стопроцентный, т.к. объекты идут не подряд в памяти. Это значит, что для получения каждого объекта будет обращение к оперативной памяти, а это уже 600 тактов процессора. И так для каждого объекта.

[FiloXSee]

Сообщение от Пепел Феникса

ну да, теперь надо вечно разименовывать указатели

Разыменование указателя - это получение данных из памяти по указателю:
Обращение к L1 - 20 тактов.
Обращение к L2 - 100 тактов.
Обращение к общей памяти - 600 тактов.
Это значит, что разыменовывать указатель очень дешево, если все данные в памяти процессора и намного выгоднее чем кэшмис.

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

[Пепел Феникса]

Массивы объектов - это чаще всего массивы указатели на классы.

массивы объектов, и массивы указателей на объекты это разное, массив объектов это массив объектов.
std::vector<class> и std::vector<class*> совсем разные вещи, но говорите вы про первое

Долго перестраивать конвейер процессора, в случае ошибки бранч предикшена (который на PS3 и так слабый).

тут пожалуй да, но есть одно НО, тут надо смотреть на длительность той самой процедуры восстановления объекта, ибо если она долгая и редко нужна, то лучше проверять всетаки.

Т.е. идем по массиву указателей на объекты.

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

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

один хрен нам работать с данными по указателю, так что на данный момент не вижу смысла(итог тот же кэшмис)
да и не думаю что проц будет ради работы с полем класса, грузить в кэш весь объект

[FiloXSee]

Сообщение от Пепел Феникса

да и работать с таким не очень уютно)

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

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

[Пепел Феникса]

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

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

[FiloXSee]

Сообщение от Пепел Феникса

тут нужно верно проектировать, если нам чаще нужен весь объект а не отдельное поле, то лучше группировать данные, если же чаще нужно какое то отдельное поле, то лучше будет если оно будет отдельно.

Согласен. Это все более справедливо для систем с большим количество данных чем для иерархий логических объектов. Хотя и для них пункт 3 является актуальным.

[f.hump]

При выполнении какой либо оптимизации, нужно ответить вопрос: для чего эта оптимизация нужна?
Большинство современных компиляторов довольно нелохо справляются с различного рода оптимизациями самостоятельно. Плюс системный менеджер памяти тоже не дураки писали.

Конечно, в общеоразовательных целях можно попробовать разное и посмотреть как оно влияет на производительность.
Вот например Intel для достижения максимальной производительности рекоммендует выранивать блоки памяти как минимумум по 64 байтной границе, еще лучше если и размер самих блоков кратен 64. Последовательное заполнение это конечно позитив, но принимая во внимание, что современные процы могут кешить данные из 8 различных страниц памяти одновременно то позитив от подобного раположения будут испытывать только однопроходные процедуры не использующие одни и те же данные многократно. Плюс общая рекоменданция это не столько последовальное расположение данных сколько регулярное (разрешен ненулевой интервал, не больше 64 байт, между группами данных). Плюс есть операции перещения данных в обход кеша, которые в теории страшно увеличивают производительность. Ну, вобщем есть много различных путей, и не факт, что компилятор делает хуже.

[f.hump]

Обращение к L1 - 20 тактов.
Обращение к L2 - 100 тактов.
Обращение к общей памяти - 600 тактов.

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

Кстати, случайно заметил постоянные референсы на PS3, это что про оптимизацию для PS3?
Потому что я писал про х86 от Intel.