Data Prefetcher, Processor, and Device for Graph Computing

Abstract

The present invention discloses a data prefetcher, processor, and device for graph computing. The data prefetcher of the present invention includes a prefetch unit located between each processor core and its L2 cache L2. The prefetch unit includes: a configuration register group for storing data related to the graph computing data structure configured by software; a status register group for maintaining the intermediate index variables of the prefetch unit during the prefetch process; a control state machine for controlling the execution of the prefetch pipeline by reading the contents of the configuration register group and the status register group; a prefetch pipeline for executing each stage of the graph data access prefetch logic in a pipeline manner; and a data cache for storing data prefetched by the prefetch pipeline. The present invention aims to improve the timeliness and accuracy of prefetching for graph computing, thereby improving the efficiency of graph computing, alleviating the memory access bottleneck of graph computing, and improving the graph computing performance of the processor.

Description

Technical Field

[0001] The present invention relates to the field of processor technology, and in particular to a data prefetcher, processor and device oriented to graph computing. Background Art

[0002] Data prefetching is a technology that predicts memory access addresses before a user requests data, pre-fetching the data that may be needed and storing it in cache or temporary storage. This minimizes memory access latency and increases processor speed. Traditional data prefetching technologies predict future memory access addresses based on the application's memory access patterns. These technologies search for data from memory or lower-level caches based on the predicted addresses, ensuring that the corresponding data is already stored in the appropriate cache level when the memory access request arrives, thus reducing memory access latency. Data prefetching can be categorized as hardware prefetching or software prefetching based on its implementation.

[0003] The most common prefetcher for hardware prefetchers is the stride prefetcher design, which uses a fixed, repeatable address difference within a sequence. However, traditional data prefetchers such as GHB and AMPM typically perform prefetching by learning the stride history in the address stream, and therefore can only recognize streaming memory access patterns with deterministic regularity. To further capture indirect access data streams, Yu et al. proposed a hardware mechanism called IMP to support indirect data stream prefetching. This mechanism first identifies the sequential data stream and then uses this to identify indirect access patterns. However, these prefetchers struggle to fully capture the four-level indirect access pattern D[C[B[A[i]]+j]] in graph computation, where i is in [0,n-1] and j is in [B[A[i]],B[A[i]+1]]. Furthermore, due to the large amount of memory required to record the access history, the implementation overhead is high. Ainsworth proposed a graph-structure-aware data prefetcher. This prefetcher needs to monitor data requests to prefetch data from subsequent nodes, but requires special optimization for the prefetching timing. At the same time, since the data returned by the prefetch is stored in the L1 cache, special consideration needs to be given to the resource waste caused by replacement.

[0004] Software prefetching is achieved by programmers or compilers adding some prefetch instructions to the program. For example, Ainsworth proposed a compiler-based indirect mode prefetcher. They can usually capture memory access patterns more accurately. Software prefetching has inherent limitations: it may not be portable across microarchitectures (for example, with different cache hierarchies), resulting in significant instruction overhead and increased power consumption, which masks the advantage of improving cache hit rate.

[0005] Ideally, prefetching techniques would incur virtually no additional overhead for memory accesses. However, in practice, prefetching is not always timely or accurate, and delayed or erroneous prefetching can impact performance. Therefore, prefetching techniques must consider three fundamental issues: how to determine the data to prefetch, namely, its address; when to prefetch the data; and where to place the prefetched data. This design, tailored to the data access patterns of graph computations, accurately prefetches all relevant data, storing all prefetched data in a dedicated prefetch cache without causing cache contamination.

[0006] Graphs in real-world scenarios are very sparse. Most nodes have no edges connecting them, and a relatively small number of nodes in the graph structure are connected to a large number of nodes. Therefore, in order to improve the storage efficiency of graph data, the Compressed Sparse Row (CSR) format is usually used to store graph data, which has high time and space utilization. Figure 1 As shown in the figure, the compressed sparse row format uses four arrays to store graph data, where the offset array stores the offset value of the first outgoing edge of each node in the edge array, the edge array stores the IDs of all outgoing nodes in node order, the weight array stores the weights of the edges corresponding to the edge array, and the property data of the nodes related to graph calculation (such as V0 to V4) are stored in the property array.

