il faut identifier les cas possibles d'optimisation
En effet, mais étant donné que tout le code qui génère l'image est déjà sous forme d'un graphe (donc sous forme de données manipulables), il suffit d'ajouter des types de nœuds spécifiques pour des opérations génériques:
map : modification de chaque pixel de la structure par une fonction
convolution par une autre matrice
move : construire une nouvelle matrice en utilisant (sans modification) des pixels d'une autre (possible changement de dimensions)
Ça c'est la partie « facile », puisqu'à priori, elle ne nécessite que l'ajout de nœuds, et la conversion (progressive) du code existant vers ce modèle. Ensuite il « suffit » de coder les réduction (qui, pour le coup, découlent directement d'une propriété mathématique) :
map f . map g = map (f . g)
Si on écrit la signature de move comme suit move :: (Int,Int) -> (Position -> Position) -> (Image -> Image) alors move (a,b) f . move (c,d) g = move (a,b) (f . g)
Le produit de convolution est associatif, ce qui permet de calculer, pour un produit de type A * B * C le meilleur parenthèsage au niveau temps de calcul (c'est déjà fait pour le produit matriciel).
On remarque (faire un dessin) que map f et move (a,b) g commutent ! Donc on peut se débrouiller pour réordonner les enchaînements « move/map/move/map » et avoir seulement deux nœuds.
Contrairement à ton exemple, les optimisation ici sont génériques, et s'appliquent sur dans des cas spécifiques : les rotations de 45° sont (à priori si on ne fait pas de lissage) des opérations de type « move », et donc l'optimisation sera bien faite ...
La partie la plus difficile semble donc ni la prise en charge de nouveaux nœuds, ni la réduction du graphe (même si c'est déjà plus compliqué), mais trouver des actions assez générales pour que les optimisations touchent beaucoup de code et soient pertinentes ! Je ne dis pas que c'est « rapide à faire », mais que sur une assez longue période de temps, c'est plutôt « simple » à mettre en place.
Enfin, rien ne peut être optimisé de manière aussi naïve si on a pas l'assurance d'avoir du code sans effet de bord, et je ne sais pas si c'est pertinent pour du traitement d'images ...
D'ailleurs, après réflexion ... Pourquoi est-ce un graphe ? Une liste d'opérations à faire ne serait pas aussi bien ?
[^] # Re: perf ?
Posté par Aluminium95 . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 2.
En effet, mais étant donné que tout le code qui génère l'image est déjà sous forme d'un graphe (donc sous forme de données manipulables), il suffit d'ajouter des types de nœuds spécifiques pour des opérations génériques:
Ça c'est la partie « facile », puisqu'à priori, elle ne nécessite que l'ajout de nœuds, et la conversion (progressive) du code existant vers ce modèle. Ensuite il « suffit » de coder les réduction (qui, pour le coup, découlent directement d'une propriété mathématique) :
map f . map g = map (f . g)move :: (Int,Int) -> (Position -> Position) -> (Image -> Image)alorsmove (a,b) f . move (c,d) g = move (a,b) (f . g)A * B * Cle meilleur parenthèsage au niveau temps de calcul (c'est déjà fait pour le produit matriciel).map fetmove (a,b) gcommutent ! Donc on peut se débrouiller pour réordonner les enchaînements « move/map/move/map » et avoir seulement deux nœuds.Contrairement à ton exemple, les optimisation ici sont génériques, et s'appliquent sur dans des cas spécifiques : les rotations de 45° sont (à priori si on ne fait pas de lissage) des opérations de type « move », et donc l'optimisation sera bien faite ...
La partie la plus difficile semble donc ni la prise en charge de nouveaux nœuds, ni la réduction du graphe (même si c'est déjà plus compliqué), mais trouver des actions assez générales pour que les optimisations touchent beaucoup de code et soient pertinentes ! Je ne dis pas que c'est « rapide à faire », mais que sur une assez longue période de temps, c'est plutôt « simple » à mettre en place.
Enfin, rien ne peut être optimisé de manière aussi naïve si on a pas l'assurance d'avoir du code sans effet de bord, et je ne sais pas si c'est pertinent pour du traitement d'images ...
D'ailleurs, après réflexion ... Pourquoi est-ce un graphe ? Une liste d'opérations à faire ne serait pas aussi bien ?