Ca ne regle malheureusement pas le probleme de fond qui est double:
- Pour chaque pixel, on integre sur une assez grande zone autour du pixel courant, ce qui bouffe une bande passante mémoire énorme.
- On traite l'image pixel par pixel, diminuer le ratio CLOCKS/Pixels.
Les solutions imaginables pour le premier point:
- Etre sur de bien aligner le tout, mine de rien, des lectures de memoire alignées c'est plus rapide pour le CPU/Controleur memoire.
- Penser à utiliser au maximum le cache CPU en travaillant sur des données le plus localisées possible et si possible se servir autant de fois que possible de chaque acces afin de ne pas avoir a y revenir plus tard.
- Voir si certains calculs pourraient utiliser moins d'acces memoire, selon que l'algo s'y prete ou pas, envisager la reutilisation de resultats precedents couvrant un grand nombre d'acces memoire.
Les solutions imaginables pour le second point:
- Regarder de plus pres l'utilisation de tout opérateur couteux (/ et *) et donc minimiser petit a petit les nombre de cycles necessaires par pixel.
- Il faut voir si on ne peut pas prévoir une vectorisation de la transformation pour pouvoir optimiser le tout en utilisant les instructions SIMD SSE d'abord, puis si on est vraiment très courageux, passer en SIMD iSSE (mais attention, il faut bien prévoir la precision de calcul en virgule fixe sous peine de tuer l'intégration ç cause de l'accumulation d'erreurs d'approximations).
Voila, c'est toujours les memes concepts d'optim qu'on doit mettre a l'oeuvre. La plupart du temps, chaque technique d'optim est limité par l'algo qui se prete plus ou moins au jeu.
A savoir que le mieux reste d'optimiser l'algo avant de penser a partir dans les delires de reduction d'acces memoire et de vectorisation.
[^] # Re: effet video
Posté par Edouard Gomez . En réponse au journal Greffon Gimp GREYCstoration. Évalué à 1.
- Pour chaque pixel, on integre sur une assez grande zone autour du pixel courant, ce qui bouffe une bande passante mémoire énorme.
- On traite l'image pixel par pixel, diminuer le ratio CLOCKS/Pixels.
Les solutions imaginables pour le premier point:
- Etre sur de bien aligner le tout, mine de rien, des lectures de memoire alignées c'est plus rapide pour le CPU/Controleur memoire.
- Penser à utiliser au maximum le cache CPU en travaillant sur des données le plus localisées possible et si possible se servir autant de fois que possible de chaque acces afin de ne pas avoir a y revenir plus tard.
- Voir si certains calculs pourraient utiliser moins d'acces memoire, selon que l'algo s'y prete ou pas, envisager la reutilisation de resultats precedents couvrant un grand nombre d'acces memoire.
Les solutions imaginables pour le second point:
- Regarder de plus pres l'utilisation de tout opérateur couteux (/ et *) et donc minimiser petit a petit les nombre de cycles necessaires par pixel.
- Il faut voir si on ne peut pas prévoir une vectorisation de la transformation pour pouvoir optimiser le tout en utilisant les instructions SIMD SSE d'abord, puis si on est vraiment très courageux, passer en SIMD iSSE (mais attention, il faut bien prévoir la precision de calcul en virgule fixe sous peine de tuer l'intégration ç cause de l'accumulation d'erreurs d'approximations).
Voila, c'est toujours les memes concepts d'optim qu'on doit mettre a l'oeuvre. La plupart du temps, chaque technique d'optim est limité par l'algo qui se prete plus ou moins au jeu.
A savoir que le mieux reste d'optimiser l'algo avant de penser a partir dans les delires de reduction d'acces memoire et de vectorisation.