[0007] Each update operation in a graph computation requires multiple memory accesses. Updating an outbound vertex requires accessing multiple data items, including the vertex ID, weight, and properties. However, computations often only involve reduction operations, which are computationally inefficient. Consequently, graph computing applications are memory-intensive when executed on general-purpose processor platforms, presenting three challenges: 1) Weak locality: Due to the complex and variable structure of graph data, the memory access behavior of programs exhibits low locality. Although a large amount of redundant structure has been found in real-world graph data, current graph computing applications still struggle to accurately predict the location of these redundant structures at runtime, limiting the optimization of data access locality. 2) High concurrency: The combination of the large number of data accesses generated by traversing vertex or edge data and simple reduction computations results in a large number of memory access requests within a short period of time, hindering the processor from obtaining the required data in a timely manner under high concurrency. 3) Fine-grained access: Computational operations in graph computing applications typically involve only a single vertex or edge attribute, which occupies a small amount of memory, resulting in fine-grained memory access behavior.

[0008] Traditional von Neumann general-purpose processor architectures use unified off-chip memory resources to store instructions and data. However, for memory-intensive applications, such as those in Figure 1, due to the large-scale, highly concurrent memory access requests, general-purpose processors based on the von Neumann architecture consume numerous idle wait cycles before obtaining the data required for computational instructions. This results in the instruction pipeline being unable to be fully filled with computational instructions, and thus, the ability to fully utilize instruction-level parallelism.

[0009] Pipeline blocking is the direct cause of processor performance degradation. The main conflicts that cause out-of-order superscalar processor blocking are resource-related, data-related, and control-related. By analyzing the proportion of pipeline blocking cycles caused by data-related, we can analyze the graph data access bottleneck. Figure 2 The figure shows the memory access instruction blocking cycle ratio obtained by executing the Single-Source Shortest Path (SSSP) algorithm on different data sets. Figure 2 As can be seen, load instructions account for an average of 38.02% of blocked cycles, while store instructions account for only 19.77%. This is primarily because load instructions are on the critical execution path, and subsequent computational instructions depend on their results. Therefore, optimizing load instructions has a greater impact on overall performance. The key to optimizing load instructions lies in data prefetching. As mentioned earlier, ideal prefetching techniques incur almost no additional overhead for memory accesses. However, in practice, prefetching is not always timely or accurate. Therefore, for data prefetchers for graph computations, alleviating the memory access bottleneck and improving the timeliness and accuracy of prefetching to enhance graph computation efficiency have become key technical challenges that need to be addressed. Summary of the Invention

[0010] Technical problem to be solved by the present invention: In response to the above-mentioned problems of the prior art, a data prefetcher, processor and device for graph computing are provided. The present invention aims to improve the timeliness and accuracy of prefetching for graph computing, so as to improve the efficiency of graph computing, alleviate the memory access bottleneck of graph computing, and improve the graph computing performance of the processor.

[0011] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0012] A data prefetcher for graph computing includes a prefetch unit located between each processor core and its L2 cache, the prefetch unit including:

[0013] Configuration register group, used to store data related to the graph computing data structure configured by the software, including array addresses related to the work queue and compressed sparse row format;

[0014] The status register group is used to maintain the intermediate index variables of the prefetch unit during the prefetch process and provide them to the control state machine to generate control signals, including the work queue index, the outbound offset index, and the data cache full flag;

[0015] A control state machine for controlling the execution of the prefetch pipeline by reading the contents of the configuration register group and the status register group, including pausing and resuming the prefetch pipeline;

[0016] The prefetch pipeline is used to execute the various stages of graph data access prefetch logic in a pipelined manner. The operations of each stage include calculating the prefetch address, sending the prefetch request, and receiving the prefetch data.

[0017] The data cache is used to store the data prefetched by the prefetch pipeline. The data cache maintains the prefetched data at the edge granularity. Each entry contains all the information related to the edge. The edge information is saved to the cache in the final stage of the pipeline.

[0018] Optionally, the various stages of executing graph data access prefetching logic in a pipeline manner include: stage 1, accessing the work queue listArray to prefetch the node n to be processed; stage 2, accessing the attribute array dataArray and the offset array offsetArray to prefetch the attributes and offsets of the source node; stage 3, accessing the edge array edgeArray and the weight array weightArray to prefetch the edge nodes and weights; stage 4, accessing the attribute array dataArray to prefetch the weight of the destination node.

[0019] Optionally, the array addresses related to the work queue and compressed sparse row format stored in the configuration register group include: the work queue starting address, the number of work queue elements, the offset data starting address, the edge array starting address, the edge weight array starting address and the attribute array starting address.

[0020] Optionally, the intermediate index variables in the status register group include the column index idx, the current column index current_idx, the current row start offset start, the current row end offset end and the data cache full flag full. The data cache full flag full is used as a credential for controlling the state machine to suspend and resume the prefetch pipeline. If the data cache full flag full is true, the prefetch pipeline is suspended, otherwise the prefetch pipeline is resumed.

[0021] Optionally, the fields of each data item in the data cache include a source node ID, a destination node ID, a source node attribute, a destination node attribute, and an outbound edge weight.

[0022] Optionally, the data prefetcher provides a configuration interface function config(addr, data), a data fetch interface function fetch_edge(), and a buffer empty state judgment interface function empty() for use by software, where addr is the address of the data prefetcher, data is the configuration data, and the software uses the data prefetcher in the following ways:

[0023] S1, configure the data prefetcher by calling the configuration interface function config(addr, data) through software. The configuration information includes the starting address and size of the offset array offsetArray, edge array edgeArray, weight array weightArray, and attribute array dataArray. The offset array offsetArray is used to record the starting offset and ending offset of the outgoing edge, the edge array edgeArray is used to record the ID of the outgoing edge node, the weight array weightArray is used to record the outgoing edge weight, and the attribute array dataArray is used to record the status data;

[0024] S2: Configure the starting address of the work queue listArray and the number of work queue elements len through software, so that the data prefetcher starts to prefetch the graph data related to all the nodes to be processed in the work queue listArray, the graph data including the source node ID, destination node ID, source node attributes, destination node attributes and outgoing edge weights, and stores the related graph data in the data cache;

[0025] S3, obtain the data in the data cache by calling the data interface function fetch_edge() through software;

[0026] S4, the software uses the pre-fetched data to perform the corresponding graph calculation and update the outgoing edge node attributes;

[0027] S5, calling the buffer empty status judgment interface function empty() by software to judge whether there is any data to be processed in the data cache of the data prefetcher, if there is any data to be processed, continue to execute step S3; otherwise, end and exit.

[0028] Optionally, in step S2, the data prefetcher starts prefetching graph data related to all nodes to be processed in the work queue listArray, including:

[0029] S2.1, get the starting address of the input work queue listArray and the number of work queue elements len; initialize the column index idx to 0;

[0030] S2.2, determine whether the column index idx is less than the number of work queue elements len. If not, then end; otherwise, jump to step S2.3;

[0031] S2.3, retrieve the index number i of the node to be processed corresponding to the column index idx from the work queue listArray; increment the column index idx by 1, and jump to step S2.3 until all the numbers of the nodes to be processed are generated;

[0032] S2.4. Pre-fetch the node attribute srcData of the node to be processed based on the starting address of the attribute array dataArray and the index number i of the node to be processed. Take the offset corresponding to the index number i of the node to be processed from the offset array offsetArray as the starting offset of the current row, start. Take the offset corresponding to the index number i+1 of the next node as the ending offset of the current row, end.

[0033] S2.5, assign the current row offset start to the current column index current_idx;

[0034] S2.6, determine whether the current column index current_idx is less than the current row end offset end. If not, jump to step S2.2; otherwise, jump to the next step;

