Большие данные и подкачка

[Igors]

Добрый день

Сцена имеет N объектов, каждый из которых по меньшей мере имеет Position (3 double) и Rotation (3 double). Однако "3 double" - это всего лишь "текущее значение", параметры хранятся в виде "анимационных кривых" (animation curves). Когда юзверь двигает "ползунок" на линейке времени, текущие значения Position и Rotation вычисляются из кривых, в рез-те объект двигается и/или вращается. Анимационные кривые - в принципе обычные контейнеры, данные хранятся в виде контрольных точек сплайна и/или тупо по кадрам (номер кадра + значение).

И вот вчера юзер (с гордостью) создал 102K объектов, и подозреваю, это далеко не предел. Правда они не анимированы, но и пустые кривые (с одной точкой сплайна) - уже 100Mb. Робкие попытки анимации 20 sec (с гораздо меньшим числом объектов) - уже 2-3Gb  (дальше просто боюсь смотреть). Вылетов нет (64-bit да и 8Gb стоит, просто "хватает"), но машина уже "убита", плохо реагирует на мышь и клаву.

Очевидно нужно как-то подкачивать данные с диска. Какую схему подкачки Вы можете предложить?

Спасибо

[qtkoder777]

Какие же они большие. Большие данные сегодня начинаются с 10^15 байт

[alex312]

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

Пы.Сы. Еще можно поиграться со сторонними аллокаторами типа jemalloc , mimalloc.

[Igors]

Если прога тормозит из-за памяти - то тут надо оптимизировать прогу по потреблению памяти, либо по количеству аллокаций и перемещений. Но никак не подкачкой.

Пример: память забита такими структурами

Код

C++ (Qt)
std::vector<std::pair<int, double>> 

Ну или second = 3 double. И что я тут "оптимизирую"? Ну разумно попытаться отсечь неиспользуемый хвост/пул вектора, но это даже не вдвое. И даже не в полтора раза. Чисто технически рез-т может быть вполне достойный. Но для юзания разница примерно "с какого этажа падать - 8-го или 9-го", итог тот же.

Поэтому если принципиально, то никаких др ходов кроме подкачки нет.

[alex312]

Значит надо копать в сторону https://en.wikipedia.org/wiki/Memory-mapped_file

[Igors]

Значит надо копать в сторону https://en.wikipedia.org/wiki/Memory-mapped_file

Так эти вещи "ортогональны" (это красивое словечко употреблял местный знаток языка). У меня есть достаточно простые (или даже примитивные) контейнеры, их (слишком) много. Пусть я создал отмапленый файл (самый распрекрасный, супер-быстрый), и.. что мне с него? Что я в него запишу? Как я сокращу (сократю?) число контейнеров забивающих память?

[Авварон]

Опять же - что показывает профайлер?

[Igors]

Опять же - что показывает профайлер?

То что и должен - память забита animation curves (контейнеры о которых писал выше). Бесполезно выяснять "а сколько" т.к. юзер всегда может создать в 10 раз больше. Или в 100. Ему достаточно ввести число. Др словами проблема в том что расход памяти стал совершенно неконтролируемым (со всеми вытекающими).

[Авварон]

Неясно. Подозреваю что у вас проблема в реалоокациях которым надо копировать вектор. std::deque пробовали? Она хранит данные чанками и добавление не вызывает реаллокаций миллионов элементов.

[RedDog]

а если animation curves в какую нибудь БД скинуть, и читать оттуда только актуальные данные?

[Igors]

Неясно. Подозреваю что у вас проблема в реалоокациях которым надо копировать вектор. std::deque пробовали? Она хранит данные чанками и добавление не вызывает реаллокаций миллионов элементов.

Дека - хорошая вещь, но она здесь ни при чем. И оптимизация переаллокаций тоже не имеет отношения к теме. Проблема в том что (просто-напросто) данных слишком много   Да, это звучит странно - а вчера что, было мало? Ну в общем да. Обычно сцена заряжается данными из файла(ов), напр obj. fbx и др. А их надо откуда-то взять, прочитать. Просто так, руками, 100K объектов не создать. Но тут появилась новая фича типа "размножить по образцу" которая позволяет юзверю легким движением руки размножить N копий. Каждая такая копия конечно юзает оригинал, но какие-то свои данные (ну хотя бы Position и Rotation) у нее есть. Вот их-то и стало безумно много.

А вообще задача очень неплохая. Речь не идет о "памяти вообще", а только о достаточно конкретных и достаточно простых контейнерах, это реально

[Авварон]

Что значит "много"? Доступ к элементам вектора не зависит от количества данных - он делается за константу. Если вы не делаете доступ, а что-то другое, говорите, что конкретно тормозит. "количество" данных в векторе тормозить не может. Может тормозить вставка, поиск, сортировка.

[alex312]

Что значит "много"? Доступ к элементам вектора не зависит от количества данных - он делается за константу.

Тут ты не прав. Потому как если данные в твоем векторе засвопились, то доступ к ним не будет таким же быстрым, как если бы он был в оперативе, или более того в каком нибудь из кешей проца.

[alex312]

Так эти вещи "ортогональны" (это красивое словечко употреблял местный знаток языка). У меня есть достаточно простые (или даже примитивные) контейнеры, их (слишком) много. Пусть я создал отмапленый файл (самый распрекрасный, супер-быстрый), и.. что мне с него? Что я в него запишу? Как я сокращу (сократю?) число контейнеров забивающих память?

после того как отмапите себе 100GB файл, пишите свой аллокатор. Все стандартные контейнеры могут работать с кастомными аллокаторами.

[Igors]

конкретно тормозит. "количество" данных в векторе тормозить не может.

Про тормоза/скорость в данной теме речь не идет. Вопрос как (принципиально) ограничить неконтролируемое потребление памяти.

после того как отмапите себе 100GB файл, пишите свой аллокатор. Все стандартные контейнеры могут работать с кастомными аллокаторами.

Не понимаю каким боком тут аллокатор. К оператору [] он отношения не имеет, а подгружать контейнер целиком нет смысла, напр на кадре 100 будет обращение ко всем контейнерам по индексу 100, т.е. загрузим/перемелем все. Итог - свап в минус