Discussion :

[Katleen Erna]

"Il faut repenser les OS pour les processeurs multi-coeurs", d'après Microsoft

Dave Probert est expert du noyau chez Microsoft. Selon lui, l'approche actuelle du multi-coeur n'est pas encore à même d'en exploiter toute la puissance, et est trop "compliquée".

Aussi, propose-t-il une autre organisation. Car, d'après lui, "la solution" ne se situerait pas dans l'amélioration de techniques "comme le parallel programming, mais plutôt dans le refonte des abstractions de base qui constituent le modèle du système d'exploitation".

Il explique qu'on ne tire pas assez parti des performances offertes par les processeurs multicoeurs et qu'aujourd'hui, on ne devrait plus avoir à patienter devant son ordinateur. "Désormais, la réactivité est reine", clame-t-il.

Il suggère que les développeurs "repensent" l'architecture de base des OS actuels pour que les bénéfices apportés par les puces multicoeurs soient pleinement exploités

Un nouveau système basé sur le multicoeur aurait un aspect "très différent" de Windows ou d'Unix. Il fonctionnerait plutôt comme un hyperviseur, d'après Probert, et servirait d'intermédiaire entre la machine virtuelle et le hardware.

Source : Déclarations de Dave Probert lors de l'Urbana-Champaign Parallel Computing keynote

Pensez-vous en effet que les performances offertes par le multicoeur ne sont pas pleinement exploitées aujourd'hui ?

Que pensez-vous de la proposition de Probert ?

[Génoce]

"Il faut repenser les OS pour les processeurs multi-coeurs", d'après Microsoft

Il explique qu'on ne tire pas assez parti des performances offertes par les processeurs multicoeurs et qu'aujourd'hui, on ne devrait plus avoir à patienter devant son ordinateur. "Désormais, la réactivité est reine", clame-t-il.

Pensez-vous en effet que les performances offertes par le multicoeur ne sont pas pleinement exploitées aujourd'hui ?

Il me semble que la plupart du temps, quand j'attends durant un chargement, c'est dû au disque(s) dur pas assez rapide non?

Sinon c'est dans la lignée de ce qui se fait aujourd'hui, toujours plus vite !
S'ils parviennent à mieux exploiter la puissance les processeurs multicoeurs, tant mieux, étant donné que c'est l'avenir!

Vivement qu'on exploite pleinement les capacités de notre cerveau aussi

[kaymak]

Un nouveau système basé sur le multicoeur aurait un aspect "très différent" de Windows ou d'Unix. Il fonctionnerait plutôt comme un hyperviseur, d'après Probert, et servirait d'intermédiaire entre la machine virtuelle et le hardware.

Ce n'est pas déjà le cas ?
Les threads ne sont pas suffisants pour ordonnancer / superviser les exécutions ?

[Shaidak]

-> Pensez-vous en effet que les performances offertes par le multicoeur ne sont pas pleinement exploitées aujourd'hui ?

Question rhétorique ? Plus sérieusement c'est loin d'être un scoop et il est évident que les proc périphériques passent la majorité de leur temps à roupiller pendant que leur coeur principal bosse et que l'on attend.

-> Que pensez-vous de la proposition de Probert ?

Une bonne idée ... reste à voir en pratique ce que cela va donner. Le multi-thread devait être omni-présent avec les processeurs multicoeurs et permettre leur pleine utilisation, or, actuellement c'est loin d'être le cas (sauf pour des applications de rendu vidéo ou audio peut-être).

Ce n'est pas déjà le cas ?
Les threads ne sont pas suffisants pour ordonnancer / superviser les exécutions ?

Si je ne me trompe pas, c'est à l'os d'assigner les thread bien plus qu' au programme lui-même, par conséquent si l'os ne gère pas correctement les différents processeurs, les multicoeurs ne seront pas pleinement exploités.

PS : N'y avait-il pas eu proposition il y a quelque temps visant à dire que c'était au hardware de gérer cela bien plus qu'au développeur ? Ou alors j'ai simplement rêvé

[LeSmurf]

Apple propose aussi une solution déjà implémentée, Grand Central Dispatch, mais ce n'est pas aussi radical que la proposition de MS

[Paul TOTH]

nos machines sont de plus en plus performantes, mais les OS restent relativement lents.

je ne pense pas que les architectures logicielles vont dans le bon sens...C'est bien beau dotNet mais c'est plus lent à charger qu'un win32

Dans un autre domaine je ne pense pas qu'en améliorant les performances des moteurs Javascript on pallie efficacement aux manques cruels de HTML en matières de contrôle de saisie.

dans les années 80, IBM sur AS/400 avait déjà songé qu'un flag "majuscules", un flag "numérique uniquement" un flag "cadrage à gauche"..etc permettait de faire des écrans de saisies efficaces en un minimum d'effort. En 2010 on continue à garnir nos pages web de code Javascript plus ou moins complexe pour valider la saisie des formulaires. C'est non seulement affligeant, mais également consommateur de bande passante et de CPU ... POUR RIEN !

Alors monsieur Probert est bien gentil mais qu'ils se mettent déjà d'accord sur des standards qu'on utilise tous les jours et qui nous rendrais la vie plus facile avant de se demander s'il ne faudrait pas réécrire l'OS !

J'en profite pour râler sur l'OS puisque Intel n'a toujours pas sorti un driver digne de ce nom pour le GMA 500 sous XP ! Pas de support OpenGL et support DirectX limité...mais c'est pas grave, on va refaire l'OS !

[Traroth2]

Et qu'est-ce qu'il propose, concrètement ? Parce que "repenser le système", c'est un peu vague...

[gannher]

nos machines sont de plus en plus performantes, mais les OS restent relativement lents.

je ne pense pas que les architectures logicielles vont dans le bon sens...C'est bien beau dotNet mais c'est plus lent à charger qu'un win32

Dans un autre domaine je ne pense pas qu'en améliorant les performances des moteurs Javascript on pallie efficacement aux manques cruels de HTML en matières de contrôle de saisie.

dans les années 80, IBM sur AS/400 avait déjà songé qu'un flag "majuscules", un flag "numérique uniquement" un flag "cadrage à gauche"..etc permettait de faire des écrans de saisies efficaces en un minimum d'effort. En 2010 on continue à garnir nos pages web de code Javascript plus ou moins complexe pour valider la saisie des formulaires. C'est non seulement affligeant, mais également consommateur de bande passante et de CPU ... POUR RIEN !

Alors monsieur Probert est bien gentil mais qu'ils se mettent déjà d'accord sur des standards qu'on utilise tous les jours et qui nous rendrais la vie plus facile avant de se demander s'il ne faudrait pas réécrire l'OS !

J'en profite pour râler sur l'OS puisque Intel n'a toujours pas sorti un driver digne de ce nom pour le GMA 500 sous XP ! Pas de support OpenGL et support DirectX limité...mais c'est pas grave, on va refaire l'OS !

Toi tu parles langages, alors que lui parle de la gestion des multi coeurs par le système d'exploitation. Ca n'a strictement rien à voir.

Quand aux standards, ils n'ont rien à voir avec le sujet dont traite Dave Probert. Bref tu es encore a coté de la plaque.

De plus, je te signale que Windows XP commence à se faire vieux (plus de 8 ans je crois). Il est normal que peu à peu les développements s'arrêtent.

Je suis d'accord quand Dave Probert dit qu'on ne devrait plus attendre, sauf calculs extrêmement complexes.
Mais bon je pense que ce n'est pas pour tout de suite ces changements

[Paul TOTH]

Toi tu parles langages, alors que lui parle de la gestion des multi coeurs par le système d'exploitation. Ca n'a strictement rien à voir.

oui j'ai la faiblesse de penser que quand on utilises des softs développés avec des usines à gaz, il ne suffit pas de repenser l'OS pour obtenir des performances.

Quand aux standards, ils n'ont rien à voir avec le sujet dont traite Dave Probert. Bref tu es encore a coté de la plaque.

il traite de ceci : "on ne devrait plus avoir à patienter devant son ordinateur", moi aussi.

De plus, je te signale que Windows XP commence à se faire vieux (plus de 8 ans je crois). Il est normal que peu à peu les développements s'arrêtent.

Sur netbook, XP était le seul OS acceptable jusque récemment (tient encore une question de performance), le driver seven pour GMA 500 est à peine mieux.

