Microsoft veut repenser le noyau

L'idée est séduisante pour l'utilisation des multicores. Les applications existantes font marcher plus vite qu'avant.

"le développeur parle d’un système qui apprendrait de l’utilisateur qui manifesterait sa frustration en appuyant sur un bouton pour montrer que le système n’est pas assez rapide"

Extra... Windows ne se lancera plus, car le bouton "RESET" sera trop souvent pressé... MDR --->

Il a des idées cet architecte, mais il ne voit pas correctement le monde réel ...
Le problème des machines aujourd'hui, ce n'est certainement pas l'occupation de la charge cpu.
Un utilisateur, ca lance firefox, excel et outlook. Depuis quand ces applis prennent trop de ressources ?
Par contre, il aurait aussi pu remarquer que ce qui ralenti une machine, ce n'est certainement pas excel à 100% de CPU, mais ces requêtes débiles qui bouclent toutes seules et qui freezent la machine, ou une partie de ses ressources. (requetes sur un périphérique, sur le reseau ou autre) (parfait exemple reproductible de la disquette non insérée dans le lecteur)
Après, s'il veut se casser la tête sur l'optimisation de Maya ou de mathématica, ce n'est pas en l'envoyant dans un système séparé qu'il va le faire tourner plus vite (puisqu'il est déjà prioritaire et plus ou moins seul sur la machine, personne ne s'amuse à lancer les deux en même temps)

Enfin, cet architecte, s'il était plus humain et moins geek, saurait que c'est la machine qui travaille pour l'homme, pas l'inverse. Donc son bouton manuel pour indiquer ses préférences, c'est pas vraiment dans ce sens là qu'il faut réfléchir ...

Mais bon, allez, 1 point pour l'effort.

Non, en fait, l'ingénieur en question bosse chez MS: la gestion des multiprocesseurs sur ces SE laisse vraiment à désirer, et le noyau actuel est limité à 32 coeurs logiques (avec les hexacore Hyperthreadés de Intel, ça en fait déjà 12 de bouffés, sur un serveur quadri-CPU, ayé, Windows y suit plus).

