Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
что интересно, на Висте оптмиизация проходит в 4 раза быстрее.
Просто не верится. Вы не могли бы протестировать MACD Sample на Windows Vista с параметрами по умолчанию на истории 2010.01.01-2010.08.01 на EURUSD M1, и сравнить их с результатами из этой ветки:
Реальный PR (performance rating) процессоров для тестирования
Vladon:
С чего бы это ?
А результаты одинаковые ?
наверно потому что Виста 64 битная, и она задействует 64 бита проца, а не 32 как ХР, это мое мнение, хотя по 3d marku результаты одинаковые
Реальная проблема происходит тогда, когда тестируются мультивалютные эксперты. Для нескольких инструментов тестирование увеличивается в разы. Как было бы здорово, если бы для мультивалютных экспертов каждый инструмент обрабатывался отдельным ядром.
Это ж какой должен быть проц? чтоб обработать 12 пар например, Ответ типо 12 ядерный не устаревает ..... :-)
Просто не верится. Вы не могли бы протестировать 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)
Реальная проблема происходит тогда, когда тестируются мультивалютные эксперты. Для нескольких инструментов тестирование увеличивается в разы. Как было бы здорово, если бы для мультивалютных экспертов каждый инструмент обрабатывался отдельным ядром.
Это скорей всего станет возможным на API, но там будут свои сложности. А собственную многопоточность MQL скорей всего приобретет только с 6-той версии (если вообще приобретет).
Интересным решением считаю наличие в MT встроенного механизма перераспределения нагрузки между ядрами. Причем вся хитрость должна заключаться в том чтобы потоки перераспределялись с учетом локальных и внешних ядер.
Реальная проблема происходит тогда, когда тестируются мультивалютные эксперты. Для нескольких инструментов тестирование увеличивается в разы. Как было бы здорово, если бы для мультивалютных экспертов каждый инструмент обрабатывался отдельным ядром.
Как Вы себе это представляете? Мне видится много причин, почему этого сделать нельзя в принципе в текущей версии (да и в будущих, скорей всего - также)
Теоретически многопоточность реализовать можно, вопрос как это будет выглядеть с точки зрения безопасности...
Тоеретически нужно писать советника так, чтобы он допускал параллелизацию, но для этого нужны спец. функции от mt. К тому же параллелизация усложняет понимание кода. Есть ещё проблемы - передача/синхронизация "окружения" дргугим процессорам, всё-равно ожидание "отстающего" ядра/процессора и т. д.
Пока хватит того, что есть. Вот лет эдак через 5-10, когда использование параллелизации в программировании станет де-факто стандартом - можно и вводить, а пока очень рано и распугает начинающих экспертописателей. имхо
Тоеретически нужно писать советника так, чтобы он допускал параллелизацию, но для этого нужны спец. функции от mt. К тому же параллелизация усложняет понимание кода. Есть ещё проблемы - передача/синхронизация "окружения" дргугим процессорам, всё-равно ожидание "отстающего" ядра/процессора и т. д.
Пока хватит того, что есть. Вот лет эдак через 5-10, когда использование параллелизации в программировании станет де-факто стандартом - можно и вводить, а пока очень рано и распугает начинающих экспертописателей. имхо