# [Compilation] Temps anormalement long.

## Djento

bonsoir,

Voilà je reviens vers Gentoo après la perte de mon portable en Avril dernier, un pentium-m 1,5Ghz, DDR2 768mo.

Actuellement je tourne sur un pentium-m 1,4Ghz et également 768mo de DDR2.

Mais voilà, les temps de compilation n'ont rien à voir entre les deux, ça va carrément du double au triple.

Une compile de noyau me prenait moins de 15minutes sur le 1,5Ghz alors que là sur le 1,4Ghz elle prend facilement 45min. Ou encore Gimp qui prenait 15-20min et à présent plus d'1 heure.

Je ne sais pas si Gcc ou meme Gentoo ont subit de gros changements ces 7 derniers mois mais c'est la deuxième fois que je rencontre de telles performances médiocres sur une gentoo 2007.x.

En effet, entre les 2pentium-M, j'avais également eu ce genre de "giffle" sur le G4 1,67Ghz+1,5Go DDR2  de mon frère, ce qui apparait evidemment anormale quoique je pensais peut-etre que Gcc n'était pas si à l'aise avec l'archi PowerPC. Toutefois, on ne peut décement pas penser que 100 petits Mhz fasse une si grosse différence sur une meme archi processeur ou qu'un P-M explose le dernier G4 à l'époque à quasi meme fréquence.

J'ai vérifié, les perfs disques très corrects,  les flags  ( CFLAGS="-O2 -mtune=pentium-m -pipe" )

rien de bien transcandants quoi, je ne pige pas donc.

Alors voilà, aurais-je manqué un épisode depuis ma gentoo 2006.x qui pétait le feu?

merciLast edited by Djento on Thu Aug 23, 2007 4:42 pm; edited 3 times in total

----------

## geekounet

Salut! Peux-tu mettre ton titre en conformité avec les conventions de notre forum s'il te plait ? Merci  :Smile: 

T'as vérifié le support de ton chipset IDE/SATA dans le kernel ? Et l'activation du DMA ?

----------

## kwenspc

