Il y a les 2: les APIs qui forcent à faire plusieurs thread et à partager peu de mémoire entre eux (via l'utilisation de BMessage pour envoyer des messages d'un thread à l'autre), et le scheduler qui savait en 2001 gérer plusieurs CPUs.
La conception est assez particulière et liée aux contraintes matérielles de la BeBox au départ. Sur la BeBox, il fallait invalider le cache de chaque CPU à la main pour assurer la synchronization (car le CPU choisi n'était pas prévu pour fonctionner en multi processeur). Du coup, grosse perte de performance dès que de la mémoire était partagée entre deux CPUs, et donc une API essayant de limiter les cas où ça se produit.
Est-ce que c'est possible de faire la même chose dans Linux? Oui, certainement. BlueEyedOS l'a montré et il se défend bien d'un point de vue des performances. Mais les priorités de Linux ne sont pas les mêmes. Aujourd'hui, Linux fait des choix plutôt orientés vers les gros serveurs qui vont traiter des milliers de requêtes réseau en parallèle. Ils font des compromis différents, et il n'est pas évident que des patches pour changer ça soient bienvenus.
Surtout, ce serait facile si ça se limitait au scheduler. Dans Haiku, le principal endroit ou ça se joue, c'est en fait sur la priorisation des accès au disques. Si tu as un truc qui fait plein de gros accès disques (mettons, tu es en train de copier plein de photos et vidéos), il faut faire en sorte que ces accès n'occupent pas le disque trop en continu et soient mis en priorité plus basse, afin que des demandes plus ponctuelles (lancement d'une application qui doit être chargée depuis le même disque) puissent être traitées rapidement. C'est un sujet sur lequel on a encore du travail à faire. La solution actuelle essaie de minimiser les mouvements de la tête de lecture du disque dur, mais le matériel a bien changé depuis: bien sûr avec les SSD qui n'ont pas cette contrainte, mais même pour les disques classiques, qui ont une mémoire cache relativement importante en interne et donc il faut gérer les choses différement pour en tenir compte.
Et dans les utilisations modernes, il y aurait probablement beaucoup à faire pour les aspects réseau, en gérant de la QoS entre différentes applications. Pour pas que le téléchargement d'un gros fichier ralentisse la navigation web ou n'augmente la latence d'une connexion ssh interactive, par exemple.
[^] # Re: Amusant que Haiku soit le seul survivant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 5.
Il y a les 2: les APIs qui forcent à faire plusieurs thread et à partager peu de mémoire entre eux (via l'utilisation de BMessage pour envoyer des messages d'un thread à l'autre), et le scheduler qui savait en 2001 gérer plusieurs CPUs.
La conception est assez particulière et liée aux contraintes matérielles de la BeBox au départ. Sur la BeBox, il fallait invalider le cache de chaque CPU à la main pour assurer la synchronization (car le CPU choisi n'était pas prévu pour fonctionner en multi processeur). Du coup, grosse perte de performance dès que de la mémoire était partagée entre deux CPUs, et donc une API essayant de limiter les cas où ça se produit.
Est-ce que c'est possible de faire la même chose dans Linux? Oui, certainement. BlueEyedOS l'a montré et il se défend bien d'un point de vue des performances. Mais les priorités de Linux ne sont pas les mêmes. Aujourd'hui, Linux fait des choix plutôt orientés vers les gros serveurs qui vont traiter des milliers de requêtes réseau en parallèle. Ils font des compromis différents, et il n'est pas évident que des patches pour changer ça soient bienvenus.
Surtout, ce serait facile si ça se limitait au scheduler. Dans Haiku, le principal endroit ou ça se joue, c'est en fait sur la priorisation des accès au disques. Si tu as un truc qui fait plein de gros accès disques (mettons, tu es en train de copier plein de photos et vidéos), il faut faire en sorte que ces accès n'occupent pas le disque trop en continu et soient mis en priorité plus basse, afin que des demandes plus ponctuelles (lancement d'une application qui doit être chargée depuis le même disque) puissent être traitées rapidement. C'est un sujet sur lequel on a encore du travail à faire. La solution actuelle essaie de minimiser les mouvements de la tête de lecture du disque dur, mais le matériel a bien changé depuis: bien sûr avec les SSD qui n'ont pas cette contrainte, mais même pour les disques classiques, qui ont une mémoire cache relativement importante en interne et donc il faut gérer les choses différement pour en tenir compte.
Et dans les utilisations modernes, il y aurait probablement beaucoup à faire pour les aspects réseau, en gérant de la QoS entre différentes applications. Pour pas que le téléchargement d'un gros fichier ralentisse la navigation web ou n'augmente la latence d'une connexion ssh interactive, par exemple.