Hierarchical compilation performance prediction method and apparatus for reconfigurable spatial accelerator

Abstract

This invention discloses a hierarchical compilation performance prediction method and apparatus for reconfigurable space accelerators, relating to the field of data processing technology. The method includes obtaining candidate compilation schemes generated by a search algorithm of the upper-layer compilation, and extracting features from the candidate compilation schemes to obtain the software graph topology and target hardware array information corresponding to the candidate compilation schemes; determining the current compilation scenario based on the software graph topology; invoking a performance prediction model pre-integrated in the lower-layer mapping based on the current compilation scenario; and determining the predicted mapping performance of the candidate compilation scheme in the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model. This technical solution can quickly predict the performance of candidate compilation schemes without performing actual lower-layer compilation, thereby guiding the compiler to make globally optimal decisions.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a method and apparatus for predicting the performance of hierarchical compilation for reconfigurable space accelerators. Background Technology

[0002] As the scale and complexity of computing tasks continue to grow, reconfigurable spatial accelerators (RSAs) have become important hardware platforms in fields such as artificial intelligence and high-performance computing due to their high parallel computing capabilities, high flexibility, and high energy efficiency. RSAs typically adopt a layered hardware architecture design, and their compilation process must also follow the layered principle, transforming the program into a layered graphical intermediate representation (IRs), and performing operation layout, routing planning, and scheduling mapping from top to bottom.

[0003] However, existing layered compilation methods have inherent flaws: upper-level compilers cannot predict the quality of lower-level mappings for all possible layouts, thus failing to accurately assess the performance of their own mappings. This leads to suboptimal compilation decisions and ultimately, a decline in overall performance. To address this issue, a high-performance cost model system needs to be built, enabling upper-level compilers to quickly and accurately predict the performance of lower-level mappings, achieving inter-layer awareness.

[0004] Existing cost models generally suffer from problems such as low prediction accuracy, lack of architectural generalization, high cost of training data acquisition, and lack of support for multi-objective optimization. Specifically, traditional formulaic cost models, such as those based on the assumption of uniform operation distribution, have extremely low prediction accuracy and cannot distinguish the performance differences between different mapping schemes; existing deep learning-based cost models are mostly designed for specific hardware architectures and are difficult to migrate to different RSA architectures; generating sufficient training data requires a large amount of actual compilation processes and incurs huge time costs. Summary of the Invention

[0005] To address at least one of the technical problems mentioned in the background section, this application provides a method and apparatus for predicting the performance of layered compilation for reconfigurable space accelerators. This method and apparatus can quickly predict the performance of candidate compilation schemes without performing actual lower-level compilation, thereby guiding the compiler to make globally optimal decisions.

[0006] In a first aspect, embodiments of the present invention provide a hierarchical compilation performance prediction method for reconfigurable space accelerators, the method comprising: Candidate compilation schemes generated by the search algorithm of the upper layer are obtained, and feature extraction is performed on the candidate compilation schemes to obtain the software graph topology and target hardware array information corresponding to the candidate compilation schemes; Based on the software graph topology, determine the current compilation scenario; Based on the current compilation scenario, the performance prediction model pre-integrated in the lower-level mapping is invoked; Based on the software graph topology, the target hardware array information, and the performance prediction model, the predicted mapping performance of the candidate compilation scheme at the lower layer is determined.

[0007] In some alternative embodiments of this example, the software graph topology is represented by an attribute graph. It means that, among them, It is a set of nodes, where each node represents a basic operation; The set of edges represents the data or control dependencies between operations; For each node, there is a collection of node attributes. It is encoded into a feature vector, which includes, but is not limited to: operation type identifier, in-degree, out-degree, number of load instructions, number of store instructions, estimated execution latency cycles, function code, and input operand features; The target hardware array information is represented by an attribute graph. It means that, among them, A set of nodes, representing reconfigurable processing units, memory interfaces, or preset functional units; This is a set of edges, representing interconnection links or communication channels between units; It is a set of attributes that describe the computing power, storage bandwidth, interconnect latency, and configurability of each hardware node.

[0008] In some optional embodiments of this example, the software graph topology includes multiple software nodes, and determining the current compilation scenario based on the software graph topology includes: Determine whether there are circular dependencies at the software node level in the software graph topology; If it exists, the current compilation scenario is determined to be a latency-oriented scenario; If it does not exist, the current compilation scenario is determined to be a throughput-oriented scenario.

[0009] In some optional embodiments of this example, the step of invoking a performance prediction model pre-integrated in the underlying mapping according to the current compilation scenario includes: In response to determining that the current compilation scenario is a latency-oriented scenario, the latency-oriented performance prediction sub-model pre-integrated in the underlying mapping is invoked; In response to determining that the current compilation scenario is a throughput-oriented scenario, the throughput-oriented performance prediction sub-model pre-integrated in the underlying mapping is invoked.

[0010] In some optional embodiments of this example, determining the prediction mapping performance of the candidate compilation scheme at the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model includes: Based on the software graph topology, determine the critical and non-critical paths of the software nodes; Based on the target hardware array information, determine the critical path and non-critical path of the hardware array; The latency-oriented performance prediction sub-model is configured as follows: The sum of the operation execution time of the critical path of the software node and the channel transmission time of the critical path of the hardware array is calculated as the first critical path delay estimate. The sum of the operation execution time of the non-critical path of the software node and the channel transmission time of the non-critical path of the hardware array is calculated as the second critical path delay estimate. The sum of the first critical path delay estimate and the second critical path delay estimate is output as the prediction mapping performance of the candidate compilation scheme at the lower layer.

[0011] In some optional embodiments of this example, determining the prediction mapping performance of the candidate compilation scheme at the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model includes: Using the software graph topology and the target hardware array information as input, and based on the pre-trained throughput-oriented performance prediction sub-model, the optimal startup interval is output as the predicted mapping performance of the candidate compilation scheme at the lower layer.

[0012] In some optional embodiments of this example, the step of training the throughput-oriented performance prediction sub-model includes: Graph neural networks are constructed by alternately stacking graph convolutional layers (GCN) and graph attention layers (GAT). A basic training set is constructed, and redundancy injection and subgraph extraction operations are performed on the basic dataset to obtain an extended dataset; Based on the extended dataset, pre-training and fine-tuning operations are performed on the graph neural network until the trained throughput-oriented performance prediction sub-model is obtained.

[0013] In some optional embodiments of this example, the network architecture of the graph neural network consists of three stages, wherein: In the first stage, the input is in the form of an N×8 node feature matrix, which enters the GNN body and is extracted by multiple layers of alternating stacked GCN and GAT layers to obtain an N×32 latent vector representation. In the second stage, mean pooling is performed on all node representations to form graph-level embeddings; In the third stage, the graph-level embedding is mapped to the final optimal start interval prediction value through a multilayer perceptron.

[0014] In some optional embodiments of this example, the steps of the redundant injection operation include: Given an original feasible sample and its complete mapping result on the modulo routing resource graph, extract the set of idle hardware processing units and the set of idle hardware connections from the complete mapping result; Based on the topological connections of the set of idle hardware processing units and the set of idle hardware connections, a set of candidate redundant segments is constructed to obtain a redundant injection dataset. Each candidate redundant segment includes a set of redundant software operations to be injected, a set of redundant software edges to be injected, and a predetermined mapping from the redundant segment to idle hardware resources.

[0015] In some optional embodiments of this example, the steps of the subgraph extraction operation include: Given an original feasible sample and its complete mapping result on the modulo routing resource graph, extract the operation subset and its corresponding initiation interval from the complete mapping result to obtain the subgraph dataset; Based on the launch interval and the number of operations of the subgraph, the mapping feasibility of the subgraph under different launch intervals is assigned a label, wherein the label includes 0, 1 and unknown, and the subgraph with the label unknown is directly discarded.

[0016] In some optional embodiments of this example, the pre-training operation includes the following steps: Replace the regression layer of the graph neural network with a binary classification layer, use subgraph extracted data for training, and determine whether the software graph, hardware architecture and triples with a given initial interval in the subgraph dataset can be mapped. If they can, output 1; otherwise, output 0.

