Есть задача обрабатывать некую матрицу. Причем она может быть размера приемлемого для размещения в памяти так и большой (тогда надо ее дампить на диск).
Обычно матрицы создаются как vector<vector<int>> размера N. Вопрос — как определить єто N, чтобы матрицу еще можно было разместить в памяти?
Здравствуйте, Hard_Club, Вы писали:
H_C>(тогда надо ее дампить на диск).
Забудь об этом решении, скорость работы будет такая что программа будет уже никому не нужна. Писал я класс для работы с матрицей с диска, после проверки это решение выкинули. Поэтому смотри в сторону uBLAS, Eigen и т.д.
H_C>Обычно матрицы создаются как vector<vector<int>> размера N. Вопрос — как определить єто N, чтобы матрицу еще можно было разместить в памяти?
Если получилось сделать resize то место есть
Зависит от того какое у тебя приложение, x64 или x32, и есть ли достаточно непрерывной памяти.
Здравствуйте, Hard_Club, Вы писали:
H_C>Есть задача обрабатывать некую матрицу. Причем она может быть размера приемлемого для размещения в памяти так и большой (тогда надо ее дампить на диск).
Насколько большая? Тут многие до тебя говорили про большие размеру, а на поверку оказалось меньше 10 мб. Если матрица в сотни мегабайт смотри как решают эти проблемы в картографии и как обрабатывают аэрофотоснимки. Подход будет тот же. Где-то тут были такие вопросы уже, кстати. H_C>Обычно матрицы создаются как vector<vector<int>> размера N. Вопрос — как определить єто N, чтобы матрицу еще можно было разместить в памяти?
Нет, обычно они создаются на базе vector<int> размера N*M.
H_C>>(тогда надо ее дампить на диск). I>Забудь об этом решении, скорость работы будет такая что программа будет уже никому не нужна. Писал я класс для работы с матрицей с диска, после проверки это решение выкинули.
Ну есть навпример memory_mapped файлы (смотреть boost::interprocess)
I>Поэтому смотри в сторону uBLAS, Eigen и т.д.
Это смотря какая матрица, если разреженная тогда да, а так нет.
H_C>>Обычно матрицы создаются как vector<vector<int>> размера N. Вопрос — как определить єто N, чтобы матрицу еще можно было разместить в памяти? I>Если получилось сделать resize то место есть I>Зависит от того какое у тебя приложение, x64 или x32, и есть ли достаточно непрерывной памяти.
Вовсе не зависит, точнее завист, но до какого то предела, который в зависимости от задачи может быть легко достигнут.
Здравствуйте, Igore, Вы писали:
I>Зависит от того какое у тебя приложение, x64 или x32, и есть ли достаточно непрерывной памяти.
Поскольку там vector<vector<int>>, непрерывной памяти (виртуальной) в большом количестве вовсе не нужно, нужен лишь суммарный объем. Храниться непрерывно будут элементы vector<int>, а сами эти вектора будут лежать как угодно.
В терминах без STL :
int a[N][M] требует непрерывной памяти N*M*sizeof(int)
int* a[N] (или int**a = new int*[N] ) с последующим a[i] = new int [M]
— не требует, нужно лишь, чтобы разместились все строки, на которые показывает a[i], то есть их суммарный объем будет тот же, но лежать эти строки могут как угодно друг относительно друга
Здравствуйте, Hard_Club, Вы писали:
H_C>Есть задача обрабатывать некую матрицу. Причем она может быть размера приемлемого для размещения в памяти так и большой (тогда надо ее дампить на диск).
Можно использовать memory mapped файлы. В этом случае можно иметь матрицу сколь угодно большого размера, периодически маппируя ее куски в адресное пространство. Дампить не придется, так как матрица автоматически записывается в файл, на основе которого сделан мэппинг.
