source: liacs/SCA2010/nQueens/report.tex@ 159

Last change on this file since 159 was 144, checked in by Rick van der Zwet, 14 years ago

Spelling fixes

File size: 9.5 KB
Line 
1%
2% $Id: report.tex 571 2008-04-20 17:31:04Z rick $
3%
4
5\documentclass[12pt,a4paper]{article}
6
7\frenchspacing
8\usepackage[english,dutch]{babel}
9\selectlanguage{dutch}
10\usepackage[pdftex]{graphicx}
11\usepackage{url}
12\usepackage{amssymb,amsmath}
13\usepackage{lipsum}
14\usepackage{float}
15
16\floatstyle{ruled}
17\newfloat{algoritm}{thp}{lop}
18\floatname{algoritm}{Algoritme}
19
20\title{\emph{n-Queens} minimale dominantie verzamelingen \\
21\large{Chessboard Domination on Programmable Graphics Hardware door Nathan Cournik}}
22\author{Rick van der Zwet\\
23 \texttt{<hvdzwet@liacs.nl>}}
24\date{\today}
25
26
27\begin{document}
28\maketitle
29\begin{abstract}
30Dit schrijven zal het paper van Nathan Cournik \emph{Chessboard Domination on
31Programmable Graphics Hardware}~\cite{CDGPU2006} ---en in het speciaal de
32gepresenteerde n-Queens oplossing--- vrij samenvatten in het nederlands en zal
33de mening van de ondergetekende op het geheel geven.
34\end{abstract}
35
36\section{Inleiding}
37\begin{figure}
38 \begin{center}
39 \includegraphics[width=0.5\textwidth]{pasted1.pdf}
40 \end{center}
41 \caption{Links; koningin kan dit patroon slaan. Rechts; ongeldige \emph{n-Queens} oplossing, opdat de koninginnen rechtsonder elkaar kunnen slaan}
42 \label{fig:patroon}
43\end{figure}
44Vanwege het het feit dat \emph{n-Queens} een algemeen geaccepteerde terminologie
45is, voor het plaatsen van $n$ koningen op een $n*n$ schaakbord zodanig dat de
46koningen elkaar niet kunnen slaan, zal dit in het schrijven niet vertaald
47worden. Verder zal in de tekst op diverse plekken de originele Engelse bewoording
48staan om zo terugzoeken en refereren in het originele paper~\cite{CDGPU2006}
49makkelijker te maken.
50
51
52\section{Minimale dominantie verzameling}
53De minimale dominantie verzameling ({\emph{Minimum domination set}}) is
54een opstelling waarbij zo weinig mogelijk koninginnen wordt gebruikt om elk vakje
55van het schaakbord door ten minste 1 koningin geslagen kan worden of dat er een
56koningin op staat. Omdat een koningin een karakteristiek patroon kan staan (zie
57Figuur~\ref{fig:patroon}) kan het minimale aantal koninginnen wat nodig is ook
58bepaald worden dmv van formule~\ref{eq:ondergrens}.
59\begin{equation}
60y(Q_{n})\geq\frac{n-1}{2}, n\geq1
61\label{eq:ondergrens}
62\end{equation}
63Als het een 'gewone' dominantie verzameling is dan hoeft het aantal koninginnen
64niet perse minimaal zijn.
65
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} processor-blokken
72worden \emph{kernels} genoemd. De data wordt getransporteerd door verschillende
73data-kanalen (\emph{streams}) en heeft de vorm van een \emph{framebuffer}, welke
74intern als $n * m$ array gezien kan worden. Een \emph{kernel} kan toegepast
75worden om een (deel van de) \emph{framebuffer}.}
76 \label{fig:werking}
77\end{figure}
78De Grafische Verwerking Eenheid (\emph{Graphics Processing Unit} ook bekend als
79\emph{GPU}) heeft speciale electronica om ervoor te zorgen dat deze snel de
80\emph{RGB} waardes van alle beeldpunten kan berekenen in complexe beeldsystemen
81met bijvoorbeeld ingewikkelde (lees: tijdrovende) berekeningen voor schaduw,
82reflectie en intensiteit. Om deze grote hoeveelheid gegevens te verwerken maakt
83de \emph{GPU} gebruik een grote hoeveelheid parallelle processoren, welke alle
84individueel een deel van de berekeningen op zich nemen.
85
86Recente (elektronica) ontwikkelingen zoals \emph{CUDA}\footnote{\url{http://en.wikipedia.org/wiki/CUDA}} en (meer generieke implementaties)
87\emph{OpenCL}\footnote{\url{http://en.wikipedia.org/wiki/OpenCL}} hebben ertoe
88geleid dat de GPU ook door de geprogrammeerd kan worden om specifieke
89berekeningen uit te voeren. Figuur~\ref{fig:werking} laat de verschillende
90stappen zien die uitgevoerd moeten worden om de \emph{GPU} aan te sturen. Het
91is belangrijk om te beseffen dat de \emph{GPU} een heel simpele processor is en
92(dus) zeer kleine buffers en instructie set heeft. Verder is het ook cruciaal
93te weten dat de \emph{GPU} \textit{niet} direct gebruik gebruik kan maken van
94het hoofd-geheugen van de \emph{CPU}, maak dat de invoer en uitvoer altijd eerst
95naar/van de \emph{GPU} verplaatst zal moeten worden.
96
97\section{Aanpak}
98Het zoeken van geldige minimale dominantie verzamelingen is een stevige klus,
99welke we (in het optimale geval) $n$ koninginnen hebben die we op een $n * n$
100schaakbord kunnen plaatsen. Dat levert $(n * n)! - ((n * n)-n)!$ mogelijkheden op.
101De \emph{GPU} zal gebruikt worden om oplossingen sneller te controleren en zal
102niet gebruikt worden om effici"{e}ntie oplossingen te vinden. De kracht zit hem in
103het feit dat meer oplossingen getest kunnen worden en dus potentieel betere
104oplossingen tussen kunnen zitten, welke ook te zien in in
105algoritme~\ref{alg:overzicht}. De genereerde potenti"{e}le oplossingen die aan de
106\emph{GPU} ter controle aangeboden worden respecteren de boven- en ondergrens.
107
108\begin{algoritm}
109\begin{verbatim}
11001: klaar=nee
11102: doe
11203: ..bereken potentieel minimale dominantie verzamelingen
11304: ..plaats in framebuffer
11405: ..als (alle pixels zijn gemarkeerd) dan
11506: ....klaar=ja
11608: totdat (klaar=ja)
117\end{verbatim}
118\caption{evalueren minimale dominantie set}
119\label{alg:overzicht}
120\end{algoritm}
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}
129Om snelle detectie mogelijk te maken, wordt er gebruikt gemaakt van een
130eigenschap waar een \emph{GPU} in uitblinkt; het '\emph{stempelen}' van objecten in
131een raster (welke in traditionele beeldbewerking gebruikt wordt om texturen te
132maken). Elk schaakstuk heeft zijn eigen stempel-patroon zoals te zien in
133figuur~\ref{fig:stempels}. Hierbij moet opgemerkt worden dat de stempels
134allemaal op hun eigen manier schalen.
135
136\begin{figure}
137 \begin{center}
138 \includegraphics[width=0.4\textwidth]{pasted5.pdf}
139 \end{center}
140 \caption{Door slim te coderen kunnen meerdere potenti"{e}le oplossingen tegelijk
141bekeken worden. Hier wordt gebruik gemaakt van (a) het feit dat de ruimte groter
142is dan het 'schaakbord' welke bekeken wordt en (b) een pixel gecodeerd is uit
143vier onafhankelijke kleuren}
144 \label{fig:raster}
145\end{figure}
146Er zijn nog twee eigenschappen van de \emph{GPU} waar dankbaar gebruik van
147gemaakt wordt, namelijk kleur en het verschil in grootte van het bord en de
148geaccepteerde invoer. Door slim te combineren ---zie figuur~\ref{fig:raster}---
149kan het aantal potenti"{e}le oplossingen die getest kan worden gemaximaliseerd
150worden.
151
152De individuele \emph{kernels} volgen het algoritme~\ref{alg:kernel}, de test of
153alle punten gemarkeerd zijn lijkt om het eerste gezicht een lus en test over
154alle beeldpunten, echter de \emph{GPU} heeft specifieke instructies om dit
155effici"{e}ntie uit te voeren.
156Voor het plaatsen van de stempels moet er gegaan worden voor de grafische
157equivalent van een \texttt{OF} operatie. Als een \texttt{INVERSE} operatie gebruikt zou
158worden om de stempel te plaatsen zou een tweede overlappende stempel onterecht
159als niet geraakt gemarkeerd worden.
160
161\begin{algoritm}
162\begin{verbatim}
16301: voor elke stempels in stempel locatie
16402: ..plaats stempel
16503: als (alle punten gemarkeerd) dan
16604: ..oplossing=ja
167\end{verbatim}
168\caption{evalueren minimale dominantie set door individuele kernel}
169\label{alg:kernel}
170\end{algoritm}
171
172\section{Conclusie}
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 dominantie 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}
180Door het toepassen van de \emph{GPU} in het \emph{n-Queens} probleem kunnen
181winsten geboekt worden zoals te zien in figuur~\ref{fig:uitvoertijd}\footnote{Gegevens direct uit \cite{CDGPU2006} overgenomen, experiment niet opnieuw uitgevoerd}.
182Het toepassen van \emph{GPU} dominantie textuur technieken technieken lijkt voor dit
183specifieke geval een goede vertaling van de traditionele \emph{CPU} wereld en
184de \emph{GPU} wereld. De stempels bieden tevens meer vrijheden om alternatieve
185'schaakstukken' te onderzoeken.
186\subsection{Verder werk}
187Er zal gekeken worden of de generatie van nieuwe oplossingen ook op de
188\emph{GPU} gedaan kan worden om zo het probleem van de langzame context
189wisselingen op te lossen.
190Verder zal er gekeken worden of de codering van de borden op nog een slimmere
191manier aangepakt kan worden, in plaats van de kleur in 4 basis-kleuren uit te
192splitsen zouden ook de volledige 32 bits (elke kleur is 8 bit) kunnen worden om
193nog meer(combinaties) van oplossingen te coderen.
194
195\subsection{Discussie}
196De claim dat de \emph{GPU} 'veel' sneller is lijkt me niet gefundeerd in de
197grafieken. Beiden lijken erg dicht bij elkaar te blijven en ik zie niet waarom
198dit plots veel beter zou worden bij grotere $n$ waarden.
199De 'tegel-methode' van figuur~\ref{fig:raster} lijkt in theorie leuk, maar als
200de $n$ groter wordt is er grote kans dat de tegels niet meer (goed) passen. Als
201de $n$ groter wordt dan in mogelijke invoer is het helemaal niet meer mogelijk.
202
203
204
205\begin{thebibliography}{2}
206\bibitem[DM2003]{DM2003}E. J. Cockayne, emph{Chessboard domination
207problems}, \emph{Discrete Math}, 86:1320, 1990.
208
209\bibitem[CDGPU2006]{CDGPU2006}Nathan Cournik,\emph{Chessboard Domination
210on Programmable Graphics Hardware}, \emph{ACM SE'06 March
21110-­12, 2006}. Melbourne, Florida, USA
212\end{thebibliography}
213\newpage
214\end{document}
Note: See TracBrowser for help on using the repository browser.