Ошибки, баги, вопросы - страница 2165
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
У меня не строится график оптимизации по отрицательным значениям.
Данные в результатах оптимизации имеются.
Попробуйте в своих советниках задавать отрицательные значения. Значения можно * -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% при абсолютно одинаковой математике.
Выходит размер массива причина тормозов?
Люди давно потеряли способность понимать результаты современных С++ компиляторов.
К тому же у вас винегрет/мусор из кода, что означает практически нулевую возможность выстроить наивные аксиомы «если такие условия, то результат получится такой». То есть, итоговая оптимизация настолько все перестроит, что ваши гипотезы будут давать на десятки процентов разные результаты даже при мизерных изменениях в коде.
Взгляните еще раз на утрамбовку 8 корней в 4 ассемблерные команды и поймите, что вы не имеете шанса что-либо утверждать, требовать или аппелировать к своей логике. Оптимизаторы давно уже работают на запредельных уровнях, недоступных программистам.
То, как компилятор разложил корни, является исскуством. А вы пытаетесь побить это массивами, даже не понимая простейшего ограничения - чтение из массива это уже провал. Идеальная регистровая работа и пакетное вычисление корней против ветвлений(штрафы) и лазанию в память с частыми промахами в кеш.
Вы задаете вопрос «почему на мелком буфере быстрее работает, а на большом оглушительно сливает» потому, что вообще не знаете о L1/L2/L3 кешах процессора. Попали в кеш - посчитали быстро. Не попали - ждите пару десятков циклов чтения данных из верхнего кеша или памяти.Люди давно потеряли способность понимать результаты современных С++ компиляторов.
К тому же у вас винегрет/мусор из кода, что означает практически нулевую возможность выстроить наивные аксиомы «если такие условия, то результат получится такой». То есть, итоговая оптимизация настолько все перестроит, что ваши гипотезы будут давать на десятки процентов разные результаты даже при мизерных изменениях в коде.
Взгляните еще раз на утрамбовку 8 корней в 4 ассемблерные команды и поймите, что вы не имеете шанса что-либо утверждать, требовать или аппелировать к своей логике. Оптимизаторы давно уже работают на запредельных уровнях, недоступных программистам.
Я прекрасно вижу ваши результаты сравнения с VS и я в восторге от этого.
Но вопрос остается открытым.
Я извиняюсь за хаосных рабочий код, но речь идет только о этом участке кода и о сравнении двух вариантов выполнения:
Здесь нет мусора.
Вы сказали, что "Оптимизация доступа к динамическому массиву отличная, выше похвал."
Но ... см. мое предыдущее сообщение.
Как Вы объясните последний мой эксперимент?:
"Т.е. когда используем массив SQRT размером 20 000, мы в выигрыше 15-20%, а когда размером 3 000 000, то проигрыш 200% при абсолютно одинаковой математике.
Выходит размер массива причина тормозов?"
Прочтите мой предыдущий ответ внимательно - он дописан с точным ответом.
Объясню ваши вопросы просто: вдумчиво прочтите пяток технических статей по устройству процессоров в плане производительности и факторов, влиящих на нее. Без этого нельзя вести обсуждение, так как вам нужно объяснять базовые вещи.
То, как компилятор разложил корни, является исскуством. А вы пытаетесь побить это массивами, даже не понимая простейшего ограничения - чтение из массива это уже провал. Идеальная регистровая работа и пакетное вычисление корней против ветвлений(штрафы) и лазанию в память с частыми промахами в кеш.
Вы задаете вопрос «почему на мелком буфере быстрее работает, а на большом оглушительно сливает» потому, что вообще не знаете о L1/L2/L3 кешах процессора. Попали в кеш - посчитали быстро. Не попали - ждите пару десятков циклов чтения данных из верхнего кеша или памяти.Прочтите мой предыдущий ответ внимательно - он дописан с точным ответом.
Объясню ваши вопросы просто: вдумчиво прочтите пяток технических статей по устройству процессоров в плане производительности и факторов, влиящих на нее. Без этого нельзя вести обсуждение, так как вам нужно объяснять базовые вещи.
Ура!!!
Наконец-то!
Из Вас, Ренат, все клещами нужно вытягивать.
Теперь картина для меня проясняется.
Был не прав, когда гнал на ваш компилятор. Каюсь, бес попутал. Можно было и додуматься, что причина в ограниченности кэшей процессора. Я, действительно, плохо соображаю в современных процессорах и, действительно, нужно почитать об этом.
Но все же не зря я написал этот код - лабораторную крысу и поднял эту волну.
Итак для читающих этот топик программистов подытожу, что лично мне в результате этой волны удалось выяснить:
Пошел исправлять свой код исходя из этой информации. Я часто злоупотреблял размером массивов.
Спасибо Всем!
как узнать нажата или отжата кнопка перекрестие?
можно отловить нажатие колесика мыши, но если мышь не используется как быть?
как узнать нажата или отжата кнопка перекрестие?
можно отловить нажатие колесика мыши, но если мышь не используется как быть?
Может при необходимости принудительно нажимать или отжимать её?
CHART_CROSSHAIR_TOOL
Включение/отключение доступа к инструменту "перекрестие" по нажатию средней клавиши мышки
bool (значение по умолчанию true)
Может при необходимости принудительно нажимать или отжимать её?
CHART_CROSSHAIR_TOOL
Включение/отключение доступа к инструменту "перекрестие" по нажатию средней клавиши мышки
bool (значение по умолчанию true)
это насколько понял лишь доступ к инструменту, но не включение выключение.