Je n'aime pas du tout sa manière de parler. Et, quel jeu amusant ! :)

Ce qui est certain, c'est qu'on voit une différence ! On va enfin récupérer une partie de la puissance inexploitée de nos machines.

belle et sacrée fluidité ; par contre qui aura plus de 4 cœurs sur sa machine ? les pro ...mais bon c'est toujours un plus bienvenue et surtout vraiment utile .

C'est bien connu, tout le monde a un opteron chez soi...

[quote]par contre qui aura plus de 4 cœurs sur sa machine ? [/quote] Dans quelques années on aura des centaines de coeurs. Ca va doubler assez rapidement et assez régulièrement. Je suis un peu déçu que la démo ne s'appuie que sur le processeur principal... Ca fait des lustres qu'il existe des outils pour faire de la programmation parallelle (OpenMP, MPI, etc.). Lorsqu'un logiciel est bien programmé, il est sensé fonctionner en parallèle, indépendamment du nombre d'unités d'exécutions disponibles. Donc si son truc marche pour 24 coeurs, il marche pour 1 coeur, mais moins vite. Je m'attendais plus à une démo montrant l'utilisation de la carte graphique pour des calculs généralistes. Je précise que concevoir des logiciels "en parallèle", c'est à dire qui répartissent leurs calculs sur plusieurs unités d'exécution, c'est TRES difficile. Pour moi c'est une torture pour l'esprit, je déteste ça. Mais bon, il y a plusieurs techniques pour y arriver, et certaines sont plus simples que d'autres. Mais pour moi le plus difficile est de paralléliser des calculs en mémoire non partagée. Essayez d'imaginer comment faire calculer le produit d'une matrice sur n processeurs qui se répartissent les calculs et qui doivent se synchroniser pour récupérer les résultats... C'est horrible, et c'est pourtant le problème le plus simple. Cette difficulté implique un certain enjeu dans la conception de langages plus simples à manipuler. J'espère qu'OpenCL facilite vraiment les choses. Pour la démo : s'il y a 24 coeurs, ça ne va pas s'exécuter 24 fois plus vite, car il y a un coût important en communication. Plus on ajoute des unités d'exécution, et plus le coût des communications est important. Sur des clusters ou des grilles on utilise des modèles qui permettent de calculer tout ça. En outre, ce n'est à première vue pas très difficile de paralléliser un tel problème (un BSP-tree et c'est bon). Mais je m'avance peut-être un peu rapidement.

Ca s'appelle du marketing de vente ce genre de démo :)))

Avant, le développeur ne devait pas changer quoi que ce soit dans son code pour bien exploiter la machine. Selon le processeur principal, la vitesse de la RAM... le programme tournait plus ou moins vite. L'arrivée des coprocesseurs dédiés (graphique, son, encodage,...) a nécessité une adaptation du code pour tirer partie de ces derniers. Pour faciliter les choses, OpenGL ou DirectX cachent en partie cette architecture et heureusement pour les développeurs de jeux, il y a peu de code qui change pour s'adapter à la carte graphique. Le problème est que maintenant le CPU principal devient multi-core, essentiellement parce que c'est devenu le moyen le plus efficace d'augmenter les performances. Nous n'avons pas les moyens technique de construire des Pentium4 à 8 ou 10 Ghz. Et là on en revient au même problème, il faudrait une couche qui cache cette complexité. Comme le dit Dr-Cube, la programmation parallèle est (très) difficile. De plus on ne tire pas parti de la même manière d'un processeur dual-core que d'une machine 24 cores. Dans une premier cas, la synchro des thread est facile à gérer et dans le second cas, cela peut devenir un casse-tête. C'est bien pour cela que même les meilleurs algorithmes parallèles ne divisent pas par deux le temps d'exécution quand on double le nombre de coeurs. C'est toujours un peu moins. Le but principal de OpenCl s'est de faciliter au maximum l'exécution parallèle. Pour le développeur, il ne faut plus adapter son code en fonction du nombre de coeurs disponibles. Il écrit son code, une seule fois qui tirera bien parti de l'architecture qu'il y aie 1, 2 ou 24 coeurs. De plus, si j'ai bien compris, OpenCl facilite la répartition entre tous les processeurs (CPU & graphique). Mais ce que je crois avoir compris également, c'est que OpenCL ne cache pas complètement l'architecture sous-jacente mais nécessite du code pour s'adapter à différents cas de figure. Donc c'est bien pour les développeurs de jeux (qui restent à un bas niveau).

