Parallelisierung des Levenshtein Algorithmus

Transkript

1 Köln, den 30. August 2014 Studiengang Informationsverarbeitung Sommersemester 2014 Sprachliche Informationsverarbeitung Hauptseminar: Angewandte Linguistische Datenverarbeitung bei Prof. Dr. Jürgen Rolshoven Parallelisierung des Levenshtein Algorithmus vorgelegt von: Alena Tabea Geduldig

2 Inhalt 1 Einleitung Die Editierdistanz Der Levenshtein Algorithmus Das Prinzip der Dynamischen Programmierung Zerlegung des Problems in Teilprobleme Lösung der kleinsten Teilprobleme Schrittweise Lösung des Gesamtproblems 7 3 Datenparalleles Rechnen auf der GPU OpenCL und Aparapi Datenparallelisierung des Levenshtein Algorithmus Anwendungsvariante 1: Editierdistanz vollständiger Dokumente Parallelisierungsstrategie Anwendungsvariante 2: Editierdistanz auf Wortebene Parallelisierungsstrategie.14 5 Laufzeitvergleich Laufzeitvergleich der dokumentbasierten Anwendungsvariante Laufzeitvergleich der wortbasierten Anwendungsvariante Fazit Literaturverzeichnis... 23

3 1 Einleitung Die vorliegende Hausarbeit baut auf das im Wintersemester 2011/2012 gehaltene Referat zum Thema Stringvergleich in der Computerlinguistik und Bioinformatik auf. Dort wurde ein in beiden Wissenschaftsbereichen angewendetes Maß zum Vergleich von Zeichenketten vorgestellt: Die Editierdistanz. Die Editierdistanz ist ein Maß für die Ähnlichkeit beziehungsweise Unähnlichkeit zweier Strings. Sie fällt damit in den Bereich des approximativen Matchens, also den Teilbereich der Stringverarbeitung, der die Ermittlung ähnlicher, aber nicht notwendigerweise identischer Zeichenketten zum Ziel hat. Das Ziel des approximativen Matchens lässt sich wie folgt charakterisieren: approximate matching problem Erkenne, finde und toleriere Zeichenketten, die einer gegebenen Zeichenkette weitgehend ähnlich sind und zwar unabhängig davon, worin die Abweichung von der Gleichheit besteht und wo sie im String lokalisiert ist. (vgl. Wegst 2006) Diese Zielsetzung setzt ein adäquates Maß für die Bewertung der Ähnlichkeit oder Unähnlichkeit von Strings voraus. In welchem Sinne adäquat in diesem Zusammenhang zu verstehen ist, wird zu Beginn dieser Arbeit erläutert und schließlich die Editierdistanz als ein geeignetes Maß für den Stringvergleich vorgestellt. Der Schwerpunkt dieser Arbeit liegt auf dem Algorithmus mit dem die Editierdistanz zweier Strings maschinell berechnet wird. Der Levenshtein Algorithmus liefert zu je zwei Zeichenketten die zugehörige Editierdistanz. In der Praxis wird der Algorithmus oft auf sehr großen Datenmengen angewendet. Beispielsweise in der Bioinformatik, um eine Gensequenz mit allen Gensequenzen einer Datenbank zu vergleichen. In der Computerlinguistik wird der Algorithmus unter anderem zur automatischen Rechtschreibkorrektur herangezogen. Bei einer manuellen Texteingabe, beispielsweise in eine Suchmaschine, kann die Editierdistanz dazu verwendet werden, dass neben identischen Treffern auch grammatisch oder phonetisch ähnliche Wörter berücksichtigt werden. In diesem Anwendungsfall muss der Levenshtein Algorithmus sehr häufig hintereinander ausgeführt werden, jeweils aber nur auf Wortebene, also auf relativ kurzen Zeichensequenzen. Neben dem Vergleich einzelner Wörter kann die Editierdistanz auch zum Vergleich vollständiger Dokumente, beispielsweise zur Plagiatserkennung, verwendet werden. In diesem Fall wird der Levenshtein Algorithmus nur einmal ausgeführt, jedoch auf erheblich längeren Zeichenketten. Beide Anwendungsvarianten werden mit wachsender Datenmenge sehr laufzeitintensiv. Im ersten Fall liegt dies weniger an der Laufzeit einer einzelnen 1

4 Algorithmusausführung, als an der Menge der Wiederholungen. Im zweiten Fall treibt die Länge der Dokumente die quadratische Laufzeit des Algorithmus in die Höhe. In dieser Hausarbeit wird ein Versuch unternommen, der starken Laufzeitentwicklung des Levenshtein Algorithmus durch die Anwendung eines GPU-gestützten Programmierverfahrens entgegenzuwirken. Dieses Programmierverfahren hat sich innerhalb der letzten Jahre unter dem Namen General Purpose Computation on Graphics Processing Units (GPGPU) etabliert. Neben der CPU, der zentralen Recheneinheit eines Computers, wird auch die GPU, die zentrale Recheneinheit der Grafikkarte, zur Ausführung von Befehlen verwendet. Durch eine geschickte Ausnutzung ihrer hardwarespezifischen Besonderheiten soll die Grafikkarte zu einer besseren Performance laufzeitintensiver Anwendungen beitragen. Das Ziel dieser Arbeit ist es, ein Programm zu implementieren, dass die Ausführung beider der oben skizzierte Anwendungsvarianten des Levenshtein-Algorithmus ermöglicht. Hierfür wird einmal eine herkömmliche Java-Applikation entwickelt, und einmal die GPGPU unterstützende Programmiersprache OpenCL verwendet. Durch einen Laufzeitvergleich dieser funktionsgleichen Programme, soll die zentrale Frage beantwortet werden, ob, und welche Anwendung des Levenshtein Algorithmus durch GPU-Programmierung beschleunigt werden kann. 2

