Part 5 : Une approche plus subtile![](images/iconlink_32.png)
Si nous résumons la situation, nous avons un programme de calcul naïf qui nous sert de référence pour le temps de calcul.
Et nous avons un programme, écrit avec des fonctions intrinsèques, qui devrait théoriquement aller près de
![10](images/imgMath3574.png)
fois plus vite que le précédent et qui n'est que
![2.75](images/imgMath3567.png)
fois plus rapide.
On pourait se dire que notre test de performance élémentaire (ou
micro-benchmark) était très biaisé et que les performances sont ce qu'elles sont.
Mais il faut reconnaître que ce n'est pas une approche très scientifique...
Dans l'épisode précédent : Intuitivement, et comme les temps de calcul par éléments sont constants, on peut dire que c'est parce que notre problème est mémory band...
Si nous reprennons nos résulats précédents de la figure
7 que nous rappellons dans la figure
8.
On remarque que le temps par élément à droite est relativement constant de
![50000](images/imgMath3624.png)
à
![450000](images/imgMath3626.png)
éléments.
Comme nos éléments sont des
float qui ont une taille de
![4](images/imgMath2651.png)
octets cela représente de
![200](images/imgMath3633.png)
ko à
![1.8](images/imgMath3635.png)
Mo, donc elles de justesse dans le cache L2 (taille 256 ko) et plus génralement dans le cache L3 (taille
![8](images/imgMath3637.png)
Mo).
Si on regarde les temps d'accéès des données (
du cours How to optimize computation with HPC) :
- Cache L1 : 1 cycle
- Cache L2 : 6 cycles
- Cache L3 : 10 cycles
- RAM : 25 cycles
Sur un ordinateur qui à une fréquence d'horloge de
![2.9](images/imgMath3670.png)
GHz cela revient à :
- Cache L1 : 1 cycle ($0.34$ ns)
- Cache L2 : 6 cycles ($2.07$ ns)
- Cache L3 : 10 cycles ($3.45$ ns)
- RAM : 25 cycles ($8.62$ ns)
or, nous avions des images en full hd soit
![1\,920\time 1\,080 = 2\,073\,600](images/imgMath3697.png)
pixels soit
![\sim 8.3](images/imgMath3699.png)
Mo (ou exactement
![8\,294\,400](images/imgMath3701.png)
octets).
Or, nous pouvons vérifier la taille du cache (le votre est peut-être différent mais cela doit être cohérent avec votre temps de calcul) :
cat /proc/cpuinfo | grep "cache size"
cache size : 8192 KB
cache size : 8192 KB
cache size : 8192 KB
cache size : 8192 KB
cache size : 8192 KB
cache size : 8192 KB
cache size : 8192 KB
cache size : 8192 KB
Il y a une valeur par
thread CPU.
Là, on se dit que c'est ballot, car nos images ne rentrent pas le
cache L3, elles sont donc en
RAM.
Donc le rapatriment de ces données prendrait environ
![0.0715](images/imgMath3721.png)
seconde par images ce qui explique une bonne partie du temps de calcul d'une image qui est d'environ
![0.1](images/imgMath3563.png)
seconde avec la version en fonctions intrinsèques.