OpenCL : de vrais défis - page 6

[Roffild]

Mathemat: Je ne l'ai pas encore vérifié dans le testeur.

Alors, pourquoi avez-vous posté des absurdités non vérifiées ?

Peut-être que je suis le seul à avoir essayé OpenCL dans le testeur après tout... l'a essayé...

[Sceptic Philozoff]

Roffild:

Alors, pourquoi avez-vous posté des absurdités non vérifiées ?

Je suis probablement le seul à avoir utilisé OpenCL dans le testeur après tout... l'a essayé...

Ce n'est pas un non-sens, c'est une demande satisfaite.

Encore une fois, écrivez à Servicedesk et justifiez ce que vous voulez. Si vous ne pouvez pas le justifier, c'est votre problème.

Au moment de la rédaction de ces articles, les discussions sur l'utilisation d'OpenCL dans le testeur n'avaient pas encore vraiment commencé. L'application fait référence à ce moment précis.

C'est vous qui devriez allumer votre cerveau car 0,35300 ms fait référence à clEnqueue[Read/Write]Buffer() et non à un accès global à la mémoire à l'intérieur du noyau.

Cette commande n'est pas présente dans l'implémentation d'OpenCL pour MQL5. De quoi parlez-vous ?

[Vladimir Gomonov]

Roffild:

Relisez mes messages.

Le critère principal : l'exécution du code MQL dans le "style OpenCL" pour 1 tick doit dépasser time = Number_Buffers * 0.35300 ms

Pour connaître la vitesse de l'algorithme dans MQL avec une précision de l'ordre de la microseconde (1000 microsecondes = 1 milliseconde), vous devrez l'exécuter plusieurs fois dans le testeur et utiliser Total_Time / Number_of_Ticks (mon message principal).

Sans le retard de la mémoire tampon, mon code passerait le test en ~30 secondes - c'est ~2 fois plus rapide que le MQL "style OpenCL" (55 secondes) et ~11 fois plus rapide que le code normal (320 secondes).

Quels sont les autres critères ?

Je ne vous demande pas de relire tous mes messages sur le forum de l'OpnCL. :) A tous les critères de base y sont décrits et discutés.

Le critère principal est le rapport t_alg/t_mem où t_alg- temps de calcul optimisé de l'algorithme du noyau et t_mem- temps d'accès à la mémoire supprimée (*). Plus ce critère est long, meilleures sont les perspectives d'accélération via OpenCL. En d'autres termes, plus les calculs sont difficiles et moins les transferts de tableaux vers et depuis le périphérique sont nombreux, meilleures sont les perspectives.

(*) mémoire distante = tous les types de mémoire "non registre" (la mémoire registre est très rapide), par exemple (1) la mémoire globale du dispositif est beaucoup plus lente que la mémoire registre mais beaucoup plus rapide que (2) la mémoire externe au dispositif (RAM du CPU).

[Roffild]

Mathemat:

Il ne s'agit pas d'un non-sens, mais d'une application satisfaite.

Encore une fois, écrivez à Servicedesk et justifiez ce que vous voulez. Si vous ne pouvez pas le justifier, c'est votre problème.

Encore une fois : bug #865549 du 2013.10.17 23:17 et les développeurs sont avertis, mais il est peu probable qu'ils corrigent quoi que ce soit. Probablement cette limitation que quelqu'un d'entre eux a ajouté exprès pour ne pas suspendre le processeur entier pendant l'optimisation.

Mais les articles n'en disent pas un mot !

Mathemat:

Il est temps d'allumer votre cerveau car 0,35300 ms fait référence à clEnqueue[Read/Write]Buffer() et non à l'accès global à la mémoire dans le noyau.

Cette commande n'est pas présente dans l'implémentation d'OpenCL pour MQL5. De quoi parlez-vous ?

Eh... Et vous débitez aussi des articles sur OpenCL...

Pour votre information, clEnqueueReadBuffer = CLBufferRead et clEnqueueWriteBuffer = CLBufferWrite sont appelés de manière synchrone.

L'apprentissage commence ici

MetaDriver: Le critère principal est le rapport t_alg/t_mem, où t_alg est le temps de calcul optimisé de l'algorithme du noyau et t_mem est le temps d'accès à la mémoire supprimée (*). En d'autres termes, plus les calculs sont "lourds" et moins les transferts de tableaux vers et depuis le périphérique sont importants, plus le potentiel d'accélération avec OpenCL est élevé.

Il s'agit d'un critère d'optimisation de l'exécution uniquement. Il n'y avait pas de chiffres approximatifs sur le taux de transfert des tampons eux-mêmes avant mes posts.

[Roffild]

Les amis, avant d'argumenter davantage, pensez aux trois messages qui commencent ici et qui concernent spécifiquement

mql5: Dans cet exemple particulier, l'avantage de l'utilisation d'OpenCL est annihilé par la surcharge de la copie de la mémoire tampon.

Parce que vous vous concentrez sur l'optimisation du noyau lui-même, alors que mes messages portent sur les tampons.

[Sceptic Philozoff]

Roffild: Pour votre information : clEnqueueReadBuffer = CLBufferRead et clEnqueueWriteBuffer = CLBufferWrite et ils sont appelés de manière synchrone.

Je sais depuis longtemps que l'implémentation d'OpenCL pour MQL5 n'est qu'une enveloppe sur la véritable API. À propos, j'ai écrit dans mon deuxième article que la possibilité de définir la taille des groupes de travail fait défaut. J'ai fait une demande à Servicedesk, et ils l'ont fait après un certain temps.

