Internet of Things floating point time sequence data compression transmission and decompression reading method based on GPU (Graphics Processing Unit)

Abstract

The invention particularly relates to an Internet of Things floating point time sequence data compression transmission and decompression reading method based on a GPU. According to the scheme, an asynchronous pipeline scheduling mechanism driven by a lightweight asynchronous event is adopted in the data batch transmission and compressed data flow return process between a CPU and a GPU, so that the problem of high transmission delay caused by data transmission in an existing GPU compression scheme is solved; on the other hand, an accurate and rapid floating-point number-to-integer conversion method with theoretical guarantee is provided, and the problem of precision loss existing in a traditional rapid conversion method is solved; besides, a bit-plane adaptive coding scheme is also designed, so that an optimal storage strategy can be dynamically selected for different parts of the data, and the negative influence of an abnormal value on the compression ratio is effectively overcome. According to the scheme provided by the invention, on the premise of ensuring that the data is absolutely lossless, the compression and decompression speed obviously superior to those of the existing CPU and GPU schemes can be realized, and the data communication transmission compression ratio and throughput in the Internet of Things system can be obviously improved.

Description

Technical Field

[0001] This invention relates to the field of IoT big data communication technology, specifically to a GPU-based method for IoT floating-point time-series data compression, transmission, decompression, and reading. Background Technology

[0002] In recent years, the Internet of Things (IoT) technology has made significant progress. In typical IoT scenarios, large amounts of floating-point time-series data (or simply time series data) are continuously generated by various sensors in a streaming manner and then transmitted to servers with limited bandwidth for further real-time analysis and processing. For example, a single flight can generate up to 0.5TB of sensor data, while a single scientific simulation can generate data in the TB or even PB range. These application scenarios have the following characteristics: 1) Limited bandwidth. The amount of time series data is enormous, but the network bandwidth between sensors and servers is usually limited. For example, the widely used wireless network communication protocol Zigbee has a defined rate of only 250 kbit / s. 2) Fault tolerance. On the one hand, sensors themselves have a certain degree of measurement error; on the other hand, some applications do not actually require precise sensor readings. For example, in daily life, only temperature readings with a maximum of two decimal places are of concern. Therefore, the compression processing of such data allows for distortion within a specified error range. 3) High real-time requirements. Many critical applications rely on real-time data analysis, meaning that each record should be sent to the server immediately once it is generated. For example, through school bus tracking and monitoring systems, parents, schools, and regulatory agencies can monitor the situation and safety inside school buses in real time.

[0003] In light of the above characteristics, compressing these IoT floating-point time-series data before transmission, while ensuring absolute data fidelity, is crucial for saving transmission and data storage costs at the receiving end, as well as improving data transmission efficiency between the acquisition and receiving ends.

[0004] Currently, leveraging the massively parallel computing capabilities of modern graphics processing units (GPUs) has made it possible to achieve unprecedented compressed throughput.

[0005] Current mainstream compression technologies can be categorized as follows:

[0006] (1) General lossless compression algorithms. Gzip and Lz4 data are used, so they cannot effectively utilize the inherent patterns in the data, resulting in a generally unsatisfactory compression ratio.

[0007] (2) CPU compression algorithms specifically for floating-point numbers. To improve compression performance, researchers have developed a variety of lossless compression algorithms for the characteristics of floating-point data. The implementation of these algorithms is mainly limited by the computing power of the central processing unit (CPU). For example, algorithms such as Elf, ALP, and Elf* can achieve excellent compression ratios, but their compression and decompression throughput is limited by their CPU-based implementation, leaving a huge room for improvement in hardware acceleration.

[0008] (3) GPU-based floating-point compression algorithms. In recent decades, the exponential development of hardware has positioned GPUs as highly promising accelerators in the field of floating-point compression. Although some GPU-accelerated general-purpose lossless compressors have emerged, their compression performance is still not ideal. Some hybrid schemes first reorganize records through clustering to co-locate related data, and then use GPUs for general compression. Although this scheme moderately improves the compression ratio and throughput, it suffers from insufficient GPU resource utilization and a lack of dedicated floating-point encoding and decoding mechanisms. A few floating-point compression methods designed specifically for GPUs are mainly aimed at scientific computing data and lack sophisticated CPU-GPU co-design, resulting in poor compression ratio and reduced throughput when processing general floating-point datasets.

[0009] In summary, although GPUs possess powerful parallel computing capabilities, their logical operation capabilities are weaker compared to CPUs. Existing CPU-based floating-point compressors are incompatible with GPU architectures due to their fundamentally different execution models. Therefore, establishing a robust CPU-GPU collaborative mechanism to fully leverage the advantages of GPU resources for efficient and lossless compression and transmission of IoT floating-point time-series data has become a crucial research topic for improving the compression rate and throughput of data communication between sensors and servers in IoT systems. Summary of the Invention

[0010] To address the shortcomings of the existing technologies, the technical problem to be solved by this invention is: how to provide a GPU-based method for compressing, transmitting, decompressing, and reading floating-point time-series data for the Internet of Things (IoT), solving the problem of high transmission latency caused by data transmission in existing GPU compression schemes, and ensuring the accuracy of data transmission, thereby significantly improving the data communication transmission compression rate and throughput in IoT systems.

[0011] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0012] Firstly, this invention proposes a GPU-based method for compressing and transmitting IoT floating-point time-series data. At the IoT floating-point time-series data acquisition end, the CPU reads the raw floating-point time-series data to be compressed in batches and transmits the read data batches to the GPU. The GPU divides each data batch into multiple floating-point data blocks and assigns them to different GPU threads to perform compression processing in parallel. Each GPU thread compresses one floating-point data block, and then each GPU thread writes its compressed data block into global memory in parallel, forming a continuous compressed data stream that flows back to the CPU. The data batch transmission and compressed data stream return between the CPU and GPU are executed using an asynchronous pipeline mechanism. Finally, the CPU at the acquisition end processes the obtained compressed data stream for external transmission.

[0013] As a preferred solution, the asynchronous pipeline mechanism is used to perform batch data transfer and compressed data stream return between the CPU and GPU as follows:

[0014] The CPU performs asynchronous concurrent transmission of multiple data batches at the data batch granularity. The transmission and compressed data stream return process for each data batch is divided into three state stages: Idle, MPend (metadata waiting), and PPend (data waiting). The Idle state represents the initial state of the data batch before processing begins; the MPend state represents the state where the CPU is waiting for the compressed data block size of the data batch after transmitting it to the GPU; and the PPend state represents the state where the CPU is waiting for the compressed data stream to return.

[0015] During the processing of each data batch transfer and compressed data stream return between the CPU and GPU, the CPU allocates a pipeline for each data batch and configures several pipelines to execute the transfer of multiple data batches in parallel and asynchronously. For each pipeline, before the CPU is ready to execute the transfer of a data batch, the pipeline first enters the idle state. When the CPU is ready to start executing the transfer of the data batch, the pipeline enters the metadata waiting state MPend and remains in this state until the GPU performs compression processing and returns the compressed data block size. When the GPU completes the compression processing of the data batch, it writes the resulting compressed data blocks to global memory and sends the compressed data block size information to the CPU. When it is ready to execute the compressed data stream return, the pipeline is triggered to enter the data waiting state PPend. Then the GPU returns the formed compressed data stream to the CPU. After the return is completed, the data waiting state PPend ends, and the pipeline re-enters the idle state, waiting for the CPU to allocate the next data batch.

[0016] Therefore, the transmission of data batches by each pipeline is executed sequentially according to the above three state stages. Different state stages of data batch transmission by different pipelines can be executed asynchronously and concurrently until the compression processing of all data batches is completed.

[0017] As a preferred approach, the process of allocating and deploying multiple GPU threads to perform compression processing in parallel on the GPU includes the following steps:

[0018] S1: For each floating-point data block, calculate and determine the maximum number of decimal places within the floating-point data block. and the corresponding maximum number of significant decimal digits. Based on this, each floating-point number contained in the floating-point data block is converted into an integer, and the resulting integer sequence is processed. Encode the integers to obtain the corresponding encoded sequence. ;

[0019] S2: The integer encoding sequence corresponding to each floating-point data block Extract the first integer encoded value. The remaining integer encoded values ​​are combined to form a new integer encoded sequence. Bit-plane conversion is performed to obtain the integer encoded sequence. Corresponding bit plane matrix Determine the bit plane matrix The bit width w;

[0020] S3: For each floating-point data block, according to the preset bit-plane encoding method, the maximum number of decimal places corresponding to the floating-point data block is... Maximum number of significant decimal digits Integer encoded value Bit width w and bit plane matrix Perform bit-plane encoding to obtain the compressed data block corresponding to the floating-point data block;

[0021] S4: Through the parallel synchronization primitive, the compressed data blocks generated by all GPU threads are aggregated. Each thread calculates its write offset in the global output buffer based on the size of its compressed data block and the global aggregation result. Then, each GPU thread writes its own compressed data block to global memory in parallel according to its own write offset in the global output buffer, forming a continuous compressed data stream back to the CPU.

