Voir la version complète : Question stupide...
Jah_Lover
09/03/2005, 10h21
Bonjour!
Désolé si ma question est crétine, mais je me demandais, étant donné l'augmentation perpetuelle des caches processeurs, si un jour on pourrait voir des kernel qui se chargent directement dans des caches à très faibles latences, et si ça aurait un interet.
Merci!
Adrien
Maxcarpone
09/03/2005, 13h31
Bonjour!
Désolé si ma question est crétine, mais je me demandais, étant donné l'augmentation perpetuelle des caches processeurs, si un jour on pourrait voir des kernel qui se chargent directement dans des caches à très faibles latences, et si ça aurait un interet.
Merci!
Adrien
Question interessante : le problème c'est qu'il faudrait quand même un gros cache, c'est pas avec 1 ou 2Mo que ça sera possible si cela possible! Et j'en sais fichtre rien!
A mon avis il y a de la marge tant qu'on a pas atteint 8Mo (PC mainstream) au minimum.
johnnyholzeisen
09/03/2005, 18h57
Pour Windows, je pense même pas que ce soit envisageable...
Par contre, l'idée pourrait intéresser les linuxiens intéressés par de vrais défis :wink:
Moi je vois pas l'interet que ca pourrait avoir....
Premierement le CPU d'un PC passe la plus grande partie de son temps a effectuer des traitements utilisateurs et non systeme donc l'avoir en cache n'accelererait pas grand chose.
Deuxiemement tout le cache utilisé pour l'OS ne sert plus pour les applications qui pourraient en avoir besoin.
Maintenant c surement possible mais bon je vois pas trop l'interet.
PS : ta question n'est pas bete je me la suis deja posée :wink:
Franck@x86
09/03/2005, 19h16
bah j'allais répondre exactement la même chose :)
Childerik
09/03/2005, 19h19
Une fois que le système est chargé dans la RAM, les DDR actuelles sont tellement rapides qu'on ne verrait aucune différence par rapport à un stockage sur L2. Il y aura toujours un temps d'attente de chargement assez long tant que les HDD n'auront pas vu leur vitesse exploser.
bah j'allais répondre exactement la même chose :) 8)
Une fois que le système est chargé dans la RAM, les DDR actuelles sont tellement rapides qu'on ne verrait aucune différence par rapport à un stockage sur L2. Il y aura toujours un temps d'attente de chargement assez long tant que les HDD n'auront pas vu leur vitesse exploser.
les temps d'accès aussi ...
The(non)Best
09/03/2005, 19h43
Dans ce cas, serait-il possible de voir un jour les HDD remplacés par de la ram, de type Flash ou quelque chose dans le genre?
J'espere :love:
Pour la rapidite et la fiabilite (plus de mecanique)
Minuteman
09/03/2005, 20h22
Dans ce cas, serait-il possible de voir un jour les HDD remplacés par de la ram, de type Flash ou quelque chose dans le genre?
Ca existe déja, mais en faible capacité.
Dans ce cas, serait-il possible de voir un jour les HDD remplacés par de la ram, de type Flash ou quelque chose dans le genre?
la flash, ca a un bon temps d'acces, mais ca reste assez lent dans l'absolu (et cher au Mo)
le seul truc que j'ai vu, c'est un disque 2,5" entièrement en flash, mais c'était hyper cher (plusieurs milliers de dollars). par contre débit CONSTANT de 40Mo/sec.
sinon, avec les technologies flash actuelles, on arive a du 10/12Mo/sec avec les cartes rapides.
sinon, pour le stockage de petite taille, les flash ont tendances a disparaitre, vu que les disques durs 1,8" et 1" sont compétitifs, nettement moins cher, rapide, et pas beaucoup plus gros.
Dans les baladeurs on le voit bien,a terme on aura les lecteurs a disques durs presque partout, sauf pour les joggeurs fous, ou la résistance des flash (pas de pièces mécaniques) est un atout.
le seul autre avantage, c'est que ca consomme moins que un disque dur, mais Sony l'a montré avec les minidiscs, mécanique n'est pas synonyme de consommation élevée.
sinon, pour terminer, il parait (depuis longtemps, cela dit) que les mémoires de type Mram pourait remplacer les disques termes.
je ne serais paussi catégorique que vous en ce qui concerne un kernel qui se logerais en mémoire cache.
Ca existe, il y a plein d'études faites dessu et ça a même un nom: "cache kernel", en cherchant dans google, on peut trouver un paquet de documents la dessu.
On peut remarquer qu'en évoluant beaucoup de systèmes systèmes d'exploitations (autres que linux) tendent a réduire la taille du kernel. Windows a maintenant un micro kernel, comme MACOS, BSD*, Solaris. QNX a même un pico kernel qui tient dans 8Ko de ram.
Un cache kernel est un kernel qui reste en cache, il doit être petit et celui de QNX est probablement toujours en cache. QNX est un système "temps réel", chaque processus/thread a un nombre de cycle précis dédié a l'avance et est recalculé a chaque itération de l'ordonanceur. L'idée est de garantir que l'ordre d'execution des taches sera connu à l'avance et sera toujours le même, c'est primodial dans des systèmes a haute sécurité ou l'erreur n'est pas admise. Le système passe donc beaucoup de temps dans l'ordonnanceur et le gain est certain si il n'y a pas besoin de faire un accès mémoire pour aller le chercher.
Une des évolution majeures des PC est pour moi le fait qu'on fait de plus en plus de choses en même temps. On a un anti-virus qui tourne, un firwall, des MP3 qui sont lus en même temps qu'on fait du Word pendant qu'on encode un trucs en gravant un cd, tout en downloadant la terre entière, bref le PC est multi-tache et mieux il les répartis, plus il parait puissant. C'est d'ailleur l'hyper-threading qui le fait bien ressortir ;).
Sam a montré qu'avec deux cores hyper-threadés si on s'emmelle avec la répartition des taches la cata :), tout ça pour dire qu'un kernel qui resterait en cache tout le temps pour optimiser au mieux le travail des différentes tâches est très loin d'être une abération.
un cache dédié au kernel alors ?
Eventuellement, mais on se retrouverait avec un processeur par système d'exploitation. Et tout n'est pas intéressant dans le kernel. Je ne suis pas sur de mes chiffres mais je crois que le kernel de windows occupe 180Ko de ram, linux 2.4 en a besoin de 1.2Mo et 2.6 dans les 2Mo.
Même pour celui de windows ça ne serait pas très intéressant de mettre tout dans un cache, par contre un espace de mémoire dédié a une sorte de mini kernel qui s'occuperait de choses bien spécifiques, le tout crypté en hardware avec des instruction dédiées a l'ordonacement. Il pourrait monitorer les cores, les remplissement des pipelines, avec un coup de main de l'hyperthreading. Ou bien même repérer un traitement répétitif et reconfigurer une untité de calcul pour booster le traitement répétitif.
Ca serait une sorte de mini-os qui so'ccuperais d'autre(s) os, ... vanderpool, lagrande, ... ?
Si peu pour le kernel de windows ?
en parlant de micro kernel
quelqu'un a vu quelque part sur le net, un QNX ou un netBSD installé sur une TI92+ (donc motorola 68000, mais peu de mémoire)
lechenejb
09/03/2005, 22h47
ba juste en cache, le WAIT, le SIGNAL, le DISPATCHER et ptétre le SCHEDULER aussi, et sa suffit, après c'est pas très utilisé, et ce sont des codes très petit car ultra optimisés. :jap:
johnnyholzeisen
09/03/2005, 22h47
TI 92+ = Motorola 68030 @ 12 MHz et autour des 2 Mo de mémoire ("FlashROM" et RAM)
J'ai pas vu, mais il y a vraiment des personnes qui ont des passions douteuses :whistle:
Se fixer de telles contraintes par plaisir, chapeau !! :jap:
T'es sur que c'est un 68030 ?
johnnyholzeisen
09/03/2005, 22h50
Pas sûr à 100%, mais j'ai lu pas mal de forum sur les Ti 68K...
La je viens de regarder et tout ce que je trouve me dit 68000...
En plus un 68030 avec son modele de gestion de memoire evolue pour si peu de memoire et un bus 32 bits tout ca dans une caltos.
par ex. http://www.alvasoft.net/main.php?p=texas/9x_modeles
johnnyholzeisen
09/03/2005, 22h56
Je me suis planté :jap:
Ma mémoire flanche :whistle:
Franck@x86
09/03/2005, 23h09
Un cache a un fonctionnement statistique, une fonction souvent utilisée à un moment donné, qu'elle soit système ou non, a de fortes chance de se trouver dans le cache.
A contrario, quel est l'intérêt de cacher une fonction système qui ne sert que très peu ? Aucun, ça pollue le cache inutilement.
Pas mal de dll système de Windows sont chargées en mémoire, car toutes les applis natives Windows y font appel (kernel32, user32). Une fois de plus c'est peu utile de charger toutes les dlls système au démarrage, ça prend de la mémoire pour rien. En cas de besoin la dll est chargée.
Jah_Lover
10/03/2005, 05h34
Merci de vos réponse! Quand je posais cette question, je pensais surtout aux micro kernel, pas à Linux (trop gros), ou à des kernel qui n'auraient pour fonction que des rôle très spécifique (comme le dis fennec, la répartition des tâches etc..)
En fait je me demandais si un jour on ne verrait pas une partie de code à l'interieur des processeurs, une sorte de "surcouche" logicielle qui permettrait une "standardisation" et une évolutivité des instructions et qui réduirait le travail de l'OS pour ce qui est de la gestion processeur (genre je t'envoie ce que j'ai a faire dans un langage défini et après tu te débrouille comme tu veux pour me rendre un résultat lisible).. Me suis-je bien fais comprendre? C'est tôt alors ne suis-je peut être pas très clair...
en parlant de micro kernel
quelqu'un a vu quelque part sur le net, un QNX ou un netBSD installé sur une TI92+ (donc motorola 68000, mais peu de mémoire)
moi je voulais le faire, µCLinux, sur une 89 ...
ben je sais que "yen a qui ont essayé" netBSD sur ti92+ car ça devrait passer en principe... mais faudrait plus de mémoire... faudrait trouver comment adapter un lot compact flash ou SD-card sur une ti92+ :heink:
Si ça peut se faire sur une 89, ça m'intéresse grave :)
http://mail-index.netbsd.org/tech-ports/2002/05/09/0000.html
c'est mal barré
si qq'un a le courage d'épluché ça : http://bespin.org/~qz/irc/clog-2000-2003/02.09.25
Merci de vos réponse! Quand je posais cette question, je pensais surtout aux micro kernel, pas à Linux (trop gros), ou à des kernel qui n'auraient pour fonction que des rôle très spécifique (comme le dis fennec, la répartition des tâches etc..)
En fait je me demandais si un jour on ne verrait pas une partie de code à l'interieur des processeurs, une sorte de "surcouche" logicielle qui permettrait une "standardisation" et une évolutivité des instructions et qui réduirait le travail de l'OS pour ce qui est de la gestion processeur (genre je t'envoie ce que j'ai a faire dans un langage défini et après tu te débrouille comme tu veux pour me rendre un résultat lisible).. Me suis-je bien fais comprendre? C'est tôt alors ne suis-je peut être pas très clair...
Je crois que Transmeta utilise un principe qui n'est pas trop eloigné de ce à quoi tu penses
http://arstechnica.com/articles/paedia/cpu/transmeta.ars
pour un peu plus d'info
Jah_Lover
10/03/2005, 11h34
Vi on peut voir ça comme du code morphing mais un peu plus avancé.. Une base normalisée d'appel CPU qui seraient interpretés par un "microcode" qui permettrait de mettre, en gros, "n'importe quelle" architecture derrière et qui gèrerait tous les problèmes de répartition de tâches etc..
J'ai mis "n'importe quelle" entre guillemet parce que je ne vois pas la chose comme l'émulation 32bits des Itaniums.. Mais quand je vois les problème d'optimisation sur les multicores (enfin sur les multi-proc pour l'instant) je me dis qu'une gestion "interne" au processeur de ces problèmes ne serait pas un mal.
Je vais me faire taper dessus (huhu!) mais le Cell à l'air de représenter (d'une façon un peu différente, et selon les spéculations que j'ai pu lire) ce dont je parle : un PPC qui gère les tâches des unités de calculs autour.
vala vala...
Pour ce qui est d'une "base normalisée d'appel" CPU je crois que les PCU x86 illustrent parfaitement ta question !
Sinon pour ce qui est de la répartition des taches directement faite par le CPU a mon avis ca manquera un peu de flexibilité pour les applications temps-réel par exemple quand on a besoin de faire un ordonnancement bien particulier qui ne peu pas forcément se résumer à un algorithme.
Oui, c'est plus à l'OS qu'au CPU de répartir les threads.
C'est le 1er, le coordinateur, celui qui a la "vision" de l'ensemble, le CPU, que ce soit demandé par l'OS ou par une interruption traite ce qu'on lui demande de traiter, et ne prend aucune décision, enfin pas à ce niveau (cf prédiction de branche).
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. Tous droits réservés