[0017] In some optional embodiments of this example, the steps of the fine-tuning training operation include: All weight parameters in the graph neural network obtained after the pre-training operation, except for the classification layer, are used as initial weights, and the binary classification layer is restored to the regression layer. The graph neural network is trained using the base dataset and the redundant injection dataset.

[0018] In a second aspect, embodiments of the present invention also provide a hierarchical compilation performance prediction device for a reconfigurable space accelerator, comprising: The feature extraction module is configured to obtain candidate compilation schemes generated by the search algorithm compiled by the upper layer, and to extract features from the candidate compilation schemes to obtain the software graph topology and target hardware array information corresponding to the candidate compilation schemes. The compilation scenario determination module is configured to determine the current compilation scenario based on the software graph topology. The model invocation module is configured to invoke a performance prediction model pre-integrated in the lower-level mapping, based on the current compilation scenario. The performance prediction module is configured to determine the prediction mapping performance of the candidate compilation scheme at the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model.

[0019] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the hierarchical compilation performance prediction method for reconfigurable space accelerators described in the first aspect.

[0020] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the hierarchical compilation performance prediction method for reconfigurable space accelerators described in the first aspect.

[0021] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the hierarchical compilation performance prediction method for reconfigurable space accelerators described in the first aspect.

[0022] This invention provides a hierarchical compilation performance prediction method and apparatus for reconfigurable space accelerators. Based on a performance prediction model integrated into a hierarchical compilation framework, it establishes an inter-layer awareness mechanism to quickly predict the performance of candidate solutions without executing actual lower-level compilation. This allows the upper-level compiler to accurately and quickly predict the final throughput, latency, and other performance consequences of different compilation decisions before executing actual lower-level requirements, thereby guiding the compiler to make globally optimal decisions and improving overall compilation quality and system performance. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art 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. In the drawings: Figure 1 This is one of the flowcharts illustrating the hierarchical compilation performance prediction method for reconfigurable space accelerators in an embodiment of the present invention; Figure 2 This is a schematic diagram of the overall framework of the performance prediction model in this embodiment of the invention; Figure 3This is a second schematic flowchart of the hierarchical compilation performance prediction method for reconfigurable space accelerators in an embodiment of the present invention; Figure 4 This is a schematic diagram of the graph neural network architecture of the throughput-oriented performance prediction sub-model in an embodiment of the present invention; Figure 5 This is one of the schematic diagrams of redundant injection in an embodiment of the present invention; Figure 6 This is one of the schematic diagrams of subgraph extraction in an embodiment of the present invention; Figure 7 This is a schematic diagram of the pre-training operation in an embodiment of the present invention; Figure 8 This is a schematic diagram of the numbering of the PE array in an embodiment of the present invention; Figure 9 This is the second schematic diagram of redundant injection operation in an embodiment of the present invention; Figure 10 This is a second schematic diagram of the subgraph extraction operation in an embodiment of the present invention; Figure 11 This is a schematic diagram of the structure used for hierarchical compilation performance prediction of reconfigurable space accelerators in an embodiment of the present invention; Figure 12 This is a schematic diagram of the structure of an electronic device in an embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0025] The information collected in the technical solution of this application is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation portals are provided for users to choose to authorize or refuse.

[0026] The acquisition, transmission, storage, use, and processing of data in this application comply with relevant national laws and regulations. It should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0027] The following is a description of the abbreviations used in this application: RSAs: reconfigurable spatial accelerators; IRs: intermediate representations; GNN: graph neural network; TPU: tensor processing unit; GPU: graphics processing unit; MLP: multilayer perceptron; MRRG: modulo routing resource graph; II: initial interval; MII: minimal initial interval; GAT: graph attention networks; GraphConv: graph convolutional layer; GeLU: Gaussian error linear unit; OP: operation.

[0028] Reconfigurable spatial architectures typically employ a layered hardware organization, with the upper layer connecting multiple hardware PE arrays via on-chip networks, and the lower layer consisting of the placement and routing within each array. During layered compilation, the upper-layer search needs to evaluate the mapping performance of each candidate partitioning scheme in the lower layer, but directly calling the lower-layer compiler is prohibitively expensive. Therefore, a lightweight performance prediction model is needed to quickly predict the performance of candidate schemes without performing actual lower-layer compilation.

[0029] The most direct inter-layer awareness approach in existing layered compilation frameworks is to actually call the lower-level compiler once for each upper-level candidate solution to obtain the true mapping results and performance metrics. However, since the underlying scheduling, placement, and routing are essentially highly complex graph mapping problems, frequently executing full compilations incurs unacceptable time overhead. Traditional analytical methods typically rely on relatively coarse heuristics, often only able to estimate throughput performance based on simple statistics such as the balance of the number of operations; and formulaic performance prediction models directly ported to reconfigurable space accelerator architectures often suffer from insufficient accuracy.

[0030] Existing RSA compilation cost models are mainly divided into three categories: (1) Formulaic analysis model These models are built upon simplified heuristics or closed-form mathematical expressions. Their core idea is to reduce the complex performance prediction problem to a function of one or a few easily computable key parameters. Common rules include distributing operations as evenly as possible across all available hardware units to balance the load, or minimizing communication between different computational partitions to reduce data transfer overhead. The advantage of these models lies in their extremely high computational efficiency, typically completing evaluations within microseconds, and supporting search algorithms that require frequent calls in compilers. However, their fundamental flaw is oversimplification: the model cannot characterize the complex spatiotemporal constraints, resource contention, and dynamic interactions of the underlying hardware when executing a specific software graph. For example, it cannot distinguish the performance differences between two software graphs with the same number of operations but vastly different dependency patterns mapped onto the same hardware. Therefore, their prediction accuracy is extremely low. In real-world applications with complex control flow or dense data dependencies, compilation decisions based on such models often deviate significantly from the optimal solution, leading to severe performance degradation and throughput losses of up to several times.

[0031] (2) Models based on traditional machine learning

[0032] To improve prediction accuracy, these methods incorporate statistical learning techniques. The process involves domain experts manually designing and extracting a set of features that attempt to describe the structural properties of the software graph and the static parameters of the hardware configuration. These feature vectors are then used in conjunction with regression or classification algorithms for training. Compared to formulaic models, these methods, through data-driven approaches, capture some nonlinear relationships to a certain extent, thus improving prediction accuracy. However, their bottleneck lies in feature engineering: model performance is highly dependent on the completeness and effectiveness of feature design, a time-consuming and labor-intensive process requiring deep domain knowledge. More importantly, when the target hardware architecture changes, including changes in the number of processing units, interconnect topology, or storage hierarchy, the originally designed feature set may become invalid or lose its discriminative power, severely limiting the model's generalization ability. For almost every new architecture, feature design and model adjustments need to be completely redesigned, resulting in high migration and maintenance costs.

[0033] (3) Deep learning-based models

[0034] In recent years, with the development of deep learning, especially the success of graph neural networks in modeling graph-structured data, models using architectures such as GNNs for performance prediction have emerged. In fields such as computer-aided design and automatic tuning of high-performance libraries, these models have been used to predict the latency of tensor programs or evaluate the design point of specific accelerators (such as TPUs and GPUs). They can learn the mapping from intermediate representations of programs / hardware to performance metrics end-to-end, avoiding tedious manual feature engineering. However, directly applying them to RSA compilation scenarios faces significant mismatch problems: First, excessive domain specificity: most existing models are optimized for scenarios with relatively regular computational patterns and fixed hardware architectures, while RSA targets a wide range of domains with diverse program control flows and a huge hardware design space, resulting in a lack of necessary generality in model architecture. Second, missing key technical components: existing models lack dedicated designs for the core challenges of RSA compilation. For example, they lack integrated, sophisticated circular dependency analysis mechanisms to distinguish between different modes of latency optimization and throughput optimization; they also lack efficient and low-cost methodologies for generating large-scale training data, making it difficult to cope with the data scarcity problem caused by the diversity of RSA target hardware.