[0022] As a preferred option, step S1 specifically involves:

[0023] S101: For each floating-point data block, calculate the set of the original decimal places for all floating-point values ​​within the floating-point data block. and the initial set of significant decimal digits ;in, , The first and second floating-point data blocks are respectively the first and second floating-point data blocks. floating-point values The corresponding number of decimal places and significant digits; n is the number of 64-bit floating-point numbers contained in a floating-point data block, and n = K×64+1, where K is the preset floating-point data block size coefficient, and K is an integer;

[0024] S102: Determine the maximum number of decimal places within the floating-point data block. And based on the maximum number of decimal places Recalculate the set of decimal significant digits within the floating-point data block. And determine the maximum number of significant decimal digits. :

[0025] ;

[0026] S103: Regarding the maximum number of decimal places and the maximum number of significant decimal digits The value is used to determine the result; if and If so, proceed to step S104; or Then proceed to step S105;

[0027] S104: Transfer the floating-point values ​​within the floating-point data block. Convert to integer as follows: :

[0028] , ;

[0029] The `round()` function rounds floating-point values ​​to integers, thus generating a sequence of integers. Then proceed to step S106;

[0030] S105: Transfer the floating-point values ​​within the floating-point data block. Convert to integer as follows: :

[0031] , ;

[0032] Here, Binlong() represents the conversion operation that converts a floating-point value to a long integer; Zigzag() represents Zigzag encoding; thus, the integer sequence is obtained. Then proceed to step S106;

[0033] S106: Transfer the integer sequence Convert to an integer encoded sequence using the following encoding method. ,in:

[0034] ;

[0035] Zigzag() represents Zigzag encoding.

[0036] As a preferred option, step S2 specifically involves:

[0037] For each floating-point data block, the corresponding integer encoding sequence Extract the first integer encoded value. Then, the remaining integer encoded values ​​are combined to form a new integer encoded sequence. ;

[0038] Then, the integer encoding sequence Each 64-bit integer encoded value View it as a row vector Calculate the encoded values ​​of each integer. The minimum number of leading zeros in the corresponding row vector. min Pruning the integer encoding sequence The common lead of all integer encoded values min A series of leading zeros form an integer encoding sequence. Corresponding bit plane matrix ; where, bit plane matrix The bit width w = 64 - lead min .

[0039] As a preferred option, step S3 specifically involves:

[0040] S301: For each floating-point data block, for the bit plane matrix Transpose the matrix to obtain the transposed bit plane matrix. ;

[0041] S302: According to the transposed bit plane matrix The number of zero bytes included determines the transposed bit plane matrix. The storage scheme for each byte; the storage scheme includes sparse storage and dense storage;

[0042] S303: According to the preset bit-plane encoding method, the maximum number of decimal places corresponding to the floating-point data block is determined. Maximum number of significant decimal digits Integer encoded value The transposed bit plane matrix is ​​processed according to the determined storage scheme. The data is arranged row by row to obtain compressed data blocks using bit-plane encoding.

[0043] As a preferred option, step S302 specifically involves:

[0044] For the transposed bit plane matrix Analyze each row independently and calculate each row. Number of zero bytes included Then, for the transposed bit plane matrix any line The storage scheme is determined based on the following conditions:

[0045] If the conditions are met Regarding the line Sparse storage is employed, using a bitmap of size (n−1) / 64 bytes to indicate zero or non-zero bytes, storing only all non-zero bytes consecutively; if the condition is not met... Regarding the line Dense storage is used, storing all (n−1) / 8 bytes of the row directly as is;

[0046] Therefore, the transposed bit plane matrix is ​​determined. Storage schemes for each row in the middle.

[0047] As a preferred embodiment, in step S303, the data format of the compressed data block using bit-plane encoding includes: 1 byte storing the maximum number of decimal places. One byte stores the maximum number of significant decimal digits. 8 bytes store the integer encoded value ; 1 byte storage width w; w-bit storage scheme selection flag, used to record the transposed bit plane matrix. The storage scheme used in each row is defined as follows: a bit value of 0 indicates sparse storage, and a bit value of 1 indicates dense storage. Finally, the transposed bit plane matrix is ​​processed according to the determined storage scheme. The data in each row is arranged and stored sequentially.

[0048] Secondly, the present invention also provides a GPU-based method for decompressing and reading IoT floating-point time series data. At the receiving end of IoT floating-point time series data, for the received compressed data stream compressed and transmitted using the aforementioned method, the CPU schedules and allocates different GPU threads to read the compressed data blocks and perform decompression processing. Each thread decompresses one compressed data block, and then each GPU thread writes its decompressed floating-point data block in parallel to a specified location in the pre-allocated GPU global memory output buffer. When all threads have completed writing, the entire decompression process ends.

[0049] The process of decompressing a compressed data block by each GPU thread includes the following steps:

[0050] SI: Based on the preset bit-plane encoding method, reverse decode to recover the maximum number of decimal places corresponding to the floating-point data block. Maximum number of significant decimal digits Integer encoded value Bit width w and bit plane matrix ;

[0051] SII: Based on the obtained bit width w and bit plane matrix The integer encoding sequence corresponding to the floating-point data block is recovered by leading zero padding. ;

[0052] SIII: According to the integer encoding sequence Reverse encoding to recover the integer sequence And according to the maximum number of decimal places and the maximum number of significant decimal digits Perform the corresponding reverse conversion to recover the floating-point data block.

[0053] As a preferred approach, in step SI, the maximum number of decimal places corresponding to the floating-point data block is recovered through reverse decoding. Maximum number of significant decimal digits Integer encoded value Bit width w and bit plane matrix The specific method is as follows:

[0054] Read the first and second bytes from the compressed data block to obtain the maximum number of decimal places. and the maximum number of significant decimal digits Then, read the next 8 bytes and the 9th byte from the compressed data block to obtain the integer encoded values. And the bit width w; then continue reading the next w bits in the compressed data block to obtain the storage scheme selection flag;

[0055] Finally, according to the scheme, the flag is selected to decode the subsequent data line by line as follows: if the flag bit value is 0, it indicates sparse storage. The GPU thread first reads the bitmap, then reads consecutive non-zero bytes from the bitmap and fills them into the correct positions to reconstruct the line. If the flag bit is 1, it indicates dense storage, and the GPU thread directly reads the corresponding number of bytes and reconstructs the data. After decoding and reconstructing all w rows, the GPU thread reconstructs the transposed bit plane matrix. Then, by reversing the bit plane matrix, the bit plane matrix can be recovered. .

[0056] Compared with the prior art, the present invention has the following beneficial effects:

[0057] 1. In the present invention, a lightweight asynchronous event-driven asynchronous pipeline scheduling mechanism is adopted in the process of data batch transmission and compressed data stream back transmission between CPU and GPU to make up for the high transmission latency caused by data transmission in the existing GPU compression scheme, which can significantly improve the overall processing throughput of data communication transmission in the Internet of Things system.

[0058] 2. The present invention proposes a method for converting floating-point numbers to integers with theoretical guarantees that is accurate and fast. This method solves the problem of precision loss in traditional fast conversion methods. Furthermore, the algorithm has simple logic and is perfectly adapted to the large-scale parallel architecture of GPUs.

[0059] 3. In this invention, a bit-plane adaptive coding scheme is also designed, which can dynamically select the optimal storage strategy for different parts of the data, effectively overcoming the negative impact of outliers on the compression ratio.

[0060] 4. The present invention can achieve compression and decompression speeds that are significantly better than existing CPU and GPU solutions while ensuring absolute data loss, and the compression effect is excellent, which can significantly improve the data communication transmission compression rate and throughput in IoT systems. Attached Figure Description

[0061] To make the objectives, technical solutions, and advantages of the invention clearer, the invention will now be described in further detail with reference to the accompanying drawings, wherein:

[0062] Figure 1 A schematic diagram of the distribution of trailing zero counts;

[0063] Figure 2 This is a flowchart illustrating the overall process of the compression transmission and decompression reading scheme proposed in this invention.

[0064] Figure 3A schematic diagram of a floating-point layout for double-precision values;

[0065] Figure 4 Schematic diagrams of the processing flow for different pipeline scheduling schemes;

[0066] Figure 5 A schematic diagram of the workflow of an event-driven scheduler;

[0067] Figure 6 Example diagram of rounding operation;

[0068] Figure 7 Example diagram for integer conversion;

[0069] Figure 8 This is an example diagram of planar encoding (in the example, 𝑛 = 65). Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but only to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0071] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0072] like Figure 1 As shown, the design of a GPU-based method for compressing and transmitting floating-point time-series data in the Internet of Things (IoT) faces three main challenges:

[0073] Defect 1: Bottleneck in heterogeneous data movement

[0074] From the perspective of the entire compression workflow, the raw floating-point data is read from external storage by the CPU (Host) and transferred to the GPU (Device) via the PCIe bus (i.e., the H2D process). After the GPU completes the compression task, the compressed data is returned to the CPU via the PCIe bus (i.e., the D2H process), and finally written to external storage by the CPU. In this process, PCIe data transfer usually plays a bottleneck role. During this period, the CPU or GPU may enter an idle state, resulting in a decrease in overall system throughput. Therefore, how to coordinate the CPU and GPU to fully utilize PCIe bandwidth to maximize overall throughput is the primary challenge.

