Les macros dans CImg, c'est juste une facon un peu spéciale de faire des *boucles*.
Tu pourrais faire la même chose en définissant des itérateurs.
Les macros dans CImg ne servent à rien d'autre qu'à faire des boucles en évitant les itérateurs (elles commencent toutes par 'for(' si tu regardes bien).
Le truc, c'est que si tu utilises des itérateurs pas trop compliqués à programmer (je l'ai testé), le code généré n'est pas aussi optimal que celui généré avec les gros for.
Je pense que l'on peut faire en sorte d'avoir quelque chose d'équivalent en terme de performance avec des itérateurs, mais alors ca va demander de programmer des itérateurs relativement compliqués. Donc du coup, tu gagnes pas grand chose, ni en performance, ni en taille de code, avec des itérateurs.
Et comme en traitement d'images, les algos ont souvent besoin de boucler un grand nombre de fois sur les images, c'est assez critique d'avoir des boucles rapides. Donc j'ai laissé les macros pour ce faire.
Par exemple, tu peux regarder la macro 'cimg_for3x3()' qui parcourt une image en maintenant à chaque instant le voisinage 3x3 de la position courante. Hé bien, cette boucle est extrèmement rapide, comparée à tous les tests que j'ai pu faire avec des itérateurs. La raison, à mon avis, c'est que je ne relis pas mon voisinage 3x3 à chaque instant, mais je le décale vers la gauche, donc si par chance, les valeurs de ce voisinage sont mis dans des registres, ca fait juste des move de valeurs de registre à registre, et çà ca fonce, comparé à une lecture en mémoire.
Ces macros là, elles permettent d'écrire non seulement du code court, pour l'utilisateur, mais en plus, elles sont rapides à executer.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. Évalué à 2.
Tu pourrais faire la même chose en définissant des itérateurs.
Les macros dans CImg ne servent à rien d'autre qu'à faire des boucles en évitant les itérateurs (elles commencent toutes par 'for(' si tu regardes bien).
Le truc, c'est que si tu utilises des itérateurs pas trop compliqués à programmer (je l'ai testé), le code généré n'est pas aussi optimal que celui généré avec les gros for.
Je pense que l'on peut faire en sorte d'avoir quelque chose d'équivalent en terme de performance avec des itérateurs, mais alors ca va demander de programmer des itérateurs relativement compliqués. Donc du coup, tu gagnes pas grand chose, ni en performance, ni en taille de code, avec des itérateurs.
Et comme en traitement d'images, les algos ont souvent besoin de boucler un grand nombre de fois sur les images, c'est assez critique d'avoir des boucles rapides. Donc j'ai laissé les macros pour ce faire.
Par exemple, tu peux regarder la macro 'cimg_for3x3()' qui parcourt une image en maintenant à chaque instant le voisinage 3x3 de la position courante. Hé bien, cette boucle est extrèmement rapide, comparée à tous les tests que j'ai pu faire avec des itérateurs. La raison, à mon avis, c'est que je ne relis pas mon voisinage 3x3 à chaque instant, mais je le décale vers la gauche, donc si par chance, les valeurs de ce voisinage sont mis dans des registres, ca fait juste des move de valeurs de registre à registre, et çà ca fonce, comparé à une lecture en mémoire.
Ces macros là, elles permettent d'écrire non seulement du code court, pour l'utilisateur, mais en plus, elles sont rapides à executer.