Encore une fois, à propos du multithreading - page 9
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
Dans le testeur, tout va dans un seul fil, mais dans la vie réelle, oui, cela fonctionne.
et les bénéfices sont-ils patents ou autour de la marge d'erreur ?
et les bénéfices sont-ils patents ou autour de la marge d'erreur ?
Nous prévoyons d'ajouter ThreadXXX et des fonctions d'échange pour exécuter des tâches individuelles.
Il ne s'agit pas de threads du programme principal, mais de scripts séparés (avec des gestionnaires OnStart) qui s'exécuteront indépendamment dans un mode caché similaire aux services.
Vous serez en mesure d'interroger et de gérer les listes de programmes. Au démarrage d'un "thread", son fichier ex5 sera spécifié à partir d'un fichier sur le disque ou de sa propre ressource. De cette façon, il est possible d'avoir un seul fichier ex5 qui peut facilement exécuter plusieurs threads à partir de ses ressources et échanger des données avec eux.
Les fils ne fonctionneront pas dans le testeur.Nous prévoyons d'ajouter ThreadXXX et des fonctions d'échange pour exécuter des tâches individuelles.
Il ne s'agit pas de threads du programme principal, mais de scripts distincts (avec des gestionnaires OnStart) qui s'exécutent indépendamment en mode caché, comme les services.
Il sera possible d'interroger et de gérer les listes de programmes. Lorsqu'un "thread" est lancé, son fichier ex5 sera spécifié à partir d'un fichier sur le disque ou de sa propre ressource. Ainsi, il sera possible d'avoir un seul fichier ex5 qui, à partir de ses ressources, lance facilement plusieurs threads et échange des données avec eux.
Les fils ne seront pas exécutés dans le testeur.C'est une bonne nouvelle :) .
Je n'ai pas offert un seul bon conseil sur les termes du problème... Bonne nuit à vous aussi...
C'était, mais il n'est pas un lecteur, c'est un écrivain.
mon cher, mon cher, soleil, avez-vous lu le problème ? c'est clairement décrit là - dans une boucle, beaucoup d'autres tâches doivent être faites en une seconde, par exemple fermer 500 000 ordres ou ne pas les fermer - vérifier ... 0.1 lot, 50 000 dépôt, vous êtes bon en maths ? Et oui, c'est synthétique. Mais votre conseil est sans valeur.
Zajinka, trouvez votre code de merde, et tout volera !
Ou, si la tâche était si mal formulée et que vous avez vraiment besoin d'accélérer un seul test, rien d'autre qu'OpenCL ne fera l'affaire. Mais cela n'a aucun sens, il est fort probable que l'approche était mauvaise dès le départ. Mais il ne sert à rien de deviner sans le code ou une description plus détaillée.
Pour accélérer les tests, vous pouvez lire les posts de fxsaber, il a traité ce problème de manière approfondie. Vous pouvez utiliser Virtual ou couper les tiques. Mais, encore une fois, le problème se trouve très probablement dans l'énoncé initial du problème ou dans un code sous-optimal.
pour fermer 500 000 commandes par seconde et compter une passe pendant 5 jours... Ouais.
Pardonnez-moi, messieurs les administrateurs, mais si vous voulez utiliser le HFT, vous devez payer environ 20 000 dollars pour une licence de logiciel spécial HFT.
Ou $100+k - ils le rédigeront pour vous.
pour fermer 500 000 commandes par seconde et compter une passe pendant 5 jours... Ouais.
Pardonnez-moi les administrateurs, mais si vous voulez utiliser le HFT, vous devez payer ~20K$ pour une licence de logiciel spécial HFT.
Ou 100+k$ - ils l'écriront pour vous.
Je soupçonne que les personnes qui s'intéressent au HFT achètent au moins une licence serveur en une fois.
Le terminal est une entité superflue lorsqu'on parle de fractions de secondes.
Je ne sais pas comment les threads sont disposés, mais MT5 n'utilise qu'un seul cœur de processeur, si le cœur du processeur est chargé au maximum, le terminal se bloque.
Vous ne devez pas paralléliser les threads, mais paralléliser les tâches à d'autres processeurs (cœurs).
Je ne sais pas comment les threads sont configurés, mais MT5 n'utilise qu'un seul cœur de CPU, si le cœur de CPU est chargé au maximum - le terminal se bloque.
Ce n'est pas le cas.
Seuls les indicateurs d'un outil fonctionnent dans un seul fil et il y aura un "pépin" s'ils sont lourds et qu'un noyau ne peut pas les gérer.
Vous ne devez pas paralléliser les threads mais paralléliser les tâches à d'autres processeurs (cœurs).
C'est ce que fait Windows.
Ce n'est pas le cas.
Seuls les indicateurs fonctionnent sur un seul fil par outil, et ils " bugueront " s'ils sont lourds et qu'un seul cœur ne peut y faire face.
C'est ce que fait Windows.
Windows n'a rien à voir avec cela, je sais que presque toutes les tâches peuvent être mises en parallèle sur tous les cœurs.