[0075] Defect 2: Conversion complexity while maintaining accuracy

[0076] Floating-point numbers have a complex underlying layout according to the IEEE 754 standard. Most existing floating-point compression methods involve complex logical operations to achieve high compression ratios. To avoid GPU-incompatible operations, one strategy is to convert floating-point numbers to integers before compression, which requires precise calculation of the decimal place to ensure lossless reconstruction.

[0077] For example, the numerical value 1.02 can be converted to the integer 102. However, it is not easy for machines to accurately calculate the number of decimal places. One time-consuming method is to first convert 1.02 to the string "1.02" before parsing. To speed up the calculation, the papers "Ruiyuan Li, ZhengLi, Yi Wu, Chao Chen, Songtao Guo, Ming Zhang, and Yu Zheng. 2023. Erasing-based lossless compression method for streaming floating-point time series.arXiv preprint arXiv:2306.16053 (2023)" and "Ruiyuan Li, Zheng Li, Yi Wu, ChaoChen, and Yu Zheng. 2023. Elf: Erasing-Based Lossless Floating-PointCompression. Proceedings of the VLDB Endowment 16, 7 (2023), 1763–1776" employ a trial-and-error method, but this method introduces errors due to the inherent imprecision of floating-point arithmetic. For example, most programming languages ​​consider 1.11 to be correct. The result is 111.00000000000001 (Note: This indicates a multiplication operation that might introduce errors, thus incorrectly determining that the number of decimal places is 3. Storing only the maximum number of decimal places within a floating-point data block introduces calculation errors: any error in calculating a single value can catastrophically propagate throughout the entire floating-point data block. Therefore, accurate and efficient calculation of decimal places is crucial for improving compression performance.

[0078] Defect 3: Sparsity degradation caused by outliers

[0079] Outliers frequently found in floating-point datasets are amplified during integer conversions. When converted to integer bit planes, these outliers can cause severe sparsity, thus degrading compression performance. For example... Figure 1 As shown, although 7.15 constitutes only a minor floating-point anomaly, its integer conversion result, 7150, produces a significant outlier. To minimize the overhead of bit width and leverage GPU parallelism, a bit-aligned planar representation is typically used, representing each integer with a fixed 13 bits. This results in excessive leading-zero bits for all values ​​except 7150. Therefore, handling these outlier records to further improve compression performance is another significant challenge.

[0080] To address the bottlenecks in heterogeneous data movement, difficulties in guaranteeing floating-point conversion accuracy, and fixed encoding strategies in existing technologies, this invention proposes a GPU-based method for compressing and transmitting floating-point time-series data for the Internet of Things (IoT), along with a corresponding decompression and reading method. The technical solution proposed in this invention will be described in detail below.

[0081] First, this invention proposes a method for high-throughput, high-compression-rate compressed transmission of IoT floating-point time-series data on a GPU. This method systematically addresses the performance bottlenecks encountered by existing technologies in a GPU environment through a cleverly designed parallel processing framework.

[0082] The implementation of this invention mainly revolves around the following core technical challenges:

[0083] Challenge 1: How to overcome the I / O bottleneck in heterogeneous systems? That is, how to design a scheduling mechanism that can deeply overlap the data transfer between the CPU and GPU and the GPU's own computing tasks, thereby avoiding idle hardware resources and maximizing end-to-end throughput.

[0084] Challenge 2: How to achieve parallel-friendly and lossless floating-point conversion? That is, how to design an algorithm to convert floating-point numbers to integers, which must simultaneously satisfy: 1) ensure mathematical lossless conversion and avoid floating-point operation errors; 2) the algorithm logic is simple enough, without complex branches, to perfectly adapt to the large-scale parallel execution model of GPUs.

[0085] Challenge 3: How to deal with the dynamic changes in data sparsity? That is, how to design an encoding strategy that can intelligently and with low overhead adapt to drastic changes in sparsity caused by factors such as outliers in the data, so as to maintain a high compression rate under various data distributions.

[0086] To address the aforementioned technical challenges, this invention primarily comprises core modules such as asynchronous pipeline scheduling, precise integer conversion, adaptive bit-plane encoding, and parallel synchronous writing. These will be elaborated upon below. This paper mainly focuses on 64-bit Double type floating-point data; the processing method for Float type data is similar.

