Voorwoord

Het behalen van een ingenieursdiploma is voor een jongere van 23 jaar, met voldoendetalenten, de normaalste zaak van de wereld. Ditzelfde realiseren eens je in het bedrijfslevengestapt bent is minder evident. Ooit vertelde mij een wijs man: “Mario, als je na Uwwerkuren een ingenieursdiploma wenst te behalen dan kunnen twee zaken fout gaan: ofwelverlies je Uw werk, ofwel verlies je Uw gezin”. Gegeven deze wijze woorden kan ik, metenige fierheid, vaststellen dat ik na 5 jaar studie beide gevaren heb kunnen ontwijken… ikwerk nog steeds bij dezelfde werkgever en ben ik er nog steeds in geslaagd om mijn gezinsamen te houden.

In bovenstaande context is het behalen van een ingenieursdiploma en in het bijzonderhet uitwerken van een Masterproef niet evident. Dit zou zeker niet gelukt zijn zonder desteun van verschillende mensen (waarbij ik er vermoedelijk nog enkele vergeet).

Eerst wens ik mijn gezin te danken voor de steun en het begrip. Ten tweede wens ik alleprofessoren en assistent van de universiteit van Gent te danken voor hun bereidwilligehulp. Verder dank ik de personen die mij geholpen hebben bij de realisatie vanonderstaande thesis: prof. dr. ir. Wilfried Philips, prof. dr. ir. Koen De Bosschere, dr. ir.Hiep Quang Luong en ir. Sean Rul.

Ten slotte wens ik ir. Paul Vernemmen, de peetvader van AUDI en AUDI fast engewaardeerde collega, een speciaal dankwoord te geven. Zonder de ondersteuning enfeedback van Paul zou deze Masterproef slechts een schim zijn van wat het uiteindelijkgeworden is. Bedankt aan allen!

ing. Mario Van de Velde, mei 2010.

Toelating tot bruikleen

De auteur geeft de toelating deze thesis voor consultatie beschikbaar te stellen en delenervan te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingenvan het auteursrecht, in het bijzonder met betrekking tot de verplichting uitdrukkelijk debron te vermelden bij het aanhalen van resultaten uit deze thesis.

The author gives the permission to use this thesis for consultation and to copy parts of itfor personal use. Every other use is subject to the copyright laws, more specifically thesource must be extensively specified when using results from this thesis.

ing. Mario Van de Velde, mei 2010.

Classificatie van documenten met behulp van OpenCL

Mario Van de Velde

Masterproef ingediend tot het behalen van de academische graad vanMaster in de ingenieurswetenschappen, afstudeerrichting Software Engineering

Academiejaar 2009-2010

Promotoren: prof. dr. ir. Wilfried Philips, prof. dr. ir. Koen De BosschereScriptiebegeleiders: dr. ir. Hiep Quang Luong, ir. Sean Rul,

ir. Paul Vernemmen (RecoMatics n.v.)

Universiteit GentFaculteit Toegepaste WetenschappenVakgroep Elektronica en informatiesystemenVoorzitter: prof. dr. ir. Jan Van CampenhoutVakgroep Telecommunicatie en informatieverwerkingVoorzitter: prof. dr. ir. Herwig Bruneel

Samenvatting

In deze thesis wordt een bestaand sequentieel geïmplementeerd documentclassificatiealgoritme kwalitatief en kwantitatief geanalyseerd en vervolgens omgezet naar een parallelgeïmplementeerd documentclassificatie algoritme.

De parallelle implementatie toont aan dat: gegeven een grafische verwerkingseenheidmet 6 multiprocessoren en 48 processoren een versnelling van 12 maal kan verwezenlijktworden.

De parallelle implementatie wordt uitgevoerd met behulp van OpenCL in combinatiemet het Microsoft .NET 3.5 raamwerk.

Trefwoorden

Documentclassificatie, GPU, OpenCL

Classification of documents by means of the OpenCL frameworkMario Van de Velde

Supervisors: Wilfried Philips, Koen De Bosschere

Abstract – Automatic document classification mustbe accurate and fast; a well-designed algorithm andenough processing power can meet theserequirements. Nowadays, Graphical Processing Units(GPU) provide massively processing power; more than470 GFLOPS is no exception. Using OpenCL (a standardframework for parallel programming), we convertedan existing sequential classification algorithm into aparallel classification algorithm. Using the OpenCLframework we managed to decrease the classificationtime for one document from 9.4 to 0.8 seconds.

Keywords – Document classification, GPU, OpenCL

I. INTRODUCTION

n most cases electronic document management systems(EDMS) require automated document classification.Wikipedia defines document classification as “Assign

an electronic document to one or more categories, basedon its contents” [1]. In 2004 RecoMatics n.v. developed aclassification module called Automatic DocumentIdentification or AUDI in short. An improved and fasterclassification algorithm was introduced in 2007; for atypical configuration of more than 5000 distinctcategories this version is about two times faster.

This improved classification algorithm called AUDI fastis scheduled on a single processor core and scales linearO(n) with the number of categories that it needs todistinguish. Nowadays the processing power of thegraphical cards (also known as graphical processing unitor GPU) increased dramatically. GPUs are probablytoday’s most powerful computational hardware that youcan get per dollar [2].

The goal of this paper is to convert the sequential-executed AUDI fast classification algorithm into aparallel-executed classification algorithm.

II. AUDI FAST CLASSIFICATION

The AUDI fast classification algorithm is privateproperty of RecoMatics n.v. and can therefore not beexplained in detail in this paper. We will only brieflysummarize the building blocks and the processing steps ofthe AUDI fast algorithm.

The AUDI fast classification works with a librarycontaining approximately 5000 known documents. Theclassification of an unknown document starts by scanningthe document by means of a scanning device. This resultsin a 200 DPI 24-bits per pixel colour image.

For each known document category a fingerprint isdefined in the library. A fingerprint describes the uniqueproperties of the known document. A fingerprint in fact isa set of features. The features are built upon three types ofpixel patches of which specific attributes are computed.

M. Van de Velde is affiliated with RecoMatics n.v., W.Philips is with UGent-TELIN-IPI-IBBT and K. DeBosschere is with UGent-ELIS

Using the library with known document categories andusing the 200 DPI colour image the classification canstart: the first step is the conversion of the colour image soit can be used to calculate a classification and validationscore; for each fingerprint a classification score iscalculated – the result of this calculation is a sorted andfiltered set of fingerprint definitions; for each fingerprintdefinition where the classification score is bigger thansome threshold, a validation score is calculated.

Finally the algorithm will classify an unknowndocument if both the classification score and thevalidation score are bigger than some predefinedthresholds. The according class or category of thefingerprint definition with this property is then assigned tothe unknown document resulting in a known document.

III. THE GPU AND OPENCL FRAMEWORK

A. Graphical Processing UnitsReferring to Figure 1, a GPU device consists of N

multiprocessors each containing M processors. Eachprocessor has its own private registers; eachmultiprocessor has on-chip shared memory; allmultiprocessors can use the device memory.

Figure 1. The NVIDIA GPU device and memoryarchitecture [3].

All processors of one multiprocessor execute, followingthe Single Instruction Multiple Data (SIMD) paradigm,one and the same instruction sequence.

B. OpenCLOpen Computing Language (OpenCL) is an open

standard for cross-platform, parallel programming ofmodern processors such as CPUs, GPUs, DSPs and Cellprocessors [4].

I

The OpenCL specification version 1.0 can be found atthe Khronos website and consists of an API forcoordinating parallel computation across heterogeneousprocessors and a cross-platform programming language.

IV. PARALLEL CLASSIFICATION

Before the classification can start, the database withfingerprint descriptions (known documents) must betransferred to the device (GPU). This transfer is done onceat start-up. The transfer of 5120 fingerprint descriptionscurrently takes about 75.20 ms.

The parallel implementation of the AUDI fast algorithmis divided into the following processing steps:

1. Preparation of the (unknown document) image isdone on the host (CPU) – this step is obviouslydone once per unknown document. Using the IntelCore i5-430M processor this step takes 13.51 ms;

2. Transfer of the prepared image from the host(CPU) to the device (GPU) – the transfer time islimited by the speed of the PCI Express bus and forour hardware platform this is 5.84 ms for an A4image of 200 DPI;

3. Calculation of the classification score on the GPU.This step can be massively parallelized because thecalculation of the classification score for eachfingerprint definition can be done independently;

4. Validation preparation of the (unknown document)image is done once and executed on the CPU;currently this non-optimized implementation takesabout 70.00 ms – this step can be improved, but fornow this is not the bottleneck;

5. Calculation of the validation score on the CPU. Thevalidation score calculation is only required forthose fingerprints of which the classification scoreis bigger than some threshold, as such thevalidation is only calculated for typically 5fingerprints. E.g., for a fingerprint librarycontaining 129 known documents this calculationtakes about 1.30 ms.

V. RESULTS

The parallel implementation of the AUDI fast algorithmimplies the knowledge of the GPU internals. Whenprogramming the GPU, memory usages and kernelscheduling are important performance factors.

The parallel implementation of the AUDI fastclassification algorithm leads to some promising results.Table 1 gives an overview of our implementation.

The initial implementation was used to get thealgorithm calculations correct. Using the NVIDIAGeForce GT 230M GPU this initial implementation wasused to classify an unknown document with respect to5120 classes. The initial implementation resulted in aninitial speedup of about 7 times the sequentialimplementation.

Improving the classification algorithm by changing thecalculation sequence of the pixel patches and optimizingscore calculation resulted in a comparable speedup.

Next we explored the constant memory cache: thefingerprint definition was tagged as constant, thereforeenabling the use of the constant memory cache. Thisresulted in a significant speedup of 13.

Changing the thread scheduling from a 2-dimensional toa 3-dimensional space and optimizing the workgroup size

resulted in an additional improvement. Finally we need toextend the parallel implementation of the classificationalgorithm by adding a maximum reduction kernel. Thisadditional processing step introduced an extra 348.06 msresulting in a total processing time of 792.98 ms.

The original classification of an unknown documentwith respect to 5120 classes takes more than 9.4 seconds.Using a GPU with 6 multiprocessors and 48 processors,the final parallel implementation takes 792.98 ms. Thisrepresents a speedup of about 12. Knowing that aprofessional GPU has up to 480 processors, theoreticallythe speedup can be 120.

Table 1. Parallel classification using the NVIDIAGeForce GT 230M GPU.

Time (ms) SpeedupCPU/GPU

Initial implementation 1328.89 7.09Algorithm improvement 1295.05 7.27Use constant cache 694.24 13.57Improved scheduling 444.93 21.17Score calculation 792.98 11.88

VI. CONCLUSIONS

The results of this paper show that the conversion of asequential implementation to a parallel implementationcan indeed improve the overall performance.

The combined improvement of 11.88 is significant, butthere are still some open questions that need to beanswered: How will the implementation scale on aprofessional GPU? What is the behaviour of theimplementation using a GPU supplied by another vendor(e.g. AMD)? These questions will be answered in ourfuture work.

ACKNOWLEDGEMENTS

The author would like to thank Paul Vernemmen for hishelp and patience while implementing the AUDI fastalgorithm on the GPU. We also thank Hiep Quang Luongand Sean Rul for their suggestions and reviews. Finallywe would like to thank Wilfried Philips and Koen DeBosschere to give us the opportunity to do this research.

REFERENCES

[1] Wikipedia, the free encyclopedia, Documentclassification,http://en.wikipedia.org/wiki/Document_classification, 2010.

[2] John D. Owens, David Luebke, Naga Govindaraju,Mark Harris, Jens Krüger, Aaron E. Lefohn, and TimPurcell. A Survey of General-Purpose Computationon Graphics Hardware. Computer Graphics Forum,26(1):80–113, March 2007.

[3] NVIDIA, OpenCL Programming Guide for theCUDA Architecture, version 2.3, 2009.

[4] Khronos, OpenCL - The open standard for parallelprogramming of heterogeneous systems,http://www.khronos.org/opencl/.

1

Inhoudsopgave

Hoofdstuk 1 Inleiding .......................................................................................................... 4

1.1 Uitgangspunt .............................................................................................................. 4

1.2 Doelstelling................................................................................................................. 5

1.3 Thesisindeling ............................................................................................................ 5

Hoofdstuk 2 Achtergrondinformatie.................................................................................. 6

2.1 Het classificeren van documenten met AUDI fast ................................................ 6

2.1.1 Voorbereiden ter classificatie................................................................................... 7

2.1.2 Classificeren............................................................................................................. 8

2.1.2.1 Classificatiebouwstenen............................................................................... 9

2.1.2.2 Classificatieresultaten .................................................................................. 9

2.1.3 Valideren van de classificatie ................................................................................ 11

2.2 De Grafische Verwerkingseenheid........................................................................ 12

2.2.1 Architectuur van de NVIDIA GVE ....................................................................... 13

2.2.2 Geheugenhiërarchie van de NVIDIA GVE............................................................ 14

2.3 Open Computing Language (OpenCL)................................................................. 15

2.3.1 De OpenCL architectuur ........................................................................................ 16

2.3.2 Het OpenCL uitvoeringsmodel .............................................................................. 17

2.3.3 Het OpenCL geheugenmodel................................................................................. 17

2.3.3.1 Globaal geheugen ....................................................................................... 18

2.3.3.2 Lokaal geheugen......................................................................................... 19

Hoofdstuk 3 Resultaten en analyse .................................................................................. 20

3.1 Gebruikte hardware ................................................................................................. 20

3.2 Gebruikte software .................................................................................................. 22

3.3 AUDI fast op de CVE ............................................................................................. 23

2

3.3.1 Referentiebibliotheek............................................................................................. 23

3.3.2 Kwantitatieve analyse (snelheid) ........................................................................... 24

3.3.3 Kwalitatieve analyse (accuraatheid) ...................................................................... 27

3.3.3.1 De invloed van rotatie ................................................................................ 27

3.3.3.2 De invloed van ruis..................................................................................... 29

3.4 AUDI fast op de GVE............................................................................................. 31

3.4.1 Datatransfer van host naar device .......................................................................... 31

3.4.2 De AUDI fast pijplijn............................................................................................. 33

3.4.3 Een AUDI fast sessie ............................................................................................. 35

3.4.3.1 Opstarten AUDI fast pijplijn..................................................................... 35

3.4.3.2 Afbreken AUDI fast pijplijn ..................................................................... 36

3.5 Parallelle classificatie op de GPU ......................................................................... 37

3.5.1 Validatie van de parallelle implementatie van de classificatie .............................. 37

3.5.2 Tijdsmeting van de parallelle implementatie van de classificatie.......................... 38

3.5.3 Eerste implementatie van de parallelle classificatie [IMPL1] ............................... 40

3.5.4 Tweede implementatie van de parallelle classificatie [IMPL2]............................. 42

3.5.5 Derde implementatie van de parallelle classificatie [IMPL3]................................ 43

3.5.6 Vierde implementatie van de parallelle classificatie [IMPL4]............................... 44

