voici quelques extraits : I just can't believe reiser4 is so fast on an unloaded system (from the numbers one could also expect it's the slowest on loaded systems and JFS seems to be the winner on those).
Hans Reiser lui même dit cela : reiser4 cpu consumption is still dropping rapidly as others and I find kruft in the code and remove it. Major kruft remains still.
(kruft = unpleasant substance)
Bien sûr j'essaye de comprendre jusqu'au bout, je ne suis pas du tout un expert.
Il me semble que le benchmark dont nous parlons a été fait avec un CPU sans charge de calcul (quel qu'il soit, système ou non).
En faisant l'hypthèse que la charge de calcul est importante (100% s'il n'y a rien d'autre à faire) ET que le scheduler ne donne pas la priorité absolue à la gestion du système de fichier (mais ça je ne le sais pas), si le système lui donne un peu de temps CPU de temps en temps, alors il y a un goulot d'étranglement au niveau du CPU pour la gestion du système de fichier.
Si ce goulot peut atteindre 30% du CPU alors reiser4 sera le plus rapide, si ce goulot est de 6% alors JFS sera le plus rapide non ?
Mais oui, c'est d'autant plus vrai que si la machine est surchargée au niveau du processeur, si tu ne disposes que de 28,25s CPU, JFS aura terminé alors que Reiser4 n'aura fait qu'à peine plus de la moitié du travail.
Je ne pense pas qu'atteindre 100% de CPU pour le système de fichier soit raisonnable, sinon tu ne pourrais plus rien faire lorsque tu fais un 'mv' d'une grosse quantité de fichiers :o)
Le petit calcul simple que j'ai fait permet de voir (en partie) l'optimisation du code pour effectuer une tâche donnée (ici le test).
JFS (que je n'ai jamais utilisé, donc je n'en fais pas du tout la promotion) semble donc avoir le code le plus performant car au final c'est celui qui utilise le moins le CPU par rapport à la tâche à effectuer.
En prenant les cas extrêmes suivants, je pense qu'un bon système de fichier est tout simplement un bon équilibre entre ces 2 cas (sûrement très difficile à trouver) :
1) le processeur est à 100% pendant 150s
avantage : c'est le plus rapide
inconvénient : tu ne peux presque plus rien faire avec ton ordinateur pendant qu'il manipule des fichiers
2) le processeur est à 0.01% pendant 500s
avantage : ton processeur est libre à 99% tout le temps
inconvénient : c'est le plus lent
Mais, je reste persuadé que le code 2) est le plus efficace car 500s * 0.01 = 5s au lieu de 150s (il y a un facteur 30) !
Il ne faut pas me faire dire ce que je n'ai pas dit : je n'ai pas dit que JFS tournait en 28.25 secondes, j'ai dit que c'était le temps CPU utilisé pour exécuter la tâche (enfin ce n'était peut être pas clair, j'espère que ça l'est plus maintenant).
De même que mon hypothèse n'est pas falsificatrice dans le sens que je viens de donner plus haut, tout dépend de ce que l'on met dans "efficacité". C'était pour se poser la question de ce que peut être l'efficacité d'un système de fichier.
On peut donc conclure que l'on peut calculer un certain nombre de quantités à partir des chiffres des benchmarks qui ont chacune un intérêt.
Si on fait l'hypothèse que l'efficacité du système de fichier est le temps CPU multiplié par le % CPU alors on a les résultats suivants (cela revient à normaliser par rapport à 100% d'utilisation CPU) :
[^] # Re: La calculatrice Google
Posté par asailor . En réponse à la dépêche La calculatrice Google. Évalué à 4.
All the Web :
http://www.alltheweb.com/(...)
IxQuick, un meta moteur :
http://www.ixquick.com/(...)
[^] # Re: Validation d'une hypothèse...
Posté par asailor . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. Évalué à 1.
http://testing.lkml.org/slashdot.php?mid=322496(...)
voici quelques extraits :
I just can't believe reiser4 is so fast on an unloaded system (from the numbers one could also expect it's the slowest on loaded systems and JFS seems to be the winner on those).
Hans Reiser lui même dit cela :
reiser4 cpu consumption is still dropping rapidly as others and I find kruft in the code and remove it. Major kruft remains still.
(kruft = unpleasant substance)
et les nouveaux résultats (plus d'opérations) incluent *mes* calculs :o)
http://epoxy.mrs.umn.edu/~minerg/fstests/results.html(...)
[^] # Re: Validation d'une hypothèse...
Posté par asailor . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. Évalué à 1.
Alors pourquoi cette remarque :
"The first item number is time, in seconds, to complete the test (lower
is better). The second number is CPU use percentage (lower is better)."
?
[^] # Re: Validation d'une hypothèse...
Posté par asailor . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. Évalué à 1.
Il me semble que le benchmark dont nous parlons a été fait avec un CPU sans charge de calcul (quel qu'il soit, système ou non).
En faisant l'hypthèse que la charge de calcul est importante (100% s'il n'y a rien d'autre à faire) ET que le scheduler ne donne pas la priorité absolue à la gestion du système de fichier (mais ça je ne le sais pas), si le système lui donne un peu de temps CPU de temps en temps, alors il y a un goulot d'étranglement au niveau du CPU pour la gestion du système de fichier.
Si ce goulot peut atteindre 30% du CPU alors reiser4 sera le plus rapide, si ce goulot est de 6% alors JFS sera le plus rapide non ?
[^] # Re: Validation d'une hypothèse...
Posté par asailor . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. Évalué à 1.
toujours sans arrière pensée trollitique ;)
[^] # Re: Validation d'une hypothèse...
Posté par asailor . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. Évalué à 1.
Le petit calcul simple que j'ai fait permet de voir (en partie) l'optimisation du code pour effectuer une tâche donnée (ici le test).
JFS (que je n'ai jamais utilisé, donc je n'en fais pas du tout la promotion) semble donc avoir le code le plus performant car au final c'est celui qui utilise le moins le CPU par rapport à la tâche à effectuer.
En prenant les cas extrêmes suivants, je pense qu'un bon système de fichier est tout simplement un bon équilibre entre ces 2 cas (sûrement très difficile à trouver) :
1) le processeur est à 100% pendant 150s
avantage : c'est le plus rapide
inconvénient : tu ne peux presque plus rien faire avec ton ordinateur pendant qu'il manipule des fichiers
2) le processeur est à 0.01% pendant 500s
avantage : ton processeur est libre à 99% tout le temps
inconvénient : c'est le plus lent
Mais, je reste persuadé que le code 2) est le plus efficace car 500s * 0.01 = 5s au lieu de 150s (il y a un facteur 30) !
Il ne faut pas me faire dire ce que je n'ai pas dit : je n'ai pas dit que JFS tournait en 28.25 secondes, j'ai dit que c'était le temps CPU utilisé pour exécuter la tâche (enfin ce n'était peut être pas clair, j'espère que ça l'est plus maintenant).
De même que mon hypothèse n'est pas falsificatrice dans le sens que je viens de donner plus haut, tout dépend de ce que l'on met dans "efficacité". C'était pour se poser la question de ce que peut être l'efficacité d'un système de fichier.
On peut donc conclure que l'on peut calculer un certain nombre de quantités à partir des chiffres des benchmarks qui ont chacune un intérêt.
:o)
# Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par asailor . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. Évalué à 2.
reiser4 : 171.28 * 0.30 = 51.38
reiserfs : 302.53 * 0.16 = 48.40
ext3 : 319.71 * 0.11 = 35.17
xfs : 429.79 * 0.13 = 55.87
jfs : 470.88 * 0.06 = 28.25
Alors jfs est le plus efficace !