[0035] In view of this, one embodiment of this application provides a hierarchical compilation performance prediction method for reconfigurable space accelerators, such as... Figure 1 As shown, it includes: Step 10: Obtain candidate compilation schemes generated by the search algorithm of the upper layer compilation, and extract features from the candidate compilation schemes to obtain the software graph topology and target hardware array information corresponding to the candidate compilation schemes.

[0036] Step 20: Determine the current compilation scenario based on the software graph topology.

[0037] Step 30: Based on the current compilation scenario, invoke the performance prediction model pre-integrated in the lower-level mapping.

[0038] Step 40: Based on the software graph topology, the target hardware array information, and the performance prediction model, determine the prediction mapping performance of the candidate compilation scheme at the lower layer.

[0039] This invention provides a hierarchical compilation performance prediction method for reconfigurable space accelerators. Based on a performance prediction model integrated into a hierarchical compilation framework, it establishes an inter-layer awareness mechanism to quickly predict the performance of candidate solutions without executing the actual lower-level compilation. This allows the upper-level compiler to accurately and quickly predict the final throughput, latency, and other performance consequences of different compilation decisions before executing the actual lower-level requirements, thereby guiding the compiler to make globally optimal decisions and improving overall compilation quality and system performance.

[0040] Next Figure 1 The steps are described in detail below: Step S10: Obtain candidate compilation schemes generated by the search algorithm of the upper layer compilation, and extract features from the candidate compilation schemes to obtain the software graph topology and target hardware array information corresponding to the candidate compilation schemes.

[0041] The software graph topology uses an attribute graph. It means that, among them, It is a set of nodes, where each node represents a basic operation; The set of edges represents the data or control dependencies between operations; For each node, there is a collection of node attributes. Encoded as a feature vector, the feature vector includes, but is not limited to: operation type identifier, in-degree, out-degree, number of load instructions, number of store instructions, estimated execution latency cycles, function encoding, and input operand characteristics; the target hardware array information is represented by an attribute graph. It means that, among them, A set of nodes, representing reconfigurable processing units, memory interfaces, or preset functional units; This is a set of edges, representing interconnection links or communication channels between units; It is a set of attributes that describe the computing power, storage bandwidth, interconnect latency, and configurability of each hardware node.

[0042] Step S20: Determine the current compilation scenario based on the software graph topology.

[0043] The design of performance prediction models faces constraints in three aspects: accuracy, latency, and generality. Regarding accuracy, the upper-layer search process is highly dependent on the evaluation results, especially in throughput scenarios. Even a small deviation from the prediction error by a small startup interval can lead to a significant decrease in overall pipeline throughput. In terms of latency, the performance prediction model is repeatedly invoked during the search phase, and excessive inference latency will negate the efficiency advantages of layered compilation itself. Regarding generality, the hardware resources and interconnection forms of the underlying arrays in reconfigurable spatial architectures differ significantly, requiring performance prediction models to be adapted to different hardware array configurations. It is worth noting that latency and throughput have fundamentally different formation mechanisms: when the inner loop carries dependencies, it is difficult to achieve sufficient parallelism between different iterations, and the compilation target shifts to the completion time of a single iteration; however, when such dependencies do not exist, iterations can be continuously launched in a pipelined manner, and the compilation target shifts to steady-state throughput, with the startup interval II as the primary performance indicator.

[0044] Therefore, it is necessary to determine the current compilation scenario based on the software graph topology, where the software graph topology includes multiple software nodes. In some optional embodiments of this example, step 20 includes: Determine whether there are circular dependencies at the software node level in the software graph topology; If it exists, the current compilation scenario is determined to be a latency-oriented scenario; If it does not exist, the current compilation scenario is determined to be a throughput-oriented scenario.

[0045] It's important to note that when there are circular dependencies at the software node level, simply allocating more hardware arrays does not improve the performance of the inner loop. This is because the next iteration must wait for the critical results of the current iteration to be generated before it can start. Upper-level searches need to prioritize determining the optimal mapping scheme for the innermost loop, using cumulative path latency as the primary evaluation metric. However, in the absence of circular dependencies, the inner loop can achieve higher parallelism through loop unrolling and additional array allocation. The overall system performance is determined by the slowest array stage on the execution path. Upper-level searches are more suitable for a throughput-oriented approach, using the startup interval as the primary evaluation metric.

[0046] Step S30: Based on the current compilation scenario, call the performance prediction model pre-integrated in the lower-level mapping.

[0047] like Figure 2 As shown, the performance prediction model is a system comprising two types of specialized sub-models, used to provide performance predictions for the hierarchical compilation of reconfigurable space accelerators. The system includes a latency-oriented analytical prediction model (i.e., a latency-oriented cost model) and a throughput-oriented data-driven prediction model (i.e., a throughput-oriented cost model). The latency-oriented analytical prediction model is a deterministic computational model based on critical path analysis. It directly calculates the predicted latency value by extracting and analyzing the most critical execution and communication paths in the software graph and hardware architecture, without iterative training. The throughput-oriented data-driven prediction model is a machine learning model based on graph neural networks. It learns the complex mapping relationship from the graph structure features of the software graph and hardware architecture to the optimal initial interval through offline training, and performs fast online inference and prediction. This model adopts a lightweight architecture with alternating stacked graph convolutional layers and graph attention layers. The software graph to be mapped refers to the program or program fragment to be accelerated, represented by a graph structure, generated during the compilation process, and is called a software node.

[0048] The predicted performance metrics refer to the quantitative values ​​that the model outputs based on the input software graph and hardware architecture, representing the expected performance after mapping. These include the time or number of clock cycles (latency) required to complete a single iteration of the computational task represented in the software graph in scenarios with cyclic dependencies, and the minimum interval (throughput) between adjacent iterations during pipelined execution in scenarios without cyclic dependencies.

[0049] In this step, after determining the current compilation scenario, it is necessary to call the performance prediction model pre-integrated in the lower layer mapping. Specifically, in response to determining that the current compilation scenario is a latency-oriented scenario, the latency-oriented performance prediction sub-model pre-integrated in the lower layer mapping is called; in response to determining that the current compilation scenario is a throughput-oriented scenario, the throughput-oriented performance prediction sub-model pre-integrated in the lower layer mapping is called.

[0050] Step S40: Based on the software graph topology, the target hardware array information, and the performance prediction model, determine the prediction mapping performance of the candidate compilation scheme at the lower layer.

[0051] In some optional modes of this embodiment, when the current compilation scenario is a latency-oriented scenario, such as Figure 3 As shown, step S40 includes: Step S401: Based on the software graph topology, determine the critical paths and non-critical paths of the software nodes; Step S402: Determine the critical path and non-critical path of the hardware array based on the target hardware array information; Wherein: the latency-oriented performance prediction sub-model is configured as follows: The sum of the operation execution time of the critical path of the software node and the channel transmission time of the critical path of the hardware array is calculated as the first critical path delay estimate. The sum of the operation execution time of the non-critical path of the software node and the channel transmission time of the non-critical path of the hardware array is calculated as the second critical path delay estimate. The sum of the first critical path delay estimate and the second critical path delay estimate is output as the prediction mapping performance of the candidate compilation scheme at the lower layer.

[0052] Specifically, the performance prediction sub-model for phase delay (the cost model for delay) is as follows: Figure 2As shown, the basic premise is that, under the goal of minimizing total latency, the compiler tends to map the critical path of a software node—that is, the software operation chain with the longest execution time—to the critical path of the hardware array—that is, the hardware path chain with the minimum cumulative channel latency. Based on this assumption, the sum of the operation execution time and channel transmission time on the critical path can be directly calculated without actually performing a complete placement and routing, thus obtaining the critical path critical value (CoC) latency estimate. However, considering only the first critical path is insufficient to accurately reflect the overall latency, because after the critical path is preferentially mapped, non-critical paths may be forced to occupy longer hardware communication paths, and their latency increase may even offset the benefits brought by critical path optimization. To this end, this application further introduces a second critical path critical value mechanism, which considers the second critical path of both the software graph and the hardware graph in the lower-level estimation stage, and uses the average latency of both CoC and 2CoC as the final prediction result. This not only retains the interpretability and low overhead of the analytical model, but also corrects the systematic bias of single-path estimation to a certain extent.

