OpenCl et les outils correspondants. Critiques et impressions. - page 2
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
Articul, tu n'as pas besoin d'être aussi catégorique. Le monde ne s'arrête pas. Les cartes graphiques modernes et monstrueuses, selon votre logique, devraient également être reconnues comme la conséquence d'un manque d'idées dans le traitement des images ?
Parfois, je suis moi-même content d'accélérer - juste pour éviter d'attendre dans le débogage du code la fin des calculs lourds, qui sont tous dans mon code dans init() (environ 10 secondes). Et tous les autres calculs, qui ont lieu "à la volée", sont très rapides, donc je n'ai pas besoin de multithreading ici.
Je crois que ce genre de pouvoir est nécessaire pour tester certaines idées. Par exemple, il serait très intéressant d'examiner les résultats des tests à terme sur les 10 dernières années pour 32 paires de devises. Et pour bien charger la machine, construisons le système sur un petit TF. Supposons qu'il s'agisse de M15. La période d'optimisation est de 8 semaines et la période hors échantillon de 2 semaines. Cependant, cela sera plus évident au niveau du graphique :
Si l'optimisation prend 1 minute, nous passerons environ 138 heures. Le nombre d'étapes (optimisations) est de 8320. Il s'agit d'une stratégie commerciale. Et s'il s'agit d'un portefeuille ? Et s'il n'y a pas de système et que nous en cherchons un ? ))) À partir de ce moment, il devient clair qu'il n'y a jamais assez de puissance.
Je suis heureux d'accélérer moi-même parfois - juste pour éviter d'attendre des calculs lourds, qui sont tous dans mon init() (environ 10 secondes), lors du débogage du code. Et tous les autres calculs, qui ont lieu "à la volée", sont vraiment très rapides, de sorte que le multithreading n'est pas nécessaire ici.
Je crois qu'une puissance de cette ampleur est nécessaire pour tester ces idées... Le nombre d'étapes (optimisations) est de 8320.
Il est probablement possible de les calculer une fois et de les mettre en cache d'une manière ou d'une autre ?
Qu'est-ce que le "cache" appliqué à un simple MQL4 ?
Je suis juste en train de déboguer le code de l'indicateur. Lorsque j'appuie sur F5, il recompile à nouveau, mais il n'affiche des informations qu'après les calculs, dont la grande majorité sont effectués dans init().
Bien entendu, vous pouvez enregistrer le code dans un fichier et le lire à partir de celui-ci tout en le déboguant. Mais c'est un peu lourd et au mauvais endroit.
En fait, l'idée n'est pas si absurde, Alexey, la seule question est la méthode de mise en œuvre.
Après tout, même le processeur a son propre cache pour une raison, et même plus d'un).
Et comment proposez-vous de le faire - sans faire référence à un codage externe à MQL4 ?
J'ai déjà suggéré - à travers des fichiers. Mais c'est long et gênant.
Un cache implique généralement une mémoire vive pour une récupération et une modification rapides des données.
Il s'agit essentiellement d'une base de données triviale. Il est clair que cela nécessitera une capacité supplémentaire, mais les gains de performance peuvent être substantiels.
Pas nécessairement, vous pourriez par exemple utiliser le mapping déjà mis en place par Junko. Je ne parle même pas de votre tâche spécifique, mais le principe lui-même me semble tout à fait rationnel.