Quantitative transaction processing method based on GPU parallel computing and related equipment

Abstract

The application discloses a kind of quantification transaction processing method and related equipment based on GPU parallel computing, method includes: in central processing unit end, received high-frequency market data stream is split into multiple stock data queues according to stock code, and stock data in each stock data queue is sorted according to time stamp, obtain multiple target stock data queues;Target stock data queue is transmitted to the storage space of GPU processor by direct memory access mechanism, and parallel computing thread or thread block is configured for each target stock data queue in GPU processor end, so that it establishes fixed mapping relationship with corresponding stock code;Index calculation is carried out on target stock data queue based on fixed mapping relationship in GPU processor end, and generates transaction signal;Transaction signal is returned to central processing unit end and generates transaction instruction.Can realize multiple stock parallel computing, significantly improve market processing throughput and reduce delay, improve the real-time performance of transaction signal output and system response speed.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and in particular to a quantitative trading processing method, apparatus, computer equipment, and storage medium based on GPU parallel computing. Background Technology

[0002] With the development of electronic trading in the securities market, quantitative trading strategies are increasingly demanding real-time processing of market data. This is especially true in high-frequency trading scenarios, where trading systems need to rapidly parse, sort, and calculate high-frequency market data streams, including order book data, trade data, and order book snapshots, and generate trading signals and orders within a very short time. Due to the large number of stocks and frequent data updates, any delay in the market data processing chain can lead to delayed trading signals, resulting in missed optimal trading opportunities.

[0003] Current mass trading systems typically use a central processing unit (CPU) as the core computing unit to handle market data processing and signal calculations. The typical process involves the CPU receiving high-frequency market data streams, splitting, preprocessing, and storing the data, and then sequentially executing or using limited multithreading to calculate indicators, generate signals, and make trading decisions. While this approach is simple to implement, when real-time analysis of a large number of stocks is required simultaneously, the limited number of CPU cores available for parallel computing makes it difficult to fully parallelize the computational tasks for a massive number of stocks. This can easily lead to task queuing, increased thread switching overhead, and ultimately, limited overall throughput.

[0004] Furthermore, traditional CPU-based processing architectures struggle to balance high concurrency and low latency in areas such as data splitting, queue sorting, computing resource scheduling, and result feedback. This can easily lead to problems like data processing backlog and delayed signal generation, thereby affecting the real-time performance and stability of the trading system.

[0005] Therefore, there is an urgent need for a GPU-based parallel computing-based quantitative trading processing method that can improve market data processing throughput and reduce trading signal generation latency in high-concurrency scenarios involving multiple stocks. Summary of the Invention

[0006] Therefore, it is necessary to provide a quantitative trading processing method, device, computer equipment, and storage medium based on GPU parallel computing to address the above-mentioned technical problems. This method has the advantages of improving market data processing throughput and reducing trading signal generation latency in high-concurrency scenarios involving multiple stocks.

[0007] A quantitative trading processing method based on GPU parallel computing, the method comprising: At the central processing unit, the received high-frequency market data stream is split into multiple stock data queues based on the stock code, and the stock data in each stock data queue is sorted according to the timestamp to obtain multiple target stock data queues, each of which corresponds to one stock code. On the central processing unit, the target stock data queue is transferred to the storage space of the GPU processor through the direct memory access mechanism, and parallel computing threads or thread blocks are configured for each target stock data queue on the GPU processor, so that each parallel computing thread or thread block establishes a fixed mapping relationship with the corresponding stock code. On the GPU processor side, based on the fixed mapping relationship, the stock data of each target stock data queue in the storage space of the GPU processor are used to calculate indicators and generate trading signals. On the GPU processor side, the transaction signal is transmitted back to the central processing unit (CPU) side, and a transaction instruction is generated on the CPU side based on the transaction signal.

[0008] Optionally, the step of sorting the stock data in each stock data queue according to the timestamp to obtain multiple target stock data queues includes: Preprocessing is performed on the stock data queue to obtain a preprocessed stock data queue. The preprocessing includes data cleaning and / or data verification. The stock data in each preprocessed stock data queue is sorted according to the timestamp to obtain multiple target stock data queues.

[0009] Optionally, the step of transferring the target stock data queue to the GPU processor's storage space via direct memory access includes: At the central processing unit, stock data in the target stock data queue is aggregated according to a preset time window to obtain market data packets; At the central processing unit, the market data packets are transmitted to the storage space of the GPU processor based on the direct memory access mechanism.

[0010] Optionally, the GPU processor's storage space is constructed with a storage structure indexed by stock code. After the market data packet is transmitted to the GPU processor's storage space based on the direct memory access mechanism, the method further includes: The GPU processor receives the market data packet and parses the market data packet to determine the stock codes and corresponding stock data contained therein. On the GPU processor side, the stock data in the market data packet is written into the corresponding index position in the storage structure according to the stock code, and the stock data corresponding to each stock code is stored continuously in the index position.

[0011] Optionally, the storage structure includes a write area and a ready area for each stock code's index position. The write area is used to cache newly added stock data to be processed, and the ready area is used to store stock data snapshots that can be read by parallel computing threads or thread blocks. The step of writing the stock data from the market data packet to the corresponding index position in the storage structure according to the stock code, and ensuring that the stock data corresponding to each stock code is stored continuously within the index position, includes: On the GPU processor side, the stock data corresponding to the stock code in the market data packet is written into the write area; On the GPU processor side, the stock data in the write area is organized into continuously stored data blocks, and the ready area is updated so that the stock data in the ready area is continuously stored in timestamp order.

[0012] Optionally, the step of calculating indicators and generating trading signals based on the fixed mapping relationship for the stock data of each target stock data queue in the storage space of the GPU processor includes: On the GPU processor side, the read pointer is atomically switched at the beginning of each computing cycle so that the parallel computing thread or thread block that has established a fixed mapping relationship with the stock code reads the stock data snapshot in the ready area corresponding to the stock code. Based on the read stock data snapshots, indicators are calculated and trading signals are generated in timestamp order.

[0013] Optionally, the storage space further includes a trading signal output area, which includes the trading signal output position corresponding to each stock code. After calculating indicators and generating trading signals for the stock data of each target stock data queue in the storage space of the GPU processor based on the fixed mapping relationship, the method further includes: The trading signal is written to the trading signal output position that matches the corresponding stock code on the GPU processor side; The step of transmitting the transaction signal back to the central processing unit at the GPU processor end includes: On the GPU processor side, when the trading signal meets the preset threshold condition, a valid mark is set for the trading signal output position corresponding to the trading signal; The valid marker is detected at the central processing unit. After detecting the valid flag, only the transaction signal with the valid flag set is sent back to the central processing unit.

[0014] A quantitative trading processing device based on GPU parallel computing, comprising a central processing unit and a GPU processor, the device including: The splitting and sorting module is used at the central processing unit to split the received high-frequency market data stream into multiple stock data queues based on stock codes, and sort the stock data in each stock data queue according to timestamps to obtain multiple target stock data queues, each target stock data queue corresponding to one stock code. The transmission configuration module is used to transmit the target stock data queue to the storage space of the GPU processor through the direct memory access mechanism on the central processing unit, and to configure parallel computing threads or thread blocks for each target stock data queue on the GPU processor, so that each parallel computing thread or thread block establishes a fixed mapping relationship with the corresponding stock code. The calculation and generation module is used to perform indicator calculations and generate trading signals on the stock data of each target stock data queue in the storage space of the GPU processor based on the fixed mapping relationship on the GPU processor side. The backhaul generation module is used to transmit the transaction signal back to the central processing unit at the GPU processor end, and generate a transaction instruction at the central processing unit end based on the transaction signal.