Je suis d'accord quand Dave Probert dit qu'on ne devrait plus attendre, sauf calculs extrêmement complexes.
Mais bon je pense que ce n'est pas pour tout de suite ces changements

les calculs extrêmement complexes sont rarement au niveau OS...serais-tu également hors sujet ?

[Mat.M]

nos machines sont de plus en plus performantes, mais les OS restent relativement lents.

je ne pense pas que les architectures logicielles vont dans le bon sens...C'est bien beau dotNet mais c'est plus lent à charger qu'un win32

je suis d'accord mais c'est parfaitement compréhensible : les éditeurs d'environnement de développement veulent rajouter des tonnes de fonctionnalités, des tonnes de classes comme c'est le cas en .NET ou Java.
Résultat des courses cela fait des frameworks et langages trop lourds pour être performants.

Pensez-vous en effet que les performances offertes par le multicoeur ne sont pas pleinement exploitées aujourd'hui ?

absolument : il ne faut pas perdre de vue qu'il y a encore beaucoup de machines qui sont encore sous XP, voire NET ou win95..

[gannher]

oui j'ai la faiblesse de penser que quand on utilises des softs développés avec des usines à gaz, il ne suffit pas de repenser l'OS pour obtenir des performances.

Rien ne t'obliges à utiliser le .net. Tu peux très bien si ça te chante tout coder en C ou même en assembleur si tu en as les compétences. Le .net, tout comme le Java, est un langage de haut niveau.

les calculs extrêmement complexes sont rarement au niveau OS...serais-tu également hors sujet ?

Oui il est vrai que l'ordonnanceur, pour ne citer que lui, est une tâche très facile à gérer...
Et puis même quand un jeu demande énormément de ressource, c'est quand même l'OS qui va gérer tout ça.

[Mat.M]

Il me semble que la plupart du temps, quand j'attends durant un chargement, c'est dû au disque(s) dur pas assez rapide non?
:

C'est une autre chose : si tu as un temps de chargement trop long c'est effectivement du au DD trop lent.
Tout ce qui est input/output pénalise les performances d'exécution

Sinon c'est dans la lignée de ce qui se fait aujourd'hui, toujours plus vite !
Si ils parviennent à mieux exploiter la puissance les processeurs multicoeurs, tant mieux, étant donné que c'est l'avenir!

Oui on est obligé : les OS deviennent trop lourds ainsi que les outils de développements.
C'est ce que nous dit Paul Toth

[Mat.M]

Toi tu parles langages, alors que lui parle de la gestion des multi coeurs par le système d'exploitation. Ca n'a strictement rien à voir.

attention la gestion des multicoeurs passe également par le langage de programmation.
Si tu ne spécifies pas dans ton code source avec des mots-clés que tu souhaites répartir tel ou tel traitement , fonction ou processus sur un coeur du CPU en particulier , eh bien ton programme une fois compilé tournera comme s'il avait été conçu pour un "vulgaire" pentium d'ancienne génération...

Par exemple il y a l'API win32 sous Windows SetProcessAffinityMask qui permet l'affectation d'un thread à un processeur..
Si on veut optimiser il faut passer par des biblios comme Thread Building Blocks d'Intel.
A noter que Visual Studio 2010 gérera nativement la gestion des multicoeurs

Et puis même quand un jeu demande énormément de ressource, c'est quand même l'OS qui va gérer tout ça.

Il me semble qu'il y a confusion : tout dépend comment le jeu est architecturé
Si un jeu demande énormément de ressources pour ce qui est de l'OS celui-ci a un role relativement limité plutot partiel !
C'est pareil pour les calculs complexes : tout dépend comment le code source pour effectuer ces calculs complexes a été pensé , architecturé et optimisé.
Mais comme les OS deviennent de plus en plus ( inutilement ) lourds et gourmands c'est certain que l'OS pompe pas mal de ressources

[Paul TOTH]

C'est totament faux ce que tu écris ; la gestion des multicoeurs passent également par le langage de programmation.
Si tu ne spécifies pas dans ton code source avec des mots-clés que tu souhaites répartir tel ou tel traitement , fonction ou processus sur un coeur du CPU en particulier , eh bien ton programme une fois compilé tournera comme s'il avait été conçu pour un "vulgaire" pentium d'ancienne génération...

