DE102013218594A1

DE102013218594A1 - System, Verfahren und Computerprogrammprodukt zur parallelen Rekonstruktion eines gesampelten Suffixarrays

Info

Publication number: DE102013218594A1
Application number: DE102013218594.4A
Authority: DE
Inventors: Jacopo Pantaleoni
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2012-11-01
Filing date: 2013-09-17
Publication date: 2014-05-08
Also published as: TW201439965A; CN103810228A; US20140123147A1

Abstract

Ein System, Verfahren und Computerprogrammprodukt werden bereitgestellt zum Rekonstruieren eines gesampelten Suffixarrays. Das gesampelte Suffixarray wird rekonstruiert durch, für jeden Index eines gesampelten Suffixarrays für einen String, Berechnen eines dem Index entsprechenden Blockwertes basierend auf einem FM-Index und Rekonstruieren des gesampelten Suffixarrays, das dem String entspricht, basierend auf den Blockwerten. Das Berechnen von mindestens zwei der Blockwerte für mindestens zwei der entsprechenden Indexe des gesampelten Suffixarrays wird parallel durchgeführt.

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf parallele Datenverarbeitung und spezifischer auf List-Ranking-Techniken.
Hintergrund
Ein Suffixarray ist ein sortiertes Array der Suffixe eines Strings. Ein Suffixarray ist eine alternative Datenstruktur zu einem Suffixbaum. Suffixarrays sind nützlich in Algorithmen, die sich auf Volltextsuchen, Bioinformatik und Datenkomprimierung sowie auf andere Anwendungen beziehen. Ein Suffixarray für einen String mag durch Durchführen eines Durchlaufs des entsprechenden Suffixbaums von oben nach unten erzeugt werden. Ein gesampeltes Suffixarray ist ein Array von einer Untermenge der Indexe, die in dem Suffixarray für einen String gespeichert sind.
Konventionelle Algorithmen zum Konstruieren eines gesampelten Suffixarrays sind serialisierter Natur und folglich ist die Anzahl von Zyklen, die zum Konstruieren des gesampelten Suffixarrays benötigt wird, proportional zu der Länge des Strings. Es besteht folglich ein Bedürfnis nach Angehen dieses Problem und/oder anderer mit dem Stand der Technik assoziierten Probleme.
ZUSAMMENFASSUNG
Ein System, Verfahren und Computerprogrammprodukt zum werden bereitgestellt zum Rekonstruieren eines gesampelten Suffixarrays. Das gesampelte Suffixarray wird rekonstruiert durch, für jeden Index eines gesampelten Suffixarrays für einen String, Berechnen eines Blockwertes, der dem Index entspricht, basierend auf einem FM-Index und Rekonstruieren des gesampelten Suffixarrays, das dem String entspricht, basierend auf den Blockwerten. Ein Berechnen mindestens zweier Blockwerte für mindestens zwei entsprechende Indexe des gesampelten Suffixarrays wird parallel durchgeführt.
Kurze Beschreibung der Zeichnungen
Die 1 stelle eine Parallelverarbeitungseinheit dar, gemäß einer Ausführungsform;
Die 2 stellt den Streaming-Multiprozessor von der 1 dar, gemäß einer Ausführungsform;
Die 3 stellt einen FM-Index für einen String T dar, gemäß einer Ausführungsform;
Die 4 stellt ein Suffixarray und ein gesampeltes Suffixarray für den String T von der 3 dar, gemäß einer Ausführungsform;
Die 5 zeigt einen beispielhaften Pseudocode zur seriellen Rekonstruktion des gesampelten Suffixarrays von der 4 basierend auf dem FM-Index von der 3, gemäß einer Ausführungsform;
Die 6 zeigt einen beispielhaften Pseudocode zur parallelen Rekonstruktion des gesampelten Suffixarrays von der 4 basierend auf dem FM-Index von der 3, gemäß einer Ausführungsform;
Die 7 stellt ein Flussdiagramm von einem Verfahren zur Rekonstruktion des gesampelten Suffixarrays dar, gemäß einer Ausführungsform;
Die 8 stellt ein Flussdiagramm von einem Verfahren zur Rekonstruktion des gesampelten Suffixarrays dar, gemäß einer weiteren Ausführungsform.
Die 9 stellt ein beispielhaftes System dar, in welchem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorhergehenden Ausführungsformen implementiert sein mögen.
Detaillierte Beschreibung
Die 1 stellt eine Parallelverarbeitungseinheit (PPU) 100 dar, gemäß einer Ausführungsform. Während ein Parallelprozessor hierin als ein Beispiel für die PPU 100 bereitgestellt ist, sollte es deutlich beachtet werden, dass ein solcher Prozessor nur zu illustrativen Zwecken dargelegt ist und dass jeder Prozessor eingesetzt werden mag, um ihn zu ergänzen oder ersetzen. In einer Ausführungsform ist die PPU 100 konfiguriert zum Ausführen einer Mehrzahl von Threads in zwei oder mehr Streaming-Multiprozessoren (SMs) 150. Ein Thread (das heißt, ein Thread von Ausführung) ist eine Instanziierung von einem Satz von Instruktionen, der innerhalb eines bestimmten SM 150 ausgeführt wird. Jeder SM 150 wird unten in Verbindung mit der 2 detaillierter beschreiben und mag, ohne darauf beschränkt zu sein, einen oder mehrere Verarbeitungskerne, eine oder mehrere Lade/Speicher-Einheiten (LSUs), einen Level-eins-(L1)-Cache, gemeinsam genutzten Speicher und ähnliches enthalten.
In einer Ausführungsform weist die PPU 100 eine Input/Output-(I/O)-Einheit 105 auf, die zum Senden und Empfangen von Kommunikationen (das heißt Befehle, Daten etc.) von einer (nicht gezeigten) zentralen Verarbeitungseinheit (CPU) über den Systembus 102 konfiguriert ist. Die I/O-Einheit 105 mag eine Peripheral Component Interconnect Express (PCIe) Schnittstelle für Kommunikationen über einen PCIe-Bus implementieren. In alternativen Ausführungsformen mag die I/O-Einheit 105 andere Typen von wohl bekannten Busschnittstellen implementieren.
Die PPU 100 weist auch eine Hostschnittstelleeinheit 110 auf, die die Befehle dekodiert und die Befehle an die Gittermanagementeinheit 115 oder an andere Einheiten der PPU 100 (zum Beispiel Speicherschnittstelle 180) sendet, wie es die Befehle spezifizieren mögen. Die Hostschnittstelleeinheit 110 ist dazu konfiguriert, Kommunikationen zwischen und unter den verschiedenen logischen Einheiten der PPU zu routen.
In einer Ausführungsform wird ein Programm, das als ein Befehlsstrom enkodiert ist, von der CPU zu einem Puffer geschrieben. Der Puffer ist ein Bereich (bzw. eine Region) im Speicher, zum Beispiel dem Speicher 104 oder Systemspeicher, auf den sowohl die CPU als auch die PPU 100 zugreifen (das heißt lesen/schreiben) können. Die CPU schreibt den Befehlsstrom zu dem Puffer und sendet dann einen Zeiger, der auf den Anfang des Befehlsstroms zeigt, an die PPU 100. Die Hostschnittstelleeinheit 110 stellt der Gittermanagementeinheit (GMU) 115 Zeigern bereit, die auf einen oder mehrere Ströme zeigen. Die GMU 115 wählt einen oder mehrere Ströme aus und ist konfiguriert zum Organisieren der ausgewählten Ströme als ein Pool von anstehenden Gittern. Das Pool von anstehenden Gittern mag neue Gitter, die noch nicht zum Ausführen ausgewählt worden sind, und Gitter, die zum Teil ausgeführt und unterbrochen worden sind, enthalten.
Eine Arbeitsverteilungseinheit 120, die zwischen der GPU 115 und den SMs 150 gekoppelt ist, managt ein Pool von aktiven Gittern, wobei sie aktive Gitter zur Ausführung von den SMs 150 auswählt und versendet. Anstehende Gitter werden von der GMU zu dem Pool aktiver Gitter überführt, wenn ein Gitter zur Ausführung auswählbar ist, das heißt keine ungeklärte Datenabhängigkeiten hat. Ein aktives Gitter wird an das anstehende Pool übertragen, wenn die Ausführung des aktiven Gitters von einer Abhängigkeit blockiert wird. Wenn die Ausführung eines Gitters abgeschlossen ist, wird das Gitter aus dem aktiven Gitterpool von der Arbeitsverteilungseinheit 120 entfern. Zusätzlich zum Empfangen von Gittern von der Hostschnittstelleeinheit 110 und der Arbeitsverteilungseinheit 120 empfängt die GMU 110 auch Gitter, die von den SMs 150 während Ausführung eines Gitters dynamisch erzeugt werden. Diese dynamisch erzeugten Gitter schließen sich den anderen anstehenden Gittern in dem anstehenden Gitterpool an.
In einer Ausführungsform führt die CPU einen Treiberkernel aus, der eine Anwendungsprogrammierschnittstelle (API) implementiert, die es erlaubt bzw. ermöglicht, dass eine oder mehrere Anwendungen, die auf der CPU ausgeführt werden, Operationen zur Ausführung auf der PPU 100 zeitlich planen (engl. „schedule”). Eine Anwendung mag Instruktionen (zum Beispiel API-Aufrufe) enthalten, die bewirken, dass der Treiberkernel ein oder mehrere Gitter zur Ausführung erzeugt. In einer Ausführungsform implementiert die PPU 100 eine SIMD-(Einzelne-Instruktion, Mehrere-Daten)-Architektur, wobei jeder Threadblock (das heißt Warp) in einem Gitter gleichzeitig auf einem unterschiedlichen Datensatz von unterschiedlichen Threads in dem Threadblock ausgeführt wird. Der Treiberkernel definiert Threadblöcke, die aus k verwandten Threads bestehen, so dass Threads in dem gleichen Threadblock Daten durch gemeinsam genutzten Speicher austauschen mögen. In einer Ausführungsform weist ein Threadblock 32 verwandte Threads auf, und ein Gitter ist eine Array von einem oder mehreren Threadblöcken, die den gleichen Strohm ausführen, und die verschiedenen Threadblöcke mögen Daten durch globalen Speicher austauschen.
In einer Ausführungsform weist die PPU 100 X SMs 150(X) auf. Die PPU 100 mag zum Beispiel 15 distinkte SMs 150 aufweisen. Jeder SM 150 ist multi-threaded und dazu konfiguriert, eine Mehrzahl von Threads (zum Beispiel 32 Threads) aus einem bestimmten Threadblock gleichzeitig auszuführen. Jeder der SMs 150 ist über eine Kreuzschiene 160 (oder eine andere Art von Verbindungsnetzwerk) mit einem Level-Zwei-(L2)-Cache 165 verbunden. Die 12-Cache 165 ist mit einer oder mehreren Speicherschnittstellen 180 verbunden. Die Speicherschnittstellen 180 implementieren 16, 32, 64, 128-Bit Datenbusse oder ähnliches für Hochgeschwindigkeitsdatenübertragung. In einer Ausführungsform weist die PPU 100 U Speicherschnittstellen 180(U) auf, wobei jede Speicherschnittstelle 180(U) mit einer entsprechenden Speichervorrichtung 104(U) verbunden ist. Die PPU 100 mag zum Beispiel mit bis zu 6 Speichervorrichtungen 104 verbunden sein, wie zum Beispiel grafikdoppeldatenrate (engl. „graphichs double-data-rate”), Version 5, synchrone dynamische frei adressierbarer Speicher (GDDR5 SDRAM).
In einer Ausführungsform implementiert die PPU 100 eine Mehrlevel-Speicherhierarchie. Der Speicher 104 befindet sich chipextern in SDRAM, der an die PPU 100 gekoppelt ist. Daten von dem Speicher 104 mögen abgerufen und in dem 12-Cache 165 gespeichert werden, der sich chipintern befindet und von den verschiedenen SMs 150 gemeinsam genutzt wird. In einer Ausführungsform implementiert jeder der SMs 150 auch einen L1-Cache. Der L1-Cache ist privater Speicher, der zu einem bestimmten SM 150 dediziert ist. Jeder der L1-Caches ist mit dem gemeinsam genutzten L2-Caache 165 gekoppelt. Daten von dem L2-Cache mögen abgerufen und in jedem der L1-Caches zur Verarbeitung in den funktionellen Einheiten der SMs 150 gespeichert werden.
In eine Ausführungsform weist die PPU 100 eine Grafikverarbeitungseinheit (GPU) auf. Die PPU 100 ist dazu konfiguriert, Befehle zu erhalten, die Shaderprogramme zur Verarbeitung von Grafikdaten spezifizieren. Grafikdaten mögen als ein Satz von Primitiven definiert sein, wie zum Beispiel Punkten, Linien, Dreiecken, Vierecken, Dreieckstreifen und ähnliches. Eine Primitive enthält typisch Daten, die eine Anzahl von Vertices für die Primitive (zum Beispiel in einem Modellraumkoordinatensystem) spezifizieren, sowie Attributen, die mit jedem Vertex der Primitive assoziiert sind. Die PPU 100 kann dazu konfiguriert sein, die Grafikprimitive zu verarbeiten, um einen Framepuffer (das heißt Pixeldaten für jedes der Pixel des Displays) zu erzeugen. Der Treiberkernel implementiert eine Grafikverarbeitungspipeline, wie zum Beispiel die von der OpenGL API definierte Grafikverarbeitungspipeline.
Eine Anwendung schreibt Modelldaten für eine Szene (das heißt, eine Sammlung von Vertices und Attributen) zum Speicher. Die Modelldaten definieren jedes der Objekte, das auf einem Display sichtbar sein mag. Die Anwendung macht dann einen Aufruf zu dem Treiberkernel, welcher Aufruf anfordert, dass die Modelldaten gerendert und angezeigt werden. Der Treiberkernel liest die Modelldaten und schreibt Befehle an den Puffer, um eine oder mehrere Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle mögen verschiedenen Shaderprogramme enkodieren, inklusive eines oder mehreren von einem Vertex-Shader, einem Hull-Shader, einem Geometrie-Shader, einem Pixel-Shader etc. Die GPU 115 mag zum Beispiel einen oder mehrere SMs 150 dazu konfigurieren, ein Vertex-Shaderprogramm auszuführen, das eine Anzahl von Vertices verarbeitet, die von den Modelldaten definiert sind. In einer Ausführungsform mag die GMU 115 verschiedene SMs 150 dazu konfigurieren, verschiedene Shaderprogramme gleichzeitig auszuführen. Zum Beispiel mag eine erste Untergruppe von SMs 150 zum Ausführen eines Vertex-Shaderprogramms konfiguriert sein, während eine zweite Untergruppe von SMs 150 zum Ausführen eines Pixel-Shaderprogramms konfiguriert sein mag. Die erste Untergruppe von SMs 150 verarbeitet Vertexdaten, um verarbeitete Vertexdaten zu erzeugen, und schreibt die verarbeiteten Vertexdaten zu dem L2-Cache 165 und/oder Speicher 104. Nachdem die verarbeiteten Vertexdaten gerastert (das heißt, aus dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum transformiert) sind, um Fragmentdaten zu erzeugen, für die zweite Untergruppe von SMs 150 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten vermischt und zu dem Framepuffer im Speicher 104 geschrieben werden. Das Vertex-Shaderprogramm und das Pixel-Shaderprogramm mögen gleichzeitig ausgeführt werden, wobei sie verschiedene Daten aus der gleichen Szene in einer gepipelinten Weise verarbeiten, bis alle Modelldaten für die Szene zu dem Framepuffer gerendert worden sind. Dann werden die Inhalte des Framepuffers an eine Anzeigesteuerung übermittelt, um auf einer Anzeigevorrichtung angezeigt zu werden.
Die PPU 100 mag in einem Desktopcomputer, einem Laptopcomputer, einem Tabletcomputer, einem Smartphone (zum Beispiel eine drahtlose Handgerät), einem persönlichen digitalen Assistenten (PDA), einer digitalen Kamera, einer elektronischen Handgerät und ähnliches inkludiert sein. In einer Ausführungsform ist die PPU 100 auf einem einzigen Halbleitersubstrat verkörpert. In einer weiteren Ausführungsform ist die PPU 100 in einem System auf einem Chip (SoC) zusammen mit einer oder mehreren anderen logischen Einheiten inkludiert, wie zum Beispiel einer CPU eines Rechners mit reduziertem Befehlssatz (RISC), einer Speichermanagementeinheit (MMU), einem Digital-Analog-Wandler (DAC) und ähnliches.
In einer Ausführungsform mag die PPU 100 auf einer Grafikkarte inkludiert sein, die eine oder mehrere Speicherschnittstellen 104 aufweise, wie zum Beispiel GDDR5 SDRAM. Die Grafikkarte mag zum Verbinden mit einem PCIe-Slot auf einer Hauptplatine eines Desktopcomputers konfiguriert sein, die zum Beispiel einen Northbridge-Chipsatz und einen Southbridge-Chipsatz aufweist. In einer noch weiteren Ausführungsform mag die PPU 100 eine integrierte Grafikverarbeitungseinheit (iGPU) sein, die in dem Chipsatz (zum Beispiel Northbridge) der Hauptplatine inkludiert ist.
Die 2 stellt den Streaming-Multiprozessor 150 von 1 dar, gemäß einer Ausführungsform. Wie es in der 2 gezeigt ist, weist der SM 150 einen Instruktionscache 205, eine oder mehrere Schedulereinheiten 210, eine Registerdatei 220, einen oder mehrere Verarbeitungskerne 250, eine oder mehrere Doppelpräzisionseinheiten (DPUs) 251, eine oder mehrere Spezialfunktionseinheiten (SFUs) 252, eine oder mehrere Lade/Speicher-Einheiten (LSUs) 253, ein Verbindungsnetzwerk 280, einen gemeinsam genutzten Speicher/L1-Cache 270 und eine oder mehrere Textureinheiten 290 auf.
Die Arbeitsverteilungseinheit 120 versendet, wie oben beschrieben, aktive Gitter zur Ausführung auf einem oder mehreren SMs 150 der PPU 100. Die Schedulereinheit 210 empfängt die Gitter von der Arbeitsverteilungseinheit 120 und managt Instruktions-Scheduling für einen oder mehrere Threadblöcke von aktiven Gittern. Die Schedulereinheit 210 plant zeitlich die Ausführung von Threads in Gruppen mit parallelen Threads, wobei jede Gruppe ein Warp benannt ist. In einer Ausführungsform weist jeder Warp 32 Threads auf. Die Schedulereinheit 210 mag eine Mehrzahl von unterschiedlichen Threadblöcken managen, wobei sie die Threadblöcke zu Warps zur Ausführung allokieren und dann Instruktionen von der Mehrzahl von verschiedenen Warps auf den verschiedenen funktionellen Einheiten (das heißt Kerne 250, DPUs 251, SFUs 252 und LUSs 253) während jedes Taktzyklus zeitlich festlegen.
In einer Ausführungsform weist jede Schedulereinheit 210 eine oder mehrere Instruktionsversandeinheiten 215 auf. Jede Versandeinheit 215 ist dazu konfiguriert, Instruktionen an eine oder mehrere von den funktionellen Einheiten zu übermitteln. In der in der 2 gezeigten Ausführungsform weist die Schedulereinheit 210 zwei Versandeinheiten 215 auf, die ermöglichen, dass zwei verschiedene Instruktionen von dem gleichen Warp während jedes Taktzyklus versendet werden. In alternativen Ausführungsformen mag jede Schedulereinheit 210 eine einzige Versandeinheit 215 oder zusätzliche Versandeinheiten 215 aufweisen.
Jeder SM 150 weist eine Registerdatei 220 auf, die einen Satz von Registern für die funktionellen Einheiten der SM 150 bereitstellt. In einer Ausführungsform ist die Registerdatei 220 zwischen jede der funktionellen Einheiten geteilt, so dass jeder funktionellen Einheit einen dedizierten Abschnitt der Registerdatei 220 allokiert ist. In einer weiteren Ausführungsform ist die Registerdatei 220 zwischen den verschiedenen Warps geteilt, die von dem SM 150 ausgeführt werden. Die Registerdatei 220 stellt temporärer Speicher für Operanden bereit, die mit den Datenpfaden der funktionellen Einheiten verbunden sind.
Jeder SM 150 weist L Verarbeitungskerne 250 auf. In einer Ausführungsform enthält der SM 150 eine große Anzahl (zum Beispiel 192 etc.) distinkter Verarbeitungskerne 250. Jeder Kern 250 ist eine vollständig gepipelinete Verarbeitungseinheit einfacher Präzision, die eine Gleitkomma-arithmetische-logische-Einheit und eine Ganzzahl-arithmetische-logische-Einheit enthält. In einer Ausführungsform implementiert die Gleitkomma-arithmetische-logische-Einheiten den IEEE 754-2008 Standard für Gleitkommaarithmetik. Jeder SM 150 enthält auch M DPUs 251, die Doppelpräzision-Gleitkommaarithmetik implementieren, N SFUs 252, die spezielle Funktionen (zum Beispiel Rechteckkopierung, Pixelmischoperationen und ähnliches) ausführen, und P LSUs 253, die Lade- und Speicheroperationen zwischen dem gemeinsam genutzten Speicher/L1-Cache 270 und der Registerdatei 220 implementieren. In einer Ausführungsform enthält der SM 150 64 DPUs 251, 32 SFUs 252 und 32 LSUs 253.
Jeder SM 150 enthält ein Verbindungsnetzwerk 280, das jede der funktionellen Einheiten mit der Registerdatei 220 und dem gemeinsam genutzten Speicher/L1-Cache 270 verbindet. In einer Ausführungsform ist das Verbindungsnetzwerk 280 eine Kreuzschiene, die dazu konfiguriert werden kann, irgendeine der funktionellen Einheiten mit irgendeinem der Register in der Registerdatei 220 oder mit irgendeiner der Speicherstellen im gemeinsam genutzten Speicher/L1-Cahce 270 zu verbinden.
In einer Ausführungsform ist der SM 150 innerhalb einer GPU implementiert. In einer solchen Ausführungsform weist der SM 150 J Textureinheiten 290 auf. Die Textureinheiten 290 sind dazu konfiguriert, Texturabbildungen (engl. „texture maps”) (das heißt ein 2D-Array von Texeln) aus dem Speicher 104 zu laden und die Texturabbildungen zu sampeln, um gesampelte Texturwerte zur Verwendung in Shaderprogrammen zu erzeugen. Die Textureinheiten 290 implementieren Texturoperationen, wie zum Beispiel Anti-Aliasing Operationen, die Mip-Maps (das heißt Texturabbildungen von variierendem Detaillierungsgrad). In einer Ausführungsform enthält der SM 150 16 Textureinheiten 290.
Die oben beschriebene PPU 100 mag dazu konfiguriert sein, hochparallele Berechnungen viel schneller als konventionelle CPUs durchzuführen. Parallele Datenverarbeitung hat Vorteile bei Grafikverarbeitung, Datenkomprimierung, Biometrik, Stream-Verarbeitungsalgorithmen und ähnliches.
Illustrativere Information in Bezug auf verschiedene optionale Architekturen und Merkmale wird jetzt dargelegt werden, mit denen das vorhergehende Framework, gemäß den Wünschen des Benutzers, implementiert oder nicht implementiert werden mag. Es sollte ausdrücklich beachtet werden, dass die nachfolgende Information zu illustrativen Zwecken dargelegt wird und nicht als in irgendeiner Weise beschränkend erfasst werden sollte. Jedes von den nachfolgenden Merkmalen mag optional mit der oder ohne die Ausschließung anderer beschriebenen Merkmale aufgenommen werden.
Die 3 stellt einen FM-Index 300 für einen String T 305 dar, gemäß einer Ausführungsform. Ein FM-Index (das heißt ein Volltextindex im kleinen Raum (engl. „Full-text index in Minute space”)) ist ein komprimiertes Volltext-Substringindex, das auf der Burrows-Wheeler-Transformation (BWT) des Strings basiert. Wie in der 3 gezeigt, weist das FM-Index 300 eine BWT von dem String, T* 310, einen Vektor L2[a_i] 320 und eine Vorkommnissentabelle (engl. „occurrences table”) O_cc[c, i] 330 auf.
Für einen gegebenen String T 305 enthält der BWT-String T* 310 eine lexikografisch-sortierte Permutation der Suffixe des Strings 305. Der String T 305 ist zum Beispiel, wie in der 3 gezeigt, als „THEPATENTOFFICE$” gegeben, wobei das spezielle Zeichen „$” ein EOF-(Ende der Datei)-Zeichen repräsentiert. Der entsprechende BWT-String T* 310 ist als „EPICTHOFTFETEA$N” gegeben. Der BWT-String t* 310 mag durch Erstellen einer Tabelle, wobei jede Zeile der Tabellen eine Rotation des Strings T 305 ist, erzeugt werden. Die Zeilen der Tabelle werden dann in fallender lexikografischer Reihenfolge sortiert. Mit anderen Worten ist Zeile[i] weniger als Zeile [i + 1]. Die Zeichen in der letzten Zeile der sortierten Tabelle weisen den BWT-String T* 310 auf.
Für einen String T 305, der ein Alphabet A hat, das der Satz von Zeichen {a₀, a₁, ..., a_b} aufweist, spezifiziert der Vektor L2[a_i] 320 die summierte Häufigkeit aller Zeichen in dem String T 305, die einen geringeren Wert hat als das Zeichen a_i. Zum Beispiel hat der String T 305, wie in der 3 gezeigt, ein Alphabet A, das der Satz von Zeichen {„A”, „C”, „E”, „F”, „H”, „I”, „N”, „O”, „P”, „T”} aufweist (das spezielle Zeichen „$” ist weggelassen). Mit diesem gegebenen Alphabet A für den String T 305 zeigt die 3, dass L2[0] gleich null ist, L2[1] gleich eins ist, L2[2] gleich zwei ist und so weiter. Mit anderen Worten indiziert L2[0], dass die Häufigkeit von Zeichen im String T 305, die einen Wert haben, der geringer als „A” ist (das heißt A[0]) gleich null ist, die Häufigkeit von Zeichen im String T 305, die einen Wert haben, der geringer als „C” (das heißt A[1]) gleich eins ist (das heißt, es gibt ein „A”-Zeichen), die Häufigkeit von Zeichen im String T 305, die einen Wert haben, der geringer als „E” (das heißt A[2]) gleich zwei ist (das heißt, es gibt ein „A”-Zeichen und ein „C”-Zeichen) und so weiter.
Für einen String T 305, der das Alphabet A hat, das den Satz von Zeichen {a₀, a₁, ..., a_b} aufweist, definiert die Vorkommnissentabelle O_cc[c, i] 330 ein zweidimensionales (2D) Array, das die Anzahl der Vorkommnisse des Zeichens c in dem Substring des BWT-Substrings T*[0, i] spezifiziert. Mit anderen Worten ist, für jedes Zeichen c im Alphabet A, die Zeile O_cc[c, i] einen Vektor, der die Anzahl von Vorkommnissen des Zeichens c in dem BWT-Substring T*[0, i] des BWT-Strings T* 310 repräsentiert. Wie in der 3 gezeigt, inkludiert die Vorkommnissentabelle O_cc[c, i] 330 16 Spalten und 10 Zeilen, jeweils entsprechend der Länge des BWT-Strings T* 310 von 16 Zeichen und den 10 distinkten Zeichen, die den BWT-String T* 310 aufweist. Eine erste Zeile des Vorkommnissentabelle O_cc[c, i] 330 entspricht dem Zeichen „A” (das heißt A[0]) und zeigt die Werte {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1}, die indizierten, dass das 14. Zeichen des BWT-Strings T* 310 (das heißt T*[13]) „A” ist.
In einer Ausführungsform ist der FM-Index 300 komprimiert. Der BWT-String T* 310, der Vektor L2[a_i] 320 und die Vorkommnissentabelle O_cc[c, i] 330 sind zum Beispiel gemäß einem Komprimierungsschema, wie zum Beispiel einem Lauflänge-Enkodierung oder einem Huffman-Enkodierung enkodiert. In einer Ausführungsform ist O_cc[c, i] 330 als eine Texturabbildung enkodiert, die unter Verwendung von Techniken, die den Fachleuten bekannt sind, komprimiert werden mag. In solchen Ausführungsformen werden der BWT-String T* 310, der Vektor L2[a_i] 320 und die Vorkommnissentabelle O_cc[ci] zumindest teilweise dekomprimiert, um einen Wert aus dem FM-Index 300 auszulesen.
Die 4 stellt ein Suffixarray 400 und ein gesampeltes Suffixarray 410 für den String T 305 der 3 dar, gemäß einer Ausführungsform. Das Suffixarray (SA) 400 ist ein Vektor von Indexen, die den Suffixen des Strings T 305 entsprechen. Zum Beispiel ist, wie in der 4 gezeigt, SA[0] 401 gleich 15, entsprechend der Position des Suffixes, der mit dem speziellen Zeichen „$” beginnt, das lexikografisch das Zeichen mit dem geringsten Wert im String T 305 ist. In ähnlicher Weise ist SA[1] 402 gleich 4, entsprechend der Position des Suffixes, der mit dem Zeichen „A” beginnt (das heißt „ATENTOFFICE$”), SA[2] 403 ist gleich 13, entsprechend der Position des Suffixes, der mit dem Zeichen „C” beginnt (das heißt „CE$”), und so weiter. Das Suffixarray 400 gruppiert ähnliche Suffixe zusammen, um sich wiederholende Substrings innerhalb des Textes des Strings T 305 einfach zu identifizieren.
In der 4 wird auch das gesampelte Suffixarray (SSA) 410 gezeigt, das einer Untermenge des ganzen Suffixarrays 400 entspricht. In einer Ausführungsform weist das gesampelte Suffixarray 410 jeden k-ten Eintrag des Suffixarrays 400 auf. Mit anderen Worten ist SSA[m] gleich SA[m*K]. Zum Beispiel ist, wie in der 4 gezeigt, SSA[0] 411 gleich 15, entsprechend der Position des Suffixes, der mit dem speziellen Zeichen „$” beginnt, SSA[1] 412 ist gleich 14, entsprechend der Position des Suffixes, der mit dem Zeichen „E” beginnt, SSA[2] 413 ist gleich 10, entsprechend der Position des Suffixes, der mit dem Zeichen „F” beginnt, und so weiter.
Die 5 zeigt ein Beispiel von Pseudocode 500 für serielle Rekonstruktion des gesampelten Suffixarrays 410 von 4 basierend auf dem FM-Index 300 von 3, gemäß einer Ausführungsform. Das gesampelte Suffixarray 410 kann insbesondere aus dem BWT-String T* 310, dem Vektor L2[a_i] 320 und der Vorkommnissentabelle O_cc[c, i] 330 rekonstruiert werden. Wie in dem Pseudocode 500 gezeigt, wird eine erste Variable, isa 501, auf null initialisiert und eine zweite Variable, sa 502, wird initialisiert, um gleich der Anzahl von Zeichen in dem String T 305 zu sein, exklusive des speziellen Zeichens (zum Beispiel 15).
Eine For-Schleife wird dazu initialisiert, einmal für jedes Zeichen in dem String T 305 zu laufen (zum Beispiel 15 Iterationen). Während jeder Iteration der For-Schleife, wird die Variable isa 501 geprüft, um festzustellen, ob der Wert von isa 501 ein ganzzahliges Vielfaches von K ist (das heißt, „isa % K 0”), wobei K die Samplefrequenz des SSA 410 darstellt. Wenn der Wert von isa 501 ein ganzzahliges Vielfaches von K ist, dann wird der Wert von SSA[isa/K] gleich dem Wert der Variable sa 502 gesetzt. Mit anderen Worten, wenn der Wert von isa 501 ein ganzzahliges Vielfaches von K ist, dann wiedergibt der Wert von sa 502 einen von den im SSA 410 gespeicherten Indexen. Wenn aber der Wert von isa 501 kein ganzzahliges Vielfaches von K ist, dann wird der Wert von sa 502 nicht im SSA 410 gespeichert. Nachdem die Variable isa 501 geprüft ist, wird der Wert von sa 502 mit eins dekrementiert (das heißt „--sa;”) und der Wert von isa 501 wird gleich der Ausgabe einer deterministischen Funktion 505 von isa 501 gesetzt.
Die deterministische Funktion 505 addiert den Wert des Vektors L2[a_i] zu dem Wert der Vorkommnissentabelle O_cc[a_i, isa], wobei a_i das Zeichen an der isa-ten Position des BWT-Strings T* 310 ist (das heißt T*[isa]). Die deterministische Funktion 505 von isa 501 mappt jeden Index in der BWT-String T* 310 auf einen entsprechenden Index in der BWT-String T* 310, der mit dem unmittelbar vorhergehenden Zeichen im String T 305 assoziiert ist.
Die For-Schleife iteriert während sa auf null abnimmt, wobei ein Index zu dem SSA 410 immer dann hinzugefügt wird, wenn der Wert von isa 501 ein ganzzahliges Vielfaches von K ist. Für extrem lange Textstrings mag der serialisierte Rekonstruktionsalgorithmus viel Zeit in Anspruch nehmen, um ausgeführt zu werden, weil die Funktion O(n) Zeit braucht, da der Wert des Variable isa 501 abhängig von dem Wert des Variable isa 501 während der vorhergehenden Iteration ist. Für lange Textstrings könnte ein paralleler Algorithmus zum Rekonstruieren des SSA 410 folglich die Verarbeitungszeit reduzieren.
Die 6 zeigt ein Beispiel von Pseudocode 600 für parallele Rekonstruktion von dem gesampelten Suffixarray 410 von 4 basierend auf dem FM-Index 300 von 3, gemäß einer Ausführungsform. Es wird für einen Fachmann offensichtlich sein, dass der serialisierte Algorithmus, der vom Pseudocode 500 dargelegt ist, eine verallgemeinerte List-Ranking-Operation ist, in der die Knoten in der Liste Positionen sind, die von der Variable isa 501 definiert sind. Es wird auch für einen Fachmann offenkundig sein, dass nur die Werte von isa 501, die ein ganzzahliges Vielfaches von K sind, für das Rekonstruieren des SSA 410 von jeglicher Interesses sind, wobei der Wert, der von der Variable sa 502 zu subtrahieren ist, gleich der Anzahl von Iterationen (das Heißt Schritten) ist, die zwischen Iterationen durchgeführt werden, wo der Wert von isa 501 ganzzahlige Vielfache von K ist. Mit anderen Worten kann die von dem seriellen Algorithmus erzeugte Liste-Datenstruktur, in kleinere Blöcke geteilt werden, die bei Indices von der Listenstruktur beginnen, die ganzzahlige Vielfache von K sind. Jeder der Blöcke kann parallel verarbeitet werden, um die Anzahl von Schritten zwischen aufeinanderfolgenden ganzzahligen Vielfachen von K zu bestimmen.
Wie in der 6 gezeigt, ist der parallele Rekonstruktionsalgorithmus in einer ersten Stufe 601 und einer zweiten Stufe 602 geteilt. In der ersten Stufe 601 wird ein Blockwert 611 für jeden Index m berechnet. Der Index m nimmt jeden ganzzahligen Wert im Bereich von null bis der Länge von SSA 410 an (das heißt, m ist in [0, n/K]). Die erste Stufe 601 initialisiert eine Do-While-Schleife 620, die für eine Anzahl von Schritten 613 (das heißt Iterationen) ausgeführt wird, während die Variable isa 501 kein ganzzahliges Vielfaches von K ist (das heißt, Iteration wird gestoppt, wenn die Variable isa 501 ein ganzzahliges Vielfaches von K ist). Der Blockwert 611 für den Index m 612 ist gleich der Anzahl von Schritten 613 gesetzt, die in der Do-While-Schleife 620 abgeschlossen wurden, bis die Variable isa 501 gleich einem ganzzahligen Vielfaches von K gesetzt wurde. Ein Block-Link 614 wird gleich dem Wert der Variable isa 501 dividiert durch K gesetzt (das heißt, das ganzzahlige Vielfaches multipliziert mit dem entsprechenden Wert von isa 501). Die erste Stufe 601 wird für mindestens zwei Werte des Indexes m 612 parallel (das heißt zumindest teilweise gleichzeitig) ausgeführt.
Es wird verstanden werden, dass die erste Stufe 601 die Anzahl der Schritte 613 zwischen einem bestimmten Index m 612 und dem nächsten Wert von isa 501, der ein ganzzahliges Vielfaches von K ist, bestimmt. Der Blockwert 611 kann unabhängig für jeden Index m 612 berechnet werden und folglich kann die erste Stufe 601 den Vorteil aus parallelen Computerarchitekturen ziehen, um die Verarbeitung zu beschleunigen. In einer Ausführungsform mag die erste Stufe 601 in einem Shaderprogramm verkörpert sein, das auf der PPU 100 von 1 ausgeführt wird. Eine Anwendung mag ein Shaderprogramm definieren, das eine Mehrzahl von Indexwerten (zum Beispiel Indices m 612) verarbeiten soll. Der Treiberkernel sendet einen Task an die PPU 100, die einen oder mehrere SMs 150 konfiguriert, um das Shaderprogramm für verschiedene Werte des Indexes m 612 gleichzeitig auszuführen.
Die zweite Stufe 602 ist eine serielle Schleif von vielmehr leichteren Gewicht zum Konstruieren des SSA 410 unter Verwendung der berechneten Blockwerte 611 und Blocklinks 614. Statt durch jeden Wert von der Variable sa 502 zu iterieren, führt die zweite Stufe nur eine Iteration für jeden Index m 612 durch. Es wird verstanden werden, dass wenn K groß ist, dann wird die zweite Stufe 602 die Anzahl von Iterationen in der zweiten Stufe 602 gegenüber dem seriellen Rekonstruktionsalgorithmus, der im Pseudocode 500 dargestellt ist, erheblich reduzieren.
In einer weiteren Ausführungsform mag die zweite Stufe 602 auch parallelisiert werden durch Applizieren von jeglichen wohl bekannten List-Ranking-Techniken, wie zum Beispiel der Wyllie-Algorithmus, der in Wyllie, J. C. (1979), "The Complexity of Parallel Computation," Ph. D. thesis, Department of Computer Science, Cornell University beschrieben ist, oder der Anderson-Miller-Algorithmus, der in Anderson, Richard J.; Miller, Gary L. (1990), "A simple randomized parallel algorithm for list-ranking", Information Processing Letters 33, pp. 269–273, doi: 10.1016/0020-0190(90)90196-5 beschrieben ist, die jeweils durch Bezugnahme in seiner Gesamtheit hierin inkorporiert werden.
Der vom Pseudocode 600 dargestellte parallele Rekonstruktionsalgorithmus könnte nach alternativen Repräsentationen des SSA 410 erweitert werden. In einer Ausführungsform könnte das SSA 410 die Werte der Variable isa 501 statt der Werte der Variable sa 502 enkodieren.
Die 7 stellt ein Flussdiagramm von einem Verfahren 700 zum Rekonstruieren des SSA 410 dar, gemäß einer Ausführungsform. Bei Schritt 702 berechnet die PPU 100, für jeden Index des SSA 410, einen Blockwert 611, der dem Index m 612 entspricht. Die Blockwerte werden in einer ersten Stufe 601 von einer parallelen Rekonstruktionsalgorithmus berechnet. Bei Schritt 704 erzeugt die PPU 100 das SSA 410 basierend auf den während des Schrittes 702 berechneten Blockwerten. In einer Ausführungsform wird das SSA 410 dadurch erzeugt, dass eine serielle Schleife initialisiert wird und jeder Blockwert einem Index des SSA 410 zugeordnet wird. In einer weiteren Ausführungsform mag das SSA 410 unter Verwendung von wohl bekannten parallelen List-Ranking-Algorithmen erzeugt werden.
Die 8 stellt ein Flussdiagramm von einem Verfahren 800 zum Rekonstruieren des gesampelten Suffixarrays 410 dar, gemäß einer weiteren Ausführungsform. Bei Schritt 802 ist die PPU 100 konfiguriert zum Ausführen eines Shaderprogramms zum Berechnen der Blockwerte 611, die den Indices des SSA 410 entsprechen. Das Shaderprogramm implementiert die erste Stufe 601 des parallelen Rekonstruktionsalgorithmus. Mindestens ein SM 150 ist zum Ausführen des Shaderprogramms konfiguriert. Bei Schritt 804 erzeugt die PPU 100 einen Threadblock, der mit dem Shaderprogramm assoziiert ist. Jeder Thread von dem Threadblock entspricht einem unterschiedlichen Index m 612 von dem SSA 410. Bei Schritt 806 führt die PPU 100 den Threadblock aus, um einen Blockwert 611 für jeden Thread zu berechnen, der dem Index m 612 entspricht. Es wird verstanden werden, dass mehrere Threadblöcke erzeugt und ausgeführt werden mögen, wenn die Anzahl der Indices von dem SSA 410 größer ist als eine maximale Anzahl von Threads in einem Threadblock.
Bei Schritt 808 ist die PPU 100 konfiguriert zum Ausführen eines zweiten Shaderprogramms, um das SSA 410 zu erzeugen. Das zweite Shaderprogramm implementiert die zweite Stufe 602 des parallelen Rekonstruktionsalgorithmus. Mindestens ein SM 150 ist konfiguriert zum Ausführen des zweiten Shaderprogramms. Bei Schritt 810 erzeugt die PPU 100 einen zweiten Threadblock, der mit dem zweiten Shaderprogramm assoziiert ist. Jeder Thread des zweiten Threadblocks entspricht mindestens einem Abschnitt des SSA 410. In einer Ausführungsform weist der zweite Threadblock einen einzigen Thread auf, der die zweite Stufe 602 als eine serielle Schleife implementiert. In einer weiteren Ausführungsform weist der zweite Threadblock zwei oder mehr Threads auf, die die zweite Stufe 602 unter Verwendung von wohl bekannten parallelen List-Ranking-Algorithmen implementieren. Bei Schritt 812 führt die PPU 100 den zweiten Threadblock aus, um das SSA 410 zu rekonstruieren. Es wird wieder verstanden werden, dass mehrere Threadblöcke erzeugt und ausgeführt werden mögen, wenn die Anzahl der Abschnitte von dem SSA 410 größer ist als eine maximale Anzahl von Threads in einem Threadblock.
Die 9 stellt ein beispielhaftes System 900 dar, in welchem die verschiedenen Architektur und/oder Funktionalität der verschiedenen vorhergehenden Ausführungsformen implementiert werden mögen. Wie gezeigt, wird ein System 900 bereitgestellt, das zumindest einen zentralen Prozessor 901 aufweist, der mit einem Kommunikationsbus 902 verbunden ist. Der Kommunikationsbus 902 mag unter Verwendung jedes geeigneten Protokolls implementiert sein, wie zum Beispiel PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphichs Port), HyperTransport oder jede andere Bus- oder Punkt-zu-Punkt-Protokoll(e). Das System 900 weist auch einen Hauptspeicher 904 auf. Steuerungslogik (Software) und Daten sind in dem Hauptspeicher 904 gespeichert, der die Form eines Speichers mit direktem Zugriff (RAM) annehmen mag. Insbesondere mag der FM-Index 300 in dem Hauptspeicher 904 gespeichert sein. Als eine Option mag das vorliegende System 900 zum Ausführen des Verfahrens 700 der 7 oder des Verfahrens 800 der 8 implementiert sein.
Das System 900 weist auch Eingabevorrichtungen 912, einen Grafikprozessor 906 und ein Display 908 auf, das heißt ein konventionelles CRT (Kathodenstrahlröhre), LCD (Flüssigkristalldisplay), LED (Licht emittierende Diode), Plasmadisplay oder ähnliches. Benutzereingaben mögen von den Eingabevorrichtungen 912 empfangen werden, zum Beispiel Tastatur, Maus, Touchpad, Mikrofon und ähnliches. In einer Ausführungsform mag der Grafikprozessor 906 eine Mehrzahl von Shader-Modulen (engl. „shader modules”), ein Rasterisierungsmodul (engl. „rasterization module”) etc. aufweisen. Jedes der vorhergehenden Module mag sich sogar auf einer einzigen Halbleiterplattform befinden, um eine Grafikverarbeitungseinheit (GPU) zu bilden.
In der vorliegenden Beschreibung mag eine einzige Halbleiterplattform auf einen alleinigen einheitlichen halbleiterbasierten integrierten Schaltkreis oder Chip verweisen. Es sollte beachtet werden, dass der Begriff einzige Halbleiterplattform auch auf Mehrchipmodule mit erhöhter Konnektivität, die Auf-dem-Chip-Operation (engl. „on-chip Operation”) simuliert, verweisen mag und erhebliche Verbesserungen gegenüber der Verwendung einer konventionellen Implementierung mit zentralem Verarbeitungseinheit (CPU) und Bus erzielen mag. Die verschiedenen Module mögen selbstverständlich auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers angeordnet werden.
Das System 900 mag auch einen sekundären Speicher 910 aufweisen. Der Sekundäre Speicher 910 weist zum Beispiel einen Festplattenlaufwerk und/oder einen entfernbaren Speicherlaufwerk (engl. „removable storage drive”), darstellend einen Floppy-Disk-Laufwerk, einen Magnetbandlaufwerk, einen Compact-Disk-Laufwerk, einen Digital-Versatile-Disk-(DVD)-Laufwerk, ein Aufnahmegerät, einen Universal-Serial-Bus-(USB)-Flashspeicher auf. Der entfern bare Speicherlaufwerk liest von und/oder schreibt zu einer entfernbaren Speichereinheit in einer wohlbekannten Art und Weise.
Computerprogramme oder Computersteuerungsalgorithmen mögen in dem Hauptspeicher 904 und/oder in dem sekundären Speicher 910 gespeichert sein. Solche Computerprogramme machen es, wenn sie ausgeführt werden, für das System 900 möglich, verschiedene Funktionen durchzuführen. Der Speicher 904, der Speicher 910 und/oder jeglicher andere Speicher sind mögliche Beispiele von computerlesbaren Medien.
In einer Ausführungsform mag die Architektur und/oder Funktionalität der verschiedenen vorhergehenden Figuren im Kontext des zentralen Prozessors 901, des Grafikprozessors 906, eines integrierten Schaltkreises (nicht gezeigt), der zu zumindest einen Teil der Fähigkeiten von sowohl dem Hostprozessor 901 als auch dem Grafikprozessor 906 aufweist, eines Chipsatzes (das heißt, eine Gruppe von integrierten Schaltkreisen, die zum Arbeiten konzipiert sind und als eine Einheit zum Ausführen verwandter Funktionen verkauft werden) und/oder übrigens auch irgendeines anderen integrierten Schaltkreises implementiert werden.
Die Architektur und/oder Funktionalität der verschiedenen vorhergehenden Figuren mögen aber auch in dem Kontext eines generellen bzw. allgemeinen Computersystems, eines Leiterplattensystems, eines Spielkonsolsystems, das für Unterhaltungszwecke dediziert ist, eines anwendungsspezifischen Systems und/oder jegliches anderen gewünschten Systems implementiert werden. Zum Beispiel, mag das System 900 die Form eines Desktopcomputers, eines Laptopcomputers, eines Servers, einer Arbeitsstation, Spielkonsolen, eingebettetes Systems und/oder jeglicher anderen Art von Logik annehmen. Das System 900 mag aber auch die Form verschiedener anderen Vorrichtungen annehmen, einschließlich einer persönlichen digitalen Assistenten-Vorrichtung (PDA), einer Mobiltelefon-Vorrichtung, eines Fernsehers etc., ohne auf diese begrenzt zu sein.
Das System 900 mag ferner, obwohl dies nicht gezeigt ist, an ein Netzwerk (zum Beispiel ein Telekommunikationsnetzwerk, ein lokales Netzwerk (LAN), ein drahtloses Netzwerk, ein Weitverkehrsnetz (WAN), wie das Internetz, ein Peer-to-Peer-Netzwerk, ein Kabelnetzwerk oder ähnliches) zu Kommunikationszwecken gekoppelt sein.
Während verschiedene Ausführungsformen oben beschrieben worden sind, sollte es verstanden werden, dass diese nur beispielhaft und nicht einschränkend dargestellt worden sind. Folglich sollte die Weite und der Umfang einer bevorzugten Ausführungsform nicht von einer jeglichen der oben beschriebenen Ausführungsformen begrenzt werden, sondern nur in Übereinstimmung mit den nachfolgenden Ansprüchen und deren Äquivalenten definiert werden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

IEEE 754-2008 Standard [0030]
Wyllie, J. C. (1979), ”The Complexity of Parallel Computation,” Ph. D. thesis, Department of Computer Science, Cornell University [0050]
Anderson, Richard J.; Miller, Gary L. (1990), ”A simple randomized parallel algorithm for list-ranking”, Information Processing Letters 33, pp. 269–273, doi: 10.1016/0020-0190(90)90196-5 [0050]

Claims

Ein Verfahren aufweisend: für jeden Index eines gesampelten Suffixarrays für einen String, Berechnen eines dem Index entsprechenden Blockwertes basierend auf einem Volltextindex im kleinen Raum (FM-Index); und Rekonstruieren des gesampelten Suffixarrays, das dem String entspricht, basierend auf den Blockwerten, wobei das Berechnen von mindestens zwei der Blockwerte für mindestens zwei der entsprechenden Indexe des gesampelten Suffixarrays parallel durchgeführt wird.
Das Verfahren gemäß Anspruch 1, wobei der FM-Index eine Burrows-Wheeler-Transformation des Strings, einen Vektor und eine Vorkommnissentabelle aufweist.
Das Verfahren gemäß Anspruch 2, wobei der Vektor die Häufigkeit von jedem Zeichen spezifiziert, das in dem String enthalten ist.
Das Verfahren gemäß Anspruch 3, wobei die Vorkommnissentabelle die Anzahl der Vorkommnisse eines bestimmten Zeichens in jedem Substring von der Burrows-Wheeler-Transformation des Strings spezifiziert.
Das Verfahren gemäß Anspruch 2, wobei das Berechnen von mindestens zwei der Blockwerte ein Addieren eines in dem Vektor gespeicherten Wertes zu einem in der Vorkommnissetabelle gespeicherten Wert aufweist.
Das Verfahren gemäß Anspruch 5, wobei das Berechnen von mindestens zwei der Blockwerte ein Zugreifen auf eine komprimierte Version der Vorkommnissentabelle und ein Dekomprimieren zumindest eines Abschnittes der Vorkommnissentabelle aufweist, um den in der Vorkommnissentabelle gespeicherten Wert zu erzeugen.
Das Verfahren gemäß Anspruch 6, wobei die Vorkommnissentabelle via Huffman-Enkodierung komprimiert ist.
Das Verfahren gemäß Anspruch 2, wobei die Vorkommnissentabelle als eine Texturabbildung gespeichert ist.
Das Verfahren gemäß Anspruch 9, wobei das Berechnen von mindestens zwei der Blockwerte ein Sampeln der Texturabbildung via eine Textureinheit in einer Parallelverarbeitungseinheit aufweist.
Das Verfahren gemäß Anspruch 1, ferner aufweisend: Konfigurieren einer Parallelverarbeitungseinheit zum Ausführen eines Shaderprogramms für das Berechnen von den mindestens zwei der Blockwerte; Erzeugen eines Threadblocks, der mit dem Shaderprogramm assoziiert ist, wobei jeder Thread des Threadblocks einem unterschiedlichen Index des gesampelten Suffixarrays entspricht; und Ausführen des Threadblocks auf mindestens einem Streaming-Multiprozessor der Parallelverarbeitungseinheit.
Das Verfahren gemäß Anspruch 10, ferner aufweisend: Konfigurieren einer Parallelverarbeitungseinheit zum Ausführen eines zweiten Shaderprogramms für Rekonstruieren des gesampelten Suffixarrays, das dem String entspricht; Erzeugen eines zweiten Threadblocks, der mit dem zweiten Shaderprogramm assoziiert ist, wobei jeder Thread des zweiten Threadblocks zumindest einem Abschnitt des gesampelten Suffixarrays entspricht; und Ausführen des zweiten Threadblocks auf mindestens einem Streaming-Multiprozessor der Parallelverarbeitungseinheit.
Das Verfahren gemäß Anspruch 11, wobei zwei oder mehr Threadblocks auf zwei oder mehr Streaming-Multiprozessoren der Parallelverarbeitungseinheit ausgeführt werden.
Das Verfahren gemäß Anspruch 1, wobei das Berechnen von mindestens zwei der Blockwerte ein Initialisieren einer Do-While-Schleife aufweist.
Das Verfahren gemäß Anspruch 13, wobei die Do-While-Schleife einen neuen Wert für eine Variable isa iterativ berechnet, während der Wert der Variable isa kein ganzzahliges Vielfaches einer Konstante K ist, und wobei die Do-While-Schleife eine Anzahl von Iterationen der Do-While-Schleife zählt, während der Wert der Variable isa kein ganzzahliges Vielfaches der Konstante K ist.
Das Verfahren gemäß Anspruch 14, wobei der neue Wert der Variable isa via eine deterministische Funktion von der Variable isa berechnet wird, und wobei die deterministische Funktion auf einem oder mehreren Werten basiert, die in dem FM-Index gespeichert sind.
Ein nicht flüchtiges computerlesbares Speichermedium, das Instruktionen speichert, die, wenn sie von einem Prozessor ausgeführt werden, bewirken, dass der Prozessor Schritte durchführt, die aufweisen: für jeden Index eines gesampelten Suffixarrays für einen String, Berechnen eines dem Index entsprechenden Blockwertes basierend auf einem Volltextindex im kleinen Raum (FM-Index); und Rekonstruieren des gesampelten Suffixarrays, das dem String entspricht, basierend auf den Blockwerten, wobei das Berechnen von mindestens zwei der Blockwerte für mindestens zwei der entsprechenden Indexe des gesampelten Suffixarrays parallel durchgeführt wird.
Das nicht flüchtige computerlesbare Speichermedium gemäß Anspruch 16, wobei der FM-Index eine Burrows-Wheeler-Transformation des Strings, einen Vektor und eine Vorkommnissentabelle aufweist.
Das nicht flüchtiges computerlesbares Speichermedium gemäß Anspruch 16, ferner aufweisend: Konfigurieren einer Parallelverarbeitungseinheit zum Ausführen eines Shaderprogramms für das Berechnen von den mindestens zwei der Blockwerte; und Ausführen eines Threadblocks auf zwei oder mehr Streaming-Multiprozessoren der Parallelverarbeitungseinheit, wobei jeder Thread des Threadblocks einem unterschiedlichen Index des gesampelten Suffixarrays entspricht.
Ein System aufweisend: eine Parallelverarbeitungseinheit; und einen Speicher, der Instruktionen speichert, die die Parallelverarbeitungseinheit konfiguriert zum: für jeden Index eines gesampelten Suffixarrays für einen String, Berechnen eines dem Index entsprechenden Blockwertes basierend auf einem Volltextindex im kleinen Raum (FM-Index); und Rekonstruieren des gesampelten Suffixarrays, das dem String entspricht, basierend auf den Blockwerten, wobei das Berechnen von mindestens zwei der Blockwerte für mindestens zwei der entsprechenden Indexe des gesampelten Suffixarrays von der Parallelverarbeitungseinheit parallel durchgeführt wird.
Das System gemäß Anspruch 19, wobei die Parallelverarbeitungseinheit eine Grafikverarbeitungseinheit ist, die zum Ausführen eines Shader für das Berechnen der Blockwerte konfiguriert ist.