[0015] A computer device includes a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor, wherein the processor implements the aforementioned GPU-based parallel computing-based quantitative trading processing method when executing the computer-readable instructions.

[0016] A readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the aforementioned GPU-based parallel computing-based quantitative trading processing method.

[0017] The aforementioned GPU-based parallel computing-based quantitative trading processing method, at the central processing unit (CPU), splits the received high-frequency market data stream into multiple stock data queues based on stock codes, and sorts the stock data in each queue according to timestamps to obtain multiple target stock data queues, each corresponding to a stock code. At the CPU, the target stock data queues are transferred to the GPU's storage space via direct memory access (DMI), and parallel computing threads or thread blocks are configured for each target stock data queue, establishing a fixed mapping relationship between each thread or thread block and its corresponding stock code. At the GPU, based on the fixed mapping relationship, indicators are calculated for the stock data in each target stock data queue in the GPU's storage space to generate trading signals. Finally, the trading signals are sent back to the CPU, and trading instructions are generated at the CPU based on these signals. By splitting high-frequency market data streams into multiple stock data queues by stock code and sorting them by timestamp at the central processing unit (CPU), the timing consistency of individual stock market data processing is ensured. Simultaneously, each target stock data queue is transferred to the GPU processor's storage space via direct memory access (DMI), and a fixed mapping relationship is established for each stock code using parallel computing threads or thread blocks. This allows the calculation of indicators for multiple stocks to be completed in parallel at the GPU processor, significantly improving the throughput of massive stock market data processing and reducing computational latency. The calculated trading signals are then sent back to the CPU to generate trading instructions, achieving collaborative processing of "parallel computing + fast decision-making." This effectively avoids the task queuing and signal lag problems caused by traditional sequential processing in CPUs, improving the real-time performance of trading signal output and the overall system response speed. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a quantitative trading processing method based on GPU parallel computing in one embodiment of the present invention; Figure 2 This is a flowchart illustrating a high-frequency market data stream processing method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the memory and thread structure in one embodiment of the present invention; Figure 4 This is a flowchart illustrating another quantitative trading processing method based on GPU parallel computing in one embodiment of the present invention. Figure 5 This is a flowchart illustrating another quantitative trading processing method based on GPU parallel computing in one embodiment of the present invention. Figure 6 This is a schematic diagram of a quantitative trading processing device based on GPU parallel computing in one embodiment of the present invention; Figure 7 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0020] 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. 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.

[0021] In one embodiment, such as Figure 1 As shown, a quantitative trading processing method based on GPU parallel computing is provided, including the following steps: 101. At the central processing unit, the received high-frequency market data stream is split into multiple stock data queues based on the stock codes, and the stock data in each stock data queue is sorted according to the timestamp to obtain multiple target stock data queues.

[0022] In this embodiment of the invention, the central processing unit (CPU) receives high-frequency market data streams pushed by exchanges or data providers and uses these data streams as input data sources for subsequent calculations and processing. The CPU can be a server CPU or an industrial computing unit with multi-core computing capabilities, used to perform data access, parsing, organization, and scheduling. The high-frequency market data stream can include order data, transaction data, and order book snapshot data, and is continuously updated in real time to reflect the dynamic changes in the securities market.

[0023] To facilitate subsequent parallel computing, the central processing unit (CPU) splits the high-frequency market data stream based on stock codes. Data corresponding to the same stock code is extracted and aggregated into an independent stock data queue, making the data for different stocks logically independent. Stock codes can use unique identifiers for securities in the securities market, such as six-digit codes or codes including exchange identifiers. A stock data queue can be understood as a time-ordered collection of messages, carrying data such as orders, transactions, and snapshot updates for the same stock within a continuous time window. Therefore, each target stock data queue corresponds to one stock code.

[0024] To ensure time-series consistency in the data processing of each stock, the central processing unit (CPU) sorts the stock data in each stock data queue according to timestamps. This allows data within the queue to enter subsequent calculations in the order it occurred in the market. The timestamp can be the event time provided by the market data source or the arrival time recorded by the receiving end, describing the chronological order of stock data generation and arrival. This method avoids calculation errors or delayed trading signals caused by out-of-order data arrival. For example, when a stock experiences multiple consecutive transactions and order changes within a very short period, sorting these data by timestamp and writing them into the same queue ensures that subsequent calculations always obtain results based on the latest and correct sequence.

[0025] In one possible embodiment, to further improve sorting efficiency and real-time performance, the central processing unit can adopt incremental sorting or a sliding window-based local reordering method to quickly align only a small amount of newly entered data in the queue, thereby reducing sorting overhead and shortening the overall processing latency.

[0026] 102. On the central processing unit, the target stock data queue is transferred to the storage space of the GPU processor through the direct memory access mechanism, and parallel computing threads or thread blocks are configured for each target stock data queue on the GPU processor, so that each parallel computing thread or thread block establishes a fixed mapping relationship with the corresponding stock code.

[0027] In this embodiment of the invention, after the central processing unit completes the construction of the target stock data queue, it transmits the target stock data queue to the storage space of the GPU processor so as to utilize the parallel computing capabilities of the GPU processor to synchronously process the market data of multiple stocks. The GPU processor can be a general-purpose graphics processing unit with large-scale parallel computing capabilities, and the storage space can be the GPU processor's video memory or a storage area that can be directly accessed by the GPU processor, used to store the market data to be calculated and intermediate results during the calculation process.

[0028] Data transfer can be implemented using Direct Memory Access (DMA). DMA enables data movement with reduced CPU involvement, allowing market data to move more efficiently from the CPU to the GPU's storage, thus reducing latency introduced by data transfer. In practical applications, the CPU can package multiple target stock data queues into one or more data blocks for transmission, making the process more continuous and consistent with the streaming update characteristics of high-frequency market data. For example, when a batch of data queue segments containing updates for multiple stocks is generated in a short period, this batch of data can be transmitted to the GPU all at once, avoiding the overhead of frequent small data transfers.

[0029] After the data enters the GPU processor, to achieve parallel computing across multiple stocks, the GPU processor configures parallel computing threads or thread blocks for each target stock data queue, establishing a fixed mapping relationship between these threads or thread blocks and their corresponding stock codes. This fixed mapping relationship can be understood as a long-term, stable binding method, ensuring that a specific parallel computing thread or thread block is dedicated to processing the target stock data queue corresponding to a particular stock code during its execution. This reduces the overhead of dynamic scheduling and improves the determinism and real-time performance of multi-stock parallel computing. Through this fixed mapping relationship, the computational tasks for different stocks can be distributed in parallel to different computing units. Each computing unit executes the same indicator calculation logic for its assigned stock data queue, but processes different data objects, thus fully leveraging the parallel capabilities of the GPU processor.

[0030] In one possible embodiment, to adapt to different numbers of stocks or different hardware resource conditions, the mapping relationship between parallel computing threads or thread blocks and stock codes can be configured during the initialization phase according to the number of stocks and computing resource usage, or a group mapping method can be adopted so that a thread block can cover multiple stocks at the same time and complete the corresponding calculation in an intra-thread partitioning manner, so as to maintain stable operation when resources are limited or the data scale expands.

[0031] 103. On the GPU processor side, based on a fixed mapping relationship, the indicators of stock data in each target stock data queue in the GPU processor's storage space are calculated and trading signals are generated.

[0032] In this embodiment of the invention, after the GPU processor completes data reception and establishes a fixed mapping relationship, it performs indicator calculations on the target stock data queue in the storage space based on the fixed mapping relationship, thereby generating trading signals. The fixed mapping relationship enables parallel computing threads or thread blocks to directly locate and access the target stock data queue corresponding to the stock code, reducing the overhead of cross-task scheduling and data lookup, and ensuring that the indicator calculations of different stocks can be completed in parallel within the same computing cycle.

