Microsoft a choisi l'AFDS pour présenter une nouvelle version de C++ optimisée pour l'exploitation des GPUs, et potentiellement de tout autre accélérateur. ...
Lire la suite ...

Pas franchement réjouissant le choix du C++... à voir à quoi va ressembler ce C++ "0x" car plus le temps passe plus le C++ sauce M$ ressemble à du patchwork.
 
L'exemple de code ressemble un peu beaucoup à une syntaxe alternative à OpenMP par contre, il y a encore du boulot pour rendre le code plus naturel (depuis quand on dit que chaque élément du tableau Z est le fruit de calculs sur chacun des éléments des tableaux X et Y? Z EST le fruit de calculs sur X et Y!).
 
M$ me semble un pwal hyperactif depuis Visual Studio 6, ils entament des démarches mais ne les mènent jamais à terme... (.NET, C#, LINQ...)

Il vaut mieux ça que le Microsoft inerte d'il y a quelques années non ?

Ça sent un peu le mode panique de la part de Microsoft, juste pour répliquer à PathScale qui a sorti EKOPath en open source.

 
D'accord avec toi sur le choix du C++, par contre peux tu expliquer en quoi .net, c# et linq ne sont pas aboutis ?

Pareil que phildarvador, l'évolution de C# (et ce qui va autour) je trouve personnellement que c'est l'une des plus belles réussites de MS. Java a pas mal stagné comparativement ces dernières années, et je ne suis pas certain que les choses s'arrangent sous l'ère Oracle.
 
Edit : Avec un peu de bol MS étendra son extension Parallel pour C# http://msdn.microsoft.com/en-us/library/dd460720.aspx

En fait, les problèmes de C# sont globalement ceux de .net, trop peu efficace pour en faire un "vrai" langage et un ecosystème qui peine à se développer (DirectX dans .net, c'est un peu la misère et ça commence seulement à prendre forme, notamment à cause de XNA qui lui-aussi montre ce côté hyperactif).

Rien à redire sur LINQ en dehors du fait que c'est encore une branche supplémentaire d'un arbre de plus en plus complexe, sans réelle raison (enfin peut-être un peu récupérer les "clients" habitués aux langages typés "bases de données", genre COBOL).

Ajoute à ça la mise en avant du "nouveau C++" alors que depuis un bail il se complique de façon monstrueuse pour rien... et on peut se demander si ils n'auraient pas mieux fait de repartir de la base saine de C#, dont on se demande ce qu'il fa devenir.

Quel manque d'efficacité ? Juste parce que c'est "managed" ?  
 
C'est un peu facile de regarder C# par le prisme du développement de jeux pour justifier d'un côté non abouti. C'est un marché ou la majorité des developpement doivent être cross compatibles consoles, et C# ne s'applique pas (ironiquement, un peu avec Unity, mais ce ne sont pas les mêmes plateformes).
 
Managed DirectX était raté, XNA a pati par ses origines et les limitations imposées coté 360. SlimDX reste un peu populaire, mais ca n'a rien a voir avec le côté abouti ou non d'un langage et d'un framework. Si on regarde ce que fait Java pour les API de jeu, on ne va pas aller très loin.

J'ai cité DirectX mais ça vaut pour d'autres API M$, c'est juste que faciliter l'exploitation du parallélisme massif en C# aurait au moins autant de sens que dans Visual C++, et je pensais justement à DirectCompute.

Pour ce qui est de l'efficacité, C# reste assez basique dans son utilisation des CPU modernes, ce qui le cantonne quasiment aux applis de gestion légères alors que le potentiel d'un langage de ce type est énorme.

C# a été le premier a avoir des extensions //, cf le lien que j'ai posté au dessus. On sent toute ton objectivité dans le "M$"

Oui, mais ça reste le bricolage à la OpenMP ça... Ce que j'aimerais voir, c'est une utilisation "native" de types Vector (côté CPU aussi...) et des outils autres que des "parallel for" que le compilo devrait de lui-même sortir, à condition que le code interne soit adapté (mais ça, ça fait partie des recommandations de base depuis des années).

Limite une simple directive #numthreads x devant le fameux foreach suffirait à remplacer l'objet Parallel et les options soit dit en passant planquées dans un autre objet ParallelOptions, ce qui casse "légèrement" le côté objet.

Et voila. Encore une autre solution pour le double problème de la vectorisation et multithreading ... Pas sure que cela va dans le bon sens. Je note que personne n'a parlé d'Intel ArBB qui est exactement la même chose et déjà dispo.
http://software.intel.com/en-us/ar [...] ng-blocks/
Je note aussi que personne ne cite OpenCL qui est la réponse Khronos Group ou GPGPU. MS n'a ici fait que d'apporter une brique qui est encore une surcouche d'une couche d'un truc qui va pas simplifier le système.
Il serait temps que tout le monde se mette d'accord sur un paradigme unique pour le multithreading, car là, c'est chacun pour soit ( nvidia => cuda, ATI => OpenCL, Intel => OpenMP, ArBB, TBB, etc, Microsoft => AMP + Parallel for c# ) ...

L'auto vectorisation dans les compilateurs C++ reste assez limitée. ICC en fait un peu plus, mais ca ne va pas très loin.

Oui et non, car ça dépend de quel parallélisme on parle.
 
Le parallélisme de base est naturel dans les langages objet comme C# (chaque instance d'un objet peut être considérée comme générant un thread), même si ça n'a pas l'air d'être le cas en pratique, du parallélisme fin et surtout l'exploitation des unités d'exécution spécialisées dans le parallélisme de données (SSE/AVX, GPU... rien n'empêche de penser SIMD même si ça finira par tourner sur des CPU minimalistes, l'inverse est par contre une horreur), c'est là qu'il faut bosser, et pas nous resortir des monstres qui requièrent des delegates et 3x le code utile juste pour pouvoir créer un thread utilisable.
 
En C#, soit on génère des threads à la barbare et l'exécution est franchement chaotique (testé), soit on utilise un Parallel sur lequel on a quasiment aucun contrôle (idem OpenMP), soit on fait appel à l'API Win32 native pour gérer soi-même ses threads et on perd la portabilité, il n'y a rien de bien réjouissant là-dedans.

Waouh    
 
J'avoue que je suis loin de maitriser tous les sujets abordés ici, cependant, de mon point de vue de petit développeur .net, je trouve que les outils de Microsoft sont de plus en plus aboutis et intéressants. La concurrence y est pour quelque chose, et ça c'est aussi un bon point. Je suis donc "content" que MS s'implique dans autant de sujets, même s'ils ne sont pas tous traités de la meilleure manière qui soit. Le framework .net a progressé au fil du temps, comme bien d'autres outils, il y a donc des chances pour que cette partie le soit aussi.  
 
Concernant DirectX et XNA, que je n'ai que survolé, j'ai trouvé l'idée de mettre à disposition des développeurs le nécessaire pour créer des jeux sur pc, xbox et wp7 excellente.
 
Pour finir, j'ai un peu utilisé le multithreading en c#, et dans mon cas ça avait très bien fonctionné... C'était un cas relativement simple - de la recherche de dispo et des prises de réservations dans l'hôtellerie - mais cette possibilité avait bien aidé à améliorer les perfs de nos programmes. Enfin bref, on s'éloigne un peu du sujet.
 
Merci pour l'article en tout cas C_Wiz  

Simples threads à la .NET 2.0 ou via Parallel? Le problème de fonctionnement chaotique dont je parle concerne l'utilisation intensive du CPU quand on laisse le CLR s'occuper de l'attribution des cores, les threads n'arrêtent pas de rebondir d'un core à l'autre et au final c'est très très laid.
 
Je ne trouve pas que ça soit HS, car il s'agit de l'avenir des développeurs, et ça m'embêterait qu'on ait le choix entre un Visual C++ patchwork mais incontournable pour certains développements (qui n'ont que faire de ces "nouveautés" ) et un Visual C# tout aussi patchwork et limité à des usages où les perfs sont secondaires.

Gigathlon>
En 20 ans de coding C++ intense, j'ai jamais vu un compilo faire du bon travail sans patch ou API dédiée au niveau parallélisme. Tout simplement parce que le parallélisme est une affaire d'application et non de compilation ou de langage et de génération de code. Et ce même sur des compilos dédiés sur les DSP massivement parallèles depuis des années, ça marche un peu mais ça ne bat jamais un tuning manuel. C'est comme ça, un compilo ne peut pas savoir a priori quel type de soft tu écris ni pourquoi tu l'as écrit de cette façon. D'où les OpenMP etc pour lui en dire plus et avoir un contrôle plus fin du parallélisme, parce que de base à moins d'aligner des lignes de commandes de 3 km incompréhensibles et impossibles à maintenir dans un environnement de production, on sait pas faire, et probablement, on ne saura jamais faire.

C_Wiz>
Juste, il aurait fallu que je précise le parallélisme en question.  
Mettons donc les points sur les i, on parle bien ici de choses qui se situent très bas niveau et non au niveau d'un objet comme le parallel du C# . La teapot du parallélisme ( ie la multiplication de matrice ) montre bien que le sujet abordé par MS est bien celui très bas niveau ). J'ai un gros vecteur, je fais un sinus dessus, il faut qu'avec 4 cores ça aille 4x plus vite ( en théorie ). En pratique les critères de bonne scalabilité sont bien moindre évidement ( entre 4 cores et 8 cores, Intel donne 1.3x comme critère c'est bon ).
Bref, revenons au sujet. Ici, MS donne une solution pour ce type de multithreading mais franchement c'est pas à la hauteur de Intel ArBB où avec un simple typage strong des variables, on adresse aussi la vectorisation. D'où double gain en puissance.
Perso, en c++, je ne préconise que 2 solutions sur le threading, OpenMP ( mature, simple, debuggable ), et TBB ( notation un peu plus complexe, mais threading the type flux aussi faisable ). Le gain de vitesse avec l'une ou l'autre API n'est que dépendant de son code et de la façon dont ses algorithmes sont remaniés pour qu'ils puissent être scalables.  
 

Je pense que le message était pour Gigathlon, moi je suis complètement d'accord
 

????!!!! Ce n'est pas le CLR qui attribue les cores aux threads ! C'est le kernel (Windows) qui gère les threads et les déplace. Il le fait généralement pour de bonnes raisons.  
 
Il le fait pour tous les threads, qui sont une construction pour le kernel, et n'ont rien a voir avec le langage (c'est pareil en C++, Java etc). On peut choisir de forcer l'affinité d'un thread, mais en dehors de quelques cas spécifiques, c'est particulièrement associal de le faire (et on peut fixer l'affinité en C# si on en a envie via COM interop).  
 
Personnellement j'ai vu d'énormes gains de réactivité et de performances dans des scénarios avec une très grande quantité de threads sur des serveurs many cores avec le kernel de 7 (et 2008R2). La réécriture du scheduler a été, à mon humble avis, le point le plus positif de 7.  
 
Mark Russinovitch en parle ici : http://channel9.msdn.com/Shows/Goi [...] -Windows-7
Et ça c'est passionnant aussi : http://channel9.msdn.com/shows/Goi [...] cher-Lock/

Justement, le CLR ne se charge pas d'attribuer les threads aux cores, ce qui dans mon cas a eu pour effet une magnifique partie de pingpong en double, avant d'aller requérir l'aide de Win32 via une interop légèrement lourdingue alors que ça pourrait être prévu d'office

Comme tu le dis si bien, c'est asocial de forcer l'affinité, mais c'est pourtant indispensable dans ce cas, ainsi que pour prendre en compte les spécificités gênantes de l'HyperThreading dans d'autres (forcer le core 0 ou 1 au repos de façon à laisser le maximum de resources pour le thread "maître" tournant sur ce core physique par exemple, ou se débrouiller pour charger chacun des cores avec 2 threads exploitant des pipelines différents de façon à maximiser le gain).

Bon, par contre j'avais testé ça avec Vista, ça a peut-être légèrement évolué mais je n'y crois pas, surtout que c'est loin d'être le seul problème quand on cherche à exploiter un minimum une machine de guerre en C#.

Le kernel connait beaucoup mieux le CPU que toi. Surtout si tu écris du code qui est censé être utilisé sur autre chose que *ta* machine. Il sait aussi pourquoi il bouge tes threads lors des context switch.

Sous 7 il différencie les coeurs physiques et virtuels. C'était possiblement le cas sous Vista, il faudrait vérifier. Sous XP Intel et MS s'étaient mis d'accord sur l'ordre idéal de déclaration des cores par rapport aux algorithmes du scheduler.

Tout ça n'a juste strictement rien a voir avec C#.

Concernant le forcage de l'affinite d'un thread avec un core, je suppose que ca correspond a l'option que l'on trouve pour chaque thread sous le gestionnaire des taches de Windows ?
 
Je suis sous Win 7 (64b) et j'utilise cette option pour les programmes les plus lourds que j'utilise au boulot (Xilinx ISE et Modelsim), et qui sont malheureusement peu multithreades. Je ne suis pas dans le soft mais dans le hard, surtout dans le dvlpt de FPGA pour du traitement d'image.
 
Le CPU de ma machine est un core i5 avec hyperthreading. Le fait de forcer l'affinite de chaque tache a un seul core me fait gagner environ 25% en perfs (si mes souvenirs sont bons). En l'occurence j'utilise le core 0 pour Xilinx ISE et le core 2 pour Modelsim, ce sont les 2 cores physiques si je ne m'abuse.
 
Je n'ai que peu de connaissances en soft (par contre j'en ai en processeur vectoriel) mais je suppose que c'est ce que Gigathlon montre du doigt quand il parle de preferer forcer l'affinite des threads avec un core. Apres je suppose aussi que C_Wiz a raison en disant que cela est lie au kernel de l'OS (et par ce biais a la machine) et n'est donc pas lie au code ni a sa compil (mais bon mes connaissances en la matiere sont tres insuffisantes pour bien me justifier).
 
Enfin bref tout ca pour dire que le deplacement des threads d'un core a l'autre semble tres mal optimise sous Windows, y compris 7, a mon humble d'avis d'utilisateur.