Oh mais je râle pas, j'ai même pas dit qu'il avait tort ...
Il est peut être super cool son scheduler sur les machines monoproc, j'en sais rien du tout. Le seul truc c'est que c'est un peu à lui de défendre son bébé avec des benchmarks par exemple.
C'est comme ça que ça marche dans la communauté et les publications scientifiques, tu fournis un boulot, tu défend ton approche, tu montres ses forces et ses faiblesses sur le papier, et par des preuves formelles et/ou expérimentales.
Personne ne te prendra au sérieux si tu arrives en disant "regardez, j'ai un algo révolutionnaire !" sans benchmarks et/ou sans preuves formelles.
On peut bien sur comprendre que c'est un amateur, peut être que d'autres peuvent faire les tests à sa place, peut être que son scheduler est très bien sur du monoproc. Après, apparemment sur du multiproc/coeur il s'effondre.
Mais on peut aussi comprendre que sur un projet de l'envergure de Linux par exemple tester de nouvelles solutions ça coute du temps que les développeurs pourraient passer sur autre chose, que c'est pas dans les plans de maintenir plusieurs scheduler, et que quand un mec arrive avec un "prenez mon scheduler je vous assure qu'il est super cool" il soit pris avec des pincettes. Si il ne montre pas qu'effectivement le scheduler est significativement plus performant dans certains cas. Il faut que le jeu de l'introduction/du maintiens dans le noyau, d'éventuellement plusieurs schedulers en vaille la chandelle. Surtout si le mainteneur est pas vivable. Peut être que des adaptations sont possible sur le scheduler actuel pour améliorer les perfs en monoproc, par exemple, ce qui pourrait être moins couteux du point de vue du projet Linux.
[^] # Re: Étude en double aveugle !
Posté par thoasm . En réponse au journal BFS : La revanche. Évalué à 3.
Il est peut être super cool son scheduler sur les machines monoproc, j'en sais rien du tout. Le seul truc c'est que c'est un peu à lui de défendre son bébé avec des benchmarks par exemple.
C'est comme ça que ça marche dans la communauté et les publications scientifiques, tu fournis un boulot, tu défend ton approche, tu montres ses forces et ses faiblesses sur le papier, et par des preuves formelles et/ou expérimentales.
Personne ne te prendra au sérieux si tu arrives en disant "regardez, j'ai un algo révolutionnaire !" sans benchmarks et/ou sans preuves formelles.
On peut bien sur comprendre que c'est un amateur, peut être que d'autres peuvent faire les tests à sa place, peut être que son scheduler est très bien sur du monoproc. Après, apparemment sur du multiproc/coeur il s'effondre.
Mais on peut aussi comprendre que sur un projet de l'envergure de Linux par exemple tester de nouvelles solutions ça coute du temps que les développeurs pourraient passer sur autre chose, que c'est pas dans les plans de maintenir plusieurs scheduler, et que quand un mec arrive avec un "prenez mon scheduler je vous assure qu'il est super cool" il soit pris avec des pincettes. Si il ne montre pas qu'effectivement le scheduler est significativement plus performant dans certains cas. Il faut que le jeu de l'introduction/du maintiens dans le noyau, d'éventuellement plusieurs schedulers en vaille la chandelle. Surtout si le mainteneur est pas vivable. Peut être que des adaptations sont possible sur le scheduler actuel pour améliorer les perfs en monoproc, par exemple, ce qui pourrait être moins couteux du point de vue du projet Linux.