"New Neural" est un projet de moteur de réseau neuronal Open Source pour la plateforme MetaTrader 5. - page 58
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
? ??
Ça n'a pas d'importance.
Je veux développer, entendre des opinions différentes et tirer des conclusions.
Je veux évoluer, je veux entendre des opinions et des conclusions différentes.
GPU Cuda est une chose puissante. J'avais un code qui fonctionnait pendant 2 à 3 heures sur 16 pistes Intel (CPU 4 cœurs). Et sur plus de 300 cœurs CUDA, il a parcouru la même distance en 10 minutes, ce qui est impressionnant. Mais le développement du code Kuda était très compliqué : il fallait répartir manuellement tous les calculs du code dans des threads parallèles, optimiser la mémoire (malheureusement, les cœurs Kuda ont peu de mémoire). C'était au-delà de mon pouvoir - un programmeur intelligent m'a aidé. J'ai toujours peur de son code et je continue à faire toutes les modifications dans mon code original (non parallélisé). J'ai développé une opinion : si l'algorithme est stable, il peut être optimisé et transféré sur GPU avec l'aide d'un programmeur compétent - les programmeurs autodidactes comme moi ne peuvent pas le faire. Si vous commencez immédiatement avec le code GPU d'un algorithme bien entraîné, il vous faudra beaucoup de temps pour le contourner. Pour ma part, je commence toujours par un code simple mais non optimal, que je peux comprendre moi-même, et ce n'est qu'après avoir obtenu les résultats escomptés que je commence à l'optimiser. Je suis un désordre, pas un programmeur :)
GPU Cuda est une chose puissante. J'avais un code qui fonctionnait pendant 2 à 3 heures sur 16 pistes Intel (CPU 4 cœurs). Et sur plus de 300 cœurs CUDA, il a parcouru la même distance en 10 minutes, ce qui est impressionnant. Mais le développement du code Kuda était très compliqué : il fallait diviser manuellement tous les calculs du code en threads parallèles, optimiser la mémoire (malheureusement, les cœurs Kuda ont peu de mémoire). C'était au-delà de mon pouvoir - un programmeur intelligent m'a aidé. J'ai toujours peur de son code et je continue à faire toutes les modifications dans mon code original (non parallélisé). J'ai développé une opinion : si l'algorithme est stable, il peut être optimisé et transféré sur GPU avec l'aide d'un programmeur compétent - les programmeurs autodidactes comme moi ne peuvent pas le faire. Si vous commencez immédiatement avec un code GPU pour un algorithme bien entraîné, il vous faudra beaucoup de temps pour le contourner. Pour ma part, je commence toujours par un code simple mais non optimal, que je peux comprendre moi-même, et ce n'est qu'après avoir obtenu les résultats escomptés que je commence à l'optimiser. Je suis un désordre, pas un programmeur :)
C'est pourquoi nous aimerions avoir l'avis d'un spécialiste dans le domaine du calcul par le GPU. yu-sha et JavaDev, ay !
Intéressé par les questions suivantes :
1. Quels aspects doivent être examinés en premier lieu lors de la création d'un projet (ou de ses modules individuels) fonctionnant sur GPU, afin d'éviter le processus fastidieux de le refaire à l'avenir ?
2. Quelles sont les limites de mémoire pour les cœurs de GPU ? Est-il possible de mettre en mémoire la totalité du code d'exécution (des dizaines et des centaines de milliers de barres) ?
Jusqu'ici, des questions générales. D'autres plus détaillées, je suppose, viendront plus tard.
Nous aimerions donc avoir l'avis d'un expert en calcul par le GPU. yu-sha et JavaDev, ow !
Intéressé par les questions suivantes :
1. Quels sont les aspects auxquels il faut prêter attention en premier lieu lors de la création d'un projet (ou de ses modules individuels) sur GPU afin d'éviter les remaniements gênants à l'avenir ?
2. Quelles sont les limites de mémoire pour les cœurs de GPU ? Est-il possible de mettre en mémoire l'ensemble du code d'exécution (des dizaines et des centaines de milliers de barres) ?
Jusqu'ici, des questions générales. D'autres plus détaillées, je suppose, viendront plus tard.
Pourquoi s'embêter avec un cuda dans un projet destiné à un usage général ? Certains utilisateurs ont un cuda, d'autres en ont un autre et d'autres encore n'en ont pas du tout. Par exemple, je n'ai pas de cuda sur mon ordinateur portable au travail. Le même code réseau sera très différent selon le nombre de cœurs dans le cuda et la mémoire. Il vaut mieux d'abord écrire ce moteur de mise en réseau pour les processeurs Intel normaux afin que tout le monde puisse l'utiliser, et ensuite l'optimiser pour Kuda si cela a un sens. À ce propos, il est préférable de créer le moteur de manière à ce qu'il fonctionne dans le nuage. Je ne suis pas familier avec le cloud computing. Il y a quelque chose là-dedans ?
Pourquoi s'embêter avec un cuda dans un projet destiné à un usage général ? Certains utilisateurs ont un cuda, d'autres en ont un autre et d'autres encore n'en ont pas du tout. Par exemple, je n'ai pas de cuda sur mon ordinateur portable au travail. Le même code réseau sera très différent selon le nombre de cœurs dans le cuda et la mémoire. Il vaut mieux d'abord écrire ce moteur de mise en réseau pour les processeurs Intel normaux afin que tout le monde puisse l'utiliser, et ensuite l'optimiser pour Kuda si cela a un sens. À ce propos, il est préférable de créer le moteur de manière à ce qu'il fonctionne dans le nuage. Je ne suis pas familier avec le cloud computing. Y a-t-il un endroit quelconque ?
MQ a promis de prendre en charge OpenCL dans MQL5, mais pas CUDA (uniquement les cartes graphiques de nVidia). OpenCL peut fonctionner sur tout matériel doté de processeurs multi-cœurs, ce qui inclut les CPU et les GPU (AMD, nVidia et intel). Ainsi, un projet qui prend en charge les calculs à la fois sur le CPU et le GPU conviendra à tout le monde.
Comme MQL5 prendra en charge OpenCL, cela signifie que les agents en nuage prendront en charge le calcul par le GPU.
Urain:
Vous ne pouvez pas toujours avoir raison, c'est à cela que sert le projet Open Source, à argumenter, à prouver.
Nous aimerions donc avoir l'avis d'un expert en calcul par le GPU. yu-sha et JavaDev, ow !
Intéressé par les questions suivantes :
1. Quels sont les aspects auxquels il faut prêter attention en premier lieu lors de la création d'un projet (ou de ses modules individuels) sur GPU afin d'éviter les remaniements gênants à l'avenir ?
2. Quelles sont les limites de mémoire pour les cœurs de GPU ? Est-il possible, en principe, de placer l'ensemble du code exécutable sur un historique distinct exécuté en mémoire (des dizaines et des centaines de milliers de barres) ?
Jusqu'ici, des questions aussi générales. D'autres plus détaillées, je suppose, seront ajoutées plus tard.
Les principaux points sont les suivants :
1) Les GPU ne sont nécessaires que pour la formation.
2) Une augmentation significative des performances est obtenue par le calcul parallèle des valeurs des neurones dans une couche et, plus important encore, par l'exécution simultanée de centaines de réseaux.
Découpage maximal du projet en éléments autonomes - voici ce qu'il faut rechercher
La mémoire DDR du GPU est plus que suffisante pour stocker l'historique de centaines de milliers de barres.
La mémoire centrale est sévèrement limitée (30-50Kbytes). Une programmation simple résout également ce problème - cela en vaut la peine car la mémoire de la puce fonctionne à la fréquence du cœur et y accéder ne coûte aucun cycle d'horloge. Il y a aussi des conflits de banques de mémoire du noyau, ils contournent cela aussi.
Il y a une chose désagréable avec la fonctionnalité de Windows - les pilotes se réinitialisent si une exécution dure >~ 5 secondes.
Ainsi, le maximum que nous puissions obtenir est la formation de 100-200 réseaux de ~100 neurones pour 100k barres d'histoire.
Avec cette configuration (maximale), nous obtenons une vitesse d'optimisation de ~ 20-30 passages par seconde sur un GPU GTX 460.