updated benchmark script and beginning method 5
This commit is contained in:
Phuntsok Drak-pa
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 21 KiB |
+93
-46
@@ -39,10 +39,10 @@ $$\sqrt{\sum_{i=0}^n(v_i - w_i)^2}$$
|
||||
~V~ étant le vecteur de pixels de l’image de référence, ~W~ étant le vecteur de
|
||||
pixels de l’image générée, et ~n~ la taille de ces deux vecteurs.
|
||||
|
||||
Les tests de temps sont réalisés sur un Thinkpad x220, disposant d’un processeur
|
||||
Intel® Core™ i5-2540M à 2.6GHz, composé de deux cœurs supportant chacun deux
|
||||
threads, et de 4Go de RAM. Le programme est compilé avec les options
|
||||
d’optimisation ~-O3~ et ~-flto~.
|
||||
Les tests de temps sont réalisés sur un Lenovo Ideapad Y700, disposant d’un
|
||||
processeur Intel® Core™ i7-6700HQ à 2.6GHz et un turbo à 3.5GHz, composé de
|
||||
quatre cœurs supportant chacun deux threads, et de 16Go de RAM. Le programme est
|
||||
compilé avec les options d’optimisation ~-O3~ et ~-flto~.
|
||||
|
||||
Voici également ci-dessous la liste des options et arguments possibles
|
||||
concernant l’exécution du logiciel.
|
||||
@@ -57,21 +57,12 @@ concernant l’exécution du logiciel.
|
||||
-v [ --verbose ] Enables verbosity
|
||||
#+end_src
|
||||
|
||||
Voici la ligne de commande utilisée depuis le répertoire ~build~ afin de pouvoir
|
||||
obtenir un temps d’exécution :
|
||||
#+begin_src shell
|
||||
perf stat -r {nombreExécutions} -B ./bin/genetic-image \
|
||||
-i ../img/mahakala-monochrome.jpg -o output.png \
|
||||
-n {nombreIterations} -m 1
|
||||
#+end_src
|
||||
Voici le script grâce auquel les valeurs de temps d’exécution ont été obtenues :
|
||||
|
||||
Les deux éléments entre accolades sont à remplacer par leur valeur, par exemple
|
||||
afin d’exécuter dix fois le programme avec vingt améliorations, il faudrait
|
||||
exécuter ceci :
|
||||
#+begin_src shell
|
||||
perf stat -r 1 -B ./bin/genetic-image \
|
||||
-i ../img/mahakala-monochrome.jpg -o output.png -n 20 -m 1
|
||||
#+end_src
|
||||
#+INCLUDE: ../benchmarks.fish src shell -n
|
||||
|
||||
Quelques-unes de ces lignes commençasont là uniquement pour de la mise en forme des
|
||||
données afin que je puisse
|
||||
|
||||
** Méthode naïve
|
||||
|
||||
@@ -86,15 +77,15 @@ de référence.
|
||||
Voici les moyennes de temps d’exécution selon le nombre d’itérations réussies
|
||||
sur le nombre d’exécutions indiqué.
|
||||
|
||||
| / | < | < | < |
|
||||
| Nb d’améliorations | Temps d’exécution (s) | Variation (s) | Nb d’exécutions |
|
||||
|--------------------+-----------------------+---------------+-----------------|
|
||||
| 10 | 0.060847 | 0.000498 | 200 |
|
||||
| 50 | 0.29823 | 0.00453 | 100 |
|
||||
| 100 | 0.7093 | 0.0135 | 50 |
|
||||
| 200 | 1.9584 | 0.0559 | 20 |
|
||||
| 500 | 8.739 | 0.291 | 10 |
|
||||
| 1000 | 27.930 | 0.582 | 5 |
|
||||
| / | < | < |
|
||||
| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
|
||||
|--------------------+-----------------+-----------------------|
|
||||
| 10 | 200 | 0.065881 |
|
||||
| 50 | 100 | 0.130041 |
|
||||
| 100 | 50 | 0.186012 |
|
||||
| 200 | 20 | 0.385982 |
|
||||
| 500 | 10 | 1.437486 |
|
||||
| 1000 | 5 | 3.608983 |
|
||||
|
||||
Naturellement, la variation en temps d’exécution croît en même temps que le
|
||||
nombre d’améliorations nécessaires à apporter à l’image à améliorer, dû à la
|
||||
@@ -120,17 +111,17 @@ de rapidité à l’exécution. Cette méthode est celle implémentée dans la f
|
||||
Voici les moyennes de temps d’exécution selon le nombre d’itérations réussies
|
||||
sur le nombre d’exécutions indiqué.
|
||||
|
||||
| / | < | < | < |
|
||||
| Nb d’améliorations | Temps d’exécution (s) | Variation (s) | Nb d’exécutions |
|
||||
|--------------------+-----------------------+---------------+-----------------|
|
||||
| 10 | 0.074951 | 0.000533 | 200 |
|
||||
| 50 | 0.26385 | 0.00401 | 100 |
|
||||
| 100 | 0.6385 | 0.0148 | 50 |
|
||||
| 200 | 1.6145 | 0.0348 | 20 |
|
||||
| 500 | 6.747 | 0.235 | 10 |
|
||||
| 1000 | 19.608 | 0.327 | 5 |
|
||||
| / | < | < |
|
||||
| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
|
||||
|--------------------+-----------------+-----------------------|
|
||||
| 10 | 200 | 0.072979 |
|
||||
| 50 | 100 | 0.114426 |
|
||||
| 100 | 50 | 0.157965 |
|
||||
| 200 | 20 | 0.290475 |
|
||||
| 500 | 10 | 0.785426 |
|
||||
| 1000 | 5 | 2.664046 |
|
||||
|
||||
On peut remarquer une amélioration dans la rapidité d’exécution du logiciel.
|
||||
On peut remarquer une amélioration quant à la rapidité d’exécution du logiciel.
|
||||
Cependant, le résultat n’est pas aussi important qu’escompté. Je suppose que
|
||||
cela est dû au fait que l’algorithme précédent peut considérer un rapprochement
|
||||
d’une zone déjà colorée vers la couleur d’origine comme une amélioration, avec
|
||||
@@ -164,15 +155,15 @@ $$taille=Rand([\![tailleMinimale;tailleMaximale[\![)$$
|
||||
Voici les moyennes de temps d’exécution selon le nombre d’itérations réussies
|
||||
sur le nombre d’exécutions indiqué.
|
||||
|
||||
| / | < | < | < |
|
||||
| Nb d’améliorations | Temps d’exécution (s) | Variation (s) | Nb d’exécutions |
|
||||
|--------------------+-----------------------+---------------+-----------------|
|
||||
| 10 | | | 200 |
|
||||
| 50 | | | 100 |
|
||||
| 100 | | | 50 |
|
||||
| 200 | | | 20 |
|
||||
| 500 | | | 10 |
|
||||
| 1000 | | | 5 |
|
||||
| / | < | < |
|
||||
| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
|
||||
|--------------------+-----------------+-----------------------|
|
||||
| 10 | 200 | 0.082068 |
|
||||
| 50 | 100 | 0.244236 |
|
||||
| 100 | 50 | 0.418075 |
|
||||
| 200 | 20 | 1.453703 |
|
||||
| 500 | 10 | 4.777205 |
|
||||
| 1000 | 5 | 20.33209 |
|
||||
|
||||
Cette version du logiciel est nettement plus lente que ses versions précédentes
|
||||
du fait de la contrainte de taille pour les formes pouvant potentiellement
|
||||
@@ -196,14 +187,70 @@ résultats sont récupérés et évalués, et parmi les résultats améliorant l
|
||||
générée, celle avec le meilleur score est conservée. Cela permet ainsi de
|
||||
multiplier les chances d’avoir une amélioration de l’image par tentative.
|
||||
|
||||
Voici les benchmarks d’exécution de cette méthode sans contrôle de la taille des
|
||||
formes aléatoires :
|
||||
| / | < | < |
|
||||
| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
|
||||
|--------------------+-----------------+-----------------------|
|
||||
| 10 | 200 | 0.080525 |
|
||||
| 50 | 100 | 0.139892 |
|
||||
| 100 | 50 | 0.169113 |
|
||||
| 200 | 20 | 0.273342 |
|
||||
| 500 | 10 | 0.610812 |
|
||||
| 1000 | 5 | 1.403816 |
|
||||
|
||||
Et voici les benchmarks d’exécution de cette même méthode avec contrôle de la
|
||||
taille des formes aléatoires :
|
||||
| / | < | < |
|
||||
| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
|
||||
|--------------------+-----------------+-----------------------|
|
||||
| 10 | 200 | 0.085981 |
|
||||
| 50 | 100 | 0.156099 |
|
||||
| 100 | 50 | 0.29183 |
|
||||
| 200 | 20 | 0.59844 |
|
||||
| 500 | 10 | 2.513782 |
|
||||
| 1000 | 5 | 6.457168 |
|
||||
|
||||
Pour résumer, ces deux tableaux montrent la parallélisation de la seconde
|
||||
méthode et de la troisième méthode respectivement via des threads
|
||||
concurrentiels. On peut remarquer que le temps d’exécution s’est nettement
|
||||
amélioré, avec un temps d’exécution à peu près deux fois plus rapide pour
|
||||
l’exécution sans contrôle de taille des formes que la seconde méthode, et
|
||||
pouvant être jusqu’à trois fois plus rapide que la troisième méthode avec le
|
||||
contrôle de la taille des formes activée. On a donc une véritable amélioration
|
||||
significative avec cette nouvelle version parallèle.
|
||||
|
||||
** Collaboration entre threads
|
||||
|
||||
Une différente approche au parallélisme peut être réalisée : plutôt que
|
||||
d’essayer de mettre en concurrence plusieurs threads, il serait possible
|
||||
d’essayer de plutôt les mettre en collaboration. Cela implique par exemple de
|
||||
diviser l’image d’entrée en plusieurs zones sur laquelle chacun des threads
|
||||
lancés travailleraient, appliquant chacun le nombre d’améliorations demandé sur
|
||||
sa zone dédiée. Puis, une fois que chacun des threads a terminé son travail, les
|
||||
différentes zones sont unifiées en une seule image.
|
||||
|
||||
* Annexes
|
||||
** Images
|
||||
*** Image de référence
|
||||
#+CAPTION: Image de référence utilisée pour les tests du logiciel
|
||||
[[../img/mahakala-monochrome.jpg]]
|
||||
*** Méthode 1
|
||||
#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la première méthode
|
||||
[[./output1.png]]
|
||||
|
||||
*** Méthode 2
|
||||
#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la seconde méthode
|
||||
[[./output2.png]]
|
||||
|
||||
*** Méthode 3
|
||||
#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la troisième méthode
|
||||
[[./output3.png]]
|
||||
|
||||
*** Méthode 4
|
||||
**** Taille des formes non contrôlée
|
||||
#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la quatrième méthode sans l’option ~-s~
|
||||
[[./output4-1.png]]
|
||||
**** Taille des formes contrôlée
|
||||
#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la quatrième méthode avec l’option ~-s~
|
||||
[[./output4-2.png]]
|
||||
|
||||
Binary file not shown.
Reference in New Issue
Block a user