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 ?
"Aigle bavard" a écrit dans le message de news:45f65393$0$21144$
Non, c'est de la compression NTFS et ça n'est toujours pas nuisible :-)
Nuisible non, mais je suppose que ça doit quand même ralentir puisqu'il y a logiquement décompression préalable lors de l'utilisation du fichier compressé.
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.
(idem pour les opérations de compression et écriture)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Aigle bavard" <ycarl@club.fr> a écrit dans le message de
news:45f65393$0$21144$7a628cd7@news.club-internet.fr...
Non, c'est de la compression NTFS et ça n'est toujours pas nuisible
:-)
Nuisible non, mais je suppose que ça doit quand même ralentir puisqu'il y
a logiquement décompression préalable lors de l'utilisation du fichier
compressé.
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.
(idem pour les opérations de compression et écriture)
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Aigle bavard" a écrit dans le message de news:45f65393$0$21144$
Non, c'est de la compression NTFS et ça n'est toujours pas nuisible :-)
Nuisible non, mais je suppose que ça doit quand même ralentir puisqu'il y a logiquement décompression préalable lors de l'utilisation du fichier compressé.
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.
(idem pour les opérations de compression et écriture)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Aigle bavard
"Aigle bavard" a écrit dans le message de news:45f65393$0$21144$
Non, c'est de la compression NTFS et ça n'est toujours pas nuisible :-)
Nuisible non, mais je suppose que ça doit quand même ralentir puisqu'il y a logiquement décompression préalable lors de l'utilisation du fichier compressé.
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.
(idem pour les opérations de compression et écriture)
Salut l'Expert !
Tu veux dire que le fichier passe une seule fois par le processeur, sous sa forme compressée ? Mais heu... la décompression, elle passe aussi par le processeur, il me semble. Il y a donc une lecture compressée (donc rapide), un traitement (donc plus long) et une dernière lecture à vitesse normale pour servir le fichier exploitable à l'application correspondante.
Ou bien je me gourre dans ma logique ?
Aigle bavard
"Aigle bavard" <ycarl@club.fr> a écrit dans le message de
news:45f65393$0$21144$7a628cd7@news.club-internet.fr...
Non, c'est de la compression NTFS et ça n'est toujours pas nuisible
:-)
Nuisible non, mais je suppose que ça doit quand même ralentir
puisqu'il y a logiquement décompression préalable lors de
l'utilisation du fichier compressé.
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.
(idem pour les opérations de compression et écriture)
Salut l'Expert !
Tu veux dire que le fichier passe une seule fois par le processeur, sous
sa forme compressée ?
Mais heu... la décompression, elle passe aussi par le processeur, il me
semble.
Il y a donc une lecture compressée (donc rapide), un traitement (donc
plus long) et une dernière lecture à vitesse normale pour servir le
fichier exploitable à l'application correspondante.
"Aigle bavard" a écrit dans le message de news:45f65393$0$21144$
Non, c'est de la compression NTFS et ça n'est toujours pas nuisible :-)
Nuisible non, mais je suppose que ça doit quand même ralentir puisqu'il y a logiquement décompression préalable lors de l'utilisation du fichier compressé.
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.
(idem pour les opérations de compression et écriture)
Salut l'Expert !
Tu veux dire que le fichier passe une seule fois par le processeur, sous sa forme compressée ? Mais heu... la décompression, elle passe aussi par le processeur, il me semble. Il y a donc une lecture compressée (donc rapide), un traitement (donc plus long) et une dernière lecture à vitesse normale pour servir le fichier exploitable à l'application correspondante.
Ou bien je me gourre dans ma logique ?
Aigle bavard
Nina Popravka
On Tue, 13 Mar 2007 09:17:29 +0100, Aigle bavard wrote:
Ou bien je me gourre dans ma logique ?
Oui, ça décompresse à la volée, on te dit. C'est-à-dire au fur et à mesure de la lecture et l'écriture. C'est pas WinZip !!! -- Nina
On Tue, 13 Mar 2007 09:17:29 +0100, Aigle bavard <ycarl@club.fr>
wrote:
Ou bien je me gourre dans ma logique ?
Oui, ça décompresse à la volée, on te dit.
C'est-à-dire au fur et à mesure de la lecture et l'écriture.
C'est pas WinZip !!!
--
Nina
On Tue, 13 Mar 2007 09:17:29 +0100, Aigle bavard wrote:
Ou bien je me gourre dans ma logique ?
Oui, ça décompresse à la volée, on te dit. C'est-à-dire au fur et à mesure de la lecture et l'écriture. C'est pas WinZip !!! -- Nina
Aigle bavard
On Tue, 13 Mar 2007 09:17:29 +0100, Aigle bavard wrote:
Ou bien je me gourre dans ma logique ?
Oui, ça décompresse à la volée, on te dit. C'est-à-dire au fur et à mesure de la lecture et l'écriture. C'est pas WinZip !!!
Mais qui décompresse ? C'est bien le processeur, qui obéit à un logiciel (même s'il est intégré au file system, il s'agit quand même bien d'un enchaînement d'instructions qui doivent passer par les registres pour agir).
En somme, la lecture d'un fichier non compressé serait plus longue que la lecture/décompression de ce même fichier compressé ?
Aigle bavard
On Tue, 13 Mar 2007 09:17:29 +0100, Aigle bavard <ycarl@club.fr>
wrote:
Ou bien je me gourre dans ma logique ?
Oui, ça décompresse à la volée, on te dit.
C'est-à-dire au fur et à mesure de la lecture et l'écriture.
C'est pas WinZip !!!
Mais qui décompresse ?
C'est bien le processeur, qui obéit à un logiciel (même s'il est intégré
au file system, il s'agit quand même bien d'un enchaînement
d'instructions qui doivent passer par les registres pour agir).
En somme, la lecture d'un fichier non compressé serait plus longue que
la lecture/décompression de ce même fichier compressé ?
On Tue, 13 Mar 2007 09:17:29 +0100, Aigle bavard wrote:
Ou bien je me gourre dans ma logique ?
Oui, ça décompresse à la volée, on te dit. C'est-à-dire au fur et à mesure de la lecture et l'écriture. C'est pas WinZip !!!
Mais qui décompresse ? C'est bien le processeur, qui obéit à un logiciel (même s'il est intégré au file system, il s'agit quand même bien d'un enchaînement d'instructions qui doivent passer par les registres pour agir).
En somme, la lecture d'un fichier non compressé serait plus longue que la lecture/décompression de ce même fichier compressé ?
Aigle bavard
Nina Popravka
On Tue, 13 Mar 2007 09:41:17 +0100, Aigle bavard wrote:
En somme, la lecture d'un fichier non compressé serait plus longue que la lecture/décompression de ce même fichier compressé ?
Avec un disque lent, un fichier facilement compressible, et un processeur rapide, oui, évidemment. -- Nina
On Tue, 13 Mar 2007 09:41:17 +0100, Aigle bavard <ycarl@club.fr>
wrote:
En somme, la lecture d'un fichier non compressé serait plus longue que
la lecture/décompression de ce même fichier compressé ?
Avec un disque lent, un fichier facilement compressible, et un
processeur rapide, oui, évidemment.
--
Nina
On Tue, 13 Mar 2007 09:41:17 +0100, Aigle bavard wrote:
En somme, la lecture d'un fichier non compressé serait plus longue que la lecture/décompression de ce même fichier compressé ?
Avec un disque lent, un fichier facilement compressible, et un processeur rapide, oui, évidemment. -- Nina
Aigle bavard
On Tue, 13 Mar 2007 09:41:17 +0100, Aigle bavard wrote:
En somme, la lecture d'un fichier non compressé serait plus longue que la lecture/décompression de ce même fichier compressé ?
Avec un disque lent, un fichier facilement compressible, et un processeur rapide, oui, évidemment.
En synthèse et avec les corrections des variations saisonnières, on peut conclure que sur une machine raisonnablement actuelle (et dont les composant présentent une certaine cohérence), l'intérêt de cette compression reste plutôt le gain de place et qu'on ne paye qu'un léger tribut en terme de rapidité ?
Autre point soulevé par JPR : le NTFS gère donc parfaitement ça mais lorsqu'on envoie un disque en récupération de données, est-ce que le procédé est suffisamment universel pour que les prestataires puissent accéder aux datas afin de les décompresser et de les restituer exploitables par un autre OS ?
Aigle bavard
On Tue, 13 Mar 2007 09:41:17 +0100, Aigle bavard <ycarl@club.fr>
wrote:
En somme, la lecture d'un fichier non compressé serait plus longue que
la lecture/décompression de ce même fichier compressé ?
Avec un disque lent, un fichier facilement compressible, et un
processeur rapide, oui, évidemment.
En synthèse et avec les corrections des variations saisonnières, on peut
conclure que sur une machine raisonnablement actuelle (et dont les
composant présentent une certaine cohérence), l'intérêt de cette
compression reste plutôt le gain de place et qu'on ne paye qu'un léger
tribut en terme de rapidité ?
Autre point soulevé par JPR : le NTFS gère donc parfaitement ça mais
lorsqu'on envoie un disque en récupération de données, est-ce que le
procédé est suffisamment universel pour que les prestataires puissent
accéder aux datas afin de les décompresser et de les restituer
exploitables par un autre OS ?
On Tue, 13 Mar 2007 09:41:17 +0100, Aigle bavard wrote:
En somme, la lecture d'un fichier non compressé serait plus longue que la lecture/décompression de ce même fichier compressé ?
Avec un disque lent, un fichier facilement compressible, et un processeur rapide, oui, évidemment.
En synthèse et avec les corrections des variations saisonnières, on peut conclure que sur une machine raisonnablement actuelle (et dont les composant présentent une certaine cohérence), l'intérêt de cette compression reste plutôt le gain de place et qu'on ne paye qu'un léger tribut en terme de rapidité ?
Autre point soulevé par JPR : le NTFS gère donc parfaitement ça mais lorsqu'on envoie un disque en récupération de données, est-ce que le procédé est suffisamment universel pour que les prestataires puissent accéder aux datas afin de les décompresser et de les restituer exploitables par un autre OS ?
Aigle bavard
Jean-Claude BELLAMY
"Aigle bavard" a écrit dans le message de news:45f65e0b$0$21142$
[...] 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.
(idem pour les opérations de compression et écriture)
Tu veux dire que le fichier passe une seule fois par le processeur, sous sa forme compressée ? OUI
Mais heu... la décompression, elle passe aussi par le processeur, il me semble. ???
Quand le fichier "passe" comme tu dis par le processeur, c'est pour y être décompressé. Mais tu ne m'as pas l'air de connaitre les processus exacts qui se produisent dans la réalité!
Il y a donc une lecture compressée (donc rapide), un traitement (donc plus long) OUI
et une dernière lecture à vitesse normale pour servir le fichier exploitable à l'application correspondante. ?????????????
Ou bien je me gourre dans ma logique ? Oui, dans la dernière phase .
La lecture du fichier compressé le stocke quelque part en RAM, dans une zone de cache éventuellement. Ensuite l'algorithme de décompression balaye toute cette zone de DONNÉES (en RAM), pour produire le contenu décompressé du fichier mais toujours en RAM ! Donc l'application finale qui a besoin de LIRE le fichier (décompressé, bien sur) le fait en RAM, et non pas sur disque !
Je vais prendre une exemple fictif, avec des valeurs nasométriques (pour fixer les idées) Soit un fichier de 10 Mo au départ On suppose que le taux de transfert Disque->Mémoire est de 50 Mo/s (je tiens du compte du débit de DMA, mais aussi des temps d'accès) Par ailleurs, le cycle moyen du processeur est de 10^-9 s (1 ns) (encore une fois, je précise que ce n'est qu'un ordre de grandeur !) Et on suppose qu'il faut environ, en moyenne, : - 50 opérations par octet "compressé" lors de la décompression (là aussi c'est un ordre de grandeur, vu que les algorithmes de compression/décompression "globalisent" plusieurs octets à la fois) - 10 opérations par octet lors de la lecture finale du fichier (stocké en RAM)
On prend un taux de compression moyen de 40 %
1) Version sans compression Il faut donc 0,5 s pour transférer le fichier en RAM Auquel on ajoute - 10^7 x 10 x 10^-9 de lecture (10 Mo , 10 fois 1 ns par octet) soit 0,1 s Total : 0,6 s
2) Version avec compression Il faut donc 0,2 s pour transférer le fichier en RAM (avec un taux de compression de 40%) Auquel on ajoute - 4 x10^6 x 50 x 10^-9 de décompression soit 0,2 s - 10^7 x 10 x 10^-9 de lecture soit 0,1 s (identique au cas précédent) Total : 0,5 s
NB : Je n'ai pas cherché à truander les nombres ! :-) J'ai voulu montrer que la compression n'était pas pénalisante en temps global. (ne pas se polariser, dans mon exemple, sur le fait que j'obtiens un temps global inférieur dans le cas de la compression)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Aigle bavard" <ycarl@club.fr> a écrit dans le message de
news:45f65e0b$0$21142$7a628cd7@news.club-internet.fr...
[...]
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.
(idem pour les opérations de compression et écriture)
Tu veux dire que le fichier passe une seule fois par le processeur, sous
sa forme compressée ?
OUI
Mais heu... la décompression, elle passe aussi par le processeur, il me
semble.
???
Quand le fichier "passe" comme tu dis par le processeur, c'est pour y être
décompressé.
Mais tu ne m'as pas l'air de connaitre les processus exacts qui se
produisent dans la réalité!
Il y a donc une lecture compressée (donc rapide), un traitement (donc plus
long)
OUI
et une dernière lecture à vitesse normale pour servir le fichier
exploitable à l'application correspondante.
?????????????
Ou bien je me gourre dans ma logique ?
Oui, dans la dernière phase .
La lecture du fichier compressé le stocke quelque part en RAM, dans une zone
de cache éventuellement.
Ensuite l'algorithme de décompression balaye toute cette zone de DONNÉES
(en RAM), pour produire le contenu décompressé du fichier mais toujours en
RAM ! Donc l'application finale qui a besoin de LIRE le fichier
(décompressé, bien sur) le fait en RAM, et non pas sur disque !
Je vais prendre une exemple fictif, avec des valeurs nasométriques (pour
fixer les idées)
Soit un fichier de 10 Mo au départ
On suppose que le taux de transfert Disque->Mémoire est de 50 Mo/s
(je tiens du compte du débit de DMA, mais aussi des temps d'accès)
Par ailleurs, le cycle moyen du processeur est de 10^-9 s (1 ns)
(encore une fois, je précise que ce n'est qu'un ordre de grandeur !)
Et on suppose qu'il faut environ, en moyenne, :
- 50 opérations par octet "compressé" lors de la décompression
(là aussi c'est un ordre de grandeur, vu que les algorithmes de
compression/décompression "globalisent" plusieurs octets
à la fois)
- 10 opérations par octet lors de la lecture finale du fichier
(stocké en RAM)
On prend un taux de compression moyen de 40 %
1) Version sans compression
Il faut donc 0,5 s pour transférer le fichier en RAM
Auquel on ajoute
- 10^7 x 10 x 10^-9 de lecture
(10 Mo , 10 fois 1 ns par octet)
soit 0,1 s
Total : 0,6 s
2) Version avec compression
Il faut donc 0,2 s pour transférer le fichier en RAM
(avec un taux de compression de 40%)
Auquel on ajoute
- 4 x10^6 x 50 x 10^-9 de décompression
soit 0,2 s
- 10^7 x 10 x 10^-9 de lecture
soit 0,1 s (identique au cas précédent)
Total : 0,5 s
NB : Je n'ai pas cherché à truander les nombres ! :-)
J'ai voulu montrer que la compression n'était pas pénalisante en temps
global.
(ne pas se polariser, dans mon exemple, sur le fait que j'obtiens un temps
global inférieur dans le cas de la compression)
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Aigle bavard" a écrit dans le message de news:45f65e0b$0$21142$
[...] 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.
(idem pour les opérations de compression et écriture)
Tu veux dire que le fichier passe une seule fois par le processeur, sous sa forme compressée ? OUI
Mais heu... la décompression, elle passe aussi par le processeur, il me semble. ???
Quand le fichier "passe" comme tu dis par le processeur, c'est pour y être décompressé. Mais tu ne m'as pas l'air de connaitre les processus exacts qui se produisent dans la réalité!
Il y a donc une lecture compressée (donc rapide), un traitement (donc plus long) OUI
et une dernière lecture à vitesse normale pour servir le fichier exploitable à l'application correspondante. ?????????????
Ou bien je me gourre dans ma logique ? Oui, dans la dernière phase .
La lecture du fichier compressé le stocke quelque part en RAM, dans une zone de cache éventuellement. Ensuite l'algorithme de décompression balaye toute cette zone de DONNÉES (en RAM), pour produire le contenu décompressé du fichier mais toujours en RAM ! Donc l'application finale qui a besoin de LIRE le fichier (décompressé, bien sur) le fait en RAM, et non pas sur disque !
Je vais prendre une exemple fictif, avec des valeurs nasométriques (pour fixer les idées) Soit un fichier de 10 Mo au départ On suppose que le taux de transfert Disque->Mémoire est de 50 Mo/s (je tiens du compte du débit de DMA, mais aussi des temps d'accès) Par ailleurs, le cycle moyen du processeur est de 10^-9 s (1 ns) (encore une fois, je précise que ce n'est qu'un ordre de grandeur !) Et on suppose qu'il faut environ, en moyenne, : - 50 opérations par octet "compressé" lors de la décompression (là aussi c'est un ordre de grandeur, vu que les algorithmes de compression/décompression "globalisent" plusieurs octets à la fois) - 10 opérations par octet lors de la lecture finale du fichier (stocké en RAM)
On prend un taux de compression moyen de 40 %
1) Version sans compression Il faut donc 0,5 s pour transférer le fichier en RAM Auquel on ajoute - 10^7 x 10 x 10^-9 de lecture (10 Mo , 10 fois 1 ns par octet) soit 0,1 s Total : 0,6 s
2) Version avec compression Il faut donc 0,2 s pour transférer le fichier en RAM (avec un taux de compression de 40%) Auquel on ajoute - 4 x10^6 x 50 x 10^-9 de décompression soit 0,2 s - 10^7 x 10 x 10^-9 de lecture soit 0,1 s (identique au cas précédent) Total : 0,5 s
NB : Je n'ai pas cherché à truander les nombres ! :-) J'ai voulu montrer que la compression n'était pas pénalisante en temps global. (ne pas se polariser, dans mon exemple, sur le fait que j'obtiens un temps global inférieur dans le cas de la compression)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Aigle bavard
La lecture du fichier compressé le stocke quelque part en RAM, dans une zone de cache éventuellement. Ensuite l'algorithme de décompression balaye toute cette zone de DONNÉES (en RAM), pour produire le contenu décompressé du fichier mais toujours en RAM ! Donc l'application finale qui a besoin de LIRE le fichier (décompressé, bien sur) le fait en RAM, et non pas sur disque !
Quelle est cette application qui est capable de travailler en RAM sans passer par le processeur ? Je pense qu'il faut un logiciel qui prend les datas compressées en RAM, les travaille dans le processeur (je ne vois pas comment on peut transformer des datas sans processeur) et les repose en RAM. Mais le proc a bien été sollicité.
Sinon, les ordres du logiciel de décompression, qui les interprète ? Est-ce que de la RAM est capable de réaliser une instruction ?
Aigle bavard
La lecture du fichier compressé le stocke quelque part en RAM, dans une
zone de cache éventuellement.
Ensuite l'algorithme de décompression balaye toute cette zone de
DONNÉES (en RAM), pour produire le contenu décompressé du fichier mais
toujours en RAM ! Donc l'application finale qui a besoin de LIRE le
fichier (décompressé, bien sur) le fait en RAM, et non pas sur disque !
Quelle est cette application qui est capable de travailler en RAM sans
passer par le processeur ? Je pense qu'il faut un logiciel qui prend les
datas compressées en RAM, les travaille dans le processeur (je ne vois
pas comment on peut transformer des datas sans processeur) et les repose
en RAM. Mais le proc a bien été sollicité.
Sinon, les ordres du logiciel de décompression, qui les interprète ?
Est-ce que de la RAM est capable de réaliser une instruction ?
La lecture du fichier compressé le stocke quelque part en RAM, dans une zone de cache éventuellement. Ensuite l'algorithme de décompression balaye toute cette zone de DONNÉES (en RAM), pour produire le contenu décompressé du fichier mais toujours en RAM ! Donc l'application finale qui a besoin de LIRE le fichier (décompressé, bien sur) le fait en RAM, et non pas sur disque !
Quelle est cette application qui est capable de travailler en RAM sans passer par le processeur ? Je pense qu'il faut un logiciel qui prend les datas compressées en RAM, les travaille dans le processeur (je ne vois pas comment on peut transformer des datas sans processeur) et les repose en RAM. Mais le proc a bien été sollicité.
Sinon, les ordres du logiciel de décompression, qui les interprète ? Est-ce que de la RAM est capable de réaliser une instruction ?
Aigle bavard
Nina Popravka
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 ??? -- Nina
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 ???
--
Nina
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 ??? -- Nina
Jean-Claude BELLAMY
"Aigle bavard" a écrit dans le message de news:45f6985b$0$21150$
La lecture du fichier compressé le stocke quelque part en RAM, dans une zone de cache éventuellement. Ensuite l'algorithme de décompression balaye toute cette zone de DONNÉES (en RAM), pour produire le contenu décompressé du fichier mais toujours en RAM ! Donc l'application finale qui a besoin de LIRE le fichier (décompressé, bien sur) le fait en RAM, et non pas sur disque !
Quelle est cette application qui est capable de travailler en RAM sans passer par le processeur ?
?????????????????????????????????????????????????? Où aurais-je écrit une telle absurdité ?
A part ce qui est DMA (accès direct à la mémoire depuis un contrôleur DD), tout passe par le processeur, bien évidemment.
Je pense qu'il faut un logiciel qui prend les datas compressées en RAM, les travaille dans le processeur (je ne vois pas comment on peut transformer des datas sans processeur) évidemment !
et les repose en RAM. Mais le proc a bien été sollicité. Mais qui a dit le contraire ?
Sinon, les ordres du logiciel de décompression, qui les interprète ? Est-ce que de la RAM est capable de réaliser une instruction ? la RAM, elle ne fait rien !
On (= le processeur ou éventuellement le DMA) vient la lire ou l'écrire
Tu devrais bien te replonger dans la structure d'un processeur, fonctionnement des registres, compteur ordinal, unité logique et arithmétique, ..., car j'ai la forte impression que c'est flou dans ton esprit ! P.ex. : http://fr.wikipedia.org/wiki/Processeur
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Aigle bavard" <ycarl@club.fr> a écrit dans le message de
news:45f6985b$0$21150$7a628cd7@news.club-internet.fr...
La lecture du fichier compressé le stocke quelque part en RAM, dans une
zone de cache éventuellement.
Ensuite l'algorithme de décompression balaye toute cette zone de DONNÉES
(en RAM), pour produire le contenu décompressé du fichier mais toujours
en RAM ! Donc l'application finale qui a besoin de LIRE le fichier
(décompressé, bien sur) le fait en RAM, et non pas sur disque !
Quelle est cette application qui est capable de travailler en RAM sans
passer par le processeur ?
??????????????????????????????????????????????????
Où aurais-je écrit une telle absurdité ?
A part ce qui est DMA (accès direct à la mémoire depuis un contrôleur DD),
tout passe par le processeur, bien évidemment.
Je pense qu'il faut un logiciel qui prend les datas compressées en RAM,
les travaille dans le processeur (je ne vois pas comment on peut
transformer des datas sans processeur)
évidemment !
et les repose en RAM. Mais le proc a bien été sollicité.
Mais qui a dit le contraire ?
Sinon, les ordres du logiciel de décompression, qui les interprète ?
Est-ce que de la RAM est capable de réaliser une instruction ?
la RAM, elle ne fait rien !
On (= le processeur ou éventuellement le DMA) vient la lire ou l'écrire
Tu devrais bien te replonger dans la structure d'un processeur,
fonctionnement des registres, compteur ordinal, unité logique et
arithmétique, ..., car j'ai la forte impression que c'est flou dans ton
esprit !
P.ex. :
http://fr.wikipedia.org/wiki/Processeur
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Aigle bavard" a écrit dans le message de news:45f6985b$0$21150$
La lecture du fichier compressé le stocke quelque part en RAM, dans une zone de cache éventuellement. Ensuite l'algorithme de décompression balaye toute cette zone de DONNÉES (en RAM), pour produire le contenu décompressé du fichier mais toujours en RAM ! Donc l'application finale qui a besoin de LIRE le fichier (décompressé, bien sur) le fait en RAM, et non pas sur disque !
Quelle est cette application qui est capable de travailler en RAM sans passer par le processeur ?
?????????????????????????????????????????????????? Où aurais-je écrit une telle absurdité ?
A part ce qui est DMA (accès direct à la mémoire depuis un contrôleur DD), tout passe par le processeur, bien évidemment.
Je pense qu'il faut un logiciel qui prend les datas compressées en RAM, les travaille dans le processeur (je ne vois pas comment on peut transformer des datas sans processeur) évidemment !
et les repose en RAM. Mais le proc a bien été sollicité. Mais qui a dit le contraire ?
Sinon, les ordres du logiciel de décompression, qui les interprète ? Est-ce que de la RAM est capable de réaliser une instruction ? la RAM, elle ne fait rien !
On (= le processeur ou éventuellement le DMA) vient la lire ou l'écrire
Tu devrais bien te replonger dans la structure d'un processeur, fonctionnement des registres, compteur ordinal, unité logique et arithmétique, ..., car j'ai la forte impression que c'est flou dans ton esprit ! P.ex. : http://fr.wikipedia.org/wiki/Processeur
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