[0053] In some optional embodiments of this example, when the current compilation scenario is a throughput wire scenario, step S40 includes: Using the software graph topology and the target hardware array information as input, and based on the pre-trained throughput-oriented performance prediction sub-model, the optimal startup interval is output as the predicted mapping performance of the candidate compilation scheme at the lower layer.

[0054] Specifically, this application addresses throughput-oriented scenarios by designing a lightweight graph neural network model. Throughput prediction is extremely sensitive to errors; even small II prediction biases can be amplified into significant overall performance degradation in upper-layer searches. Factors affecting throughput involve complex interactions between software graph topology and hardware mapping constraints, which are difficult to accurately characterize using analytical rules. Graph neural networks are well-suited for handling such graph-structured inputs, extracting structural features related to the optimal startup interval from node relationships and local topology. Furthermore, runtime factors such as NoC dynamic blocking have a relatively weak impact on throughput scenarios; system throughput is typically determined by computationally limited hardware arrays, making predictions based on static graph structures more reliable. Therefore, in the dual-path framework, the latency path is modeled analytically, while the throughput path uses a GNN for optimal startup interval prediction.

[0055] In some optional embodiments of this example, the step of training the throughput-oriented performance prediction sub-model includes: Step S1: Alternately stack graph convolutional layers (GCN) and graph attention layers (GAT) to construct a graph neural network.

[0056] As mentioned above, the throughput guidance path uses a graph neural network to predict the optimal initiation interval (OII). The input representation and network structure of this model will be introduced next.

[0057] The input to a graph neural network consists of two parts: node features and graph topology. For example... Figure 4 As shown, each software operation in a software node is encoded as a node feature vector, and the data dependencies between nodes constitute the edge set of the graph. The single-node features have eight dimensions, as shown in Table 1: software graph operation sub-number, in-degree, out-degree, number of internal loads, number of internal stores, execution latency, operation function code, and input operand features. Among these, the operation sub-number is a discrete encoding of the software operation type, helping the model distinguish between different types of computation or memory operations; in-degree and out-degree reflect the connectivity of nodes in the software graph, providing local topological information; the number of internal loads / stores is related to memory access patterns; the execution latency feature provides the performance baseline for a single node; and the operation function code and input operand features describe the semantic information of the node. These features describe information related to OII from two dimensions: node attributes and graph structure.

[0058] Table 1

[0059] It should be noted that, since the performance prediction model is repeatedly invoked during the search process, the network architecture must balance expressive power and inference efficiency. This paper adopts a lightweight architecture that alternates between graph convolutional layers (GCN) and graph attention layers (GAT). Figure 4 As shown, the network consists of three stages: In the first stage, the input is an N×8 node feature matrix that enters the GNN body and is extracted by multiple layers of alternating stacked GCN and GAT layers to obtain an N×32 latent vector representation; In the second stage, mean pooling is performed on all node representations to form graph-level embeddings; In the third stage, the graph-level embeddings are mapped to the final optimal start interval prediction value through a multilayer perceptron.

[0060] In this application, GCN and GAT are alternately stacked instead of a single type of layer because GCN aggregates neighborhood information with fixed graph structure weights, excelling at efficiently aggregating local topological statistics; while GAT dynamically weights neighbor contributions through an attention mechanism, sensitively capturing critical paths and special dependency clusters. The alternating arrangement also helps alleviate the oversmoothing and training instability problems commonly found in pure GCN stacking.

[0061] Step S2: Construct a basic training set, and perform redundancy injection and subgraph extraction operations on the basic dataset to obtain an extended dataset.

[0062] In this embodiment, the dataset is constructed and expanded based on an open-source dataset, which refers to a collection of programs extracted from publicly available and widely used embedded and high-performance computing benchmark suites, serving as the basic source of training and validation data for the cost model.

[0063] The dataset construction and expansion refers to the process of generating labeled training samples (i.e., true optimal performance metrics) based on software graphs extracted from open-source datasets, and then expanding the sample size and diversity using innovative technologies. This process specifically includes the following steps: (1) Basic Data Construction: For each graph in the software graph sample pool, a complete and accurate compilation process is performed on the target hardware architecture to obtain its optimal performance metric on the given hardware as a label. This step generates a high-quality but limited number of initial training datasets that are costly to acquire.

[0064] (2) Data expansion with redundant injection: To overcome the drawback of the huge time consumption in basic data construction, an expansion method without additional compilation overhead is proposed. Specifically, for a software graph that has obtained the optimal mapping result and its corresponding modular routing resource graph, a new software graph with a different syntax structure is constructed by adding new virtual software operation nodes and dependency edges to the idle hardware units in MRRG without changing the critical path of the original graph.

[0065] (3) Data expansion using subgraph extraction: To further enrich data diversity, another compilation-free expansion method is proposed. For a modular routing resource graph constructed for a specific initial interval, connected subgraph structures are randomly or heuristically extracted from it. This subgraph can be regarded as a new, smaller software graph. Since this subgraph originates from an effective global mapping, it is mappable under the original II value. Using these two data expansion methods, a large number of software graph samples with different structures can be generated quickly, which is particularly suitable for the pre-training stage of the model.

[0066] Through the above construction and expansion process, the size and diversity of the training dataset can be increased by several orders of magnitude without significantly increasing the actual compilation time. This effectively solves the problem of data scarcity in machine learning model training and lays a data foundation for building high-precision, high-generalization performance prediction models.

[0067] The following describes the specific steps of the redundancy injection operation, which include: Given an original feasible sample and its complete mapping result on the modulo routing resource graph, extract the set of idle hardware processing units and the set of idle hardware connections from the complete mapping result; Based on the topological connections of the set of idle hardware processing units and the set of idle hardware connections, a set of candidate redundant segments is constructed to obtain a redundant injection dataset. Each candidate redundant segment includes a set of redundant software operations to be injected, a set of redundant software edges to be injected, and a predetermined mapping from the redundant segment to idle hardware resources.

[0068] The redundancy injection method in this embodiment can find operator injection positions in the computational gaps of the MRRG unfolded graph and further refine them based on the pre-trained graph neural network. The starting point for redundancy injection is an observation of the MRRG mapping results: in most successful mapping cases, the processing units and interconnect resources of the hardware array are not fully utilized. Specifically, when the software graph... G Mapping the target hardware array with the optimal boot interval OII H At that time, MRRG M (OII) typically contains a large number of idle hardware processing unit locations and unused hardware connections. The existence of these idle resources means that, without changing the original mapping scheme or affecting the timing and routing relationships of already mapped operations, additional software operations and data dependencies can be superimposed on these idle locations to construct a new software graph that is larger in scale but maintains the optimal startup interval. Since the added operations only occupy the originally idle hardware resources and do not cause any resource conflicts with the original mapping, the mapping feasibility of the expanded software graph on the same MRRG is strictly guaranteed, and the correctness of its OII labels is directly inherited from the original mapping results.

[0069] The specific process of redundancy injection is as follows: Given an original feasible sample and in Complete mapping results on The algorithm first extracts the set of idle hardware processing units from the mapping results. Collection of idle hardware connections Subsequently, based on the topological connectivity of these idle resources, a set of candidate redundant segments is constructed. C Each candidate redundant segment It consists of three parts: a set of redundant software operations to be injected. A set of redundant software edges to be injected And the pre-defined mapping of redundant segments to idle hardware resources. For each candidate fragment, the algorithm checks its mapping. Whether it falls entirely within the range of available resources, i.e. Only redundant fragments that meet this strict constraint will be accepted, ensuring that the injection process does not affect the correctness of the original mapping.

[0070] by Figure 5 For example, if a computation graph containing three operators OP0, OP1, and OP2 is mapped onto hardware with two processing units, there may still be idle processing positions after the spatiotemporal expansion. These positions can be further injected with a new operator OP3, while introducing additional routing relationships between OP3 and the original operators, such as OP0→OP3, OP1→OP3, etc. This process expands the graph structure without disrupting the original feasible mapping; therefore, the augmented samples still maintain the original optimal start interval.

