Dans certains cas, des considérations de performance encouragent à ne pas découper en sous-fonctions.
Je suis d'accord que c'est assez spécifique, mais sur des algo de DSP ou de calcul haute performance (HPC), [et non, on ne fait pas/plus que de l'assembleur et du FORTRAN dans ces cas-là !] on peut manipuler beaucoup de boucles imbriquées autour d'un bout de calcul très simple.
Le coût d'un appel de sous-fonction peut alors ne pas être négligeable : empilage des paramètres, branchement + delay slot, et au retour dépilage des valeurs de retour et second branchement + delay slot => ca fait plus d'une dizaine de cycles.
Autour d'un papillon de FFT qui fait moins de 10 cycles, ca peut doubler le temps de calcul !
Par ailleurs on veut souvent laisser le plus de sémantique possible au compilateur, pour qu'il puisse détecter du parallélisme, réordonner les boucles pour optimiser le remplissage des caches, ou bien rendre la fonction inline ... Les trucs à éviter pour que ca marche c'est la linéarisation des tableaux multi-dimensionnels, et l'arithmétique de pointeurs.
Un exemple d'optimisations de ce genre : la librairie Graphite http://gcc.gnu.org/wiki/Graphite , intégrée dans GCC 4.4 http://linuxfr.org/2009/04/21/24809.html
< radote >
La limitation à 80 colonnes, c'était à cause des cartes perforées.
Il n'y a que ceux qui codent encore en FORTRAN 77 (les pauvres) qui subissent encore cette limitation.
< /radote >
[^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne
Posté par Jimmy . En réponse au sondage La taille de l'indentation de mon code source (tab ou espace). Évalué à 2.
Je suis d'accord que c'est assez spécifique, mais sur des algo de DSP ou de calcul haute performance (HPC), [et non, on ne fait pas/plus que de l'assembleur et du FORTRAN dans ces cas-là !] on peut manipuler beaucoup de boucles imbriquées autour d'un bout de calcul très simple.
Le coût d'un appel de sous-fonction peut alors ne pas être négligeable : empilage des paramètres, branchement + delay slot, et au retour dépilage des valeurs de retour et second branchement + delay slot => ca fait plus d'une dizaine de cycles.
Autour d'un papillon de FFT qui fait moins de 10 cycles, ca peut doubler le temps de calcul !
Par ailleurs on veut souvent laisser le plus de sémantique possible au compilateur, pour qu'il puisse détecter du parallélisme, réordonner les boucles pour optimiser le remplissage des caches, ou bien rendre la fonction inline ... Les trucs à éviter pour que ca marche c'est la linéarisation des tableaux multi-dimensionnels, et l'arithmétique de pointeurs.
Un exemple d'optimisations de ce genre : la librairie Graphite http://gcc.gnu.org/wiki/Graphite , intégrée dans GCC 4.4 http://linuxfr.org/2009/04/21/24809.html
< radote >
La limitation à 80 colonnes, c'était à cause des cartes perforées.
Il n'y a que ceux qui codent encore en FORTRAN 77 (les pauvres) qui subissent encore cette limitation.
< /radote >