Parallel decompression of compressed data streams

Abstract

Parallel decompression of compressed data streams is disclosed. In various examples, metadata corresponding to a compressed data stream compressed according to a serial compression algorithm (such as arithmetic coding, entropy coding, etc.) can be generated to enable parallel decompression of the compressed data. Consequently, modifications to the compressed data stream itself may not be required, and the bandwidth and storage requirements of the system may be minimally impacted. Furthermore, by parallelizing decompression, the system may benefit from faster decompression times while also reducing or completely eliminating the system's latency associated with using metadata for parallel decompression.

Description

Background Art

[0001] For a long time, lossless compression algorithms have been used to reduce the size of data sets for storage and transmission. Many traditional compression algorithms rely on the Lempel-Ziv (LZ) algorithm, Huffman coding, or a combination thereof. As an example, the DEFLATE compression format (Internet standard RFC1951) combines the LZ algorithm and Huffman coding for use with email communications, downloading web pages, generating ZIP files for storage on hard drives, etc. Algorithms like DEFLATE can save bandwidth in data transmission and / or can save disk space by storing data with fewer bits. However, due to the strong dependence on previous input for reconstruction of later input, traditional compression algorithms are inherently serial in nature, which makes these compression techniques less ideal for decompression on parallel processing units (such as graphics processing units (GPUs)). As a result, fine-grained parallel decompression algorithms for processing compressed data are rare.

[0002] Most conventional methods for parallel decompression rely on modifying the compression algorithm itself to remove the data hazards of the LZ algorithm and / or remove or limit the Huffman encoding step. Examples of existing methods for parallel decompression include LZ4 and LZ Sort and Set Empty (LZSSE). These and similar methods can achieve some benefits from a parallel processing architecture—for example, reduced runtime—although at the expense of some of the compression benefits of the LZ algorithm and / or Huffman encoding. For example, these parallel decompression algorithms typically result in a 10%-15% increase in file size compared to the same file compressed using a traditional sequential implementation of the DEFLATE compression format.

[0003] Another disadvantage of these parallel decompression algorithms is that the widespread use of traditional file formats presents a significant barrier to the widespread adoption of any newly proposed format. For example, for a system that already stores data according to a more traditional compression format (such as using the LZ algorithm, Huffman coding, or a combination thereof), the system may need to be reconfigured to work with the new type of compression algorithm. This reconfiguration may be expensive because the bandwidth and storage requirements of the system may have been optimized for the lower bandwidth and reduced file size of the serial compression algorithm, and the increase in bandwidth and storage requirements of the parallel decompression algorithm may require additional resources. In addition, the stored data from the existing compression format may have to be reformatted and / or a new copy of the data may have to be stored in the updated format before the existing copy is removed - thereby further increasing the time of the adoption cycle and possibly requiring the acquisition of additional resources. Summary of the Invention

[0004] Embodiments of the present disclosure relate to techniques for performing parallel decompression of compressed data streams. Systems and methods are disclosed for generating metadata for data streams compressed according to more traditional compression algorithms (such as Lempel-Ziv (LZ), Huffman coding, combinations thereof, and / or other compression algorithms) to expose different types of parallelism within the data stream for use in parallel decompression of the compressed data. For example, the metadata may indicate demarcations of individual data portions or blocks corresponding to the compressed data, demarcations of data segments within each content portion, and / or demarcations of dictionary segments within each data portion or block. Furthermore, the metadata may indicate output locations within the data output stream, thereby enabling a decompressor—particularly when performing parallel decompression—to identify where the decompressed data fits within the output stream. As such, and compared to conventional systems (such as those described above), metadata associated with a compressed stream results in a more minimal (e.g., 1%-2%) increase in the overall file size of the compressed data stream, without requiring any modifications to the compressed data stream itself. Thus, the bandwidth and storage requirements of the system may be minimally impacted compared to conventional parallel decompression algorithms, while also realizing the benefit of faster decompression times due to the parallel processing of the compressed data. Additionally, since the compressed stream is unaffected (e.g., in the case of DEFLATE format, the compressed stream still corresponds to the DEFLATE format), compatibility issues with older systems and files may be avoided, as systems employing central processing unit (CPU) decompression may ignore the metadata and decompress the compressed data serially according to conventional techniques, while systems employing parallel processors (such as GPUs) for decompression may use the metadata to decompress the data in parallel. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The present system and method for parallel decompression of compressed data streams are described in detail below with reference to the accompanying drawings, in which:

[0006] Figure 1 depicts an example data flow diagram illustrating a process 100 for parallel decompression of compressed data streams, according to some embodiments of the present disclosure;

[0007] Figure 2A depicts example tables corresponding to metadata for parallel decompression of compressed data streams according to some embodiments of the present disclosure;

[0008] Figure 2B depicts an example table of metadata corresponding to prefixes and formats for parallel decompression of compressed data streams according to some embodiments of the present disclosure;

[0009] Figure 2C depicts example tables corresponding to dictionaries and metadata associated with the dictionaries according to some embodiments of the present disclosure;

[0010] Figure 2D depicts an example table corresponding to metadata for parallel decompression of blocks of a compressed data stream according to some embodiments of the present disclosure;

[0011] Figure 2E depicts an example table corresponding to replication of a compressed data stream not suitable for parallel processing according to some embodiments of the present disclosure;

[0012] Figure 2F depicts an example table corresponding to replication of a compressed data stream suitable for parallel processing according to some embodiments of the present disclosure;

[0013] Figure 3 depicts a flow chart corresponding to a method for generating metadata of a compressed data stream for use in parallel decompression of the compressed data stream, according to some embodiments of the present disclosure;

[0014] Figure 4 depicts a flow chart corresponding to a method for parallel decompressing a compressed data stream according to some embodiments of the present disclosure;

[0015] Figure 5 depicts a block diagram of an example computing device suitable for implementing some embodiments of the present disclosure; and

[0016] Figure 6 is a block diagram of an example data center suitable for implementing some embodiments of the present disclosure. DETAILED DESCRIPTION

[0017] Disclosed are systems and methods for parallel decompression of compressed data streams. Although primarily described herein with respect to data streams compressed using the Lempel-Ziv (LZ) algorithm and / or Huffman encoding (e.g., DEFLATE, LZ4, LZ Sort and Set Empty (LZSSE), PKZIP, LZJaccard Distance (LZJD), LZWelch (LZW), BZIP2, finite state entropy, etc.), this is not intended to be limiting. As such, other compression algorithms and / or techniques may be used without departing from the scope of the present invention. For example, Fibonacci encoding, Shannon-Fano encoding, arithmetic coding, artificial bee colony algorithm, Bentley, Sleator, Tarjan and Wei (BSTW) algorithm, prediction by partial matching (PPM), run-length encoding (RLE), entropy encoding, Rice encoding, Golomb encoding, dictionary-type encoding, etc. As another example, the metadata generation and parallel decompression techniques described herein may be suitable for any compressed data format that includes variable bit lengths for encoding symbols and / or variable output sizes of replications (e.g., replications may correspond to one symbol, two symbols, five symbols, etc.).

[0018] The metadata generation and decompression techniques described herein can be used in any technology space that implements data compression and decompression, particularly for lossless compression and decompression. For example, but not limited to, the techniques described herein can be implemented for the following: audio data, raster graphics, three-dimensional (3D) graphics, video data, cryptography, genetics and genomics, medical imaging (e.g., for compressing Digital Imaging and Communications (DICOM) data in medicine), executable files, moving data to and from a network server, sending data between and among a central processing unit (CPU) and a graphics processing unit (GPU) (e.g., for increasing input / output (I / O) bandwidth between the CPU and the GPU), data storage (e.g., to reduce the data footprint), email, text, messaging, compressed files (e.g., ZIP files, GZIP files, etc.), and / or other technology spaces. The systems and methods described herein can be particularly well-suited for amplifying storage and increasing PCIe bandwidth for I / O-intensive use cases, such as communicating data between a CPU and a GPU.

[0019] Reference Figure 1 , Figure 11 is an example data flow diagram illustrating a process 100 for parallel decompression of compressed data streams according to some embodiments of the present disclosure. It should be understood that this and other arrangements described herein are merely set forth as examples. In addition to or in place of those arrangements and elements shown, other arrangements and elements (e.g., machines, interfaces, functions, sequences, functional groupings, etc.) may be used, and some elements may be omitted together. Further, many elements described herein are functional entities that may be implemented as discrete or distributed components or in combination with other components, and implemented in any suitable combination and position. The different functions described herein as being performed by entities may be performed by hardware, firmware, and / or software. For example, the different functions may be performed by a processor executing instructions stored in a memory.