En aucun cas Gentoo est à mettre en cause. Le fait qu'un paquet mette plus de temps à compiler c'est soit que ta machine est plus molle (là j'en doute), soit qu'elle est pas config, soit que le paquet a subit une telle évolution que le code source est nettement plus fournit (là encore, en si peu de temps on peu en douter)

Déjà ton MAKEOPTS, dans ton make.conf il est à combien? -j4 est une bonne valeur pour un mono-cpu. Ensuite le scheduler I/O? CFQ est généralement un bon choix.

Pour le reste tentes d'optimiser le support de ton matériel dans le noyau. Et sinon 768 Mo de ram c'est pas optimum (1Go minimum c'est déjà mieux) mais je doute que ce soit le coupable.

Si tes perfs disques sont correct, quel FS utilises tu par contre?

----------

## Farnsworth

-j4 pour un mono-cpu (mono-coeur)?

Je suis reste sur le vieux calcul: "nombre de cpus/coeurs + 1", cette surpuissante 'equation' n'est plus d'actualite?

----------

## kwenspc

 *Farnsworth wrote:*   

> -j4 pour un mono-cpu (mono-coeur)?
> 
> Je suis reste sur le vieux calcul: "nombre de cpus/coeurs + 1", cette surpuissante 'equation' n'est plus d'actualite?

 

Si si c'est bien aussi  :Smile: 

----------

## Temet

Ca sert surtout à rien.

Je n'ai vu aucune différence entre "-j5" et "-j3" sur mon Core Duo... qui de toute manière ne cesse de m'impressionner par sa vitesse de compilation (c'est pas un C2D pourtant).

----------

## kwenspc

 *Temet wrote:*   

> Ca sert surtout à rien.
> 
> Je n'ai vu aucune différence entre "-j5" et "-j3" sur mon Core Duo... qui de toute manière ne cesse de m'impressionner par sa vitesse de compilation (c'est pas un C2D pourtant).

 

Hum essais -j1 et -j3 là tu verras une différence, après -j4, -j5 et plus c'est en effet peu approprié pour un mono-core qui est déjà saturé dès 3 process de compilation.

----------

## Temet

Normal, "-j1" j'ai un core qui va rien glander ^^.

----------

## Farnsworth

Oui, du coup la regle n+1 est pas mal, en mettre pas assez c'est pas top, mais en mettre trop non seulement ca peut ecrouler la machine (bon ok faudrait etre un sauvage et mettre -j123412342134 pour que ca le fasse  :Wink:  ) mais en plus tu perds du temps lorsque le cpu bascule d'un process a l'autre, non?

Pour en revenir au probleme, tu peux installer genlop et voir si le probleme est present depuis les toutes premieres compilations ou depuis une certaine date (ajout d'un use flag, ...), c'est peut-etre une piste?

tu as regarde ici pour les flags: http://fr.gentoo-wiki.com/HOWTO_CFLAGS ?

----------

## Djento

Merci pour vos interventions.

geekounet: entendu,  et là ça donne quoi?

fansworth: C'est une installation toute fra^iche d'une semaine, il n'y a pas eu compilation ou recompilation de applications/bibliothèques systèmes, ce sont celles du liveCD. 

Kwenspc: Ça me semble également simplet d'accuser la distro mais c'est vraiment le seul truc qui ressort.

j'ai gardé le m^eme make.conf que j'avais sur la machine qui "roulait" impec (machine de référence).

Le chipset (Intel) et le disque sont quasi identiques ainsi que le cpu à 100mhz près  :Smile:  .

Et puis le powerbook G4 1,67Ghz est un très bonne machine de là à ^etre 2x voir 3x plus lente que le Pentium-M 1,5Ghz est impensable.

Donc récapitulation: MAKEOPTS en -j2.

C'est bien l'ordononceur CFQ que j'utilise.

Le disque actuel tourne dans ces eaux là:

 hdparm -tT /dev/hda:

Timing cached reads: 416 MB in 2.00 seconds = 207.63 MB/sec

Timing buffered disk reads: 74 MB in 3.05 seconds = 24.29 MB/sec 

Quasi les m^eme perfs que ma machine de réfèrence.

Le FS est toujours le m^eme depuis 5ans, ReiserFS 3.6.

Quant aux paquets, pour l'exemple du noyau c'est la version officiel dite vanilla.

Enfin voilà, je patauge...

----------

## kwenspc

 *Djento wrote:*   

> 
> 
> Et puis le powerbook G4 1,67Ghz est un très bonne machine de là à ^etre 2x voir 3x plus lente que le Pentium-M 1,5Ghz est impensable.
> 
> 

 

Hum le G4 est de conception nettement plus vieille que le pentium-M que tu utilises donc ça se vaut. (les mhz n'y sont pour rien, Intel s'en est bien rendu compte: mieux vaut une bonne archi à faible Mhz qu'une archi de merde à des Mhz de fou). Et puis l'optimisation de ce processeur sous Linux est de loin moins bonne que sous Mac OS X, ceci pouvant expliquer cela. 

Par contre je ne m'explique pas en effet que tu ais cette perte d'un pentium M à un autre. Sont ils de même génération? (Dothan vs Yonah et même un autre avant je crois bien). La même taille de cache et tout?

25Mo/sec de transfert c'est pas bcp mais ça n'explique pas non plus cette perte, à moins que ton ancien disque étaient nettement plus rapide. Mais j'en doute. 

Quel noyau utilisais tu sur ton ancien laptop. essais de switcher sur cet ancien noyau (doit toujours être dans l'arbre non?) juste pour voir.

Sinon globalement je vois pas trop d'où peut venir le problème. À moins que tu te fasses des idées  :Laughing: 

----------

## Djento

25Mo/sec de transfert c'est pas bcp mais ça n'explique pas non plus cette perte, à moins que ton ancien disque étaient nettement plus rapide. Mais j'en doute.

Ce sont les m^eme perfs.

Par contre je ne m'explique pas en effet que tu ais cette perte d'un pentium M à un autre. Sont ils de même génération?

Banias tous les deux.

Quel noyau utilisais tu sur ton ancien laptop. essais de switcher sur cet ancien noyau (doit toujours être dans l'arbre non?) juste pour voir. 

mmh, je pense que je tournais aux alentours d'un 2.6.18, à présent j'utilise linux 2.6.22.3 

Sinon globalement je vois pas trop d'où peut venir le problème. À moins que tu te fasses des idées :lol 

Est-ce qu'il est permit de douter quand à l'époque ( avril 2007) on mettait 15minutes pour une compile noyau et une 20aine de minutes pour Gimp et qu'à présent on mette respectivement 45minutes et 1h30? héhé

Comme je l'ai dit sur le forum anglais, la seule différence outre la fréquence, c'est que sur ma machine de réfèrence j'avais commencé l'installation au stage 2 et avait recompilé les grosses libs importantes et GCC alors que sur le G4 et le P-M 1,4Ghz  j'utilise tout le précompilé de la distro.

Je tente  un -march=pentium4 ou i686, une recompilation de GCC.

J'ai découvers à l'instant, durant la rédaction, la piste PREEMPTION, je n'avais pas ça au paravant.

L'article semble pertinent:http://kerneltrap.org/node/2702 

je test...

----------

## kwenspc

le "bug" du PREEMPTION date quand même vachement  :Confused:  je sais pas trop.

----------

## kopp

Pourquoi march=pentium-4 ? là ça ne marchera plus  ! penitum-m != pentium-4

----------

## xaviermiller

ben si : PentiumM > Pentium4 > i686 donc ok  :Wink: 

----------

## kopp

pentium-m et pentium-4 ne sont pas compatibles en -march

c'est pas plus du pentium3 !

i686, oki, mais pentium-m et pentium-4 sont deux branches différentes !

----------

## Farnsworth

Pourquoi emploies-tu -mtune au lieu de -march?

en plus je crois que mtune n'inclue pas par defaut tout ce qui est instructions cpu mmx/sse/3dnow/... ?

----------

## ghoti

 *Djento wrote:*   

> geekounet: entendu,  et là ça donne quoi?

 

Comme geekounet n'est pas sorti de sa sieste, je réponds à sa place :

C'est pas mal sauf qu'il faut supprimer le "(non résolu)" : un sujet est résolu ou ne l'est pas !

En mettant "non résolu", tu introduis la confusion dans les recherches car le critère "résolu" renvoie également tous les "non résolu" ...  :Wink: 

----------

## Djento

moué pas grand changement avec ou sans preemption...

----------

## ghoti

En vrac :

Aucun indice dans les logs ? 

Que donne un "free" au plus fort de la compil (autrement dit : est-ce que ça swappe ?)

Que raconte la commande "top" ? Y aurait-il une appli qui boufferait toutes les ressources ?

Peut-être un problème de NICENESS ?

----------

## Djento

 *Quote:*   

>  Currently merging 1 out of 1
> 
>  * media-gfx/gimp-2.3.19 
> 
>        current merge time: 1 hour, 19 minutes and 8 seconds.
> ...

 

un free -m durant le travail.

 *Quote:*   

>    total     .  used     .   free   .    shared      .     buffers  .   cached
> 
> Mem:         755   .     734   .      21    .         0     .        65      .   428
> 
> -/+ buffers/cache:      240    .    515
> ...

 

un uptime:

22:12:30 up  1:35,  2 users,  load average: 3.17, 3.18, 2.80

Niceness je l'ai abaissé à 5

C'est peut-^etre bien la mémoire partagée qui bride le tout... mais c'est une violente dégradation alors  :Smile: .

Le moindre emerge du plus petit paquet prend une plombe.

Bon pour la compilation noyau, je tourne maintenant aux alentours de 30minutes, ça pourrait se tenir, j'ai 100mhz en moins, 3 périph en plus, c'est possible que ça prenne le double du temps.

Reste plus qu'à lancer la compile le soir pour autre chose genre KDE avec un niceness de -10  :Smile: 

----------

## Temet

C'est pas normal que tu swappes!

T'as un truc anormal qui te bouffe toute ta ram. Forcément, si tu swappes quand tu compiles... je m'étonne même que les temps soient seulement doublés.

J'ai 1 Go de RAM et je ne swappe jamais!

PS : perso j'ai un niceness de 19 pour portage. Je peux matter des DVDs ou faire ce que j'ai à faire sans ralentissement notable comme ça.

----------

## Farnsworth

ou tu vois qu'il swap?

il est a 0 used, y a du y avoir un loupé dans le copier/coller, il manque juste '88' a la fin de son quote!

parceque 488Mo de swap, 0 used et 4 free ca veut pas dire grand chose non?

----------

## Temet

Ah oui t'as raison....

C'est de sa faute! La balise "code" elle est là pour garder la forme de ce genre de choses!!   :Laughing: 

----------

## Farnsworth

 *Temet wrote:*   

> Ah oui t'as raison....

 

Toujours...    :Twisted Evil: 

Et concernant le souci, je reviens a la charge avec ca mais le flag -mtune me parait pas adapte (genere un code plus lourd car compatible descendant), de plus il n'utilise pas toutes les possibilites du cpu, c'est peut-etre pas ca qui va diviser ton temps de compil par deux mais ca peut deja ameliorer!

je me trompe?

Ou alors vous avez quelquechose contre -march?

----------

## Djento

J'utilise -march=i686 à présent et cette compile s'est faite de cette manière.

Et quant à la swap, le système l'utilise à peine.

La mémoire partagée semble justifier ce massacre avec les 100mhz en moins.

De toute façon, bientôt j'aurai un core 2 duo T7000 donc...

Je continue à  scruter le bousin mais bon, je n'en fais plus ma priorité.

Merci encore, mais si vous êtes encore pleins d'idées, n'hésitez  pas héhéLast edited by Djento on Fri Aug 24, 2007 3:44 pm; edited 1 time in total

----------

## ghoti

Qu'est-ce que tu entends par "mémoire partagée" ?

----------

## Djento

Mémoire partagée avec la carte graphique. (environ 8mb)

----------

## ghoti

 *Djento wrote:*   

> (environ 8mb)

 

Heu : tu rigoles ?

----------

## Djento

c'est à dire? Car je n'ai pas besoin de plus moi.

----------

## _Seth_

Salut,

  Je suis pas trop étonné par les perfs du G4, c'est effectivement mieux d'avoir une config "homogène" car un CPU overclocké par rapport à la vitesse du bus ça ne sert pas à grand chose.

  Pour les temps de compil, j'ai cru comprendre que tu avais changé de portable et pas seulement de CPU, donc peut-être la config de ton nouveau portable est à remettre en cause par rapport à l'ancienne. Une vitesse de proco affiché plus sympa mais une config (CM-RAM-CPU) un petit peu inférieure peut donner des perfs moins importantes.

  Le coup de la swap est à vérifier car ça peut te planter complètement... essaye de changer ta swappiness :

```
# cat /proc/sys/vm/swappiness
```

tu peux la changer dans ton /etc/sysctl.conf :

```
vm.swappiness=25
```

----------

## widan

 *Djento wrote:*   

> La mémoire partagée semble justifier ce massacre avec les 100mhz en moins.

 

Nan, ça bouffe rien en bande passante mémoire en 2D. Et ton ancien chipset était surement aussi en mémoire partagée.

 *ghoti wrote:*   

>  *Djento wrote:*   (environ 8mb) 
> 
> Heu : tu rigoles ?

 

Non c'est possible. Sur chipset Intel, c'est 8 Mo en permanence pour le framebuffer et le reste pour aller à 64/128/256 Mo en DVMT (allouée dynamiquement en fonction des besoins).

----------

