Need help! Не решается задача, упираюсь в ограничения железа - страница 11
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Юрчик, я имел ввиду без выкрутасов с обработкой файлов, сжатием и т.п. Чисто работа с SQL и логикой робота/индикатора. Работал со многими БД, единственной проблемой было подружить MQL c SQL )), сделал красивое решение без всяких там массивов и структур.
В общем, я предпочитаю не изобретать велосипед, а решать задачи оптимальными средствами.
Женя да , я понял тебя...
именно это и я предпочитаю
... особенно если есть готовый профессиональный инструмент ... лучше красиво интегрировать
Вот это дискуссия! Спасибо всем за участие!
Отвечу всем вместе, постараюсь ничего (и никого) не пропустить.
1. Перейти на x64
Далеко не сразу дошло, что я не указал версию терминала. Я работаю с 4-кой, и на 5-ку переносить этого советника пока не собираюсь. МТ4, к сожалению, только 32-битный.
Убираем ограничение в 4 Гб памяти на 32 битных Windows 8 / 8.1 - не поможет, система у меня и так x64.
2. Резать на куски / читать по частям / загружать небольшие блоки
Не получится по условиям задачи.
Я попробую дать больше деталей ниже, возможно, это позволит лучше понять проблему.
3. Закупить больше памяти / арендовать мощный сервер или облако / перенести все на SSD
Я, конечно, поставлю еще 16 Гб памяти в свободные слоты, но это не выход.
Этот объем - не предел, и расширение мощностей решит лишь частный случай задачи.
Считаю, что к этому нужно будет прибегать только когда будет уверенность, что алгоритмически выжато 100%.
4. Сжать данные
Этим сейчас занимаюсь.
Текстовый кэш (который 20 Гб) сжался в 2 раза, и еще наверное немного сожмется.
Это не решает проблему с объемом данных в памяти, но приближает к некоторым другим решениям (RAM-диск).
Перевод в бинарный вид тоже сделаю, это еще ускорит чтение и сократит объем.
Как сжимают мастера из http://www.nanex.net/historical.html - не понятно. Структуры с данными у них достаточно избыточные.
5. Сжать/закодировать данные и разжать/раскодировать нужный кусок перед использованием
Принимается, как вариант.
Но что-то мне подсказывает, что будет тоже долго (тут упремся в процессор).
6. Перенести расчет во внешнюю программу (Matlab/R/etc)
Не хочется, причин много.
Разве что в хорошо интегрированную с МТ среду. Но это все равно потребует время на изучение программы/среды и/или заказ решения у стороннего разработчика. Это неудобно и затратно на этапе разработки (а у меня именно он).
В общем, пока стараюсь остаться в песочнице со всеми ее плюсами и минусами.
Не понимаю, как это может помочь.
Все равно придется многократно получать данные из основного файла (постоянно его перечитывая).
8. Использовать БД
Очень заманчивый вариант, учитывая:
Но и минусы есть:
- Относительно новая для меня среда (плотно не работал, только базовые запросы);
- Сложность инсталляции на отдельно взятой клиентской машине (автономный вариант);
- Наверняка что-то еще..
В общем, если не подойдут другие варианты, скорее всего к этому и вернусь.9. Разобраться и проверить новые и непонятные термины
Это просто заметка себе на будущее и/или запрос на дополнительную информацию к авторам ;)
Остались нераскрытыми: Файл-маппинг, решения на основе хешей, В-деревьев.
10. Перенести терминал со всеми кэшами на виртуальный RAM диск
Пока это наиболее перспективный (по соотношению трудозатраты/результат) вариант.
RAM Disk от SoftPerfect установил, закончу сжимать кэш, перепишу считалку на постоянное чтение файла и проверю быстродействие.
11. Правильно поставить задачу =)
Очень хороший совет, особенно учитывая скудность вводной информации.
Как и обещал, попробую дать больше деталей.
Есть много однотипных последовательностей сделок, каждая последовательность отсортирована по времени.
Сделки в разных последовательностях разные, по времени распределены неравномерно (и в каждой последовательности по своему). Сделок разное количество. Но все - в интервале от Даты1 до Даты2.
Задача - двигаясь от Д1 до Д2 с шагом М минут (а лучше - конкретно по точкам совершения сделок всех последовательностей), находить последовательность, которая лучше остальных по критерию К (отдельная задача - не просто находить лучшую последовательность, а сортировать все множество по критерию и выводить 10 лучших - но это факультатив, пока не обязательно).
Критерий К рассчитывается на основании Х предыдущих сделок соответствующей ему последовательности, при расчетах используется практически вся информация о каждой из Х сделок (только прибыли, например, не достаточно).
Критерий (К), количество сделок (Х), и другие параметры, влияющие на результаты, меняются пользователем. Т.е. не могут быть "зашиты" в алгоритм.
Как-то так.
По идее, можно переструктурировать файл, чтоб он был линейным для всех сделок всех последовательностей.
Но как это сделать, не помещая всю информацию в память? И как потом пересчитать Критерий, если сделки одной последовательности "размажутся" по всему файлу?
Теперь, надеюсь, задача ясна.
Еще раз выражаю огромную благодарность за участие, обсуждение, вопросы, ссылки и конкретные ответы:
TheXpert, Urain, sergeev, elugovoy, anonymous, meat, ALXIMIKS, IvanIvanov, Integer, C-4, marketeer, barabashkakvn, Silent, GT788, papaklass, grizzly_v, artemiusgreat, YuraZ, Candid, Contender и server
Спасибо!
Вот это дискуссия! Спасибо всем за участие!
....Очень заманчивый вариант, учитывая:
Но и минусы есть:
- Относительно новая для меня среда (плотно не работал, только базовые запросы);
- Сложность инсталляции на отдельно взятой клиентской машине (автономный вариант);
- Наверняка что-то еще..
В общем, если не подойдут другие варианты, скорее всего к этому и вернусь.Если идти в сторону SQL
Это может достаточно тормознуть на этапе освоения.
Если выбрать этот вариант лучше построить всю бизнес логику хранимыми процедурами
оставив эксперту только две функции отправить серверу запрос и получить полностью готовый результат
все расчеты на сервере
На самом деле в сети можно найти много описаний как поставить SQL сервер
( ORACL,SYBASE + CENTOS например ) ORACL,SYBASE,MS SQL+WINDOWS отдельная машина
ORACL - чуть сложнее в освоении - меньше специалистов ,меньше литературы
MS SQL - пожалуй больше всего в сети информации и больше литературы
особых трудностей тут не будет - в инете достаточно много описаний в магазине больше книг
MSSQL 2012 по своим параметрам приблизился вплотную к ORACL - уже есть 2014
Выбор связки SQL + LINUX обычно выбирают в промышленной эксплуатации - и если нет познаний в LINUX лучше взять WINDOWS
komposter:
Есть много однотипных последовательностей сделок, каждая последовательность отсортирована по времени.
Сделки в разных последовательностях разные, по времени распределены неравномерно (и в каждой последовательности по своему). Сделок разное количество. Но все - в интервале от Даты1 до Даты2.
Задача - двигаясь от Д1 до Д2 с шагом М минут (а лучше - конкретно по точкам совершения сделок всех последовательностей), находить последовательность, которая лучше остальных по критерию К (отдельная задача - не просто находить лучшую последовательность, а сортировать все множество по критерию и выводить 10 лучших - но это факультатив, пока не обязательно).
Критерий К рассчитывается на основании Х предыдущих сделок соответствующей ему последовательности, при расчетах используется практически вся информация о каждой из Х сделок (только прибыли, например, не достаточно).
Критерий (К), количество сделок (Х), и другие параметры, влияющие на результаты, меняются пользователем. Т.е. не могут быть "зашиты" в алгоритм.
Как-то так.
По идее, можно переструктурировать файл, чтоб он был линейным для всех сделок всех последовательностей.
Но как это сделать, не помещая всю информацию в память? И как потом пересчитать Критерий, если сделки одной последовательности "размажутся" по всему файлу?
Теперь, надеюсь, задача ясна.
Традиционно торможу с утра :).
Одна последовательность будет помещаться в память или уже с этим проблемы?
Если первое, то когда возникает многократное чтение с диска, при смене пользователем критерия и параметров?
Если да, то смена идёт по какому-то алгоритму или вручную по каким-то субъективным основаниям?
Традиционно торможу с утра :).
Одна последовательность будет помещаться в память или уже с этим проблемы?
Если первое, то когда возникает многократное чтение с диска, при смене пользователем критерия и параметров?
Если да, то смена идёт по какому-то алгоритму или вручную по каким-то субъективным основаниям?
Миллион последовательностей.
А потом в каждой из них находится точка с нужной датой и анализируется предшествующая история.
И выбирается лучшая из последовательностей.
И происходит переход к следующей точке "истории".
Думаю, что если не хочется заморчивать конечных пользователей установкой СУБД, то есть вариант синтезировать несколько (с десяток) типичных критериев К (например, обозвать их консервативная торговля, агрессивная торговля и т.д.) и фактически зашить-таки в алгоритм, просчитать один раз для всех последовательностей изменение выбранного показателя во времени и потом уже работать с одномерными векторами.
Критериев, допустим, всего 2.
Но параметров, которые настраивают критерий, несколько, и каждый может принимать разные значения.
Даже если очень грубо взять несколько значений каждого параметра получится не одномерный вектор, а 3-х или 4-х мерный массив.
Тогда точно памяти не хватит =)
Миллион последовательностей.
А потом в каждой из них находится точка с нужной датой и анализируется предшествующая история.
И выбирается лучшая из последовательностей.
И происходит переход к следующей точке "истории".
В память загружается последовательность целиком. Затем в ней "находится точка с нужной датой и анализируется предшествующая история". Значение критерия сравнивается с лучшим достигнутям. Если лучше, то запоминается критерий и то, что нужно знать про лучшую последовательность. Затем на место обработанной последовательности загружается следующая. И так миллион раз.
Файл при этом читается последовательно и только один раз.
Что не так?
В память загружается последовательность целиком. Затем в ней "находится точка с нужной датой и анализируется предшествующая история". Значение критерия сравнивается с лучшим достигнутям. Если лучше, то запоминается критерий и то, что нужно знать про лучшую последовательность. Затем на место обработанной последовательности загружается следующая. И так миллион раз.
Файл при этом читается последовательно и только один раз.
Что не так?
Все так.
А потом "нужная дата" сдвигается на точку закрытия сделки из выбранной последовательности и алгоритм повторяется.
И так еще миллион раз =)
Все так.
А потом "нужная дата" сдвигается на точку закрытия сделки из выбранной последовательности и алгоритм повторяется.
И так еще миллион раз =)
Но последовательности же независимы друг от друга? Тогда почему нельзя сделать сразу цикл по датам на один раз загруженной последовательности? Здесь, кстати, как раз может появиться возможность перейти к какому-нибудь эффективному рекуррентному алгоритму, но это как повезёт. Размерность миллион на миллион останется, а файл один раз будет читаться.
Вообще конечно задача, в которой на следующей итерации число шагов остаётся прежним (то есть зона поиска по мере расчётов не сужается), не выглядит особо робастной. Но это субъективно конечно.