Parallel decompression of compressed data streams

Abstract

To provide techniques for performing parallel decompression of compressed data streams.SOLUTION: In various examples, metadata may be generated corresponding to compressed data streams that are compressed according to serial compression algorithms, such as arithmetic or entropy encoding, in order to allow parallel decompression of the compressed data. As a result, modification to the compressed data stream itself may not be required, and bandwidth requirements and storage requirements of the system may be minimally impacted. In addition, by parallelizing the decompression, the system may benefit from faster decompression times while also reducing or entirely removing an adoption cycle for systems using the metadata for the parallel decompression.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] Lossless compression algorithms have long been used to reduce the size of data sets for storage and transmission. Many conventional compression algorithms rely on the Lempel-Ziv (LZ) algorithm, Huffman coding, or a combination of both. As one example, the DEFLATE compression format—Internet Standard RFC 1951—combines the LZ algorithm and Huffman coding for use with email communications, downloading web pages, and generating ZIP files for storage on hard drives, among other things. Algorithms like DEFLATE may save bandwidth in data transfer and / or conserve disk space by storing data in fewer bits. However, conventional compression algorithms are inherently sequential, with a strong reliance on previous inputs to reconstruct later inputs, making 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 approaches to parallel decompression rely on modifying the compression algorithm itself to eliminate data hazards in the LZ algorithm and / or to eliminate or limit the Huffman encoding step. Examples of previous parallel decompression approaches include LZ4 and LZ sort and set empty (LZSSE). These and similar approaches can achieve some benefits from parallel processing architectures, such as reduced runtime, while sacrificing some of the compression benefits of the LZ algorithm and / or Huffman encoding. For example, these parallel decompression algorithms often result in a 10-15% increase in file size compared to the same file compressed under a traditional sequential implementation of the DEFLATE compression format. Summary of the Invention [Problem to be solved by the invention]

[0003] Another drawback of these parallel decompression algorithms is that the widespread use of traditional file formats presents significant challenges to the widespread adoption of any new proposed format. For example, in the case of schemes in which data is already stored according to more conventional compressed formats—such as those using the LZ algorithm, Huffman coding, or a combination thereof—the scheme may need to be reconfigured to work with the new compression algorithm type. This reconfiguration may be costly, as the bandwidth and storage requirements of the scheme may have been optimized for the reduced bandwidth and file size of sequential compression algorithms, while the increased bandwidth and storage requirements of parallel decompression algorithms may require additional resources. Furthermore, data already stored from the existing compressed format may need to be reformatted, and / or a new copy of the data may need to be stored in the updated format before the existing copy is removed, thereby further increasing the adoption cycle time and potentially requiring the acquisition of additional resources. [Means for solving the problem]

[0004] Embodiments of the present disclosure relate to techniques for implementing parallel decompression of compressed data streams. Systems and methods are disclosed that generate metadata for data streams compressed according to more conventional compression algorithms, such as Lembel-Ziv (LZ), Huffman coding, combinations thereof, and / or other compression algorithms, to expose different types of parallelism within the data stream for parallel decompression of the compressed data. For example, the metadata may indicate delimiters within the compressed data corresponding to individual data portions or blocks of the compressed data, data segment delimiters within each content portion, and / or dictionary segment delimiters within each data portion or block. Furthermore, the metadata may indicate output locations within the output stream of the data so that the decompressor can identify where the decompressed data fits within the output stream, particularly when decompressing in parallel. Thus, in contrast to conventional systems, such as those described above, the metadata associated with the compressed stream results in a more modest increase, e.g., 1-2%, in the overall file size of the compressed data stream without requiring modifications to the compressed data stream itself. As a result, the bandwidth and storage requirements of the system may be minimally affected compared to conventional parallel decompression algorithms, while also achieving the benefit of faster decompression times due to parallel processing of the compressed data. Furthermore, systems that use parallel processors such as GPUs for decompression may use the metadata to decompress the data in parallel, while systems that use a central processing unit (CPU) for decompression may ignore the metadata and decompress the compressed data sequentially according to conventional techniques, so that compatibility issues with older systems and files can be avoided by leaving the compressed stream unaffected (e.g., if the DEFLATE format is used, the compressed stream still corresponds to the DEFLATE format).

[0005] The present system and method for parallel decompression of compressed data streams is described in detail below with reference to the accompanying drawings. [Brief explanation of the drawings]

[0006] [Figure 1] 1 is an exemplary data flow diagram illustrating a process 100 for parallel decompression of compressed data streams, according to some embodiments of the present disclosure. [Figure 2A] 1 is an exemplary table corresponding to metadata for parallel decompression of compressed data streams, according to some embodiments of the present disclosure. [Figure 2B] 1 is an exemplary table corresponding to prefix sum format metadata for parallel decompression of compressed data streams, according to some embodiments of the present disclosure. [Figure 2C] 1 is an example table corresponding to a dictionary and metadata associated with the dictionary according to some embodiments of the present disclosure. [Figure 2D] 1 is an exemplary table corresponding to metadata for parallel decompression of blocks of a compressed data stream, according to some embodiments of the present disclosure. [Figure 2E] 10 is an exemplary table corresponding to a copy of a compressed data stream not suitable for parallel processing, according to some embodiments of the present disclosure. [Figure 2F] 10 is an exemplary table corresponding to a copy of a compressed data stream not suitable for parallel processing, according to some embodiments of the present disclosure. [Figure 3] 1 is a flow diagram corresponding to a method for generating metadata for a compressed data stream for parallel decompression of the compressed data stream, according to some embodiments of the present disclosure. [Figure 4] 1 is a flow diagram corresponding to a method for decompressing compressed data streams in parallel, according to some embodiments of the present disclosure. [Figure 5] FIG. 1 is a block diagram of an exemplary computing device suitable for use in implementing some embodiments of the present disclosure. [Figure 6] FIG. 1 is a block diagram of an exemplary data center suitable for use in implementing some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0007] Systems and methods are disclosed in connection with parallel decompression of compressed data streams. While described herein primarily with respect to data streams compressed using the Lembel-Ziv (LZ) algorithm and / or Huffman coding (e.g., DEFLATE, LZ4, LZ Sorting and Emptying (LZSSE), PKZIP, LZ Jaccard Distance (LZJD), LZ Welch (LZW), BZIP2, finite-state entropy, etc.), this is not intended to be limiting. Accordingly, other compression algorithms and / or techniques may be used without departing from the scope of this disclosure. For example, Fibonacci coding, Shannon-Fano coding, arithmetic coding, artificial bee colony algorithm, Bentley, Sleator, Tarjan, and Wei (BSTW) algorithm, prediction by partial matching (PPM), run-length encoding (RLE), entropy coding, Rice coding, Golomb coding, dictionary coding, etc. As another example, the metadata generation and parallel decompression techniques described herein may be suitable for any compressed data format that includes either a variable number of bits for encoding symbols and / or a variable output size for copies (e.g., a copy may correspond to one symbol, two symbols, five symbols, etc.).

