Приведенный код основан на недоработке компилятора
Результат: 1... а почему не 2 ?
При том что С++ сообщает при компиляции об ошибке, поскольку очевидно подходят обе функции и кроме того синтаксис не позволяет явно вызвать функцию (2)
Более того учитывая специфику MQL логичнее было бы сделать с точностью до наоборот - установить приоритет передачи параметра не по значению (как сейчас), а по const ссылке (преимущества чего особенно видны на примере строк)
При использовании Local агентов файл с результатами оптимизации создается в общей папке, при использовании Local Network Farm или MQL5 Cloud Network файла нет.
Тестер стратегий позволяет тестировать и оптимизировать торговые стратегии (советники) перед началом использования их в реальной торговле. При тестировании советника происходит его однократная прогонка с начальными параметрами на исторических данных. При оптимизации торговая стратегия прогоняется несколько раз с различным набором параметров...
Безоговорочный кратный слив коду, который генерится в MQL5.
Удивительно, но у MSVC даже попыток оптимизации нет - всю математику гонит через библиотеки словно пишет под процессор 20 летней давности. И включение набора AVX команд нисколько не меняет поведения компилятора.
Тестовый C++ файл приложен. Мысль про "ошибка в тестовом примере" не надо высказывать, ошибки нет.
SQRT + математические вычисления идут без ветвлений и за одну команду (128 бит данные) вычисляется сразу два корня
Вот этот код превращается в следующий ассемблерный SSE код:
Это произведение исскуства вообще-то. 8 корней вычислено за 4 вызова ассемблерной команды. Два double числа вычислялись за один вызов.
При операциях через массив все идет штатно, с проверками, ветвлениями и потерями на конвертации double -> integer index
При работе с массивами в этом примере идет постоянное смешение FPU/ALU, что очень плохо сказывается на производлительности
Оптимизация доступа к динамическому массиву отличная, выше похвал. Но смешение FPU/ALU операций + перевод double -> integer + ветвления тратят время
Общий вывод: математика в MQL5 побеждает за счет идеальной оптимизации. Тут не массивы проигрывают, а математика выигрывает.
Спасибо большое за ценную информацию.
Новости, конечно же, больше радостные. Это реально круто!
Я всегда говорил, что MQ красавцы!
Но я также понимаю , что нужно быть крайне аккуратным со смешением типов данных. Но предупрежден - значит вооружен. Было бы здорово от разработчиков получить какие-то рекомендации в этом свете.
Сейчас поэксперементирую с типами как обычных переменных так и массивов. Интересно что получиться.
в нем только тип int и нет никакого смешения типов. При этом и сам массив SQRT стал int.
Pаботает он только на процентов 10 быстрее.
C вариантом double похожая картина.
Ну все одинаковое, только в одном случае идет вычисление функции sqrt(), при этом там происходит смешение типов.
А во втором случае идет обращение к int массиву и нет никакого смешения типов и по идее должен использоваться только ALU.
И при этом второй вариант в 3 раза медленнее. Ну как не крути причина - массив.
И еще один важный момент.
В примере int если канвас размером 100x100, т.е. с такими параметрами
то при обращении к массиву мы получаем выйгрыш в скорости.
Т.е. когда используем массив SQRT размером 20 000, мы в выигрыше 15-20%, а когда размером 3 000 000, то проигрыш 200% при абсолютно одинаковой математике.
Люди давно потеряли способность понимать результаты современных С++ компиляторов.
К тому же у вас винегрет/мусор из кода, что означает практически нулевую возможность выстроить наивные аксиомы «если такие условия, то результат получится такой». То есть, итоговая оптимизация настолько все перестроит, что ваши гипотезы будут давать на десятки процентов разные результаты даже при мизерных изменениях в коде.
Взгляните еще раз на утрамбовку 8 корней в 4 ассемблерные команды и поймите, что вы не имеете шанса что-либо утверждать, требовать или аппелировать к своей логике. Оптимизаторы давно уже работают на запредельных уровнях, недоступных программистам.
То, как компилятор разложил корни, является исскуством. А вы пытаетесь побить это массивами, даже не понимая простейшего ограничения - чтение из массива это уже провал. Идеальная регистровая работа и пакетное вычисление корней против ветвлений(штрафы) и лазанию в память с частыми промахами в кеш.
Вы задаете вопрос «почему на мелком буфере быстрее работает, а на большом оглушительно сливает» потому, что вообще не знаете о L1/L2/L3 кешах процессора. Попали в кеш - посчитали быстро. Не попали - ждите пару десятков циклов чтения данных из верхнего кеша или памяти.
Те кто не читают и не покупают, много ли Вы купили товаров не понимая для чего товар ?
Может тогда все публиковать в блогах ?
Понять предназначение товара из инструкции?
Глупость. Скачаю, и пощупаю демку.
Приведенный код основан на недоработке компилятора
Результат: 1... а почему не 2 ?
При том что С++ сообщает при компиляции об ошибке, поскольку очевидно подходят обе функции и кроме того синтаксис не позволяет явно вызвать функцию (2)
Более того учитывая специфику MQL логичнее было бы сделать с точностью до наоборот - установить приоритет передачи параметра не по значению (как сейчас), а по const ссылке (преимущества чего особенно видны на примере строк)
Непонятно зачем передавать (фактически копировать) длинющие строки по значению когда это можно делать по ссылке
Ошибка при компиляции
А зачем вручную переносить содержимое .h файла (тем более что оно может периодически меняться) если его можно просто включить?
Добрый день, подскажите:
Как записать результаты оптимизации в файл при использовании Local Network Farm или MQL5 Cloud Network ?
Есть процедура в OnTester(), использует:
При использовании Local агентов файл с результатами оптимизации создается в общей папке, при использовании Local Network Farm или MQL5 Cloud Network файла нет.
26170
Проверка показала, что:
Вот этот код превращается в следующий ассемблерный SSE код:
Это произведение исскуства вообще-то. 8 корней вычислено за 4 вызова ассемблерной команды. Два double числа вычислялись за один вызов.
Общий вывод: математика в MQL5 побеждает за счет идеальной оптимизации. Тут не массивы проигрывают, а математика выигрывает.
26170
А вот какую порнографию сделал на том же коде Visual C++ 2017 x64 с полными оптимизациями:
Безоговорочный кратный слив коду, который генерится в MQL5.
Удивительно, но у MSVC даже попыток оптимизации нет - всю математику гонит через библиотеки словно пишет под процессор 20 летней давности. И включение набора AVX команд нисколько не меняет поведения компилятора.
Тестовый C++ файл приложен. Мысль про "ошибка в тестовом примере" не надо высказывать, ошибки нет.
У меня не строится график оптимизации по отрицательным значениям.
Данные в результатах оптимизации имеются.
Попробуйте в своих советниках задавать отрицательные значения. Значения можно * -1 для проверки.
Проверка показала, что:
Вот этот код превращается в следующий ассемблерный SSE код:
Это произведение исскуства вообще-то. 8 корней вычислено за 4 вызова ассемблерной команды. Два double числа вычислялись за один вызов.
Общий вывод: математика в MQL5 побеждает за счет идеальной оптимизации. Тут не массивы проигрывают, а математика выигрывает.
Спасибо большое за ценную информацию.
Новости, конечно же, больше радостные. Это реально круто!
Я всегда говорил, что MQ красавцы!
Но я также понимаю , что нужно быть крайне аккуратным со смешением типов данных. Но предупрежден - значит вооружен.
Было бы здорово от разработчиков получить какие-то рекомендации в этом свете.
Сейчас поэксперементирую с типами как обычных переменных так и массивов. Интересно что получиться.
Поэкспериментировал.
Что-то у меня все равно пазлы не сходятся.
Сделал два варианта. Первый -по максимуму все перевел на тип int. Второй - на double.
Да, стало чуть быстрее. Но основные тормоза все равно присутствуют.
Вот с вариантом int главный тормозной блок:
в нем только тип int и нет никакого смешения типов. При этом и сам массив SQRT стал int.
Pаботает он только на процентов 10 быстрее.
C вариантом double похожая картина.
Ну все одинаковое, только в одном случае идет вычисление функции sqrt(), при этом там происходит смешение типов.
А во втором случае идет обращение к int массиву и нет никакого смешения типов и по идее должен использоваться только ALU.
И при этом второй вариант в 3 раза медленнее. Ну как не крути причина - массив.
И еще один важный момент.
В примере int если канвас размером 100x100, т.е. с такими параметрами
то при обращении к массиву мы получаем выйгрыш в скорости.
Т.е. когда используем массив SQRT размером 20 000, мы в выигрыше 15-20%, а когда размером 3 000 000, то проигрыш 200% при абсолютно одинаковой математике.
Выходит размер массива причина тормозов?
26170
Люди давно потеряли способность понимать результаты современных С++ компиляторов.
К тому же у вас винегрет/мусор из кода, что означает практически нулевую возможность выстроить наивные аксиомы «если такие условия, то результат получится такой». То есть, итоговая оптимизация настолько все перестроит, что ваши гипотезы будут давать на десятки процентов разные результаты даже при мизерных изменениях в коде.
Взгляните еще раз на утрамбовку 8 корней в 4 ассемблерные команды и поймите, что вы не имеете шанса что-либо утверждать, требовать или аппелировать к своей логике. Оптимизаторы давно уже работают на запредельных уровнях, недоступных программистам.
То, как компилятор разложил корни, является исскуством. А вы пытаетесь побить это массивами, даже не понимая простейшего ограничения - чтение из массива это уже провал. Идеальная регистровая работа и пакетное вычисление корней против ветвлений(штрафы) и лазанию в память с частыми промахами в кеш.
Вы задаете вопрос «почему на мелком буфере быстрее работает, а на большом оглушительно сливает» потому, что вообще не знаете о L1/L2/L3 кешах процессора. Попали в кеш - посчитали быстро. Не попали - ждите пару десятков циклов чтения данных из верхнего кеша или памяти.