Archi GPU et GPGPU

[Møgluglu]

Intel a publié les specs de ses contrôleurs graphiques :
http://intellinuxgraphics.com/documentation.html

C'est une doc complète, contrairement à ce qu'a publié AMD jusqu'ici...

Je l'ai juste parcourue rapidement, mais il y a des choses intéressantes dans le volume 4 (unités programmables). En particulier :

• plusieurs modes de fonctionnement SIMD, horizontaux et/ou verticaux,
• des communications par messages entre les unités, y compris juste pour calculer une racine carrée,
• des accumulateurs entiers 8*64bits, 16*33bits ou flottants 8*(54+8) bits, qui permettent de faire des FMA () et calculer toutes sortes de choses précisément (sommes, somme de différences absolues, produits scalaires, polynômes...),
• des exceptions (mais pas vraiment de triggers intéressants),
• une infrastructure pour les debuggers (breakpoints, snapshots),
• divers modes d'accès mémoire plus ou moins exotiques comme on peut en attendre d'un GPU...

[Lissyx]

J'ai entendu parler (sur linuxfr je crois), d'un mode de fonctionnement pour calculer des trucs pour l'encodage vidéo.

[Møgluglu]

Pour la vidéo, il y a une petite partie fixe, principalement pour les premières étapes du décodage MPEG-2. Pour tout le reste, on utilise les unités programmables.

