Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Слишком большой массив

41K
19 мая 2013 года
dreamlore
23 / / 19.05.2013
столкнулся с такой проблемой. Для обработки объектов в opengl мне в память нужно загрузить определённое количество объектов с числом точек, приблизительно 2000, которые имеют координаты (x,y,z,v,u), итого 2000*5=10000. пошёл я простым способом, запихнул их в массив одной переменной:

 
Код:
double object_a[10000];
объект отобразился корректно. дошло дело до анимации, где цикл её составил 5 кадров, переменная приобрела уже такой вид

 
Код:
double object_a[5][10000];
тут оказалось тоже всё в порядке, но нужно загрузить более одного объекта, в итоге всех изменений, переменная приобрела окончательный вид

 
Код:
double object_a[100][10][20][5][10000];
конечно, для одной переменной это очень большой массив, выходит, что 100*10*20*5*10000 будет равен массиву [100000][10000] или [1000000000].
решил проблему, задавая каждому объекту с анимацией свою переменную

 
Код:
double object_a[5][10000];
double object_b[5][10000];
всё работало, но объявив больше переменных, компилятор выдал ту же ошибку, о переполнении массива. в итоге я заметил, что если сложись массивы всех переменных и их сумма будет меньше 1000000, то всё компилируется нормально, если же больше выдаёт ошибку. пробовал объявлять переменные динамически

 
Код:
int *object_a = new int[300000000];
тут массив побольше, но всё-равно при попытке создать ещё одну переменную с таким же массивом, прога выдаёт ошибку.

пробовал структуры

 
Код:
struct strct_a
{
double U[2000];
double V[2000];
double X[2000];
double Y[2000];
double Z[2000];
} *object_a[100000];

object_a[1]->U[10]=10.200;
исход один, либо компилятор выдаёт ошибку, либо само приложение, если компиляция была успешна. пробую метод std::vector, но так как мои знания языка не достаточны, мои потуги дают плохой результат, vector<double> *object_a=new vector<double> [300000000] выдаёт тот же результат, что и обычное динамическое объявление переменной.
326
19 мая 2013 года
sadovoya
757 / / 19.11.2005
Непомерные аппетиты у вашей программы :) 300 млн. int = 1,2Гбайта. С double в два раза больше (на большинстве платформ int занимает 4 байта, double - 8).В стеке (статический массив) -- не реально. Динамический (в куче) -- зависит от свободной памяти компа. Надо что-то менять в программе :) Или типе данных, т.е. взять покороче. Правда, эти "короткие" возможно быдут расширены при обработке...
1
19 мая 2013 года
kot_
7.3K / / 20.01.2000
Цитата: sadovoya
Надо что-то менять в программе :)


+100
Если возникает необходимость в подобных массивах - надо пересматривать алгоритм

41K
20 мая 2013 года
dreamlore
23 / / 19.05.2013
Цитата: sadovoya
Непомерные аппетиты у вашей программы :) 300 млн. int = 1,2Гбайта. С double в два раза больше (на большинстве платформ int занимает 4 байта, double - 8).В стеке (статический массив) -- не реально. Динамический (в куче) -- зависит от свободной памяти компа. Надо что-то менять в программе :) Или типе данных, т.е. взять покороче. Правда, эти "короткие" возможно быдут расширены при обработке...



ну да))) при выделении памяти через вектор, 130 лямов плюс программочка забивают 1 гиг оперативки, о размерах переменных я знал, но не догадывался что такими капельками можно так сильно заполнить океан оперативы.
во временный бинарный файл на диске тоже не запихнёшь (загружать с жёсткого диска несколько миллионов кординат, 30 раз в секунду глупо даже для меня), может, как-то стринги в этом случае можно использовать...

1
20 мая 2013 года
kot_
7.3K / / 20.01.2000
Цитата: dreamlore
Цитата: sadovoya
Непомерные аппетиты у вашей программы :) 300 млн. int = 1,2Гбайта. С double в два раза больше (на большинстве платформ int занимает 4 байта, double - 8).В стеке (статический массив) -- не реально. Динамический (в куче) -- зависит от свободной памяти компа. Надо что-то менять в программе :) Или типе данных, т.е. взять покороче. Правда, эти "короткие" возможно быдут расширены при обработке...



ну да))) при выделении памяти через вектор, 130 лямов плюс программочка забивают 1 гиг оперативки, о размерах переменных я знал, но не догадывался что такими капельками можно так сильно заполнить океан оперативы.
во временный бинарный файл на диске тоже не запихнёшь (загружать с жёсткого диска несколько миллионов кординат, 30 раз в секунду глупо даже для меня), может, как-то стринги в этом случае можно использовать...