"Apple ne nous ayant pas franchement régalé, lors de la dernière WWDC, de démonstrations montrant les mérites d'OpenCL dans Snow Leopard" Ce n'est pas vraiment vrai. Certe Apple n'a pas fait de démo lors du keynote publique de la WWDC, mais lors des sessions développeurs, plusieurs sessions consacrées à OpenCL (trois exclusivement à OpenCL et une partagée avec OpenGL) ont été réalisées avec de nombreuses démos très spectaculaires. Apple a inventé OpenCL, elle n'allait pas négliger d'en parler en détail lors de sa WWDC.

Un seul Opteron ? T'as pas tes 4 Opterons 6-coeurs ? :O

Euh OpenCL, c'est pas la technologie qui permet d'exploiter les processeurs graphiques pour décharger le processeur des calculs parallelisables ? J'ai l'impression de que dans les commentaires, bcp de monde confond Grand Central Dispatch et OpenCL. Faut dire que faire une démo d'OpenCL en prenant une applis graphiques comme support alors qu'OpenCL, c'est justement tirer partie des processeurs graphiques pour faire autre chose que du graphisme, c'est pas très très malin !

@Zouba OpenCL est plutot une API qui permet d'utiliser un GPU pour faire du calcul vectoriel de façon parallèle. Mais elle permet d'utiliser tout autre chose des CPU (multicore ou plusieurs CPU) des unités spécialisées ou tout autre ressource de calcul disponible. OpenCL permet de faire des calculs du genre traitement de matrices en utilisant toutes les ressources disponibles sur la machine que ca soit un PC ou un téléphone. Le concepteur écrit son code en utilisant les primitives OpenCL et en fonction de la machine sur laquelle il exécute ses primitives font appelle au éléments disponibles. Pour revenir à la démo d'AMD, il ne s'agit pas d'une application graphique, ce qui consomme le plus de ressource ici c'est les calculs pour gérer l'interaction entre les particules pas leur affichage. C'est plus ce qu'on retrouve dans catia que dans 3dsMax. @Dr_cube: La démo n'est pas supposé démontrer la facilité de paralléliser ce genre de problème mais plutôt démontrer la versatilité de l'API OpenCL et les possibilité de gain de performances et ne jouant que sur le runtime OpenCL sans aucunement modifier son code. J'aimerai bien voir aussi comment ce comporte son code avec un runtime qui utilise les GPU voir un runtime sur iphone.

après les clés usb, les clés microprocesseurs, imaginer acheter une clé usb qui contient des microprocesseurs, une couche logicielle détecterait automatiquement le rajout du matériel et la puissance en deviendrais démultipliée. la science fiction en informatique n'est jamais très loin de la réalité prochaine

cela ferait un nouveau marché pour intel en plus, pas besoin d'integrateur, directement du producteur au consommateur, de quoi relancer fab 24 !

Enfin de vrai démonstration d'OPEN CL et par qui : AMD. Si c'est pas le coeur ça.

Mouaif… Une demo d' OpenCL pour accélérer l'encodage video "par exemple" m'aurait fait plus bavé… Nvidia ont déjà des logiciels qui promettent sur ce front , mais CUDA n'est pas Open, alors… Faut pas qu'ils ratent l'entrée de d'OpenCL, c'est bien bo comme exemple, mais a 24Pross, c'est pas le GPU est mis en avant, et ca parle du tout a tout a chacun.

"Dans quelques années on aura des centaines de coeurs. Ca va doubler assez rapidement et assez régulièrement." Ouai mais quand est-ce que le x86 (qui atteint sérieusement ses limites) sera mis a la trappe pour un nouvelle architecture conçue spécialement pour le massivement parallèle aussi..?... sinon, c'est cool a demo, perso, j'aurai preferé un test, avec un quad core plus un carte graphique, plutot qu'un ordi avec 6x4 coeurs, le truc que personne a chez soi.