OpenCL : tests de l'implémentation interne dans MQL5 - page 62
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
C'est très amusant, mais le programme OCL s'exécute avec brio même s'il y a un crawl en dehors du tableau ! - et ça marche très bien, mais il obtient non pas n'importe quoi mais 0 d'un blob vide et non marqué.
Que ce soit bon ou pas, c'est à la discrétion de chacun. Je ne le sais que maintenant.
Les zéros ne veulent rien dire. Le programme OCL peut tout simplement ne pas compiler.
Utilisez-vous un compilateur de noyau externe (du fournisseur de matériel graphique) ?
Les zéros ne vous disent rien. Le programme OCL peut tout simplement ne pas compiler.
Utilisez-vous un compilateur externe du fournisseur de matériel graphique ?
Après avoir redémarré l'ordinateur, partagez vos impressions...
C'est la raison pour laquelle il n'y a pas de support OpenCL dans le testeur jusqu'à présent...
Pour l'instant, nous cherchons des moyens de résoudre ce problème d'OpenCL.
Alors regarde, Andrei. J'en ai un Intel hors ligne (il y a même une photo dans l'article). Beaucoup de messages si quelque chose ne va pas. Vous pouvez modifier le noyau immédiatement dans celui-ci pour le rendre plus rapide.
Très pratique. Dommage qu'il n'y ait pas de débogage. Mais c'est beaucoup plus pratique que dans l'éditeur du terminal.
Alors regarde, Andrei. J'en ai un Intel hors ligne (il y a même une photo dans l'article). Beaucoup de messages si quelque chose ne va pas. Vous pouvez modifier le noyau immédiatement dans celui-ci pour être plus rapide.
C'est très pratique. C'est dommage qu'il n'y ait pas de débogage. Mais c'est beaucoup plus pratique que dans l'éditeur du terminal.
Le noyau fonctionne et fonctionne sans erreur, conformément à la logique. Je n'édite pas du tout le noyau dans ME, car il est inutile en termes de détection d'erreurs potentielles - je le vérifie et l'édite dans OpenCLCodeChecker. Le noyau fonctionne.
J'ai délibérément configuré la boucle pour qu'elle aille au-delà du tableau et cela ne provoque pas le plantage du pilote OCL lorsque le programme est en cours d'exécution ; cette "ouverture" a été signalée dans ce fil de discussion. Voir le message d'Ilyaz ci-dessus.
Je suis d'accord, c'est une chose stupide chez ME.
Mon OpenCLCodeChecker ne fonctionne pas comme ça. Et bien, tant pis, je me contenterai de celui d'Intel d'une manière ou d'une autre...
Je suis d'accord, c'est une chose stupide chez ME.
Mon OpenCLCodeChecker ne fonctionne pas comme ça. Eh bien, tant pis, je ferai avec celui d'Intel d'une façon ou d'une autre...
Ouais, il y a une raison pour laquelle AMD a acheté ATI il y a 6 ans. Juste quand le Core 2 Duo a été annoncé.
Intel ne reste pas non plus immobile sur la partie IGP, mais il est toujours à la traîne. Sur ixbt les experts disent que l'Intel HD 4000 rivalisera avec l'actuel A6 en termes de graphisme. Mais c'est aussi une grande progression.
P.S. Au fait, la partie OpenCL de Trinity n'est pas très bonne. Il semble être basé sur le Cayman CE (c'est-à-dire la série 6xxx, bien qu'ils l'appellent HD 7xxx pour une raison quelconque) mais le rapport de performance double à flottant est de 16.
P.S. Au fait, la partie OpenCL de Trinity n'est pas très bonne. Le cœur semble être basé sur le Cayman CE (c'est-à-dire la série 6xxx, bien qu'ils l'appellent HD 7xxx pour une raison quelconque), mais le rapport de performance double à flottant est de 16.