Encore une fois, à propos du multithreading - page 3
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
Je vous recommande de relire votre message original, de prêter attention à toutes vos épithètes, puis d'aller voir les réponses ci-dessous.
Les réponses ont été données calmement, avec quelques questions douces comme "Pour paralléliser les calculs de quelque chose, il faut d'abord se rendre compte", puis les réponses ont été données et l'état actuel des choses a été expliqué "ce qui devrait vraiment être parallélisé".
Mais au lieu d'une courbe d'apprentissage rapide, vous avez craché plus d'absurdités et mis les chiens sur nous. Le résultat a été une réponse sévère.
OK, je suis d'accord avec les épithètes, j'ai un peu exagéré, et je m'en excuse. Je n'ai rien dit de grossier, juste une critique trop émotive, mais elle est totalement inadéquate par rapport à la dureté avec laquelle vous y réagissez. Je n'ai dit nulle part que les développeurs sont inutiles et ne comprennent rien, alors n'exagérez pas.
Depuis que j'ai abordé ce sujet, je sais bien à quoi il sert et il y a beaucoup de choses à paralléliser. Tous les algorithmes ne se limitent pas à "hello world !", il en existe de bien plus complexes et gourmands en ressources. C'est pourquoi il est très étrange d'entendre de tels enseignements moraux sur ce qu'il faut paralléliser et ce qu'il ne faut pas, alors que vous n'avez même pas vu l'algorithme.
Quant à la mise en œuvre du code dans la DLL ainsi qu'à l'utilisation d'OpenCL, elle n'a aucun rapport avec MQL. Et la question portait sur la programmation en MQL.
OpenCL fonctionne dans le code MQL5.
Voici un exemple de code.
Quant à l'implémentation du code dans la DLL, ainsi que l'utilisation d'OpenCL, cela n'est plus pertinent pour MQL. Et nous parlions de la programmation en MQL.
Et quelle a été votre réponse ? Vous avez commencé à me dire que vous aviez un terminal et un testeur formidables, travaillant dans de multiples flux. Et je n'ai pas dit un mot sur votre terminal. Je voulais parler d'une autre chose : le multithreading dans le code MQL. Lorsqu'un algorithme peut être divisé en plusieurs parties, et que chaque partie est exécutée en parallèle. Et vous, n'ayant même pas compris le sujet, vous commencez à être grossier. Eh bien, comme je le vois, avec cette approche il n'y a pas d'approche constructive, donc il n'y a pas de raison de continuer la discussion.
Il existe des solutions constructives, même dans l'état actuel des choses. Plusieurs programmes mql (Expert Advisors et/ou indicateurs) peuvent échanger des messages et, par conséquent, des tâches et des résultats de l'exécution des tâches - bien sûr, si vous créez et arrangez un protocole d'échange approprié. Tous les conseillers-experts travaillent dans des threads différents (chacun dans son propre thread), par conséquent, ce schéma de calculs conjoints est évidemment multithread et les chargera de manière assez égale avec plusieurs cœurs.
Un échange de messages (à l'aide des outils mql5) est possible par le biais de
1. les événements terminaux
2. les canaux nommés
3. DLL
4. fichiers
5. etc.
Parmi cet ensemble d'outils, vous pouvez choisir celui qui convient le mieux ou en utiliser plusieurs (tous en même temps). Chaque méthode a ses avantages et ses inconvénients. Par exemple, les tuyaux nommés vous permettent de transférer des informations sur le réseau local, d'où la possibilité de paralléliser une tâche pour plus d'un processeur multicœur.
Bonne chance.
OpenCL fonctionne dans le code MQL5.
Voici un exemple de code.
Eh bien, le fait que ça marche est la moitié de la bataille. Mais comment l'éditer et le déboguer ensuite ? S'il est contenu dans une constante de type chaîne, comment rechercher une erreur ? Cela signifie qu'il doit être développé dans un programme externe et ensuite inséré dans MQL. Mais si vous vous occupez constamment de ce genre de portage, vous allez devenir fou, comme je l'ai souligné dans le premier message. Puisque le développement du code est fait ailleurs de toute façon, quel est l'intérêt de tout mettre dans MQL ? Il est plus facile de compiler comme une DLL et de l'importer.
Bien sûr, je comprends que le but est de créer un code source ouvert, sans utiliser de dlls auto-écrits. Mais il s'agit de cas particuliers. En général, le programme est écrit pour vous-même et non pour les autres. Et peu de gens voudraient être constamment engagés dans des manipulations sans intérêt pour faire glisser le code d'un programme à l'autre.
Mais si vous faites un compilateur intégré pour tout cela, c'est une autre histoire. Et d'ailleurs, pourquoi pas ? Je veux dire, c'est comme une syntaxe C là-dedans. C'est-à-dire que vous pourriez utiliser tout cela comme une partie du code mql normal, en ajoutant simplement des fonctions supplémentaires à votre MetaEditor. Le compilateur mettrait alors en forme le fragment de code correspondant de manière appropriée, en ajoutant des \r\n, etc.
Eh bien, le fait que ça marche est la moitié de la bataille. Comment l'éditer et le déboguer ensuite ? Si c'est dans la constante de la chaîne, comment trouver l'erreur ? Cela signifie qu'il doit être développé dans un programme externe et ensuite inséré dans MQL. Mais si vous vous occupez constamment de ce genre de portage, vous allez devenir fou, comme je l'ai souligné dans le premier message. Puisque le développement du code est fait ailleurs de toute façon, quel est l'intérêt de tout mettre dans MQL ? Il est plus facile de compiler comme une DLL et de l'importer.
Bien sûr, je comprends que le but est de créer un code source ouvert, sans utiliser de dlls auto-écrits. Mais il s'agit de cas particuliers. En général, le programme est écrit pour vous-même et non pour les autres. Et peu de gens voudraient être constamment engagés dans des manipulations sans intérêt pour faire glisser le code d'un programme à l'autre.
Mais si vous faites un compilateur intégré pour tout cela, c'est une autre histoire. Et d'ailleurs, pourquoi pas ? Je veux dire, c'est comme une syntaxe C là-dedans. C'est-à-dire que vous pourriez utiliser tout cela comme une partie du code mql normal, en ajoutant simplement des fonctions supplémentaires à votre MetaEditor. Le compilateur mettrait alors en forme le fragment de code correspondant de manière appropriée, en ajoutant des \r\n, etc.
Celui qui le veut, cherche des opportunités. Qui ne veut pas, raisonne © Proverbe
Il existe des solutions constructives même avec le statu quo. Plusieurs programmes mql (experts et/ou indicateurs) peuvent échanger des messages, et par conséquent, des tâches et des résultats de tâches - bien sûr, si vous créez et arrangez un protocole d'échange approprié. Tous les conseillers-experts travaillent dans des threads différents (chacun dans son propre thread), par conséquent, ce schéma de calculs conjoints est évidemment multithread et les chargera de manière assez égale avec plusieurs cœurs.
Un échange de messages(à l'aide des outils mql5) est possible par le biais de
1. les événements terminaux
2. les canaux nommés
3. DLL.
4. fichiers
5. etc.
Parmi cet ensemble d'outils, vous pouvez choisir celui qui convient le mieux ou en utiliser plusieurs (tous en même temps). Chaque méthode a ses avantages et ses inconvénients. Par exemple, les tuyaux nommés vous permettent de transférer des informations sur le réseau local, d'où la possibilité de paralléliser la tâche pour plus d'un processeur multicœur.
Bonne chance.
Disons qu'ils ne sont pas tous des outils mql5 :) Et il ne s'agissait pas de savoir comment résoudre (contourner) ce problème. On peut toujours trouver un moyen de le contourner, c'est certain. La question est de savoir pourquoi nous ne pouvons pas ajouter la fonctionnalité correspondante à mql5, afin de ne pas avoir à nous en débarrasser.
Vous devez admettre qu'il n'est pas rationnel et fiable de lancer un grand nombre d'Expert Advisors avec des graphiques appropriés juste pour organiser leur traitement dans plusieurs threads.
Qui veut, cherche des possibilités. Qui ne veut pas, les raisons © Proverbe
Tout d'abord, nous devons comprendre la faisabilité :) Je veux parler du bien-fondé de l'utilisation de MQL5 en général, et de MT5, respectivement, si cela vaut la peine de passer à cette plateforme. Si, comme dans MT4, pour fonctionner correctement, vous devez utiliser de la magie, exécuter plusieurs EA ou transférer le code dans une DLL, alors cela n'a aucun sens de changer une merde pour une merde. Si le code doit être écrit en DLL, il est alors plus facile et plus sûr d'utiliser une plateforme avec une API ouverte, que d'avoir un rembourrage supplémentaire sous la forme d'un conseiller expert (et d'un terminal en fonctionnement dans son ensemble).
Tout d'abord, nous devons comprendre la faisabilité :) Je veux parler du bien-fondé de l'utilisation de MQL5 en général, et de MT5, respectivement, si cela vaut la peine de passer à cette plateforme. Si, comme dans MT4, pour fonctionner correctement, vous devez utiliser des astuces, lancer plusieurs conseillers experts ou transférer le code dans une DLL, alors il est inutile de remplacer une merde par une autre merde. Si le code doit être écrit en DLL, il est alors plus facile et plus sûr d'utiliser immédiatement une plateforme avec une API ouverte, que d'avoir un rembourrage supplémentaire sous la forme d'un conseiller expert (et d'un terminal en fonctionnement dans son ensemble).
Personne n'oblige quiconque à passer à MQL5. Par exemple, les fonctionnalités de MQL4 me manquaient, j'ai donc dû passer à MQL5.
Par exemple, toutes les fonctionnalités peuvent être implémentées en С++ et MQL5 ne devrait contenir que la partie exécutive et le tout devrait être lié à un protocole utilisant des canaux nommés. Il existe de nombreuses variantes. Tout ce dont vous avez besoin, c'est d'une forte volonté.