[0071] It's important to note that redundancy injection requires no additional compilation overhead. Since the injection process is entirely based on existing mapping results, it doesn't require calling the lower-level compiler to re-execute placement and routing on the expanded software graph. Therefore, the time required to expand each sample is only the computational overhead of constructing redundant fragments and verifying resource constraints, typically in the millisecond range. In contrast, obtaining the OII label of a new sample using an integer linear programming-based compilation method takes an average of 107.0 seconds. Therefore, the cost of redundancy injection to expand the dataset is very low.

[0072] The expanded sample graph generated by redundant injection is typically larger than the original sample graph, but shares the same OII labels. This helps the model understand that graph structural complexity is not the sole determinant of OII, avoiding the use of the number of operations as the dominant feature for prediction. However, the expanded graph is always a hypergraph of the original graph, and redundant operations do not affect the critical path. When the expansion factor is too high, a large number of structurally similar samples may cause the model to overfit to a specific pattern. Therefore, the expansion factor of redundant injection needs to be appropriately controlled based on the size of the original dataset.

[0073] The following describes the steps for subgraph extraction, including the specific steps for subgraph advance: Given an original feasible sample and its complete mapping result on the modulo routing resource graph, extract the operation subset and its corresponding initiation interval from the complete mapping result to obtain the subgraph dataset; Based on the launch interval and the number of operations of the subgraph, the mapping feasibility of the subgraph under different launch intervals is assigned a label, wherein the label includes 0, 1 and unknown, and the subgraph with the label unknown is directly discarded.

[0074] This embodiment introduces a subgraph extraction method, which can extract a subset of the computation graph from the complete mapping result, thereby further augmenting the dataset and enabling deeper fine-tuning based on the pre-trained graph neural network. Unlike redundant injection, which adds operations to the graph, subgraph extraction extracts a subset of operations from the mapped complete software graph, generating new samples that are smaller in scale but have verifiable labels, thus expanding the coverage of the training data in the direction of graph size reduction.