[0035] S2.7, determine whether the data cache is full. If so, jump to step S2.7 again; otherwise, jump to the next step;

[0036] S2.8, extract the element corresponding to the current column index current_idx from the edge array edgeArray as the obtained outgoing node node corresponding to the node to be processed i, and extract the element corresponding to the current column index current_idx from the weight array weightArray as the obtained edge weight weight;

[0037] S2.9, read the attribute data of the outgoing node node corresponding to the node to be processed i from the attribute array dataArray according to the node node; add 1 to the current column index current_idx, and jump to step S2.6.

[0038] In addition, the present invention also provides a processor, including a processor body comprising a plurality of processor cores, wherein the processor body is provided with the graph-oriented computing data prefetcher.

[0039] In addition, the present invention also provides a computer device, comprising a processor and a memory connected to each other, wherein the processor is provided with any one of the graph-oriented computing data prefetchers.

[0040] Compared with the prior art, the present invention can mainly achieve the following beneficial effects: in order to alleviate the memory access bottleneck of graph computing, the data prefetcher of the present invention includes a prefetch unit located between each processor core and its L2 cache L2, and the prefetch unit includes: a configuration register group for storing data related to the graph computing data structure configured by the software; a status register group for maintaining the intermediate index variables of the prefetch unit during the prefetch process; a control state machine for controlling the execution of the prefetch pipeline by reading the contents of the configuration register group and the status register group; a prefetch pipeline for executing each stage of the graph data access prefetch logic in a pipeline manner; and a data cache for storing data prefetched by the prefetch pipeline. The present invention can improve the timeliness and accuracy of prefetching for graph computing, thereby improving the efficiency of graph computing, alleviating the memory access bottleneck of graph computing, and improving the graph computing performance of the processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 A schematic diagram of the Compressed Sparse Row (CSR) format in the prior art.

[0042] Figure 2 It is the proportion of memory access instruction blocking cycles of the single-source shortest path algorithm in the existing technology.

[0043] Figure 3 FIG. 4 is a flowchart of data access in an embodiment of the present invention.

[0044] Figure 4 Schematic diagram of the structure of a data prefetcher in an embodiment of the present invention.

[0045] Figure 5 Schematic diagram of the structure of the prefetch unit in the data prefetcher according to an embodiment of the present invention.

[0046] Figure 6 This is an overall execution flow chart of the collaboration mechanism in an embodiment of the present invention.

[0047] Figure 7 Schematic diagram of the working process of the data prefetcher in an embodiment of the present invention.

[0048] Figure 8 is the normalized execution time of different algorithms in the embodiments of the present invention.

[0049] Figure 9 It is the normalized proportion of memory access instruction blocking cycles of different algorithms in the embodiments of the present invention. DETAILED DESCRIPTION

[0050] In order to enable those skilled in the art to better understand the technical solution of the present invention, the technical solution of the present invention will be further described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0051] like Figure 3 As shown, the steps of graph data access targeted by the data prefetcher in this embodiment include: S101, initializing the column index idx to 0, and the number of work queue elements len to the size of the work queue listArray listArray.size(); S102, judging whether the column index idx is less than the number of work queue elements len, if not, ending; otherwise jumping to the next step; S103, taking out the node listArray[idx] corresponding to the column index idx from the work queue listArray as the node to be processed i, and adding 1 to the column index idx (idx+=1); S104, taking out the offset offsetArray[i] corresponding to the node to be processed i from the offset array offsetArray as the offset start of the current row, and the offset offsetArray[i] corresponding to the next node i+1 [i+1] is used as the end offset end of the current row; S105, the start offset start of the current row is assigned to the current column index current_idx; S106, whether the current column index current_idx is less than the end offset end of the current row is established, if not, jump to step S102; otherwise, jump to the next step; S107, take out the element edgeArray[current_idx] corresponding to the current column index current_idx from the edge array edgeArray as the obtained outgoing node node corresponding to the node i to be processed, and take out the element weightArray [current_idx] corresponding to the current column index current_idx from the weight array weightArray as the obtained edge weight weight; S108, read the attribute data dataArray[node] of the outgoing node node corresponding to the node i to be processed from the attribute array dataArray according to the node node; S109, add 1 to the current column index current_idx (current_idx+=1); jump to step S106.