Par exemple il y a l'API win32 sous Windows SetProcessAffinityMask qui permet l'affectation d'un thread à un processeur..
Si on veut optimiser il faut passer par des biblios comme Thread Building Blocks d'Intel.
A noter que Visual Studio 2010 gérera nativement la gestion des multicoeurs

absolument, d'ailleurs Chrome a choisi un modèle multiprocess plutôt que multithread, et cela change énormément la donne (en mieux ou pas c'est une autre question).

sans compter qu'il n'est pas nécessaire de revenir au C ou à l'assembleur pour développer plus léger.

je pense également qu'il est plus simple de repenser les outils de développement "haut niveau" que de chercher à remplacer les OS en place...bien que c'est derniers réclameraient en effet quelques révisions

[gannher]

attention la gestion des multicoeurs passe également par le langage de programmation.
Si tu ne spécifies pas dans ton code source avec des mots-clés que tu souhaites répartir tel ou tel traitement , fonction ou processus sur un coeur du CPU en particulier , eh bien ton programme une fois compilé tournera comme s'il avait été conçu pour un "vulgaire" pentium d'ancienne génération...

Par exemple il y a l'API win32 sous Windows SetProcessAffinityMask qui permet l'affectation d'un thread à un processeur..
Si on veut optimiser il faut passer par des biblios comme Thread Building Blocks d'Intel.
A noter que Visual Studio 2010 gérera nativement la gestion des multicoeurs

Mais si c'est le programme qui gère ça, l'ordonnanceur de l'OS n'a plus son mot à dire ?

Je sais bien que dans les langages, on peut répartir les traitements mais je pensais que c'était à l'OS de décider quel processeur allait être utilisé.

[Paul TOTH]

Mais si c'est le programme qui gère ça, l'ordonnanceur de l'OS n'a plus son mot à dire ?

Je sais bien que dans les langages, on peut répartir les traitements mais je pensais que c'était à l'OS de décider quel processeur allait être utilisé.

c'est toujours le même problème...à haut niveau, doit-on utiliser un garbage collector qui ne sait pas à quoi servent les données ou laisser le programme gérer la durée de vie de ses données...au niveau OS doit-on laisser l'OS décider de quels process doivent être priorisés alors qu'il ne connait rien de leurs tâches ou l'application doit-elle l'en informer.

il n'y a pas de solution ultime, juste des politiques...et repenser l'OS impose de repenser les outils de développement et leur méthode de gestion de ces problématiques.

[Rams7s]

Je pense qu'un poil au delà de ça, le gros problème, c'est la réflexion.
Coder un truc en C, ça s'apprend relativement facilement. C'est un langage procédural, tout se passe comme dans la vie:

• entrer(porte_boulangerie)
• acheter_pain(&porte_monaie,baguette_farinee)
• sortir(porte_boulangerie)

Quand on apprend l'objet, ça mets une petite-claque derrière la tête au début. une fois acquis, ça se fait tout seul, et ça devient tout naturel. Personnellement, je trouve ça plus simple.

Dans les 2 cas, dès qu'on attaque de la programmation concurrente, ouïe ouïe!
Soit on ne crée des threads ou autres que pour certains calculs dont on est certain que ça ne va pas interférer avec le prog principal, soit on essaye de tout mélanger en même temps et il faut y aller à coups de sémaphores, synchronized, etc. Tester dans tous les sens, se dire qu'avec les conditions de courses on peut avoir zapper un truc.

Par contre, si il y a moyen de trouver une nouvelle façon de penser les choses, là ça peut-être fantastique. Il y a plusieurs langages vraiment orientés vers des concepts différents, mais aucun (à ma connaissance) ne semble s'être vraiment imposé comme LA solution.

Un truc que j'aime bien, c'est en VHDL la façon de coder qui implique que tout se fait en même temps, sauf si spécifié différemment. Il y a peut-être moyen de creuser là-dessous.

Par contre, écrire de l'assembleur à la main pour que ça mouline plus vite c'est pas bien malin. Le compilateur est juste plus fort que toi.

En lisant la news, il propose l'OS comme une interface entre une machine virtuelle et le hardware. De ce que je comprends (là je suis pas sûr de moi), il veut juste changer la partie kernel. Toute la partie UI et les primitives systèmes peuvent rester les mêmes si il parle de machine virtuelle.

