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

New comment
 
fxsaber #:

You can remove this restriction by adding eras.

There is no point. The probability of MQL life in 2100 is zero
 
fxsaber #:

Added this one. x64.

I have a different picture on a newer stone.

2024.05.02 01:26:08.576 TestDate3 (EURUSD,M1)   1 - 28.50 ns, контрольная сумма = 231124680107  // TimeToStruct
2024.05.02 01:26:09.897 TestDate3 (EURUSD,M1)   2 - 13.21 ns, контрольная сумма = 231124680107  // amrali
2024.05.02 01:26:10.721 TestDate3 (EURUSD,M1)   2 - 8.25 ns, контрольная сумма = 231124680107  // TimeToStruct2100
2024.05.02 01:26:11.549 TestDate3 (EURUSD,M1)   2 - 8.28 ns, контрольная сумма = 231124680107  // TimeToStruct2100 fxsaber
2024.05.02 01:26:18.906 TestDate3 (EURUSD,M1)   1 - 28.03 ns, контрольная сумма = 231123677979  // TimeToStruct
2024.05.02 01:26:20.204 TestDate3 (EURUSD,M1)   2 - 12.98 ns, контрольная сумма = 231123677979  // amrali
2024.05.02 01:26:20.992 TestDate3 (EURUSD,M1)   2 - 7.88 ns, контрольная сумма = 231123677979  // TimeToStruct2100
2024.05.02 01:26:21.799 TestDate3 (EURUSD,M1)   2 - 8.07 ns, контрольная сумма = 231123677979  // TimeToStruct2100 fxsaber
2024.05.02 01:26:27.976 TestDate3 (EURUSD,M1)   1 - 32.04 ns, контрольная сумма = 231120182713  // TimeToStruct
2024.05.02 01:26:29.306 TestDate3 (EURUSD,M1)   2 - 13.30 ns, контрольная сумма = 231120182713  // amrali
2024.05.02 01:26:30.081 TestDate3 (EURUSD,M1)   2 - 7.74 ns, контрольная сумма = 231120182713  // TimeToStruct2100
2024.05.02 01:26:30.914 TestDate3 (EURUSD,M1)   2 - 8.33 ns, контрольная сумма = 231120182713  // TimeToStruct2100 fxsaber

In addition, I have it implemented via static variables, which should slow down the random time test and speed up a lot on an ordered input time stream.


Files:
TestDate3.mq5  16 kb
 
Nikolai Semko #:

I'm getting a different picture on a newer stone.

Then a question to the developers, why do you have to create stone-dependent code for optimal performance?

 
fxsaber #:

Then a question to the developers, why do you have to create stone-dependent code for optimal performance?

read this article
https://habr.com/ru/amp/publications/811151/

Кто реально угрожает C++ (нет, Rust, не ты) / Habr
  • habr.com
Привет! Меня зовут Александр Каленюк, и я крепко подсел на C++. Пишу на C++ 18 лет кряду, и все эти годы отчаянно пытаюсь избавиться от этой разрушительной зависимости. Всё началось в конце 2005 года, когда мне довелось писать движок для симуляции 3D-пространства. В этом движке было буквально всё, чем язык C++ мог похвастаться в 2005 году...
 
Nikolai Semko #:
The probability of MQL's life in 2100 is zero

Why?

 
Nikolai Semko #:

Read this article
https://habr.com/ru/amp/publications/811151/

Thanks. But still the article demonstrates performance differences for very different hardware.

Here Intel stones are also different.

 
fxsaber #:

Thank you. But still the article demonstrates performance differences for very different hardware.

Intel stones are different here.

Intel stones separated in time can be quite different hardware. The same code can be executed by quite different logic inside a processor. The instruction system of any manufacturer has its evolution too
 
Nikolai Semko #:

I've pieced together various methods that have appeared here before.

To compare speeds of the proposed methods (the standard one is not interesting) it makes sense to do only such a checksum. 
uint mm =dt.year+ dt.mon+ dt.day/*+ dt.hour+ dt.min+ dt.sec+ dt.day_of_week+ dt.day_of_year*/;
DayOfYear - I have no idea what it's for. Intraday time (and day of the week) - elementary always. But the first three summands are the main difficulty, that's why their implementations are worth comparing. As well as the reverse functionality.
 
fxsaber #:
For comparison of speeds of the proposed methods (the standard method is not interesting) it makes sense to do only such a checksum.
DayOfYear - I have no idea what it is for. Intraday time (and day of the week) - elementary always. But the first three summands are the main difficulty, that's why their implementations are worth comparing. So is the inverse functionality.

Then it's enough 

uint mm =dt.day;

you still need month and year to calculate the day

2024.05.02 23:28:38.923 TestDate3 (EURUSD,M20)  1 - 22.48 ns, контрольная сумма = 1572958884  // TimeToStruct
2024.05.02 23:28:39.497 TestDate3 (EURUSD,M20)  2 - 5.75 ns, контрольная сумма = 1572958884  // amrali
2024.05.02 23:28:39.874 TestDate3 (EURUSD,M20)  3 - 3.76 ns, контрольная сумма = 1572958884  // TimeToStruct2100
2024.05.02 23:28:40.354 TestDate3 (EURUSD,M20)  4 - 4.81 ns, контрольная сумма = 1572958884  // TimeToStruct2100 fxsaber
2024.05.02 23:28:45.598 TestDate3 (EURUSD,M20)  1 - 22.50 ns, контрольная сумма = 1573013128  // TimeToStruct
2024.05.02 23:28:46.168 TestDate3 (EURUSD,M20)  2 - 5.70 ns, контрольная сумма = 1573013128  // amrali
2024.05.02 23:28:46.554 TestDate3 (EURUSD,M20)  3 - 3.86 ns, контрольная сумма = 1573013128  // TimeToStruct2100
2024.05.02 23:28:47.065 TestDate3 (EURUSD,M20)  4 - 5.11 ns, контрольная сумма = 1573013128  // TimeToStruct2100 fxsaber
 
fxsaber #:
For comparison of speeds of the proposed methods (the standard method is not interesting) it makes sense to do only such a checksum. DayOfYear - I have no idea what it is for. Intraday time (and day of the week) - elementary always. But the first three summands are the main difficulty, that's why their implementations are worth comparing. As well as the reverse functionality.

Programmer's Day

1...253254255256257258259260261262263264265266267...299
New comment