[0008] The metadata generation and decompression techniques described herein may be used in any technology space where data compression and decompression—particularly lossless compression and decompression—is implemented. For example, without limitation, the techniques described herein may be implemented for audio data, raster graphics, three-dimensional (3D) graphics, video data, cryptography, genetics and genomics, medical imaging (e.g., for compressing digital imaging and communication in medicine (DICOM) data), executable files, moving data to and from web servers, sending data between central processing units (CPUs) and graphics processing units (GPUs) (e.g., to increase input / output (I / O) bandwidth between the CPU and GPU), data storage (e.g., to reduce data footprint), email, text, messages, compressing files (e.g., ZIP files, GZIP files, etc.), and / or other technology spaces. The systems and methods described herein are 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.

[0009] Referring to FIG. 1, FIG. 1 is an exemplary 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 provided by way of example only. Other arrangements and elements (e.g., machines, interfaces, functions, sequences, groupings of functions, etc.) may be used in addition to or instead of the illustrated arrangements and elements, and some elements may be omitted entirely. Furthermore, many of the elements described herein are functional entities that may be implemented as separate components or distributed components, or with other components, in any suitable combination and location. Various functions described herein as being performed by entities may be performed by hardware, firmware, and / or software. For example, various functions may be performed by a processor executing instructions stored in memory.

[0010] 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, the technology spaces 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 that is to be stored and / or transmitted using lossless compression techniques.

[0011] The process 100 may include a compressor 104 that compresses the data 102 to generate compressed data 106. The data 102 may be compressed according to any compression format or algorithm, such as, but not limited to, those described herein. For example, but not limited to, the data 102 may be compressed according to the Lembel-Ziv algorithm, Huffman coding, DEFLATE format, and / or another compression format or technique.

[0012] The compressed data analyzer 108 may analyze the compressed data 106 to determine opportunities for parallel processing therein. For example, the compressed data analyzer 108 may identify segments (or sections) within the compressed data 132 that correspond to portions of the 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 divided into 32 different segments so that 32 threads (or coprocessors) of a warp on a GPU can process the 32 segments in parallel. As other non-limiting examples, the compressed data 106, or blocks thereof, may be divided into 4 segments, 12 segments, 15 segments, 64 segments, etc. The number of segments may correspond to each block of data and / or each portion of a data structure used for dictionary coding corresponding to each block, as described herein. Thus, the data structure (dictionary) may be divided into a number of segments for parallel decoding, and the data may be divided into an (in an embodiment, equal) number of segments for parallel decoding, e.g., using an already decoded dictionary.

[0013] To determine which portions of the compressed data 106 should be 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 in the compressed data 106. Then, in a second pass, the number of symbols may be used to determine how many symbols and which symbols will be included 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 contain 10 symbols. In other instances, the number of symbols may be adjusted, e.g., plus or minus one or more symbols for one or more of the segments, to simplify deployment. For example, instead of choosing 10 symbols per segment in the above example, one or more of the segments may contain 11 symbols (other segments may contain 9) in order to make the segment boundaries correspond to a byte interval, e.g., a 4-byte interval, that the decompressor 114 can handle more easily (e.g., by avoiding splitting the output between bytes of the compressed data 106).

[0014] The segments may then be analyzed by the metadata generator 110 to generate metadata 112 corresponding to the compressed data 106 that provides information to the decompressor 114 for decompressing the compressed data 106 in parallel. For example, within each segment, the metadata 112 may identify three pieces of information: first, a number of bits that identify where within the compressed data to begin decoding the segment; second, a location in an output buffer where the decoded results will be inserted; and third, a position or location within a list of copies (or matches), e.g., a copy index, at which to begin outputting deferred copies. For example, with respect to the third type of metadata 112, because decoding can be performed in parallel, if an LZ algorithm is used, the decompressor 114 may not decode copies sequentially, so that the copies may be batched for later execution. Thus, a copy index may be included in the metadata 112 to indicate to the decompressor 114 to save space in the output buffer for each copy, and the copy index may be stored in a separate data array so that copying can be performed by the decompressor 114 to store the data in the output buffer once a first pass by the decompressor 114 is performed. In some embodiments, the copy window may be a set length, e.g., a sliding window. For example, if LZ77 is used, the sliding window for copying may be 32 kb, but in other algorithms, the sliding window may be a different size (e.g., 16 kb, 64 kb, 128 kb, etc.) or may be variable in size. Thus, the compressed data 106 may be generated based on the sliding window size. As a result of the metadata 112, parallel processing on the GPU may be performed such that each thread of the GPU can begin decoding a portion of the compressed data 106 independently of each other. In the above example using 32 segments, this process 100 may result in 32-way parallel processing, with each thread being able to decode 1 / 32 of the compressed data 106, i.e., its block.

[0015] In some embodiments, the metadata may correspond to the number of bits for each segment, the number of output bytes for each segment, and / or the number of copies within each segment. However, in other embodiments, a prefix sum operation may be performed on this data (e.g., the number of bits, the number of output bytes, and / or the number of copies) to generate metadata 112 in prefix sum format. As a result, metadata 112 may correspond to the input (bit, nibble, byte, etc.) location for each segment (e.g., determined using the number of bits, nibbles, or bytes for each previous segment), the output (bit, nibble, byte, etc.) location for each segment (e.g., determined using the number of output bits, nibbles, or bytes from the previous segment), and the number of copies included in each segment prior to the current segment for which metadata 112 is being generated. An illustration of the difference between these two forms of metadata is shown in FIGS. 2A and 2B, as described in further detail herein. In some embodiments, by having monotonically increasing values ​​of the input bit, output position, and / or copy index for each segment, the metadata 112 may be compressed by storing a common offset (shared by all segments) and the difference between the input bit, output position, and copy index within each segment.

[0016] As described herein, the compressed data analyzer 108 may analyze the compressed data 106 to determine metadata 112 corresponding to content portions of the compressed data 106, but may also analyze the compressed data 106 to determine metadata 112 corresponding to dictionary portions (if any) corresponding to the compressed data 106 and / or to determine metadata 112 corresponding to identifying blocks within a larger stream of the compressed data 106. As one example, a content portion of the compressed data 106 may require a dictionary to be properly decoded by the decompressor 114. The dictionary may include a representation of a Huffman tree (or matching tree) in embodiments in which Huffman coding is used. In some embodiments, such as when both the LZ algorithm and Huffman coding are used (e.g., in DEFLATE format), a first Huffman coding operation may be performed on the lengths of the literals and copies, and a second Huffman coding operation may be performed on the distances. Thus, two or more Huffman trees may be included in the dictionary for decoding each of the lengths and distances of the literals and copies.

[0017] In other embodiments, the dictionary may provide an indication of which symbols—or corresponding bit values—the compressed data 106 corresponds to, so that the decompressor 114 can use the dictionary to decompress the content portion of the compressed data 106. In some embodiments, the dictionary may be Huffman coded and correspond to a Huffman tree for decompressing the compressed data 106. When a dictionary is used, such as in DEFLATE format, for each block of compressed data 106, the metadata generator 110 may generate metadata 112 corresponding to the starting input bit 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. Thus, the dictionary may be divided into segments based on the metadata 112 and processed in parallel using threads of a GPU. As described herein, the number of segments may be similar to or different from the number of segments in the data or content portion of the block of compressed data 106, depending on the embodiment. Additionally, the dictionary may be filled or repeated, similar to that of copying or matching data segments of the compressed data 106, and this filling or repetition may be used to further compress the dictionary.

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

