« Il faut repenser les OS pour les processeurs multi-coeurs »

Moi j'estime que l'optimisation du code pour des besoins de rapidité, c'est pas mon travail. C'est devenu le travail du compilateur.

Donc que déjà quand on parle de langages rapides ou lents, on se trompe de débat. C'est pas le langage qui est performant (ou pas), c'est le compilateur. Sinon pourquoi on compare les performances du code compilé C selon les compilateur ?

C'est vrai, à condition que tu ne codes pas comme un pied non plus.

Quand on regarde les architectures de système ou de langage nouveau tel que Lisaac ou Hurd !

On peut voir un espoir d'améliorations.

Le C a été crée dans le but de faire un OS de façon plus facile et performante.C'était il y a plus de 30ans. On connait le résultat : "Unix".

Hurd par exemple veut exploser le noyau en programme indépendant. Que ce soit la pile réseau ou les systèmes de fichiers. Le portage sur L4 (jamais finalisée) devait permettre (en théorie) au programme de gérer eux même leurs swap et thread, mais sans prendre le role de l'OS.
L'idée est simple, la séparation des mécanisme et des politique. L'OS fournie le mécanisme, le programme choisit sa politique de swap ou de thread, si il n'en fournie pas c'est la politique par défaut.

Lisaac 0.39 de son côté, a un modèle de gestion du multitâche intéressant, le mieux est d'aller voir sur le site.

L'union d'un langage évolué comme lisaac avec la séparation des mécanismes et des politiques systèmes comme hurd, serait un bon moyen d'avoir du neuf dans les système d'exploitations, par la facilité et la puissance du langage d'un côté, et la modularité et le découpage fonctionnel, le découpage de l'OS et des applications de l'autre.

La question essentiel que je me pose : "peut-on changer de façon de concevoir l'outil informatique avec les anciens paradigmes systèmes et de langage ? Ou faut-il une coupure avec l'existant et dépassé ces anciens concepts ?"

Bien a vous.

+1

La gestion "multicore" de Solaris (ou d'autres OS "serveur" n'est pas vraiment une remise en cause de l'architecture de l'OS. On a toujours du time-sharing pour simuler le multitâche sur chaque core, et un seul kernel qui gère la totalité des ressources hard/soft.

L'optimisation "multicore" dans es OS consiste généralement à avoir des algorithmes de scheduling optimisés qui permettent de limiter les défauts de cache dus aux commutations de tâches (time-sharing) sur chaque core.

Il y a encore des gens qui croient au tout assembler

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

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

-> 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).

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é