You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
It turns out that I was looking at the web generation frequency, not the output frequency.
These are different numbers, multiples of each other.
It turns out I was calculating the web generation frequency (without output) and output frequency (without generation) a bit wrong
Here is a more correct version.
Results on my processor:
If you take the time purely by generating a frame of 200 smoothed circles without output, it happens at about 500 frames per second.
forming a frame of 200 unsmoothed circles without output - about 1000 fps.
The frequency of the image (canvas) output itself (Update function) is about 650 fps.
You have really worked hard!
Beware of mass conversions of (int)double or (double)int types and mixing int+double in mat operations in general.
This gives the wildest overhead to the processor - just such an expensive assembler command. If you count in double, keep counting in double and don't switch to integer types.
Commands like cvtsi2sd/cvttsd2si are very long. A little tip in the article"The slowest x86 instruction", villain number 2.
Thanks for a very valuable article.
But to be honest, I don't understand why then in this simple script:
the sum of long with conversion of double type to long is much faster than the sum of double of the same array without conversion
Firstly, one should look at the assembly code and the result of optimizations of extremely simple cases (supermicrosynthetics has long been misleading). It is easy to run into an ideal case of conveyor implementation.
Secondly, hardly anybody can guarantee how this or that code will compile and how long it will take to execute.
You just have to add one more line/command into the code and the speed changes drastically. The real code/data might well get out of the L1/L2 cache and that's it.
How did it work for you? In theory/super-synthetics it seems that integer commands will help in speed, but in real code it's a drain. Because there is tens/hundreds of times more code, no convectorization, constant jumping from integer to real calculations and optimization is limited.
Why is initialization of arrays of any types in MQL4 more than 10 times slower than in MQL5?
Why is initialization of arrays of any types in MQL4 more than 10 times slower than in MQL5?
Because all arrays there are dynamic and the language is ten times slower.
An ultra-fast indicator of hundreds of moving averages, implemented on Canvas.
100 lines MA (period step 10) - time of calculation and displaying on the screen - 4-7 milliseconds
1000 lines MA (period step 1) - time of calculation and displaying - 20-30 milliseconds.
I haven't tested the code too much. There may be bugs. Implemented only for one pixel thick bar (it is forced to this scale). Also screen refresh rate is not optimized. All lines are calculated and fully output at every tick.
An ultra-fast indicator of hundreds of moving averages, implemented on Canvas.
100 lines MA (period step 10) - time of calculation and displaying on the screen - 4-7 milliseconds
1000 MA lines (period step 1) - time for calculation and display - 20-30 milliseconds
cool, with standard indicators everything would be dead
cool, the standard indicators would have hung it all up.
and then there'd be a mile of code...
maybe even that can only be done with a template. I don't know about the limitation of the number of indicator lines in the body of one indicator.
...
Not aware of the limitation on the number of indicator lines in the body of one indicator.
There is a limit. Up to 512 indicator buffers can be made >>>https://www.mql5.com/ru/docs/indicators