IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

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

  1. #1
    Expert éminent sénior
    Avatar de Katleen Erna
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    1 547
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 547
    Points : 75 992
    Points
    75 992
    Par défaut "Il faut repenser les OS pour les processeurs multi-coeurs", d'après Microsoft
    "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 ?

  2. #2
    Membre éclairé
    Homme Profil pro
    NoOb
    Inscrit en
    mai 2007
    Messages
    554
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : NoOb

    Informations forums :
    Inscription : mai 2007
    Messages : 554
    Points : 849
    Points
    849
    Par défaut
    Citation Envoyé par Katleen Erna Voir le message
    "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

  3. #3
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 448
    Points : 2 199
    Points
    2 199
    Par défaut
    Citation Envoyé par Katleen Erna Voir le message
    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 ?

  4. #4
    Membre actif
    Profil pro
    Développeur informatique
    Inscrit en
    août 2008
    Messages
    148
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2008
    Messages : 148
    Points : 231
    Points
    231
    Par défaut
    -> 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).


    Citation Envoyé par kaymak Voir le message
    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é

  5. #5
    Membre expérimenté
    Profil pro
    Inscrit en
    septembre 2006
    Messages
    477
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : septembre 2006
    Messages : 477
    Points : 1 490
    Points
    1 490
    Par défaut
    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

  6. #6
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    novembre 2002
    Messages
    8 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 8 211
    Points : 26 601
    Points
    26 601
    Par défaut
    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 !
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  7. #7
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 288
    Points
    2 288
    Par défaut
    Et qu'est-ce qu'il propose, concrètement ? Parce que "repenser le système", c'est un peu vague...

  8. #8
    Membre averti
    Homme Profil pro
    Ingénieur sécurité
    Inscrit en
    avril 2007
    Messages
    234
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur sécurité

    Informations forums :
    Inscription : avril 2007
    Messages : 234
    Points : 335
    Points
    335
    Par défaut
    Citation Envoyé par Paul TOTH Voir le message
    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

  9. #9
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    novembre 2002
    Messages
    8 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 8 211
    Points : 26 601
    Points
    26 601
    Par défaut
    Citation Envoyé par gannher Voir le message
    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.

    Citation Envoyé par gannher Voir le message
    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.

    Citation Envoyé par gannher Voir le message
    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.

    Citation Envoyé par gannher Voir le message
    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 ?
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  10. #10
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 466
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 466
    Points : 17 429
    Points
    17 429
    Par défaut
    Citation Envoyé par Paul TOTH Voir le message
    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.

    Citation Envoyé par Katleen Erna Voir le message
    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..

  11. #11
    Membre averti
    Homme Profil pro
    Ingénieur sécurité
    Inscrit en
    avril 2007
    Messages
    234
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur sécurité

    Informations forums :
    Inscription : avril 2007
    Messages : 234
    Points : 335
    Points
    335
    Par défaut
    Citation Envoyé par Paul TOTH Voir le message
    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.

    Citation Envoyé par Paul TOTH Voir le message
    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.

  12. #12
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 466
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 466
    Points : 17 429
    Points
    17 429
    Par défaut
    Citation Envoyé par Génoce Voir le message
    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

  13. #13
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 466
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 466
    Points : 17 429
    Points
    17 429
    Par défaut
    Citation Envoyé par gannher Voir le message
    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

    Citation Envoyé par gannher Voir le message
    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

  14. #14
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    novembre 2002
    Messages
    8 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 8 211
    Points : 26 601
    Points
    26 601
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    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
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  15. #15
    Membre averti
    Homme Profil pro
    Ingénieur sécurité
    Inscrit en
    avril 2007
    Messages
    234
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur sécurité

    Informations forums :
    Inscription : avril 2007
    Messages : 234
    Points : 335
    Points
    335
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    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é.

  16. #16
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    novembre 2002
    Messages
    8 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 8 211
    Points : 26 601
    Points
    26 601
    Par défaut
    Citation Envoyé par gannher Voir le message
    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.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  17. #17
    Membre éclairé
    Profil pro
    Inscrit en
    février 2010
    Messages
    412
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2010
    Messages : 412
    Points : 788
    Points
    788
    Par défaut
    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.

  18. #18
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    novembre 2002
    Messages
    8 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 8 211
    Points : 26 601
    Points
    26 601
    Par défaut
    Citation Envoyé par Rams7s Voir le message
    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.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  19. #19
    Membre émérite
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 2 502
    Points
    2 502
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    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

  20. #20
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 062
    Points : 15 892
    Points
    15 892
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    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.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

Discussions similaires

  1. Réponses: 0
    Dernier message: 18/04/2015, 09h18
  2. alias ou synonymes pour les tables ou les champs ?
    Par nanou9999 dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 16/03/2006, 11h04
  3. [Jobs] Supprimer tous les jobs pour les recreer
    Par yolepro dans le forum Oracle
    Réponses: 3
    Dernier message: 25/11/2005, 16h47

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo