Очень большие массивы

[aldep]

Возникла проблема: в программе надо использовать массивы размером больше, чем 4GB.
Напрашивающееся решение - создать библиотеку, которая через memory-mapped files будет хранить массив на диске и по мере надобности подмонтировать нужные секции в память.
Нужен совет вот по каким вопросам:
1. Есть ли какие-то подводные камни в этом подходе?
2. Нет ли уже написанной библиотеки?

П.С. Платформа - Win32.

[Woozy]

Это всё связано с ограничением Win32 на память, доступную процессу?

Встречный вопрос - "хранить на диске" значит только во время работы программы или в самом деле "хранить"?

Если только хранить на время работы программы, то какой ожидается размер одного элемента массива?

Есть ещё такое подозрение, подойдёт vector из stl. Надо подкрутить: allocator для этого vector, чтобы мог выделять память из memory-mapped files, то есть за пределами доступной процессу.. Примеров в сети на аллокаторы - много.

[Vovchik]

Возникла проблема: в программе надо использовать массивы размером больше, чем 4GB.
Напрашивающееся решение - создать библиотеку, которая через memory-mapped files будет хранить массив на диске и по мере надобности подмонтировать нужные секции в память.
Нужен совет вот по каким вопросам:
1. Есть ли какие-то подводные камни в этом подходе?
2. Нет ли уже написанной библиотеки?

П.С. Платформа - Win32.

А че б не использовать базу данных и хранить всю эту фигню в таблице?

[aldep]

Это всё связано с ограничением Win32 на память, доступную процессу?

Да.

Встречный вопрос - "хранить на диске" значит только во время работы программы или в самом деле "хранить"?
Если только хранить на время работы программы, то какой ожидается размер одного элемента массива?

Только на время работы.
Размер одного элемента массива обычно double, но может быть и небольшая не больше килобайта строка.

Есть ещё такое подозрение, подойдёт vector из stl. Надо подкрутить: allocator для этого vector, чтобы мог выделять память из memory-mapped files, то есть за пределами доступной процессу.. Примеров в сети на аллокаторы - много.

Вообще идея интересная, спасибо, посмотрю, единственное что смущает - производительность. Динамический массив нам не нужен. Размер данных известен заранее и он не изменяется.

[Woozy]

Вообще идея интересная, спасибо, посмотрю, единственное что смущает - производительность. Динамический массив нам не нужен. Размер данных известен заранее и он не изменяется.

А для vector можно зарезервировать сразу сколько надо элементов и операции по изменению его размера задействованы не будут, до следующего явного изменения размера или при попытке создать больше элементов.

[aldep]

А че б не использовать базу данных и хранить всю эту фигню в таблице?

Хранится как раз все это в базе данных.

Проблема в том, что приходится многократно проходить этот массив и изменять его, создавать новые таблицы, и если все хранить в базе, то производительность, по сравнению к доступу из памяти, падает в ~20 раз. Поэтому мы загружали всю таблицу в память, но ее стало не хватать.

[aldep]

А для vector можно зарезервировать сразу сколько надо элементов и ни операции по изменению его размера задействованы не будут, до следующего явного изменения размера или при попытке создать больше элементов.

