MT5 et la vitesse en action - page 71
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 suggère que c'est la fin de la théorisation, qui ne croise jamais la pratique ici.
Je vous suggère alors d'arrêter également les tests synchrones monofilaires inutiles.
S'attendre à des résultats parallèles.
Le problème n'est en aucun cas résolu. Les programmes MQL deviendront plus compliqués d'un ordre de grandeur, si les variables internes, par exemple, sont accessibles en lecture/écriture à partir de différents threads.
C'est juste que MQL6 devrait être similaire à Erlang, pas à C++ ;)
Alors je vous suggère d'arrêter aussi les tests synchrones monofilaires inutiles.
S'attendre à des résultats parallèles.
Je suis préoccupé par les décalages de grande ampleur qui se produisent presque à chaque tick. Cela n'a rien à voir avec les fils. Les développeurs sont en train de le découvrir.
C'est juste que MQL6 devrait être similaire à Erlang, pas à C++ ;)
alors Scala est meilleur.
.... mais quelle que soit la façon dont vous le regardez, derrière l'enveloppe de ces langages fonctionnels forts avec typage dynamique... il y aura toujours des machines C++, Python en est la preuve, le java discuté avec des boucles d'événements vient d'une autre galaxie où vous devez avoir un système multiprocesseur distribué pour obtenir une sorte d'expansion et d'extensibilité du système informatique.
A l'école.
- Vovochka, comment utilisez-vous le poulet en peluche ?
- Je ne sais pas.
- Sur quoi dormez-vous ?
- Sur le sol.
- Et sur quoi tu poses ta tête ?
- Sur une botte en feutre.
- Et sur quoi dorment tes parents ?
- Sur le sol.
- Et sur quoi mettent-ils leur tête ?
- Sur le valenki.
- Et sur quoi grand-mère dort-elle ?
- Sur le fourneau.
- Et sur quoi pose-t-elle sa tête ?
- Sur un oreiller.
- Et dans l'oreiller, c'est quoi le duvet ?
- Et dans l'oreiller, il y a un valenki.
Scala est meilleur alors
.... mais quelle que soit la façon dont vous le regardez, derrière l'enveloppe de ces langages fonctionnels forts avec typage dynamique... Python en est la preuve, le java discuté avec des boucles d'événements vient d'une autre galaxie où vous devez avoir un système multiprocesseur distribué pour obtenir une certaine forme d'extensibilité et d'extensibilité du système de calcul.
C'est le problème, Python est écrit en C et Python possède une bibliothèque asyncio qui est basée sur le modèle de la boucle d'événement.
Voilà pour l'anecdote de l'andain ;))
alors Scala est meilleur.
L'essentiel est de compiler en VHDL et de créer son propre serveur).
La discussion est allée quelque part sur le côté - la vitesse d'intégration avec Python est bien sûr une question importante, mais il y a beaucoup de problèmes de base qui affectent la vitesse d'exécution des EAs.
Je suggère de se concentrer sur le problème suivant : dans la fonction OnTradeTransaction, lors de l'appel final de TRADE_TRANSACTION_HISTORY_ADD, les champs des structures MqlTradeTransaction et MqlTradeResult sont presque vides, c'est-à-dire qu'ils ne sont pas remplis par analogie avec la façon dont l'ordre est reflété ultérieurement dans l'onglet Historique et la façon dont ils sont classés dans l'Aide/Documentation. La correction de ce défaut donnerait déjà une réelle accélération dans l'exécution du combat, car il ne serait pas nécessaire d'appeler inutilement HistoryOrderSelect pour obtenir des valeurs exhaustives sur l'ordre exécuté.
Et dans l'ensemble, au niveau de la communauté Mql, l'élimination de cette lacune entraînera une réduction massive de l'effort nécessaire pour créer différentes béquilles dans les conseillers experts afin de contourner les lacunes de l'implémentation actuelle de OnTradeTransactio.
La question est de savoir comment influencer l'équipe MQ ? Peut-être un post séparé avec un vote et une collecte de signatures pour l'élimination de ce défaut de cette fonction ?
La question est de savoir comment influencer l'équipe de développement de MQ.
Ma recette semble fonctionner : reproduire le problème avec un code concis.
La discussion est allée quelque part sur le côté - la vitesse d'intégration avec Python est bien sûr une question importante, mais il y a beaucoup de problèmes de base qui affectent la vitesse d'exécution des EAs.
Je suggère de se concentrer sur le problème suivant : dans la fonction OnTradeTransaction, lors de l'appel final de TRADE_TRANSACTION_HISTORY_ADD, les champs des structures MqlTradeTransaction et MqlTradeResult sont presque vides, c'est-à-dire qu'ils ne sont pas remplis par analogie avec la façon dont l'ordre est ensuite reflété dans l'onglet Historique et la façon dont ils sont classés dans l'Aide/Documentation. La correction de ce défaut permettrait déjà d'accélérer l'exécution du combat, car il ne serait plus nécessaire d'appeler inutilement HistoryOrderSelect pour obtenir des valeurs complètes sur l'ordre exécuté.
Et dans l'ensemble, au niveau de la communauté Mql, l'élimination de cette lacune entraînera une réduction massive de l'effort nécessaire pour créer différentes béquilles dans les conseillers experts afin de contourner les lacunes de l'implémentation actuelle de OnTradeTransactio.
La question est de savoir comment influencer l'équipe MQ ? Peut-être un post séparé avec un vote et une collecte de signatures pour l'élimination de ce défaut de cette fonction ?
Python est un bon exemple de modèle piloté par les événements. Et l'anecdote d'Igor est tout à fait pertinente.
Et si le développeur a saisi le sens de l'exemple, il sait alors où creuser.
Toute attente d'un résultat opportun tôt ou tard repose sur un modèle d'exécution synchrone.
En mql, c'est arrivé. Les possibilités du langage sont très riches, mais artificiellement limitées à l'exécution synchrone.
Roman:
Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом.
C'est vous qui ne comprenez pas, n'encombrez pas le fil de discussion.