5 2 Die Editierdistanz Das Ziel des approximativen Matchens ist die Erkennung zueinander ähnlicher Zeichenketten. Diese Aufgabe erfordert ein Maß, mit dem die Ähnlichkeit beziehungsweise Unähnlichkeit zweier Zeichenfolgen eindeutig bestimmt werden kann. Wie könnte also ein adäquates Maß für String- Ähnlichkeit aussehen? Zu je zwei Zeichenketten sollte ein Ähnlichkeitsmaß eine eindeutige Maßzahl liefern, die den Unterschiedlichkeitsgrad der beiden Strings ausdrückt. Gesucht ist folglich eine Abbildung, die ein Paar von Strings <S 1, S 2 > auf eine Zahl abbildet. Im Falle eines Distanzmaßes sollten zueinander ähnlichere Strings auf eine niedrigere Zahl abgebildet werden, als deutlich verschiedenere Strings. (Bei einem Ähnlichkeitsmaß gilt die genau umgekehrte Anforderung). Eine weitere Anforderung an ein adäquates Distanzmaß ist, dass die Reihenfolge der beiden Strings keine Auswirkung auf den Distanzwert haben sollte. Es sollte also keine Rolle spielen, ob das Paar <S 1, S 2 >, oder <S 2, S 1 > bewertet wird, da die Ähnlichkeit von Strings unabhängig von ihrer Reihenfolge ist. Als letzte Anforderung sollte ein Distanzmaß identische Strings auf den Wert 0 abbilden. Die Editierdistanz ist ein Stringmaß, das genau diese Eigenschaften erfüllt. Sie misst die Operationen, die notwendig sind, um den ersten String in den zweiten String zu überführen. Zugelassen sind hierbei genau drei Operationen: 1. Das Löschen eines Zeichens aus S 1 (delete) 2. Das Einfügen eines Zeichens in S 1 (insert) 3. Der Austausch eines Zeichens von S 1 in ein Zeichen von S 2 (replace) Eine Folge von Operationen, die einen Strings S 1 in einen anderen String S 2 überführt, nennt man Editskript von S 1 und S 2. Hieraus ergibt sich auch die exakte Definition der Editierdistanz: Definition Die Editierdistanz des Stringpaares <S 1,S 2 > entspricht genau der Länge des kürzesten Editskriptes von S 1 und S 2.(vgl. Gusfield 1997: 216) Stimmen zwei Zeichen überein, so dass keine Operation notwendig ist, enthält das Editskript die Anweisung match (engl. Übereinstimmung), welche jedoch nicht als Operation gezählt wird. Zur Veranschaulichung ist nachfolgend ein Editskript für das Stringpaar <darling, airline> aufgeführt: E darling,airline = d,m,i,m,m,m,r 3

6 Folgt man dieser Operationsfolge nacheinander angewendet auf die einzelnen Zeichen des Wortes darling, erhält man den neuen String airline. E darling,airline ist folglich ein gültiges Editskript für dieses Stringpaar. Es hat die Länge 3, da es drei der oben genannten Operationen enthält. Da es kein noch kürzeres Editskript gibt, ist drei die Editierdistanz der beiden Strings. Der Vermerk auf ein kürzestes Editskript in der Definition der Editierdistanz weist darauf hin, dass gültige Editskripte nicht eindeutig und von unterschiedlicher Länge sein können. Mit der Länge des kürzesten Editskriptes ist die Editierdistanz jedoch eindeutig bestimmt und erfüllt somit die erste Bedingung (Eindeutigkeit) an ein adäquates Distanzmaß. Im Folgenden wird gezeigt, dass die Editierdistanz auch die weitere Anforderung (Unabhängigkeit der String- Reigenfolge) erfüllt: Um S 1 in S 2 zu überführen ist sicherlich ein anderes Editskript nötig, als um S 2 in S 1 zu überführen. Beide sollten jedoch dieselbe Länge haben um die Anforderung zu erfüllen. Sei also E 1,2 ein kürzestes Editskript für <S 1,S 2 > der Länge n. Dann entspricht n der Editierdistanz von <S 1,S 2 >. Nun erhält man durch den Austausch der Operationen delete und insert auch ein Editskript für das Paar <S 2,S 1 > das ebenfalls die Länge n hat. Gäbe es ein noch kürzeres Editskript für das Paar <S 2,S 1 >, etwa der Länge n-i, so ließe sich auch daraus, durch den Austausch der Operationen delete und insert ein Editskript für <S 1,S 2 > erzeugen. Dieses hätte jedoch auch die Länge n-i, was im Widerspruch zur Voraussetzung steht, das n bereits die Länge des kürzesten Editskriptes war. Folglich muss n auch bereits die Länge des kürzesten Editskriptes von <S 2,S 1 > sein, womit die Anforderung erfüllt ist. Dass auch die dritte Anforderung (Abbildung identischer Strings auf den Wert 0) erfüllt ist, geht unmittelbar aus der Definition hervor. Die Editierdistanz ist somit ein adäquates Distanzmaß für die Ähnlichkeit von Zeichenketten. Bisher wurde jedoch nur die Definition dieses Maßes erläutert, nicht aber wie die Editierdistanz maschinell berechnet werden kann. Mit dieser Frage befasst sich das folgende Kapitel. 4