[0075] The theoretical basis for subgraph extraction lies in the decomposability of the MRRG mapping result. When a software graph G is at the optimal startup interval... Successfully mapped to MRRG M ( After that, any subset of operations in the mapping result And the corresponding hardware resource allocation itself constitutes a [system / mechanism] in [the context of] [the system / mechanism]. M ( A valid mapping on a subgraph. This means that the subgraph... During startup interval The following must be mappable. Furthermore, since... The number of operations does not exceed G The number of operations, for any II , M (II) The provided spacetime resources will only become more abundant, therefore In all II All of these can be mapped. This reasoning provides a partial guarantee of the correctness of the labels for the samples generated by subgraph extraction.

[0076] For each extracted valid subgraph, its mapping feasibility under different initiation intervals needs to be labeled. As mentioned above, when II hour, The feasibility of the mapping can be determined to be 1. And for II ≤ In this case, label determination becomes more complex and requires discussion in two scenarios. The first scenario involves subgraphs... Number of operations Exceeded The total number of hardware processing units in the system If the size of the subgraph exceeds the maximum number of processing units that MRRG can provide under a smaller startup interval, then based on resource constraints, it can be determined that the subgraph is in II < If the subgraph cannot be mapped, the label is 0. In the second case, if the subgraph size does not exceed the resource limit, the feasibility of mapping cannot be determined based on resource constraints alone, because the actual mapping feasibility also depends on complex factors such as the subgraph's topology, inter-operation dependencies, and hardware interconnection constraints. In this case, the label is marked as unknown.

[0077] For example, performing a time extension of II = 4 on a 1×2 hardware array yields the corresponding MRRG. Any subgraph extracted from this MRRG is a subset of the original software graph and retains certain isomorphic features. Using this subgraph extraction method, we can obtain more training samples without performing additional compilation tasks, and the correctness of these samples can be verified by the original mapping results and their derivations. Figure 6 An example is given: First, map OP0→OP1→OP2→OP3←OP6←OP5←OP4 to the MRRG unfolded graph of PE0→PE1 with T=4, where OP0→OP1 is a valid subgraph of the original graph. Due to the original mapping... = 4, which determines that the subgraph is in II. Mapping is possible when II = 4. However, for the case where II < 4, since OP0→OP1 only contains 2 operations, and MRRG provides 6 processing unit positions when II = 3, the resource constraints cannot determine that it is not mappable, so these tags are marked as unknown.

[0078] For labels marked as unknown, this application adopts a conservative strategy, discarding them directly without using them for training. The rationale for this approach is that the negative impact of training with incorrect labels on the model far outweighs the loss of a small amount of training data. Through rigorous filtering, all retained samples generated from subgraph extraction have provably correct labels, ensuring the reliability of the training data.

[0079] It is important to note that the extracted subgraphs are generally less complex in terms of topological complexity and diversity of operation types compared to the complete software graph. When the original dataset is already large enough, too many simple subgraph samples may introduce distribution bias and interfere with the model's predictive ability on real-scale graphs. Therefore, the proportion of subgraph samples extracted also needs to be appropriately adjusted according to the size of the dataset.

[0080] In this application, the pre-training stage uses threshold-amplified data to complete the coarse-tuning of binary classification, and the fine-tuning stage uses the original data plus expanded data from redundant injection and subgraph extraction to complete OII regression training. None of the three augmentations require additional compilation overhead.

[0081] Step S3: Perform pre-training and fine-tuning training operations on the graph neural network based on the extended dataset until the trained throughput-oriented performance prediction sub-model is obtained.

[0082] In this embodiment, the built model is trained using an extended dataset, and the model is optimized using methods such as normalized training (i.e., pre-training) and fine-tuning.

[0083] Normalized training refers to the training phase where a task transfer strategy is used to initialize the model before formally training the performance regression model. Specifically, the final regression layer of the throughput-oriented data-driven prediction model is temporarily replaced with a binary classification layer, and then training is performed using data extracted from a large-scale, readily available subgraph. The training objective at this stage is not to accurately predict the II value, but rather to learn whether a given "software graph-hardware architecture-initial margin" triple is mappable, i.e., whether at least one feasible mapping scheme exists.

[0084] The pre-training operation is described in detail below. In some optional embodiments of this example, the steps of the pre-training operation include: Replace the regression layer of the graph neural network with a binary classification layer, use subgraph extracted data for training, and determine whether the software graph, hardware architecture and triples with a given initial interval in the subgraph dataset can be mapped. If they can, output 1; otherwise, output 0.

[0085] Specifically, this embodiment introduces a pre-training method to provide better parameter initialization for the graph neural network. For example, the original training dataset of this application contains 100 data flow graph samples, distributed across five benchmark test sets. A sample size of hundreds is relatively limited for graph neural networks, and direct training is prone to overfitting. Therefore, this paper introduces a pre-training stage to provide better parameter initialization for the model. The pre-training method utilizes a physical property of OII: OII has a threshold characteristic. Specifically, for a given combination of software node and target hardware array, when the attempted startup interval II is less than OII, the temporal unfolding layer of the Modular Routing Resource Graph (MRRG) is insufficient to accommodate all software operations and routing requirements, and the mapping will inevitably fail; when the attempted startup interval II is greater than or equal to OII, the MRRG provides sufficient spatiotemporal resources, and the mapping becomes possible. This threshold characteristic can be formally expressed as: for the mapping of software graph G on the target hardware array H, the mapping feasibility function... satisfy:

[0086] This threshold property provides a natural mechanism for data augmentation: each original sample It can be expanded into multiple binary classification samples. , where y is determined by the threshold relationship described above.

[0087] like Figure 7As shown, for a computational graph with an optimal initiation interval of 4, it is clearly impossible to achieve the spatiotemporal mapping of CGRA with an initiation interval less than 4. Therefore, when the input trial II is 1, 2, or 3, the model output should be 0, indicating no mapping; while when the input trial II is 4, 5, or 6, the model output should be 1, indicating mapping. In this way, a single data point can be expanded into II. max There are 10 data points. Taking the OII value range of 1 to 6 in this dataset as an example, II... max When the value is 6, each original sample can be expanded into 6 binary classification samples, and the entire dataset expands from 100 regression samples to 600 binary classification samples, increasing the sample size by 6 times.

[0088] It's important to note that in terms of the pre-trained network structure, the pre-trained model shares the core of the graph neural network with the formal OII prediction model, including alternating stacked GCN and GAT layers and mean pooling layers. The only difference lies in the output header: the pre-training stage uses a binary classification output header, concatenating the graph-level embedding vector with the input starting margin and mapping it to the mapping feasibility II probability through a fully connected layer; the fine-tuning stage uses a regression output header, directly mapping from the graph-level embedding to the OII prediction value. This allows the graph structure representation learned in the pre-training stage to be directly used in the fine-tuning stage.

[0089] The binary classification task in the pre-training phase is less challenging than the regression task in the fine-tuning phase: the model only needs to determine whether a mapping is feasible under a given start interval, rather than predicting precise OII values; simultaneously, the binary classification labels are strictly guaranteed by the threshold characteristics of OII, eliminating label noise. Through this task, the graph neural network backbone can initially learn the correlation patterns between computation graph structure and mapping feasibility, such as that graphs with higher operation density typically require larger start intervals, and that memory-intensive graphs are more difficult to map on PE-constrained hardware. This structural knowledge provides a better starting point for parameters in the fine-tuning phase.

[0090] Fine-tuning refers to the training phase after pre-training, where the model is adjusted to the final task format and optimized accordingly. The specific process is as follows: First, all weight parameters in the pre-trained model, except for the final classification layer, are used as the initial weights for a throughput-oriented data-driven prediction model. Then, the last layer of the model is restored to a regression layer, and training is performed using basic compiled data containing true performance numerical labels and redundant injected data. The training objective at this stage is to minimize the error between the model's predicted initial margin and the true optimal initial margin. Through fine-tuning, the general graph structure understanding acquired by the model during pre-training is guided and refined, focusing on learning accurate predictions of the performance quantification metric II.

[0091] It should be noted that after obtaining the performance prediction model, it is also necessary to embed the performance prediction model into the standard layered compilation process to form a closed-loop optimization.

[0092] The hierarchical compilation process refers to a typical top-down compilation process on a reconfigurable space accelerator, matching the hardware hierarchy. This process decomposes the complex global mapping problem into multiple levels of sub-problems, solving them sequentially to manage compilation complexity. Its standard steps include top-level compilation and bottom-level compilation. In the top-level compilation stage, the compiler handles high-level program representations. Its main tasks include decomposing the program into several coarse-grained software nodes that can be mapped to a single hardware array for execution using loop analysis, graph partitioning, or clustering algorithms, and allocating these generated software nodes to different hardware arrays and determining the global data interconnects between nodes. In the bottom-level compilation stage, fine-grained mapping is performed for each software node assigned to a specific hardware array. Its main tasks include mapping each basic operation within the software node to a specific processing unit within the hardware array, allocating paths for their data dependencies on the interconnects, and determining the execution cycle of each operation. For throughput optimization scenarios, modular scheduling algorithms are typically used. This hierarchical process is the integration object and optimization carrier of this invention.

[0093] The closed-loop optimization refers to embedding the performance prediction cost model as a key feedback link into each decision point of the above-mentioned layered compilation process, so as to transform the original open-loop, sequential compilation process into an intelligent optimization system with performance awareness and dynamic adjustment capabilities.

[0094] For example, integrating performance prediction models into search algorithms can provide real-time performance predictions. Specifically: The search algorithm refers to an algorithm used in the hierarchical compilation process of a reconfigurable space accelerator to solve combinatorial optimization problems such as graph mapping and resource allocation.

[0095] The real-time performance prediction refers to the entire process during compiler execution, where for each candidate compilation scheme generated by the search algorithm, a pre-trained performance prediction model is invoked to obtain its performance estimate within milliseconds of latency. The specific steps of this process are as follows: (1) Candidate Solution Characterization: When the search algorithm generates a candidate solution, the compiler automatically extracts the description of the corresponding sub-software graph and target hardware sub-architecture, and instantiates it into the standard graph structure input required by the cost model. (2) Model Invocation and Inference: Based on the current compilation scenario, the compiler automatically selects and invokes the corresponding latency-oriented analytical model or throughput-oriented GNN model. The model uses the graph data prepared in the previous step as input and performs one inference. (3) Prediction Result Return and Application: The model outputs the predicted latency value or initial interval value in millimeter-level time. This prediction value is immediately returned to the search algorithm. The algorithm compares this prediction value with the current optimal solution, or uses it to calculate the evaluation score of the candidate solution, thereby deciding whether to accept the solution, reject the solution, or explore further based on the solution.

[0096] The following example illustrates the entire process of the hierarchical compilation performance prediction method for reconfigurable space accelerators proposed in this application: First, assume the computation graph to be mapped has... The target reconfigurable space accelerator, mapped by an operator, consists of 10 identical PEAs, each PEA consisting of... Each PE, numbered as follows Figure 8 As shown, the values ​​are {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}, and the 10 PEAs are numbered {0,1,2,3,4,5,6,7,8,9}. Traditional two-layer mapping methods suffer from high compilation time overhead in the lower-layer mapping, limiting the upper layer to only a few partitions. With the cost model, the lower-layer mapping speed is reduced to milliseconds, allowing the upper layer to perform as many computational graph partitions as possible based on the search algorithm, with an upper limit of [missing value]. kind.

[0097] Second, construct a high-precision performance prediction cost model. For example... Figure 4 As shown, the core of the cost model consists of 5 layers of GAT+GeLU and 5 layers of GCN+GeLU interleaved. Multiple GCN and GAT layers can effectively extract key information from the graph topology and generate graph embeddings, while the subsequent multilayer perceptron (MLP) layers are responsible for outputting the target value. The input of the finally trained cost model is the computation graph and the PEA array, and the output is the initial margin (II).

[0098] Third, normalized training improves model accuracy. The output II of the dataset is normalized and judged. As shown in Table 2, if the model gives a value greater than or equal to the minimum initial margin (MII), the training is accepted; otherwise, it is discarded.

[0099] Table 2

[0100] Fourth, redundant injection is used to expand the dataset, aiming to improve model accuracy by increasing the dataset size. Redundant computational tasks and interconnect schemes are added to idle hardware units in the compiled output to obtain an expanded software graph. For example... Figure 9 As shown, for a software graph with mapping II=2, there will be unused PE calculation points. In this case, adding a new op3 to the existing op0, op1, and op2 can expand the software graph while keeping II unchanged. The interconnection methods of op3 include op0 and op1 pointing to op3 simultaneously, op1 pointing to op3, and op0 pointing to op3. At this time, additional datasets are obtained for training.

[0101] Fifth, subgraph extraction expands the dataset to improve model accuracy. In the compiled output, there may be instances of II overestimation. Extracting the portion that precisely matches MII makes the training dataset more accurate. For example... Figure 10 As shown, the software graph consists of op0 and op1. These two operators can be executed correctly as long as II=2. Therefore, the process of extracting the subgraph is completed by mapping these two operators to T=0 and T=1 from the MRRG graph.

[0102] Sixth, the successfully trained cost model is integrated into the search algorithm. After generating each candidate solution, the search algorithm does not immediately perform full mapping verification, but instead first calls the cost model for rapid performance prediction. The specific software graph and target PEA combination in the candidate solution is converted into model input features, and the cost model outputs the predicted throughput metric of that software graph on that PEA. The initial prediction intervals of multiple software graphs are aggregated into the overall cost of the candidate solution according to system rules, thereby completing candidate ranking, pruning, and selection. Based on the initial prediction intervals, the algorithm quickly approaches the optimal candidate within a large search space.

[0103] Seventh, online prediction is integrated into a hierarchical compilation closed loop. When the search algorithm selects a small number of priority candidates for real-world validation, actual model scheduling and wiring mapping are performed at the lower level. At this point, the cost model does not replace real-world validation, but rather serves as a starting point for the lower-level search, performing feasibility checks on the initial intervals until they are feasible. This reduces the large number of invalid iterations caused by trying each initial interval one by one, thus lowering compilation time. After obtaining the true results from the lower-level validation, the true scores of the current candidates are updated and the final solution is determined. At the same time, new samples are collected for subsequent offline training, allowing the cost model to be continuously calibrated in real-world workloads.

[0104] This invention provides a hierarchical compilation performance prediction method for reconfigurable space accelerators. Based on a performance prediction model integrated into a hierarchical compilation framework, it establishes an inter-layer awareness mechanism to quickly predict the performance of candidate solutions without executing the actual lower-level compilation. This allows the upper-level compiler to accurately and quickly predict the final throughput, latency, and other performance consequences of different compilation decisions before executing the actual lower-level requirements, thereby guiding the compiler to make globally optimal decisions and improving overall compilation quality and system performance.

[0105] This invention also provides a hierarchical compilation performance prediction device for reconfigurable space accelerators, as described in the following embodiments. Since the principle by which this device solves the problem is similar to that of a hierarchical compilation performance prediction method for reconfigurable space accelerators, the implementation of this device can refer to the implementation of a hierarchical compilation performance prediction method for reconfigurable space accelerators; repeated details will not be elaborated further.

[0106] like Figure 11 As shown, the hierarchical compilation performance prediction device for a reconfigurable space accelerator includes: The feature extraction module 501 is configured to obtain candidate compilation schemes generated by the search algorithm compiled by the upper layer, and to extract features from the candidate compilation schemes to obtain the software graph topology and target hardware array information corresponding to the candidate compilation schemes. The compilation scenario determination module 502 is configured to determine the current compilation scenario based on the software graph topology. The model invocation module 503 is configured to invoke a performance prediction model pre-integrated in the lower-level mapping based on the current compilation scenario. The performance prediction module 504 is configured to determine the prediction mapping performance of the candidate compilation scheme at the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model.

[0107] In some alternative embodiments of this example, the software graph topology is represented by an attribute graph. It means that, among them, It is a set of nodes, where each node represents a basic operation; The set of edges represents the data or control dependencies between operations; For each node, there is a collection of node attributes. It is encoded into a feature vector, which includes, but is not limited to: operation type identifier, in-degree, out-degree, number of load instructions, number of store instructions, estimated execution latency cycles, function code, and input operand features; The target hardware array information is represented by an attribute graph. It means that, among them, A set of nodes, representing reconfigurable processing units, memory interfaces, or preset functional units; This is a set of edges, representing interconnection links or communication channels between units; It is a set of attributes that describe the computing power, storage bandwidth, interconnect latency, and configurability of each hardware node.

[0108] In some optional embodiments of this example, the software graph topology includes multiple software nodes, and determining the current compilation scenario based on the software graph topology includes: Determine whether there are circular dependencies at the software node level in the software graph topology; If it exists, the current compilation scenario is determined to be a latency-oriented scenario; If it does not exist, the current compilation scenario is determined to be a throughput-oriented scenario.

[0109] In some optional embodiments of this example, the step of invoking a performance prediction model pre-integrated in the underlying mapping according to the current compilation scenario includes: In response to determining that the current compilation scenario is a latency-oriented scenario, the latency-oriented performance prediction sub-model pre-integrated in the underlying mapping is invoked; In response to determining that the current compilation scenario is a throughput-oriented scenario, the throughput-oriented performance prediction sub-model pre-integrated in the underlying mapping is invoked.

[0110] In some optional embodiments of this example, determining the prediction mapping performance of the candidate compilation scheme at the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model includes: Based on the software graph topology, determine the critical and non-critical paths of the software nodes; Based on the target hardware array information, determine the critical path and non-critical path of the hardware array; The latency-oriented performance prediction sub-model is configured as follows: The sum of the operation execution time of the critical path of the software node and the channel transmission time of the critical path of the hardware array is calculated as the first critical path delay estimate. The sum of the operation execution time of the non-critical path of the software node and the channel transmission time of the non-critical path of the hardware array is calculated as the second critical path delay estimate. The sum of the first critical path delay estimate and the second critical path delay estimate is output as the prediction mapping performance of the candidate compilation scheme at the lower layer.

[0111] In some optional embodiments of this example, determining the prediction mapping performance of the candidate compilation scheme at the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model includes: Using the software graph topology and the target hardware array information as input, and based on the pre-trained throughput-oriented performance prediction sub-model, the optimal startup interval is output as the predicted mapping performance of the candidate compilation scheme at the lower layer.

[0112] In some optional embodiments of this example, the step of training the throughput-oriented performance prediction sub-model includes: Graph neural networks are constructed by alternately stacking graph convolutional layers (GCN) and graph attention layers (GAT). A basic training set is constructed, and redundancy injection and subgraph extraction operations are performed on the basic dataset to obtain an extended dataset; Based on the extended dataset, pre-training and fine-tuning operations are performed on the graph neural network until the trained throughput-oriented performance prediction sub-model is obtained.

[0113] In some optional embodiments of this example, the network architecture of the graph neural network consists of three stages, wherein: In the first stage, the input is in the form of an N×8 node feature matrix, which enters the GNN body and is extracted by multiple layers of alternating stacked GCN and GAT layers to obtain an N×32 latent vector representation. In the second stage, mean pooling is performed on all node representations to form graph-level embeddings; In the third stage, the graph-level embedding is mapped to the final optimal start interval prediction value through a multilayer perceptron.

[0114] In some optional embodiments of this example, the steps of the redundant injection operation include: Given an original feasible sample and its complete mapping result on the modulo routing resource graph, extract the set of idle hardware processing units and the set of idle hardware connections from the complete mapping result; Based on the topological connections of the set of idle hardware processing units and the set of idle hardware connections, a set of candidate redundant segments is constructed to obtain a redundant injection dataset. Each candidate redundant segment includes a set of redundant software operations to be injected, a set of redundant software edges to be injected, and a predetermined mapping from the redundant segment to idle hardware resources.

[0115] In some optional embodiments of this example, the steps of the subgraph extraction operation include: Given an original feasible sample and its complete mapping result on the modulo routing resource graph, extract the operation subset and its corresponding initiation interval from the complete mapping result to obtain the subgraph dataset; Based on the launch interval and the number of operations of the subgraph, the mapping feasibility of the subgraph under different launch intervals is assigned a label, wherein the label includes 0, 1 and unknown, and the subgraph with the label unknown is directly discarded.

[0116] In some optional embodiments of this example, the pre-training operation includes the following steps: Replace the regression layer of the graph neural network with a binary classification layer, use subgraph extracted data for training, and determine whether the software graph, hardware architecture and triples with a given initial interval in the subgraph dataset can be mapped. If they can, output 1; otherwise, output 0.

[0117] In some optional embodiments of this example, the steps of the fine-tuning training operation include: All weight parameters in the graph neural network obtained after the pre-training operation, except for the classification layer, are used as initial weights, and the binary classification layer is restored to the regression layer. The graph neural network is trained using the base dataset and the redundant injection dataset.

[0118] An embodiment of this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the hierarchical compilation performance prediction method for a reconfigurable space accelerator as described in the first aspect.

[0119] An embodiment of this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the hierarchical compilation performance prediction method for a reconfigurable space accelerator as described in the first aspect.

[0120] An embodiment of this application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the hierarchical compilation performance prediction method for a reconfigurable space accelerator as described in the first aspect.

[0121] Figure 12A schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0122] like Figure 12 As shown, device 900 includes a computing unit 901, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 902 or a computer program loaded from storage unit 908 into random access memory (RAM) 903. RAM 903 may also store various programs and data required for the operation of device 900. The computing unit 901, ROM 902, and RAM 903 are interconnected via bus 904. Input / output (I / O) interface 905 is also connected to bus 904.

[0123] Multiple components in device 900 are connected to I / O interface 905, including: input unit 906, such as keyboard, mouse, etc.; output unit 907, such as various types of monitors, speakers, etc.; storage unit 908, such as disk, optical disk, etc.; and communication unit 909, such as network card, modem, wireless transceiver, etc. Communication unit 909 allows device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0124] Computing unit 901 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of computing unit 901 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Computing unit 901 performs the various methods and processes described above, such as a hierarchical compilation performance prediction method for a reconfigurable space accelerator.

