On Sat, 06 Aug 2005 22:19:11 +0200, Eric Levenez wrote:
Le 6/08/05 21:39, dans , « Grrrr » a écrit :
Il faut que je retrouve cette interview ou l'explication était donnée par un des pricipaux contributeurs du kernel de NextStep: il leur fallait absolument avoir un kernel très vite et le seul moyen d'y parvenir était de ne pas faire de serveurs, au sens de l'architecture Mach.
Alors regarde aussi tous les benchs de Mach sur la comparaison des 2 implémentations : vrai micro-noyau et pseudo micro-noyau. Mais si c'est juste pour polémiquer sur les micro-boyau vs les macro-noyau, tu peux toujours contacter Linus ou RMS suivant ton camp.
Tu dérailles, là. Oui, je sais bien que les micros-noyaux sont moins efficace à cause des multiples switch de contexte, au moins sur les machines lentes qui se servent de la pile pour les exceptions (donc les 68k, ce n'est pas le cas sur PPC...). Et je sais également que Mach n'est pas le modèle de micro-noyau le plus efficace, loin de là.
Bon, j'aurais mieux fait de me taire, puisque je ne retrouve pas ce papier qui parlait de la façon dont l'assemblage du noyau de NextStep a été fait.
Quand à dire que c'est pour une question de performance, quand on voit le code de bas niveau de Mac OS X, c'est une mauvaise excuse: il aurait été très simple de gagner les 15~20 % de surcout d'un noyau Mach en optimisant ces parties là. Elles sont d'une inneficacité rare...
"très simple de gagner 15 à 20 %", mais bien sûr. Facile de lancer des chiffres. Moi je dis 30 %, qui dit mieux ? On se demande pourquoi Apple court après un CPU à 3 GHz alors qu'il suffisait de demander à Grrrr d'y consacrer une demi-journée :-D
Regarde, juste les kilomêtres de code qu'il faut dérouler pour rentrer dans un syscall depuis le handler d'exception. C'est ahurissant. C'est au point qu'Apple a rajouté dans ce code 2 systèmes de "fast syscall" qui permettent d'éviter d'executer une partie de ce code. Regarde bien le code en question, tu verras que les fast syscall ne sont pas des routines rapides (du genre un getclock ou un getpid qui ne demanderai pas de sortir du code assembleur) mais simplement des routines appelées plus souvent. Plutôt que d'écrire correctement le cas général, il ont rajouté des hacks pour que quelques cas particuliers marchent mieux.
Il suffit de savoir lire du code pour PowerPC pour le constater et, par exemple, de comparer le code équivalent dans Linux ou un BSD "classique". Dans ces bouts de code, chaque cycle CPU est critique donc il suffit même de compter les instructions executées pour voir qu'il y a un vrai problème dans Mac OS X. Maintenant, comme ce code est propre au PPC, il est possible que ce soit juste le portage d'Apple qui soit délirant, pas le code original. Je ne peux pas en juger: je n'ai jamais vu le code original.
J'ai écrit une émulation des syscalls de BSD, dont Mac OS X, sous Linux, pour m'amuser. Le fait d'appeler un syscall de Mac OS X sous Linux me coute 2 instructions de plus que en utilisant l'API Linux pour rentrer dans le syscall (et ne coute évidement rien dans le cas des syscalls natifs Linux). Donc, il me semble que je suis capable de comparer deux codes de bas niveau qui font la même chose, l'un en émulation en quelques dizaines d'instructions, l'autre en natif en plusieurs centaines d'instructions. Et je ne parle que du code assembleur...
On Sat, 06 Aug 2005 22:19:11 +0200, Eric Levenez wrote:
Le 6/08/05 21:39, dans <pan.2005.08.06.19.39.03.661822@Grrr.org.invalid>,
« Grrrr » <Grrr@Grrr.org.invalid> a écrit :
Il faut que je retrouve cette interview ou l'explication était donnée
par un des pricipaux contributeurs du kernel de NextStep: il leur fallait
absolument avoir un kernel très vite et le seul moyen d'y parvenir était
de ne pas faire de serveurs, au sens de l'architecture Mach.
Alors regarde aussi tous les benchs de Mach sur la comparaison des 2
implémentations : vrai micro-noyau et pseudo micro-noyau. Mais si c'est
juste pour polémiquer sur les micro-boyau vs les macro-noyau, tu peux
toujours contacter Linus ou RMS suivant ton camp.
Tu dérailles, là.
Oui, je sais bien que les micros-noyaux sont moins efficace à cause des
multiples switch de contexte, au moins sur les machines lentes qui se
servent de la pile pour les exceptions (donc les 68k, ce n'est pas le cas
sur PPC...). Et je sais également que Mach n'est pas le modèle de
micro-noyau le plus efficace, loin de là.
Bon, j'aurais mieux fait de me taire, puisque je ne retrouve pas ce papier
qui parlait de la façon dont l'assemblage du noyau de NextStep a été
fait.
Quand à dire que c'est pour une question de performance, quand on voit le
code de bas niveau de Mac OS X, c'est une mauvaise excuse: il aurait été
très simple de gagner les 15~20 % de surcout d'un noyau Mach en
optimisant ces parties là. Elles sont d'une inneficacité rare...
"très simple de gagner 15 à 20 %", mais bien sûr. Facile de lancer des
chiffres. Moi je dis 30 %, qui dit mieux ? On se demande pourquoi Apple
court après un CPU à 3 GHz alors qu'il suffisait de demander à Grrrr d'y
consacrer une demi-journée :-D
Regarde, juste les kilomêtres de code qu'il faut dérouler pour rentrer
dans un syscall depuis le handler d'exception.
C'est ahurissant. C'est au point qu'Apple a rajouté dans ce code 2
systèmes de "fast syscall" qui permettent d'éviter d'executer une partie
de ce code.
Regarde bien le code en question, tu verras que les fast syscall ne sont
pas des routines rapides (du genre un getclock ou un getpid qui ne
demanderai pas de sortir du code assembleur) mais simplement des routines
appelées plus souvent. Plutôt que d'écrire correctement le cas
général, il ont rajouté des hacks pour que quelques cas particuliers
marchent mieux.
Il suffit de savoir lire du code pour PowerPC pour le constater et, par
exemple, de comparer le code équivalent dans Linux ou un BSD "classique".
Dans ces bouts de code, chaque cycle CPU est critique donc il suffit même
de compter les instructions executées pour voir qu'il y a un vrai
problème dans Mac OS X. Maintenant, comme ce code est propre au PPC, il
est possible que ce soit juste le portage d'Apple qui soit délirant, pas
le code original. Je ne peux pas en juger: je n'ai jamais vu le code
original.
J'ai écrit une émulation des syscalls de BSD, dont Mac OS X, sous Linux,
pour m'amuser. Le fait d'appeler un syscall de Mac OS X sous Linux me
coute 2 instructions de plus que en utilisant l'API Linux pour rentrer
dans le syscall (et ne coute évidement rien dans le cas des syscalls
natifs Linux). Donc, il me semble que je suis capable de comparer deux
codes de bas niveau qui font la même chose, l'un en émulation en
quelques dizaines d'instructions, l'autre en natif en plusieurs centaines
d'instructions.
Et je ne parle que du code assembleur...
On Sat, 06 Aug 2005 22:19:11 +0200, Eric Levenez wrote:
Le 6/08/05 21:39, dans , « Grrrr » a écrit :
Il faut que je retrouve cette interview ou l'explication était donnée par un des pricipaux contributeurs du kernel de NextStep: il leur fallait absolument avoir un kernel très vite et le seul moyen d'y parvenir était de ne pas faire de serveurs, au sens de l'architecture Mach.
Alors regarde aussi tous les benchs de Mach sur la comparaison des 2 implémentations : vrai micro-noyau et pseudo micro-noyau. Mais si c'est juste pour polémiquer sur les micro-boyau vs les macro-noyau, tu peux toujours contacter Linus ou RMS suivant ton camp.
Tu dérailles, là. Oui, je sais bien que les micros-noyaux sont moins efficace à cause des multiples switch de contexte, au moins sur les machines lentes qui se servent de la pile pour les exceptions (donc les 68k, ce n'est pas le cas sur PPC...). Et je sais également que Mach n'est pas le modèle de micro-noyau le plus efficace, loin de là.
Bon, j'aurais mieux fait de me taire, puisque je ne retrouve pas ce papier qui parlait de la façon dont l'assemblage du noyau de NextStep a été fait.
Quand à dire que c'est pour une question de performance, quand on voit le code de bas niveau de Mac OS X, c'est une mauvaise excuse: il aurait été très simple de gagner les 15~20 % de surcout d'un noyau Mach en optimisant ces parties là. Elles sont d'une inneficacité rare...
"très simple de gagner 15 à 20 %", mais bien sûr. Facile de lancer des chiffres. Moi je dis 30 %, qui dit mieux ? On se demande pourquoi Apple court après un CPU à 3 GHz alors qu'il suffisait de demander à Grrrr d'y consacrer une demi-journée :-D
Regarde, juste les kilomêtres de code qu'il faut dérouler pour rentrer dans un syscall depuis le handler d'exception. C'est ahurissant. C'est au point qu'Apple a rajouté dans ce code 2 systèmes de "fast syscall" qui permettent d'éviter d'executer une partie de ce code. Regarde bien le code en question, tu verras que les fast syscall ne sont pas des routines rapides (du genre un getclock ou un getpid qui ne demanderai pas de sortir du code assembleur) mais simplement des routines appelées plus souvent. Plutôt que d'écrire correctement le cas général, il ont rajouté des hacks pour que quelques cas particuliers marchent mieux.
Il suffit de savoir lire du code pour PowerPC pour le constater et, par exemple, de comparer le code équivalent dans Linux ou un BSD "classique". Dans ces bouts de code, chaque cycle CPU est critique donc il suffit même de compter les instructions executées pour voir qu'il y a un vrai problème dans Mac OS X. Maintenant, comme ce code est propre au PPC, il est possible que ce soit juste le portage d'Apple qui soit délirant, pas le code original. Je ne peux pas en juger: je n'ai jamais vu le code original.
J'ai écrit une émulation des syscalls de BSD, dont Mac OS X, sous Linux, pour m'amuser. Le fait d'appeler un syscall de Mac OS X sous Linux me coute 2 instructions de plus que en utilisant l'API Linux pour rentrer dans le syscall (et ne coute évidement rien dans le cas des syscalls natifs Linux). Donc, il me semble que je suis capable de comparer deux codes de bas niveau qui font la même chose, l'un en émulation en quelques dizaines d'instructions, l'autre en natif en plusieurs centaines d'instructions. Et je ne parle que du code assembleur...
une.bevueVOTEZ
Dominique Lang wrote:
Ah bon? Je n'en ai pas du tout l'impression sur mon antiquité G4 667 MHz...
depuis Tiger j'ai souvent la wheel qui apparaît...
bon, vous llaez me dire, ce sont les applications...
hier je tente de charger un fichier 8 mo dans mozilla (une page unique de docum pour MySQL) j'ai du abandonner :
- bruit du ventilateur (iMac G5) - extrême lenteur...
le "même" document en pdf, pas de pb... -- une bévue
Dominique Lang <dominiquelang@FromMyTrailer.invalid> wrote:
Ah bon? Je n'en ai pas du tout l'impression sur mon antiquité G4 667
MHz...
depuis Tiger j'ai souvent la wheel qui apparaît...
bon, vous llaez me dire, ce sont les applications...
hier je tente de charger un fichier 8 mo dans mozilla (une page unique
de docum pour MySQL) j'ai du abandonner :
- bruit du ventilateur (iMac G5)
- extrême lenteur...
le "même" document en pdf, pas de pb...
--
une bévue
Ah bon? Je n'en ai pas du tout l'impression sur mon antiquité G4 667 MHz...
depuis Tiger j'ai souvent la wheel qui apparaît...
bon, vous llaez me dire, ce sont les applications...
hier je tente de charger un fichier 8 mo dans mozilla (une page unique de docum pour MySQL) j'ai du abandonner :
- bruit du ventilateur (iMac G5) - extrême lenteur...
le "même" document en pdf, pas de pb... -- une bévue
c.moi
Sergio wrote:
Ben vi ... c'est aussi rapide que du ethernet gigabit d'après mes essais ; en fait ce sont les accès disques (paramètres du disque et vitesse du bus) qui saturent les premiers.
J'ai un switch qui me limite en 100 :=((
-- Je cherche comme cherche celui qui veut trouver, et je trouve comme trouve celui qui a cherché. :o)
Sergio <sergiot.bidon@free.invalid.fr> wrote:
Ben vi ... c'est aussi rapide que du ethernet gigabit d'après mes essais
; en fait ce sont les accès disques (paramètres du disque et vitesse du
bus) qui saturent les premiers.
J'ai un switch qui me limite en 100 :=((
--
Je cherche comme cherche celui qui veut trouver,
et je trouve comme trouve celui qui a cherché. :o)
Ben vi ... c'est aussi rapide que du ethernet gigabit d'après mes essais ; en fait ce sont les accès disques (paramètres du disque et vitesse du bus) qui saturent les premiers.
J'ai un switch qui me limite en 100 :=((
-- Je cherche comme cherche celui qui veut trouver, et je trouve comme trouve celui qui a cherché. :o)
Eric Levenez
Le 7/08/05 8:49, dans , « Grrrr » a écrit :
Donc, il me semble que je suis capable de comparer deux codes de bas niveau qui font la même chose, l'un en émulation en quelques dizaines d'instructions, l'autre en natif en plusieurs centaines d'instructions.
Comme beaucoup, tu confonds optimisation d'une fonction avec l'optimisation d'un noyau pour gagner 15 à 20 % (sic). On voit souvent des benchs débiles avec des boucles sur des getpid ou autres conneries et là ils en déduisent les performances du système au final ! Mais si tu penses que tu pourrais gagner les 15 à 20 % en performance sur le noyau que tu as annoncés, contacte Apple, ils t'accueilleront les bras ouvert !
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 7/08/05 8:49, dans <pan.2005.08.07.06.49.39.496068@Grrr.org.invalid>,
« Grrrr » <Grrr@Grrr.org.invalid> a écrit :
Donc, il me semble que je suis capable de comparer deux
codes de bas niveau qui font la même chose, l'un en émulation en
quelques dizaines d'instructions, l'autre en natif en plusieurs centaines
d'instructions.
Comme beaucoup, tu confonds optimisation d'une fonction avec l'optimisation
d'un noyau pour gagner 15 à 20 % (sic). On voit souvent des benchs débiles
avec des boucles sur des getpid ou autres conneries et là ils en déduisent
les performances du système au final ! Mais si tu penses que tu pourrais
gagner les 15 à 20 % en performance sur le noyau que tu as annoncés,
contacte Apple, ils t'accueilleront les bras ouvert !
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Donc, il me semble que je suis capable de comparer deux codes de bas niveau qui font la même chose, l'un en émulation en quelques dizaines d'instructions, l'autre en natif en plusieurs centaines d'instructions.
Comme beaucoup, tu confonds optimisation d'une fonction avec l'optimisation d'un noyau pour gagner 15 à 20 % (sic). On voit souvent des benchs débiles avec des boucles sur des getpid ou autres conneries et là ils en déduisent les performances du système au final ! Mais si tu penses que tu pourrais gagner les 15 à 20 % en performance sur le noyau que tu as annoncés, contacte Apple, ils t'accueilleront les bras ouvert !
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Grrrr
On Sun, 07 Aug 2005 12:26:03 +0200, Eric Levenez wrote:
Le 7/08/05 8:49, dans , « Grrrr » a écrit :
Donc, il me semble que je suis capable de comparer deux codes de bas niveau qui font la même chose, l'un en émulation en quelques dizaines d'instructions, l'autre en natif en plusieurs centaines d'instructions.
Comme beaucoup, tu confonds optimisation d'une fonction avec l'optimisation d'un noyau pour gagner 15 à 20 % (sic). On voit souvent des benchs débiles avec des boucles sur des getpid ou autres conneries et là ils en déduisent les performances du système au final ! Mais si tu penses que tu pourrais gagner les 15 à 20 % en performance sur le noyau que tu as annoncés, contacte Apple, ils t'accueilleront les bras ouvert !
Tu n'as pas l'air d'avoir compris ce que j'ai expliqué: je ne parle pas de l'optimisation d'une fonction particulière mais du chemin parcouru lors d'une exception, c'est à dire l'endroit le plus critique en temps dans un noyau. Si cette partie là est inefficace, il est assez vain de chercher des optimisation plus haut. Quand les couches basses et génériques marchent mal, on n'arrive jamais à rattraper la donne en tripatouillant le reste du code. C'est toujours par là qu'il faut commencer. La seule raison valable pour laquelle Apple ne touche pas à ce code, AMHA, c'est qu'ils ont peur de tout casser. En effet, ce code assembleur est d'une grande complexité, dans leur implémentation, et d'expérience je sais bien que c'est à peu près ce qu'il y a de plus dur à debugger. Et je n'ai jamais prétendu que c'était suffisant pour avoir un système efficace, je dis que c'est un pré-requis.
Je ne peut pas chiffrer précisément le gain obtenu en divisant la longueur de ce code par 2, par exemple, mais il est certain qu'il est non négligeable puisque c'est le code par lequel on passe le plus souvent dans tout le code éxécuté par la machine et qu'en plus une bonne partie de ce code est exécuté dans des conditions critiques (interruptions désactivées, ...). On gagne d'autant plus dans un micro-kernel puisque le nombre de switches de contexte est beaucoup plus grand que dans un kernel monolitique: on y passe donc d'autant plus souvent. Mon essai d'émulation m'a montré que de diminuer par 2 la longueur de cette partie me permettait de gagner 20 à 30 % en vitesse pour l'execution de programmes BSD. A part pour les programmes de calcul pur, qui ne font pas de syscalls, le gain n'est jamais négligeable.
On Sun, 07 Aug 2005 12:26:03 +0200, Eric Levenez wrote:
Le 7/08/05 8:49, dans <pan.2005.08.07.06.49.39.496068@Grrr.org.invalid>,
« Grrrr » <Grrr@Grrr.org.invalid> a écrit :
Donc, il me semble que je suis capable de comparer deux
codes de bas niveau qui font la même chose, l'un en émulation en
quelques dizaines d'instructions, l'autre en natif en plusieurs centaines
d'instructions.
Comme beaucoup, tu confonds optimisation d'une fonction avec l'optimisation
d'un noyau pour gagner 15 à 20 % (sic). On voit souvent des benchs débiles
avec des boucles sur des getpid ou autres conneries et là ils en déduisent
les performances du système au final ! Mais si tu penses que tu pourrais
gagner les 15 à 20 % en performance sur le noyau que tu as annoncés,
contacte Apple, ils t'accueilleront les bras ouvert !
Tu n'as pas l'air d'avoir compris ce que j'ai expliqué:
je ne parle pas de l'optimisation d'une fonction particulière mais du
chemin parcouru lors d'une exception, c'est à dire l'endroit le plus
critique en temps dans un noyau. Si cette partie là est inefficace, il
est assez vain de chercher des optimisation plus haut.
Quand les couches basses et génériques marchent mal, on n'arrive jamais
à rattraper la donne en tripatouillant le reste du code.
C'est toujours par là qu'il faut commencer. La seule raison valable pour
laquelle Apple ne touche pas à ce code, AMHA, c'est qu'ils ont peur de
tout casser. En effet, ce code assembleur est d'une grande complexité,
dans leur implémentation, et d'expérience je sais bien que c'est à peu
près ce qu'il y a de plus dur à debugger.
Et je n'ai jamais prétendu que c'était suffisant pour avoir un système
efficace, je dis que c'est un pré-requis.
Je ne peut pas chiffrer précisément le gain obtenu en divisant la
longueur de ce code par 2, par exemple, mais il est certain qu'il est non
négligeable puisque c'est le code par lequel on passe le plus souvent
dans tout le code éxécuté par la machine et qu'en plus une bonne partie
de ce code est exécuté dans des conditions critiques (interruptions
désactivées, ...). On gagne d'autant plus dans un micro-kernel puisque
le nombre de switches de contexte est beaucoup plus grand que dans un
kernel monolitique: on y passe donc d'autant plus souvent.
Mon essai d'émulation m'a montré que de diminuer par 2 la longueur de
cette partie me permettait de gagner 20 à 30 % en vitesse pour
l'execution de programmes BSD. A part pour les programmes de calcul pur,
qui ne font pas de syscalls, le gain n'est jamais négligeable.
On Sun, 07 Aug 2005 12:26:03 +0200, Eric Levenez wrote:
Le 7/08/05 8:49, dans , « Grrrr » a écrit :
Donc, il me semble que je suis capable de comparer deux codes de bas niveau qui font la même chose, l'un en émulation en quelques dizaines d'instructions, l'autre en natif en plusieurs centaines d'instructions.
Comme beaucoup, tu confonds optimisation d'une fonction avec l'optimisation d'un noyau pour gagner 15 à 20 % (sic). On voit souvent des benchs débiles avec des boucles sur des getpid ou autres conneries et là ils en déduisent les performances du système au final ! Mais si tu penses que tu pourrais gagner les 15 à 20 % en performance sur le noyau que tu as annoncés, contacte Apple, ils t'accueilleront les bras ouvert !
Tu n'as pas l'air d'avoir compris ce que j'ai expliqué: je ne parle pas de l'optimisation d'une fonction particulière mais du chemin parcouru lors d'une exception, c'est à dire l'endroit le plus critique en temps dans un noyau. Si cette partie là est inefficace, il est assez vain de chercher des optimisation plus haut. Quand les couches basses et génériques marchent mal, on n'arrive jamais à rattraper la donne en tripatouillant le reste du code. C'est toujours par là qu'il faut commencer. La seule raison valable pour laquelle Apple ne touche pas à ce code, AMHA, c'est qu'ils ont peur de tout casser. En effet, ce code assembleur est d'une grande complexité, dans leur implémentation, et d'expérience je sais bien que c'est à peu près ce qu'il y a de plus dur à debugger. Et je n'ai jamais prétendu que c'était suffisant pour avoir un système efficace, je dis que c'est un pré-requis.
Je ne peut pas chiffrer précisément le gain obtenu en divisant la longueur de ce code par 2, par exemple, mais il est certain qu'il est non négligeable puisque c'est le code par lequel on passe le plus souvent dans tout le code éxécuté par la machine et qu'en plus une bonne partie de ce code est exécuté dans des conditions critiques (interruptions désactivées, ...). On gagne d'autant plus dans un micro-kernel puisque le nombre de switches de contexte est beaucoup plus grand que dans un kernel monolitique: on y passe donc d'autant plus souvent. Mon essai d'émulation m'a montré que de diminuer par 2 la longueur de cette partie me permettait de gagner 20 à 30 % en vitesse pour l'execution de programmes BSD. A part pour les programmes de calcul pur, qui ne font pas de syscalls, le gain n'est jamais négligeable.