7 3 Der Levenshtein Algorithmus Der Levenshtein Algorithmus ist benannt nach dem russischen Wissenschaftler Wladimir Lewenstein, der die Editierdistanz im Jahr 1965 einführte. Zu je zwei Zeichenketten liefert der Levenshtein-Algorithmus die zugehörige Editierdistanz. Er basiert auf dem Prinzip der dynamischen Programmierung und liefert bei Bedarf nicht nur die Editierdistanz, sondern auch alle möglichen Editskripte zweier Strings. 3.1 Das Prinzip der Dynamischen Programmierung Dynamische Programmierung ist eine algorithmische Methode zur Lösung von Optimierungsproblemen. Sie kann dann erfolgreich eingesetzt werden, wenn das zu lösende Problem in mehrere äquivalente Teilprobleme gegliedert werden kann. Löst man zunächst die kleinsten Teilprobleme optimal, so können diese zu den Lösungen der jeweils größeren Teilprobleme erweitert werden. Indem man alle Teillösungen in einer Tabelle speichert, wird dieses Prinzip fortgeführt, bis schließlich die Lösung des Gesamtproblems erreicht wird. (zur Dynamischen Programmierung siehe auch Cormen 2013: Kap. 15) Dynamische Programmierung lässt sich folglich in drei Schritte zerlegen: 1. Zerlegung des Gesamtproblems in Teilprobleme 2. Lösung der kleinsten Teilprobleme 3. Sukzessives Lösen der jeweils nächstgrößeren Teilprobleme Diese drei Schritte werden nun, angewendet auf die Editierdistanz, erläutert Zerlegung des Problems in Teilprobleme Der erste Schritt zur dynamischen Lösung eines Optimierungsproblems ist die Zerlegung in mehrere Teilprobleme. Im Fall der Editierdistanz bedeutet dies, dass die beidem Strings in alle ihre möglichen Präfixe {S 1 (0..i)} i=0-n und {S 2 (0 j)} j=0-m zerlegt werden. Als ein Teilproblem ist somit die Berechnung der Editierdistanz eines Präfixpaares zu verstehen. Des Weiteren wird eine Matrix D angelegt, in der die Zwischenlösungen, also die Editierdistanzen aller Präfixpaare gespeichert werden. Jede Teillösung hat dabei einen festen Platz in der Matrix. Abbildung 3.1 veranschaulicht diesen Vorgang für das Stringpaar <brot,not>. 5

8 Abbildung 3.1: Distanzmatrix zur Speicherung von Teillösungen zur Berechnung der Editierdistanz am Beispiel des Stringpaares <brot,not>. Jeder Matrixeintrag steht für die Editierdistanz eines Präfixpaares Lösung der kleinsten Teilprobleme Die kleinsten Teilprobleme sind im Falle des Levenshtein-Algorithmus die Distanzberechnungen der Präfixpaare, bei denen mindestens einer der beiden Präfixe dem leeren String entspricht. Die Lösungen sind trivial und ohne Rechenaufwand bestimmbar: Die Distanz eines Strings zum leeren String entspricht genau seiner Länge. Jedes Zeichen muss durch eine delete-operation gelöscht werden. Abbildung 3.2 zeigt die Distanzmatrix nach der Ausführung des ersten Teilschritts: Abbildung 3..2: Distanzmatrix nach Lösung der kleinsten Teilprobleme. 6

