OpenCl et les outils correspondants. Critiques et impressions. - page 28
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
Dans quelques années, nous vous rappellerons ce fil de discussion.
Personnellement, cette branche m'a été très utile - même lorsque le topicstarter a commencé à effrayer mon esprit immature des horreurs de la précision réduite des calculs.
Le mode d'optimisation sur MT5 est très lent lorsque l'algorithme génétique est activé. J'ai créé un conseiller expert sur MT4 et je l'ai testé et optimisé. Le temps d'optimisation ne dépasse pas 5 minutes sur un double cœur (bien sûr, MT4 n'a qu'un seul cœur en jeu, mais les autres tâches n'interfèrent pas, car elles peuvent fonctionner sur le deuxième cœur). J'ai réécrit le même Expert Advisor pour MT5. Je l'ai testé pour l'optimisation. Le temps d'optimisation est de plus d'une heure, près de 2 heures pour être exact. Quelle est la différence ?
Il n'y a pas de différence maintenant.
MetaTrader 5 semble avoir une longueur d'avance, même en testant les prix d'ouverture : Comparaison de la vitesse de test dans MetaTrader 4 et MetaTrader 5
Comme promis, nous avons simplifié le mode de test d'ouverture des barres et l'avons rendu plus rapide.
Eh bien, ça fait deux ans.
La version CUDA de l'EA fonctionne. Sous MT4. Pour l'instant, il n'est qu'en mode test. Jusqu'à présent, je n'ai pas pu obtenir l'accélération des calculs promise par nVidia.
Il y a deux problèmes ici :
1. nVidia lui-même, qui exagère la vitesse de refonte des programmes, ou ne prépare PAS du tout sa documentation, ou change fondamentalement certains aspects essentiels de la programmation.
2. La parallélisation d'algorithmes sous GPU prend beaucoup plus de temps que prévu. Lorsque j'ai commencé à porter un programme de DLL à CUDA-DLL, en me basant sur mes plus de 20 ans d'expérience dans le langage Caelian, j'ai pensé que les promesses de nVidia devraient être divisées par 3, et que le temps de portage de l'algorithme qu'ils ont cité devrait être multiplié par, disons, 3.
Mais il s'est avéré que la règle générale est la suivante : toutes les promesses de nVidia doivent être divisées par DIX et le temps estimé du portage de C vers CUDA doit être multiplié par 10.
Remarque : si vous avez compris les principes de fonctionnement des accélérateurs GPU, vous pouvez porter l'algorithme de C à CUDA en TROIS SEMAINES. Et vous pouvez le faire directement - juste pour vérifier la construction. En d'autres termes, votre programme sera exécuté par UN SEUL des centaines ou des MILLIERS de petits processeurs de la carte vidéo. Cela fonctionne environ 70 (soixante-dix) fois plus lentement que sur le CPU. Oui, lent, mais ça marche.
Vous pourrez alors, avec beaucoup plus d'efforts, commencer à mettre votre programme en parallèle. Cela fonctionne déjà 4-5 fois plus lentement, ou seulement 2-3 fois plus vite que sur le processeur central.
Et modifier votre ALGORITHME de manière globale, afin qu'il soit exécuté dans la PASSIONS, je répète dans la PASSIONS, plutôt que de manière séquentielle comme on vous l'enseigne dans toutes les universités du monde, est une tâche difficile.
Soyons clairs : il est difficile mais pas inhabituel de paralléliser un algorithme séquentiel habituel par le principe du multithreading. C'est une chose. Vous obtenez une accélération de 5 à 10 fois plus rapide sur le GPU de la même manière. Mais pour convertir l'algorithme séquentiel en un algorithme en grappe (je n'ai pas de meilleur mot dans mon vocabulaire), pour charger des centaines et des milliers de processeurs GPU et obtenir l'accélération de 100 fois promise par nVidia - cela peut être un problème.
Mais c'est aussi soluble. Ce n'est qu'une question de temps.
Mais il y a aussi la Crimée, les Benderites, etc. .....
3. MetaTrader-4 n'a aucun problème pour écrire une DLL pour CUDA.
Le problème est que les développeurs du logiciel nVidia (2500 personnes) sont en désaccord radical avec le modèle de multithreading utilisé dans MetaTrader-4-5. Nvidia a fondamentalement changé ce modèle lorsqu'elle est passée de CUDA 3.2 à 4.0+. De plus, si vous commencez à leur demander pourquoi il en était ainsi (comme Metatrader-4 et des centaines d'autres programmes multithreads) et qu'il en est ainsi maintenant, tout ce que vous entendrez en réponse est "vous avez fondamentalement mal compris notre kAnstment".
J'ai déjà entendu ça quelque part. .... récemment.....
4. Il est beaucoup plus facile de traduire un nouvel algorithme de C à CUDA que de C à OpenCL générique directement, c'est pourquoi je recommande cette méthode. D'autant plus qu'aujourd'hui même, nVidia est censé présenter officiellement CUDA-6 dans lequel, théoriquement, sur les nouveaux GPU de la série Maxwell et sous certains systèmes d'exploitation, il sera possible de réduire considérablement la quantité de programmation - en raison de l'unification de la mémoire et de la suppression des opérations de transfert entre le CPU et le GPU.
Alors ?
Et alors ?
Personne n'est intéressé ?
Pas une seule question ou un seul message en un an.
Mais c'est intéressant pour Nvidia : elle a lu mes plaintes sur ce forum et d'autres, a réuni son conseil artistique, l'a frotté de toutes les manières possibles - et a décidé que les traders sont aussi des personnes, et que le terminal de trading est aussi un programme, et a introduit dans la dernière version de CUDA une clé spéciale pour le compilateur - pour créer des programmes hautement multithreadés dans CUDA.
http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/
une chaîne comme
nvcc --default-stream per-thread ./pthread_test.cu -o pthreads_per_thread
Malheureusement, même le Xeon Phi n'a pas décollé. Et c'est encore plus proche de la programmation conventionnelle.
Quiconque a besoin de puissance dans les calculs universels peut désormais l'obtenir facilement sans trop solliciter les systèmes multiprocesseurs à usage général. Le nombre de cœurs dans les processeurs Intel augmente assez vite.
Par exemple, nos serveurs ont 40 cœurs chacun, j'ai même un ordinateur de travail avec 20 cœurs et de la mémoire DDR4. Un serveur avec 40 cœurs Xeon à 3 GHz bat sans ambiguïté un Xeon Phi à basse fréquence avec 56 cœurs ou plus sans avoir à réécrire une seule ligne de code.
Quiconque a besoin de puissance dans le domaine de l'informatique polyvalente peut désormais l'obtenir facilement sans trop de contraintes pour les systèmes multiprocesseurs polyvalents. Le nombre de cœurs dans les processeurs Intel augmente assez rapidement.
Par exemple, nos serveurs ont 40 cœurs chacun, j'ai même un ordinateur de travail avec 20 cœurs et de la mémoire DDR4. Un serveur basé sur Xeon avec 40 cœurs à 3Ghz bat sans ambiguïté un Xeon Phi à basse fréquence avec 56 cœurs ou plus, sans qu'il soit nécessaire de réécrire une seule ligne de code.
Vous vous trompez légèrement (2 fois. Les deux.). C'est ce que je pensais aussi, surtout lorsque je me suis lancé dans la programmation de GPU.
(1). La "puissance en calculs universels" sur un CPU hôte peut facilement être obtenue UNIQUEMENT pour les algorithmes les plus simples. C'est le point de friction pour la plupart des programmeurs OpenMP et GPU. Il y a des centaines de millions de cartes vidéo CUDA vendues, mais seulement environ 300 programmes pour cette technologie. Pour les finances - seulement environ 7-8 (sans compter les collections des bibliothèques inutiles).
Consultez la liste complète sur le site Web de nVidia :
http://www.nvidia.com/object/gpu-applications.html?cFncE
(Notre premier EA accéléré par CUDA et disponible dans le commerce pour le terminal de trading MT4 n'est *pas* encore là).
Cette liste n'a pas changé depuis plusieurs années.
Pourquoi ? Eh bien, parce que l'algorithme adaptatif complexe, qui peut facilement être assemblé à partir de morceaux sur un CPU hôte, s'avère qu'il ne suffit pas de le programmer, il faut le BREAKer. Et ce n'est pas une tâche facile à cause de :
a). les particularités et les limites du modèle GPU CUDA-OpenCL (les noyaux de tailles différentes doivent être exécutés séquentiellement).
b). tout transfert de données via le bus PCI entre le GPU et le processeur hôte annule le gain de vitesse. Et dans les algorithmes adaptatifs complexes, vous ne pouvez pas vous en passer.
(2). "ne nécessitant pas la réécriture d'une seule ligne de code" ne concerne également que les algorithmes simples. La situation est aggravée par le fait qu'OpenMP - en tant que véritable alternative au GPU - fonctionne mystérieusement, c'est-à-dire que parfois il fonctionne, et parfois il produit des déchets. Il est illusoire de penser qu'il suffit d'ajouter une ligne pragma à un endroit pour que l'algorithme se parallélise immédiatement. C'est loin d'être le cas. Dans un algorithme complexe, de telles corrélations inattendues se produisent entre les données et les fils parallèles que nous ne pouvons pas faire sans construire un graphe.
Le GPU est une question entièrement différente. Il y a plus de travail à faire au début, mais le programme fonctionne TOUJOURS correctement, en termes de timing. De plus, un programme réécrit pour CUDA (même sans écrire les noyaux) est traduit en OpenMP ACTIVEMENT par une ligne de pragma et cela fonctionne. Cela n'a aucun sens de le traduire en OpenMP juste après cela - il serait beaucoup plus perspectif et fiable d'ajouter des noyaux pour CUDA-OpenCL. De manière surprenante, les noyaux pour les GPU CUDA s'avèrent courts, clairs et fiables.
En termes de vitesse absolue et de fiabilité, le processeur hôte n'a aucune chance contre le GPU.
=Les marchés financiers et le marché des changes en particulier sont une version TRÈS comprimée d'énormes processus qui se déroulent dans le monde entier.
=Pour cette raison, un aglorithme pour la prédiction des prix ne peut être simple. C'est pourquoi il doit être adaptatif et statistique au sens figuré de nos jours.
=Sans simulation ni rétroaction adaptative dans un si bon algorithme, il n'y a nulle part où aller.
=Par conséquent, si le CPU hôte peut encore être utile pour passer des commandes (c'est-à-dire que sa vitesse est encore suffisamment élevée), il est presque impossible de travailler sans GPU à des fins de test et d'optimisation.
Vous avez déclaré que j'avais tort à deux reprises et ensuite, sous couvert de preuve, vous avez donné un élément de preuve complètement étranger.
J'ai raison sur le point suivant (qui a été énoncé immédiatement) :
Je n'ai pas du tout mentionné OpenMP. De mon point de vue, OpenMP est une "balle d'argent pour les mauviettes". Si vous vous battez pour de vraies performances, débarrassez-vous des absurdités de l'OpenMP et écrivez à la main du code multithreading initialement correct/natif, profilez-le et poussez-le au maximum.
Vous avez vous-même prouvé qu'il n'y a pas assez de logiciels de calcul par le GPU. La plupart des programmes GPU ne sont que les cas les plus simples, notamment les craqueurs de mots de passe et les mineurs stupides (les jeux ne sont pas abordés).
À mon avis, les processeurs et l'infrastructure sous-jacente évoluent suffisamment vite pour que les performances des GPU soient réellement supérieures à celles des applications réelles. Il y a 3 ou 4 ans, vous auriez pu croire au potentiel des GPU, mais aujourd'hui, c'est devenu clair.
Vous avez déclaré que j'avais tort à deux reprises et ensuite, sous couvert de preuve, vous avez donné un élément de preuve complètement étranger.
J'ai raison sur le point suivant (qui a été énoncé immédiatement) :
Je n'ai pas du tout mentionné OpenMP. De mon point de vue, OpenMP est une "balle d'argent pour les mauviettes". Si vous vous battez pour de vraies performances, laissez tomber les absurdités d'OpenMP et écrivez à la main du code multithreading initialement correct/natif, profilez-le et poussez-le au maximum.
Vous avez vous-même prouvé qu'il n'y a pas assez de logiciels de calcul par le GPU. La plupart des programmes GPU ne sont que les cas les plus simples, y compris les craqueurs de mots de passe et les mineurs stupides (jeux à ne pas discuter).
À mon avis, les processeurs et l'infrastructure sous-jacente évoluent suffisamment vite pour que les performances des GPU soient supérieures à celles des applications du monde réel. Il y a 3 ou 4 ans, vous auriez pu croire au potentiel des GPU, mais aujourd'hui, c'est devenu clair.
1. En extrapolant le taux de croissance des cœurs du processeur hôte, il est peu probable que dans les prochaines années leur nombre atteigne 3000 cœurs comme AUJOURD'HUI une bonne carte vidéo en possède. Et chaque cœur de carte vidéo tourne à environ 1 GHz. Il serait donc impossible pour un processeur hôte de concurrencer le GPU. Mais cela suppose qu'il existe un bon programme capable non seulement de faire fonctionner ces 3000 cœurs, mais aussi de prendre en charge tous les pièges de l'architecture matérielle GPU d'aujourd'hui. Et la vitesse vidéo de la mémoire GDDR5 sur la carte vidéo moyenne d'aujourd'hui est d'environ 150 GBytes/sec. Tous les types de mémoire DDR4 (25 Go/sec) ont encore un long chemin à parcourir.
Comment un processeur hôte peut-il rivaliser avec 40 à 60 cœurs, même à 4 GHz et 25 Gb/s de mémoire ?
2. Toutes sortes d'exotiques comme Phi n'ont pas le support nécessaire et la polyvalence d'une carte vidéo. Par conséquent, ils se sont éteints.
3. sur la nécessité d'une programmation directe en multithreading - oui, je suis d'accord avec vous, mais c'est une tâche ardue . Il est très difficile d'écrire un nouvel algorithme adaptatif complexe en une seule fois dans une version multithread. Et vous devez travailler par évolution, pour ainsi dire. Et d'ailleurs, je n'ai pas besoin de vous dire à quel point Windows gère mal les multithreads lorsqu'ils sont vraiment nombreux (il y a toutes sortes de retards). C'est pourquoi même l'OS a mis au point ce qu'on appelle des fibres - des fils simplifiés.
Conclusion : il n'y a rien de moins cher, de plus prometteur et de plus fiable que le GPU.