OpenCL : tests de l'implémentation interne dans MQL5 - page 33
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
Andrew, est-ce que, disons, Intel + Radeon est une mauvaise chose ?
Pas mal, mais excessivement cher (à cause du processeur). :)
Au fait, je suis un fan de longue date des cartes nVidia. J'ai même une boîte quelque part avec le légendaire GeForce 3. Et si je voulais jouer à des jeux, je n'hésiterais pas à m'en tenir au fabricant de puces graphiques "vertes".
Plus sérieusement, je suis très curieux de savoir ce que vous allez pouvoir en tirer, surtout si vous avez 2 Giga DDR5. Il s'avère que la mémoire du GPU embarqué peut être une ressource TRES importante pour les calculs OpenCL.
De toutes les informations dont je dispose, j'ai conclu que la ressource principale est le nombre de cœurs du GPU. S'il n'y en a pas assez, le problème se divise en courses consécutives de cœurs avec de nouveaux threads mais il est difficile d'économiser sur cette ressource lors de l'achat de la carte car plus il y a de cœurs, plus le prix est élevé.
Le deuxième facteur le plus important est la vitesse à laquelle la mémoire du GPU fonctionne (puisque la mémoire est accédée assez fréquemment). Dans la plupart des cas, les tâches du GPU sont assez primitives et utilisent des opérations 1-2-3 avant d'accéder à la mémoire pour afficher les résultats. Toute opération logique complexe étant contre-indiquée pour les GPU, les programmeurs s'efforceront de la minimiser, ce qui se traduira logiquement par des accès à la mémoire plus fréquents. Il y a ici des variantes, si la tâche est décrite par le programmeur de manière à ce que les accès à la mémoire soient aussi faibles que possible, alors cette ressource n'est pas si importante.
Et la troisième ressource, je l'appellerais la quantité de mémoire du GPU. Les crash-tests ayant montré que, quel que soit le nombre de contextes concurrents, toute la mémoire distribuée dans les contextes est allouée dans un seul champ de mémoire et ne se chevauche pas. Laissez-moi vous expliquer par un exemple : si vous avez N contextes dans chacun desquels des tampons sont alloués dans 1/4 de la mémoire du dispositif, vous pouvez avoir 4 de ces contextes en même temps. Le cinquième contexte, même si vous le créez, ne se verra pas allouer de mémoire car elle est déjà distribuée par les contextes précédents. Mais libérer de la mémoire dans l'un des contextes précédents (en supprimant simplement le tampon) donnera de l'espace et le cinquième contexte fonctionnera bien.
Nous n'en sommes qu'au début. Nous devons nous assurer que les programmes OpenCL ne bloquent pas l'ensemble du réseau en raison de problèmes liés aux GPU et aux programmes OpenCL eux-mêmes.
En fait, les programmes OpenCL ne peuvent être mis en ligne qu'après avoir été testés sur des agents locaux pour s'assurer que le programme est fonctionnel et ne tue pas l'ordinateur.
La tâche d'un réseau de calcul parallèle distribué. Le nom lui-même peut prêter à confusion pour un lecteur non averti. Si l'organisation d'un réseau distribué sur des machines multicœurs vous posait des problèmes, ceux-ci seront désormais résolus. Tous les cœurs peuvent être considérés comme des unités de réseau distinctes car ils effectuent des tâches séparées. Mais auparavant, leur vitesse d'exécution différait tout au plus de 2 à 3 fois (pour laquelle vous avez introduit des limites de vitesse pour les cœurs lents), la quantité de mémoire dans la plupart des cas ne jouait pas de rôle, car les tableaux ont 10^7 éléments maximum (pour les machines modernes, c'est quelques centimes).
Mais avec les GPU, le problème change radicalement. Tout d'abord, seulement ~12 matrices doubles avec une longueur de 10^7 sont déjà 1Gb, ce qui est une limite pour de nombreuses cartes. Dans les calculs du CPU, les tâches avec plus de tampons sont assez courantes (même si, bien sûr, le programmeur du GPU peut s'enregistrer en utilisant la mémoire hôte, mais c'est similaire à la RAM virtuelle, en bref, c'est une mauvaise chose).
Deuxièmement, la différence entre les vitesses d'exécution est linéairement proportionnelle au nombre de cœurs d'un GPU. La différence entre les deux cartes est de 10 à 1000 fois.
En général, la tâche de mise en réseau se résume à la classification du programme à exécuter. Faites attention au profileur CUDA. Ses statistiques peuvent servir de base à la classification des tâches. Si la tâche est conçue de manière à ce que la plupart du temps soit consacré à l'accès à la mémoire, elle nécessite un cluster de machines avec de grandes tailles de mémoire, mais si la plupart du temps est consacré à l'arithmétique, nous avons besoin d'un cluster avec un grand nombre de cœurs. Les clusters peuvent être flexibles ou inclusifs (c'est une question d'exécution).
Bien que la tâche soit un peu simplifiée par l'unification appliquée par le temps lui-même. Une carte à 12 cœurs est susceptible d'avoir 256 Mo, une carte à 96 cœurs a 512 Mo. En moyenne, les fabricants n'autorisent pas les grands déséquilibres (contrairement à l'unité centrale, où l'utilisateur peut coller son vieux caillou avec de la RAM jusqu'à la gueule, ou mettre un minimum de RAM sur le nouveau caillou, juste pour faire des économies à l'achat).
Bien que, à mon avis, une approche plus correcte serait de créer un débogueur pour OpenCL et sur sa base défendre l'optimisation pour le périphérique dans le bytecode. Sinon, nous en arriverions à l'assembleur où le programmeur devrait deviner sur quelle carte le programme fonctionnerait et les caractéristiques moyennes du programme pour un environnement possible.
Dites-moi, si vous le voulez bien, comment faites-vous le test ? Où, quoi changer ? Copie, sélection, résultat :
Win7 x64 build 607
Cet exemple n'a pas besoin d'être "exécuté" dans le testeur. Pour exécuter le script, faites-le glisser et déposez-le du "Navigateur" vers le graphique. Le résultat sera affiché dans le panneau " Outils", onglet " Experts".
w7 32 bit 4GB ( 3.5GB disponible)
Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) vs Radeon HD 5770
w7 32 bit 4GB ( 3.5GB disponible)
Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) vs Radeon HD 5770
Cool, maintenant tu sais où creuser... :)
les processeurs ont déjà 2 ou 3 générations de retard
et vidéo 5770 - 6770 -7770
:)
A partir des informations disponibles, je suis arrivé à la conclusion que la ressource principale est le nombre de cœurs du GPU, en cas de manque de cœurs, la tâche est divisée en plusieurs passages consécutifs de cœurs avec de nouveaux threads, mais il est difficile d'économiser sur cette ressource lors de l'achat d'une carte car plus il y a de cœurs, plus le prix est élevé.
Le deuxième facteur le plus important est la vitesse à laquelle la mémoire du GPU fonctionne (puisque la mémoire est accédée assez fréquemment). Dans la plupart des cas, les tâches du GPU sont assez primitives et utilisent des opérations 1-2-3 avant d'accéder à la mémoire pour afficher les résultats. Toute opération logique complexe étant contre-indiquée pour les GPU, les programmeurs s'efforceront de la minimiser, ce qui se traduira logiquement par des accès à la mémoire plus fréquents. Il y a ici des variantes, si la tâche est décrite par le programmeur de manière à ce que les accès à la mémoire soient aussi faibles que possible, alors cette ressource n'est pas si importante.
Et la troisième ressource, je l'appellerais la quantité de mémoire du GPU. Les crash-tests ayant montré que, quel que soit le nombre de contextes concurrents, toute la mémoire distribuée dans les contextes est allouée dans un seul champ de mémoire et ne se chevauche pas. Laissez-moi vous expliquer par un exemple : si vous avez N contextes dans chacun desquels des tampons sont alloués dans 1/4 de la mémoire du dispositif, vous pouvez avoir 4 de ces contextes en même temps. Le cinquième contexte, même si vous le créez, ne se verra pas allouer de mémoire car elle est déjà distribuée par les contextes précédents. Cependant, en libérant la mémoire dans certains des contextes précédents (en supprimant simplement le tampon), un peu d'espace apparaîtra et le cinquième contexte fonctionnera bien.
après la mise à jour vers la version 607, j'ai soudainement réussi à faire fonctionner opencltest sur mon ordinateur portablehttps://www.mql5.com/ru/code/825, cela ne fonctionnait pas auparavant (il y a environ deux semaines), je pense que cela disait "OpenCL non trouvé".
"Je sens un truc", je n'ai pas encore joué avec les fractales de Mandelbrot ))))))))))))) mais c'est quand même bien que ce ne soit pas un nouvel ordinateur portable qui puisse être utile pour tester MT5.