Pour les outils différents je peu pas faire autrement.
Rien de t'empêche de faire un programme en C de 10 lignes pour copier un fichier, et de le compiler sous Linux et sous Windows. Au moins, tu sauras ce que fait ton programme.
Pour les testes concurrent j'ai mit 4 programme essayant de faire un lecture parallèle du disk brute. dd if=/dev/sda of=/dev/null pour linux
Ca alors, d'un essai à l'autre, la vitesse a été multipliée par 10...
Bien sûr, on voit tout de suite que le buffer cache a été utilisé pour le deuxième essai, d'où la différence énorme. Tout cela pour dire que j'ai de gros doutes quant à la pertinence de tes tests...
Les performances dépendent de plein de facteurs, l'ordonnanceur d'E/S, le readahead, le FS, l'utlisation du cache...
Il faut savoir que 90% des benchmarks que tu peux trouver sur Internet sont totalement inutiles : il ne faut pas se leurrer, c'est plus complexe qu'il n'y paraît, certaines grandes boîtes emploient des gars dont c'est la spécialité.
Je n'ai rien contre ta curiosité, au contraire, mais il faut bien se renseigner avant de crier au loup, et de vouloir contacter les développeurs du noyau ;-)
J'ai vu que tu développais un équivalent de super-copier sous Linux, ce ne serait pas à cause d'un écart de performances sous Windows et sous Linux que tu te poserais des questions ;-) ?
Si tel est le cas, je te conseille de regarder ton code avant d'aller poster sur lkml, notamment quand je vois ceci :-)
Hypotése: L'ordonnanceur sous linux ne preampt pas correctement la tache en la mettant sur pause le temps d'avoir les données hdd, mais fait tourner le cpu en boucle.
[^] # Re: ...
Posté par neologix . En réponse au message Bug dans les accès concurrent du disk. Évalué à 6.
Rien de t'empêche de faire un programme en C de 10 lignes pour copier un fichier, et de le compiler sous Linux et sous Windows. Au moins, tu sauras ce que fait ton programme.
Pour les testes concurrent j'ai mit 4 programme essayant de faire un lecture parallèle du disk brute. dd if=/dev/sda of=/dev/null pour linux
root@neobox:/home/cf# free -m
total used free shared buffers cached
Mem: 502 383 119 0 122 71
-/+ buffers/cache: 188 313
Swap: 486 0 486
root@neobox:/home/cf# time dd if=/dev/hda2 of=/dev/null count=100K
102400+0 enregistrements lus
102400+0 enregistrements écrits
52428800 bytes (52 MB) copied, 2,61817 s, 20,0 MB/s
real 0m2.622s
user 0m0.069s
sys 0m0.256s
root@neobox:/home/cf# free -m
total used free shared buffers cached
Mem: 502 433 69 0 173 71
-/+ buffers/cache: 189 313
Swap: 486 0 486
root@neobox:/home/cf# time dd if=/dev/hda2 of=/dev/null count=100K
102400+0 enregistrements lus
102400+0 enregistrements écrits
52428800 bytes (52 MB) copied, 0,262924 s, 199 MB/s
real 0m0.267s
user 0m0.057s
sys 0m0.206s
Ca alors, d'un essai à l'autre, la vitesse a été multipliée par 10...
Bien sûr, on voit tout de suite que le buffer cache a été utilisé pour le deuxième essai, d'où la différence énorme. Tout cela pour dire que j'ai de gros doutes quant à la pertinence de tes tests...
Les performances dépendent de plein de facteurs, l'ordonnanceur d'E/S, le readahead, le FS, l'utlisation du cache...
Il faut savoir que 90% des benchmarks que tu peux trouver sur Internet sont totalement inutiles : il ne faut pas se leurrer, c'est plus complexe qu'il n'y paraît, certaines grandes boîtes emploient des gars dont c'est la spécialité.
Je n'ai rien contre ta curiosité, au contraire, mais il faut bien se renseigner avant de crier au loup, et de vouloir contacter les développeurs du noyau ;-)
J'ai vu que tu développais un équivalent de super-copier sous Linux, ce ne serait pas à cause d'un écart de performances sous Windows et sous Linux que tu te poserais des questions ;-) ?
Si tel est le cas, je te conseille de regarder ton code avant d'aller poster sur lkml, notamment quand je vois ceci :-)
Hypotése: L'ordonnanceur sous linux ne preampt pas correctement la tache en la mettant sur pause le temps d'avoir les données hdd, mais fait tourner le cpu en boucle.