[0087] like Figure 2 As shown, the overall technical framework of this invention is divided into the compression and transmission process at the IoT acquisition end ( Figure 2 (a)), and the decompression and reading process at the IoT receiver ( Figure 2 (b) Two parts. In practical applications, the IoT acquisition end can typically be an IoT edge calculator, data concentrator, or other device, used to centrally collect a large amount of floating-point time-series data generated by sensors, compress it, and then send the IoT data to the outside world; the IoT receiving end can typically be an IoT server or other device, used to receive and decompress the floating-point time-series data from the sensors, and perform data storage, analysis, and other processing.

[0088] In the GPU-based IoT floating-point time-series data compression and transmission process proposed in this invention, at the IoT floating-point time-series data acquisition end, the CPU reads the raw floating-point time-series data to be compressed in batches and transmits the read data batches to the GPU. The GPU divides each data batch into multiple floating-point data chunks and assigns them to different GPU threads to perform compression processing in parallel. Each GPU thread compresses one floating-point data chunk, and then each GPU thread writes its compressed data chunks to global memory in parallel, forming a continuous compressed data stream that flows back to the CPU. The data batch transmission and compressed data stream return between the CPU and GPU are executed using an asynchronous pipeline mechanism. Finally, the CPU at the acquisition end processes the obtained compressed data stream for external transmission.

[0089] like Figure 2As shown, the process of allocating and scheduling multiple GPU threads to perform compression processing in parallel on a GPU includes the following steps:

[0090] S1: For each floating-point data block, calculate and determine the maximum number of decimal places within the floating-point data block. and the corresponding maximum number of significant decimal digits. Based on this, each floating-point number contained in the floating-point data block is converted into an integer, and the resulting integer sequence is processed. Encode the integers to obtain the corresponding encoded sequence. ;

[0091] S2: The integer encoding sequence corresponding to each floating-point data block Extract the first integer encoded value. The remaining integer encoded values ​​are combined to form a new integer encoded sequence. Bit-plane conversion is performed to obtain the integer encoded sequence. Corresponding bit plane matrix Determine the bit plane matrix The bit width w;

[0092] S3: For each floating-point data block, according to the preset bit-plane encoding method, the maximum number of decimal places corresponding to the floating-point data block is... Maximum number of significant decimal digits Integer encoded value Bit width w and bit plane matrix Perform bit-plane encoding to obtain the compressed data block corresponding to the floating-point data block;

[0093] S4: Through the parallel synchronization primitive, the compressed data blocks generated by all GPU threads are aggregated. Each thread calculates its write offset in the global output buffer based on the size of its compressed data block and the global aggregation result. Then, each GPU thread writes its own compressed data block to global memory in parallel according to its own write offset in the global output buffer, forming a continuous compressed data stream back to the CPU.

[0094] The above processing flow can be summarized into four core steps: ① Integer Conversion: Using a precise and parallel-friendly algorithm to convert floating-point numbers to integers without loss; ② Adaptive Bit-Plane Encoding: Performing efficient bit-plane encoding on the converted integers, capable of adapting to dynamic changes in data sparsity; ③ Compressed Size Sync: Using a two-layer parallel synchronization mechanism, quickly calculating the precise write position of each compressed block in the final output stream; ④ Chunk Writing: Each thread writes its own compression result to global memory in parallel, forming a continuous compressed data stream, which is eventually transmitted back to the CPU.

[0095] The decompression and reading process at the IoT receiver is the reverse of the above process, and is also executed in parallel on the GPU.

[0096] The following is a detailed explanation.

[0097] 1. Prior knowledge and definitions

[0098] To facilitate an accurate understanding of the technical solution of this invention, the key terms and background knowledge involved in the solution are first defined.

[0099] 1.1 IEEE 754 floating-point format

[0100] The floating-point numbers processed in this invention conform to the IEEE 754 standard. Taking double-precision floating-point numbers as an example, they are composed of 64 bits of binary data, such as... Figure 3 As shown. These 64 bits are divided into three parts: Sign (s): 1 bit, used to indicate the sign of the value (0 for positive, 1 for negative); Exponent (e): 11 bits, stored in biased form, used to determine the position of the decimal point; Mantissa (m): 52 bits, also called significant bits, used to represent the precision of the value. A non-zero regular floating-point value v can be represented by the following formula:

[0101] ;

[0102] Where e is the unsigned integer value of the exponent, the expression It represents a binary fractional number whose integer part is an implicit "1" and whose fractional part consists of a 52-bit mantissa m.

[0103] Calculation imprecision and unit end precision (ULP):

[0104] Due to limitations in storage bits, floating-point arithmetic in computers has inherent imprecision. For example, in mathematics... However, in a computer, the result may be represented as This will result in the least significant bit of the mantissa. This changes. This minimum representation interval is called the Unit in the Last Place (ULP). For a regular 64-bit double-precision floating-point number v, its ULP value can be calculated using the following formula: The rounding error introduced by any floating-point operation will not exceed half of the ULP value of the result. This characteristic forms the theoretical basis for the subsequent accurate conversion judgment in this invention.

[0105] 1.2 Definition of Core Parameters

[0106] Definition 1: Decimal Format (DF). Given a floating-point number v, its decimal format DF(v) refers to its regular decimal representation, in the form of: .in, And the first Non-zero (unless the integer part has only one bit), last bit Non-zero (unless the decimal part is 0).

[0107] Definition 2: Decimal Place (DP) and Decimal Significant Place (DS). Based on the decimal format of the floating-point number v, the following two core parameters are defined: Decimal Place DP(v): defined as the number of digits after the decimal point in the decimal representation of v. Formally, .For example, Significant digits DS(v): Defined as the total number of digits in the decimal representation of v, from the first non-zero digit to the last non-zero digit. For example, (The number of significant figures is 314) For a non-zero floating-point number v, its dynamic programming (DP) and data storage (DS) satisfy the following relationship:

[0108] ;

[0109] In the following description of the invention, Greek letters will be used. and These refer to the number of decimal places (DP) and the number of significant digits (DS), respectively.

[0110] 1.3 Background of GPU Execution Model

[0111] The design of this invention fully utilizes the architectural features of modern GPUs. Understanding their execution model is key to understanding the design choices of this invention.

[0112] Execution Hierarchy: A GPU program (called a kernel) is launched by the CPU and executed on the GPU in the form of a grid. Each grid contains multiple thread blocks, and each block contains multiple threads. Threads are scheduled in groups of 32 (called warps) and executed in a Single Instruction, Multiple Threads (SIMT) manner. This architecture provides massive parallelism for data-parallel tasks such as compression.

[0113] Memory Hierarchy: GPUs have a hierarchical memory structure. Global memory has a large capacity but high latency; shared memory has a small capacity but extremely low latency and is shared between threads within the same thread block, making it ideal for thread collaboration. Efficient GPU algorithms must carefully manage data movement across hierarchies to minimize latency.

[0114] Host-Device Interaction: The CPU (host) and GPU (device) communicate via the PCIe bus. This communication is often a significant performance bottleneck for the entire system, and it is also the core problem that the asynchronous pipeline module of this invention aims to solve.

[0115] 1.4 Glossary of technical terms mentioned later

[0116] (1) Asynchronous Pipeline. This refers to an execution mode used to organize tasks in a heterogeneous computing system (CPU+GPU of this invention). In this mode, multiple processing stages, such as data transfer (I / O) and computation, are designed to be executed concurrently and overlappingly, rather than strictly serially waiting. The purpose is to hide the time consumption of high-latency operations such as I / O, thereby improving the end-to-end throughput of the entire system.

[0117] (2) Bit plane. A two-dimensional bit matrix obtained by decomposing a set of binary numbers (such as multiple 64-bit integers) in the vertical direction. Each row of the matrix represents an integer, and each column represents the set of values ​​of all integers at the same bit position (such as the k-th bit).

[0118] (3) Thread bundle splitting. A phenomenon unique to GPUs. GPUs execute SIMT (Single Instruction, Multithreaded) in groups of 32 threads (called a Warp). When a thread within a Warp encounters a conditional branch (such as if-else) and chooses a different execution path, the hardware executes each branch path serially, causing some threads to be idle and waiting. This severely reduces the parallel computing efficiency of the GPU.

[0119] (4) Zigzag encoding. A method for reversibly mapping signed integers to unsigned integers. For an n-bit signed integer x, its Zigzag encoding Zigzag(x) is usually calculated using bitwise operations, i.e.: .

[0120] 2. Asynchronous event-driven pipeline

[0121] In GPU-based compression frameworks, a major performance bottleneck stems from I / O latency between the CPU (host) and GPU (device). Data is transferred between them via the PCIe bus, including H2D processes from host to device and D2H processes from device to host. To hide this latency, this invention implements an asynchronous pipeline that executes at the data batch level.

[0122] However, since the size of each batch after compression is often unpredictable before execution, when multiple batches are processed concurrently, their outputs may be written to memory at the same time, which may lead to memory access conflicts.

[0123] To solve this problem, the most direct approach is to use a pre-allocation scheduler, such as... Figure 4 As shown in (a), this scheme pre-allocates a fixed-size memory space for each data batch. Its drawbacks are: if the allocated space is too large, it results in wasted memory; if it is too small, there is a risk of memory overflow. Furthermore, this scheme requires an additional merging step, reducing throughput.

[0124] Another solution is a sync-based scheduler, such as... Figure 4 As shown in (b), this scheme decomposes the data backhaul (D2H) process into two stages: metadata backhaul (M-D2H) and payload data backhaul (P-D2H), allowing for some overlapping operations. Its disadvantage is that the processing of the next batch must wait for the M-D2H steps of the previous batch to complete before it can begin, which limits the pipeline's parallel depth and overall throughput.

[0125] To completely solve the above-mentioned defects, this invention proposes a lightweight asynchronous pipeline mechanism that cleverly utilizes the GPU's event mechanism and the asynchronous execution capability of streams to construct a nearly non-blocking deep pipeline interaction method between the CPU and the GPU.

[0126] Specifically, the asynchronous pipeline mechanism is used to perform batch data transfer and compressed data stream return between the CPU and GPU as follows:

[0127] The CPU performs asynchronous concurrent transmission of multiple data batches at the data batch level. The transmission and compressed data stream return process for each data batch is divided into three states: Idle, MPend (metadata waiting state), and PPend (data waiting state). Figure 5 As shown in (a); where:

[0128] The Idle state represents the initial state of the data batch before processing begins;

[0129] The Meta Pending state indicates that the CPU is waiting for the compressed data block size of the data batch after transferring it to the GPU.

[0130] The Payload Pending (PPend) state indicates that the CPU is waiting for the compressed data stream to be transmitted back.

[0131] During the processing of each data batch transfer and compressed data stream return between the CPU and GPU, the CPU allocates a pipeline for each data batch and configures several pipelines to execute the transfer of multiple data batches in parallel and asynchronously. For each pipeline, before the CPU is ready to execute the transfer of a data batch, the pipeline first enters the idle state. When the CPU is ready to start executing the transfer of the data batch, the pipeline enters the metadata waiting state MPend and remains in this state until the GPU performs compression processing and returns the compressed data block size. When the GPU completes the compression processing of the data batch, it writes the resulting compressed data blocks to global memory and sends the compressed data block size information to the CPU. When it is ready to execute the compressed data stream return, the pipeline is triggered to enter the data waiting state PPend. Then the GPU returns the formed compressed data stream to the CPU. After the return is completed, the data waiting state PPend ends, and the pipeline re-enters the idle state, waiting for the CPU to allocate the next data batch.

[0132] Therefore, the transmission of data batches by each pipeline is executed sequentially according to the above three state stages. Different state stages of data batch transmission by different pipelines can be executed asynchronously and concurrently until the compression processing of all data batches is completed.

[0133] In practical applications, an event-driven scheduler can be compiled into a program. Figure 4 (c) is used to schedule the execution of this asynchronous pipeline interaction process. Algorithm 1 shows the pseudocode of this event-driven scheduler.

[0134]

[0135] The inputs to the event-driven scheduler are the raw value stream in, the number of pipeline streams Ns, and the number of values ​​in each batch batchSize.

[0136] During the initialization phase, the algorithm declares several key variables: stream[N] s ] and state[N s ] respectively represent N s Each stream and its corresponding state (initialized to Idle); gIn[N s ] and gOut[N s ] are the input and output buffers allocated for each stream in the GPU's global memory; eventQ[N s ] is the event queue associated with each stream; cs[N s This is used to store the compression size of each batch. `current` indicates the index of the stream currently waiting for compression; `active` records the number of active streams; `cache` is the starting address of the compression result; `offset` tracks the offset of the current stream result; and `batch` holds the next batch of raw data to be processed.

[0137] In the Verification Loop, as long as there is still unprocessed data (batch ≠ null) or active streams (active > 0), the algorithm will continuously iterate to check the state of each stream and execute the corresponding asynchronous operations. All functions marked as Async are executed asynchronously; the CPU will not wait for them to complete after they are called before continuing to execute the next line of code. The stream[i] parameter at the end of these functions specifies the stream to which the operation belongs; all asynchronous operations within the same stream will be executed sequentially.

[0138] Figure 5 (b) and Figure 5(c) illustrates a pipeline example containing three streams. At time t1, although Stream1 has completed its M-D2H stage, it must wait for Stream0 to complete its M-D2H because the CPU cannot yet determine the offset of its result. At time t2, both Stream0 and Stream1 have completed their M-D2H, so current is updated to 2 and offset is set to cs[0] + cs[1]. At this point, the P-D2H stage of Stream1 may execute before Stream0. This mechanism ensures the order of the final writes while maximizing parallel processing, effectively solving the I / O bottleneck.

