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
Regardez votre propre code : Et puis, à la dernière ligne, vous divisez vous-même 240 par 18 (ce sont des unités pour votre carte).
Vous êtes manifestement confus à propos de quelque chose. Voici l'article controversé :
Conclusion : global=30 local=1
Et 240 octets, c'est exactement le moment où vous créez le tampon.
Vous êtes manifestement confus à propos de quelque chose. Voici une pièce controversée :
Sortie : global=30 local=1
Et 240 octets exactement lors de la création du tampon.
global_work_size[0]
Et local_work_size[0] = (uint) 240/18 = 13
P.S. Oui, vous avez raison. Pardon. J'ai été un peu confus.
local_work_size[0] = (uint) 30/18 = 1. Et j'ai la même chose, puisque les unités = 28.
Encore une fois, Roffild:
Mathemat: Давай тупо прикинем. 18 задач, выполняемых одновременно на мухах GPU, - это максимум то, что можно сделать на 4-5 нитках CPU. А CPU на x86 эмуляции может организовать гораздо больше ниток. Во всяком случае, если это Intel. Мой бывший Pentium G840 (2 ядра) дал ускорение примерно в 70 раз - на двух unit'ах! Я уже не говорю о том, что вытворяет мой текущий... условно говоря, i7.
Une tâche bien parallélisée (voir les scripts de MetaDriver à partir du premier thread ocl) peut atteindre des accélérations jusqu'à 1000 ou plus sur GPU (par rapport à l'exécution d'un seul thread sur CPU sur MQL5). Si vous ne le trouvez pas - je peux vous l'envoyer, vous pouvez le tester sur votre carte.
Avez-vous trouvé le tampon et sa vitesse ?
Vous feriez mieux d'utiliser AMD CodeXL pour déterminer les UNITÉS etc. - il a de beaux graphiques de performance.
AMD CodeXL lui-même est défaillant mais il est difficile de tirer des conclusions sans lui.
Je n'utiliserai pas OpenCL tant que le testeur ne me permettra pas d'utiliser le CPU ou tant que je n'exécuterai pas une tâche dont la durée est supérieure à Number of_buffers * 0,353 msec.
P.S.
J'ai finalement fini d'optimiser mon code et la variante finale passe le test en 33 secondes (320 secondes - avant optimisation, 55 secondes - "style OpenCL").
Il n'y a rien à découvrir. Il est clair qu'il s'agit d'une opération lente. Conclusion - augmenter le travail à l'intérieur du noyau (il y en a trop peu dans votre code).
Et achetez une carte vidéo plus moderne, il semble s'être amélioré avec elle.
AMD CodeXL lui-même est défaillant mais il est difficile de tirer des conclusions sans lui.
L'utilitaire d'Intel est plutôt utile aussi, mais pour les pierres Intel. Eh bien, et pour attraper les erreurs les plus évidentes dans le noyau.
P.S. J'ai, après tout, fini d'optimiser mon code et la variante finale passe maintenant le test en 33 secondes (320 secondes - avant optimisation, 55 secondes - "OpenCL-style").
C'est déjà beaucoup mieux.
Aujourd'hui, j'ai eu besoin de générer un tableau avec 1 bit dans les chiffres.
En même temps, je me suis entraîné avec OpenCL.
Je poste le code pour démontrer une méthode intéressante de calcul de global_work_size et local_work_size. L'idée elle-même est tirée de IntrotoOpenCL.pdf (j'en ai une copie), mais je l'ai modifiée.