[0052] In order to alleviate the memory bottleneck of graph computing, such as Figure 4 As shown, this embodiment provides a data prefetcher for graph computing, including a prefetch unit located between each processor core and its L2 cache. The prefetch unit is placed next to the L1 cache to reduce the latency of the processor accessing prefetched data. Figure 5 As shown, the prefetch unit includes:

[0053] Configuration register group, used to store data related to the graph computing data structure configured by the software, including array addresses related to the work queue and compressed sparse row format;

[0054] The status register group is used to maintain the intermediate index variables of the prefetch unit during the prefetch process and provide them to the control state machine to generate control signals, including the work queue index, the outbound offset index, and the data cache full flag;

[0055] A control state machine for controlling the execution of the prefetch pipeline by reading the contents of the configuration register group and the status register group, including pausing and resuming the prefetch pipeline;

[0056] The prefetch pipeline is used to execute the various stages of graph data access prefetch logic in a pipelined manner. The operations of each stage include calculating the prefetch address, sending the prefetch request, and receiving the prefetch data.

[0057] The data cache is used to store the data prefetched by the prefetch pipeline. The data cache maintains the prefetched data at the edge granularity. Each entry contains all the information related to the edge. The edge information is saved to the cache in the final stage of the pipeline.

[0058] like Figure 5 As shown, in this embodiment, the various stages of executing the graph data access prefetching logic in a pipeline manner include: stage 1, accessing the work queue listArray to prefetch the node n to be processed; stage 2, accessing the attribute array dataArray and the offset array offsetArray to prefetch the attributes and offsets of the source node; stage 3, accessing the edge array edgeArray and the weight array weightArray to prefetch the edge nodes and weights; stage 4, accessing the attribute array dataArray to prefetch the weight of the destination node.

[0059] like Figure 5 As shown, the array addresses related to the work queue and compressed sparse row format stored in the configuration register group in this embodiment include: the work queue starting address, the number of work queue elements, the offset data starting address, the edge array starting address, the edge weight array starting address and the attribute array starting address.

[0060] like Figure 5 As shown, the intermediate index variables in the status register group in this embodiment include the column index idx, the current column index current_idx, the current row start offset start, the current row end offset end and the data cache full flag full. The data cache full flag full is used as a credential for controlling the state machine to suspend and resume the prefetch pipeline. If the data cache full flag full is true, the prefetch pipeline is suspended, otherwise the prefetch pipeline is resumed.

[0061] like Figure 5As shown, in this embodiment, the fields of each data item in the data cache include a source node ID, a destination node ID, a source node attribute, a destination node attribute, and an outbound edge weight.

[0062] like Figure 6 As shown, the data prefetcher in this embodiment provides a configuration interface function config(addr, data), a data fetch interface function fetch_edge(), and a buffer empty state judgment interface function empty() for software use, where addr is the address of the data prefetcher, data is the configuration data, and the software uses the data prefetcher in the following ways:

[0063] S1, configure the data prefetcher by calling the configuration interface function config(addr, data) through software. The configuration information includes the starting address and size of the offset array offsetArray, edge array edgeArray, weight array weightArray, and attribute array dataArray. The offset array offsetArray is used to record the starting offset and ending offset of the outgoing edge, the edge array edgeArray is used to record the ID of the outgoing edge node, the weight array weightArray is used to record the outgoing edge weight, and the attribute array dataArray is used to record the status data;

[0064] S2: Configure the starting address of the work queue listArray and the number of work queue elements len through software, so that the data prefetcher starts to prefetch the graph data related to all the nodes to be processed in the work queue listArray, the graph data including the source node ID, destination node ID, source node attributes, destination node attributes and outgoing edge weights, and stores the related graph data in the data cache;

[0065] S3, obtain the data in the data cache by calling the data interface function fetch_edge() through software;

