Need help! Не решается задача, упираюсь в ограничения железа

 

Есть большой объем информации (около 20 Гб в текстовом файле).

Информация состоит из однотипных последовательностей, их около миллиона. 

Необходимо многократно перебирать все последовательности и производить некие расчеты.

 

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

Но не тут-то было, при очередном ресайзе МТ ругается "Memory handler: cannot allocate 5610000 bytes of memory".

Диспетчер при этом говорит, что terminal.exe использует 3.5 Гб оперативки (из 16 физической). Я так понимаю, это из-за того, что процесс может получить только 4Гб.

Перед началом 

Прочитано 2% 

Прочитано 6% 

Прочитано 12% 

Прочитано 15% 

Все... 

 

Советник говорит "Not enough memory (4007 Mb used, 88 Mb available, 4095 Mb total)!!!".

А это - только 15.3% от необходимого объема (а хотелось бы и его в перспективе увеличить). 


 

Вариант №2 - каждый раз читать файл. Находить нужный кусок, сохранять его в структуру, читать следующий кусок, сравнивать результат, перезаписывать структуру.

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

Поэтому читать придется много раз, а это:

  • ооооочень медленно
  • протрет дырку в винте
Не уверен, что готов ждать результатов несколько дней...

Огорчает и объем информации... Было бы там Гиг 10, перенес бы на RAM-диск (по сути, в память), и читал бы сколько влезет. Да? 

 

 

А больше у меня фантазии не хватает.

Попробовать перекомпоновать эти последовательности так, чтоб получилось много-много кусков, но в каждом - только необходимая на текущий момент информация?

Еще сжать данные (я и так на float-ы с char-ами везде где можно перешел)? Но это даст еще процентов 10-20% максимум, а мне нужно на порядок уменьшить объем..

 

Подскажите, кто что думает, друзья. За мной не заржавеет ) 

 

komposter:

Подскажите, кто что думает, друзья. За мной не заржавеет ) 

Как варианты...

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

2. использовать маппинг для файла. винда сама закеширует что ей надо, винт не затрется.

 
TheXpert:

Как варианты...

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

2. использовать маппинг для файла. винда сама закеширует что ей надо, винт не затрется.

1. Это и есть кэш... Или я не понимаю, что ты имеешь в виду. Мой вариант с постоянным чтением необходимых кусков?

2. Можно чуть подробнее? Что даст маппинг и с какой стороны к нему подойти?

 
Про маппинг начинаю въезжать. Сейчас еще поизучаю маны, и вперед на мины )
 

Черт...

32-битные архитектуры (Intel 386, ARM 9) не могут создавать отображения длиной более 4 Гб

Те же яйца, только сбоку. Чтение, может, и ускорится, но глобально проблему это не решает.

 

Еще одна мысль - перенести все в БД (MySQL?) и работать с ней. По идее, БД заточены под такие объемы и постоянное перелопачивание.

Есть эксперты? Кто что скажет? 

 

1) Переделать алгоритм как-то можно? Чтобы загружать блок (2Гб) обрабатывать, сохранять результат (по короче),  освобождать память, загружать следующий блок ...

а в конце все результаты обрабатывать заново. 

2) Когда много работы с памятью ассоциируются решения на основе хешей, В-деревьев (и их модификаций), выгрузка в БД. 

 
ALXIMIKS:

1) Переделать алгоритм как-то можно? Чтобы загружать блок (2Гб) обрабатывать, сохранять результат (по короче),  освобождать память, загружать следующий блок ...

а в конце все результаты обрабатывать заново. 

2) Когда много работы с памятью ассоциируются решения на основе хешей, В-деревьев (и их модификаций), выгрузка в БД. 

1. Об этом писал - можно, но проблема в том, что обрабатывать данные нужно многократно. Это будет очень медленно.

2. Завтра погуглю сам, буду благодарен за краткое описание.

 
komposter:

1. Об этом писал - можно, но проблема в том, что обрабатывать данные нужно многократно. Это будет очень медленно.

2. Завтра погуглю сам, буду благодарен за краткое описание.

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

Отсортировать строки в файле размером 3GB | FulcrumWeb
Отсортировать строки в файле размером 3GB | FulcrumWeb
  • www.fulcrumweb.com.ua
Необходимо написать алгоритм, который бы смог отсортировать строки в файле большого размера (от 2-х до 4-х Gigabytes). Результатом выполнения должен быть другой файл. За хорошую реализацию гарантированный приз – флешка для хранения таких файлов и, возможно, предложение работы в нашей компании.
 
я конечно извинсь а что если попробовать 64 бита или мт крутит только 32 
я по наивности считал что такая высоко математичная штука должна вращаться на 64х битах
взять те же проги по расчету аэродинамики летательных аппаратов так они в принципе не работают на 32х
по поводу основного аргумента что на 32х быстрее машина шевелится знаю но вот это уже действительно проблема железа имхо
 

1. Естественно, использовать x64 систему.

2. Арендовать машину помощнее в облаке Amazon EC2 и сделать расчёты на ней.

3. Использовать сжатые данные, распаковывать в памяти на лету. Вещественные данные лучше сжимаются, если разделить их на потоки (знак/мантисса/экспонента); можно использовать 12-bit float (в ущерб точности).

4. Сделать расчёт вне советника чем-нибудь, что умеет работать с большими данными (Matlab/R/etc).

Причина обращения: