OpenCl et les outils correspondants. Critiques et impressions. - page 6
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 soupçonne que c'est ce que Mischek criait il y a un mois.
Je vois l'application d'OpenCL dans les tests lourds ou les calculs parallélisés très intensifs à la volée.
Jusqu'à présent, je n'en ai pas besoin (tous les calculs lourds sont dans mon init() de l'inducteur), mais cela vaut la peine d'être mentionné.
Alexey, j'ai le même problème : j'essaie de glisser quelque chose vers init, puis vers le temps réel :)
Mon cerveau est tourné vers un langage procédural. La POO est souhaitable, mais pas native.
Pour les fanatiques qui ne vont pas sur mql5.com : OpenCL : tests internes d'implémentation dans MQL5
Merci, je n'ai personnellement pas vu celui-là. Seulement, ce n'est pas si simple.
De plus, Rinat confond les gens : OpenCL 1.0 peut fonctionner correctement avec le double float, c'est une "option ouvertement disponible" supportée par tous les fabricants - MAIS PAS POUR TOUTES LES ANCIENNES MAPS.
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
"Option double précision et demi-floating point".
OpenCL 1.0 ajoute le support de la double précision et de la demi-valeur flottante comme extensions optionnelles. Le type de données double doit être conforme au format de stockage double précision IEEE-754.
Une application qui souhaite utiliser le double devra inclure la directive #pragma OPENCL EXTENSION cl_khr_fp64 : enable avant que tout type de données en double précision ne soit déclaré dans le code du noyau. Cela élargira la liste des types de données vectorielles et scalaires intégrés pour inclure les suivants : .....".
Cela peut fonctionner dans le testeur de stratégie, mais pas dans le conseiller expert OpenCL 1.0, non pas parce que, comme le dit Rinat, "il n'y a pas de double flottant", mais, comme je l'ai déjà mentionné, parce qu'il n'y a pas de threading sûr dans OpenCL 1.0 et qu'il n'y a pas de threading dans MT4-5.
OpenCL (et CUDA) est déroutant en général. Que voulez-vous ? Après tout, les ingénieurs du fer et de la radio ont entrepris de changer le concept de la programmation. Ils ont un état d'esprit de fer.
Il y aura également un problème avec la soi-disant "SÉLECTION DE PLATE-FORME" : le programme, c'est-à-dire MT ou DLL ou Expert Advisor, DOIT, juste DOIT choisir la plate-forme (AMD, Nvidia, Intel), qui peut être plusieurs différentes qui exécuteront le connecteur OpenCL, et ensuite sélectionner manuellement DEVICE si votre ordinateur fonctionne en Multi-GPU. L'auto-sélection de la plate-forme dans OpenCL n'existe pas encore. Rinat parle de "sélectionner automatiquement le plus puissant" mais je ne sais pas comment cela se passe. Dans l'exemple présenté ici, il n'y a pas de sélection de plate-forme ni de sélection de périphérique (GPU, CPU).
En outre, la norme ne prévoit pas encore de parallélisation automatique des tâches OpenCL sur plusieurs GPU ou sur GPU+CPU. Disons-le ainsi : dans certaines versions de ses pilotes/SDK, AMD a effectué une telle autoparallélisation mais a rencontré quelques problèmes et a désactivé cette fonction pour le moment.
En résumé, le développement et l'activation de programmes OpenCL pour MT4-5 nécessitent un effort manuel et ne fonctionneront donc pas automatiquement ou par "recompilation avec option". Ce qui, à son tour, est susceptible de provoquer de nombreux blocages dans le monde réel. Ce sera un travail subtil et, ce qui est important, je me permets de le répéter, c'est malheureusement la PROGRAMMATION ORIENTÉE PAR LES JUIFS, qui est mauvaise. Le débogage des programmes parallèles pour CUDA ou OpenCL s'est avéré beaucoup plus difficile que ne le supposaient les révolutionnaires du fer. Nvidia a même annulé sa conférence CUDA de l'automne 2011 - en raison de problèmes de pilotes et de nombreuses plaintes concernant le blocage du débogage. Ils ont donc ajouté 1000 nouvelles fonctionnalités à la dernière version de la boîte à outils - et qu'en faire si les programmes les plus simples ne fonctionnent même pas ou fonctionnent avec des interruptions ? Après tout, ils n'ont même pas mentionné la moitié du mécanisme interne d'OpenCL ou de CUDA dans leurs outils descriptifs.
La vitesse du GPU (en GigaFLOPS) d'une carte vidéo suspendue en raison de la compatibilité du pilote ou du logiciel est nulle.
Merci, je ne l'ai pas vu personnellement. Seulement, ce n'est pas si simple.
....Ce n'est pas vraiment la question. Vous pouvez écrire dans un style procédural sur un cinq.
joo : Et , je suis découragé par ce fait, akhtung ! - MQL4 appelant une dll fonctionne plus rapidement que MQL5 appelant la même dll...
C'est ce qui est si alarmant.
Ils auraient pu développer un support natif pour OMP dans MQL5. Ce serait facile et bon marché pour le codeur, et il n'y a pas besoin d'écrire de dll.
Mais cet essaim d'abeilles dans un langage de programmation en fer incomplet... ne m'inspire pas encore vraiment. Eh bien, oui, une accélération centuplée dans certains cas est formidable, mais en termes de culture de programmation, c'est un pas en arrière.
Il y a beaucoup de confusion dans OpenCL (et CUDA) en général. Que voulez-vous ? Après tout, les ingénieurs du fer et de la radio ont entrepris de changer le concept de la programmation. Ils ont un état d'esprit de fer.
Il y aura également un problème avec la soi-disant "SÉLECTION DE PLATE-FORME" : le programme, c'est-à-dire MT ou DLL ou Expert Advisor, DOIT, juste DOIT choisir la plate-forme (AMD, Nvidia, Intel), qui peut être plusieurs différentes qui exécuteront le connecteur OpenCL, et ensuite sélectionner manuellement DEVICE si votre ordinateur fonctionne en Multi-GPU. L'auto-sélection de la plate-forme dans OpenCL n'existe pas encore. Rinat parle de "sélectionner automatiquement le plus puissant" mais je ne sais pas comment cela se passe. Dans l'exemple présenté ici, il n'y a pas de sélection de plate-forme ni de sélection de périphérique (GPU, CPU).
En outre, il n'existe pas encore de méthode standard pour paralléliser automatiquement les tâches OpenCL sur plusieurs GPU ou sur GPU+CPU. Disons-le ainsi : dans certaines versions de ses pilotes/SDK, AMD avait l'habitude d'implémenter cette autoparallélisation, mais il y a eu des problèmes et AMD l'a jusqu'à présent désactivée.
En résumé, le développement et l'activation de programmes OpenCL pour MT4-5 nécessitent un effort manuel et ne fonctionneront donc pas automatiquement ou par "recompilation avec option". Ce qui, à son tour, entraîne de nombreux blocages dans le monde réel. Ce sera un travail subtil et, ce qui est important, je me permets de le répéter, c'est malheureusement la PROGRAMMATION ORIENTÉE PAR LES JUIFS, qui est mauvaise. Le débogage des programmes parallèles pour CUDA ou OpenCL s'est avéré beaucoup plus difficile que ne le supposaient les révolutionnaires du fer. Nvidia a même annulé sa conférence CUDA de l'automne 2011 - en raison de problèmes de pilotes et de nombreuses plaintes concernant le blocage du débogage. Ils ont donc ajouté 1000 nouvelles fonctionnalités à la dernière boîte à outils - et que faire avec, si les programmes les plus simples ne fonctionnent même pas ou fonctionnent avec des interruptions ? Après tout, ils n'ont même pas mentionné la moitié du mécanisme interne d'OpenCL ou de CUDA dans leurs outils descriptifs.
La vitesse du GPU (en GigaFLOPS) d'une carte vidéo suspendue en raison de la compatibilité du pilote ou du logiciel est égale à zéro.
Ce n'est pas vraiment la question. Vous pouvez également écrire dans un style procédural sur 5.
Mais c'est alarmant.
Ils auraient pu développer un support natif pour OMP dans MQL5. C'est simple et serein, il n'y a pas besoin d'écrire une dll.
Mais cet essaim d'abeilles dans un langage de programmation matériel incomplet... ...ne semble pas très excitant. Oui, une accélération au centuple dans certains cas est formidable, mais en termes de culture de programmation, c'est un pas en arrière.
J'ai également rencontré des cas où mql4 fonctionne plus rapidement que MQL5. Dans la plupart des cas, elle se manifeste par des opérations mathématiques optimisées par le programmeur.
Mais je pense que ce n'est pas le problème principal - en utilisant OpenCL MQ, ils ont pris une voie parallèle à la voie de programmation principale - peut-être que jusqu'à présent, cela nécessite un retour en arrière, mais dans le développement futur de la technologie informatique, nous verrons des systèmes évolutifs intégrés où il dépendra déjà du code si le traitement séquentiel ou parallèle est utilisé.
La route est donc tout à fait droite. Bien qu'aujourd'hui il n'y ait pas beaucoup d'algorithmes exigeant la mise en œuvre d'une approche parallèle, c'est plutôt parce que la pensée mathématique n'avait pas d'équipement pour la mise en œuvre de calculs parallèles et donc il n'y avait pas besoin de créer de tels algorithmes.
Alexey, réfléchissez à un fait : toutes les découvertes mathématiques ont été faites il y a 200-300 ans, les 100 dernières années, la pensée mathématique n'a fait que polir ce qui existe. Ce n'est que la découverte de la NS qui a créé la demande de calculs parallèles. Au cours des 100 prochaines années, les algorithmes seront considérablement parallèles. Et vous, parmi d'autres, pouvez inventer l'un d'entre eux.
J'ai aussi vu des faits où mql4 est plus rapide que MQL5. Cela se produit le plus souvent dans les opérations matricielles optimisées par le programmeur.
Mais je pense que ce n'est pas le problème principal - en entrant dans OpenCL, MQ a pris une route parallèle à la route principale de la programmation ; peut-être que jusqu'à présent cela nécessite un recul, mais dans le développement futur de la technologie informatique, nous verrons des systèmes évolutifs intégrés où il dépendra déjà du code si le traitement séquentiel ou parallèle est utilisé.
La route est donc tout à fait droite. Bien qu'aujourd'hui il n'y ait pas tant d'algorithmes exigeant la mise en œuvre d'une approche parallèle, c'est plutôt parce que la pensée mathématique n'avait pas d'équipement pour la mise en œuvre de calculs parallèles et donc il n'y avait pas besoin de créer de tels algorithmes.
Alexey, ne pense qu'à un seul fait : toutes les découvertes mathématiques ont été faites il y a 200-300 ans, les 100 dernières années, la pensée mathématique n'a fait que polir ce qui existe. Ce n'est que la découverte de la NS qui a suscité la demande de calculs parallèles. Au cours des 100 prochaines années, les algorithmes seront considérablement parallèles. Et vous, parmi d'autres, pouvez inventer l'un d'entre eux.
Non, vous n'êtes pas tout à fait désespéré après tout. :)
Salut.
Les MQ sont bons, ils n'ont pas eu peur de s'attaquer à un problème aussi douloureux (pour eux) que l'introduction du support des calculs GPU. La douleur, tout d'abord, est liée au fait que l'introduction de technologies fondamentalement nouvelles (n'importe lesquelles) réduit dans un premier temps la fiabilité et la tolérance aux pannes de la plate-forme dans son ensemble. Mais ils comprennent parfaitement que l'avenir appartient à l'informatique parallèle et que, tôt ou tard, ils devront faire quelque chose dans ce sens (le premier pas a déjà été fait - le nuage).
PS : Salut Nikolaï. Pourquoi avez-vous disparu ? - Envoyez-moi un message.
Ce n'est pas un fait, car ce n'est pas le cas. Le développement qualitatif des mathématiques n'a jamais été interrompu.
Et les calculs parallèles ne sont pas seulement nécessaires aux NS, mais aussi à des tâches plus banales, comme le codage ou le rendu vidéo.
Mais le vecteur général du mouvement MQ est certainement encourageant.