[0020] Process 100 may include receiving and / or generating data 102. For example, data 102 may correspond to any type of technology space, such as, but not limited to, those described herein. For example, data 102 may correspond to text data, image data, video data, audio data, genome sequencing data, and / or other data types or combinations thereof. In some embodiments, data 102 may correspond to data stored and / or transmitted using lossless compression techniques.

[0021] Process 100 may include a compressor 104 compressing data 102 to generate compressed data 106. Data 102 may be compressed according to any compression format or algorithm, such as, but not limited to, those described herein. For example, and without limitation, data 102 may be compressed according to a Lempel-Ziv algorithm, Huffman coding, DEFLATE format, and / or another compression format or technique.

[0022] The compressed data analyzer 108 may analyze the compressed data 106 to identify opportunities for parallelization therein. For example, the compressed data analyzer 108 may identify segments (or portions) within the compressed data 132 that correspond to portions of a data stream that can be processed at least partially in parallel without affecting the processing of other segments. In some embodiments, the number of segments may be the same for each block of data, or may be different (e.g., dynamically determined). The number of segments is not limited to any particular number; however, in some non-limiting embodiments, each block of compressed data may be split into 32 different segments, such that 32 threads (or coprocessors) in a warp on a GPU can process the 32 segments in parallel. As other non-limiting examples, the compressed data 106 or a block thereof may be split into 4 segments, 12 segments, 15 segments, 64 segments, etc. The number of segments may correspond to each block of data and / or to each portion of a data structure for dictionary coding, as described herein, corresponding to each block. As such, the data structure (dictionary) may be separated into multiple segments for parallel decoding, and the data may be separated into (in embodiments, equal) multiple segments for parallel decoding—eg, using an already decoded dictionary.

[0023] To determine which portion of the compressed data 106 is associated with each segment, the compressed data analyzer 108 may perform a first pass on the compressed data 106 to determine the number of symbols or tokens within the compressed data 106. In a second pass, the number of symbols may then be used to determine how many and which symbols to include in each segment. In some embodiments, the number of symbols may be divided equally, or as equally as possible, between the segments. For example, if there are 320 symbols and 32 segments, each segment may include 10 symbols. In other examples, the number of symbols may be adjusted—e.g., by adding or subtracting one or more symbols for one or more of the segments—to simplify decompression. For example, instead of selecting 10 symbols per segment in the above example, one or more of the segments may include 11 symbols (while other segments may include 9 symbols) so that the segment boundaries correspond to a certain byte interval—e.g., a 4-byte interval—that the decompressor 114 can more easily process (e.g., by avoiding splitting the output between bytes of the compressed data 106).

[0024] The segments can then be analyzed by metadata generator 110 to generate metadata 112 corresponding to the compressed data 106. This metadata 112 provides information to decompressor 114 for decompressing the compressed data 106 in parallel. For example, within each segment, metadata 112 may identify three pieces of information. First, the bit number identifying where in the compressed data to begin decoding the segment; second, the position in the output buffer where the decoded result will be inserted; and third, the position or location within the replication list (or match) to begin outputting the delayed replication—e.g., a replication index. For example, with the third type of metadata 112, because decoding can be performed in parallel, using the LZ algorithm, decompressor 114 may not decode the replications serially, so the replications can be batched for later execution. Accordingly, the replication index can be included in metadata 112 to indicate to decompressor 114 to save space in the output buffer for each replication. The replication index can also be stored in a separate data array so that once decompressor 114 has performed the first pass, the replication can be performed by decompressor 114 to fill the output buffer with data. In some embodiments, the replication window can be a set length—e.g., a sliding window. For example, in the case of LZ77, the replication sliding window can be 32kb, while in other algorithms, the sliding window can be different (e.g., 16kb, 64kb, 128kb, etc.) or variable size. In this way, compressed data 106 can be generated based on the sliding window size. As a result of the metadata 112, parallelism on the GPU can be implemented so that each thread of the GPU can begin decoding a portion of the compressed data 106 independently of each other. In the example above using 32 segments, this process 100 can result in 32-way parallelism, and each thread can decode 1 / 32 of the compressed data 106 or a block thereof.

[0025] In some embodiments, the metadata may correspond to the number of bits per segment, the number of output bytes per segment, and / or the number of replications in each segment. However, in other embodiments, a prefix sum operation may be performed on the data (e.g., the number of bits, the number of output bytes, and / or the number of replications) to generate metadata 112 in a prefix sum format. Thus, the metadata 112 may correspond to the input (bit, nibble, byte, etc.) position of each segment (e.g., as determined using the number of bits, nibbles, or bytes of each previous segment), the output (bit, nibble, byte, etc.) position of each segment (e.g., as determined using the number of output bits, nibbles, or bytes from the previous segment), and the number of replications included in each segment prior to the current segment for which the metadata 112 is being generated. Examples of the differences between these two formats of metadata are provided in

[114] . Figure 2A and Figure 2B, as described in further detail herein. In some embodiments, because the values of the input bits, output position, and / or replication index for each segment are monotonically increasing, the metadata 112 can be compressed by storing a common offset (shared by all segments) and the difference between the input bits, output position, and replication index in each segment.

[0026] As described herein, the compressed data analyzer 108 may analyze the compressed data 106 to determine metadata 112 corresponding to a content portion of the compressed data 106, but may also analyze the compressed data 106 to determine metadata 112 corresponding to a dictionary portion (if present) corresponding to the compressed data 106 and / or to determine metadata 112 corresponding to a block within a larger stream identifying the compressed data 106. As an example, the content portion of the compressed data 106 may require a dictionary in order to be properly decoded by the decompressor 114. In embodiments using Huffman encoding, the dictionary may include a representation of a Huffman tree (or matching tree). In some embodiments, such as where both the LZ algorithm and Huffman encoding are used (e.g., in DEFLATE format), a first Huffman encoding operation may be performed on the copied literal and length, and a second Huffman encoding operation may be performed on the distance. As such, two or more Huffman trees may be included in the dictionary for decoding each of the copied literal, length, and distance.

[0027] In other embodiments, the dictionary may provide an indication of which symbols or bit values correspond to the compressed data 106, thereby enabling the decompressor 114 to use the dictionary to decompress the content portion of the compressed data 106. In some embodiments, the dictionary may be Huffman encoded and may also correspond to a Huffman tree used to decompress the compressed data 106. When a dictionary is used for each block of compressed data 106, for example in DEFLATE format, the metadata generator 110 may generate metadata 112 corresponding to the starting input bits of each segment of the dictionary and the number of bits used for each symbol in the content portion of the block of compressed data 106 to which the dictionary corresponds. In this manner, the dictionary may be divided into segments based on the metadata 112 and processed in parallel using threads of the GPU. As described herein, depending on the embodiment, the number of segments may be similar to the number of segments of the data or content portion of the block of compressed data 106, or may be different. Furthermore, the dictionary may include padding or repetitions, similar to duplication or matching of data segments of the compressed data 106, and the padding or repetitions may be used to further compress the dictionary.

[0028] Compressed data 106 can be separated into any number of blocks based on any number of criteria, as determined by compressor 104, and / or depending on the compression format or algorithm used. For example, a first block and a second block may be created if the frequency or priority within compressed data 106 varies. As a non-limiting example, the letters A, e, and i may be most frequent for a first portion of compressed data 106, while the letters g, F, and k may be most frequent for a second portion of compressed data 106. Thus, depending on the specific compression algorithm used, the first portion may be separated into a first block, and the second portion may be separated into a second block. Compressor 104 may determine any number of blocks for compressed data 106. Compressed data analyzer 108 may analyze these blocks to determine their position within the larger stream of compressed data 106. Thus, metadata generator 110 may generate metadata 112 that identifies the starting input bit and output byte (e.g., the position of the first output byte of the decoded data) for each block of compressed data 106 (which may include uncompressed blocks). Because the blocks are separate from one another and are separately identified by metadata 112, the blocks can also be processed in parallel—e.g., in addition to the compressed data 106 within each block being processed in parallel. For example, where each block includes 32 segments, the first block can be executed using a first warp of the GPU, and the second block can be executed using a second warp of the GPU in parallel with the first block. In examples where one or more of the blocks are uncompressed, the uncompressed blocks can be sent without a dictionary, and the input bits and output bytes of the uncompressed blocks can be used by the decompressor 114 to copy the data directly to the output.

[0029] As a result, metadata 112 may correspond to the input and output positions of each block within the larger stream, the input position of the dictionary within each block and the bit value of each symbol of the dictionary, as well as the input position, output position, and replication index of each segment within each block. This metadata 112 can be used by the decompressor 114 to decode or decompress the compressed data 106 in various forms of parallelism. For example, as described herein, individual blocks can be decoded in parallel—e.g., using different GPU resources and / or parallel processing units. Additionally, within each (parallel decompressed) block, the dictionary (if present) can be divided into segments, and the segments can be decoded or decompressed in parallel (e.g., if there are 64 segments of the dictionary, all 64 segments can be decoded in parallel, e.g., by using 64 different threads or two warps of a GPU). Further, within each (parallel decompressed) block, the content portion of the block can be divided into segments, and the segments can be decoded or decompressed in parallel. Further, as defined herein, one or more of these copy or match operations may be performed in parallel by the decompressor 114 - e.g., where a copy depends on data that has already been decoded into the output stream, the copy may be performed in parallel with one or more other copies. Additionally, each individual copy operation may be performed in parallel. For example, where a copy has a length greater than 1, the copying of each symbol or character of the complete copy may be performed in parallel by the decompressor 114 - e.g., with respect to Figure 2F , each character of “issi” can be executed in parallel (e.g., copying “i” on a first thread of the GPU, copying “s” on a second thread, copying “s” on a third thread, and copying “i” on a fourth thread to generate corresponding output bytes of the output stream).

[0030] The decompressor 114 may receive the compressed data 106 and metadata 112 associated therewith. The decompressor 114 may use the metadata 112 to separate the compressed data 106 into individual blocks (where more than one block exists). For example, the decompressor 114 may analyze the block-level metadata 112 corresponding to the compressed data 106 and may determine the input (bit, nibble, byte, etc.) location of each block (e.g., the first bit or compressed data 106 corresponding to the block) and the output (bit, nibble, byte, etc.) location of each block (e.g., the first output location in the output stream where the data from the block (after decompression) is located). After identifying each block, the decompressor 114 may process each block serially (e.g., may process the first block, then the second block, etc.), may assign two or more of the blocks for parallel decompression by different GPU resources (e.g., by assigning the first block to a first GPU or a first set of threads thereof and the second block to a second GPU or a second set of threads of the first GPU, etc.), or a combination thereof. In some embodiments, each block may correspond to a different type or mode, such as an uncompressed mode block, a fixed code table mode block, a generated code table mode block, and / or other types. The decompressor 114 may decompress the compressed data 106 based on the mode (and / or decode the uncompressed data when in uncompressed mode), and the metadata 112 may be different based on the mode. For example, in uncompressed mode, there may not be a dictionary because the data does not need to be decompressed and / or there may not be copying or matching. As such, the metadata may simply indicate the input and output locations of the data, so that the input data stream corresponding to the uncompressed block is directly copied to the output stream.

[0031] The decompressor 114 can decompress each data block using metadata 112 associated with the dictionary and the content portion of the block. For example, for each block, the metadata 112 may identify the input (bit, nibble, byte, etc.) location of the dictionary and the bit value (or number of bits) for each symbol of each segment of the data in the block. As described herein, the dictionary can be used by the decompressor 114 to accurately decompress the content portion of the block. The dictionary can be generated using Huffman encoding of the content portion of the block, and in some embodiments, the compressed data corresponding to the dictionary can also be Huffman encoded. As a result, in embodiments, the dictionary portion of the compressed data can be compressed using Huffman encoding, and the content portion of the compressed data can be Huffman encoded. The metadata 112 corresponding to the dictionary portion of the compressed data 106 within each block may indicate the input location of the dictionary segment. For example, if the dictionary is divided into 32 segments, the metadata 112 may indicate the starting input bit (and / or output byte or other location) for each segment of the dictionary. As such, the decompressor 114 may decompress or decode the dictionary portion of the compressed data 106 in parallel (e.g., one segment per thread of the GPU) using the metadata 112. The dictionary may be compressed according to the LZ algorithm (in an embodiment, in addition to using Huffman coding), and therefore, decompression of the dictionary portion of the compressed data 106 may include copying or padding. As such, where parallel decompression of the dictionary is performed, a first pass by the decompressor 114 may decode the actual bit values (e.g., the bit length corresponding to each symbol in the dictionary) and leave placeholders for the bit values to be copied or padded. During a second pass, the decompressor 114 may perform padding or copying operations to fill in missing bit values corresponding to the symbols of the dictionary (e.g., as described herein with respect to Figure 2C described in more detail).

[0032] The decompressor 114 may use the metadata 112 corresponding to the content portion of the compressed data 106 for each block to identify the first input position (e.g., bit, nibble, byte, etc.) of each segment of the compressed data 106, the output position in the output stream of each segment of the compressed data 106 after decompression, and / or a replication index or number of replications for each segment of the compressed data 106. The decompressor 114 may perform a prefix sum operation to determine the input position, output position, and number of replications for each segment. However, in other embodiments, as described herein, the metadata 112 may alternatively indicate the number of bits in each segment, the number of output bytes in each segment, and the number of replications in each segment, rather than using a prefix sum format to identify the input position, output position, and replication index. The decompressor 114 may decompress the identified segments of the compressed data 106 in parallel. For example, using the identifiers from the metadata 112, the decompressor 114 may assign blocks or portions of the compressed data 106 corresponding to each segment to different threads of the GPU. The first pass through each segment of the compressed data 106 by the decompressor 114 can be performed to output the decompressed literals (e.g., actual symbols) from the compressed data 106 directly to the output stream (e.g., at a location identified by the metadata), and store the copy or match information in a separate queue for later processing (e.g., in a second pass of the decompressor 114), while reserving space in the output stream for the copy. The amount of space reserved in the output stream can be determined using metadata 112. These queued copies or matches may be referred to herein as delayed copies.

[0033] After the delayed copies are queued and the placeholders in the output stream are created, the decompressor 114 may perform a second pass through the delayed copies. Depending on whether each copy is determined to be safe to copy (e.g., a copy may be determined to be safe if the data to be copied has already been decompressed or does not depend on another copy that has not yet been copied), one or more of the copies may be executed in parallel. For example, the decompressor 114 may look ahead in the copy sequence to find additional copies that can be executed in parallel. The ability to process copies in parallel may be determined using metadata 112 and / or information corresponding to the copy. For example, the copy's output position within the output stream (as determined from metadata 112), the source position from which the copy is to be processed (as determined from the encoded distance information corresponding to the copy), and / or the length of the copy (as determined from the encoded length information corresponding to the copy) may be used to determine whether the copy is safe to be processed in parallel with one or more other copies. When the source ends before the current output cursor and the copy itself does not overlap, the copy may be safe to be executed in parallel with another copy. As an example, and based on experimentation, the number of bytes copied simultaneously can be increased from 3-4 to 90-100 or more. This process provides significant additional opportunities for parallelism across threads, as well as for memory system parallelism within a single thread. As such, one or more of the copies (e.g., intra-block copies or inter-block copies) can be performed in parallel with one or more other copies. Figure 2E-2F Examples of secure and unsecure copies for parallel execution are described. Furthermore, in some embodiments, symbols within a single copy can be executed in parallel. For example, if the copy has a length greater than 1, two or more threads (or coprocessors) of a GPU can be used to copy each symbol within the copy to (bytes of) the output stream in parallel.

[0034] As a result, the decompressor 114 may output each of the symbols to an output stream by performing a first pass of the compressed data 106 to output the literals and performing a second pass of the copy to output the symbols from the copy. The result may be an output stream corresponding to the data 102 originally compressed by the compressor 104. In examples using lossless compression techniques, the data 102 output may be the same or substantially the same as the data 102 input to the compressor 104.

[0035] In some embodiments, a binary tree search algorithm with a shared memory table can be performed on the compressed data 106 to avoid cross-thread divergence that would occur with a typical fast path / slow path implementation found in CPU-based decoders or decompressors. For example, in conventional implementations on a CPU, a larger data array can be used to decode a certain number of bits at a time. With the DEFLATE format, each symbol can range from 1 to 15 bits long, so when decoding the data, it may not be immediately obvious to the decompressor how long each symbol is. As a result, the CPU decompressor uses one bit to check whether it is a symbol of length 1, then another bit to check whether it is a symbol of length 2, and so on, until the actual number of bits corresponding to the symbol is determined. This task can be time-consuming and can slow down the decompression process, even for CPU implementations. Therefore, some methods have implemented methods that analyze multiple bits (e.g., 15 bits) at a time. In such an embodiment, 15 bits can be pulled from the compressed data stream, and a lookup table can be used to determine which symbol the data corresponds to. However, this process is wasteful because the sliding window may only be 32 kb, but the system must store 15 bits for analysis, even though the symbol may only be compressed to 2 bits. Therefore, in some implementations, a fast path / slow path approach may be used, where 8 bits are extracted, a symbol lookup is performed on the 8 bits, and when the symbol is shorter than 8 bits, the fast path is used, and when the symbol is longer than 8 bits, the slow path is used to determine what symbol the data represents. This process is also time-consuming and reduces the runtime of the system for decompressing the compressed data 106.

[0036] On one or more GPUs, instead of using a fast path / slow path approach, where a certain number of threads (e.g., 32) are executing on a certain number of symbols (e.g., 32), some will hit the fast path and some will hit the slow path, intermingled within the warp (e.g., in the presence of 32 segments), which is inefficient. To address this issue, a binary search algorithm can be used to improve efficiency. For example, a binary search can be performed on a small table (e.g., a table 15 entries long) to determine which symbols belong to that table. Due to the reduced size of the array, the array can be stored in on-chip shared memory, which can result in faster lookups on the GPU. Additionally, using a binary search algorithm can allow all threads to execute the same code, even if they are looking at different portions of the array in shared memory. Consequently, memory traffic can be reduced because the binary search can look at symbols of length 8 to see whether the symbol is longer or shorter than 8 bits. Furthermore, one or more (e.g., two) of the top levels of the binary tree can be cached in data registers to reduce the amount of shared memory accessed per lookup (e.g., from 5 to 3). Thus, the first of the four accesses can always be the same access, rather than loading it from memory each time, and the registers can remain alive on the GPU. The next can be 4 or 12, but instead of having another level of memory access, the system can choose whether to look at the sign-4 register or the sign-12 register, and this can reduce the total number of accesses by 2 or more (e.g., typically 4 for a binary search to get the length, and 1 to get the actual sign, so this process is reduced from 4 plus 1 to 2 plus 1). In this way, rather than loading the entry and then shifting the sign to compare, the sign itself is pre-shifted.

[0037] Furthermore, in some embodiments, the input stream of compressed data 106 can be swizzled or interleaved. For example, because the blocks of compressed data 106 can be divided into a certain number of segments (e.g., 32) by compressed data analyzer 108, each thread can read from a distant portion of the stream. Therefore, the input stream can be interleaved at segment boundaries during preprocessing (e.g., using metadata 112) to improve data read locality. For example, if data 102 corresponds to a practical dictionary containing all words in a particular language, one thread can read from words beginning with the letter "A," another from the letter "D," another from the letter "P," and so on. To remedy this problem, the data can be reformatted so that all threads can read from adjacent memory. For example, information from an index can be used to interleave compressed data 106 so that each thread can read from a similar cache line. In this way, data can be shuffled together so that when threads are processing data, they can have some similarity in the data, even if the data is different. For the playing card example, swapping or interleaving the data can allow each thread to process cards with the same number or character, even if they are different suits.

[0038] As another example, for example, where a segment is processed using threads in a warp of a GPU, a warp-synchronized data-parallel loop can be executed to load and process a dictionary. For example, using index and data-parallel algorithms, the system can index dictionary entries in parallel. When processing serially, the system can check how many symbols are length 2, length 3, etc. However, instead of performing these calculations serially, the system can execute a data algorithm to calculate or assign a thread to each symbol in parallel, then report whether the symbol has a specific length, and then perform warp reduction to the total number of warps. For example, where there are 286 symbols to be analyzed (e.g., 0-255 bytes, 256 ends of the block, 257-286 for different lengths), each of the 286 symbols can be analyzed in parallel.

[0039] Now refer to Figures 2A-2F , each of the described examples may correspond to data compressed according to the DEFLATE compression format and metadata corresponding thereto 112. However, this is for example purposes only, and as described herein, the techniques of the present disclosure may be implemented for or applied to any type of data compression format, such as, but not limited to, those described herein.

[0040] Figure 2AAn example table 200A corresponding to metadata 112 for parallel decompression of a compressed data stream according to some embodiments of the present disclosure is depicted. For example, data 102 (or a portion thereof, such as a block thereof) may correspond to the word "Mississippi." Compressor 104 may compress data 102 according to the DEFLATE compression algorithm to generate a compressed version of data 102 (e.g., compressed data 106) represented as "Miss < replication length 4, distance 3 > ppi." Furthermore, compressed data 106 may be Huffman encoded, and thus, different symbols may be represented by multiple bits corresponding to a certain priority or frequency evaluation of compressor 104. For non-limiting example, "M" may be represented by 3 bits, replication may be represented by 4 bits (e.g., 3 bits for length and 1 bit for distance), and "i," "s," and "p" may each be represented by 2 bits in compressed data 106. For this example, assuming that the block of compressed data 106 is decomposed into four segments (e.g., a 4-way index), compressed data analyzer 108 can analyze compressed data 106 to determine a first segment including "Mi," a second segment including "ss," a third segment including a replication and "p," and a fourth segment including "p." For example, the eleven characters or symbols "Mississippi" can be decomposed into eight symbols (e.g., seven literals and one replication), and these segments can be generated to have substantially equal sizes. However, due to the odd number of symbols, the fourth segment may include only one symbol. Compressed data analyzer 108 can then determine the number of outputs (or output bytes) for each segment, the number of inputs (or input bits) for each segment, and / or the number of replications in each segment. In some examples, metadata generator 110 can directly use this information to generate metadata 112. However, in other examples, a prefix sum operation can be performed on this data to generate metadata 112 according to table 200B.

[0041] about Figure 2B , Figure 2BAn example table 200B is depicted corresponding to metadata 112 in a prefix sum format for parallel decompression of a compressed data stream, according to some embodiments of the present disclosure. For example, instead of multiple outputs, each segment can be identified by an output position within the output stream to indicate to the decompressor 114 where the output of decompressed symbols from the segment should begin. Instead of multiple inputs, an input position within the compressed data stream can be identified to indicate to the decompressor 114 where to begin decompressing the segment, so that a unique thread of the GPU can be assigned to the segment for parallel processing. Additionally, instead of the number of replications in each segment, a running total of replications from previous segments of the block can be identified in the metadata 112 to indicate to the decompressor which replication corresponds to each delayed replication in the queue. Ultimately, in this example, the prefix and format of the metadata 112 may indicate to the decompressor 114 that within the content portion (or data portion) of the current block of compressed data, there are 11 bytes of output, 19 bits of input, and one replication, and may indicate where each segment begins in the compressed data 106, where to output each segment, and / or replication index.

[0042] See also Figure 2C , Figure 2C An example table 200C corresponding to a dictionary and metadata 112 associated with the dictionary is depicted according to some embodiments of the present disclosure. Figure 2A and Figure 2BA dictionary may be generated to indicate these values using the same number of bits as the symbols described (e.g., as determined using Huffman coding). In this example, the dictionary may correspond to lowercase and uppercase letters of the English alphabet. However, this is not intended to be limiting, and the dictionary may correspond to any type of symbol, including characters from any language, numbers, symbols (e.g., !$, *, ^, and / or other symbol types), etc. As such, because the compressed data 106 may correspond only to M, i, s, and p, the dictionary portion of the compressed data 106 may be compressed to indicate these values. In such an example, the data string 202 may represent data 102 corresponding to the dictionary, wherein each of the 52 characters (e.g., AZ and az) is represented by a value corresponding to a plurality of bits. To further compress the dictionary, the compressor 104 may generate padding or replication symbols corresponding to repeated values from the data string 202. In this case, the repetition value is 0, so the compressed data 106 corresponding to the dictionary can be represented by "<fill 12x> 3<fill 21x> 2<fill 6x> 2002<fill 7x>". The compressed data analyzer 108 can analyze the compressed data 106 corresponding to the dictionary and determine the segment breaks (e.g., in the example using four segments, the compressed data 106 can be separated into four segments). The separation of the four segments is indicated by the dashed lines. The metadata generator 110 can then analyze the segment information to generate metadata 112 corresponding to the dictionary portion of the block of compressed data 106 - for example, to indicate the starting input position and symbol number or index of each segment in the dictionary.

[0043] Now see Figure 2D , Figure 2DAn example table 200D is depicted corresponding to metadata 112 for parallel decompression of blocks of a compressed data stream, according to some embodiments of the present disclosure. For example, assuming the data 102 is "MississippiMississippiMiss," the compressor 104 may separate the data 102 into two blocks for compression: a first block corresponding to "Mississippi"; and a second block corresponding to "MississippiMiss." Thus, to identify the locations of the different blocks within the compressed data 106 and the dictionaries corresponding thereto, the compressed data analyzer 108 may analyze the compressed data 106 to determine the initial input position (e.g., the first input bit, nibble, byte, etc.) of each block of the compressed data 106 and / or the initial output position (e.g., the first bit, nibble, byte, etc.) of each block in the output stream. Thus, metadata 112 corresponding to a stream of compressed data 106 may indicate the number of inputs (e.g., bits, nibbles, bytes, etc.) and the number of outputs (e.g., bits, nibbles, bytes, etc.) for each block of compressed data 106, the number of inputs (e.g., bits, nibbles, bytes, etc.) and the number of symbols for each segment within each block, and / or the number of inputs (e.g., bits, nibbles, bytes, etc.), the number of outputs (e.g., bits, nibbles, bytes, etc.), and the number of replications for each segment within each block. In the case of a prefix sum operation, metadata 112 may alternatively include the initial input position and initial output position for each block of compressed data, the initial input position and symbol index for each segment of the dictionary portion of each block, and / or the initial input position, initial output position, and replication index for each segment of the content portion of each block (or data portion). In further embodiments, some combination of two different metadata formats may be used, such that the metadata for one or more of the blocks, dictionaries, or data is in prefix sum format, while one or more of the blocks, dictionaries, or data is not in prefix sum format.