Du coup, l'ISA de ces unités est conçue à la fois pour les calculs 3D et vidéo. Probablement au dépends de la puissance de calcul géométrique et de texturage : ça semble un peu léger par rapport aux unités du G80...
(mais bon, on s'y attendait)

[Lissyx]

Mais accélérer l'encodage vidéo avec les GPU, ça peut être intéressant, non ?
Vu la parallélisation dans ces machins, si on combine entre ça et un système SMP ...

[Neo_13]

pourras t on utiliser les fonctions de calcul du GMA tout en utilisant une CG sur le PCIe ?

[Møgluglu]

Mais accélérer l'encodage vidéo avec les GPU, ça peut être intéressant, non ?
Vu la parallélisation dans ces machins, si on combine entre ça et un système SMP ...

Dans le cas d'Intel, ça semble effectivement avoir été prévu dés le départ. Vu que les unités de calcul ne sont pas spécifique à un algo de décodage vidéo particulier, on peut aussi bien s'en servir pour de l'encodage.
Après c'est pas sûr que ça vaille le coup de faire de l'encodage sur un GMA X3100 si on a un Yorkfield à côté. Sur un G92 avec Cuda ça devrait être plus intéressant, mais on n'a pas les features du GMA comme le SIMD "rectangulaire" ou l'accumulateur long DSP-like.

pourras t on utiliser les fonctions de calcul du GMA tout en utilisant une CG sur le PCIe ?

Officiellement, non. D'après les datasheets des G965 et G35, il semble qu'on puisse mettre une carte non graphique dans le PCIe, ou des cartes graphique en PCI (ou dans les slots PCIe de l'ICH?), mais pas de CG PCIe.

[Lissyx]

Dans le cas d'Intel, ça semble effectivement avoir été prévu dés le départ. Vu que les unités de calcul ne sont pas spécifique à un algo de décodage vidéo particulier, on peut aussi bien s'en servir pour de l'encodage.
Après c'est pas sûr que ça vaille le coup de faire de l'encodage sur un GMA X3100 si on a un Yorkfield à côté. Sur un G92 avec Cuda ça devrait être plus intéressant, mais on n'a pas les features du GMA comme le SIMD "rectangulaire" ou l'accumulateur long DSP-like.

Pas intéressant parce que moins puissant qu'un Yorkfield ? Peut-être. Mais ça peut apporter un gain de temps quand même. Yorkfield+GMA ça irait sûrement encore un poil plus vite que Yorkfield tout seul

Après, est-ce que le gain est probant, c'est une autre question.

[DJ_DaMS]

Officiellement, non. D'après les datasheets des G965 et G35, il semble qu'on puisse mettre une carte non graphique dans le PCIe, ou des cartes graphique en PCI (ou dans les slots PCIe de l'ICH?), mais pas de CG PCIe.

Sérieux? A l'epoque du 915, j'avais essayé un HBA Fiber Channel PCIe (8x je crois) dans le PCIe 16x normalement dédié à la carte graphique, ça foirait completement... C'est bon a savoir qu'on puisse mettre autre chose qu'une CG dans ce slot à présent... (Désolé pour le HS)

[Møgluglu]

La doc de l'i915 semble dire qu'on peut mettre des cartes non-graphiques, mais que ça tournera seulement en PCIe 1x. Après il faut aussi que le bios et les drivers le supportent, j'imagine.

[Møgluglu]

Pour revenir au sujet initial (vous me dites si je vous gonfle avec mes GPU), ça complète le paysage de l'archi des unités programmables des GPU :

• nVidia G80
  - Exécution superscalaire out-of-order sur 2 voies : MAD et MUL+special
  - Vecteurs SIMD architecturaux de taille 32 (plus ou moins splittables en 2x16 pour les branchements).
  - 8 unités de calcul par coeur en double vitesse.
  - Mots d'instruction de 32 ou 64 bits.
  
• AMD R600
  - VLIW à 6 voies : 4xMAD, 1xMAD+special, 1xbranch
  - Vecteurs SIMD architecturaux de 64.
  - 16 unités par coeur.
  
• Intel GMA X3100
  - Exécution scalaire in-order.
  - Largeur SIMD architecturale configurable entre 4 et 16.
  - 4 unités de calcul en 32-bits ou 8 en 16-bits.
  - Mots d'instruction de 128 bits.

(sources : à moitié de mémoire, à moitié Beyond3D, non garanti)

Les GPU d'Intel sont fort logiquement plus légers en unités de calcul, mais plus souples, en particulier pour le calcul entier.
Ensuite arrive nVidia avec son mini superscalaire OOO et ses SIMD un peu plus larges, et enfin AMD avec l'artillerie lourde...

[fefe]

Interessant, je n'avais jamais fait le rapprochement que G80 vs R600 correspondait au traditionnel duel entre OOO superscalaire et VLIW. Presente comme ca le GMA intel semble aussi une generation en retard (generation au sens large pas au sens revision).

[Møgluglu]

Oui, et c'est pour ça que je ne comprend pas trop le choix de l'exécution in-order pour Larrabee. (parenthèse)
Surtout sur du X86, c'est des archis et des perfs d'un autre âge, même Via en est sorti...

Le GMA a au moins le mérite d'avoir un jeu d'instruction adapté à son mode d'exécution, avec beaucoup de registres, de la prédication et des accès mémoire bien contrôlés (masquage de latence explicite). Le même genre d'archi avec du X86 ça devrait tourner à la vitesse d'un C3...

Edit: au fait, un superscalaire SIMD, c'est un supervectoriel?

[Neo_13]

Oui, et c'est pour ça que je ne comprend pas trop le choix de l'exécution in-order pour Larrabee. (parenthèse)
Surtout sur du X86, c'est des archis et des perfs d'un autre âge, même Via en est sorti...

Le GMA a au moins le mérite d'avoir un jeu d'instruction adapté à son mode d'exécution, avec beaucoup de registres, de la prédication et des accès mémoire bien contrôlés (masquage de latence explicite). Le même genre d'archi avec du X86 ça devrait tourner à la vitesse d'un C3...

Edit: au fait, un superscalaire SIMD, c'est un supervectoriel?

ouais, mais l'OoO consomme du transistor... Or quand on a 16+ cores simplifiés possibles et une grosse expérience du VLIW, peut être que tenter ce coup là est un bon plan en termes d'opti de la conso en transistors...

Evidement les perfs en INT vont s'en ressentir (si on prend en compte les perfs d'EPIC en INT), mais je ne crois pas que Larrabee sera un CPU, donc il pourrait se charger quasi exclusivement de FLOAT (de la même façon, si on regarde EPIC, pourtant In Order, qui arrache quasiment tout ce qui existait en float). En faisant également l'exécution simultanée plutot que la prédiction des branchements, on doit pouvoir s'en sortir pas mal (en prenant garde aux dénormaux quand même) avec masse de core (et il n'y a pas vraiment de raison de se limiter à 16cores quand chaque core fait moins de 5M transistors... Quoique, avec le cache ils feront probablement un peu plus, mais ça devrait rester très raisonnable/core).

[Møgluglu]

ouais, mais l'OoO consomme du transistor... Or quand on a 16+ cores simplifiés possibles et une grosse expérience du VLIW, peut être que tenter ce coup là est un bon plan en termes d'opti de la conso en transistors...

Quand on regarde une 8800 GT, ce n'est pas si évident que ça. Un OoO léger (2 voies, tampons de réordo d'une douzaine d'instructions) ne coûte pas si cher que ça et permet déjà de nettement soulager les compilateurs. Surtout qu'on fait du SIMD, donc pour 1 seule instruction lue on a 16 à 64 calculs à faire. Donc on a besoin de bien moins d'unités de fetch/decode/pick à plus faible fréquence que d'unités de calcul.

Et puis si on parle de VLIW, on est plus en X86. Du VLIW in-order ça peut bien marcher si le compilo suit, mais du X86 in-order ça ne me convainc vraiment pas.

Evidement les perfs en INT vont s'en ressentir (si on prend en compte les perfs d'EPIC en INT), mais je ne crois pas que Larrabee sera un CPU, donc il pourrait se charger quasi exclusivement de FLOAT (de la même façon, si on regarde EPIC, pourtant In Order, qui arrache quasiment tout ce qui existait en float).

EPIC est un bon exemple d'archi in-order qui demande beaucoup plus de ressources en surface et conso que du X86 OoO...

En faisant également l'exécution simultanée plutot que la prédiction des branchements, on doit pouvoir s'en sortir pas mal (en prenant garde aux dénormaux quand même)

avec masse de core (et il n'y a pas vraiment de raison de se limiter à 16cores quand chaque core fait moins de 5M transistors...

Ce que tu décris ressemblerait plus à Niagara qu'à un GPU...

La caractéristique no 1 du GPU est d'être SIMD, donc le nombre de coeurs ne veut rien dire en soi (le R600 avec 4 coeurs à 5x16 unités a plus de puissance théorique que le G80 avec 16 coeurs à 8 unités (le "320 scalar units" d'ATI )).

C'est un compromis à trouver dans un espace à plusieurs dimensions :
- la largeur SIMD
- la largeur du VLIW/superscalaire
- le nombre de cores

Mais c'est vrai que la tendance jusqu'ici chez les GPU a été à la diminution de la largeur SIMD et à l'augmentation du nombre de cores, pour permettre plus de souplesse dans les branchements. Le G80 n'est plus qu'à un facteur 4 du SSE (autrement dit, il faudra au moins 64 cores SSE pour simplement égaler la puissance théorique du G80, ou bien élargir le SSE et tomber dans les mêmes travers que les GPU).

[fefe]

Le OOO ne coute pas tant que ca, le probleme de Larrabee est qu'il part avec la taxe x86, le nombre minimal de transistors pour decoder du x86 et etre compatible avec une archi dont le manuel fait 5 bouquins enormes. Quand tu parts avec une telle taxe, il faut faire des tradeoffs pour arriver a un chip qui reste essentiellement domine par des transistors de calcul plus que par des transistors destines a ameliore l'efficacite des calculs (un CPU actuel est domine par les 2nds).

[Yasko]

1,$s/taxe/tare/g

[Alice]

nVidia G80
- Exécution superscalaire out-of-order sur 2 voies : MAD et MUL+special
- Vecteurs SIMD architecturaux de taille 32 (plus ou moins splittables en 2x16 pour les branchements).
- 8 unités de calcul par coeur en double vitesse.
- Mots d'instruction de 32 ou 64 bits.

Møgluglu, super intéressant ce petit récapitulatif des archi des GPU. En ce qui concerne le G80 j'ai quelques intérrogations/précisions/corrections suivant que je me gourre ou non ?

Il me semble que le G80 est composé de 128 ALUs scalaires FP32 MAD+MUL dual issue splittées en 8 clusters de 16 ALUs. Comme chaque cluster peut exécuter des instructions différentes on peut donc y voir une organisation en 8-way MIMD ou des clusters en 16-way SIMD. En fait, chaque cluster est a nouveau splitté en 2 groupes de 8 ALUs et chaque groupe peut travailler sur des données/instructions différentes. Au final on peut y voir 2 8-way SIMD par cluster. Un scheduler par cluster se charge de répartir le travail. Chacun de ces groupes de 8 ALUs FP32 MAD+MUL dual issue est couplé à 8 ALUs FP32 qui se charge de l'interpolation de scalaires et des opérations spéciales (=> plus on utilise d'opérations spéciales moins en a de puissance d'interpolation).

Enfin le dual issu MAD+MUL est plutôt utopique sachant que ce dual issu est quasiment impossible à programmer. Le MUL est utilisé principalement après l'interpolation pour effectuer la division perspective (perspective correct interpolation).

[fefe]

Enfin le dual issu MAD+MUL est plutôt utopique sachant que ce dual issu est quasiment impossible à programmer. Le MUL est utilisé principalement après l'interpolation pour effectuer la division perspective (perspective correct interpolation).

Je suppose que tu peux avoir un thread en train de faire une transformation avec le MAD pendant qu'un autre est en train de faire des muls pour la "division perspective" (je ne suis pas sur de ce que tu entends par division perspective ? normalisation ?)

[Alice]

Je suppose que tu peux avoir un thread en train de faire une transformation avec le MAD pendant qu'un autre est en train de faire des muls pour la "division perspective" (je ne suis pas sur de ce que tu entends par division perspective ? normalisation ?)

Je suppose aussi... ceci dit une division perspective est bcp moins souvent solicité qu'une opération de MUL classique et pourrait être directement intégré aux ALUs d'interpolation par exemple. Qt à la division perspectice c'est effectivement la normalisation effectuée pour transformer les sommets dans l'espace du device normalisé. Elle sert aussi à interpoler correctement les paramètres de sommets lors de la rastérization du triangle. Je peux linker quelques papiers qui expliquent le tout et qui démontrent que la rastérization à la Quake c'est la préhistoire mais c'est "bcp hors sujet"

[Møgluglu]

Møgluglu, super intéressant ce petit récapitulatif des archi des GPU.

Merci

En ce qui concerne le G80 j'ai quelques intérrogations/précisions/corrections suivant que je me gourre ou non ?

Il me semble que le G80 est composé de 128 ALUs scalaires FP32 MAD+MUL dual issue splittées en 8 clusters de 16 ALUs. Comme chaque cluster peut exécuter des instructions différentes on peut donc y voir une organisation en 8-way MIMD ou des clusters en 16-way SIMD. En fait, chaque cluster est a nouveau splitté en 2 groupes de 8 ALUs et chaque groupe peut travailler sur des données/instructions différentes. Au final on peut y voir 2 8-way SIMD par cluster.

Ce qui est sûr c'est qu'on a une archi 8x2x8. La question c'est si c'est un MIMD (8x2) x SIMD 8 ou un MIMD 8 x SIMD (2x8).

J'ai l'impression (je me gourre peut-être) que les 2 groupes d'un cluster partagent le même cache d'instruction et doivent obligatoirement exécuter le même shader/programme. Par contre, il pourraient suivre des branchements différents dans ce programme (granularité de branchement de 16 dans les vertex shaders et Cuda, soit 8 unités double vitesse).

Un scheduler par cluster se charge de répartir le travail. Chacun de ces groupes de 8 ALUs FP32 MAD+MUL dual issue est couplé à 8 ALUs FP32 qui se charge de l'interpolation de scalaires et des opérations spéciales (=> plus on utilise d'opérations spéciales moins en a de puissance d'interpolation).

Je ne vois pas le découpage comme ça. Pour moi on a 2 ports d'exécution :
- 8x ALU MAD
- 2x ALU spéciales/interpolation de quads/(4x?)MUL

Le débit des fonctions spéciales est inférieur d'un facteur 4 à celui du MAD.

Pour le 4x devant le MUL, il me semble que c'est à partir du G86/G84, et que le G80 n'a qu'1 (ou 2?) MUL. Sur un post du forum de Beyond3D que je ne retrouve plus quelqu'un avait colorié les datapaths de l'unité multifonction d'Oberman [1] pour faire apparaître 1 ou 2 multiplieurs flottants.
Il est probable qu'ils aient étendu les multiplieurs depuis pour faire 4 muls sur le G84.

C'est cohérent avec les quelques tests que j'avais fait avec Cuda - et Decuda [2] sur G86.
Mes test montraient que les choses ressemblaient beaucoup à ce qui est décrit dans les brevets [3] et [4], sauf que :
- la longueur du buffer d'instruction est de l'ordre de 10-12 (à peu près l'équivalent de 2x la longueur du pipeline d'exécution double vitesse).
- l'instruction réduction d'argument RRO est apparemment implantée dans l'unité spéciale/interpolation et pas dans le MMAD. [Re-edit: là je confonds peut-être, à vérifier.]

[1] Oberman, Siu. A High-Performance Area-Efficient Multifunction Interpolator. Arith 17, 2005 http://pctuning.cz/ilustrace3/soucek/G80/paper-164.pdf
[2] Decuda http://www.cs.rug.nl/~wladimir/decuda/
[3] http://appft1.uspto.gov/netacgi/nph-...DN/20070130447
[4] http://www.google.com/patents?id=aB-...BAJ&dq=7225323

Edit: pour les prises de têtes sur le scheduling d'instruction sur le G80, ce topic est pas mal :
http://forum.beyond3d.com/showthread.php?t=37977
(bien que j'ai l'impression que ça manque un peu de confrontation avec la réalité...)

[fefe]

Qt à la division perspectice c'est effectivement la normalisation effectuée pour transformer les sommets dans l'espace du device normalisé.

C'est bon je vois ce que c'est, mon background en 3D a 10+ ans donc je comprends les "vieux" termes. Pour les interpolations lors de la rasterisation, c'est l'interpolation des normales pour le shading a la phong ou autre chose?

[Alice]

J'ai l'impression (je me gourre peut-être) que les 2 groupes d'un cluster partagent le même cache d'instruction et doivent obligatoirement exécuter le même shader/programme

Tu as raison. Après une brève vérification (pas dutout sur donc) un cluster éxécute un même programme pour un cyle donné.

Pour le découpage des ALUs et sauf si j'ai tout compris à l'envers, il se peut très bien que tu aies raison. Les ALU dual issue FP32 MAD+MUL viennent en grande parti du discours d'NVIDIA et se plaque bien sur la puissance théorique avancée. Vu qu'il semblerait que ce dual issue soit difficilement vérifiable en pratique (si ce n'est pour la division perspective), ton découpage n'est pas idiot

C'est bon je vois ce que c'est, mon background en 3D a 10+ ans donc je comprends les "vieux" termes. Pour les interpolations lors de la rasterisation, c'est l'interpolation des normales pour le shading a la phong ou autre chose?

C'est pour une "perspective correct interpolation" de tous les paramètres des sommets du triangle. Donc ça comprends le Z pour mettre à jour le Z-test/Z-buffer, les coordonnées de textures, les couleurs...etc et les normales aussi si elles sont définies par sommet (=> pas de bump mapping).

[Møgluglu]

Vu qu'il semblerait que ce dual issue soit difficilement vérifiable en pratique (si ce n'est pour la division perspective), ton découpage n'est pas idiot

Je ne sais pas pour les shaders, mais avec Cuda j'arrive souvent à atteindre un débit de 1,5 pour les MUL (i.e. 6x32 MUL en 16 cycles) sans optimisation particulière à la main.

Pour les ALU/FPU, ça me parait assez cohérent et je suis d'accord avec moi-même.
Après la vraie inconnue du G80 reste l'organisation du banc de registres. Apparemment c'est ça le facteur limitant pour le scheduling d'instruction.
(Les dépendances entre instructions peuvent être évitées avec du SMT, mais le register file est divisé en banks (*), et chaque bank a semble-t-il moins de ports que ce qu'il faut pour nourrir toutes les unités de calcul, donc des conflits peuvent se produire. Ce qui limite le choix du couple d'instructions à exécuter. Du moins c'est comme ça que je vois les choses.)

(*) anglicisme pour pas dire que le banc est divisé en bancs...

[Yasko]

Sans indiscrétion, tu leur fais calculer quoi à tes CG, Møgluglu ?

Tu as quels rapport de perfs en moyenne par rapport à si tu le faisais sur un CPU ?

[ylyad]

Je me posais la même question

[Møgluglu]

Sans indiscrétion, tu leur fais calculer quoi à tes CG, Møgluglu ?

Pas de pb, ça risque juste de sortir un peu du sujet

En ce moment (= à 3 mois près), j'écris une bibliothèque d'arithmétique par intervalles en Cuda et Cg.
C'est une collaboration avec un chercheur en info graphique qui en a besoin pour du lancer de rayons sur surfaces implicites.

L'idée c'est que tu as une surface définie par une équation arbitraire f(x, y, z)=0, et que tu veux chercher son intersection avec un rayon.
f peut être un polynôme de degré 4 ou 5, ou même une formule avec des divisions, des racines carrées ou des exponentielles. On ne sait donc pas résoudre l'équation algébriquement.
À la place, on résout l'équation numériquement. Ça se ramène à chercher où la fonction s'annule.
On peut faire ça en flottant avec des méthodes qui convergent assez rapidement. Le problème, c'est que sur des surfaces un peu biscornues, on peut rater des solutions. Et donc risquer qu'un pixel s'affiche de la mauvaise couleur .
Avec un algo de Newton par intervalle par contre on peut être sûr de ne rater aucune solution, même en calculant en flottant.

(désolé pour le manque de lien, Wikipédia est pas au top sur l'arithmétique par intervalles...)

Problème : ça rame. Bien plus que le lancer de rayons sur implicite non-certifié, qui est lui-même un ordre de grandeur plus lent que le lancer de rayon sur triangle.
Donc on va essayer de faire tourner ça sur GPU dans l'espoir que ça aille un peu moins lentement.
Mais l'arithmétique pas IEEE-754 fait que c'est pas trivial de faire de l'intervalle sur GPU.

Et c'est là que j'arrive avec ma bibliothèque d'arithmétique par intervalles optimisée et/ou garantie.
Et je maudit les constructeurs pour l'absence d'exceptions qui m'oblige à tester aprés chaque opération les underflows, overflows et NaNs qui arrivent une fois tous les 36 du mois.

Sinon je m'intéresse aussi à l'évaluation des fonctions élémentaires (exp, log, trigo...) sur GPU.

Tu as quels rapport de perfs en moyenne par rapport à si tu le faisais sur un CPU ?

Sur des benchs synthétiques de mes opérateurs, je suis entre 66 et 100% du peak rate du GPU suivant l'opération. (bien sûr ça veut rien dire je peux faire plein de calculs inutiles).
À vrai dire je n'ai même pas encore pensé à comparer avec le CPU. À ma décharge, le fight entre le Prescott et la 8500GT sur lesquels je bosse manquerait un peu de piment...

Mon collègue graphiste annonce des speedups de 150 à 350 sur l'appli complète avec ma bibliothèque sur G80, mais en toute honnêteté j'ai des doutes sur le degré d'optimisation de sa version CPU.

En théorie, il y a à peu près un facteur 10 en puissance de calcul. En pratique ça tourne entre 3 et 5 (mais chiffres vieux du temps d'avant Cuda). Si on exploite les unités des GPU qu'on a pas sur CPU (fonctions élémentaires, filtrage, interpolation...), on peut espérer arriver entre 30 et 80 (à la louche). Au dessus, il y a une embrouille quelque part.

[fefe]

Au dessus, il y a une embrouille quelque part.

De ce que j'ai vu, beuacoup de speedups enormes venaient de la methodologie de test. On test un petit kernel qu'on a optimise aux petits oignons sur les 2 platformes et on trouve 200x. Mais on oublie de prendre en compte l'impact de la hierarchie memoire sur la perf de l'appli globale (celle qui englobe le kernel), et on se retrouve en fait a mesurer la bande passante memoire multipliee par les capacite de calcul.

Dans une appli reelle, le kernel aurait probablement deja ses donnees dans un cache (ou le kernel suivant) si l'algo a ete "bloque" de maniere appropriee, et la difference de bande passante memoire entre le GPU et le CPU aurait ete partiellement resorbee.

Sinon 3 a 5x pour des applis n'utilisant pas le hardware dedie des GPU me semble tout a fait raisonable (au niveau appli, bcp plus au niveau kernel). Si tu mesures a surface de silicone equivalent tu risques meme de descendre a ~2x... (les gpus scalent mieux que les cpus, donc si on compare avec des cpus bas de gamme c'est plus avantageux pour les cpus...)

[Yasko]

Problème : ça rame. [...] Donc on va essayer de faire tourner ça sur GPU dans l'espoir que ça aille un peu moins lentement.

A part sur x86, sur quoi vous avez testé ?
Ton problème de résolution d'équation, ca devrait bien tourner sur une archi RISC in-order (enfin, je m'avance un peu peut-être mais c'est l'impression que j'ai).

Vous avez pas essayé sur une PS3 ? (Cell...)

[Møgluglu]

Fight Prescott 3GHz vs. 8500 GT sur calcul d'intervalle en float :

Opérateur	CPU	GPU dummy-proof	GPU laxiste	Speedup d-p	Speedup lax
x+y	7,75	1,56	0,82	4,97	9,45
x*y	24,44	1,87	1,22	13,07	20,03
x^2	19,67	1,02	0,68	19,28	28,93
x^5	68,54	1,73	0,78	39,62	87,87

(TODO: aligner les colonnes avec les en-têtes)

Les chiffres sont en ns par opération, obtenus en soustrayant le temps d'une boucle vide au temps d'une boucle pleine de calculs. La version CPU codée en 15 min est monothread donc exploite pas l'HT et utilise la bibliothèque d'intervalle de Boost. [edit: et compilée avec gcc 4.1.3 en -O2]

Ma version dummy-proof tient compte des dénormaux, des infinis et des NaN. La version laxiste fait n'importe quoi si ça arrive.

Je suis particulièrement fier de ma fonction puissance entière constante qui fait que x^5 coûte moins cher qu'une addition

A part sur x86, sur quoi vous avez testé ?
Ton problème de résolution d'équation, ca devrait bien tourner sur une archi RISC in-order (enfin, je m'avance un peu peut-être mais c'est l'impression que j'ai).

C'est vrai qu'on a un Merced au fond du couloir qui prend la poussière
Et un Alpha 21264A EV6.7 à 667 MHz sous Tru64 5.1 qui sert de serveur web/proxy/ssh/un peu tout.

Mais je pense qu'il faut juste une archi un peu couillue en flottant SP... Avec une implémentation bien tunée en SSE on devrait déjà gagner pas mal.
De toute façon sur mes benchs synthétique on n'a pas de problème de dépendances ni mémoires et on peut atteindre facile le débit crête quelle que soit l'archi...

Vous avez pas essayé sur une PS3 ? (Cell...)

Nan, on a pas réussi à trouver les crédits pour s'en acheter une, déjà justifier une carte graphique c'est dûr...

[Yasko]

Je suis particulièrement fier de ma fonction puissance entière constante qui fait que x^5 coûte moins cher qu'une addition

Je dois reconnaitre que les résultats m'ont surpris.

Pour le x² sur CPU comme sur GPU, il est (un peu, pour le CPU) plus rapide que le x*y, et ca doit s'expliquer assez bien vu que x²=x*x, et qu'on a donc qu'un load a faire, par rapport à 2 pour x*y.
Par contre, pour x^5
Si tu en es fier, je suppose que c'est plus compliqué que x*x*x*x*x ? (remarque, les résultats en eux-même sont suffisants pour être fier )

Pour x+x, tu as combien ? (ah oui mais le compilo va faire un mul 2, pas un add...)

Nan, on a pas réussi à trouver les crédits pour s'en acheter une, déjà justifier une carte graphique c'est dûr...

Tu bosses pour une université française ?
Clair que ta 8500, elle fait un peu pitié (et je ne parle pas ton prescott bien sur).