Après les explications indispensables (et claires, même en anglais), des chiffres étonnants sont fournis (graphiques à l'appui) !
Le grand vainqueur est le duo Low-Latency+Preemption qui tire le meilleur parti des 2. C'est donc en toute logique que les mainteneurs des patch (Robert Love et Andrew Morton) travaillent sur une fusion.
Linux n'a pas fini d'accélérer...
Aller plus loin
- L'article (23 clics)
- FirstLinux (3 clics)
- Preemption Patch (13 clics)
- Low-Latency Patch (24 clics)
# Boost
Posté par VACHOR (site web personnel) . Évalué à 3.
Pasque quoiqu'on en dise, depuis 2 ans, il accélère pas ;-(
D'ailleurs je pense que je vais me ré-installer un bon vieux 4DOS avec Stacker 2.0.
[^] # Rien à voir, comme d'hab, avec la news
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
Mais leur principal problème est qu'ils ne connaissent qu'une seule architecture, un seul OS, ce qui rend très difficile d'appréhender correctement l'informatique !
Regardez autour de vous, les gens ne comprennent plus le fonctionnement des ordinateurs, ils ne voient que la partie visible de l'iceberg sans se douter de ce qui se trouve en dessous ! Quand ça plante, ils rebootent !
Quand les informaticiens de notre génération (>25 ans, j'aurais pu mettre moins pour être démago, mais non) ne feront plus de technique, l'informatique dépérira doucement faute de personnes comprennant de façon globale des ordinateurs.
Il faut revenir à des systèmes simples et logiques, comme l'amiga, pour avoir des bases solides. Les élèves élevés avec la pourriture intellienne n'auront malheureusement pas cette chance...
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par Lu (site web personnel) . Évalué à 10.
Quelqu'un ayant l'esprit curieux se posera toujours les bonnes questions, quel que soit le système utilisé.
Quelqu'un qui n'utilise l'ordinateur que comme un outil se fiche pas mal de la manière dont ça fonctionne, sur Intel/Windows XP ou sur Atari ST.
Ma soeur a douze ans et ne reboote pas au moindre souci. Tout ça juste pour dire qu'avec un minimum de formation (et d'information), les futurs "informaticiens" seront tout aussi compétent que les actuels.
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
Sauf que les informaticiens actuels ont appris la plupart de leurs connaissances de base tous seuls. Ce n'est pas à l'école qu'on apprend le fonctionnement d'un PC, on apprend juste à l'utiliser, ce qui est insuffisant pour un futur hacker. (et puis je sais pas ce qu'il en est maintenant, mais il y a 10 ans les profs étaient plutot nuls en info).
Je pense (des fois ça m'arrive mais ça fait mal) que l'architecture intel est trop complexe pour être facilement appréhendée, alors qu'à notre époque (il y a bien 10 ans...) les ordinateurs et les systèmes d'exploitation associés étaient beaucoup plus simples à comprendre (le DOS ne compte pas, ce n'est pas un OS). Et c'est ça qui fait des bases solides. Et pour bien construire, il faut des bases solides. Et j'ai bien peur que nos futurs informaticiens ne soient pas très nombreux à maîtriser les vraies bases de l'informatique.
[^] # -1, car totalement hors-sujet
Posté par Lu (site web personnel) . Évalué à 10.
Je te "rassure", les profs n'ont pas trop changé apparemment, puisque le prof d'informatique qui officie au collège de ma frangine est plutôt un prof de Windows(tm)(c)(etc).
J'ai même dû aller lui expliquer ma vision des choses après qu'il lui ai collé une bulle parcequ'elle avait rapporté son devoir dans un (je cite) format compressé totalement exotique. Ce format compressé, c'était du ....tar.bz2
Pour lui (et donc pour ses éleves), traitement de texte=MS Word, tableur=MS Excel, compression=WinZIP, ordi=MS Windows, et j'en passe.
Et ça, je trouve que c'est bien plus affolant que le manque de formations de quelques informaticiens, car c'est cette masse de jeunes qui risque de devnir une masse de moutons bien à l'écoute des discours protectionnistes de MS et autres gloutons (cf DMCA, etc) dans les années à venir.
[^] # Re: -1, car totalement hors-sujet
Posté par bad sheep (site web personnel) . Évalué à 5.
[^] # Re: -1, car totalement hors-sujet
Posté par ghent . Évalué à 6.
[^] # HS, d'accord mais pu*ain c grave !
Posté par David Bosman . Évalué à 10.
réduire l'informatique à MS et aux outils qui tournent sous Windows, c'est grave.
Et qu'elle ne connaisse pas Linux n'est pas une raison : l'incompétence ou le manque de curiosité n'est pas une 'bonne excuse' quand on est enseignant !
Moi je lui colle un zéro pointé et je la démissionne d'office ;-)
David
PS : rassure moi : elle a rectifié ta note et tu lui a expliqué comment affiché un tar.gz sous Win ? :))
[^] # Re: HS, d'accord mais pu*ain c grave !
Posté par Lu (site web personnel) . Évalué à 1.
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par François Romieu (site web personnel) . Évalué à 9.
des microprocesseurs et des ordinateurs. Dans le volume horaire qui nous est accordé, je pense que
les élèves ne s'en sortent pas trop mal (on a tendance à supposer trop de choses connues).
L'architecture Intel n'est pas si complexe que ça: elle est assez pragmatique, a pas mal vécu et
permet d'apprendre sur un système qui, hors des lieux d'enseignement, a également sa place en
production. C'est rare. Je serais surpris que la vague actuelle de bons informaticiens (parce qu'il
y en a quand même pas mal) ne soit pas un peu liée à la démocratisation du pécé.
--
Ueimor
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par Jul (site web personnel) . Évalué à 10.
Le hardware à trop d'influence pour que la programmation puisse être reproductible des fois.
Des fois la résolution de bug tient à des déplacements physique des cartes dans le boitier (car l'irq machin est partagée avec tel slot), parce que les composants sont non standards (voir les bugs triton et autres joyeuseté). En fait dans le monde d'intel la programmation tient du chamanisme.
Sans oublier les normes implémentées de façon exotique par les constructeurs de HW (problèmes aved les DMA au début de l'EIDE).
Je ne suis pas sur qu'on puisse apprendre l'informatique dans le monde du chapelier fou.
A le 68000, ça s'était du processeur !!
Je retourne au joie de la nostalgie, je vais lancer xmame pour émuler ces gloires d'antant.
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par togno . Évalué à 10.
On a eu de la chance je pense : on a appris en douceur: basic quand on était petit, puis un petit peu de windows pour se familiariser avec des concepts comme l'interface graphique. Et les OS alternatifs pour rentrer dans le vif du sujet. Les enfants d'aujourd'hui sont plongés dans la complexité de l'ordinateur familial de la maison, et toute leur intelligence est mobilisée pour apprendre à utiliser windows. Ce qui n'est pas simple contrairement au mythe propagé par l'éditeur.
J'ai aussi une petite soeur mais sans moi pour lui expliquer doucement (je n'ai pas souvent l'occasion de la voir), j'ai bien peur qu'elle ne comprenne jamais les bases de l'informatique.
Conclusion: vive les amstrads, les mo5 et les amigas !
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par »-(¯`v´¯)-» . Évalué à -3.
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par Yann Droneaud (site web personnel) . Évalué à 3.
Non, donc les programmeurs ont de moins en moins conscience du matériel, de l'architecture et des contraintes.
Ce sont des choses qui ne s'apprendront plus que dans des ecoles ou il y aura des professeurs pour
decortiqué les systemes complique et simplifié l'acces aux architectures actuelles.
(vive le Z80)
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par VACHOR (site web personnel) . Évalué à 0.
Mais t'as raison, faut faire un patch pour que l'OS aille plus lentement. En cas de plantage, c'est bien connu, c'est la vitesse qui tue.
Vive le Linux lent.
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par Aza . Évalué à 10.
Ce qui est rigolo c'est que windows 2000 sait gérer la complétion : c'est une clé de registre à modifier. La question a 1000 euros c'est pourquoi est-ce que ce n'est pas activé par défaut ? quel interet de ne pas activé la complétion par défaut ? la j'avoue que je ne vois pas...
[^] # Re: Rien à voir, comme d'hab, avec la news
Posté par koopa . Évalué à 10.
[^] # Re: Boost
Posté par Thomas Cataldo (site web personnel) . Évalué à 10.
[^] # Re: Boost
Posté par Gaël Le Mignot . Évalué à 5.
Euh... ce n'est pas trop le signification de O(1) ça... je ne sais pas si tu t'es mal exprimé ou quoi, mais O(1) signifie juste "temps constant par rapport à la taille des données" (ici le nombre de processus en attente du CPU). Maintenant, oui, le scheduler O(1) d'Ingo apporte beaucoup pour le SMP, mais pas parce uniquement qu'il est en O(1)... ;)
-1 pour tetracapillectomie
[^] # Re: Boost
Posté par gndl (site web personnel) . Évalué à -5.
mais que veut dire ce terme informatique très savant?
[^] # Re: Boost
Posté par Gaël Le Mignot . Évalué à 2.
-1
[^] # Re: patch scheduler O(1)
Posté par Anne Onimousse . Évalué à 1.
A priori la complexité d'un algorithme a une influence pour n grand (mathématiquement pour le calcul de complexité n est supposé "proche" de l'infini), je comprends que pour un serveur Web avec 8 processeur et un serveur Apache configuré avec un pool de 10000 thread (qui sous Linux sont gérés comme des processus), ce patch puisse jouer sur les performances mais est-ce vraiment le cas pour une utilisation de station de travail classique ?
Tout ça ne réléverait-il pas plutôt de l'effet placébo.
# Intéressant mais...
Posté par Gads . Évalué à 10.
Je constate effectivement que Mozilla va plus vite :) (peut-être même encore plus avec le low-latency patch)
Mais quelqu'un aurait il des infos sur l'efficacité globale du noyau patché ? (Dans quelle mesure les autres procs sont ralentis?)
Pour exemple, dès que je lance 2 processus qui font des appels '"monstrueux"' au disque (Mozilla + OpenOffice) le disque rame terriblement et le temps de lancement des deux applis est largement supérieur à celui où les deux sont lancés l'un après l'autre...
[^] # Re: Intéressant mais...
Posté par Serge Rossi (site web personnel) . Évalué à 10.
D'aprés LMbench, y'a pas de quoi se relever la nuit. (j'avais commencé à copier/coller les résultats dans mon message mais le fait de ne pas pouvoir mettre de <PRE></PRE> dans son message sur LinuxFr rend la chose illisible).
Pour résumer, les bandes passantes sont en général en baisse et les temps de latence sur les communications locales pas forcément améliorés.
J'ai aussi fait tourner ce bon vieux Byte Benchmark. Je n'ai pas gardé les résultats mais c'était 5 ou 10 % moins bon avec le noyau patché.
Il est vrai que le but de ces patchs, c'est de réduire la latence au maximum pour rendre Linux idéal parfaitement adapté au traitement du son mais ça n'est sans doute plus si adapté à une utilisation en poste de travail perso.
[^] # Re: Intéressant mais...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 10.
Essayes désormais, je les ai rajouté ;)
[^] # Re: Intéressant mais...
Posté par poil oq . Évalué à -10.
WindowMaker Roulaize !!
y'a pas un petit problème de lignes ?
[^] # Re: Intéressant mais...
Posté par feth . Évalué à -4.
le 0.7 est sorti je crois
[^] # Re: Intéressant mais...
Posté par Serge Rossi (site web personnel) . Évalué à 10.
Merci Fabien :-) (y'a juste 2 sauts de ligne en trop pour chaque ligne mais bon, c'est lisible)
Le noyau avec les patchs preempt et low latency, c'est le 2.4.18-
# Attention quand même...
Posté par Serge Rossi (site web personnel) . Évalué à 10.
J'ai testé cette combinaison de preempt + low-latency sur mon 2.4.18 et si tout semblait fonctionner très bien au premier abord (ni plus ni moins vite au feeling mais bon, j'ai une machine rapide), je suis vite revenu en arrière lors de ma première connexion à Internet (j'utilise une carte Numeris en 64 ou 128 KBps) car je me suis apperçu que ma connexion devenait horriblement lente avec des temps de latence monstrueux (et là, je parle de dizaines de secondes et plus de millisecondes).
Tout est revenu dans l'ordre avec le retour au 2.4.18 "nature".
[^] # Re: Attention quand même...
Posté par imr . Évalué à 3.
Gagner quelques microsecondes ici pour perdre des heures en maintenance serait une idée stupide.
et pourquoi pas intégrer l'interface graphique au noyau tant qu'on y est en idée stupide qui fait "gagner du temps".
# On m'aurait encore mentit ?
Posté par gndl (site web personnel) . Évalué à -10.
[^] # Non, c'est juste un amalgame de ta part
Posté par JSL . Évalué à 10.
Là, comme tu l'auras déjà compris, on parle au niveau systéme : le kernel lui-même se met à être «préemptif» (mais là, je me ne mouille pas pour donner une défintion précise de ce qu'est un kernel préemptif ;)
[^] # Re: Non, c'est juste un amalgame de ta part
Posté par falbala . Évalué à -10.
Un kernel préemptif est un µkernel.
--
Comme hurd
[^] # Re: Non, c'est juste un amalgame de ta part
Posté par pasBill pasGates . Évalué à 9.
un kernel preemptif c'est un kernel qui peut interrompre des threads/process alors qu'ils se trouvent dans le code kernel, ca n'a rien a voir avec la facon dont le kernel est architecture(enfin si, mais c'est independant du cote 'micro-kernel' d'un kernel).
Un micro-kernel peut tout a fait etre non-preemptif, et un kernel preemptif peut tout a fait ne pas etre un micro-kernel(un exemple de cela etant le kernel linux avec les patchs).
[^] # Re: Non, c'est juste un amalgame de ta part
Posté par falbala . Évalué à -4.
enfin si, mais c'est independant du cote 'micro-kernel' d'un kernel
c'est oui ou c'est non ?
c'est du kernel ou pas, ou ça l'est sans l'être ?
[^] # Re: Non, c'est juste un amalgame de ta part
Posté par pasBill pasGates . Évalué à 10.
Le fait qu'un kernel ait une architecture micro-kernel n'en fait pas un kernel preemptif, ce n'est pas ce cote architectural la qui est necessaire pour cela, mais un autre(gestion des locks et structures du kernel).
Le fait qu'un kernel soit preemptif donne une indication sur son architecture(il est preemptif), ca ne signifie pas que son architecture est un micro-kernel.
Ce n'est pas une partie du code qui a un droit de premption sur une autre, c'est le scheduler qui a la possibilite de stopper un thread/process(selon ce que traite le scheduler) quand il en ressent le besoin, ce qui est le cas dans tout kernel d'un OS multitache preemptif, que le kernel lui-meme soit premptif ou pas.
[^] # Re: Non, c'est juste un amalgame de ta part
Posté par gndl (site web personnel) . Évalué à 0.
[^] # Re: Non, c'est juste un amalgame de ta part
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: On m'aurait encore mentit ?
Posté par RB . Évalué à 2.
Linux a toujours été préemptif (peut-être pas au temps des version 0.1, mais après certainement). Donc arrête de dire des conneries. Le seul trucs c'est qu'en noyau "normal" une tâche avec priorité maximum pouvait squatter le CPU pendant 400ms dans les cas extrèmes, ce qui rend le système peut réactif pour un utilisateur qui essaie de bosser avec une interface graphique tout en jouant des MP3. Le patch préemptif et l'autre cherchent à diminuer le temps de chaques tâches, tout en n'y perdant pas trop de puissance globale. Le patch préemptif ne porte pas un très bon nom puisqu'il induit certaines confusions.
[^] # Re: On m'aurait encore mentit ?
Posté par pasBill pasGates . Évalué à 10.
Le patch preemptif cherche pas a diminuer le temps de chaque tache(ca s'appelle diminuer le quantum ca), il s'occupe de permettre au kernel de scheduler une tache de priorite plus importante meme si le process courant est dans le kernel, et de permettre de scheduler une autre tache quand un process est dans le kernel et attend qqe chose.
[^] # Re: On m'aurait encore mentit ?
Posté par maxoub . Évalué à 10.
Linux est préemptif au niveau du user space. Donc n'importe quel tache qui s'execute en mode user peut être interrompu par le noyau, qui passera la main à une autre tache. Il l'a toujours été, depuis la version 0.01.
Maintenant, si une tache fait un appel système quelconque, et passe en mode noyau, elle ne pourra être interrompu durant la durée de son passage en mode noyau. Cela n'est habituellement pas génant, sauf pour les systèmes "temps réel dur".
Les patchs préemptif visent à permettre l'interruption d'une tache passée en mode noyau, par une tache plus prioritaire. Dans certains cas, c'est possible, mais pas toujours, comme le dit l'article http://www.linuxdevices.com/articles/AT4185744181.html(...)
[^] # Re: On m'aurait encore mentit ?
Posté par gndl (site web personnel) . Évalué à -2.
[^] # Re: On m'aurait encore mentit ?
Posté par gndl (site web personnel) . Évalué à -3.
# Vivez dangereusement !
Posté par Schwarzy . Évalué à -3.
http://perso.wanadoo.fr/l.boulard/deb/kernel/(...)
vous trouverez en vrac:
la même chose pour 686 bientôt (ce week-end j'espère).
Bien sûr, utilisez ces packages à vos risques et périls (perso mon serveur utilise que les kernels officiel debian).
[^] # Re: Vivez dangereusement !
Posté par TSelek . Évalué à 2.
Ca sert à quoi un module plex pour bochs ? La dernière fois que j'ai fait tourner bochs, c'était juste une appli tout userland, alors le module je saisi pas bien.
[^] # Re: Vivez dangereusement !
Posté par Schwarzy . Évalué à -1.
# un commentaire intéressant
Posté par anonyme512 . Évalué à 7.
http://slashdot.org/comments.pl?sid=29858&cid=3206789(...)
il y a donc un troisième patch, le lock-break patch, qui semble prometteur en combinaison avec le preempt.
[^] # Re: un commentaire intéressant
Posté par reno . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.