Discussion de l'article "Accélération des calculs avec le réseau cloud MQL5"
Qu'en est-il de la génétique ? Là, "100 fois" est inaccessible. Enfin, si c'est 20-30 fois, voire moins.
Qu'en est-il de la génétique ? Là, "100 fois" est inaccessible. Si c'est 20-30 fois, ou même moins.
https://www.mql5.com/ru/forum/4927/page114
stringo 2012.02.02 15:50
Lors du calcul de l'algorithme génétique, toute la génération suivante (de 64 à 256 tâches de calcul) est donnée au nuage.
Dans une recherche complète, une pile de 512 tâches est confiée à chaque serveur en nuage. Ensuite, lorsqu'un certain nombre de tâches sont terminées, le double de tâches est ajouté (c'est-à-dire qu'un serveur en nuage signale 5 tâches terminées, il en ajoute immédiatement 10).
l'accélération de l'AG n'est donc pas de 20 à 30 fois, mais d'au moins 64 fois, voire 256 fois.
L'AG ne peut pas être plus rapide que l'énumération d'un nombre similaire de paramètres. Le goulot d'étranglement de l'AG est l'attente de l'agent le plus lent. Et cela se produit (en moyenne) de 10240 / 256 à 10240 / 64 fois (de 40 à 160 fois, sur la base des données de stringo). Et c'est l'agent le plus lent qui détermine la vitesse. En outre, dans l'article, Rosh avait 4 agents locaux propres -> la limite de vitesse pour GA peut être de 256 / 4 = 64 fois (pour parler de valeurs comparables), mais dans la vie, c'est beaucoup moins.
Comme beaucoup l'ont remarqué, les serveurs en nuage détectent automatiquement les agents lents et redistribuent les passes "ralenties" à d'autres agents (à la fois dans l'énumération complète et dans la génétique).
En outre, les agents ayant un PR>100 sont acceptés dans la génétique, ce qui réduit considérablement les conséquences de l'utilisation d'agents lents.
Les conditions de test sont les suivantes : 4 cœurs Intel Core i5-2500 à 3,3 GHz, 4 Go de RAM, Windows XP 64 bits, terminal x64 bild 581 (PR = 160-180). Pendant les tests, un navigateur était en cours d'exécution et un film était en cours de visionnage. Les mêmes conditions que dans l'article ont été utilisées (Moving Avarege Expert Advisor, H1, sur OHLC à 1 m. + génétique). Paramètres :
Test sur les noyaux locaux :
Test on Cloud :
Sans hésitation, nous constatons que Cloud a compté 8,7 fois plus vite. C'est tout. Mais en fait, le réseau est encore plus lent car le cache de calcul a été utilisé.
Les cœurs locaux ont donc effectué 8704 - 3666 = 5038 passes en 30 min. 2 sec = 1802 secondes -> 0.3577 secondes par passe en moyenne.
Le cloud a effectué 8704 - 4455 = 4249 passes en 3 min. 28 sec = 208 secondes -> le temps d'attente pour une passe de Cloud est en moyenne de 0,049 seconde.
Au total, Cloud a accéléré le calcul par un facteur de 0,3577 / 0,049 = 7,3 fois ( !).
Mon hypothèse initiale selon laquelle ce chiffre atteindrait probablement 20 fois s'est avérée un peu optimiste. Et nous ne pouvons même pas parler de centaines.
Oui, j'ai utilisé des cœurs puissants, c'est-à-dire que j'ai un peu triché. Mais il n'en reste pas moins que même ces 4249 passes avec la génétique du réseau ont été effectuées en 208 secondes et 14040 passes avec la recherche complète en 164 secondes (le temps d'attente pour une passe est de 0,0117 seconde). Au total, le test génétique d'une passe sur le Cloud est en moyenne plus lent que la force brute (en reprenant l'exemple de l'EA en question) de 0,049 / 0,0177 = 2,8 fois.
Je ne critique pas le réseau - le Cloud Network est certainement la meilleure chose qui ait été faite depuis que les logiciels de trading existent. Et c'est une chose très nécessaire (même si elle n'est pas beaucoup utilisée, mais cela viendra avec le temps).
J'aimerais que les slogans publicitaires soient plus corrects. D'accord, c'est du passé
Si vous effectuez des tests dont le temps d'une passe est inférieur à une seconde, vous devez tenir compte de la latence du réseau, qui est souvent supérieure ou égale au temps d'une tâche "rapide". Nous avons fait beaucoup d'efforts pour nous débarrasser des frais généraux du système sur la latence du réseau en regroupant les tâches. Nous y sommes parvenus, même si ce problème ne peut pas être complètement résolu.
Votre exemple montre bien que vous avez participé à une lutte à court terme avec un temps de transit dont on sait qu'il est inférieur au délai du réseau. Pour évaluer réellement la puissance de claud, il faut s'éloigner des tâches dont le temps d'exécution est inférieur à une seconde et s'orienter vers des tâches plus coûteuses.
J'ai lancé genetics avec une tâche similaire mais avec un temps de passage supérieur à 10 secondes sur un processeur i7. Je publierai les résultats dans l'heure qui suit.
Pendant 3 min. 28 secondes d'utilisation du réseau, j'ai été facturé soit 2, soit 3 centimes (3 centimes dans le terminal, 2 centimes sur le site web, et 3 centimes gelés). Soit 3, ou même pour simplifier, l'utilisation du réseau pour la génétique coûte 1 centime pour une minute. Au total, une heure coûte 60 cents, 24 heures = 14,4 $. Cela me semble très cher. Les prix devraient être réduits au moins trois fois pour les rendre attrayants pour les consommateurs (beaucoup de gens testent les EA, mais tout le monde ne peut/veut pas payer environ 15 dollars par jour pour le Cloud, et si c'était 5 dollars ou moins - il y aurait plus de gens prêts à le faire).
De plus, j'ai déjà compris comment pré-estimer le coût de l'optimisation d'un EA (en moyenne, bien sûr). Algorithme pour la génétique (de même pour la force brute) :
1) Exécuter la génétique moyenne mobile sur les cœurs locaux (+ vous pouvez aussi connecter vos agents distants) ; à la fin, calculer le temps d'attente pour un passage -> T1
2) Calculer T1 / 0,049 = T2 - combien de fois l'optimisation est accélérée par la génétique dans le nuage.
3) Exécutez l'optimisation sur les cœurs locaux (+ vous pouvez également connecter vos agents distants ; la configuration doit être identique à celle de l'étape 1) de l'EA requise et attendez, par exemple, 100 passes. Calculez le temps d'une passe (dans le journal - trouvez le premier et le dernier enregistrement) -> T3
4) 10240 * T3 / T2 = T4 -> temps de test estimé en nuage.
5) T4 / 60 = coût du test en cents.
(vous pouvez également prendre en compte vos cœurs, pour cela nous utilisons T2' = T2 + 1).
Il s'agit d'une estimation basée sur l'optimisation Moving Avarage. Peut-être que dans un mois ou deux, des cœurs plus puissants seront mis en ligne et que les chiffres changeront, ainsi que le coût.
Je pense que ma pensée est claire
Votre exemple montre bien que vous étiez en compétition dans un combat à court terme avec un temps de passage dont on sait qu'il est inférieur au délai du réseau.
Oui, je m'en doutais, mais je ne l'avais pas envisagé. Attendons vos résultats.
Et mon post précédent, para. 2 devra être corrigé après vos tests.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Un nouvel article Accélération des calculs avec le réseau cloud MQL5 a été publié :
Combien de cœurs avez-vous sur votre ordinateur personnel ? Combien d'ordinateurs pouvez-vous utiliser pour optimiser une stratégie de trading ? Nous montrons ici comment utiliser le réseau cloud MQL5 pour accélérer les calculs en recevant la puissance de calcul à travers le monde d'un simple clic de souris. L'expression « Le temps, c'est de l'argent » devient de plus en plus d'actualité d'année en année, et nous ne pouvons pas nous permettre d'attendre des calculs importants pendant des dizaines d'heures, voire des jours.
Aux fins indiquées ci-dessus, nous utilisons un ordinateur avec Intel Core i7 (8 cœurs, 3,07 GHz) et 12 Go de mémoire avec le système d'exploitation Windows 7 64 bits et MetaTrader 5 build 1075.
L'Expert Advisor Moving Average.mq5 de paquet de livraison standard avec les paramètres suivants est testé :
- Symbole : EURUSD H1
- Intervalle de test : du 2011.01.01 au 2011.10.01
- Mode simulation de prix : 1 minute OHLC (les prix Open, High, Low et Close sur les barres de 1 minute sont utilisés)
- Type d'optimisation : algorithme complet lent, au total 14 040 passes
Paramètres optimisés :Auteur : MetaQuotes