View driving type subgraph matching load balancing method and system and storage medium

Abstract

The invention relates to a view-driven subgraph matching load balancing method and system, computer equipment, a storage medium and a computer program product. Candidate points of part of subgraphs are acquired and screened by starting a kernel function; collecting calculation data; calculating a prefix sum and a total candidate vertex number; dividing a calculation range according to the total number of candidate vertexes; screening candidate points, and recording the number of the candidate points; and counting results and generating a matching result array. The problems of waste of computing resources and low efficiency in the prior art are solved; through the load balancing method, the computing resources of the GPU are fully utilized, and the overall computing performance is remarkably improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a view-driven subgraph matching load balancing method, system, storage medium, and computer program product. Background Art

[0002] Subgraph matching is one of the most fundamental graph problems, with widespread applications in fields such as social network analysis and finance. Due to its computational intensiveness, subgraph matching is well-suited for GPU computing. However, the dramatic increase in real-world data volumes has led to the emergence of large graphs that exceed the capacity of GPU memory. VSGM is a subgraph matching method that can handle data graphs significantly larger than GPU memory.

[0003] The following is a basic introduction to VSGM. Subgraph matching is a technology that searches for subgraphs that match a given pattern graph (denoted as P) in a large-scale graph (denoted as G). In order to process a data graph G that is much larger than the video memory, VSGM divides the data graph G into a set of view buckets and puts them into the GPU for calculation in turn. Each view bucket contains all the data required for subgraph matching starting from a set of source vertices. The sets of source vertices in all buckets do not overlap with each other, and their union constitutes the vertex set of the data graph. The data in these view buckets serves as the source data for our query on the GPU. In addition, a query order π needs to be given before the query, and then the GPU will match according to the query order π. The steps for enumerating subgraphs are as follows: Figure 1 As shown in , we call the graph that only matches some of the nodes in the process a partial subgraph, and the graph that matches all the nodes is called an instance. The text description of the subgraph enumeration steps is as follows: (1) Obtain candidates: Select the next vertex to match according to the search order π. If the vertex has an already determined adjacent node, use the adjacency list of these matched neighbors to find the intersection, exclude the matched candidate points, and thus obtain the candidate items; (2) Filter candidates: Select the part that meets the conditions from the candidate items, and then combine the points that meet the conditions with the partial subgraph that has been matched before this processing to form a new partial subgraph; (3) Repeat operations 1 and 2 until all vertices on the pattern graph P have been matched.

[0004] However, the current operation of VSGM on the GPU has the following problems. When implementing subgraph enumeration on the GPU, VSGM will let each warp on the GPU process a partial subgraph, and then let each thread on the warp jointly judge the candidate points of this partial subgraph. However, each partial subgraph will have a different number of candidate vertices. When the vertex density in some areas of the data graph G is significantly higher than that in other areas, that is, the number of edges connected to some vertices is much higher than that of other vertices, the running time of some warps will be much longer than that of other warps. However, the subsequent calculation steps require the calculation results of all warps in a block to proceed. This causes some warps to stop after the calculation is completed and wait for the warp with a long running time to run out the results, resulting in a waste of computing resources. Summary of the Invention

[0005] Based on this, it is necessary to provide a view-driven subgraph matching load balancing method, system, computer device, storage medium and computer program product to address the above technical problems.

[0006] In a first aspect, the present application provides a view-driven subgraph matching load balancing method, the method comprising:

[0007] Start the kernel function to obtain and filter candidate points of some subgraphs;

[0008] Collecting computational data;

[0009] Calculate the prefix sum and the total number of candidate vertices;

[0010] Dividing the calculation range according to the total number of candidate vertices;

[0011] Screen candidate points and record the number of candidate points;

[0012] Count the results and generate a matching result array.

[0013] In one embodiment, the starting kernel function to obtain and filter candidate points of a portion of the subgraph includes:

[0014] Launch multiple kernel functions to obtain and filter candidate points of some subgraphs;

[0015] Calculate the number of warps in the block that perform fetch and filter operations.

[0016] In one embodiment, calculating the prefix sum and the total number of candidate vertices includes:

[0017] Calculate the prefix sum of the number of candidate vertices for each warp in the block and get the total number of candidate vertices.

[0018] In one embodiment, dividing the calculation range according to the total number of candidate vertices includes:

