Discussion :

[sunn14]

en fait la boucle for est moin complexe que la boucle while donc il vaut mieux utiliser l for

[kromartien]

Je ne crois pas qu'une explication aussi simpliste soit satisfaisante. for et while sont simplement deux formalismes différents pour un fonctionnement algorithmique identique. C'est l'implémentation qui fait toute la différence comme il est dit précédemment.

[souviron34]

J'aimerai savoir si la compression de l'écriture permet d'améliorer la vitesse du code, par exemple les exemples "programmeur expérimenté" que j'ai pu voir dans le livre langage C ANSI Ritchie et Kernighan (les incrémentations dans les expression conditionnelles et de test, mettre des fonctions à valeur de retour dans des expressions de test, du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ( MonPointeur=malloc(128) )

).

NON

Non seulement c'est moins lisible, mais le code généré est exactement le même que si c'était plus clair.... Pourquoi faire compliqué quand on peut faire plus simple ?

Dans quelle mesure le compilateur influence-t-il la vitesse d'exécution avec deux sources portables différentes et optimisées, ie un programme peut être "optimisé" pour un compilateur mais pas pour l'autre et inversement.

N'est ce pas au compilateur de réaliser les optimisations au maximum dans la mesure du possible ?

Il influence beaucoup, mais pas sur les choses qu'on cite depuis le début de ce thread. Il peut par exemple "inliner" des choses, définir comme constantes locales d'autres , éventuellement (si on est sur une machine adéquate) parallèliser certaines choses.