Да я знаю, поэтому то идея и интересная, боюсь только доступ к вектору векторов будет медленный (нам нужны именно табличные данные.
Ты не встречал примеры таких аллокаторов?

[Woozy]

Да я знаю, поэтому то идея и интересная, боюсь только доступ к вектору векторов будет медленный (нам нужны именно табличные данные.
Ты не встречал примеры таких аллокаторов?

1. Самое значительное время будет тратиться на операции чтения-записи в-из memory-mapped file. STL-ный overhead будет незначительный, если память заранее выделена.

2. Встречал. Писал, правда вовсе другой allocator. Из интереса покопаю google когда будет лишних 15 мин.

[Vovchik]

А че б не использовать базу данных и хранить всю эту фигню в таблице?

Хранится как раз все это в базе данных.

Проблема в том, что приходится многократно проходить этот массив и изменять его, создавать новые таблицы, и если все хранить в базе, то производительность, по сравнению к доступу из памяти, падает в ~20 раз. Поэтому мы загружали всю таблицу в память, но ее стало не хватать.

Тыда надо таблицу разбить по кускам. Типа - партишн как в Оракле. Ты ж все равно будешь читать писать в файлы. ТО что ты хочешь - это как раз Оракловая партишен таблица, сдается мне.
А ежели Оракл сидит на Шмуниксе, и там типа хорошо покрутить всякие гайки - то приблизительно мона добиться чтоб ваще вся таблица (или куски) торчали в памяти на сервере и свести ввод вывод на диск к минимуму.

[aldep]

1. Самое значительное время будет тратиться на операции чтения-записи в-из memory-mapped file. STL-ный overhead будет незначительный, если память заранее выделена.

2. Встречал. Писал, правда вовсе другой allocator. Из интереса покопаю google когда будет лишних 15 мин.

1. Если подсоединять секции по паре десятков Мб то ИО не должен быть узким местом.
2. Покопай, если сможешь, буду признателен. Кстати, если я правильно понимаю, то надо будет также переписывать сам вектор тоже, он должен обрабатывать ситуацию, когда нужный элемент выгружен на диск.

[aldep]

А че б не использовать базу данных и хранить всю эту фигню в таблице?

Хранится как раз все это в базе данных.

Проблема в том, что приходится многократно проходить этот массив и изменять его, создавать новые таблицы, и если все хранить в базе, то производительность, по сравнению к доступу из памяти, падает в ~20 раз. Поэтому мы загружали всю таблицу в память, но ее стало не хватать.

Тыда надо таблицу разбить по кускам. Типа - партишн как в Оракле. Ты ж все равно будешь читать писать в файлы. ТО что ты хочешь - это как раз Оракловая партишен таблица, сдается мне.
А ежели Оракл сидит на Шмуниксе, и там типа хорошо покрутить всякие гайки - то приблизительно мона добиться чтоб ваще вся таблица (или куски) торчали в памяти на сервере и свести ввод вывод на диск к минимуму.

База может находится на другой машине, и кстати она совсем не обязательно в Оракле. Очень часто она в SAS файле, так как Оракл не поддерживает больше 1К столбцов.
Запрос к memory mapped файлу гораздо быстрее чем запрос к серверу БД, даже если он на той же машине.
Время на создание и заплонение такого файла небольшое по сравнению с временем вычислений. Кроме того, как я сказал, данные надо изменять, поэтому на сервере все равно надо создавать временную таблицу.

[Woozy]

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

Я не нашёл в точности того метода, о котором писал, но вот, тоже решение: http://www.garret.ru/~knizhnik/post.html

Как понимаю, persistent так же будет решением для невообразимо огромных массивов.

[dEBUGER]

А как mapped memory file решает проблему?

Исходная проблема ведь заключается в отсутствии механизма адресации памяти свыше 4гб, как только замэпишь
файл в память, получишь доступ только к его 4 гб от начала
(а еще точнее 2гб - пользовательские), так?

ИМХО копать надо в построение механизма адресации
с 64разрядными адресами, и его мэппинга на 32 разрядные.

Я одно время интересовался, но не получив зеленого света от начальства, бросил, даже не начав А было бы интересно,
действительно.

Идея с базой данных вполне живая, имхо.
Там все эти проблемы в полный рост, и уже решены.

Д.

[Woozy]

А как mapped memory file решает проблему?

Код: Выделить всё

LPVOID MapViewOfFile(
  HANDLE hFileMappingObject,
  DWORD dwDesiredAccess,
  DWORD dwFileOffsetHigh,             // 32 bit +
  DWORD dwFileOffsetLow,              // 32 bit
  SIZE_T dwNumberOfBytesToMap
);

А как код, использующий MMF, вычисляет и хранит индекс для доступа к массиву с потенциальным размером (не числом элементов, размером!) в 64 бит - это вовсе не Win32 проблема.

[MarkM]

Возникла проблема: в программе надо использовать массивы размером больше, чем 4GB.
Напрашивающееся решение - создать библиотеку, которая через memory-mapped files будет хранить массив на диске и по мере надобности подмонтировать нужные секции в память.
Нужен совет вот по каким вопросам:
1. Есть ли какие-то подводные камни в этом подходе?
2. Нет ли уже написанной библиотеки?

П.С. Платформа - Win32.

[trn]V Vin32 adresnoe prostranstvo processa 2Gb. (3Gb v Advanced Server). Kak ne kruti, bol'she v pamjat' ne vpihnesh. Hranit' 2-h Gb sekcii na diske mozhno. Esli u tebja posledovatel'nyj dostup. Esli dostup vraznoboj, to peremaplen'ja sozhrut ves' performans.


[/trn]