Discussion :

[befalimpertinent]

-faut toujours privilégier la récursion (par ex l'appel de fonction récursives) sur les boucles for.

Plutôt l'inverse en fait. La récursivité est très puissante mais aussi très dangereuse (explosion de la pile d'appel). On cherche la plupart du temps au contraire à dérécursifier des algos pour les optimiser (ce qui se fait facilement quand on a bien compris le but de l'algo en question).
Ce qui est vrai en imperatif (C) ou en objet (c++) ne l'est pas forcément en fonctionnel par exemple (Caml,F#) et vice versa.

[loufoque]

Les compilateurs C et C++ font aussi de la tail call optimization hein...
Le problème avec la récursion c'est pas la consommation mémoire, c'est les appels de fonction eux-mêmes.

C'est dans les options du compilateur que ca se règle ca?

Non.
Je l'ai déjà dit cent fois : écris ton code de manière à ce qu'il soit impossible de calculer certaines choses à la compilation. Par exemple en utilisant des variables volatiles ou en prenant une variable depuis l'entrée standard.

[deubelte]

c'est bizarre parce qu'en VBA, on m'a toujours dit qu'il fallait utilisé la récursion. Ca semble faux en C.
Mais intuitivement, ca me semblait être plus performant.

[moldavi]

Bonjour.

Tu souhaites réduire les temps de calcul. Comme beaucoup de personnes le disent ici, il est difficile de faire mieux que le compilateur de nos jours. Et en tout cas passer en revue des parties de code en assembleur pour gagner quelques nonasecondes est contre-productif.

Mise à part effectivement si tes boucles sont mal conçues, mais ça ne semble pas être le cas, et vu que tu n'utilises pas un algorithme très compliqué, il n'y a peut-être pas de moyen d'augmenter significativement les temps de calcul.

Une méthode à tester et vu que tu utilises des "double" et des fonctions comme "pow", serait d'utiliser les fonctionnalités des processeurs dédiées à ce genre de calcul. Pour les processeurs Intel, tu as le Intel SDK, par exemple.
Par contre ça limite ton programme à un type de processeur. Et d'ailleurs le compilo le fait peut-être déjà pour certains calculs...

[white_tentacle]

Lors de la compilation, le switch case sera de toutes manières remplacer par des test booléens (par contre, du stricte point de vue de la lecture, le gain est énorme ), et ceci, sans compter sur le fait qu'un switch case ne peut fonctionner qu'avec des valeurs entières (ou assimilées), ce qui disqualifie le switch case dans une série de cas

Un gros avantage du switch, c'est que, sur un enum, le compilateur sait vérifier qu'on traite bien tous les cas. Très pratique, surtout lorsqu'on en vient à modifier un enum pour lui rajouter une valeur.

[3DArchi]

Un gros avantage du switch, c'est que, sur un enum, le compilateur sait vérifier qu'on traite bien tous les cas. Très pratique, surtout lorsqu'on en vient à modifier un enum pour lui rajouter une valeur.

C'est vrai avec gcc, mais avec Visual Express, non. J'ai pas d'avertissement en ce sens.

[loufoque]

Un switch, c'est O(1), une série de tests booléens, c'est O(n)...
Un switch c'est bien évidemment plus rapide oui. Dans le cas où il y a peu de cas, ça génerera probablement des branchements, parce que ça reste plus rapide que des tables même si ça ne passe pas à l'échelle.

[3DArchi]

Un switch, c'est O(1), une série de tests booléens, c'est O(n)...

Tu peux préciser? Parce que, avec Visual Express en release pour un switch de 3 cas, j'ai :

Code :

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

1
2
3
4
5
6
7
 
	sub	eax, 0
	je	SHORT $LN3@main
	sub	eax, 1
	je	SHORT $LN2@main
	sub	eax, 1
	jne	SHORT $LN4@main

Ca reste du O(n)?

[white_tentacle]

Si tu rajoutes plus de cas, et avec un bon optimiseur, il y a des chances que le compilateur passe par une "jump table" (pas sûr du terme français), qui est donc O(1).

Chose qu'il ne fera probablement jamais avec des if else imbriqués.

[3DArchi]

Si tu rajoutes plus de cas, et avec un bon optimiseur, il y a des chances que le compilateur passe par une "jump table" (pas sûr du terme français), qui est donc O(1).

Chose qu'il ne fera probablement jamais avec des if else imbriqués.

Effectivement, en augmentant le nombre de cas, je passe effectivement par une table intermédiaire.