9 3.1.3 Schrittweise Lösung des Gesamtproblems Das Ziel dieses Schritts ist es, die Matrix nun sukzessive mit den Editierdistanzen der übrigen Präfixpaare zu füllen, so dass der Matrixeintrag D[i][j] der Distanz des Stringpaares <S 1 (1..i), S 2 (1..j)> entspricht. Dies erfolgt Zeilenweise (oder Spaltenweise) damit auf die Lösungen der jeweils kleineren Präfixpaare aufgebaut werden kann. Bei der Berechnung des Eintrages D[i][j] sind die folgenden Editskripte somit bereits bekannt: (a) Das Editskript E i-1,j von <S 1 (1..i-1), S 2 (1 j)> (Eintrag D[i-1][j ]) (b) Das Editskript E i,j-1 von <S 1 (1..i),S 2 (1..j-1)> (c) Das Editskript E i-1,j-1 von <S 1 (1..i-1), S 2 (1..j-1)> (Eintrag D[i ][j-1]) (Eintrag D[i-1][j-1]) Wie nun gezeigt wird, benötigt das gesuchte Editskript E i,j höchstens eine Operation mehr, als das kürzeste der oben aufgezählten Editskripte (a) (c): (a) Wenn E i-1,j eine Vorschrift ist, um das Präfix S 1 (1..i-1) in das Präfix S 2 (1..j) zu überführen, dann ist E i-1,j + delete auch eine Vorschrift um S 1 (1..i-1,i) in S 2 (1..j) zu überführen. delete sorgt dann genau für die Entfernung des überflüssigen i-ten Zeichens aus S 1. (b) Äquivalent dazu erfüllt auch E i,j-1 + insert die Anforderungen eines Editskripts für S 1 (1..i) in S 2 (1..j). Wenn E i,j-1 das Präfix S 1 (1..i) in das Präfix S 2 (1..j-1) überführt, dann erhält man durch ein anschließendes Hinzufügen des j-ten Zeichens von S 2 aus dem Präfix S 1 (1..i) das Präfix S 2 (1 j-1,j) (c) Um E i-1,j-1 zu dem gesuchten Editskript zu erweitern, müssen 2 Fälle unterschieden werden: 1. Das i-te Zeichen von S 1 und das j-te Zeichen von S 2 sind identisch: In diesem Fall ist keine weitere Operation mehr nötig. Das gesuchte Editskript lautet Ei-1,j-1 + match 2. Das i-te Zeichen von S 1 und das j-te Zeichen von S 2 sind nicht identisch: Das gesuchte Editskript lautet in diesem Fall Ei-1,j-1+replace. Das i-te Zeichen von S 1 wird durch das j-te Zeichen von S 2 ersetzt. Aus diesen Überlegungen ergibt sich folgende Rekursionsgleichung zur zeilenweisen Berechnung der fehlenden Matrixeinträge: 7

10 Abbildung 3.3 zeigt die vollständig berechnete Distanzmatrix mit Hilfe der Rekursionsgleichung für das Paar <brot, not>. Die gesuchte Editierdistanz befindet sich im letzten Matrixfeld D[4][3]. Abbildung 3.3: Vollständig ausgefüllte Distanzmatrix für das Stringpaar <brot, not> Bei Bedarf erhält man aus der Matrix auch die zugehörigen Editskripte. Hierfür muss ein Backwerden. (Vgl. Gusfield Trace durch die Matrix beginnend beim letzten Eintrag durchgeführt 1997: 221) Nachdem nun die Funktionalität des Levenshtein-Algorithmus erläutert wurde, werden im folgenden Kapitel die Möglichkeiten seiner Parallelisierung untersucht. Sollte sich der Algorithmus, in parallel ausführbare Berechnungen zerlegen lassen, so können diese durch die Ausführung auf einem Grafikprozessor (GPU) umgesetzt werden. 8

11 3 Datenparalleles Rechnen auf der GPU Die besondere Architektur moderner Grafikkarten ermöglicht die datenparallele Ausführung von Befehlen. Dies bedeutet, dass auf einer GPU derselbe Befehlssatz zeitgleich auf unterschiedlichen Daten ausgeführt werden kann, statt nacheinander wie auf einem CPU-Kern. Verglichen mit einer sequentiellen Ausführung, kann durch daten-paralleles Rechnen also sehr viel Rechenzeit eingespart werden. Voraussetzung ist natürlich, dass ein Algorithmus auf die datenparallele Arbeitsweise übertragbar ist ohne in seiner Funktionalität verfälscht zu werden. Die Gründe für die parallele Rechenfähigkeit von Grafikprozessoren liegen in ihrer vielkernigen Architektur. Während eine herkömmliche CPU in etwa 4 8 Kerne besitzt, verfügt eine GPU über mehrere hundert Kerne. Im Unterschied zu den Kernen einer CPU, haben GPU-Kerne keinen eigenen Befehlssatz, sondern teilen sich einen Befehlssatz und Cache mit vielen weiteren Kernen. Dies hat die folgenden Konsequenzen: Auf Grund der sehr hohen Zahl an Kernen, ist auf der GPU hochgradig paralleles Rechnen möglich, denn jeder Kern kann zeitgleich auf unterschiedlichen Daten operieren. Da sich die Kerne ihren Befehlssatz jedoch mit anderen Kernen teilen müssen, können sie zeitgleich auch nur dieselben Befehle ausführen. Dies ist auch der Grund warum nur datenparalleles und kein taskparalleles 1 Rechnen möglich ist. Zur Kommunikation mit der Grafikkarte eines Computers sind inzwischen Schnittstellen entwickelt worden, die den Austausch von Befehlen und Daten zwischen CPU und GPU ermöglichen. Zu den populärsten gehören die Schnittstellen CUDA (Compute Unified Device Language) 2, welche allein der Programmierung von Nvidia-Grafikchips vorbehalten ist und die plattformunabhängige Schnittstelle OpenCL (Open Compute Language) 3. OpenCL geht aus einer Zusammenarbeit der Firmen Apple, Nvidia, AMD, IBM und Intel hervor und wurde 2008 in einer ersten Version vorgestellt. Aus Gründen der besseren Austauschbarkeit und Reproduzierbarkeit, wurde für die Implementierungen zu dieser Arbeit die Schnittstelle OpenCL zu Grunde gelegt. Darüber hinaus wurde Aparapi 4 verwendet. Dies ist eine offene Bibliothek, die Java-Bytecode während der Laufzeit in OpenCL-Code übersetzt. 3.1 OpenCL und Aparapi 1 Beim taskparallelen Rechnen werden zeitgleich unterschiedliche, meist umfangreiche Aufgaben ausgeführt. 2 zuletzt aufgerufen am zuletzt aufgerufen am zuletzt aufgerufen am

12 Eine OpenCL-Anwendung lässt sich unterteilen in ein Host-Programm und ein Kernel- Programm. Das Host-Programm läuft auf der CPU und regelt von dort aus den Programmfluss. Von hier aus wird die Schnittstelle OpenCL initiiert und die Kommunikation mit der GPU durchgeführt. Ein Kernel ist der Teil der Anwendung, der für die Ausführung auf der GPU bestimmt ist. Wird ein Kernel zur parallelen Ausführung an die GPU gesendet, wird ein Indexraum erstellt. Jedem Punkt des Indexraumes wird dann eine Instanz des Kernels zugeordnet. Jede Instanz ist zur Ausführung auf einem anderen GPU Kern bestimmt. Durch den ihr zugewiesenen Punkt im Indexraum, ihre globale ID sind die einzelnen Kernelinstanzen eindeutig identifizierbar. Jede Kernelinstanz wird zeitgleich von einem der GPU Kerne ausgeführt. Alle enthalten dieselben Befehle, die jedoch durch eine Bezugnahme auf die globale ID variieren können. Eine Kernelinstanz ist somit vergleichbar mit einem Schleifendurchlauf einer for-schleife. Auch hier werden in jedem Durchlauf dieselben Befehle ausgeführt, die durch eine Bezugnahme auf den Laufindex variieren. Der Unterschied liegt jedoch darin, dass die Kernelinstanzen parallel ausgeführt werden, während eine for-schleife sequentiell abgearbeitet wird. Kernelprogramme müssen normalerweise in einer OpenCL-spezifischen Sprache geschrieben und als Textdatei oder in String-Form separat abgespeichert werden. Die Aparapi-Bibliothek stellt jedoch die Klasse Kernel bereit, welche direkt in das Programm eingebunden werden kann. Die Klasse Kernel erfordert die Implementation der Methode run(), welche aus dem Host- Programm aufgerufen werden kann. In dieser Methode können die auf der GPU auszuführenden Befehle in Java-Code definiert werden. Über die Befehle put() und get() kann das Host-Programm außerdem den Hin- und Rücktransfer von Daten zwischen CPU- und GPU- Speicher regeln. 10

13 4 Datenparallelisierung des Levenshtein Algorithmus Im Rahmen dieser Arbeit wurden zwei verschiedene Anwendungsmöglichkeiten des Levenshtein-Algorithmus implementiert. Die erste Variante berechnet die Editierdistanz von jeweils zwei vollständigen Dokumenten. Die zweite Variante berechnet die Editierdistanz eines einzelnen Wortes zu jedem Wort in einer gegebenen Datenbank. Beide Versionen wurden einmal auf herkömmliche sequentielle Weise implementiert und einmal als daten-parallele OpenCL- Anwendung. 4.1 Anwendungsvariante 1: Editierdistanz vollständiger Dokumente Diese Levenshtein-Variante ist für Anwendungen konzipiert, bei denen der Levenshtein- Algorithmus nur einmalig und auf sehr langen Zeichenketten ausgeführt wird, also beispielsweise zur Plagiatsanalyse. Die jeweiligen Implementierungen befinden sich im Package documentbasedlevenshtein. Abbildung 4.1 zeigt das zugehörige Klassendiagramm. Die abstrakte Klasse AbstractDocBasedLevenshtein definiert die Methode setdocuments(), zur Übergabe der Dokumente und die abstrakte Methode getdistance(). Diese Methode wird in der KlasseSequentialDocBasedLevenshtein auf herkömmliche Weise, so wie in Kapitel 2 beschrieben, realisiert. ParallelDocBasedLevenshtein erfüllt dieselbe Funktion, nutzt hierfür jedoch die parallelen Strukturen der Grafikkarte. 11

14 Abbildung 4.1: Klassendiagramm für die dokumentbasiere Anwendungsvariante des Levenshtein Algorithmus Parallelisierungsstrategie Um die Vorteile der Berechnung auf der GPU nutzen zu können ist zunächst eine Analyse des Algorithmus hinsichtlich seiner Parallelisierbarkeit durchzuführen. Zentrale Fragen ist hierbei, welche Berechnungsschrittee voneinander unabhängig sind, denn nur dann ist eine parallele Ausführung möglich. Die meiste Zeit des Algorithmus wird für die Berechnung der Matrixeinträge benötigt. Die Berechnung eines einzelnen Eintrags geschieht zwar in konstanter Zeit, jedoch müssen insgesamt n*m dieser Einträge berechnet werden, was in einer herkömmlichen sequentiellen Version eine verschachtelte for-schleife über alle Zeichen beider Dokumente erfordert. Wie im vorherigen Kapitel gezeigt wurde, sind die einzelnen Distanzberechnungen jedoch nicht alle unabhängig voneinander. Bis auf die Startlösungen baut jede Teillösung auf den Ergebnissen dreier weiterer Teilprobleme auf. Die Berechnung des Eintrags D[i][j] setzt die Lösungen in den Einträgen D[i-1][j], D[i][j-1] und D[i-1][j-1] voraus. Alle Matrixeinträge können folglich nicht zur selben Zeit bestimmt werden. Dennoch lassen sich einige Berechnungen, die nicht aufeinander aufbauen parallel ausführen, wie Abbildung 4.2 demonstriert. 12

15 Abbildung 4.2: Darstellung der parallel berechenbaren Matrixeinträge. Jeweils die Einträge auf einer Diagonalen sind unabhängig zueinander und eine zeitgleiche Berechnung somit möglich. Diese Parallelisierungsstrategie wird im Programm wie folgt umgesetzt: ParallelDocBasedLevenshtein stellt die Host-Applikation dar, die ebenfalls eine Realisierung der abstrakten Klasse AbstractDocBasedLevenshtein darstellt. DocBasedLevenshteinKernel enthält das auf der GPU ausführbare Kernelprogramm. Es kann aus der Host-Applikation heraus aufgerufen werden. Der erste Schritt zur Berechnung der Editierdistanz ist der Transfer der Dokumente vom CPUdie nach und nach zu Speicher an den GPU-Speicher. Dort wird außerdem Speicherplatz für berechnende Distanzmatrix alloziert. Mit dem ersten Kernelaufruf aus der Host-Methode getdistance() werden nun die ersten n+m+1 Matrixeinträge, also die Startbedingungen bestimmt. (Die entsprechenden Matrixfelder sin in Abbildung 4.2 mit dem Wert 0 markiert.) Jeder Eintrag wird parallel von einem der GPU-Kerne ermittelt. Iterativ folgen weiteree Kernelaufrufe aus der Host-Applikation. Mit jedem Kernelaufruf werden so viele Kernelinstanzen gebildet, wie bereits neue Einträge berechenbar sind. Ist die Matrix vollständig berechnet, befindet sich die Editierdistanz der Dokumente im Matrixfeld D[n+1][m+1]. Nur dieser Eintrag wird anschließend zurück an den CPU-Speicher transferiert und von der Methode getdistance() zurückgegeben. 4.2 Anwendungsvariante 2: Editierdistanz auf Wortebene Die zweite Anwendungsvariante der Editierdistanz ist für Anwendungenn konzipiert, bei denen ein einzelnes Wort, beziehungsweise eine kurze Zeichensequenz mit allen Wörtern in einer großen Datenbank verglichen werden soll. Die jeweiligen Implementierungen befinden sich im Package wordbasedlevenshtein. Abbildung 4.3 zeigt das zugehörige Klassendiagramm. Die abstrakte Klasse abstractwordbasedlevenshtein definiert die Methode setdatabase() mittels derer die zu Grunde gelegte Wort-Datenbank gesetzt werden kann. Außerdem wird die abstrakte Methode getalldistances() definiert, welche zu einem gegebenen Wort, sämtliche Editierdistanzen zu den 13

16 Wörtern der Datenbank zurückgeben soll. In der Klasse sequentialwordbasedlevenshtein wird diese Methode auf sequentielle Weise mittels einer Schleife über sämtliche Wörter der Datenbank realisiert. In jedem Iterationsschritt der Schleife wird die Editierdistanz des gegebenen Wortes zum entsprechenden Datenbankeintrag berechnet und im Ergebnis-Array festgehalten. Abbildung 4.3: Klassendiagramm für die wortbasierte Anwendungsvariante des Levenshtein Algorithmus Parallelisierungsstrategie Was in der sequentiellen Version nacheinander in den verschiedenen Schleifeniterationen geschieht, wird in der parallelen Variante zeitgleich von einzelnen GPU-Kernen abgearbeitet. Jeder GPU-Kern übernimmt eine vollständige Ausführung des Levenshtein-Algorithmus, jeweils für ein anderes Wort aus der Datenbank. Folglich müssen so viele Kernelinstanzen initiiert werden, wie es Wörter in der zu Grunde gelegten Datenbank gibt. Da die Distanzberechnung zweier Wörter unabhängig zu den Distanzberechnungen anderer Wortpaare erfolgen kann, ist in dieser Variante nur ein Kernelaufruf aus der Host-Applikation nötig der sämtliche Kernelinstanzen zeitgleich zur Ausführung frei gibt. Zu Beginn der Anwendung wird die vollständige Datenbank an den Speicher der GPU gesendet. Dieser Arbeitsschritt kostet zwar Transferzeit, die in der sequentiellen Version entfällt, jedoch ist dieser Datentransfer nur einmalig notwendig, und muss nicht für jedes einzelne Wort, dass mit der Datenbank verglichen werden soll wiederholt werden. Die zusätzliche Zeit durch Datentransfer in der parallelen Variante ist somit konstant und kann möglicherweise nach einigen 14

17 Datenbankabfragen wieder ausgeglichen werden. Voraussetzung hierfür ist natürlich, dass die parallele Distanzberechnung tatsächlich schneller ausgeführt werden kann, als die sequentielle Version. Das folgende Kapitel soll diese Frage beantworten und somit herausstellen, ob sich der Einsatz von Grafikprozessoren für Levenshtein-basierte Anwendungen lohnen kann. 15

18 5 Laufzeitvergleich Für den Performancevergleich zwischen den GPU-basierten Levenshtein-Varianten und den sequentiellen Varianten wurde die Gesamtlaufzeit der Anwendungen unter jeweils gleichen Voraussetzungen gemessen. Da das primäre Interesse dieser Untersuchungen dem Laufzeitverhalten gilt und nicht den berechneten Ergebnissen, spielt der semantische Inhalt der verwendeten Textdokumente in diesem Zusammenhang keine Rolle. Einfluss auf die Laufzeit hat lediglich die Länge der verwendeten Texte beziehungsweise Wörter. 5.1 Laufzeitvergleich der dokumentbasierten Anwendungsvariante Zunächst wurden die beiden Implementationen der ersten Anwendungsvariante des Levenshtein Algorithmus miteinander verglichen. Die Laufzeitmessungen beziehen sich also jeweils auf die Berechnung der Editierdistanz zweier vollständiger Dokumente. Es wurden Messungen mit jeweils variierenden Dokumentlängen gemacht. Die Ergebnisse sind in Abbildung 4.3 festgehalten. time total number of characters CPU-Time GPU-Time Abbildung 4.3: Laufzeitvergleich des datenparallelen und sequentiellen Levenshtein Algorithmus bei wachsender Dokumentlänge Auf den ersten Blick fallen die deutlich längeren Laufzeiten der GPU-basierten, datenparallelen Algorithmus-Version ins Auge. Sowohl bei insgesamt 2024 Zeichen, als auch bei deutlich längeren Dokumenten mit insgesamt ist die herkömmliche sequentielle Levenshtein- 16

19 Implementierung in der Laufzeit deutlich überlegen. Weitere Tests mit noch längeren Dokumenten waren auf Grund der begrenzten Speicherkapazität des Rechners nicht mehr möglich. Der Versuch, die Berechnung der Editierdistanz von vollständigen Dokumenten durch datenparalleles Rechnen zu beschleunigen muss somit als gescheitert bezeichnet werden. Betrachtet man jedoch statt der absoluten Laufzeiten die relativen Laufzeitunterschiede, so kann zumindest hier mit wachsender Dokumentlänge ein Fortschritt festgestellt werden. Abbildung 4.4 stellt den relativen Performancevorteil der GPU-basierten gegenüber der CPU basierten Implementierung dar. speedup 0,45 0,4 0,35 0,3 0,25 0,2 0,15 0,1 0, total number of characters Abbildung 4.4: relativer Performancevorteil der datenparallelen gegenüber der sequentiellen Levenshtein- Version Der Abbildung lässt sich entnehmen, dass die datenparallele Version zwar stets langsamer bleibt als die sequentielle, der relative Laufzeitunterschied nimmt jedoch bei wachsender Dokumentlänge stetig ab. Je länger die verwendeten Dokumente sind, desto näher kommt die datenparallele Laufzeit an die der sequentiellen Version heran. Diese Beobachtung schließt zumindest nicht aus, dass ein Ein- beziehungsweise Überholen der GPU-Laufzeit an die CPU- Laufzeit bei noch größeren Datenmengen möglich wäre. 5.2 Laufzeitvergleich der wortbasierten Anwendungsvariante Zum Vergleich der datenparallelen Version mit der sequentiellen Version der wortbasierten Levenshtein Anwendung, wurdedas Laufzeitverhalten in zwei unterschiedlichen Testszenarien gemessen. Im ersten Testszenario blieb die Größe der hinterlegten Wortdatenbank konstant bei 3280 Wörtern. Es variierte stattdessen die Zahl der Datenbankabfragen, also die 17

20 Ausführungshäufigkeit der Methode getalldistances(). Das Ergebnis der Messungen ist in Abbildung 4.5 festgehalten time cpu gpu Anzahl der Datenbankabfragen Abbildung 4.5: Laufzeitvergleich der datenparallelen und sequentiellen Version bei einer konstanten Datenbankgröße von 3280 Wörtern Die Grafik zeigt, dass die datenparallele Version bereits ab der vierzigsten Datenbankabfrage schneller arbeitet als die herkömmliche sequentielle Version der Levenshtein Anwendung. Offenbar sind vierzig Ausführungen notwendig, um die einmalig zu Beginn benötigte Datentransferzeit zwischen CPU- und GPU-Speicher aufzuholen. Während sich die Laufzeit der sequentiellen Variante bei einer Verdopplung der Datenbankabfragenfast eins zu eins mit verdoppelt, ist bei der datenparallelen Version ein wesentlich langsamerer Anstieg zu beobachten. Der Performancevorteil der datenparallelen gegenüber der sequentiellen Version bleibt somit nicht konstant, sondern wird mit jeder weiteren Anfrage an die Datenbank größer. Bei insgesamt 640 Datenbankabfragen rechnet die GPU-basierte Version etwa fünf Mal schneller als die herkömmliche Version auf der CPU. (vergleiche Abbildung 4.6) 18