Donc oui il faut utiliser les flags d'optimisation, lorsqu'on veut optimiser. Mais non seulement ça ne suffit pas, mais de plus à certains niveaux cela peut être dangereux (par exemple, compiler un générateur de MPEG avec le maximum d'optimisation ne produit pas un code correct).

Les additions sont moins coûteuses que les multiplications je crois, cependant, le langage C est fait pour nous éviter d'avoir à replonger dans la conception de fonctions "opérateurs élémentaires".
Ainsi, il serait ridicule je crois de bondir parce que l'on réalise une division sur long double avec les processeurs PC actuels. Tout dépend alors en fait (je crois) du compilateur et de la plateforme sur laquelle servira le code compilé.

D'une part on ne parlait pas des additions, mais des différences entre multiplications et divisions.

Ensuite, si, lorsque on doit faire de la VRAIE optimisation, il faut prendre en compte les particularités , comme on le dit, par exemple d'une division par rapport à une multiplication. Par exemple en recherche génomique, en modèlisation 3D, etc... on peut passer de 6 heures de traitement à 3 minutes, juste par des trucs comme on dit depuis le début. Et c'est une bonne différence, entre attendre une journée le résultat d'un run, ou pouvoir en faire 60 par jour... Donc non il ne serait pas ridicule de bondir....
Les exemples ci-dessus te prouvent que déjà juste ça te divise le temps de calcul par 2...

La typage fort du langage C est une des caractéristiques qui en font un langage compilé propre aux optimisations. L'optimisation réelle ne peut se faire qu'en ayant une connaissance intime des caractéristiques et des possibilités à la fois du microprocesseur, du compilateur et du langage C, ce qui forme pour quelqu'un comme moi (~débutant) un domaine d'exploration assez vaste.

oui c'est en général un domaine extra pointu. Il faut très bien connaître l'algorithmie, les différentes instructions possibles, les concepts sous-tendus par telle ou telle opération, et en général très bien possèder son domaine.

Comme dit dans un des posts plus haut, on peut même aller jusqu'à coder des parties directement en assembleur..

[GuiYom00]

NON
oui c'est en général un domaine extra pointu. Il faut très bien connaître l'algorithmie, les différentes instructions possibles, les concepts sous-tendus par telle ou telle opération, et en général très bien possèder son domaine.

Comme dit dans un des posts plus haut, on peut même aller jusqu'à coder des parties directement en assembleur..

Je suis tout à fait d'accord avec ce qui a été dis jusqu'à présent concernant ces "petites" optimisations. Je rajouterai aussi une partie concernant la mémoire et les pointeurs afin de réduire le temps nécessaire quand on se déplace au sein de tableaux.

Mais concernant l'assembleur j'aurai tendance à mettre un petit bémol.
Le bémol étant que, pour le calcul scientifique, de plus en plus de machines sont 64bits et donc avec un codage assembleur différent...
De plus, à moins de vraiment bien connaitre l'assembleur, les compilos actuels fourniront bien souvent un code bien meilleur.
A choisir j'aurai tendance à préférer l'utilisation des fonctions SSE2 intrinseques, au moins elles marchent en 32 et 64bits ou de manière générale tout faire pour que le code soit vectorisable et maintenant parallélisable vu que les systèmes double coeurs se répandent de plus en plus.
Mais la aussi apres se pose la question de la portabilité et sur quel type de machine le code est destiné

Edit : petit rajout sur la portabilité

[mchk0123]

A choisir j'aurai tendance à préférer l'utilisation des fonctions SSE2 intrinseques, au moins elles marchent en 32 et 64bits ou de manière générale tout faire pour que le code soit vectorisable et maintenant parallélisable vu que les systèmes double coeurs se répandent de plus en plus.

Oui et Non !

Oui pour le côté jeu d'instruction identique, car effectivement les instructions 64 bits permettent de traiter des données volumineuses et des fonctions compliquées plus rapidement. Ca c'est le côté "survol" de la question.

Non pour le côté équivalence des optimisations, car même si l'ABI SSE2 fait que les instructions sont identiques en 32 et 64 bits, d'autres choses ont changés dans la micro-architecture des processeurs faisant que les compilateurs C/C++ en plus d'avoir à gérer un nouveau jeu d'instruction et de registres doivent mettre à jour leur règles d'optimisation : le guide AMD64 fait 400 pages tout de même !

Donc ça va prendre surement pas mal de temps de voir tous les compilateurs C/C++ passer en 64 bits et le faire proprement. Je parierais ma chemise que les premières versions des compilos. 64bits soient moins performants que les compilos 32 dernières versions (je parle des compilos gratuit là).

Donc en attendant les programmeurs ASM 64 vont avoir la vie belle

[GuiYom00]

oui on est d'accord que dans une optique programmeur pur asm64, il a encore de beaux jours devant lui je ne dis pas le contraire. Mais par exemple ne pas oublier que l'asm inline n'est plus possible sur système 64bits
Je parlais toujours dans le cas d'un code "C" majoritaire avec quelques parties asm

Non pour le côté équivalence des optimisations, car même si l'ABI SSE2 fait que les instructions sont identiques en 32 et 64 bits, d'autres choses ont changés dans la micro-architecture des processeurs faisant que les compilateurs C/C++ en plus d'avoir à gérer un nouveau jeu d'instruction et de registres doivent mettre à jour leur règles d'optimisation : le guide AMD64 fait 400 pages tout de même !

Donc ça va prendre surement pas mal de temps de voir tous les compilateurs C/C++ passer en 64 bits et le faire proprement. Je parierais ma chemise que les premières versions des compilos. 64bits soient moins performants que les compilos 32 dernières versions (je parle des compilos gratuit là).

bon ca va tu as précisé gratuits Meme si a ce niveau la j'ai entendu que intel sur amd64 donnait des resultats pas mal du tout (non testé de mon cote)
Pour gcc la je pense que les prochaines versions permettront de mieux voir ce qu'il en est...

[mchk0123]

GuiYom00 je peux te demander ce que tu fait dans la vie ?

[GuiYom00]

Oui oui tu peux
Je travaille dans une fac et j'ai développé aussi un code de calcul pour des résolutions d'équations.
Et la je suis justement dans une phase d'optimisation enfin c'est plus "vaste" que ca, car cette phase est accompagnée d'une phase de parallelelisation du code...
Et donc entre autre justement j'ai regardé un peu differents compilateurs pour voir les gains que je pouvais avoir.

Pourquoi cette question, j'ai dis des énormités?

[souviron34]

bah je ne citais l'assembleur que pour augmenter mon argument vis à vis de Kromartien, qui pensait qu'on pouvait laisser faire le compilo pour l'optimisation.

Et que donc, quand on veut faire de la vraie optimisation, il faut jouer sur tout ce sur quoi on peut jouer..