Bonjour,
 
Je cherche à écrire un programme de simulation numérique orientée scientifique. Le temps de calcul est en règle générale assez long. Etant donné que je connais un peu le C j'ai décidé de l'écrire en utilisant ce langage. Ceci dit j'ai quelques questions:
 
1- Le Fortran est-il plus rapide pour un même algorithme?
 
2- Doit-on privilégier des #define ou des const pour déclarer les constantes? Je suppose que l'utilisation des define ne monopolise pas la mémoire et les const oui...?
 
3- Pour gagner en temps doit-on travailler en float ou en double? Logiquement float mais il semblerait que ce n'est pas toujours vrai...
 
4- En terme de rapidité, est-il plus intéressant de modulariser le programme avec des fonctions internes ou externes ou de faire les calculs directement (ex au lieu de calculer Y=carre(X); on écrit directement Y=X*X
 
5- De même X*X est-il plus rapide que pow(X,2)?
 
Merci
 
Je suis vivement intéressé par toutes les remarques relatives au sujet de l'optimisation en rapidité d'exécution  

Houlala. Que de fausses questions.
Bon en premier lieu, avant de mettre les mains dans le camboui il faut se poser la question : mon algo est il performant ? Si on pense qu'il est a bloc, que l'algo en lui meme est imbatable, alors on descent au niveau en dessous, pas avant.
 
2/ #define, const, ca reviendra au meme pour le compilo
3/ tu gagneras un peu en passant de double a float, car les deplacements mémoire seront plus petits. Déplacement et pas calcul, car la FPU travaille en interne sur 80bits
4/ Tu peux faire des fonctions inline pour ce genre de sport. Privilige quand meme la lisibilité sur les performances, on a tot fait de s'en mordre les doigts sinon
5/oui, il sera plus rapide. pow(), c'est tres general, comme fonction
 
 
l'optimisation ca se passe comme ca:
 
1/on fait un profil du programme  
2/on etudie ce profil : ou est ce que je perds le plus de temps
3/on optimise la partie reponsable de la lenteur
4/on retourne a 1
 
on attaque pas au bol et au pif. Ne pas se battre et faire un truc horrible pour virer deux appels de fonction, mais deja virer les grosses lacunes.
 

Je suis d'accord avec toi sur qualité de l'algo et le profiling du prog. Je voulais juste quelques informations théoriques de principe sur l'optimisation d'un algo de calcul scientifique, merci pour ta contribution!

ca depend de beaucoup de chose, profile d'abord on en reparleras + tard
 
"Premature optimisation is the root of all evil" Knuth.

1 - Non, et il n'est pas plus lent non plus.
 
2 - C'est comme tu préfere. #define et const donneront le même binaire.
 
3 - Je pensais au contraire que double était en général plus rapide, car il correspond au type manipulé par ton CPU. Mais en fait je n'en sait rien.
 
4 - Du plus rapide au plus lent : 1) Faire le calcul sur place sans appel de fonction 2) Appeler une fonction dans le même binaire 3) Appeler une fonction dans un autre objet (librairie). Il y a une "grosse" différence entre 1) et 2), et une "petite" différence entre 2) et 3).
 
5 - Oui, d'une part à cause de 4), et d'autre part parce que pow() est une fonction générique qui est capable de faire autre chose qu'élever au carré. On ne peux pas faire plus rapide que "X*X".
 
Sinon comme l'a dit chrisbk, ce ne sont pas forcément de bonnes questions. Utilises un profiler.

Ca c'est du C++. GROFRED veut faire du C donc pas question de "inline".
 

Tu es certain ? Le #define est remplacé par le préprocesseur donc le compilo voit une valeur numérique. Alors que le "const" reste qd même une variable non ? Je sais pas trop ce qu'il en ressort..

 
je fais du C au taf et j'ai du inline de ci de la...

Tu compiles ton C avec "gcc" ou "g++" ? Parce que un programme écrit en C mais compilé avec "g++" est analysé comme du C++. Et s'il contient du "inline" il n'y aura aucun pb mais restera considéré comme C++...

Bonne question mon cher Jean-Louis, en fait je fais make et j'ai aucune idée de quel brol se lance derriere. Cela dit j'ai bien droit a toutes les merdes du C comme l'obligation de decl les vars en debut de bloc

et y'a pas du inline en c99 ?

 
http://www.greenend.org.uk/rjk/2003/03/inline.html

 
Hum... je viens d'apprendre qq chose.
Il y a un truc dont j'ai horreur en informatique, c'est que les choses changent très vite. Un jour tu apprends le C; puis plus tard tu apprends le C++ et on te dit "en c++ c'est super on peut faire du inline etc..." puis un beau matin tu te réveille et on te dit "pov atardé, le inline existe aussi en C"...
 
Merci à "chrisbk" et à "Evadream -jbd" de m'avoir montré à quel point je retardais...  

Le C99 ça date... de 99
 
Il y a un article sympa sur Kuro5hin si tu veux voir les changements apportés

 
il me semblait pourtant que la precision de certaines instructions pouvaient etre parametré suivant le type utilisé

Les titre en CAP ca le fais pas ....

 
bin tu peux switcher la précision de la fpu (remember l'init de dx7), mais c'est bien tout, si je dis pas trop de conneries

Merci pour toutes ces informations. Comme on me l'a conseillé, je vais privilégier la lisibilité et la modularité. Pour le temps de calcul je verrais après avec un profiler.