Reprise du message précédent :

Il me semble que dans Gpu Gems 2 ils en parlent, en utilisant une indirection avec une texture et quelques subtilités en plus pour conserver une localité décente, c'est pas aussi efficace que du dense mais ça reste ptêtre intéressant.

tu dois avoir un remplissage merdique et une coallescence dramatique
Et de toute façon, si c'est pour ce casser à faire ça et avoir un gain de 8, autant le faire sur du quad-core avec des outils qui marchent

Ok, merci du conseil. Donc comme "outils qui marchent" pour du quad-core, tu préconiserais quoi? Ce que tu m'a dis précédemment, LAPACK tuné pour mon archi (atlas en SSE2 par exemple)?

LAPACK pour du tout fait validé qui dépote.
 
si tu tiens à rigoler en implantant un SVD parallele tout seul : OpenMP ou boost::thread pr les threads, NT² pr l'aspect SIMD automatique.
Et bon courage

Mon conseil : Cuda est une magnifique techno, peline d'avenir, mais attendez encore un peu avant de vous lancer, que ca mûrisse un peu. C'est une techno d'avenir, encore légèrement jeune, mais qui sera bientôt prête.

Ca fonctionne très très très bien, mais par contre :

• L'allocation mémoire est encore bugguée : Le pilote qui connait pas encore ses limites (et qui vous autorise à allouer de la mémoire dans le pilote aéro de vista... qui va donc vous faire crasher votre magnifique appli, sans warning, sans rien, tout accès ram est revenu à 0 quand vous allez dans les 40 derniers Mo de la carte). Exemple : le driver vous raporte 950Mo de libre, allouez que 900Mo, sinon, crash... et des fois, vous pouvez aller jusque 970Mo (sous XP32 par exemple )
• Les versions ne tournent pas sur toutes les cartes (cf Cuda 2.0 qui ne tournent pas sur les G80 première génération... dommage)
• certaines limites "étranges" (pas plus de 4096 cudaMallocs sous Vista sinon crash)
• un comportement erratique sous vista justement (bon, c'est le point 1 et 3 combinés).

Par contre, une fois stabilisé, ce sera clairement quelque chose de fantastique. Mais cela souffre encore d'erreurs de jeunesse AMHA.

Utilisez-la, mais évitez pour le moment de faire comme moi et d'aller dans les limites et de titiller les bornes de l'allocation mémoire, ou vous aurez des surprises...

surtout que ca se standardise vraiment autour d'openCL.

openCL

Tu fais quoi avec, Tetedeiench ?

http://forum.hardware.fr/hfr/Overc [...] 7556_1.htm

Je sais pas si c'est passé, mais il y a une belle série d'articles sur Dr Dobb's:
http://www.ddj.com/hpc-high-perfor [...] /207200659

Encore des benchs foireux
Ils oublient de dire que sur le Q6700, SSE2+OpenMP vont à peu prés aussi vite que leur x12 quoi pour un effort similaire et plus portable.

Le jour ou NVIDIA et consort arreteront leur mauvaise fois, on y verra plus clair.

Et le priceless :

Chez moi, on doit FORCEMENT mesurer des HFLOPS sinon ca sert à rien

c'est un monstre cette tesla.

salut!
je suis un débutant en CUDA. j'ai une carte GPU EN9800GT, j'ai téléchargé cuda toolkit 2.3 et le cuda sdk 2.3 comme dans les instructions d'installation. là j'essaye de compiler et exécuter le projet template fourni avec les sources mais ça marche pas. je me pose donc la question: la carte GPU accepte-t-elle deux "entrées" à la fois (l'écran branché à la GPU et les algorithmes qu'on lui envoie)?  
quelqu'un a une petite idée SVP?
 
ps: je travaille sur win XP 32bits et VS2008.

Oui, la carte accepte les deux entrées. Par contre c'est pas supporté pour VS2008 il me semble, lu ici : http://codereflect.com/2008/09/26/ [...] -visual-c/

 
openCL :    
 
au moins c'est portable et standard...
 
ca m'a tj fait marrer les devs trop proches du hard : en général ils pronent des solutions non évolutives.
 
le hard s'adapte au soft, et non l'inverse.
 
les jeux ps3 tournent bien et les devs ne s'amusent plus a optimiser le placement des pixels en mémoire.
 
les seules technos viables sur le long terme sont des standards et ouverts de surcroit.
 
le reste périt obligatoirement du fait de la complexité inutile engendrées et des difficultés rencontrées.
 
arm, x86, http, c, fortran, xvid, dvd
 
vs wma, aac, atrac, les disquettes amstrad, les nombreux ports video des macs, 3dfx et le glide, ...
 
et il est impératif de ne jamais mettre tous ses oeufs dans le meme panier, ce conseil est digne de la  
ménagère et pourtant, s'applique bien ici, sinon on n'a plus de comparaison par exemple possible pour  
l'execution d'un code...
 
toutes les bibs d'opti à terme seront en language standard, ce qui permet de surcroit de comparer deux
archis à code constant, et d'illustrer le rôle du compilateur.
 
En bref remettre ce paradigme à zéro c'est revenir en arrière et s'auto limiter pour le futur.
 
Et avant de cracher sur openCL essaie de savoir si il permet de coder efficacement ce que tu veux faire...
 
 

 
il y a d'autres topic sur la programmation gpu (en particulier opencl) ou c'est le seul

 
Avant de parler renseigne toi

 
y a que celui la, poses ta question

j'avais pas spécialement de question pour l'instant (débutant-inside) mais au cas où : est-ce qu'il y a déjà de bonnes librairies opencl (pas trop pourraves à prendre en main et efficaces en temps calcul) de résolution de gros systèmes linéaires prêtes en gpu ou est-ce que je suis bon pour finir le code que j'ai commencé ?

edit: j'ai vu qu'en cuda il y avait un cula pour ça mais je préfère tenter ma chance sur opencl

openCL est encore tres peu mature. Y a pas mal de chose faites en CUDA avec des performances corrects.

“Believe it or Not! Multi-core CPUs Can Match GPU Performance for FLOP-intensive Application!”
 
Un chouette article, avec très certainement des choses discutables dans l'implémentation CUDA, mais rafraîchissant.

\o/ enfin

il a pris une gtx 285, il a donc plafonné à 720 Glops.
Avec une Gtx 480 il serait monté à 1.3 TFlops et donc sa publi elle serait passée à la trappe.

Figure 1 : Apprendre à GrosBoc la notion de délai de publications ...

Figure 2 : "c'est moi qui est le plus gros flop..."

aussi ^^

A la même époque, il pouvait le faire avec des Tesla.      

Tesla qui avait encore le probleme de Dual Issues.

pour changer, une vraie question GPU : sous opencl il y a un truc que j'ai du mal à comprendre c'est le rôle du local_work_size dans le EnqueueNDRangeKernel

d'après ce que j'ai vu on peut mettre NULL et dans ce cas il gère par défaut, mais d'après les tests que j'ai fait selon la taille du problème à faire tourner il vaut mieux mettre un local_work_size >0 et dans ce cas global_work_size=n * local_work_size... mais ça ne change absolument pas la valeur du global_work_size qui correspond toujours à la vraie taille de mon problème ! dans ce cas comment on gère le local_work_size

Les spec d'openCL 1.1 sont sorties.

 
Effectivement, openCL gère tout seul ces aspects, par défaut.
De tête parce que je n'ai pas les documents sous la main, ton local_work_size c'est le nombre de threads par blocs dans la dénomination utilisée par cuda : 32, 64, 128, 256, 512, (1024).
Ton global_work_size c'est la taille de tes données.

 
C''est infernal, ya pas moyen de suivre.

 
c'est cette version qui doit enfin gérer les chargements en mémoire décalés de kernels ?
 

 
pour les valeurs du local_work_size j'ai testé avec un peu n'importe quoi (du moment que c'était inférieur à la valeur  512 indiquée par ma carte et que c'était un diviseur du global_work_size) et la seule différence que j'y ai vu  c'était que sur NULL j'avais pour des données assez grosses une segmentation fault et que pour d'autres valeurs j'arrivais à les faire passer... ça ne m"aide pas à comprendre comment ça marche et comment le calibrer automatiquement

Je te laisse vérifier par toi même:
http://www.khronos.org/registry/cl [...] cl-1.1.pdf    

Bonjour tout le monde,
 
J'aimerais savoir si l'emplacement est adéquat à ma question :
J'aimerais de l'aide pour porter un programme c++ très parallélisable , sur ma 8800 GTS 512, qui doit probablement savoir exécuter le code plus vite que mon processeur. CUDA étant une facon de le faire si j'ai bien compris.
 
Merci, n'hésiter pas à me rediriger si je ne me trouve pas dans le bon thread    (Celui ci me semblait être le plus propice à me répondre).

Vazy, balance...

Je sais que c'est pas facile à lire comme code, je suis pas très doué mais voilà, ca me fait plaisir si vous pouvez m'aider.
 
Pour ceux que ça intéressent : à la base c'est un problème de calcul d’électromagnétisme, mais ne vous intéressez pas à la formule qui se trouve au final dans la condition, vous n'allez probablement rien comprendre (c'est normal ^^).
 
Edit : Je vous remercie d'avance    
 

Effectivement, ça semble être un cas d'école. Je ne vais pas écrire le programme pour toi, mais tu devrais pouvoir y arriver simplement en suivant les exemples donnés par le guide de programmation.  
 
Ici, ton problème se prête bien à une parallélisation mono-dimensionnelle : tu vas te contenter d'écrire la fonction qui est dans la première boucle for sous forme de fonction cuda, et demander à 100 000 noyaux de l'exécuter.
 
Tu devras cependant faire une petite modification, dans la façon dont tu gères tes différentes matrices de valeurs possibles (d'ailleurs je ne suis pas sûr que ce soit très pertinent, même dans le cas présent) : plutôt que de calculer les valeurs dans la phase d'initialisation, et de les stocker en mémoire, il sera nettement plus rentable de les faire calculer au fur et à mesure des calculs par chacun des fils d'exécution de ton gpu. L'expression de chacun de tes vecteurs en fonction de i, j, k et l est triviale. Ça t'évitera des accès mémoire dans la mémoire globale au coût prohibitif.
 
(De façon général, déjà que c'est mal de programmer en français, c'est pire si on fait des fautes d'orthographe. Et c'est vraiment très inélégant ces deux boucles for de construction et d'utilisation des vecteur, en plus d'être source à des erreurs d'exécution.)

 
avant de penser à cuda, un peu de refactorisation peut pas faire de mal.
 
- resize() un bon coup et []= au lieu de faire des push_back
- dans ton if, t'as moultes termes utilisées plusieures fois, utilise des variables pour les évaluer une seul fois.
 
- si ce que tu mets dans tes vectors sont bien des constantes stupides (ie i/100.0), alors benne tes vectors, et utilise un for( double truc =  0 ; .... ; truc += 0.01 ) ou le /100 dans la boucle. éjecte un max d'accès mémoire.

Reserve et non resize à ce compte là
 
(mais benner les vecteurs, c'est mieux )

Bonsoir messieurs,
Je suis heureux de voir que vous répondez
 
Alors à mon tour :
 
hephaestos :  
>> Tu me conseils de voir "les exemples donnés par le guide de programmation", mais quel guide ? Le guide CUDA sur le site nVidia officiel ?
>> "Il sera nettement plus rentable de les faire calculer au fur et à mesure des calculs par chacun des fils d'exécution de ton gpu. Ça t'évitera des accès mémoire dans la mémoire globale au coût prohibitif." Je prends note, merci.
>> "Et c'est vraiment très inélégant ces deux boucles for de construction et d'utilisation des vecteur." Je ne suis pas sûr de comprendre. Penses-tu qu'il serait plus intelligent de ne pas créer de vecteur et d'utiliser des valeurs qui seront générées au fur et à mesure de leur appellation ?
(>> Pour la langue française je suis conscient que je ne suis pas une bête, veux tu bien me préciser où se trouvent mes erreurs ? Ça m'aidera à les corriger, merci.)
 
bjone :
>> Je suis pour toute simplification ! Je vais voir ce que je peux faire au niveau de la factorisation. C'est vrai que j'ai balancé la formule comme calculée directement sans penser à la simplifier au maximum.
>>  Pour le resize() je me demande si en fait, il ne serait pas mieux de manipuler des vecteurs de taille fixe ( des tableaux ). Qu'en pensez vous ?
>> pour la boucle for et les /100, j'avais jamais pensé à utiliser autre chose que des nombre entiers je dois vous avouer ^^, je vais donc faire ceci :
for(double i = 0; i < C; i += 0.01){...}
Quel vision étroite de ma part !
 
J'ai apprécié tous vos commentaires et suggestions, et je vous en remercie.
 
PS : je crois que je vais virer les vecteurs, ils servent à rien en fait... j'essaye de faire un code trop propre mais là pour du calcul comme ça, je perds trop en performance.
 
J'ai vu le temps que ça me prenait sur mon Q6600 @ 3.6 GHz, il me faut 11 ans... Mais c'est sans parallélisation.