Encore une fois, à propos du multithreading - page 4
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
Eh bien, disons que tout ce que vous avez énuméré ne concerne pas les outils mql5 :) Et la question n'était pas de savoir comment résoudre (contourner) cette question. On peut toujours trouver un moyen de le contourner, c'est certain. La question est de savoir pourquoi nous n'avons pas voulu ajouter la fonctionnalité nécessaire à mql5 sans aucun détail.
MQL5 a tout ce dont nous avons besoin, nous devons juste apprendre à l'utiliser.
Transférez une partie des calculs vers l'indicateur et exécutez-le depuis un conseiller expert.
Et personne ne fera le parallélisme de base pour deux douzaines d'utilisateurs (en étant optimiste).
Il existe des scripts pour le multithreading. Et vous n'en avez pas besoin dans le testeur.
Comment exécuter un script à partir d'un Expert Advisor ?
Transférez certains des calculs à l'indicateur, et exécutez-le depuis le Conseiller Expert.
C'est reparti pour la danse du tambourin. Je parlais d'une mise en œuvre normale.
Et personne ne fera le parallélisme habituel pour deux douzaines d'utilisateurs (en étant optimiste).
Il m'a semblé dès le début que MQL5 se positionne comme un langage pour les programmeurs plus ou moins qualifiés, contrairement à mql4. Cela signifie que l'optimisation de l'algorithme, sa mise en parallèle sur plusieurs threads, doit être une nécessité quotidienne. C'est pourquoi j'ai attiré votre attention sur ce point au début du sujet. Et Renat, pour une raison quelconque, y a réagi très douloureusement.
Résoudre constamment le problème de l'optimisation par le biais d'un seul endroit, comme le suggèrent de nombreuses personnes ici, n'est pas du tout ce que l'on souhaite faire.
D'ailleurs, j'ai déjà dit au tout début que je ne leur demandais pas de faire du parallélisme normal. Je suis parfaitement capable de tout mettre en parallèle moi-même, en utilisant WinApi. Tout ce dont j'ai besoin, c'est d'une adresse de fonction. C'est pourquoi j'ai demandé d'ajouter uniquement les pointeurs vers les fonctions. Bien sûr, il est souhaitable de supporter la directive __stdcall, mais ce n'est pas nécessaire, vous pouvez faire les manipulations nécessaires par vous-même.
Les pointeurs vers les fonctions sont en fait une chose très utile. Les utiliser pour créer des fils n'est qu'une des nombreuses utilisations possibles. Ils sont également utilisés, par exemple, pour spécifier des fonctions de rappel dans diverses opérations asynchrones. Ils seront également transférés de manière archi-utile dans la DLL, ce qui simplifie la communication entre la DLL et l'Expert Advisor qui l'a importé, c'est-à-dire une intégration complète. Au moment de l'exécution, la DLL peut appeler directement la fonction MQL et obtenir de celle-ci certaines informations nécessaires. Maintenant, pour le faire, nous devons générer un événement (par exemple, un tick), qui appellera un Expert Advisor et passera ensuite les informations requises à la DLL... En somme, des tracas supplémentaires et une perte de temps.
- L'ajout du multithreading au langage implique la création d'une API spéciale qui prend en charge le multithreading,
- Il faut réécrire l'optimiseur du compilateur MQL5 - en fait, cela aggrave les optimisations.
- C'est un endroit pour les bogues d'utilisateur difficiles à trouver.
Enfin, peu d'utilisateurs en ont besoin et l'absence de support peut être contournée.qui à son tour fonctionnera plus lentement que les API sans ce support, j'espère que c'est clair (loki, etc.).
À propos des pointeurs vers les fonctions.
La question est ouverte en ce qui concerne leur utilisation dans le code MQL5.
Malheureusement, nous ne serons pas en mesure de passer le pointeur à la DLL - nous avons dû sacrifier l'accord d'appel pour la crossplatform x86/x64.
En ce qui concerne le multithreading.
L'homme ne fait que troller (je croyais que le langage était...) pour un raisonnement théorique et ne comprend ni la nature appliquée du langage ni les conséquences du multithreading.
En fait, il n'a même pas de véritable tâche de parallélisme.
mql5:
...Ну и последнее, нужно это не очень малому числу пользователей и отсутствие поддержки можно обойти.
J'aime l'idée d'utiliser des scripts, mais comment les appeler depuis l'EA ?
J'aime l'idée d'utiliser des scripts, mais comment les appeler depuis l'EA ?
Mais il existe un moyen, par le biais d'un modèle de graphique, si vous écrivez un script dans celui-ci au lieu du conseiller expert.
Lorsqu'on applique un tel modèle à un nouveau graphique, le script est lancé (cependant, il s'agit d'une "fonctionnalité non documentée", qui pourrait ne pas être disponible un jour)...
Quelle est votre tâche ?
Pourquoi ne pas avoir un conseiller expert prêt à fonctionner sur le graphique adjacent, qui fera son travail après avoir reçu un événement ?
Le lancement d'un nouveau programme MQL5 est coûteux, en raison de la protection des fichiers EX5.
Malheureusement, les scripts ne peuvent pas être lancés à partir de MQL5.
Mais il existe un moyen, par le biais d'un modèle de graphique, si nous y plaçons un script à la place du conseiller expert.
Lorsqu'on applique un tel modèle à un nouveau graphique, le script est lancé (cependant, il s'agit d'une "fonctionnalité non documentée", qui pourrait ne pas être disponible un jour)...
Quelle est votre tâche ?
Pourquoi ne pas avoir un conseiller expert prêt à fonctionner sur le graphique adjacent, qui fera son travail après avoir reçu un événement ?
Le lancement d'un nouveau programme MQL5 est coûteux, en raison de la protection des fichiers EX5.
J'ai des milliers d'objets graphiques à analyser : supprimer ceux qui sont inutiles, modifier les propriétés, calculer des caractéristiques statistiques, etc. Même sur un seul graphique, il y a des décalages, et que faire s'il y en a plusieurs ?
Le problème du travail avec des objets graphiques doit être résolu de manière algorithmique. Économique et ne mélangez pas les commandes de changement et de lecture d'objets. Par exemple, 1000 lectures et seulement 1000 écritures seront beaucoup plus rapides que 1000 lectures et écritures.
À propos du multithreading.
- L'ajout du multithreading au langage implique la création d'une API spéciale qui supporte le multithreading,
- Il faut réécrire l'optimiseur du compilateur MQL5 - en fait, cela aggrave les optimisations.
- C'est un endroit pour les bogues d'utilisateur difficiles à trouver.
Enfin, peu d'utilisateurs en ont besoin et l'absence de support peut être contournée.qui à son tour fonctionnera plus lentement que les API sans ce support, j'espère que c'est clair (loki, etc.).
À propos des pointeurs vers les fonctions.
La question est ouverte en ce qui concerne leur utilisation dans le code MQL5.
Malheureusement, le passage d'un pointeur dans une DLL ne fonctionnera pas - nous avons dû sacrifier la convention d'appel pour le crossplatform x86/x64.