Ca fait maintenant 2 ans que sous Linux le scheduler a été repensé pour tirer partie de processeurs ultra nombreux sans bouffer de la RAM pour rien (parce qu'avant, un système multiprocesseur 1024 coeurs bouffait un Go de RAM pour la queue de process).

C'est un ingé MS: il a une idée, ça fait 10 ans qu'ailleurs on a déjà concrétisé, mais chez lui c'est tout neuf.

Améliorer la gestion de l' hardware et des ressources ok.
L'ingénieur MS (Dave Probert, Kernel architect MS) mise bien quand il entend exploiter mieux les multicore, je parle du proget Barrelfish, dans lequel MS teste un sample avec une machine intel à 48core. Il mise bien car c'est là le futur et à l'heure actuelle la gestion multicore sous windows n'est pas très performante.
Bien pour l'implémentation du Trim sous win7.
Dave a comme originalité la vison d'un "hypervisor" dans le kernell qui fait de layer entre la machine virtuelle et l'hardware, et ce juste pour être flexible au style de l'utilisateur.
Bien d'idées, de projet lancés comme le Barrelfish, mais officiellement aucune direction n'a pas encore été prise.

Côté réactivité, je n'ai encore rien vu de mieux que Beos.
Qu'elle bonne idée pour l'époque que d'avoir fait un "thread" pour l'affichage de chaque application : on ne passait pas son temps à attendre que l'application X, Y ou Z ai finis d'enregistrer un fichier pour pouvoir ouvrir son menu.

"le développeur parle d’un système qui apprendrait de l’utilisateur qui manifesterait sa frustration en appuyant sur un bouton pour montrer que le système n’est pas assez rapide."
Houah, un starter sur mon ordi. Je ne sais pas pourquoi mais je sens que beaucoup de monde va passer son temps à cliquer dessus, non pas par ce qu'une autre applis consomme trop de ressource, mais par ce que le gentil vendeur va lui avoir dit que "ça accélère l'application". Vous savez quoi? S'ils mettent cette idée en pratique, on va voir pleins de gens sur internet qui diront partout qu'Excel va deux fois plus vite quand il clique sur ce bouton magique.

Ce que Dave Probert cherche est à donner plus de flexibilté à l'OS, il veut introduire dans le Kernel un hypervisor qui va paramétrer globalement les ressources de façon personnalisable. C'est déjà un peu personnalisable, lui il veut que l'OS le soit encore plus.
Pour un PC réactif faut pas rêver, faut du matos, hardware, et bon, SSD in primis.
Ce qui ne dispense pas le OS de bien gérer les ressource et puisqu'on parle de PC -Personal C- un processus de personnalisation est toujours le bienvenu. Vous conviendrez avec moi que avoir un OS qui peut se paramétrer automatiquement en fonction de votre style d'utilisation est une solution convenable.
Car le futur nous réserve des OS qui vont se paramétrer aussi en fonction de notre humeur quotidien (le bouton à appuyer quand ça ne va pas est rudimentaire) et de notre pression artérielle et de la fatigue visuelle, ça ne sera pas pour demain.

Il n'y a pas besoin de passer par un hyperviseur pour faire ça! Ce type de solution va entraîner une complexification de l'OS, et surtout un gâchis de RAM (rappel: chaque process d'une machine peut partager ses ressources avec d'autres; par contre, pas moyen de faire ça de manière raisonnable entre des process inter-machines).

La SEULE raison qui pourrait valider un tel remaniement serait de conserver une compatibilité partielle entre cette nouvelle version et les anciennes itérations de l'OS, tout en obtenant une relative stabilité.

Mais à ce moment-là, autant partir sur un micro-kernel: ce serait plus simple.

Bien.
Autre chose, il y a quelques années j'ai entendu dire que pour les requêtes ce n'était plus le CPU qui interromperait ce qu'il faisait pour interroger les périphériques, ce qui causait du ralentissement; mais que ce serait aux périphs d'interrompre le CPU lorsqu'ils voudraient interagir.

@geek_du_44: tu remontes à loin, là. Non, c'est toujours la même chose: le périphérique émet une interruption, le CPU s'occupe du périph, et retourne à autre chose. Le gros progrès qui a eu lieu il y alongtemps se trouve au niveau des disques durs IDE: les disque Ultra DMA étaient désormais capables d'accéder à une zone mémoire sans demander au processeur de s'occuper d'eux: le proc' n'avait plus qu'à faire une copie vers la zone mémoire dédiée au contrôleur UDMA, et celui-prenait alors la main pour gérer la partie protocolaire du transport, et inversement. A l'inverse, auparavant, le processeur devait s'occuper de gérer le périphérique pendant toute la durée de l'opération.

L'autre gros progrès est plus récent, et date de 2000: la création d'interruptions virtuelles, gérées par un contrôleur d'interruptions (en général, le contrôleur ACPI pour ne pas le nommer), fait que le processeur a moins de travail à fournir pour dissocier quel périphérique se gère via quelle interruption.

Mais le processeur doit toujours répondre à un périph' qui émet une interruption, il n'a pas le choix... C'est juste que désormais, les périphériques devenus plus intelligents ont moins besoin de demander l'aide du processeur.

Ah ! C'est bien. Enfin quelqu'un chez MS qui se rend compte que leur noyau est tout pourri, bon j'édulcore avec de la litote : qu'il mérite une refonte. Faut dire qu'en même temps, http://www.top500.org/stats/list/34/osfam et il faut s'accrocher pour convaincre un sysadmin unix / linux que quitter son unix multitâches multiprocesseur multiutilisateurs réseau par conception pour un système MS va lui améliorer ses performances, sa tenue en charge, sa disponilibité, le coût, la facilité d'administration d'une grande quantité de machines. Le noyau futur saura-t-il faire autre chose que gérer un utilisateur unique, sur un PC unique, qui exécute un système unique (avec licence) sur un processeur unique (avec licence aussi) ? Le dire, c'est bien, c'est qu'il y a déjà un début de prise de conscience. Après, il faudra que la mise en pratique n'échoue pas à cause de considérations plus marketing que techniques.

Je rebondis sur l'affaire de la disquette. Le CTRL de disquette est géré par un DMA (direct memory access) qui tourne à 4MHz (non, pas d'erreur de typo). Donc, quand le machin cherche la disquette, le PC se comporte comme un PC premier modèle, celui avec le 8088 à 4,77 MHz. Forcément, ça ralentit... De plus, le PC comporte toujours un bus ISA, 16bits à 8 MHz, même si le connecteur n'est plus présent depuis 10 ans maintenant, regardez votre gestionnaire de périphériques. L'utilisation d'un périphérique de ce bus, ou pire l'interruption d'un périphérique connecté à ce bus, ralentit fortement le PC : lecteur de disquette, port imprimante parallèle, tablette graphique sur le port série, joystick sur la prise DB15 jaune... La solution : émulation USB ou recyclage de l'objet ancien !

Charmante initiative, mais il était temps qu'ils y pensent

CaptainDangeax >
lecteur de disquette > plus personne n'en utilise
port imprimante parallèle > faut une vielle imprimante pour pas avoir de port USB ou réseau
tablette graphique sur le port série > Elles sont passé au USB maintenant
joystick sur la prise DB15 jaune > De mémoire ils sont USB maintenant et il faut chercher dans le très bas de gamme pour en trouver qui se branchent sur la carte son (je n'ai pas vu de "prise DB15 jaune" ailleurs)

Reste quoi alors? Le matériel qu'on a rentabilisé depuis quelques années et qu'on ne change pas par ce qu'on a pas besoin de mieux? Bon, c'est pas si génant alors.