Coder un truc rapide en C - Page 3

" Impérativement, au moins un switch d'optimisation (-Os, -O2 ou -O3). "
C'est bien, mais largement pas impératif. En revanche, ce qu je trouverais plutôt impératif, moi, c'est le -WAll, et après, ne rien laisser passer

ben disons qu'en général, un -WAll qu'on laisse passer, c'est un futur probleme qui arrivera. Même si certains warnings ne sont pas à virer dans certains cas -rares -.

Martial Demolins (./58) :
Ouep, mais c'est pareil non, c'est pas un pointeur sur 4 octets?

effectivement sur TI il se trouve que ça fait 4 octets donc ça marche, mais tu vas te prendre des warnings pour ne pas avoir utilisé le bon type ^^

onur (./33) :
Dura lex sed lex.

Euh, tu sais ce que ça veut dire ? parce que je vois pas le rapport...

sinon moi en général je mets -W -Wall (il y a des warnings bien pratiques dans -W aussi)

Lol, parce que tu cherches un sens à mes posts? :s

Martial> Le C permet justement quelques abstractions pour ne pas avoir besoin de réfléchir à ce à quoi correspond réellement un type (en termes de taille et d'organisation), donc n'essaie pas de traficoter des trucs avec tes connaissances en TI-68k, car le C étant, grâce à ce mécanisme d'abstraction, multi-plateforme, te bidouilles risquent de ne pas marcher.

C'est intéressant de savoir ce qui se passe à l'échelle du matériel (ça permet de comprendre plus facilement par exemple le rôle d'un pointeur), mais c'est pratique aussi de pouvoir s'en abstraire.

Autrement dit, quand tu utilises une fonction qui attend un objet de type FILE * quelque part, donne-lui ce qu'elle attend sans même te poser de question sur ce qu'il y a derrière ce type FILE.

Zephyr (./64) :

Martial Demolins (./58) :
Ouep, mais c'est pareil non, c'est pas un pointeur sur 4 octets?

effectivement sur TI il se trouve que ça fait 4 octets donc ça marche, mais tu vas te prendre des warnings pour ne pas avoir utilisé le bon type ^^

Sur win64 la taille d'un unsigned long est différente d'un pointeur

d'où le "sur TI il se trouve que"

oui, oui. C'était juste pour info.

Martial Demolins (./68) :
Ok, c'est mon manque d'habitude, je trouve ça bizare de pouvoir coder sans savoir exactement ce qui va se passer en mémoire ou dans le proc

c'est vrai que les règles spéciales genre les tableaux C qui se transforment automagiquement en pointeurs sont pas forcément évidentes à piger au début, mais avec un peu d'habitude tu sauras exactement à quoi correspond en mémoire chaque bout de code (enfin, tu ne pourras prédire l'ordre des variables sur la pile ou quelles variables seront mises dans des registres, mais ça on s'en fout un peu)

Martial Demolins (./58) :
Ouep, mais c'est pareil non, c'est pas un pointeur sur 4 octets?

Le C est (relativement) type safe, il ne fonctionne pas comme l'assembleur (où 4 octets sont 4 octets).

De plus, je te signale que long ne fait pas toujours 4 octets, ce sont 8 octets sur x86_64.

PpHd (./69) :
Sur win64 la taille d'un unsigned long est différente d'un pointeur

Oui, et ça casse pas mal de programmes ça. Sous GNU/Linux, un pointeur rentre toujours dans un unsigned long, et il y a des logiciels qui utilisent ça (mais pas comme essayait de le faire Martial, les types ne sont évidemment pas interchangeables). Cela dit, c'est crade, le standard C99 prévoit le type ptrint_t pour ça. Mais comme peu de programmes utilisent le C99...

kim (./61) :
" Impérativement, au moins un switch d'optimisation (-Os, -O2 ou -O3). "C'est bien, mais largement pas impératif.

Euh si... -O0 (le mode par défaut) génère du code exécrable (gros et rame à fond), c'est inutilisable sauf à la limite pour pouvoir déboguer plus facilement (mais il y a pas mal de travail effectué dans GCC et GDB pour pouvoir déboguer convenablement un programme optimisé, donc même là, -O0 sert rarement).

En revanche, ce qu je trouverais plutôt impératif, moi, c'est le -WAll, et après, ne rien laisser passer

-Wall, pas -WAll

Sally (./65) :
sinon moi en général je mets -W -Wall (il y a des warnings bien pratiques dans -W aussi)

C'est obsolète -W, dans les GCC récents, c'est -Wextra (mais -W est toujours accepté pour des raisons de compatibilité antérieure).

Sinon, je conseille aussi -Wwrite-strings (c'est aussi mis par défaut dans TIGCC).

K² > safe type... vite fait quoi.. quand on déclare
typedef int reg_id, il fait aucune différence entre f(int a) et g(reg_id a), et on peut appeler avec f(b) que b soit int ou reg_id... Ca parait pas trop grave comme ca, mais cest surtout problématique en C++ où on peut faire des surcharges du genre f(int a) et f(reg_id a). En Ada, il appelerait la bonne fonction en connaissance du type de b quand on met f(b).

Sinon, j'aimerais en savoir plus sur le 64 bit mais je vais créer un topic pour ca je pense bientot.

march=i386 -mtune=generic

Arg et apres tu parle d'optimiser

onur (./74) :
K² > safe type... vite fait quoi..

C'est pour ça que j'ai dit "relativement".

Godzil (./75) :

march=i386 -mtune=generic

Arg et apres tu parle d'optimiser

* Ça crée des binaires réutilisables.
* Ça ne sert à rien de mettre un -march plus élevé en pratique (sauf pour des logiciels comme le noyau Linux ou glibc qui ont des versions 686).
* -mtune=generic donne un résultat à peu près aussi rapide que -mtune=le CPU qu'on utilise et nettement plus rapide que -mtune=le mauvais CPU.
Les ingénieurs de Red Hat qui travaillent sur GCC savent ce qu'ils font. Et au moins nos binaires ne sont pas compilés pour 2 ou 3 architectures totalement différentes en même temps.

c'est crai que les "ingénieur" de chez RedHa sont des dieux qui font la pluie et le beau temps...

Godzil (./77) :
c'est crai que les "ingénieur" de chez RedHa sont des dieux qui font la pluie et le beau temps...

Ils s'y connaissent certainement plus que toi. Tu as quoi comme chiffres pour prouver que ça vaut le coup d'utiliser tes -march et -mtune? Les développeurs de Red Hat ont donné leurs chiffres pour -mtune=generic. Cherche dans les archives de la mailing list de GCC si tu ne me crois pas.

Martial > Si tu as peur de pas contrôler ce qui se passe en mem en programmant en C, utilise la commande tigcc -S (c'est bien ça?) __sans optimisations__ pour voir le source assembleur généré. Tu remarqueras que c'est pas si étrange que ça ensuite, tu mets les optimisations, mais là le code devient difficile à comprendre, parfois

Kevin Kofler (./79) :

Godzil (./77) :
c'est crai que les "ingénieur" de chez RedHa sont des dieux qui font la pluie et le beau temps...

Ils s'y connaissent certainement plus que toi. Tu as quoi comme chiffres pour prouver que ça vaut le coup d'utiliser tes -march et -mtune? Les développeurs de Red Hat ont donné leurs chiffres pour -mtune=generic. Cherche dans les archives de la mailing list de GCC si tu ne me crois pas.

je me demande bien alors quel est l'interet de mettre de tele options, vu que de tte maniere le progres c'est obsolete et que optimiser le code pour un CPU qui a moins de 20ans ça ne sert a rien

-mtune=generic n'optimise pas pour les CPU d'il y a 20 ans, il optimise pour les CPU actuels sans favoriser d'architecture particulière... Les options que donnent Kevin sont un bon choix si les éventuels gains apportés par les instructions SSE & compagnie sont négligeables par rapport à la simplicité d'un binaire commun à tous les x86 ^^

certe, mais kevin ne dit pas sa, kevin dit

"Personne n'a besoin dutilise les autre options, ya que mois qui ai raison, les autres ont tord"

et les optimisation par architecture prennent aussi en compte les cycles & co qui peuvent etre tres différent suivant les archi. autant une optimisation pour 386 peut fortement faire ralentir sur un Pentium...

Godzil (./83) :
certe, mais kevin ne dit pas sa, kevin dit

"Personne n'a besoin dutilise les autre options, ya que mois qui ai raison, les autres ont tord"

Il a pas dit ça Il a juste donné les options par défaut qu'il y avait sur sa config...

et les optimisation par architecture prennent aussi en compte les cycles & co qui peuvent etre tres différent suivant les archi. autant une optimisation pour 386 peut fortement faire ralentir sur un Pentium...

Ben c'est justement pour ça 1) que c'est pas fait pour les 386 mais pour les CPU modernes, même si le code reste compatible 386 ; 2) que c'est pas fait pour une architecture particulière mais pour un mix de toutes les architectures modernes : gcc choisira un truc qui fait 5 cycles partout plutôt que 4 cycles sur une architecture et 50 cycles sur une autre...

Une fois de plus, ce n'est pas une optimisation pour 386! Tu n'as pas l'air de comprendre la différence entre -march et -mtune. C'est une optimisation pour CPU moderne générique (-mtune=generic), en n'utilisant que des instructions qui sont disponibles partout (-march=i386, le 386 ayant été le premier CPU 32 bits de la série). Mais les modèles pour cycles, scheduling etc. sont ceux pour CPUs modernes (mais pas un CPU particulier au point où on pessimise pour les autres => generic)!

Cest bien ce que je dit, on force GCC a proposer/utiliser des spécificité de CPU qui on 20ans

pas des spécificités des CPU, des spécificités du jeu d'instruction ; et puis les CPU modernes sont faits pour rester très efficaces même avec ce jeu d'instruction, donc j'ai du mal à voir quel code C "peut fortement faire ralentir sur un Pentium" (./83) quand il est compilé pour le jeu d'instruction 386 plutôt que Pentium... (à condition que -mtune soit pour Pentium et pas 386, évidemment)

Cela dit, il y a des gens qui conseillent d'utiliser -mtune=i386 (ou -mcpu=i386, c'était l'ancien nom) parce que ça donne souvent du code plus petit.

Oui parce que entre avoir du code optimisé mais qui se voit pas a l'execution et avoir du code pas optimisé mais super petit qui evite de trop swapper le choix est vite fait pour la majorité des cas

A cette échelle là c'est pas une question de swap. C'est de l'ordre de quelques ko tout au plus.
En revanche ça peut jouer sur les lignes de cache ^^