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
Au niveau actuel des processeurs, vous pouvez oublier les freins de la double mathématique. Il n'y a pas de décalage.
Et les méthodes d'optimisation par conversion en nombre entier sont déjà vraiment dépassées. Vous perdrez beaucoup plus sur la conversion que vous ne gagnerez sur les mathématiques.
En tenant compte du code 64 bits et de notre compilateur, vous devriez oublier les entiers dans la classe des tâches basées sur les calculs doubles.
Voici un échantillon précédent des tentatives d'optimisation de Nikolaï : https://www.mql5.com/ru/forum/1111/page2164#comment_6796332.
Le compilateur a réussi à combiner les calculs de deux racines doubles de 64 bits provenant d'expressions différentes en une seule commande assembleur de 128 bits. Lorsque vous travaillez avec des mathématiques doubles, il est fortement déconseillé de sauter/convertir vers des types entiers. Il y a des surcharges sauvages de CPU sur la conversion (pas la nôtre).
Vous n'avez pas à arrondir quoi que ce soit.
Voici un script à titre d'exemple.
Exécutez-le d'abord avec les paramètres par défaut (avec des cercles anticrénelés et des coordonnées et dimensions de type double)
et ensuite l'exécuter avec le paramètre typ = not_smoothed_circles (avec des cercles non lissés et des coordonnées et tailles de type int - de la classe CCanvas).
Ça a bien marché.
J'ai obtenu 347 fps sans antialiasing et 97 avec antialiasing sur une toile de 2100x550 pixels.
Pour information, nous avons un limiteur de taux de mise à jour de la fenêtre de 500fps. Cela montre combien de performances peuvent être atteintes dans les graphiques.
Au niveau actuel des processeurs, vous pouvez oublier le freinage des doubles maths. Il n'y a pas de freins.
Et les méthodes d'optimisation par conversion en nombre entier sont déjà vraiment dépassées. Vous perdrez beaucoup plus sur la conversion que vous ne gagnerez sur les mathématiques.
En tenant compte du code 64 bits et de notre compilateur, vous devriez oublier les entiers dans la classe des tâches basées sur les calculs doubles.
Voici un échantillon précédent des tentatives d'optimisation de Nikolaï : https://www.mql5.com/ru/forum/1111/page2164#comment_6796332.
Le compilateur a réussi à combiner les calculs de deux racines doubles de 64 bits provenant d'expressions différentes en une seule commande assembleur de 128 bits. Lorsque vous travaillez avec des mathématiques doubles, il est fortement déconseillé de sauter/convertir vers des types entiers. Il y a des surcharges sauvages de CPU sur la conversion (pas la nôtre).
Je suis presque sûr que si nous faisons en sorte que les ticks soient basés sur des nombres entiers, le testeur commencera à travailler beaucoup plus rapidement.
Non, ce n'est pas un morphing. C'est un peu exagéré d'appeler ça un morphing :
En fait, j'étais trop paresseux pour en faire un vrai moi-même - je l'ai trouvé dans les dossiers d'exemples.
Morphing, littéralement - mortification.
Il est presque certain que si vous rendez les ticks entiers, le Testeur commencera à travailler beaucoup plus rapidement.
C'est clair pour le cheval, comme l'a dit Elena Yurievna.
Basé sur Doom et sur les conseils de @fxsaber.
J'ai utilisé l'algorithme dece site avec quelques légères modifications.
Qu'est-ce que tu utilises pour faire des photos, Nikolaï ?
Il est presque certain que si vous rendez les ticks entiers, le Testeur commencera à travailler beaucoup plus rapidement.
Non.
Pour commencer, sachez que :
Morphing, littéralement - la mort.
Cela ne vaut pas la peine d'en discuter ici, mais le morphing ( morphing) Où voyez-vous des personnes mortes, dégrisez...
Cela ne vaut pas la peine d'être discuté ici, mais le Morphing ( morphing- transformation) Où vous voyez des personnes mortes - dégrisez...
L'analyse morphométrique est l'analyse des cellules mortes. D'abord on les tue, puis on les met sous le microscope.
Non.
Double int est deux fois plus rapide que double