Appel chaîné de fonction et code compilé

Bonjour à toutes et à tous,

réfléchissant sur le mix de deux énormes applications similaires qui doivent à terme pouvoir être lancées indépendament ou bien ensemble je me pose de nombreuses questions sur quel serait le mieux dans l'organisation de ce projet pour garder en lisibilité tout en gardant les performances.

J'ai donc pensé à l'appel succéssif de fonction, comment les compilateurs gèrent-ils cela ? Cela rentre-t-il dans les optimisations automatiques ?

J'entend par là la chose suivante :

Code:

---

1 2 3

void maFonction(int val){ maFonction2(val); }

---

L'appel de maFonction() à maFonction2() va-t-il générer deux changements de pile ou bien une optimisation va-t-elle exécuter directement maFonction2 en évinçant du code asm l'appel à maFonction ?

Cordialement,
xTG.

Salut,

Honnêtement, je ne me tracasserais pas trop de ce genre de considération dans un premier temps.

D'abord, parce que le temps nécessaire à l'appel d'une fonction en lui-même n'est que rarement rédibitoire par rapport au temps de fonctionnement d'une fonction, mais surtout parce que cela dépend vraiment des ciroconstances:

D'un coté, il se peut que le compilateur effectue effectivement deux appels de fonctions, si aucune des deux n'est inlinée, mais de l'autre, les fonctions inlinées ne font que demander au compilateur de remplacer l'appel de la fonction par son code.

Si le code résultant dépasse un certain nombre d'instruction processeur, le compilateur peut en effet parfaitement décider de ne pas inliner une fonction pourtant définie comme inline ;)

Enfin, Ce genre de considération entre vraiment dans ce que l'on peut appeler les optimisations prématurées :

Avant de t'inquiéter de ce genre de "détails", veilles déjà à ce que toutes tes fonctions fassent ce que tu attends effectivement de leur part, et veilles à ce que tes algorithmes soient efficaces.

Si, une fois que tu es sur que tu as (correctement :D) implémenté les algorithmes les plus efficaces, tu éprouves encore des problèmes de perfs, il sera toujours temps de passer un profiler afin de voir s'il y a effectivement des appels de fonctions dont l'appel seul représente un cout en temps inacceptable ;)

Bah le souci c'est que je suis pas l'auteur des deux énormes codes.
Donc je serai bien incapable de dire si ils sont optimisés ou non (je pars du principe que oui vu qu'ils sont pour des systèmes critiques tout de même) mais surtout je n'ai pas 6 mois devant moi pour les étudier.
Ma problématique c'est plutôt de faire une sorte de launcher pour interfacer le lancement de ces deux applications sans aller bouffer sur leurs performances. (Si je vous dis qu'une préemption du système peut foutre la merde ça vous parle mieux ? :mouarf:)

D'où cette question qui semble à priori tirée par les cheveux pour les 99% des développeurs mais qui est hautement sensible dans mon cas.

Je sais pas si j'arrive à me faire comprendre et à expliquer véritablement mon problème. En gros on me demande de faire du code fantôme jusqu'à une certaine tolérance. :mrgreen:

Oui, oui, j'ai bien compris ton problème...

Mais il faut être conscient que ce n'en est en réalité pas un :p

Un appel de fonction, cela se traduit généralement par deux instructions processeur au début et une ou deux instructions processeur à la fin de la fonction, à peine plus s'il s'agit de fonctions virtuelle.

Le cout (en terme de temps d'exécution) d'un appel de fonction est donc marginal par rapport au cout en temps d'exécution de la plupart des fonctions et il y a, pour ne donner qu'un exemple, beaucoup à parier qu'une simple allocation dynamique de la mémoire ou que la construction d'un objet complexe soit beaucoup plus chronophage que le simple fait d'avoir une fonction qui appelle une fonction.

Le problème auquel tu es confronté est que tu as deux programmes qui ont été développé de manière distincte.

Si tu dois faire en sorte qu'ils "se rejoignent quelque part", il n'y a pas 36 solutions : il faut soit que tu passes par une "façade", qui a un cout d'appel marginal, soit que tu prenne la décision pure et simple de ... redévelopper tout ou partie d'un des projets de manière à ce qu'il soit compatible avec l'interface de l'autre.

A priori, ce serait quand meme se donner beaucoup de mal pour rien ;)