21 6 5 speedup Anzahl der Datenbankabfragen Abbildung 4.6: relativer Performancevorteil der datenparallelen gegenüber der sequentiellen Version der Wortbasierten Levenshtein Anwendung In einem weiteren Testszenario wurde das Laufzeitverhalten beider Versionen bei gleichbleibend 40 bzw. 160 Datenbankabfragen gemessen. Es variierte stattdessen die Größe der hinterlegten Datenbank. Beginnend bei 205 Wörtern in der Datenbank, wurde die Zahl der Wörter in jedem neuen Durchgang verdoppelt, bis schließlich ein Umfang von Wörtern erreicht wurde. Die Ergebnisse der Laufzeitmessungen sind in Tabelle 4.7 festgehalten. db-size 40 queries 160 queries CPUtime GPU-time speedup CPU-time GPU-time speedup , , , , , , , , , , , , Tabelle 4.1: Ergebnisse der Laufzeitmessungen bei Veränderung der Datenbankgröße Bei 40 Datenbankabfragen pro Messung lässt sich bereits bei einer Datenbankgröße von 3280 Wörtern ein minimaler Vorsprung der datenparallelen Version ausmachen. Dieser kann mit jeder 19

22 Vergrößerung der Datenbank weiter ausgebaut werden. Bei Wörtern in der Datenbank ist die datenparallele Version mehr als sechs Mal schneller als die sequentielle Variante. Bei 160 Datenbankabfragen wird der Performancegewinn durch datenparalleles Rechnen (wie auf Grund der obigen Messungen zu erwarten) noch größer. Bis zu 17 Mal schneller als das sequentielle Programm berechnet der GPU-basierte Algorithmus die Editierdistanzen. 20

23 5 Fazit In dieser Arbeit wurde die Editierdistanz als Maß für den approximativen Stringvergleich vorgestellt. Sowohl in der Bioinformatik als auch in der Computerlinguistik finden sich mehrere Einsatzgebiete für die Editierdistanz und den zugehörigen Levenshtein Algorithmus.. Insbesondere zwei unterschiedliche Einsatzmöglichkeiten des Levenshtein-Algorithmus wurden in dieser Arbeit näher skizziert: Dies war zum einen die Berechnung der Editierdistanz sehr langer Zeichensequenzen. Als Anwendungsbeispiel diente hierfür der Vergleich längerer Textdokumente beispielsweise als Mittel zur Plagiatsanalyse. Weiter wurde ein Anwendungsszenario skizziert, bei dem die Editierdistanz sehr häufig hintereinander berechnet wird, jeweils aber nur auf sehr kurzen Zeichensequenzen. Als ein Beispiel aus der Bioinformatik wurde hierfür der Vergleich einer kurzen Gensequenz mit jeder Gensequenz aus einer großen Datenbank genannt. Das Hauptanliegen dieser Arbeit war es, ein Programm zu implementieren, dass die Ausführung beider der skizzierte Anwendungsvarianten des Levenshtein-Algorithmus ermöglicht. Auf Grund der sehr hohen (da quadratischen) Laufzeit des Levenshtein Algorithmus, spielte der Laufzeitfaktor hierbei eine entscheidende Rolle. Neben einer herkömmlichen Java- Implementation des Programms wurde daher auch ein funktionsgleiches Programm in der GPUbasierten Sprache OpenCL implementiert. Hierbei stand die zentrale Fragestellung im Vordergrund, ob die verschiedenen Anwendungen des Levenshtein Algorithmus, durch die zusätzliche Verwendung des Grafikprozessors, in ihrer Laufzeit beschleunigt werden können. Diese Fragestellung konnte in Kapitel 5 dieser Arbeit durch den direkten Laufzeitvergleich beider Programme beantwortet werden. Es konnte herausgestellt werden, dass insbesondere das zweite Anwendungsszenario, bei dem die Editierdistanz sehr häufig auf kurzen Zeichensequenzen berechnet wird, von der GPU- Programmierung profitieren kann. Je nach Größe der hinterlegten Datenbank und der Anzahl der Vergleiche, konnten mit dem GPU-basierten Programm bis zu 17 Mal schnellere Laufzeiten erzielt werden. Eine große Datenbank und hohe Anzahl von Vergleichen stelle sich hierbei als besonders begünstigend für den Performancevorsprung der GPU-basierten Version heraus. Bei kleineren Datensätzen blieb der Vorsprung gering, oder fiel hinter den des herkömmlichen Programms zurück. Zum Vergleich längerer Dokumente stellte sich der Einsatz der GPU-Programmierung als weniger geeignet heraus. Hier konnte keine Testumgebung geschaffen werden, bei der die GPU basierte Version des Levenshtein Algorithmus schneller arbeitete als die herkömmliche CPU- 21

24 basierte Variante. Auch bei längeren Dokumenten blieb die herkömmliche Version mehr als doppelt so schnell wie die OpenCL-Version. Insgesamt zeigte sich aber mit wachsendem Datenumfang eine Tendenz zur Annäherung, da das Laufzeitwachstum der GPU-basierten Version langsamer war, als das der CPU-basierten Version. Als universelle Methode für performanceoptimiertes Rechnen kann die GPU-Programmierung in dem hier untersuchten Kontext zwar nicht bezeichnet werden, unter bestimmten Voraussetzungen, sind jedoch erhebliche Laufzeitverbesserungen möglich und der zusätzliche Mehraufwand durchaus lohnenswert. 22

25 6 Literaturverzeichnis CORMEN, Thomas: 2013, Algorithmen Eine Einführung. 4., durchges. und kommentierte Aufl. Oldenbourg Verlag, München. GUSFIELD, Dan: 1999, Algorithms on strings, trees and sequences.computer science and computational biology. Cambridge University Press, Cambridge. WEGST, Tillmann: Stringähnlichkeit. n.d. Web. 30. Aug