Bonjour,
je viens de trouver une utilité de la course aux Ghz:
j'ai ordinateur ou je stocke des images de systèmes que j'utilise pour
Qemu. Eh bien pour pas bloater, je compresse avec bzip2 les images non
utilisées. Là, on mets une bonne dizaine de minutes à en compresser une.
Et quand il faut maintenant décompresser celle dont on a besoin,...
presque pareil.
Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je
crois... non?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gilles-Claude Rajaobelina
Bonjour, je viens de trouver une utilité de la course aux Ghz: [...]. Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je crois... non?
Cheux pas. Temps de calcul = f(taille des images) vs Temps des E/S toussa
Bonjour,
je viens de trouver une utilité de la course aux Ghz:
[...].
Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je
crois... non?
Cheux pas.
Temps de calcul = f(taille des images)
vs
Temps des E/S
toussa
Bonjour, je viens de trouver une utilité de la course aux Ghz: [...]. Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je crois... non?
Cheux pas. Temps de calcul = f(taille des images) vs Temps des E/S toussa
Le Thu, 16 Nov 2006 00:30:27 +0100, "Rakotomandimby (R12y)" écrivait dans fr.comp.os.linux.debats:
Bonjour, je viens de trouver une utilité de la course aux Ghz: j'ai ordinateur ou je stocke des images de systèmes que j'utilise pour Qemu. Eh bien pour pas bloater, je compresse avec bzip2 les images non utilisées. Là, on mets une bonne dizaine de minutes à en compresser une. Et quand il faut maintenant décompresser celle dont on a besoin,... presque pareil. Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je crois... non?
Oui et non. Il y a beaucoup de facteurs en jeu.
Par exemple, tel puce à 1 GHz utilise 5 coups d'horloge pour faire une addition et une autre puce à 500 MHz utilise un seul coup d'horloge. Donc, ici, la puce à 500 MHz est plus rapide.
De même, la mémoire peut être moins rapide (par exemple, il faut 5 coups d'horloge pour lire une valeur dans le CPU au lieu de 2).
Donc, même si ici on parle d'un calcul qui se fait tout en mémoire et qui ne devrait pas être affecté par les E/S, ajouter des GHz pourrait ne pas accélérer le travail.
Chose certaine, plus on est près de la machine, plus on est rapide. Faire le calcul directement en shell sans lancer Gnome ou KDE pourrait réellement accélérer un calcul de ce genre. Reste à voir si on utilise des librairies offrant une telle possibilité (du calcul pur sans graphisme).
Denis
Le Thu, 16 Nov 2006 00:30:27 +0100, "Rakotomandimby (R12y)"
<mihamina.rakotomandimby@etu.univ-orleans.fr> écrivait dans
fr.comp.os.linux.debats:
Bonjour,
je viens de trouver une utilité de la course aux Ghz:
j'ai ordinateur ou je stocke des images de systèmes que j'utilise pour
Qemu. Eh bien pour pas bloater, je compresse avec bzip2 les images non
utilisées. Là, on mets une bonne dizaine de minutes à en compresser une.
Et quand il faut maintenant décompresser celle dont on a besoin,...
presque pareil.
Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je
crois... non?
Oui et non. Il y a beaucoup de facteurs en jeu.
Par exemple, tel puce à 1 GHz utilise 5 coups d'horloge pour faire une
addition et une autre puce à 500 MHz utilise un seul coup d'horloge.
Donc, ici, la puce à 500 MHz est plus rapide.
De même, la mémoire peut être moins rapide (par exemple, il faut
5 coups d'horloge pour lire une valeur dans le CPU au lieu de 2).
Donc, même si ici on parle d'un calcul qui se fait tout en mémoire
et qui ne devrait pas être affecté par les E/S, ajouter des GHz
pourrait ne pas accélérer le travail.
Chose certaine, plus on est près de la machine, plus on est rapide.
Faire le calcul directement en shell sans lancer Gnome ou KDE
pourrait réellement accélérer un calcul de ce genre. Reste à voir
si on utilise des librairies offrant une telle possibilité (du
calcul pur sans graphisme).
Le Thu, 16 Nov 2006 00:30:27 +0100, "Rakotomandimby (R12y)" écrivait dans fr.comp.os.linux.debats:
Bonjour, je viens de trouver une utilité de la course aux Ghz: j'ai ordinateur ou je stocke des images de systèmes que j'utilise pour Qemu. Eh bien pour pas bloater, je compresse avec bzip2 les images non utilisées. Là, on mets une bonne dizaine de minutes à en compresser une. Et quand il faut maintenant décompresser celle dont on a besoin,... presque pareil. Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je crois... non?
Oui et non. Il y a beaucoup de facteurs en jeu.
Par exemple, tel puce à 1 GHz utilise 5 coups d'horloge pour faire une addition et une autre puce à 500 MHz utilise un seul coup d'horloge. Donc, ici, la puce à 500 MHz est plus rapide.
De même, la mémoire peut être moins rapide (par exemple, il faut 5 coups d'horloge pour lire une valeur dans le CPU au lieu de 2).
Donc, même si ici on parle d'un calcul qui se fait tout en mémoire et qui ne devrait pas être affecté par les E/S, ajouter des GHz pourrait ne pas accélérer le travail.
Chose certaine, plus on est près de la machine, plus on est rapide. Faire le calcul directement en shell sans lancer Gnome ou KDE pourrait réellement accélérer un calcul de ce genre. Reste à voir si on utilise des librairies offrant une telle possibilité (du calcul pur sans graphisme).
Denis
Rakotomandimby (R12y)
Gilles-Claude Rajaobelina:
je viens de trouver une utilité de la course aux Ghz: [...]. Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je crois... non? Cheux pas.
Temps de calcul = f(taille des images) vs Temps des E/S
En regardant la loupiotte du disque dur, elle n'est pas encore allumée en permanence... Il y a encore de la marge ;)
Gilles-Claude Rajaobelina:
je viens de trouver une utilité de la course aux Ghz:
[...].
Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je
crois... non?
Cheux pas.
Temps de calcul = f(taille des images)
vs
Temps des E/S
En regardant la loupiotte du disque dur, elle n'est pas encore allumée en
permanence... Il y a encore de la marge ;)
je viens de trouver une utilité de la course aux Ghz: [...]. Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je crois... non? Cheux pas.
Temps de calcul = f(taille des images) vs Temps des E/S
En regardant la loupiotte du disque dur, elle n'est pas encore allumée en permanence... Il y a encore de la marge ;)
Michel Billaud
"Rakotomandimby (R12y)" writes:
Bonjour, je viens de trouver une utilité de la course aux Ghz: j'ai ordinateur ou je stocke des images de systèmes que j'utilise pour Qemu. Eh bien pour pas bloater, je compresse avec bzip2 les images non utilisées. Là, on mets une bonne dizaine de minutes à en compresser une. Et quand il faut maintenant décompresser celle dont on a besoin,... presque pareil.
J'ai fait des tests récemment sur la question du stockage compressé des fichiers COW d'User Mode Linux. Il ya le meme genre de choses sur qemu.
la particularité de ces fichiers COW, c'est qu'ils sont très creux (sparse). Exemple : $ ls -lh *.cow -rw-r--r-- 1 billaud profs 430M 2006-11-13 14:06 sl.cow
Il faut (sur un bipro P3-700, scsi...), pour le compresser - 30 secondes par gzip (615 Ko) - 90 secondes par bzip2 (116 Ko)
En fait, sous linux, les blocs contenant des zeros ne sont pas alloués, ce qui économise de la place. L'occupation disque est nettement inférieure $ du -h *.cow 1,6M sl.cow
le problème c'est que ces deux commandes ne tirent pas profit de la non-allocation des blocs nuls, et donc demandent à lire des blocs nuls, et les traitent, ce qui prend du temps.
Par contre, la commande tar sait gérer les blocs non alloués : les blocs nuls ne sont pas stockés dans l'archive
fabrication archive
- par tar cf : 41 secondes, 431 M - par tar cSf : 7 secondes, 1 M - par tar czSf : 7,5 secondes, 700 K - par tar cjSf : 7,6 secondes, 86 K
Donc un gain de temps/espace 1 à 10 sur le bzip2 d'origine.
Amusant, non ?
Tests sur machine peu chargée, pas répétés, dépendant du fichier, etc. Mais ça donne une idée.... Si vous voulez des tests sérieux, faites les vous mêmes ! Sur un autre exemple (le COW d'un systeme de fichiers plus remué) il y a une grosse difference de temps entre les compressions z (gzip) et j (bzip2), qui font que j'ai choisi tar czSf plutot qu cjSf.
Accessoirement, pour transférer les fichiers creux et meme les copier, il vaut mieux utiliser rsync avec l'option S, que faire un cp local ou sur NFS !
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Bonjour,
je viens de trouver une utilité de la course aux Ghz:
j'ai ordinateur ou je stocke des images de systèmes que j'utilise pour
Qemu. Eh bien pour pas bloater, je compresse avec bzip2 les images non
utilisées. Là, on mets une bonne dizaine de minutes à en compresser une.
Et quand il faut maintenant décompresser celle dont on a besoin,...
presque pareil.
J'ai fait des tests récemment sur la question du stockage compressé
des fichiers COW d'User Mode Linux. Il ya le meme genre de choses sur
qemu.
la particularité de ces fichiers COW, c'est qu'ils sont très creux
(sparse).
Exemple :
$ ls -lh *.cow
-rw-r--r-- 1 billaud profs 430M 2006-11-13 14:06 sl.cow
Il faut (sur un bipro P3-700, scsi...), pour le compresser
- 30 secondes par gzip (615 Ko)
- 90 secondes par bzip2 (116 Ko)
En fait, sous linux, les blocs contenant des zeros ne sont pas
alloués, ce qui économise de la place. L'occupation disque est
nettement inférieure
$ du -h *.cow
1,6M sl.cow
le problème c'est que ces deux commandes ne tirent pas profit de la
non-allocation des blocs nuls, et donc demandent à lire des blocs
nuls, et les traitent, ce qui prend du temps.
Par contre, la commande tar sait gérer les blocs non alloués : les
blocs nuls ne sont pas stockés dans l'archive
fabrication archive
- par tar cf : 41 secondes, 431 M
- par tar cSf : 7 secondes, 1 M
- par tar czSf : 7,5 secondes, 700 K
- par tar cjSf : 7,6 secondes, 86 K
Donc un gain de temps/espace 1 à 10 sur le bzip2 d'origine.
Amusant, non ?
Tests sur machine peu chargée, pas répétés, dépendant du fichier, etc.
Mais ça donne une idée.... Si vous voulez des tests sérieux, faites les
vous mêmes ! Sur un autre exemple (le COW d'un systeme de fichiers
plus remué) il y a une grosse difference de temps entre les
compressions z (gzip) et j (bzip2), qui font que j'ai choisi tar czSf
plutot qu cjSf.
Accessoirement, pour transférer les fichiers creux et meme les
copier, il vaut mieux utiliser rsync avec l'option S, que faire un cp
local ou sur NFS !
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Bonjour, je viens de trouver une utilité de la course aux Ghz: j'ai ordinateur ou je stocke des images de systèmes que j'utilise pour Qemu. Eh bien pour pas bloater, je compresse avec bzip2 les images non utilisées. Là, on mets une bonne dizaine de minutes à en compresser une. Et quand il faut maintenant décompresser celle dont on a besoin,... presque pareil.
J'ai fait des tests récemment sur la question du stockage compressé des fichiers COW d'User Mode Linux. Il ya le meme genre de choses sur qemu.
la particularité de ces fichiers COW, c'est qu'ils sont très creux (sparse). Exemple : $ ls -lh *.cow -rw-r--r-- 1 billaud profs 430M 2006-11-13 14:06 sl.cow
Il faut (sur un bipro P3-700, scsi...), pour le compresser - 30 secondes par gzip (615 Ko) - 90 secondes par bzip2 (116 Ko)
En fait, sous linux, les blocs contenant des zeros ne sont pas alloués, ce qui économise de la place. L'occupation disque est nettement inférieure $ du -h *.cow 1,6M sl.cow
le problème c'est que ces deux commandes ne tirent pas profit de la non-allocation des blocs nuls, et donc demandent à lire des blocs nuls, et les traitent, ce qui prend du temps.
Par contre, la commande tar sait gérer les blocs non alloués : les blocs nuls ne sont pas stockés dans l'archive
fabrication archive
- par tar cf : 41 secondes, 431 M - par tar cSf : 7 secondes, 1 M - par tar czSf : 7,5 secondes, 700 K - par tar cjSf : 7,6 secondes, 86 K
Donc un gain de temps/espace 1 à 10 sur le bzip2 d'origine.
Amusant, non ?
Tests sur machine peu chargée, pas répétés, dépendant du fichier, etc. Mais ça donne une idée.... Si vous voulez des tests sérieux, faites les vous mêmes ! Sur un autre exemple (le COW d'un systeme de fichiers plus remué) il y a une grosse difference de temps entre les compressions z (gzip) et j (bzip2), qui font que j'ai choisi tar czSf plutot qu cjSf.
Accessoirement, pour transférer les fichiers creux et meme les copier, il vaut mieux utiliser rsync avec l'option S, que faire un cp local ou sur NFS !
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Michel Billaud
"Rakotomandimby (R12y)" writes:
Gilles-Claude Rajaobelina:
je viens de trouver une utilité de la course aux Ghz: [...]. Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je crois... non? Cheux pas.
Temps de calcul = f(taille des images) vs Temps des E/S
En regardant la loupiotte du disque dur, elle n'est pas encore allumée en permanence... Il y a encore de la marge ;)
C'est que ton processeur passe son temps à compresser des blocs de données contenant plein de zeros, blocs qui n'existent même pas sur le disque (fichiers creux, voir autre message).
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
je viens de trouver une utilité de la course aux Ghz:
[...].
Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je
crois... non?
Cheux pas.
Temps de calcul = f(taille des images)
vs
Temps des E/S
En regardant la loupiotte du disque dur, elle n'est pas encore allumée en
permanence... Il y a encore de la marge ;)
C'est que ton processeur passe son temps à compresser des blocs de
données contenant plein de zeros, blocs qui n'existent même pas sur le
disque (fichiers creux, voir autre message).
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
je viens de trouver une utilité de la course aux Ghz: [...]. Avec beaucoup de GHz, on aurait peut-etre fait ça plus rapidement, je crois... non? Cheux pas.
Temps de calcul = f(taille des images) vs Temps des E/S
En regardant la loupiotte du disque dur, elle n'est pas encore allumée en permanence... Il y a encore de la marge ;)
C'est que ton processeur passe son temps à compresser des blocs de données contenant plein de zeros, blocs qui n'existent même pas sur le disque (fichiers creux, voir autre message).
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Nicolas George
Michel Billaud , dans le message , a écrit :
En fait, sous linux, les blocs contenant des zeros ne sont pas alloués
C'est le contraire. Si tu écris effectivement des zéros, les blocs correspondants sont alloués. Ce qui se passe, c'est que si tu forces la taille d'un fichier, sans effectivement écrire dedans partout, alors les blocs non alloués apparaissent comme remplis de zéros.
Michel Billaud , dans le message <7zirhfphym.fsf@serveur5.labri.fr>, a
écrit :
En fait, sous linux, les blocs contenant des zeros ne sont pas
alloués
C'est le contraire. Si tu écris effectivement des zéros, les blocs
correspondants sont alloués. Ce qui se passe, c'est que si tu forces la
taille d'un fichier, sans effectivement écrire dedans partout, alors les
blocs non alloués apparaissent comme remplis de zéros.
En fait, sous linux, les blocs contenant des zeros ne sont pas alloués
C'est le contraire. Si tu écris effectivement des zéros, les blocs correspondants sont alloués. Ce qui se passe, c'est que si tu forces la taille d'un fichier, sans effectivement écrire dedans partout, alors les blocs non alloués apparaissent comme remplis de zéros.
Michel Billaud
Nicolas George <nicolas$ writes:
Michel Billaud , dans le message , a écrit :
En fait, sous linux, les blocs contenant des zeros ne sont pas alloués
C'est le contraire. Si tu écris effectivement des zéros, les blocs correspondants sont alloués. Ce qui se passe, c'est que si tu forces la taille d'un fichier, sans effectivement écrire dedans partout, alors les blocs non alloués apparaissent comme remplis de zéros.
J'ai rien bu pourtant.
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Nicolas George <nicolas$george@salle-s.org> writes:
Michel Billaud , dans le message <7zirhfphym.fsf@serveur5.labri.fr>, a
écrit :
En fait, sous linux, les blocs contenant des zeros ne sont pas
alloués
C'est le contraire. Si tu écris effectivement des zéros, les blocs
correspondants sont alloués. Ce qui se passe, c'est que si tu forces la
taille d'un fichier, sans effectivement écrire dedans partout, alors les
blocs non alloués apparaissent comme remplis de zéros.
J'ai rien bu pourtant.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
En fait, sous linux, les blocs contenant des zeros ne sont pas alloués
C'est le contraire. Si tu écris effectivement des zéros, les blocs correspondants sont alloués. Ce qui se passe, c'est que si tu forces la taille d'un fichier, sans effectivement écrire dedans partout, alors les blocs non alloués apparaissent comme remplis de zéros.
J'ai rien bu pourtant.
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
