Errors, bugs, questions - page 1952

New comment
 
Stanislav Korotky:

Compiler does not help here - tested - local object by return is duplicated and then nailed. There is no optimal move in this case.


Did you perform speed tests? Or just diagnosing of object creation? If it's the second, then of course nothing will be removed from the code, because you yourself prevent this with your checks.

 
Alexey Navoykov:


Did you carry out speed tests? Or are you just diagnosing the fact of object creation? If it's the latter, of course nothing will be cut out of the code since you yourself prevent it through your checks.

How's that? All my checks consist only of traces set in constructors and destructors. If extra copies are created and deleted, that's proof enough for me that there's no optimization.

 
Alexey Navoykov:


Have you performed speed measurement tests? Or just diagnosing the fact of object creation? If the second, then of course nothing will be cut out of the code, because you yourself prevent this with your checks.

Well, if you can't move lines, you can't move more complex objects.

 
Stanislav Korotky:

How's that? All my checks consist only of traces set in constructors and destructors. If extra copies are created and deleted, that to me is sufficient proof of the lack of optimization.

The optimizer can't rip out a fragment containing your trace.) Only things that don't affect your logic can be clipped.
 

Now in OnTesterInit you can set optimization ranges for each input parameter. The tester then generates a pass table by itself, splits it into the number of Agents/Packages and sends it to the Agents. This table is not editable in any way now.

But during Optimisation it is actually very common to be concerned first of all with passages where some important parameter changes, then where another changes, etc. If it were possible to edit a generated table of passes (to change places of elements (sets of input parameters)) or to generate it oneself, it would be possible to set the necessary priority, when the most interesting passes would go to Agents first, and then - less interesting passes.


Therefore I propose to add to OnTesterInit the possibility of changing the default table of passes:

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

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


// Прописывает список входных параметров для соответствующего прохода,
// если индекс не меньше размера таблицы, то идет дозапись в конец таблицы и размер ее увеличивается на единицу
int PassesSet( const int Index, const MqlParam& Parameters[] );
 
Alexey Navoykov:
The optimizer will not be able to cut the section with your trace in it ) The only thing that can be cut out is the one that doesn't interfere with your logic.

Well, the topic is over ;-). I think the optimization in this case could happen only in that code place where the return of value occurs, and in no way depends on what's written in the constructor.

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:

Well, the topic is over ;-). In my opinion, the optimization in this case could only take place in that place of code where the return of value takes place, and it doesn't depend in any way on what's written in the constructor.

Anyway, I must regretfully admit that the MQL compiler is far from being as clever as I thought it was ) I would even say it's not smart at all. ) I tried to make some simple examples and it turned out that even if I create a dummy object, that isn't used anywhere and doesn't do anything, the compiler doesn't care about it. It's not optimized at all. I'm judging by the speed alone. And for some reason it works slower in new builds than in old ones.

Here is a trivial code:

class A { };

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

Well, I have to unfortunately admit, that MQL compiler is not so smart, as I thought it was ) I'd even say it's not smart at all.)


Have you ever thought that it could be tuned to optimize the real things that most people use, rather than the nonsense that was just made out of thin air?

 
Stanislav Korotky:

Well, the topic is over ;-). In my opinion, the optimization in this case could only take place in that place of code where the return of value takes place, and in no way depends on what is written in the constructor.


It's only in 2 years that copy constructors were introduced.
Next in line are RVO (return value optimization) and NRVO (named return value optimization)...

 
Sergey Dzyublik:

Have you considered that it might be sharpened to optimise the real things that most people use, rather than the bullshit they're making out of thin air?

what is "the real stuff most people use" ?
1...194519461947194819491950195119521953195419551956195719581959...3189
New comment
Reason: