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.
[^] # 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)