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

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
Wow! The first version, consistently the best on all processors (x86/AVX/AVX2).
Just probably should make a script to test for correctness of all algorithms. It's simple, IMHO. In a date loop compare all the results of calculations with the built-in function.
BTW, AMD processors still support AVX512....
My AMD Ryzen 3 PRO 3200GE does not. I think server processors support it, but I haven't inquired.
AMD Ryzen 3 PRO 3200GE
Some very little more optimized version:
Results:
I have noticed for a long time that something strange is happening with the MQL compiler when running benchmarks,
If the number of functions to compare exceeds a certain limit ?!, then you are not getting the right results (i.e., the functions towards the end of the mq5 file gets the best results with least execution time, while the upper functions have bad results). This has happened to me before, so it's better to limit the compared functions to 3/4 maximum. If anybody has an explanation for this strange phenomenon, please enlight me.
This happened here too, when Dominic's version was added to the benchmark script file.
To get a more clear view,I simply kept only the two functions in the source code, and here are my results head-to-head:
The same performance and both managed to get below 5 nanoseconds.
I have noticed something strange has been happening with the MQL compiler when running benchmarks for a long time now,
If the number of functions to compare exceeds a certain limit ?!, then you are not getting the right results (i.e., the functions towards the end of the mq5 file gets the best results with least execution time, while the upper functions have bad results). This has happened to me before, so it's better to limit the compared functions to 3/4 maximum. If anybody has an explanation for this strange phenomenon, please enlight me.
This happened here too, when Dominic's version was added to the benchmark script file.
To get a more clear view,I simply kept only the two functions in the source code, and here are my results head-to-head:
The same performance and both managed to get below 5 nanoseconds.
yes exactly, we ran into the same issue when testing radix sort. The problem still exists.
I don't know if it is a problem with compiler's applied optimizations, or the processor is ramping its clock up (warm-up, turbo boost or whatever..).
yes exactly, we ran into the same issue when testing radix sort. The problem still exists.
I don't know if it is a problem with compiler's applied optimizations, or the processor is ramping its clock up (warm-up, turbo boost or whatever..).
Here is a version with a minimal memory footprint, but for some reason I am unable to replace the const uint t with a variable from the structure. - If I do so, I get an "array out of range" error. - Any idea?
EDIT:
Yes, it is a bit strange, though, I have issues replicating it... - Same story as back then, I had the issue, but nobody else could replicate it.
Results of attached file:
Here is a version with a minimal memory footprint, but for some reason I am unable to replace the const uint t with a variable from the structure. - If I do so, I get an "array out of range" error. - Any idea?
Here it is (maybe for a digital clock with limited memory):
after year 2038, the seconds counter (unix timestamp) will reach INT_MAX, so you must keep using uint type for seconds (to avoid negative no).
Note that fields of MqlDateTime are ints, so you have to cast the re-used field. Casting to the same no. of bits or more (widening cast) does not change the bits. It only changes interpretation of the sign bit (2's complement).
Here it is (maybe for a digital clock with limited memory):
after year 2038, the seconds counter (unix timestamp) will reach INT_MAX, so you must keep using uint type for seconds (to avoid negative no).
Note that fields of MqlDateTime are ints, so you have to cast the re-used field. Casting to the same no. of bits or more (widening cast) does not change the bits. It only changes interpretation of the sign bit (2's complement).