Линейное торможение - ошибка программиста или особенность работы MT4? - страница 9
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
К вам у меня нет никаких претензий.
K papaklass тоже нету.
Вы его адвокат?
А вы его прокурор? Не понравилось мне, что вы за него посчитали - там можно сказать, да не тебе, а тут нельзя тебе, а вот тому дядьке можно.
Просто не понравилось, вот и высказался. Никаких личностных претензий - сугубо относительно ситуации.
-Aleks-:
Итак примерная скорость обработки данных - 23 прохода с 2000 по 2013 на часовом тайм фрейме по ценам открытия:
1. Kamikadze_MA_V_01 - 5 минут
2. Kamikadze_MA_V_02 - 15 минут
3. Kamikadze_MA_V_03 - более 30 минут
Такая работа просто убивает возможность оперативной настройки советника.
То есть 23 прохода за 30 минут - это долго?.. Интересно.
У меня советник на М15 с июня по сентябрь по всем тикам на один проход в тестере тратит сутки. Вот это - долго. Про оптимизацию вообще молчу. Да и не нужна она...
У меня советник на М15 с июня по сентябрь по всем тикам на один проход в тестере тратит сутки. Вот это - долго. Про оптимизацию вообще молчу. Да и не нужна она...
То есть 23 прохода за 30 минут - это долго?.. Интересно.
У меня советник на М15 с июня по сентябрь по всем тикам на один проход в тестере тратит сутки. Вот это - долго. Про оптимизацию вообще молчу. Да и не нужна она...
Самое важное это то, что я показал как регрессировала скорость работы при эволюционировано советника. Советник который работает по тикам - я вообще в таких сомневаюсь, так как тики сгенерированы и ничего общего с историей не имеют.
А у меня мультивалютник на М5 по ценам открытия на 9месячной истории тратит 20 минут на 15000 проходов генетики. Но это тоже не показатель. Многое зависит от количества используемых индикаторов...
А можно ли существенно ускорить работу советника на истории, подготовив расчетные данные индикаторов предварительно сохранив их в файл?
Самое важное это то, что я показал как регрессировала скорость работы при эволюционировано советника. Советник который работает по тикам - я вообще в таких сомневаюсь, так как тики сгенерированы и ничего общего с историей не имеют.
А можно ли существенно ускорить работу советника на истории, подготовив расчетные данные индикаторов предварительно сохранив их в файл?
Есть вероятность, что скорость чтения с диска будет проигрывать скорости расчёта оптимизированного индикатора. Да и как быть с вычислениями на удалённых агентах? Засылать им рассчитанные индикаторы? В конкретно Вашем случае полно вариантов оптимизации скорости выполнения. Нужно избегать лишних циклов. + подумать, все ли действия так уж критично производить на каждом тике, возможно достаточно будет ограничится "событием новый бар".
Есть вероятность, что скорость чтения с диска будет проигрывать скорости расчёта оптимизированного индикатора. Да и как быть с вычислениями на удалённых агентах? Засылать им рассчитанные индикаторы? В конкретно Вашем случае полно вариантов оптимизации скорости выполнения. Нужно избегать лишних циклов. + подумать, все ли действия так уж критично производить на каждом тике, возможно достаточно будет ограничится "событием новый бар".
А разве нельзя прочесть данные один раз и создать из них массив, и уже потом обращаться к нему?
Что же касается моего конкретного советника, то напоминаю, что оптимизацию проводил по ценам открытия - т.е. без тиков видимо. А насчет подумать, то в итоге плачу исполнителю за оптимизацию своего же кода, но без проверок в коде на произошедшие события по действию советника, обещает существенный прирост скорости работы в оптимизаторе, надеюсь что это так.
Спасибо за дельный совет!
К месту задам тут вопрос, если советников штук 20 одновременно будут работать в момент открытия бара, то не приведет ли это к пиковому торможению и ошибкам открытия ордеров, так как за время расчета данных цена сильно измениться?
А разве нельзя прочесть данные один раз и создать из них массив, и уже потом обращаться к нему?
При тестировании происходит прогон по истории. Эмуляция торговли. когда при каждом следующем отсчёте (вызове советника) он получает только те данные которые уже поступили бы. В случае с файлом у него будет в распоряжении ВСЯ история индикатора включая то будущее, что его ждёт впереди при последующих вызовах. т.е. либо нужно дочитывать файл, либо правильно адресоваться по массиву. Кстати, массив при этом будет немало места в памяти занимать. Уверяю это не та сторона в которую нужно двигаться при оптимизации. По крайней мере не в этом случае уж точно.
К месту задам тут вопрос, если советников штук 20 одновременно будут работать в момент открытия бара, то не приведет ли это к пиковому торможению и ошибкам открытия ордеров, так как за время расчета данных цена сильно измениться?
В случае, если все 20 советников будут на одном и том-же инструменте, да. Они начнут вычисления практически одновременно. Но нужно учитывать, что:
- каждый из них будет выполняться в отдельном потоке. При 4х ядерной конфигурации компьютера смогут выполняться 4 одновременно практически не оказывая взаимного влияния.
- время на единичный расчёт скорее всего будет не сопоставимо мало с временем отправки торгового приказа. Именно по этой причине, торговые приказы по текущим ценам (если их может генерироваться несколько на 1 проходе) лучше бы отправлять асинхронно. Это позволит не дожидаться результата размещения первого приказа перед отправкой второго. Но и тут могут быть разные варианты... Всё зависит от торговой стратегии.
В случае же, если советники работают на разных инструментах, то и тики и новый бар у них чаще всего будут происходить не одновременно.
При тестировании происходит прогон по истории. Эмуляция торговли. когда при каждом следующем отсчёте (вызове советника) он получает только те данные которые уже поступили бы. В случае с файлом у него будет в распоряжении ВСЯ история индикатора включая то будущее, что его ждёт впереди при последующих вызовах. т.е. либо нужно дочитывать файл, либо правильно адресоваться по массиву. Кстати, массив при этом будет немало места в памяти занимать. Уверяю это не та сторона в которую нужно двигаться при оптимизации. По крайней мере не в этом случае уж точно.
В случае, если все 20 советников будут на одном и том-же инструменте, да. Они начнут вычисления практически одновременно. Но нужно учитывать, что:
- каждый из них будет выполняться в отдельном потоке. При 4х ядерной конфигурации компьютера смогут выполняться 4 одновременно практически не оказывая взаимного влияния.
- время на единичный расчёт скорее всего будет не сопоставимо мало с временем отправки торгового приказа. Именно по этой причине, торговые приказы по текущим ценам (если их может генерироваться несколько на 1 проходе) лучше бы отправлять асинхронно. Это позволит не дожидаться результата размещения первого приказа перед отправкой второго. Но и тут могут быть разные варианты... Всё зависит от торговой стратегии.
В случае же, если советники работают на разных инструментах, то и тики и новый бар у них чаще всего будут происходить не одновременно.
Я правильно понял, что надо сделать искусственную задержку при отправке приказов на открытие ордеров, но при этом не ждать подтверждения того, что они открылись?
Я правильно понял, что надо сделать искусственную задержку при отправке приказов на открытие ордеров, но при этом не ждать подтверждения того, что они открылись?
micle:
никаких искусственных задержек делать не нужно. Это за вас сделает интернет и брокер...
Я говорю про следующую ситуацию, возникающую при ручной торговле - отправил заявку на открытие ордера и ждешь пока он обработается, бывает что минуту ждешь а при попытке отправить ещё один ордер пишут "канал занят", в итоге, как правило, первый ордер не открыт по причине изменения цены, а второй терминал не дал отправить (или брокер не принял?), как в таком случае поведет советник себя, нужно ли как то это особо прописывать, или он сможет отправлять заявки на открытия не дожидаясь их исполнения?