[0066] S4, the software uses the pre-fetched data to perform the corresponding graph calculation and update the outgoing edge node attributes;

[0067] S5, calling the buffer empty status judgment interface function empty() by software to judge whether there is any data to be processed in the data cache of the data prefetcher, if there is any data to be processed, continue to execute step S3; otherwise, end and exit.

[0068] like Figure 7 As shown, in step S2 of this embodiment, the data prefetcher starts to prefetch graph data related to all nodes to be processed in the work queue listArray, including:

[0069] S2.1, get the starting address of the input work queue listArray and the number of work queue elements len; initialize the column index idx to 0;

[0070] S2.2, determine whether the column index idx is less than the number of work queue elements len. If not, then end; otherwise, jump to step S2.3;

[0071] S2.3, retrieve the index number i of the node to be processed corresponding to the column index idx from the work queue listArray; increment the column index idx by 1, and jump to step S2.3 until all the numbers of the nodes to be processed are generated;

[0072] S2.4. Pre-fetch the node attribute srcData of the node to be processed based on the starting address of the attribute array dataArray and the index number i of the node to be processed. Take the offset corresponding to the index number i of the node to be processed from the offset array offsetArray as the starting offset of the current row, start. Take the offset corresponding to the index number i+1 of the next node as the ending offset of the current row, end.

[0073] S2.5, assign the current row offset start to the current column index current_idx;

[0074] S2.6, determine whether the current column index current_idx is less than the current row end offset end. If not, jump to step S2.2; otherwise, jump to the next step;

[0075] S2.7, determine whether the data cache is full. If so, jump to step S2.7 again; otherwise, jump to the next step;

[0076] S2.8, extract the element corresponding to the current column index current_idx from the edge array edgeArray as the obtained outgoing node node corresponding to the node to be processed i, and extract the element corresponding to the current column index current_idx from the weight array weightArray as the obtained edge weight weight;

[0077] S2.9, read the attribute data of the outgoing node node corresponding to the node to be processed i from the attribute array dataArray according to the node node; add 1 to the current column index current_idx, and jump to step S2.6.

[0078] To verify the performance of the data prefetcher for graph computing in this embodiment, a quad-core Skylake processor was used to evaluate the prefetcher on the ZSim simulator. The specific configuration is shown in Table 1. Six graph datasets were also tested, as shown in Table 2.

[0079] Table 1 Simulator parameter configuration

[0080]

[0081] Table 2 Graph dataset

[0082]

[0083] This example selected three graph datasets from different domains from the Stanford University Large-Scale Network Dataset Snap website: Email-Eu-core, Wiki-Vote, and Soc-Epinions. Each dataset exhibits typical characteristics and complexity within its respective domain, covering a wide range of application scenarios and usage conditions. Furthermore, three automatically generated random graph datasets of varying sizes, graph1 through graph3, were designed to simulate various unknown or future graph structures, further enhancing the generalizability and robustness of the experiment.

[0084] To evaluate the performance of the data prefetcher on different graph algorithms, this embodiment uses three graph algorithms: BFS (Bread First Search), SSSP (Single-Source Shortest Path), and SSWP (Single-Source Widest Path). The BFS algorithm traverses a graph to obtain the depth of all nodes from the origin. It can be used for friendship and community discovery in social network analysis, as well as state space search and network link analysis in artificial intelligence. The SSSP algorithm is used to search for single-source shortest paths in a graph. In network routing, it analyzes the topology to obtain the shortest path from one node to other nodes, thereby achieving efficient network routing and data transmission. In social network analysis, this algorithm obtains the shortest path from one node to other nodes, enabling relationship analysis and influence assessment in social networks. The SSWP algorithm is used to find the single-source widest path. In network communications, the widest path refers to the path with the maximum bandwidth in the network and can be used to search for the path with the maximum bandwidth between two nodes. In traffic planning, the widest path refers to the maximum capacity of a road and can be used to search for the path with the maximum capacity between two locations.