не надо. надо всего навсего ознакомиться с тем, как это делают другие. Если своей думалки не хватает

414
20 мая 2013 года
CassandraDied
763 / / 24.05.2012
Цитата: kot_
Цитата: sadovoya
Надо что-то менять в программе :)


+100
Если возникает необходимость в подобных массивах - надо пересматривать алгоритм


Это ты так пошутил?

326
20 мая 2013 года
sadovoya
757 / / 19.11.2005
Если сильно хочется решить "в лоб" без переделки алгоритма, то попробуйте (unsigned) short int: 65 тыс. градаций координат -- достаточная точность. А памяти всего 2 байта на хранение. Приведение к типу, "потребляемому" ф-циями (хоть к double) пусть занимается проц., времени ему хватит :)
1
20 мая 2013 года
kot_
7.3K / / 20.01.2000
Цитата: CassandraDied
Цитата: kot_
Цитата: sadovoya
Надо что-то менять в программе :)


+100
Если возникает необходимость в подобных массивах - надо пересматривать алгоритм


Это ты так пошутил?


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

414
20 мая 2013 года
CassandraDied
763 / / 24.05.2012
Не могу. Ты ничего не писал об игре в посте. Я подумал, что ты вообще все программы имеешь в виду.
А вообще, если ты спрашиваешь про картографический софт, где могут потребоваться такие объёмы памяти, то могу подсказать одну софтинку. Но там большие объёмы были необходимы только в момент кое-каких расчётов, которые потом закешировались и обновляются очень-очень-очень редко.
1
21 мая 2013 года
kot_
7.3K / / 20.01.2000
Цитата: CassandraDied
Не могу. Ты ничего не писал об игре в посте. Я подумал, что ты вообще все программы имеешь в виду.
А вообще, если ты спрашиваешь про картографический софт, где могут потребоваться такие объёмы памяти, то могу подсказать одну софтинку. Но там большие объёмы были необходимы только в момент кое-каких расчётов, которые потом закешировались и обновляются очень-очень-очень редко.


и что - там это решалось выделением массивов на миллион объектов? Что-то сомневаюсь.

414
21 мая 2013 года
CassandraDied
763 / / 24.05.2012
Там решалось не "это". Опять же, в своём посте ты не уточнял, что имеешь в виду конкретную задачу топикстартера. Приложений, с задачами ТС, я действительно не знаю, чтобы кто-то использовал в них такие огромные массивы. А в прошлом посте имел в виду "карту интернета", если слышал о такой. Она в облаке недельку считалась. Вот там граф был объёмный — ужас просто. И, думаю, алгоритм не позволил бы загружать и выгружать части графа, а требовал всё и сразу в памяти.
1
21 мая 2013 года
kot_
7.3K / / 20.01.2000
Цитата: CassandraDied
Там решалось не "это". Опять же, в своём посте ты не уточнял, что имеешь в виду конкретную задачу топикстартера. Приложений, с задачами ТС, я действительно не знаю, чтобы кто-то использовал в них такие огромные массивы. А в прошлом посте имел в виду "карту интернета", если слышал о такой. Она в облаке недельку считалась. Вот там граф был объёмный — ужас просто. И, думаю, алгоритм не позволил бы загружать и выгружать части графа, а требовал всё и сразу в памяти.


ну я вообщето не имею ввиду задачу ТС.
Любой граф - он зависит от задачи и цели - тут показатель не то, сколько считалась. И тем более это не показатель размера массива. Хотя да - некоторые задачи картторгфии требуют немалых массивов. Но в целом, это суют на отдельные машины - которые дают готовый результат.

414
21 мая 2013 года
CassandraDied
763 / / 24.05.2012
Конкретно в той задаче было необходимо посчитать количество переходов от каждого сайта к каждому сайту.
Цитата:
После нормализации мы получаем взвешенный ненаправленный граф с 350 тысячами вершин и более 2 млн. ребер.


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


Я точно не знаю, насколько был оптимизирован алгоритм, но предположил, что загрузка памяти, даже если и была оптимизирована в 122 раза, всё равно составит 1 млрд. записей, что очень много. И всё это добро было посчитано с использованием .NET. *_*

41K
22 мая 2013 года
dreamlore
23 / / 19.05.2013
короче ничего с этим не сделаешь, с таким количеством объектов, выводимых одновременно на экран даже игровые движки бессильны (если это только не война клонов, которая встречается в 90% всех игр) остаётся только урезать зону видимости до минимума и загружать только те объекты, которые должны быть видны в этой зоне и в зоне допусков(тоторые мы, предположительно увидим следующими)
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог