A ces compilateurs .... - Linux et OS Alternatifs
Marsh Posté le 14-05-2002 à 13:10:27
tiens, tu veux le tuner, amuse-toi !
http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html
http://gcc.gnu.org/onlinedocs/gcc- [...] html#SEC13
Marsh Posté le 14-05-2002 à 13:46:04
gcc -O2
ou -O3
ou -O9
...
info gcc
Marsh Posté le 14-05-2002 à 15:50:54
-O2 est recommande
apres pour les options, les plus utilisees sont:
-fomit-frame-pointer -funroll-loops
pour les specifiques au cpu: -march=athlon (a partir de la 2.96)
-mmmx, -m3dnow, -msse a partir de la 3.1(en dev)
Marsh Posté le 14-05-2002 à 16:20:28
les miennes que j'aimes bien :
-O9 -funroll-loops -ffast-math -malign-double -fomit-frame-pointer -fno-exceptions
sans oublier le fameux -mcpu=tonarch -march=ton arch
si tu cherches la stabilité et la puissance/optimisation brute du code, regardes egcs... Si tu cherches l'utilisation des dernières technos (sse, ...), cherches gcc3
Marsh Posté le 14-05-2002 à 16:26:10
PinG a écrit a écrit : les miennes que j'aimes bien : -O9 -funroll-loops -ffast-math -malign-double -fomit-frame-pointer -fno-exceptions sans oublier le fameux -mcpu=tonarch -march=ton arch si tu cherches la stabilité et la puissance/optimisation brute du code, regardes egcs... Si tu cherches l'utilisation des dernières technos (sse, ...), cherches gcc3 |
avec ces options, il faut pas esperer debuguer après !
Marsh Posté le 14-05-2002 à 16:29:20
ha oui, autre chose, tu peux striiper le binaire, pour l'accélérer encore... qaund je pense que beaucoup de distros ne le font pas...
Sous Debian c'est fait pour les branches stable et testing...
Marsh Posté le 14-05-2002 à 16:30:17
manu025 a écrit a écrit : avec ces options, il faut pas esperer debuguer après ! |
-ggdb, mais c'est pas gagné
et puis anyway, tu codes/teste sans optimisations, et tu release avec optimis+strip
Marsh Posté le 14-05-2002 à 16:46:19
PinG a écrit a écrit : ha oui, autre chose, tu peux striiper le binaire, pour l'accélérer encore... qaund je pense que beaucoup de distros ne le font pas... Sous Debian c'est fait pour les branches stable et testing... |
C'est fait pour toutes les branches... Et en fait, ça accélère un peu le chargement mais l'intérêt majeur est de réduire la taille des exécutables.
Marsh Posté le 14-05-2002 à 17:14:50
Jar Jar a écrit a écrit : C'est fait pour toutes les branches... Et en fait, ça accélère un peu le chargement mais l'intérêt majeur est de réduire la taille des exécutables. |
non, pas sur tous les pkg pour sid, justement pour pouvoir avoir des reports de certains trucs...
Et puis ca accélère... pourquoi? parcequ'un near jump a toujours été vachement plus rapide qu'un far jump qui de plus redemande la chargement d'un segment, et touti quanti... Franchement, quand dans une appli t'en est à jouer avec les codes bloats et le padding, tu est interressé par le striping...il faut savoir que dans les elfs, TOUS les symboles ne sont pas dans des segments à part...
Marsh Posté le 14-05-2002 à 17:41:06
PinG a écrit a écrit : Et puis ca accélère... pourquoi? parcequ'un near jump a toujours été vachement plus rapide qu'un far jump qui de plus redemande la chargement d'un segment, et touti quanti... Franchement, quand dans une appli t'en est à jouer avec les codes bloats et le padding, tu est interressé par le striping... |
Effectivement, je n'avais pas pensé à ça.
Mais à ce niveau, on doit beaucoup moins y gagner qu'avec la compilation statique (enfin, uniquement sur i386, les architectures ne sont pas aussi limitées).
Marsh Posté le 14-05-2002 à 17:53:32
Jar Jar a écrit a écrit : Effectivement, je n'avais pas pensé à ça. Mais à ce niveau, on doit beaucoup moins y gagner qu'avec la compilation statique (enfin, uniquement sur i386, les architectures ne sont pas aussi limitées). |
mouaip, c'est clair... mais les libs en statique, d'un coté ca alourdi lezimbrec, de l'autre ca rends les méthodes locales au process...
enfin bon, même avec les ldcache et les preloads, le statique est plus performant...
sinon, je pense qu'vant de s'inquiéter à c, les codeurs devraient apprendre à coder... quand je pensse que beaucoup de daemons forkent alors qu'ils pouraient faire la même chose avec des threads (bcp plus rapide à instancier, la gestion d'un pool de threads est plus aisée, la communication entre les process plus rapide, ...); ou bien ceux qui utilisent des sockets TCP pour se connecter en local (les sockets unix c'est pour les chiens?)
donc bon...
Marsh Posté le 14-05-2002 à 18:23:07
et je pense aussi que kmfcsdfc cfldsjkskjfd vlksdjvl.
pas vous ?
(oké, je sors... )
Marsh Posté le 14-05-2002 à 18:44:58
PinG a écrit a écrit : mouaip, c'est clair... mais les libs en statique, d'un coté ca alourdi lezimbrec, de l'autre ca rends les méthodes locales au process... enfin bon, même avec les ldcache et les preloads, le statique est plus performant... sinon, je pense qu'vant de s'inquiéter à c, les codeurs devraient apprendre à coder... quand je pensse que beaucoup de daemons forkent alors qu'ils pouraient faire la même chose avec des threads (bcp plus rapide à instancier, la gestion d'un pool de threads est plus aisée, la communication entre les process plus rapide, ...); ou bien ceux qui utilisent des sockets TCP pour se connecter en local (les sockets unix c'est pour les chiens?) donc bon... |
peut-être mais si tous les codeurs devaient avoir minimum bac+5 (ce qui est loin d'être le cas), il y aurais plus de bug ! On se ferait chier !
Marsh Posté le 14-05-2002 à 19:18:43
PinG a écrit a écrit : enfin bon, même avec les ldcache et les preloads, le statique est plus performant... |
Uniquement sur cette architecture pourrie qu'est ia32...
Citation : sinon, je pense qu'vant de s'inquiéter à c, les codeurs devraient apprendre à coder... |
Ah bin ça ma bonne dame, c'est pas demain la veille. Enfin, on arrive toujours à trouver pire ailleurs.
Marsh Posté le 14-05-2002 à 19:37:52
en tout cas vu la taille des executables en statique, moi je le ferais pas!!!!
Marsh Posté le 14-05-2002 à 20:01:19
manu025 a écrit a écrit : peut-être mais si tous les codeurs devaient avoir minimum bac+5 (ce qui est loin d'être le cas), il y aurais plus de bug ! On se ferait chier ! |
j'ai pas compris le sens de ton post
Perso, je n'ai pas BAc+5, et je dois avouer que mes trois ans après le bac de formation d'ingénieur ne m'ont absolument RIEN apportées techniquement... donc les études
Marsh Posté le 14-05-2002 à 22:50:19
PinG a écrit a écrit : j'ai pas compris le sens de ton post Perso, je n'ai pas BAc+5, et je dois avouer que mes trois ans après le bac de formation d'ingénieur ne m'ont absolument RIEN apportées techniquement... donc les études |
Je voulais juste dire que c'est pas le mec qui sort d'un iut (en général un codeur) qui va te faire des threads dans ces programmes, du moins s'il n'as pas encore l'xp. Il y a quand même certaines notions difficiles à comprendre si t'as pas des bases (en système notamment) assez avancées.
Marsh Posté le 14-05-2002 à 23:00:34
manu025 a écrit a écrit : Je voulais juste dire que c'est pas le mec qui sort d'un iut (en général un codeur) qui va te faire des threads dans ces programmes, du moins s'il n'as pas encore l'xp. Il y a quand même certaines notions difficiles à comprendre si t'as pas des bases (en système notamment) assez avancées. |
ok... mais :
Marsh Posté le 15-05-2002 à 20:33:31
Pendant ce temps la, je suis alle lire ailleur ...
d´ailleur ya un post recent au sujet de gcc 3,1 ... alire ....
Bon, sinon, pour les heureux possesseurs de proc intels ... intel a sortit un compilo pour vous .... c icc (intel c compileur)
il est normalement en en licence qui permet de ne pas payer si on est un particulier ... donc a prendre d´office, il arrache gcc haut la main ....
Evidemment il ságit de comparer les fichiers compiles ... pas la vitesse des compilo ... ca on s´en fout ....
sites off :
intelCPP : developer.intel.com/software/products/compilers/c50/linux/
Sinon, on peut aussi executer un optimisateur de code comme IPO ...
www.heise.de/newsticker/data/hes-11.11.01-000/
Marsh Posté le 15-05-2002 à 20:57:11
PinG a écrit a écrit : mouaip, c'est clair... mais les libs en statique, d'un coté ca alourdi lezimbrec, de l'autre ca rends les méthodes locales au process... enfin bon, même avec les ldcache et les preloads, le statique est plus performant... sinon, je pense qu'vant de s'inquiéter à c, les codeurs devraient apprendre à coder... quand je pensse que beaucoup de daemons forkent alors qu'ils pouraient faire la même chose avec des threads (bcp plus rapide à instancier, la gestion d'un pool de threads est plus aisée, la communication entre les process plus rapide, ...); ou bien ceux qui utilisent des sockets TCP pour se connecter en local (les sockets unix c'est pour les chiens?) donc bon... |
Puique avec ta culture si forte et ton savoir tous faire
t as qu a coder toi
pis si c bien ben Linus les integra peut etre pis participe au GNU/hurd c encore une meilleurs occasion pour montrer ce qu ec ets un vrai codeur
a moins tu sait po coder donc t as critique se serait a chier
mais ca m etonnerai
[jfdsdjhfuetppo]--Message édité par asphro le 15-05-2002 à 20:58:15--[/jfdsdjhfuetppo]
Marsh Posté le 15-05-2002 à 21:00:29
le truc intel c est interressant la je vasi voir qui qui aime les intel
Marsh Posté le 15-05-2002 à 21:03:33
mais c des compilateurs c++, il egre le c aussi ....
car c po exactemnt pareille le c/c++
et je vois po la license dont tu parle aussi a part evaluation et buy ou encore "If you've already downloaded the 'Non-Commercial Unsupported' version of the compiler, click here to purchase the Full Version License or to upgrade your current product."
[jfdsdjhfuetppo]--Message édité par asphro le 15-05-2002 à 21:06:23--[/jfdsdjhfuetppo]
Marsh Posté le 15-05-2002 à 21:08:19
ReplyMarsh Posté le 15-05-2002 à 22:26:48
asphro a écrit a écrit : Puique avec ta culture si forte et ton savoir tous faire t as qu a coder toi pis si c bien ben Linus les integra peut etre pis participe au GNU/hurd c encore une meilleurs occasion pour montrer ce qu ec ets un vrai codeur a moins tu sait po coder donc t as critique se serait a chier mais ca m etonnerai |
alors :
[jfdsdjhfuetppo]--Message édité par PinG le 15-05-2002 à 22:27:05--[/jfdsdjhfuetppo]
Marsh Posté le 15-05-2002 à 22:40:40
NounouRs a écrit a écrit : il est normalement en en licence qui permet de ne pas payer si on est un particulier ... donc a prendre d´office, il arrache gcc haut la main .... |
C'est faux. Dans certaines conditions, gcc est même plus rapide.
Le choix doit dépendre de ce qu'on fait (et le compilateur Intel n'étant pas libre, et jamais vraiment écrasant niveau performances, le mien est vite fait).
Par contre, un truc qui pourrait intéresser certains, c'est qu'Intel a fait un compilateur Fortran 95 pour Linux, gratuit et sous la même licence. Vu l'état d'avancement de g95 et le prix des autres compilateurs, c'est une grande nouvelle pour ceux qui sont encore condamnés au Fortran (oui, ça existe).
Marsh Posté le 16-05-2002 à 00:23:05
Marsh Posté le 16-05-2002 à 10:03:29
Moi j'ai une quesion sur le but de ce post.
Pourquoi vouloir prendre un autre compilo que gcc (ou g++) ?
Ca fait 6 ans que j'utilise Linux, et ça fait 6 ans que je vois gcc dans tous les sens!
C'est le compilo GNU/linux par excellence, il est très performant et parfaitement éprouvé. Il est capable de sortir un code hyper débuggable comme un code hyper optimisé, je vois donc pas ce qu'il peut envier aux autres.
Si il n'y plus gcc, il n'y a plus Linux (enfin à mon avis).
Ce serait comme dire que Gnome fonctionne sans gtk, ou KDE sans qt.
.... en attente d'un avis très objectif qui me contradirait ...
Marsh Posté le 16-05-2002 à 10:21:43
PinG a écrit a écrit : les miennes que j'aimes bien : -O9 -funroll-loops -ffast-math -malign-double -fomit-frame-pointer -fno-exceptions sans oublier le fameux -mcpu=tonarch -march=ton arch si tu cherches la stabilité et la puissance/optimisation brute du code, regardes egcs... Si tu cherches l'utilisation des dernières technos (sse, ...), cherches gcc3 |
Est-ce possible de mettre ces params de compilations dans ( par exemple ) une variable d'environnement pour qu'a chaque compilation, on n'ai pas besoin de se retapper ces options.
Marsh Posté le 16-05-2002 à 10:25:13
euuh c'est plutot agressif comme params de compilation
ça doit pas fonctionner sur pas mal d'applis
A+
Marsh Posté le 16-05-2002 à 10:30:10
tu peux les mettre dans les variables
CFLAGS et CXXFLAGS
mais je te le conseille pas
A+
Marsh Posté le 16-05-2002 à 10:51:34
Babouchka a écrit a écrit : tu peux les mettre dans les variables CFLAGS et CXXFLAGS mais je te le conseille pas A+ |
OK pour les variables.
J'ai 2 PIII ( 650MHz et 1400MHz ) à "optimiser", quel serait les meilleurs flags pour optimiser ( pas besoin de trucs pour le debugage ) sans que ce soit super extreme avec des trucs limite instable ?
Marsh Posté le 16-05-2002 à 10:52:09
Babouchka a écrit a écrit : euuh c'est plutot agressif comme params de compilation ça doit pas fonctionner sur pas mal d'applis |
Tu m'étonnes, surtout le -O9. Au-delà de -O3, rien ne garantit que les instructions seront exécutées dans le bon ordre.
Ça peut marcher.
Marsh Posté le 16-05-2002 à 10:54:48
DrDS a écrit a écrit : J'ai 2 PIII ( 650MHz et 1400MHz ) à "optimiser", quel serait les meilleurs flags pour optimiser ( pas besoin de trucs pour le debugage ) sans que ce soit super extreme avec des trucs limite instable ? |
Je dirais -O3 -march=i686, avec éventuellement quelques -ftrucmachin, à voir.
Marsh Posté le 16-05-2002 à 10:55:09
DrDS a écrit a écrit : OK pour les variables. J'ai 2 PIII ( 650MHz et 1400MHz ) à "optimiser", quel serait les meilleurs flags pour optimiser ( pas besoin de trucs pour le debugage ) sans que ce soit super extreme avec des trucs limite instable ? |
L'optimisation à la compilation ne peut pas rendre instable, c'est juste une mauvaise programmation. Sinon, les flags de PinG ont l'air pas mal du tout. De toutes façons, dès lors que tu met un -O9, tu as déjà le pire code !
Marsh Posté le 16-05-2002 à 14:31:23
't1, ça a l'air interressant tout ça ... vous pouvez donner plus de détail sur ce que ça fait, et sur les risque qu'on prend à les utiliser (je connaissais que le -march=architecture jusqu'ici)
je voudrais notamment capter ce que sont les -0X : j'ai regarder le manuel, mais ils mettent pour -03 que c'est comme -02 mais avec finline_function en plus, et je sais pas ce que c'est.
allez-y, expliquer (et pis dite les truc interressant en plus dans le 3.X
Marsh Posté le 16-05-2002 à 14:33:36
minusplus a écrit a écrit : tiens, tu veux le tuner, amuse-toi ! http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html http://gcc.gnu.org/onlinedocs/gcc- [...] html#SEC13 |
Marsh Posté le 17-05-2002 à 19:39:47
Le meilleur (pour les performances) c'est Icc, le compilateur d'Intel.
En tant que particulier, tu peux le telecharger et l'utiliser gratuitement.
Et si tu as la bonne idee d'utiliser Gentoo Linux, il n'y a qu'une petite ligne a changer dans ton make.conf pour que tout ton systeme soit recompile avec Icc.
Marsh Posté le 17-05-2002 à 19:45:43
axey a écrit a écrit : Le meilleur (pour les performances) c'est Icc, le compilateur d'Intel. En tant que particulier, tu peux le telecharger et l'utiliser gratuitement. |
Cf. mon message plus haut.
Marsh Posté le 14-05-2002 à 13:03:48
Quel est le meilleur compilateur C (meme quest pour le C++) a l'heure actulle sous Linux ?
Et pour le cas de gcc .... est il possible de lui passer des parametres d'optimisation de qualite ou bien de rapidite ??? un peu comme le mp3 quoi !
Parceque j'ai entendu dire que gcc3 est donne des executables qui tournent moins vite que le gcc2.
Alors, je me dis, il y a surement des parametres a lui passer pour qu'il fasse un meilleur travail ?!?
Kit a compiler un truc .. autant que ce soit bien fait