Алгоритмы, методы решений, сравнение их производительности - страница 23

Новый комментарий
 
Andrey Khatimlianskii:

Можно просто более длинный интервал. Чтобы хотя бы секунд 30 тест шел.

С нормализацией.

pass 0 returned result 100000.000000 in 0:00:35.296
pass 1 returned result 100000.000000 in 0:00:29.361
pass 2 returned result 100000.000000 in 0:00:24.549
pass 3 returned result 100000.000000 in 0:00:25.067
pass 4 returned result 100000.000000 in 0:00:24.578
pass 5 returned result 100000.000000 in 0:00:24.634
pass 6 returned result 100000.000000 in 0:00:25.079
optimization finished, total passes 7
optimization done in 3 minutes 09 seconds
shortest pass 0:00:24.549, longest pass 0:00:35.296, average pass 0:00:26.937


Без нормализации.

pass 0 returned result 100000.000000 in 0:00:33.035
pass 1 returned result 100000.000000 in 0:00:26.020
pass 2 returned result 100000.000000 in 0:00:20.137
pass 3 returned result 100000.000000 in 0:00:20.859
pass 4 returned result 100000.000000 in 0:00:21.130
pass 5 returned result 100000.000000 in 0:00:20.664
pass 6 returned result 100000.000000 in 0:00:21.001
optimization finished, total passes 7
optimization done in 2 minutes 50 seconds
shortest pass 0:00:20.137, longest pass 0:00:33.035, average pass 0:00:23.263


Все те же 20%.

 
fxsaber:

Так один Агент работает, последовательно считает одно и то же. Если убрать всякие случайности, то чистая производительность близка именно к shortest.

Чистая не интересна, так как не достижима в реальности.

Благодарю за тесты.

 
fxsaber:

С нормализацией.

Без нормализации.

Все те же 20%.


20% для советника-пустышки, который ничего не делает... Не очень то и значимо.  В реальном коде цифра будет в разы меньше.  Стоит ли тратить время на такие пустяки.

И если уж говорить об оптимизации вычислений, то надо начать того, что нет нужды постоянно мониторить уровни всех отложенных ордеров. Требуется проверять только ближайший. Если он достигнут, то следующий уровень, и т.д.

 
Alexey Navoykov:

20% для советника-пустышки, который ничего не делает... Не очень то и значимо.  В реальном коде цифра будет в разы меньше.  Стоит ли тратить время на такие пустяки.

Замечание справедливо. На своем нормальном роботе вижу слишком сильное отставание Тестера. Причин много. И эта одна из них. Один проход - 100 миллионов тиков. Возьмем стандартную генетику на 10К проходов. Это триллион тиков, как минимум. На каждом тике Тестер делает, как минимум, одну нормализацию. Когда мог бы не делать совсем. Какая экономия на такой Оптимизации? Более того, заморачиваться - это делать нормализацию при каждом сравнении, как происходит сейчас. На самом деле проще и эффективнее - сделать нормализацию только входящих цен.

И если уж говорить об оптимизации вычислений, то надо начать того, что нет нужды постоянно мониторить уровни всех отложенных ордеров. Требуется проверять только ближайший. Если он достигнут, то следующий уровень, и т.д.

Штатный Тестер очень сильно проседает при увеличении количества ордеров. Те же сеточные ТС - его "убийцы". Предлагал такую алгоритмическую оптимизацию. Не думаю, что возьмутся.

Здесь мы упускаем из обсуждение еще большое количество сопутствующих каждому тику внутренних вычислений Тестера.

1...1617181920212223
Новый комментарий