[0033] Indicator calculations can analyze and process stock data in the target stock data queue according to the needs of quantitative trading strategies, and calculate indicator results reflecting information such as price, trading volume, and changes in the order book. Indicators may include, but are not limited to, moving averages, price changes, volume change rates, bid-ask spreads, order depth changes, and trading intensity, used to characterize market conditions and assist in identifying trading opportunities. Because the stock data in the target stock data queue is already arranged in timestamp order, indicator calculations can update data sequentially according to the order in which it occurred, ensuring that the calculation results always correspond to the latest market conditions, thus avoiding errors caused by out-of-order data.

[0034] Trading signals can be further triggered by indicator calculations to express the decision-making intent of a trading strategy, such as buy signals, sell signals, or wait-and-see signals. Trading signals can include information such as stock code, signal type, signal strength, and trigger time, enabling rapid formation of trading instructions in subsequent stages. For example, when a stock's short-term moving average breaks above its long-term moving average and trading volume increases simultaneously, a parallel computing thread can generate a buy signal after updating the indicator; when the bid-ask spread continues to deteriorate and reaches a preset threshold, a sell signal can be generated; when indicator changes do not meet the trigger conditions, a static state can be maintained to reduce invalid trades.

[0035] In one possible embodiment, to further reduce computational latency and improve indicator update efficiency, the GPU processor can adopt an incremental update method, updating the indicator status only based on newly entered stock data in the target stock data queue, without having to repeat full calculations for the entire queue. At the same time, stock status caches, such as the latest price, market snapshot, and cumulative trading volume, can be maintained during the calculation process, so that trading signals can be generated and output in a very short time after the data arrives.

[0036] 104. On the GPU processor side, the trading signal is sent back to the central processing unit (CPU) side, and the CPU side generates trading instructions based on the trading signal.

[0037] In this embodiment of the invention, after generating a trading signal, the GPU processor sends the signal back to the central processing unit (CPU) so that the CPU can generate trading instructions and interact with the external order placement interface. The signal feedback can be achieved using a data transmission channel between the GPU and the CPU. The feedback content may include stock code, signal type, signal strength, trigger time, and auxiliary information related to risk control, enabling the CPU to quickly make decisions and construct instructions after receiving the signal.

[0038] To reduce backhaul bandwidth consumption and further compress latency, backhaul can adopt an event-triggered approach. This means the GPU processor only backhauls trading signals that meet preset conditions. These preset conditions could include signal strength exceeding a threshold, indicator changes reaching a trigger threshold, or the bid-ask spread exceeding a threshold. This allows the central processing unit (CPU) to prioritize high-value signals, rather than backhauling the calculation results for all stocks in every calculation cycle. For example, when a stock generates a strong buy signal, the GPU processor marks the signal as valid and backhauls it immediately. For stocks that generate only weak signals or no signals, backhauling can be delayed or eliminated, thereby reducing invalid data transmission and improving overall response speed.

[0039] After receiving trading signals, the central processing unit (CPU) generates trading instructions based on these signals. Trading instructions can include elements such as security code, trading direction, order price, order quantity, and order type. They can also be validated for legality and executability by incorporating information such as available account funds, current holdings, and trading time restrictions. The CPU can also execute simplified risk control logic before generating trading instructions, such as position limit checks, single order size limits, price deviation limits, and cooldown time limits, to prevent abnormal order placement under extreme market conditions. Once the trading instruction is generated, the CPU can send it to the trading gateway or brokerage trading interface for execution.

[0040] In one possible embodiment, the central processing unit can set a priority queue for trading signals, so that trading signals of different stocks are sorted and processed according to their strength or urgency. It can also trigger retry, cancellation or downgrade strategies when an order fails or the transaction feedback is abnormal, so as to further improve the stability and controllability of the trading chain.

[0041] In this embodiment of the invention, at the central processing unit (CPU), the received high-frequency market data stream is split into multiple stock data queues based on stock codes. The stock data in each queue is then sorted according to timestamps to obtain multiple target stock data queues, each corresponding to a stock code. At the CPU, the target stock data queues are transferred to the GPU's storage space via direct memory access (DMI). Parallel computing threads or thread blocks are configured for each target stock data queue at the GPU, establishing a fixed mapping relationship between each thread or thread block and its corresponding stock code. At the GPU, based on the fixed mapping relationship, indicators are calculated for the stock data in each target stock data queue within the GPU's storage space, and trading signals are generated. The trading signals are then sent back to the CPU, where trading instructions are generated based on the trading signals. By splitting high-frequency market data streams into multiple stock data queues by stock code and sorting them by timestamp at the central processing unit (CPU), the timing consistency of individual stock market data processing is ensured. Simultaneously, each target stock data queue is transferred to the GPU processor's storage space via direct memory access (DMI), and a fixed mapping relationship is established for each stock code using parallel computing threads or thread blocks. This allows the calculation of indicators for multiple stocks to be completed in parallel at the GPU processor, significantly improving the throughput of massive stock market data processing and reducing computational latency. The calculated trading signals are then sent back to the CPU to generate trading instructions, achieving collaborative processing of "parallel computing + fast decision-making." This effectively avoids the task queuing and signal lag problems caused by traditional sequential processing in CPUs, improving the real-time performance of trading signal output and the overall system response speed.

[0042] It is understood that in the specific implementation of this application, data such as high-frequency market data streams, stock codes, and timestamps are involved. When the embodiments in this application are applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0043] Optionally, in the step of sorting the stock data in each stock data queue according to the timestamp to obtain multiple target stock data queues, preprocessing can also be performed on the stock data queues to obtain preprocessed stock data queues. The preprocessing includes data cleaning and / or data verification. The stock data in each preprocessed stock data queue is then sorted according to the timestamp to obtain multiple target stock data queues.

[0044] In this embodiment of the invention, to improve the reliability and consistency of market data after it enters the calculation stage, after the stock data queue is constructed, preprocessing can be performed on the stock data queue first, and then the data in the preprocessed stock data queue can be sorted according to timestamp order to obtain the target stock data queue for subsequent parallel computing. The purpose of preprocessing is to eliminate abnormal data that may be introduced during the transmission, parsing, or splicing of high-frequency market data streams in advance, and to avoid abnormal data directly participating in indicator calculations and causing trading signal deviations.

[0045] Preprocessing can include data cleaning and data validation. Data cleaning removes empty fields, outliers, duplicate records, invalid identifiers, etc., and corrects or discards data that clearly does not conform to business logic, such as negative trading volume, zero price that does not comply with suspension rules, or timestamp rollback exceeding the allowable range. Data validation confirms the integrity and legality of stock data, such as verifying field formats, checking for missing key fields, verifying the continuity of data packet sequence numbers, and verifying whether timestamps are monotonically increasing or meet preset order requirements. Through cleaning and validation, the data entering subsequent processing is ensured to be computable, reducing abnormal branches generated by subsequent threads during calculations, thereby improving overall throughput efficiency.

[0046] After preprocessing, the stock data in the preprocessed stock data queue is sorted by timestamp, arranging the data in the chronological order of market events. This helps maintain consistency in the time series status updates of each stock. For example, if the tick-by-tick transaction data and market snapshot data of the same stock are briefly out of order during network transmission, without preprocessing and sorting, indicator calculations might read the newer snapshot before the older transaction, causing a state rollback. By first verifying and removing abnormal records, and then sorting by timestamp, subsequent calculations can always be based on a stable time series input, thereby improving the accuracy and interpretability of trading signal generation.

[0047] In one possible embodiment, preprocessing can also introduce configurable filtering rules or whitelist mechanisms to adapt to different data quality characteristics under different data sources and different trading periods. For example, a stricter verification strategy can be adopted in the call auction phase, and a more real-time fast cleaning strategy can be adopted in the continuous auction phase to further balance data reliability and processing latency.

[0048] Furthermore, regarding the processing of high-frequency market data streams and stock data queues, please refer to... Figure 2 A flowchart illustrating a high-frequency market data stream processing method further explains that, through... Figure 2 It can be seen that, Figure 2The right side shows the entry point for the mixed market data stream received by the central processing unit. This mixed market data stream can be understood as a unified input channel where market updates for multiple stocks across the entire market arrive continuously on the timeline. Each data entry typically carries a stock code, timestamp, and fields such as transaction details, order information, or snapshots. After entering the central processing unit, the mixed market data stream is first parsed and formatted by the preprocessing module, transforming the raw input into structured data that can be used for subsequent distribution and storage.

[0049] Figure 2 The central part of the diagram illustrates the processing logic for splitting and distributing data by stock code. The preprocessing module splits the mixed market data stream into multiple stock data queues based on stock codes, ensuring that each queue contains only data for the same stock code and maintaining an organization within the queue that allows for continuous appending and sequential reading. The diagram uses multiple stock codes as examples to illustrate the correspondence between different queues; for instance, it may include queues numbered 000001, 000002, etc. Each queue can contain information such as order details, trades, and market snapshots for that stock over a continuous time period. This splitting method transforms the originally mixed data source into a parallel, multi-channel input structure, providing a foundation for subsequent parallel computation.

[0050] Figure 2 The left side of the diagram illustrates the storage and organization of multiple stock data queues on the GPU processor. The GPU processor can pre-allocate an independent data buffer area for each stock code to store the corresponding stock data queue content, thereby achieving data isolation and parallel reading. Each buffer area can further organize data using contiguous storage, allowing the queue to be accessed as contiguous memory blocks during writing and reading, reducing bandwidth waste caused by random access. The side-by-side display of multiple buffer areas in the diagram reflects the state where multiple stock data reside simultaneously in the GPU processor's storage space, enabling different parallel computing threads or thread blocks to each read the data of their respective stocks and perform indicator calculations.

[0051] Figure 2 The right side of the data queue also shows the data transfer relationship between the central processing unit (CPU) and the GPU (i.e., batch asynchronous transfer to the GPU). After forming the stock data queue, the CPU can aggregate updated data within a very short time window into a market data packet and transfer the market data packet to the GPU, enabling the GPU to periodically obtain the latest queue increment data. This transfer process can be coordinated with the GPU's computation cycle to ensure that the data read by the GPU is logically complete and consistent, thereby avoiding read / write conflicts or inconsistent states during computation.

[0052] For example, when both tick-by-tick transactions and snapshot updates for stocks 000001 and 000002 are received simultaneously within a certain time window, the central processing unit (CPU) can append the data for each stock to its respective stock data queue, organize the data in the queue according to timestamps, and then aggregate the queue increments within the window into a market data packet, which is then transmitted to the GPU processor. After the GPU processor writes the incremental data into the buffer area of ​​the corresponding stock, the parallel computing thread or thread block that has established a fixed mapping relationship with the stock code can immediately read and update the indicator calculation results to generate timely trading signals.

[0053] Optionally, in the step of transferring the target stock data queue to the storage space of the GPU processor via direct memory access mechanism, the stock data in the target stock data queue can also be aggregated at the central processing unit according to a preset time window to obtain market data packets; and the market data packets can be transferred to the storage space of the GPU processor based on the direct memory access mechanism at the central processing unit.

[0054] In this embodiment of the invention, to further reduce the waiting time and transmission overhead of high-frequency market data during transmission, when transmitting the target stock data queue to the GPU processor's storage space, a method of aggregating data by time window before transmission can be used to complete the data transfer. The central processing unit can first extract newly arrived stock data within a preset time window from each target stock data queue, and then aggregate and organize this stock data to form a unified market data packet. This market data packet is then transmitted to the GPU processor's storage space based on the direct memory access mechanism, enabling the GPU processor to receive and process data in batches.

[0055] A preset time window is used to constrain the data range of each aggregation, ensuring a stable rhythm between transmission and computation. The preset time window can be configured according to business needs, for example, using microsecond or millisecond time spans. This ensures that the aggregation process neither excessively delays data arrival nor causes additional overhead due to frequent transmission of single data entries. A market data packet can be understood as the smallest organizational unit of a transmission. A market data packet can contain stock data fragments corresponding to multiple stock codes, and carries the corresponding stock code identifier and timestamp information within the packet, enabling the GPU processor to quickly complete parsing and writing after receiving the data.

[0056] Direct Memory Access (DMI) is used to enable rapid data transfer between the CPU and GPU, allowing data to be transmitted with minimal CPU resource consumption. Using this method, the CPU can directly trigger data transmission after processing the market data packets, placing them into the GPU's memory and providing input for subsequent parallel computation. Since transmission occurs in units of market data packets, the GPU can receive incremental data for multiple stocks in a single reception, reducing the number of transmissions and improving effective bandwidth utilization.

[0057] For example, when multiple stocks generate tick-by-tick transactions and snapshot updates simultaneously within a short period of time, the central processing unit can aggregate these updates according to a preset time window, generate a market data packet containing incremental updates of multiple stocks, and transmit it to the GPU processor in one go through the direct memory access mechanism. This allows the GPU processor to complete the data updates and indicator calculations of multiple stocks within the same computing cycle, avoiding frequent waiting and latency accumulation caused by transmitting data one by one.

[0058] In one possible embodiment, the market data packets can also be organized using a contiguous memory layout, so that stock code identifiers and stock data fragments are arranged in memory in a preset order, thereby enabling the GPU processor to quickly locate the data during parsing and reducing the overhead caused by non-contiguous access, further improving transmission and writing efficiency.

[0059] Optionally, the GPU processor's storage space is constructed with a storage structure indexed by stock code. After the step of transmitting market data packets to the GPU processor's storage space based on the direct memory access mechanism, the GPU processor can also receive market data packets and parse them to determine the stock codes and corresponding stock data contained therein. On the GPU processor, the stock data in the market data packets is written into the corresponding index positions in the storage structure according to the stock codes, and the stock data corresponding to each stock code is stored continuously within the index positions.

[0060] In this embodiment of the invention, to enable the parallel computing threads on the GPU processor to read input data matching their own stock codes with low overhead, a storage structure indexed by stock codes can be pre-built in the GPU processor's storage space. After the market data packet transmission is completed, the GPU processor performs reception, parsing, and writing. The storage structure indexed by stock codes is used to isolate the data of different stocks, so that each stock code corresponds to an independent index position. The index position can correspond to a pre-allocated storage area for storing the stock data sequence of that stock, thereby facilitating subsequent fast location and continuous reading by stock code.

[0061] After market data packets enter the GPU processor's storage space, the GPU processor can parse the data packets to determine the set of stock codes contained within the data packets, and the corresponding stock data content for each stock code. Parsing may include reading the packet header information to obtain the number of data entries, stock code identifiers, data length or offset information, and using this to locate the start and end positions of each group of stock data in the market data packet. After parsing, the stock data can be written to the corresponding index position in the storage structure according to the stock code, so that stock data for the same stock code enters the storage area managed by the same index position.

[0062] To improve parallel reading efficiency, the stock data corresponding to each stock code can be organized using contiguous storage within the index location. Contiguous storage ensures that multiple data entries for the same stock are arranged adjacently in memory, facilitating sequential scanning or batch loading by parallel computing threads and reducing the access overhead caused by cross-address jumps. Contiguous storage can be manifested by writing multiple data entries for the stock within a preset time window sequentially into the same contiguous address space according to arrival order or timestamp order, and maintaining the write offset or effective length in the index location, so that subsequent calculations can accurately obtain the effective data range.

[0063] For example, a market data packet might contain multiple update records for stocks A, B, and C within the same time window. After parsing, the positions of several records corresponding to stock A within the market data packet can be identified, and these records are written to the contiguous storage area corresponding to the index position of stock A. The data for stocks B and C are written to the contiguous storage areas corresponding to their respective index positions. Subsequently, when the parallel computing thread performs indicator calculations, the thread with a fixed mapping to stock A can directly access the contiguous data block at the index position of stock A to complete the calculation, without needing to repeatedly filter and jump through mixed data.

[0064] In one possible embodiment, the storage structure indexed by stock code can be implemented as a two-dimensional array, where the first dimension represents the index number after the stock code is mapped, and the second dimension represents the data sequence position of the stock. Alternatively, it can be implemented using a combination of hash index and contiguous data blocks, where the hash index is used to quickly map the stock code to the corresponding index position, and the contiguous data blocks are used to store the stock data sequence. Furthermore, to reduce memory fragmentation and reordering overhead during the write process, a fixed capacity can be pre-allocated at each index position and an append-only write method can be used. When the capacity is insufficient, expansion or rolling over is triggered to maintain the contiguous storage characteristics.

[0065] Furthermore, the mapping between memory and threads can be achieved through methods such as... Figure 3 The schematic diagram of a memory and thread structure shown further illustrates that, through Figure 3 It can be seen that, Figure 3 The upper part of the diagram illustrates the thread grid organization on the GPU processor side, where each thread block is responsible for the parallel processing of one or a group of stocks. Each thread block contains at least one parallel computing thread for performing indicator calculations and trading signal generation. The diagram exemplifies multiple thread blocks, including thread block 0, thread block 1, and thread block M. Thread block 0 processes stock 000001, thread block 1 processes stock 000002, and thread block M processes stock XXXXX, thus forming a fixed mapping relationship between stock codes and parallel execution units.

[0066] Figure 3 The lower part of the diagram shows that the GPU processor's global storage space is divided into multiple independent data storage partitions. Each partition can be viewed as a data area divided by stock code, used to store stock data queues matching the corresponding stock code. The diagram exemplifies multiple partitions, such as data partition 0, data partition 1, and data partition M, with each partition containing the corresponding stock data queue. For example, data partition 0 stores the data queue for stock 000001, data partition 1 stores the data queue for stock 000002, and data partition M stores the data queue for stock XXXXX. Each data queue can contain multiple data entries such as individual orders, individual transactions, and market snapshots, organized sequentially by timestamp for sequential reading and batch calculation.

[0067] Figure 3 The connection between thread blocks and data partitions is based on independent access relationships, reflecting the data isolation principle in parallel computing. Each thread block only accesses the data partition that matches its own stock code, avoiding access to data partitions of other stocks. This avoids the competition risk caused by cross-stock data sharing and ensures that the state updates of different stocks do not interfere with each other during parallel computing. Because the access path is fixed, threads can directly locate consecutive data blocks in the corresponding data partition during execution, reducing latency caused by repeated searches and random jumps.

[0068] For example, when thread block 0 processes stock 000001, the thread inside thread block 0 can directly read the stock 000001 data queue in data partition 0 and update intermediate variables such as price, trading volume, and order book status in the order of timestamps. Then, it completes the indicator calculation and outputs the trading signal. At the same time, when thread block 1 processes stock 000002, it only accesses the stock 000002 data queue in data partition 1. The two are executed in parallel and do not affect each other, thus forming a corresponding structure of "multi-threaded blocks processing in parallel and multiple data partitions storing independently".

[0069] Optionally, the storage structure includes a write area and a ready area for each stock code's index position. The write area is used to cache newly added stock data to be processed, and the ready area is used to store stock data snapshots that can be read by parallel computing threads or thread blocks. In the step of writing stock data from the market data packet to the corresponding index position in the storage structure according to the stock code, and ensuring that the stock data corresponding to each stock code is stored continuously within the index position, the stock data of the corresponding stock code in the market data packet can also be written to the write area on the GPU processor side. On the GPU processor side, the stock data in the write area is organized into continuously stored data blocks, and the ready area is updated so that the stock data in the ready area is stored continuously in timestamp order.

[0070] In this embodiment of the invention, to avoid read-write conflicts when high-frequency writing and parallel reading occur simultaneously, and to ensure the integrity and consistency of the data read by parallel computing threads, a write area and a ready area can be divided in the storage structure indexed by stock code, corresponding to the index position of each stock code. The write area is used to receive and temporarily store the latest arriving, yet unprocessed, new stock data, while the ready area is used to store snapshots of stock data that have been processed and can be stably read by parallel computing threads or thread blocks, thereby forming a storage organization method in which "writing and computing are mutually isolated".

[0071] When the GPU processor receives market data packets, it first parses them to obtain the stock codes and corresponding stock data. Then, it writes the stock data belonging to a specific stock code into the write area at the corresponding index position of that stock code. The write area can be understood as a cache pool, used to absorb newly added data arriving continuously within a short period of time, avoiding directly overwriting valid data being read during the write process. After writing is complete, the stock data in the write area can be organized, arranged in timestamp order, and the organized result can be grouped into contiguous storage blocks. For example, each order, each transaction, and market snapshot of the same stock code within a preset time window can be merged into a contiguous memory area by timestamp, reducing the random access overhead during subsequent calculations.

[0072] After the data processing is complete, the ready area can be updated to ensure that the stock data is stored continuously in timestamp order. The ready area can be updated via overwrite, append, or by pointing the ready area to a new continuous data block and simultaneously updating the metadata identifier. This ensures that parallel computing threads or thread blocks read a stable snapshot of stock data during their computation cycle, preventing data loss, duplication, or out-of-order issues caused by continuous writing to the write area. In this way, the write area continuously absorbs new data, while the ready area continuously provides computable snapshots. Their clear division of labor allows for a balance between write efficiency and computational consistency in high-frequency data stream scenarios.

[0073] For example, within a certain calculation cycle, the parallel computing thread corresponding to stock 000001 needs to calculate indicators based on the latest transaction and order changes over a certain period. At this time, the thread directly reads data blocks arranged continuously by timestamp from the ready area and processes them sequentially. Simultaneously, when a new market data packet arrives, the newly added data for stock 000001 is written to the write area and processed, but this does not affect the snapshot of the ready area that the thread is currently reading. When the next calculation cycle begins, the ready area is updated, and the thread can read the latest snapshot containing the newly added data, thus achieving "no interference between writing and reading, and consistency between calculation results and data versions".

[0074] In one possible embodiment, the write area and the ready area can be set up with sub-areas for different data types, such as caching each order, each transaction and market snapshot respectively, and merging them uniformly according to timestamps during the consolidation phase; or a fixed capacity can be set for the ready area and a rolling update strategy can be adopted so that the ready area always retains continuous data within the most recent window, so as to balance real-time performance and storage usage.

[0075] Optionally, in the step of calculating indicators and generating trading signals for stock data in each target stock data queue in the GPU processor's storage space based on a fixed mapping relationship, the read pointer can also be atomically switched at the beginning of each calculation cycle on the GPU processor side, so that the parallel computing thread or thread block that has established a fixed mapping relationship with the stock code reads the stock data snapshot in the ready area corresponding to the stock code; and the indicators are calculated and trading signals are generated based on the read stock data snapshot in timestamp order.

[0076] In this embodiment of the invention, to ensure the consistency of the data version read during the parallel computing phase and to avoid concurrent read / write conflicts caused when updating the ready area from the write area, a read pointer can be maintained on the GPU processor side for the ready area corresponding to each stock code. At the beginning of each computing cycle, the read pointer is switched atomically, ensuring that the parallel computing thread or thread block with a fixed mapping relationship to the stock code always reads a complete snapshot of the stock data. The atomic switching means that the update of the read pointer is completed in an indivisible manner at the hardware level, thereby avoiding intermediate states when multiple threads read or update pointers simultaneously. This ensures that the pointer seen by the reading thread either points to the previous complete snapshot or a new complete snapshot, and never to a partially updated data area.

[0077] The fixed mapping relationship here serves to ensure "clear thread ownership." A parallel computing thread or thread block corresponding to a specific stock code only accesses the ready area corresponding to that stock code and does not share state or intermediate variables with other stock codes. This reduces data contention across stocks and limits the switching range of the read pointer to the storage area corresponding to a single stock, making consistency control easier to achieve. The calculation cycle can be triggered according to a preset time window, such as batch processing market data in microsecond or millisecond-level windows. At the beginning of each new calculation cycle, the thread first completes the read pointer switching before starting to read the data in the ready area, thus ensuring that the data version used remains unchanged throughout the entire cycle.

[0078] Once the parallel computing thread reads the stock data snapshot from the ready area, it can process the stock data in the snapshot sequentially according to the timestamp order. For example, it can update the latest price, trading volume, order book volume, market depth, and other state variables in turn. During the update process, it can calculate indicators such as moving average, volume-weighted average, price spread, and volatility, and then generate trading signals based on indicator thresholds or combination rules. Since the snapshot is stored continuously by timestamp, the thread can complete the calculation using a linear traversal method, reducing the latency fluctuations caused by random access, while ensuring that the indicator calculation strictly follows the time order, avoiding indicator distortion caused by out-of-order data.

[0079] For example, the ready area corresponding to a stock code stores the transaction and order update records for the most recent time window. At the start of the calculation period, the thread corresponding to that stock atomically switches the read pointer to lock the current snapshot, then iterates through the records from morning to night according to the timestamp and updates the order book snapshot, calculating the bid-ask difference and trading strength. When the difference and trading strength simultaneously meet preset conditions, a buy signal is generated and written to the trading signal output area. At the same time, the write area can continue to receive new stock data from the next window and organize it into the next snapshot, but this will not affect the snapshot version currently being used by the thread.

[0080] In one possible implementation, the read pointer can switch between two ready area snapshots to facilitate double-buffered updates; alternatively, in a circular buffer organization, it can switch to the new start and end positions of the valid interval and complete the consistency switch by atomically updating the start offset and valid length, thereby achieving the same concurrent consistency effect under different storage organization methods.

[0081] Optionally, the storage space also includes a trading signal output area, which includes the trading signal output position corresponding to each stock code. After the step of calculating indicators and generating trading signals based on a fixed mapping relationship for the stock data of each target stock data queue in the storage space of the GPU processor, the trading signal can be written to the trading signal output position matching the corresponding stock code on the GPU processor side. In the step of sending the trading signal back to the central processing unit on the GPU processor side, when the trading signal meets the preset threshold condition, a valid mark can be set on the trading signal output position corresponding to the trading signal on the GPU processor side. The valid mark is detected on the central processing unit side. After the valid mark is detected, only the trading signals with the set valid mark are sent back to the central processing unit side.

[0082] In this embodiment of the invention, to reduce the data backhaul overhead between the GPU processor and the central processing unit (CPU) and to minimize the time it takes for trading signals to reach the CPU, a trading signal output area can be set up in the GPU processor's storage space. The trading signal output area reserves a trading signal output position for each stock code, used to store the latest trading signal corresponding to that stock code and its associated fields, such as signal direction, signal strength, and generation time. Since a fixed mapping relationship has been established between parallel computing threads or thread blocks and stock codes, after a trading signal is generated, it can be directly written to the trading signal output position matching the stock code. This achieves slot-based writing by stock code, avoiding write conflicts caused by multiple threads competing for the same write address, and also facilitating the CPU to quickly locate the target signal by index.

[0083] To further reduce the amount of data transmitted back, valid markers can be set at the output positions of trading signals to indicate whether a high-priority trading signal requiring transmission exists at that position. Valid markers indicate whether a trading signal meets a preset threshold condition, which may be related to factors such as signal strength, risk constraints, price spread changes, and sudden changes in trading volume. Only when a trading signal meets the preset threshold condition will the GPU processor set a valid marker at the corresponding output position; if the preset threshold condition is not met, the valid marker remains invalid or is cleared, thus preventing a large number of "weak signals" from triggering transmission.

[0084] The central processing unit (CPU) can detect valid flags through polling or event notification. When a valid flag is detected at a certain trading signal output location, the CPU only sends back the trading signals with the valid flag, rather than sending back all trading signals for all stock codes. This significantly reduces the data throughput pressure on the backhaul channel, allowing the backhaul link to focus on a small number of high-value signals, reducing waiting and congestion, and thus improving overall response speed. After the backhaul is complete, the CPU or GPU can reset the corresponding valid flag to allow for the next round of detection and backhaul.

[0085] For example, within a single calculation cycle, thousands of stocks complete indicator calculations in parallel, but only a few trigger "strong buy" or "strong sell" conditions. After the corresponding thread writes the trading signal output location, it sets the valid flag to valid. Upon detecting the valid flag, the CPU only sends back the trading signals of these stocks from the GPU and immediately enters the trading instruction generation and issuance process. Signals of other stocks that did not trigger the threshold conditions are not sent back, thus avoiding the additional delays caused by "full data transmission" and "CPU parsing invalid data."

[0086] In one possible embodiment, valid tags can be organized together with the trading signal output position into a structured record so that the central processing unit can obtain the validity status and trading signal content at the same time in one read; or the valid tags can be organized separately into a tag table that can be scanned quickly, and the corresponding trading signal output position can be read by stock code index after a valid tag is detected, thereby achieving lower detection and backhaul overhead under different hardware bandwidth and access modes.

[0087] Furthermore, the specific application methods of the aforementioned trading signal output position, preset threshold conditions, and effective markers can be achieved through methods such as... Figure 4 The flowchart shown further illustrates another quantitative trading processing method based on GPU parallel computing, through... Figure 4 It can be seen that, Figure 4 The demonstration showcased the collaborative logic between the GPU processor and the central processing unit (CPU) in the signal generation and backhaul phases. The GPU processor focuses on parallel computing and signal filtering, while the CPU focuses on signal acquisition and transaction instruction generation, thus enabling the backhaul link to focus only on valid signals and reduce overall latency.

[0088] On the GPU processor side, multiple parallel computing threads or thread blocks perform indicator calculations on their respective fixed-mapped stock data, generating trading signals upon completion. The strength of these trading signals is then compared to preset threshold conditions. When a trading signal meets the threshold, it is written to the corresponding output position in the trading signal output area, and a valid marker is set at that position, marking it as "valid." When a trading signal does not meet the threshold, no trading signal may be written, or only a null value may be written, while the valid marker remains "invalid," preventing meaningless signals from consuming backhaul bandwidth. Different stock codes in the trading signal output area correspond to different output positions, and these positions are independent of each other, ensuring that the parallel writing process does not cause write conflicts.

[0089] On the central processing unit (CPU), the status of valid flags can be continuously polled or obtained through event notifications. Based on the valid flags, it can determine whether there are any trading signals that need to be transmitted back. When a valid flag is detected, the CPU only reads the output position of the trading signal corresponding to the valid flag, thereby obtaining a valid signal and generating a trading instruction. When no valid flag is detected, the CPU enters a waiting state or continues to execute the next round of detection to reduce the time overhead caused by invalid data transfer and parsing. In this way, the CPU does not need to obtain trading signals for all stocks in each calculation cycle, but only obtains a small number of trading signals that meet the threshold conditions, enabling trading decisions to be triggered and executed more quickly.

