Russian Qt Forum
Ноябрь 21, 2024, 22:24 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1] 2 3   Вниз
  Печать  
Автор Тема: Большие данные и подкачка  (Прочитано 15036 раз)
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« : Октябрь 07, 2020, 10:22 »

Добрый день

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

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

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

Спасибо
Записан
qtkoder777
Частый гость
***
Offline Offline

Сообщений: 245


Просмотр профиля
« Ответ #1 : Октябрь 07, 2020, 14:43 »

Какие же они большие. Большие данные сегодня начинаются с 10^15 байт
Записан
alex312
Хакер
*****
Offline Offline

Сообщений: 606



Просмотр профиля
« Ответ #2 : Октябрь 07, 2020, 15:28 »

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

Пы.Сы. Еще можно поиграться со сторонними аллокаторами типа jemalloc , mimalloc.
« Последнее редактирование: Октябрь 07, 2020, 16:18 от alex312 » Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #3 : Октябрь 08, 2020, 11:04 »

Если прога тормозит из-за памяти - то тут надо оптимизировать прогу по потреблению памяти, либо по количеству аллокаций и перемещений. Но никак не подкачкой.
Пример: память забита такими структурами
Код
C++ (Qt)
std::vector<std::pair<int, double>>
Ну или second = 3 double. И что я тут "оптимизирую"? Ну разумно попытаться отсечь неиспользуемый хвост/пул вектора, но это даже не вдвое. И даже не в полтора раза. Чисто технически рез-т может быть вполне достойный. Но для юзания разница примерно "с какого этажа падать - 8-го или 9-го", итог тот же.

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

Сообщений: 606



Просмотр профиля
« Ответ #4 : Октябрь 09, 2020, 12:16 »

Значит надо копать в сторону https://en.wikipedia.org/wiki/Memory-mapped_file
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #5 : Октябрь 09, 2020, 14:29 »

Значит надо копать в сторону https://en.wikipedia.org/wiki/Memory-mapped_file
Так эти вещи "ортогональны" (это красивое словечко употреблял местный знаток языка). У меня есть достаточно простые (или даже примитивные) контейнеры, их (слишком) много. Пусть я создал отмапленый файл (самый распрекрасный, супер-быстрый), и.. что мне с него? Что я в него запишу? Как я сокращу (сократю?) число контейнеров забивающих память?
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3260


Просмотр профиля
« Ответ #6 : Октябрь 09, 2020, 14:31 »

Опять же - что показывает профайлер?
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #7 : Октябрь 09, 2020, 15:33 »

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

Сообщений: 3260


Просмотр профиля
« Ответ #8 : Октябрь 09, 2020, 15:54 »

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

Сообщений: 221


Просмотр профиля
« Ответ #9 : Октябрь 09, 2020, 16:47 »

а если animation curves в какую нибудь БД скинуть, и читать оттуда только актуальные данные?
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #10 : Октябрь 09, 2020, 16:54 »

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

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

Сообщений: 3260


Просмотр профиля
« Ответ #11 : Октябрь 09, 2020, 18:03 »

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

Сообщений: 606



Просмотр профиля
« Ответ #12 : Октябрь 09, 2020, 22:56 »

Что значит "много"? Доступ к элементам вектора не зависит от количества данных - он делается за константу.
Тут ты не прав. Потому как если данные в твоем векторе засвопились, то доступ к ним не будет таким же быстрым, как если бы он был в оперативе, или более того в каком нибудь из кешей проца.
Записан
alex312
Хакер
*****
Offline Offline

Сообщений: 606



Просмотр профиля
« Ответ #13 : Октябрь 09, 2020, 23:04 »

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

Сообщений: 11445


Просмотр профиля
« Ответ #14 : Октябрь 10, 2020, 09:50 »

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

после того как отмапите себе 100GB файл, пишите свой аллокатор. Все стандартные контейнеры могут работать с кастомными аллокаторами.
Не понимаю каким боком тут аллокатор. К оператору [] он отношения не имеет, а подгружать контейнер целиком нет смысла, напр на кадре 100 будет обращение ко всем контейнерам по индексу 100, т.е. загрузим/перемелем все. Итог - свап в минус
Записан
Страниц: [1] 2 3   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.13 секунд. Запросов: 22.