Je ne pense pas que les professionnels du secteur seront près à modifier les compilo (et donc ajouter de l'incertitude dans un maillon capital de leur chaîne) pour supporter une nouvelle norme qui de toute façon ne sera pas appliqué par les vieux barbus du C "-ansi -pedantic" qui ont déjà tout ce qu'ils veulent en C : de la simplicité, de la liberté et de la puissance.
Si tu mates la page de C99, tu verras que les compilateurs pour les gros systèmes UNIX (et clones) et Windows ont adapte leur compilateur: IBM C for AIX, PGI C Compiler, GCC (presqu'entièrement), ICC (presqu'entièrement), Sun C Compiler -- bref, les compilateurs qui comptent.
Et ce n'est pas parce que certains grincheux ont décidé que seule la norme C89 compte que ça va rester ainsi. Si on va par là, on devrait suivre les coding styles de la fondation GNU: utiliser la syntaxe pré-ANSI pour definir les fonctions. Quelque chose du genre:
intfoo(a,b,c)char*a,floatb,unsignedc{}
... Juste parce que "tous les compilateurs n’implémentent pas encore la norme ANSI". Crois-moi, il y a tout un tas de gens très contents du fait que C99 ait été inventé et qui programment avec, car le langage fournit tout un tas de mécanismes utiles pour le programmeur, tout en limitant la complexité (l'alternative bas-niveau devenant C++, autrement plus compliqué).
Concernant l'ajout de constructions visant la programmation concurrente et parallèle : il s'agit d'ajouts fondamentaux. Un langage système, même bas-niveau, doit désormais être capable de gérer la concurrence. Les systèmes du futur seront très certainement des processeurs de type "manycore", avec plus de 60 coeurs sur une seule puce. Il existe déjà des processeurs de ce type, certains utilisables en production (d'autres sont réservés à la recherche, et d'autres ne sont produits que pour certaines agences dont le nom est un acronyme à trois lettres que nous ne nommerons pas) :
Cyclops-64 (IBM C64) a produit un processeur avec 160 coeurs, avec une unité flottante partagée par deux coeurs. Il y a un micro-OS (proprio) pour booter le processeur, pas de mémoire virtuelle, pas de caches de données (uniquement des scratchpads, i.e. des mémoires locales aux coeurs, adressables directement par le programmeur). Le processeur est cadencé à 500MHz.
Single Cloud on a Chip (Intel SCC) est un processeur qui comprend 4 zones. Chaque zone embarque 6 tuiles. Chaque tuile comporte 2 coeurs, chacun ayant 2 niveaux de cache (un L1D et un L2 unifié données +instructions), sans protocole de cohérence. Chaque tuile comporte aussi un "Message Passing Buffer" (MPB), qui est en gros un scratchpad pour communiquer avec les autres tuiles. SCC est un processeur intéressant pour tester des politiques de gestion de puissance et d’énergie (pas simplement l'ajustement de fréquence, mais aussi la variation de tension). Il y a donc 48 coeurs (à base de Pentium classique) sur un chip. Il existe deux modes : l'un où un Linux tourne par tuile (c'est le coté "cloud"), et l'autre où on boote un noyau Linux sur une tuile, et le reste est à programmer par le programmeur système.
Les processeurs de la compagnie Tilera (TileGX, etc.) sont des processeurs de 32 ou 64 coeurs, qui ont la particularité de proposer un système de cache cohérent (en fait si je me souviens bien, il y a cinq réseaux différents sur le chip, mais je ne me souviens plus exactement quels sont les usages). La performance en virgule flottante est relativement pourrie, mais la performance sur valeurs entières reste plutôt intéressante. Le processeur est situee sur une carte avec interface PCIe. Aucun OS, rien sur le chip : il faut tout programmer soi-même.
Les accélérateurs d'Intel (famille MIC, Knight's Corner, Knight's Ferry, etc.) sont les descendants de feu le Larrabee. Pour le moment il s'agit d'une carte accélératrice (donc PCIe) avec 32 coeurs x86 modifies avec des unités SIMD (AVX, successeur de SSE, et dont les registres font 256 bits au lieu de 128).
Il y a d'autres processeurs manycore qui vont pointer le bout de leur nez. Tous ont en commun de la mémoire partagée, un grand nombre de processeurs, une mémoire locale relativement petite (scratchpad et/ou cache avec ou sans cohérence), etc. Essayer de les programmer sans avoir du parallélisme en tête ne peut mener qu'à une perte de performance globale (dans le meilleur des cas) ou à des bugs très difficilement corrigeables (dans le pire).
Ajouter des constructions pour gérer la concurrence en C et C++ et en règle générale dans les langages orientées programmation système est à mon sens inévitable.
[^] # Re: Bof
Posté par lasher . En réponse à la dépêche C11 n'est pas encore mort. Évalué à 10.
Si tu mates la page de C99, tu verras que les compilateurs pour les gros systèmes UNIX (et clones) et Windows ont adapte leur compilateur: IBM C for AIX, PGI C Compiler, GCC (presqu'entièrement), ICC (presqu'entièrement), Sun C Compiler -- bref, les compilateurs qui comptent.
Et ce n'est pas parce que certains grincheux ont décidé que seule la norme C89 compte que ça va rester ainsi. Si on va par là, on devrait suivre les coding styles de la fondation GNU: utiliser la syntaxe pré-ANSI pour definir les fonctions. Quelque chose du genre:
... Juste parce que "tous les compilateurs n’implémentent pas encore la norme ANSI". Crois-moi, il y a tout un tas de gens très contents du fait que C99 ait été inventé et qui programment avec, car le langage fournit tout un tas de mécanismes utiles pour le programmeur, tout en limitant la complexité (l'alternative bas-niveau devenant C++, autrement plus compliqué).
Concernant l'ajout de constructions visant la programmation concurrente et parallèle : il s'agit d'ajouts fondamentaux. Un langage système, même bas-niveau, doit désormais être capable de gérer la concurrence. Les systèmes du futur seront très certainement des processeurs de type "manycore", avec plus de 60 coeurs sur une seule puce. Il existe déjà des processeurs de ce type, certains utilisables en production (d'autres sont réservés à la recherche, et d'autres ne sont produits que pour certaines agences dont le nom est un acronyme à trois lettres que nous ne nommerons pas) :
Cyclops-64 (IBM C64) a produit un processeur avec 160 coeurs, avec une unité flottante partagée par deux coeurs. Il y a un micro-OS (proprio) pour booter le processeur, pas de mémoire virtuelle, pas de caches de données (uniquement des scratchpads, i.e. des mémoires locales aux coeurs, adressables directement par le programmeur). Le processeur est cadencé à 500MHz.
Single Cloud on a Chip (Intel SCC) est un processeur qui comprend 4 zones. Chaque zone embarque 6 tuiles. Chaque tuile comporte 2 coeurs, chacun ayant 2 niveaux de cache (un L1D et un L2 unifié données +instructions), sans protocole de cohérence. Chaque tuile comporte aussi un "Message Passing Buffer" (MPB), qui est en gros un scratchpad pour communiquer avec les autres tuiles. SCC est un processeur intéressant pour tester des politiques de gestion de puissance et d’énergie (pas simplement l'ajustement de fréquence, mais aussi la variation de tension). Il y a donc 48 coeurs (à base de Pentium classique) sur un chip. Il existe deux modes : l'un où un Linux tourne par tuile (c'est le coté "cloud"), et l'autre où on boote un noyau Linux sur une tuile, et le reste est à programmer par le programmeur système.
Les processeurs de la compagnie Tilera (TileGX, etc.) sont des processeurs de 32 ou 64 coeurs, qui ont la particularité de proposer un système de cache cohérent (en fait si je me souviens bien, il y a cinq réseaux différents sur le chip, mais je ne me souviens plus exactement quels sont les usages). La performance en virgule flottante est relativement pourrie, mais la performance sur valeurs entières reste plutôt intéressante. Le processeur est situee sur une carte avec interface PCIe. Aucun OS, rien sur le chip : il faut tout programmer soi-même.
Les accélérateurs d'Intel (famille MIC, Knight's Corner, Knight's Ferry, etc.) sont les descendants de feu le Larrabee. Pour le moment il s'agit d'une carte accélératrice (donc PCIe) avec 32 coeurs x86 modifies avec des unités SIMD (AVX, successeur de SSE, et dont les registres font 256 bits au lieu de 128).
Il y a d'autres processeurs manycore qui vont pointer le bout de leur nez. Tous ont en commun de la mémoire partagée, un grand nombre de processeurs, une mémoire locale relativement petite (scratchpad et/ou cache avec ou sans cohérence), etc. Essayer de les programmer sans avoir du parallélisme en tête ne peut mener qu'à une perte de performance globale (dans le meilleur des cas) ou à des bugs très difficilement corrigeables (dans le pire).
Ajouter des constructions pour gérer la concurrence en C et C++ et en règle générale dans les langages orientées programmation système est à mon sens inévitable.