Discussion :

[Fractal LLG]

Bonjour

Le programme que je suis entrain de faire (solveur de Sokoban) a de façon très simplifiée la structure suivante :

Code :

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

1
2
3
4
5
6
let rec solve (c:configuration) = 
   let possibles_moves c = ... (* renvoie la liste des mouvements effectuables dans cette configuration *)
      ...
      ...
   in
   List.iter (fun m -> solve (effectue c m)) (possibles_moves c);; (* où effectue c m renvoie la configuration c après avoir effectué le mouvement m *)

Étant donné que la fonction solve va être appellée des centaines de milliers de fois durant l'exécution, je me demandais comment le compilateur traitait la définition locale de la fonction possible_moves.
Est-ce qu'il va relire et se traduire la définition de possibles_moves à chaque appel de solve sans s'apercevoir que c'est toujours la même chose, ou bien est-ce qu'il va ne la lire qu'une seule fois, la première fois qu'il la rencontre?
Parce que dans le premier cas je dois perdre un temps considérable à la relire à chaque fois alors que rien n'a changé dans sa définition.
Qu'en pensez-vous?

(Edit)
NB : Ma fonction possibles_moves est récursive terminale, je ne sais pas si ça peut vous être utile.

Fractal

[Jedai]

Tu as remarqué que OCaml était compilé, et pas interprété ? Je pense que ça réponds à ta question non ? Pour plus de détail, regarde comment OCaml compile les closures, et ne t'inquiète pas, il ne les recompile pas à chaque fois !!!

--
Jedaï

[alex_pi]

Je trouve franchement que tu te poses beaucoup trop de questions de performances... Qu'est ce que tu dirais de simplement tenter de programmer le plus naturellement et clairement possible, et commencer à te prendre la tête seulement le jour où tu constateras des problèmes de performances ? Fais un peu confiance au compilo OCaml : évidement qu'il ne "recompile" pas une fonction à chaque fois qu'elle est appelé ! Ce serait completement abominable dans un langage fonctionnel où l'on passe son temps à appeler des fonctions, et il est généralement admis que les performances sont environ deux fois moins bonnes que celle du C, donc rassure toi, c'est bien fait :-)

[Garulfo]

Complètement d'accord avec Alex_Pi.

C'est amusant de voir que quand on débute on se préoccupe énormément de la performance. Et en prenant de la maturité on se rend compte que c'est souvent secondaire à une bonne conception ^_^

[InOCamlWeTrust]

C'est amusant de voir que quand on débute on se préoccupe énormément de la performance.

Hmmmmm... on verrait de meilleurs algorithmes, sinon !

Et en prenant de la maturité on se rend compte que c'est souvent secondaire à une bonne conception ^_^

Pas d'accord : on peut concilier tous ces paramètres :

- de vrais bons algorithmes
- une bonne conception
- un code clair et lisible
- un code simple

Souvent, les gens pensent que lisibilité et optimisation sont antagonistes, mais je pourrais leur montrer, par A + B, que c'est tout simplement archi-faux, que ce soit en OCaml, en C ou en tout ce que tu veux. A algorithme égal, un code petit et clair sera toujours plus performant qu'un code "optimisé", obscur.

Maintenant, pour tirer le meilleur parti de OCaml en termes de performances, IL SUFFIT D'ECRIRE DE PETITS CODES CLAIRS.

[Garulfo]

Hmmmmm... on verrait de meilleurs algorithmes, sinon !

Pas forcément justement. On se dit que les petites améliorations de codes sont plus importantes que les algorithmes.

Pas d'accord : on peut concilier tous ces paramètres :

- de vrais bons algorithmes
- une bonne conception
- un code clair et lisible
- un code simple

Tu lis des choses que je n'ai pas dit. Je suis complètement d'accord avec toi. J'ai dit que la performance est secondaire à la bonne conception. En effet, puisque les problèmes de performances sont dus à des algorithmes déficients la majorité du temps, on apprend à faire un effort sur la conception avant tout. Qui a dit que c'était antagoniste ? Secondaire ne veut ni dire négligeable ni opposé.