Stooooooooooooooooop !
It's not a bug, it's a feature :-)
Avec une granularité si faible (proche du millième de secondes) il faut tenir compte du scheduler (l'ordonnanceur). Pendant que ton programme s'exécute, il n'est pas seul sur la machine. Et de temps à autre, le noyau décide de lui faire passer son tour. Ce qui se traduit par des "trous". Ceux qui ont des valeurs constantes n'avaient juste rien d'autre qui tournait. Et je pense que sous Windows, si tu fais tourner autre chose en //, tu auras le même problème.
Démonstration :
Le programme Ruby en lien [0] execute autant de fois que possible la fonction "busyloop". Après chaque intervalle de temps, il affiche combien de fois elle a été exécutée.
On constate exactement le même phénomène : de temps en temps, les performances chutent brusquement. En graphant [1], on constate même autre chose : à vue de nez, c'est régulier ! Ce qui confirme bien l'hypothèse que, de temps en temps, le noyau laisse la place à une autre appli.
Maintenant, pour résoudre ton problème, tu peux :
- augmenter la priorité de ton programme, et l'executer en tant que root
- fermer toutes tes petites applets qui bouffent tout plein de proc et ne servent à rien de toute facon
- tenir compte du fait que, parfois, il faut laisser les autres s'executer, par exemple en appelant volontairement sched_yield() quand ça t'arrange
- jouer avec les priorités temps réel du noyau, pour ne pas laisser les autres s'executer
Pourquoi ca ne fait pas pareil sous Windows ?
Je ne connais pas le scheduler de Windows. Mais peut-être qu'il autorise une appli à bouffer tout le proc pendant 5 secondes. Ca vaut peut-être le coup d'augmenter la durée du test.
Ou alors, peut-etre que ton Windows est juste moins chargé que ton Linux.
# C'est le scheduler que tu mesures ...
Posté par Lucas . En réponse au journal Drivers nvidia, drivers en carton ?. Évalué à 10.
It's not a bug, it's a feature :-)
Avec une granularité si faible (proche du millième de secondes) il faut tenir compte du scheduler (l'ordonnanceur). Pendant que ton programme s'exécute, il n'est pas seul sur la machine. Et de temps à autre, le noyau décide de lui faire passer son tour. Ce qui se traduit par des "trous". Ceux qui ont des valeurs constantes n'avaient juste rien d'autre qui tournait. Et je pense que sous Windows, si tu fais tourner autre chose en //, tu auras le même problème.
Démonstration :
Le programme Ruby en lien [0] execute autant de fois que possible la fonction "busyloop". Après chaque intervalle de temps, il affiche combien de fois elle a été exécutée.
On constate exactement le même phénomène : de temps en temps, les performances chutent brusquement. En graphant [1], on constate même autre chose : à vue de nez, c'est régulier ! Ce qui confirme bien l'hypothèse que, de temps en temps, le noyau laisse la place à une autre appli.
Maintenant, pour résoudre ton problème, tu peux :
- augmenter la priorité de ton programme, et l'executer en tant que root
- fermer toutes tes petites applets qui bouffent tout plein de proc et ne servent à rien de toute facon
- tenir compte du fait que, parfois, il faut laisser les autres s'executer, par exemple en appelant volontairement sched_yield() quand ça t'arrange
- jouer avec les priorités temps réel du noyau, pour ne pas laisser les autres s'executer
Pourquoi ca ne fait pas pareil sous Windows ?
Je ne connais pas le scheduler de Windows. Mais peut-être qu'il autorise une appli à bouffer tout le proc pendant 5 secondes. Ca vaut peut-être le coup d'augmenter la durée du test.
Ou alors, peut-etre que ton Windows est juste moins chargé que ton Linux.
[0] http://bazaar.lucas-nussbaum.net/linuxfr/sched.rb(...)
[1] http://bazaar.lucas-nussbaum.net/linuxfr/sched.png(...)