DE102021121333A1 - Parallele dekomprimierung von komprimierten datenströmen - Google Patents

Parallele dekomprimierung von komprimierten datenströmen Download PDF

Info

Publication number
DE102021121333A1
DE102021121333A1 DE102021121333.9A DE102021121333A DE102021121333A1 DE 102021121333 A1 DE102021121333 A1 DE 102021121333A1 DE 102021121333 A DE102021121333 A DE 102021121333A DE 102021121333 A1 DE102021121333 A1 DE 102021121333A1
Authority
DE
Germany
Prior art keywords
compressed data
segments
data
output
metadata
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102021121333.9A
Other languages
English (en)
Inventor
Steven Parker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE102021121333A1 publication Critical patent/DE102021121333A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
    • H03M7/3088—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method employing the use of a dictionary, e.g. LZ78
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/174—Redundancy elimination performed by the file system
    • G06F16/1744—Redundancy elimination performed by the file system using compression, e.g. sparse files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0644—Management of space entities, e.g. partitions, extents, pools
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0656—Data buffering arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H03M7/4031—Fixed length to variable length coding
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60—General implementation details not specific to a particular type of compression
    • H03M7/6005—Decoder aspects
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60—General implementation details not specific to a particular type of compression
    • H03M7/6017—Methods or arrangements to increase the throughput
    • H03M7/6023—Parallelization

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

In verschiedenen Beispielen können Metadaten erzeugt werden, die komprimierten Datenströmen entsprechen, die nach seriellen Komprimierungsalgorithmen - wie arithmetischer Codierung, Entropiecodierung usw. - komprimiert werden - um ein paralleles Dekomprimieren der komprimierten Daten zu ermöglichen. Infolgedessen ist eine Änderung des komprimierten Datenstroms selbst nicht erforderlich, und die Bandbreiten- und Speicheranforderungen des Systems können minimal beeinträchtigt werden. Darüber hinaus kann das System durch die Parallelisierung der Dekomprimierung von schnelleren Dekomprimierungszeiten profitieren und gleichzeitig den Adoptionszyklus für Systeme, die die Metadaten für die parallele Dekomprimierung verwenden, reduzieren oder ganz abschaffen.

Description

  • HINTERGRUND
  • Verlustfreie Komprimierungsalgorithmen werden seit langem verwendet, um die Größe von Datensätzen für die Speicherung und Übertragung zu reduzieren. Viele herkömmliche Komprimierungsalgorithmen basieren auf einem Lempel-Ziv (LZ)-Algorithmus, einer Huffman-Codierung oder einer Kombination davon. Das Komprimierungsformat DEFLATE - Internetstandard RFC1951 - kombiniert beispielsweise den LZ-Algorithmus und die Huffman-Codierung für die E-Mail-Kommunikation, das Herunterladen von Webseiten, die Erstellung von ZIP-Dateien für die Speicherung auf einer Festplatte und/oder Ähnliches. Algorithmen wie DEFLATE können bei der Datenübertragung Bandbreite einsparen und/oder Speicherplatz einsparen, indem sie die Daten mit weniger Bits speichern. Herkömmliche Komprimierungsalgorithmen sind jedoch aufgrund der starken Abhängigkeit von früheren Eingaben für die Rekonstruktion späterer Eingaben von Natur aus seriell, so dass sich diese Komprimierungstechniken weniger gut für die Dekomprimierung auf parallelen Verarbeitungseinheiten wie z. B. Grafikprozessoren (GPUs) eignen. Folglich sind feinkörnige parallele Dekomprimierungsalgorithmen für die Verarbeitung komprimierter Daten selten.
  • Die meisten konventionellen Ansätze zur parallelen Dekomprierung beruhen auf der Modifizierung des Komprimierungsalgorithmus selbst, um die Datenrisiken der LZ-Algorithmen zu beseitigen und/oder den Huffman-Codierungsschritt zu entfernen oder einzuschränken. Beispiele für frühere Ansätze zur parallelen Dekomprimierung umfassen LZ4 und LZ Sort and Set Empty (LZSSE). Diese und ähnliche Ansätze sind in der Lage, einige Vorteile mit Parallelverarbeitungsarchitekturen zu erzielen - z. B. eine geringere Laufzeit -, wenn auch auf Kosten einiger Komprimierungsvorteile der LZ-Algorithmen und/oder der Huffman-Codierung. Beispielsweise führen diese parallelen Dekomprimierungsalgorithmen oft zu einer Zunahme der Dateigröße um 10-15 % im Vergleich zu denselben Dateien, die mit herkömmlichen sequentiellen Implementierungen des DEFLATE-Komprimierungsformats komprimiert wurden.
  • Ein weiterer Nachteil dieser parallelen Dekomprimierungsalgorithmen besteht darin, dass die weit verbreitete Verwendung der herkömmlichen Dateiformate eine erhebliche Hürde für die breite Akzeptanz jedes neu vorgeschlagenen Formats darstellt. Bei Systemen, in denen die Daten bereits in einem traditionelleren komprimierten Format gespeichert sind - z. B. unter Verwendung von LZ-Algorithmen, Huffman-Codierung oder einer Kombination davon - muss das System möglicherweise neu konfiguriert werden, um mit dem Typ eines neuen Komprimierungsalgorithmus zu arbeiten. Diese Neukonfiguration kann kostspielig sein, da die Bandbreiten- und Speicheranforderungen des Systems möglicherweise für die geringere Bandbreite und die geringeren Dateigrößen der seriellen Komprimierungsalgorithmen optimiert wurden, während die höheren Bandbreiten- und Speicheranforderungen der parallelen Dekomprimierungsalgorithmen zusätzliche Ressourcen erfordern können. Darüber hinaus müssen möglicherweise bereits gespeicherte Daten aus dem bestehenden Komprimierungsformat neu formatiert werden und/oder eine neue Kopie der Daten muss im aktualisierten Format gespeichert werden, bevor die bestehende Kopie entfernt werden kann, wodurch sich der Zeitaufwand für den Übernahmezyklus weiter erhöht und möglicherweise der Erwerb zusätzlicher Ressourcen erforderlich wird.
  • ZUSAMMENFASSUNG
  • Ausführungsformen der vorliegenden Offenbarung beziehen sich auf Vorgehen zur parallelen Dekomprimierung komprimierter Datenströme. Es werden Systeme und Verfahren offenbart, die Metadaten für Datenströme erzeugen, die nach herkömmlichen Komprimierungsalgorithmen - wie Lempel-Ziv (LZ), Huffman-Codierung, einer Kombination davon und/oder anderen Komprimierungsalgorithmen - komprimiert wurden, um verschiedene Arten von Parallelität in den Datenströmen für die parallele Dekomprimierung der komprimierten Daten aufzudecken. So können die Metadaten beispielsweise Abgrenzungen in den komprimierten Daten angeben, die einzelnen Datenabschnitten oder Blöcken der komprimierten Daten, Abgrenzungen von Datensegmenten innerhalb jedes Inhaltsabschnitts und/oder Abgrenzungen von Zuordnungstabellensegmenten innerhalb jedes Datenabschnitts oder Blocks entsprechen. Darüber hinaus können die Metadaten Ausgabestellen in einem Ausgabestrom von Daten angeben, so dass ein Dekomprimierer - insbesondere bei paralleler Dekomprimierung - erkennen kann, wo die dekomprimierten Daten in den Ausgabestrom passen. Im Gegensatz zu herkömmlichen Systemen, wie den oben beschriebenen, führen die dem komprimierten Datenstrom zugeordneten Metadaten zu einer eher trivialen Erhöhung der Gesamtdateigröße des komprimierten Datenstroms, z. B. um 1-2 %, ohne dass eine Änderung des komprimierten Datenstroms selbst erforderlich ist. Infolgedessen werden die Bandbreiten- und Speicheranforderungen des Systems im Vergleich zu herkömmlichen parallelen Dekomprimierungsalgorithmen nur minimal beeinträchtigt, während gleichzeitig der Vorteil schnellerer Dekomprimierungszeiten aufgrund der parallelen Verarbeitung der komprimierten Daten erzielt wird. Da der komprimierte Datenstrom nicht beeinflusst wird (z. B. wenn ein DEFLATE-Format verwendet wird, entspricht der komprimierte Datenstrom immer noch dem DEFLATE-Format), können außerdem Kompatibilitätsprobleme mit älteren Systemen und Dateien vermieden werden, da Systeme, die zentrale Verarbeitungseinheiten (CPUs) für die Dekomprimierung verwenden, die Metadaten ignorieren und die komprimierten Daten nach herkömmlichen Verfahren seriell dekomprimieren können, während Systeme, die parallele Prozessoren wie GPUs für die Dekomprimierung verwenden, die Metadaten verwenden können, um die Daten parallel zu dekomprimieren.
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren zur parallelen Dekomprimierung komprimierter Datenströme werden im Folgenden unter Bezugnahme auf die beigefügten Figuren im Detail beschrieben, wobei gilt:
    • 1 zeigt ein beispielhaftes Datenflussdiagramm, das ein Verfahren 100 zur parallelen Dekomprimierung von komprimierten Datenströmen gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt;
    • 2A zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle, die Metadaten für die parallele Dekomprimierung von komprimierten Datenströmen entspricht,
    • 2B zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle, die Metadaten in einem Präfixsummenformat für die parallele Dekomprimierung von komprimierten Datenströmen entspricht;
    • 2C zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle, die einem Wörterbuch bzw. einer Zuordnungstabelle und den damit verbundenen Metadaten entspricht;
    • 2D zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle, die Metadaten für die parallele Dekomprimierung von Blöcken eines komprimierten Datenstroms entspricht;
    • 2E zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle, die Kopien eines komprimierten Datenstroms entspricht, die nicht zur parallelen Verarbeitung geeignet sind;
    • 2F zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle, die Kopien eines komprimierten Datenstroms entspricht, die für eine parallele Verarbeitung geeignet sind;
    • 3 zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das einem Verfahren zur Erzeugung von Metadaten für einen komprimierten Datenstrom zur parallelen Dekomprimierung des komprimierten Datenstroms entspricht;
    • 4 zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das einem Verfahren zum parallelen Dekomprimieren eines komprimierten Datenstroms entspricht;
    • 5 zeigt ein Blockdiagramm einer beispielhaften Recheneinrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
    • 6 ist ein Blockdiagramm eines beispielhaften Rechenzentrums, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.
  • DETAILLIERTE BESCHREIBUNG
  • Systeme und Verfahren werden im Zusammenhang mit der parallelen Dekomprimierung komprimierter Datenströme offengelegt. Obwohl die Beschreibung hier in erster Linie in Bezug auf Datenströme erfolgt, die unter Verwendung eines Lempel-Ziv (LZ)-Algorithmus und/oder einer Huffman-Codierung komprimiert werden (z. B. DEFLATE, LZ4, LZ sort and set empty (LZSSE), PKZIP, LZ Jaccard Distance (LZJD), LZ Welch (LZW), BZIP2, Finite State Entropy usw.), ist dies nicht als Einschränkung zu verstehen. Es können auch andere Komprimierungsalgorithmen und/oder -techniken verwendet werden, ohne den Rahmen der vorliegenden Offenbarung zu verlassen. Zum Beispiel eine Fibonacci-Codierung, eine Shannon-Fano-Codierung, eine arithmetische Codierung, ein künstlicher Bienenvolk-Algorithmus, ein Bentley, Sleator, Tarjan und Wei (BSTW)-Algorithmus, eine Prädiktion durch partielle Übereinstimmung (PPM), eine Lauflängencodierung (RLE), eine Entropiecodierung, eine Rice-Codierung, eine Golomb-Codierung, eine Codierung mit einer Zuordnungstabelle und/oder Ähnliches. Als weiteres Beispiel können die hier beschriebenen Vorgehen zur Erzeugung von Metadaten und zur parallelen Dekomprimierung für jedes komprimierte Datenformat geeignet sein, das entweder eine variable Bitlänge für die Codierung von Symbolen und/oder eine variable Ausgabegröße für Kopien aufweist (z. B. können Kopien einem Symbol, zwei Symbolen, fünf Symbolen usw. entsprechen).
  • Die hier beschriebenen Verfahren zur Erzeugung und Dekomprimierung von Metadaten können in jedem Technologiebereich eingesetzt werden, in dem Datenkomprimierung und -dekomprimierung implementiert sind - insbesondere für verlustfreie Komprimierung und Dekomprimierung. Beispielsweise und ohne Einschränkung können die hier beschriebenen Vorgehen für Audiodaten, Rastergrafiken, dreidimensionale (3D) Grafiken, Videodaten, Kryptografie, Genetik und Genomik, medizinische Bildgebung (z. B. zur Komprimierung von DICOM-Daten), ausführbare Dateien, das Verschieben von Daten von und zu einem Webserver, das Senden von Daten zwischen einer zentralen Verarbeitungseinheit (CPU) und einer Grafikverarbeitungseinheit (GPU) (z. B. zur Erhöhung der Ein-/Ausgabebandbreite zwischen CPU und GPU), Datenspeicherung (z. B. zur Verringerung des Datenumfangs), E-Mails, Text, Nachrichten, Komprimierung von Dateien (z. B. ZIP-Dateien, GZIP-Dateien usw.) und/oder andere Technologiebereiche. Die hier beschriebenen Systeme und Verfahren eignen sich besonders gut zur Erweiterung des Speichers und zur Erhöhung der PCIe-Bandbreite für E/A-intensive Anwendungsfälle - wie z. B. die Kommunikation von Daten zwischen einer CPU und einer GPU.
  • 1 ist ein beispielhaftes Datenflussdiagramm, das ein Verfahren 100 zur parallelen Dekomprimierung komprimierter Datenströme gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Es ist klar, dass diese und andere Anordnungen, wie sie hier beschrieben sind, nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Reihenfolgen, Gruppierungen von Funktionen usw.) können zusätzlich zu den gezeigten oder anstelle von ihnen verwendet werden, und einige Elemente können ganz weggelassen werden. Darüber hinaus handelt es sich bei vielen der hier beschriebenen Elemente um funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert sein können. Verschiedene Funktionen, wie sie hier beschrieben sind, können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Das Verfahren 100 kann ein Empfangen und/oder ein Erzeugen von Daten 102 enthalten. Zum Beispiel können die Daten 102 jeder Art von Technologieraum entsprechen, wie es hier beschrieben ist, sind aber nicht darauf beschränkt. Zum Beispiel können die Daten 102 Textdaten, Bilddaten, Videodaten, Audiodaten, genomische Sequenzierungsdaten und/oder andere Datentypen oder eine Kombination davon entsprechen. Bei einigen Ausführungsformen können die Daten 102 Daten entsprechen, die unter Verwendung verlustfreier Komprimierungstechniken zu speichern und/oder zu übertragen sind.
  • Das Verfahren 100 kann einen Komprimierer 104 aufweisen, der die Daten 102 komprimiert, um komprimierte Daten 106 zu erzeugen. Die Daten 102 können nach jedem beliebigen Komprimierungsformat oder -algorithmus komprimiert werden, wie z. B., aber nicht beschränkt auf, die, die hier beschrieben sind. Beispielsweise und ohne Einschränkung können die Daten 102 gemäß dem Lempel-Ziv-Algorithmus, der Huffman-Codierung, dem DEFLATE-Format und/oder einem anderen Komprimierungsformat oder -verfahren komprimiert werden.
  • Ein Analysator 108 für komprimierte Daten kann die komprimierten Daten 106 analysieren, um Möglichkeiten für eine Parallelität darin zu bestimmen. Zum Beispiel kann der Analysator 108 für komprimierte Daten Segmente (oder Abschnitte) innerhalb der komprimierten Daten 106 identifizieren, die Abschnitten eines Datenstroms entsprechen, die zumindest teilweise parallel verarbeitet werden können, ohne die Verarbeitung anderer Segmente zu beeinträchtigen. Bei einigen Ausführungsformen kann die Anzahl der Segmente für jeden Datenblock gleich sein oder unterschiedlich sein (was z. B. dynamisch bestimmt wird). Die Anzahl der Segmente ist nicht auf eine bestimmte Anzahl beschränkt; bei einigen Ausführungsformen kann jedoch jeder Block komprimierter Daten in 32 verschiedene Segmente aufgeteilt sein, so dass 32 Threads (oder Coprozessoren) eines Warp auf einer GPU die 32 Segmente parallel verarbeiten können. Als weitere nicht einschränkende Beispiele können die komprimierten Daten 106 - oder Blöcke davon - in 4 Segmente, 12 Segmente, 15 Segmente, 64 Segmente usw. aufgeteilt sein. Die Anzahl der Segmente kann jedem Datenblock und/oder jedem Abschnitt einer Datenstruktur entsprechen, die für eine Codierung mit Zuordnungstabelle verwendet wird, die jedem Block entspricht, wie es hier beschrieben ist. So kann die Datenstruktur (die Zuordnungstabelle) in eine Anzahl von Segmenten für die parallele Decodierung aufgeteilt werden, und die Daten können in eine (bei bestimmten Ausführungsformen gleiche) Anzahl von Segmenten für die parallele Decodierung aufgeteilt werden - z. B. unter Verwendung der bereits decodierten Zuordnungstabelle.
  • Um zu bestimmen, welcher Abschnitt der komprimierten Daten 106 den einzelnen Segmenten zuzuordnen ist, kann der Analysator 108 für komprimierte Daten einen ersten Durchlauf über die komprimierten Daten 106 durchführen, um die Anzahl der Symbole oder Token innerhalb der komprimierten Daten 106 zu bestimmen. In einem zweiten Durchlauf kann die Anzahl der Symbole dann verwendet werden, um zu bestimmen, wie viele - und welche - Symbole in jedes Segment aufzunehmen sind. Bei einigen Ausführungsformen kann die Anzahl der Symbole gleichmäßig - oder so gleichmäßig wie möglich - auf die Segmente verteilt werden. Bei 320 Symbolen und 32 Segmenten kann zum Beispiel jedes Segment 10 Symbole aufweisen. In anderen Beispielen kann die Anzahl der Symbole angepasst werden - z. B. plus oder minus ein oder mehrere Symbole für ein oder mehrere Segmente -, um die Dekomprimierung zu vereinfachen. Anstatt wie im obigen Beispiel 10 Symbole pro Segment zu wählen, können eines oder mehrere der Segmente 11 Symbole aufweisen (während andere 9 aufweisen können), um zu bewirken, dass eine Segmentgrenze einem bestimmten Byte-Intervall - z. B. einem 4-Byte-Intervall - entspricht, das ein Dekomprimierer 114 leichter handhaben kann (um z. B. ein Aufteilen von Ausgaben zwischen Bytes der komprimierten Daten 106 zu vermeiden).
  • Die Segmente können dann von einem Metadatengenerator 110 analysiert werden, um Metadaten 112 zu erzeugen, die den komprimierten Daten 106 entsprechen und dem Dekomprimierer 114 Informationen zum parallelen Dekomprimieren der komprimierten Daten 106 bereitstellen. Zum Beispiel können die Metadaten 112 innerhalb jedes Segments drei Informationen identifizieren. Erstens eine Bitnummer, die angibt, an welcher Stelle bzw. Position in den komprimierten Daten mit der Decodierung des Segments zu beginnen ist; zweitens eine Stelle bzw. Position in dem Ausgabepuffer, an der die decodierten Ergebnisse einzufügen sind; und drittens die Position oder Stelle innerhalb einer Liste von Kopien (oder Übereinstimmungen), an der mit der Ausgabe der verzögerten Kopien zu beginnen ist - z. B. ein Kopierindex. In Bezug auf die dritte Art von Metadaten 112 kann der Dekomprimierer 114 die Decodierung parallel ausführen, wenn ein LZ-Algorithmus verwendet wird, indem die Kopien beispielsweise nicht seriell decodiert werden, sondern die Kopien für eine spätere Ausführung aufeinander folgend gespeichert werden. Dabei kann der Kopierindex in den Metadaten 112 vorhanden sein, um dem Dekomprimierer 114 anzuzeigen, dass er im Ausgabepuffer für jede Kopie Platz reservieren soll, und er kann auch in einem separaten Datenfeld den Kopierindex speichern, so dass, sobald ein erster Durchlauf durch den Dekomprimierer 114 ausgeführt wurde, die Kopien von dem Dekomprimierer 114 ausgeführt werden können, um den Ausgabepuffer mit den Daten zu füllen. Bei einigen Ausführungsformen kann das Kopierfenster eine bestimmte Länge aufweisen, wie z. B. ein gleitendes Fenster. Bei Verwendung von LZ77 kann das gleitende Fenster für Kopien beispielsweise 32kb groß sein, während bei anderen Algorithmen das gleitende Fenster eine andere (z. B. 16kb, 64kb, 128kb usw.) oder variable Größe aufweisen kann. So können die komprimierten Daten 106 abhängig von der Größe des gleitenden Fensters erzeugt werden. Infolge der Metadaten 112 kann die Parallelisierung auf der GPU so ausgeführt werden, dass jeder Thread der GPU mit der Decodierung eines Abschnitts der komprimierten Daten 106 unabhängig voneinander beginnen kann. In dem obigen Beispiel mit 32 Segmenten kann dieses Verfahren 100 zu einer 32-fachen Parallelität führen und jeder Thread kann 1/32 der komprimierten Daten 106 - oder einen Block davon - decodieren.
  • Bei einigen Ausführungsformen können die Metadaten der Anzahl von Bits für jedes Segment, der Anzahl von Ausgabebytes für jedes Segment und/oder der Anzahl von Kopien in jedem Segment entsprechen. Bei anderen Ausführungen kann jedoch eine Präfixsummenoperation an diesen Daten (z. B. der Anzahl der Bits, der Anzahl der Ausgabebytes und/oder der Anzahl der Kopien) ausgeführt werden, um die Metadaten 112 in einem Präfixsummenformat zu erzeugen. Infolgedessen können die Metadaten 112 der Eingabeposition (Bit, Nibble, Byte usw.) für jedes Segment (z. B. anhand der Anzahl der Bits, Nibbles oder Bytes des jeweiligen vorherigen Segments bestimmt werden), der Ausgabeposition (Bit, Nibble, Byte usw.) für jedes Segment (z. B, anhand der Anzahl der Ausgabe-Bits, - Nibbles oder -Bytes des jeweiligen vorherigen Segments bestimmt werden) und die Anzahl der Kopien, die jedes Segment vor dem aktuellen Segment, für das die Metadaten 112 erzeugt werden, aufweist. Ein Beispiel für den Unterschied zwischen diesen beiden Formaten der Metadaten ist in den 2A und 2B dargestellt und wird hier mit mehr Details beschrieben. Bei einigen Ausführungsformen können die Metadaten 112 aufgrund der monoton ansteigenden Werte des Eingabebits, der Ausgabeposition und/oder des Kopierindex für jedes Segment komprimiert werden, indem gemeinsame Offsets (die von allen Segmenten gemeinsam genutzt werden) und Unterschiede zwischen dem Eingabebit, der Ausgabeposition und dem Kopierindex in jedem Segment gespeichert werden.
  • Wie es hier beschrieben ist, kann der Analysator 108 für komprimierte Daten die komprimierten Daten 106 analysieren, um die Metadaten 112 zu bestimmen, die dem Inhaltsabschnitt der komprimierten Daten 106 entsprechen, er kann aber auch die komprimierten Daten 106 analysieren, um die Metadaten 112 zu bestimmen, die einem Zuordnungstabellenabschnitt (sofern vorhanden) entsprechen, der den komprimierten Daten 106 entspricht, und/oder um die Metadaten 112 zu bestimmen, die der Identifizierung von Blöcken innerhalb eines größeren Stroms von komprimierten Daten 106 entsprechen. Beispielsweise kann der Inhaltsabschnitt der komprimierten Daten 106 eine Zuordnungstabelle erfordern, um von dem Dekomprimierer 114 korrekt decodiert zu werden. Die Zuordnungstabelle kann in Ausführungsformen, in denen die Huffman-Codierung verwendet wird, eine Darstellung eines Huffman-Baums (oder eines Zuordnungsbaums) aufweisen. Bei einigen Ausführungsformen, z. B. wenn sowohl der LZ-Algorithmus als auch die Huffman-Codierung verwendet werden (z. B. beim DEFLATE-Format), kann eine erste Huffman-Codierungsoperation auf den Buchstabensymbolen und den Längen der Kopien ausgeführt werden, und eine zweite Huffman-Codierungsoperation kann auf den Abständen ausgeführt werden. Dabei können zwei oder mehr Huffman-Bäume in der Zuordnungstabelle zur Decodierung jedes der Zeichen bzw. Buchstabensymbole und der Längen und Abstände der Kopien vorhanden sein.
  • Bei anderen Ausführungsformen kann die Zuordnungstabelle einen Hinweis darauf bereitstellen, welchen Symbolen die komprimierten Daten 106 entsprechen - oder welche Bitwerte ihnen entsprechen -, so dass der Dekomprimierer 114 die Zuordnungstabelle verwenden kann, um den Inhaltsabschnitt der komprimierten Daten 106 zu dekomprimieren. Bei einigen Ausführungsformen kann die Zuodnungstabelle Huffman-codiert sein und auch einem Huffman-Baum zur Dekomprimierung der komprimierten Daten 106 entsprechen. Wenn für jeden Block der komprimierten Daten 106 eine Zuordnungstabelle verwendet wird, wie z. B. im DEFLATE-Format, kann der Metadatengenerator 110 Metadaten 112 erzeugen, die einem Starteingabebit jedes Segments der Zuordnungstabelle und einer Anzahl von Bits entsprechen, die für jedes Symbol in dem Inhaltsabschnitt des Blocks der komprimierten Daten 106 verwendet werden, dem die Zuordnungstabelle entspricht. So kann die Zuordnungstabelle abhängig von den Metadaten 112 in Segmente unterteilt und unter Verwendung von Threads der GPU parallel verarbeitet werden. Wie es hier beschrieben ist, kann die Anzahl der Segmente ähnlich der Anzahl der Segmente des Daten- oder Inhaltsabschnitts des Blocks der komprimierten Daten 106 sein oder sich abhängig von der Ausführungsform unterscheiden. Darüber hinaus kann die Zuordnungstabelle Füllungen oder Wiederholungen aufweisen, die denen der Kopien oder Übereinstimmungen des Datensegments der komprimierten Daten 106 ähnlich sind, und die Füllungen oder Wiederholungen können verwendet werden, um die Zuordnungstabelle weiter zu komprimieren.
  • Die komprimierten Daten 106 können in eine beliebige Anzahl von Blöcken aufgeteilt werden, basierend auf einer beliebigen Anzahl von Kriterien, die von dem Komprimierer 104 und/oder gemäß dem verwendeten Komprimierungsformat oder -algorithmus bestimmt werden. So können beispielsweise ein erster Block und ein zweiter Block erzeugt werden, wenn sich die Frequenzen oder Prioritäten in den komprimierten Daten 106 ändern. Als nicht einschränkendes Beispiel können die Buchstaben A, e und i in einem ersten Abschnitt der komprimierten Daten 106 am häufigsten vorkommen, während die Buchstaben g, F und k in einem zweiten Abschnitt der komprimierten Daten 106 am häufigsten vorkommen können. Je nach verwendetem Komprimierungsalgorithmus kann der erste Abschnitt in einen ersten Block und der zweite Abschnitt in einen zweiten Block abgetrennt werden. Es kann eine beliebige Anzahl von Blöcken für die komprimierten Daten 106 existieren, die von dem Komprimierer 104 bestimmt wurden. Der Analysator 108 für komprimierte Daten kann diese Blöcke analysieren, um die Positionen der Blöcke innerhalb des größeren Stroms der komprimierten Daten 106 zu bestimmen. Als solches kann der Metadatengenerator 110 Metadaten 112 erzeugen, die ein Starteingabebit und ein Ausgabebyte (z. B. eine erste Ausgabebyteposition der decodierten Daten) jedes Blocks der komprimierten Daten 106 identifizieren - die unkomprimierte Blöcke aufweisen können. Da die Blöcke voneinander getrennt sind und durch die Metadaten 112 separat identifiziert werden, können die Blöcke auch parallel verarbeitet werden - z. B. zusätzlich zu den komprimierten Daten 106 in jedem der Blöcke, die parallel verarbeitet werden. Wenn jeder Block beispielsweise 32 Segmente aufweist, kann der erste Block mit einem ersten Warp eines Grafikprozessors und der zweite Block mit einem zweiten Warp des Grafikprozessors parallel zu dem ersten Block bearbeitet werden. In einem Beispiel, in dem einer oder mehrere der Blöcke unkomprimiert sind, können die unkomprimierten Blöcke ohne Zuordnungstabelle übertragen werden, und das Eingabebit und das Ausgabebyte des unkomprimierten Blocks können von dem Dekomprimierer 114 verwendet werden, um die Daten direkt in die Ausgabe zu kopieren.
  • Folglich können die Metadaten 112 den Eingabe- und Ausgabepositionen für jeden Block innerhalb eines größeren Datenstroms, einer Eingabeposition für die Zuordnungstabelle innerhalb jedes Blocks sowie Bitwerten für jedes Symbol der Zuordnungstabelle und Eingabepositionen, Ausgabepositionen und Kopierindizes für jedes Segment innerhalb jedes Blocks entsprechen. Diese Metadaten 112 können von dem Dekomprimierer 114 verwendet werden, um die komprimierten Daten 106 mit verschiedenen Formen der Parallelität zu decodieren oder zu dekomprimieren. Zum Beispiel können, wie es hier beschrieben ist, die einzelnen Blöcke parallel decodiert werden - z. B. unter Verwendung verschiedener GPU-Ressourcen und/oder paralleler Verarbeitungseinheiten. Darüber hinaus kann innerhalb jedes (parallel dekomprimierten) Blocks die Zuordnungstabelle (sofern vorhanden) in Segmente unterteilt sein, und die Segmente können parallel decodiert oder dekomprimiert werden (z. B. können bei 64 Segmenten der Zuordnungstabelle alle 64 Segmente parallel decodiert werden, z. B. durch Verwendung von 64 verschiedenen Threads oder zwei Warps einer GPU). Darüber hinaus kann innerhalb jedes (parallel dekomprimierten) Blocks der Inhaltsabschnitt des Blocks in Segmente unterteilt sein, und die Segmente können parallel decodiert oder dekomprimiert werden. Darüber hinaus können, wie es hier definiert ist, eine oder mehrere der Kopieroperationen oder Operationen bei Übereinstimmung durch den Dekomprimierer 114 parallel ausgeführt werden - z. B. wenn sich eine Kopie auf Daten bezieht, die in den Ausgabestrom decodiert wurden, kann die Kopie parallel zu einer oder mehreren anderen Kopien ausgeführt werden. Darüber hinaus kann jeder einzelne Kopiervorgang parallel ausgeführt werden. Wenn beispielsweise eine Kopie eine Länge von mehr als eins aufweist, kann die Kopie jedes Symbols oder Zeichens der vollständigen Kopie durch den Dekomprimierer 114 parallel ausgeführt werden - z. B. kann in Bezug auf 2F jedes Zeichen von „issi“ parallel ausgeführt werden (z. B. Kopieren von „i“ mit einem ersten Thread, „s“ mit einem zweiten Thread, „s“ mit einem dritten Thread“ und „i“ mit einem vierten Thread einer GPU, um die jeweiligen Ausgabebytes für den Ausgabestrom zu erzeugen).
  • Der Dekomprimierer 114 kann die komprimierten Daten 106 und die damit verbundenen Metadaten 112 empfangen. Der Dekomprimierer 114 kann die Metadaten 112 verwenden, um die komprimierten Daten 106 in separate Blöcke zu unterteilen (wenn es mehr als einen Block gibt). Beispielsweise kann der Dekomprimierer 114 die Metadaten 112 analysieren, die der Blockebene der komprimierten Daten 106 entsprechen, und die Eingabeposition (Bit, Nibble, Byte usw.) jedes Blocks (z. B. das erste Bit der komprimierten Daten 106, das dem Block entspricht) und die Ausgabeposition (Bit, Nibble, Byte usw.) für jeden Block (z. B. die erste Ausgabeposition in dem Ausgabestrom, an der sich die Daten - nach der Dekomprimierung - des Blocks befinden) bestimmen. Nachdem jeder Block identifiziert wurde, kann der Dekomprimierer 114 jeden Block seriell verarbeiten (z. B. kann ein erster Block verarbeitet werden, dann ein zweiter Block usw.), er kann zwei oder mehr der Blöcke zur parallelen Dekomprimierung durch verschiedene GPU-Ressourcen zuweisen (z. B. durch Zuweisung eines ersten Blocks an eine erste GPU oder eine erste Gruppe von Threads davon und Zuweisung eines zweiten Blocks an eine zweite GPU oder eine zweite Gruppe von Threads der ersten GPU usw.) oder eine Kombination davon. Bei einigen Ausführungsformen kann jeder Block mit einem anderen Typ oder Modus korrespondieren, z. B. ein Block mit einem unkomprimierten Modus, ein Block mit einem Modus mit einer festgelegten Codierungstabelle, ein Block mit einem Modus einer erzeugten Codierungstabelle und/oder anderen Typen. Der Dekomprimierer 114 kann die komprimierten Daten 106 je nach Modus dekomprimieren (und/oder die unkomprimierten Daten decodieren, wenn sie sich im unkomprimierten Modus befinden), und die Metadaten 112 können abhängig von dem Modus unterschiedlich sein. In einem unkomprimierten Modus kann beispielsweise keine Zuordnungstabelle vorhanden sein, da die Daten nicht dekomprimiert werden müssen, und/oder es können keine Kopien oder Übereinstimmungen vorhanden sein. In diesem Fall können die Metadaten nur einen Eingabe- und einen Ausgabespeicherort für die Daten angeben, so dass der dem unkomprimierten Block entsprechende Eingabedatenstrom direkt in den Ausgabestrom kopiert wird.
  • Der Dekomprimierer 114 kann jeden Datenblock unter Verwendung der Metadaten 112 dekomprimieren, die der/den Zuordnungstabelle(n) und dem/den Inhaltsabschnitt(en) des Blocks zugeordnet sind. Beispielsweise können die Metadaten 112 für jeden Block die Eingabeposition (Bit, Nibble, Byte usw.) der Zuordnungstabelle(n) und die Bitgrößen (oder die Anzahl der Bits) für jedes Symbol jedes Datensegments in dem Block identifizieren. Wie es hier beschrieben ist, kann die Zuordnungstabelle von dem Dekomprimierer 114 verwendet werden, um den Inhaltsabschnitt des Blocks genau zu dekomprimieren. Die Zuordnungstabelle kann mittels einer Huffman-Codierung bezüglich des Inhaltsabschnitts des Blocks erstellt werden, und bei einigen Ausführungsformen können die komprimierten Daten, die der Zuordnungstabelle entsprechen, ebenfalls Huffman-codiert sein. In Ausführungsformen kann daher der Zuordnungstabellenabschnitt der komprimierten Daten mittels Huffman-Codierung komprimiert sein, und der Inhaltsabschnitt der komprimierten Daten kann Huffman-codiert sein. Die Metadaten 112, die dem Zuordnungstabellenabschnitt der komprimierten Daten 106 innerhalb jedes Blocks entsprechen, können die Eingabepositionen der Segmente der Zuordnungstabelle angeben. Wenn die Zuordnungstabelle beispielsweise in 32 Segmente unterteilt ist, können die Metadaten 112 ein Starteingabebit (und/oder ein Ausgabebyte oder eine andere Position) für jedes Segment der Zuordnungstabelle angeben. So kann der Dekomprimierer 114 die Metadaten 112 verwenden, um den Zuordnungstabellenabschnitt der komprimierten Daten 106 parallel zu dekomprimieren oder zu decodieren (z. B. ein Segment pro Thread der GPU). Die Zuordnungstabelle kann gemäß einem LZ-Algorithmus komprimiert sein (in Ausführungsformen zusätzlich zur Huffman-Codierung), so dass die Dekomprimierung des Zuordnungstabellenabschnitts der komprimierten Daten 106 Kopien oder Füllungen aufweisen kann. Wenn also eine parallele Dekomprimierung der Zuordnungstabelle durchgeführt wird, kann der Dekomprimierer 114 in einem ersten Durchgang die tatsächlichen Bitwerte decodieren (z. B. entsprechend einer Bitlänge jedes Symbols in der Zuordnungstabelle) und einen Platzhalter für die zu kopierenden oder zu füllenden Bitwerte hinterlassen. Während eines zweiten Durchlaufs kann der Dekomprimierer 114 die Füll- oder Kopieroperation ausführen, um die fehlenden Bitwerte entsprechend den Symbolen der Zuordnungstabelle aufzufüllen (wie es hier in Bezug auf 2C beispielhaft näher beschrieben ist).
  • Der Dekomprimierer 114 kann die Metadaten 112, die dem Inhaltsabschnitt der komprimierten Daten 106 für jeden Block entsprechen, verwenden, um die erste Eingabeposition (z. B. Bit, Nibble, Byte usw.) jedes Segments der komprimierten Daten 106, die Ausgabeposition in dem Ausgabestrom für jedes Segment der komprimierten Daten 106 nach der Dekomprimierung und/oder den Kopierindex oder die Anzahl der Kopien für jedes Segment der komprimierten Daten 106 zu identifizieren. Eine Präfixsummenoperation kann von dem Dekomprimierer 114 ausgeführt werden, um die Eingabeposition, die Ausgabepositionen und die Anzahl der Kopien für jedes Segment zu bestimmen. Bei anderen Ausführungen, wie sie hier beschrieben sind, können die Metadaten 112 stattdessen die Anzahl der Bits in jedem Segment, die Anzahl der Ausgabebytes in jedem Segment und die Anzahl der Kopien in jedem Segment angeben, anstatt ein Präfixsummenformat zu verwenden, um die Eingabepositionen, die Ausgabepositionen und den Kopierindex zu identifizieren. Der Dekomprimierer 114 kann identifizierte Segmente der komprimierten Daten 106 parallel dekomprimieren. Beispielsweise kann der Dekomprimierer 114 unter Verwendung der Bezeichner aus den Metadaten 112 verschiedenen Threads einer GPU Teile oder Abschnitte der komprimierten Daten 106 zuweisen, die den Segmenten entsprechen. Ein erster Durchlauf des Dekomprimierers 114 durch jedes Segment der komprimierten Daten 106 kann ausgeführt werden, um dekomprimierte Buchstabensymbole (z. B. tatsächliche Symbole) aus den komprimierten Daten 106 direkt in den Ausgabestrom auszugeben (z. B. an einer durch die Metadaten identifizierten Position) und die Kopier- oder Übereinstimmungsinformation in einer separaten Warteschlange für eine spätere Verarbeitung (z. B. in einem zweiten Durchlauf durch den Dekomprimierer 114) zu speichern, wobei in dem Ausgabestrom Platz für die Kopien freigehalten wird. Der Umfang des in dem Ausgabestrom freigehaltenen Platzes kann anhand der Metadaten 112 bestimmt werden. Diese in die Warteschlange gestellten Kopien oder Übereinstimmungen können hier als zeitversetzte Kopien bezeichnet werden.
  • Nachdem die zurückgestellten Kopien in die Warteschlange gestellt und Platzhalter in dem Ausgabestrom erzeugt wurden, kann der Dekomprimierer 114 einen zweiten Durchlauf durch die zurückgestellten Kopien durchführen. Eine oder mehrere der Kopien können parallel ausgeführt werden, je nachdem, ob das Kopieren jeder Kopie als sicher eingestuft wird (z. B. wenn die zu kopierenden Daten bereits dekomprimiert wurden oder nicht auf einer anderen, noch zu kopierenden Kopie beruhen, kann die Kopie als sicher eingestuft werden). So kann der Dekomprimierer 114 beispielsweise in der Abfolge der Kopien nach weiteren Kopien suchen, die parallel ausgeführt werden können. Die Fähigkeit, Kopien parallel zu verarbeiten, kann anhand der Metadaten 112 und/oder der den Kopien entsprechenden Informationen bestimmt werden. Beispielsweise kann eine Ausgabeposition der Kopie innerhalb des Ausgabestroms (wie sie aus den Metadaten 112 bestimmt wird), eine Ursprungsposition, von der aus die Kopie zu erstellen ist (wie sie aus der codierten Abstandsinformation für die Kopie bestimmt wird), und/oder eine Länge der Kopie (wie sie aus der codierten Längeninformation für die Kopie bestimmt wird) verwendet werden, um zu bestimmen, ob eine Kopie für die parallele Verarbeitung mit einer oder mehreren anderen Kopien sicher ist oder nicht. Eine Kopie kann sicher für die parallele Ausführung mit einer anderen Kopie sein, wenn der Ursprung vor dem aktuellen Ausgabecursor endet und die Kopie sich nicht überschneidet. Als Beispiel, das auf einem Versuch basiert, kann die Anzahl der gleichzeitig kopierten Bytes von 3-4 auf 90-100 oder mehr erhöht werden. Dieses Verfahren bietet beträchtliche zusätzliche Möglichkeiten für eine Parallelität sowohl zwischen Threads als auch für eine Speichersystem-Parallelität innerhalb eines einzelnen Threads. So können eine oder mehrere der Kopien (z. B. Intra-Block-Kopien oder Inter-Block-Kopien) parallel zu einer oder mehreren anderen Kopien ausgeführt werden. Beispiele für sichere und unsichere Kopien zur parallelen Ausführung werden in den 2E-2F beschrieben. Darüber hinaus können bei einigen Ausführungsformen Symbole innerhalb einer einzelnen Kopie parallel ausgeführt bzw. kopiert werden. Wenn beispielsweise eine Kopie eine Länge von mehr als eins hat, können die einzelnen Symbole innerhalb der Kopie unter Verwendung von zwei oder mehr Threads (oder Koprozessoren) einer GPU parallel (in Bytes) des bzw. den Ausgabestrom kopiert werden.
  • Infolgedessen kann der Dekomprimierer 114 jedes der Symbole an den Ausgabestrom ausgeben, indem er einen ersten Durchlauf der komprimierten Daten 106 zur Ausgabe der Zeichen bzw. Buchstabensymbole und einen zweiten Durchlauf der Kopien zur Ausgabe der Zeichen bzw. Symbole aus den Kopien ausführt. Das Ergebnis kann ein Ausgabestrom sein, der den Daten 102 entspricht, die ursprünglich von dem Komprimierer 104 komprimiert wurden. In Beispielen, in denen verlustfreie Komprimierungstechniken verwendet werden, können die ausgegebenen Daten 102 identisch oder im Wesentlichen identisch mit den in den Komprimierer 104 eingegebenen Daten 102 sein.
  • Bei einigen Ausführungsformen kann ein Binärbaum-Suchalgorithmus mit einer gemeinsam genutzten Speichertabelle auf den komprimierten Daten 106 ausgeführt werden, um eine Divergenz zwischen Threads zu vermeiden, die bei den typischen Implementierungen mit einem schnellen/langsamen Pfad in CPUbasierten Decodern oder Dekomprimierern auftreten würde. Bei herkömmlichen Implementierungen auf einer CPU kann beispielsweise ein großes Datenfeld verwendet werden, um eine bestimmte Anzahl von Bits auf einmal zu decodieren. Beim DEFLATE-Format kann jedes Symbol zwischen 1 und 15 Bits lang sein, so dass der Dekomprimierer bei der Decodierung der Daten möglicherweise nicht sofort erkennt, wie lang jedes Symbol ist. Infolgedessen nehmen CPU-Dekomprimierer ein Bit, um festzustellen, ob es sich um ein Symbol der Länge 1 handelt, dann ein weiteres Bit, um festzustellen, ob es sich um ein Symbol der Länge 2 handelt, und so weiter, bis die tatsächliche Anzahl der Bits für ein Symbol ermittelt ist. Diese Aufgabe kann zeitaufwendig sein und den Dekomprimierungsvorgang selbst bei CPU-Implementierungen verlangsamen. Daher wurde in einigen Ansätzen ein Verfahren zur gleichzeitigen Analyse mehrerer Bits, z. B. 15 Bits, eingeführt. Bei solchen Ausführungsformen können 15 Bits aus dem komprimierten Datenstrom entnommen werden, und anhand einer Nachschlagetabelle kann ermittelt werden, welchem Symbol die Daten entsprechen. Dieses Verfahren ist jedoch verschwenderisch, da das gleitende Fenster nur 32kb groß sein kann, das System aber 15 Bits für die Analyse speichern muss, selbst wenn ein Symbol nur in 2 Bits komprimiert ist. Daher kann in einigen Implementierungen ein Verfahren mit einem schnellen/langsamen Pfad verwendet werden, bei der 8 Bits extrahiert werden, eine Symbolsuche für die 8 Bits durchgeführt wird, und wenn das Symbol kürzer als 8 Bits ist, der schnelle Pfad verwendet wird, und wenn das Symbol größer als 8 Bits ist, der langsame Pfad verwendet wird, um zu bestimmen, welches Symbol durch die Daten dargestellt wird. Dieses Vorgehen ist ebenfalls zeitaufwendig und verringert die Laufzeit des Systems zur Dekomprimierung der komprimierten Daten 106.
  • Bei (einer) GPUs wird/werden bei einem Verfahren mit schnellem/langsamem Pfad, bei dem eine bestimmte Anzahl von Threads (z. B. 32) auf einer bestimmten Anzahl von Symbolen (z. B. 32) ausgeführt wird, einige auf den schnellen Pfad und einige auf den langsamen Pfad treffen und gemischt in einem Warp (z. B. bei 32 Segmenten) sein, was ineffizient ist. Um dieses Problem zu lösen, kann ein binärer Suchalgorithmus verwendet werden, um die Effizienz zu verbessern. Die binäre Suche kann z. B. mit einer kleinen Tabelle mit 15 Einträgen ausgeführt werden, um festzustellen, zu welchem Eintrag der Tabelle ein Symbol gehört. Aufgrund der geringeren Größe des Feldes kann das Feld in einem gemeinsamen Speicher auf dem Chip gespeichert sein, was zu einer schnellen Suche auf einer GPU führen kann. Darüber hinaus kann die Verwendung eines binären Suchalgorithmus allen Threads die Ausführung desselben Codes ermöglichen, auch wenn sie unterschiedliche Abschnitte des Feldes im gemeinsamen Speicher betrachten. Infolgedessen kann der Speicherverkehr reduziert werden, da eine binäre Suche bei einem Symbol der Länge 8 prüfen kann, ob das Symbol länger als 8 Bit oder kürzer als 8 Bit ist. Darüber hinaus kann eine oder können mehrere (z. B. zwei) der obersten Ebenen des binären Baums in Datenregistern zwischengespeichert bzw. cached sein, um die Anzahl der Zugriffe auf den gemeinsamen Speicher pro Suchvorgang (z. B. von 5 auf 3) zu verringern. Infolgedessen kann der erste von vier Zugriffen immer derselbe sein, so dass nicht jedes Mal aus dem Speicher geladen werden muss, sondern ein Register auf der GPU aktiv gehalten werden kann. Der nächste kann 4 oder 12 sein, und anstatt eine weitere Ebene des Speicherzugriffs zu haben, kann das System wählen, ob es das Symbol-4-Register oder das Symbol-12-Register betrachtet, und dies kann die Gesamtzahl der Zugriffe um 2 oder mehr reduzieren (z. B. normalerweise 4 für die binäre Suche, um die Länge zu erhalten, und einen weiteren, um das eigentliche Symbol zu erhalten, so dass dieser Prozess von 4 plus 1 auf 2 plus 1 reduziert wird). Anstatt einen Eintrag zu laden und dann das Symbol zu verschieben, mit dem verglichen werden soll, wird das Symbol selbst vorab verschoben.
  • Bei einigen Ausführungsformen kann der Eingabestrom der komprimierten Daten 106 zusätzlich verschoben oder verschachtelt werden. Da beispielsweise ein Block der komprimierten Daten 106 durch den Analysator 108 für komprimierte Daten in eine bestimmte Anzahl von Segmente (z. B. 32) unterteilt werden kann, kann jeder Thread aus einem anderen Teil des Stroms lesen. Infolgedessen kann der Eingabestrom an den Segmentgrenzen (z. B. unter Verwendung der Metadaten 112) in einem Vorprozess verschachtelt werden, um die Lokalisierung beim Lesen der Daten zu verbessern. Entsprechen die Daten 102 beispielsweise einer tatsächlichen Zuordnungstabelle bzw. Wörterbuch, das alle Wörter einer bestimmten Sprache aufweist, kann ein Thread die Wörter lesen, die mit dem Buchstaben „A“ beginnen, ein anderer die mit dem Buchstaben „D“, ein weiterer die mit dem Buchstaben „P“ usw. Um dieses Problem abzumildern, können die Daten so umformatiert werden, dass alle Threads aus einem benachbarten Speicher lesen können. Beispielsweise können die komprimierten Daten 106 mit Hilfe von Informationen aus einem Index so verschachtelt werden, dass jeder Thread aus ähnlichen Cache-Zeilen lesen kann. So können die Daten gemischt werden, so dass die Threads bei der Verarbeitung der Daten eine gewisse Ähnlichkeit in den Daten haben, obwohl die Daten unterschiedlich sind. Bei einem Spielkartenbeispiel kann das Mischen oder Verschachteln der Daten es jedem Thread ermöglichen, Karten mit denselben Zahlen oder Zeichen zu verarbeiten, auch wenn sie eine andere Farbe aufweisen.
  • Als weiteres Beispiel, etwa wenn die Segmente unter Verwendung von Threads eines Warp einer GPU verarbeitet werden, kann eine Warp-synchrone Daten parallele Schleife ausgeführt werden, um die Zuordnungstabelle zu laden und zu verarbeiten. Beispielsweise kann das System unter Verwendung eines Index und eines datenparallelen Algorithmus die Zuordnungstabelleneinträge parallel verarbeiten. Bei der seriellen Verarbeitung kann das System prüfen, wie viele Symbole der Länge 2, der Länge 3 usw. existieren. Anstatt diese Berechnungen jedoch seriell durchzuführen, kann das System einen Datenalgorithmus ausführen, um - parallel - zu rechnen oder einen Thread jedem Symbol zuzuweisen, dann zu melden, ob die Symbole eine bestimmte Länge aufweisen, und dann eine Warp-Reduzierung bezüglich der Gesamtzahl der Warps auszuführen. Wenn beispielsweise 286 Symbole zu analysieren sind (z. B. 0-255 Bytes, 256 Blockende, 257-286 für unterschiedliche Längen), kann jedes der 286 Symbole parallel analysiert werden.
  • Die in den 2A-2F beschriebenen Beispiele beziehen sich auf Daten, die nach dem DEFLATE-Komprimierungsformat komprimiert wurden, und auf die entsprechenden Metadaten 112. Wie es hier beschrieben ist, können die Vorgehen der vorliegenden Offenbarung für jede Art von Datenkomprimierungsformat implementiert oder angewendet werden, wie z. B., aber nicht beschränkt auf die hier beschriebenen Formate.
  • 2A zeigt eine beispielhafte Tabelle 200A, die den Metadaten 112 für die parallele Dekomprimierung von komprimierten Datenströmen gemäß einigen Ausführungsformen der vorliegenden Offenbarung entspricht. Zum Beispiel können die Daten 102 (oder ein Abschnitt davon, wie ein Block davon) dem Wort „Mississippi“ entsprechen. Der Komprimierer 104 kann die Daten 102 gemäß dem DEFLATE-Komprimierungsalgorithmus komprimieren, um eine komprimierte Version der Daten 102 (z. B. die komprimierten Daten 106) zu erzeugen, die als „Miss<Kopierlänge 4, Abstand 3>ppi“ dargestellt wird. Darüber hinaus können die komprimierten Daten 106 Huffman-codiert sein, so dass die verschiedenen Symbole durch eine Anzahl von Bits dargestellt werden können, die einer Prioritäts- oder Frequenzbewertung durch den Komprimierer 104 entsprechen. Als nicht einschränkendes Beispiel kann „M“ durch 3 Bits dargestellt werden, die Kopie kann durch 4 Bits dargestellt werden (z. B. 3 Bits für die Länge und 1 Bit für den Abstand), und „i“, „s“ und „p“ können jeweils durch 2 Bits in den komprimierten Daten 106 dargestellt werden. Unter der Annahme, dass in diesem Beispiel Blöcke der komprimierten Daten 106 in vier Segmente unterteilt sind (z. B. ein 4-Wege-Index), kann der Analysator 108 für komprimierte Daten die komprimierten Daten 106 analysieren, um ein erstes Segment, das „Mi“ aufweist, ein zweites Segment, das „ss“ aufweist, ein drittes Segment, das die Kopie und „p“ aufweist, und ein viertes Segment, das „pi“ aufweist, zu bestimmen. Beispielsweise kann „Mississippi“ mit elf Zeichen odschneider Symbolen in acht Symbole aufgeteilt werden (z. B. sieben Buchstabensymbole und eine Kopie), und die Segmente können so erzeugt werden, dass sie im Wesentlichen gleich groß sind. Allerdings kann das vierte Segment aufgrund der ungeraden Anzahl von Symbolen nur ein Symbol aufweisen. Der Analysator 108 für komprimierte Daten kann dann die Anzahl der Ausgaben (oder Ausgabebytes) für jedes Segment, die Anzahl der Eingaben (oder Eingabebits) für jedes Segment und/oder die Anzahl der Kopien in jedem Segment bestimmen. Bei einigen Beispielen kann der Metadatengenerator 110 diese Informationen direkt verwenden, um die Metadaten 112 zu erzeugen. In anderen Beispielen kann jedoch eine Präfixsummenoperation auf diesen Daten ausgeführt werden, um die Metadaten 112 gemäß Tabelle 200B zu erzeugen.
  • In Bezug auf 2B zeigt 2B eine beispielhafte Tabelle 200B, die den Metadaten 112 in einem Präfixsummenformat für die parallele Dekomprimierung von komprimierten Datenströmen gemäß einigen Ausführungsformen der vorliegenden Offenbarung entspricht. Beispielsweise kann jedes Segment anstelle einer Anzahl von Ausgaben durch die Ausgabeposition innerhalb des Ausgabestroms identifiziert werden, um dem Dekomprimierer 114 anzuzeigen, wo die Ausgabe der dekomprimierten Symbole aus dem Segment beginnen soll. Anstelle einer Anzahl von Eingaben kann die Eingabeposition innerhalb des komprimierten Datenstroms identifiziert werden, um dem Dekomprimierer 114 anzuzeigen, wo mit der Dekomprimierung des Segments begonnen werden soll, so dass das Segment einem eindeutigen Thread der GPU zur parallelen Verarbeitung zugewiesen werden kann. Darüber hinaus kann in den Metadaten 112 anstelle einer Anzahl von Kopien in jedem Segment eine laufende Gesamtzahl von Kopien aus früheren Segmenten des Blocks angegeben werden, um dem Dekomprimierer mitzuteilen, welche Kopie der jeweiligen zurückgestellten Kopie in der Warteschlange entspricht. Letztendlich kann in diesem Beispiel das Präfixsummenformat der Metadaten 112 dem Dekomprimierer 114 anzeigen, dass es innerhalb des Inhaltsabschnitts des aktuellen Blocks (oder Datenabschnitts) der komprimierten Daten 11 Bytes der Ausgabe, 19 Bits der Eingabe und eine Kopie gibt, und kann angeben, wo jedes Segment in den komprimierten Daten 106 beginnt, wo jedes Segment auszugeben ist, und/oder den Kopierindex angeben.
  • Unter Bezugnahme auf 2C zeigt 2C gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle 200C, die einer Zuordnungstabelle und den damit verbundenen Metadaten 112 entspricht. Beispielsweise kann unter Verwendung der gleichen Anzahl von Bits für die Symbole, wie es hier in Bezug auf die 2A und 2B beschrieben ist (z. B. unter Verwendung der Huffman-Codierung), die Zuordnungstabelle erstellt werden, um diese Werte anzugeben. In diesem Beispiel kann die Zuordnungstabelle den Klein- und Großbuchstaben des englischen Alphabets entsprechen. Dies ist jedoch nicht als Einschränkung gedacht, und die Zuordnungstabelle kann allen Arten von Symbolen entsprechen, einschließlich Zeichen einer beliebigen Sprache, Zahlen, Sondersymbolen (z. B. !, $, *, ^ und/oder andere Symboltypen) usw. Da die komprimierten Daten 106 nur mit M, i, s und p korrespondieren, kann der Zuordnungstabellenabschnitt der komprimierten Daten 106 komprimiert werden, um diese Werte anzugeben. In einem solchen Beispiel kann die Datenfolge 202 die Daten 102, die mit der Zuordnungstabelle korrespondieren, darstellen, wobei jedes der 52 Zeichen (z. B. A-Z und a-z) durch einen Wert dargestellt ist, der einer Anzahl von Bits entspricht. Um die Zuordnungstabelle weiter zu komprimieren, kann der Komprimierer 104 Füll- oder Kopiersymbole erzeugen, die sich wiederholenden Werten aus der Datenfolge 202 entsprechen. In diesem Fall sind die sich wiederholenden Werte die Nullen, so dass die komprimierten Daten 106, die der Zuordnungstabelle entsprechen, durch „<fill 12x>3<fill 21x>2<fill 6x>2002<fill 7x>“ dargestellt werden können. Der Analysator 108 für komprimierte Daten kann die komprimierten Daten 106, die der Zuordnungstabelle entsprechen, analysieren und Segmentunterbrechungen bestimmen (z. B. können in dem Beispiel, in dem vier Segmente verwendet werden, die komprimierten Daten 106 in vier Segmente aufgeteilt werden). Die Aufteilung der vier Segmente ist durch die gestrichelten Linien gekennzeichnet. Der Metadatengenerator 110 kann dann die Segmentinformationen analysieren, um die Metadaten 112 zu erzeugen, die dem Zuordnungstabellenabschnitt des Blocks der komprimierten Daten 106 entsprechen - z. B. um die Starteingabeposition und die Symbolnummer oder den Symbolindex jedes Segments in der Zuordnungstabelle anzugeben.
  • Mit Bezug zu 2D ist in 2D gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle 200D dargestellt, die den Metadaten 112 für die parallele Dekomprimierung von Blöcken eines komprimierten Datenstroms entspricht. Wenn es sich bei den Daten 102 beispielsweise um „MississippiMississippiMiss“ handelt, kann der Komprimierer 104 die Daten 102 zur Komprimierung in zwei Blöcke aufteilen: einen ersten Block, der „Mississippi“ entspricht, und einen zweiten Block, der „MississippiMiss“ entspricht. Um die Positionen der verschiedenen Blöcke innerhalb der komprimierten Daten 106 - und die ihnen entsprechenden Zuordnungestabellen - zu identifizieren, kann der Analysator 108 für komprimierte Daten die komprimierten Daten 106 analysieren, um die anfängliche Eingabeposition (z. B. ein erstes Eingabe-Bit, -Nibble, -Byte usw.) jedes Blocks der komprimierten Daten 106 und/oder die anfängliche Ausgabeposition (z. B. ein erstes Bit, Nibble, Byte usw.) jedes Blocks in dem Ausgabestrom zu bestimmen. Folglich können die Metadaten 112, die einem Strom komprimierter Daten 106 entsprechen, eine Anzahl von Eingaben (z. B. Bits, Nibbles, Bytes usw.) und eine Anzahl von Ausgaben (z. B. Bits, Nibbles, Bytes usw.) für jeden Block der komprimierten Daten 106, eine Anzahl von Eingaben (z. B, Bits, Nibbles, Bytes usw.) und eine Symbolnummer für jedes Segment innerhalb jedes Blocks und/oder eine Anzahl von Eingaben (z. B. Bits, Nibbles, Bytes usw.), eine Anzahl von Ausgaben (z. B. Bits, Nibbles, Bytes usw.) und eine Anzahl von Kopien für jedes Segment innerhalb jedes Blocks angeben. Wenn eine Präfixsummenoperation ausgeführt wird, können die Metadaten 112 stattdessen die anfängliche Eingabeposition und die anfängliche Ausgabeposition jedes Blocks der komprimierten Daten, eine anfängliche Eingabeposition und einen Symbolindex für jedes Segment des Zuordnungstabellenabschnitts für jeden Block und/oder eine anfängliche Eingabeposition, eine anfängliche Ausgabeposition und einen Kopierindex für jedes Segment des Inhaltsabschnitts für jeden Block (oder Datenabschnitt) aufweisen. Bei weiteren Ausführungsformen kann darüber hinaus eine Kombination von zwei unterschiedlichen Metadatenformaten verwendet werden, so dass die Metadaten für einen oder mehrere der Blöcke, Zuordnungstabellen oder Daten im Präfixsummenformat vorliegen, während einer oder mehrere der Blöcke, Zuordnungstabellen oder Daten nicht im Präfixsummenformat vorliegen.
  • Die Metadaten 112 können dann von dem Dekomprimierer 114 verwendet werden, um die komprimierten Daten 106 zu dekomprimieren. Zum Beispiel kann jeder Block der komprimierten Daten 106 unter Verwendung der Metadaten 112 identifiziert werden, so dass zwei oder mehr Blöcke der komprimierten Daten 106 parallel dekomprimiert werden können - z. B. Block A und Block B. Für jeden Block können die Metadaten 112 verwendet werden, um die Segmente der Zuordnungstabelle zu bestimmen, so dass die Zuordnungstabelle parallel dekomprimiert werden kann - z. B. ein Segment pro Thread oder Koprozessor. Die Zuordnungstabelle kann dann verwendet werden, um den Inhaltsabschnitt des komprimierten Datenstroms zu dekomprimieren. Beispielsweise können die Metadaten 112 die Segmente des Inhaltsabschnitts der komprimierten Daten 106 angeben, und der Dekomprimierer 114 kann die Zuordnungstabelle verwenden, um die Buchstabensymbole aus den komprimierten Daten 106 zu decodieren und die Buchstabensymbole in den Ausgabestrom auszugeben. Der Dekomprimierer 114 kann darüber hinaus die Metadaten 112 und die in den komprimierten Daten 106 codierten Kopierinformationen verwenden, um Abschnitte des Ausgabestroms für Kopien zu reservieren und um eine Warteschlange oder Datenstruktur mit Informationen über jede Kopie (z. B. eine Ursprungsposition, einen Abstand, eine Länge usw.) zu füllen. Wie es hier beschrieben ist, können die Segmente des Inhaltsabschnitts der komprimierten Daten 106 parallel dekomprimiert werden. Nach der Dekomprimierung kann der Dekomprimierer 114 die Kopiervorgänge an den aufgeschobenen Kopien in der Warteschlange ausführen, um die reservierten Platzhalter in dem Ausgabestrom mit den entsprechenden kopierten Symbolen aufzufüllen. Als Beispiel und in Bezug auf 2A kann die Kopie von „issi“, die durch eine Ursprungsposition von 1, eine Kopierlänge von 4 und einen Abstand von 3 gekennzeichnet ist, verwendet werden, um „i“ an die Position 4, „s“ an die Position 5, „s“ an die Position 6 und „i“ an Position 7 zu kopieren. Das „i“ an Position 7 kann als Überlappungskopie bezeichnet werden, da das „i“ an Position 7 von dem „i“ an Position 4 kopiert wird, das bis zum Beginn des Kopiervorgangs nicht existierte. Wie es hier beschrieben ist, kann der einzelne Kopiervorgang bei einigen Ausführungsformen parallel ausgeführt werden, so dass zwei oder mehr der „issi“-Kopiervorgänge unter Verwendung verschiedener Threads der GPU parallel ausgeführt werden können.
  • Darüber hinaus können bei einigen Ausführungsformen separate Kopiervorgänge parallel ausgeführt werden, wenn die Kopiervorgänge als sicher eingestuft werden. Mit Bezug auf 2E zeigt 2E beispielsweise gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle 400E, die mit Kopien eines komprimierten Datenstroms korrespondiert, die nicht für eine parallele Verarbeitung geeignet sind. Wenn die komprimierten Daten 106 beispielsweise „MississippiMississippi“ entsprechen, können die komprimierten Daten 106 zwei Kopien aufweisen (z. B. copy #1 und copy #2, wie es in der Tabelle 200E angegeben ist). In diesem Beispiel kann der Dekomprimierer 114 bei der Ausführung oder während der Ausführung der ersten Kopie bestimmen, ob eine oder mehrere zusätzliche Kopien - z. B. die zweite Kopie - parallel ausgeführt werden können. Der Dekomprimierer 114 kann die Ursprungsposition der zweiten Kopie und die Ausgabeposition der ersten Kopie betrachten, um festzustellen, ob es eine Überschneidung gibt. Da die zweite Kopie auf die Ausgabe der ersten Kopie angewiesen ist, ist es in diesem Fall möglicherweise nicht sicher, die zweite Kopie parallel zu der ersten Kopie auszuführen. Daher sollten die erste Kopie und die zweite Kopie nacheinander ausgeführt werden.
  • Als weiteres Beispiel und unter Bezugnahme auf 2F zeigt 2F gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Tabelle 200F, die Kopien eines komprimierten Datenstroms entspricht, die für eine parallele Verarbeitung geeignet sind. Wenn die komprimierten Daten 106 beispielsweise „MississippiMiss“ entsprechen, können die komprimierten Daten 106 zwei Kopien aufweisen (z. B. copy #1 und copy #2, wie es in der Tabelle 200F angegeben ist). In diesem Beispiel kann der Dekomprimierer 114 bei der Ausführung oder während der Ausführung der ersten Kopie feststellen, ob eine oder mehrere zusätzliche Kopien - z. B. die zweite Kopie - parallel ausgeführt werden können. Der Dekomprimierer 114 kann die Ursprungsposition der zweiten Kopie und die Ausgabeposition der ersten Kopie betrachten, um festzustellen, ob es eine Überschneidung gibt. Da in diesem Fall die zweite Kopie nicht auf die Ausgabe der ersten Kopie angewiesen ist (z. B. weil die zweite Kopie ausgeführt werden kann, ohne dass Ergebnisse der ersten Kopie in den Ausgabepuffer eingetragen werden müssen), kann die zweite Kopie sicher parallel zu der ersten Kopie ausgeführt werden. Daher können die erste Kopie und die zweite Kopie parallel ausgeführt werden, wodurch Ausgaben von 8 Symbolen auf einmal anstelle von 4 und 4 nacheinander bereitgestellt werden.
  • Unter Bezugnahme auf die 3-4, umfasst jeder Block der Verfahren 300 und 400, wie es hier beschrieben ist, einen Rechenvorgang, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem oder mehreren Prozessoren ausgeführt werden, die im Speicher gespeicherte Anweisungen ausführen. Die Verfahren 300 und 400 können auch in Form von von einem Computer verwendbaren Anweisungen auf Computerspeichermedien gespeichert sein. Die Verfahren 300 und 400 können durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige zu nennen. Darüber hinaus werden die Verfahren 300 und 400 beispielhaft für das Verfahren 100 von 1 beschrieben. Diese Verfahren 300 und 400 können jedoch zusätzlich oder alternativ innerhalb eines beliebigen Verfahrens durch ein beliebiges System oder eine beliebige Kombination von Verfahren und Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen.
  • Unter Bezugnahme auf 3 zeigt 3 ein Flussdiagramm, das einem Verfahren 300 zur Erzeugung von Metadaten für einen komprimierten Datenstrom zum parallelen Dekomprimieren des komprimierten Datenstroms gemäß einigen Ausführungsformen der vorliegenden Offenbarung entspricht. Das Verfahren 300 weist im Block B302 ein Analysieren von komprimierten Daten auf. Zum Beispiel kann der Analysator 108 für komprimierte Daten die komprimierten Daten 106 analysieren.
  • Das Verfahren 300 weist im Block B304 ein Bestimmen von Abgrenzungen zwischen einer Vielzahl von Segmenten der komprimierten Daten auf. Zum Beispiel kann der Analysator 108 für komprimierte Daten Abgrenzungen zwischen Segmenten der komprimierten Daten 106 bestimmen.
  • Das Verfahren 300 weist im Block B306 zumindest teilweise auf der Grundlage der Abgrenzungen und für mindestens zwei Segmente der Vielzahl von Segmenten ein Erzeugen von Metadaten auf, die mit jedem Datensegment der mindestens zwei Datensegmente korrespondieren und die eine anfängliche Eingabeposition innerhalb der komprimierten Daten und eine anfängliche Ausgabeposition in Ausgabedaten angeben. Zum Beispiel kann der Metadatengenerator 110 die Metadaten 112, die mit den Segmenten korrespondieren, erzeugen, um die anfänglichen Eingabepositionen, die anfänglichen Ausgabepositionen und/oder den Kopierindex für einige oder alle Segmente des Inhaltsabschnitts jedes Blocks der komprimierten Daten 106 zu identifizieren.
  • Das Verfahren 300 weist im Block B308 ein Übertragen der komprimierten Daten und der Metadaten an einen Dekomprimierer auf. Zum Beispiel können die komprimierten Daten 106 und die Metadaten 112 von dem Dekomprimierer 114 verwendet werden, um die komprimierten Daten 106 zumindest teilweise parallel zu dekomprimieren.
  • Mit Bezug zu 4 ist in 4 ein Flussdiagramm dargestellt, das einem Verfahren 400 zur parallelen Dekomprimierung eines komprimierten Datenstroms gemäß einigen Ausführungsformen der vorliegenden Offenbarung entspricht. Das Verfahren 400 weist im Block B402 ein Empfangen von komprimierten Daten und den dazugehörigen Metadaten auf. Zum Beispiel kann der Dekomprimierer 114 die komprimierten Daten 106 und die Metadaten 112 empfangen.
  • Das Verfahren 400 weist in Block B404 auf der Grundlage der Metadaten ein Bestimmen einer anfänglichen Eingabeposition und einer anfängliche Ausgabeposition auf, die den komprimierten Daten entsprechen. Zum Beispiel können die Metadaten 112 eine anfängliche Eingabeposition in den komprimierten Daten 106 und eine anfängliche Ausgabeposition in dem Ausgabedatenstrom entsprechend jedem Block der komprimierten Daten 106 angeben.
  • Das Verfahren 400 weist im Block B406 auf der Grundlage der anfänglichen Eingabeposition und der anfänglichen Ausgabeposition ein Bestimmen einer Eingabe-Zuordnungstabellen-Position und eines Symbolindex für zwei oder mehr Zuordnungstabellensegmente einer Zuordnungstabelle der komprimierten Daten auf. Zum Beispiel können die Metadaten 112 eine anfängliche Eingabeposition und einen Symbolindex für Segmente der Zuordnungstabelle angeben, die den komprimierten Daten 106 entsprechen.
  • Das Verfahren 400 weist im Block B408 ein zumindest teilweises paralleles Dekomprimieren der Zuordnungstabelle auf der Grundlage der Eingabe-Zuordnungstabellen-Position auf. Beispielsweise können die Metadaten 112 die Segmente der Zuordnungstabelle angeben, und diese Information kann von dem Dekomprimierer 114 verwendet werden, um jedes Segment der Zuordnungstabelle unter Verwendung von Threads einer GPU parallel zu verarbeiten.
  • Das Verfahren 400 weist in Block B410 auf der Grundlage der anfänglichen Eingabeposition und der anfänglichen Ausgabeposition ein Bestimmen einer Eingabesegmentposition, einer Ausgabesegmentposition und eines Kopierindexwerts für mindestens zwei Segmente einer Vielzahl von Segmenten der komprimierten Daten auf. Beispielsweise kann der Dekomprimierer 114 die Metadaten 112 verwenden, um die anfängliche Eingabeposition in den komprimierten Daten 106, die anfängliche Ausgabeposition in dem Ausgabestrom und den Kopierindex (z. B. die Anzahl der Kopien in den Segmenten vor dem aktuellen Segment) für jedes Segment der komprimierten Daten 106 in einem Block oder Datenabschnitt zu bestimmen.
  • Das Verfahren 400 weist im Block B412 ein paralleles Dekomprimieren der mindestens zwei Segmente gemäß der Eingabesegmentposition und der Ausgabesegmentposition auf, um eine dekomprimierte Ausgabe zu erzeugen. Zum Beispiel kann der Dekomprimierer 114 die Metadaten 112 und die Zuordnungstabelle verwenden, um die Daten 102 aus den komprimierten Daten 106 zu erzeugen. Sobald die Daten 102 wiederhergestellt sind, können sie auf der Empfängerseite verwendet werden, um eine oder mehrere Operationen durchzuführen. Wurden die Daten 102 beispielsweise komprimiert und von einer CPU zur parallelen Verarbeitung an die GPU weitergeleitet, können die Daten anschließend an die CPU zurückgegeben werden. Handelt es sich bei den Daten 102 um Text, Nachrichten oder E-Mails, können die Daten auf einer Einrichtung - z. B. einer Benutzer- oder Client-Einrichtung - angezeigt werden. Handelt es sich bei den Daten 102 um ein Video, Audio, Bild usw., können die Daten über eine Anzeige, einen Lautsprecher, ein Headset, ein Ohrstück usw. ausgegeben werden. Handelt es sich bei den Daten 102 um eine Website, kann die Website in einem Browser auf der empfangenden Einrichtung - z. B. der Benutzer- oder Client-Einrichtung - angezeigt werden. Die dekomprimierten Daten können auf verschiedene Weise verwendet werden und sind aufgrund der parallelen Dekomprimierung schneller verfügbar, während sie im Vergleich zu herkömmlichen Ansätzen weniger Speicherressourcen benötigen.
  • BEISPIELHAFTE RECHENEINRICHTUNG
  • 5 ist ein Blockdiagramm (einer) beispielhaften/r Recheneinrichtung(en) 500, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist/sind. Die Recheneinrichtung 500 kann ein Verbindungssystem 502 aufweisen, das direkt oder indirekt die folgenden Einrichtungen koppelt: einen Speicher 504, eine oder mehrere Zentraleinheiten (CPUs) 506, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 508, eine Kommunikationsschnittstelle 510, Ein-/Ausgabeanschlüsse (E/A) 512, Ein-/Ausgabekomponenten 514, eine Stromversorgung 516, eine oder mehrere Präsentationskomponenten 518 (z. B. Display(s)) und eine oder mehrere Logikeinheiten 520. Bei mindestens einer Ausführungsform kann/können die Recheneinrichtung(en) 500 eine oder mehrere virtuelle Maschinen (VMs) umfassen, und/oder jede ihrer Komponenten kann virtuelle Komponenten umfassen (z. B. virtuelle Hardwarekomponenten). Als nicht einschränkende Beispiele können eine oder mehrere der GPUs 508 eine oder mehrere vGPUs umfassen, eine oder mehrere der CPUs 506 können eine oder mehrere vCPUs umfassen, und/oder eine oder mehrere der Logikeinheiten 520 können eine oder mehrere virtuelle Logikeinheiten umfassen. Als solche kann eine Recheneinrichtung 500 diskrete Komponenten (z.B. eine vollständige GPU, die für die Recheneinrichtung 500 reserviert ist), virtuelle Komponenten (z.B. einen Abschnitt einer GPU, der für die Recheneinrichtung 500 reserviert ist) oder eine Kombination davon aufweisen.
  • Obwohl die verschiedenen Blöcke von 5 als über das Verbindungssystem 502 mit Linien verbunden dargestellt sind, ist dies nicht als Einschränkung gedacht und dient nur der Klarheit. Bei einigen Ausführungsformen kann beispielsweise eine Präsentationskomponente 518, wie eine Anzeigeeinrichtung, als E/A-Komponente 514 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 506 und/oder GPUs 508 Speicher aufweisen (z. B. kann der Speicher 504 zusätzlich zum Speicher der GPUs 508, der CPUs 506 und/oder anderer Komponenten eine Speichereinrichtung darstellen). Mit anderen Worten, die Recheneinrichtung von 5 ist lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „in der Hand gehaltenes Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Einrichtungs- oder Systemtypen unterschieden, da alle im Rahmen der Recheneinrichtung von 5 in Betracht gezogen werden.
  • Das Verbindungssystem 502 kann eine oder mehrere Verbindungen oder Busse darstellen, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 502 kann einen oder mehrere Bus- oder Verbindungstypen aufweisen, wie z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express) und/oder eine andere Art von Bus oder Verbindung. Bei einigen Ausführungsformen gibt es direkte Verbindungen zwischen den Komponenten. So kann beispielsweise die CPU 506 direkt mit dem Speicher 504 verbunden sein. Darüber hinaus kann die CPU 506 auch direkt mit der GPU 508 verbunden sein. Bei direkten oder Punkt-zu-Punkt-Verbindungen zwischen Komponenten kann das Verbindungssystem 502 eine PCIe-Verbindung aufweisen, um die Verbindung herzustellen. In diesen Beispielen muss ein PCI-Bus nicht in der Recheneinrichtung 500 vorhanden sein.
  • Der Speicher 504 kann eine Vielzahl von computerlesbaren Medien aufweisen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die die Recheneinrichtung 500 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie entfernbare und nicht-entfernbare Medien aufweisen. Als Beispiel und ohne Einschränkung können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
  • Die Computerspeichermedien können sowohl flüchtige als auch nicht-flüchtige Medien und/oder entfernbare und nicht-entfernbare Medien aufweisen, die in einem beliebigen Verfahren oder einer Technologie zur Speicherung von Informationen, wie z.B. computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen, implementiert sind. Beispielsweise kann der Speicher 504 computerlesbare Anweisungen speichern (z. B. solche, die ein Programm bzw. Programme und/oder ein Programmelement bzw. Programmelemente darstellen, wie z. B. ein Betriebssystem. Computerspeichermedien können ein RAM, ein ROM, ein EEPROM, einen Flash-Speicher oder andere Speichertechnologien, eine CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium aufweisen, das zum Speichern der gewünschten Informationen verwendet werden kann und auf das die Recheneinrichtung 500 zugreifen kann, sind jedoch nicht darauf beschränkt. Wie es hierin verwendet wird, umfasst das Computerspeichermedium nicht per se Signale.
  • Die Computerspeichermedien können computerlesbare Anweisungen, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal, wie z. B. einer Trägerwelle oder einem anderen Transportmechanismus, ausgestalten und weisen beliebige Informationsübertragungsmedien auf. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder verändert wurden, dass Informationen in dem Signal codiert sind. Die Computerspeichermedien können beispielsweise verdrahtete Medien, wie ein verdrahtetes Netzwerk oder eine direkte Kabelverbindung, und drahtlose Medien, wie akustische, RF-, Infrarot- und andere drahtlose Medien, aufweisen und sind nicht auf diese beschränkt. Kombinationen der oben genannten Medien sollen ebenfalls in dem Anwendungsbereich der computerlesbaren Medien vorhanden sein.
  • Die CPU(s) 506 kann/können so ausgestaltet sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt/ausführen, um eine oder mehrere Komponenten der Recheneinrichtung 500 zu steuern, um eine oder mehrere der hier beschriebenen Verfahren und/oder Vorgehen durchzuführen. Die CPU(s) 506 kann/können jeweils einen oder mehrere Kerne aufweisen (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.), die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 506 kann/können jede Art von Prozessor aufweisen und je nach Art der implementierten Recheneinrichtung 500 verschiedene Arten von Prozessoren aufweisen (z. B. Prozessoren mit weniger Kernen für mobile Einrichtungen und Prozessoren mit mehr Kernen für Server). Je nach Art der Recheneinrichtung 500 kann der Prozessor beispielsweise ein Advanced RISC Machines (ARM)-Prozessor sein, der mit Reduced Instruction Set Computing (RISC) arbeitet, oder ein x86-Prozessor, der mit Complex Instruction Set Computing (CISC) arbeitet. Die Recheneinrichtung 500 kann eine oder mehrere CPUs 506 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Koprozessoren, wie z. B. mathematischen Koprozessoren, aufweisen.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 506 kann/können die GPU(s) 508 ausgestaltet sein, um zumindest einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Recheneinrichtung 500 zu steuern, um eine oder mehrere der hier beschriebenen Verfahren und/oder Vorgänge durchzuführen. Eine oder mehrere der GPU(s) 508 kann/können eine integrierte GPU sein (z. B. mit einer oder mehreren der CPU(s) 506), und/oder eine oder mehrere der GPU(s) 508 kann/können eine diskrete GPU sein. In Ausführungsformen kann eine oder können mehrere der GPU(s) 508 ein Koprozessor einer oder mehrerer der CPU(s) 506 sein. Der/die Grafikprozessor(en) 508 kann/können von der Recheneinrichtung 500 zum Rendern von Grafiken (z. B. 3D-Grafiken) oder zur Durchführung von Allzweckberechnungen verwendet werden. Die GPU(s) 508 kann/können beispielsweise für General-Purpose-Computing auf GPUs (GPGPU) verwendet werden. Die GPU(s) 508 kann/können Hunderte oder Tausende von Kernen aufweisen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 508 kann/können als Reaktion auf Rendering-Befehle (z. B. Rendering-Befehle von der/den CPU(s) 506, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 508 kann/können einen Grafikspeicher, z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, wie z. B. GPGPU-Daten, aufweisen. Der Anzeigespeicher kann als Teil des Speichers 504 vorhanden sein. Die GPU(s) 508 kann/können zwei oder mehr GPUs aufweisen, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt (z. B. mit NVLINK) oder über einen Switch (z. B. mit NVSwitch) verbinden. In Kombination kann jede GPU 508 Pixeldaten oder GPGPU-Daten für verschiedene Abschnitte einer Ausgabe oder für verschiedene Ausgaben erzeugen (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher aufweisen oder sich den Speicher mit anderen GPUs teilen.
  • Zusätzlich zu oder alternativ zu der (den) CPU(s) 506 und/oder der (den) GPU(s) 508 kann (können) die Logikeinheit(en) 520 so ausgestaltet sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt (ausführen), um eine oder mehrere Komponenten der Recheneinrichtung 500 zu steuern, um eine oder mehrere der hier beschriebenen Verfahren und/oder Vorgänge durchzuführen. In Ausführungsformen können die CPU(s) 506, die GPU(s) 508 und/oder die Logikeinheit(en) 520 diskret oder gemeinsam eine beliebige Kombination der Verfahren, Vorgänge und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 520 kann/können Teil einer oder mehrerer der CPU(s) 506 und/oder der GPU(s) 508 sein und/oder eine oder mehrere der Logikeinheiten 520 kann/können diskrete Komponenten sein oder anderweitig außerhalb der CPU(s) 506 und/oder der GPU(s) 508 liegen. In Ausführungsformen kann eine oder können mehrere der Logikeinheiten 520 ein Koprozessor einer oder mehrerer der CPU(s) 506 und/oder einer oder mehrerer der GPU(s) 508 sein.
  • Beispiele für die Logikeinheit(en) 520 weisen einen oder mehrere Verarbeitungskerne und/oder Komponenten davon auf, wie z. B. Tensor-Cores (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphics Processing Clusters (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), Tree Traversal Units (TTUs), Künstliche-Intelligenz-Beschleuniger (AlAs), Deep-Learning-Beschleuniger (DLAs), Arithmetik-Logik-Einheiten (ALUs), anwendungsspezifische integrierte Schaltungen (ASICs), Fließkomma-Einheiten (FPUs), Eingabe-/Ausgabe-Elemente (E/A), Peripheral-Component-Interconnect-Elemente (PCI) oder Peripheral-Component-Interconnect-Express-Elemente (PCle) und/oder dergleichen.
  • Die Kommunikationsschnittstelle 510 kann einen oder mehrere Empfänger, Sender und/oder Transceiver aufweisen, die es der Recheneinrichtung 500 ermöglichen, mit anderen Recheneinrichtungen über ein elektronisches Kommunikationsnetz zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 510 kann Komponenten und Funktionen aufweisen, um die Kommunikation über eine Reihe verschiedener Netzwerke zu ermöglichen, wie z.B. drahtlose Netzwerke (z.B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), verdrahtete Netzwerke (z.B. Kommunikation über Ethernet oder InfiniBand), Low-Power-Weitverkehrsnetzwerke (z.B. Lo-RaWAN, SigFox, etc.) und/oder das Internet.
  • Die E/A-Anschlüsse 512 können es der Recheneinrichtung 500 ermöglichen, logisch mit anderen Einrichtungen gekoppelt zu sein, einschließlich der E/A-Komponenten 514, der Präsentationskomponente(n) 518 und/oder anderer Komponenten, von denen einige in die Recheneinrichtung 500 eingebaut (z. B. integriert) sein können. Beispielhafte E/A-Komponenten 514 weisen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, eine Steuerung für Spiele, eine Satellitenschüssel, einen Scanner, einen Drucker, eine drahtlose Einrichtung usw. auf. Die E/A-Komponenten 514 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben eines Benutzers verarbeitet. In einigen Fällen können die Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie es unten ausführlicher beschrieben ist) in Verbindung mit einer Anzeige der Recheneinrichtung 500 implementieren. Die Recheneinrichtung 500 kann Tiefenkameras, wie z. B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, eine Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -steuerung aufweisen. Darüber hinaus kann die Recheneinrichtung 500 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) aufweisen, die die Erkennung von Bewegungen ermöglichen. Bei einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Recheneinrichtung 500 verwendet werden, um immersive Augmented Reality oder Virtual Reality darzustellen.
  • Die Stromversorgung 516 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon aufweisen. Die Stromversorgung 516 kann die Recheneinrichtung 500 mit Strom versorgen, um den Betrieb der Komponenten der Recheneinrichtung 500 zu ermöglichen.
  • Die Präsentationskomponente(n) 518 kann/können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Head-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten aufweisen. Die Präsentationskomponente(n) 518 kann/können Daten von anderen Komponenten (z. B. der/den GPU(s) 508, der/den CPU(s) 506 usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
  • BEISPIEL EINES RECHENZENTRUMS
  • 6 illustriert ein beispielhaftes Rechenzentrum 600, das bei mindestens einer Ausführungsform der vorliegenden Offenbarung verwendet werden kann. Das Rechenzentrum 600 kann eine Rechenzentrums-Infrastrukturschicht 610, eine Frameworkschicht 620, eine Softwareschicht 630 und/oder eine Anwendungsschicht 640 aufweisen.
  • Wie es in 6 gezeigt ist, kann die Infrastrukturschicht 610 des Rechenzentrums einen Ressourcen-Orchestrator 612, gruppierte Rechenressourcen 614 und Knoten-Rechenressourcen („NODE C.R.s“) 616(1)-616(N) aufweisen, wobei „N“ eine beliebige ganze, positive Zahl darstellt. Bei mindestens einer Ausführungsform können die Node C.R.s 616(1)-616(N) aufweisen, sind aber nicht darauf beschränkt, eine beliebige Anzahl von Zentraleinheiten („CPUs“) oder anderen Prozessoren (einschließlich Beschleunigern, feldprogrammierbaren Gate-Arrays (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Speichereinrichtungen (z. B. einen dynamischen Festwertspeicher), Speichergeräten (z. B. Festkörper- oder Festplattenlaufwerke), Netzwerk-Eingabe-/Ausgabeeinrichtungen („NW E/A“), Netzwerk-Switches, virtuelle Maschinen („VMs“), Stromversorgungsmodule und/oder Kühlmodule, usw. Bei einigen Ausführungsformen kann ein oder können mehrere Knoten-C.R.s unter den Knoten-C.R.s 616(1)-616(N) einem Server entsprechen, der über eine oder mehrere der oben erwähnten Rechenressourcen verfügt. Darüber hinaus können bei einigen Ausführungsformen die Knoten C.R.s 616(1)-6161 (N) eine oder mehrere virtuelle Komponenten aufweisen, wie z.B. vGPUs, vCPUs und/oder dergleichen, und/oder einer oder mehrere der Knoten C.R.s 616(1)-616(N) kann/können einer virtuellen Maschine (VM) entsprechen.
  • Bei mindestens einer Ausführungsform können die gruppierten Rechenressourcen 614 separate Gruppierungen von Knoten-C.R.s 616 aufweisen, die in einem oder mehreren Racks (nicht gezeigt) oder in vielen Racks untergebracht sind, die sich in Rechenzentren an verschiedenen geografischen Standorten befinden (ebenfalls nicht gezeigt). Separate Gruppierungen von Knoten-C.R.s 616 innerhalb der gruppierten Rechenressourcen 614 können gruppierte Rechen-, Netzwerk-, Speicher- oder Speicherressourcen aufweisen, die zur Unterstützung einer oder mehrerer Arbeitslasten ausgestaltet oder zugewiesen werden können. Bei mindestens einer Ausführungsform können mehrere Knoten-C.R.s 616, die CPUs, GPUs und/oder andere Prozessoren aufweisen, in einem oder mehreren Racks gruppiert sein, um Rechenressourcen zur Unterstützung einer oder mehrerer Arbeitslasten bereitzustellen. Das eine oder die mehreren Racks kann/können auch eine beliebige Anzahl von Stromversorgungsmodulen, Kühlmodulen und/oder Netzwerk-Switches in beliebiger Kombination aufweisen.
  • Der Ressourcen-Orchestrator 622 kann einen oder mehrere Knoten C.R.s 616(1)-616(N) und/oder gruppierte Rechenressourcen 614 konfigurieren oder anderweitig steuern. Bei mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 622 eine Software-Design-Infrastruktur („SDI“)-Verwaltungseinheit für das Rechenzentrum 600 aufweisen. Der Ressourcen-Orchestrator 622 kann Hardware, Software oder eine Kombination davon aufweisen.
  • Bei mindestens einer Ausführungsform, wie es in 6 gezeigt ist, kann die Frameworkschicht 620 einen Job Scheduler 632, einen Konfigurationsmanager 634, einen Ressourcenmanager 636 und/oder ein verteiltes Dateisystem 638 aufweisen. Die Frameworkschicht 620 kann ein Framework zur Unterstützung der Software 632 der Softwareschicht 630 und/oder eine oder mehrere Anwendung(en) 642 der Anwendungsschicht 640 aufweisen. Die Software 632 oder die Anwendung(en) 642 können jeweils webbasierte Dienstsoftware oder Anwendungen aufweisen, wie sie beispielsweise von Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt werden. Bei der Framework-Schicht 620 kann es sich um eine Art von freiem und quelloffenem Software-Webanwendungs-Framework wie Apache SparkTM (im Folgenden „Spark“) handeln, das ein verteiltes Dateisystem 638 für die Verarbeitung großer Datenmengen (z. B. „Big Data“) nutzen kann, ohne darauf beschränkt zu sein. Bei mindestens einer Ausführungsform kann der Job Scheduler 632 einen Spark-Treiber aufweisen, um die Planung von Arbeitslasten zu erleichtern, die von verschiedenen Schichten des Rechenzentrums 600 unterstützt werden. Der Konfigurationsmanager 634 kann in der Lage sein, verschiedene Schichten wie die Softwareschicht 630 und die Framework-Schicht 620 auszugestalten, die Spark und ein verteiltes Dateisystem 638 zur Unterstützung der Datenverarbeitung in großem Maßstab aufweisen. Der Ressourcenmanager 636 kann in der Lage sein, geclusterte oder gruppierte Computerressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 638 und des Job Schedulers 632 zugeordnet sind. Bei mindestens einer Ausführungsform können geclusterte oder gruppierte Rechenressourcen gruppierte Rechenressourcen 614 auf der Infrastrukturschicht 610 des Rechenzentrums aufweisen. Der Ressourcenmanager 1036 kann sich mit dem Ressourcen-Orchestrator 612 koordinieren, um diese zugeordneten oder zugewiesenen Computerressourcen zu verwalten.
  • Bei mindestens einer Ausführungsform kann die in der Softwareschicht 630 enthaltene Software 632 Software aufweisen, die von mindestens Abschnitten der Knoten-CRs 616(1)-616(N), der gruppierten Rechenressourcen 614 und/oder des verteilten Dateisystems 638 der Frameworkschicht 620 verwendet wird. Eine oder mehrere Arten von Software können Internet-Webseiten-Such-Software, E-Mail-Virenscan-Software, Datenbank-Software und Streaming-Video-Content-Software aufweisen, sind aber nicht darauf beschränkt.
  • Bei mindestens einer Ausführungsform kann (können) die in der Anwendungsschicht 640 enthaltene(n) Anwendung(en) 642 eine oder mehrere Arten von Anwendungen aufweisen, die von mindestens Abschnitten der Knoten C.R.s 616(1)-616(N), der gruppierten Rechenressourcen 614 und/oder des verteilten Dateisystems 638 der Frameworkschicht 620 verwendet werden. Eine oder mehrere Arten von Anwendungen können eine beliebige Anzahl von Genomanwendungen, kognitiven Berechnungen und Anwendungen für maschinelles Lernen aufweisen, einschließlich Trainings- oder Inferencing-Software, Framework-Software für maschinelles Lernen (z. B. PyTorch, TensorFlow, Caffe usw.) und/oder andere Anwendungen für maschinelles Lernen, die in Verbindung mit einer oder mehreren Ausführungsformen verwendet werden, sind jedoch nicht darauf beschränkt.
  • Bei mindestens einer Ausführungsform kann jeder von Konfigurationsmanager 634, Ressourcenmanager 636 und Ressourcen-Orchestrator 612 eine beliebige Anzahl und Art von selbstmodifizierenden Aktionen implementieren, die auf einer beliebigen Menge und Art von Daten basieren, die auf jede technisch machbare Weise erfasst werden. Selbstmodifizierende Aktionen können einen Rechenzentrumsbetreiber des Rechenzentrums 600 davon entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen, und kann möglicherweise nicht ausgelastete und/oder schlecht funktionierende Abschnitte eines Rechenzentrums vermeiden.
  • Das Rechenzentrum 600 kann Werkzeuge, Dienste, Software oder andere Ressourcen aufweisen, um ein oder mehrere maschinelle Lernmodelle zu trainieren oder Informationen unter Verwendung eines oder mehrerer maschineller Lernmodelle gemäß einer oder mehrerer Ausführungsformen, die hier beschrieben sind, vorherzusagen oder abzuleiten. Beispielsweise kann ein maschinelles Lernmodell bzw. können maschinelle Lernmodelle trainiert werden, indem Gewichtsparameter gemäß einer neuronalen Netzwerkarchitektur unter Verwendung von Software und/oder Computerressourcen berechnet werden, die oben in Bezug auf das Rechenzentrum 600 beschrieben wurden. Bei mindestens einer Ausführungsform können trainierte oder eingesetzte maschinelle Lernmodelle, die einem oder mehreren neuronalen Netzen entsprechen, verwendet werden, um Informationen abzuleiten oder vorherzusagen, wobei Ressourcen verwendet werden, die oben in Bezug auf das Rechenzentrum 600 beschrieben sind, indem Gewichtungsparameter verwendet werden, die durch eine oder mehrere Trainingstechniken berechnet werden, wie zum Beispiel, aber nicht beschränkt auf die hier beschriebenen.
  • Bei mindestens einer Ausführungsform kann das Rechenzentrum 600 CPUs, anwendungsspezifische integrierte Schaltungen (ASICs), GPUs, FPGAs und/oder andere Hardware (oder virtuelle Rechenressourcen, die diesen entsprechen) verwenden, um ein Training und/oder ein Inferencing unter Verwendung der oben beschriebenen Ressourcen durchzuführen. Darüber hinaus kann eine oder können mehrere der oben beschriebenen Software- und/oder Hardwareressourcen als Dienst ausgestaltet sein, um Benutzern das Training oder die Durchführung von Inferencing von Informationen zu ermöglichen, wie z. B. Bilderkennung, Spracherkennung oder andere Dienste der künstlichen Intelligenz.
  • BEISPIELHAFTE NETZWERKUMGEBUNGEN
  • Netzwerkumgebungen, die zur Verwendung bei der Implementierung von Ausführungsformen der Offenbarung geeignet sind, können eine oder mehrere Client-Einrichtungen, Server, Network Attached Storage (NAS), andere Backend-Einrichtungen und/oder andere Einrichtungstypen aufweisen. Die Client-Einrichtungen, Server und/oder andere Einrichtungstypen (z. B. jede Einrichtung) können auf einer oder mehreren Instanzen der Recheneinrichtung(en) 500 von 5 implementiert sein - z. B. kann jede Einrichtung ähnliche Komponenten, Merkmale und/oder Funktionalität der Recheneinrichtung(en) 500 aufweisen. Wenn Backend-Einrichtungen (z. B. Server, NAS usw.) implementiert sind, können die Backend-Einrichtungen außerdem als Teil eines Rechenzentrums 600 vorhanden sein, von dem ein Beispiel hier in Bezug auf 6 näher beschrieben ist.
  • Komponenten einer Netzwerkumgebung können über ein oder mehrere Netzwerke miteinander kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netzwerk kann mehrere Netzwerke oder ein Netzwerk von Netzwerken aufweisen. So kann das Netzwerk beispielsweise ein oder mehrere Wide Area Networks (WANs), ein oder mehrere Local Area Networks (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonnetz (PSTN) und/oder ein oder mehrere private Netzwerke aufweisen. Wenn das Netz ein drahtloses Telekommunikationsnetz aufweist, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Anschlussmöglichkeit bereitstellen.
  • Kompatible Netzwerkumgebungen können eine oder mehrere Peer-to-Peer-Netzwerkumgebungen - in diesem Fall kann ein Server nicht in einer Netzwerkumgebung enthalten sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzwerkumgebung enthalten sein - aufweisen. In Peer-to-Peer-Netzwerkumgebungen kann die hier beschriebene Funktionalität in Bezug auf einen oder mehrere Server auf einer beliebigen Anzahl von Client-Einrichtungen implementiert sein.
  • Bei mindestens einer Ausführungsform kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. aufweisen. Eine Cloud-basierte Netzwerkumgebung kann eine Frameworkschicht, einen Job Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem aufweisen, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kernnetzwerkserver und/oder Edge-Server aufweisen können. Eine Frameworkschicht kann ein Framework zur Unterstützung von Software einer Softwareschicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht aufweisen. Die Software oder die Anwendung(en) kann/können jeweils webbasierte Dienstsoftware oder Anwendungen aufweisen. In Ausführungsformen kann eine oder können mehrere der Client-Einrichtungen die webbasierte Dienstsoftware oder Anwendungen nutzen (z. B. durch Zugriff auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (APIs)). Bei der Frameworkschicht kann es sich um eine Art freies und quelloffenes Software-Webanwendungs-Framework handeln, das z. B. ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwenden kann, ohne darauf beschränkt zu sein.
  • Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder einen Cloud-Speicher bereitstellen, was eine beliebige Kombination der hier beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Abschnitte davon) ausführt. Jede dieser verschiedenen Funktionen kann über mehrere Standorte von zentralen oder Hauptservern (z. B. von einem oder mehreren Rechenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) verteilt sein. Befindet sich eine Verbindung zu einem Benutzer (z. B. eine Client-Einrichtung) relativ nahe an einem oder mehreren Edge-Servern, kann ein Hauptserver zumindest einen Abschnitt der Funktionalität dem oder den Edge-Servern zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat (z. B. auf eine einzelne Organisation beschränkt), öffentlich (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon (z. B. eine hybride Cloud-Umgebung) sein.
  • Die Client-Einrichtung(en) kann (können) zumindest einige der Komponenten, Merkmale und Funktionen der beispielhaften Recheneinrichtung(en) 500 aufweisen, wie es hier in Bezug auf 5 beschrieben ist. Als Ausführungsform und ohne Einschränkung kann eine Client-Einrichtung ein Personal Computer (PC), ein Laptop-Computer, ein mobiles Gerät, ein Smartphone, ein Tablet-Computer, eine Smartwatch, ein tragbarer Computer, ein Personal Digital Assistant (PDA), ein MP3-Player, ein Virtual-Reality-Headset, ein Global Positioning System (GPS) oder eine Einrichtung, ein Video-Player, eine Videokamera, eine Überwachungseinrichtung oder ein Überwachungssystem, ein Fahrzeug, ein Boot, ein fliegendes Luftschiff, eine virtuelle Maschine, eine Drohne, ein Roboter, ein in der Hand gehaltenes Kommunikationsgerät, ein Krankenhausgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Fahrzeugcomputersystem, eine eingebettete Systemsteuerung, eine Fernbedienung, ein Gerät, eine Unterhaltungselektronikeinrichtung, eine Workstation, eine Edge-Einrichtung, eine beliebige Kombination dieser beschriebenen Einrichtungen oder eine andere geeignete Einrichtung sein.
  • Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Befehlen beschrieben sein, die computerausführbare Befehle wie z. B. Programmmodule aufweisen, die von einem Computer oder einer anderen Maschine, wie z. B. einem persönlichen Datenassistenten oder einer anderen in der Hand gehaltenen Einrichtung, ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule, die Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw. aufweisen, auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen ausgeübt werden, die in der Hand gehaltene Geräte, Unterhaltungselektronik, Allzweckcomputer, speziellere Recheneinrichtungen usw. aufweisen. Die Offenbarung kann auch in verteilten Rechenumgebungen angewendet werden, in denen Tasks von entfernt arbeitenden Einrichtungen ausgeführt werden, die über ein Kommunikationsnetz miteinander verbunden sind.
  • Wie es hierin verwendet ist, sollte eine Erwähnung von „und/oder“ in Bezug auf zwei oder mehr Elemente so interpretiert werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C enthalten. Darüber hinaus kann „mindestens eines der Elemente A oder B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B enthalten. Ferner kann „mindestens eines der Elemente A und B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B enthalten.
  • Der Gegenstand der vorliegenden Offenbarung wird hier mit einer gewissen Genauigkeit beschrieben, um die gesetzlichen Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise ausgestaltet sein kann, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien aufzuweisen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden können, um verschiedene Elemente der angewandten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbarten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.

Claims (34)

  1. Verfahren umfassend: Empfangen von komprimierten Daten und den komprimierten Daten entsprechenden Metadaten; Bestimmen, zumindest teilweise auf der Grundlage der Metadaten, einer anfänglichen Eingabeposition und einer anfänglichen Ausgabeposition, welche den komprimierten Daten entsprechen; Bestimmen, zumindest teilweise auf der Grundlage der anfänglichen Eingabeposition und der anfänglichen Ausgabeposition, einer Eingabesegmentposition und einer Ausgabesegmentposition für mindestens zwei Segmente einer Vielzahl von Segmenten der komprimierten Daten; und Dekomprimieren der mindestens zwei Segmente parallel gemäß der Eingabesegmentposition und der Ausgabesegmentposition, um eine dekomprimierte Ausgabe zu erzeugen.
  2. Verfahren nach Anspruch 1, welches darüber hinaus umfasst: Bestimmen, zumindest teilweise auf der Grundlage der Metadaten, einer Eingabe-Zuweisungstabellen-Position und eines Symbolindexes für jedes Zuordnungstabellensegment einer Zuordnungstabelle des Blocks der komprimierten Daten; und Dekomprimieren der Zuordnungstabelle, wobei das Dekomprimieren der Vielzahl von Segmenten unter Verwendung der Zuordnungstabelle ausgeführt wird.
  3. Verfahren nach Anspruch 2, wobei das Dekomprimieren der Zuordnungstabelle parallel ausgeführt wird, so dass jedes Zuordnungstabellensegment der Zuordnung unter Verwendung eines entsprechenden Threads eines Prozessors dekomprimiert wird.
  4. Verfahren nach Anspruch 2 oder 3, welches darüber hinaus umfasst ein Bestimmen eines Kopierindexwertes für jedes Segment der Vielzahl von Segmenten der komprimierten Daten, zumindest teilweise auf der Grundlage der Metadaten.
  5. Verfahren nach einem der Ansprüche 2 bis 4, wobei die anfängliche Eingabeposition eine oder mehrere Blockeingabepositionen und die anfängliche Ausgabeposition eine oder mehrere Blockausgabepositionen für mindestens zwei Blöcke einer Vielzahl von Blöcken der komprimierten Daten angibt, wobei die Vielzahl von Segmenten einem einzelnen Block der Vielzahl von Blöcken entspricht.
  6. Verfahren nach Anspruch 5, wobei zwei oder mehr Blöcke der Vielzahl von Blöcken unter Verwendung von zwei oder mehr Prozessorressourcen parallel dekomprimiert werden.
  7. Verfahren nach Anspruch 6, wobei jeder Block der zwei oder mehr Blöcke unter Verwendung eines entsprechenden Warps einer Grafikverarbeitungseinheit (GPU) verarbeitet wird.
  8. Verfahren nach Anspruch 6, wobei das parallele Dekomprimieren der mindestens zwei Segmente ein paralleles Dekomprimieren jedes Segments unter Verwendung separater Verarbeitungsthreads eines Prozessors aufweist.
  9. Verfahren nach einem der Ansprüche 2 bis 8, wobei das Dekomprimieren der mindestens zwei Segmente ein Ausführen eines Durchlaufs über die Vielzahl von Segmenten aufweist, um ein oder mehrere Zeichen aus den komprimierten Daten in Ausgabedaten auszugeben, um in den Ausgabedaten Platz für eine oder mehrere Kopieroperationen zu reservieren und um eine Kopierinformation in einer Datenstruktur zu speichern.
  10. Verfahren nach Anspruch 9, wobei das Dekomprimieren der mindestens zwei Segmente ein Ausführen eines weiteren Durchlaufs über die eine oder die mehreren Kopieroperationen aufweist, um die eine oder die mehreren Kopieroperationen auszuführen und Symbole, welche mit der einen oder den mehreren Kopieroperationen korrespondieren, in den Ausgabestrom auszugeben.
  11. Verfahren nach Anspruch 10, wobei mindestens eine Kopieroperation der einen oder der mehreren Kopieroperationen parallel zu einer oder mehreren anderen Kopieroperationen der einen oder der mehreren Kopieroperationen ausgeführt wird.
  12. Verfahren nach Anspruch 10 oder 11, wobei ein erstes Symbol einer Kopieroperation parallel zu einem zweiten Symbol der Kopieroperation in die Ausgabe kopiert wird.
  13. Verfahren nach einem der vorhergehenden Ansprüche, wobei die komprimierten Daten mindestens eine variable Bitlänge zum Codieren von Symbolen innerhalb der komprimierten Daten oder eine variable Ausgabegröße für eine oder für mehrere in den komprimierten Daten codierte Kopieroperationen aufweisen.
  14. Verfahren nach einem der vorhergehenden Ansprüche, wobei die komprimierten Daten Daten entsprechen, die unter Verwendung eines Codierens mittels Zuordnungstabelle und/oder eines Entropiecodierens codiert sind.
  15. Verfahren umfassend: Analysieren von komprimierten Daten, um Abgrenzungen zwischen einer Vielzahl von Segmenten der komprimierten Daten zu bestimmen; Erzeugen, zumindest teilweise auf der Grundlage der Abgrenzungen und für mindestens zwei Segmente der Vielzahl von Segmenten, von Metadaten, welche eine anfängliche Eingabeposition innerhalb der komprimierten Daten und eine anfängliche Ausgabeposition in Ausgabedaten angeben, die jedem Datensegment der mindestens zwei Datensegmente entsprechen; und Übertragen der komprimierten Daten und der Metadaten an einen Dekomprimierer.
  16. Verfahren nach Anspruch 15, wobei die Metadaten darüber hinaus einen Kopierindex angeben, welcher den mindestens zwei Datensegmenten entspricht.
  17. Verfahren nach Anspruch 15 oder 16, welches darüber hinaus umfasst: Bestimmen, zumindest teilweise auf der Grundlage des Analysierens, von zusätzlichen Abgrenzungen zwischen Zuordnungstabellensegmenten einer Zuordnungstabelle, welche mit den komprimierten Daten korrespondiert; und Erzeugen zusätzlicher Metadaten, welche zumindest eine andere anfängliche Eingabeposition jedes Zuordnungstabellensegments der Zuordnungstabelle innerhalb der komprimierten Daten anzeigen, wobei das Übertragen darüber hinaus ein Übertragen der zusätzlichen Metadaten aufweist.
  18. Verfahren nach einem der Ansprüche 15 bis 17, welches darüber hinaus umfasst: Bestimmen zusätzlicher Abgrenzungen zwischen zusätzlichen Segmenten der komprimierten Daten zumindest teilweise auf der Grundlage des Analysierens; und Erzeugen zusätzlicher Metadaten, welche eine weitere anfängliche Eingabeposition jedes weiteren Segments der komprimierten Daten anzeigen, wobei das Übertragen darüber hinaus ein Übertragen der weiteren Metadaten aufweist.
  19. Verfahren nach einem der Ansprüche 15 bis 18, wobei die komprimierten Daten gemäß einem DEFLATE-Komprimierungsformat komprimiert werden, und das Verfahren darüber hinaus umfasst: Bestimmen weiterer Abgrenzungen innerhalb der komprimierten Daten zumindest teilweise auf der Grundlage des Analysierens; und Erzeugen zusätzlicher Metadaten, welche eine andere anfängliche Eingabeposition anzeigen, die den weiteren Abgrenzungen entspricht, wobei das Übertragen darüber hinaus ein Übertragen der weiteren Metadaten aufweist.
  20. Verfahren nach einem der Ansprüche 15 bis 19, wobei die komprimierten Daten einem Datenstrom mit einer variablen Eingabelänge und/oder einer variablen Ausgabelänge entsprechen.
  21. Verfahren nach einem der Ansprüche 15 bis 20, wobei die komprimierten Daten mit einem Lempel-Ziv-Algorithmus und/oder mit einem Huffman-Codieren komprimiert werden.
  22. Verfahren nach einem der Ansprüche 15 bis 21, wobei die komprimierten Daten unter Verwendung von einem arithmetischen Codieren und/oder einem Entropiecodieren komprimiert werden.
  23. Verfahren nach einem der Ansprüche 15 bis 22, wobei die komprimierten Daten eine variable Bitlänge zum Codieren von Symbolen innerhalb der komprimierten Daten und/oder eine variable Ausgabegröße für eine oder mehrere in den komprimierten Daten codierte Kopieroperationen aufweisen.
  24. Verfahren nach einem der Ansprüche 15 bis 23, wobei mindestens ein Abschnitt der Metadaten in einem Präfixsummenformat codiert ist.
  25. System umfassend: einen oder mehrere Prozessoren; eine oder mehrere Speichereinrichtungen, in denen Anweisungen gespeichert sind, welche, wenn sie unter Verwendung des einen oder der mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, zu instanziieren: einen Analysator für komprimierte Daten, um Segmente von komprimierten Daten zu identifizieren; einen Metadatengenerator, um zumindest teilweise auf der Grundlage der identifizierten Segmente Metadaten zu erzeugen, welche eine anfängliche Eingabeposition, eine anfängliche Ausgabeposition und einen Kopierindex für jedes identifizierte Segment der identifizierten Segmente der komprimierten Daten angeben; und einen Dekomprimierer um: die komprimierten Daten und die Metadaten zu empfangen; die identifizierten Segmente unter Verwendung von Threads eines Prozessors parallel und gemäß den Metadaten zu verarbeiten; zumindest teilweise basierend auf der Verarbeitung Zeichensymbolen an eine Ausgabe und eine Kopierinformation an eine Warteschlange für verzögerte Kopien auszugeben; und die Kopierinformation zu verarbeiten, um kopierte Symbole in die Ausgabe auszugeben.
  26. System nach Anspruch 25, welches darüber hinaus einen Komprimierer umfasst, um die komprimierten Daten aus einem Eingabedatenstrom zu erzeugen.
  27. System nach Anspruch 25 oder 26, wobei das Verarbeiten der Kopierinformation ein Verarbeiten einer ersten Kopieroperation parallel zu einer zweiten Kopieroperation aufweist.
  28. System nach einem der Ansprüche 25 bis 27, wobei das Verarbeiten der Kopierinformation ein Verarbeiten eines ersten Symbols einer Kopieroperation parallel zu einem zweiten Symbol der Kopieroperation aufweist.
  29. System nach einem der Ansprüche 25 bis 28, wobei: der Analysator für komprimierte Daten darüber hinaus dazu dient, um Blöcke innerhalb der komprimierten Daten zu identifizieren; und wobei die identifizierten Segmente einem Block aus zwei oder mehr Segmenten entsprechen.
  30. System nach einem der Ansprüche 25 bis 29, wobei: der Analysator für komprimierte Daten darüber hinaus dazu dient, Zuordnungstabellensegmente einer Zuordnungstabelle zu identifizieren, welche den identifizierten Segmenten entsprechen; die Metadaten darüber hinaus eine anfängliche Zuordnungstabellenposition der Zuordnungstabellensegmente angeben; die Zuordnungstabellensegmente parallel verarbeitet werden, um die Zuordnungstabelle zu erzeugen; und das Verarbeiten der identifizierten Segmente zumindest teilweise auf der Zuordnungstabelle basiert.
  31. System nach Anspruch 30, wobei die Zuordnungstabelle zumindest teilweise auf der Grundlage eines ersten Codierungsdurchgangs erzeugt wird, welcher auf dem komprimierten Datenstrom durchgeführt wird, und wobei die Zuordnungstabelle zumindest teilweise auf der Grundlage eines zweiten Codierungsdurchgangs komprimiert wird, welcher auf einer komprimierten Version der Zuordnungstabelle durchgeführt wird.
  32. System nach einem der Ansprüche 25 bis 31, wobei die komprimierten Daten eine variable Bitlänge zum Codieren von Symbolen innerhalb der komprimierten Daten und/oder eine variable Ausgabegröße für in den komprimierten Daten codierte Kopien aufweisen.
  33. System nach einem der Ansprüche 25 bis 32, wobei das System mindestens eines umfasst von: einem Steuerungssystem für eine autonome oder halbautonome Maschine; einem Wahrnehmungssystem für eine autonome oder halbautonome Maschine; einem System zur Durchführung von Simulationsoperationen; einem System zur Durchführung von Deep-Learning-Operationen; einem System zur Durchführung von Echtzeit-Streaming-Übertragungen; einem System zur Durchführung von Videoüberwachungsdiensten; einem System zur Durchführung einer intelligenten Videoanalyse; einem System, welches unter Verwendung einer Edge-Einrichtung implementiert ist; einem System zur Erzeugung einer grafischen Ausgabe mit Raytracing;; einem System, welches eine oder mehrere virtuelle Maschinen (VMs) enthält; einem System, welches zumindest teilweise in einem Rechenzentrum implementiert ist; oder einem System, welches zumindest teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert ist.
  34. Verfahren umfassend: Empfangen von komprimierten Daten und Metadaten, welche den komprimierten Daten entsprechen, wobei die Metadaten eine anfängliche Eingabeposition und eine anfängliche Ausgabeposition, welche den komprimierten Daten entsprechen, und eine Eingabesegmentposition und eine Ausgabesegmentposition für mindestens zwei Segmente aus einer Vielzahl von Segmenten der komprimierten Daten angeben; und Dekomprimieren der mindestens zwei Segmente parallel unter Verwendung einer Eingabe, welche einer Position entspricht, die durch die anfängliche Eingabeposition und die Eingabesegmentposition angegeben wird, wobei eine Ausgabe des Dekomprimierens eine Position aufweist, welche der anfänglichen Ausgabeposition und der Ausgabesegmentposition entspricht.
DE102021121333.9A 2020-08-25 2021-08-17 Parallele dekomprimierung von komprimierten datenströmen Pending DE102021121333A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/002,564 US11405053B2 (en) 2020-08-25 2020-08-25 Parallel decompression of compressed data streams
US17/002,564 2020-08-25

Publications (1)

Publication Number Publication Date
DE102021121333A1 true DE102021121333A1 (de) 2022-03-03

Family

ID=80221720

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021121333.9A Pending DE102021121333A1 (de) 2020-08-25 2021-08-17 Parallele dekomprimierung von komprimierten datenströmen

Country Status (4)

Country Link
US (3) US11405053B2 (de)
JP (1) JP2022037900A (de)
CN (1) CN114116635A (de)
DE (1) DE102021121333A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220040573A1 (en) * 2020-08-10 2022-02-10 Nvidia Corporation Transferring from a cloud-hosted instance of an application to a local instance
WO2024020465A1 (en) * 2022-07-21 2024-01-25 Kbr Wyle Services Llc Systems and methods for transmitting information using an electronic media
CN116521063B (zh) * 2023-03-31 2024-03-26 北京瑞风协同科技股份有限公司 一种hdf5的试验数据高效读写方法及装置
CN117331512B (zh) * 2023-12-01 2024-04-12 芯动微电子科技(武汉)有限公司 对gpu核内存储器执行写操作的数据压缩及处理方法
CN117375627B (zh) * 2023-12-08 2024-04-05 深圳市纷享互联科技有限责任公司 适用于字符串的纯文本格式数据的无损压缩方法和系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9264068B2 (en) * 2014-05-09 2016-02-16 Micron Technology, Inc. Deflate compression algorithm
US10230392B2 (en) * 2016-12-28 2019-03-12 Intel Corporation Techniques for parallel data decompression

Also Published As

Publication number Publication date
US11817886B2 (en) 2023-11-14
CN114116635A (zh) 2022-03-01
US20220069839A1 (en) 2022-03-03
US11405053B2 (en) 2022-08-02
US20220376701A1 (en) 2022-11-24
JP2022037900A (ja) 2022-03-09
US20240080041A1 (en) 2024-03-07

Similar Documents

Publication Publication Date Title
DE102021121333A1 (de) Parallele dekomprimierung von komprimierten datenströmen
DE102019133028A1 (de) Für neuronale netzwerke geeignetes effizientes matrixformat
DE102020124932A1 (de) Vorrichtung und Verfahren zur Echtzeit-Grafikverarbeitung mittels lokaler und cloudbasierter Grafikverarbeitungsbetriebsmittel
US9025898B2 (en) Dynamically selecting compression method for graphics remoting
DE112020000464T5 (de) Mehrfachkachel-grafikprozessor-rendering
US20150269773A1 (en) Graphics processing systems
DE102019135639A1 (de) Auf Echtzeit-Strahlverfolgung (RTRT) basierende adaptive Mehrfrequenzschattierung (AMFS)
DE102019119085A1 (de) Punktbasiertes rendern und entfernung von projektionsrauschen
DE102013218594A1 (de) System, Verfahren und Computerprogrammprodukt zur parallelen Rekonstruktion eines gesampelten Suffixarrays
DE102021207678A1 (de) Streamen eines komprimierten lichtfelds
DE102020107080A1 (de) Grafiksysteme und Verfahren zum Beschleunigen von Synchronisation mittels feinkörniger Abhängigkeitsprüfung und Planungsoptimierungen basierend auf verfügbarem gemeinsam genutztem Speicherplatz
DE102019127726A1 (de) Für fernarbeitsplatz-anwendungen geeignetes streaming individueller anwendungsfenster
DE102019103310A1 (de) Schätzer for einen optimalen betriebspunkt für hardware, die unter einer beschränkung der gemeinsam genutzten leistung/wärme arbeitet
DE102020132377A1 (de) Vorrichtung und Verfahren zur Drosselung einer Raytracing-Pipeline
DE102022112157A1 (de) Echtzeit-verbesserung für streaming-inhalt
DE102022100638A1 (de) Tracking und Kompensation von Pixeldegradation bei Display-Technologien
DE102020107828A1 (de) Komprimierung für spärliche datenstrukturen unter verwendung von modus-suchannäherung
DE102021104310A1 (de) Reservoir-basiertes räumlich-zeitliches resampling nach wichtigkeit unter verwendung einer globalen beleuchtungsdatenstruktur
DE112020007087T5 (de) Gleichzeitige Hashtabellen-Aktualisierungen
DE102022107232A1 (de) Gepackter fehlerkorrekturcode (ecc) für komprimierten datenschutz
DE102021128286A1 (de) Adaptives abtasten mit einer zielabtastrate
DE102021125895A1 (de) Latenzbestimmungen für einrichtungen mit menschlicher schnittstelle
DE102021120604A1 (de) Dynamische bildglättung basierend auf netzwerkbedingungen
DE102022114518A1 (de) Fusionierte verarbeitung eines kontinuierlichen mathematischen operators
DE102022112488A1 (de) Projektive hash-karten

Legal Events

Date Code Title Description
R012 Request for examination validly filed