Programmation asynchrone et multithread dans MQL - page 23
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
Expliquez-moi ce qui ne va pas avec Opencl. Le terminal implémente la possibilité d'écrire du code opencl, et ceci en multithreading. Je veux comprendre par moi-même quelles sont les différences entre le multithreading qui est écrit ici et cette fonctionnalité.
Il n'y a pas de cartes vidéo sur les serveurs VPS, ou alors c'est très peu rentable s'il y en a ;)
Même la plupart des utilisateurs en local, les cartes vidéo ne supportent pas opencl)).
Sans parler de la complexité d'écrire un code correct pour opencl.
Oui, il existe une option, mais pour un cercle très restreint de personnes.
Les cartes vidéo ne sont pas disponibles sur les serveurs VPS, ou très peu rentables si elles sont disponibles ;))
Même la plupart des utilisateurs sur un site local ne supportent pas opencl))
Sans parler de la complexité d'écrire un code correct pour opencl.
Option oui, il y en a une, mais pour un cercle très restreint de personnes.
Sur un processeur opencl, cela fonctionne aussi. Il suffit de sélectionner l'appareil qui exécutera le code. Il ne s'agit pas seulement de la technologie des cartes vidéo. Sur les serveurs, je sais qu'il y a des problèmes avec les cartes vidéo.
Mais je ne savais pas qu'opencl fonctionne aussi sur les CPUs. Je n'arrive toujours pas à accéder à l'article de Renat pour lire sur opencl.
J'ai lu un post sur opencl ici aussi, mais je ne peux pas obtenir tous les programmeurs sur opencl, les méthodes natives de tâches hors de la boîte semblent plus utilisables.
Alors, opencl fonctionne-t-il sur n'importe quel processeur ? Ou cela dépend-il aussi du modèle ?
Mais je ne savais pas qu'opencl fonctionne aussi sur les processeurs. Je n'arrive toujours pas à accéder à l'article de Renat pour lire sur opencl.
J'ai lu un post sur opencl ici aussi, mais vous ne pouvez pas mettre tous les programmeurs sur opencl, les méthodes standard de tâches de la boîte semblent plus utilisables.
Alors, opencl fonctionne-t-il sur n'importe quel processeur ? Ou cela dépend-il aussi du modèle ?
Il semble que oui, il devrait fonctionner sur Intel et amd, vous devez juste installer des pilotes. Je l'ai essayé sur Amd et ça a marché.
Il s'avère tout de même qu'un certain degré de dépendance dépend soit du modèle de processeur, soit des pilotes.
Cela peut ne pas convenir à tous, par exemple à ceux qui distribuent (vendent) leur travail.
Il y a des gens qui se soucient de la portabilité du programme, à mon avis c'est aussi un paramètre important.
Opencl peut-il fonctionner avec des dlls personnalisées ?
c'est-à-dire appeler de manière asynchrone les fonctions exportées par la dll ?
Si nous avions une classe interne pour travailler avec les tâches, nous pourrions appeler nos propres fonctions à partir de la dll de manière asynchrone.
En d'autres termes, la fonctionnalité ordinaire est beaucoup plus utilisable et plus accessible dans l'écriture du code.
Dommage que nous n'ayons pas entendu le chef du département des transports - quelle tâche spécifique voulez-vous mettre en œuvre le multithreading ? Dessinez un schéma fonctionnel simple de la solution proposée.
Vous vous entêtez à essayer d'intégrer une tâche MKL pour laquelle elle n'était pas prévue à l'origine. En un mot, pas du tout. Il existe des solutions prêtes à l'emploi - regardez ZeroMQ qui a une API pour presque tous les JDs. De plus, le gentil Ding Li a développé une bibliothèque pour ZeroMQ utilisant MQL4/5 avec un ensemble d'exemples. Veuillez lire le fil de discussion du forum sur ce sujet avec des exemples pratiques de code.
Pourquoi vous (l'initiateur du sujet) poussez de l'eau dans une casserole ? Ou êtes-vous également lié au marché ?
Bonne chance
Est-ce que opencl sait comment travailler avec des dlls personnalisées ?
C'est-à-dire appeler de manière asynchrone les fonctions exportées par la dll ?
Il y avait une classe interne pour travailler avec les tâches, vous pouviez appeler vos fonctions à partir de la dll de manière asynchrone également.
En d'autres termes, la fonctionnalité ordinaire est beaucoup plus utilisable et plus accessible dans l'écriture du code.
Appelez la fonction DLL. Vous créez un thread dans la DLL et lui transférez des données, puis vous déconnectez le thread et l'oubliez - il se terminera de lui-même après avoir accompli sa tâche. Lorsque vous déconnectez le thread dans la DLL, le thread du terminal est libéré. L'ensemble du processus prend, je crois, moins d'une milliseconde. A en juger par le fait que même sans déconnecter le thread, le processus d'écriture dans la base de données est de 4-5 ms. Eh bien, et 60 ticks/min est suffisant pour ne pas être triste à propos de l'appel asynchrone à partir du terminal.
Dommage que nous n'ayons pas entendu le chef du département des transports - quelle tâche spécifique voulez-vous mettre en œuvre le multithreading ? Dessinez un schéma fonctionnel simple de la solution proposée.
Vous vous entêtez à essayer d'intégrer une tâche MKL pour laquelle elle n'était pas prévue à l'origine. En un mot, pas du tout. Il existe des solutions prêtes à l'emploi - regardez ZeroMQ qui a une API pour presque tous les JDs. De plus, le gentil Ding Li a développé une bibliothèque pour ZeroMQ utilisant MQL4/5 avec un ensemble d'exemples. Veuillez lire le fil de discussion du forum sur ce sujet avec des exemples de code pratiques.
Pourquoi vous (l'initiateur du sujet) poussez de l'eau dans une casserole ? Ou êtes-vous également lié au marché ?
Bonne chance
J'essaie de ne pas utiliser de solutions tierces.
J'ai déjà trouvé une solution à mon problème de réseau ; il ne reste plus qu'à l'étudier, à l'appliquer et à ne pas me casser la tête.
Mais il y a ici des programmeurs qui ont également besoin d'appels non bloquants et d'asynchronie.
C'est pourquoi j'ai suggéré de mettre en œuvre cette fonctionnalité dans la livraison standard de la langue. Et c'est aux développeurs de décider, l'essentiel étant l'idée, et elle est sensée.
Pourquoi pensez-vous que le terminal n'est pas conçu pour implémenter EventLoop ? Surtout depuis le début...
Quel algorithme est utilisé pour exécuter les agents locaux ? Probablement dans un pool de fils, non ? Qui les gère, distribue les tâches ?
Ainsi, le terminal dispose déjà d'un tel algorithme, pourquoi ne pas l'utiliser pour étendre ses fonctionnalités ?
Donner aux programmeurs un mode asynchrone d'écriture du code.
Je suis pour l'idée, si personne n'en a besoin de manière asynchrone, eh bien que puis-je dire, je regrette seulement que beaucoup soient coincés dans un seul fil.
Appelez la fonction DLL. Vous créez un thread dans la DLL et lui transférez des données, puis vous déconnectez le thread et l'oubliez - il se terminera de lui-même après avoir accompli sa tâche. Lorsque vous déconnectez le thread dans la DLL, le thread du terminal est libéré. L'ensemble du processus prend, je crois, moins d'une milliseconde. A en juger par le fait que même sans déconnecter le thread, le processus d'écriture dans la base de données est de 4-5 ms. Eh bien, 60 ticks/s est suffisant pour ne pas être triste de l'appel asynchrone depuis le terminal.
Ici, merci pour une autre idée, je peux écrire la dll selon les articles locaux, mais malheureusement ils ne décrivent pas la procédure de point d'entrée, l'initialisation, l'allocation de mémoire, la création de thread, etc.
Je ne trouve aucune littérature sur ce sujet, je ne trouve pas comment gérer le point d'entrée correctement. Si vous disposez d'informations à ce sujet, veuillez me les communiquer.
Ou si vous pouvez m'apprendre, je serai heureux d'accepter la connaissance.
Je n'ai pas étudié en tant que programmeur, tout ce que j'ai appris moi-même, donc, ne me donnez pas de coups de pied dans le dos ;))
Expliquez-moi ce qui ne va pas avec Opencl. Le terminal implémente la possibilité d'écrire du code opencl, et ceci en multithreading. Je veux comprendre par moi-même quelles sont les différences entre le multithreading qui est écrit ici et cette fonctionnalité.