Использование ядер проца для тестинга - страница 2

 
Vladon:
что интересно, на Висте оптмиизация проходит в 4 раза быстрее.

Просто не верится.  Вы не могли бы протестировать MACD Sample на Windows Vista с параметрами по умолчанию на истории 2010.01.01-2010.08.01 на EURUSD M1, и сравнить их с результатами из этой ветки:

Реальный PR (performance rating) процессоров для тестирования

 
Valmars:
Vladon:

С чего бы это ?

А результаты одинаковые ?

наверно потому что Виста 64 битная, и она задействует 64 бита проца, а не 32 как ХР, это мое мнение, хотя по 3d marku результаты одинаковые


C-4:

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


Это ж какой должен быть проц? чтоб обработать 12 пар например, Ответ типо 12 ядерный не устаревает ..... :-)

 
dabystru:

Просто не верится.  Вы не могли бы протестировать MACD Sample на Windows Vista с параметрами по умолчанию на истории 2010.01.01-2010.08.01 на EURUSD M1, и сравнить их с результатами из этой ветки:

Реальный PR (performance rating) процессоров для тестирования

ща перегружусь на висту посмотрим( Мне виста не нравится, на нее половину программ не ставится..... )
 

Результат:  Vista x64

AMD PHENOM II x4 955 3200 MHz , 2046(DDR3 - пойду наверно еще 4гига куплю....) mb PR 128


2010.09.29 13:10:11    Core 1    EURUSD,M1: 7143132 ticks (212232 bars) generated within 24383 ms (total bars in history 576660)

Второй запуск того же самого:

2010.09.29 13:17:33    Core 1    EURUSD,M1: 7143132 ticks (212232 bars) generated within 21341 ms (total bars in history 576660)


от же самое но приоритет программе выставил на максимум, потому как при тестировании почему-то используется только 42 % процессора.  Ребята не подскажите в чем мой трабл?

2010.09.29 13:32:01    Core 1    EURUSD,M1: 7143132 ticks (212232 bars) generated within 21326 ms (total bars in history 576660)


Результат:  XP x32

AMD PHENOM II x4 955 3200 MHz , 2046mb PR 130


1 запуск:

2010.09.29 13:38:58    Core 1    EURUSD,M1: 7143132 ticks (212232 bars) generated within 22890 ms (total bars in history 576660)

2 запуск:

2010.09.29 13:40:27    Core 1    EURUSD,M1: 7143132 ticks (212232 bars) generated within 20640 ms (total bars in history 576660)


 
C-4:
Реальная проблема происходит тогда, когда тестируются мультивалютные эксперты. Для нескольких инструментов тестирование увеличивается в разы. Как было бы здорово, если бы для мультивалютных экспертов каждый инструмент обрабатывался отдельным ядром.

Это скорей всего станет возможным на API, но там будут свои сложности. А собственную многопоточность MQL скорей всего приобретет только с 6-той версии (если вообще приобретет).

Интересным решением считаю наличие в MT встроенного механизма перераспределения нагрузки между ядрами. Причем вся хитрость должна заключаться в том чтобы потоки перераспределялись с учетом локальных и внешних ядер.


 
C-4:
Реальная проблема происходит тогда, когда тестируются мультивалютные эксперты. Для нескольких инструментов тестирование увеличивается в разы. Как было бы здорово, если бы для мультивалютных экспертов каждый инструмент обрабатывался отдельным ядром.
Как Вы себе это представляете? Мне видится много причин, почему этого сделать нельзя в принципе в текущей версии (да и в будущих, скорей всего - также)
 
notused:
Как Вы себе это представляете? Мне видится много причин, почему этого сделать нельзя в принципе в текущей версии (да и в будущих, скорей всего - также)
Теоретически многопоточность реализовать можно, вопрос как это будет выглядеть с точки зрения безопасности...
 
Interesting:
Теоретически многопоточность реализовать можно, вопрос как это будет выглядеть с точки зрения безопасности...

Тоеретически нужно писать советника так, чтобы он допускал параллелизацию, но для этого нужны спец. функции от mt. К тому же параллелизация усложняет понимание кода. Есть ещё проблемы - передача/синхронизация "окружения" дргугим процессорам, всё-равно ожидание "отстающего" ядра/процессора и т. д.

Пока хватит того, что есть. Вот лет эдак через 5-10, когда использование параллелизации в программировании станет де-факто стандартом - можно и вводить, а пока очень рано и распугает начинающих экспертописателей. имхо 

 
notused:

Тоеретически нужно писать советника так, чтобы он допускал параллелизацию, но для этого нужны спец. функции от mt. К тому же параллелизация усложняет понимание кода. Есть ещё проблемы - передача/синхронизация "окружения" дргугим процессорам, всё-равно ожидание "отстающего" ядра/процессора и т. д.

Пока хватит того, что есть. Вот лет эдак через 5-10, когда использование параллелизации в программировании станет де-факто стандартом - можно и вводить, а пока очень рано и распугает начинающих экспертописателей. имхо 

Совершенно верно. Нам бы, хотя бы визуализацию увидеть одновременно на нескольких символах. А то уже замучился удалять пустые графики после тестирования, так как торговля ведётся по другим инструментам. Зачем ввели этот автоматизм ? Ну, хочешь посмотреть график, ткни на кнопку, как раньше было. Ведь потом удалять не проще.