Voil=E0 : il y a deux ans environ, un de mes deux disques avait l=E2ch=E9
(salet=E9 de sata) et je ne tournais plus qu'avec un seul disque. Lors
d'un nettoyage Windows, il me semble que j'avais accept=E9 l'option
compressant les fichiers (et programmes) non-utilis=E9s depuis plus de
xx jours.
Je voudrais arr=EAter cette option et ne plus rien compresser.
Mais je ne sais pas o=F9 choper la commande.
Dans un menu Windows 2000 Pro ?
Une ligne de commande ?
La BDR ?
On Tue, 13 Mar 2007 13:27:12 +0100, Aigle bavard wrote:
Quelle est cette application qui est capable de travailler en RAM sans passer par le processeur ?
Keski dans le post de JCB te fait penser que le processeur n'est pas dans le coup ???
Ce n'est pas dans ce post-là. C'est parce qu'il répond à mon post de 09:17 où je posais la question : "Tu veux dire que le fichier passe une seule fois par le processeur, sous sa forme compressée ? ".
Aigle bavard
On Tue, 13 Mar 2007 13:27:12 +0100, Aigle bavard <ycarl@club.fr>
wrote:
Quelle est cette application qui est capable de travailler en RAM sans
passer par le processeur ?
Keski dans le post de JCB te fait penser que le processeur n'est pas
dans le coup ???
Ce n'est pas dans ce post-là.
C'est parce qu'il répond à mon post de 09:17 où je posais la question :
"Tu veux dire que le fichier passe une seule fois par le processeur,
sous sa forme compressée ? ".
On Tue, 13 Mar 2007 13:27:12 +0100, Aigle bavard wrote:
Quelle est cette application qui est capable de travailler en RAM sans passer par le processeur ?
Keski dans le post de JCB te fait penser que le processeur n'est pas dans le coup ???
Ce n'est pas dans ce post-là. C'est parce qu'il répond à mon post de 09:17 où je posais la question : "Tu veux dire que le fichier passe une seule fois par le processeur, sous sa forme compressée ? ".
Aigle bavard
Marc Boyer
Le 13-03-2007, Aigle bavard a écrit :
Car pour moi, la décompression induit un passage supplémentaire par le processeur. Càd : 1 - lecture du fichier compressé (donc passage par le proc) 2 - stockage du fichier compressé en RAM 3 - exploitation des données en RAM par l'application de décompression (donc second passage par le proc) 4 - ecriture en RAM du fichier décompressé (troisième passage par le proc)
A comparer avc la procédure de lecture d'un fichier non-compressé : 1 - lecture du fichier (passage par le proc) 2 - stockage du fichier en RAM
Est-ce une erreur ?
On ne peut pas faire de décompression à la volée ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 13-03-2007, Aigle bavard <ycarl@club.fr> a écrit :
Car pour moi, la décompression induit un passage supplémentaire par le
processeur. Càd :
1 - lecture du fichier compressé (donc passage par le proc)
2 - stockage du fichier compressé en RAM
3 - exploitation des données en RAM par l'application de décompression
(donc second passage par le proc)
4 - ecriture en RAM du fichier décompressé (troisième passage par le proc)
A comparer avc la procédure de lecture d'un fichier non-compressé :
1 - lecture du fichier (passage par le proc)
2 - stockage du fichier en RAM
Est-ce une erreur ?
On ne peut pas faire de décompression à la volée ?
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Car pour moi, la décompression induit un passage supplémentaire par le processeur. Càd : 1 - lecture du fichier compressé (donc passage par le proc) 2 - stockage du fichier compressé en RAM 3 - exploitation des données en RAM par l'application de décompression (donc second passage par le proc) 4 - ecriture en RAM du fichier décompressé (troisième passage par le proc)
A comparer avc la procédure de lecture d'un fichier non-compressé : 1 - lecture du fichier (passage par le proc) 2 - stockage du fichier en RAM
Est-ce une erreur ?
On ne peut pas faire de décompression à la volée ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Aigle bavard
"Aigle bavard" a écrit dans le message de news:45f6985b$0$21150$
Quelle est cette application qui est capable de travailler en RAM sans passer par le processeur ?
?????????????????????????????????????????????????? Où aurais-je écrit une telle absurdité ?
Même erreur que Nina : je ne dis pas que tu l'as écrit. Mais tu réponds à mon post de 09:17 posant la question précisément sur le passage par le _processeur_ (il n'y est pas du tout question du disque dur).
Car pour moi, la décompression induit un passage supplémentaire par le processeur. Càd : 1 - lecture du fichier compressé (donc passage par le proc) 2 - stockage du fichier compressé en RAM 3 - exploitation des données en RAM par l'application de décompression (donc second passage par le proc) 4 - ecriture en RAM du fichier décompressé (troisième passage par le proc)
A comparer avc la procédure de lecture d'un fichier non-compressé : 1 - lecture du fichier (passage par le proc) 2 - stockage du fichier en RAM
Est-ce une erreur ?
Aigle bavard
"Aigle bavard" <ycarl@club.fr> a écrit dans le message de
news:45f6985b$0$21150$7a628cd7@news.club-internet.fr...
Quelle est cette application qui est capable de travailler en RAM sans
passer par le processeur ?
??????????????????????????????????????????????????
Où aurais-je écrit une telle absurdité ?
Même erreur que Nina : je ne dis pas que tu l'as écrit. Mais tu réponds
à mon post de 09:17 posant la question précisément sur le passage par le
_processeur_ (il n'y est pas du tout question du disque dur).
Car pour moi, la décompression induit un passage supplémentaire par le
processeur. Càd :
1 - lecture du fichier compressé (donc passage par le proc)
2 - stockage du fichier compressé en RAM
3 - exploitation des données en RAM par l'application de décompression
(donc second passage par le proc)
4 - ecriture en RAM du fichier décompressé (troisième passage par le proc)
A comparer avc la procédure de lecture d'un fichier non-compressé :
1 - lecture du fichier (passage par le proc)
2 - stockage du fichier en RAM
"Aigle bavard" a écrit dans le message de news:45f6985b$0$21150$
Quelle est cette application qui est capable de travailler en RAM sans passer par le processeur ?
?????????????????????????????????????????????????? Où aurais-je écrit une telle absurdité ?
Même erreur que Nina : je ne dis pas que tu l'as écrit. Mais tu réponds à mon post de 09:17 posant la question précisément sur le passage par le _processeur_ (il n'y est pas du tout question du disque dur).
Car pour moi, la décompression induit un passage supplémentaire par le processeur. Càd : 1 - lecture du fichier compressé (donc passage par le proc) 2 - stockage du fichier compressé en RAM 3 - exploitation des données en RAM par l'application de décompression (donc second passage par le proc) 4 - ecriture en RAM du fichier décompressé (troisième passage par le proc)
A comparer avc la procédure de lecture d'un fichier non-compressé : 1 - lecture du fichier (passage par le proc) 2 - stockage du fichier en RAM
Est-ce une erreur ?
Aigle bavard
Marc Boyer
Le 13-03-2007, Aigle bavard a écrit :
Ben si, d'après ce que dit Nina mais je vois pas du tout comment ça se passe dans le détail.
Ca doit dépendre des algos.
Pour les algos de type 'audio/vidéo' que je connais, on stoque un petit bloc, on le décode, on passe au suivant en gardant quelques infos (codage en différentiel), etc. Les 'quelques infos' restant dans la taille d'un cache ça reste dans le proc.
Pour des algos de type 'dictionnaire', on a en tête de fichier compressé un dico, on stocke le dico, puis on lit un bloc de données, on décompresse à partir du dico, puis on lit le blocs de données suivant, etc.
On doit pouvoir combiner les approches.
Je crains que ce terme "à la volée" re recouvre en fait les opérations que je décris ci-dessus mais réalisées assez rapidement pour être qualifiées de "à la volée".
Non, dans le sens ou l'ensemble du fichier compressé n'a pas à être stocké tel quel en entier en mémoire d'abord.
Ce ne serait pas la première fois que la micro abuserait de terminologies flatteuses (ie "multitâche").
Que reproches-tu à "multitâche" ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 13-03-2007, Aigle bavard <ycarl@club.fr> a écrit :
Ben si, d'après ce que dit Nina mais je vois pas du tout comment ça se
passe dans le détail.
Ca doit dépendre des algos.
Pour les algos de type 'audio/vidéo' que je connais, on
stoque un petit bloc, on le décode, on passe au suivant en
gardant quelques infos (codage en différentiel), etc.
Les 'quelques infos' restant dans la taille d'un cache
ça reste dans le proc.
Pour des algos de type 'dictionnaire', on a en tête
de fichier compressé un dico, on stocke le dico, puis
on lit un bloc de données, on décompresse à partir du
dico, puis on lit le blocs de données suivant, etc.
On doit pouvoir combiner les approches.
Je crains que ce terme "à la volée" re recouvre en
fait les opérations que je décris ci-dessus mais réalisées assez
rapidement pour être qualifiées de "à la volée".
Non, dans le sens ou l'ensemble du fichier compressé
n'a pas à être stocké tel quel en entier en mémoire d'abord.
Ce ne serait pas la première fois que la micro abuserait de
terminologies flatteuses (ie "multitâche").
Que reproches-tu à "multitâche" ?
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Ben si, d'après ce que dit Nina mais je vois pas du tout comment ça se passe dans le détail.
Ca doit dépendre des algos.
Pour les algos de type 'audio/vidéo' que je connais, on stoque un petit bloc, on le décode, on passe au suivant en gardant quelques infos (codage en différentiel), etc. Les 'quelques infos' restant dans la taille d'un cache ça reste dans le proc.
Pour des algos de type 'dictionnaire', on a en tête de fichier compressé un dico, on stocke le dico, puis on lit un bloc de données, on décompresse à partir du dico, puis on lit le blocs de données suivant, etc.
On doit pouvoir combiner les approches.
Je crains que ce terme "à la volée" re recouvre en fait les opérations que je décris ci-dessus mais réalisées assez rapidement pour être qualifiées de "à la volée".
Non, dans le sens ou l'ensemble du fichier compressé n'a pas à être stocké tel quel en entier en mémoire d'abord.
Ce ne serait pas la première fois que la micro abuserait de terminologies flatteuses (ie "multitâche").
Que reproches-tu à "multitâche" ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Aigle bavard
Car pour moi, la décompression induit un passage supplémentaire par le processeur. Càd : 1 - lecture du fichier compressé (donc passage par le proc) 2 - stockage du fichier compressé en RAM 3 - exploitation des données en RAM par l'application de décompression (donc second passage par le proc) 4 - ecriture en RAM du fichier décompressé (troisième passage par le proc)
A comparer avc la procédure de lecture d'un fichier non-compressé : 1 - lecture du fichier (passage par le proc) 2 - stockage du fichier en RAM
Est-ce une erreur ?
On ne peut pas faire de décompression à la volée ?
Marc Boyer
Ben si, d'après ce que dit Nina mais je vois pas du tout comment ça se passe dans le détail. Je crains que ce terme "à la volée" re recouvre en fait les opérations que je décris ci-dessus mais réalisées assez rapidement pour être qualifiées de "à la volée". Ce ne serait pas la première fois que la micro abuserait de terminologies flatteuses (ie "multitâche").
Aigle bavard
Car pour moi, la décompression induit un passage supplémentaire par le
processeur. Càd :
1 - lecture du fichier compressé (donc passage par le proc)
2 - stockage du fichier compressé en RAM
3 - exploitation des données en RAM par l'application de décompression
(donc second passage par le proc)
4 - ecriture en RAM du fichier décompressé (troisième passage par le proc)
A comparer avc la procédure de lecture d'un fichier non-compressé :
1 - lecture du fichier (passage par le proc)
2 - stockage du fichier en RAM
Est-ce une erreur ?
On ne peut pas faire de décompression à la volée ?
Marc Boyer
Ben si, d'après ce que dit Nina mais je vois pas du tout comment ça se
passe dans le détail. Je crains que ce terme "à la volée" re recouvre en
fait les opérations que je décris ci-dessus mais réalisées assez
rapidement pour être qualifiées de "à la volée".
Ce ne serait pas la première fois que la micro abuserait de
terminologies flatteuses (ie "multitâche").
Car pour moi, la décompression induit un passage supplémentaire par le processeur. Càd : 1 - lecture du fichier compressé (donc passage par le proc) 2 - stockage du fichier compressé en RAM 3 - exploitation des données en RAM par l'application de décompression (donc second passage par le proc) 4 - ecriture en RAM du fichier décompressé (troisième passage par le proc)
A comparer avc la procédure de lecture d'un fichier non-compressé : 1 - lecture du fichier (passage par le proc) 2 - stockage du fichier en RAM
Est-ce une erreur ?
On ne peut pas faire de décompression à la volée ?
Marc Boyer
Ben si, d'après ce que dit Nina mais je vois pas du tout comment ça se passe dans le détail. Je crains que ce terme "à la volée" re recouvre en fait les opérations que je décris ci-dessus mais réalisées assez rapidement pour être qualifiées de "à la volée". Ce ne serait pas la première fois que la micro abuserait de terminologies flatteuses (ie "multitâche").
Aigle bavard
Aigle bavard
Non, dans le sens ou l'ensemble du fichier compressé n'a pas à être stocké tel quel en entier en mémoire d'abord.
OK, je n'avais pas pensé à ça...
Que reproches-tu à "multitâche" ?
D'avoir oublié une partie de son vrai nom (temps partagé) et de prétendre tourner sur une bécane mono-processeur... ;-)
Aigle bavard
Non, dans le sens ou l'ensemble du fichier compressé
n'a pas à être stocké tel quel en entier en mémoire d'abord.
OK, je n'avais pas pensé à ça...
Que reproches-tu à "multitâche" ?
D'avoir oublié une partie de son vrai nom (temps partagé) et de
prétendre tourner sur une bécane mono-processeur... ;-)
Non, dans le sens ou l'ensemble du fichier compressé n'a pas à être stocké tel quel en entier en mémoire d'abord.
OK, je n'avais pas pensé à ça...
Que reproches-tu à "multitâche" ?
D'avoir oublié une partie de son vrai nom (temps partagé) et de prétendre tourner sur une bécane mono-processeur... ;-)
Aigle bavard
Marc Boyer
Le 13-03-2007, Aigle bavard a écrit :
Que reproches-tu à "multitâche" ?
D'avoir oublié une partie de son vrai nom (temps partagé) et de prétendre tourner sur une bécane mono-processeur... ;-)
Ben non, il gère de multiples tâches. Son nom ne prétend pas les exécuter en même temps. Il s'opposait à des OS qui ne géraient qu'une tache après l'autre. Mon bon vieux Windows se bloquaient quand il copiait une disquette, alors que mon Linux acceptait quand même que je touche au clavier.
Mais comme les bécannes mono-processeurs vont toutes devenir multi-coeur...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 13-03-2007, Aigle bavard <ycarl@club.fr> a écrit :
Que reproches-tu à "multitâche" ?
D'avoir oublié une partie de son vrai nom (temps partagé) et de
prétendre tourner sur une bécane mono-processeur... ;-)
Ben non, il gère de multiples tâches. Son nom ne prétend
pas les exécuter en même temps. Il s'opposait à des OS qui
ne géraient qu'une tache après l'autre. Mon bon vieux
Windows se bloquaient quand il copiait une disquette,
alors que mon Linux acceptait quand même que je touche au
clavier.
Mais comme les bécannes mono-processeurs vont toutes
devenir multi-coeur...
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
D'avoir oublié une partie de son vrai nom (temps partagé) et de prétendre tourner sur une bécane mono-processeur... ;-)
Ben non, il gère de multiples tâches. Son nom ne prétend pas les exécuter en même temps. Il s'opposait à des OS qui ne géraient qu'une tache après l'autre. Mon bon vieux Windows se bloquaient quand il copiait une disquette, alors que mon Linux acceptait quand même que je touche au clavier.
Mais comme les bécannes mono-processeurs vont toutes devenir multi-coeur...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Clairon
Bonjour !
Marc Boyer a ecrit le 13/03/2007 16:48:
Ben non, il gère de multiples tâches.
Oui, mais pas toutes en même temps. A un instant donné une seule tâche est en cours et toutes les autres sont en attente. Simplement le processeur passe si vite d'une tâche à l'autre que nous, humains, avons *l'impression* qu'elles sont traitées en parallèle. Or, une vraie exécution en parallèle nécessite un OS multi-tâches _et_ une machine multi-processeurs. Sinon c'est un OS à temps partagé.
-- Clairon
Bonjour !
Marc Boyer a ecrit le 13/03/2007 16:48:
Ben non, il gère de multiples tâches.
Oui, mais pas toutes en même temps. A un instant donné une seule tâche
est en cours et toutes les autres sont en attente. Simplement le
processeur passe si vite d'une tâche à l'autre que nous, humains, avons
*l'impression* qu'elles sont traitées en parallèle. Or, une vraie
exécution en parallèle nécessite un OS multi-tâches _et_ une machine
multi-processeurs. Sinon c'est un OS à temps partagé.
Oui, mais pas toutes en même temps. A un instant donné une seule tâche est en cours et toutes les autres sont en attente. Simplement le processeur passe si vite d'une tâche à l'autre que nous, humains, avons *l'impression* qu'elles sont traitées en parallèle. Or, une vraie exécution en parallèle nécessite un OS multi-tâches _et_ une machine multi-processeurs. Sinon c'est un OS à temps partagé.
-- Clairon
Marc Boyer
Le 13-03-2007, Clairon a écrit :
Marc Boyer a ecrit le 13/03/2007 16:48:
Ben non, il gère de multiples tâches.
Oui, mais pas toutes en même temps.
"gérer" n'est pas synonyme d'"exécuter"
L'OS gère, et passe d'une tache à l'autre en fonction de différents critères (quantum de temps, process bloqué sur une IO, coopération, etc).
A un instant donné une seule tâche est en cours et toutes les autres sont en attente. Simplement le processeur passe si vite d'une tâche à l'autre que nous, humains, avons *l'impression* qu'elles sont traitées en parallèle. Or, une vraie exécution en parallèle nécessite un OS multi-tâches _et_ une machine multi-processeurs. Sinon c'est un OS à temps partagé.
Ou un processeur multi-coeur ;-)
Oui, multi-tâche n'est pas synonyme de "parallèle". D'ailleurs, dans des machines SIMD (je ne sais pas si on en fait encore), on avait du parallélisme mono-tache.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 13-03-2007, Clairon <cbrione@free.fr> a écrit :
Marc Boyer a ecrit le 13/03/2007 16:48:
Ben non, il gère de multiples tâches.
Oui, mais pas toutes en même temps.
"gérer" n'est pas synonyme d'"exécuter"
L'OS gère, et passe d'une tache à l'autre en fonction
de différents critères (quantum de temps, process bloqué
sur une IO, coopération, etc).
A un instant donné une seule tâche
est en cours et toutes les autres sont en attente. Simplement le
processeur passe si vite d'une tâche à l'autre que nous, humains, avons
*l'impression* qu'elles sont traitées en parallèle. Or, une vraie
exécution en parallèle nécessite un OS multi-tâches _et_ une machine
multi-processeurs. Sinon c'est un OS à temps partagé.
Ou un processeur multi-coeur ;-)
Oui, multi-tâche n'est pas synonyme de "parallèle".
D'ailleurs, dans des machines SIMD (je ne sais pas si on en
fait encore), on avait du parallélisme mono-tache.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
L'OS gère, et passe d'une tache à l'autre en fonction de différents critères (quantum de temps, process bloqué sur une IO, coopération, etc).
A un instant donné une seule tâche est en cours et toutes les autres sont en attente. Simplement le processeur passe si vite d'une tâche à l'autre que nous, humains, avons *l'impression* qu'elles sont traitées en parallèle. Or, une vraie exécution en parallèle nécessite un OS multi-tâches _et_ une machine multi-processeurs. Sinon c'est un OS à temps partagé.
Ou un processeur multi-coeur ;-)
Oui, multi-tâche n'est pas synonyme de "parallèle". D'ailleurs, dans des machines SIMD (je ne sais pas si on en fait encore), on avait du parallélisme mono-tache.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Alain Redic
NON, cela ne ralentit pas du tout, car le fichier occupant MOINS de place sur le disque, le temps de transfert (très long à l'échelle du processeur) se trouve réduit d'autant. Donc le temps perdu dans la décompression est très largement compensé par le gain de temps de lecture du fichier.
loin de moi l'idée de vouloir contredire, mais c'étaient les mêmes arguments cités à l'époque pour stacker. A l'usage on s'est vite rendu compte de la lenteur de celui-ci.
NON, cela ne ralentit pas du tout, car le fichier occupant MOINS de
place sur le disque, le temps de transfert (très long à l'échelle du
processeur) se trouve réduit d'autant.
Donc le temps perdu dans la décompression est très largement compensé
par le gain de temps de lecture du fichier.
loin de moi l'idée de vouloir contredire, mais c'étaient les mêmes
arguments cités à l'époque pour stacker.
A l'usage on s'est vite rendu compte de la lenteur de celui-ci.
NON, cela ne ralentit pas du tout, car le fichier occupant MOINS de place sur le disque, le temps de transfert (très long à l'échelle du processeur) se trouve réduit d'autant. Donc le temps perdu dans la décompression est très largement compensé par le gain de temps de lecture du fichier.
loin de moi l'idée de vouloir contredire, mais c'étaient les mêmes arguments cités à l'époque pour stacker. A l'usage on s'est vite rendu compte de la lenteur de celui-ci.
