Need help! Не решается задача, упираюсь в ограничения железа - страница 19
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Так нужно будет перебирать несколько миллионов сделок от других последовательностей! Я именно об этом.
Ну речь о проверке одного одного числа (номера последовательности), миллион не так уж и много для такой элементарной операции. Если считать критерий рекурсивно то это всего один проход файла, его то по любому делать придётся. Другое дело, что "карта" данных для рекурсии будет на те же несколько миллионов элементов (помножить на число параметров для одной последовательности).
Возможна и альтернатива - сплошной расчёт критерия с запоминанием до сортировки. Опять критична возможность использования рекурсии.
Понятно, что операций по любому будет много, а разве в исходном варианте их меньше?
В С++ можно и без парсера если:
толкаю идею в 10 раз - завести еще один файл с значениями начала позиций последовательностей в другом файлу, тогда в структуре последовательности даже не нужно будет хранить количество сделок.
Получится обычный индекс, о котором уже упоминалось ранее.
Реализовал алгоритм, который описывал выше.
Обработка моих данных при Х = 20 (расчет критерия по 20 сделкам) занимала примерно 112 минут (точно не засек), львиную долю съедал сдвиг массивов (40% судя по профилировщику).
После закольцовки массивов и некоторой другой оптимизации обработка стала занимать:
Памяти хватало всего на 65 сделок (умножить на миллион последовательностей). Этого, конечно, недостаточно, я рассчитывал хотя бы на 100.
Следующим шагом стало отбрасывание всей лишней информации о сделках. Оставив только время открытия и закрытия, и прибыль в пунктах, удалось взлететь с Х = 185.
Дальше - только ускорять работу с файлом, FileReadХХХ сейчас занимает 30% времени (при чем диспетчер говорит что работы с диском нет, только процессор загружен).
FileRead - конкретно первый после FileSeek-а, т.е. последовательное чтение работает быстро.
О новых результатах сообщу.
В С++ это делается fread-ом в буфер 64К-128К, разбирать лучше своим парсером, ибо sscanf-ы сильно тормозные.
Буду пробовать работать с файлами через WinAPI, мне, собственно, это сервис-деск и посоветовал:
толкаю идею в 10 раз - завести еще один файл с значениями начала позиций последовательностей в другом файлу, тогда в структуре последовательности даже не нужно будет хранить количество сделок.
Я не понимаю, что даст индекс.
Запись кол-ва сделок погоды не делает, последовательное чтение работает быстро, проблема именно в чтении блока после перемещения по файлу.
Напишите, пожалуйста, предполагаемый алгоритм действий.
Задача нетривиальна, но нет еще ни одной строчки кода. Андрей, многие здесь заинтересовались - сформулируй задачу, предложи тестовые данные. Устроим спортивное программирование.
Нужны тестовые данные + псевдокод, с общими принципами работы с данными.
Задача сформулирована от и до.
А тестовые данные можно сгенерировать немного доработанным скриптом, выложенным мной ранее.
Сделаю это чуть позже.
зачем перебирать варианты из базы? может лучше сгенерировать сделки на истории согласно критериям? не? разве получится не то же, что требуется?
Если для тестов, то, конечно, да, а если для решения задачи, то, конечно, нет )
Candid:
Ну речь о проверке одного одного числа (номера последовательности), миллион не так уж и много для такой элементарной операции. Если считать критерий рекурсивно то это всего один проход файла, его то по любому делать придётся. Другое дело, что "карта" данных для рекурсии будет на те же несколько миллионов элементов (помножить на число параметров для одной последовательности).
Возможна и альтернатива - сплошной расчёт критерия с запоминанием до сортировки. Опять критична возможность использования рекурсии.
Понятно, что операций по любому будет много, а разве в исходном варианте их меньше?
В исходном варианте можно рассчитывать критерий один раз при нахождении последней сделки из пройденной истории.
А вашем варианте нужно прочитать такой кусок файла, чтоб в него поместилось Х сделок всех последовательностей. Это будет сильно больше чем Х*кол-во последовательностей, т.к. сделок разное кол-во и они могут быть распределены не равномерно.
2 all:
В любом случае, спасибо за поддержку.
Если не сложно, запустите у себя тестовый скрипт и поделитесь результатами.
А тестовые данные можно сгенерировать немного доработанным скриптом, выложенным мной ранее.
Прикладываю обновленный скрипт, теперь он записывает не просто одинаковые сделки, а генерирует случайные последовательности с заданными настройками (время жизни - от и до, прибыль - от и до).
Чтоб получить файл, сопоставимый с моим, запустите скрипт с параметрами по умолчанию:
2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15: 140000 secuences writed in 57.1 sec
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15: 6632 Mb loaded in 44.0 sec (150.7 MB/sec)
После этого на нем можно отрабатывать алгоритм.
Для самых ленивых - архив с файлом на гугл-диске.
komposter:
1. В исходном варианте можно рассчитывать критерий один раз при нахождении последней сделки из пройденной истории.
2. А вашем варианте нужно прочитать такой кусок файла, чтоб в него поместилось Х сделок всех последовательностей. Это будет сильно больше чем Х*кол-во последовательностей, т.к. сделок разное кол-во и они могут быть распределены не равномерно.
1. Это не очень понятно, если мы ищем максимум(минимум) критерия, мы в конечном итоге всё равно должны рассчитывать критерий для всех кандидатов. Даже неважно, локальный или глобальный экстремум ищется.
2. Понятно, что больше, вопрос приемлемый размер или нет с точки зрения требуемой памяти. Более того, больший размер блока в смысле скорости чтения с диска по идее даже лучше. Конечно пока не создаёт проблем для оперативной памяти. Принципиально важно, что чтение происходит последовательно и только один раз.
Вариант с расчётом критерия до сортировки правда требует чтения два раза. Но там свои преимущества, особенно с учётом возможности разбивки данных на несколько меньших файлов и их последующей совместной обработки.
Впрочем, без реализации все аргументы останутся абстрактными. Так что в этом месте дискуссии мне как раз будет уместно откланяться :)
Может сделать сшивку файлов? с индексацией на каком бите начало и конец какого файла.
Например сделать из ляма файлов, 1000 метафайлов по 1000 первоначальных, при этом если критерии известны то сделать статистическое упорядочивание чтоб похожие файлы лепились в один метафайл.
ЗЫ а лучше поэкспериментировать с FileOpen, как он быстрее работает на открытие большого файла или мелкого, в смысле открыть 1000 раз большой файл по объёму равный 1000 маленьких или 1000000 раз открыть маленький?
А то может оказаться что файлы нужно не сшивать а дробить.
Может сделать сшивку файлов? с индексацией на каком бите начало и конец какого файла.
Например сделать из ляма файлов, 1000 метафайлов по 1000 первоначальных, при этом если критерии известны то сделать статистическое упорядочивание чтоб похожие файлы лепились в один метафайл.
ЗЫ а лучше поэкспериментировать с FileOpen, как он быстрее работает на открытие большого файла или мелкого, в смысле открыть 1000 раз большой файл по объёму равный 1000 маленьких или 1000000 раз открыть маленький?
А то может оказаться что файлы нужно не сшивать а дробить.
Я сейчас работаю с одним большим файлом, но хотел уйти к миллиону маленьких.
Во-первых, их можно дописывать, а, во-вторых, к ним можно получать доступ по имени (не надо хранить "начало каждой последовательности").
В сервис-деске спрашивал про миллион открытий разных файлов (у меня так кэш реализован). Ответ однозначен и понятен.
Тестировать апи-функции буду и для одного большого файла и для миллиона маленьких, результаты опубликую.
Впрочем, без реализации все аргументы останутся абстрактными. Так что в этом месте дискуссии мне как раз будет уместно откланяться :)
С этого надо было начинать ;)
Но в любом случае спасибо за участие, идеи без кода тоже ценны.
С миллионом файлов вы угробите ntfs так, что плакать будете от этого безумного поделия Майкрософта, который навсегда всех запер в своей безумно тормозной реализации файловой системы.
Все, что сделал мс в своих файловых системах, является чудовищными гирями, тормознутостью и тупостью. Черт возьми, эти идиоты никаких усилий не предприняли для оптимизации и скорости, а апи просто примитивно. В 2014 году это можно утверждать однозначно. Ну и плакать.
Любой, кто хочет улучшить эффективность работы с кучей файлов в windows, первым делом уходит в чанки - группировку и собственную структуру данных внутри единого файла.
Как только начинаешь хранить более тысячи (а тем более десятков и сотен тысяч) разрозненных файлов в windows, ты попал.
Файловые операции в MQL4/5 у нас идут через наши очень эффективные кеширующие механизмы, которые позволяют добиваться очень эффективной и высокой скорости чтения и записи.
Можно хоть по байту стримить данные - все они сначала быстро будут собраны во внутреннем буфере и записаны на диск только большими кусками. Количество вызовов WinAPI минимально, что дает высокую скорость работы. Чтение аналогично - оно работает упреждающе, вычитывает большими кусками, очень редко обращаясь к WinAPI и очень быстро отдавая данные из своего кеша с минимальными расходами.
Грубо говоря, по сравнению с 509 билдами мы подняли скорость файловых операций в MQL4/5 на порядок(если говорить об обычной кусочной работе, а не выдуманном варианте "пишем мегабайтными блоками для максимизации замера скорости").