Re: GCC et AMD64

Vous avez raison : revenons-en au sujet de départ ;-)

Pour ma part j'utilise des CFLAGS relativement classiques : -Os -march=k8 -pipe -fomit-frame-pointer

J'ai pris l'habitude d'utiliser Os depuis plusieurs mois déjà, après avoir constaté une amélioration sensible des performances de mon portable avec ces réglages : -Os inclut les optimisation de -O2, mais génère des binaires plus petits : sur mon disque de portable, relativement ancien et lent, le temps de chargement de la distrib est un poil plus court (pas mesuré, mais c'est sensible), mais surtout le système est plus réactif.

Bref, je me suis dit que ce qui était bon pour mon portable ne pouvait être mauvais pour mon desktop.

Attention toutefois, les dernières version de Gentoo spécifient clairement dans le make.conf d'origine de ne pas utiliser -Os sur architecture k8. Je l'ai fait quand même, en connaissance de cause, sans souci jusque-là.

Cordialement,

Quelques références sur ce sujet en cadeau bonus :
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Optimize-Options.html#Optimize-Options
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

Un thread sur le forum, en anglais, et très long : http://forums.gentoo.org/viewtopic.php?t=5717






Michel Paquet a écrit :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Merci Hubert pour cette réponse. Avoir eu le lien, je l'aurrais envoyé
volontier mais j'ai télécharger le fichier sans vraiment me rappeler
d'où je l'avais sorti (probablement sur le site d,AMD en fesant des
recherche)

Milles pardon à tout ceux que mon fichier ai pu nuire.

Maintenant si nous pouvions revenir au sujet réel (voir Sujet ci-haut),
j'aimerais avoir vos commentaire sur les CFLAGS

  

Bertrant:
Pourquoi march=k8 et pas march=athlon64 ?
    

march=k8 et march=athlon64 sont exactement identique, saufe que l'un
s'écrit en 2 lettre et l'autre en 8 :P


Michel P.


Hubert Mercier a écrit :
  

Bonjour,

Effectivement, 800 ko, ce n'est pas énorme, sur ce point personne ne
vous contredira. Par contre, il faut faire attention à quelques points
"de détails" lorsqu'on poste des documents. Par exemple la charge
induite par l'envoi d'un tel courrier sur une mailing-list comptant
quelques centaines d'abonnés (317 à ce jour, cf (1)). 800 ko * 317 = 253
600 Ko, soit environ 200 Mo.

=> Autrement dit, un tel document, de seulement 800 Ko, envoyé à la
mailing-liste, a généré un traffic sortant de plus de 200 Mo uniquement
pour ce message. Et comme chacun sait, la bande passante a un coût bien
réel. Le même document, envoyé sur la liste gentoo-user (2531 abonnés)
aurait généré un traffic de 2 Go !

Mais je vous accorde que ce genre de considérations ne saute pas
forcément aux yeux lorsqu'on envoie un message. Et mon intervention n'a
pas pour but de "désigner un coupable", mais simplement d'éclairer un
peu le pourquoi du comment de certains règles de nos petites communautés.
Je suis en revanche certain que vous n'aviez aucunement l'intention
d'embêter le monde en envoyant ce mail, mais bien au contraire d'être
constructif vis-à-vis du sujet que vous abordez, et nous vous en sommes
reconnaissant à ce titre-là.

Bien amicalement,

Hubert.

(1) http://lists.gentoo.org/ml_stats.txt




Michel Paquet a écrit :
Yoann Pannier a écrit :
 
    

Michel Paquet wrote, On 03/23/2006 01:36 AM:
   
          

P.S. j'ai joins la doc d'AMD pour les curieux ;)
      
            

et hop, 800Ko dans les dents.

    
          

C'est vrai que 800ko, c'est énorme. Ouff, mon système en a pris plein la
poire! Les systèmes de courriel de nos jours ne supporte surement pas un
attachement de plus de 4Ko. De plus nos disque dur sont en moyenne
rarement au dessus de 40Mo (j'ai bien dit Mo et non pas Go). Merde, un
fichier de 800ko va remplir ce qui reste de mon disque... Voyon donc!

 ... (sarcastiquement)

Faut être pas être parano quand-même...
    

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

iD8DBQFEI+m5wpieyJYB3AkRAppsAJ9T+TB929QeFQ1cvrl6g8UMG2/vOgCfbWny
ttDuocQVCC0jO2hzXGEwUGI=
=UZhM
-----END PGP SIGNATURE-----