[Paul TOTH]

Je pense qu'un poil au delà de ça, le gros problème, c'est la réflexion.
Coder un truc en C, ça s'apprend relativement facilement. C'est un langage procédural, tout se passe comme dans la vie:

• entrer(porte_boulangerie)
• acheter_pain(&porte_monaie,baguette_farinee)
• sortir(porte_boulangerie)

Quand on apprend l'objet, ça mets une petite-claque derrière la tête au début. une fois acquis, ça se fait tout seul, et ça devient tout naturel. Personnellement, je trouve ça plus simple.

Dans les 2 cas, dès qu'on attaque de la programmation concurrente, ouïe ouïe!
Soit on ne crée des threads ou autres que pour certains calculs dont on est certain que ça ne va pas interférer avec le prog principal, soit on essaye de tout mélanger en même temps et il faut y aller à coups de sémaphores, synchronized, etc. Tester dans tous les sens, se dire qu'avec les conditions de courses on peut avoir zapper un truc.

Par contre, si il y a moyen de trouver une nouvelle façon de penser les choses, là ça peut-être fantastique. Il y a plusieurs langages vraiment orientés vers des concepts différents, mais aucun (à ma connaissance) ne semble s'être vraiment imposé comme LA solution.

Un truc que j'aime bien, c'est en VHDL la façon de coder qui implique que tout se fait en même temps, sauf si spécifié différemment. Il y a peut-être moyen de creuser là-dessous.

Par contre, écrire de l'assembleur à la main pour que ça mouline plus vite c'est pas bien malin. Le compilateur est juste plus fort que toi.

En lisant la news, il propose l'OS comme une interface entre une machine virtuelle et le hardware. De ce que je comprends (là je suis pas sûr de moi), il veut juste changer la partie kernel. Toute la partie UI et les primitives systèmes peuvent rester les mêmes si il parle de machine virtuelle.

alors je suis d'accord avec toi sur l'intérêt d'un nouveau concept de programmation, qui serait à l'objet ce que l'objet est au procédural, avec l'ajout d'un dimension multitâche.

mais tout comme la programmation objet génère du code assembleur, tout comme C++ n'est qu'une surcouche à C, on pourrait avoir ce nouveau langage sur l'API existante ( reste à l'inventer )

et pour en revenir à l'assembleur ou pas, là n'est pas le soucis, on peut code en assembleur et faire de l'OLE du COM et SOAP et de l'XML...autant de techniques qui sont certainement intéressantes dans des cas précis mais qui donnent des lourdeurs de traitement épouvantables dans la plus part des cas.
Sauf que quand on vient dire que c'est lourd, on nous répond que la RAM et le disque ça ne coûte plus rien, que Internet à 512Ko c'est préhistorique et qu'on va pas revenir à la programmation en assembleur...ben oui mais entre l'assembleur et ça il y'a quelque chose comme 20 années d'évolution de la programmation dans lesquelles tout n'est pas à jeter.

[deadalnix]

Et qu'est-ce qu'il propose, concrètement ? Parce que "repenser le système", c'est un peu vague...

Ils ont récemment publié un tas de travaux de recherches à ce sujet. Cherche barrelfish ou helios pour en savoir plus

[pseudocode]

attention la gestion des multicoeurs passe également par le langage de programmation.
Si tu ne spécifies pas dans ton code source avec des mots-clés que tu souhaites répartir tel ou tel traitement , fonction ou processus sur un coeur du CPU en particulier , eh bien ton programme une fois compilé tournera comme s'il avait été conçu pour un "vulgaire" pentium d'ancienne génération...

Là tu décris le moyen d'optimiser des applications sur un OS conventionnel qui tourne sur une machine multicoeurs. Bref, tu parles de faire du multi-threading.

Dave Probert parle carrément d'optimiser l'OS pour un machine multicoeurs. L'OS sera alors multi-core. Pour faire simple, on pourrait dire "multi-kernel".

La programmation des applications s'en trouvera effectivement modifiée, mais elle le sera surtout a cause de l'architecture de l'OS, et pas de la présence des coeurs. Si le multi-threading reste possible, il ne sera plus necessaire pour profiter d'un gain de puissance.