[0125] For example, in some embodiments, a hierarchical compilation performance prediction method for a reconfigurable space accelerator can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 908. In some embodiments, part or all of the computer program can be loaded and / or installed on device 900 via ROM 902 and / or communication unit 909. When the computer program is loaded into RAM 903 and executed by computing unit 901, one or more steps of the hierarchical compilation performance prediction method for a reconfigurable space accelerator described above can be performed. Alternatively, in other embodiments, computing unit 901 can be configured to perform a hierarchical compilation performance prediction method for a reconfigurable space accelerator by any other suitable means (e.g., by means of firmware).

[0126] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0127] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0128] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0129] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0130] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0131] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0132] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0133] It should be noted that in the description of this application, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0134] In the embodiments of this application, the singular forms "a," "the," etc., including the plural forms, should be broadly understood as "a kind" or "a class" rather than limited to the meaning of "an." Furthermore, the term "the" should be understood to include both the singular and plural forms, unless the context explicitly indicates otherwise. Additionally, the term "according to" should be understood as "at least partially based on…," and the term "based on" should be understood as "at least partially based on…," unless the context explicitly indicates otherwise.

[0135] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0136] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for predicting the performance of hierarchical compilation for reconfigurable space accelerators, characterized in that, include: Candidate compilation schemes generated by the search algorithm of the upper layer are obtained, and feature extraction is performed on the candidate compilation schemes to obtain the software graph topology and target hardware array information corresponding to the candidate compilation schemes; Based on the software graph topology, determine the current compilation scenario; Based on the current compilation scenario, the performance prediction model pre-integrated in the lower-level mapping is invoked; Based on the software graph topology, the target hardware array information, and the performance prediction model, the predicted mapping performance of the candidate compilation scheme at the lower layer is determined.