[0019] As a result, the metadata 112 may correspond to input and output locations for each block within the larger stream, input locations and bit values ​​for the dictionary within each block for each symbol in the dictionary, and input locations, output locations, and copy indexes for each segment within each block. This metadata 112 may be used by the decompressor 114 to decode or decompress the compressed data 106 using various forms of parallel processing. For example, as described herein, individual blocks may be decoded in parallel, e.g., using different GPU resources and / or parallel processing units. Furthermore, within each (parallel decompressed) block, the dictionary (if present) may be divided into segments, which may be decoded or decompressed in parallel (e.g., if there are 64 segments in the dictionary, all 64 segments may be decoded in parallel, such as by using 64 different threads or two warps of the GPU). Furthermore, within each (parallel decompressed) block, the content portions of the block may be divided into segments, which may be decoded or decompressed in parallel. Further, as defined herein, one or more of the copy or matching operations may be performed in parallel by the unpacker 114; for example, if the copy depends on data being decoded into the output stream, the copy may be performed in parallel with one or more other copies. Furthermore, each individual copy operation may be performed in parallel. For example, if the copy has a length greater than one, the copy of each symbol or letter of the complete copy may be performed in parallel by the unpacker 114—e.g., with reference to FIG. 2F , each letter of “issi” may be performed in parallel (e.g., copying “i” on a first thread of the GPU, “s” on a second thread, “s” on a third thread, and “i” on a fourth thread to generate respective output bytes for the output stream).

[0020] The decompressor 114 may receive the compressed data 106 and its associated metadata 112. The decompressor 114 may use the metadata 112 to separate the compressed data 106 into separate blocks (if there are multiple blocks). For example, the decompressor 114 may analyze the metadata 112 corresponding to the block level of the compressed data 106 and determine an input (bit, nibble, byte, etc.) location for each block (e.g., the first bit or compressed data 106 corresponding to the block) and an output (bit, nibble, byte, etc.) location for each block (e.g., the first output location in the output stream where decompressed data from the block will be placed). After each block is identified, the decompressor 114 may process each block sequentially (e.g., the first block may be processed, then the second block, etc.), or 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 group of its threads and the second block to a second GPU or a second group of threads of the first GPU), 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 type. The decompressor 114 may decompress the compressed data 106 (and / or decode the uncompressed data when in uncompressed mode) based on the mode, and the metadata 112 may differ based on the mode. For example, in uncompressed mode, there may be no dictionary because data does not need to be decompressed and / or there may be no copying or matching. Thus, the metadata may only indicate the input and output locations for the data, such that the input data stream corresponding to the uncompressed block is copied directly to the output stream.

[0021] The decompressor 114 may decompress each block of data using the dictionary and metadata 112 associated with the content portion of the block. For example, for each block, the metadata 112 may identify the dictionary entry (bit, nibble, byte, etc.) location and the bit value (or number of bits) for each symbol of every segment of data within the block. As described herein, the dictionary may be used by the decompressor 114 to accurately decompress the content portion of the block. The dictionary may be generated using Huffman coding for the content portion of the block, and in some embodiments, the compressed data corresponding to the dictionary may also be Huffman coded. As a result, in embodiments, the dictionary portion of the compressed data may be compressed using Huffman coding, and the content portion of the compressed data may be Huffman coded. The metadata 112 corresponding to the dictionary portion of the compressed data 106 within each block may indicate the entry 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) of each dictionary segment. Thus, the decompressor 114 may use the metadata 112 to decompress or decode the dictionary portion of the compressed data 106 in parallel (e.g., one segment per thread of the GPU). The dictionary may be compressed according to the LZ algorithm (in addition to using Huffman coding, in an embodiment), so that decompression of the dictionary portion of the compressed data 106 may include copying or padding. Thus, when parallel decompression of the dictionary is performed, a first pass by the decompressor 114 may decode the actual bit values ​​(e.g., corresponding to the bit length of 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 dictionary symbols (e.g., as described in more detail herein with reference to FIG. 2C ).

[0022] The decompressor 114 may use metadata 112 corresponding to content portions of the compressed data 106 for each block to identify a first input location (e.g., bit, nibble, byte, etc.) of each segment of the compressed data 106, an output location in the output stream for each segment of the compressed data 106 after decompression, and / or a copy index or number of copies for each segment of the compressed data 106. A prefix sum operation may be performed by the decompressor 114 to determine the input location, output location, and number of copies for each segment. However, in other embodiments, instead of identifying the input location, output location, and copy index using a prefix sum format as described herein, the metadata 112 may indicate the number of bits in each segment, the number of output bytes in each segment, and the number of copies in each segment. The decompressor 114 may decompress the identified segments of the compressed data 106 in parallel. For example, using identifiers from the metadata 112, the decompressor 114 may assign portions of the compressed data 106 corresponding to chunks or segments to different threads of a GPU. A first pass by the decompressor 114 through each segment of the compressed data 106 may be performed to output expanded literals (e.g., actual symbols) from the compressed data 106 directly to the output stream (e.g., at locations identified by metadata) and to store copy or matching information in a separate queue for later processing (e.g., in a second pass by the decompressor 114) while preserving space in the output stream for copying. The amount of space to maintain in the output stream may be determined using the metadata 112. These queued copies or matches may be referred to herein as deferred copies.

[0023] After the deferred copies are queued and placeholders in the output stream are created, the decompressor 114 may perform a second pass through the deferred copies. One or more of the copies may be performed in parallel 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 is already decompressed or if the data to be copied does not depend on another copy that has not yet been copied). For example, the decompressor 114 may search a sequence of copies to find additional copies that can be performed in parallel. The ability to process a copy in parallel may be determined using metadata 112 and / or information corresponding to the copy. For example, the output position of the copy in the output stream (determined from the metadata 112), the source position where the copy is to be made (determined from encoded distance information corresponding to the copy), and / or the length of the copy (determined from encoded length information corresponding to the copy) may be used to determine whether the copy is safe for parallel processing with one or more other copies. A copy may be safe to run in parallel with another copy when the source ends before the current output cursor and the copy does not overlap with itself. As one example, based on experiments, the number of bytes copied simultaneously may be increased from 3-4 to 90-100 or more. This process provides significant additional opportunities for both cross-thread parallelism and memory system parallelism within a single thread. Thus, one or more of the copies (e.g., intra-block copies or inter-block copies) may be performed in parallel with one or more other copies. Examples of copies that are safe and unsafe for parallel execution are described with reference to Figures 2E-2F. Furthermore, in some embodiments, symbols within a single copy may be executed in parallel. For example, if the copy has a length greater than one, individual symbols within the copy may be copied in parallel to the output stream (bytes of the output stream) using two or more threads (or coprocessors) of the GPU.

[0024] As a result, the decompressor 114 may output each of the symbols to an output stream by performing a first pass over the compressed data 106 outputting the literals and a second pass over the copy outputting the symbols from the copy. The result may be an output stream corresponding to the data 102 originally compressed by the compressor 104. In instances where a lossless compression technique is used, the output of the data 102 may be identical or substantially identical to the input compressor 104 of the data 102.

