Concernant le kernel préemptif, je ne suis pas du tout d'accord, ce sont des choses assez différentes. Je te rappelle que l'amiga (et oui) avait un multi-tâche non préemptif (alors pour le noyau, ah, ah, ah) et que pourtant, il fonctionnait très bien ce multi-tâches. En fait, on peut même montrer que le multi-tâche préemptif coûte du temps d'exécution (le temps passé dans le scheduler, justement) et c'est pourquoi certains systèmes embarqués ou temps réel n'ont même pas de scheduler. De même, les programmeurs de jeu ont longtemps été très très réticents à utiliser des threads pour éviter de perdre quelques fps. J'ai moi même été obligé de me battre avec les développeurs de freecraft pour pouvoir placer mon patch de son dans un thread à part. Mon expérience à ce moment est qu'effectivement, on perdait des fps en passant à la version avec thread, mais qu'au moins on avait un son potable. Avec le scheduling à la main, on perdait parfois des évènements de son.
Bref, tout ça pour dire qu'un kernel preemptif, c'est très bien pour l'interactivité et pour la réactivité en général (un truc à la BeOS par exemple) mais que ça ne veut pas dire que ça scale bien (grand nombre de process) par exemple. Les tests menés avec linux montrent que les patchs low-latency font gagner des perfs sur certains aspects (justement la réactivité) mais perdre sur d'autres.
D'autre part, les différents micro-bench que je connais montrent que linux est meilleur que windows (sur un mono processeur) en terme de scheduling : la création d'un thread ou d'un process est plus rapide, le temps passé dans le scheduler est moins important, etc. pour des charges normales. Par contre, quand on atteint un grand nombre de threads (genre 500), windows devenait meilleur (avant le patch O(1) de Molnar). D'ailleurs, ce problème de thread est connu car il faisait pas mal merder certaines applications Java, car il fallait en Java utiliser des threads pour faire des IO non bloquantes (alors que la bonne façon de faire est l'appel système select sous unix). Depuis la version 1.4, ce problème est réglé grâce à une api à la select en Java. D'autre part, Molnar et consort ont implémenté un modèle de threads mixte à la Solaris/NT qui peut être ajouté à Linux et qui améliore encore les performances du scheduling. Et ne me dit pas que c'est le futur, c'est la RedHat actuelle.
Sinon, il me semble que le système de priorité des threads/process est moins fin (moins de niveau de priorité) sous windows que sous linux, mais ça je ne suis pas sûr.
Concernant le SMP, je ne me prononce pas pour plusieurs raisons. La première, c'est que je n'ai pas une super confiance dans les benchs TPC. Je n'accuse pas MS de les bidouiller, mais je ne suis pas sûr que cela soit très représentatif de ce que la communauté linux cherche à faire avec le linux SMP. D'autre part, tous les articles que j'ai pu lire sur l'optimisation pour le grand nombre de processeurs sont négatifs, au sens où ils disent tous que la stratégie employée actuellement (un gros des locks très fins dans le noyau) a beaucoup de conséquences négatives sur les performances en mono ou dual (je parle entre autres d'articles d'ingénieurs de chez Sun qui connaissent bien le problème). Mon point de vue est que Linux progresse lentement dans le support efficace des grosses machines pour une raison très simple : il est inacceptable que les choix architecturaux effectués dans cette progression fassent baisser les performances en mono processeur.
[^] # Re: Microsoft fait de la formation Linux
Posté par boubou . En réponse à la dépêche Microsoft fait de la formation Linux. Évalué à 2.
Concernant le kernel préemptif, je ne suis pas du tout d'accord, ce sont des choses assez différentes. Je te rappelle que l'amiga (et oui) avait un multi-tâche non préemptif (alors pour le noyau, ah, ah, ah) et que pourtant, il fonctionnait très bien ce multi-tâches. En fait, on peut même montrer que le multi-tâche préemptif coûte du temps d'exécution (le temps passé dans le scheduler, justement) et c'est pourquoi certains systèmes embarqués ou temps réel n'ont même pas de scheduler. De même, les programmeurs de jeu ont longtemps été très très réticents à utiliser des threads pour éviter de perdre quelques fps. J'ai moi même été obligé de me battre avec les développeurs de freecraft pour pouvoir placer mon patch de son dans un thread à part. Mon expérience à ce moment est qu'effectivement, on perdait des fps en passant à la version avec thread, mais qu'au moins on avait un son potable. Avec le scheduling à la main, on perdait parfois des évènements de son.
Bref, tout ça pour dire qu'un kernel preemptif, c'est très bien pour l'interactivité et pour la réactivité en général (un truc à la BeOS par exemple) mais que ça ne veut pas dire que ça scale bien (grand nombre de process) par exemple. Les tests menés avec linux montrent que les patchs low-latency font gagner des perfs sur certains aspects (justement la réactivité) mais perdre sur d'autres.
D'autre part, les différents micro-bench que je connais montrent que linux est meilleur que windows (sur un mono processeur) en terme de scheduling : la création d'un thread ou d'un process est plus rapide, le temps passé dans le scheduler est moins important, etc. pour des charges normales. Par contre, quand on atteint un grand nombre de threads (genre 500), windows devenait meilleur (avant le patch O(1) de Molnar). D'ailleurs, ce problème de thread est connu car il faisait pas mal merder certaines applications Java, car il fallait en Java utiliser des threads pour faire des IO non bloquantes (alors que la bonne façon de faire est l'appel système select sous unix). Depuis la version 1.4, ce problème est réglé grâce à une api à la select en Java. D'autre part, Molnar et consort ont implémenté un modèle de threads mixte à la Solaris/NT qui peut être ajouté à Linux et qui améliore encore les performances du scheduling. Et ne me dit pas que c'est le futur, c'est la RedHat actuelle.
Sinon, il me semble que le système de priorité des threads/process est moins fin (moins de niveau de priorité) sous windows que sous linux, mais ça je ne suis pas sûr.
Concernant le SMP, je ne me prononce pas pour plusieurs raisons. La première, c'est que je n'ai pas une super confiance dans les benchs TPC. Je n'accuse pas MS de les bidouiller, mais je ne suis pas sûr que cela soit très représentatif de ce que la communauté linux cherche à faire avec le linux SMP. D'autre part, tous les articles que j'ai pu lire sur l'optimisation pour le grand nombre de processeurs sont négatifs, au sens où ils disent tous que la stratégie employée actuellement (un gros des locks très fins dans le noyau) a beaucoup de conséquences négatives sur les performances en mono ou dual (je parle entre autres d'articles d'ingénieurs de chez Sun qui connaissent bien le problème). Mon point de vue est que Linux progresse lentement dans le support efficace des grosses machines pour une raison très simple : il est inacceptable que les choix architecturaux effectués dans cette progression fassent baisser les performances en mono processeur.