3.5.7 Vijfde implementatie van de parallelle classificatie [IMPL5] ............................... 49

Hoofdstuk 4 Vaststellingen, besluit en verder onderzoek............................................. 52

4.1 Vaststellingen........................................................................................................... 52

4.2 Besluit ....................................................................................................................... 53

4.3 Verder onderzoek..................................................................................................... 54

3

Lijst met gebruikte afkortingen

• API: Application Programming Interface• AUDI: Automatic Document Identification• BPP: Bits Per Pixel• CD: Computing Device• CU: Computing Unit• CUDA: Compute Unified Device Architecture• CVE: Centrale verwerkingseenheid• DPI: Dots Per Inch• EDMS: Elektronische Document Management Systemen• GPGPU: General Purpose Graphical Processing Unit• GVE: Grafische verwerkingseenheid• IPP: Integrated Performance Primitives• OpenCL: Open Computing Language• PE: Processing Element• SDK: Software Development Kit• SIMD: Single Instruction Multiple Data

4

Hoofdstuk 1

Inleiding

1.1 Uitgangspunt

Elektronische document management systemen (EDMS) vereisen in de meeste gevalleneen documentclassificatie. Onder documentclassificatie verstaan we: “aan de hand van deinhoud van een (elektronisch) document een bepaalde klasse aan het (elektronisch)document toekennen” [17]. Een typisch toepassingsvoorbeeld is het factuurdocument. Elkeleverancier heeft zijn eigen gepersonaliseerde lay-out en aan de hand van de inhoud van defactuur, meerbepaald de discriminerende kenmerken van de gepersonaliseerde lay-out, kanhet document volgens leverancier geclassificeerd worden.

RecoMatics n.v. is een systeemintegrator dewelke gespecialiseerd is in het domain vanEDMS. Een deeldomein binnen EDMS is het elektronisch verwerken vanfactuurdocumenten. Hiervoor werd in 2004 de herkenningsmodule AUDI1 ontwikkeld.Deze module is in staat om aan de hand van een gesuperviseerd geleerde bibliotheek vanfactuurdocumenten een correcte classificatie uit te voeren. Het classificeren van ééndocument neemt op een hedendaagse processor typisch 15 tot 20 seconden in beslag.Daarom werd in 2007 een nieuw classificatiealgoritme ontwikkeld. Ditclassificatiealgoritme kreeg de naam AUDI fast.

Een AUDI fast classificatie neemt per klasse typisch 2 milliseconden in beslag. Hetclassificeren van één factuurdocument ten opzichte van een bibliotheek met bijvoorbeeld5000 gekende factuurdocumenten neemt bijgevolg ongeveer 10 seconden in beslag (5000classificaties, elke classificatie 2 ms).

1 AUtomatic Document Identification

5

1.2 Doelstelling

De doelstelling van deze thesis is dubbel. Eerst wensen we het bestaande AUDI fastclassificatiealgoritme kwalitatief en kwantitatief te analyseren. Vervolgens wensen we hetalgoritme te converteren van een sequentieel uitvoeren op een centrale verwerkingseenheid(CVE) naar een parallel uitvoeren op een CVE in combinatie met een grafischeverwerkingseenheid (GVE).

Deze laatste doelstelling staat niet op zichzelf. Deze doelstelling is het gevolg van debasis doelstelling: “het versneld classificeren van documenten”. In de praktijk, in cijfersuitgedrukt, komt dit neer op: “Tot 200.000 pagina’s2 classificeren in een tijdspanne van 8uur”.

Hierbij gaan we uit van een bibliotheek met 5120 elementen. Een bibliotheek met 5120elementen blijkt in de praktijk een realistische grootte te zijn: de classificatie met behulpvan AUDI wordt momenteel beperkt tot 5000 elementen. Echter, we kiezen een totaal van5120 elementen omdat dit een veelvoud van 64 is en vanuit praktisch oogpunt enkelevoordelen heeft. Deze praktische voordelen worden in paragraaf 3.5.6 in detail beschreven.

200.000 pagina’s in 8 uur classificeren impliceert een classificatiesnelheid van 6,94pagina’s per seconde – afgerond is de doelstelling dus 7 pagina’s per seconde classificerenten opzichte van een bibliotheek met 5120 elementen.

1.3 Thesisindeling

In grote lijnen is deze thesis ingedeeld in twee hoofdstukken. In het eerste hoofdstukwordt de achtergrondinformatie, dewelke bij het uitvoeren van deze thesis gebruik is,beschreven. In het tweede hoofdstuk wordt eerst een analyse gemaakt van de bestaandeimplementatie van het classificatiealgoritme en wordt vervolgens de gevolgde werkwijzeen de resultaten van de nieuwe geparallelliseerde implementatie van hetclassificatiealgoritme beschreven.

Indien het classificeren van documenten, de centrale verwerkingseenheid (CVE), degrafische verwerkingseenheid (GVE) en het OpenCL raamwerk voor u geen geheimenmeer heeft, dan start u best ineens met hoofdstuk 3 op pagina 20. In het andere geval is hetraadzaam dat u eerst hoofdstuk 2 op de volgende pagina doorneemt om vervolgens over tegaan naar hoofdstuk 3.

2 Voor de eenvoud van de redenering veronderstellen we steeds dat één document één pagina betekent.

6

Hoofdstuk 2

Achtergrondinformatie

In onderstaande paragrafen geven we eerst een overzicht van het AUDI fast algoritme.Aangezien het AUDI fast algoritme eigendom is van RecoMatics n.v. hebben we niet detoestemming om het algoritme publiek te maken. Om de rest van de thesis te begrijpen,beschrijven we het AUDI fast algoritme aan de hand van een aantal tussenliggendeberekeningsresultaten. Deze grafische voorstellingen volstaan om de lezer voldoendeinzicht te geven om het vervolg van deze thesis te kunnen volgen.

Naast het AUDI fast algoritme is een basiskennis van grafische verwerkingseenheden(GVE) vereist. Onderstaande paragraaf beschrijft dan ook enkele basisconcepten van eenGVE. Naast de benodigde GVE hardware is er ook aansturingssoftware nodig. Uiteindelijkhebben we gekozen om gebruik te maken van OpenCL (Open Computing Language), dit iseen standaard raamwerk en API beheerd door de Khronos werkgroep [8].

2.1 Het classificeren van documenten met AUDI fast

Het uitgangspunt van de classificatie is een bibliotheek met “gekende documenten”.Overeenkomstig elk “gekend document” wordt een vingerafdruk genomen. Dezevingerafdruk beschrijft de typische kenmerken van het “gekende document”. We gaan uitvan een bibliotheek met 5120 vingerafdrukken.

Een te classificeren “ongekend papieren document” wordt eerst met behulp van eenscantoestel gedigitaliseerd. De classificatie vertrekt uitgaande van een 24 bpp3, 200 dpi4,kleurenbeeld.

3 bpp: bits per pixel4 dpi: dots (pixels) per inch (2,54 cm)

7

Figuur 1: Principewerking classificatie met behulp van AUDI fast.

De classificatie wordt schematisch in Figuur 1 weergegeven. Uitgaande van (1) debibliotheek met vingerafdrukken en (2) het kleurenbeeld van het “ongekende document”kan de classificatie middels AUDI fast gestart worden. Het eindresultaat van declassificatie is (3) een “gekend document”.

De AUDI fast classificatie gebeurt in enkele sequentiële stappen. In grote lijnen kunnenwe deze stappen als volgt opdelen:

1. Het voorbereiden van het (elektronisch) document ter classificatie;

2. Het classificeren van het (elektronisch) document ten opzichte van alle “gekendedocumenten”;

3. Het valideren van de classificatie.

2.1.1 Voorbereiden ter classificatie

Een eerste bewerking die tijdens de voorbereiding uitgevoerd wordt, is het rechtzettenvan het gescande beeld. Zoals beschreven in paragraaf 3.3.3.1 is het AUDI fast algoritmebeperkt bestand tegen een rotatie van het “ongekende document” ten opzichte van het“gekende document”. Om het falen van de classificatie ten gevolge van de scanrotatietijdens de beeldopname te minimaliseren wordt het beeld eerst recht gezet. Dezebewerking is bij de aanvang van deze thesis nog niet in de AUDI fast implementatievoorzien.

Het classificatiealgoritme maakt gebruik van bepaalde documenteigenschappen: dezedocumenteigenschappen noemen we features. De features worden op het “ongekendedocument” berekend. Een feature bestaat uit meerdere pixelvlakken. De gemiddelde

8

intensiteiten van deze pixelvlakken vormen de basis van het AUDI fastclassificatiealgoritme.

Tijdens de classificatievoorbereiding wordt het beeld van het “ongekende document”geconverteerd naar een beeld waarmee de gemiddelde intensiteitsberekening per pixelvlaksnel uitgevoerd kan worden. Dit beeld noemen we het integraalbeeld: het integraalbeeld iseen 32 bpp enkelvoudige precisie vlottende kommagetal beeld.

Zoals hierna beschreven bestaat de classificatie uit twee stappen: classificeren envalidatie van de classificatie. Om de verwerkingstijd tijdens de validatiestap minimaal tehouden volstaat het om gebruik te maken van een laagresolutiebeeld. Hethoogresolutiebeeld van 200 dpi wordt tijdens de voorbereiding omgezet naar eenlaagresolutiebeeld van 100 dpi. De classificatiestap gebruikt het 200 dpi beeld, terwijl devalidatiestap het 100 dpi beeld gebruikt.

2.1.2 Classificeren

Het classificeren van het “ongekende document” ten opzichte van alle “gekendedocumenten” resulteert in het uiteindelijk filteren en sorteren van de lijst met “gekendedocumenten”. Het sorteren gebeurt aan de hand van een berekende score en het filterengebeurt aan de hand van een verwachte minimale score. De berekende score is een maatvoor de graad van overeenstemming van het “ongekende document” ten opzichte van elk“gekend document” in de bibliotheek.

De kern van de classificatie is aldus het berekenen van de classificatiescore in hetinterval [0, 100], waarbij een lage en een hoge score respectievelijk een slechte en eengoede overeenkomst betekent. Naast de classificatiescore wordt voor elk “gekenddocument” de (X, Y) translatie ten opzichte van het “ongekende document” bepaald. Deze(X, Y) translatie wordt tijdens de validatiestap in rekening gebracht (zie verder in paragraaf2.1.3).

Aangezien het AUDI fast algoritme en dus de berekening van de classificatiescore nietpubliek is, beperken we ons tot een aantal tussenliggende resultaten.

Figuur 2: Bouwstenen van een AUDI fast feature.

9

2.1.2.1 Classificatiebouwstenen

Op niveau van een feature onderscheiden we drie soorten pixelvlakken: tussenruimtes(GAP), achtergrond (BACKGROUND) en tekst (TEXT).

In Figuur 2 wordt één feature weergegeven. In de praktijk bevat één vingerafdrukgemiddeld een 3-tal features. Het in de figuur weergegeven feature bevat vier GAPs(paars), vier BACKGROUNDs (groen) en vier TEXTs (blauw) pixelvlakken. Elk pixelvlakrepresenteert één bepaalde eigenschap van het “gekende document”:

• GAP: ruimte tussen de voorgrondobjecten;• BACKGROUND: de regelruimte tussen de voorgrondobjecten;• TEXT: de inhoud en vorm van de voorgrondobjecten.

2.1.2.2 Classificatieresultaten

De aanwezigheid van een verschuiving tussen het “gekende document” en het“ongekende document” is bij het uitwerken van het AUDI fast algoritme voorzien onder devorm van een afstandsmatrix. Dit is een matrix van 96 op 96 punten waarbij elk punt eenbepaalde (X, Y) verschuiving voorstelt. Gegeven dat er gebruik gemaakt wordt van 200dpi beelden is een verschuiving van ongeveer 0,6 cm (in plus en min) toegestaan. Het punt(48, 48) komt overeen met geen verschuiving, 96 pixels op een 200 dpi beeld komtovereen met 0,48 inch of 1,219 cm.

Voor elk type pixelvlak wordt de afstandsmatrix op een specifieke manier berekend.Hierbij worden de pixelvlakken per type gecombineerd en worden vervolgens dezeresulterende afstandsmatrices gecombineerd tot één feature afstandsmatrix. Hetuiteindelijke resultaat voor de gegeven vingerafdruk is een combinatie van alle featureafstandsmatrices. Ter verduidelijking worden in Figuur 3 de individuele afstandsmatricesvisueel voorgesteld. Bovenaan worden de verschillende soorten pixelvlakkenweergegeven. Elk type pixelvlak resulteert in een specifieke afstandsmatrix. Dezeafstandsmatrices worden in de tweede rij weergegeven. Finaal worden deze drieafstandsmatrices gecombineerd tot één feature afstandsmatrix.

In Figuur 4 wordt een overzicht gegeven van de verschillende afstandsmatrices. Elke rijin de figuur toont de afstandsmatrices van één afzonderlijk feature. De rechtse kolom toontde gecombineerde afstandsmatrix van elk feature. De eerste kolom toont deafstandsmatrices van de GAP pixelvlakken; de tweede kolom toont de afstandsmatricesvan de BACKGROUND pixelvlakken; de derde kolom toont de afstandsmatrices van deTEXT pixelvlakken. Onderaan rechts wordt de afstandsmatrix van de vingerafdrukweergegeven.

10

In het geval van een overeenstemming ontstaat een afstandsmatrix met een zogenaamde“oogstructuur”: centraal is er een witte zone omringd door een zwarte canvas. De positievan de witte zone is een maat voor de verschuiving van het “ongekende document” tenopzichte van het “gekende document”.

Figuur 3: Tussenliggende afstandsmatrices van één feature.

Figuur 4: Tussenliggende afstandsmatrices van één vingerafdruk.

11

2.1.3 Valideren van de classificatie

De classificatiestap resulteert in het uiteindelijk filteren en sorteren van de lijst met“gekende documenten”. In de validatiestap wordt nu een finale beslissing genomen.

In de praktijk blijkt dat, gegeven een bibliotheek met honderden diversevingerafdrukken, de lijst met kandidaat “gekende documenten” beperkt is tot maximaal een5-tal elementen en gemiddeld 1,5 elementen bevat. Enkel de “gekende documenten”waarvan de classificatiescore hoger is dan 90 worden als kandidaat van de classificatiestapweerhouden in de validatiestap; in de praktijk blijkt 90 een juiste drempelwaarde te zijn.

De validatie maakt gebruik van de overeenstemming tussen een selectief aantal tekstvlakken, meer bepaald het verschil in intensiteitsverloop van een tekst zone: dit resulteertin een validatiescore in het interval [0, 100]. Een validatiescore van minimaal 75 resulteertin een finale (positieve) beslissing.

Figuur 5 en Figuur 6 geven een voorbeeld van respectievelijk een positieve en eennegatieve validatie.

Figuur 5: Voorbeeld van een positieve validatie; de uiteindelijke validatiescore is groter dan 75.

