Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Gentoo [gentoo-user-fr] CFLAGS="-O3/2/1/s" ?

[gentoo-user-fr] CFLAGS="-O3/2/1/s" ?

12 réponses
Avatar
Etienne.Hilson
Bonjour,

Voici la question la plus stupide qu'il m'ait été donné de poser :

Le flag d'optimisation dans le fichier /etc/make.conf
CFLAGS="-Os" -> "-O3"
-Os optimise la taille
-O1 -O2 -O3 optimise la vitesse

Mais cela veut-il dire :

1) Balancer la taille/vitesse de la compilation ?
2) Balancer la taille/vitesse de l'exécutable généré ?
3) Balancer la taille/vitesse de l'exécution du programme compilé ?

Jusqu'à présent, je pensais que c'était le 3, donc j'utilisais toujours -O3,
histoire que les performances soient optimales à l'utilisation.

Mais je commence à me poser des questions car je suis occupé à installer
gentoo sur un vieux celeron 1Ghz avec 128Mo de ram, et je vois que le swap
(kswapd0) travaille comme un fou furieux et que certaines compilations
n'avancent vraiment pas (pour le moment, plus de 72 heures pour compiler x et
kde, ça me semble un peu long...)

Merci pour vos lumières :-)

--
Etienne Hilson
Alcatel Bell SA
Customer Support Department Namur
Office : +32 81 23 56 01
Mobile : +32 478 96 04 69
etienne.hilson@alcatel.be

--
gentoo-user-fr@gentoo.org mailing list
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Stéphan BERNARD
Extrait de man gcc :

-Os Optimize for size. -Os enables all -O2 optimizations that do not
typically increase code size. It also performs further optimizations
designed to reduce code size.

Ce qui veut dire que -Os est équivalent à -O2 sauf en ce qui concerne
des optimisations gourmandes en taille. -Os ajoute aussi d'autres
optimisations conçues pour réduire la taille.

Tu peux aussi garder un -O2 ou -O3 avec un -s, mais c'est du gagne pas
gros :

-s Remove all symbol table and relocation information from the executable.

--
Stéphan
--
mailing list
Avatar
Jean-Jacques FABRE
------=_Part_9223_7019543.1139940270262
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Bonjour,

directement du man de g++ :

-O Optimize. Optimizing compilation takes somewhat more time, and a lo t
more memory for a large function.
**
Donc si tu es short en temps et memoire pour la compilation, ne mets pas le
-O. Ta compilation ira plus vite et prendra moins de memoire. Mais ca ne
fera pas du code optimise (donc lors de l'execution tu auras un binaire plu s
lent ou prenant un peu plus de memoire)...

Par contre, O1/O2/O3 utilisent successivement de plus en plus
d'optimisation. Donc un -O1 ou -O2 serait peut-etre un bon compromis

bonne compile :-)

JJacques

On 2/14/06, Stéphan BERNARD wrote:

Extrait de man gcc :

-Os Optimize for size. -Os enables all -O2 optimizations that do not
typically increase code size. It also performs further optimizations
designed to reduce code size.

Ce qui veut dire que -Os est équivalent à -O2 sauf en ce qui concerne
des optimisations gourmandes en taille. -Os ajoute aussi d'autres
optimisations conçues pour réduire la taille.

Tu peux aussi garder un -O2 ou -O3 avec un -s, mais c'est du gagne pas
gros :

-s Remove all symbol table and relocation information from the
executable.

--
Stéphan
--
mailing list





------=_Part_9223_7019543.1139940270262
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Bonjour,<br>
<br>
directement du man de g++ :<br>
<br>
-O&nbsp;&nbsp;&nbsp;&nbsp; Optimize.&nbsp; Optimizing compilation takes
somewhat more time, and a lot more memory for a large function.<br>
<strong></strong><br>
Donc si tu es short en temps et memoire pour la compilation, ne mets
pas le -O. Ta compilation ira plus vite et prendra moins de memoire.
Mais ca ne fera pas du code optimise (donc lors de l'execution tu auras
un binaire plus lent ou prenant un peu plus de memoire)...<br>
<br>
Par contre, O1/O2/O3 utilisent successivement de plus en plus
d'optimisation. Donc un -O1 ou -O2 serait peut-etre un bon compromis<br>
<br>
bonne compile :-)<br>
<br>
JJacques<br><br><div><span class="gmail_quote">On 2/14/06, <b class="gm ail_sendername">Stéphan BERNARD</b> &lt;<a href="mailto:stephan.bernard @clermont.cemagref.fr"></a>&gt; wrote:< /span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Extrait de man gc c :<br><br>&nbsp;&nbsp;-Os Optimize for size.&nbsp;&nbsp;-Os enables all -O 2 optimizations that do not
<br>typically increase code size. It also performs further optimizations<br >designed to reduce code size.<br><br>Ce qui veut dire que -Os est équiva lent à -O2 sauf en ce qui concerne<br>des optimisations gourmandes en tai lle. -Os ajoute aussi d'autres
<br>optimisations conçues pour réduire la taille.<br><br>Tu peux aussi garder un -O2 ou -O3 avec un -s, mais c'est du gagne pas<br>gros :<br><br>- s&nbsp;&nbsp;Remove all symbol table and relocation information from the ex ecutable.<br>
<br>--<br>Stéphan<br>--<br><a href="mailto:">g </a> mailing list<br><br></blockquote></div><br>

------=_Part_9223_7019543.1139940270262--
--
mailing list
Avatar
Michel Paquet
a écrit :
Bonjour,

Voici la question la plus stupide qu'il m'ait été donné de poser :

Le flag d'optimisation dans le fichier /etc/make.conf
CFLAGS="-Os" -> "-O3"
-Os optimise la taille
-O1 -O2 -O3 optimise la vitesse

Mais cela veut-il dire :

1) Balancer la taille/vitesse de la compilation ?
2) Balancer la taille/vitesse de l'exécutable généré ?
3) Balancer la taille/vitesse de l'exécution du programme compilé ?

Jusqu'à présent, je pensais que c'était le 3, donc j'utilisais toujours -O3,
histoire que les performances soient optimales à l'utilisation.

Mais je commence à me poser des questions car je suis occupé à installer
gentoo sur un vieux celeron 1Ghz avec 128Mo de ram, et je vois que le swap
(kswapd0) travaille comme un fou furieux et que certaines compilations
n'avancent vraiment pas (pour le moment, plus de 72 heures pour compiler x et
kde, ça me semble un peu long...)

Merci pour vos lumières :-)




72 hrs pour compilé X, c'est pas si énorme que cela. Ca ma pris un peu
moin de 70hrs sur mon Pentium3 933Mhz avec 512mo de ram :P

Maintenant je suis sur un Athlon64 3000+ et en moin de 10 hrs X étais
compilé. KDE m'en a pris que 14 hrs (plus de 100hrs sur mon vieux 933
pour comparer)

A mon avis, le temps de compilation est surtout relier à la machine
elle-même et non au optimisation apporté à gcc

Michel P.
--
mailing list
Avatar
Christophe PEREZ
Le Tue, 14 Feb 2006 18:29:08 -0500, Michel Paquet a écrit :

72 hrs pour compilé X, c'est pas si énorme que cela. Ca ma pris un peu
moin de 70hrs sur mon Pentium3 933Mhz avec 512mo de ram :P

Maintenant je suis sur un Athlon64 3000+ et en moin de 10 hrs X étais
compilé. KDE m'en a pris que 14 hrs (plus de 100hrs sur mon vieux 933
pour comparer)



Les temps que tu annonces pour un PIII m'étonnent profondément. J'en ai
3 ici, un 800, un 866 et un 933, 2 avec 384Mo de RAM et le 800 avec 256,
et aucun, je dis bien aucun, ne prend de tels temps de compilation pour X .
Je n'ai jamais mesuré, mais c'est tout au plus 2 ou 3 heures, mais
certainement pas 70 heures, heureusement, ça serait insupportable.

OOo alors, c'est 2 mois pleins chez toi ?
Je l'ai compilé encore la nuit dernière sur le PIII 866, et il n'a pa s
pris 24h. Si besoin de confirmation, je pourrai regarder dans les logs.

En plus, pour OOo, ce n'est même pas une question de distcc puisqu'il n e
l'utilise pas.

--
Christophe PEREZ
--
mailing list
Avatar
Etienne.Hilson
On Wednesday 15 February 2006 00:29, Michel Paquet wrote:

72 hrs pour compilé X, c'est pas si énorme que cela. Ca ma pris un peu
moin de 70hrs sur mon Pentium3 933Mhz avec 512mo de ram :P



Heu, je n'ai pas dit que la compilation était terminée :-D
Je lancé samedi en fin d'après-midi un emerge kde après l'installation du
stage 3, et il tourne encore :-P

A mon avis, le temps de compilation est surtout relier à la machine
elle-même et non au optimisation apporté à gcc

Michel P.



Dans mon cas, je suis certain que c'est à cause du swapping, quand je fais un
top, je vois que le process kswapd0 a comme temps total d'utilisation cpu 10x
le temps du process qui compile (je ne me rappelle plus le nom).

Bah, patience sera mon maître mot pour le reste de la semaine.

En tout cas, c'est certain que la première chose que je fais dès qu'il a
terminé, c'est d'installer distcc :-D


Etienne

--
mailing list
Avatar
Christophe Garault
Christophe PEREZ a écrit :

Les temps que tu annonces pour un PIII m'étonnent profondément. J'en ai
3 ici, un 800, un 866 et un 933, 2 avec 384Mo de RAM et le 800 avec 256,
et aucun, je dis bien aucun, ne prend de tels temps de compilation pour X.
Je n'ai jamais mesuré, mais c'est tout au plus 2 ou 3 heures, mais
certainement pas 70 heures, heureusement, ça serait insupportable.




Itou. Sur un Duron 1600 avec 512 Mo de RAM et des tonnes d'appli et de
services en arrière-plan (postfix, amavisd-new, apache, postgresql,
courier-imap, etc...):

marge ~ # genlop -t xorg-x11
* x11-base/xorg-x11

[snip]

Thu Nov 24 15:02:28 2005 >>> x11-base/xorg-x11-6.8.2-r6
merge time: 1 hour, 5 minutes and 36 seconds.


A noter pour ceux qui veulent raccourcir le temps de l'emerge (et non
pas la compile) la possibilité de se passer de certaines features dans
le make.conf: test et collision-protect par exemple peuvent prendre
beaucoup de temps suivant les ebuild.

mes 0.02¤

--
Et sous les vieux haubans rongés de lente usure,
Poulies aux yeux crevés sur l'infini perdu,
Témoins momifiés des hommes disparus,
Quel dieu féroce a pétrifié dans vos membrures
Les fantômes railleurs de vos orgueils vaincus.
- Anita Conti.

--
mailing list
Avatar
granger
> Maintenant je suis sur un Athlon64 3000+ et en moin de 10 hrs X étais
compilé. KDE m'en a pris que 14 hrs (plus de 100hrs sur mon vieux 933
pour comparer)

A mon avis, le temps de compilation est surtout relier à la machine
elle-même et non au optimisation apporté à gcc



enfin tout ce temps pour un a64 3000+, je pense que la aussi il y a
problème les 2 compris ne devrait pas dépasser 5heures !!!!
ou alors c est que l'a64 est monté avec une barette de 128 Mo et un disque
4200rpm.

Je pense aussi que les versions de kde ne sont plus faites pour des pc en
dessous du p4 et athlon xp, sauf pour une utilisation de logiciel tiers
sur un wm léger.

--
mailing list
Avatar
Michel Paquet
a écrit :
Maintenant je suis sur un Athlon64 3000+ et en moin de 10 hrs X étais
compilé. KDE m'en a pris que 14 hrs (plus de 100hrs sur mon vieux 933
pour comparer)

A mon avis, le temps de compilation est surtout relier à la machine
elle-même et non au optimisation apporté à gcc




enfin tout ce temps pour un a64 3000+, je pense que la aussi il y a
problème les 2 compris ne devrait pas dépasser 5heures !!!!
ou alors c est que l'a64 est monté avec une barette de 128 Mo et un disque
4200rpm.

Je pense aussi que les versions de kde ne sont plus faites pour des pc en
dessous du p4 et athlon xp, sauf pour une utilisation de logiciel tiers
sur un wm léger.




On parle bien ici de "Compilation" et non d'installation de packetage
pré-compilé obtenu sur le 2ième disque de Gentoo??? Parce que si c'est
le cas, tu doit avoir un Athlon256bit cadensé à 23.6 Terahertz avec au
moins 16Go de ram

:P:P:P

Plus sérieusement, tu devrais nous expliqué comment tu a pu compilé Xorg
+ KDE en moin de 5 hrs sur 1 seul ordinateur. Ca pourrais être
instructif pour un paquet de gens ici. Je tien à précisé que dans mon
cas, j'utilise Xorg 6.9 (ebuild overlay) et KDE 3.5.1 (ebuild séparer)

Michel P.


--
mailing list
Avatar
Benjamin LASSERRE
Michel Paquet wrote:

On parle bien ici de "Compilation" et non d'installation de packetage
pré-compilé obtenu sur le 2ième disque de Gentoo??? Parce que si c'est
le cas, tu doit avoir un Athlon256bit cadensé à 23.6 Terahertz avec au
moins 16Go de ram

:P:P:P

Plus sérieusement, tu devrais nous expliqué comment tu a pu compilé Xorg
+ KDE en moin de 5 hrs sur 1 seul ordinateur. Ca pourrais être
instructif pour un paquet de gens ici. Je tien à précisé que dans mon
cas, j'utilise Xorg 6.9 (ebuild overlay) et KDE 3.5.1 (ebuild séparer)

Michel P.





# genlop -t xorg-x11
* x11-base/xorg-x11

Sun Feb 13 14:03:51 2005 >>> x11-base/xorg-x11-6.8.0-r4
merge time: 52 minutes and 26 seconds.

# genlop -t openoffice
* app-office/openoffice

Mon Jan 23 23:15:36 2006 >>> app-office/openoffice-2.0.1
merge time: 7 hours, 25 minutes and 3 seconds.


je parle bien ici de compilation, sur un _P4 prescott 1 Go de RAM_
pour info j'avais avant un second pc _celeron 500 avec 400Mo de RAM_
la compil de X ne m'a *jamais* pris plus de 24h (sans distcc)

je pense que vous avez un problème... je ne vois malheureusement pas
lequel ! :p

un /emerge --info/ pourrait être un bon début de résolution du problème

--
mailing list
Avatar
Michel Paquet
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Benjamin LASSERRE a écrit :
Michel Paquet wrote:

On parle bien ici de "Compilation" et non d'installation de packetage
pré-compilé obtenu sur le 2ième disque de Gentoo??? Parce que si c'est
le cas, tu doit avoir un Athlon256bit cadensé à 23.6 Terahertz avec au
moins 16Go de ram

:P:P:P

Plus sérieusement, tu devrais nous expliqué comment tu a pu compilé Xorg
+ KDE en moin de 5 hrs sur 1 seul ordinateur. Ca pourrais être
instructif pour un paquet de gens ici. Je tien à précisé que dans mon
cas, j'utilise Xorg 6.9 (ebuild overlay) et KDE 3.5.1 (ebuild séparer)

Michel P.





# genlop -t xorg-x11
* x11-base/xorg-x11

Sun Feb 13 14:03:51 2005 >>> x11-base/xorg-x11-6.8.0-r4
merge time: 52 minutes and 26 seconds.

# genlop -t openoffice
* app-office/openoffice

Mon Jan 23 23:15:36 2006 >>> app-office/openoffice-2.0.1
merge time: 7 hours, 25 minutes and 3 seconds.


je parle bien ici de compilation, sur un _P4 prescott 1 Go de RAM_
pour info j'avais avant un second pc _celeron 500 avec 400Mo de RAM_
la compil de X ne m'a *jamais* pris plus de 24h (sans distcc)

je pense que vous avez un problème... je ne vois malheureusement pas
lequel ! :p

un /emerge --info/ pourrait être un bon début de résolution du problème




Je rétracte mes dires. J'ai lancé un 'emerge -e world' (histoire de
tester quelques choses) hier soir vers les 20:00h (il est présentement
7:30am lors de l'écriture de ce message) et j'ai 296 package sur 512 de
fait déja. Ceci inclut glibc, baselayoute, Xorg et presque la moitier de
KDE.

On pourrais donc en conclure que le problème a du venir d'un des
packetage provenant du cd-rom d'installation. Je me suis démarrer à
partir du stage 3 et installé le tout sans me soussier de faire un
'emerge -avuD world' pour vérifier si il y avait des package à mettre à jour

Michel P.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD9HG+wpieyJYB3AkRAqYfAJoCRWz8OvqDuuK6qo1lb6cDqANKCQCfYHzw
q1xmFYt0f4LQxLkWJhsUw6M =0XpU
-----END PGP SIGNATURE-----
--
mailing list
1 2