Je lis le livre « Modern Operating Systems » de Andrew Tanenbaum, Herbert Bos & Co mais je n’en suis qu’au début. Ce qui me paraît étonnant c’est la corrélation qui est faite entre la consommation mémoire et l’affichage instantané à l’écran.
Lors du cat /tmp/1gib.test, quelque chose a dû vous sauter aux yeux : il n’y a pas d’attente, le fichier vous est affiché immédiatement et progressivement.
[…] (appels systèmes) Ce que nous pouvons en déduire, c’est que la lecture du fichier est progressive et envoyée directement à la sortie.
[…] cat conserve une empreinte mémoire la plus faible possible vu qu’il évite l’accumulation sur la RAM.
L’instantanéité perçue est relative à la « vitesse des opérations ». Sur mon Raspberry Pi l’affichage de la console Linux est très lent lors de la phase d’amorçage ou lors d’une compilation logicielle par rapport à un ordinateur portable avec un processeur puissant (autant de mémoire RAM disponible). Qu’en est-il en remplaçant le HDD (Hard Disk Drive) par un SDD (Solid State Drive) ? La réalité semble plus complexe (éloignée) que l’interprétation éclaire (erronée ?) qui en est faite dans l’article.
Très bon choix de livre, c’est une référence. Effectivement, la vitesse d’affichage est dépendante de ton archi, mais ce n’est pas là qu’est la vraie information de l’article en réalité. Cette phrase n’existe que pour faire un premier constat, constat qui est expliqué par le code. L’affichage est immédiat parce que la conso de RAM est constante (et faible) [EDIT: my bad, cette phrase est fausse. Cf. la suite de la conversation]. Le tout étant la conséquence du streaming de données. Au besoin, tu peux augmenter la taille du fichier pour tester les limites de ton propre système.
Avec ton Raspberry tu observes une latence qui peut être liée à d’autres paramètres dont j’ai pas conscience mais ça ne remet pas en question la logique interne de cat qui ne fait pas un « loadFileInMemory then print ». Ça se teste très facilement avec un trace. Je t’invite à jouer avec la stack de test que j’ai mise en place https://gitlab.com/prytoegrian/blog-codes/-/tree/main/consommation_memoire_cat en limitant la RAM de docker pour valider ton cas limite.
Pour la petite anecdote, je me suis aperçu que l’implémentation de cat sous alpine différait de celle sous debian ; la logique de streaming demeurait. Ça ne me choquerait pas qu’il y ai aussi quelques adaptations pour Raspberry.
Ce qui me bloque c’est que je ne comprends pas l’assertion « L’affichage est immédiat parce que la conso de RAM est constante (et faible) » : si possible, il me faudrait une explication (exposer les choses).
Après relecture, je m’aperçois que mon premier message t’as induit en erreur, la causalité est dans l’autre sens.
Cat est un algo simple : il prend un input et l’affiche dans un output. Pour être performant, il libère la RAM au plus tôt et pour cela, il se débarrasse de ses données ASAP (il les affiche). L’affichage immédiat est donc la cause d’une consommation réduite : le programme en lui-même n’en a plus besoin.
Dans un système à faibles ressources, tu pourrais te retrouver avec une lenteur, mais jamais parce que cat charge la totalité du fichier, juste par spécificités du système.
Je lis le livre « Modern Operating Systems » de Andrew Tanenbaum, Herbert Bos & Co mais je n’en suis qu’au début. Ce qui me paraît étonnant c’est la corrélation qui est faite entre la consommation mémoire et l’affichage instantané à l’écran.
L’instantanéité perçue est relative à la « vitesse des opérations ». Sur mon Raspberry Pi l’affichage de la console Linux est très lent lors de la phase d’amorçage ou lors d’une compilation logicielle par rapport à un ordinateur portable avec un processeur puissant (autant de mémoire RAM disponible). Qu’en est-il en remplaçant le HDD (Hard Disk Drive) par un SDD (Solid State Drive) ? La réalité semble plus complexe (éloignée) que l’interprétation éclaire (erronée ?) qui en est faite dans l’article.
Très bon choix de livre, c’est une référence. Effectivement, la vitesse d’affichage est dépendante de ton archi, mais ce n’est pas là qu’est la vraie information de l’article en réalité. Cette phrase n’existe que pour faire un premier constat, constat qui est expliqué par le code.
L’affichage est immédiat parce que la conso de RAM est constante (et faible)[EDIT: my bad, cette phrase est fausse. Cf. la suite de la conversation]. Le tout étant la conséquence du streaming de données. Au besoin, tu peux augmenter la taille du fichier pour tester les limites de ton propre système.Avec ton Raspberry tu observes une latence qui peut être liée à d’autres paramètres dont j’ai pas conscience mais ça ne remet pas en question la logique interne de cat qui ne fait pas un « loadFileInMemory then print ». Ça se teste très facilement avec un trace. Je t’invite à jouer avec la stack de test que j’ai mise en place https://gitlab.com/prytoegrian/blog-codes/-/tree/main/consommation_memoire_cat en limitant la RAM de docker pour valider ton cas limite.
Pour la petite anecdote, je me suis aperçu que l’implémentation de cat sous alpine différait de celle sous debian ; la logique de streaming demeurait. Ça ne me choquerait pas qu’il y ai aussi quelques adaptations pour Raspberry.
Ce qui me bloque c’est que je ne comprends pas l’assertion « L’affichage est immédiat parce que la conso de RAM est constante (et faible) » : si possible, il me faudrait une explication (exposer les choses).
Après relecture, je m’aperçois que mon premier message t’as induit en erreur, la causalité est dans l’autre sens.
Cat est un algo simple : il prend un input et l’affiche dans un output. Pour être performant, il libère la RAM au plus tôt et pour cela, il se débarrasse de ses données ASAP (il les affiche). L’affichage immédiat est donc la cause d’une consommation réduite : le programme en lui-même n’en a plus besoin.
Dans un système à faibles ressources, tu pourrais te retrouver avec une lenteur, mais jamais parce que cat charge la totalité du fichier, juste par spécificités du système.