A moins que ces 159 Mo de swap correspondant en majorité à des processus "dormants" (présents en mémoire mais inactifs).
Ça peut aussi être un gros tmpfs.
C'est vrai, je n'y pense jamais. Mon seul tmpfs est /dev/shm, et apparemment il est toujours vide.
Par exemple ici, j'ai presque 800 Mo de swap utilisés, mais presque 900 Mo dans /tmp (principalement des arbres de compilation de ffmpeg) qui est en tmpfs.
Ça reste rentable d'avoir /tmp en tmpfs dans ces conditions ? Je suppose que le noyau swappera plus volontiers un tmpfs qu'un processus ?
Pascal Hambourg wrote in message <ff4nnk$2sf2$1@biggoron.nerim.net>:
A moins que ces 159 Mo de swap
correspondant en majorité à des processus "dormants" (présents en
mémoire mais inactifs).
Ça peut aussi être un gros tmpfs.
C'est vrai, je n'y pense jamais. Mon seul tmpfs est /dev/shm, et
apparemment il est toujours vide.
Par exemple ici, j'ai presque 800 Mo de
swap utilisés, mais presque 900 Mo dans /tmp (principalement des arbres de
compilation de ffmpeg) qui est en tmpfs.
Ça reste rentable d'avoir /tmp en tmpfs dans ces conditions ?
Je suppose que le noyau swappera plus volontiers un tmpfs qu'un processus ?
A moins que ces 159 Mo de swap correspondant en majorité à des processus "dormants" (présents en mémoire mais inactifs).
Ça peut aussi être un gros tmpfs.
C'est vrai, je n'y pense jamais. Mon seul tmpfs est /dev/shm, et apparemment il est toujours vide.
Par exemple ici, j'ai presque 800 Mo de swap utilisés, mais presque 900 Mo dans /tmp (principalement des arbres de compilation de ffmpeg) qui est en tmpfs.
Ça reste rentable d'avoir /tmp en tmpfs dans ces conditions ? Je suppose que le noyau swappera plus volontiers un tmpfs qu'un processus ?
Nicolas George
Pascal Hambourg wrote in message <ff4s7c$25n$:
C'est vrai, je n'y pense jamais. Mon seul tmpfs est /dev/shm, et apparemment il est toujours vide.
qemu s'en sert, il me semble.
Ça reste rentable d'avoir /tmp en tmpfs dans ces conditions ?
Clairement oui : le noyau ne se sent alors pas obligé d'écrire sur disque les le produit de la compilation dans les 30 secondes qui suivent leur production.
Je suppose que le noyau swappera plus volontiers un tmpfs qu'un processus ?
J'ai bien l'impression.
Pascal Hambourg wrote in message <ff4s7c$25n$1@biggoron.nerim.net>:
C'est vrai, je n'y pense jamais. Mon seul tmpfs est /dev/shm, et
apparemment il est toujours vide.
qemu s'en sert, il me semble.
Ça reste rentable d'avoir /tmp en tmpfs dans ces conditions ?
Clairement oui : le noyau ne se sent alors pas obligé d'écrire sur disque
les le produit de la compilation dans les 30 secondes qui suivent leur
production.
Je suppose que le noyau swappera plus volontiers un tmpfs qu'un processus ?
C'est vrai, je n'y pense jamais. Mon seul tmpfs est /dev/shm, et apparemment il est toujours vide.
qemu s'en sert, il me semble.
Ça reste rentable d'avoir /tmp en tmpfs dans ces conditions ?
Clairement oui : le noyau ne se sent alors pas obligé d'écrire sur disque les le produit de la compilation dans les 30 secondes qui suivent leur production.
Je suppose que le noyau swappera plus volontiers un tmpfs qu'un processus ?
J'ai bien l'impression.
Frederic Bezies
Actuellement, avec une compilation de Minefield en cours et une ubuntu gutsy x86_64 dans un vmware server (512 Mo partagés) :
c++ devant manger dans les 50 Mo pour les fichiers en cours de compilation.
On voit que 159 Mo de swap sont occupés, ce qui n'est pas négligeable par rapport aux 402 Mo occupés par le noyau et les processus, alors que ~1 Go est alloué au cache disque. Si j'interprète correctement ces données, cela signifie que l'activité des systèmes de fichiers est si intensive que le noyau juge plus efficace de swapper des applications pour agrandir le cache disque. A moins que ces 159 Mo de swap correspondant en majorité à des processus "dormants" (présents en mémoire mais inactifs).
En effet. Compiler une version de développement de Minefield (250 Mo de sources environ) prend 45 minutes de compilation intense. Sans oublier une machine virtuelle qui prend aussi sa portion de calcul.
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers), il est normal que l'activité disque soit intensive, non ? ;)
En tout cas, le noyau jongle parfaitement avec, c'est assez jouissif, non ? ;)
c++ devant manger dans les 50 Mo pour les fichiers en cours de
compilation.
On voit que 159 Mo de swap sont occupés, ce qui n'est pas négligeable
par rapport aux 402 Mo occupés par le noyau et les processus, alors que
~1 Go est alloué au cache disque. Si j'interprète correctement ces
données, cela signifie que l'activité des systèmes de fichiers est si
intensive que le noyau juge plus efficace de swapper des applications
pour agrandir le cache disque. A moins que ces 159 Mo de swap
correspondant en majorité à des processus "dormants" (présents en
mémoire mais inactifs).
En effet. Compiler une version de développement de Minefield (250 Mo de
sources environ) prend 45 minutes de compilation intense. Sans oublier
une machine virtuelle qui prend aussi sa portion de calcul.
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers),
il est normal que l'activité disque soit intensive, non ? ;)
En tout cas, le noyau jongle parfaitement avec, c'est assez jouissif,
non ? ;)
c++ devant manger dans les 50 Mo pour les fichiers en cours de compilation.
On voit que 159 Mo de swap sont occupés, ce qui n'est pas négligeable par rapport aux 402 Mo occupés par le noyau et les processus, alors que ~1 Go est alloué au cache disque. Si j'interprète correctement ces données, cela signifie que l'activité des systèmes de fichiers est si intensive que le noyau juge plus efficace de swapper des applications pour agrandir le cache disque. A moins que ces 159 Mo de swap correspondant en majorité à des processus "dormants" (présents en mémoire mais inactifs).
En effet. Compiler une version de développement de Minefield (250 Mo de sources environ) prend 45 minutes de compilation intense. Sans oublier une machine virtuelle qui prend aussi sa portion de calcul.
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers), il est normal que l'activité disque soit intensive, non ? ;)
En tout cas, le noyau jongle parfaitement avec, c'est assez jouissif, non ? ;)
On voit que 159 Mo de swap sont occupés, ce qui n'est pas négligeable par rapport aux 402 Mo occupés par le noyau et les processus, alors que ~1 Go est alloué au cache disque. Si j'interprète correctement ces données, cela signifie que l'activité des systèmes de fichiers est si intensive que le noyau juge plus efficace de swapper des applications pour agrandir le cache disque.
En effet. Compiler une version de développement de Minefield (250 Mo de sources environ) prend 45 minutes de compilation intense. Sans oublier une machine virtuelle qui prend aussi sa portion de calcul.
Mais là je ne parle que d'occupation mémoire, pas du CPU.
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers), il est normal que l'activité disque soit intensive, non ? ;)
Oui, mais ce n'est pas forcément suffisant pour faire grossir le cache disque au point de swapper une part importante de la mémoire occupée par le noyau et les processus. Pour arriver à ce résultat l'activité du cache disque doit être de nature à créer une forte pression sur la mémoire. Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache. Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
En tout cas, au vu de ces résultats je ne suis pas étonné que l'ajout de mémoire ait amélioré les performances de ta machine.
En tout cas, le noyau jongle parfaitement avec, c'est assez jouissif, non ? ;)
Encore heureux, parce que ce n'est pas l'utilisateur qui va s'en charger tout seul !
On voit que 159 Mo de swap sont occupés, ce qui n'est pas négligeable
par rapport aux 402 Mo occupés par le noyau et les processus, alors
que ~1 Go est alloué au cache disque. Si j'interprète correctement ces
données, cela signifie que l'activité des systèmes de fichiers est si
intensive que le noyau juge plus efficace de swapper des applications
pour agrandir le cache disque.
En effet. Compiler une version de développement de Minefield (250 Mo de
sources environ) prend 45 minutes de compilation intense. Sans oublier
une machine virtuelle qui prend aussi sa portion de calcul.
Mais là je ne parle que d'occupation mémoire, pas du CPU.
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers),
il est normal que l'activité disque soit intensive, non ? ;)
Oui, mais ce n'est pas forcément suffisant pour faire grossir le cache
disque au point de swapper une part importante de la mémoire occupée par
le noyau et les processus. Pour arriver à ce résultat l'activité du
cache disque doit être de nature à créer une forte pression sur la
mémoire. Or il me semble qu'un fichier source n'est lu qu'une seule fois
par compilation, il n'est donc pas forcément utile de le garder en
cache. Par contre si la compilation produit un gros volume de fichiers
temporaires qui vont être modifiés et relus plusieurs fois par
compilation, cela peut le faire.
En tout cas, au vu de ces résultats je ne suis pas étonné que l'ajout de
mémoire ait amélioré les performances de ta machine.
En tout cas, le noyau jongle parfaitement avec, c'est assez jouissif,
non ? ;)
Encore heureux, parce que ce n'est pas l'utilisateur qui va s'en charger
tout seul !
On voit que 159 Mo de swap sont occupés, ce qui n'est pas négligeable par rapport aux 402 Mo occupés par le noyau et les processus, alors que ~1 Go est alloué au cache disque. Si j'interprète correctement ces données, cela signifie que l'activité des systèmes de fichiers est si intensive que le noyau juge plus efficace de swapper des applications pour agrandir le cache disque.
En effet. Compiler une version de développement de Minefield (250 Mo de sources environ) prend 45 minutes de compilation intense. Sans oublier une machine virtuelle qui prend aussi sa portion de calcul.
Mais là je ne parle que d'occupation mémoire, pas du CPU.
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers), il est normal que l'activité disque soit intensive, non ? ;)
Oui, mais ce n'est pas forcément suffisant pour faire grossir le cache disque au point de swapper une part importante de la mémoire occupée par le noyau et les processus. Pour arriver à ce résultat l'activité du cache disque doit être de nature à créer une forte pression sur la mémoire. Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache. Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
En tout cas, au vu de ces résultats je ne suis pas étonné que l'ajout de mémoire ait amélioré les performances de ta machine.
En tout cas, le noyau jongle parfaitement avec, c'est assez jouissif, non ? ;)
Encore heureux, parce que ce n'est pas l'utilisateur qui va s'en charger tout seul !
Frederic Bezies
[...]
En effet. Compiler une version de développement de Minefield (250 Mo de sources environ) prend 45 minutes de compilation intense. Sans oublier une machine virtuelle qui prend aussi sa portion de calcul.
Mais là je ne parle que d'occupation mémoire, pas du CPU.
Quoique le CPU gère les ordres pour la mémoire, non ? ;)
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers), il est normal que l'activité disque soit intensive, non ? ;)
Oui, mais ce n'est pas forcément suffisant pour faire grossir le cache disque au point de swapper une part importante de la mémoire occupée par le noyau et les processus. Pour arriver à ce résultat l'activité du cache disque doit être de nature à créer une forte pression sur la mémoire. Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache. Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
C'est le cas avec des codes sources comme celui de mozilla firefox... Et il faut dire qu'avec une machine virtuelle en plus, c'est un peu excessif ;)
En tout cas, au vu de ces résultats je ne suis pas étonné que l'ajout de mémoire ait amélioré les performances de ta machine.
Non ? ;)
En tout cas, le noyau jongle parfaitement avec, c'est assez jouissif, non ? ;)
Encore heureux, parce que ce n'est pas l'utilisateur qui va s'en charger tout seul !
En effet. Compiler une version de développement de Minefield (250 Mo
de sources environ) prend 45 minutes de compilation intense. Sans
oublier une machine virtuelle qui prend aussi sa portion de calcul.
Mais là je ne parle que d'occupation mémoire, pas du CPU.
Quoique le CPU gère les ordres pour la mémoire, non ? ;)
Avec près de 250 Mo de fichiers dans le code (environ 55 000
fichiers), il est normal que l'activité disque soit intensive, non ? ;)
Oui, mais ce n'est pas forcément suffisant pour faire grossir le cache
disque au point de swapper une part importante de la mémoire occupée par
le noyau et les processus. Pour arriver à ce résultat l'activité du
cache disque doit être de nature à créer une forte pression sur la
mémoire. Or il me semble qu'un fichier source n'est lu qu'une seule fois
par compilation, il n'est donc pas forcément utile de le garder en
cache. Par contre si la compilation produit un gros volume de fichiers
temporaires qui vont être modifiés et relus plusieurs fois par
compilation, cela peut le faire.
C'est le cas avec des codes sources comme celui de mozilla firefox... Et
il faut dire qu'avec une machine virtuelle en plus, c'est un peu excessif ;)
En tout cas, au vu de ces résultats je ne suis pas étonné que l'ajout de
mémoire ait amélioré les performances de ta machine.
Non ? ;)
En tout cas, le noyau jongle parfaitement avec, c'est assez jouissif,
non ? ;)
Encore heureux, parce que ce n'est pas l'utilisateur qui va s'en charger
tout seul !
En effet. Compiler une version de développement de Minefield (250 Mo de sources environ) prend 45 minutes de compilation intense. Sans oublier une machine virtuelle qui prend aussi sa portion de calcul.
Mais là je ne parle que d'occupation mémoire, pas du CPU.
Quoique le CPU gère les ordres pour la mémoire, non ? ;)
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers), il est normal que l'activité disque soit intensive, non ? ;)
Oui, mais ce n'est pas forcément suffisant pour faire grossir le cache disque au point de swapper une part importante de la mémoire occupée par le noyau et les processus. Pour arriver à ce résultat l'activité du cache disque doit être de nature à créer une forte pression sur la mémoire. Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache. Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
C'est le cas avec des codes sources comme celui de mozilla firefox... Et il faut dire qu'avec une machine virtuelle en plus, c'est un peu excessif ;)
En tout cas, au vu de ces résultats je ne suis pas étonné que l'ajout de mémoire ait amélioré les performances de ta machine.
Non ? ;)
En tout cas, le noyau jongle parfaitement avec, c'est assez jouissif, non ? ;)
Encore heureux, parce que ce n'est pas l'utilisateur qui va s'en charger tout seul !
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers), il est normal que l'activité disque soit intensive, non ? ;)
Oui, mais ce n'est pas forcément suffisant pour faire grossir le cache disque au point de swapper une part importante de la mémoire occupée par le noyau et les processus. Pour arriver à ce résultat l'activité du cache disque doit être de nature à créer une forte pression sur la mémoire. Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache.
GNU ld essaye de regrouper les constantes identiques. C'était (et c'est peut-être encore) le comportement par défaut. C'est indolore pour les petits binaires mais pas pour les gros. Je me rappelle de temps de link de l'ordre de 10 minutes.
Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
Que je sache, GCC utilise des pipes par défaut sous Linux.
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) There is always someone somewhere who needs a good laugh.
On 2007-10-17, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Avec près de 250 Mo de fichiers dans le code (environ 55 000
fichiers), il est normal que l'activité disque soit
intensive, non ? ;)
Oui, mais ce n'est pas forcément suffisant pour faire grossir
le cache disque au point de swapper une part importante de la
mémoire occupée par le noyau et les processus. Pour arriver à
ce résultat l'activité du cache disque doit être de nature à
créer une forte pression sur la mémoire. Or il me semble qu'un
fichier source n'est lu qu'une seule fois par compilation, il
n'est donc pas forcément utile de le garder en cache.
GNU ld essaye de regrouper les constantes identiques. C'était
(et c'est peut-être encore) le comportement par défaut. C'est
indolore pour les petits binaires mais pas pour les gros. Je me
rappelle de temps de link de l'ordre de 10 minutes.
Par contre si la compilation produit un gros volume de
fichiers temporaires qui vont être modifiés et relus plusieurs
fois par compilation, cela peut le faire.
Que je sache, GCC utilise des pipes par défaut sous Linux.
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: mikeb@blindfold.com zon@prior.com)
There is always someone somewhere who needs a good laugh.
Avec près de 250 Mo de fichiers dans le code (environ 55 000 fichiers), il est normal que l'activité disque soit intensive, non ? ;)
Oui, mais ce n'est pas forcément suffisant pour faire grossir le cache disque au point de swapper une part importante de la mémoire occupée par le noyau et les processus. Pour arriver à ce résultat l'activité du cache disque doit être de nature à créer une forte pression sur la mémoire. Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache.
GNU ld essaye de regrouper les constantes identiques. C'était (et c'est peut-être encore) le comportement par défaut. C'est indolore pour les petits binaires mais pas pour les gros. Je me rappelle de temps de link de l'ordre de 10 minutes.
Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
Que je sache, GCC utilise des pipes par défaut sous Linux.
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) There is always someone somewhere who needs a good laugh.
Pascal Hambourg
On 2007-10-17, Pascal Hambourg wrote:
Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache.
GNU ld essaye de regrouper les constantes identiques. C'était (et c'est peut-être encore) le comportement par défaut. C'est indolore pour les petits binaires mais pas pour les gros. Je me rappelle de temps de link de l'ordre de 10 minutes.
Tu veux dire les constantes chaînes, tableaux, structures... bref les gros trucs ? Parce que chercher à regrouper des constantes de type entier qui vont se retrouver en adressage immédiat dans les instructions, ça ne doit pas être très intéressant. Je suis loin d'être spécialiste des outils de compilation mais il me semble qu'un éditeur de liens travaille sur les fichiers objets générés par le compilateur à partir des fichiers sources, et non sur les fichiers sources eux-mêmes.
Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
Que je sache, GCC utilise des pipes par défaut sous Linux.
Ah... peut-être, si tu le dis. :-D Pour quoi faire au juste ?
On 2007-10-17, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Or il me semble qu'un
fichier source n'est lu qu'une seule fois par compilation, il
n'est donc pas forcément utile de le garder en cache.
GNU ld essaye de regrouper les constantes identiques. C'était
(et c'est peut-être encore) le comportement par défaut. C'est
indolore pour les petits binaires mais pas pour les gros. Je me
rappelle de temps de link de l'ordre de 10 minutes.
Tu veux dire les constantes chaînes, tableaux, structures... bref les
gros trucs ? Parce que chercher à regrouper des constantes de type
entier qui vont se retrouver en adressage immédiat dans les
instructions, ça ne doit pas être très intéressant.
Je suis loin d'être spécialiste des outils de compilation mais il me
semble qu'un éditeur de liens travaille sur les fichiers objets générés
par le compilateur à partir des fichiers sources, et non sur les
fichiers sources eux-mêmes.
Par contre si la compilation produit un gros volume de
fichiers temporaires qui vont être modifiés et relus plusieurs
fois par compilation, cela peut le faire.
Que je sache, GCC utilise des pipes par défaut sous Linux.
Ah... peut-être, si tu le dis. :-D Pour quoi faire au juste ?
Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache.
GNU ld essaye de regrouper les constantes identiques. C'était (et c'est peut-être encore) le comportement par défaut. C'est indolore pour les petits binaires mais pas pour les gros. Je me rappelle de temps de link de l'ordre de 10 minutes.
Tu veux dire les constantes chaînes, tableaux, structures... bref les gros trucs ? Parce que chercher à regrouper des constantes de type entier qui vont se retrouver en adressage immédiat dans les instructions, ça ne doit pas être très intéressant. Je suis loin d'être spécialiste des outils de compilation mais il me semble qu'un éditeur de liens travaille sur les fichiers objets générés par le compilateur à partir des fichiers sources, et non sur les fichiers sources eux-mêmes.
Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
Que je sache, GCC utilise des pipes par défaut sous Linux.
Ah... peut-être, si tu le dis. :-D Pour quoi faire au juste ?
Andre Majorel
On 2007-10-18, Pascal Hambourg wrote:
On 2007-10-17, Pascal Hambourg wrote:
Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache.
GNU ld essaye de regrouper les constantes identiques. C'était (et c'est peut-être encore) le comportement par défaut. C'est indolore pour les petits binaires mais pas pour les gros. Je me rappelle de temps de link de l'ordre de 10 minutes.
Tu veux dire les constantes chaînes, tableaux, structures... bref les gros trucs ?
Oui. Tout ce qui va dans la section .rodata.
Parce que chercher à regrouper des constantes de type entier qui vont se retrouver en adressage immédiat dans les instructions, ça ne doit pas être très intéressant.
Ça ferait perdre du temps et de la place.
Je suis loin d'être spécialiste des outils de compilation mais il me semble qu'un éditeur de liens travaille sur les fichiers objets générés par le compilateur à partir des fichiers sources, et non sur les fichiers sources eux-mêmes.
Oui. ld cherche les doublons dans les sections .rodata des fichiers objets.
Le monsieur qui a des problèmes avec son champ de mines pourrait essayer de linker avec -fno-merge-constants.
Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
Que je sache, GCC utilise des pipes par défaut sous Linux.
Ah... peut-être, si tu le dis. :-D Pour quoi faire au juste ?
Pour ne pas créér de fichiers temporaires. :-) Voir -pipe dans gcc(1).
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) There is always someone somewhere who needs a good laugh.
On 2007-10-18, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
On 2007-10-17, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Or il me semble qu'un
fichier source n'est lu qu'une seule fois par compilation, il
n'est donc pas forcément utile de le garder en cache.
GNU ld essaye de regrouper les constantes identiques. C'était
(et c'est peut-être encore) le comportement par défaut. C'est
indolore pour les petits binaires mais pas pour les gros. Je me
rappelle de temps de link de l'ordre de 10 minutes.
Tu veux dire les constantes chaînes, tableaux, structures... bref les
gros trucs ?
Oui. Tout ce qui va dans la section .rodata.
Parce que chercher à regrouper des constantes de type entier
qui vont se retrouver en adressage immédiat dans les
instructions, ça ne doit pas être très intéressant.
Ça ferait perdre du temps et de la place.
Je suis loin d'être spécialiste des outils de compilation mais
il me semble qu'un éditeur de liens travaille sur les fichiers
objets générés par le compilateur à partir des fichiers
sources, et non sur les fichiers sources eux-mêmes.
Oui. ld cherche les doublons dans les sections .rodata des
fichiers objets.
Le monsieur qui a des problèmes avec son champ de mines pourrait
essayer de linker avec -fno-merge-constants.
Par contre si la compilation produit un gros volume de
fichiers temporaires qui vont être modifiés et relus plusieurs
fois par compilation, cela peut le faire.
Que je sache, GCC utilise des pipes par défaut sous Linux.
Ah... peut-être, si tu le dis. :-D Pour quoi faire au juste ?
Pour ne pas créér de fichiers temporaires. :-) Voir -pipe dans
gcc(1).
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: akix@troublesome.com kacofepej@Billmenow.com)
There is always someone somewhere who needs a good laugh.
Or il me semble qu'un fichier source n'est lu qu'une seule fois par compilation, il n'est donc pas forcément utile de le garder en cache.
GNU ld essaye de regrouper les constantes identiques. C'était (et c'est peut-être encore) le comportement par défaut. C'est indolore pour les petits binaires mais pas pour les gros. Je me rappelle de temps de link de l'ordre de 10 minutes.
Tu veux dire les constantes chaînes, tableaux, structures... bref les gros trucs ?
Oui. Tout ce qui va dans la section .rodata.
Parce que chercher à regrouper des constantes de type entier qui vont se retrouver en adressage immédiat dans les instructions, ça ne doit pas être très intéressant.
Ça ferait perdre du temps et de la place.
Je suis loin d'être spécialiste des outils de compilation mais il me semble qu'un éditeur de liens travaille sur les fichiers objets générés par le compilateur à partir des fichiers sources, et non sur les fichiers sources eux-mêmes.
Oui. ld cherche les doublons dans les sections .rodata des fichiers objets.
Le monsieur qui a des problèmes avec son champ de mines pourrait essayer de linker avec -fno-merge-constants.
Par contre si la compilation produit un gros volume de fichiers temporaires qui vont être modifiés et relus plusieurs fois par compilation, cela peut le faire.
Que je sache, GCC utilise des pipes par défaut sous Linux.
Ah... peut-être, si tu le dis. :-D Pour quoi faire au juste ?
Pour ne pas créér de fichiers temporaires. :-) Voir -pipe dans gcc(1).
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) There is always someone somewhere who needs a good laugh.