[0019] The calculation tasks are evenly distributed on the warp according to the total number of candidate vertices, and the starting and ending positions of the calculation of each warp are given.

[0020] In one embodiment, screening candidate points and recording the number of candidate points includes:

[0021] The candidate vertices within the range are judged one by one on the warp, the candidate points that meet the conditions are screened out, and the number of candidate points is recorded.

[0022] In one embodiment, the statistical results generate a matching result array, including:

[0023] The filtered data in the entire block is counted to obtain an array that records the number of matching results of some subgraphs on the block.

[0024] In a second aspect, the present application further provides a view-driven subgraph matching load balancing system, the system comprising:

[0025] The startup module is used to start the kernel function and obtain and filter candidate points of some subgraphs;

[0026] A collection module, used to collect calculation data;

[0027] Calculation module, used to calculate the prefix sum and the total number of candidate vertices;

[0028] A partitioning module, configured to partition a calculation range according to the total number of candidate vertices;

[0029] Screening module, used to screen candidate points and record the number of candidate points;

[0030] The statistics module is used to count the results and generate a matching result array.

[0031] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are performed:

[0032] Start the kernel function to obtain and filter candidate points of some subgraphs;

[0033] Collecting computational data;

[0034] Calculate the prefix sum and the total number of candidate vertices;

[0035] Divide the calculation range according to the total number of candidate vertices;

[0036] Screen candidate points and record the number of candidate points;

[0037] Count the results and generate a matching result array.

[0038] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the following steps:

[0039] Start the kernel function to obtain and filter candidate points of some subgraphs;

[0040] Collecting computational data;

[0041] Calculate the prefix sum and the total number of candidate vertices;

[0042] Dividing the calculation range according to the total number of candidate vertices;

[0043] Screen candidate points and record the number of candidate points;

[0044] Count the results and generate a matching result array.

[0045] In a fifth aspect, the present application further provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the following steps:

[0046] Start the kernel function to obtain and filter candidate points of some subgraphs;

[0047] Collecting computational data;

[0048] Calculate the prefix sum and the total number of candidate vertices;

[0049] Dividing the calculation range according to the total number of candidate vertices;

[0050] Screen candidate points and record the number of candidate points;

[0051] Count the results and generate a matching result array.

[0052] The above-described view-driven subgraph matching load balancing method, system, computer device, storage medium, and computer program product, by launching a kernel function, obtains and filters candidate points for a portion of the subgraph; collects computational data; calculates the prefix sum and the total number of candidate vertices; divides the computational range based on the total number of candidate vertices; filters the candidate points and records the number of candidate points; and finally, calculates the results to generate a matching result array. This solves the problems of computational resource waste and inefficiency in existing technologies. Through this load balancing method, GPU computing resources are more fully utilized, significantly improving overall computing performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1A schematic diagram of implementing subgraph enumeration in the prior art;

[0054] Figure 2 A flow chart of a view-driven subgraph matching load balancing method provided by one embodiment of the present invention;

[0055] Figure 3 An architectural diagram of a view-driven subgraph matching load balancing system provided by one embodiment of the present invention;

[0056] Figure 4 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0058] Before each warp starts to perform the screening operation, the partial subgraph data involved in the current warp will be transferred to the shared memory for storage. Subsequently, from the vertices involved in this partial subgraph, the vertices with a smaller number of candidate points are screened out as hub vertices. Next, the adjacent vertices of the hub vertex are extracted from the related CSR (Compressed Sparse Row) storage of the hub vertex, and these vertices are assigned to different threads in the warp for judgment operations. However, due to the differences in the number of these candidate vertices, the computational load of different warps is unbalanced, which in turn affects the overall computational efficiency. Based on the above problem analysis, the main idea of ​​this method is to count and calculate the number of all candidate vertices that need to be judged in the block before the warp screens the candidate vertices. Then, the number of these candidate vertices is reasonably distributed within the entire warp range, so that the number of candidate vertices that need to be judged on each warp remains basically consistent.

[0059] To achieve the above purpose, please refer to Figure 1 , the present application provides a view-driven subgraph matching load balancing method, the method comprising:

[0060] S100, starting the kernel function to obtain and filter candidate points of some subgraphs.

[0061] In this application, it is necessary to start multiple kernel functions to obtain and filter candidate points of some subgraphs, and pass the number of warps for acquisition and filtering operations in the block to the subsequent device-side function for allocation operations.

[0062] Specifically, if there are 256 threads in each block and 32 threads in each warp, there will be 8 warps in each block. We first assume that in the subsequent filtering operation, one warp will process a partial subgraph, so we need at least the same number of warps as the partial subgraphs. Because when a block is started, all 8 warps on it will be started, but when the number of partial subgraphs cannot be divided by 8, there will be extra warps on the last block, and subsequent filtering operations will not be performed on these extra warps. Therefore, on each kernel function, the number pid of the current warp on all warps will be calculated, and the subsequent filtering function will be run only when the pid is less than the number of partial subgraphs. In addition, the averaging operation also needs to know the number of warps in the block that will perform subsequent filtering operations. Therefore, the number of active warps in the current block will also be passed into the subsequent operations.

[0063] S200, collecting calculation data.

[0064] Specifically, some subgraph-related data involved in the subgraph enumeration in the block is transferred to the shared memory, and the data required for subsequent calculations is calculated.

[0065] This step is used to collect the data required for subsequent calculations. Because it is assumed in step S100 that each warp processes a partial subgraph, we need to first transfer the data of the partial subgraph into the shared memory. Here, a two-dimensional array in the shared memory is defined:

[0066] M[WARPS_PER_BLOCK][kMaxQueryVerticesNum]

[0067] WARPS_PER_BLOCK is 8, indicating the number of warps in each block, and kMaxQueryVerticesNum is the maximum number of vertices in the possible pattern graph P. Each row of the two-dimensional array M represents a vertex sequence for a partial subgraph, and each element in a row represents the identifier of a matched vertex. The first thread in each warp collects data from the previous row of M corresponding to the warp. Furthermore, the ThreadChoosePivotLevel function in the VSGM method assigns a number shm_pivot_level on M[warp_id]. This number is used to select a vertex M[warp_id][shm_pivot_level] from the partial subgraph. This vertex is called the pivot vertex, and subsequent candidate vertices are obtained from its adjacent vertices. warp_id is the number of the current warp in the block. Subsequently, the starting position and number of candidate points in the CSR structure are determined based on the CSR storage associated with the pivot node. We record the starting position and number in the shm_row_ptrs[warp_id] and raw_number[warp_id] arrays respectively for subsequent calculations.

[0068] S300, calculating the prefix sum and the total number of candidate vertices.

[0069] In this application, the prefix sum of the number of candidate vertices for each warp in the block is calculated, and the total number of candidate vertices is obtained at the same time.

[0070] Specifically, in order to reuse the original function in the VSGM method to determine whether the candidate vertex is valid, we need to give the currently calculated warp_id when judging the vertex, which we record as src_warp_id. However, after the load balancing operation, this vertex may be assigned to another warp for calculation and cannot be directly obtained through the GPU built-in variable threadIdx.x. Therefore, we need a method to obtain src_warp_id, and the src_warp_id can be easily obtained by the prefix sum of the total number of candidate vertices of all warps in the block.

[0071] In step S200, the candidate number numbered warp_id is stored in raw_number[warp_id], and the inclusive prefix sum of this array is calculated and stored in

[0072] warp_candidate_offsets[WARPS_PER_BLOCK] array,

[0073] warp_candidate_offsets[0] is the number of candidate vertices of the partial subgraph involved in the first warp, and warp_candidate_offsets[WARPS_PER_BLOCK-1] is the sum of the number of candidate vertices of all partial subgraphs on the block.

[0074] S400: Divide the calculation range according to the total number of candidate vertices.

[0075] In this application, the computing tasks need to be evenly distributed among the warps according to the total number of candidate vertices, and the starting and ending positions of the calculations for each warp need to be given.

[0076] Specifically, in step S300, we get the total number of candidate vertices of all partial subgraphs on the block, which is recorded as total_candidates. In addition, in step S100, a parameter recording the number of active warps in the block is passed in, which is recorded as raw_warp_number.

[0077] task_per_warp_base

[0078] =(total_candidates+raw_warp_number-1) / raw_warp_number;

[0079] Divide all candidate items into blocks of size raw_warp_number task_per_warp_base. Each warp is responsible for computing one of these blocks, and each warp's vertex computation starts at warp_task_start and ends at warp_task_end. This ensures even distribution of computational tasks within the block.

[0080] S500: Screen candidate points and record the number of candidate points.

[0081] In this application, the candidate vertices within the range are judged in turn on the warp, the candidate points that meet the conditions are screened out, and the number of candidate points is recorded.

[0082] Specifically, on each warp, candidate nodes within the range from warp_task_start to warp_task_end are evaluated one by one. The thread number on the warp is denoted as lane_id. Each thread on the warp starts evaluating the vertex numbered warp_task_start + lane_id. After evaluation, the number is incremented by threads_per_warp until all candidate points in the processing range have been evaluated. This allows threads on the warp to screen candidate vertices in parallel.

[0083] The thread screening process is then described in detail. First, to reuse the existing function for determining the validity of candidate vertices in the VSGM method, the src_warp_id must be calculated, as described in step S300. The current vertex's location, chunk_index, is compared with each data item in the prefix sum array, warp_candidate_offsets. The index of the first data item in the array greater than chunk_index is the value of src_warp_id. The src_warp_id and the judgment function are then used to determine whether the current vertex is valid. Finally, the vertex's validity is recorded. However, in step S400, the computational tasks are redistributed, and vertices previously assumed to be computed on the same warp may be assigned to different warps. Therefore, an array, my_thread_valid_count[WARPS_PER_BLOCK], is maintained on each warp. When a thread determines that a vertex meets the criteria, the value at the array index src_warp_id is incremented by 1. This process ensures that even after redistribution, each thread's judgment result is still accurately attributed to its original warp.

[0084] There are several ways to meet the conditions:

[0085] Label consistency: Candidate points must be consistent with the labels of nodes in the query graph. For example, if a node in the query graph is labeled "A", then the candidate point must also be a node with label "A".

[0086] Edge Relationship Consistency: The edge relationships between candidate points must be consistent with the edge relationships in the query graph. This means that the connection mode, direction, and type between candidate points must match the connection mode, direction, and type of the corresponding nodes in the query graph.

[0087] Attribute consistency: If the query graph nodes or edges have specific attribute requirements, the candidate points must also meet these attribute conditions. For example, the query graph nodes may require specific attribute values, and the candidate points must meet these attribute requirements.

[0088] S600: Count the results and generate a matching result array.

[0089] In this application, statistics are collected on the filtered data in the entire block to obtain an array that records the number of matching results of some subgraphs on the block.

[0090] Specifically, when counting the screening results, we first perform a warp-level reduction operation. Each warp performs a reduction and sum operation on each position of the my_thread_valid_count array of its internal threads. We store the reduced and summed values ​​of each warp into a two-dimensional array in shared memory.

[0091] temp_number[WARPS_PER_BLOCK][WARPS_PER_BLOCK]

[0092] Where temp_number[warp_id][src_warp_id] represents the number of vertices calculated on the warp identified by warp_id that would have met the filter criteria if they had been calculated on src_warp_id. Finally, the first thread of each warp sums the data in the temp_number array to obtain the number of candidate vertices that would have met the criteria if the warp identified by src_warp_id had been calculated.

[0093] Finally, to verify the effectiveness of this load balancing method, we first conducted a comparative analysis of the final statistical results. The results showed that after adopting the load balancing method, the statistical results were completely consistent with the results of the previous unoptimized method, which fully demonstrated the effectiveness of the load balancing method in maintaining the accuracy of the results. Furthermore, we used the NVIDIA Nsight Compute tool to conduct a detailed measurement and analysis of the functions involved in load balancing. The analysis results showed that the optimized Achieved Occupancy (actual occupancy) increased significantly from the original 72% to 99%, which is basically the same as the theoretical value of 100%. This significant improvement shows that through the load balancing method, the GPU's computing resources are more fully utilized, significantly improving overall computing performance.

[0094] In summary, this application addresses the waste of computing resources and inefficiency inherent in existing technologies by initiating a kernel function to obtain and filter candidate points for a portion of the subgraph; collecting computational data; calculating the prefix sum and the total number of candidate vertices; dividing the computational range based on the total number of candidate vertices; filtering candidate points and recording the number of candidate points; and finally, generating a matching result array based on the results. This approach addresses the waste of computing resources and inefficiency inherent in existing technologies. Through load balancing, GPU computing resources are more fully utilized, significantly improving overall computing performance.

[0095] At least part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the steps or stages in other steps.

