Mouais. À mon avis, c'est un pis-aller, non ? Il vaut mieux une bonne réflexion en amont sur le code en lui-même plutôt qu'un recours à des règles strictes et inflexibles... qui me semblent plus réservées au contrôle - a priori - de la cohérence du code.
Pas seulement. Le typage permet en partie de s'affranchir des problemes
d'alias. Par exemple, si tu passes un pointeur sur un int et un pointeur sur un float a une fonction, le compilateur a le droit de supposer que les deux pointeurs pointent sur des zones distinctes en memoire, et donc qu'il a le droit de reordonnancer les acces, et de triturer le code jusqu'a faire des choses plus efficaces.
L'air de rien, lorsqu'on a des fonctions generiques, c'est pratique. C'est moins bien que de pouvoir dire explicitement que deux tableaux sont disjoints (ben oui, c'est un concept de Fortran qui manque en C ca, et restrict n'y suffit pas), mais c'est quand meme fortement sympathique dans quelques cas.
Cote optimisations, comme d'habitude, c'est la version suivante de GCC qui devrait etre bien. Enfin, pas comme d'habitude, puisque la ils vont allegrement franchir deux versions: gcc 3.4 a des chances d'etre aussi calamiteux que gcc 3.3 et on nous promet monts et merveilles pour gcc 3.5
L'air de rien, lorsqu'on a des fonctions generiques, c'est pratique. C'est moins bien que de pouvoir dire explicitement que deux tableaux sont disjoints (ben oui, c'est un concept de Fortran qui manque en C ca, et restrict n'y suffit pas), mais c'est quand meme fortement sympathique dans quelques cas.
Cote optimisations, comme d'habitude, c'est la version suivante de GCC qui devrait etre bien. Enfin, pas comme d'habitude, puisque la ils vont allegrement franchir deux versions: gcc 3.4 a des chances d'etre aussi calamiteux que gcc 3.3 et on nous promet monts et merveilles pour gcc 3.5.
In article <20040106120619.22ee849b.21.101@free.fr>,
Vincent <10.50@free.fr> wrote:
Mouais. À mon avis, c'est un pis-aller, non ? Il vaut mieux une bonne
réflexion en amont sur le code en lui-même plutôt qu'un recours à
des règles strictes et inflexibles... qui me semblent plus réservées au
contrôle - a priori - de la cohérence du code.
Pas seulement. Le typage permet en partie de s'affranchir des problemes
d'alias. Par exemple, si tu passes un pointeur sur un int et un pointeur
sur un float a une fonction, le compilateur a le droit de supposer que
les deux pointeurs pointent sur des zones distinctes en memoire, et
donc qu'il a le droit de reordonnancer les acces, et de triturer le
code jusqu'a faire des choses plus efficaces.
L'air de rien, lorsqu'on a des fonctions generiques, c'est pratique. C'est
moins bien que de pouvoir dire explicitement que deux tableaux sont
disjoints (ben oui, c'est un concept de Fortran qui manque en C ca, et
restrict n'y suffit pas), mais c'est quand meme fortement sympathique
dans quelques cas.
Cote optimisations, comme d'habitude, c'est la version suivante de GCC
qui devrait etre bien. Enfin, pas comme d'habitude, puisque la ils vont
allegrement franchir deux versions: gcc 3.4 a des chances d'etre aussi
calamiteux que gcc 3.3 et on nous promet monts et merveilles pour gcc 3.5
L'air de rien, lorsqu'on a des fonctions generiques, c'est pratique. C'est
moins bien que de pouvoir dire explicitement que deux tableaux sont
disjoints (ben oui, c'est un concept de Fortran qui manque en C ca, et
restrict n'y suffit pas), mais c'est quand meme fortement sympathique
dans quelques cas.
Cote optimisations, comme d'habitude, c'est la version suivante de GCC
qui devrait etre bien. Enfin, pas comme d'habitude, puisque la ils vont
allegrement franchir deux versions: gcc 3.4 a des chances d'etre aussi
calamiteux que gcc 3.3 et on nous promet monts et merveilles pour gcc 3.5.
Mouais. À mon avis, c'est un pis-aller, non ? Il vaut mieux une bonne réflexion en amont sur le code en lui-même plutôt qu'un recours à des règles strictes et inflexibles... qui me semblent plus réservées au contrôle - a priori - de la cohérence du code.
Pas seulement. Le typage permet en partie de s'affranchir des problemes
d'alias. Par exemple, si tu passes un pointeur sur un int et un pointeur sur un float a une fonction, le compilateur a le droit de supposer que les deux pointeurs pointent sur des zones distinctes en memoire, et donc qu'il a le droit de reordonnancer les acces, et de triturer le code jusqu'a faire des choses plus efficaces.
L'air de rien, lorsqu'on a des fonctions generiques, c'est pratique. C'est moins bien que de pouvoir dire explicitement que deux tableaux sont disjoints (ben oui, c'est un concept de Fortran qui manque en C ca, et restrict n'y suffit pas), mais c'est quand meme fortement sympathique dans quelques cas.
Cote optimisations, comme d'habitude, c'est la version suivante de GCC qui devrait etre bien. Enfin, pas comme d'habitude, puisque la ils vont allegrement franchir deux versions: gcc 3.4 a des chances d'etre aussi calamiteux que gcc 3.3 et on nous promet monts et merveilles pour gcc 3.5
L'air de rien, lorsqu'on a des fonctions generiques, c'est pratique. C'est moins bien que de pouvoir dire explicitement que deux tableaux sont disjoints (ben oui, c'est un concept de Fortran qui manque en C ca, et restrict n'y suffit pas), mais c'est quand meme fortement sympathique dans quelques cas.
Cote optimisations, comme d'habitude, c'est la version suivante de GCC qui devrait etre bien. Enfin, pas comme d'habitude, puisque la ils vont allegrement franchir deux versions: gcc 3.4 a des chances d'etre aussi calamiteux que gcc 3.3 et on nous promet monts et merveilles pour gcc 3.5.
Vincent
(Marc Espie) dixit :
Pas seulement. Le typage permet en partie de s'affranchir des problemes d'alias. Par exemple, si tu passes un pointeur sur un int et un pointeur sur un float a une fonction, le compilateur a le droit de supposer que les deux pointeurs pointent sur des zones distinctes en memoire, et donc qu'il a le droit de reordonnancer les acces, et de triturer le code jusqu'a faire des choses plus efficaces.
Admettons. J'ai quand même essayé hier un certain nombre de choses sur le code de la DCT du logiciel bladeenc. En particulier, dans la version actuelle, il y a des accès pour le calcul des papillons à des tableaux trigo précalculés. Ex : truc = cs [k] * machin + cs [17-k] * bidule ; Je me suis dit : réordonnons le tableau pour virer l'indice 17-k, le transformer en k+1, de sorte que le processeur puisse se dispenser d'utiliser deux pointeurs d'adresses, et éventuellement faire du préfetch en cache.
Moralité : une fois transformé, le code tourne plus lentement que l'original !
Y a des choses qui m'échappent !
Ou alors je vais carrément réécrire la boucle en assembleur une bonne fois pour toutes ! :)
Cote optimisations, comme d'habitude, c'est la version suivante de GCC qui devrait etre bien. Enfin, pas comme d'habitude, puisque la ils vont allegrement franchir deux versions: gcc 3.4 a des chances d'etre aussi calamiteux que gcc 3.3 et on nous promet monts et merveilles pour gcc 3.5
Tiens, je n'étais pas au courant qu'on en était déjà à la version 3.5 de gcc.
Vincent
espie@tetto.gentiane.org (Marc Espie) dixit :
Pas seulement. Le typage permet en partie de s'affranchir des
problemes d'alias. Par exemple, si tu passes un pointeur sur un int et
un pointeur sur un float a une fonction, le compilateur a le droit de
supposer que les deux pointeurs pointent sur des zones distinctes en
memoire, et donc qu'il a le droit de reordonnancer les acces, et de
triturer le code jusqu'a faire des choses plus efficaces.
Admettons.
J'ai quand même essayé hier un certain nombre de choses sur le code de
la DCT du logiciel bladeenc. En particulier, dans la version actuelle,
il y a des accès pour le calcul des papillons à des tableaux trigo
précalculés. Ex : truc = cs [k] * machin + cs [17-k] * bidule ;
Je me suis dit : réordonnons le tableau pour virer l'indice 17-k, le
transformer en k+1, de sorte que le processeur puisse se dispenser
d'utiliser deux pointeurs d'adresses, et éventuellement faire du
préfetch en cache.
Moralité : une fois transformé, le code tourne plus lentement que
l'original !
Y a des choses qui m'échappent !
Ou alors je vais carrément réécrire la boucle en assembleur une bonne
fois pour toutes ! :)
Cote optimisations, comme d'habitude, c'est la version suivante de GCC
qui devrait etre bien. Enfin, pas comme d'habitude, puisque la ils
vont allegrement franchir deux versions: gcc 3.4 a des chances d'etre
aussi calamiteux que gcc 3.3 et on nous promet monts et merveilles
pour gcc 3.5
Tiens, je n'étais pas au courant qu'on en était déjà à la version 3.5 de
gcc.
Pas seulement. Le typage permet en partie de s'affranchir des problemes d'alias. Par exemple, si tu passes un pointeur sur un int et un pointeur sur un float a une fonction, le compilateur a le droit de supposer que les deux pointeurs pointent sur des zones distinctes en memoire, et donc qu'il a le droit de reordonnancer les acces, et de triturer le code jusqu'a faire des choses plus efficaces.
Admettons. J'ai quand même essayé hier un certain nombre de choses sur le code de la DCT du logiciel bladeenc. En particulier, dans la version actuelle, il y a des accès pour le calcul des papillons à des tableaux trigo précalculés. Ex : truc = cs [k] * machin + cs [17-k] * bidule ; Je me suis dit : réordonnons le tableau pour virer l'indice 17-k, le transformer en k+1, de sorte que le processeur puisse se dispenser d'utiliser deux pointeurs d'adresses, et éventuellement faire du préfetch en cache.
Moralité : une fois transformé, le code tourne plus lentement que l'original !
Y a des choses qui m'échappent !
Ou alors je vais carrément réécrire la boucle en assembleur une bonne fois pour toutes ! :)
Cote optimisations, comme d'habitude, c'est la version suivante de GCC qui devrait etre bien. Enfin, pas comme d'habitude, puisque la ils vont allegrement franchir deux versions: gcc 3.4 a des chances d'etre aussi calamiteux que gcc 3.3 et on nous promet monts et merveilles pour gcc 3.5
Tiens, je n'étais pas au courant qu'on en était déjà à la version 3.5 de gcc.
