2014-02-13 4 views
0

Так что мне нужно иметь массив Terrain (земля), который содержит 2xx небольшую местность (земля). Каждый небольшой ландшафт (земля) содержит 1 000 000 точек плавания.Лучший способ запасать 2xx миллионов точек

Так я думал о чем-то вроде

QVector<QVector<float> > terrain; 
QVector<float> littleTerrain; 

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

Поэтому, конечно, я думал о

QVector<float*> 

но необходимо удалить все указатели в векторе

Таким образом, с помощью смарт-указатель можно здесь? В противном случае, что лучший выбор?

+1

Что такое 2xx? Я не знаком с обозначением – fritzone

+1

«Но в данный момент есть проблема со всеми выделениями, которые я могу сделать». Это значит, что именно? @fritzone: Между 200 и 300 миллионами – deviantfan

+0

вы имеете в виду 'QVector *>'? –

ответ

0

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

0

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

В 32-битных архитектурах вам не хватает адресного пространства, чтобы все это было в простой структуре данных.

Итак, вам нужно сделать схему кэширования, где только подмножество этих данных постоянно находится в структуре данных в памяти. Чтобы оптимизировать поведение кэширования на всех уровнях (L1, L2, L3, пейджинг), вам необходимо - и это важно - хранить пространственно соседние данные в соседних адресах памяти.

Одним из способов сделать это будет то, чтобы вся местность была разделена на квадраты размером 32x32. Обратите внимание: 32*32*sizeof(float) == 4096 - это небольшой размер страницы на большинстве систем. Этот квадрат следует дополнительно подразделить на квадраты 4x4. Обратите внимание, что 4*4*sizeof(float) == 64 и размер строки кеша на многих системах.

+0

Не знаете о вашем компьютере, но 200 списков векторов имеют накладные расходы, измеренные в килобайтах. Нет проблем вообще, даже не в 16 бит. Отдельные векторы занимают по 4 МБ каждый, что достаточно мало, чтобы не справляться с серьезными проблемами фрагментации даже на 32-битных системах. – MSalters

+0

@MSalters 300 * 1 млн. * 4 = 1,2 ГБ, из 2 ГБ доступно под 32-битной Windows. Путь слишком близок к практичности, особенно с потенциалом роста. Даже если это виртуальное адресное пространство доступно, возможно, он не будет доступен в кусках 4 МБ. Речь идет не о фрагментации, а о локальности доступа. Доступ к вертикальной полосе 1000x1 в одном из этих блоков 4 МБ требует разбиения на страницы всего фрагмента, чтобы получить доступ к данным на 4 Кбайта, а также потратит до 1000 строк кеша - орехи. –

0

Накладные расходы будут пропорциональны количеству контейнеров, которые у вас есть, - несколько сотен контейнеров, всего несколько килобайт. Другими словами, ничего.

Главное, что нужно сделать, это зарезервировать достаточную память для количества точек на «малое количество». В противном случае Qt будет следить за тем, чтобы он соответствовал, но, вероятно, накладывается на 50% или около того.

Смежные вопросы