[0096] Based on the same inventive concept, embodiments of the present application also provide a view-driven subgraph matching load balancing system for implementing the aforementioned method. The solution provided by this system is similar to the solution described in the aforementioned method. Therefore, the specific limitations of one or more view-driven subgraph matching load balancing system embodiments provided below can be found in the limitations of the view-driven subgraph matching load balancing method described above and will not be further elaborated here.

[0097] In one embodiment, Figure 3 As shown, a view-driven subgraph matching load balancing system is provided, including:

[0098] The starting module 100 is used to start the kernel function to obtain and filter candidate points of some subgraphs.

[0099] The collection module 200 is used to collect calculation data.

[0100] The calculation module 300 is used to calculate the prefix sum and the total number of candidate vertices.

[0101] The division module 400 is configured to divide the calculation range according to the total number of candidate vertices.

[0102] The screening module 500 is used to screen candidate points and record the number of candidate points.

[0103] The statistics module 600 is used to collect statistics results and generate a matching result array.

[0104] In one embodiment, the startup module 100 is further configured to start multiple kernel functions to acquire and filter candidate points of a portion of the subgraph; and calculate the number of warps that perform acquisition and filtering operations in the block.

[0105] In one embodiment, the calculation module 300 is further configured to calculate the prefix sum of the number of candidate vertices of each warp in the block, and obtain the total number of candidate vertices.

[0106] In one embodiment, the partitioning module 400 is further configured to: evenly distribute the computation tasks among the warps according to the total number of candidate vertices, and provide a starting position and an ending position for the computation of each warp.

[0107] In one embodiment, the screening module 500 is further configured to: sequentially judge the candidate vertices within the range on the warp, screen out candidate points that meet the conditions, and record the number of candidate points.

[0108] In one embodiment, the statistics module 600 is further configured to perform statistics on the filtered data in the entire block to obtain an array recording the number of matching results of some subgraphs on the block.

[0109] Each module in the above-described view-driven subgraph matching load balancing system can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0110] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store preset data. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a view-driven subgraph matching load balancing method is implemented.

[0111] Those skilled in the art will understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0112] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the above-mentioned view-driven subgraph matching load balancing method when executing the computer program.

[0113] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the above-mentioned view-driven subgraph matching load balancing method is implemented.

[0114] In one embodiment, a computer program product is provided, including a computer program, which implements the above-mentioned view-driven subgraph matching load balancing method when executed by a processor.

[0115] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program. The above-mentioned computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, etc., but are not limited to these.

[0116] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0117] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A view-driven subgraph matching load balancing method, characterized in that: The method comprises: Start the kernel function to obtain and filter candidate points of some subgraphs; Collecting computational data; Calculate the prefix sum and the total number of candidate vertices; Dividing the calculation range according to the total number of candidate vertices; Screen candidate points and record the number of candidate points; Count the results and generate a matching result array.

2. The method according to claim 1, characterized in that The kernel function is started to obtain and filter candidate points of some subgraphs, including: Launch multiple kernel functions to obtain and filter candidate points of some subgraphs; Calculate the number of warps in the block that perform fetch and filter operations.

3. The method according to claim 2, characterized in that The calculation of the prefix sum and the total number of candidate vertices includes: Calculate the prefix sum of the number of candidate vertices for each warp in the block and get the total number of candidate vertices.

4. The method according to claim 2, characterized in that The dividing the calculation range according to the total number of candidate vertices includes: The computational tasks are evenly distributed among the warps according to the total number of candidate vertices, and the starting and ending positions of the computations for each warp are given.

5. The method according to claim 2, characterized in that Screen candidate points and record the number of candidate points including: The candidate vertices within the range are judged one by one on the warp, the candidate points that meet the conditions are screened out, and the number of candidate points is recorded.

6. The method according to claim 2, characterized in that The statistical results generate a matching result array, including: The filtered data in the entire block is counted to obtain an array that records the number of matching results of some subgraphs on the block.

7. A view-driven subgraph matching load balancing system, characterized in that: The system comprises: The startup module is used to start the kernel function and obtain and filter candidate points of some subgraphs; A collection module, used to collect calculation data; Calculation module, used to calculate the prefix sum and the total number of candidate vertices; A partitioning module, configured to partition a calculation range according to the total number of candidate vertices; Screening module, used to screen candidate points and record the number of candidate points; The statistics module is used to count the results and generate a matching result array.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method according to any one of claims 1 to 6 when executing the computer program.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images