[0025] In some embodiments, a binary tree search algorithm using a shared memory table may be performed on the compressed data 106 to avoid the inter-thread divergence that would occur with typical fastpath / slowpath implementations found in CPU-based decoders or decompressors. For example, in conventional implementations on CPUs, large arrays of data may be used to decode some number of bits at a time. For DEFLATE format, each symbol can range from 1 to 15 bits long, so when decoding the data, it may not be immediately clear to the decompressor as to how long each symbol is. As a result, a CPU decompressor may use one bit to determine if it is a length-1 symbol, then another bit to determine if it is a length-2 symbol, 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 in CPU implementations. As a result, some techniques implement techniques that parse multiple bits at a time, such as 15 bits. In such an embodiment, 15 bits may be pulled from the compressed data stream, and a lookup table may be used to determine which symbol the data corresponds to. However, this process is wasteful because the sliding window may be only 32 kb, and the system must store 15 bits for analysis even when a symbol is compressed to only 2 bits. As a result, some implementations may use a fastpath / slowpath method in which if 8 bits are extracted, a symbol lookup is performed on the 8 bits; when the symbol is shorter than 8 bits, the fastpath is used, and when the symbol is larger than 8 bits, the slowpath is used to determine which symbol is represented by the data. This process is also time-consuming and reduces the system's runtime for expanding the compressed data 106.

[0026] On a GPU, if some number of threads (e.g., 32) are running on some number of symbols (e.g., 32), instead of using a fast path / slow path method, some will hit the fast path and some will hit the slow path, intermixing together within a warp (e.g., if there are 32 segments), which is inefficient. To address this issue, a binary search algorithm may be used to improve efficiency. For example, a binary search may be performed on a small table, such as a table that is 15 entries long, to determine which symbol the table belongs to. By reducing the size of the array, the array may be stored in shared memory on the chip, which may result in fast lookup on the GPU. Furthermore, using a binary search algorithm may allow all threads to execute the same code even when examining different parts of the array in shared memory. As a result, memory traffic may be reduced because a binary search may examine a symbol of length 8 to see if the symbol is longer or shorter than 8 bits. Additionally, one or more (e.g., two) of the top levels of the binary tree may be cached in data registers to reduce the number of shared memory accesses per lookup (e.g., from five to three). As a result, the first of four accesses may always be the same, allowing the register to remain live on the GPU rather than loading from memory each time. The next may be four or twelve, and instead of having another level of memory access, the system may choose whether to look at a symbol 4 register or a symbol 12 register, which may reduce the total number of accesses by two or more (e.g., typically a binary search is four to get the length and one more to get the actual symbol, so the process reduces from four plus one to two plus one). Thus, instead of loading an entry and then shifting the symbol to compare, the symbol itself is pre-shifted.

[0027] Additionally, in some embodiments, the input stream of compressed data 106 may be swizzled or interleaved. For example, a block of compressed data 106 may be divided into some number of segments (e.g., 32) by compressed data analyzer 108, so that each thread can read from a distant part of the stream. As a result, the input stream may be interleaved at segment boundaries in a pre-process (e.g., using metadata 112) to improve data read locality. For example, if data 102 corresponds to an actual dictionary containing all of the words of a particular language, one thread may read from words beginning with the letter "A," another thread may read from words beginning with the letter "D," another thread may read from words beginning with the letter "P," and so on. To eliminate this problem, the data may be reformatted so that all threads can read from contiguous memory. For example, the compressed data 106 may be interleaved using information from the index so that each thread may read from a similar cache line. Thus, when the threads are processing the data, the data may be shuffled together so that the threads may have some similarity in the data even if the data is different. In the playing card example, swizzling or interleaving the data may allow each thread to process cards with the same number or letter even if they are in different suits.

[0028] As a further example, such as when segments are processed using threads of a GPU warp, a warp-synchronized data-parallel loop may be executed to load and process the dictionary. For example, using a lookup and data-parallel algorithm, the system may index the dictionary entries in parallel. When processing sequentially, the system may determine how many symbols are of length 2, length 3, etc. However, instead of performing these calculations sequentially, the system may calculate or assign a thread to each symbol, then report whether the symbol is of a particular length, and then execute a data algorithm in parallel to perform the warp reduction to the total number of warps. For example, if 286 symbols are to be parsed (e.g., 0 to 255 bytes, 256 being the end of the block, 257 to 286 being for different lengths), each of the 286 symbols may be parsed in parallel.

[0029] 2A-2F, each of the illustrated examples may correspond to data compressed according to the DEFLATE compression format and corresponding metadata 112. However, this is for illustrative 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, including, but not limited to, the data compression formats described herein.

[0030] FIG. 2A illustrates an example table 200A corresponding to metadata 112 for parallel decompression of a compressed data stream, according to some embodiments of the present disclosure. For example, data 102 (or a portion thereof, such as a block thereof) may correspond to the word "Mississippi." The compressor 104 may compress the data 102 according to the DEFLATE compression algorithm to generate a compressed version of the data 102 (e.g., compressed data 106) represented as "Miss<copy length 4, distance 3> ppi." Furthermore, the compressed data 106 may be Huffman encoded, such that various symbols may be represented by several bits corresponding to some priority or frequency evaluation by the compressor 104. As a non-limiting example, "M" may be represented by three bits, copy may be represented by four bits (e.g., three bits for length and one bit for distance), and "i," "s," and "p" may each be represented by two bits in the compressed data 106. For this example, assuming a block of compressed data 106 is decomposed into four segments (e.g., a four-way index), compressed data analyzer 108 may analyze compressed data 106 to determine the first segment to contain "Mi," the second segment to contain "ss," the third segment to contain a copy and a "p," and the fourth segment to contain a "p." For example, "Mississippi," which is 11 letters or symbols, may be decomposed into eight symbols (e.g., seven literals and one copy), and the segments may be generated to be substantially equal in size. However, the fourth segment may contain only one symbol due to the odd number of symbols. Compressed data analyzer 108 may 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 copies within each segment. In some instances, metadata generator 110 may use this information directly to generate metadata 112. However, in other instances, a prefix union operation may be performed on this data to generate metadata 112 according to table 200B.

[0031] 2B, which illustrates an example table 200B corresponding to prefix-sum format metadata 112 for parallel decompression of a compressed data stream, according to some embodiments of the present disclosure. For example, instead of several outputs, each segment may instead be identified by an output position within the output stream to indicate to the decompressor 114 where output from decompressed symbols from the segment should begin. Instead of several inputs, an input position within the compressed data stream may be identified to indicate to the decompressor 114 where to begin decompressing the segment so that the segment can be assigned to a unique thread of the GPU for parallel processing. Furthermore, instead of several copies within each segment, a running total of copies from previous segments of the block may be identified in the metadata 112 to indicate to the decompressor which copy corresponds to each deferred copy in the queue. Finally, in this example, the prefix-sum format of the metadata 112 may indicate to the decompressor 114 that there are 11 bytes of output, 19 bits of input, and 1 copy in the content portion (or data portion) of the current block of compressed data, and may indicate where each segment begins in the compressed data 106, where each segment should be output, and / or a copy index.

[0032] Referring to FIG. 2C, FIG. 2C illustrates an example table 200C corresponding to a dictionary and metadata 112 associated with the dictionary according to some embodiments of the present disclosure. For example, using the same number of bits per symbol (e.g., as determined using Huffman coding) as described herein with reference to FIGS. 2A and 2B, a dictionary may be generated to represent these values. 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 letters, numbers, symbols (e.g., !, $, *, ^, and / or other symbol types) from any language. Thus, since the compressed data 106 may only correspond to M, i, s, and p, the dictionary portion of the compressed data 106 may be compressed to represent these values. In such an example, a data string 202 may represent data 102 corresponding to the dictionary, with each of the 52 letters (e.g., A-Z and a-z) represented by values ​​corresponding to several bits. To further compress the dictionary, compressor 104 may generate filler or copy symbols corresponding to repeated values ​​from data string 202. In this case, the repeated values ​​are 0, so that compressed data 106 corresponding to the dictionary appears as "<fill 12x> 3<fill 21x> 2<fill 6x> 2002<fill 7x> ". The compressed data analyzer 108 may analyze the compressed data 106 corresponding to the dictionary and determine segment breaks (e.g., in an example where four segments are used, the compressed data 106 may be divided into four segments). The division of the four segments is indicated by dashed lines. The metadata generator 110 may then analyze the segment information to indicate, for example, the starting input location and symbol number or index of every segment within the dictionary, to generate metadata 112 corresponding to the dictionary portion of the block of compressed data 106.

[0033] 2D , which illustrates an example table 200D 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 data 102 is “MississippiMississippiMiss,” compressor 104 may separate data 102 into two blocks for compression: a first block corresponding to “Mississippi;” and a second block corresponding to “MississippiMiss.” Accordingly, to identify the locations of different blocks within compressed data 106 and their corresponding dictionaries, compressed data analyzer 108 may analyze compressed data 106 to determine an initial input location (e.g., first input bit, nibble, byte, etc.) of each block of compressed data 106 and / or an initial output location (e.g., first bit, nibble, byte, etc.) of each block within the output stream. As a result, metadata 112 corresponding to the stream of compressed data 106 may indicate several inputs (e.g., bits, nibbles, bytes, etc.) and several outputs (e.g., bits, nibbles, bytes, etc.) for each block of compressed data 106, several inputs (e.g., bits, nibbles, bytes, etc.) and symbol numbers for each segment within each block, and / or several inputs (e.g., bits, nibbles, bytes, etc.), several outputs (e.g., bits, nibbles, bytes, etc.), and several copies for each segment within each block. If a prefix sum operation is performed, metadata 112 may instead include initial input locations and initial output locations for each block of compressed data, initial input locations and symbol indexes for each segment of the dictionary portion for each block, and / or initial input locations, initial output locations, and copy indexes for each segment of the content portion (or data portion) for each block. 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, but one or more of the blocks, dictionaries, or data is not in prefix sum format.

[0034] The metadata 112 may then be used by the decompressor 114 to decompress the compressed data 106. For example, each block of the compressed data 106 may be identified using the metadata 112 so that two or more blocks of the compressed data 106—e.g., block A and block B—can be decompressed in parallel. For each block, the metadata 112 may be used to determine a dictionary segment, e.g., one segment per thread or coprocessor, so that the dictionary can be decompressed in parallel. The dictionary may then be used to decompress content portions of the compressed stream. For example, the metadata 112 may indicate the segment of the content portion of the compressed data 106, and the decompressor 114 may use the dictionary to decode literals from the compressed data 106 and output the literals to the output stream. The decompressor 114 may further use the metadata 112 and copy information encoded in the compressed data 106 to reserve portions of the output stream for copying and store information about each copy (e.g., source location, distance, length, etc.) in a queue or data structure. 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 copy operations on deferred copies in the queue to store corresponding copied symbols in reserved placeholders in the output stream. As one example, referring to FIG. 2A , a copy of “issi” indicated by a source position of 1, a copy length of 4, and a distance of 3 may be used to copy “i” to position 4, “s” to position 5, “s” to position 6, and “i” to position 6. Because the “i” at position 6 is copied from the “i” at position 4 that did not exist before the copying began, the “i” at position 6 may be referred to as a duplicate copy. As described herein, individual copy operations may be performed in parallel in some embodiments, such that two or more of the “issi” copies may be executed in parallel using different threads of a GPU.

