Pointeurs sur fonctions (question pointue !) - C++ - Programmation
Marsh Posté le 07-11-2002 à 05:17:23
Une indirection, un simple accès mémoire, difficile de faire plus rapide.
Je ne pense pas que les processeurs aillent jusqu'a prédire/se souvenir des branchements variables.
Non pas que ce soit compliqué à faire, mais simplement que c'est peu utilisé comparé au boucles normales.
La mémoire cache à elle seule doit apporter beaucoup.
Si il y en a qui savent, je suis aussi intéressé.
Marsh Posté le 07-11-2002 à 12:53:46
me rapelle que dans une doc AMD, ils disaient que l'athlon était pas super super copain avec les indirect calls. Bon, ca fait un an que j'ai lu ladite doc, fodrait que je la relise pour etre sur de pas dire des grosses conneries
Marsh Posté le 07-11-2002 à 15:57:48
Plus rapide que quoi ? Là est le Pb !
Généralement la seule alternative ce sont des switch (quand il y a une alternative)
et là tu opposes une solution couteuse de complexité constante à une solution peu couteuse linéaire ! plus il y a de choix plus le pointeur de fonction est une bonne methode...
Du point de vue optimisation le switch beneficie des previsions de branchement et d'une optimisation à la compilation (inline par exemple)...
Maintenant la solution du pointeur de fonction est celle qui se trouve derriere les methodes virtuelles...
Marsh Posté le 07-11-2002 à 16:20:54
Merci pour toutes vos réponses !
J'ai eu exactement ce que je voulais : d'une part : la solution proche de la machine, et de l'autre, la solution C/C++ (surtout C++ pour les méthodes virtuelles) Nikel !
Pour répondre à ta question, benb, je voulais comparer l'appel à une fonction via un pointeur de fonction vis à vis d'un appel classique ...
Marsh Posté le 07-11-2002 à 16:27:19
theShOcKwAvE a écrit a écrit : Merci pour toutes vos réponses ! J'ai eu exactement ce que je voulais : d'une part : la solution proche de la machine, et de l'autre, la solution C/C++ (surtout C++ pour les méthodes virtuelles) Nikel ! Pour répondre à ta question, benb, je voulais comparer l'appel à une fonction via un pointeur de fonction vis à vis d'un appel classique ... |
Dans ce cas là tu perds (en performances bien sur) à passer par un pointeur, c'est à peu pres certain, sauf si le compilo peut predire la valeur du pointeur... mais dans ce cas quel interet ?
Les dernieres versions de comilo/linker disent qu'il sont capable de generer certaines fonction inline meme sans que la fonction ait été déclarée inline, c'est à priori une possibilité d'optim que tu perds à priori aussi...
Ensuite il faut se poser la question de la maintenance... et là à priori le pointeur de fonction est plus difficile à lire que l'appel direct... (sauf cas d'un gros switch... )
Marsh Posté le 07-11-2002 à 16:44:06
Bien ... Imagine un prog dans lequel tu gagnes énormément à utiliser des pointeurs de fonctions. Imaginons par exemple que tu as plusieurs manières de remplir un triangle : face pleine + éclairage, éclairage + texture, éclairage/bump+texture+alpha [ce n'est qu'un exemple ... je rappelle ! ]
Suivant la config, vu que c'est du soft, on va choisir d'utiliser tel ou tel niveau d'effets. Le pointeur sera donc choisi dans les options au début et c'est tout. Après, à chaque fois que tu voudras dessiner un triangle, tu utiliseras la fonction ciblée par le pointeur. Dans ce cas, est-ce qu'un proc serait capable de voir que le pointeur n'est pas modifié par aucune des lignes dans le pipeline et qu'il peut, par conséquent prédire que la suite des instructions se trouve à l'adresse désignée au lieu de se gaufrer bêtement au moment du saut ? (je ne pense pas que le compilo puisse gérer ca ...)
Marsh Posté le 07-11-2002 à 16:50:15
theShOcKwAvE a écrit a écrit : Bien ... Imagine un prog dans lequel tu gagnes énormément à utiliser des pointeurs de fonctions. Imaginons par exemple que tu as plusieurs manières de remplir un triangle : face pleine + éclairage, éclairage + texture, éclairage/bump+texture+alpha [ce n'est qu'un exemple ... je rappelle ! ] Suivant la config, vu que c'est du soft, on va choisir d'utiliser tel ou tel niveau d'effets. Le pointeur sera donc choisi dans les options au début et c'est tout. Après, à chaque fois que tu voudras dessiner un triangle, tu utiliseras la fonction ciblée par le pointeur. Dans ce cas, est-ce qu'un proc serait capable de voir que le pointeur n'est pas modifié par aucune des lignes dans le pipeline et qu'il peut, par conséquent prédire que la suite des instructions se trouve à l'adresse désignée au lieu de se gaufrer bêtement au moment du saut ? (je ne pense pas que le compilo puisse gérer ca ...) |
Ben tu vois que ton choix est bien pointeur de fct ou switch, car en lieu et place de ton pointeur de fonction, tu peux utiliser une fonction qui fera le switch en fct d'une variable...
typiquement c'est un cas l'application du poymorphisme et donc des fonctions virtuelles...
Il y a des tests qui permettent de comparer la difference d'execution prog C (basé sur switch et boucles) et un prog C++ (basé sur du polymorphisme) et certains complio donnent un ratio de 1... (Intel icc pour Linux)...
Marsh Posté le 07-11-2002 à 20:39:19
a mon avis faut profiler avant de pouvoir dire ce qui rallentira ton application.
Un appel de fonction via un pointeur ne cause pas de souci s'il
ne cause pas de cache miss et est infiniment plus rapide
que l'appel aleatoire a des fonctions "normales" mais qui ne sont pas dans le cache. C'est d'ailleurs pour ca que parfois le code "optimise pour les performances" se fait battre par le code "optimise pour la taille de l'executable"..
Pour ce qui est de ton probleme de choix a l'execution, malheureusement, le C++ ne propose pas tant de latitude quant a la facon dont seront appele les fonctions definies dynamiquement.
Et le pointeur de fonction reste le plus rapide (en theorie pas moins rapide qu'un switch et de toute facon beaucoup plus flexible).
LeGreg
Marsh Posté le 07-11-2002 à 01:18:33
Alors ... Est-ce rapide ? Est-ce que les procs peuvent prédire le branchement lors des appels au travers de variables contenant les adresses des fonctions ? A quelles conditionsn si il y en a ?
Merci d'avance !
---------------
last.fm