Pour contredire un peu le dernier lien, quelque peu négatif envers les micro-noyaux : je pense que les micro-noyaux sont à l'OS ce que l'objet est à la programmation.
Ce que je veux dire : dans les deux cas, on passe à un niveau d'abstraction supérieur. Dans les deux cas, les avantages au niveau du design apparaissent immédiatement, et on voit tout de suite l'intérêt pratique... à condition que les performances en terme de vitesse d'exécution ne s'effondrent pas, sinon tous ces nouveaux avantages n'ont pas grand intérêt, car la vitesse reste la fonctionnalité la plus recherchée.
Or, justement, dans le cas de la programmation objet et des micro-noyaux, un tas de petite bidouille nous sont interdites, du fait de la plus grande rétention d'information (chaque module/serveur ne communique avec les autres qu'au travers d'interfaces, il ne connaît rien de ce qui se passe à l'intérieur de chacun) induite par l'élévation du niveau d'abstraction.
Et puisqu'on ne peut appliquer ces petites bidouilles (qui sont en général de belle prouesse en terme de hacking d'ailleurs), cela fait autant d'optimisation manuelle perdue ! Une seule solution :
1) il faut que les mécanismes soient impeccablement pensés, car la moindre perte de performance due à un mauvait choix se fera ressentir à tous les niveaux, puisque inévitable !
2) il faut qu'un maximum d'optimisations soient applicables automatiquement quand cela est possible, puisque le programmateur ne peut le faire lui-même, à moins de briser le principe de rétention d'information et de modularité. (ce deuxième est surtout valable pour la programmation objet, plus que pour les micro-noyaux, à mon avis)
Dans la pratique, qu'est-ce que cela donne ? Si les débuts des compilateurs de language orienté objets furent une catastrophe (mais si, rappellez-vous, personne n'y croyait...), il faut quand même reconnaître que ça s'est bien amélioré, et en fait, on arrive même (avec des languages comme Eiffel par exemple) à un stade où le compilateur prend en charge tellement d'optimisation automatique qu'un super-hacker ne ferait pas mieux, voire moins bien, et en bien plus de temps. Mais bien sûr, pour que le compilateur puisse faire automatiquement ces optimisations, il faut que lui apparaisse la structure de haut niveau du programme : de telles optimisations automatiques seraient impossibles en C par exemple !
Et là, les avantages prennent le pas sur les inconvénients, mais il faut énormément de travail en amont, et ça ne s'est pas fait sans heurt, sans erreur et sans recherche éperdue.
Je suis persuadé qu'il en sera de même pour les micro-noyaux : au lieux de laisser à chacun le boulot de faire ses petites optimisations dans son coin (principalement l'énorme problème que constitue la communication inter-processus), une grosse part du problème est déplacée dans le micro-noyaux, mais celui-ci devra se révéler d'une implémentation impeccable, car toute perte de performance sera tout de suite très sensible sur un système complet. Or, le temps passant, je pense que les micro-noyaux vont commencer à révéler leur potentiel pratique.
Ensuite, il faudra que tout ce qui se construit au-dessus suive, et soit au top de la nouveauté, pour que cela intéresse du monde, et ça ne se fera pas en deux ans, mais ce n'est pas une raison pour suivre l'évolution de la chose, avec espoir, mais surtout pas avec de l'impatience ;)
[^] # programmation objet et micro-noyaux : même combat !
Posté par JSL . En réponse à la dépêche Version 0.1 de L4Ka:Pistachio disponible. Évalué à 10.
Ce que je veux dire : dans les deux cas, on passe à un niveau d'abstraction supérieur. Dans les deux cas, les avantages au niveau du design apparaissent immédiatement, et on voit tout de suite l'intérêt pratique... à condition que les performances en terme de vitesse d'exécution ne s'effondrent pas, sinon tous ces nouveaux avantages n'ont pas grand intérêt, car la vitesse reste la fonctionnalité la plus recherchée.
Or, justement, dans le cas de la programmation objet et des micro-noyaux, un tas de petite bidouille nous sont interdites, du fait de la plus grande rétention d'information (chaque module/serveur ne communique avec les autres qu'au travers d'interfaces, il ne connaît rien de ce qui se passe à l'intérieur de chacun) induite par l'élévation du niveau d'abstraction.
Et puisqu'on ne peut appliquer ces petites bidouilles (qui sont en général de belle prouesse en terme de hacking d'ailleurs), cela fait autant d'optimisation manuelle perdue ! Une seule solution :
1) il faut que les mécanismes soient impeccablement pensés, car la moindre perte de performance due à un mauvait choix se fera ressentir à tous les niveaux, puisque inévitable !
2) il faut qu'un maximum d'optimisations soient applicables automatiquement quand cela est possible, puisque le programmateur ne peut le faire lui-même, à moins de briser le principe de rétention d'information et de modularité. (ce deuxième est surtout valable pour la programmation objet, plus que pour les micro-noyaux, à mon avis)
Dans la pratique, qu'est-ce que cela donne ? Si les débuts des compilateurs de language orienté objets furent une catastrophe (mais si, rappellez-vous, personne n'y croyait...), il faut quand même reconnaître que ça s'est bien amélioré, et en fait, on arrive même (avec des languages comme Eiffel par exemple) à un stade où le compilateur prend en charge tellement d'optimisation automatique qu'un super-hacker ne ferait pas mieux, voire moins bien, et en bien plus de temps. Mais bien sûr, pour que le compilateur puisse faire automatiquement ces optimisations, il faut que lui apparaisse la structure de haut niveau du programme : de telles optimisations automatiques seraient impossibles en C par exemple !
Et là, les avantages prennent le pas sur les inconvénients, mais il faut énormément de travail en amont, et ça ne s'est pas fait sans heurt, sans erreur et sans recherche éperdue.
Je suis persuadé qu'il en sera de même pour les micro-noyaux : au lieux de laisser à chacun le boulot de faire ses petites optimisations dans son coin (principalement l'énorme problème que constitue la communication inter-processus), une grosse part du problème est déplacée dans le micro-noyaux, mais celui-ci devra se révéler d'une implémentation impeccable, car toute perte de performance sera tout de suite très sensible sur un système complet. Or, le temps passant, je pense que les micro-noyaux vont commencer à révéler leur potentiel pratique.
Ensuite, il faudra que tout ce qui se construit au-dessus suive, et soit au top de la nouveauté, pour que cela intéresse du monde, et ça ne se fera pas en deux ans, mais ce n'est pas une raison pour suivre l'évolution de la chose, avec espoir, mais surtout pas avec de l'impatience ;)