Figuur 6: Voorbeeld van een negatieve validatie; de uiteindelijke validatiescore iskleiner dan of gelijk aan 75.

12

Grafiek 1: Evolutie performantiekloof tussen de GVE (groen) en de CVE (blauw) [14].

2.2 De Grafische Verwerkingseenheid

De hedendaagse grafische verwerkingseenheden (GVE) zijn vermoedelijk de meestperformante hardware per eenheidsprijs [6].

Nemen we als voorbeeld de NVIDIA GeForce GTS 250 met 1GB geheugen en eentheoretische geheugen bandbreedte5 van 70,4 GB/s: de kostprijs bedraagt (anno 2010)slechts 140,- EUR. Naast de hoge bandbreedte is de vlottende komma rekensnelheid van470 GFLOPS [3] tot zes maal sneller dan bijvoorbeeld de Intel Core i7 processor. De IntelCore i7 processor bestaat uit 4 kernen en heeft een piek berekeningsnelheid van 70GFLOPS. Grafiek 1 geeft een overzicht van de evolutie van de performantie kloof tussende CVE en de GVE. De grafiek vergelijkt de piekperformantie in GFLOPS van deNVIDIA GVE (groen) ten opzichte van de Intel CVE (blauw).

De twee belangrijkste producenten van grafische verwerkingseenheden zijn NVIDIA enAMD6 (zie Figuur 7). Beide nemen meer dan 85% van de markt in beslag [16]. Inonderstaande thesis beperken we ons tot de NVIDIA grafische verwerkingseenheden. In devolgende paragrafen beschrijven we de belangrijkste eigenschappen van de NVIDIA GVE.

Figuur 7: Marktaandeel producenten GVEs [16].

5 Kloksnelheid is 1,1 GHz, 256-bit interface DDR: 1,1 . (256/8) . 2 = 70,4 GB/s6 In 2006 werd ATI ((Array Technology Industry) door AMD (Advanced Micro Devices) overgenomen.

13

2.2.1 Architectuur van de NVIDIA GVE

De architectuur van een GVE was initieel ontworpen om louter dienst te doen alsprocessor van een grafische videokaart. Pas later werd de GVE gebruikt als coprocessorom berekende 2D of 3D beelden in real-time op het scherm te visualiseren. Deze takenkunnen massaal in parallel uitgevoerd worden. De nood aan deze massaal parallelleverwerking heeft bijgedragen tot de hedendaagse architectuur van de GVE.

De GVE is geïmplementeerd als een set van zogenaamde multiprocessoren. Elkemultiprocessor heeft een Single Instruction Multiple Data (SIMD) architectuur en bestaattypisch uit acht processoren. Bij elke klokcyclus wordt door alle processoren van éénmultiprocessor, in parallel, dezelfde instructie uitgevoerd. Hierbij wordt de instructietoegepast op verschillende datablokken, vandaar de naam SIMD. Nemen we als voorbeeldde NVIDIA GeForce GTX 295 grafische kaart (een referentie van wat anno 2010 praktischhaalbaar is); deze beschikt per GVE - er zijn er 2 - over 30 multiprocessoren met permultiprocessor 8 processoren, wat resulteert in een totaal van 240 processoren per GVE, endus in totaal 480 processoren voor deze grafische kaart.

In tegenstelling tot de CVE wordt bij de GVE meer transistoren gebruikt voor derekeneenheden (ALU) en minder transistoren gebruikt voor de controle- en decachegeheugeneenheid. De typische architectuur van een CVE en een GVE wordt inFiguur 8 weergegeven. Omdat dezelfde instructie door verschillende rekeneenhedenuitgevoerd wordt, is er minder behoefte aan een ingewikkelde controle eenheid. Omdat deuitgevoerde instructies in de meeste gevallen rekenintensief zijn, kan de geheugenlatentieverborgen worden en is er minder nood aan grote geheugencaches [14].

Figuur 8: Typische architectuur van een CVE (links) en een GVE (rechts) [14].

14

Figuur 9: Geheugenhiërarchie van een NVIDIA GVE [14].

2.2.2 Geheugenhiërarchie van de NVIDIA GVE

De typische architectuur van de GVE vereist een aangepaste geheugenhiërarchie. Figuur9 geeft een schematisch overzicht van de bouwstenen van de GVE met de bijhorendegeheugenhiërarchie. De GVE (device) bevat N multiprocessoren, elke multiprocessor bevatop zijn beurt M processoren. Elke processor binnen één multiprocessor maakt gebruik vandezelfde instructieeenheid (instruction unit).

De geheugenhiërarchie is als volgt opgebouwd:

• Elke processor beschikt over een eigen set van 32 bit registers;

• Elke multiprocessor beschikt over gedeeld geheugen (shared memory); elkeprocessor binnen de desbetreffende multiprocessor heeft hierbij lees- enschrijfrechten;

• Elke multiprocessor beschikt verder ook over een constant geheugen cache entextuur geheugen cache. Deze caches worden gebruikt bij het lezen van constant- oftextuurgeheugen;

• Ten slotte beschikt de GVE (device) over het devicegeheugen. Dit geheugen is voorelke processor binnen elke multiprocessor zowel voor lees- als schrijfactiesbeschikbaar.

15

Nemen we terug als voorbeeld de NVIDIA GeForce GTX 295 grafische kaart; dezeGVE beschikt per GVE over [4]:

• 16 KB registers per multiprocessor, of 2 KB registers per processor;

• 16 KB gedeeld geheugen per multiprocessor;

• 64 KB constant cache per multiprocessor;

• 6 tot 8 KB textuur cache per multiprocessor;

• 1,792 GB DDR3 devicegeheugen.

2.3 Open Computing Language (OpenCL)

OpenCL (Open Computing Language) is een programmeertaal en platform ontwikkelddoor Apple voor het uitvoeren van parallelle berekeningen op ondermeer de CVE en deGVE. De taal is gebaseerd op C en stelt applicaties in staat om de GVE te gebruiken vooralgemene berekeningen (ook bekend als GPGPU) [18].

De OpenCL standaard wordt beheerd door de Khronos werkgroep en heeft alsdoelstelling het standaardiseren van berekeningen op heterogene data, alsook parallelleberekeningen op heterogene toestellen (devices) zoals o.a. de centrale verwerkingseenheid(CVEs), de grafische verwerkingseenheid (GVEs), de digitale signaalprocessor (DSPs) ende Cell processor.

In deze thesis beperken we ons tot parallelle berekeningen op de GVE. Ondanks dezebeperking bied OpenCL enkele belangrijke voordelen ten opzichte van andere parallelleplatformen zoals bijvoorbeeld CUDA:

• Om te beginnen is OpenCL een standaard die ondermeer door de twee belangrijksteGVE fabrikanten NVIDIA en AMD ondersteund wordt. Hierdoor kan deimplementatie onafhankelijk van de gekozen GVE uitgevoerd worden en kan, inprincipe, een combinatie van meerdere (verschillende) GVE toestellen gebruiktworden;

• OpenCL, oorspronkelijk ontwikkeld door Apple, is beschikbaar voor meerderebesturingssystemen. Zo wordt OpenCL ondersteund door: Linux, Windows enMacOS;

• Ten slotte biedt OpenCL de mogelijkheid om tijdens de ontwikkeling de softwareop de CVE uit te voeren. Hierdoor kan tijdens de ontwikkeling het systeem eerstgetest worden op de CVE. Dit maakt het opsporen en analyseren van fouten eenstuk gemakkelijker. Na het debuggen kan vervolgens de performantie getestworden op de GVE.

16

Figuur 10: OpenCL Architectuur [12]

2.3.1 De OpenCL architectuur

De OpenCL architectuur wordt in Figuur 10 weergegeven. De gastheer (host) is in demeeste gevallen een CVE: deze host is met behulp van de PCI express bus verbonden metéén of meerdere rekenhardware (Computing Device, CD). Deze rekenhardware is de GVE.Vanuit het standpunt van OpenCL kan deze rekenhardware door verschillende fabrikantengeproduceerd zijn. Het is dus perfect mogelijk om één (of meerdere) NVIDIA GVE(s) enéén (of meerdere) AMD GVE(s) te combineren tot een set van rekenhardware [9].

Een rekenhardware bevat op zijn beurt uit meerdere rekeneenheden (Computing Unit,CU): deze rekeneenheden is een multiprocessor. Een rekeneenheden bestaat op zijn beurtuit meerdere verwerkingselementen (Processing Element, PE).

Bovenstaande architectuur reflecteert het heterogeen karakter van OpenCL. Een OpenCLprogramma wordt uitgevoerd op de host en verstuurt commando’s naar de rekenhardware.Het commando wordt op de rekenhardware in parallel uitgevoerd. Een typisch OpenCLprogramma bestaat aldus uit een sequentie van instructies die uitgevoerd worden op dehost en vervolgens instructies die (gelijktijdig) uitgevoerd worden op de rekenhardware.

Bijvoorbeeld de NVIDIA GeForce GTX 295 beschikt over 2 CD, per CD zijn er 30 CU,elke CU beschikt over 8 PE, waardoor deze GVE in totaal over 2x240, hetzij 480 PEbeschikt.

17

Figuur 11: OpenCL, structuur van een 1-dimentionele NDRange [11].

2.3.2 Het OpenCL uitvoeringsmodel

Een GVE is in staat om een zogenaamde kernel uit te voeren. Een kernel is een functiedie een bepaalde bewerking uitvoert. Een kernel wordt voor een bepaalde GVEgecompileerd tot een OpenCL programma en binnen een zogenaamde NDRange teruitvoering gepland op de GVE.

Een NDRange (N-dimensionale range, met N in het bereik [1-3]) is een indexruimtewaarin een kernel geplaatst wordt. Op deze manier kan de werkruimte onderverdeeldworden in verschillende subruimtes en kan elke kerneluitvoering een werkgebied in desubruimte berekenen. Het OpenCL uitvoeringsmodel volgt aldus het Single InstructionMultiple Data (SIMD) paradigma.

Een kernelnstantie wordt in het OpenCL raamwerk een werkitem genoemd. De OpenCLfunctie get_global_id(0) bepaalt de index binnen de NDRange. Verschillende werkitemsworden gegroepeerd tot één werkgroep. Een werkgroep wordt op één rekenhardwareuitgevoerd. De werkitems worden in blokken (warps) van 32 draden (threads) uitgevoerd.

Binnen één rekeneenheden worden de instructies van één warp instructie per instructieen in parallel uitgevoerd. Er worden dus in totaal 32 instructies per warp op een CUopgestart.

Figuur 11 geeft een voorstelling van een typische NDRange. In dit geval gaat het overeen 1DRange waarbij elke werkgroep opgebouwd is uit 8 werkitems.

2.3.3 Het OpenCL geheugenmodel

Het OpenCL geheugenmodel komt in grote lijnen overeen met de geheugenhiërarchiezoals beschreven in paragraaf 0. Binnen het OpenCL raamwerk wordt aan elk typegeheugen een specifieke terminologie gekoppeld: privaat geheugen, lokaal geheugen,constant geheugen en globaal geheugen.

Figuur 12 geeft een overzicht van de verschillende types geheugen. Rechts wordt descoop en de levensduur van elk geheugentype weergegeven; centraal wordt de OpenCLterminologie aangegeven; links wordt een typische GVE configuratie aangegeven.

18

Figuur 12: OpenCL geheugenmodel [12].

De twee geheugentypes: lokaal geheugen en globaal geheugen verdienen wat extraaandacht. Het juiste gebruik van beide types kan immers een groot performantie verschiltot gevolg hebben.

2.3.3.1 Globaal geheugen

Het globaal geheugen heeft de grootste capaciteit (tot 4 GB) en tevens de kleinstebandbreedte (en grootste latentie). Vanuit het standpunt van het OpenCL werkitem kan delatentie van het globaal geheugen gecompenseerd worden door gebruik te maken vansneller geheugen (lokaal- of privaat geheugen) of door gebruik te maken van de juistegeheugen toegangssequentie. Een aaneengesloten toegangssequentie geeft de kleinstelatentie.

Vooraleer een OpenCL werkitem gebruik kan maken van het globaal geheugen moeteerst de data vanuit het centraal geheugen (host) overgebracht worden naar het globaalgeheugen (device). Hier zijn er verschillende mogelijkheden. Voor een gedetailleerdebeschrijving verwijzen we naar de OpenCL specificaties [8]; we beperken ons hier tot eenbeknopte samenvatting.

19

De OpenCL API voorziet de volgende mogelijkheden:

• Expliciet een buffer kopiëren:

o Gebruik maken van pagineerbaar hostgeheugen: het hostgeheugen kan doorhet besturingssysteem tijdelijk naar het swapbestand gekopieerd worden;

o Gebruik maken van gepind hostgeheugen: het hostgeheugen wordt door hetbesturingssysteem nooit naar het swapbestand gekopieerd en blijft aldusaltijd in het intern geheugen beschikbaar. Bij de allocatie van het host bufferwordt gebruik gemaakt van de CL_MEM_COPY_HOST_PTR vlag;

• Impliciet een buffer mappen:

o Gebruik maken van een hostpointer: bij de allocatie van het hostbufferwordt gebruik gemaakt van de CL_MEM_USE_HOST_PTR vlag.

2.3.3.2 Lokaal geheugen

Het lokaal geheugen is on-chip geheugen en heeft hierdoor een kleinere latentie dan hetglobaal geheugen. De capaciteit van het lokaal geheugen is typisch 16 KB permultiprocessor.

Het lokaal geheugen is opgedeeld in een aantal evenredig verdeelde geheugenmodules,de zogenaamde geheugenbanken. Deze geheugenbanken zijn allemaal tezelfdertijdtoegankelijk: een geheugentoegang tot N verschillende geheugenlocaties waarbij degeheugenlocaties binnen N disjuncte geheugenbanken vallen, heeft de snelheid van ééngeheugentoegang, en hierdoor is de snelheid N maal de snelheid van één enkelvoudigegeheugentoegang.

In het geval dat de toegangssequentie van het globaal geheugen niet aaneengeslotenuitgevoerd kan worden, biedt het lokaal geheugen een alternatief. Hierbij wordt debenodigde data eerst via een aaneengesloten toegangssequentie van het globaal naar hetlokaal geheugen gekopieerd en daarna kan de niet aaneengesloten toegangssequentieuitgevoerd worden op het lokaal geheugen.

20

Hoofdstuk 3

Resultaten en analyse

De omzetting van een sequentieel uitgevoerd algoritme naar een parallel uitvoerbaaralgoritme is geen exacte wetenschap. Ondanks enkele pogingen om deze conversie teautomatiseren [7] blijkt dit niet zo evident. Een goede kennis van de werking van deonderliggende hardware en het daarbij horende softwaremodel is een voorwaarde om toteen voldoend performante systeemimplementatie te komen.

Onderstaande paragrafen beschrijven de werkwijze die gebruikt is bij de conversie vande sequentiële implementatie van het AUDI fast classificatiealgoritme. We beginnen meteen beschrijving van de gebruikte hardware en software. Vervolgens wordt een analysegemaakt van het sequentieel geïmplementeerd classificatiealgoritme. Ten slotte wordt hetparallel geïmplementeerd classificatiealgoritme uitvoerig besproken.

3.1 Gebruikte hardware

De reële snelheid van de classificatie is niet enkel afhankelijk van het gebruiktealgoritme, maar ook sterk afhankelijk van de gebruikte hardware. Om een vergelijking tekunnen maken tussen de verschillende implementaties gebruiken we één referentiehardwareplatform. Hieronder geven we de technische specificatie van het gebruiktehardwareplatform.

21

Tabel 1: Overzicht berekeningmogelijkheden NVIDIA GVE.

Compute Capability 1,0 1,1 1,2 1,3 2,0Threads / Warp 32 32 32 32 32Warps / Multiprocessor 24 24 32 32 48Threads / Multiprocessor 768 768 1024 1024 1536Thread Blocks / Multiprocessor 8 8 8 8 8Shared Memory / Multiprocessor (bytes) 16384 16384 16384 16384 49152Register File Size 8192 8192 16384 16384 32768Register Allocation Unit Size 256 256 512 512 64Allocation Granularity block block block block warpShared Memory Allocation Unit Size 512 512 512 512 128Warp allocation granularity (for registers) 2 2 2 2 2

Alle metingen worden uitgevoerd op een HP Pavilion dv7-3100eb Entertainmentnotebook met volgende specificaties7:

• Intel Core i5 processor i5-430M (2 kernen, 8 draden), kloksnelheid 2,26 GHz• 3 MB level 3 cache• PCI express (x16) met een theoretische snelheid van 4 GB/s• 4 GB DDR3 (2 x 2048 MB) geheugen• NVIDIA GeForce GT 230M, NVIDIA OpenCL driver versie 197.16• Windows 7, 64-bit versie besturingssysteem

De gebruikte GVE is de NVIDIA GeForce GT 230M. Deze GVE heeft de volgendeeigenschappen8:

• Berekeningsmogelijkheden (compute capability, zie ook Tabel 1): 1.2• Aantal multiprocessoren: 6 (met 8 processoren elk, in totaal 48 processoren)• Geheugenstructuur: 128 bit, 800 MHz DDR [ (128/8). 0,8 . 2 ] = 25,6 GB/s,

gemeten 20,3 GB/s• Berekeningen: 158 GFLOPS• Globaal geheugen: 986 MB• Gedeeld (lokaal) geheugen per multiprocessor: 16 KB• Registers per multiprocessor: 16 KB• Aantal draden per warp: 32

Ter informatie geven we in Tabel 1 hierboven een overzicht van deberekeningsmogelijkheden zoals opgegeven in het NVIDIA GVE Computing SDK.

7 De CVE specificatie kan eenvoudig met het programma CPU-Z (http://www.cpuid.com/cpuz.php)bepaald worden.

8 De GVE specificatie kan eenvoudig met het programma ‘GPU Caps Viewer’(http://www.ozone3d.net/gpu_caps_viewer/) bepaald worden.

22

Tabel 2: Overzicht .NET - OpenCL API binding.

Naam Voordelen NadelenHoopoehttp://www.hoopoe-cloud.com

• documentatie • geen broncode• geen

voorbeeldcode

Open TKhttp://www.opentk.com/project/opentk

• broncode• voorbeeldcode• documentatie

• enkel OpenCLAPI

OpenCL .NEThttp://sourceforge.net/projects/openclnet

• beschikbaar• OpenCL API en

objectmodel• voorbeeldcode• documentatie

3.2 Gebruikte software

Het uitgangspunt van deze thesis is het sequentieel geïmplementeerd AUDI fastalgoritme. Het AUDI fast algoritme is ontwikkeld in de object-geörienteerdeprogrammeertaal C-sharp (C#) en maakt gebruik van het Microsoft .NET 2.0 raamwerk.Alhoewel het Microsoft .NET 2.0 raamwerk een aantal beeldmanipulatieprimitievenvoorziet (o.a. System.Drawing), is geopteerd om voor alle beeldmanipulaties gebruik temaken van de Intel® Integrated Performance Primitives (IPP) versie 5.1. De Intel® IPPbibliotheek biedt tal van beeldmanipulatiefuncties welke op een Intel® processor zeer sneluitgevoerd kunnen worden.

Zoals beschreven in paragraaf 2.3 gebruiken we bij het uitvoeren van deze thesis hetOpenCL raamwerk. Het OpenCL raamwerk maakt een abstractie van de gebruiktehardware en bijhorende stuurprogramma’s. Het OpenCL raamwerk beschrijft een APIdewelke door een bepaalde leverancier van een parallel device geïmplementeerd wordt.

Gegeven het sequentieel geïmplementeerd AUDI fast algoritme (ontwikkeld in C#) enhet OpenCL raamwerk zoeken we een softwareoplossing waarbij het OpenCL raamwerkvanuit het Microsoft .NET raamwerk gebruikt kan worden. Een aantal alternatieven zijnvoorhanden: in Tabel 2 wordt een overzicht gegeven van enkele zogenaamde OpenCL -.NET bindings. Uiteindelijk hebben we besloten om gebruik te maken van OpenCL.NET[15] versie 0.4: de opgesomde voordelen zijn hierbij de doorslaggevende factoren.

Ondertussen heeft Microsoft een nieuw .NET raamwerk uitgebracht: .NET versie 3.5.Aangezien dit raamwerk enkele nieuwe krachtige functionaliteiten bevat wordt finaal het.NET raamwerk versie 3.5 gebruikt.

23

Tabel 3: verdeling pixelvlakken in referentiebibliotheek met 129 vingerafdrukken.

Maximaal aantal per Gemiddeld aantal perSoort pixelvlak

Feature Vingerafdruk Feature VingerafdrukTotaalaantal

GAP 9 21 4 16 2073BACKGROUND 6 16 4 13 1694TEXT 8 15 3 13 1619

Aantal vingerafdrukken 129Aantal features 473Aantal pixelvlakken 5386

3.3 AUDI fast op de CVE

3.3.1 Referentiebibliotheek

Zoals beschreven in paragraaf 2.1, maakt AUDI fast gebruik van een bibliotheek met“gekende documenten”. Tijdens de ontwikkeling van het AUDI fast algoritme is ermanueel een bibliotheek met “gekende documenten” aangemaakt. Deze bibliotheek bevat159 verschillende vingerafdrukken. De bibliotheek bevat documenten van verschillendeformaten. Als we ons beperken tot de documenten die voldoen aan het A4 formaat, danbeschikken we over 129 verschillende vingerafdrukken.

De set met 129 verschillende A4 vingerafdrukken wordt in onderstaande analyse alsreferentiebibliotheek gebruikt. Immers, in de praktijk zijn de meeste factuurdocumentenA4 documenten.

De referentiebibliotheek bevat in totaal 473 features, wat resulteert in een gemiddeldevan 3,67 features per vingerafdruk. Het maximaal en gemiddeld aantal pixelvlakken perfeature en vingerafdruk wordt in Tabel 3 weergegeven.

De uiteindelijke doelstelling is de classificatie van een “ongekend document” tenopzichte van een bibliotheek met 5120 “gekende documenten”. Echter, het manueeldefiniëren van 5120 “gekende documenten” (vingerafdrukken) is binnen een beperkte tijdniet mogelijk.

We wensen dus op een geautomatiseerde manier de bibliotheek met 5120vingerafdrukken aan te maken. Hiervoor kan gebruik gemaakt worden van de informatiedie tijdens de verwerking met AUDI (de voorloper van AUDI fast) beschikbaar gesteldwordt. Een eerste analyse heeft uitgewezen dat, aan de hand van de vaste tekst die doorAUDI bepaald is, de potentiële discriminerende features automatisch bepaald kunnenworden.

24

De doelstelling van deze thesis is, in eerste instantie, het versnellen van het AUDI fastalgoritme. Daarom werd het automatisch aanmaken van een bibliotheek met “gekendedocumenten” niet verder uitgewerkt: dit is mogelijks het onderwerp van een vervolgthesis.

Om een bibliotheek met 5120 vingerafdrukken te simuleren werd de bestaandebibliotheek met 129 vingerafdrukken verschillende malen gekopieerd zodat we uiteindelijkeen bibliotheek met 5120 vingerafdrukken bekomen. Bij de interpretatie van de resultatenwordt hiermee rekening gehouden: de classificatiestap zal immers meerdere malenhetzelfde vingerafdrukken te verwerken krijgen.

Naast de 129 “gekende documenten” beschikken we ook over 393 verschillendetestvoorbeelden. Deze “ongekende documenten” worden gebruikt om de resultaten van declassificatie te controleren. Uiteindelijk weten we op voorhand voor elk “ongekenddocument” het juiste classificatieresultaat.

3.3.2 Kwantitatieve analyse (snelheid)

Een kwantitatieve analyse van het AUDI fast algoritme stelt ons in staat om eenreferentiesnelheid te bepalen. Om randeffecten te minimaliseren wordt bij elke tijdsmetingde te meten operatie meerdere malen uitgevoerd. Na het meten van de totaleverwerkingstijd kunnen we de verwerkingstijd van de operatie bepalen door de totale tijdte delen door het uitgevoerde aantal.

Tabel 4 geeft de resultaten van de gemeten tijden. Deze metingen zijn uitgevoerd over393 verschillende “ongekende documenten” en daarna uitgemiddeld. De tijd is telkensuitgedrukt in milliseconden. De voorbereidende stappen zijn per “ongekend document”; declassificatie en validatie is per vingerafdruk. Het gaat hier telkens over de classificatie vanéén “ongekend document” ten opzichte van alle 129 vingerafdrukken.

Voor de classificatiestap kan de individuele tijd (per vingerafdruk) berekend wordendoor de totaaltijd te delen door het aantal vingerafdrukken. Voor de validatiestap is dit nietvan toepassing omdat de validatiestap niet ten opzichte van alle vingerafdrukkenuitgevoerd wordt. De individuele validatietijd is gemeten door de validatie uit te voeren tenopzichte van één vingerafdruk en dat voor alle 393 verschillende testvoorbeelden. Degemiddelde waarde van 0,97 ms is hierbij het resultaat van deze meting.

In de vierde kolom van Tabel 4 worden de berekende tijden weergegeven in het gevaldat er gebruik gemaakt zou worden van 5120 vingerafdrukken. Het aantal vingerafdrukkenheeft geen invloed op de voorbereidende stappen: deze worden immers eenmaal per“ongekend document” uitgevoerd. De classificatietijd kan berekend worden door deindividuele tijd te vermenigvuldigen met het aantal vingerafdrukken: totaal is dit 9.420,80ms.

25

Tabel 4: AUDI fast op CVE, tijd per verwerkingsstap en per vingerafdruk of “ongekende document”.

Verwerkingsstap Tijd (ms)Individueel

Tijd (ms)129

Vingerafdrukken(gemeten)

Tijd (ms)5120

Vingerafdrukken(berekend)

Voorbereiden (niveau 1) 13,51 13,51 13,51Voorbereiden (niveau 2) 70,00 70,00 70,00Classificatie (niveau 1) 1,84 237,36 9.420,80Validatie (niveau 2) 0,97 1,30 -

De validatietijd, in het geval dat er gebruik gemaakt wordt van 5120 vingerafdrukken,kunnen we niet berekenen. De validatietijd is immers afhankelijk van het discriminerendkarakter van elk der individuele vingerafdrukken: immers, het aantal vingerafdrukkenwaarvoor de classificatiescore groter is dan 90 bepaalt het aantal maal dat de validatiestapuitgevoerd zal worden.

Uitgaande van de bibliotheek met 129 vingerafdrukken blijkt dat de validatiestap per“ongekend document” gemiddeld slechts 1,34 maal (1,30 ms gedeeld door 0,97 ms)uitgevoerd wordt.

Naast de tijd per verwerkingsstap is het ook nuttig om de tijd in functie van het aantalvingerafdrukken te bepalen. Het is duidelijk dat enkel de classificatiestap en in veelmindere mate de validatiestap gevoelig is voor het aantal vingerafdrukken. Aangezien devalidatiestap, zoals hierboven beschreven, enkel op een zeer beperkt aantalvingerafdrukken toegepast wordt beperken we hierna de meting tot de classificatiestap.

Grafiek 2 toont de invloed van het aantal vingerafdrukken op de classificatietijd. Wemeten de totale tijd van de classificatie bij toenemend aantal vingerafdrukken. Het aantalvingerafdrukken varieert van 5 tot 125 in stappen van 5. Het is duidelijk te zien dat declassificatietijd lineair toeneemt met het aantal vingerafdrukken (zoals te verwachten); decomplexiteit van de classificatie stap is O(n); hierbij is n het aantal vingerafdrukken. Delineaire correlatie coëfficiënt R² is bij deze meting 0,9992; de individuele classificatietijd is1,86 ms – dit is vergelijkbaar met de meting zoals weergegeven in Tabel 4.

26

Grafiek 2: Classificeren in functie van het aantal vingerafdrukken.

Grafiek 3: AUDI fast classificatie op CVE: invloed van rotatie,de aangegeven hoek is de hoek waarbij de classificatie nog net lukt.

27

3.3.3 Kwalitatieve analyse (accuraatheid)

Naast de snelheid is de accuraatheid van het AUDI fast algoritme een belangrijkekwaliteitsfactor. Het is immers niet zinvol om een algoritme te versnellen waarbij deverkeerde resultaten berekend worden. Daarom werden naast de snelheidsmetingen eenaantal kwalitatieve testen uitgevoerd.

De eerste stap bij de classificatie van een “ongekend document” is het digitaliseren vanhet papieren document. Tijdens deze digitalisatie kunnen zich een aantal anomalieënvoordoen: het papieren document kan met een kleine rotatie door het scantoestelopgenomen worden; de instellingen van het scantoestel kan verschillend zijn in de tijd.Deze anomalieën kunnen we eenvoudige simuleren door, uitgaande van eenreferentiebeeld, een rotatie toe te passen of Gaussiaanse ruis aan het beeld toe te voegen.Verder kan de tekst op het papieren document, tijdens het afdrukken, eveneens een kleineverschuiving hebben. Deze verschuiving wordt buiten beschouwing gelaten omdat derotatie sowieso een locale translatie tot gevolg heeft.

3.3.3.1 De invloed van rotatie

De gebruikte werkwijze is als volgt: overeenkomstig eenzelfde klasse selecteren we 10testbeelden. Deze rotatie wordt telkens toegepast ten opzichte van het hoekpuntlinksboven. De rotatie varieert van 0,5° tot 3° (in stappen van 5°).

De beeldenrij wordt vervolgens aan het AUDI fast classificatiealgoritme aangeboden.De hoek waarbij de classificatie geen beslissing meer neemt, omdat de classificatiescore ofde validatiescore te laag is, wordt genoteerd. Dit resulteert in de grafiek zoals weergegevenin Grafiek 3. Verticaal worden de referentiebeelden uitgezet. Horizontaal wordt derotatiehoek uitgezet. De horizontale staven geven de punten aan waarbij de classificatielukt.

Bekijken we het effect van de rotatie dan kunnen we vaststellen dat het AUDI fastalgoritme, in dit geval (voor deze vingerafdruk), geen classificatie kan uitvoeren in hetgeval de rotatie groter is dan 2,5°. In één geval faalt de classificatie bij een rotatie van 0,5°.

We kunnen deze resultaten, uitgaande van het algoritme, eenvoudig verklaren. Weweten dat het AUDI fast classificatiealgoritme een verschuiving van 0,6 cm (in plus enmin) toestaat. Hierbij gaan we uit van een afstandsmatrix van 96 op 96 punten en een beeldmet een resolutie van 200 dpi. Afhankelijk van de plaats van de features zal een rotatie van0,5° tot 2,5° een verschuiving van meer dan 0,6 cm tot gevolg kunnen hebben, waardoorhet feature buiten de scoop van een afstandsmatrix valt.

28

Figuur 13: Afstandmatrix vingerafdruk [0000006A.jpg] bij verschillende rotaties,van links naar rechts respectievelijk: 0° - 0,5° - 1,0°.

Opvallend is dat het voorbeeld 0000006A.jpg bij een beperkte rotatie van 0,5°onmiddellijk faalt. Figuur 13 geeft een overzicht van de verschillende afstandmatrices bijverschillende rotaties. De oorzaak kan gezocht worden bij het gescande beeld: ten opzichtevan de andere voorbeelden is dit beeld vrij donker, waardoor de gemiddelde intensiteitenvan de pixelvlakken vrij snel afwijken ten opzichte van het “gekende document”. Dit heefttot gevolg dat het gevormde oog klein is en dat de minste rotatie als gevolg heeft dat declassificatie faalt.

Indien een rotatie van meer dan 2,5° vereist is, dan zijn er verschillende mogelijkheden:

• De afstandsmatrix van 96 op 96 punten kan uitgebreid worden tot bijvoorbeeld 128op 128 punten. Hierdoor wordt een grotere ‘translatie’ ondersteund, maar zal declassificatietijd eveneens kwadratisch toenemen – de werkruimte is immers 1,77maal groter (128²/96²);

• De resolutie van het gescande beeld kan verkleind worden naar bijvoorbeeld 150dpi. Hierdoor kan een verschuiving van 0,8 cm (in plus en min) opgevangenworden met behoud van dezelfde 96 op 96 afstandsmatrix;

• De gedefinieerde features worden zo gepositioneerd dat de ‘translatie’ ten gevolgevan rotatie minimaal is. Bij een rotatie van 2° (ten opzichte van het hoekpuntlinksboven) is de maximale verticale positie van een feature 20,5 cm. Immers 0,6cm / tan(2°) is 20,48 cm. Concreet betekent dit: indien de features meer centraalgeplaatst worden en de rotatie rond het middelpunt gebeurt, dat dan het effect vande rotatie kleiner is;

29

Grafiek 4: AUDI fast classificatie op CVE: invloed van ruis, het aangegeven ruisniveau isde ruiswaarde waarbij de classificatie nog net lukt.

3.3.3.2 De invloed van ruis

De gebruikte werkwijze is vergelijkbaar met bovenstaande werkwijze: we selectereneen 10-tal beelden waarvoor de classificatieresultaten gekend zijn. Aan elke beeld wordtnu Gaussiaanse witte ruis toegevoegd.

Het toevoegen van Gaussiaanse ruis gebeurt met behulp van de MATLAB functieimnoise(I,'gaussian',m,v) [1]. Hierbij is I het oorspronkelijk beeld, m het gemiddelde en vde variantie. Als gemiddelde kiezen we 0 (nul), de variantie wordt in stappen van 0,01opgevoerd van 0,01 tot 0,20. De waarde 0,20 stellen we in de grafiek gelijk aan 100%. Ditis het punt waarbij de classificatie voor alle voorbeelden faalt.

De beeldenrij wordt vervolgens aan het AUDI fast classificatiealgoritme aangeboden.Het ruisniveau waarbij de classificatie geen beslissing meer neemt, omdat declassificatiescore of de validatiescore te laag is, wordt genoteerd. Dit resulteert in degrafiek zoals weergegeven in Grafiek 4. Verticaal worden de referentie beelden uitgezet.Horizontaal wordt het ruisniveau procentueel uitgezet. De variantie gaat van 0 (0% of geenruis) tot 0,20 (100% of maximale ruis). De horizontale staaf geeft de punten aan waarbij declassificatie lukt.

30

0000001A.jpg – origineel

0000006A.jpg - origineel

0000001A.jpg - ruisvariantie 0,20 (100%)

0000006A.jpg - ruisvariantie 0,03 (15%)

Figuur 14: AUDI fast op CVE, links beeld zonder ruis, rechts beeld met ruis.

Bekijken we het effect van ruis, dan kunnen we vaststellen dat het AUDI fast algoritmeuitermate bestand is tegen ruis. In Figuur 14 wordt voorbeeld 0000001A.jpg zonder ruis(links) en met 100% (variantie 0,20) ruis (rechts) weergegeven. We kunnen dezeresultaten, uitgaande van het algoritme, eenvoudig verklaren. We weten dat het AUDI fastclassificatiealgoritme gebruik maakt van gemiddelde intensiteiten en hierbij rekeninghoudt met verschillende feature eigenschappen: afstand tussen voorgrondobjecten,regelruimte tussen voorgrondobjecten en inhoud en vorm van de voorgrondobjecten.

Opvallend is terug voorbeeld 0000006A.jpg. Bij een ruisniveau met een variantie van0,03 faalt de classificatie. Figuur 14 geeft een overzicht van het origineel beeld en hetbeeld met een ruisvariantie van 0,03. Zoals hierboven beschreven kan de oorzaak gezochtworden bij het oorspronkelijk beeld: ten opzichte van de andere voorbeelden is dit beeldvrij donker, waardoor de gemiddelde intensiteiten van de pixelvlakken vrij snel afwijkenvan het “gekende document”.

Uitgaande van bovenstaande resultaten kunnen we besluiten dat het AUDI fastalgoritme vrij goed bestand is tegen ruis. Uitgaande van het voorbeeld 0000006A.jpgmerken we wel dat de intensiteit van de documentcanvas een invloed heeft op denauwkeurigheid. Een regelmatige visuele controle tijdens het scannen is aan te raden:indien de scaninstellingen te donkere beelden tot gevolg heeft kan de scanoperator op tijdingrijpen.

31

Tabel 5: Datatransfer van host naar device.

MethodeBandbreedte

(GB/s)

Gebruik hostpointer (CL_MEM_READ_ONLY|CL_MEM_USE_HOST_PTR) 1,394Kopieer hostgeheugen naar devicegeheugen, gebruik pagineerbaar hostgeheugen(CL_MEM_READ_ONLY)

2,194

Kopieer hostgeheugen naar devicegeheugen, gebruik gepind hostgeheugen(CL_MEM_READ_ONLY|CL_MEM_COPY_HOST_PTR)

2,569

3.4 AUDI fast op de GVE

3.4.1 Datatransfer van host naar device

Het classificeren van een document impliceert dat het papieren document eerstgedigitaliseerd moet worden. Het digitaliseren van een papieren document kan opverschillende manieren. Bij de analyse van het AUDI fast algoritme vertrekken we van een24 bpp kleurenbeeld met een resolutie van 200 dpi. Het kleurenbeeld wordt tijdens devoorbereiding omgezet naar een 32-bits per pixel (enkelvoudige precisie vlottende komma)integraalbeeld met dezelfde resolutie. Het integraalbeeld neemt hierdoor ongeveer 15 MBin beslag.

De transfer van 15 MB van de host naar het device kan op verschillende manieren.Zoals beschreven in 2.3.3 biedt de OpenCL runtime meerdere datatransfer mogelijkheden.In Tabel 5 schetsen we kort de verschillende mogelijkheden en de bijhorende gemetenbandbreedte (telkens uitgedrukt in GB per seconde).

Het verloop van de datatransfersnelheid van de host naar het device in functie van dedatagrootte is eveneens een factor die de performantie van het systeem kan beïnvloeden.Daarom meten we de snelheid van de datatransfer voor verschillende datagroottes.

De resultaten van deze metingen worden in Grafiek 5 weergegeven. De blauwe lijngeeft het verloop in het geval dat gebruik gemaakt wordt van pagineerbaar hostgeheugen;de roze lijn geeft het verloop in het geval dat gebruik gemaakt wordt van gepindhostgeheugen.

32

Grafiek 5: Datatransfer van host naar device in functie van de buffergrootte (logaritmisch).

Hierna geven we enkele conclusies:

• Indien gebruik gemaakt wordt van gepind hostgeheugen, dan neemt de transfer van15 MB (NVIDIA GeForce GT 230M) 5,84 ms in beslag. De PCI express bus ishierbij de beperkende factor; de theoretische snelheid van de PCI express (x16) busis 4 Gb/s. Het aldus gerealiseerde rendement is 64,2% (100,0 x 2,569 / 4,0). UitGrafiek 5 volgt dat een maximum datatransfer van 2,6 GB/s bereikt kan worden,wat overeenkomt met een rendement van 65,0%. De gemeten resultaten komenovereen met de aanbevelingen zoals beschreven in de ‘Best Practices Guide’ vanNVIDIA [13] – het gebruik van gepind geheugen wordt aanbevolen;

• De transfer van data van host naar device gebeurt best met behulp van voldoendegrote buffers, dit is duidelijk in Grafiek 5 waar te nemen: hoe groter het gekozenbuffer, hoe groter de effectieve transfersnelheid.

• We concluderen dat we het bronbeeld met één transfer van de host naar het devicekopiëren en dat dit gemiddeld ongeveer 6 ms in beslag zal nemen.

33

3.4.2 De AUDI fast pijplijn

Uitgaande van het AUDI fast algoritme zoals beschreven in paragraaf 2.1 is hetduidelijk dat een belangrijk aantal bewerkingen onafhankelijk van elkaar en bijgevolg inparallel uitgevoerd kan worden. Verder blijkt uit de kwantitatieve analyse, zoalsbeschreven in paragraaf 3.3.2, dat de classificatietijd ten opzichte van een gegevenbibliotheek van 5120 vingerafdrukken het grootste deel van de verwerkingstijd in beslagneemt.

Gegeven bovenstaande vaststellingen gebruiken we de volgende implementatiestrategie:

• We concentreren ons op het parallel berekenen van de classificatiescores – hetberekenen van de classificatiescore van het “ongekende document” ten opzichtevan één “gekend document” (vingerafdruk) kan immers volledig onafhankelijk tenopzicht van alle andere “gekende documenten” (vingerafdrukken) uitgevoerdworden;

• Aangezien de classificatiescore op de GVE berekend wordt en de featurebeschrijving van de “gekende documenten” (vingerafdrukken) constant is, kan debibliotheek met “gekende documenten” eenmalig naar het globaal geheugen van deGVE gekopieerd worden. De tijd om deze opstart uit te voeren kan eigenlijkverdeeld worden over alle te classificeren documenten en is bijgevolg (zoals laterzal blijken) verwaarloosbaar;

• Volgende verwerkingsstappen kunnen aldus in een gepijplijnde structuuruitgevoerd worden:

a. Voorbereiding (niveau 1): op de CVE wordt het beeld van het teclassificeren “ongekende document” geconverteerd naar een 200 dpi 32-bitsper pixel integraalbeeld op basis waarvan de gemiddeldeintensiteitsberekeningen snel uitgevoerd kunnen worden;

b. Transfer beeld “ongekende document” van de host naar het device:volgens de conclusies van paragraaf 3.4.1 realiseren we de grootstegeheugentransfersnelheid in het geval de data in één kopieeroperatieuitgevoerd wordt. De snelheid is bepaald door de snelheid van de PCIexpress bus. Op ons referentie hardwareplatform is dit ongeveer 2,5 GB/s ofvoor een integraalbeeld van 15 MB overeenkomstig een A4 document eengemiddelde transfertijd van 5,84 ms;

c. Parallelle classificatie (niveau 1): per vingerafdruk wordt een kernelbinnen één NDRange opgestart. Uiteindelijk worden er in totaal 5120kernels gelanceerd (dit is het totaal aantal vingerafdrukken in de bibliotheekmet “gekende documenten”). Het resultaat van deze berekening is een lijstvan classificatiescores met naast de classificatiescore de (X,Y) verschuiving

34

van het “ongekende document” ten opzichte van het “gekende document”(vingerafdruk). De implementatie van de classificatiekernel wordt inparagraaf 3.5 in detail beschreven.

d. Voorbereiding (niveau 2): op de CVE wordt het beeld van het teclassificeren “ongekende document” geconverteerd naar eenlaagresolutiebeeld van 100 dpi;

e. Sequentiële validatie (niveau 2): aangezien de validatie van declassificatie (niveau 1) slechts voor enkele vingerafdrukken nodig is, wordtdeze validatie op de CVE uitgevoerd. Nemen we maximaal 5validatieberekeningen dan is de totale verwerkingstijd 4,85 ms, hetzij 5maal 0,97 ms. De transfer van het lageresolutiebeeld van 100 dpi, hetzij 15MB gedeeld door 4 of 3,75 MB, neemt volgens de metingen zoalsweergegeven in Grafiek 5 in totaal ongeveer 1,6 ms in beslag. Gegeven datde parallelle implementatie van de validatiestap slechts 3,25 ms (4,85 – 1,6)in beslag zou mogen nemen, lijkt ons dit een juiste keuze.

De verschillende pijplijnstappen worden in Figuur 15 weergegeven. De classificatiestapis hierbij duidelijk niet op schaal weergegeven: deze stap (c) blijkt bij de eersteimplementatie ongeveer 100 maal langer te duren dan bijvoorbeeld stap (a).

De stappen (a), (d) en (e) worden uitgevoerd op de CVE. De stap (c) wordt uitgevoerdop de GVE. Stap (b), de transfer van het integraalbeeld van de CVE naar de GVE, kan passtarten nadat stap (c) van de vorige verwerkingssequentie voltooid is.

De tijden per verwerkingsstap worden weergegeven in Tabel 6. Uiteindelijk bepaalt stap(c) de doorloopsnelheid van de pijplijn. In het vervolg van de tekst concentreren we onsdan ook op de optimalisatie van stap (c). In paragraaf 3.5 beschrijven we achtereenvolgensde verschillende implementaties van stap (c). Voordat we overgaan naar de optimalisatievan stap (c) introduceren we eerst het concept ‘AUDI fast sessie’.

Figuur 15: AUDI fast op GVE, schematische voorstelling gepijplijnde structuur.

35

Tabel 6: AUDI fast op GVE, verwerkingstijden voor elke pijplijnstap – merk op dat de sequentiëlevalidatietijd in onderhevig testscenario – bibliotheek met 5120 vingerafdrukken - een benadering is.

Verwerkingsstap Tijd(ms)

a. Voorbereiding (niveau 1) 13,51b. Transfer beeld “ongekende document”van de host naar het device 5,84c. Parallelle classificatie (niveau 1): verschillende implementaties, zie paragraaf 3.5 -d. Voorbereiding (niveau 2) 70,00e. Sequentiële validatie (niveau 2), zie paragraaf 3.3.2 1,30

3.4.3 Een AUDI fast sessie

Vooraleer de AUDI fast pijplijn opgestart kan worden, zijn er een aantal voorbereidendestappen nodig. Deze voorbereidende stappen bevatten ondermeer de allocatie van buffers,het laden van de bibliotheek met “gekende documenten” en het opzetten van de pijplijn.Nadat het laatste “ongekende document” door de AUDI fast pijplijn verwerkt is en finaalde verwerking gestopt wordt, kunnen alle gebruikte resources vrijgegeven worden.

Het opstarten, uitvoeren en afbreken van de AUDI fast pijplijn noemen we een AUDIfast sessie. Om een voldoend grote verwerkingscapaciteit te realiseren is het belangrijk dathet aantal “ongekende documenten” dat binnen één sessie verwerkt wordt voldoende grootis. In het limietgeval waarbij slechts één “ongekend document” per sessie verwerkt wordt,is de overhead van de opstart en het afbreken van de AUDI fast pijplijn niet teverwaarlozen.

Bij de implementatie van AUDI fast op de GVE nemen we als uitgangspunt dat de tijdom de AUDI fast pijplijn op te starten en af te breken in eerste instantie niet tijdskritisch is.Deze stappen zijn dan ook bij deze eerste implementatie niet geoptimaliseerd.

Hierna beschrijven we achtereenvolgens het opstarten en het afbreken van de AUDI fastpijplijn.

3.4.3.1 Opstarten AUDI fast pijplijn

Aangezien de tijd voor de allocatie van een buffer op de GVE en de tijd voor de transfervan data van de host naar het device niet te verwaarlozen zijn, worden deze operaties (in demate van het mogelijke) zo weinig mogelijk uitgevoerd.

Bij het classificeren is de bibliotheek met “gekende documenten” constant en kan dezebibliotheek, eens beschikbaar op de GVE, bij elke classificatie telkens opnieuwongewijzigd gebruikt worden. Naast de bibliotheek met “gekende documenten” kunnenook de buffers die gebruikt worden om de tijdelijke resultaten van de classificatie pervingerafdruk op te slaan bij elke classificatie opnieuw gebruikt worden.

We concluderen dat, bij het opstarten van de AUDI fast sessie, volgende stappenuitgevoerd kunnen worden:

36

• De bibliotheek met “gekende documenten” kopiëren van de host naar hetdevice: per vingerafdruk wordt één vector met pixelvlakken en één vector metfeatures gealloceerd. De vector met pixelvlakken bevat achtereenvolgens alle GAP,alle BACKGROUND en alle TEXT pixelvlakken. De vector met features bevat perfeature en per soort pixelvlak de index van het eerste pixelvlak en het aantalpixelvlakken. De structuur van de bibliotheek met “gekende documenten” wordt inFiguur 16 schematisch voorgesteld: het gaat hier over de structuur overeenkomstigéén vinderafdruk: totaal zijn er F features en P pixelvlakken. Het alloceren enkopiëren van alle benodigde gegevens van 5120 vingerafdrukken neemt in totaalongeveer 1,5 seconden in beslag. In de veronderstelling dat er binnen één AUDIfast sessie vanuit praktisch oogpunt typisch meer dan 1000 “ongekendedocumenten” verwerkt worden, dan is deze opstarttijd van 1,5 ms per “ongekenddocument” inderdaad te verwaarlozen;

• Allocatie en initialisatie GVE buffers: De classificatieresultaten per vingerafdrukbestaan uit: een classificatiescore (komma getal, enkelvoudige precisie, in hetinterval [0, 100]); een (X,Y) verschuiving in pixels van het “ongekende document”ten opzichte van het “gekende document”. De (X,Y) verschuiving kan een waardeaannemen in het interval [-48,48]. Deze resultaten worden gebundeld in eenstructuur (in de c-syntax is dit een struct). Voor elke vingerafdruk wordt éénstructuur gealloceerd; dit resulteert in een buffer van 40 KB (8 bytes per structuur,5120 vingerafdrukken).

3.4.3.2 Afbreken AUDI fast pijplijn

Het afbreken van de AUDI fast pijplijn bestaat uit: het vrijgeven van de gebruiktebuffers, het vrijgeven van de bibliotheek met “gekende documenten” en het opkuisen vanalle GVE gerelateerde resources.

Figuur 16: structuur van de AUDI fast bibliotheek met “gekende documenten”.

37

3.5 Parallelle classificatie op de GPU

In onderstaande paragrafen bespreken we de verschillende geparallelliseerdeimplementaties van de classificatie. Het gaat hier telkens over de implementatie van stap(c) van de AUDI fast pijplijn zoals hierboven beschreven in paragraaf 3.4.2.

Naast de tijd voor de classificatie van een “ongekende document” is ook de juistheidvan de geparallelliseerde implementatie van de classificatie van belang. Zoals beschrevenin paragraaf 3.3 vertrekken we van een accurate sequentiële implementatie van hetclassificatiealgoritme. We gebruiken de resultaten van deze implementatie als referentie bijde ontwikkeling en validatie van de geparallelliseerde implementatie van hetclassificatiealgoritme. De gebruikte validatiewerkwijze wordt in paragraaf 3.5.1beschreven. Deze werkwijze wordt na elke aanpassing van de geparallelliseerdeimplementatie toegepast; op deze manier zijn we zeker dat er geen fouten geïntroduceerdworden.

Elke geparallelliseerde implementatie van het classificatiealgoritme geven we eenunieke identificatie van de vorm [IMPLx]: hierbij is x een oplopend nummer dat de versieaangeeft. Zo is [IMPL1] de eerste parallelle implementatie van het classificatiealgoritme.

3.5.1 Validatie van de parallelle implementatie van de classificatie

De gebruikte OpenCL implementatie, dewelke beschikbaar gesteld is binnen deNVIDIA SDK versie 3.0, biedt momenteel niet de mogelijkheid om de OpenCL coderechtstreeks op instructie niveau te debuggen. Ook is er voor het NVIDIA GVE platformgeen mogelijkheid om de OpenCL code op een CVE uit te voeren. Dit wil zeggen dat hetopsporen van eventuele fouten potentieel een vrij tijdrovende bezigheid kan zijn.

Daarom hebben we beslist om, vanaf de eerste implementatie, een geautomatiseerdvalidatieraamwerk te ontwikkelen. In dit validatieraamwerk wordt systematisch hetresultaat van de sequentiële classificatie (op de CVE) vergeleken met het resultaat van deparallelle classificatie (op de GVE).

De ontwikkeling van het parallelle classificatiealgoritme is stapsgewijs opgebouwd:vertrekkende van de berekening van één afstandsmatrix van een GAP pixelvlak tot en methet volledig uitrekenen van een afstandsmatrix van een vingerafdruk. Bij elke stap wordtde sequentieel berekende afstandsmatrix vergeleken met de corresponderende parallelberekende afstandsmatrix. Het verschil tussen beide afstandsmatrices moet resulteren ineen afstandsmatrices met in elk punt de waarde nul. Met andere woorden het verschil vanbeide afstandsmatrices moet resulteren in een ‘witte afstandsmatrix’.

38

Figuur 17: AUDI fast op GVE, validatie afstandsmatrices, linker helft: de afstandsmatrices van éénTEXT pixelvlak, rechter helft: de afstandsmatrices van één feature.

Figuur 17 toont enkele validatieresultaten. Per helft van de figuur worden links desequentiële berekende afstandsmatrices weergegeven; centraal de parallel berekendeafstandsmatrices; rechts het verschil tussen beide. Elke rij komt overeen met één“ongekend document”. Het gaat hier dus telkens over vier verschillende “ongekendedocumenten”.

3.5.2 Tijdsmeting van de parallelle implementatie van de classificatie

Volgens de aanbevelingen van NVIDIA, zoals beschreven in de NVIDIA OpenCL BestPractices Guide [13], kan de tijdsmeting van een OpenCL oproep op twee manierengemeten worden: met behulp van de CVE timers of met behulp van de GVE timers. Beidebieden dezelfde functionaliteit: omdat we met de CVE timers vertrouwd zijn, opteren weom de CVE timers te gebruiken.

Bij het meten van de tijd van een OpenCL oproep is het belangrijk om rekening tehouden met de aard van de OpenCL functie: bepaalde OpenCL functies zijn asynchroon,waardoor aldus de oproeper niet geblokkeerd wordt totdat de volledige operatie uitgevoerdis. Om een juiste tijdsmeting te bekomen moet expliciet de CVE draad gesynchroniseerdworden met de GVE. De OpenCL functie clFinish blokkeert de CVE draad totdat allevoorgaande oproepen op de GVE uitgevoerd zijn.

39

Tabel 7: Initialisatie OpenCL raamwerk.

Lancering lege kernel over 3DRangevan 512x1x1

OpenCL.Nettijd (ms)

OpenCLtijd (ms)

Eerste oproep 0,921 0,509Tweede oproep 0,208 0,201

Een ander belangrijk element bij tijdsmetingen is de nauwkeurigheid van de gebruiktetimer. We maken gebruik van de hoogresolutie performance counter functieQueryPerformanceCounter. De resolutie van deze timer is hardwareafhankelijk en wordtuitgedrukt in aantal tellingen per seconde – voor het gebruikte hardwareplatform is deresolutie 2208037 tellingen per seconde of 0,45 µs. Daar de meeste metingen in de grootteorde van milliseconden zijn, kunnen we besluiten dat dit ruim voldoende is..

Volgens Daniel Lélis Baggio [2] neemt de initialisatie van het CUDA raamwerk181,980 ms in beslag: dit is in het geval van CUDA duidelijk niet te verwaarlozen. In hetgeval van OpenCL blijkt dit een stuk minder te zijn. Echter, om dit randeffect tijdens onzemetingen correct in rekening te brengen meten we de initialisatietijd van het OpenCLraamwerk. In deze test kunnen we ook de vertraging ten gevolge van het gebruik van deOpenCL.NET binding meten. De resultaten worden in Tabel 7 weergegeven: hierbij wordteen lege kernel (kernel zonder enige instructie) gelanceerd over een 3DRange van 512x1x1punten.

Zowel voor de OpenCL.Net als de OpenCL implementatie meten we een verschil tussende eerste en de tweede functieoproep. De initialisatietijd van het OpenCL raamwerk isechter veel kleiner dan het CUDA raamwerk: respectievelijk 0,921 ms ten opzichte van181,980 ms. De eerste oproep middels de OpenCL.Net implementatie duurt langer dan metde OpenCL implementatie: het verschil van 0,412 ms is enkel van toepassing bij de eersteoproep. De tweede oproep is voor beide implementaties quasi gelijk. We besluiten dat deeerste OpenCL oproep niet gebruikt mag worden bij de tijdmetingen. Bij de bepaling vande gemiddelde tijd wordt telkens de eerste meting buiten beschouwing gelaten.

40

3.5.3 Eerste implementatie van de parallelle classificatie [IMPL1]

Bij deze eerste implementatie concentreren we ons in eerste instantie op de juistheid vande berekening en pas in tweede instantie op de snelheid. De classificatie van het“ongekende document” ten opzichte van één vingerafdruk wordt uitgevoerd door éénkernellancering. Uiteindelijk worden er dus 5120 kernels (het totaal aantal vingerafdrukkenin de bibliotheek) gelanceerd.

Elke kernel gebruikt de volgende parameters:

• Verwijzing naar het integraalbeeld van het “ongekende document”; het beeld vanhet “ongekende document” is in de vorige stap (b) naar het globaal geheugen vande GVE gekopieerd; alle kernellanceringen gebruiken dezelfde verwijzing;

• Verwijzing naar de geheugenruimte waar de resultaten van de berekening, i.e. deafstandsmatrices per vingerafdruk, opgeslagen worden; dit is per gelanceerdekernel uniek, totaal zijn er 5120 geheugenlocaties;

• Verwijzing naar de beschrijving van de vingerafdruk; de beschrijvingen van devingerafdrukken zijn tijdens het starten van de AUDI fast sessie naar het globaalgeheugen van de GVE gekopieerd.

De kernel wordt gelanceerd over een 2DRange van 96 op 96 punten: dit komt overeenmet de dimensies van één afstandsmatrix. Elke kernelnstantie is aldus verantwoordelijkvoor de berekening van één punt in de resulterende afstandsmatrix.

De code van de gebruikte kernel wordt in Figuur 18 weergegeven. De interne werkingvan de kernel is als volgt:

• Elke kernel bepaalt zijn positie in de 2DRange, dit zijn twee nummer in het interval[0, 95]; deze nummers worden gebruikt om onder andere het punt binnen deresultaatmatrix te bepalen;

• Alle features van de vingerafdruk worden overlopen en per feature worden depixelvlakken berekend;

• Uiteindelijk worden alle features gecombineerd en bekomen we de matrix voor deopgegeven vingerafdruk.

41

#define __source_attribute __global#define __inventory_attribute __global

kernel void CalcFingerprintMatrix(

__source_attribute const float* pSource, int nSourceStride, __global float* pResult, int nResultStride, __inventory_attribute const Spot* pAllSpots, __inventory_attribute const Feature* pAllFeatures, int nFeatureSize){// 2DRange: 96 x 96 pixels ==> one distance matrix in center of spotssize_t glid_x = (ushort)get_global_id(0);size_t glid_y = (ushort)get_global_id(1);

// Calculate resultfloat fingerprintCombinedResult = 1.0;for (int f=0; f<nFeatureSize; f++){__inventory_attribute const Feature* pFeature = &pAllFeatures[f];

// compute gap and update combined valuefloat gapResult = 0.0;for (int g=0; g<pFeature->gapCount; g++){AddGapMatrix(pSource, nSourceStride, &pAllSpots[g+pFeature->gapIndex]

, glid_x, glid_y, &gapResult);}

// compute background and update combined valuefloat bckgrnResult = 0.0;for (int b=0; b<pFeature->backCount; b++){AddBckgrnMatrix(pSource, nSourceStride, &pAllSpots[b+pFeature->backIndex]

, glid_x, glid_y, &bckgrnResult);}

// compute text and update combined valuefloat textResult = 0.0;for (int t=0; t<pFeature->textCount; t++){AddTextMatrix(pSource, nSourceStride, &pAllSpots[t+pFeature->textIndex]

, glid_x, glid_y, &textResult);}

// final feature resultfingerprintCombinedResult *= gapResult*bckgrnResult*textResult;

}

// Result pixel__global float* pResultPix = (__global uchar*)pResult

+ glid_y*nResultStride+ glid_x*sizeof(float);

*pResultPix = fingerprintCombinedResult;}

Figuur 18: AUDI fast op GVE, kernelcode [IMPL1].

42

Tabel 8: AUDI fast op GVE, tijd 5120 vingerafdrukken, implementatie [IMPL1].

Verwerkingsstap en versie implementatie Tijd(ms)

Parallelle classificatie – 5120 vingerafdrukken [IMPL1] 1.328,89

De classificatietijd van implementatie [IMPL1] worden weergegeven in Tabel 8. Wezien dat de classificatie in totaal 1,33 seconden in beslag neemt. Dezelfde stap neemt op deCVE 9,42 seconden in beslag: de implementatie heeft dus een versnelling van 7,1.Gegeven dat de gebruikte GVE (slechts) 6 multiprocessoren bevat en een professioneleGVE tot 60 multiprocessoren bevat, hebben we een theoretische versnellingspotentieel van71 op een professionele GVE van de huidige generatie. Gegeven de doelstelling om 7pagina’s per seconde te classificeren, wat overeenstemt met 142,86 ms per pagina, lijkt ditop een professionele GVE haalbaar.

3.5.4 Tweede implementatie van de parallelle classificatie [IMPL2]

In het geval dat voor een bepaalde verschuiving (dit is een punt in de afstandsmatrix)voor één type pixelvlak de waarde nul is, dan is de rest van de berekeningen overbodig indit punt. De finale waarde zal uiteindelijk nul zijn.

Bekijken we de afstandsmatrix van een TEXT pixelvlak dan merken we dat deze matrixtypisch de meeste nulwaarden (of zwarte pixels) bevat.

Bovenstaande vaststellingen kunnen we gebruiken om implementatie [IMPL1] alvastals volgt aan te passen:

• Eerst wordt de afstandsmatrix van de TEXT pixelvlakken, vervolgens deafstandsmatrix van de GAP pixelvlakken en ten slotte de afstandsmatrix van deBACKGROUND pixelvlakken berekend;

• Indien de waarde van een pixelvlak nul is, dan kan de rest van de berekeningen (dusvoor volgende features en/of pixelvlakken) gestopt worden, de finale waarde is nul.Figuur 19 toont de aanpassing voor de TEXT pixelvlakken.

// compute text and update combined valuefloat textResult = 0.0;for (int t=0; t<pFeature->textCount; t++){

AddTextMatrix(pSource, nSourceStride, &pAllSpots[t+pFeature->textIndex], glid_x, glid_y, &textResult);

}if (textResult==0.0){

featureCombinedResult = 0.0;break;

}Figuur 19: AUDI fast op GVE, kernelcode voor [IMPL2].

43

Tabel 9: AUDI fast op GVE, tijd 5120 vingerafdrukken, implementatie [IMPL2].

Verwerkingsstap en versie implementatie Tijd(ms)

Individueleversnelling

Parallelle classificatie – 5120 vingerafdrukken [IMPL1] 1.328,89 -Parallelle classificatie – 5120 vingerafdrukken [IMPL2]Optimalisatie volgorde berekening pixelvlakken en optimalisatieindien één waarde nul is

1.295,05 33,83 ms1,03x

De resultaten van implementatie [IMPL2] worden weergegeven in Tabel 9.Bovenstaande aanpassingen resulteren in een beperkte versnelling van 3%. In absolutewaarde is dit 33,83 ms. Op een totale te classificeren populatie van 200.000 pagina’s is diteen tijdswinst van ongeveer 1,9 uur.

3.5.5 Derde implementatie van de parallelle classificatie [IMPL3]

We gaan op zoek naar een optimalisatie van het geheugengebruik. Gegeven dat debeschrijving van de vingerafdrukken constant is en beperkt in grootte (ongeveer 3 MBvoor 5012 vingerafdrukken), kunnen we deze beschrijving zoveel mogelijk als constantaangeven. Op deze manier wordt de constant geheugencache maximaal gebruikt.

De aanpassing van de implementatie resulteert in het veranderen van het OpenCLgeheugen attribuut van __global (globaal geheugen) naar __constant (constant geheugen).De resultaten van implementatie [IMPL3] worden weergegeven in Tabel 10.

De uitvoeringstijd is met 600,81 ms afgenomen. Dit komt overeen met een versnellingvan 1,87 ten opzichte van [IMPL2]. Het is duidelijk dat het gebruik van de constantgeheugen cache een grote snelheidwinst geeft. Inderdaad, de bibliotheek met “gekendedocumenten” zoals beschreven in paragraaf 3.4.3.1 zorgt ervoor dat de constantebeschrijving van de vingerafdruk sequentieel in het device (GVE) geheugen geplaatstwordt. Hierdoor is de kans op een cache hit maximaal.

Tabel 10: AUDI fast op GVE, tijd 5120 vingerafdrukken, implementatie [IMPL3].

Verwerkingsstap en versie implementatie Tijd(ms)

Individueleversnelling

Cumulatieveversnelling

Parallelle classificatie – 5120 vingerafdrukken[IMPL1]

1.328,89 - -

Parallelle classificatie – 5120 vingerafdrukken[IMPL2]Optimalisatie volgorde berekening pixelvlakken enoptimalisatie indien één waarde nul is

1.295,05 33,83 ms1,03x

33,83 ms1,03x

Parallelle classificatie – 5120 vingerafdrukken[IMPL3]Gebruik constant geheugen voor beschrijvingvingerafdrukken.

694,24 600,81 ms1,86x

634,65 ms1,92

44

Figuur 20: AUDI fast op GVE, structuur bibliotheek met “gekende documenten”.

3.5.6 Vierde implementatie van de parallelle classificatie [IMPL4]

De derde implementatie [IMPL3] van de parallelle classificatie maakt gebruik van een2DRange van 96 op 96 punten. Per vingerafdruk wordt er één kernel gelanceerd: in totaalworden er dus 5120 kernels gelanceerd, dit overeenkomstig het aantal vingerafdrukken inde bibliotheek. Volgens Daniel Lélis Baggio [2] neemt de oproep van één kernel metbehulp van het CUDA raamwerk ongeveer 40 µs in beslag. Volgens onze metingen inparagraaf 3.5.2 duurt de oproep van een lege kernel in het OpenCL raamwerk 208 µs, eenfactor 5,2 langer.

Hoe kunnen we het aantal kernellanceringen nu beperken? We kunnen gebruik makenvan de 3-de dimensie in de NDRange: de derde implementatie [IMPL3] van de parallelleclassificatie wordt aangepast zodat één kernel meerdere vingerafdrukken kan berekenen.

Bovenstaande aanpassing heeft tot gevolg dat we de structuur van de bibliotheek met“gekende documenten” moeten aanpassen: meerdere vingerafdrukken worden gebundeldtot één blok met N vingerafdrukken. De parameter N is instelbaar en varieert van 1 tot 64.Hierbij is, voor het gebruikte hardwareplatform, 64 het maximaal aantal draden dat we inde 3-de dimensie van de NDRange kunnen lanceren. In het geval dat het aantal teonderscheiden vingerafdrukken een veelvoud is van 64 dan is de kernel implementatieeenvoudige en is het uitvoeringsrendement maximaal: elk gelanceerd werkitem zaleffectief een vinderafdruk berekenen.

De bibliotheek met “gekende documenten” zoals beschreven in paragraaf 3.4.3.1 wordtnu als volgt gestructureerd:

• Per blok met vingerafdrukken worden er op de GPU drie vectoren gealloceerd: éénvector met vingerafdrukken, één vector met features en een vector metpixelvlakken;

• De vector met vingerafdrukken bevat per vingerafdruk de index van het eerstefeature en het aantal features;

• De vector met features bevat per feature en per soort pixelvlak de index van heteerste pixelvlak en het aantal pixelvlakken;

45

• De vector met pixelvlakken bevat achtereenvolgens alle GAP, alleBACKGROUND en alle TEXT pixelvlakken.

Deze structuur is vergelijkbaar met de structuur zoals beschreven in paragraaf 3.4.3.1,met uitzondering van de extra dimensie overeenkomstig de vingerafdrukken. In Figuur 20wordt de gewijzigde structuur van de bibliotheek met “gekende documenten”weergegeven. De vector met vingerafdrukken bevat N elementen, waarbij er per elementeen verwijzing is naar de vector met features. De vector met features bevat F elementen,waarbij er per element drie verwijzingen zijn naar de vector met pixelvlakken. De vectormet pixelvlakken bevat P elementen; deze elementen zijn achtereenvolgens alle GAP, alleBACKGROUND en alle TEXT pixelvlakken.

De aangepaste structuur heeft als bijkomend voordeel dat de transfer van de bibliotheekmet “gekende documenten” van de host naar het device minder tijd in beslag neemt. Deindividuele datablokken zijn immers groter waardoor de bandbreedte per datablokeveneens groter is (zie paragraaf 3.4.1). Grafiek 6 geeft het verloop van de transfertijd infunctie van de blokgrootte: bij een blokgrootte van 64 is de transfertijd slechts 75,20 ms.Ter vergelijking: indien er geen blokken gebruik worden is de transfertijd 1480,77 ms (eenfactor 19 maal trager).

De vierde implementatie [IMPL4] maakt gebruik van een 3DRange van 96 op 96 op Npunten. Voor elke blok met vingerafdrukken wordt er één kernel gelanceerd: in totaalworden er aldus 5120 / N kernels gelanceerd. We kunnen ons nu de vraag stellen: wat is deoptimale waarde van N (de blokgrootte)?

Om bovenstaande vraag te beantwoorden meten we de classificatietijd in functie van deblokgrootte. We variëren de blokgrootte van 1 tot 64. De blokgrootte is telkens eenveelvoud van twee: deze voorwaarde vereenvoudigt de implementatie van declassificatiekernel. De resultaten worden in Grafiek 7 weergegeven. Het is duidelijk dateen grotere blokgrootte een kortere classificatietijd tot gevolg heeft. Het is opvallend dat detijdswinst bij het verdubbelen van de blokgrootte kleiner wordt naarmate de blokgroottegroter is. We kiezen ervoor om uiteindelijk een blokgrootte van 64 te gebruiken.

Zoals beschreven in paragraaf 2.3.2 worden verschillende werkitems gegroepeerd totéén werkgroep. Het aantal werkgroepen binnen een NDRange kan automatisch door deOpenCL implementatie of manueel door de oproeper bepaald worden. Gegeven degekozen 3DRange van 96 op 96 op 64 punten weten we nu hoeveel werkitems gecreëerdworden (96x96x64), maar kennen we nog niet de optimale grootte van de werkgroepen. Deautomatisch door het OpenCL raamwerk gebaalde werkgroepgrootte is bij aanvang 96x1x1werkitems per werkgroep.

46

Transfertijd bibliotheek met "gekende documenten"

0,00

200,00

400,00

600,00

800,00

1000,00

1200,00

1400,00

1600,00

1 4 8 16 32 64

Blokgrootte

Tijd

(ms)

Grafiek 6: Datatransfer bibliotheek met “gekende documenten” vanhost naar device in functie van de vingerafdruk blokgrootte.

Parallelle classificatietijd [IMPL4]

500,00520,00540,00560,00580,00600,00620,00640,00660,00680,00700,00

1 4 8 16 32 64

Blokgrootte

Tijd

(ms)

Grafiek 7: Classificatietijd [IMPL4] in functie van de vingerafdruk blokgrootte – bij bovenstaandemeting bestaat elke werkgroep uit 96x1x1 werkitems.

47

Grafiek 8: Classificatietijd [IMPL4] in functie van de werkgroepdimensie,dit is het aantal werkitems in elke dimensie van de 3DRange.

Figuur 21: Gebruikte 3DRange met 96x96x64 werkitems [IMPL4].De 3DRange is verdeeld in werkgroepen van 32x1x4 werkitems.

48

Tabel 11: AUDI fast op GVE, tijd 5120 vingerafdrukken, implementatie [IMPL4].

Verwerkingsstap en versie implementatie Tijd(ms)

Individueleversnelling

Cumulatieveversnelling

Parallelle classificatie – 5120 vingerafdrukken[IMPL1]

1.328,89 - -

Parallelle classificatie – 5120 vingerafdrukken[IMPL2]Optimalisatie volgorde berekening pixelvlakkenen optimalisatie indien één waarde nul is

1.295,05 33,83 ms1,03x

33,83 ms1,03x

Parallelle classificatie – 5120 vingerafdrukken[IMPL3]Gebruik constant geheugen voor beschrijvingvingerafdrukken.

694,24 600,81 ms1,86x

634,65 ms1,92x

Parallelle classificatie – 5120 vingerafdrukken[IMPL4]Gebruik blokgrootte 64 en werkgroepen van32x1x4 werkitems

444,93 249,31ms1,56x

883,96 ms2,99x

Één werkgroep wordt op één multiprocessor uitgevoerd. Het aantal werkitems binnenéén werkgroep is begrensd door de geheugenbeperkingen van de multiprocessor: degrootte van het on-chip gedeeld geheugen en het aantal 32 bit registers. Verder moet hetaantal werkitems binnen een werkgroep voor alle werkgroepen constant zijn: het totaalaantal werkitems in elke dimensie van de 3DRange is een veelvoud van het aantalwerkitems in elke werkgroep.

De uiteindelijke doelstelling is om de GVE zo veel mogelijk ‘bezig te houden’, meerspecifiek streven we naar een optimale bezettingsgraad (occupancy) [13]. Rekeninghoudend met bovenstaande randvoorwaarden wordt voor alle mogelijkewerkgroepdimensies de classificatietijd gemeten. We variëren telkens één dimensie van dewerkgroep en meten de gemiddelde classificatietijd over alle 393 testsamples.

Het resultaat wordt weergegeven in Grafiek 8. De meetpunten zijn gesorteerd volgensafnemende (X,Y,Z) waarden. Uit Grafiek 8 volgt dat, tot op zekere hoogte, een groteraantal werkitems per werkgroep een positieve invloed heeft of de classificatietijd. Deoptimale werkgroepdimensie is uiteindelijk: 32 op 1 op 4 werkitems per werkgroep. Degebruikte 3DRange wordt in Figuur 21 weergegeven.

We kunnen dit resultaat eenvoudig verklaren. Uitgaande van het OpenCLuitvoeringsmodel, zoals beschreven in paragraaf 2.3.2, weten we dat de werkitems binnenéén werkgroep in blokken (warps) van 32 draden op een multiprocessor uitgevoerdworden: dit komt exact overeen met het aantal werkitems binnen één enkele dimensie vanéén werkgroep. Op het moment dat er door alle 32 werkitems een geheugenleesinstructieuitgevoerd wordt, zijn alle geheugenlocatie aaneensluitend en is bijgevolg hetbandbreedtegebruik van het globaal geheugen maximaal.

49

De resultaten van implementatie [IMPL4] worden weergegeven in Tabel 11. Deuitvoeringstijd is met 249,32 ms afgenomen: dit komt overeen met een versnelling van1,56 ten opzichte van [IMPL3].

3.5.7 Vijfde implementatie van de parallelle classificatie [IMPL5]

Zoals beschreven in paragraaf 2.1.3 resulteert de classificatiestap in het filteren ensorteren van de lijst met “gekende documenten”. Het filteren en sorteren is gebaseerd op deberekende classificatiescore. De tot nu toe beschreven implementaties [IMPL1] tot[IMPL4] berekenen één uiteindelijke afstandsmatrix per vingerafdruk. De ontbrekendestap, het berekenen van de classificatiescore, wordt in deze vijfde en laatste implementatietoegevoegd.

De per vingerafdruk te berekenen classificatiescore is gebaseerd op de maximalewaarde binnen de uiteindelijke afstandsmatrix. Het punt binnen de uiteindelijkeafstandsmatrix waarvan de waarde maximaal is bepaalt enerzijds de classificatiescore enanderzijds de (X,Y) verschuiving van het “ongekende document” ten opzichte van een“gekende document” (de vingerafdruk). De (X,Y) verschuiving wordt in eerste instantiebuiten beschouwing gelaten; de (X,Y) verschuiving kunnen we immers op een eenvoudigemanier op de CVE berekenen.

Het bepalen van de maximale waarde in een afstandsmatrix vertaalt zich in eenzogenaamde parallelle reductie. In de literatuur vinden we verschillende oplossingen:onder andere in de presentatie van Mark Harris [10] wordt bijvoorbeeld de CUDA-gebaseerde parallelle reductie uitvoerig uitgelegd.

De parallelle reductie van één uiteindelijke afstandsmatrix gebeurt nu als volgt:

• Per werkgroep (32x1x4 werkitems) wordt er een locale reductie uitgevoerd. Eerstworden de individuele waarden van de afstandmatrix berekend: deze waardenworden in het locaal geheugen weggeschreven. Vervolgens worden alle draden metbehulp van de OpenCL functie barrier(CLK_LOCAL_MEM_FENCE)gesynchroniseerd zodat alle waarden in het locaal geheugen geldig zijn. Aangezienvoor de 32 draden binnen één en hetzelfde blok (warp) de instructies striktsequentieel uitgevoerd worden, is er tussen de opeenvolgende reductiestappen geensynchronisatie nodig. De locale reductie wordt in Figuur 22 weergegeven;

• Het resultaat van de locale reductie is (per vingerafdruk) één matrix van 3 op 96punten (“3 op 96” = “96 / 32 op 96”). Deze tijdelijke matrix kunnen we in eentweede stap reduceren tot één maximale waarde per vingerafdruk. Hiervoor moeteen tweede kernel gebruikt worden omdat het synchroniseren tussen werkgroepenniet mogelijk is. Dit zou immers de hardware implementatie van de GVE tecomplex (en te duur) maken. Deze reductie kernel vertrekt van de matrix met 3 op96 punten en reduceert deze matrix tot één waarde: de waarde in het punt (0, 0)

50

bevat finaal de maximale waarde van de eerder berekende uiteindelijkeafstandsmatrix. Ter verduidelijking wordt de finale implementatie [IMPL5]schematisch in Figuur 23 weergegeven.

unsigned int tid = get_local_id(0); // thread ID in workgroupunsigned int fpid = get_local_id(2); // fingerprint ID in workgroup

// local result vector (assume workgroup dimensions 32x1x4)__local float fpRes[32][4];

// do reduction in shared memif (tid < 16){

fpRes[tid][fpid] = max(fpRes[tid][fpid], fpRes[tid + 16][fpid]);fpRes[tid][fpid] = max(fpRes[tid][fpid], fpRes[tid + 8][fpid]);fpRes[tid][fpid] = max(fpRes[tid][fpid], fpRes[tid + 4][fpid]);fpRes[tid][fpid] = max(fpRes[tid][fpid], fpRes[tid + 2][fpid]);fpRes[tid][fpid] = max(fpRes[tid][fpid], fpRes[tid + 1][fpid]);

}

Figuur 22: AUDI fast op GVE, locale reductie kernelcode [IMPL5].

Figuur 23: AUDI fast op GVE, werkingsprincipe implementatie [IMPL5]. KERNEL1: aan de hand van hetintegraalbeeld wordt, overeenkomstig telkens 4 vingerafdrukken, een subafstandsmatrix van 32x1x4 puntenberekend. Deze subafstandsmatrix wordt gereduceerd tot 1x1x4, en bijgevolg resulteert dit, uiteindelijk, ineen matrix van 3x96 punten per vingerafdruk. KERNEL2: verdere reductie, per vingerafdruk, van de matrixvan 3x96 punten tot één maximum waarde (per vingerafdruk).

51

Tabel 12: AUDI fast op GVE, tijd 5120 vingerafdrukken, implementatie [IMPL5].

Verwerkingsstap en versieimplementatie

Tijd(ms)

Individueleversnelling

Cumulatieveversnelling

VersnellingCVE/GVE

Parallelle classificatie – 5120vingerafdrukken [IMPL1] 1.328,89 - - 8091,91 ms

7,09xParallelle classificatie – 5120vingerafdrukken [IMPL2]Optimalisatie volgorde berekeningpixelvlakken en optimalisatie indienéén waarde nul is

1.295,05 33,83 ms1,03x

33,83 ms1,03x

8125,75 ms7,27x

Parallelle classificatie – 5120vingerafdrukken [IMPL3]Gebruik constant geheugen voorbeschrijving vingerafdrukken.

694,24 600,81 ms1,86x

634,65 ms1,92x

8726,56 ms13,57x

Parallelle classificatie – 5120vingerafdrukken [IMPL4]Gebruik blokgrootte 64 enwerkgroepen van 32x1x4 werkitems

444,93

249,31ms1,56x 883,96 ms

2,99x8975,87 ms

21,17

Parallelle classificatie – 5120vingerafdrukken [IMPL5]Berekenen classificatiescore

792.98 -348,06ms0,56x - 8627,82

11,88x

De resultaten van implementatie [IMPL5] worden weergegeven in Tabel 12. Deuitvoeringstijd is met 348,06 ms toegenomen: deze extra tijd is ten gevolge van debijkomende reductiestap. Uiteindelijk bekomen we een versnelling ten opzichte van desequentieel geïmplementeerde classificatie van 8627,82 ms of een versnelling met eenfactor 11,88.

52

Hoofdstuk 4

Vaststellingen, besluit en verder onderzoek

4.1 Vaststellingen

Het omzetten van een sequentieel uitgevoerd algoritme naar een parallel uitvoerbaaralgoritme is geen exacte wetenschap. Voordat de eerste letter code geschreven wordt is hetraadzaam om eerst een grondige studie en analyse te voorzien. In ons geval is hier meerdan 60% van de totale tijd aan besteed. Het is immers niet zinvol om zonder enige kennisvan zaken te werk te gaan.

Na de analyse kan aan de hand van enkele voorbeelden de mogelijkheden van hetgekozen raamwerk getest worden. In het geval van OpenCL lijkt de NVIDIAimplementatie het meest toegankelijk te zijn: naast de vele CUDA voorbeelden wordt bijde installatie van de NVIDIA OpenCL implementatie een 30-tal voorbeelden meegeleverd.Deze voorbeelden vormen een schat van informatie. Ook de meegeleverde documentatie isvan uitstekende kwaliteit.

Naast de voorbeelden en de documentatie voorziet NVIDIA ook in een profiling tool:de “OpenCL Visual Profiler”. De “OpenCL Visual Profiler” is, vreemd genoeg, eenonderdeel van de CUDA toolkit versie 3.0. Bij het uitvoeren van enkele experimentenbleek dat de beperkte documentatie echter ontoereikend is: de juiste interpretatie van deverschillende gemeten waarden is onvoldoende gedocumenteerd.

De meest tijdrovende bezigheid bij de ontwikkeling met behulp van het OpenCLraamwerk is het opsporen van programmeer fouten. De afwezigheid van een debuggingomgeving is een ernstige tekortkoming. Hier lijkt gDEBugger [5] een oplossing te bieden.Tijdens het uitvoeren van onderstaande thesis was de OpenCL versie van deze debuggingtool echter nog niet beschikbaar.

53

4.2 Besluit

In deze thesis hebben we aangetoond dat een parallelle implementatie van het AUDIfast classificatiealgoritme mogelijk is: voor een GVE met slechts 6 multiprocessoren is desnelheid bijna 12 maal groter dan een vergelijkbare sequentiële implementatie op de CVE.Naarmate het aantal te differentiëren klassen toeneemt is de tijdswinst per te classificerendocument opmerkelijk: in het geval dat we een bibliotheek hebben met 5120vingerafdrukken bekomen we een tijdswinst van meer dan 8,6 seconden per “ongekenddocument”.

De doelstelling: “7 pagina’s per seconde classificeren ten opzichte van een bibliotheekmet 5120 elementen” impliceert een maximale verwerkingstijd van 142 ms per “ongekenddocument”. Gegeven dat de parallel geïmplementeerde AUDI fast classificatie per“ongekend document” finaal bijna 793 ms in beslag neemt, is deze doelstelling, striktgenomen, niet bereikt. Echter, het gebruikte hardwareplatform beschikt (slechts) over 48processoren. Ter vergelijking: een professionele GVE beschikt over 480 processoren, hettienvoud.

De classificatietijd in functie van het aantal te onderscheiden vingerafdrukken is inGrafiek 9 weergegeven. Vanaf 64 vingerafdrukken schalen beide implementaties lineair –de complexiteit is O(n) met n het aantal te onderscheiden vingerafdrukken.

Grafiek 9: Vergelijking classificatietijd in functie van het te onderscheiden vingerafdrukken.

54

4.3 Verder onderzoek

De parallelle implementatie van het AUDI fast algoritme geeft hoopgevende resultaten.De in deze thesis gepresenteerde resultaten kunnen aanleiding geven tot verder onderzoeken ontwikkeling.

Hieronder schetsen we kort enkele ideeën:

• De metingen zoals beschreven in paragraaf 3.5 zijn uitgevoerd op een GVE met eenbeperkte rekencapaciteit. De eerste voor de hand liggende vraag die we ons kunnenstellen is: hoe gedraagt de parallelle implementatie zich op een professionele GVE.Nemen we als voorbeeld de NVIDIA GeForce GTX 295. Deze GVE beschikt intotaal over 480 processoren. Theoretisch zou deze GVE 10-maal sneller moetenzijn ten opzicht van het gebruikte referentie hardwareplatform. We vermoeden datin de praktijk bepaalde knelpunten (zoals bijvoorbeeld de geheugensnelheid of debezettingsgraad) deze versnelling in de weg kunnen staan.

• De parallelle implementatie is geoptimaliseerd voor de NVIDIA GVE. Het zounuttig zijn om de performantie met een ander type GVE (NVIDIA versus NVIDIA,NVIDIA versus AMD en AMD versus AMD) te vergelijken. De onderliggendehardware implementatie is immers per GVE type verschillend. Ook de manierwaarop de kernels over de processoren verdeeld worden kan eenperformantieverschil tot gevolg hebben. Nemen we als voorbeeld de ATI Radeon™HD 5870 GPU: deze GPU bestaat uit 20 rekeneenheden, met elk 16 kernen en elkekern 5 verwerkingselementen. In totaal beschikt deze GVE dus over 1600verwerkingselementen.

• Uitgaande van de OpenCL specificaties kan de huidige implementatie (zonder codeaanpassing) eveneens uitgevoerd worden op een ander heterogeen toestel. Wedenken hierbij bijvoorbeeld aan de Cell Processor. Momenteel hebben we geenzicht op de performantie in het geval er gebruik gemaakt wordt van een CellProcessor – hiervoor zou eerst onder andere de architectuur van de Cell Processorgrondig bestudeerd moeten worden.

• Zoals in paragraaf 3.3.1 beschreven is het automatiseren van de definitie van debibliotheek met “gekende documenten” een potentieel onderwerp van eenvervolgthesis. Inderdaad, vooraleer het parallel geïmplementeerd AUDI fastalgoritme kan gecommercialiseerd worden, is er nood aan een automatischedefinitie van de bibliotheek. Het is immers niet mogelijk om dit manueel te doen:dit zou een te tijdrovende bezigheid zijn. Trouwens, de manuele definitie vereisteen grondige kennis van de interne werking van het AUDI fast algoritme.

55

Referenties

[1] Beschrijving MATLAB functie imnoise (Add noise to image),http://www.mathworks.com/access/helpdesk/help/toolbox/images/imnoise.html.

[2] Daniel Lélis Baggio, GPGPU BASED IMAGE SEGMENTATION LIVEWIREALGORITHM IMPLEMENTATION, 2007.

[3] GPU Review, NVIDIA GeForce GTS 250, http://www.gpureview.com/GeForce-GTS-250-card-606.html.

[4] GPU Review, NVIDIA GeForce GTX 295, http://www.gpureview.com/geforce-gtx-295-card-603.html.

[5] Graphic Remedy, gDEBugger CL, http://www.gremedy.com/gDEBuggerCL.php

[6] John D. Owens, David Luebke, Naga Govindaraju, Mark Harris, Jens Krüger, Aaron E.Lefohn, and Tim Purcell. A Survey of General-Purpose Computation on GraphicsHardware. Computer Graphics Forum, 26(1):80–113, March 2007.

[7] Kanupriya Gulati en Sunil P Khatri, “An Automated Approach for SIMD KernelGeneration for GPU based Software Acceleration”,http://saahpc.ncsa.illinois.edu/09/papers/Gulati_paper.pdf.

[8] Khronos, OpenCL - The open standard for parallel programming of heterogeneous systems,http://www.khronos.org/opencl/.

[9] Lucid HYDRA: Combine multi-GPU Power into one – NVIDIA, AMD ATi,http://www.taranfx.com/lucid-hydra-combine-multi-gpu-power-into-one-nvidia-amd-ati.

[10] Mark Harris, Optimizing Parallel Reduction in CUDA,http://developer.download.nvidia.com/compute/cuda/1_1/Website/projects/reduction/doc/reduction.pdf

[11] Neil Trevett and Cyril Zeller, NVIDIA, "OpenCL on the CVE", San Jose, CA, September30, 2009.

[12] Neil Trevett and Cyril Zeller, NVIDIA, "OpenCL on the GPU", San Jose, CA, September30, 2009.

56

[13] NVIDIA, OpenCL Best Practices Guide, version 2.3,http://developer.download.NVIDIA.com/compute/cuda/3_0/toolkit/docs/NVIDIA_OpenCL_BestPracticesGuide.pdf.

[14] NVIDIA, OpenCL Programming Guide for the CUDA Architecture, version 2.3, 2009.

[15] OpenCL.NET, binding tot OpenCL API, http://sourceforge.net/projects/openclnet/

[16] Passmark software, Video Card Benchmarks,http://www.videocardbenchmark.net/30dayshare.html, 2010.

[17] Wikipedia, Document classification, http://en.wikipedia.org/wiki/Document_classification.

[18] Wikipedia, OpenCL, http://nl.wikipedia.org/wiki/OpenCL.