Erreurs, bugs, questions - page 2162
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
Si le modèle de fonction contient
EnumToString() ;
Les problèmes surgissent...
Un exemple s'impose.
J'ai fait une surcharge, dont un motif...
pour que je puisse séparer les mouches des escalopes...
J'ai fait une surcharge, dont un motif...
pour que je puisse séparer les mouches des escalopes...
Optimisation des mathématiques : essayer d'utiliser des tableaux au lieu de sqrt.
Ainsi, prendre un élément par indice dans un tableau simple devrait être une opération très rapide, n'est-ce pas ?
Ainsi, prendre un élément par indice d'un simple tableau devrait être une opération très rapide, n'est-ce pas ?
Où voyez-vous un tableau simple ?
C'est un tableau dynamique d'un langage géré avec toutes les implications de contrôle. Et sqrt est une seule instruction native du CPU.
Bienvenue dans le monde des découvertes étonnantes d'optimisations et de l'influence d'une masse de facteurs dans chaque cas, dans chaque génération de CPU, dans chaque différence de taille de cache, dans le multitâche, dans les pénalités, etc.
Il y a seulement 20 ans, je bricolais du code assembleur sur un processeur 486, me débattant avec des vitesses qui variaient de plusieurs dizaines de pour cent en raison du réarrangement des instructions, de l'alignement et du simple positionnement de la mémoire. Cela semblait fou, mais les manuels d'Intel et Vtune ont ensuite expliqué le tableau.
Mais aujourd'hui, la situation des résultats d'optimisation est devenue incontrôlable depuis longtemps. Il y a tellement de processeurs différents avec des caches différents sur le marché que votre code est garanti de s'exécuter à des vitesses différentes. Les caches des processeurs et l'architecture des processeurs ont un impact énorme. Même le contrôle dynamique de la fréquence du processeur doit être désactivé pour éliminer des dizaines de pour cent de différence dans un benchmark.
Par exemple : les atomes avec des manques de cache apparemment sur une architecture décente ou des modèles U étranglés montrent souvent des résultats plusieurs fois inférieurs même sur des cas simples. Plus de ratés dans le cache et au revoir.
Je connais les mouches, j'ai vu les escalopes, mais le problème n'est pas visible sans le code de fonction.
Où voyez-vous un tableau simple ?
Ce n'est pas le bon cas pour établir la complexité. Les tableaux sont utilisés partout, dans les indicateurs ils sont la partie principale du calcul, et vous admettez maintenant presque directement que votre implémentation des tableaux est lente.
Je pense que vous êtes bien meilleur en matière d'optimisation, mais du point de vue d'un utilisateur commun, cela semble étrange - vous déclarez que le compilateur MQL génère un code comparable à celui du C++, mais il s'avère soudainement que les tableaux dans MQL ne sont pas rapides du tout.Ce n'est pas le bon cas pour fixer la complexité. Les tableaux sont utilisés partout, dans les indicateurs ils sont la partie principale du calcul, et vous admettez maintenant presque directement que votre implémentation des tableaux est lente.
Par rapport à une commande assembleur unique directe ?
Oui, c'est vrai. Ne savez-vous pas que les processeurs intègrent depuis longtemps des tableaux pré-calculés de diverses fonctions mathématiques ? Et les commandes mathématiques coûteuses du processeur les utilisent pour accélérer les choses.
Nous ferons une analyse détaillée de son exemple lundi et découvrirons la cause exacte.Par rapport à une commande assembleur unique directe ?
l'index du tableau est au mieux également réduit à une seule commande assembleur directe, donc la question reste posée
Je crois que vous êtes bien meilleur en matière d'optimisation, mais du point de vue d'un utilisateur ordinaire, cela semble étrange - vous prétendez que le compilateur MQL génère un code comparable à celui du C++, mais il s'avère ensuite que les tableaux dans MQL ne sont pas rapides du tout.Un langage géré/managé signifie clairement que les tableaux doivent être étroitement contrôlés. Sans cela, la langue ne peut être sécurisée.
Pour les tableaux statiques, le contrôle est plus simple et peut être partiellement simplifié au stade de l'optimiseur de code. Pour les réseaux dynamiques, le contrôle est plus important et il est difficile de simplifier.
Le code est généré au niveau de qualité C++, mais il y a certainement une surcharge dans les choses gérées. Les mathématiques, les boucles et tout le reste sont au niveau du C++.