2. The performance prediction method according to claim 1, characterized in that, The software graph topology uses an attribute graph. It means that, among them, It is a set of nodes, where each node represents a basic operation; The set of edges represents the data or control dependencies between operations; For each node, there is a collection of node attributes. It is encoded into a feature vector, which includes, but is not limited to: operation type identifier, in-degree, out-degree, number of load instructions, number of store instructions, estimated execution latency cycles, function code, and input operand features; The target hardware array information is represented by an attribute graph. It means that, among them, A set of nodes, representing reconfigurable processing units, memory interfaces, or preset functional units; This is a set of edges, representing interconnection links or communication channels between units; It is a set of attributes that describe the computing power, storage bandwidth, interconnect latency, and configurability of each hardware node.

3. The performance prediction method according to claim 1, characterized in that, The software graph topology includes multiple software nodes. Determining the current compilation scenario based on the software graph topology includes: Determine whether there are circular dependencies at the software node level in the software graph topology; If it exists, the current compilation scenario is determined to be a latency-oriented scenario; If it does not exist, the current compilation scenario is determined to be a throughput-oriented scenario.

4. The performance prediction method according to claim 1 or 3, characterized in that, The step of invoking a performance prediction model pre-integrated in the underlying mapping based on the current compilation scenario includes: In response to determining that the current compilation scenario is a latency-oriented scenario, the latency-oriented performance prediction sub-model pre-integrated in the underlying mapping is invoked; In response to determining that the current compilation scenario is a throughput-oriented scenario, the throughput-oriented performance prediction sub-model pre-integrated in the underlying mapping is invoked.

5. The performance prediction method according to claim 4, characterized in that, The step of determining the predicted mapping performance of the candidate compilation scheme at the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model includes: Based on the software graph topology, determine the critical and non-critical paths of the software nodes; Based on the target hardware array information, determine the critical path and non-critical path of the hardware array; The latency-oriented performance prediction sub-model is configured as follows: The sum of the operation execution time of the critical path of the software node and the channel transmission time of the critical path of the hardware array is calculated as the first critical path delay estimate. The sum of the operation execution time of the non-critical path of the software node and the channel transmission time of the non-critical path of the hardware array is calculated as the second critical path delay estimate. The sum of the first critical path delay estimate and the second critical path delay estimate is output as the prediction mapping performance of the candidate compilation scheme at the lower layer.

6. The performance prediction method according to claim 4, characterized in that, The step of determining the predicted mapping performance of the candidate compilation scheme at the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model includes: Using the software graph topology and the target hardware array information as input, and based on the pre-trained throughput-oriented performance prediction sub-model, the optimal startup interval is output as the predicted mapping performance of the candidate compilation scheme at the lower layer.

7. The performance prediction method according to claim 6, characterized in that, The steps for training the throughput-oriented performance prediction sub-model include: Graph neural networks are constructed by alternately stacking graph convolutional layers (GCN) and graph attention layers (GAT). A basic training set is constructed, and redundancy injection and subgraph extraction operations are performed on the basic dataset to obtain an extended dataset; Based on the extended dataset, pre-training and fine-tuning operations are performed on the graph neural network until the trained throughput-oriented performance prediction sub-model is obtained.

8. The performance prediction method according to claim 7, characterized in that, The network architecture of the graph neural network consists of three stages, wherein: In the first stage, the input is in the form of an N×8 node feature matrix, which enters the GNN body and is extracted by multiple layers of alternating stacked GCN and GAT layers to obtain an N×32 latent vector representation. In the second stage, mean pooling is performed on all node representations to form graph-level embeddings; In the third stage, the graph-level embedding is mapped to the final optimal start interval prediction value through a multilayer perceptron.

9. The performance prediction method according to claim 7, characterized in that, The steps of the redundant injection operation include: Given an original feasible sample and its complete mapping result on the modulo routing resource graph, extract the set of idle hardware processing units and the set of idle hardware connections from the complete mapping result; Based on the topological connections of the set of idle hardware processing units and the set of idle hardware connections, a set of candidate redundant segments is constructed to obtain a redundant injection dataset. Each candidate redundant segment includes a set of redundant software operations to be injected, a set of redundant software edges to be injected, and a predetermined mapping from the redundant segment to idle hardware resources.

10. The performance prediction method according to claim 7, characterized in that, The steps of the subgraph extraction operation include: Given an original feasible sample and its complete mapping result on the modulo routing resource graph, extract the operation subset and its corresponding initiation interval from the complete mapping result to obtain the subgraph dataset; Based on the launch interval and the number of operations of the subgraph, the mapping feasibility of the subgraph under different launch intervals is assigned a label, wherein the label includes 0, 1 and unknown, and the subgraph with the label unknown is directly discarded.

11. The performance prediction method according to claim 10, characterized in that, The pre-training operation includes the following steps: Replace the regression layer of the graph neural network with a binary classification layer, use subgraph extracted data for training, and determine whether the software graph, hardware architecture and triples with a given initial interval in the subgraph dataset can be mapped. If they can, output 1; otherwise, output 0.

12. The performance prediction method according to claim 11, characterized in that, The steps of the fine-tuning training operation include: All weight parameters in the graph neural network obtained after the pre-training operation, except for the classification layer, are used as initial weights, and the binary classification layer is restored to the regression layer. The graph neural network is trained using the base dataset and the redundant injection dataset.

13. A hierarchical compilation performance prediction device for a reconfigurable space accelerator, characterized in that, include: The feature extraction module is configured to obtain candidate compilation schemes generated by the search algorithm compiled by the upper layer, and to extract features from the candidate compilation schemes to obtain the software graph topology and target hardware array information corresponding to the candidate compilation schemes. The compilation scenario determination module is configured to determine the current compilation scenario based on the software graph topology. The model invocation module is configured to invoke a performance prediction model pre-integrated in the lower-level mapping, based on the current compilation scenario. The performance prediction module is configured to determine the prediction mapping performance of the candidate compilation scheme at the lower layer based on the software graph topology, the target hardware array information, and the performance prediction model.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the hierarchical compilation performance prediction method for reconfigurable space accelerators as described in any one of claims 1 to 12.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the hierarchical compilation performance prediction method for reconfigurable space accelerators as described in any one of claims 1 to 12.

16. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the hierarchical compilation performance prediction method for reconfigurable space accelerators as described in any one of claims 1 to 12.

Images