The splendour and poverty of the PLO - page 7

New comment
 

Found it! Managed to get a higher speed with the PLO after all. Yes! The benefits are undeniable.


 
dimeon:

Let's write everything in assembly language then. It would be faster anyway.

I don't understand the problem. I have never seen an Expert Advisor or indicator with 1 MB of code.

The call of any function also takes some time. Let's give up functions as well!

Control over large projects is much more convenient with OOP.

Also, code execution speed is very often not as critical as pinging time to broker and response to broker's order.

Check out the HFT algorithms. They require maximum speed, but you won't find any complex calculations there.

PS. You don't usually need a supercar or a snowmobile to get from point A to point B. A moped is enough! A moped is enough!

There is one person here who, instead of writing a function, writes code in the file and includes it.
 
Integer:

Found it! Still managed to get a higher speed with the PLO. Yes! The benefits are undeniable.

So what was the code?
 
meat:
So, what was the code?
Calling iCustom() with different number of parameters, a different case for each number of parameters, or a different class for each number of parameters in the OOP variant.
 

In the new build of the MQL compiler, we have already included the optimization of replacing a virtual method with a direct call if it is the final method in a chain of virtual methods and there are no links to external libraries.

This method will simplify and speed up virtual calls to many programs that work with classes.

The results of the test.mq4 example from the first post in the 670 build:

switch: 172
OOP:    312

The loop had to be increased from 10,000,000 to 50,000,000 in order not to work with minuscule time measurements of 32-64 ms. Time in ms is shown, the smaller number is, the faster code is.

This is what I got with the new compiler on the same code:

switch: 157
OOP:     93

OOP won with a bang. But why?

First, the virtual method was turned into a regular method, and then it was inline and optimized to zero. In fact, the function call and body disappeared completely, leaving a pure loop:

  mov     int[i] <- int[0]

$label:
                                        <- тут когда-то было тело, но оно оптимизировалось в ноль
  add     int[i] <- int[i], int[1]
  jlt     int[i], int[50000000] --> $label

The files are attached, including the new beta of the console compiler. You can compare any examples using regular 670 build of MetaEditor (the compiler is built into it) and the console compiler.


What this proves:

  1. It is the quality of the compiler optimizer that is being tested.
  2. Tests should actually be written with a full understanding of how everything is optimized
  3. As I said - showed on an existing example how it is possible to mislead (OOP suddenly won), if you don't know peculiarities of code optimization
Files:
test.mq4  9 kb
Test.ex4  7 kb
test_optimized.ex4  6 kb
mql_exe.zip  1117 kb
1234567
New comment