[0044] The metadata 112 can then be used by the decompressor 114 to decompress the compressed data 106. For example, the metadata 112 can be used to identify each block of the compressed data 106, so that two or more blocks of the compressed data 106, such as block A and block B, can be decompressed in parallel. For each block, the metadata 112 can be used to determine the segmentation of the dictionary, so that the dictionary can be decompressed in parallel, such as one segment per thread or coprocessor. The dictionary can then be used to decompress the content portion of the compressed stream. For example, the metadata 112 can indicate the segmentation of the content portion of the compressed data 106, and the decompressor 114 can use the dictionary to decode literals from the compressed data 106 and output the literals to the output stream. The decompressor 114 can further use the metadata 112 and the replication information encoded in the compressed data 106 to reserve portions of the output stream for replication and populate a queue or data structure with information about each replication (e.g., source location, distance, length, etc.). As described herein, segments of the content portion of the compressed data 106 may be decompressed in parallel. After decompression, the decompressor 114 may perform a copy operation on the delayed copies in the queue to fill the reserved placeholders in the output stream with the corresponding copied symbols. As an example, and with respect to Figure 2A , a copy of "issi" indicated by source position 1, copy length 4, and distance 3 may be used to copy "i" to position 4, copy "s" to position 5, and copy "i" to position 6. The "i" at position 6 may be referred to as an overlapping copy because the "i" at position 6 is copied from the "i" at position 4, which did not exist until the copying began. As described herein, in some embodiments, the individual copy operations may be performed in parallel, such that two or more of the "issi" copies may be performed in parallel using different threads of the GPU.