[0139] 3. Precise and fast floating-point to integer conversion

[0140] According to the IEEE 754 standard, floating-point values ​​have a fairly complex underlying binary layout, and even small fluctuations in their value can lead to drastic changes at the bit level. Directly compressing the binary representation of floating-point numbers is generally inefficient. Therefore, to improve compression ratios, existing CPU compression methods typically employ complex logical operations, but this is not conducive to large-scale parallelization in GPUs. This is because GPUs operate in a Single Instruction, Multiple Threads (SIMT) manner, and too many logical branches can cause threads within the same warp to execute serially, severely reducing throughput.

[0141] To address this, this invention proposes a GPU-friendly floating-point compression method. Its core idea is to, given a floating-point number v and its number of decimal places... = DP(v), first convert it into an integer that is easier to compress. Then, a GPU-friendly encoding strategy is applied to the integer. However, two key issues exist in implementing this conversion: Issue I: Can the converted integer be losslessly restored to the original floating-point number? Issue II: How to accurately and efficiently calculate the number of decimal places of the floating-point number? ?

[0142] 3.1 Correctness of the conversion

[0143] For ease of explanation, let's first assume... It is known, and the following definition is introduced:

[0144] Definition 3 (Decimal Scaled Value): Given a floating-point number v, = DP(v), in a purely mathematical sense, is called DP(v). Let i be the decimal scaling value of v, where i ≥ 0.

[0145] Theorem 1 (Invariance of Decimal Significant Numbers): Given v and its... = DP(v), for any i ∈ {0, 1,..., },have .

[0146] Brief proof: From a mathematical perspective, Simply shifting the decimal point of v to the right by i positions does not change its sequence of significant digits, so the DS value remains unchanged.

[0147] Although mathematically valid, in computers, due to the limited number of bits in a floating-point number representation, multiplication operations... This may introduce errors. To obtain a mathematically correct transformation result... It is necessary to Perform a decimal rounding operation on top of the initial decimal rounding. Prove that this operation is correct under specific conditions.

[0148] Theorem 2 (Conversion Correctness): Given v, its = DP(v), DS(v), if ,but: .

[0149] Brief proof: When At that time, the mathematical target value It can be accurately represented by no more than 50 binary bits. The resulting binary rounding error only affects the least significant bit. This can be explained by analyzing three possible error scenarios (such as...). Figure 6 As shown in the figure, it can be proven that the subsequent decimal rounding operation round() can always accurately correct this tiny binary error.

[0150] Theorem 3 (Conversion Recoverability): Given v, its = DP(v)≤22, DS(v)≤15. Therefore:

[0151] ;

[0152] That is, floating-point division does not introduce any error.

[0153] Brief proof: According to Theorem 2, the dividend It can be represented precisely. Secondly, regarding the divisor... ,like ≤22, it can also be precisely represented by the double type. Since both sides of the operation can be precisely represented, the result of the division is also precise.

[0154] Combining Theorems 2 and 3, for those satisfying ≤15 and A floating-point number v with a value ≤ 22 can be converted to an integer without loss and recovered precisely.

[0155] 3.2 Calculation of Decimal Places

[0156] This invention proposes a novel calculation method based on the following theorem.

[0157] Theorem 4 (Transformation Error Boundary): Given v, , Define the error term. and error boundary as follows:

[0158] ;

[0159] ;

[0160] For any ,have ; and when Sometimes, .

[0161] Proof in brief: This represents the maximum error that floating-point calculations themselves can introduce. When hour, If it is a non-integer, its distance to the nearest integer is... Significantly greater than floating-point calculation error And when hour, It is an integer. The value is reduced to the floating-point calculation error itself.

[0162]

[0163] Based on Theorem 4, Algorithm 2 (DPAndDSCalculation) finds the answer through a simple loop. .from Begin iterating, checking the conditions at each step. Is the condition satisfied? Once satisfied, the loop terminates. This is the desired result. The algorithm combines high efficiency and high accuracy.

[0164] 3.3 Numerical Conversion

[0165] For a whole floating-point data block A unified conversion process was designed. This process first requires determining a unified conversion benchmark for the entire floating-point data block.

[0166] Intuitively, the original number of decimal places for all values ​​within the block can be calculated. and the original decimal significant digits Since the number of decimal places in values ​​tends to be similar in a floating-point dataset, this invention uses the largest number of decimal places within a block. As a unified transformation scale for all values, and only records This metadata is used to save space. However, when using a unified... When scaling all values ​​within a block, those original values... The number of significant digits in the value will change. Therefore, it must be based on Recalculate a new set of significant decimal digits. For each value in the block Its new number of significant digits The calculation method is as follows:

[0167] ;

[0168] After obtaining a new set of significant digits Then, calculate its maximum value. .

[0169] Now, we have two key parameters calculated for the entire floating-point data block: and Based on these two values, two cases are handled (e.g.) Figure 7 (as shown)

[0170] Case 1: and (Under normal circumstances)

[0171] Integer conversion: Convert each value within the block Convert to integer The lossless reversibility of this transformation is guaranteed by the following theorem:

[0172] Theorem 5 (Recoverability of Unified Transformation): If and Then for any value within the block have .

[0173] Brief proof: For any ,because ,therefore It must be an integer. Its decimal significant digits DS( ) = This means that for scaled values... The premise of Theorem 2 is satisfied. Therefore, the round operation can correctly convert it to an integer. And because According to the principle of Theorem 3, the divisor It can be represented precisely, therefore the division operation is lossless, thus ensuring... It can be precisely recovered.

[0174] Difference and Encoding: Dividing integer sequences Convert to ,in:

[0175] ;

[0176] Difference operations are used because adjacent values ​​in time series data are usually close, and their differences are small. Zigzag encoding maps potentially negative differences to small positive integers, which is beneficial for subsequent encoding.

[0177] Case 2: or (Abnormal situation)

[0178] Since this exceeds the scope guaranteed by the theorem, an alternative but equally efficient transformation method is adopted:

[0179] Integer conversion: directly convert The 64-bit binary representation is interpreted as a long integer using the BinLong() operation, and then encoded using Zigzag() to ensure it is positive, resulting in... .

[0180] Differential and Coding: Same as Case 1, The sequence is obtained by differential and Zigzag encoding. .exist The addition of one Zigzag encoding in the calculation is to handle Case 2. and Special cases where the signs may be opposite are avoided to prevent the difference from producing a number with a huge absolute value, which is crucial for subsequent encoding.

[0181] Due to the values ​​in a dataset and Typically, they are similar, and all GPU threads tend to execute the same branch, which makes the effect of thread bundle differentiation negligible, thus ensuring the efficient execution of the GPU.

[0182] Therefore, in the IoT floating-point time-series data compression and transmission method of the present invention, the specific process of the GPU thread executing step S1 is as follows:

[0183] S101: For each floating-point data block, calculate the set of the original decimal places for all floating-point values ​​within the floating-point data block. and the initial set of significant decimal digits ;in, , The first and second floating-point data blocks are respectively the first and second floating-point data blocks. floating-point values The corresponding number of decimal places and significant digits; n is the number of 64-bit floating-point numbers contained in a floating-point data block, and n = K×64+1, where K is the preset floating-point data block size coefficient, and K is an integer. The limitation of n = K×64+1 is to ensure that the bytes can be aligned after the bit plane transpose, which will be explained later.

[0184] S102: Determine the maximum number of decimal places within the floating-point data block. And based on the maximum number of decimal places Recalculate the set of decimal significant digits within the floating-point data block. And determine the maximum number of significant decimal digits. :

[0185] .

[0186] S103: Regarding the maximum number of decimal places and the maximum number of significant decimal digits The value is used to determine the result; if and If so, proceed to step S104; or Then proceed to step S105.

[0187] S104: Transfer the floating-point values ​​within the floating-point data block. Convert to integer as follows: :

[0188] , ;

[0189] The `round()` function rounds floating-point values ​​to integers, thus generating a sequence of integers. Then proceed to step S106.

[0190] S105: Transfer the floating-point values ​​within the floating-point data block. Convert to integer as follows: :

[0191] , ;

[0192] Here, Binlong() represents the conversion operation that converts a floating-point value to a long integer; Zigzag() represents Zigzag encoding; thus, the integer sequence is obtained. Then proceed to step S106.

[0193] S106: Transfer the integer sequence Convert to an integer encoded sequence using the following encoding method. ,in:

[0194] ;

[0195] Zigzag() represents Zigzag encoding.

[0196] 4. Adaptive Bit Plane Encoding and Parallel Writing

