Question pour les développeurs - utilisation de tous les cœurs de calcul pendant l'optimisation - page 8
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
Une approche intéressante.
Il pourrait y avoir plusieurs solutions à ce problème selon les spécificités.
Si tous les paramètres, ceux qui existent déjà et ceux qui peuvent apparaître, ont une place strictement définie dans l'ensemble des paramètres (chromosome ou autre équivalent), alors il n'y a aucun problème.
S'il n'est pas possible de définir à l'avance l'emplacement de chaque paramètre, il est nécessaire de diviser les paramètres en types qui ne peuvent être combinés qu'entre eux (l'emplacement d'un paramètre n'a alors aucune importance) - il faut modifier l'AO.
Il existe d'autres moyens de résoudre le problème, mais dans tous les cas, vous aurez besoin d'un AO personnalisé, une superstructure par-dessus le standard.
surcharge confirmée de la mémoire .... Bien qu'étrange, personne n'a annulé le swap, une fois de plus, je pense que les développeurs doivent prendre cela en considération.
Vous devriez nous faire savoir comment le problème est résolu. Nous sommes inquiets pour vous, n'est-ce pas ?
De combien de mémoire minimale avez-vous besoin par agent (avez-vous réduit le nombre d'agents activés jusqu'à ce qu'ils soient tous chargés de manière égale?)
Augmenté la pagefile ? La mémoire physique sera constamment échangée, elle peut ralentir considérablement, vous devez trouver un nombre de cœurs où le temps d'optimisation total est minimal.
Vous devriez nous faire savoir comment le problème est résolu. Nous sommes inquiets pour vous, n'est-ce pas ?
De combien de mémoire minimale avez-vous besoin par agent (avez-vous réduit le nombre d'agents activés jusqu'à ce qu'ils soient tous chargés de manière égale ?)
Augmenté la pagefile ? La mémoire physique sera constamment échangée, il pourrait y avoir de graves ralentissements, nous devons trouver un nombre de cœurs où le temps total d'optimisation est minimal.
Tout dépend de l'utilisation des tics, de la profondeur de l'historique, du nombre d'outils. Il suffit de regarder dans le gestionnaire des tâches, vous y verrez tout, la quantité de toute la RAM moins 1 à 2 Go pour le système d'exploitation divisée par la quantité utilisée par un agent. C'est différent pour chacun.
Une réelle amélioration peut être apportée par les développeurs si une seule zone de RAM est utilisée pour les cotations et éventuellement pour les indicateurs.Tout dépend de l'utilisation des tics, de la profondeur de l'historique, du nombre d'outils. Il suffit de regarder le gestionnaire des tâches pour voir la taille totale de la RAM moins 1 à 2 Go pour le système d'exploitation, divisée par la taille utilisée par un agent. C'est différent pour chacun.
Les développeurs peuvent vraiment améliorer la situation, si une zone de RAM est utilisée pour les cotations et, peut-être, pour les indicateurs.Vous me l'expliquez ? J'expliquais le problème à un homme, et maintenant je suis intéressé par le résultat. Il n'y a pas de retour d'information.
Et nous avons déjà discuté à plusieurs reprises de l'utilisation inefficace de la mémoire par le terminal, et MQ a plusieurs fois promis de changer la situation avec la duplication de l'historique des tics et des fichiers temporaires pour chaque agent, et leur longue création avant chaque optimisation des tics. Personnellement, j'ai dû désactiver près de la moitié des agents et cocher les optimisations sur un certain nombre d'années. J'ai 8 Go et 8 agents. Mais pour l'instant, nous utilisons ce que nous avons, et nous pouvons soit augmenter la taille de la mémoire, soit désactiver les agents.
Vous me l'expliquez ? J'ai expliqué le problème à l'homme, et maintenant je m'interroge sur le résultat. Il n'y a pas de retour d'information.
Et l'utilisation inefficace de la mémoire par le terminal, nous en avons déjà parlé à plusieurs reprises, et MQ a plusieurs fois promis de changer la situation avec la duplication de l'historique des tics et des fichiers temporaires pour chaque agent, et leur longue création avant chaque optimisation des tics. Personnellement, j'ai dû désactiver près de la moitié des agents et des optimisations de coche sur plusieurs années. J'ai 8 Go et 8 agents. Mais pour l'instant, nous utilisons ce que nous avons, et nous pouvons soit augmenter la taille de la mémoire, soit désactiver les agents.
>, il vous suffit de nous faire savoir comment le problème est résolu. Nous sommes inquiets pour vous.
>J'ai expliqué le problème à l'homme, et maintenant je suis intéressé par le résultat. Aucun retour d'information.
Je suis désolé, je travaillais, je n'avais pas le temps.
J'ai optimisé l'EA. J'ai supprimé certaines parties "sans importance" afin de faire fonctionner l'optimiseur (plus précisément, tout ce qui concerne OpenCL et SQLite). Je n'ai pas de débordement de mémoire maintenant. MAIS ... ce n'est pas une solution, bien sûr.
Sur un autre ordinateur, j'ai dû désactiver certains des cœurs juste pour éviter le gel ... Ainsi, par exemple, le système sur un 3950X (16 cœurs/32 threads) et 32 Go, lorsqu'il utilise tous les threads, se bloque et tout. De plus, il se bloque sur les agents et reste bloqué jusqu'à ce que vous tuiez manuellement le processus via le gestionnaire de tâches ..... J'ai désactivé certains des cœurs, le calcul a continué. Je pense que les développeurs devraient faire quelque chose pour rendre le problème explicite. Si l'optimiseur a besoin de plus de dix gigas de mémoire pour ses calculs, cela doit être clairement écrit dans une sorte d'alerte. Je vais cependant vous rappeler une fois de plus l'échange. J'ai installé Xmeters ... Ainsi, je peux voir visuellement la charge de la mémoire directement dans la barre des tâches.
Je pense qu'il y a un autre problème lié spécifiquement au CPU d'amdc et qu'il n'était pas là avant - bien que l'EA soit la même. Les symptômes sont les suivants - seulement 5 cœurs .... et l'erreur de calcul pend... Et ce n'est pas exactement la mémoire, c'est-à-dire que le même Expert Advisor force 16 threads sans problème, et le problème est flottant, de temps en temps il ne l'est pas. Si j'exécute le test sans l'optimiseur, il fonctionne bien. Je l'ai remarqué plus d'une fois. Je dois donc vérifier.
Concernant les freins sur les agents du réseau, je n'y arrive toujours pas. Le principe "un noyau - un travail" dépasse l'entendement des développeurs. Comme précédemment, 10 cœurs recevront chacun 30 tâches et 30 autres agents de réseau seront inactifs. Il faut beaucoup de temps pour distribuer les tâches en pensant à quelque chose. Donc, dans l'ensemble, il y a beaucoup de décalage.
Et oui, j'ai oublié : merci beaucoup à tous pour votre participation, votre aide et vos conseils.àRenat Fatkhullin
Je souhaite néanmoins aborder à nouveau le sujet et poser une question spécifiqueà Renat Fatkhullin.
1. Je suis en train d'optimiser une ferme locale composée de plusieurs serveurs aux performances très différentes et j'ai constaté des retards vraiment terribles pendant l'optimisation, causés par des CPU aux performances différentes. Supposons qu'il existe des serveurs équipés de CPU Xeon E5-2620 v2 (2.1 GHz), Xeon E5-2620 0 (2.00 GHz), i7-3820 (3.6 GHz), Xeon E3-1245 (3.7 GHz), Ryzen 7 2700, Ryzen 9 3900X, Ryzen 9 3950X. L'algorithme actuel fonctionne de la manière suivante : il forme une pile de tâches, divise cette pile de tâches de manière égale pour chaque cœur disponible. En raison des processeurs Xeon E5-2620 0 (2,00 GHz) et Xeon E5-2620 v2 (2,1 GHz) à faible vitesse, la ferme était inactive et comptait ses tâches, mais ces deux processeurs n'en comptaient même pas la moitié. Ainsi, la ferme entière reste inactive. Cela se produit et continuera de se produire parce que les CPU ont des vitesses différentes et tant que les tâches seront distribuées par paquets. L'expérience montre que la latence du réseau n'a aucune importance et est négligeable. Est-il déjà possible de retravailler l'algorithme de distribution des tâches : ne pas distribuer plusieurs tâches à chaque cœur disponible, mais"donner à chaque cœur libéré une tâche de la pile de génération actuelle" ?
2. Est-il possible d'ajouter la sauvegarde des résultats des tests dans un fichier xml toutes les 10 minutes .... et l'exécution à partir de la dernière sauvegarde ?
Nous avons entrepris une réécriture complète du testeur et de l'optimiseur.
Nous allons procéder à une refonte radicale et régler les problèmes accumulés.
Nous avons entrepris une réécriture complète du testeur et de l'optimiseur.
Nous allons procéder à une refonte radicale et régler les problèmes accumulés.
Il y en aura :
1. réponse plus rapide à l'abandon de l'agent, où, par exemple, s'il n'y a pas de retrait de l'agent, la livraison des paquets est interrompue pendant quelques minutes et les paquets sont redistribués.
Sera-t-il possible de télécharger en une seule fois les données de tous les agents sur une machine distante?
3. le problème du transfert de grandes quantités de données, lorsque la connexion avec un agent est interrompue, n'aura-t-il pas téléchargé toutes les données (fichiers) nécessaires à l'optimisation ?
Il y a une autre chose qui me dérange .....
disons que l'optimisation est en cours et qu'à ce moment-là le metatrader de l'agent est mis à jour .... l'agent a un travail (ou plutôt un lot de travaux), sera-t-il perdu ou recalculé ?