Je sais également que CLBuffer[Read/Write] est similaire à clEnqueue[Read/Write]Buffer, mais ces fonctions ne sont pas du tout identiques : elles ont des syntaxes différentes.

Mais je ne comprends pas pourquoi vous continuez à parler des fonctions clEnqueueXXX qui ne sont pas présentes dans OpenCL pour MQL5.

Je vais essayer de comprendre ce que vous voulez.

Roffild:

Il est temps d'allumer votre cerveau car 0,35300 ms fait référence à clEnqueue[Read/Write]Buffer() et non à un accès global à la mémoire dans le noyau.

La seconde peut être résolue en optimisant le noyau lui-même alors que la première est une limite de fer.

Ok. Contre qui avez-vous une plainte ? Le fabricant de la carte graphique ?

[Roffild]

Mathemat: Je sais également que CLBuffer[Read/Write] est analogue à clEnqueue[Read/Write]Buffer mais ces fonctions ne sont pas du tout identiques : elles ont des syntaxes différentes.

Mais je ne comprends pas pourquoi vous continuez à parler des fonctions clEnqueueXXX qui ne sont pas présentes dans OpenCL pour MQL5.

Il n'y a pas de différence. Il y a probablement un tel emballage :

template<typename T>
cl_int BufferWrite(cl_mem buffer, const T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueWriteBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}
template<typename T>
cl_int BufferRead(cl_mem buffer, T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueReadBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}

Vous n'avez donc pas besoin d'élaborer la syntaxe non plus. Le fait que le 3ème argument = CL_TRUE a déjà été confirmé.

Mathemat:

La seconde peut être résolue en optimisant le noyau lui-même, tandis que la première est une contrainte de fer et le cerveau n'y fera rien.

Ok. Contre qui avez-vous une plainte ? Le fabricant de la carte vidéo ?

Les auteurs des articles se plaignent de l'absence de données pratiques sur cette limitation essentielle ! (Il n'y en avait pas, jusqu'à ce que je le teste.)

[Vladimir Gomonov]

Roffild:

La plainte s'adresse aux rédacteurs de l'article, qui ne disposent d'aucune donnée pratique sur cette limitation essentielle ! (Il n'y en avait pas, jusqu'à ce que je le teste.)

Ne lisez plus d'articles et vous ne vous plaindrez plus. ;)

--

Pourquoi vous vous en prenez à moi ? Comment pouvez-vous citer des données inconnues dans un article ? Le délai de transfert des données vers/depuis un appareil est énorme et doit être pris en compte ? Les chiffres spécifiques dépendent du matériel spécifique. Donc, vous l'avez testé sur vous-même et bien joué. Parfois, les gens (moi y compris) établissent un code de test pour estimer les capacités et les limites de différents matériels. Ils demandent à d'autres personnes de partager leurs résultats, ce que les gens font souvent (bravo à eux pour cela), en même temps que tout le monde peut voir les statistiques et ce qui fonctionne dans quelles combinaisons. Ensuite, quelqu'un achète à nouveau du matériel ou change d'approche pour écrire du code en tenant compte des résultats. Qu'est-ce que vous voulez ? Eh bien, écrivez une plainte à Sportloto, peut-être que cela fera fonctionner votre code plus rapidement...

:)

[Roffild]

En fait, j'ai déjà tout fini sur https://www.mql5.com/ru/forum/13715/page5#comment_646513, mais les auteurs des articles voulaient eux-mêmes prouver autre chose.

Il n'y a pas d'informations spécifiques et très importantes dans vos articles, ils ne sont donc pas finis et décrivent des tâches irréalistes.

Vous pouvez ne pas ajouter d'informations aux articles, mais il est stupide de prétendre que ces chiffres particuliers ne veulent rien dire.

[Sceptic Philozoff]

Je ne comprends pas le sens caché du script/conseil que vous avez posté, Roffild. Le code est, pour le moins, incompréhensible.

- Où se trouve le pragma cl_khr_fp64 ? Vous en avez besoin pour calculer avec le double dans le noyau.

- Pourquoi y a-t-il ce morceau de code dans la fonction OnTick(), qui peut être mis dans l'initialisation en calculant une fois ?

uint units = (uint)CLGetInfoInteger(hcontext, CL_DEVICE_MAX_COMPUTE_UNITS);
uint global_work_offset[] = {0};
uint global_work_size[1];
uint local_work_size[1];
global_work_size[0] = ArraySize(price);
local_work_size[0] = global_work_size[0] / units;

- Pourquoi la taille de la tâche globale est-elle égale à 240 octets ? Il faudrait qu'il soit beaucoup plus grand pour tirer un avantage d'OpenCL. Eh bien, il devrait être au moins un million de fois plus grand si vous pouvez juste juger à l'œil.

- Pourquoi une tâche globale doit-elle être divisée par le nombre d'unités pour obtenir la taille d'une tâche locale ? Le CPU et le GPU permettent tous deux de diviser une tâche globale en un nombre beaucoup plus important de sous-tâches. Et les unités dans votre cas sont juste un certain nombre de moteurs SIMD.

Disons, par exemple, que le nombre d'unités de ma carte vidéo est de 28 (Radeon HD7950). Mais ce nombre ne divise pas exactement 240. Cela signifie qu'une partie importante des calculs peut être non parallèle.

Le nombre de shaders dont je dispose est de 1792. Le vôtre est de 1440. C'est à peu près le nombre que vous devriez diviser la tâche globale, pour charger correctement la carte. Mais vous devrez calculer la taille correcte de la tâche globale. (Et il est préférable de ne pas diviser, mais de multiplier).

Et ce que votre carte compte pendant tout ce temps n'est pas clair du tout.

En bref : que doit faire votre code ?