Оптимизация в Тестере стратегий - страница 3

 
Batohov:

Похоже, что обсуждение ушло в конкретику кода определенного эксперта. Но я заметил, что почти все время тратиться на подготовительную работу (больше 90%) независимо от того, какой эксперт оптимизируется. И так при каждом прогоне (pass в логе) с новыми оптимизируемыми входными параметрами. Т.е. как ни оптимизируй код, можно получить только пару процентов прироста производительности.


Мы улучшим этап подготовительной работы при оптимизации эксперта. Время должно сократиться. Подождите немного, пожалуйста.
 
Rosh:

Мы улучшим этап подготовительной работы при оптимизации эксперта. Время должно сократиться. Подождите немного, пожалуйста.
Спасибо. Первый конкретный ответ "проблема есть, задача поставлена и решается". Подождем...
 
Batohov:

Но я заметил, что почти все время тратиться на подготовительную работу (больше 90%) независимо от того, какой эксперт оптимизируется.

Мы работаем над этим. У нас есть мысли, как уменьшить время подготовительной работы на следующих прогонах (не на первом прогоне) оптимизации.
 
alexvd:

Тоже по возможности подробнее опишите ситуацию. Сколько приходится ждать? Что пишется (если пишется) в журнал? ...

 

В журнале "complete optimization started".  Все процессора показывают ready. Ждать приходится более 5-10 минут. Точно не измерял когда начинается оптимизация потому что всегда переключался на другой access point. Access point всегда показывал все или почти все зелёные бары.
 
gpwr:
В журнале "complete optimization started".  Все процессора показывают ready. Ждать приходится более 5-10 минут. Точно не измерял когда начинается оптимизация потому что всегда переключался на другой access point. Access point всегда показывал все или почти все зелёные бары.
аналогично и у меня.. одно ядро busy, остальные ready хоть ты тресни. а иногда работают и все 4.. вот только ето никак не отражаеться на гиганском времени оптимизации
 
gpwr:
В журнале "complete optimization started".  Все процессора показывают ready. Ждать приходится более 5-10 минут. Точно не измерял когда начинается оптимизация потому что всегда переключался на другой access point. Access point всегда показывал все или почти все зелёные бары.

Кстати, проблема с начатием тестирования возникает также когда оптимизация отключена: тестирование не начинается пока не переключусь на другой Access Point. При отключенной оптимизации в журнале вообще ничего не пишется и все ядра показывают ready. Цифры в Connection Status (рядом с синим ящиком и зелёной галочкой) быстро щёлкуют. Диск тоже усердно что-то "щёлкает" в такт цифиркам. Но тестирование не начинается. По-видимому, теряется связь с Access Point не смотря на зелёную галочку. Проблема возникает на 3-х разных компьютерах: двух дома, на одном IP, и одном на работе, на другом IP.

Сообщил об этой проблеме в сервисдеск. 

 

зачем столько мусора в логах..  и ето без перечня input int, в каждую строку... кроме того обратите внимание на скорость.. до запуска теста.. проходит 2 минуты... просто один прогон ... и ето за LAST MONTH тест.. и одно ядро.. остальные отдыхают)


так же заметил что запуск самого терминала происходит чрезвычайно долго.. и даже после запуска ему нужно секнуд 5 чтоб раздуплится и начать торговать, если в експерте поставить сразу тупо продавать.. (експерт елементарный.. никаких циклов и etc)

 

Этот так называемый Вами "мусор" помогает нам выяснять причины неудач.

 
stringo:

Этот так называемый Вами "мусор" помогает нам выяснять причины неудач.

люди программируют на mql5, понимают что такое ООП :), они не посмотрят в текстовый лог при необходимости? .. зачем же ж столько всего в бортовой журнал.

и обратите внимание на время от старта.. до запуска теста.. 1m 46sec

 
maryan.dirtyn:

люди программируют на mql5, понимают что такое ООП :), они не посмотрят в текстовый лог при необходимости? .. зачем же ж столько всего в бортовой журнал.

и обратите внимание на время от старта.. до запуска теста.. 1m 46sec

Ну я понимаю в ООП. И что, думаете в лог не смотрю, периодически?

Причина обращения: