Changeset 143
- Timestamp:
- Jul 1, 2010, 8:17:44 PM (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
liacs/SCA2010/nQueens/report.tex
r142 r143 11 11 \usepackage{url} 12 12 \usepackage{amssymb,amsmath} 13 \usepackage{wrapfig}14 13 \usepackage{lipsum} 15 14 \usepackage{float} … … 17 16 \floatstyle{ruled} 18 17 \newfloat{algoritm}{thp}{lop} 19 \floatname{algoritm}{Algoritm }18 \floatname{algoritm}{Algoritme} 20 19 21 20 \title{\emph{n-Queens} minimale dominatie verzamelingen \\ … … 53 52 \section{Minimale dominatie verzameling} 54 53 De minimale dominatie verzameling ({\emph{Minimum domination set}}) is 55 een setup waarbij elk vakje van het schaakbord door ten minste 1 koningin56 geslagen kan worden of dat er een koningin op staat. Omdat een koningineen57 k arakteristiek patroon kan staan (zie Figuur~\ref{fig:patroon}) kan het58 minimale aantal koninginnen wat nodig is ook bepaald worden dmv van 59 formule~\ref{eq:ondergrens}.54 een setup waarbij zo weinig mogelijk koninginnen wordt gembruikt om elk vakje 55 van het schaakbord door ten minste 1 koningin geslagen kan worden of dat er een 56 koningin op staat. Omdat een koningin een karakteristiek patroon kan staan (zie 57 Figuur~\ref{fig:patroon}) kan het minimale aantal koninginnen wat nodig is ook 58 bepaald worden dmv van formule~\ref{eq:ondergrens}. 60 59 \begin{equation} 61 60 y(Q_{n})\geq\frac{n-1}{2}, n\geq1 62 61 \label{eq:ondergrens} 63 62 \end{equation} 63 Als het een 'gewone' dominatie verzameling is dan hoeft het aantal koninginnen 64 niet per-se minimaal zijn. 64 65 65 66 66 67 \section{Grafische Verwerking Eenheid} 68 \begin{figure} 69 \centering 70 \includegraphics[width=0.4\textwidth]{pasted1.png} 71 \caption{\emph{GPU} werking. De verschillende \emph{GPU} processorblokken 72 worden \emph{kernels} genoemd. De data wordt getransporteerd door verschillende 73 datakanalen (\emph{streams}) en heeft de vorm van een \emph{framebuffer}, welke 74 intern als $n * m$ array gezien kan worden. Een \emph{kernel} kan toegepast 75 worden om een (deel van de) \emph{framebuffer}.} 76 \label{fig:werking} 77 \end{figure} 67 78 De Grafische Verwerking Eenheid (\emph{Graphics Processing Unit} ook bekend als 68 79 \emph{GPU}) heeft speciale electronica om ervoor te zorgen dat deze snel de … … 83 94 het hoofdgeheugen van de \emph{CPU}, maak dat de invoer en uitvoer altijd eerst 84 95 naar/van de \emph{GPU} verplaatst zal moeten worden. 85 \begin{figure} 86 \begin{center} 87 \includegraphics[width=0.4\textwidth]{pasted1.png} 88 \end{center} 89 \caption{\emph{GPU} werking. De verschillende \emph{GPU} processorblokken 90 worden \emph{kernels} genoemd. De data wordt getransporteerd door verschillende 91 datakanalen (\emph{streams}) en heeft de vorm van een \emph{framebuffer}, welke 92 intern als $n * m$ array gezien kan worden. Een \emph{kernel} kan toegepast 93 worden om een (deel van de) \emph{framebuffer}} \label{fig:werking} 94 \end{figure} 95 96 \section{Algoritme} 96 97 \section{Aanpak} 97 98 Het zoeken van geldige minimale dominatie verzamelingen is een stevige klus, 98 99 welke we (in het optimale geval) $n$ koninginnen hebben die we op een $n * n$ 99 100 schaakbord kunnen plaatsen. Dat levert $(n * n)! - ((n * n)-n)!$ mogelijkheden op. 100 De \emph{GPU} zal gebruikt worden om oplossingen sneller te controlen en zal 101 niet gebruikt worden om effientere oplossingen te vinden. 101 De \emph{GPU} zal gebruikt worden om oplossingen sneller te controleren en zal 102 niet gebruikt worden om effientere oplossingen te vinden. De kracht zit hem in 103 het feit dat meer oplossingen getest kunnen worden en dus potentieel betere 104 oplossingen tussen kunnen zitten, welke ook te zien in in 105 algoritme~\ref{alg:overzicht}. De genereerde potentieele oplossingen die aan de 106 \emph{GPU} ter controle aangeboden worden respecteren de boven- en ondergrens. 102 107 103 108 \begin{algoritm} … … 105 110 01: klaar=nee 106 111 02: doe 107 03: ..bereken potentieel minimale dominatie verzameling 112 03: ..bereken potentieel minimale dominatie verzamelingen 108 113 04: ..plaats in framebuffer 109 114 05: ..als (alle pixels zijn gemarkeerd) dan 110 115 06: ....klaar=ja 111 07: ..eindeals112 116 08: totdat (klaar=ja) 113 117 \end{verbatim} 114 \caption{aanpak minimale dominatie set} 118 \caption{evalueren minimale dominatie set} 119 \label{alg:overzicht} 115 120 \end{algoritm} 116 \subsection{Computing the piece configuration} 117 \begin{itemize} 118 \item Exhaustive manner 119 \item Piece configuration stored on the CPU as linked links 120 \item Lower bound and Upper bound is respected 121 \end{itemize} 122 123 \subsection{Rendered in Framebuffer} 124 \begin{wrapfigure}{r}{0.4\textwidth} 125 \begin{center} 126 \includegraphics[width=0.4\textwidth]{pasted4.pdf} 127 \end{center} 128 \caption{The Toucan} 129 \end{wrapfigure} 130 \begin{itemize} 131 \item GPU supports textures, every piece is a texture 132 \item Render points on the CPU and offload to the GPU to map texture on 133 specific place 134 \end{itemize} 135 136 \subsection{Determine Domination (e.g. Mark solution)} 137 \begin{itemize} 138 \item Simple approch 139 \item Sum all pixels of $n*n$ board and match if $sum=n*n$ 140 \end{itemize} 141 142 \section{GPU Optimalizations} 143 \begin{wrapfigure}{r}{0.4\textwidth} 121 122 \subsection{Detectie algoritme} 123 \begin{figure} 124 \centering 125 \includegraphics[width=0.4\textwidth]{pasted4.pdf} 126 \caption{Stempels van verschillende schaakstukken, de verschillende groottes zijn noodzakelijk om aan te geven hoe de stempel vergroot of verkleint moet worden} 127 \label{fig:stempels} 128 \end{figure} 129 Om snelle detectie mogelijk te maken, wordt er gebruikt gemaakt van een 130 eigenschap waar een \emph{GPU} in uitblinkt; het '\emph{stempelen}' van objecten in 131 een raster (welke in traditionele beeldbewerking gebruikt wordt om texturen te 132 maken). Elk schaakstuk heeft zijn eigen stempelpatroon zoals te zien in 133 figuur~\ref{fig:stempels}. Hierbij moet opgemerkt worden dat de stempels 134 allemaal op hun eigen manier schalen. 135 136 \begin{figure} 144 137 \begin{center} 145 138 \includegraphics[width=0.4\textwidth]{pasted5.pdf} 146 139 \end{center} 147 \caption{The Toucan} 148 \end{wrapfigure} 149 \begin{itemize} 150 \item GPU is able to process all colours at the times 151 Grid Framebuffer 152 \end{itemize} 153 \begin{itemize} 154 \item GPU has many CPU's called kernels 155 \item Each kernel can process it's own little block of information 156 \item Putting multiple possible solutions in one bloc 157 \end{itemize} 158 159 \section{Uitleg probleem} 160 \section{Theorie} 161 \section{Aanpak} 162 \section{Implementatie} 163 \section{Experimenten} 140 \caption{Door slim te coderen kunnen meerdere potentiele oplossingen tegelijk 141 bekeken worden. Hier wordt gebruik gemaakt van (a) het feit dat de ruimte groter 142 is dan het 'schaakbord' welke bekeken wordt en (b) een pixel gecodeerd is uit 143 vier onafhankele kleuren} 144 \label{fig:raster} 145 \end{figure} 146 Er zijn nog twee eigenschappen van de \emph{GPU} waar dankbaar gebruik van 147 gemaakt wordt, namelijk kleur en het verschil in grootte van het bord en de 148 geaccepteerde invoer. Door slim te combineren ---zie figuur~\ref{fig:raster}--- 149 kan het aantal potentiele oplossingen die getest kan worden gemaximaliseerd 150 worden. 151 152 De individule \emph{kernels} volgen het algoritme~\ref{alg:kernel}, de test of 153 alle punten gemarkeerd zijn lijkt om het eerste gezicht een lus en test over 154 alle beeldpunten, echter de \emph{GPU} heeft specifieke instructies om dit 155 effienter uit te voeren. 156 Voor het plaatsen van de stempels moet er gegaan worden voor de grafische 157 equivalent van een \texttt{OF} operatie. Als een \texttt{INVERSE} operatie gebruikt zou 158 worden om de stempel te plaatsen zou een tweede overlappende stempel onterecht 159 als niet geraakt gemarkeerd worden. 160 161 \begin{algoritm} 162 \begin{verbatim} 163 01: voor elke stempels in stempel locatie 164 02: ..plaats stempel 165 03: als (alle punten gemarkeerd) dan 166 04: ..oplossing=ja 167 \end{verbatim} 168 \caption{evalueren minimale dominatie set door individuele kernel} 169 \label{alg:kernel} 170 \end{algoritm} 171 164 172 \section{Conclusie} 165 \begin{wrapfigure}{r}{0.4\textwidth} 166 \begin{center} 167 \includegraphics[width=0.4\textwidth]{pasted6.pdf} 168 \end{center} 169 \caption{ 170 Execution times (log scale) of CPU and GPU based minimum domination 171 implementations computing $y(Q_{n})$. As $n$ increases, the GPU's 172 speed advantage over the CPU become more evident.} 173 \end{wrapfigure} 174 175 \begin{itemize} 176 \item Domination texture good mapping between CPU world and GPU world 177 \item Flexible texture definition without any impact 178 \end{itemize} 179 180 \subsection{Discussion} 181 \begin{itemize} 182 \item No significant speedup, claim that $n\geq13$ GPU is \emph{'much'} faster 183 \item No scaleable 184 \end{itemize} 173 \begin{figure} 174 \centering 175 \includegraphics[width=0.4\textwidth]{pasted6.pdf} 176 \caption{ 177 Uitvoer tijden (logaritmische schaal) van de \emph{CPU} en \emph{GPU} gebaseerde minimale dominatie implementaties welke $y(Q_{n})$ uitrekenen. Hoe groter $n$ wordt, de beter de \emph{GPU} gaan presteren boven de \emph{CPU}} 178 \label{fig:uitvoertijd} 179 \end{figure} 180 Door het toepassen van de \emph{GPU} in het \emph{n-Queens} probeem kunnen 181 winsten geboekt worden zoals te zien in figuur~\ref{fig:uitvoertijd}\footnote{Gegevens direct uit \cite{CDGPU2006} overgenomen experiment niet opnieuw uitgevoerd}. 182 Het toepassen van \emph{GPU} dominatie textuur technieken technieken lijkt voor dit 183 specifieke geval een goede vertaling van de traditionele \emph{CPU} wereld en 184 de \emph{GPU} wereld. De stempels bieden tevens meer vrijheden om alternatieve 185 'schaakstukken' te onderzoeken. 186 \subsection{Verder werk} 187 Er zal gekeken worden of de generatie van nieuwe oplossingen ook op de 188 \emph{GPU} gedaan kan worden om zo het probeem van de langzame context 189 wisselingen op te lossen. 190 Verder zal er gekeken worden of de codering van de borden op nog een slimmere 191 manier aangepakt kan worden, in plaats van de kleur in 4 basiskleuren uit te 192 splitsen zouden ook de volledige 32 bits (elke kleur is 8 bit) kunnen worden om 193 nog meer(combinaties) van oplossingen te coderen. 194 195 \subsection{Discussie} 196 De claim dat de \emph{GPU} 'veel' sneller is lijkt me niet gefundeerd in de 197 grafieken. Beiden lijken erg dicht bij elkaar te blijven en ik zie niet waarom 198 dit plots veel beter zou worden bij grotere $n$ waarden. 199 De 'tegelmethode' van figuur~\ref{fig:raster} lijkt in theorie leuk, maar als 200 de $n$ groter wordt is er grote kans dat de tegels niet meer (goed) passen. Als 201 de $n$ groter wordt dan in mogelijke invoer is het helemaal niet meer mogelijk. 202 203 185 204 186 205 \begin{thebibliography}{2}
Note:
See TracChangeset
for help on using the changeset viewer.