# [Optimisation] GCC4.2 et Amd64

## apocryphe

Bonsoir,

GCC4.2 va sous peu de temps sortir en stable officiel

et je compte me fabriquer mon propre live cd avec catalyst

je me renseigne donc sur l'optimisation du binair... je cherche des options safes ( entendez qu'il faut que 90% des paquets compiles)

pour le moment j'ai ca avec gcc4.1.1:

 *Quote:*   

> 
> 
> CFLAGS="-march=k8 -pipe -O2 -ftree-vectorize"
> 
> CHOST="x86_64-pc-linux-gnu"
> ...

 

merci

----------

## Tom_

Tu peux regarder du côté des LDFLAGS aussi. 

Actuellement j'utilise : 

```
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -s -Wl,--hash-style=both"
```

Généralement ca compile bien sauf dans certains cas ù as-needed n'est pas supporté (on trouve des patchs pour mal de programmes).

Prelink fait un bon boulot avec ces LDFLAGS aussi.Last edited by Tom_ on Sat Sep 02, 2006 6:22 pm; edited 1 time in total

----------

## man in the hill

Salut,

Moi c'est très safe ! 

```
crazy_gentoo faya %

 cat /etc/make.conf

# These settings were set by the catalyst build script that automatically built this stage

# Please consult /etc/make.conf.example for a more detailed example

CFLAGS="-march=k8 -O2 -msse3 -pipe"

CHOST="x86_64-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j2"

ACCEPT_KEYWORDS="~amd64"

...
```

Franchement j'ai dejà essayé pleins de flags dont le -ftree-vectorize et ldflags  mais je n'ai remarqué aucune compile plus rapide donc je suis revenu au safe mode ! 

                                                                        @+

----------

## Tom_

Les (C,CCX,L)FLAGS n'améliorent pas les temps de compilation mais généralement le temps de chargement des programmes, la réactivité du système (s'ils sont bien choisis) .

----------

## man in the hill

 *Tom_ wrote:*   

> Les (C,CCX,L)FLAGS n'améliorent pas les temps de compilation mais généralement le temps de chargement des programmes, la réactivité du système (s'ils sont bien choisis) .

 

C'est clair mais franchement à mon avis les paquets ont déjà des bonnes flags par défaults ....

[EDIT] Je suis  désolé mais les CFLAGS sont là pour optimiser ton compilateur pour la compilation et optimiser aussi le résultat , bien sur, et les ldflags pour le linkeur !

Petite correction quand même   :Wink:   ! [/EDIT]

----------

## GentooUser@Clubic

Justement sous Gentoo non ! 

Les flags par défaut c'est ceux que tu met dans ton (C,CCX,L)FLAGS.

----------

## man in the hill

Les devs des paquets mettent ds flags par defaults !

Il y a des paquets qui vont zapper tes flags memes si tu les rajoutes ds ton make.conf et ds l'ebuild ...

----------

## GentooUser@Clubic

Pour la suppression de certains flags je le savais.

Mais pour l'ajout j'avoue ne pas avoir remarqué.

Ça dois être assez discret et rare alors, parce que je vois rarement autre chose que mes flags lors des make !

----------

## titoucha

 *Tom_ wrote:*   

> 
> 
> Actuellement j'utilise : 
> 
> ```
> ...

 

As tu eu la librairie libstdc++-v3 dans ce cas   :Question: 

----------

## man in the hill

 *GentooUser@Clubic wrote:*   

> Pour la suppression de certains flags je le savais.
> 
> Mais pour l'ajout j'avoue ne pas avoir remarqué.
> 
> Ça dois être assez discret et rare alors, parce que je vois rarement autre chose que mes flags lors des make !

 

je me souviens avoir voulu viré un ldflags https://forums.gentoo.org/viewtopic-t-475307-highlight-ldflags.html qui faisait planter  un paquet et qui n'était pas ds mon make.conf  et j'ai essayé via l'ebuild et pas moyen  et j'avais trouvé une astuce ! Mais franchement à l'époque ou je faisait mes optmisation ou j'ai essayé --hash-style  lancé sur le forum unsupported software, je n'ai jamais remarqué de gain véritable de vitesse d'exécution  et c'est pour cela je ne prends plus la tête ds ce genre d'optimisations...

----------

## Tom_

@titoucha, la libstdc++-v3 est présente sur mon système.

----------

## apocryphe

merci,

en ce qui me concerne je ne veux pas ameliorer la rapidite de compilation... mais l optimisation du binair  :Smile: 

jvais aller lire la doc de gcc

----------

## GentooUser@Clubic

 *man in the hill wrote:*   

>  *GentooUser@Clubic wrote:*   Pour la suppression de certains flags je le savais.
> 
> Mais pour l'ajout j'avoue ne pas avoir remarqué.
> 
> Ça dois être assez discret et rare alors, parce que je vois rarement autre chose que mes flags lors des make ! 
> ...

 

C'est sur qu'en gain global de performence je ne remarque pas grande difference avec le autres distribs.

Par contre sur les cas particuliers... Remplacer libhal et libSDL livré avec ut2004 par celle compilé au petits oignons par Gentoo pour mon systeme ma fait gagner pas mal de FPS, avant je ne pouvais pas jouer les plus grosse cartes de ut2004 sur ma config, maintenant je peut !

----------

## Scullder

 *Tom_ wrote:*   

> Tu peux regarder du côté des LDFLAGS aussi. 
> 
> Actuellement j'utilise : 
> 
> ```
> ...

 

Pour "--hash-style=both", j'ai trouvé ça : http://gentoo-wiki.com/HOWTO_Hashstyle

Je m'empresse d'essayer  :Very Happy: 

edit : en fait faut que je sauvegarde mon système avant, on sait jamais  :Very Happy: 

----------

## man in the hill

 *Scullder wrote:*   

>  *Tom_ wrote:*   Tu peux regarder du côté des LDFLAGS aussi. 
> 
> Actuellement j'utilise : 
> 
> ```
> ...

 

ça se passe à côté à la base https://forums.gentoo.org/viewtopic-t-475538-start-0.html   tu verras la genese du wiki ... Cela peut tjrs être interressant avant de te lancer   :Wink:   !

----------

## titoucha

 *Tom_ wrote:*   

> @titoucha, la libstdc++-v3 est présente sur mon système.

 

Mais as tu eu un problème à la compiler avec le hashstyle   :Question: 

----------

## Tom_

Non je n'ai eu aucun problème pour la compiler mais je dois avouer que je partais d'un stage 3 tout propre. Ca a peut-être joué. 

Pour --hash-style, je n'ai aucun problème ca passe tout seul avec tous les paquets.

----------

## Scullder

Alors d'après ces pages :

http://gnu.gnusoft.net/software/gcc/gcc-4.0/changes.html#visibility

http://gcc.gnu.org/wiki/Visibility

on peut cumuler les options -fvisibility=hidden -fvisibility-inlines-hidden. Je l'ai fait, et d'autres options on peut être aidé, mais le binaire d'amule a perdu 1Mo en passant de 4.4Mo à 3.4Mo.

Par contre j'arrive pas à trouver le rôle de l'option  -enable-gcc-hidden-visibility.

Dans le même genre il y a le use flag kdehiddenvisibility

Je suis tombé sur cette option aussi qui a l'air risquée : -fno-enforce-eh-specs

 *Quote:*   

> 
> 
> -fno-enforce-eh-specs
> 
>     Do not check for violation of exception specifications at runtime. This option violates the C++ standard, but may be useful for reducing code size in production builds, much like defining NDEBUG. The compiler will still optimize based on the exception specifications. 
> ...

 

http://web.mit.edu/rhel-doc/3/rhel-gcc-en-3/c---dialect-options.html

Pour mes ldflags, j'ai suivi le tutorial du wiki et Tom, et j'ai mis ça :

```
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -s -Wl,--hash-style=both"
```

Il y a aussi une option utile pour les prog KDE, on peut l'ajouter dans une nouvelle variable "EXTRA_CONF" dans le make.conf  (je connaissais pas, j'ai vu ça sur le forum, et effectivement ça fonctionne).

```
EXTRA_ECONF="--enable-new-ldflags"
```

Pour la glibc, il y a deux use flag qui ont l'air intéressants, glibc-omitfp (omit frame pointer, je croyais que c'était le comportement par défaut avec -march=k8 ?) et nomalloccheck.

Là je recompile, et après un coup de prelink -afmR. Donc si tout est stable je garde, sinon, j'ai une sauvegarde dans le pire des cas  :Smile: 

----------

## titoucha

 *Scullder wrote:*   

> 
> 
> on peut cumuler les options -fvisibility=hidden -fvisibility-inlines-hidden. Je l'ai fait, et d'autres options on peut être aidé, mais le binaire d'amule a perdu 1Mo en passant de 4.4Mo à 3.4Mo.
> 
> 

 

Tu n'as pas eu de plantées avec ces flags car la première chose que fait le compilateur lorsque je les ai mis c'est de me dire qu'ils pouvaient casser les paquets et que si jamais ils fallait les enlever   :Question: 

----------

## Scullder

 *titoucha wrote:*   

>  *Scullder wrote:*   
> 
> on peut cumuler les options -fvisibility=hidden -fvisibility-inlines-hidden. Je l'ai fait, et d'autres options on peut être aidé, mais le binaire d'amule a perdu 1Mo en passant de 4.4Mo à 3.4Mo.
> 
>  
> ...

 

J'ai des paquets qui compilent pas (comme libpcre), mais ça a toujours l'air de fonctionner.

----------

## Tom_

Existe-t-il une manière de calculer le temps que met un programme à se charger. 

Je connais la commande "time" mais elle mesure le temps entre le moment où on ouvre le programme et on le ferme (temps variable donc), nen?

Merci.

Sinon, je me vais recompiler quelques programmes avec les options proposées par Scullder.  :Smile: 

----------

## Scullder

Pour la commande que tu demandes, j'essaie de retrouver ça et je te la passe (pas le temps tout de suite).

J'ai quelques résultats assez impressionnants :

Avant :

```

gentoo scullder # ldd //usr/bin/yakuake | wc -l

37

gentoo scullder # stat /usr/bin/yakuake

  File: `/usr/bin/yakuake'

  Size: 993696          Blocks: 1952       IO Block: 4096   regular file

Device: 803h/2051d      Inode: 299783      Links: 1

Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)

Access: 2006-08-31 19:21:52.000000000 +0200

Modify: 2006-06-20 14:11:59.000000000 +0200

Change: 2006-08-31 19:21:52.000000000 +0200

```

Après :

```

gentoo scullder # stat /usr/bin/yakuake

  File: `/usr/bin/yakuake'

  Size: 159424          Blocks: 320        IO Block: 4096   regular file

Device: 803h/2051d      Inode: 963196      Links: 1

Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)

Access: 2006-09-05 02:34:42.000000000 +0200

Modify: 2006-09-05 02:34:42.000000000 +0200

Change: 2006-09-05 02:34:42.000000000 +0200

gentoo scullder # ldd //usr/bin/yakuake | wc -l

35

```

Bon, ça doit être les flag hidden visibility je suppose pour la taille du binaire  :Smile:  pour le --as-needed, c'est moins impressionnant que ce que je pensais en général, quoique, c'est rassurant.

----------

## Scullder

J'ai des erreurs de ce genre pour certains prog (même si ça boot) :

```
scullder@gentoo ~ $ k3b: symbol lookup error: /usr/lib64/libk3bdevice.so.2: undefined symbol: _ZN6DBusQt10ConnectionC1EP7QObject

scullder@gentoo ~ $ amule

amule: /usr/lib/libwx_gtk2u_adv-2.6.so.0: no version information available (required by amule)

amule: /usr/lib/libwx_baseu_net-2.6.so.0: no version information available (required by amule)

amule: /usr/lib/libwx_baseu-2.6.so.0: no version information available (required by amule)

amule: /usr/lib/libwx_gtk2u_core-2.6.so.0: no version information available (required by amule)

amule: /usr/lib/libwx_gtk2u_core-2.6.so.0: no version information available (required by amule)

amule: /usr/lib/libwx_gtk2u_core-2.6.so.0: no version information available (required by amule)

amule: symbol lookup error: /usr/lib/libwx_baseu_net-2.6.so.0: undefined symbol: _ZNK19wxFileSystemHandler12GetClassInfoEv
```

je pense que ça doit venir de --as-needed.

edit : bien vu, list de package problématiques ici et solution (script pour spécifier les ld flag par package) :

https://forums.gentoo.org/viewtopic-t-316445-start-0-postdays-0-postorder-asc-highlight-.html

----------

## geekounet

J'ai eu des problèmes de ce genre là avec la libpng quand j'ai ajouté -fvisibility=hidden à mes CFLAGS.

----------

## _droop_

 *Tom_ wrote:*   

> Existe-t-il une manière de calculer le temps que met un programme à se charger. 

 

Bonjour,

```
LD_DEBUG=statistics konqueror
```

ca donne le temps de chargement et d'éditions des liens pour les bibliothèques dynamique (ca permet de tester des LDFLAGS).

Voilà.

----------

## Scullder

 *pierreg wrote:*   

> J'ai eu des problèmes de ce genre là avec la libpng quand j'ai ajouté -fvisibility=hidden à mes CFLAGS.

 

Je pense que ça doit juste causer les erreurs undefined symbol.

----------

