-
Notifications
You must be signed in to change notification settings - Fork 1
/
edge-neon_teil2.tex
85 lines (65 loc) · 4.44 KB
/
edge-neon_teil2.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
\newpage
%% edge-neon_teil2.tex
\subsection{Neon}
\paragraph{Korrektheit}
\label{paragraph:neon_korrektheit}
%Bild Eingabe (Duck / matting-global / car-stack?)
%Vergleich Ausgabe bei Eingabe mit gleichen Parametern GIMP – GEGL Bilder
%Ergebnis vom Diff
Trotz sehr aufwändiger Suche und Behandlung, auch mehrfaches Neuanfangs konnten wir einen Fehler bei der Kachelzerlegung nicht fixen.
Unerwarteter Weise werden horizontale Kachelränder etwas verzerrt, wobei in den allermeisten Bildern die angesprochene Verzerrung so unauffällig ist, dass man nach dieser gezielt suchen muss.
Anscheinend behandelt GEGL diesen Punkt nicht gleichermaßen wie GIMP.
Da wir aber auch dieses Filter gern commiten würden, werden wir uns mit GEGL-Leuten in Verbindung setzen und um Hinweise bitten.
Wird das Bild nur in senkrechte oder keine Kacheln zerlegt, so stimmen die Ausgaben von GEGL und GIMP überein.
\paragraph{Laufzeit}
%X Durchläufe in Diagram abtragen?
%System beschreiben (Hardware, Software, Umgebungsvariablen) !!!
%Boxplots !!!
%Statistische Analyse ?!
%Aus Debug-Output Diagramm erstellen um Anteil des Filters an Gesamtlaufzeit zu verdeutlichen
Tabelle \ref{tab:NEON_runtime} enthält wichtigste Daten über die Laufzeit dieses Filters in verschiedenen Konfigurationen.
Manche Messungen sind mit schedule(dynamic) durchgeführt, solche sind mit dem ``d''-Zeichen neben der Threadszahl markiert. Wie man der Tabelle entnehmen kann, liegt der entstehende Vorteil durch schedule(dynamic) mit 4 Threads unter 1\%. Bei einer geringeren Threadszahl zeigt sich dynamische Aufteilung bediengt durch Overhead sogar störend (nicht in der Tabelle aufgelistet).
Der ursprünglich verfolgte Ansatz ``Sections'' konnte unsere Erwartungen leider nicht erfüllen, und schließt die Liste in allen Tests ab. Eine wichtige Anmerkung an dieser Stelle ist, dass für innere Parallelität hier SET\_NESTED=TRUE essentiell ist.
Der konservative Ansatz zeigte sich im Gegenteil zu Section sehr gut. Hier lässt sich eine Abhängigkeit zwischen Threadszahl und der ausgewählten Methode beobachten. Während Ansatz ohne Datenabhängigket (mit zusätzlichen Buffern) sich am besten mit wenigen Threads zeigt, konnte der Ansatz mit Datenabhängigkeit(ohne zusätzliche Buffer) unsere Tests mit 4 Threads am besten abschneiden(unabhängig von Scheduler und Bildgröße).
Alle Angaben in Sekunden. Messungen an Intel i5-3570 CPU mit 4 physikalischen Kernen (4 Threads) @ 3.40GHz und 6144 KB L2-Cache, ausgerüstet mit 8 Gb RAM (1600 Mhz) unter Ubuntu 13.10. Gemessen wurde aber mit Standartparametern und nur gesamte Zeit: mit GEGL aufrufen, mit Bild einlesen, mit Bild abspeichern - nur diese Angaben sind für den Endnutzer interessant.
Info über verwendete Bilder:
raupe.png 6023x3645 Pixel, 7.5 MB
wolf.png 2620x1503 Pixel, 322.8 kB
lenna.png 512x512 Pixel
\begin{table}[h] 473.8 kB
\centering
\begin{tabular}{c p{2cm}p{2cm}p{2cm}}
\toprule
\textbf{\#Thread} & \textbf{Lenna} & \textbf{Wolf} & \textbf{Raupe} \\
\cmidrule(r){1-4}
\multicolumn{4}{c}{Conservative (ohne DA, static)} \\
4d & 0.252 &1.124 &6.822 \\
4 & 0.252 &4.123 &6.960 \\
2 & 0.270 &1.454 &8.603 \\
1 & 0.314 &2.157 &12.438 \\
\cmidrule(r){1-4}
\multicolumn{4}{c}{Sections (ohne DA, static)} \\
2*2 & 0.254 &1.222 &7.412 \\
2*1 & 0.280 &1.571 &9.366 \\
\cmidrule(r){1-4}
\multicolumn{4}{c}{Conservative (mit DA, static)} \\
4d & 0.246 & 1.126 & 6.761 \\
4 & 0.248 &1.139 & 6.792 \\
2 & 0.268 &1.471 & 8.685 \\
1 & 0.318 &2.203 &12.772 \\
\bottomrule
\end{tabular}
\flushleft{
\footnotesize{\textsuperscript{*} ein ``'d'-Zeichen neben der Threadszahl weist darauf hin, dass diese Laufzeit mit schedule(dynamic) gemessen wurde, ansonsten mit schedule(static)
}}
\caption{Laufzeit von Neon in verschiedenen Konfigurationen}
\label{tab:NEON_runtime}
\end{table}
Zusammenfassend kann man volgendes sagen:
\begin{itemize}
\item Sections sind in diesem Filter eher ungeeignet (allgemeine Tests ob sections in OpenMP effizient abgearbeitet werden wären erwünscht).
\item Bei geringen Threadszahlen ist der konservative Ansatz mit Datenabhängigkeit wegen der besseren Cache-Ausnutzung (vgl. zu Kapitel \ref{paragraph:neon_filter}:Parallelisierung) die beste Wahl.
\item Mit steigender Threadszahl wird der konservative Ansatz ohne Datenabhängigkeit zum Spitzenreiter.
\item Erzielter SpeedUp: $\frac{Beste allgemeine 1-Thread-Zeit}{Beste allgemeine 4-Thread-Zeit:}$
lenna: 1.2764, wolf: 1.9190, raupe: 1.8312
\end{itemize}