![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Il s'avère que je regardais la fréquence de génération du web, et non la fréquence de sortie.
Ce sont des nombres différents, des multiples les uns des autres.
Il s'avère que j'ai calculé la fréquence de génération du web (sans sortie) et la fréquence de sortie (sans génération) de manière un peu erronée.
Voici une version plus correcte.
Résultats sur mon processeur :
Si vous prenez le temps purement en générant une image de 200 cercles lissés sans sortie, cela se produit à environ 500 images par seconde.
former une image de 200 cercles non lissés sans sortie - environ 1000 fps.
La fréquence de la sortie de l'image (canevas) elle-même (fonction Update) est d'environ 650 images par seconde.
Vous avez vraiment travaillé dur !
Attention aux conversions massives de types (int)double ou (double)int et au mélange int+double dans les opérations mat en général.
Cela donne la surcharge la plus folle au processeur - juste une commande assembleur aussi coûteuse. Si vous comptez en double, continuez à compter en double et ne passez pas aux types entiers.
Les commandes comme cvtsi2sd/cvttsd2si sont très longues. Un petit conseil dans l'article"L'instruction x86 la plus lente", méchant numéro 2.
Merci pour cet article très utile.
Mais pour être honnête, je ne comprends pas pourquoi alors dans ce simple script :
la somme de long avec conversion du type double en long est beaucoup plus rapide que la somme de double du même tableau sans conversion
Tout d'abord, il faut regarder le code assembleur et le résultat des optimisations de cas extrêmement simples (la supermicrosynthèse est depuis longtemps trompeuse). Il est facile de se heurter à un cas idéal de mise en œuvre d'un convoyeur.
Deuxièmement, presque personne ne peut garantir comment tel ou tel code sera compilé et combien de temps il prendra pour s'exécuter.
Il suffit d'ajouter une ligne/commande supplémentaire dans le code pour que la vitesse change radicalement. Le vrai code/données pourrait bien sortir du cache L1/L2 et c'est tout.
Comment cela a-t-il fonctionné pour vous ? En théorie/super-synthetique, il semble que les commandes entières aident à la vitesse, mais dans le code réel, c'est un gouffre. Parce qu'il y a des dizaines ou des centaines de fois plus de code, pas de convectorisation, des sauts constants des calculs entiers aux calculs réels et l'optimisation est limitée.
Pourquoi l'initialisation des tableaux de tous types est-elle plus de 10 fois plus lente dans MQL4 que dans MQL5 ?
Pourquoi l'initialisation des tableaux de tous types est-elle plus de 10 fois plus lente dans MQL4 que dans MQL5 ?
Parce que tous les tableaux y sont dynamiques et que le langage est dix fois plus lent.
Un indicateur ultra-rapide de centaines de moyennes mobiles, implémenté sur Canvas.
100 lignes MA (pas de période 10) - temps de calcul et d'affichage à l'écran - 4-7 millisecondes
1000 lignes MA (période étape 1) - temps de calcul et d'affichage - 20-30 millisecondes.
Je n'ai pas trop testé le code. Il peut y avoir des bugs. Implémenté seulement pour une barre d'un pixel d'épaisseur (elle est forcée à cette échelle). Le taux de rafraîchissement de l'écran n'est pas non plus optimisé. Toutes les lignes sont calculées et entièrement sorties à chaque tick.
Un indicateur ultra-rapide de centaines de moyennes mobiles, implémenté sur Canvas.
100 lignes MA (pas de période 10) - temps de calcul et d'affichage à l'écran - 4-7 millisecondes
1000 lignes MA (étape 1 de la période) - temps de calcul et d'affichage - 20-30 millisecondes
cool, avec des indicateurs standards tout serait mort
cool, les indicateurs standards auraient accroché tout ça.
et ensuite il y aurait un kilomètre de code...
peut-être même que cela ne peut être fait qu'avec un modèle. Je ne connais pas la limitation du nombre de lignes d'indicateur dans le corps d'un indicateur.
...
Pas au courant de la limitation du nombre de lignes d'indicateur dans le corps d'un indicateur.
Il y a une limite. Il est possible de créer jusqu'à 512 tampons indicateurs >>>https://www.mql5.com/ru/docs/indicators