komposter:
Подскажите, кто что думает, друзья. За мной не заржавеет )
Как варианты...
1. делать свой кэш. в этом случае ты будешь сам управлять тем что висит в памяти. алгоритм ты знаешь, поэтому сможешь сделать кэш эффективным.
2. использовать маппинг для файла. винда сама закеширует что ей надо, винт не затрется.
Как варианты...
1. делать свой кэш. в этом случае ты будешь сам управлять тем что висит в памяти. алгоритм ты знаешь, поэтому сможешь сделать кэш эффективным.
2. использовать маппинг для файла. винда сама закеширует что ей надо, винт не затрется.
1. Это и есть кэш... Или я не понимаю, что ты имеешь в виду. Мой вариант с постоянным чтением необходимых кусков?
2. Можно чуть подробнее? Что даст маппинг и с какой стороны к нему подойти?
Черт...
32-битные архитектуры (Intel 386, ARM 9) не могут создавать отображения длиной более 4 Гб
Те же яйца, только сбоку. Чтение, может, и ускорится, но глобально проблему это не решает.
Еще одна мысль - перенести все в БД (MySQL?) и работать с ней. По идее, БД заточены под такие объемы и постоянное перелопачивание.
Есть эксперты? Кто что скажет?
1) Переделать алгоритм как-то можно? Чтобы загружать блок (2Гб) обрабатывать, сохранять результат (по короче), освобождать память, загружать следующий блок ...
а в конце все результаты обрабатывать заново.
2) Когда много работы с памятью ассоциируются решения на основе хешей, В-деревьев (и их модификаций), выгрузка в БД.
1) Переделать алгоритм как-то можно? Чтобы загружать блок (2Гб) обрабатывать, сохранять результат (по короче), освобождать память, загружать следующий блок ...
а в конце все результаты обрабатывать заново.
2) Когда много работы с памятью ассоциируются решения на основе хешей, В-деревьев (и их модификаций), выгрузка в БД.
1. Об этом писал - можно, но проблема в том, что обрабатывать данные нужно многократно. Это будет очень медленно.
2. Завтра погуглю сам, буду благодарен за краткое описание.
1. Об этом писал - можно, но проблема в том, что обрабатывать данные нужно многократно. Это будет очень медленно.
2. Завтра погуглю сам, буду благодарен за краткое описание.
вспомнил о сайте, там похожею задачу обговаривали и варианты ее решения на с++.
- www.fulcrumweb.com.ua
1. Естественно, использовать x64 систему.
2. Арендовать машину помощнее в облаке Amazon EC2 и сделать расчёты на ней.
3. Использовать сжатые данные, распаковывать в памяти на лету. Вещественные данные лучше сжимаются, если разделить их на потоки (знак/мантисса/экспонента); можно использовать 12-bit float (в ущерб точности).
4. Сделать расчёт вне советника чем-нибудь, что умеет работать с большими данными (Matlab/R/etc).
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Есть большой объем информации (около 20 Гб в текстовом файле).
Информация состоит из однотипных последовательностей, их около миллиона.
Необходимо многократно перебирать все последовательности и производить некие расчеты.
Первое, что приходит в голову - прочесть все содержимое файла, заполнить им массив структур, и работать с ними в памяти.
Но не тут-то было, при очередном ресайзе МТ ругается "Memory handler: cannot allocate 5610000 bytes of memory".
Диспетчер при этом говорит, что terminal.exe использует 3.5 Гб оперативки (из 16 физической). Я так понимаю, это из-за того, что процесс может получить только 4Гб.
Советник говорит "Not enough memory (4007 Mb used, 88 Mb available, 4095 Mb total)!!!".
А это - только 15.3% от необходимого объема (а хотелось бы и его в перспективе увеличить).
Вариант №2 - каждый раз читать файл. Находить нужный кусок, сохранять его в структуру, читать следующий кусок, сравнивать результат, перезаписывать структуру.
И если бы нужно было бы пройтись по этим последовательностям единожды, то я так бы и поступил. Но нужно проходить по ним многократно, каждый раз сдвигаясь немного вперед.
Поэтому читать придется много раз, а это:
Огорчает и объем информации... Было бы там Гиг 10, перенес бы на RAM-диск (по сути, в память), и читал бы сколько влезет. Да?
А больше у меня фантазии не хватает.
Попробовать перекомпоновать эти последовательности так, чтоб получилось много-много кусков, но в каждом - только необходимая на текущий момент информация?
Еще сжать данные (я и так на float-ы с char-ами везде где можно перешел)? Но это даст еще процентов 10-20% максимум, а мне нужно на порядок уменьшить объем..
Подскажите, кто что думает, друзья. За мной не заржавеет )