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

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

Whole bunch of typo's corrected

File size: 9.6 KB
RevLine 
[2]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}
[142]10\usepackage[pdftex]{graphicx}
[2]11\usepackage{url}
12\usepackage{amssymb,amsmath}
[142]13\usepackage{lipsum}
14\usepackage{float}
[2]15
[142]16\floatstyle{ruled}
17\newfloat{algoritm}{thp}{lop}
[143]18\floatname{algoritm}{Algoritme}
[142]19
[144]20\title{\emph{n-Queens} minimale dominantie verzamelingen \\
[142]21\large{Chessboard Domination on Programmable Graphics Hardware door Nathan Cournik}}
[2]22\author{Rick van der Zwet\\
[142]23 \texttt{<hvdzwet@liacs.nl>}}
[2]24\date{\today}
25
[142]26
[2]27\begin{document}
28\maketitle
[142]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}
[2]35
36\section{Inleiding}
[142]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}
[168]44Vanwege 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
[142]46koningen elkaar niet kunnen slaan, zal dit in het schrijven niet vertaald
[144]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}
[142]49makkelijker te maken.
50
51
[144]52\section{Minimale dominantie verzameling}
53De minimale dominantie verzameling ({\emph{Minimum domination set}}) is
[168]54een opstelling waarbij met zo weinig mogelijk koninginnen elk vakje
55van het schaakbord a) door ten minste 1 koningin geslagen kan worden of b) dat er een
[143]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}.
[142]59\begin{equation}
60y(Q_{n})\geq\frac{n-1}{2}, n\geq1
61\label{eq:ondergrens}
62\end{equation}
[144]63Als het een 'gewone' dominantie verzameling is dan hoeft het aantal koninginnen
64niet perse minimaal zijn.
[142]65
66
67\section{Grafische Verwerking Eenheid}
[143]68\begin{figure}
69 \centering
70 \includegraphics[width=0.4\textwidth]{pasted1.png}
[144]71 \caption{\emph{GPU} werking. De verschillende \emph{GPU} processor-blokken
[143]72worden \emph{kernels} genoemd. De data wordt getransporteerd door verschillende
[144]73data-kanalen (\emph{streams}) en heeft de vorm van een \emph{framebuffer}, welke
[143]74intern als $n * m$ array gezien kan worden. Een \emph{kernel} kan toegepast
[168]75worden op een (deel van de) \emph{framebuffer}.}
[143]76 \label{fig:werking}
77\end{figure}
[142]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
[144]81met bijvoorbeeld ingewikkelde (lees: tijdrovende) berekeningen voor schaduw,
82reflectie en intensiteit. Om deze grote hoeveelheid gegevens te verwerken maakt
[168]83de \emph{GPU} gebruik van een grote hoeveelheid parallelle processoren, welke alle
[142]84individueel een deel van de berekeningen op zich nemen.
85
[168]86Recente (elektronica) ontwikkelingen zoals \emph{CUDA}\footnote{\url{http://en.wikipedia.org/wiki/CUDA}} en een meer generieke implementatie
[142]87\emph{OpenCL}\footnote{\url{http://en.wikipedia.org/wiki/OpenCL}} hebben ertoe
[168]88geleid dat op de \emph{GPU} in plaats van enkel beeldverwerkingen te doen nu ook geprogrammeerd kan worden om specifieke
[142]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
[144]94het hoofd-geheugen van de \emph{CPU}, maak dat de invoer en uitvoer altijd eerst
[142]95naar/van de \emph{GPU} verplaatst zal moeten worden.
96
[168]97\section{Aanpak emph{n-Queens} probleem op de \emph{GPU}}
[144]98Het zoeken van geldige minimale dominantie verzamelingen is een stevige klus,
[168]99waarvoor minimaal (en dus optimale geval) $n$ koninginnen nodig zijn die we op een $n * n$
[142]100schaakbord kunnen plaatsen. Dat levert $(n * n)! - ((n * n)-n)!$ mogelijkheden op.
[143]101De \emph{GPU} zal gebruikt worden om oplossingen sneller te controleren en zal
[144]102niet gebruikt worden om effici"{e}ntie oplossingen te vinden. De kracht zit hem in
[143]103het feit dat meer oplossingen getest kunnen worden en dus potentieel betere
104oplossingen tussen kunnen zitten, welke ook te zien in in
[144]105algoritme~\ref{alg:overzicht}. De genereerde potenti"{e}le oplossingen die aan de
[143]106\emph{GPU} ter controle aangeboden worden respecteren de boven- en ondergrens.
[142]107
108\begin{algoritm}
109\begin{verbatim}
11001: klaar=nee
11102: doe
[144]11203: ..bereken potentieel minimale dominantie verzamelingen
[142]11304: ..plaats in framebuffer
11405: ..als (alle pixels zijn gemarkeerd) dan
11506: ....klaar=ja
11608: totdat (klaar=ja)
117\end{verbatim}
[144]118\caption{evalueren minimale dominantie set}
[143]119\label{alg:overzicht}
[142]120\end{algoritm}
121
[143]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
[144]132maken). Elk schaakstuk heeft zijn eigen stempel-patroon zoals te zien in
[143]133figuur~\ref{fig:stempels}. Hierbij moet opgemerkt worden dat de stempels
134allemaal op hun eigen manier schalen.
[142]135
[143]136\begin{figure}
[142]137 \begin{center}
138 \includegraphics[width=0.4\textwidth]{pasted5.pdf}
139 \end{center}
[144]140 \caption{Door slim te coderen kunnen meerdere potenti"{e}le oplossingen tegelijk
[143]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
[144]143vier onafhankelijke kleuren}
[143]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
[168]148geaccepteerde invoer. Door slim te combineren ---zie figuur~\ref{fig:raster} op pagina~\pageref{fig:raster}---
149kan het aantal potenti"{e}le oplossingen dat getest kan worden gemaximaliseerd
[143]150worden.
[142]151
[168]152De individuele \emph{kernels} volgen het algoritme~\ref{alg:kernel}. De test of
153alle punten gemarkeerd zijn lijkt op het eerste gezicht een lus/loop die test over
[143]154alle beeldpunten, echter de \emph{GPU} heeft specifieke instructies om dit
[168]155effici"{e}nter uit te voeren.
156Voor het plaatsen van de stempels is er een een grafische operatie die
157equivalent is aan een \texttt{OF} operatie. Als een \texttt{INVERSE} operatie gebruikt zou
[143]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}
[144]168\caption{evalueren minimale dominantie set door individuele kernel}
[143]169\label{alg:kernel}
170\end{algoritm}
171
[2]172\section{Conclusie}
[143]173 \begin{figure}
174 \centering
175 \includegraphics[width=0.4\textwidth]{pasted6.pdf}
176 \caption{
[168]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 des te beter de \emph{GPU} gaan presteren in vergelijking met de \emph{CPU}}
[143]178 \label{fig:uitvoertijd}
179\end{figure}
[144]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}.
[168]182Het toepassen van \emph{GPU} dominantie textuur technieken lijkt voor dit
[143]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
[144]188\emph{GPU} gedaan kan worden om zo het probleem van de langzame context
[143]189wisselingen op te lossen.
190Verder zal er gekeken worden of de codering van de borden op nog een slimmere
[144]191manier aangepakt kan worden, in plaats van de kleur in 4 basis-kleuren uit te
[143]192splitsen zouden ook de volledige 32 bits (elke kleur is 8 bit) kunnen worden om
193nog meer(combinaties) van oplossingen te coderen.
[142]194
[143]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.
[144]199De 'tegel-methode' van figuur~\ref{fig:raster} lijkt in theorie leuk, maar als
[143]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.
[142]202
203
[143]204
[142]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
[2]212\end{thebibliography}
213\newpage
214\end{document}
Note: See TracBrowser for help on using the repository browser.