[0090] For example, within a computing cycle, the GPU processor completes indicator calculations for a large number of stocks, but only a small number of stocks generate strong buy or sell signals. These signals are written to the corresponding output positions and set as valid markers. After the central processing unit detects the valid markers, it only sends back these valid signals and immediately generates trading instructions. The output positions corresponding to the remaining stocks remain invalid and do not trigger a feedback, thus achieving a low-latency, low-bandwidth signal feedback process.

[0091] In one possible embodiment, the threshold condition can be dynamically adjusted according to the market volatility state. For example, the threshold can be increased during high volatility phases to suppress noise signals, and the threshold can be decreased during low volatility phases to improve the sensitivity of capturing opportunities. The effective flag can also be extended to a multi-level flag to distinguish trading signals of different priorities, so that the central processing unit can prioritize sending back higher-level signals and execute more urgent trading decisions.

[0092] Furthermore, such as Figure 5 The embodiment of the present invention also provides a flowchart of another quantitative trading processing method based on GPU parallel computing, through which... Figure 5 It can be seen that, Figure 5This demonstrates the division of labor and cooperation between the central processing unit (CPU) and the GPU processor in the quantitative trading process based on GPU parallel computing. The CPU focuses on receiving and preprocessing high-frequency market data, receiving trading signals, and generating and executing trading instructions, while the GPU focuses on scheduling parallel computing resources and calculating parallel indicators for massive stock data, thus forming a heterogeneous collaborative processing link for low-latency trading scenarios.

[0093] After the quantitative trading process based on GPU parallel computing begins, the central processing unit (CPU) performs data reception and preprocessing. This involves receiving high-frequency market data streams from the market data source and parsing, formatting, validating, or cleaning the data to create target data usable for subsequent calculations. By performing preprocessing on the CPU, the computational overhead on the GPU during the data preparation phase can be reduced, allowing the GPU's computing resources to be more focused on parallel indicator calculation tasks.

[0094] After preprocessing, the central processing unit (CPU) moves the target data to the global storage space of the GPU, enabling the GPU to directly access the relevant stock data and perform parallel computations. To meet the demands of parallel computing, the GPU further configures parallel tasks and starts kernel functions, establishing a correspondence between parallel computing threads or thread blocks and the stock data to be processed. This allows multiple parallel computing units to simultaneously process data from different stocks. Figure 5 The thread grid shown in the image represents the way parallel tasks are organized on the GPU processor side, and the thread block represents the grouping structure of parallel computing resources. Different threads or thread blocks can process data queues of different stocks respectively, realizing parallel computing of multiple stock data within the same time window.

[0095] During the parallel computing phase on the GPU processor, each parallel computing thread or thread block independently processes the market data of its corresponding stock, generating trading signals through the same indicator calculation logic. This process involves a large number of threads running simultaneously but processing different data objects, thus transforming the traditional sequential computing mode on the central processing unit into a large-scale parallel computing mode, avoiding the accumulation of latency caused by multiple stock calculation tasks queuing up on the central processing unit.

[0096] After the indicator calculation is completed and a trading signal is generated, the trading signal is sent back to the central processing unit (CPU). Upon receiving the trading signal, the CPU generates a trading instruction and sends it to the trading execution chain to complete the trading decision and execution. By keeping the trading decision and execution at the CPU, it is easier to combine risk control constraints, capital checks, order placement rules, and other logic, achieving an effective connection between computational acceleration and trading execution control.

[0097] In one possible embodiment, the target data transport can be carried out in an asynchronous manner, so that the central processing unit can continue to receive and preprocess the next batch of data while transporting the data; the GPU processor can also use a pipelined approach to continuously execute index calculations, so that data transport and parallel computing overlap in parallel, thereby further reducing end-to-end processing latency and increasing the frequency of transaction signal output.

[0098] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0099] In one embodiment, a GPU-based parallel computing quantitative trading processing device is provided, which corresponds one-to-one with the GPU-based parallel computing quantitative trading processing method described in the above embodiments. For example... Figure 6 As shown, this GPU-based parallel computing quantitative trading processing device includes a central processing unit and a GPU processor. The device comprises a splitting and sorting module 601, a transmission configuration module 602, a calculation and generation module 603, and a return generation module 604. Detailed descriptions of each functional module are as follows: The splitting and sorting module 601 is used to split the received high-frequency market data stream into multiple stock data queues based on stock codes at the central processing unit, and sort the stock data in each stock data queue according to the timestamp to obtain multiple target stock data queues, each target stock data queue corresponding to one stock code. The transmission configuration module 602 is used to transmit the target stock data queue to the storage space of the GPU processor through the direct memory access mechanism on the central processing unit, and to configure parallel computing threads or thread blocks for each target stock data queue on the GPU processor, so that each parallel computing thread or thread block establishes a fixed mapping relationship with the corresponding stock code. The calculation and generation module 603 is used to perform indicator calculations on the stock data of each target stock data queue in the storage space of the GPU processor based on the fixed mapping relationship on the GPU processor side, and generate trading signals. The backhaul generation module 604 is used to backhaul the transaction signal to the central processing unit at the GPU processor end, and generate a transaction instruction at the central processing unit end based on the transaction signal.

[0100] At the central processing unit, the received high-frequency market data stream is split into multiple stock data queues based on the stock code, and the stock data in each stock data queue is sorted according to the timestamp to obtain multiple target stock data queues, each of which corresponds to one stock code. On the central processing unit, the target stock data queue is transferred to the storage space of the GPU processor through the direct memory access mechanism, and parallel computing threads or thread blocks are configured for each target stock data queue on the GPU processor, so that each parallel computing thread or thread block establishes a fixed mapping relationship with the corresponding stock code. On the GPU processor side, based on the fixed mapping relationship, the stock data of each target stock data queue in the storage space of the GPU processor are used to calculate indicators and generate trading signals. On the GPU processor side, the transaction signal is transmitted back to the central processing unit (CPU) side, and a transaction instruction is generated on the CPU side based on the transaction signal.

[0101] Optionally, the splitting and sorting module 601 is further configured to: Preprocessing is performed on the stock data queue to obtain a preprocessed stock data queue. The preprocessing includes data cleaning and / or data verification. The stock data in each preprocessed stock data queue is sorted according to the timestamp to obtain multiple target stock data queues.

[0102] Optionally, the transmission configuration module 602 is further configured to: At the central processing unit, stock data in the target stock data queue is aggregated according to a preset time window to obtain market data packets; At the central processing unit, the market data packets are transmitted to the storage space of the GPU processor based on the direct memory access mechanism.

[0103] Optionally, the GPU processor's storage space is constructed with a storage structure indexed by stock code, and the device further includes: The parsing module is used to receive the market data packet on the GPU processor and parse the market data packet to determine the stock code and corresponding stock data contained therein; The first writing module is used on the GPU processor to write the stock data in the market data packet into the corresponding index position in the storage structure according to the stock code, and to make the stock data corresponding to each stock code continuously stored in the index position.

[0104] Optionally, the storage structure includes a write area and a ready area for each stock code's index position. The write area is used to cache newly added stock data to be processed, and the ready area is used to store snapshots of stock data that can be read by parallel computing threads or thread blocks. The write module is further used for: On the GPU processor side, the stock data corresponding to the stock code in the market data packet is written into the write area; On the GPU processor side, the stock data in the write area is organized into continuously stored data blocks, and the ready area is updated so that the stock data in the ready area is continuously stored in timestamp order.