[0045] Furthermore, in some embodiments, when it is determined that replication is safe, separate replications can be performed in parallel. Figure 2E , Figure 2EDepicted is an example table 400E corresponding to replications of a compressed data stream that are not suitable for parallel processing according to some embodiments of the present disclosure. For example, in the case where compressed data 106 corresponds to "MississippiMississippi", compressed data 106 may include two replications (e.g., replication #1 and replication #2 as indicated in table 200E). In this example, decompressor 114 may determine whether one or more additional replications, e.g., a second replication, can be executed in parallel when the first replication is about to be executed or during the execution of the first replication. Decompressor 114 may check the source location of the second replication and the output location of the first replication to determine whether there is overlap. In this case, because the second replication depends on the output from the first replication, it may not be safe for the second replication to be executed in parallel with the first replication. In this manner, the first replication and the second replication may be executed sequentially.

[0046] As another example, see Figure 2F , Figure 2F An example table 400F is depicted corresponding to replications of a compressed data stream suitable for parallel processing, according to some embodiments of the present disclosure. For example, if compressed data 106 corresponds to "MississippiMiss," compressed data 106 may include two replications (e.g., replication #1 and replication #2 as indicated in table 200F). In this example, decompressor 114 may determine whether one or more additional replications—e.g., a second replication—can be executed in parallel when the first replication is about to be executed or during the execution of the first replication. Decompressor 114 may check the source location of the second replication and the output location of the first replication to determine if there is any overlap. In this case, because the second replication does not depend on the output from the first replication (e.g., because the second replication can be executed without filling the output buffer with the results from the first replication), it may be safe to execute the second replication in parallel with the first replication. Accordingly, the first replication and the second replication may be executed in parallel, thereby providing an output of 8 symbols at a time, rather than providing outputs of 4 and 4 symbols sequentially.

[0047] Now see Figure 3-4 , each block of methods 300 and 400 described herein includes a computing process that can be performed using any combination of hardware, firmware, and / or software. For example, the various functions may be performed by a processor executing instructions stored in a memory. Methods 300 and 400 may also be embodied as computer-usable instructions stored on a computer storage medium. Methods 300 and 400 may be provided by a standalone application, a service, or a hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few. Furthermore, by way of example, with respect to Figure 1Methods 300 and 400 are described in conjunction with process 100. However, these methods 300 and 400 may additionally or alternatively be performed within any one process by any one system or any combination of processes and systems, including but not limited to those described herein.

[0048] See also Figure 3 , Figure 3 A flowchart corresponding to a method 300 for generating metadata for a compressed data stream for parallel decompression of the compressed data stream is depicted according to some embodiments of the present disclosure. At block B302, the method 300 includes analyzing the compressed data. For example, the compressed data analyzer 108 may analyze the compressed data 106.

[0049] At block B304 , the method 300 includes determining boundaries between segments of the compressed data. For example, the compressed data analyzer 108 may determine boundaries between segments of the compressed data 106 .

[0050] At block B306, the method 300 includes generating metadata for at least two of the plurality of segments based at least in part on the demarcation, the metadata indicating an initial input position within the compressed data and an initial output position in the output data corresponding to each of the at least two data segments. For example, the metadata generator 110 may generate metadata 112 corresponding to the segments to identify initial input positions, initial output positions, and / or replication indexes for some or all of the segments of the content portion of each block of the compressed data 106.

[0051] At block B308 , the method 300 includes sending the compressed data and metadata to a decompressor. For example, the compressed data 106 and the metadata 112 may be used by the decompressor 114 to decompress the compressed data 106 at least partially in parallel.

[0052] Now see Figure 4 , Figure 4 A flowchart corresponding to a method 400 for parallel decompressing compressed data streams according to some embodiments of the present disclosure is depicted. At block B402, the method 400 includes receiving compressed data and metadata corresponding thereto. For example, the decompressor 114 may receive the compressed data 106 and the metadata 112.

[0053] At block B404, method 400 includes determining an initial input position and an initial output position corresponding to the compressed data based on the metadata. For example, metadata 112 may indicate an initial input position in compressed data 106 and an initial output position in the output data stream corresponding to each block of compressed data 106.

[0054] At block B406, method 400 includes determining input dictionary positions and symbol indices for two or more dictionary segments of the dictionary of the compressed data based on the initial input positions and the initial output positions. For example, metadata 112 may indicate initial input positions and symbol indices for segments of the dictionary corresponding to compressed data 106.

[0055] At block B408, method 400 includes decompressing the dictionary at least partially in parallel based on the input dictionary position. For example, metadata 112 may indicate segmentation of the dictionary, and this information may be used by decompressor 114 to process each segment of the dictionary in parallel using threads of the GPU.

[0056] At block B410, the method 400 includes determining an input segment position, an output segment position, and a copy index value for at least two of the plurality of segments of the compressed data based on the initial input position and the initial output position. For example, the decompressor 114 may use the metadata 112 to determine an initial input position in the compressed data 106, an initial output position in the output stream, and a copy index (e.g., the number of copies in the segment preceding the current segment) for each segment of the compressed data 106 in the block or data portion.

[0057] At block B412, method 400 includes decompressing at least two segments in parallel based on the input segment positions and the output segment positions to generate a decompressed output. For example, decompressor 114 may use metadata 112 and a dictionary to generate data 102 from compressed data 106. As such, once data 102 has been recovered, data 102 may be used to perform one or more operations on the receiving end. For example, if data 102 is compressed and transferred from a CPU to a GPU for parallel processing, the data may then be transferred back to the CPU. If data 102 corresponds to text, messaging, or email, the data may be displayed on a device (e.g., a user device or client device). If data 102 corresponds to video, audio, images, etc., the data may be output using a display, speakers, headphones, earpieces, etc. If data 102 corresponds to a website, the website may be displayed within a browser on the receiving device (e.g., a user device or client device). As such, the decompressed data may be used in any of a variety of ways and, due to the parallel decompression, may be available more quickly while using less memory resources than conventional methods.

[0058] Example computing device

[0059] Figure 55 is a block diagram of an example computing device 500 suitable for implementing some embodiments of the present disclosure. The computing device 500 may include an interconnect system 502 that directly or indirectly couples the following devices: memory 504, one or more central processing units (CPUs) 506, one or more graphics processing units (GPUs) 508, a communication interface 510, input / output (I / O) ports 512, I / O components 514, a power supply 516, one or more presentation components 518 (e.g., one or more displays), and one or more logic units 520. In at least one embodiment, the one or more computing devices 500 may include one or more virtual machines (VMs), and / or any of their components may include virtual components (e.g., virtual hardware components). For non-limiting examples, the one or more GPUs 508 may include one or more vGPUs, the one or more CPUs 506 may include one or more vCPUs, and / or the one or more logic units 520 may include one or more virtual logic units. As such, one or more computing devices 500 may include discrete components (eg, a full GPU dedicated to computing device 500 ), virtual components (eg, a portion of a GPU dedicated to computing device 500 ), or a combination thereof.

[0060] although Figure 5 The various blocks of are shown as being connected via an interconnect system 502 having wires, but this is not intended to be limiting and is provided for clarity only. For example, in some embodiments, a presentation component 518 such as a display device may be considered an I / O component 514 (e.g., if the display is a touch screen). As another example, the CPU 506 and / or the GPU 508 may include memory (e.g., the memory 504 may represent a storage device in addition to the memory of the GPU 508, the CPU 506, and / or the other components). In other words, Figure 5 The term computing device is illustrative only. No distinction is made between categories such as "workstation," "server," "laptop," "desktop," "tablet," "client device," "mobile device," "handheld device," "game console," "electronic control unit (ECU)," "virtual reality system," and / or other device or system types, as all are considered within the Figure 5 within the range of computing devices.

[0061] Interconnect system 502 can represent one or more links or buses, such as an address bus, a data bus, a control bus or a combination thereof. Interconnect system 502 can include one or more bus types, such as an industry standard architecture (ISA) bus, an extended industry standard architecture (EISA) bus, a video electronics standard association (VESA) bus, a peripheral component interconnect (PCI) bus, a peripheral component interconnect express (PCIe) bus, and / or another type of bus or link. In some embodiments, there is a direct connection between components. As an example, CPU 506 can be directly connected to memory 504. In addition, CPU 506 can be directly connected to GPU 508. In the case of a direct or point-to-point connection between components, interconnect system 502 can include a PCIe link to perform the connection. In these examples, it is not necessary to include a PCI bus in computing device 500.

[0062] Memory 504 may include any of a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computing device 500. Computer-readable media can include volatile and non-volatile media and removable and non-removable media. By way of example and not limitation, computer-readable media can include computer storage media and communication media.

[0063] Computer storage media may include volatile and non-volatile media and / or removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, and / or other data types. For example, memory 504 may store computer-readable instructions (e.g., representing programs and / or program elements, such as an operating system). Computer storage media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing device 500. As used herein, computer storage media does not include signals themselves.

[0064] Computer storage media may embody computer-readable instructions, data structures, program modules, and / or other data types in a modulated data signal such as a carrier wave or other transmission mechanism, and include any information delivery media. The term "modulated data signal" may refer to a signal that has one or more of its characteristics set or changed in such a manner as to encode information into the signal. By way of example and not limitation, computer storage media may include wired media such as a wired network or a direct wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0065] The CPU 506 can be configured to execute at least some computer-readable instructions to control one or more components of the computing device 500 to perform one or more of the methods and / or processes described herein. Each of the CPUs 506 can include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of processing a large number of software threads simultaneously. The CPU 506 can include any type of processor and can include different types of processors, depending on the type of computing device 500 implemented (e.g., a processor with fewer cores for mobile devices and a processor with more cores for servers). For example, depending on the type of computing device 500, the processor can be an Advanced RISC Machine (ARM) processor implemented using Reduced Instruction Set Computing (RISC) or an x86 processor implemented using Complex Instruction Set Computing (CISC). The computing device 500 can also include one or more CPUs 506 in addition to one or more microprocessors or supplementary coprocessors such as math coprocessors.

[0066] In addition to or in lieu of the CPU 506 , the GPU 508 may be configured to execute at least some computer-readable instructions to control one or more components of the computing device 500 to perform one or more methods and / or processes described herein. The one or more GPUs 508 may be integrated GPUs (e.g., with the one or more CPUs 506) and / or the one or more GPUs 508 may be discrete GPUs. In embodiments, the one or more GPUs 508 may be coprocessors for the one or more CPUs 506. The computing device 500 may use the GPU 508 to render graphics (e.g., 3D graphics) or perform general-purpose computations. For example, the GPU 508 may be used for general-purpose computations on a GPU (GPGPU). The GPU 508 may include hundreds or thousands of cores capable of processing hundreds or thousands of software threads simultaneously. The GPU 508 may generate pixel data for outputting an image in response to rendering commands (e.g., rendering commands received from the CPU 506 via a host interface). The GPU 508 may include graphics memory, such as display memory, for storing pixel data or any other suitable data, such as GPGPU data. The display memory may be included as part of the memory 504. The GPU 508 may include two or more GPUs operating in parallel (e.g., via a link). The link may connect the GPUs directly (e.g., using NVLINK) or through a switch (e.g., using NVSwitch). When combined, each GPU 508 may generate pixel data or GPGPU data for a different portion of the output or for different outputs (e.g., a first GPU for a first image and a second GPU for a second image). Each GPU may include its own memory or may share memory with other GPUs.

[0067] In addition to or in lieu of the CPU 506 and / or GPU 508, the logic unit 520 may be configured to execute at least some computer-readable instructions to control one or more components of the computing device 500 to perform one or more methods and / or processes described herein. In embodiments, the CPU 506, GPU 508, and / or the logic unit 520 may independently or jointly perform any combination of methods, processes, and / or portions thereof. The one or more logic units 520 may be part of and / or integrated with one or more of the CPU 506 and / or GPU 508, and / or the one or more logic units 520 may be discrete components or otherwise external to the CPU 506 and / or GPU 508. In embodiments, the one or more logic units 520 may be coprocessors for the one or more CPUs 506 and / or GPUs 508.

[0068] Examples of logic unit 520 include one or more processing cores and / or components thereof, such as a tensor core (TC), a tensor processing unit (TPU), a pixel vision core (PVC), a vision processing unit (VPU), a graphics processing cluster (GPC), a texture processing cluster (TPC), a streaming multiprocessor (SM), a tree traversal unit (TTU), an artificial intelligence accelerator (AIA), a deep learning accelerator (DLA), an arithmetic logic unit (ALU), an application-specific integrated circuit (ASIC), a floating point unit (FPU), an input / output (I / O) element, a peripheral component interconnect (PCI) or a peripheral component interconnect express (PCIe) element, etc.

[0069] The communication interface 510 may include one or more receivers, transmitters, and / or transceivers that enable the computing device 500 to communicate with other computing devices via an electronic communication network, including wired and / or wireless communications. The communication interface 510 may include components and functionality that enable communication over any of a number of different networks, such as wireless networks (e.g., Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), wired networks (e.g., via Ethernet or InfiniBand communications), low-power wide-area networks (e.g., LoRaWAN, SigFox, etc.), and / or the Internet.

[0070] The I / O ports 512 can enable the computing device 500 to be logically coupled to other devices including I / O components 514, presentation components 518, and / or other components, some of which can be built into (e.g., integrated into) the computing device 500. Illustrative I / O components 514 include a microphone, a mouse, a keyboard, a joystick, a game pad, a game controller, a satellite dish, a scanner, a printer, a wireless device, and the like. The I / O components 514 can provide a natural user interface (NUI) that processes user-generated mid-air gestures, voice, or other physiological input. In some instances, the input can be transmitted to an appropriate network element for further processing. The NUI can implement any combination of voice recognition, stylus recognition, facial recognition, biometric recognition, gesture recognition on and adjacent to the screen, mid-air gestures, head and eye tracking, and touch recognition associated with the display of the computing device 500 (as described in more detail below). The computing device 500 can include a depth camera such as a stereo camera system, an infrared camera system, an RGB camera system, touch screen technology, and combinations thereof for gesture detection and recognition. Additionally, computing device 500 may include an accelerometer or gyroscope to enable motion detection (e.g., as part of an inertial measurement unit (IMU)). In some examples, the output of the accelerometer or gyroscope may be used by computing device 500 to render immersive augmented or virtual reality.

[0071] The power supply 516 may include a hardwired power supply, a battery power supply, or a combination thereof. The power supply 516 may provide power to the computing device 500 to enable the components of the computing device 500 to operate.

[0072] The presentation component 518 may include a display (e.g., a monitor, a touch screen, a television screen, a head-up display (HUD), other display types, or a combination thereof), speakers, and / or other presentation components. The presentation component 518 may receive data from other components (e.g., the GPU 508, the CPU 506, etc.) and output the data (e.g., as images, video, sound, etc.).

[0073] Sample Data Center

[0074] Figure 6 An example data center 600 is shown that can be used in at least one embodiment of the present disclosure. The data center 600 can include a data center infrastructure layer 610, a framework layer 620, a software layer 630, and / or an application layer 640.

[0075] like Figure 6 As shown, the data center infrastructure layer 610 may include a resource coordinator 612, grouped computing resources 614, and node computing resources ("node CRs") 616(1)-616(N), where "N" represents any complete positive integer. In at least one embodiment, the node CRs 616(1)-616(N) may include, but are not limited to, any number of central processing units ("CPUs") or other processors (including accelerators, field programmable gate arrays (FPGAs), graphics processors or graphics processing units (GPUs), etc.), memory devices (e.g., dynamic read-only memory), storage devices (e.g., solid-state drives or disk drives), network input / output ("NW I / O") devices, network switches, virtual machines ("VMs"), power modules and / or cooling modules, etc. In some embodiments, one or more of the node CRs 616(1)-616(N) may correspond to a server having one or more of the above-mentioned computing resources. Furthermore, in some embodiments, node CRs 616 ( 1 )- 616 (N) may include one or more virtual components, such as vGPUs, vCPUs, etc., and / or one or more of node CRs 616 ( 1 )- 616 (N) may correspond to virtual machines (VMs).

[0076] In at least one embodiment, the computing resources 614 of the grouping can include a separate grouping (not shown) of node CRs 616 housed in one or more racks, or many racks (also not shown) housed in data centers at various geographic locations. The separate grouping of node CRs within the computing resources 614 of the grouping can include computing, network, memory, or storage resources that can be configured or assigned to support the grouping of one or more workloads. In at least one embodiment, several node CRs 616 comprising CPUs, GPUs, and / or other processors can be grouped in one or more racks to provide computing resources to support one or more workloads. One or more racks can also include any number of power modules, cooling modules, and / or network switches, in any combination.

[0077] Resource coordinator 622 may configure or otherwise control one or more node CRs 616(1)-616(N) and / or grouped computing resources 614. In at least one embodiment, resource coordinator 622 may comprise a software design infrastructure ("SDI") management entity for data center 600. Resource coordinator 622 may comprise hardware, software, or some combination thereof.

[0078] In at least one embodiment, Figure 6 As shown, the framework layer 620 may include a job scheduler 632, a configuration manager 634, a resource manager 636, and / or a distributed file system 638. The framework layer 620 may include a framework that supports the software 632 of the software layer 630 and / or one or more applications 642 of the application layer 640. The software 632 or the application 642 may include web-based service software or applications, such as those provided by Amazon Web Services, Google Cloud, and Microsoft Azure. The framework layer 620 may be, but is not limited to, a free and open source software web application framework, such as Apache Spark, which may utilize the distributed file system 638 for large-scale data processing (e.g., "big data"). TM(hereinafter referred to as "Spark"). In at least one embodiment, the job scheduler 632 may include a Spark driver to facilitate scheduling of workloads supported by the various layers of the data center 600. The configuration manager 634 may be capable of configuring different layers, such as the software layer 630 and the framework layer 620 including Spark and a distributed file system 638 for supporting large-scale data processing. The resource manager 636 may be capable of managing the mapping or allocation of clustered or grouped computing resources used to support the distributed file system 638 and the job scheduler 632. In at least one embodiment, the clustered or grouped computing resources may include grouped computing resources 614 on the data center infrastructure layer 610. The resource manager 636 may coordinate with the resource coordinator 612 to manage these mapped or allocated computing resources.

[0079] In at least one embodiment, the software 632 included in the software layer 630 may include software used by at least a portion of the node CRs 616(1)-616(N), the grouped computing resources 614, and / or the distributed file system 638 of the framework layer 620. The one or more types of software may include, but are not limited to, Internet web page search software, email virus scanning software, database software, and streaming video content software.

[0080] In at least one embodiment, the one or more applications 642 included in the application layer 640 may include one or more types of applications used by at least a portion of the node CRs 616(1)-616(N), the grouped computing resources 614, and / or the distributed file system 638 of the framework layer 620. The one or more types of applications may include, but are not limited to, any number of genomics applications, cognitive computing, and machine learning applications, including training or inference software, machine learning framework software (e.g., PyTorch, TensorFlow, Caffe, etc.), and / or other machine learning applications used in conjunction with one or more embodiments.

[0081] In at least one embodiment, any of configuration manager 634, resource manager 636, and resource coordinator 612 can implement any number and type of self-modification actions based on any number and type of data acquired in any technically feasible manner. The self-modification actions can relieve a data center operator of data center 600 from making potentially poor configuration decisions and can avoid underutilized and / or poorly performing portions of the data center.

[0082] The data center 600 may include tools, services, software, or other resources to train one or more machine learning models or use one or more machine learning models to predict or infer information according to one or more embodiments described herein. For example, a machine learning model may be trained by calculating weight parameters according to a neural network architecture using the software and / or computing resources described above with respect to the data center 600. In at least one embodiment, information may be inferred or predicted using trained or deployed machine learning models corresponding to one or more neural networks using the resources described above with respect to the data center 600 using weight parameters calculated using one or more training techniques such as, but not limited to, those described herein.

[0083] In at least one embodiment, the data center 600 may use a CPU, an application-specific integrated circuit (ASIC), a GPU, an FPGA, and / or other hardware (or corresponding virtual computing resources) to perform training and / or reasoning using the aforementioned resources. In addition, one or more of the aforementioned software and / or hardware resources may be configured as a service to allow users to train or perform information reasoning, such as image recognition, speech recognition, or other artificial intelligence services.

[0084] Sample network environment

[0085] A network environment suitable for implementing embodiments of the present disclosure may include one or more client devices, servers, network attached storage (NAS), other backend devices, and / or other device types. The client devices, servers, and / or other device types (e.g., each device) may be configured to: Figure 5 The data center 600 may be implemented on one or more instances of one or more computing devices 500 - for example, each device may include similar components, features and / or functions of one or more computing devices 500. In addition, in the case of implementing a backend device (e.g., a server, NAS, etc.), the backend device may be included as part of the data center 600, an example of which is described herein with respect to Figure 6 Describe in more detail.

[0086] The components of a network environment can communicate with each other via one or more networks, which can be wired, wireless, or both. A network can include multiple networks or a network of multiple networks. For example, a network can include one or more wide area networks (WANs), one or more local area networks (LANs), one or more public networks such as the Internet and / or a public switched telephone network (PSTN), and / or one or more private networks. In the case where the network includes a wireless telecommunications network, components such as base stations, communication towers, or even access points (and other components) can provide wireless connectivity.

[0087] Compatible network environments may include one or more peer-to-peer network environments (in which case the server may not be included in the network environment) and one or more client-server network environments (in which case one or more servers may be included in the network environment). In a peer-to-peer network environment, the functionality described herein with respect to the server may be implemented on any number of client devices.

[0088] In at least one embodiment, the network environment may include one or more cloud-based network environments, distributed computing environments, combinations thereof, and the like. The cloud-based network environment may include a framework layer, a job scheduler, a resource manager, and a distributed file system implemented on one or more servers, which may include one or more core network servers and / or edge servers. The framework layer may include software supporting the software layer and / or a framework for one or more applications at the application layer. The software or applications may include network-based service software or applications, respectively. In an embodiment, one or more client devices may use web-based service software or applications (e.g., by accessing the service software and / or applications via one or more application programming interfaces (APIs)). The framework layer may be, but is not limited to, a type of free and open source software web application framework, such as one that may use a distributed file system for large-scale data processing (e.g., "big data").

[0089] A cloud-based network environment can provide cloud computing and / or cloud storage that performs any combination of the computing and / or data storage functions described herein (or one or more portions thereof). Any of these different functions can be distributed across multiple locations from a central or core server (e.g., one or more data centers that can be distributed across a state, region, country, global, etc.). If the connection to the user (e.g., client device) is relatively close to an edge server, the core server can assign at least a portion of the functionality to the edge server. A cloud-based network environment can be private (e.g., limited to a single organization), public (e.g., available to many organizations), and / or a combination thereof (e.g., a hybrid cloud environment).

[0090] One or more client devices may include Figure 5At least some of the components, features, and functionality of one or more example computing devices 500 are described. By way of example and not limitation, the client device may be embodied as a personal computer (PC), a laptop computer, a mobile device, a smartphone, a tablet computer, a smartwatch, a wearable computer, a personal digital assistant (PDA), an MP3 player, a virtual reality headset, a global positioning system (GPS) or device, a video player, a camera, a surveillance device or system, a vehicle, a boat, a spacecraft, a virtual machine, a drone, a robot, a handheld communication device, a hospital device, a gaming device or system, an entertainment system, a vehicle computer system, an embedded system controller, a remote control, an appliance, a consumer electronic device, a workstation, an edge device, any combination of these depicted devices, or any other suitable apparatus.

[0091] The present disclosure can be described in the general context of machine-usable instructions or computer code executed by a computer or other machine such as a personal digital assistant or other handheld device, including computer-executable instructions such as program modules. Generally, program modules including routines, programs, objects, components, data structures, etc. refer to code that performs a specific task or implements a specific abstract data type. The present disclosure can be practiced in a variety of system configurations, including handheld devices, consumer electronics, general-purpose computers, more specialized computing devices, etc. The present disclosure can also be practiced in a distributed computing environment where tasks are performed by remote processing devices linked through a communication network.

[0092] As used herein, the statement "and / or" with respect to two or more elements should be interpreted as referring to only one element or combination of elements. For example, "element A, element B and / or element C" can include only element A, only element B, only element C, element A and element B, element A and element C, element B and element C, or elements A, B and C. In addition, "at least one of element A or element B" can include at least one of element A, at least one of element B, or at least one of element A and at least one of element B. Further, "at least one of element A and element B" can include at least one of element A, at least one of element B, or at least one of element A and at least one of element B.

[0093] The subject matter of the present disclosure is described in detail herein to meet statutory requirements. However, the description itself is not intended to limit the scope of the present disclosure. On the contrary, the inventors have contemplated that the claimed subject matter may also be embodied in other ways to include steps that are different from the steps described herein in conjunction with other current or future technologies, or combinations of similar steps. Moreover, although the terms "step" and / or "frame" may be used herein to imply different elements of the method employed, these terms should not be interpreted as implying any particular order among or between the various steps disclosed herein, unless the order of the steps is explicitly described.

Claims

1. A method comprising: receiving compressed data and metadata corresponding to the compressed data; determining an initial input location and an initial output location corresponding to the compressed data based at least in part on the metadata; determining an input segment position and an output segment position of at least two segments of the plurality of segments of the compressed data based at least in part on the initial input position and the initial output position; as well as The at least two segments are decompressed in parallel based on the input segment position and the output segment position to generate a decompressed output.

2. The method according to claim 1, further comprising: determining an input dictionary position and a symbol index for each dictionary segment of a dictionary for the block of compressed data based at least in part on the metadata; as well as decompress the dictionary, Wherein decompressing the plurality of segments is performed using the dictionary. 3 . The method of claim 2 , wherein the decompressing the dictionary is performed in parallel such that each dictionary segment of the dictionary is decompressed using a respective thread of a processor.

4. The method according to claim 2, further comprising: A replication index value for each of the plurality of segments of the compressed data is determined based at least in part on the metadata.

5. The method of claim 2 , wherein the initial input position indicates one or more block input positions of at least two blocks of the plurality of blocks of the compressed data, and the initial output position indicates one or more block output positions of at least two blocks of the plurality of blocks of the compressed data, the plurality of segments corresponding to individual blocks of the plurality of blocks. The method of claim 5 , wherein two or more processor resources are used to decompress two or more of the plurality of blocks in parallel. 7 . The method of claim 6 , wherein each of the two or more blocks is processed using a corresponding warp of a graphics processing unit (GPU).

8. The method of claim 6, wherein the decompressing the at least two segments in parallel comprises: Each segment is decompressed in parallel using a separate processing thread of the processor.

9. The method of claim 2, wherein the decompressing the at least two segments comprises: A transfer is performed on the plurality of segments to output one or more literals from the compressed data to output data, to reserve space in the output data for one or more copy operations, and to store copy information in a data structure.

10. The method of claim 9, wherein the decompressing the at least two segments comprises: Another pass is performed on the one or more copy operations to perform the one or more copy operations and output symbols corresponding to the one or more copy operations to an output stream. 11 . The method of claim 10 , wherein at least one of the one or more copy operations is performed in parallel with one or more other of the one or more copy operations.

12. The method of claim 10, wherein a first symbol of a copy operation is copied to the output in parallel with a second symbol of the copy operation.

13. The method of claim 1, wherein the compressed data comprises at least one of a variable length of bits used to encode symbols within the compressed data or a variable output size used to encode one or more copy operations in the compressed data.

14. The method of claim 1, wherein the compressed data corresponds to data encoded using at least one of dictionary encoding or entropy encoding.

15. A method comprising: analyzing compressed data to determine boundaries between a plurality of segments of the compressed data; generating metadata for at least two of the plurality of segments based at least in part on the demarcation, the metadata indicating an initial input position within the compressed data and an initial output position in output data corresponding to each of the at least two data segments; as well as The compressed data and the metadata are sent to a decompressor. The method of claim 15 , wherein the metadata further indicates replication indexes corresponding to the at least two data segments.

17. The method according to claim 15, further comprising: determining, based at least in part on the analyzing, additional boundaries between dictionary segments of a dictionary corresponding to the compressed data; as well as generating additional metadata indicating at least another initial input location of each dictionary segment of the dictionary within the compressed data, The sending further includes: sending the additional metadata.

18. The method according to claim 15, further comprising: determining additional boundaries between additional segments of the compressed data based at least in part on the analyzing; as well as generating additional metadata indicating another initial input location of each additional segment of the compressed data, The sending further includes: sending the additional metadata.

19. The method of claim 15, wherein the compressed data is compressed according to a DEFLATE compression format, and the method further comprises: determining additional demarcations within the compressed data based at least in part on the analyzing; as well as generating additional metadata indicating another initial input position corresponding to the additional demarcation, The sending further includes: sending the additional metadata.

20. The method of claim 15, wherein the compressed data corresponds to a data stream having at least one of a variable input length or a variable output length.

21. The method of claim 15, wherein the compressed data is compressed according to at least one of a Lempel-Ziv algorithm or Huffman coding.

22. The method of claim 15, wherein the compressed data is compressed using at least one of arithmetic coding or entropy coding.

23. The method of claim 15, wherein the compressed data comprises at least one of a variable length of bits used to encode symbols within the compressed data or a variable output size used to encode one or more copy operations in the compressed data.

24. The method of claim 15, wherein at least a portion of the metadata is encoded in a prefix sum format.

25. A system comprising: one or more processors; One or more memory devices having stored thereon instructions that, when executed using the one or more processors, cause the one or more processors to instantiate: a compressed data analyzer for identifying segments of compressed data; a metadata generator for generating metadata indicating an initial input position, an initial output position, and a copy index for each of the identified segments of the compressed data based at least in part on the identified segments; as well as Decompressor for: receiving the compressed data and the metadata; processing the identified segments in parallel and based on the metadata using threads of a processor; Based at least in part on the processing, outputting the literal symbol to an output and copying the information to a delayed copy queue; as well as The copied information is processed to output the copied symbols to the output.

26. The system of claim 25, further comprising a compressor for generating the compressed data from an input data stream.

27. The system of claim 25, wherein said processing said replication information comprises: The first copy operation is processed in parallel with the second copy operation.

28. The system of claim 25, wherein said processing said replication information comprises: A first symbol of the copy operation is processed in parallel with a second symbol of the copy operation.

29. The system of claim 25, wherein: The compressed data analyzer is further configured to identify blocks within the compressed data; and The identified segments correspond to blocks having two or more segments.

30. The system of claim 25, wherein: The compressed data analyzer is further configured to identify a dictionary segment of the dictionary corresponding to the identified segment; The metadata further indicates an initial dictionary position of the dictionary segment; processing the dictionary segments in parallel to generate the dictionary; as well as The processing of the identified segments is based at least in part on the dictionary.

31. The system of claim 30, wherein the dictionary is generated based at least in part on a first encoding pass being performed on the compressed data stream, and the dictionary is compressed based at least in part on a second encoding pass being performed on a compressed version of the dictionary.

32. The system of claim 25, wherein the compressed data comprises at least one of a variable length of bits used to encode symbols within the compressed data or a variable output size used to encode replication in the compressed data.

33. The system of claim 25, wherein the system is included in at least one of the following: control systems for autonomous or semi-autonomous machines; Perception systems for autonomous or semi-autonomous machines; a system for performing simulation operations; Systems for performing deep learning operations; A system for performing real-time streaming broadcasting; Systems for performing video surveillance services; A system for performing intelligent video analysis; Systems implemented using edge devices; A system for generating ray traced graphical output; A system for merging one or more virtual machines VM; A system implemented at least in part in a data center; or A system implemented at least in part using cloud computing resources.

34. A method comprising: receiving compressed data and metadata corresponding to the compressed data, the metadata indicating an initial input position and an initial output position corresponding to the compressed data, and input segment positions and output segment positions of at least two of a plurality of segments of the compressed data; as well as The at least two segments are decompressed in parallel using input corresponding to positions indicated by an initial input segment and the input segment position, wherein the decompressed output has a position corresponding to the initial output position and the output segment position.

Images