[0085] Figure 8The figure shows the normalized execution time of the three algorithms on different data sets, normalized to the baseline system without the data prefetcher. The smaller the time, the higher the performance. It can be seen that the data prefetcher in this embodiment can improve the performance of the BFS algorithm, SSSP algorithm, and SSWP algorithm by an average of 31%, 41%, and 36%, respectively. At the same time, Figure 9 The figure shows the normalized percentage of memory access instruction block cycles for the three algorithms on different data sets. Normalized to a baseline system without an integrated prefetcher, smaller values indicate higher performance. All three algorithms show a significant reduction in the percentage of memory access instruction block cycles, with average reductions of 95%, 66%, and 43% for the BFS, SSSP, and SSWP algorithms, respectively. This demonstrates that graph data access in graph computing significantly blocks pipeline execution, impacting overall performance. Furthermore, graph computing's data access patterns are relatively fixed, allowing for the design of dedicated data prefetchers tailored to these access patterns. Compared to previous general data prefetching techniques, the graph-based data prefetcher in this embodiment achieves superior prefetching performance due to its tailored design for graph data access and customized prefetching scheme. This embodiment addresses the shortcomings of existing data prefetching mechanisms and offers a customized design based on three key aspects of data prefetching. By combining software configuration with hardware prefetching, it can be flexibly integrated into existing graph computing frameworks, achieving user transparency. Existing graph computing is typically developed using existing frameworks. This embodiment improves the efficiency of hardware prefetching by adding software configuration without changing existing usage. Experiments on various algorithms and datasets show that the graph computing-oriented data prefetcher in this embodiment can improve the performance of the BFS algorithm, SSSP algorithm, and SSWP algorithm by an average of 31%, 41%, and 36%, respectively.

[0086] In addition, this embodiment further provides a processor including a processor body having multiple processor cores, wherein the processor body is provided with the graph computing-oriented data prefetcher. The processor can be either a general-purpose processor or an accelerated processor for graph computing.

[0087] In addition, this embodiment also provides a computer device, including a processor and a memory connected to each other, wherein the processor is provided with the graph-oriented computing data prefetcher. The computer device can be either a general-purpose computer device or a special-purpose computer device for graph computing.

[0088] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiment. All technical solutions based on the concept of the present invention are within the scope of protection of the present invention. It should be noted that for those skilled in the art, various improvements and modifications that do not depart from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A data prefetcher for graph computing, characterized in that: The prefetch unit includes a prefetch unit located between each processor core and its L2 cache, and the prefetch unit includes: Configuration register group, used to store data related to the graph computing data structure configured by the software, including array addresses related to the work queue and compressed sparse row format; A status register group is used to maintain the intermediate index variables of the prefetch unit during the prefetch process and provide them to the control state machine to generate control signals. The intermediate index variables include the work queue index, the outbound offset index, and the data cache full flag; A control state machine for controlling the execution of the prefetch pipeline by reading the contents of the configuration register group and the status register group, including pausing and resuming the prefetch pipeline; The prefetch pipeline is used to execute the various stages of graph data access prefetch logic in a pipelined manner. The operations of each stage include calculating the prefetch address, sending the prefetch request, and receiving the prefetch data. The data cache is used to store data prefetched by the prefetch pipeline. The data cache maintains prefetched data at the edge granularity. Each entry contains all information related to the edge. The edge information is saved to the cache at the final stage of the pipeline. The various stages of executing graph data access prefetching logic in a pipeline manner include: stage 1, accessing the work queue listArray to prefetch the node n to be processed; stage 2, accessing the attribute array dataArray and the offset array offsetArray to prefetch the attributes and offsets of the source node; stage 3, accessing the edge array edgeArray and the weight array weightArray to prefetch the edge nodes and weights; stage 4, accessing the attribute array dataArray to prefetch the attribute data of the destination node.

2. The data prefetcher for graph computing according to claim 1, characterized in that: The array addresses related to the work queue and compressed sparse row format stored in the configuration register group include: the work queue starting address, the number of work queue elements, the offset data starting address, the edge array starting address, the edge weight array starting address and the attribute array starting address.