[0197] After the aforementioned integer conversion steps, a sequence of positive integers is obtained. , where n is the number of values ​​in a floating-point data chunk. Due to differential encoding, the values ​​in the sequence... (Apart from These bits are typically small, meaning their 64-bit binary representation contains a large number of leading zeros. This section will explain how to leverage this characteristic for efficient encoding and how to write the encoded results into memory in parallel.

[0198] 4.1 Adaptive Bit Plane Encoding

[0199] This invention employs an adaptive bit-plane encoding strategy that can intelligently address the dynamic changes in sparsity caused by outliers in the data.

[0200] 4.1.1 Construction and Pruning of the Bit Plane

[0201] In step S2 of the IoT floating-point time-series data compression and transmission method of the present invention, a bit plane construction and pruning strategy is proposed.

[0202] First, for each floating-point data block, the corresponding integer encoding sequence Extract the first integer encoded value. (because (It will be stored directly), and then the remaining integer encoded values ​​will be combined as a new integer encoded sequence. The integer encoding sequence Each 64-bit integer encoded value View it as a row vector A bit-plane matrix is ​​constructed. Then, the integer encoding sequence is calculated. Each integer encoding value The minimum number of leading zeros in the corresponding row vector. min This means that all valid data bits for all values ​​are in w = 64 -lead. min Within this width; trim the integer encoded sequence. The common lead of all integer encoded values min A series of leading zeros form an integer encoding sequence. A corresponding new, more compact bit plane matrix ; where, bit plane matrix The bit width w = 64 - lead min .like Figure 8 As shown in (a).

[0203] 4.2.2 Bit-plane coding mechanism

[0204] In step S3 of the IoT floating-point time-series data compression and transmission method of this invention, a bit-plane encoding mechanism is proposed, the specific process of which is as follows:

[0205] S301: For each floating-point data block, for the bit plane matrix Transpose the matrix to obtain the transposed bit plane matrix. ;

[0206] S302: According to the transposed bit plane matrix The number of zero bytes included determines the transposed bit plane matrix. The storage scheme for each byte; the storage scheme includes sparse storage and dense storage;

[0207] S303: According to the preset bit-plane encoding method, the maximum number of decimal places corresponding to the floating-point data block is determined. Maximum number of significant decimal digits Integer encoded value The transposed bit plane matrix is ​​processed according to the determined storage scheme. The data is arranged row by row to obtain compressed data blocks using bit-plane encoding.

[0208] The following is a detailed explanation.

[0209] Bit plane transpose and byte alignment

[0210] Directly processing matrix M row-by-row is not conducive to GPU memory access. Therefore, for the bit plane matrix... Transpose the matrix to obtain the transposed bit plane matrix. ,like Figure 8 As shown in (b). After transposition, the contiguous nature of the original data in memory is preserved, making it more suitable for parallel reading by the GPU. By setting the block size n to n = K×64+1 (for example, n=1025 in the implementation), the transposed matrix can be guaranteed to maintain its integrity. Each line is byte-aligned for easier subsequent processing.

[0211] Adaptive row storage strategy

[0212] The core innovation of this invention lies in not using a single encoding method for the entire matrix, but rather for the transpose matrix. Each row is analyzed independently, and the optimal storage solution is dynamically selected. (One row) Corresponding to all values The i-th bit.

[0213] A byte (8 bits) is defined as a zero byte if all bits are 0; otherwise, it is called a non-zero byte. For each row, calculate each row Number of zero bytes included Then, for the transposed bit plane matrix... any line The storage scheme is determined based on the following conditions:

[0214] Sparse Storage: If the conditions are met That is, if there are enough zero bytes, then the line... Sparse storage is used, with a bitmap of size (n−1) / 64 bytes used to indicate zero or non-zero bytes (e.g., '1' represents a non-zero byte and '0' represents a zero byte), and only all non-zero bytes are stored consecutively.

[0215] Dense Storage: If the conditions are not met Regarding the line Use dense storage, storing all (n−1) / 8 bytes of the row directly as is.

[0216] Therefore, the transposed bit plane matrix is ​​determined. Storage schemes for each row in the middle.

[0217] This adaptive design can efficiently handle outliers. Outliers in the data typically only affect the transpose matrix. The first few rows (high bits) contain a large number of non-zero bytes, making them suitable for dense storage. The majority of the later rows (low bits) are very sparse, containing a large number of zero bytes; sparse storage can greatly compress these rows. This strategy perfectly suits this situation. Furthermore, it is GPU-friendly because zero bytes are mainly concentrated in specific rows. When GPU threads process different rows, their branch selection (using sparse or dense storage) tends to be consistent, effectively mitigating the warp divergence problem.

[0218] Bit-plane encoded data format

[0219] The data format of compressed data blocks using bit-plane encoding is as follows: Figure 8 As shown, it includes:

[0220] One byte stores the maximum number of decimal places. ;

[0221] One byte stores the maximum number of significant decimal digits. ;

[0222] 8 bytes to store integer encoded value ;

[0223] One byte of storage width w;

[0224] The w-bit storage scheme selection flag is used to record the transposed bit plane matrix. The storage scheme used in each row is defined as follows: a bit value of 0 indicates sparse storage, and a bit value of 1 indicates dense storage.

[0225] Finally, the transposed bit plane matrix is ​​processed according to the determined storage scheme. The data in each row is arranged and stored sequentially.

[0226] 5. Compression size synchronization and parallel block writing

[0227] In step S4 of the IoT floating-point time-series data compression and transmission method of the present invention, a compression size synchronization and parallel block writing mechanism is adopted.

[0228] After each GPU thread completes the encoding of its floating-point data chunks, the resulting compressed data is stored in the GPU's low-latency local memory (such as shared memory). At this point, the compression results from all threads need to be merged into a contiguous region of the GPU's global memory.

[0229] Traditional serial merging methods are inefficient. This invention employs a highly efficient parallel writing scheme, mainly comprising two steps:

[0230] Compressed Size Sync: First, the exact size of the compressed blocks generated by each thread needs to be known. Using an efficient parallel synchronization primitive (such as a shuffle instruction or a shared memory-based scan operation), all threads can quickly aggregate their compressed sizes. Based on this aggregation, each thread can calculate its own write offset in the global output buffer. This process utilizes the decoupled look-back strategy mentioned in the literature "

[12] Yafan Huang, Sheng Di, Guanpeng Li, and Franck Cappello. 2024. CUSZP2: A GPU LossyCompressor with Extreme Throughput and Optimized Compression Ratio. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC '24). IEEE / ACM, Atlanta, GA, USA" and "Duane Merrill and Michael Garland. 2016. Single-pass Parallel PrefixScan with Decoupled Look-back. Technical Report NVR-2016-002. NVIDIA Corporation" to accelerate computation.

[0231] Parallel Chunk Writing: After obtaining their respective write offsets, all GPU threads can simultaneously and in parallel copy their compressed data blocks from local memory directly to the final location in global memory.

[0232] This "synchronize size first, then write in parallel" mechanism avoids any form of serialization bottleneck, ensuring that the entire process from encoding to final output is highly parallel, thus guaranteeing extremely high compression throughput. At this point, the compression of a data batch is complete (corresponding to the end of CmpKernel).

[0233] 6. Summary of Compression Algorithms

[0234] To more precisely describe the core compression logic of this invention, Algorithm 3 demonstrates the main steps of the CmpKernel function executed on the GPU. This algorithm is executed in parallel by thousands of threads on the GPU, each thread responsible for processing an independent floating-point data chunk.

[0235]

[0236] 7. Decompression and Reading of IoT Floating-Point Time Series Data

[0237] At the IoT receiver, the process of decompressing and reading the data that has been compressed and transmitted using the aforementioned method is designed to be the exact reverse of the compression process. It is also optimized to achieve a high degree of parallelization, thereby ensuring extremely high decompression throughput.

[0238] Since the original size of each floating-point data chunk is fixed (e.g., 1025 double values, totaling 1025 * 8 bytes) and known before decompression begins, the decompression scheduler does not need to handle the problem of uncertain compression ratio. This allows for the use of a simpler and more efficient pre-allocation scheduler (Fig. 5a), which pre-allocates a contiguous target storage space in the GPU's global memory for all decompressed floating-point data chunks.

[0239] At the receiving end of IoT floating-point time-series data, the CPU schedules and allocates different GPU threads to read the compressed data blocks and decompress them. Each thread decompresses one compressed data block, and then each GPU thread writes the decompressed floating-point data block in parallel to the specified location of the pre-allocated GPU global memory output buffer. When all threads have finished writing, the entire decompression process ends.

[0240] At the start of decompression, the CPU first reads global metadata from the header of the compressed data stream, including an array of compressed block sizes. Based on this array, the CPU can quickly calculate the starting offset of each compressed data block in the input stream. This offset information is then copied to the GPU's global memory for all decompression threads to access. Each GPU thread retrieves the starting address of its assigned compressed block from the global offset array based on the block index assigned to it, and then reads the entire compressed block from the compressed data stream in parallel into its local or shared memory.

[0241] The process of decompressing a compressed data block by each GPU thread includes the following steps:

[0242] SI: Based on the preset bit-plane encoding method, reverse decode to recover the maximum number of decimal places corresponding to the floating-point data block. Maximum number of significant decimal digits Integer encoded value Bit width w and bit plane matrix .

[0243] This is the inverse operation of the bit-plane encoding process, and its specific steps are as follows:

[0244] Read the first and second bytes from the compressed data block to obtain the maximum number of decimal places. and the maximum number of significant decimal digits Then, read the next 8 bytes and the 9th byte from the compressed data block to obtain the integer encoded values. And the bit width w; then continue reading the next w bits in the compressed data block to obtain the storage scheme selection flag;

[0245] Finally, according to the scheme, the flag is selected to decode the subsequent data line by line as follows: if the flag bit value is 0, it indicates sparse storage. The GPU thread first reads the bitmap, then reads consecutive non-zero bytes from the bitmap and fills them into the correct positions to reconstruct the line. If the flag bit is 1, it indicates dense storage, and the GPU thread directly reads the corresponding number of bytes and reconstructs the data. After decoding and reconstructing all w rows, the GPU thread reconstructs the transposed bit plane matrix. Then, by reversing the bit plane matrix, the bit plane matrix can be recovered. .

[0246] SII: Based on the obtained bit width w and bit plane matrix The integer encoding sequence corresponding to the floating-point data block is recovered by leading zero padding. .

[0247] The bit plane matrix is ​​recovered. Then, the minimum number of leading zeros (lead) is determined by calculating the bit width w. min The value of lead min =64-w, thus leading is filled by the leader. min Then encode the first integer value with zeros. By inserting the filler, the integer encoded sequence Z is finally recovered.

[0248] SIII: According to the integer encoding sequence Reverse encoding to recover the integer sequence And according to the maximum number of decimal places and the maximum number of significant decimal digits Perform the corresponding reverse conversion to recover the floating-point data block.

[0249] This is the inverse operation of integer encoding. The GPU thread first decodes the integer encoded sequence Z using inverse differential and inverse Zigzag. This process reconstructs the integer sequence G. Then, based on the metadata... and Determine whether it belongs to Case 1 or Case 2, and perform the corresponding reverse conversion (i.e., (or the reverse BinLong / Zigzag operation), ultimately accurately recovering the original floating-point data block V.

[0250] All threads write the decompressed raw floating-point data V in parallel to a specified location in the pre-allocated GPU global memory output buffer. The entire decompression process ends when all threads have finished writing.

[0251] Experimental Examples

[0252] To verify the performance of the proposed Falcon framework, a series of detailed experiments were conducted. The experiments comprehensively compared the invention with various mainstream and state-of-the-art compression algorithms across three core dimensions: compression ratio, compression throughput, and decompression throughput.

[0253] Data set: See Table 1.

[0254] Table 1. Dataset

[0255]

[0256] Experimental setup:

[0257] All experiments were conducted on the same workstation equipped with an NVIDIA GeForce RTX 4090 GPU, an Intel® Core™ i9-13900K CPU, and 64 GB of DDR5 memory. The software environment consisted of Ubuntu 22.04 LTS and CUDA Toolkit 12.2.

[0258] Experimental methods:

[0259] Falcon was compared to 10 representative competitors, including:

[0260] CPU-specific floating-point compression algorithms: Elf, ALP, Elf* (an improved version of Elf), representing the most advanced CPU lossless compression technology currently available. GPU-specific floating-point compression algorithm: ndzip, a GPU compressor designed specifically for scientific data. GPU general-purpose compression algorithms: Lz4, Snappy, GDeflate, Bitcomp, all from NVIDIA's official nvCOMP library, representing the highest level of general-purpose GPU compression. GPU porting comparison of this invention: To fairly evaluate the innovation of the core algorithms under identical hardware conditions, the two most advanced CPU algorithms, Elf* and ALP, were also ported to the GPU for execution (GPU:Elf*, GPU:ALP).

[0261] Comparison Standard:

[0262] 1) Compression Ratio: Defined as the size of the compressed data divided by the size of the original data. A lower value indicates better compression. 2) Compression / Decompression Throughput (GB / s): Defined as the size of the original data divided by the total processing time. A higher value indicates faster processing speed.

[0263] Compression ratio:

[0264] The experimental results are shown in Table 2. Falcon achieved the best or second-best compression ratio on the vast majority of datasets. On average, Falcon's compression ratio (0.299) represents a relative improvement of 11.8% and 9.1% compared to the state-of-the-art CPU algorithms Elf* (0.339) and ALP (0.329), respectively. This demonstrates the superiority of the adaptive encoding strategy of this invention in terms of compression performance. Falcon's compression ratio is far superior to all general-purpose GPU compression algorithms and the dedicated ndzip (average compression ratio 0.996), showcasing the significant advantages of an encoding scheme specifically designed for floating-point data.

[0265] Table 2. Compression Ratio

[0266]

[0267] Compression throughput:

[0268] As shown in Table 3, Falcon achieved an average compression throughput of 10.82 GB / s. Compared to its fastest GPU competitor (GDeflate, approximately 4.46 GB / s), this represents a performance improvement of about 2.4 times. Compared to our own ported GPU:ALP (3.76 GB / s) and GPU:Elf* (0.81 GB / s), the performance advantage is even more significant, proving that the algorithm design of this invention is natively GPU-friendly. Compared to CPU algorithms, it offers performance improvements of tens or even hundreds of times, fully demonstrating the value of GPU acceleration.

[0269] Decompression throughput:

[0270] As shown in Table 4, Falcon achieved an average decompression throughput of 12.32 GB / s. Similar to compression, its decompression performance also far surpasses all compared CPU and GPU algorithms, achieving approximately 2.4 times the performance of its fastest GPU competitor, GPU:Elf* (5.13 GB / s).

[0271] Table 3. Compressed throughput (GB / s)

[0272]

[0273] Table 4. Decompression throughput (GB / s)

[0274]

[0275] The experimental data above fully demonstrates that the GPU-based IoT floating-point time-series data compression transmission and decompression reading method proposed in this invention successfully achieves excellent compression ratio while significantly improving the throughput of compression transmission and decompression reading. Its overall performance far exceeds that of existing CPU and GPU floating-point time-series data compression transmission schemes.

[0276] In summary, addressing the bottlenecks in heterogeneous data movement, difficulties in guaranteeing floating-point conversion accuracy, and fixed encoding strategies in existing technologies, this invention proposes a GPU-based method for compressing, transmitting, decompressing, and reading floating-point time-series data for the Internet of Things (IoT). In this invention, a lightweight asynchronous event-driven asynchronous pipeline scheduling mechanism is employed during batch data transmission between the CPU and GPU and the return of compressed data streams. This compensates for the high transmission latency caused by data transmission in existing GPU compression schemes, significantly improving the overall processing throughput of data communication in IoT systems. Furthermore, this invention proposes a theoretically guaranteed accurate and fast floating-point to integer conversion method, solving the accuracy loss problem in traditional fast conversion methods. The algorithm is also simple in logic and perfectly adapted to the large-scale parallel architecture of GPUs. In addition, this invention designs a bit-plane adaptive encoding scheme that dynamically selects the optimal storage strategy for different parts of the data, effectively overcoming the negative impact of outliers on the compression ratio. This invention achieves significantly faster compression and decompression speeds than existing CPU and GPU solutions while ensuring absolute data loss, with excellent compression performance, significantly improving the compression ratio and throughput of data communication in IoT systems.

[0277] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit the technical solutions. Those skilled in the art should understand that any modifications or equivalent substitutions to the technical solutions of the present invention without departing from the spirit and scope of the present invention should be covered within the scope of the claims of the present invention.

Claims

1. A GPU-based IoT floating-point time-series data compression transmission method, characterized in that, At the collection end of the Internet of Things floating-point time series data, the CPU reads the original floating-point time series data to be compressed in batches, and transmits the read data batches to the GPU; the GPU divides each data batch into multiple floating-point data blocks, assigns them to different GPU threads for parallel compression processing, each GPU thread compresses a floating-point data block, and then each GPU thread writes the compressed data block obtained after compression to the global memory in parallel to form a continuous compressed data stream back to the CPU; the data batch transmission and compressed data stream transmission between the CPU and the GPU are executed in an asynchronous pipeline mechanism, and finally the CPU at the collection end transmits the obtained compressed data stream.

2. The GPU-based IoT floating-point time-series data compression and transmission method according to claim 1, wherein, The specific way of executing the data batch transmission and compressed data stream transmission between the CPU and the GPU in an asynchronous pipeline mechanism is as follows: The CPU executes the asynchronous concurrent transmission of multiple data batches in data batch granularity; the execution process of each data batch transmission and compressed data stream transmission is divided into three state stages: idle state Idle, metadata waiting state MPend, and data waiting state PPend; wherein, the idle state Idle represents the initial state of the data batch before processing; the metadata waiting state MPend represents the state of the CPU waiting for the compressed data block size of the data batch after transmitting the data batch to the GPU; the data waiting state PPend represents the state of the CPU waiting for the compressed data stream transmission; During the processing of each data batch transmission and compressed data stream transmission between the CPU and the GPU, the CPU allocates a pipeline for each data batch, and configures several pipelines to execute the transmission of multiple data batches in parallel; for each pipeline, before the CPU is ready to execute the transmission of a data batch for the pipeline, the pipeline first enters the idle state Idle; when the CPU is ready to start executing the transmission of the data batch, the pipeline enters the metadata waiting state MPend, and continues in this state until the GPU completes the compression processing and the compressed data block size is transmitted to the CPU; when the GPU completes the compression processing of the data batch, writes the obtained compressed data blocks to the global memory, and sends the size information of each compressed data block to the CPU, it is ready to execute the compressed data stream transmission, triggers the pipeline to enter the data waiting state PPend, and then the GPU transmits the formed compressed data stream back to the CPU until the transmission is completed, the data waiting state PPend ends, and the pipeline reenters the idle state Idle, waiting for the CPU to allocate the next data batch; Therefore, the transmission of each pipeline for each data batch is executed in the order of the above three state stages, and the different state stages of different pipelines for data batch transmission can be executed asynchronously and concurrently, until the compression processing of all data batches is completed.

3. The GPU-based IoT floating-point time-series data compression and transmission method of claim 1, wherein, On the GPU, the process of allocating and mobilizing multiple GPU threads to execute compression processing in parallel includes the following steps: S1: for each floating-point data block, calculate the maximum number of significant digits within the floating-point data block and the corresponding maximum decimal significant digit number , according to which each floating-point number contained in the floating-point data block is converted into an integer, and the sequence of converted integers is encoded to obtain the corresponding integer encoding sequence ; S2: for each floating-point data block corresponding integer encoding sequence , take out the first integer encoding value , the remaining integer encoding values are combined as a new integer encoding sequence , bit plane conversion processing is performed to obtain the bit plane matrix corresponding to the integer encoding sequence , determine the bit width w of the bit plane matrix , the bit plane matrix ​ S3: for each floating-point data block, performing bit-plane coding on the floating-point data block according to a preset bit-plane coding mode to obtain a compressed data block corresponding to the floating-point data block, wherein the bit-plane coding mode comprises the following steps: , a maximum value of decimal significant digits , an integer coding value , a bit width w and a bit-plane matrix performing bit-plane coding to obtain a compressed data block corresponding to the floating-point data block; S4: aggregating the compressed data blocks generated by all GPU threads through parallel synchronization primitives, each thread calculating its write offset in the global output buffer based on the size of the compressed data block it gets and the global aggregation result; then each GPU thread writes its compressed data block into the global memory according to its write offset in the global output buffer, forming a continuous compressed data stream back to the CPU.

4. The GPU-based IoT floating-point time-series data compression and transmission method of claim 3, wherein, Step S1 is specifically: S101: For each floating-point data block, calculate the set of the original decimal places for all floating-point values ​​within the floating-point data block. and the initial set of significant decimal digits ;in, , The first and second floating-point data blocks are respectively the first and second floating-point data blocks. floating-point values The corresponding number of decimal places and significant digits; n is the number of 64-bit floating-point numbers contained in a floating-point data block, and n = K×64+1, where K is the preset floating-point data block size coefficient, and K is an integer; S102: determine the maximum number of significant digits within the floating-point data block , and based on the maximum number of significant digits recompute the set of decimal significant digits within the floating-point data block , and determine the maximum value of decimal significant digits : ； S103: Regarding the maximum number of decimal places and the maximum number of significant decimal digits The value is used to determine the result; if and If so, proceed to step S104; or Then proceed to step S105; S104: convert each floating-point value within the floating-point data block to an integer value to an integer as follows : ， ； wherein round() represents an operation of rounding a floating point value to an integer; thereby obtaining an integer sequence Then, step S106 is executed. S105: convert each floating-point value within the floating-point data block to an integer value to an integer as follows : ， ； wherein Binlong() represents a conversion operation that converts a floating point value into a long integer number; Zigzag() represents Zigzag encoding; and wherein the integer sequence is obtained by arranging Then, step S106 is executed. S106: convert the integer sequence into a sequence of binary numbers converted into an integer encoding sequence by the following encoding scheme wherein: ； Wherein, Zigzag() represents Zigzag encoding.

5. The GPU-based IoT floating-point time-series data compression and transmission method of claim 4, wherein, Step S2 is specifically: for each block of floating point data , take the first integer encoding value , and combine the remaining integer encoding values as a new integer encoding sequence ; Then, the integer encoding sequence Each 64-bit integer encoded value View it as a row vector Calculate the encoded values ​​of each integer. The minimum number of leading zeros in the corresponding row vector. min Pruning the integer encoding sequence The common lead of all integer encoded values min A series of leading zeros form an integer encoding sequence. Corresponding bit plane matrix Among them, the bit plane matrix The bit width w = 64 - lead min .

6. The GPU-based IoT floating-point time-series data compression and transmission method of claim 5, wherein, Step S3 is specifically: S301: For each block of floating-point data, transpose the bit plane matrix to obtain a transposed bit plane matrix ; S302: according to the transpose bit plane matrix the number of zero bytes contained, determining the storage scheme of each byte in the transpose bit plane matrix the number of zero bytes contained, determining the storage scheme of each byte in the transpose bit plane matrix S303: According to the preset bit-plane encoding method, the maximum number of decimal places corresponding to the floating-point data block is determined. Maximum number of significant decimal digits Integer encoded value The transposed bit plane matrix is ​​processed according to the determined storage scheme. The data is arranged row by row to obtain compressed data blocks using bit-plane encoding.

7. The GPU-based IoT floating-point time-series data compression and transmission method of claim 6, wherein, Step S302 is specifically: The transposed bit plane matrix is analyzed independently for each row The number of zero bytes contained in each row ;​ Then, for any row of the transposed bit plane matrix a storage scheme is determined according to the following conditions:​ If the condition is met For this row Sparse storage is used, using a bitmap of size (n−1) / 64 bytes to indicate zero or non-zero bytes, and only storing all non-zero bytes continuously; if the condition is not met For this row Dense storage is used, directly storing all (n−1) / 8 bytes of this row as they are; The transposed bit plane matrix is thus determined the storage scheme of the rows in each of the matrices.

8. The GPU-based IoT floating-point time-series data compression and transmission method of claim 7, wherein, In step S303, the data format of the compressed data block using bit plane encoding includes: 1 byte stores the maximum number of digits ; 1 byte stores the maximum number of significant digits in decimal ; 8 bytes store integer encoded value ; 1 byte stores bit width w; w-bit storage scheme selection flag flag, used for recording the storage scheme adopted by each row of the transposed bit plane matrix bit value of 0 indicates sparse storage, and a bit value of 1 indicates dense storage. Finally, the data in each row of the transposed bit plane matrix is stored in sequence row by row according to the determined storage scheme.

9. A GPU-based IoT floating-point time-series data decompression reading method, characterized by, At the receiving end of the Internet of Things floating-point time series data, for the compressed data stream received by using the method for compression transmission of claim 1, different GPU threads are scheduled and allocated by the CPU to read and decompress the compressed data blocks therein, each thread decompresses a compressed data block, and then each GPU thread writes the decompressed floating-point data block into the designated position of the pre-allocated GPU global memory output buffer in parallel, and when all threads complete the writing, the entire decompression process ends. The process of decompressing a compressed data block by each GPU thread includes the following steps: SI: according to the preset bit plane coding mode, inverse decoding is performed to recover the maximum number of significant bits corresponding to the floating point data block , maximum value of decimal significant bits , integer coding value , bit width w and bit plane matrix ; SII: the bit width w and the bit plane matrix are obtained , the integer encoding sequence corresponding to the floating point data block is recovered by the leading zero padding processing ; SIII: according to the integer encoding sequence performing reverse encoding to recover the integer sequence and according to the maximum number of significant digits and the maximum value of the decimal significant digits performing corresponding reverse conversion processing to recover the floating point data block.

10. The GPU-based IoT floating-point time-series data decompression reading method of claim 9, wherein, The compressed data block uses the data format of bit plane encoding as claimed in claim 8; In step SI, the inverse decoding recovers the maximum number of significant bits corresponding to the floating-point data block , the maximum value of decimal significant bits , the integer encoding value , the bit width w and the bit plane matrix The specific way is: Read the 1st and 2nd bytes in the compressed data block to obtain the maximum number of digits and the maximum number of decimal significant digits ; then, read the next 8 bytes and the 9th byte in the compressed data block to obtain the integer encoding value and the bit width w; continue to read the next w bits in the compressed data block to obtain the storage scheme selection flag flag; Finally, according to the scheme selection flag flag, the subsequent data is decoded row by row as follows: if the flag bit value is 0, indicating sparse storage, the GPU thread first reads the bitmap, reads only the continuous non-zero bytes according to the bitmap, and fills them into the correct position to reconstruct the row ; If the flag bit value is 1, indicating dense storage, the GPU thread directly reads the corresponding number of bytes, reconstructs the row ; after decoding and reconstructing all w rows, the GPU thread reconstructs the transposed bit plane matrix , and then restores the bit plane matrix through inverse transposition .

Images