[0035] Furthermore, in some embodiments, when a copy is determined to be safe, separate copies may be executed in parallel. For example, referring to FIG. 2E, FIG. 2E shows an example table 400E corresponding to a copy of a compressed data stream that is not suitable for parallel processing, according to some embodiments of the present disclosure. For example, if compressed data 106 corresponds to "MississippiMississippi," compressed data 106 may include two copies (e.g., copy #1 and copy #2 shown in table 200E). In this example, when or during the execution of the first copy, decompressor 114 may determine whether one or more additional copies, e.g., second copies, may be executed in parallel. Decompressor 114 may examine the source location of the second copy and the output location of the first copy to determine whether there is an overlap. In this case, because the second copy relies on the output from the first copy, the second copy may not be safe to execute in parallel with the first copy. Thus, the first copy and the second copy may be executed sequentially.

[0036] As another example, refer to FIG. 2F, which illustrates an exemplary table 400F corresponding to copies 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 copies (e.g., copy #1 and copy #2 shown in table 200F). In this example, when or during the execution of the first copy, decompressor 114 may determine whether one or more additional copies—e.g., second copies—can be executed in parallel. Decompressor 114 may examine the source location of the second copy and the output location of the first copy to determine whether there is an overlap. In this case, because the second copy does not rely on the output from the first copy (e.g., because the second copy can be executed without requiring the results from the first copy to be stored in an output buffer), it may be safe to execute the second copy in parallel with the first copy. Thus, the first copy and the second copy may be run in parallel, thereby providing an output of eight symbols at once, instead of four symbols and four symbols sequentially.

[0037] Referring now to FIGS. 3-4, each block of methods 300 and 400 described herein includes a computing process that may be implemented using any combination of hardware, firmware, and / or software. For example, various functions may be performed by a processor executing instructions stored in 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 hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few examples. Furthermore, methods 300 and 400 are described with reference to process 100 of FIG. 1 as an example. However, methods 300 and 400 may additionally or alternatively be performed within any single process by any single system, or any combination of processes and systems, including, but not limited to, the processes and systems described herein.

[0038] 3, which illustrates a flow diagram corresponding to a method 300 for generating metadata for a compressed data stream for parallel decompression of the compressed data stream, in accordance with some embodiments of the present disclosure. The method 300 includes, at block B302, parsing the compressed data. For example, the compressed data analyzer 108 may analyze the compressed data 106.

[0039] The method 300 includes determining, at block B304, separations between the segments of the compressed data. For example, the compressed data analyzer 108 may determine separations between the segments of the compressed data 106.

[0040] At block B306, the method 300 includes generating, for at least two of the plurality of segments based in part on the delimitation, metadata indicating an initial input location in the compressed data and an initial output location in the output data corresponding to each data segment 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 locations, initial output locations, and / or copy indexes for some or all of the segments of the content portion of each block of the compressed data 106.

[0041] The method 300 includes sending the compressed data and the metadata to a decompressor 114 at block B308. 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.

[0042] 4, which illustrates a flow diagram corresponding to a method 400 for decompressing compressed data streams in parallel, according to some embodiments of the present disclosure. The method 400 includes, at block B402, receiving compressed data and corresponding metadata. For example, the decompressor 114 may receive the compressed data 106 and the metadata 112.

[0043] The method 400 includes determining, at block B404, initial input and output locations corresponding to the compressed data based on the metadata. For example, the metadata 112 may indicate an initial input location within the compressed data 106 and an initial output location within the output data stream corresponding to each block of the compressed data 106.

[0044] The method 400 includes determining, at block B406, input dictionary locations and symbol indexes for two or more dictionary segments of the dictionary of the compressed data based on the initial input location and the initial output location. For example, the metadata 112 may indicate the initial input location and symbol index for the segment of the dictionary that corresponds to the compressed data 106.

[0045] The method 400 includes expanding the dictionary at least partially in parallel based on the input dictionary location at block B408. For example, the metadata 112 may indicate the segments of the dictionary, and this information may be used by the expander 114 to process each segment of the dictionary in parallel using threads of the GPU.

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

[0047] At block B412, the method 400 includes decompressing at least two segments in parallel according to the input segment location and the output segment location to generate a decompressed output. For example, the decompressor 114 may use the metadata 112 and the dictionary to generate the data 102 from the compressed data 106. Thus, once the data 102 is recovered, it may be used at the receiving end to perform one or more operations. For example, if the data 102 is compressed and passed from the CPU to a GPU for parallel processing, the data may then be passed back to the CPU. If the data 102 corresponds to text, a message, or an email, the data may be displayed on a device, such as a user device or a client device. If the data 102 corresponds to video, audio, an image, or the like, the data may be output using a display, speakers, a headset, earphones, or the like. If the data 102 corresponds to a website, the website may be displayed within a browser on the receiving device, such as a user device or a client device. Thus, the decompressed data may be used in any of a variety of ways, and parallel decompression may be made available more quickly while using fewer memory resources compared to traditional approaches.

[0048] Exemplary Computing Devices 5 is a block diagram of an example computing device 500 suitable for use in implementing some embodiments of the present disclosure. Computing device 500 may include an interconnection 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, input / output components 514, a power supply 516, one or more presentation components 518 (e.g., displays), and one or more logic units 520. In at least one embodiment, computing device 500 may include one or more virtual machines (VMs), and / or any of its components may include virtual components (e.g., virtual hardware components). As non-limiting examples, one or more of GPUs 508 may include one or more vGPUs, one or more of CPUs 506 may include one or more vCPUs, and / or one or more of logical units 520 may include one or more virtual logical units. Thus, computing device 500 may include discrete components (e.g., a full GPU dedicated to computing device 500), virtual components (e.g., a portion of a GPU dedicated to computing device 500), or a combination thereof.

[0049] While the various blocks in FIG. 5 are shown as connected with lines via interconnect system 502, this is not intended to be limiting and is 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, CPU 506 and / or GPU 508 may include memory (e.g., memory 504 may represent a storage device in addition to the memory of GPU 508, CPU 506, and / or other components). In other words, the computing devices in FIG. 5 are merely exemplary. 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 they are all contemplated to be within the scope of the computing devices in FIG. 5 .

[0050] The interconnect system 502 may represent one or more links or one or more buses, such as an address bus, a data bus, a control bus, or a combination thereof. The interconnect system 502 may include one or more bus or link types, such as an industry standard architecture (ISA) bus, an extended industry standard architecture (EISA) bus, a video electronics standards 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 are direct connections between components. As one example, the CPU 506 may be directly connected to the memory 504. Further, the CPU 506 may be directly connected to the GPU 508. When there are direct or point-to-point connections between components, the interconnect system 502 may include a PCIe link to make the connection. In these instances, a PCI bus need not be included in computing device 500 .

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

[0052] Computer storage media may include both volatile and nonvolatile media, and / or removable and non-removable media implemented in any method or technology for storage of 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 disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the desired information and that can be accessed by computing device 500. As used herein, computer storage media does not include the signals themselves.

[0053] Computer storage media may embody computer-readable instructions, data structures, program modules, and / or other data types, such as modulated data signals, such as carrier waves or other transport mechanisms, and may 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 in the signal. By way of example, and not limitation, computer storage media may include wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

[0054] The CPU 506 may be configured to execute at least some of the 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. The CPUs 506 may each include one or more cores (e.g., 1, 2, 4, 8, 28, 72, etc.) capable of simultaneously handling multiple software threads. The CPUs 506 may include any type of processor, and may include different types of processors depending on the type of computing device 500 implemented (e.g., a processor with fewer cores for a mobile device and a processor with more cores for a server). For example, depending on the type of computing device 500, the processor may 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). Computing device 500 may include one or more CPUs 506 in addition to one or more microprocessors or auxiliary coprocessors such as math coprocessors.

[0055] In addition to, or alternatively to, CPU 506, GPU 508 may be configured to execute at least some of the computer-readable instructions to control one or more components of computing device 500 to perform one or more of the methods and / or processes described herein. One or more of GPUs 508 may be an integrated GPU (e.g., with one or more of CPUs 506 and / or one or more of GPUs 508 may be a discrete GPU. In an embodiment, one or more of GPUs 508 may be a coprocessor of one or more of CPUs 506. GPU 508 may be used by computing device 500 to render graphics (e.g., 3D graphics) or perform general-purpose computation. For example, GPU 508 may be used for general-purpose computing on GPU (GPGPU). The GPU 508 may be used for graphics processing (GPU). The GPU 508 may include hundreds or thousands of cores capable of handling hundreds or thousands of software threads simultaneously. The GPU 508 may generate pixel data to output images in response to rendering commands (e.g., rendering commands from the CPU 506 received 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. 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 coupled together, each GPU 508 may generate pixel data or GPGPU data for a different portion of the output or for a different output (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.

[0056] In addition to or alternatively to the CPU 506 and / or GPU 508, the logic unit 520 may be configured to execute at least some of the 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. In an embodiment, the CPU 506, the GPU 508, and / or the logic unit 520 may separately or jointly perform any combination of methods, processes, and / or portions thereof. One or more of the logic units 520 may be part of and / or integrated into one or more of the CPUs 506 and / or GPUs 508, and / or one or more of the logic units 520 may be separate components or may be external to the CPUs 506 and / or GPUs 508. In an embodiment, one or more of the logic units 520 may be a coprocessor of one or more of the CPUs 506 and / or GPUs 508.

[0057] Examples of the logic unit 520 include a tensor core (TC), a tensor processing unit (TPU), a pixel visual 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), a scalable processor (SPC ... In some embodiments, there may be one or more processing cores and / or their components, such as a PCI Express (Peripheral Component Interconnect) Unit, an Input / Output (I / O) element, a Peripheral Component Interconnect (PCI) element, or a Peripheral Component Interconnect Express (PCIe) element.

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

[0059] The I / O ports 512 may 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 may be incorporated into (e.g., built into) the computing device 500. Exemplary I / O components 514 include a microphone, mouse, keyboard, joystick, game pad, game controller, satellite dish, scanner, printer, wireless device, etc. The I / O components 514 may provide a natural user interface (NUI) that processes air gestures, voice, or other physiological input generated by a user. In some examples, the input may be routed to an appropriate network element for further processing. The NUI may implement any combination of voice recognition, stylus recognition, facial recognition, biometric recognition, gesture recognition both on-screen and adjacent to the screen, air gestures, head and eye tracking, and touch recognition associated with the display of computing device 500 (described in more detail below). Computing device 500 may include a depth camera, such as a stereo camera system, an infrared camera system, an RGB camera system, touchscreen technology, and combinations thereof, for gesture detection and recognition. Additionally, computing device 500 may include an accelerometer or gyroscope (e.g., as part of an inertia measurement unit (IMU)) to enable detection of movement. In some instances, the output of the accelerometer or gyroscope may be used by computing device 500 to render immersive augmented or virtual reality experiences.

[0060] The power supply 516 may include a hard-wired 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.

[0061] The presentation component 518 may include a display (e.g., a monitor, a touch screen, a television screen, a heads-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.).

[0062] Exemplary Data Center

[0063] 6 illustrates an example data center 600 that may be used in at least one embodiment of the present disclosure. Data center 600 may include a data center infrastructure layer 610, a framework layer 620, a software layer 630, and / or an application layer 640.

[0064] 6, the data center infrastructure layer 610 may include a resource orchestrator 612, grouped computing resources 614, and node computing resources (“node CRs”) 616(1) through 616(N), where “N” represents any positive integer. In at least one embodiment, the node CRs 616(1) through 616(N) may include, without limitation, any number of central processing units (“CPUs”) or other processors (including accelerators, field programmable gate arrays (FPGAs), graphics processors, or graphics processing units (GPUs)), 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. In some embodiments, one or more of the nodes CR 616(1)-616(N) may correspond to a server having one or more of the computing resources described above. Additionally, in some embodiments, the nodes CR 616(1)-616(N) may include one or more virtual components, such as a vGPU, a vCPU, etc., and / or one or more of the nodes CR 616(1)-616(N) may correspond to a virtual machine (VM).

[0065] In at least one embodiment, the grouped computing resources 614 may include distinct groupings of nodes CR616 housed in one or more racks (not shown) or in many racks (also not shown) housed in data centers in various geographic locations. The distinct groupings of nodes CR616 within the grouped computing resources 614 may include grouped compute, network, memory, or storage resources that may be configured or assigned to support one or more workloads. In at least one embodiment, several nodes CR616 including CPUs, GPUs, and / or other processors may be grouped within one or more racks to provide compute resources to support one or more workloads. The one or more racks may also include any number of power modules, cooling modules, and / or network switches in any combination.

[0066] The resource orchestrator 622 may configure or control one or more nodes CR 616(1)-616(N) and / or grouped computing resources 614. In at least one embodiment, the resource orchestrator 622 may include a software design infrastructure (“SDI”) management entity for the data center 600. The resource orchestrator 622 may include hardware, software, or some combination thereof.

[0067] In at least one embodiment, as shown in FIG. 6 , framework layer 620 may include a job scheduler 632, a configuration manager 634, a resource manager 636, and / or a distributed file system 638. Framework layer 620 may include a framework supporting software 632 in software layer 630 and / or one or more applications 642 in application layer 640. Software 632 or applications 642 may each include web-based service software or applications, such as service software or applications offered by Amazon Web Services, Google Cloud, and Microsoft Azure. Framework layer 620 may be a type of free, open-source software web application framework, such as, but not limited to, Apache Spark™ (hereinafter “Spark”), which may utilize distributed file system 638 for large-scale data processing (e.g., “big data”). In at least one embodiment, job scheduler 632 may include a Spark driver that facilitates scheduling of workloads supported by various tiers of data center 600. The configuration manager 634 may be capable of configuring different layers, such as the software layer 630, the framework layer 620 including Spark, and the distributed file system 638, to support large-scale data processing. The resource manager 636 may be capable of managing clustered or grouped computing resources mapped to or allocated 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 in the data center infrastructure layer 610. The resource manager 636 may coordinate with the resource orchestrator 612 to manage these mapped or allocated computing resources.

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

[0069] In at least one embodiment, the applications 642 included in the application layer 640 may include one or more types of applications used by the nodes CRs 616(1)-616(N), the grouped computing resources 614, and / or at least a portion of 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 connection with one or more embodiments.

[0070] In at least one embodiment, any of configuration manager 634, resource manager 636, and resource orchestrator 612 may implement any number and types of self-correcting actions based on any amount and type of data obtained in any technically feasible manner. The self-correcting actions may save data center operators of data center 600 from making potentially poor configuration decisions and potentially avoid underutilized and / or poorly performing portions of the data center.

[0071] Data center 600 may include tools, services, software, or other resources for training one or more machine learning models or predicting or inferring information using one or more machine learning models 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 data center 600. In at least one embodiment, the trained or deployed machine learning model corresponding to one or more neural networks may be used to infer or predict information using the resources described above with respect to data center 600 by using the weight parameters calculated through one or more training techniques, such as, but not limited to, the training techniques described herein.

[0072] In at least one embodiment, data center 600 may use CPUs, application specific integrated circuits (ASICs), GPUs, FPGAs, and / or other hardware (or corresponding virtual compute resources) to perform training and / or inference using the resources described above. Additionally, one or more of the software and / or hardware resources described above may be configured as services that enable users to train or perform inference on information, such as image recognition services, speech recognition services, or other artificial intelligence services.

[0073] Example Network Environment A network environment suitable for use in implementing embodiments of the present disclosure may include one or more client devices, servers, network attached storage (NAS), other back-end devices, and / or other device types. The client devices, servers, and / or other device types (e.g., each device) may be implemented on one or more instances of computing device 500 of FIG. 5—e.g., each device may include similar components, features, and / or functionality of computing device 500. Furthermore, if a back-end device (e.g., server, NAS, etc.) is implemented, the back-end device may be included as part of data center 600, an example of which is described in more detail herein with reference to FIG. 6.

[0074] Components in a networked environment may communicate with each other over a network, which may be wired, wireless, or both. A network may include multiple networks or a network of networks. By way of example, a network may 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 the public switched telephone network (PSTN), and / or one or more private networks. When a network includes a wireless telecommunications network, components such as base stations, communication towers, or even access points (as well as other components) may provide wireless connectivity.

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

[0076] In at least one embodiment, the network environment may include one or more cloud-based network environments, distributed computing environments, combinations thereof, etc. 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 of the servers, which may include one or more core network servers and / or edge servers. The framework layer may include software in the software layer and / or a framework supporting one or more applications in the application layer. The software or applications may each include web-based service software or applications. In an embodiment, one or more of the client devices may use the 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 a type of free, open-source software web application framework, such as, but not limited to, one that may utilize a distributed file system for large-scale data processing (e.g., “big data”).

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

[0078] A client device may include at least some of the components, features, and functionality of the exemplary computing device 500 described herein with reference to Figure 5. By way of example and not limitation, a client device may be embodied as a personal computer (PC), a laptop computer, a mobile device, a smartphone, a tablet computer, a smart watch, 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 video camera, a surveillance device or system, a vehicle, a boat, a flying vessel, a virtual machine, a drone, a robot, a handheld communications device, a hospital device, a gaming device or system, an entertainment system, an in-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 recited devices, or any other suitable device.

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

[0080] As used herein, the term "and / or" in reference to two or more elements should be interpreted to mean only one element or a combination of elements. For example, "element A, element B, and / or element C" may include element A only, element B only, element C only, elements A and B, elements A and C, elements B and C, or elements A, B, and C. Furthermore, "at least one of element A or element B" may 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. Furthermore, "at least one of element A and element B" may 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.

[0081] The subject matter of the present disclosure is described with particularity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of the disclosure. Rather, the inventors contemplate that the claimed subject matter may be embodied in other ways, including different steps or combinations of steps similar to those described in this document, along with other current or future technologies. Furthermore, although the terms "step" and / or "block" may be used herein to connote different elements of a method employed, these terms should not be construed to imply any particular order among the various steps disclosed herein unless and when the order of individual steps is explicitly described.

Claims

1. 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 input segment locations and output segment locations for at least two segments of the plurality of segments of the compressed data based at least in part on the initial input location and the initial output location; unfolding the at least two segments at least partially in parallel according to the input segment locations and the output segment locations to generate unfolded outputs; A method comprising:

2. determining an input dictionary location and symbol index for each dictionary segment of a dictionary for the block of compressed data based at least in part on the metadata; Expanding said dictionary; further comprising said expanding said plurality of segments is performed using said dictionary; The method of claim 1.

3. The method of claim 2 , wherein the unfolding of the dictionary is performed in parallel such that each dictionary segment of the dictionary is unfolded using a respective thread of a processor.

4. The method of claim 2 , further comprising determining a copy index value for each segment of the plurality of segments of the compressed data based at least in part on the metadata.

5. 3. The method of claim 2, wherein for at least two blocks of the plurality of blocks of the compressed data, the initial input location indicates one or more block input locations, the initial output location indicates one or more block output locations, and the plurality of segments corresponds to a single block of the plurality of blocks.

6. 6. The method of claim 5, wherein two or more of the plurality of blocks are expanded in parallel using two or more processor resources.

7. The method of claim 6 , wherein each block of the two or more blocks is processed using a respective warp of a graphics processing unit (GPU).

8. The method of claim 6 , wherein the unrolling of the at least two segments in parallel comprises unrolling each segment in parallel using a separate processing thread of a processor.

9. 3. The method of claim 2, wherein the decompressing the at least two segments comprises performing a pass over 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. 10. The method of claim 9, wherein the unfolding the at least two segments comprises performing another pass over 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. 11. The method of claim 10, wherein at least one copy operation of the one or more copy operations is performed in parallel with one or more other copy operations of the one or more copy operations.

12. 11. 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. 2. The method of claim 1, wherein the compressed data includes at least one of a variable length of bits for encoding symbols within the compressed data or a variable output size for one or more copy operations encoded within 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. analyzing the compressed data to determine boundaries between a plurality of segments of the compressed data; generating, for at least two segments of the plurality of segments based at least in part on the delimitation, metadata indicating an initial input location within the compressed data and an initial output location within the output data corresponding to each segment of the at least two segments; sending the compressed data and the metadata to a decompressor; A method comprising:

16. The method of claim 15 , wherein the metadata further indicates copy indexes corresponding to the at least two segments.

17. determining additional separations between dictionary segments of a dictionary corresponding to the compressed data based at least in part on the analyzing; and generating additional metadata indicating at least one more initial input location for each dictionary segment of the dictionary within the compressed data; further comprising said sending further comprising sending said additional metadata.

16. The method of claim 15.

18. determining additional separations between additional segments of the compressed data based at least in part on said analyzing; generating additional metadata indicating a different initial input location for each additional segment of said compressed data; further comprising said sending further comprising sending said additional metadata.

16. The method of claim 15.

19. the compressed data is compressed according to a DEFLATE compression format, and the method comprises: determining additional segments within the compressed data based at least in part on said analyzing; generating additional metadata indicating another initial input location corresponding to the additional segment; further comprising said sending further comprising sending said additional metadata.

16. The method of claim 15.

20. 16. 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. 16. The method of claim 15, wherein the compressed data is compressed according to at least one of the Lembel-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. 16. The method of claim 15, wherein the compressed data includes at least one of a variable length of bits for encoding symbols within the compressed data or a variable output size for one or more copy operations encoded within 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. one or more processors; one or more memory devices that, when executed using said one or more processors, cause said one or more processors to: a compressed data analyzer for identifying segments of compressed data; a metadata generator that generates, based at least in part on the identified segments, metadata indicating an initial input location, an initial output location, and a copy index for each identified segment of the compressed data; and receiving the compressed data and the metadata; processing the identified segments in accordance with the metadata at least partially in parallel using threads of a processor; outputting the literal symbol to an output and outputting copy information to a deferred copy queue based at least in part on said processing; processing the copy information to output copied symbols to the output; Deployer one or more memory devices storing instructions for instantiating the A system comprising:

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

27. 26. The system of claim 25, wherein said processing said copy information comprises processing a first copy operation in parallel with a second copy operation.

28. 26. The system of claim 25, wherein said processing said copy information comprises processing a first symbol of a copy operation in parallel with a second symbol of said copy operation.

29. the compressed data analyzer further identifies blocks within the compressed data; the identified segment corresponds to a block of two or more segments; 26. The system of claim 25.

30. the compressed data analyzer further identifies a dictionary segment of a dictionary corresponding to the identified segment; the metadata further indicates an initial dictionary location of the dictionary segment; the dictionary segments are processed in parallel to generate the dictionary; said processing said identified segments is based at least in part on said dictionary; 26. The system of claim 25.

31. 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. 26. The system of claim 25, wherein the compressed data includes at least one of a variable length of bits for encoding symbols within the compressed data or a variable output size for copies encoded within the compressed data.

33. The system comprises: Control systems for autonomous or semi-autonomous machines, Perception systems for autonomous or semi-autonomous machines, a system for performing simulation calculations; A system for performing deep learning computations; A system for conducting real-time streaming broadcasts, A system for implementing video monitoring services; A system for performing intelligent video analytics; Systems implemented using edge devices, A system for generating ray-traced graphical output; a system incorporating one or more virtual machines (VMs); a system implemented at least in part within a data center; or A system implemented at least in part using cloud computing resources 26. The system of claim 25, wherein the system is provided in at least one of:

34. receiving compressed data and metadata corresponding to the compressed data, the metadata indicating initial input and output locations corresponding to the compressed data and input and output segment locations for at least two segments of the plurality of segments of the compressed data; unfolding the at least two segments at least partially in parallel using inputs corresponding to locations indicated by the initial input location and the input segment location, wherein outputs of the unfolding have locations corresponding to the initial output location and the output segment location; A method comprising:

Images