Ошибки, баги, вопросы - страница 1952

Новый комментарий
 
Stanislav Korotky:

Компилятор тут не помогает - проверено - локальный объект по return-у дублируется и затем прибивается. Оптимального в данном случае переноса (move) нет.


Вы тесты замеров скорости проводили?  Или просто диагностируете факт создания объекта?  Если второе, то естественно ничего не вырежется из кода, т.к. вы сами препятствуете этому своими проверками.

 
Alexey Navoykov:


Вы тесты замеров скорости проводили?  Или просто диагностируете факт создания объекта?  Если второе, то естественно ничего не вырежется из кода, т.к. вы сами препятствуете этому своими проверками.

Это как? Все мои проверки заключаются только в трейсах поставленных в конструкторах и деструкторах. Если лишние копии создаются и удаляются, для меня это достаточное доказательство отсутствия оптимизации.

 
Alexey Navoykov:


Вы тесты замеров скорости проводили?  Или просто диагностируете факт создания объекта?  Если второе, то естественно ничего не вырежется из кода, т.к. вы сами препятствуете этому своими проверками.

Ну если со строками move не происходит, то что уж говорить про более сложные объекты.

 
Stanislav Korotky:

Это как? Все мои проверки заключаются только в трейсах поставленных в конструкторах и деструкторах. Если лишние копии создаются и удаляются, для меня это достаточное доказательство отсутствия оптимизации.

Оптимизатор и не сможет вырезать участок, в котором стоит ваш трейс )  Вырезаться может только то, что не влияет на логику работы
 

Сейчас в OnTesterInit можно задать диапазоны оптимизации каждого входного параметра. После чего тестер сам формирует таблицу проходов, разбивает ее на количество Агентов/Пакетов и отправляет на Агентов. Данная таблица никак не редактируется сейчас.

Но при Оптимизации на самом деле очень часто возникает ситуация, когда волнуют в первую очередь проходы, где меняется какой-то важный параметр, затем, где меняется другой и т.д. Если бы можно было сформированную таблицу проходов редактировать (менять местами элементы (наборы входных параметров)) или самому формировать, то можно было как раз задать необходимый приоритет, когда на Агентов сначала пойдут наиболее интересные проходы, а затем - менее интересные.


Поэтому предлагаю в OnTesterInit добавить возможность изменения сформированной по-умолчанию таблицы проходов:

long PassesTotal(); // количество проходов в таблице для Оптимизации

// Получает список входных параметров соответствующего прохода
int PassesGet( const int Index,  MqlParam& Parameters[] );


// Прописывает список входных параметров для соответствующего прохода,
// если индекс не меньше размера таблицы, то идет дозапись в конец таблицы и размер ее увеличивается на единицу
int PassesSet( const int Index, const MqlParam& Parameters[] );
 
Alexey Navoykov:
Оптимизатор и не сможет вырезать участок, в котором стоит ваш трейс )  Вырезаться может только то, что не влияет на логику работы

Ну, тема исчерпалась ;-). Я считаю, что оптимизация в данном случае могла бы происходить только в том месте кода, где происходит возврат значения, и никоим боком не зависит от того, что понаписано в конструкторе.

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.

 
Stanislav Korotky:

Ну, тема исчерпалась ;-). Я считаю, что оптимизация в данном случае могла бы происходить только в том месте кода, где происходит возврат значения, и никоим боком не зависит от того, что понаписано в конструкторе.

В общем я вынужден с прискорбием признать, что компилятор MQL далеко не такой умный, как о нём думал )  Я бы даже сказал - совсем не умный )  Попробовал набросать простенькие примеры, и оказалось что даже если создаётся объект-пустышка, который  нигде не используется и ничего не делает, то компилятору на это пофиг. Оптимизации никакой.  Сужу чисто по скорости работы.  Причём в новых билдах почему-то работает медленнее, чем в старых.

Вот банальный код:

class A { };

void OnStart()
  {
    uint starttick= GetTickCount();
    for (int i=0; i<1e8; i++)
    { 
      A a;
    }
    Print(GetTickCount()-starttick," ms");
  }
 
Alexey Navoykov:

В общем я вынужден с прискорбием признать, что компилятор MQL далеко не такой умный, как о нём думал )  Я бы даже сказал - совсем не умный ) 


А вы не думали, что он может быть заточен под оптимизацию реальных вещей, которую используют большинство, а не высосанной из пальца ахинеи?

 
Stanislav Korotky:

Ну, тема исчерпалась ;-). Я считаю, что оптимизация в данном случае могла бы происходить только в том месте кода, где происходит возврат значения, и никоим боком не зависит от того, что понаписано в конструкторе.


Всего за 2 года ввели конструкторы копирования...
Следующие на очередь ждем RVO (return value optimization) и NRVO (named return value optimization)...

 
Sergey Dzyublik:

А вы не думали, что он может быть заточен под оптимизацию реальных вещей, которую используют большинство, а не высосанной из пальца ахинеи?

что такое "реальные вещи, которую используют большинство" ?
1...194519461947194819491950195119521953195419551956195719581959...3521
Новый комментарий
Причина обращения: