AMD или Intel а так-же бренд memory - страница 62

 

Новые ответы и новые вопросы - у вас все еще быстрее чем должно бы быть. И причина так же очевидна - сделок до сих пор меньше чем у меня (43012 при тех же настройках)... Хотя разница уже не так велика - порядка 10%.

Но вот что еще с этим делать - пока не придумал.

Изменения в таблицу внес.

Mathemat, прогони у себя тест при параметрах как у Петра в посте - сколько будет сделок?

 
ок. Посчитайте отношение кол-во сделок / время. Это будет показательно. По-уму, конечно, надо бы в числитель сумму сделок по всем прогонам, но и так сойдет.
 

Петр, это у тебя максимальное количество сделок? Ну то есть сортировка результатов по кол-ву сделок?

 
Mathemat >>:

Петр, это у тебя максимальное количество сделок? Ну то есть сортировка результатов по кол-ву сделок?


Нет. Это просто первая итерация оптимизации. Тебя интересует экстремумы по кол-ву? Тогда мне надо будет заново тест запускать - вышел я уже из того терминала. Но могу - комп пока не загружен. Так нужно?

 

510 -12767.51 8719 0.72 -1.46 13779.51 1.38% MovingPeriod=55 MovingShift=10 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
1 -56968.97 39923 0.61 -1.43 57046.37 5.70% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
Ну вот, как ни странно, это были первая и последняя итерации.

Что я еще могу сделать? Могу выложить файл экспорта истории (22 метра архива - 150 несжатых) и ты прогонишь свой тест, импортнув ее. Спред у меня на момент оптимизации (я в офф-лайне гонял) был 17 пп. в их, алпаревском пятизнаке. Можешь тоже его выставить - ссылку на прогу я приводил.

 

Мой тест - так же, 9:05.

1 -56631.66 41959 0.62 -1.35 56711.86 5.67% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
Похоже, Петр, что у тебя сортировка по числу сделок, т.к. внешние параметры у меня при такой сортировке те же, что у тебя (выделены голубым). Ну 5% мы скостили, но меня это не удовлетворяет...

Тут BARS посоветовал поставить внешнюю видяху (интегрированная отжирает память). Это я смогу проверить.

И, думаю, есть еще один фактор - синхронизация FSB камня и памяти. Максимум производительности - тогда, когда они равны, но мне пришлось бы разогнать камень в полтора раза, примерно до 3.8 GHz. Камень-то такое выдержит, он способен, но платка у меня не та, не для разгону...

А тайминги пямяти не сильно критичны, вроде где-то на ixbt читал.

P.S. У меня тоже Альпари, но данные я качал с метаквотовского сервака.

 

У меня общее количество сделок 6 710 383, и соответственно среднее за проход 13157.61

 
Mathemat писал(а) >>

Тут BARS посоветовал поставить внешнюю видяху (интегрированная отжирает память). Это я смогу проверить.

И, думаю, есть еще один фактор - синхронизация FSB камня и памяти. Максимум производительности - тогда, когда они равны, но мне пришлось бы разогнать камень в полтора раза, примерно до 3.8 GHz. Камень-то такое выдержит, он способен, но платка у меня не та, не для разгону...

А тайминги пямяти не сильно критичны, вроде где-то на ixbt читал.

Интегрированным видео можно при такой скрости памяти и наличии 2 каналов пренебречь - серьезно тормозить будет только в 3D. А на десктопе в пределах погрешности измерений.

А для синхронности работы FSB процессора и памяти можно снизить коэффициент умножения. 7*400 например будет всего 2.8 ГГц.

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

 

Ну хорошо.

Раз мы хотим реалистичности в тестировании скорости работы тестера, и очень не хотим иметь дело с бестолковыми и не имеющими ни какого отношения к реальности неторгующими экспертами, а так же с бесполезными сферическими конями, прикинем, сколько времени на что тратится.

1. Накладные расходы работы терминала и оптимизатора в нём. t1

2. Время записи логов в файл. t2

3. Время исполнения эксперта, полный 1 цикл на баре void start(). t3

Общее время:

T=k*bars*(t1+t2+t3)

k-количество проходов в оптимизаторе, у всех одинаковое, const

bars - количество баров в истории, различие у участников тестирования не более 1%(надо полагать), можно принять с достаточной точностью, const

t1-от внешних факторов не зависит (погода на улице, экономический кризис и т.д. :), зависит только от тестируемого железа.

t2 - зависит от жд.

t3 - зависит от очень многих факторов, не связанных напрямую с железом, и влияющих на точность результатов из за содержания в коде торговых функций.

Для обеспечения равных условий для всех участников тестирования на какие из трех компонентов мы можем повлиять?

Ну, наверное, t3.

С количеством сделок что то поделать сложно. Но зато можно добавить в код эксперта блок "очень полезных" вычислений, с тем, чтобы снизить влияние негативных для тестирования факторов до минимума. Скажем, что бы блок "очень полезных" вычислений занимал 95-99% от всего времени. Всё. Задача решена. Будет достигнута достаточно высокая достоверность для наших опытов.


зы. На счет сферического коня ака скрипт. Существует очень много задач, не связанных с оптимизаций экспертов в оптимизаторе. Это и жадные до вычислительных ресурсов индикаторы, и сложные мат вычисления в скриптах. Например, у меня индикатор использует нс с нейронами 400-600-200. И того 360800 весов. Для тренировки этого тяжеловеса использую отдельный скрипт. А индикатор уже читает готовые веса из файла. Ясно, что если реализовать тренировку в самом индикаторе, будем иметь проблемы с отображением графика. Можно приводить примеры и дальше.

 

Ай, я тоже так хотел, кстати. У меня - 6 577 074 сделок, чуть меньше, чем у тебя, Docent.

P.S. Вот только что еще раз прогнал. Время - 8:18 (498 сек!!!), хотя ничего не делал абсолютно. Но того затыка (раньше "задумывалась" оптимизация на минутку где-то) теперь не было.

Нужные оба файла удалил (из кэша и истории). Ничего не понимаю. Ща еще попробую видяху поставить.

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