Depuis quelques années, on assiste à la généralisation des puces multicoeur. En effet le nombre de transistors que les nouvelles finesse de gravure permettent de caser sur un bout de silicium impose aux fondeurs de mettre plusieurs processeurs par coeur, en ayant beaucoup trop pour faire un seul coeur qui serait extrêmement complexe et chauferait trop.
Le problèm est que le niveau technique des programmeurs pour gérer le massivement multi thread ne va pas évoluer exponentiellement lui.
Et les archi d'Os actuelles vont rapidement trouver leur limite (ceux qui me connaissent vont comprendre, "suivez mon regard", oui je sais, mais mon propos n'est pas de défendre ma crèmerie, simplement de faire un constat).
Ils ont à mes yeux deux défauts :
- Ils sont basés sur une architecture paginés, même pas segmentée, mais paginée. Hors une archi paginée tue le parrallélisme : elle oblige à passer très souvent par le noyau, avec tous les problèmes que cela comporte.
- Ils sont essentiellement architecturés pour être procéduraux et ne permettent le fonctionnement de logiciel émergent (architecture Com/Dcom et maintenant .Net chez kro, et Kpart chez Kde) que par l'intermédiaire de bidouille plus ou moins "crade".
Alors Hurd ? Ben j'y crois pas.
Le problème du Hurd est que son micronoyau possède peu d'info, et qu'il a donc du mal à optimiser.
Et en plus c'est encore écrit dans un langage à pointeur ce qui le rend amha trop complexe à gérer.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Parallélisme, nouveau défi
Posté par Ontologia (site web personnel) . En réponse au journal Hurd, une si belle idée et pourtant.. Évalué à 3.
Cela risque de se généraliser, dixit intel themselves (aller, au hasard : http://www.x86-secret.com/popups/articleswindow.php?id=125 ) avec des architectures masivement multicoeurs.
Le problèm est que le niveau technique des programmeurs pour gérer le massivement multi thread ne va pas évoluer exponentiellement lui.
Et les archi d'Os actuelles vont rapidement trouver leur limite (ceux qui me connaissent vont comprendre, "suivez mon regard", oui je sais, mais mon propos n'est pas de défendre ma crèmerie, simplement de faire un constat).
Ils ont à mes yeux deux défauts :
- Ils sont basés sur une architecture paginés, même pas segmentée, mais paginée. Hors une archi paginée tue le parrallélisme : elle oblige à passer très souvent par le noyau, avec tous les problèmes que cela comporte.
- Ils sont essentiellement architecturés pour être procéduraux et ne permettent le fonctionnement de logiciel émergent (architecture Com/Dcom et maintenant .Net chez kro, et Kpart chez Kde) que par l'intermédiaire de bidouille plus ou moins "crade".
Alors Hurd ? Ben j'y crois pas.
Le problème du Hurd est que son micronoyau possède peu d'info, et qu'il a donc du mal à optimiser.
Et en plus c'est encore écrit dans un langage à pointeur ce qui le rend amha trop complexe à gérer.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker