Obtenir le nombre de décimales de n'importe quel nombre (pas seulement les guillemets) en contournant Digits() dans MQL4 et MQL5 - page 21

 
Nikolai Semko:
Sur la route pour le moment. Vous pouvez l'essayer vous-même. L'idée est d'utiliser des unions avec des tableaux de structures de différentes tailles, par exemple 10, 100, 1000, 10000...
Cela raccourcira la boucle de plusieurs ordres de grandeur et réduira le nombre d'appels à ArrayCopy de plusieurs ordres de grandeur.
Cela devrait être proche de la variante memcopy.

Cette idée a été utilisée. Dans ce cas

Vous pouvez tout voir dans le code source.
 
fxsaber:

Cette idée a été utilisée. Ce faisant

Vous pouvez tout voir dans le livre de référence.
Oui, j'ai vérifié. C'est étrange que ça n'ait pas d'effet.
 
Nikolai Semko:
Oui, j'ai vérifié. C'est étrange que ça n'ait aucun effet.

Il y a une ligne dans la source qui contrôle la taille

#define  CONVERT_AMOUNT 128

Vous pouvez modifier cette valeur et voir le résultat. Si la valeur est supérieure à cent, la vitesse n'augmente pas. C'est en fait facile à expliquer, car le même nombre d'éléments est copié au total. Et les décalages associés aux petites portions de copie sont éliminés.

 
fxsaber:

Je crains que nous ne soyons déjà bloqués sur la performance maximale.

Oui, je suis d'accord.
Je l'ai essayé - le même résultat que dans votre TicksToIntArray_fxsaber4/IntArrayToTicks_fxsaber4

 
Andrey Khatimlianskii:

Vous avez le code source, vous pouvez le mesurer vous-même.

Alors, mesurez-la. Je suis presque sûr que non, donc je ne vois pas l'intérêt de perdre du temps sur l'article ou la mesure.

 
fxsaber:

Je crains que nous ne soyons déjà à la limite de la performance.

Pour être honnête, je suis très surpris qu'ils aient réussi à être si proches de memcpy. Ce n'est pas possible. Quelque chose ne va pas.

 
fxsaber:

Je crains que nous soyons déjà coincés avec la performance maximale.

Je crois que je comprends une très grave erreur de calcul de votre part.
Votre BANCH sélectionne un minimum de 50 séries absolument identiques.
Mais le compilateur est un gros malin et paresseux. Il ne fera pas le même travail 50 fois et optimisera le code. C'est pourquoi vous devriez au moins changer les matrices à chaque passage. Vous pouvez aussi remplacer 50 par 1 et augmenter le nombre d'essais. Les résultats seront alors bien différents et plus objectifs.

2018.12.09 13:55:43.048 StructToArray__2        https://www.mql5.com/ru/forum/287618/page18#comment_9813963
2018.12.09 13:55:43.048 StructToArray__2        TicksToIntArray_thexpert
2018.12.09 13:55:43.296 StructToArray__2        Time[TicksToIntArray(TicksIn,Array)] = 247579
2018.12.09 13:55:43.296 StructToArray__2        IntArrayToTicks_thexpert
2018.12.09 13:55:43.544 StructToArray__2        Time[IntArrayToTicks(Array,TicksOut)] = 247840
2018.12.09 13:55:43.634 StructToArray__2        true
2018.12.09 13:55:43.766 StructToArray__2        
2018.12.09 13:55:43.766 StructToArray__2        https://www.mql5.com/ru/forum/287618/page18#comment_9814108
2018.12.09 13:55:43.766 StructToArray__2        TicksToIntArray_fxsaber4
2018.12.09 13:55:44.118 StructToArray__2        Time[TicksToIntArray(TicksIn,Array)] = 351847
2018.12.09 13:55:44.118 StructToArray__2        IntArrayToTicks_fxsaber4
2018.12.09 13:55:44.452 StructToArray__2        Time[IntArrayToTicks(Array,TicksOut)] = 334011
2018.12.09 13:55:44.548 StructToArray__2        true
2018.12.09 13:55:44.692 StructToArray__2        
2018.12.09 13:55:44.692 StructToArray__2        https://www.mql5.com/ru/forum/287618/page18#comment_9814108
2018.12.09 13:55:44.692 StructToArray__2        TicksToIntArray_semko
2018.12.09 13:55:45.037 StructToArray__2        Time[TicksToIntArray(TicksIn,Array)] = 344707
2018.12.09 13:55:45.037 StructToArray__2        IntArrayToTicks_semko
2018.12.09 13:55:45.373 StructToArray__2        Time[IntArrayToTicks(Array,TicksOut)] = 336193
2018.12.09 13:55:45.462 StructToArray__2        true

Quand la différence par rapport à memcpy est de 40% c'est plus plausible

Je me demande si la compression du tableau aura un effet. Un tableau de ticks peut être compressé par un facteur de 10-12. La seule question qui se pose est de savoir si cela permettra de gagner le temps nécessaire à l'envoi et à la réception par le biais de la ressource.

Dossiers :
 
Nikolai Semko:

Je crois que je comprends une très grave erreur de calcul de votre part.
Votre BANCH sélectionne le minimum de 50 exécutions absolument identiques.
Mais le compilateur est un gros malin et paresseux. Il ne fera pas le même travail 50 fois, il optimisera le code.

Le code est écrit de manière à ce qu'il fasse exactement ce qu'il est censé faire. Le compilateur ne pourra pas affecter la vitesse de memcpy, mais les résultats de ses passages sont les suivants

Une boucle d'une passe

https://www.mql5.com/ru/forum/287618/page18#comment_9813963
TicksToIntArray_thexpert
Time[TicksToIntArray(TicksIn,Array)] = 235285
IntArrayToTicks_thexpert
Time[IntArrayToTicks(Array,TicksOut)] = 192509
true


Sur 50

https://www.mql5.com/ru/forum/287618/page18#comment_9813963
TicksToIntArray_thexpert
Time[TicksToIntArray(TicksIn,Array)] = 80970
IntArrayToTicks_thexpert
Time[IntArrayToTicks(Array,TicksOut)] = 81103
true
 
fxsaber:

Le code est écrit de manière à ce qu'il fasse exactement ce que vous voulez qu'il fasse. Le compilateur n'est pas en mesure d'affecter la vitesse de memcpy, mais les résultats des passes sont les suivants

Une boucle d'une passe.


Sur 50.

Mais alors pourquoi cela se produit-il ? Bien sûr, le compilateur ne peut pas affecter le processus d'exécution du memcpy, mais il peut refuser de l'exécuter, en tirant les résultats pré-enregistrés du premier calcul, s'il comprend qu'aucun des paramètres calculés ne change pendant la boucle. C'est ainsi que j'organiserais moi-même le compilateur pour corriger les alogismes du programme.
 
Ilya Malev:

Alors, mesurez-la. Je suis presque sûr que non, donc je ne vois pas l'intérêt de perdre du temps avec l'article ou la mesure.

Je n'ai pas à le faire.