Effacement d'un tableau d'élément(s) défini(s) - page 16
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
Je pense que c'est un bon match pour les drapeaux :
http://osinavi.ru/asm/4.php
et pour les opérateurs/comparaisons inutiles...
Je reviens à ma différence incomprise de temps d'exécution de deux boucles presque 100% identiques en logique et en nombre de contrôles et de sommes :
J'ai déjà écrit ci-dessus - j'ai moins d'opérations de comparaison dans mon code...
-----
De l'extérieur de l'école, quelque part dans les années 90 :
1) si (les conditions) A, B, C sont indépendantes, alors vous devez les faire entrer dans la fonction ET lorsque la probabilité augmente, et dans la fonction OU lorsqu'elle diminue.
et si elles sont dépendantes, elles ne doivent pas être combinées en une seule expression (c'est-à-dire do if (A && B) ).
2) S'il y a des boucles imbriquées A et B, alors la boucle extérieure doit être plus courte.
3) S'il y a une condition à l'intérieur de la boucle, vous devez diviser la boucle et prendre la condition à l'extérieur, si possible.
J'ai déjà écrit plus haut - j'ai moins d'opérations de comparaison dans mon code...
-----
à partir d'études extrascolaires, quelque part dans les années 90 :
1) si (les conditions) A, B, C sont indépendantes, alors elles doivent être placées dans la fonction ET par probabilité croissante, et dans la fonction OU par probabilité décroissante.
et si elles sont dépendantes, elles ne peuvent pas être combinées en une seule expression (c'est-à-dire do if (A && B) ).
2) S'il y a des boucles imbriquées A et B, alors la boucle extérieure doit être plus courte.
3) S'il y a une condition à l'intérieur de la boucle, vous devez diviser la boucle et prendre la condition à l'extérieur, si possible.
1) vice versa, ce qui est exactement ce que vous avez fait. Si la première condition d'un opérateur ET composé n'est pas exécutée, pourquoi devrions-nous vérifier toutes les autres conditions ? Donc, nous vérifions d'abord la condition qui est très probablement fausse.
Bien que, oui - c'est : trier par probabilité ascendante des déclarations de vérité dans une condition composée.
1) l'inverse, ce que vous avez fait. Particularités de l'exécution des opérateurs conditionnels en C.
Peut-être que je l'ai mal écrit, mais c'est plus facile à expliquer pour tout le monde en même temps...
A && B && C
ET doit être feyed dès que possible pour éviter d'essayer toutes les autres conditions. L'optimiseur ne le fera pas pour le programmeur (*), puisqu'il ne sait pas sur quelles données le programme sera exécuté.
A || B | C
ici c'est l'inverse :-) car il s'agit d'arithmétique booléenne. !( ((!A)&&(!B)&&(!C) ) (si vous ne vous trompez pas dans les parenthèses, signez à nouveau)
(*) Les compilateurs d'optimisation peuvent compter sur le fait que les conditions sont bien définies et ils construisent leur cuisine interne sur ces hypothèses.
Peut-être que je l'ai mal écrit, mais c'est plus facile pour tout le monde de comprendre d'un coup d'oeil...
A && B && C
ET devrait être feyed le plus tôt possible afin de ne pas passer par toutes les autres conditions. L'optimiseur ne le fera pas pour le programmeur (*) car il ne sait pas sur quelles données le programme sera exécuté.
A || B | C
c'est l'inverse :-) car il s'agit d'arithmétique booléenne. !( ((!A)&&(!B)&&(!C) ) (si encore entre parenthèses, les signes ne sont pas confondus)
(*) Les compilateurs d'optimisation peuvent compter sur le fait que les conditions sont bien définies et ils construisent leur cuisine interne sur ces hypothèses.
Je suis tout à fait d'accord.
Je reviens à ma différence incomprise de temps d'exécution de deux boucles presque 100% identiques en logique et en nombre de contrôles et de sommes :
Donc, encore une fois, pourquoi une telle variante du code de Kuznetsov :
fonctionne plus de deux fois plus vite que celui qui fait absolument la même chose :
Quelles sont les merveilles du compilateur ?
Est-ce vraiment possible pour un design comme celui-ci :
le compilateur trouve une commande spéciale de recherche de l'assembleur pour le processeur ? Mais il y a une vérification supplémentaire i<j à l'intérieur, n'est-ce pas ?
Parce que la même chose à travers pour est exécutée beaucoup plus lentement :
Le code du script de démonstration est joint
C'est ainsi que cela se passe souvent. Vous vous occupez de quelques déchets inutiles et vous découvrez quelque chose de plutôt intéressant.
Développeurs, pourriez-vous jeter un coup d'œil au code exécutable et voir ce qui fait cette différence ?
Vous devez comprendre la logique du compilateur afin de créer des algorithmes plus optimaux à l'avenir.
Quelle situation étrange en général. Je pense que beaucoup de choses dépendent du compilateur et de la machine sur laquelle je teste. Voici le résultat de votre exemple sur une machine 32 bits
comme vous pouvez le constater, il n'y a pas d'avantage particulier. Et voici un test des fonctions de suppression de tableau de la dernière variante.
Parfois, lors des tests, les résultats peuvent être très différents des précédents, et on ne sait pas pourquoi, peut-être cela a-t-il quelque chose à voir avec un système d'interruption spécifique dans le traitement du code MQL.
lorsqu'on teste des algorithmes, il faut prendre
* ou des ensembles de données préparés à l'avance (à peu près semblables à ceux qui sont effectivement requis),
* ou faire un nombre très important de passes sur le RNG,
dans les tests :
* alterner/rebattre la séquence d'essais et
* observer les pauses et réinitialiser toutes sortes de caches
lorsqu'on teste des algorithmes, il faut prendre
* ou des ensembles de données préparés à l'avance (à peu près semblables à ceux qui sont effectivement requis),
* ou faire un nombre très important de passes sur le RNG,
dans les tests :
* séquence d'essai alternée/mélangée et
* observer les pauses et réinitialiser toutes sortes de caches
bien, comme si nous utilisions des données préparées à l'avance. Pour toutes les fonctions, les mêmes données sont utilisées pour le test. En ce qui concerne le brassage/la mise en file d'attente, oui, j'ai remarqué une différence si vous changez l'ordre des tests. Mais comment réinitialiser les caches ?
lorsqu'on teste des algorithmes, il faut prendre
* ou des ensembles de données préparés à l'avance (à peu près semblables à ceux qui sont effectivement requis),
* ou faire un nombre très important de passes sur le RNG,
dans les tests :
* alterner/mélanger les séquences d'essais et
* observer les pauses et vider toutes sortes de caches
Ne vous moquez pas des gens