Question pour les développeurs - utilisation de tous les cœurs de calcul pendant l'optimisation - page 6
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
Ce n'est pas la bonne approche. Au lieu de donner les tâches une par une, vous devez redistribuer la capacité si vous avez des ressources libres, c'est-à-dire annuler les tâches déjà données et les donner à d'autres pour qu'ils les exécutent. En même temps, il est nécessaire d'analyser les performances de chaque agent afin de donner au noyau le bon nombre de nouveaux emplois.
c'est un non-sens, désolé
> Vous devez annuler les travaux existants et les renvoyer au noyau pour que d'autres puissent les exécuter.
Je pense que ce n'est pas réaliste, et pourquoi, alors qu'il est plus facile de créer un lot de travaux, de donner un travail au premier thread disponible, d'attendre qu'il soit exécuté, de donner le travail suivant au premier thread disponible (j'attire l'attention sur le mot thread, pas le processeur central, la restriction sur les threads devrait être supprimée - ce n'est pas le droit des programmeurs, mais les droits de l'utilisateur, rappelez-vous que maintenant les threads du réseau sont seulement le vrai noyau, pas les threads, ce qui diminue artificiellement les performances de moitié)
>, il est nécessaire d'analyser les performances de chaque agent afin de donner au noyau le nombre requis de nouveaux travaux à exécuter.
et ce n'est pas du tout nécessaire, parce que les cœurs du même processeur avec la même performance, selon les tâches, comptent avec une vitesse différente, il n'y a pas besoin de compter quelque chose quand on ne peut rien compter du tout
c'est des conneries, je suis désolé.
> annuler les tâches qui ont déjà été émises et les renvoyer à d'autres pour qu'elles soient exécutées
Je pense que ce n'est pas réaliste, et pourquoi pas, il est plus facile de créer un lot de travaux, de donner un travail au premier thread disponible, d'attendre qu'il soit exécuté, de donner le travail suivant au premier thread disponible (notez le mot thread, pas le processeur central, la restriction sur les threads devrait être supprimée - ce n'est pas le droit des programmeurs, mais de l'utilisateur, rappelez-vous que maintenant les threads réseau ne sont que de vrais cœurs, pas des threads, ce qui diminue artificiellement les performances de moitié)
>, il est nécessaire d'analyser les performances de chaque agent afin de donner au noyau le nombre requis de nouveaux travaux à exécuter.
et vous n'en avez pas besoin parce que les cœurs d'un processeur avec la même performance selon les tâches comptent avec une vitesse différente, pourquoi devriez-vous compter quelque chose là, quand vous pouvez ne rien compter du tout ?
Vous semblez avoir peu d'expérience avec l'optimiseur et ne comprenez pas que l'information sur les passages terminés arrive tardivement, qu'après qu'un travail soit fait l'agent envoie une trame, qui peut être très lourde, tout cela va entraîner des retards dans la communication et ralentir l'optimisation. Il convient donc d'attribuer les missions par lots et de suivre leur évolution - en attribuant de nouvelles missions aux agents qui sont sur le point de terminer leur travail.
Vous semblez avoir peu d'expérience avec l'optimiseur, et ne comprenez pas que les informations sur les passages terminés arrivent tardivement, qu'une fois un travail terminé, un agent envoie une trame, qui peut être très lourde, tout cela entraîne des retards de communication et ralentit l'optimisation. Par conséquent, les tâches doivent être émises par lots et il convient de suivre l'avancement des tâches - en émettant de nouvelles tâches aux agents qui sont sur le point de terminer le travail.
>Il semble que vous ayez peu d'expérience avec Optimizer,
Vous plaisantez ? 6 ans sans interruption
>L'information sur les passes terminées arrive tardivement, qu'après avoir terminé un travail un agent envoie une trame, qui peut être très lourde, tout cela va entraîner des retards de communication et ralentir l'optimisation. Il convient donc d'attribuer les missions par lots et de suivre leur évolution - en attribuant de nouvelles missions aux agents qui sont sur le point de terminer leur travail.
>, ce qui entraînera des retards de communication et ralentira l'optimisation.
et ça n'a pas d'importance, les réseaux sont rapides maintenant.
mais le fait d'avoir des cœurs inactifs pendant qu'un pauvre cœur termine un groupe de travaux ralentit l'optimisation parce que tous les autres (des dizaines de cœurs) restent inactifs et les cœurs doivent continuer à compter sans s'arrêter.
il semble que vous n'avez jamais optimisé pour un grand nombre de paramètres ... et n'argumentez pas que vous n'avez pas d'expérience pratique
>Il semble que vous ayez peu d'expérience avec l'optimiseur,
Vous plaisantez ? 6 ans sans interruption
>L'information sur les passages terminés arrive tardivement, qu'après qu'un travail soit fait l'agent envoie une trame qui peut être très lourde, tout ceci va conduire à des retards de communication et ralentir l'optimisation. Il convient donc d'attribuer les missions par lots et de suivre leur évolution - en attribuant de nouvelles missions aux agents qui sont sur le point de terminer leur travail.
>, ce qui entraînera des retards de communication et ralentira l'optimisation.
et ça n'a pas d'importance, les réseaux sont rapides maintenant.
mais le fait d'avoir des cœurs inactifs pendant qu'un pauvre cœur termine un groupe de travaux ralentit l'optimisation parce que tous les autres (des dizaines de cœurs) restent inactifs et les cœurs doivent continuer à compter sans s'arrêter.
il semble que vous n'avez jamais optimisé pour un grand nombre de paramètres ... et ne prétendez pas que vous n'avez aucune expérience pratique ...
Vous ne pouvez pas être un égocentrique, les réseaux sont rapides, quel égocentrisme. Au contraire, les réseaux ne sont pas rapides lorsqu'il s'agit de dizaines et de centaines de mégaoctets.
L'optimisation primitive de l'EA n'est pas tout ce qu'elle est censée être - élargissez vos horizons et utilisez le calcul mathématique.
Oui, et gardez à l'esprit qu'il s'agit avant tout d'un projet à but lucratif, pas pour le plaisir des utilisateurs, et qu'à ce titre, le mécanisme doit tenir compte de la distribution aléatoire des tâches et de la comptabilisation financière correcte de leur exécution...
Vous ne pouvez pas être un égocentrique, les réseaux sont rapides, quel égocentrisme. Au contraire, les réseaux ne sont pas rapides lorsqu'il s'agit de dizaines et de centaines de mégaoctets.
L'optimisation primitive de l'EA n'est pas tout ce qu'elle est censée être - élargissez vos horizons et utilisez le calcul mathématique.
Oh, et gardez à l'esprit qu'il s'agit avant tout d'un projet à but lucratif, et non de faire plaisir aux utilisateurs, et qu'en tant que tel, le mécanisme doit tenir compte de la distribution aléatoire des emplois et de la comptabilité financière correcte de leurs performances...
des dizaines et des centaines de mégaoctets, ce n'est rien, le temps passé est minime et d'ailleurs cela n'a rien à voir avec cela, vous devriez réfléchir avant d'écrire que dans un lot que de toute façon un par un ce trafic devra passer
> L'optimisationprimitivede l'EA ne sert pas qu'à ça - élargissez vos horizons et utilisez les calculs mathématiques.
Je vous souhaite la même chose pour les horizons
Sur l'égoïsme, aussi.
Je ne suis pas primitif, et à quoi cela sert-il, alors éclairez-nous, ignorants.
Je trouve votre initiative complètement absurde en termes de consommation de temps et de vitesse d'optimisation.
Vous ne regardez que votre cas particulier d'optimisation, tandis qu'Alexey regarde le sien (son EA fait plusieurs centaines de Mo et prend beaucoup de temps à transférer).
Et MQ regarde l'utilisation globale de l'optimiseur et l'ajuste pour qu'il convienne à la plupart, pas à vous et Alexey.
Les tâches sont redistribuées, du moins pour moi sur les cœurs locaux. Si quelque part ils ne sont pas redistribués, donnez-moi un exemple à reproduire, pour que les développeurs puissent en tenir compte également.
Vous ne regardez que votre cas particulier d'optimisation, tandis qu'Alexey regarde le sien (son EA fait plusieurs centaines de Mo et prend beaucoup de temps à transférer).
Et MQ regarde l'utilisation globale de l'optimiseur et l'ajuste pour qu'il convienne à la plupart, pas à vous et Alexey.
Les tâches sont redistribuées, du moins pour moi sur les cœurs locaux. Si quelque part ils ne sont pas redistribués, donnez-moi un exemple à reproduire, pour que les développeurs puissent en tenir compte également.
Je reconnais que mon cas est particulier.
Il y a un problème d'allocation des tâches si de nouveaux agents distants sont connectés - cela se produit lorsque des ressources sont libérées d'autres tâches.
Vous ne regardez que votre cas particulier d'optimisation, tandis qu'Alexey regarde le sien (son EA fait plusieurs centaines de Mo et prend beaucoup de temps à transférer).
Et MQ regarde l'utilisation globale de l'optimiseur et l'ajuste pour qu'il convienne à la plupart, pas à vous et Alexey.
Les tâches sont redistribuées, du moins pour moi sur les cœurs locaux. Si quelque part ils ne sont pas redistribués, donnez-moi un exemple à reproduire, pour que les développeurs puissent en tenir compte aussi.
>peut-être que j'en ai un privé aussi, mais vraiment "probablement"
>donner un exemple à reproduire pour que les développeurs puissent aussi en tenir compte.
pas vraiment... je ne peux pas afficher mon EA, je ne suis pas intéressé par les standards, je peux faire des captures d'écran pour montrer qu'ils ne sont pas redistribués
Si elles étaient redistribuées, ce serait une solution au problème.
.... temps de calcul triplé est-ce qu'ils arriveront un jour à faire fonctionner l'optimiseur correctement ???? beaucoup de cœurs libres sont inactifs ...
le deuxième jour il ne compte rien, tous les cœurs au nombre de 12 locaux et environ 30 cœurs réseau sont inactifs, je ne le touche pas exprès.... Je ne sais pas à quoi il pense, probablement à la recherche du sens de la vie ou d'un remède contre le coronovirus :-)
Je pense que nous devrions abandonner l'optimiseur en raison de son inopérabilité et de sa lenteur.
et les récentes décisions de MT de ne limiter que les cœurs physiques, de distribuer de manière persistante et stupide un ensemble de travaux à certains cœurs seulement au lieu de chaque cœur - un travail - démontre un manque total de compréhension des calculs de haute performance de la part des développeurs.