OpenCL : tests de l'implémentation interne dans MQL5 - 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
Il y a des clarifications :
...
2) Nous supportons OpenCL 1.1 et plus car il supporte les types doubles. La version OpenCL 1.0 ne peut fonctionner qu'avec un flotteur, dont la précision n'est en aucun cas adaptée aux calculs financiers
.
Essayez d'installer des pilotes plus récents, bien que de nombreuses cartes des générations précédentes ne prennent pas en charge les opérations doubles.
En testant les scriptsJavaDev cet été,nous avons rencontré un problème : ma carte graphique ne supportait pas ledouble, maiselle fonctionnaitavec lefloat. Les pilotes ne peuvent pas le réparer, nous devons changer la carte :(
J'ai installé le centre de catalyse 12, avant c'était 11. Vous avez déjà obtenu des résultats (surlignés en rouge) :
J'ai juste "joué" avec la liste déroulante de "0" à "1" et l'icône ATI est apparue. Il n'a pas disparu à nouveau au démarrage de ce programme. Un petit problème dans le logiciel semble être....
Cool ! J'ai un MSI R6970 - 1536 threads (agents) et un Gigabyte HD5870 (1600 processeurs). Dans BOINC manager, ils peuvent être utilisés sans les combiner en crossfair (il suffit de brancher une sortie de la deuxième carte ou de connecter une des sorties du deuxième moniteur. Question : sera-t-il possible d'utiliser les deux sans crossfire ???
Pas encore sûr. Cela dépend davantage du programme lui-même qui sélectionne les appareils, ce qui implique l'utilisation explicite de chaque carte dans le code.
Nous verrons plus tard, lorsque nous publierons la première version bêta.
J'espère que la version 1.1 de Float est toujours supportée ? Float n'est pas suffisant dans le cas général, mais dans de nombreux cas particuliers, il est même très suffisant. Et la mémoire supplémentaire est souvent très coûteuse, surtout dans les calculs parallèles.
Si je comprends bien, 1 GPU est un agent très puissant ? Dans ce cas, les agents CPU pourraient-ils être désactivés (en raison de leur faible vitesse par rapport à la vidéo) ?
Le cœur du processeur ne peut être désactivé d'aucune manière, il est de toute façon utilisé comme plateforme hôte dans l'environnement MQL5.
Il est important de comprendre que les cœurs de GPU sont "un essaim d'abeilles hautement spécialisées" par rapport aux "bêtes de somme" que sont les cœurs de CPU. Les cœurs de GPU ne peuvent en aucun cas se substituer aux cœurs d'un CPU classique.
Si un développeur d'EA est en mesure de paralléliser la tâche en des centaines et des milliers de threads indépendants, le GPU offrira une vitesse 10 à 100 fois supérieure. Mais dans la plupart des tâches simples (trading et indicateurs, par exemple), les calculs sont séquentiels et il n'y a aucune chance de paralléliser efficacement les processus. De même, l'utilisation de calculs réels en double précision sur des GPU ordinaires permet d'obtenir des vitesses deux fois moins rapides que les valeurs maximales obtenues sur les flottes. Voici un lien intéressant avec une discussion sur la baisse de vitesse sur le double : http://www.gpgpu.ru/node/901.
Nous allons nous-mêmes acheter des cartes de différentes classes pour publier une petite recherche pour les calculs de certaines tâches sur double et float. Nous sommes nous-mêmes intéressés par ce que nous pouvons obtenir.
Voici une petite étude des vitesses de calcul avec float et double sur différents appareils (rapport complet : http://agora.guru.ru/hpc-h/files/017_Krivov_NvidiaGpuComparision.pdf). Vous pouvez voir que la vitesse double sur Tesla est 2 fois plus faible que la vitesse maximale du flotteur, alors que sur des cartes communes comme la GeForce 480 GTX, elle est presque 10 fois plus lente. En fait, cela signifie qu'il est possible d'obtenir de meilleurs résultats sur un processeur ordinaire de 4 à 8 cœurs avec une utilisation active de SSE2-4 et d'AVX dans les calculs doubles :
Nous avons pu obtenir des accélérations centuplées (dans la limite de 100-1000 et plus) sur des tests séquentiels dans l'optimiseur de stratégies de trading et des accélérations décuplées (dans la limite de 10-20-50-100-200 fois) dans la génétique grâce à l'idée native d'exécutions de tests parallèles et au MQL5 Cloud Network. Mais lorsqu'il s'agit de parallélisme au sein d'une même tâche, tous les efforts reposent sur les épaules du programmeur du GPU qui peut distribuer intelligemment la tâche entre des centaines ou des milliers de cœurs simples indépendants.
Il y a une autre nuance - le plus souvent, lorsque plusieurs agents utilisent l'ordinateur, un seul agent se verra attribuer le droit d'utiliser le GPU. Ou, s'il y a quelques dispositifs GPU physiques réels, ils seront distribués entre les agents au début des agents.
Le fait est qu'il n'est pas raisonnable de diviser un dispositif physique entre plusieurs agents, car le résultat du partage est une baisse non linéaire des performances. En d'autres termes, les performances de 4 agents sur un GPU seraient beaucoup plus mauvaises que celles d'un agent sur un GPU. Nos tests internes l'ont démontré.
Nous effectuerons des tests plus détaillés et trouverons une solution qui optimisera le résultat.
........
Nous avons été en mesure d'obtenir des accélérations centuplées (dans la limite de 100-1000 et plus) sur les recherches séquentielles dans Strategy Trading Optimizer et des accélérations décuplées (dans la limite de 10-20-50-100-200 fois) sur les génétiques grâce à l'idée native des tests parallèles et du MQL5 Cloud Network. Mais lorsqu'il s'agit de parallélisme au sein d'une même tâche, tous les efforts reposeront sur les épaules du programmeur GPU qui peut raisonnablement répartir la tâche entre des centaines ou des milliers de cœurs simples indépendants.
........
Republié depuis le fil de discussion OpenCL sur MQL4.com :
https://www.mql5.com/ru/forum/137422/page6
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 TOUJOURS 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) suscite beaucoup de confusion 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 la plate-forme: le programme, c'est-à-dire MT ou DLL ou Expert Advisor, DOIT, juste DOIT sélectionner manuellement la plate-forme (AMD, Nvidia, Intel), qui peut être plusieurs différentes sur un ordinateur et qui exécutera le noyau OpenCL, et ensuite sélectionner manuellement DEVICE si l'ordinateur a 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 avait l'habitude d'introduire ce type d'autoprovisionnement 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, 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 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.