Need help! Не решается задача, упираюсь в ограничения железа - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
вспомнил о сайте, там похожею задачу обговаривали и варианты ее решения на с++.
Спасибо, почитаю.
я конечно извинсь а что если попробовать 64 бита или мт крутит только 32
Переход на х64 просто отодвинет потолок, при чем не очень далеко. Не бежать же мне еще за 16 Гб памяти? ;)
1. Естественно, использовать x64 систему.
2. Арендовать машину помощнее в облаке Amazon EC2 и сделать расчёты на ней.
3. Использовать сжатые данные, распаковывать в памяти на лету. Вещественные данные лучше сжимаются, если разделить их на потоки (знак/мантисса/экспонента); можно использовать 12-bit float (в ущерб точности).
4. Сделать расчёт вне советника чем-нибудь, что умеет работать с большими данными (Matlab/R/etc).
1,2: это про отодвигание потолка, а хочется решить задачу без привязки к конкретной цифре.
3. Проблема не в объеме данных на диске, а наоборот - на объеме в памяти. Я могу сжать еще на процентов 10-20, но, повторюсь, это не решит проблему.
4. Пока питаю надежду остаться в песочнице. Чтоб потом копировщики/синхронизаторы не писать...
Спасибо за участие!
Переход на х64 просто отодвинет потолок, при чем не очень далеко. Не бежать же мне еще за 16 Гб памяти? ;)
Вы же не всё время работаете с такими данными? Пишите сразу под x64 и запускайте на amazon, когда нужно. Можно и дебажить там же на micro инстансе.
Если всё-таки такая задача возникает постоянно - 64 ГБ памяти можно купить примерно за $1k, e.g. Corsair Vengeance Pro CMY64GX3M8A2133C11.
Либо пересмотреть устройство алгоритма, чтобы он мог работать в один проход по данным
p.s. Можно и в памяти сжатые данные хранить, а разжимать по мере необходимости на время, достаточное для обработки
Спасибо, почитаю.
Переход на х64 просто отодвинет потолок, при чем не очень далеко. Не бежать же мне еще за 16 Гб памяти? ;)
Вариант 1. Порезать файл на кусочки.
Вариант 2. Тоже порезать на кусочки, но еще систематизировать. Как слово в словаре ищем. Начинается на букву "А" ищем в файле "A.txt". Так можно расположить данные в форме дерева (по аналогии с словарем: папки А, Б... в папке А папки АА, АБ и т.д.), поиск будет выполняться очень быстро.
Поэтому читать придется много раз, а это:
виртуальный RAM диск в помощь ;)
и дырки не будет, и скорость понравится.
и весь объем сразу доступен.
резать на куски не надо, ибо по задаче куски не подходят
1. Это и есть кэш... Или я не понимаю, что ты имеешь в виду. Мой вариант с постоянным чтением необходимых кусков?
Ну... читать файл через свою обертку, обертка будет держать небольшую часть файла в памяти и подставлять без чтения. Я в том смысле что ты знаешь как используется файл поэтому оболочка должна получиться вполне эффективной.
Черт...
Те же яйца, только сбоку. Чтение, может, и ускорится, но глобально проблему это не решает.
Ну я думал повторяющиеся действия в пределах небольшого масштаба.
Использование маппинга это задействование виндового кэша вместо того чтобы свой писать. Загрузил кусок, прочитал, выгрузил. Если кусок используется часто, винда будет держать его в памяти.
3. Использовать сжатые данные, распаковывать в памяти на лету. Вещественные данные лучше сжимаются, если разделить их на потоки (знак/мантисса/экспонента); можно использовать 12-bit float (в ущерб точности).
4. Сделать расчёт вне советника чем-нибудь, что умеет работать с большими данными (Matlab/R/etc).
Есть большой объем информации (около 20 Гб в текстовом файле).
...
А если этот файл сжать архиватором, какой получится объём (ведь текст должен очень хорошо сжиматься)?