Dans l'ordre des problèmes qui peuvent nuire aux performances, celui des appels de fonction doit se situer quelque part entre la 50 eme et la 100 eme place...

Si problème de performances il y a (car tu n'es même pas encore sur à l'heure actuelle qu'il y aura effectivement des problèmes de performances !! ;) ), il y aura sans doute 50 ou 100 causes pour lequel le gain en terme de performances sera largement supérieur à celui que tu pourrais obtenir en évitant un appel de fonction.

Je ne dis pas que tu as tord de te poser la question, mais je dis que, dans l'ordre des priorités, il y a très certainement des questions autrement plus utiles à se poser ;)

Je pense que :

• Déjà, avec un bon compilateur, il ne devrait y avoir aucune différence
• Si tu es vraiment dans un cas où ce genre de considérations de performances importe (système temps réel dur, avec contraintes très fortes), je pense que tu as d'autres problèmes :
  
  • Ce genre de code fonctionne rarement sur des systèmes où tu as de bon compilateurs, donc ma première remarque est potentiellement fausse, mais qui sait... A vérifier...
  • Ce genre de code n'est pas prévu pour tourner en compagnie d'autre code. Par exemple, il fait très attention à l'utilisation de la mémoire, du cache, des registres.... et le fait d'exécuter un autre code au beau milieu peut totalement invalider ces optimisations
• Tu évoques la notion d'un système et du fait qu'il a la possibilité de préempter ton application. J'en déduis que tu n'es en fait probablement pas dans un cas temps réel dur avec contraintes très fortes :)

Citation:

---

Envoyé par JolyLoic

• Tu évoques la notion d'un système et du fait qu'il a la possibilité de préempter ton application. J'en déduis que tu n'es en fait probablement pas dans un cas temps réel dur avec contraintes très fortes :)

---

Le système se limite à l'ordonnanceur et au gestionnaire d'interruption au grand mot, donc non je ne parlai pas de système en tant que système d'exploitation. Mais ta déduction/simplification est un peu biaisée je trouve. Si pas de préemption cela veut dire qu'il n'y a aucune données externes à ton système. Ce qui n'est pas une grande majorité de ce qu'on conçoit faut bien l'admettre...

Là où le bas blesse c'est justement qu'on m'a demandé de joindre ces deux programmes et qu'on ne dépasse pas les 1% de performance. Sauf que je ne sais absolument pas comme vous l'avez dit si ces deux programmes ne vont pas se tarader la mémoire chacun... J'espère sincèrement qu'ils tapent principalement dans le cache L1 parce que sinon tout ce que je pourrai rajouter ne serait que bagatelle.

Bon il y a pas trente-six moyen au final... Je vais faire une façade la plus simple possible avec appel des deux sous-programme avec des paramètres statiques et voir les temps que j'obtiens. Si déjà avec ça on explose je pourrai retourner que c'est pas possible sans recoder les applis.

Citation:

---

Envoyé par transgohan

Le système se limite à l'ordonnanceur et au gestionnaire d'interruption au grand mot, donc non je ne parlai pas de système en tant que système d'exploitation.

---

J'avais vraiment compris système comme système d'exploitation, d'où ma mauvaise interprétation.

Citation:

---

Envoyé par transgohan

Bon il y a pas trente-six moyen au final... Je vais faire une façade la plus simple possible avec appel des deux sous-programme avec des paramètres statiques et voir les temps que j'obtiens. Si déjà avec ça on explose je pourrai retourner que c'est pas possible sans recoder les applis.

---

Je commencerais comme ça, en effet, mais je ne sais pas si c'est suffisant. Dans certains domaines, il ne suffit pas de tester et mesurer, il faut aussi démontrer que dans tous les cas possibles, les performances sont respectées. Mais je n'ai jamais travaillé dans un tel contexte, et ne peux t'aider plus.