Features of the mql5 language, subtleties and tricks - page 275

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
fxsaber #:
Correct and faster now.
Random.
Not random.
Magic.
We remove this line in the source (see attachment).
TimeToCalendar in AVX-compiler is very much ahead of any other implementation.
Random.
Not random.
Magic.
We remove this line in the source (see attachment).
TimeToCalendar in AVX-compiler is very much ahead of any other implementation.
AVX2 is slower ?
Is AVX2 running slower?
I don't have such a processor to test.
The source is working, you can try it.I don't have such a processor to test.
The source is working, you can try it.Comparison of the 3 compilation mode at my disposal (I don't have AVX512).
Compiler Version: 4702 AVX2 + FMA3, optimization - true
Intel Core i7-9750H @ 2.60GHz, AVX2 + FMA3
Without hours (dt.hour+ dt.min+ dt.sec - off), random datetimes[].
1970.01.01 00:01:44 - 2097.11.29 23:59:41
6.29 ns, checksum = 1269354861838493 // TimeToStruct2100
5.90 ns, checksum = 1269354861838493 // TimeToStructFast
6.49 ns, checksum = 1269354861838493 // TimeToStructFast_fxsaber
3.60 ns, checksum = 1269354861838493 // TimeToCalendar
6.47 ns, checksum = 1269354861838493 // TimeToJulian
31.65 ns, checksum = 1269354861838493 /// MQL's TimeToStruct()
Compiler Version: 4702 AVX, optimization - true
Intel Core i7-9750H @ 2.60GHz, AVX2 + FMA3
Without hours (dt.hour+ dt.min+ dt.sec - off), random datetimes[].
1970.01.01 00:00:47 - 2097.11.29 23:59:41
6.30 ns, checksum = 1286714313014774 // TimeToStruct2100
5.92 ns, checksum = 1286714313014774 // TimeToStructFast
6.40 ns, checksum = 1286714313014774 // TimeToStructFast_fxsaber
6.46 ns, checksum = 1286714313014774 // TimeToCalendar
6.11 ns, checksum = 1286714313014774 // TimeToJulian
31.89 ns, checksum = 1286714313014774 /// MQL's TimeToStruct()
Compiler Version: 4702 X64 Regular, optimization - true
Intel Core i7-9750H @ 2.60GHz, AVX2 + FMA3
Without hours (dt.hour+ dt.min+ dt.sec - off), random datetimes[].
1970.01.01 00:00:09 - 2097.11.29 23:58:42
6.13 ns, checksum = 1257992266603185 // TimeToStruct2100
5.69 ns, checksum = 1257992266603185 // TimeToStructFast
6.37 ns, checksum = 1257992266603185 // TimeToStructFast_fxsaber
6.27 ns, checksum = 1257992266603185 // TimeToCalendar
13.06 ns, checksum = 1257992266603185 // TimeToJulian
31.63 ns, checksum = 1257992266603185 /// MQL's TimeToStruct()
Comparison of the 3 compilation modes available to me (I don't have AVX512).
If interested... I apologise, I didn't clean it up.
You can see well that there is a strong dependence on compiler settings. AVX2+FMA3 significantly affects TimeToCalendar.
Apparently, there are some acceleration laws when a lot of such simple actions is more favourable than few complex expressions.
A lot of simple ones.
Forum on trading, automated trading systems and testing trading strategies.
Peculiarities of the mql5 language, subtleties and techniques of work
amrali, 2024.11.26 18:33
Few complex.
Forum on trading, automated trading systems and testing trading strategies
Peculiarities of mql5 language, subtleties and techniques of work
fxsaber, 2024.11.27 14:32
It is not clear how to understand from the code which of the bottom will be faster.
for the sake of clarity, it is necessary to compare it with the system/library functions. (there are several variants in the system, which of them is more "basic" I find it difficult to answer, those who are interested will find out).
In general, there are only 2 functions for converting time into structures: (1) the standard one from the authors of the terminal and MQL, (2) from the authors of the OS and system libraries. And almost exactly the 1st one directly or indirectly causes the 2nd one.
PS/ I will never use and advise anyone not to use their homemade "fast" analogues. All speed measurements are just a sport for the sake of competition and "whose confu is cooler" :-)
It is not clear how to understand from the code which of the bottoms will be faster.
Eh, where are the times of assembly language programming? I used to calculate speed by knowing the number of clock cycles of each instruction. I had to do it when in the 80s I wrote a driver for our laboratory audio card and a speech synthesiser for GTS.
And on the matter - if you calculate the number of mat. operations and estimate the speed of each type ( * / + - - )?
And to the point - if you count the number of mat operations and estimate the speed of each type ( * / + - - )?
I did. I didn't see any reason for such a difference.