Salut,
 
Bon bah, quasiment tout est dit dans le sujet !!
Le code est optimiser à fond, pas de malloc inutiles etc (Char à la palce de Int etc ...)
J'aurais voulu savoir comment optimiser plus avec Gcc.
J'utilise la ligne de compilation suivante :
 
" gcc -I. -W -Wall -pedantic -ansi -O3 -g3 -Wstrict-prototypes -S -fsigned-bitefields -fno_default_inline -p -Winline -mcpu=i386 "
 
Je vous demande ca car je pense qu'il y a sans doutes plus d'options pour optimiser que -O3, j'aimerais bien que vous éclairiez ma lanterne XD.
 
Merci d'avance !

Char plus rapide que int ? Vous avez fait des tests ?
Théoriquement c'est le contraire car au niveau  interne, les opérations se font au minimum sur 16 bits et quand il n'y a que 8 bits, cela oblige à un masquage. Mais de toutes manières la différence est tellement minime entre les deux que cela ne devrait pas se sentir sauf si vous faîtes du calcul vraiment intensif.
Eviter les malloc est en effet une bonne chose. Vous les remplacer par quoi ? Par des données statiques, des données sur la piles, en registres ?
Si vous postiez ici la partie de votre programme qui prend le plus de temps, il y aurait très probablement quelques personnes qui pourraient vous proposer des optimisations.

Cela est completement dependant de l'architecture cible, et ca n'est pas vrai dans le cas de l'architecture intel classique (les pc, quoi).  
 
kaiser >> ton code n'est pas assez rapide? as-tu essaye de le profiler pour voir ce qui prenait du temps?

 
En faite le but c'est de faire un programme qui resoud des sudoku ( Pour l'instant le teste est fait sur 10 maps d'affile. A la fin se sera entre 100 et 1000 maps), mais le plus rapidement possible.
Notre but c'est d'optimiser un code avec Bruit de Force.
Quand je dis optimisation, c'est niveau de la taille de l'executable, de la bouffe de memoire lors de l'execution, et du temps d'execution.
 

 
Le char a la place de int c'est surtout pour la bouffe lors de l'execution, mais j'ai remis les int pour l'optimisation du temps d'execution.
Apres oui les mallocs sont change par des donnees statiques.

? faut qu'ça pète quoi.
 

En général, le compilateur ne joue pas sur les trois tableaux. Puisque tu utilises GCC ; celui-ci a des options pour optimiser en vitesse (-O3), et pour optimiser en taille (-Os). Pour ce qui est de la consommation mémoire, je ne suis pas sur, mais il me semble que GCC n'influe pas trop là-dessus.
 
Ce que tu à l'air de vouloir, c'est de l'optimisation en vitesse, -O3 est à priori un bon choix. Après GCC a bien d'autres options, mais pour te conseiller, il faudrait que tu donnes la version de GCC que tu utilises.  
 

Mais même sans connaitre la version de GCC, tu peux enlever -g3, c'est le plus haut niveau d'information de debuggage, ton binaire va alors bien maigrir. Enlève aussi -p quand tu ne profile pas.
Tu peux essayer -fomit-frame-pointer -DNDEBUG si tu n'a pas besoin de debugger, et que tu penses utile de désactiver les assert.
 
au lieu de -mcpu=i386, tu peux essayer -march=xxx en spécifiant ton processeur - cf man gcc.
 
Et -Wl,-s pour stripper le binaire plus -Wl,-O1 pour optimiser le link.

