Ошибки, баги, вопросы - страница 1952
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Компилятор тут не помогает - проверено - локальный объект по return-у дублируется и затем прибивается. Оптимального в данном случае переноса (move) нет.
Вы тесты замеров скорости проводили? Или просто диагностируете факт создания объекта? Если второе, то естественно ничего не вырежется из кода, т.к. вы сами препятствуете этому своими проверками.
Вы тесты замеров скорости проводили? Или просто диагностируете факт создания объекта? Если второе, то естественно ничего не вырежется из кода, т.к. вы сами препятствуете этому своими проверками.
Это как? Все мои проверки заключаются только в трейсах поставленных в конструкторах и деструкторах. Если лишние копии создаются и удаляются, для меня это достаточное доказательство отсутствия оптимизации.
Вы тесты замеров скорости проводили? Или просто диагностируете факт создания объекта? Если второе, то естественно ничего не вырежется из кода, т.к. вы сами препятствуете этому своими проверками.
Ну если со строками move не происходит, то что уж говорить про более сложные объекты.
Это как? Все мои проверки заключаются только в трейсах поставленных в конструкторах и деструкторах. Если лишние копии создаются и удаляются, для меня это достаточное доказательство отсутствия оптимизации.
Сейчас в OnTesterInit можно задать диапазоны оптимизации каждого входного параметра. После чего тестер сам формирует таблицу проходов, разбивает ее на количество Агентов/Пакетов и отправляет на Агентов. Данная таблица никак не редактируется сейчас.
Но при Оптимизации на самом деле очень часто возникает ситуация, когда волнуют в первую очередь проходы, где меняется какой-то важный параметр, затем, где меняется другой и т.д. Если бы можно было сформированную таблицу проходов редактировать (менять местами элементы (наборы входных параметров)) или самому формировать, то можно было как раз задать необходимый приоритет, когда на Агентов сначала пойдут наиболее интересные проходы, а затем - менее интересные.
Поэтому предлагаю в OnTesterInit добавить возможность изменения сформированной по-умолчанию таблицы проходов:
Оптимизатор и не сможет вырезать участок, в котором стоит ваш трейс ) Вырезаться может только то, что не влияет на логику работы
Ну, тема исчерпалась ;-). Я считаю, что оптимизация в данном случае могла бы происходить только в том месте кода, где происходит возврат значения, и никоим боком не зависит от того, что понаписано в конструкторе.
C++11 standard: When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization.
Ну, тема исчерпалась ;-). Я считаю, что оптимизация в данном случае могла бы происходить только в том месте кода, где происходит возврат значения, и никоим боком не зависит от того, что понаписано в конструкторе.
В общем я вынужден с прискорбием признать, что компилятор MQL далеко не такой умный, как о нём думал ) Я бы даже сказал - совсем не умный ) Попробовал набросать простенькие примеры, и оказалось что даже если создаётся объект-пустышка, который нигде не используется и ничего не делает, то компилятору на это пофиг. Оптимизации никакой. Сужу чисто по скорости работы. Причём в новых билдах почему-то работает медленнее, чем в старых.
Вот банальный код:
В общем я вынужден с прискорбием признать, что компилятор MQL далеко не такой умный, как о нём думал ) Я бы даже сказал - совсем не умный )
А вы не думали, что он может быть заточен под оптимизацию реальных вещей, которую используют большинство, а не высосанной из пальца ахинеи?
Ну, тема исчерпалась ;-). Я считаю, что оптимизация в данном случае могла бы происходить только в том месте кода, где происходит возврат значения, и никоим боком не зависит от того, что понаписано в конструкторе.
Всего за 2 года ввели конструкторы копирования...
Следующие на очередь ждем RVO (return value optimization) и NRVO (named return value optimization)...
А вы не думали, что он может быть заточен под оптимизацию реальных вещей, которую используют большинство, а не высосанной из пальца ахинеи?