3. The data prefetcher for graph computing according to claim 2, characterized in that: The work queue index, outbound offset index and data cache full flag include column index idx, current column index current_idx, current row start offset start, current row end offset end and data cache full flag full. The data cache full flag full is used as a credential for controlling the state machine to pause and resume the prefetch pipeline. If the data cache full flag full is true, the prefetch pipeline is paused, otherwise the prefetch pipeline is resumed.

4. The data prefetcher for graph computing according to claim 3, characterized in that The fields of each data item in the data cache include a source node ID, a destination node ID, a source node attribute, a destination node attribute, and an outbound edge weight.

5. The data prefetcher for graph computing according to claim 4, characterized in that The data prefetcher provides a configuration interface function config(addr, data), a data fetch interface function fetch_edge(), and a buffer empty state judgment interface function empty() for software use, where addr is the address of the data prefetcher, data is the configuration data, and the software uses the data prefetcher in the following ways: S1, configure the data prefetcher by calling the configuration interface function config(addr, data) through software. The configuration information includes the starting address and size of the offset array offsetArray, the edge array edgeArray, the weight array weightArray and the attribute array dataArray. The offset array offsetArray is used to record the starting offset and ending offset of the outgoing edge, the edge array edgeArray is used to record the id of the outgoing edge node, the weight array weightArray is used to record the outgoing edge weight, and the attribute array dataArray is used to record the attribute data; S2: Configure the starting address of the work queue listArray and the number of work queue elements len through software, so that the data prefetcher starts to prefetch the graph data related to all the nodes to be processed in the work queue listArray, the graph data including the source node ID, destination node ID, source node attributes, destination node attributes and outgoing edge weights, and stores the related graph data in the data cache; S3, obtain the data in the data cache by calling the data interface function fetch_edge() through software; S4, the software uses the pre-fetched data to perform the corresponding graph calculation and update the outgoing edge node attributes; S5, calling the buffer empty status judgment interface function empty() by software to judge whether there is any data to be processed in the data cache of the data prefetcher, if there is any data to be processed, continue to execute step S3; otherwise, end and exit.

6. The data prefetcher for graph computing according to claim 5, characterized in that: In step S2, the data prefetcher starts to prefetch the graph data related to all the nodes to be processed in the work queue listArray, including: S2.1, get the starting address of the input work queue listArray and the number of work queue elements len; initialize the column index idx to 0; S2.2, determine whether the column index idx is less than the number of work queue elements len. If not, then end; otherwise, jump to step S2.3; S2.3, retrieve the index number i of the node to be processed corresponding to the column index idx from the work queue listArray; increment the column index idx by 1, and jump to step S2.3 until all the numbers of the nodes to be processed are generated; S2.

4. Pre-fetch the node attribute srcData of the node to be processed based on the starting address of the attribute array dataArray and the index number i of the node to be processed. Take the offset corresponding to the index number i of the node to be processed from the offset array offsetArray as the starting offset of the current row, start. Take the offset corresponding to the index number i+1 of the next node as the ending offset of the current row, end. S2.5, assign the current row offset start to the current column index current_idx; S2.6, determine whether the current column index current_idx is less than the current row end offset end. If not, jump to step S2.2; otherwise, jump to the next step; S2.7, determine whether the data cache is full. If not, jump to step S2.7 again; otherwise, jump to the next step; S2.8, extract the element corresponding to the current column index current_idx from the edge array edgeArray as the obtained outgoing node node corresponding to the node to be processed i, and extract the element corresponding to the current column index current_idx from the weight array weightArray as the obtained edge weight weight; S2.9, read the attribute data of the outgoing node node corresponding to the node to be processed i from the attribute array dataArray according to the node node; add 1 to the current column index current_idx, and jump to step S2.

6.

7. A processor comprising a processor body having multiple processor cores, characterized in that: The processor body is provided with a data prefetcher for graph computing according to any one of claims 1 to 6.

8. A computer device comprising a processor and a memory connected to each other, characterized in that: The processor is provided with a data prefetcher for graph-oriented computing as claimed in any one of claims 1 to 6.

Images