ça fait plaisir les gens qui ont le soucis de la performance avant d'écrire un programme correct. Et laisse tranquille se malloc, si c'est lent, c'est que tes algos sont pourris. Va pas chercher ailleurs l'explication de tes lenteurs ailleurs (enfait je suis sur que t'es entrain de te faire mousser parce que ton machine mets 0.2s au lieu de 0.1s). Ce n'est ni la faute à gcc, ni par ignorance du flag magic. -O2 est très bien. Cherche dans ton code, profiler à l'appuie.
 
Mouarf, j'avais pas lu le détail sur 'niveau de la taille de l'executable, de la bouffe de memoire lors de l'execution'.
 
Sérieusement, ça sert à rien de changer tes flags de compilation ou de sur-pourir ton code.

Ah ouais, tu sais ce que tu fais. -I. chapeau. -g3 et -p du code optimisé avec les infos de debug, c'est pour optimiser la taille de l'exécutable je suppose. -O3 aussi apparemment. -S c'est pour sortir l'assembleur ... -fsigned-bitefields n'existe pas. -fno_default_inline non plus. -mcpu=i386 est soit la valeur par défaut te gcc voire une valeure plus contraignante permettant moins d'optimisation. Beau travail

 
Hola du calmes !
Je commence dans la prog donc faut etre indulgent.
Dejas :
 
-C'est un travail de groupe.
-C'est pas ma ligne de commande.
-Je ne fais pas le debug ( Donc le -g3 et tous et tous c'est pas mon probleme ).
-J'ai pas le droit de changer l'algo je doit me DEMERDER avec un algo en Bruit de Force.
-Pour -fsigned-bitfields ca existe : http://www.linux-kheops.com/doc/ma [...] gcc.1.html. Edit : CTR + F ca mange pas de pain.
 
Apres si tu peux pas comprendre j'y peu rien moi    
Apart ca.
Le code est passe de 2sec32 a 0sec42 en changeant la ligne de compilation.

 
PS : Je comprend pas pouquoi -O3 apelle -O2 et que -O2 n'appelle pas -O1.
Edit : C'est pas facil d'aprendre a comprendre le code d'un autre, de le debugger et de l'optimiser !

 
Oui, et non pas *bite*fields.
 

Qu'est-ce qui te fais croire ça ? Et Qu'est-ce qui t'empêches de consulter la documentation à ce sujet ?
 

 
Mais c'est pas de ma faute si mon partenaire ne sait pas recopier . Si ?
C'est mon groupe donc je leur fais confiance... C'est un crime ?
 
On m'a demande de poste pour avoir des reponses a des question, et c'est tous se que je recole...
Merci, vraiment Merci.
 

 
J'ai consulte la documentation.
Je sais que -O avec -O1 active certaines choses.
Puis j'ai retire le -mcpu=XXX, on aura pas de testes sur des ancienes machines.
Et je suis oblige d'utiliser le GCC du systeme, le binaire de la version 4.1.2 n'est pas compatible Sun et Alpha.
 
La derniere version revient a ca :
 

C'est quoi le "etc" ?
T'as calculé la complexité de ton code, ainsi que la complexité optimale pour ce genre de problème ?
 
Bref: as-tu la preuve que ton algo est *le* plus rapide ?
Parce qu'étrangement, les gens se soucient avant de O3 et après de leur code ...

 
Comme je l'ai dis plus haut, je dois faire avec se que l'on me donne.
Donc l'algo c'est pas mon probleme.
Le but c'est surtout d'aprendre a comprendre un Code qui ne m'apartient pas et de bien utiliser GCC.

okay.
 
Tu penses que ca va faire avancer le sujet ?

 
C'était sans importance, et je me contrefout de la cause.
 

J'ai passé 5 minutes à te répondre, et je le regrette. Pour ma part, j'ai fini de te répondre.
 
 

C'est une marque de respect envers les gens qui te lisent. C'est donc primordial.

 
C'est aussi ma façon de faire. C'est bien plus facile de régler un problème avec des flags de compilation, que de repenser un algorithme.

Je dirais qu'on a plus de chances en général de voir un programme s'executer plus rapidement en optimisant l'algo que le compilo; j'ai pas été très loin dans les options de compilation, mais j'ai déjà eu des vitesse d'execution décuplée en optimisant boucles, tests ou affectations. Des options de compilations permettent un tel ratio ?

 
Et se que tu as fais c'est pas un manque de respect de ta part ?
Encore j'aurais écrit en langage SMS je veux bien.
Mais la c'est du grand n'importe quoi, le but c'est de se faire comprendre, et le faite de mettre que 1 seul P à la place de 2 ne va pas changer la façon dont ton cerveau va l'interpréter à part si tu es autistes.
 
Enfin le sujet n'est pas là.
 
edit :
 

 
J'ai pas vraiment fais de gros programmes à part un Raytracer mais sans optimisations à la compilation.
Mais sur se projet, je suis quand même passé de 2sec32 à 0sec42. Il est possible qu'avec des optimisations de boucle et à la compilation tu puisses perdre le double de temps d'exécution.
 
edit : Becherel ou pas ?  

Pardon ?

Exactement, et le français est le bon outil pour ça.

N'importe quoi.

Si, aussi.

Tu vois, moi j'essaye de discuter avec des gens et de trouver des solutions à des problèmes.
Et ne vas pas me dire que tu essayes de trouver des solutions à mes problèmes d'orthographes.
Si tu n'as jamais fais de fautes d'orthographes dans ta vie c'est génial pour toi. J'ai écrit ca en vitesse.
J'aime bien la communauté HFR, mais là.... enfin bon.
Mais si tu viens pas ici pour faire avancer le sujet, je t'invite à sortir.

T'inquiètes, je réponds pas aux mecs qui n'ont pas de respect pour leurs lecteurs.

"Bruit de Force", t'es sûr ?

Cadeau:
 
http://www.onlamp.com/pub/a/onlamp [...] eters.html

 
Oui, enfin c'est comme ca qu'ils appellent cette technique.
Ca consiste a piler / dépiler etc....., la Méthode Barbar...
 

 
Merci, je vais lire ca de très près.

"Brute force" alors, pas "bruit de force".

 
Ok.
La prochaine fois je leur demanderais d'articuler, et en même temps j'irais me racheter des oreilles.  

Merci d'avoir relever ça, ça permet mieux percevoir le contexte.
C'est quoi l'optimisation "bruit de force" ?

 
Tu veux pas dire "Force Brute" (Brute Force) plutôt que "Bruit de Force" ?
Si c'est le cas, tu ferais mieux d'utiliser un meilleur algorithme plutôt que d'optimiser salement un algo dont tu sais qu'il est mauvais pour ton problème.
 
le Sudoku est un bête problème de CSP qui se résoud facilement et avec une complexité raisonnable avec un algo comme Bucket Elimination. Au pire tu peux toujours rester sur un Brute Force mais passe un pré-filtrage de ton espace des valeurs à essayer pour retirer un max de valeurs idiotes.
 

Zut, déjà vu par d'autres ;-)

Oui je sais on m'a déjà repris sur le " Brute Force ", maintenant je le sais    
Puis c'est bon le projet à été clos et soutenue se matin !
Merci à tous de votre aide tchao.
 
See you.
 
PS : Problème résolu avec _darkalt3_.

 
Je ne connais pas d'options miracles pour les flags de compilation, mais c'est sur qu'il y a une nette différence entre une compilation avec optimisation et une compilation sans.
 
Après, j'essaye juste d'être faignant/productif ; si je peux régler un problème de performance sans mettre en péril mes tests de non régression, je ne vais pas m'en priver. Et j'observe qu'il y a d'avantage de risque en touchant au code qu'aux options du compilateur -- pour peu qu'on sache à peu près ce que l'on touche.