[0105] Optionally, the calculation and generation module 603 is further configured to: On the GPU processor side, the read pointer is atomically switched at the beginning of each computing cycle so that the parallel computing thread or thread block that has established a fixed mapping relationship with the stock code reads the stock data snapshot in the ready area corresponding to the stock code. Based on the read stock data snapshots, indicators are calculated and trading signals are generated in timestamp order.

[0106] Optionally, the storage space further includes a trading signal output area, which includes the trading signal output position corresponding to each stock code. The device also includes: The second writing module is used to write the trading signal to the trading signal output position that matches the corresponding stock code on the GPU processor side; The return generation module 604 is further configured to: On the GPU processor side, when the trading signal meets the preset threshold condition, a valid mark is set for the trading signal output position corresponding to the trading signal; The valid marker is detected at the central processing unit. After detecting the valid flag, only the transaction signal with the valid flag set is sent back to the central processing unit.

[0107] The modules in the aforementioned GPU-based parallel computing quantitative trading processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the computer device's memory as software, so that the processor can call and execute the corresponding operations of each module.

[0108] In one embodiment, a computer device is provided, which may be a terminal device, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computational and control capabilities. The memory includes a readable storage medium storing computer-readable instructions. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer-readable instructions implement a GPU-based parallel computing-based quantitative trading processing method. The readable storage medium provided in this embodiment includes both non-volatile and volatile readable storage media.

[0109] In this application embodiment, a computer device is provided, including a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor. When the processor executes the computer-readable instructions, it implements the steps of the quantitative trading processing method based on GPU parallel computing described above.

[0110] In one embodiment of the application, a readable storage medium is provided, which stores computer-readable instructions. When the computer-readable instructions are executed by a processor, they implement the steps of the quantitative trading processing method based on GPU parallel computing described above.

[0111] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a non-volatile readable storage medium or a volatile readable storage medium. When executed, these computer-readable instructions can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0112] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0113] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for processing quantization transactions based on GPU parallel computing, characterized in that, The method includes: At the central processing unit, the received high-frequency market data stream is split into multiple stock data queues based on the stock code, and the stock data in each stock data queue is sorted according to the timestamp to obtain multiple target stock data queues, each of which corresponds to one stock code. On the central processing unit, the target stock data queue is transferred to the storage space of the GPU processor through the direct memory access mechanism, and parallel computing threads or thread blocks are configured for each target stock data queue on the GPU processor, so that each parallel computing thread or thread block establishes a fixed mapping relationship with the corresponding stock code. On the GPU processor side, based on the fixed mapping relationship, the stock data of each target stock data queue in the storage space of the GPU processor are used to calculate indicators and generate trading signals. On the GPU processor side, the transaction signal is transmitted back to the central processing unit (CPU) side, and a transaction instruction is generated on the CPU side based on the transaction signal.

2. The quantitative trading processing method based on GPU parallel computing as described in claim 1, characterized in that, The stock data in each stock data queue is sorted according to timestamps to obtain multiple target stock data queues, including: Preprocessing is performed on the stock data queue to obtain a preprocessed stock data queue. The preprocessing includes data cleaning and / or data verification. The stock data in each preprocessed stock data queue is sorted according to the timestamp to obtain multiple target stock data queues.

3. The quantitative trading processing method based on GPU parallel computing as described in claim 1, characterized in that, The step of transferring the target stock data queue to the GPU processor's storage space via direct memory access includes: At the central processing unit, stock data in the target stock data queue is aggregated according to a preset time window to obtain market data packets; At the central processing unit, the market data packets are transmitted to the storage space of the GPU processor based on the direct memory access mechanism.

4. The quantitative trading processing method based on GPU parallel computing as described in claim 3, characterized in that, The GPU processor's storage space is constructed with a storage structure indexed by stock code. After the market data packets are transmitted to the GPU processor's storage space based on the direct memory access mechanism, the method further includes: The GPU processor receives the market data packet and parses the market data packet to determine the stock codes and corresponding stock data contained therein. On the GPU processor side, the stock data in the market data packet is written into the corresponding index position in the storage structure according to the stock code, and the stock data corresponding to each stock code is stored continuously in the index position.

5. The quantitative trading processing method based on GPU parallel computing as described in claim 4, characterized in that, The storage structure includes a write area and a ready area for each stock code's index position. The write area is used to cache newly added stock data to be processed, and the ready area is used to store stock data snapshots that can be read by parallel computing threads or thread blocks. The step of writing the stock data from the market data packet to the corresponding index position in the storage structure according to the stock code, and ensuring that the stock data corresponding to each stock code is stored continuously within the index position, includes: On the GPU processor side, the stock data corresponding to the stock code in the market data packet is written into the write area; On the GPU processor side, the stock data in the write area is organized into continuously stored data blocks, and the ready area is updated so that the stock data in the ready area is continuously stored in timestamp order.

6. The quantitative trading processing method based on GPU parallel computing as described in claim 5, characterized in that, The step of calculating indicators and generating trading signals based on the fixed mapping relationship for the stock data of each target stock data queue in the storage space of the GPU processor includes: On the GPU processor side, the read pointer is atomically switched at the beginning of each computing cycle so that the parallel computing thread or thread block that has established a fixed mapping relationship with the stock code reads the stock data snapshot in the ready area corresponding to the stock code. Based on the read stock data snapshots, indicators are calculated and trading signals are generated in timestamp order.

7. The quantitative trading processing method based on GPU parallel computing as described in claim 1, characterized in that, The storage space also includes a trading signal output area, which includes the trading signal output position corresponding to each stock code. After calculating indicators and generating trading signals for the stock data of each target stock data queue in the storage space of the GPU processor based on the fixed mapping relationship, the method further includes: The trading signal is written to the trading signal output position that matches the corresponding stock code on the GPU processor side; The step of transmitting the transaction signal back to the central processing unit at the GPU processor end includes: On the GPU processor side, when the trading signal meets the preset threshold condition, a valid mark is set for the trading signal output position corresponding to the trading signal; The valid marker is detected at the central processing unit. After detecting the valid flag, only the transaction signal with the valid flag set is sent back to the central processing unit.

8. A quantitative trading processing device based on GPU parallel computing, characterized in that, The GPU-based parallel computing quantitative trading processing device includes a central processing unit and a GPU processor. The device comprises: The splitting and sorting module is used at the central processing unit to split the received high-frequency market data stream into multiple stock data queues based on stock codes, and sort the stock data in each stock data queue according to timestamps to obtain multiple target stock data queues, each target stock data queue corresponding to one stock code. The transmission configuration module is used to transmit the target stock data queue to the storage space of the GPU processor through the direct memory access mechanism on the central processing unit, and to configure parallel computing threads or thread blocks for each target stock data queue on the GPU processor, so that each parallel computing thread or thread block establishes a fixed mapping relationship with the corresponding stock code. The calculation and generation module is used to perform indicator calculations and generate trading signals on the stock data of each target stock data queue in the storage space of the GPU processor based on the fixed mapping relationship on the GPU processor side. The backhaul generation module is used to transmit the transaction signal back to the central processing unit at the GPU processor end, and generate a transaction instruction at the central processing unit end based on the transaction signal.

9. A computer device comprising a memory, a processor, and computer-readable instructions stored in the memory and running on the processor, characterized in that, When the processor executes the computer-readable instructions, it implements the GPU-based parallel computing quantitative trading processing method as described in any one of claims 1 to 7.

10. A readable storage medium having computer-readable instructions stored thereon, characterized in that, When the computer-readable instructions are executed by the processor, they implement the GPU-based parallel computing quantitative trading processing method as described in any one of claims 1 to 7.

Images