LLM-based multi-hardware platform high-performance operator automatic generation and iterative optimization method

Abstract

The application is specifically a multi-hardware platform high-performance operator automatic generation and iterative optimization method based on LLM, relates to the technical field of heterogeneous computing, and comprises: sequentially performing structure verification, execution verification and function verification on the generated code, arranging each layer of verification in order from low to high verification cost, and terminating the verification of the subsequent layer and outputting the exception information of the current layer as the verification result when any layer of verification fails. In the application, the platform constraint set organized according to the hardware type and version number is used for parameterized assembly of the prompt word, and the large language model can perceive the memory constraint, thread constraint and instruction set constraint of the target hardware platform when generating the code, so that the code incompatibility problem caused by platform difference is reduced.

Description

Technical Field

[0001] This invention relates to the field of heterogeneous computing technology, and in particular to a method for automatic generation and iterative optimization of high-performance operators for multiple hardware platforms based on LLM. Background Technology

[0002] In the field of heterogeneous computing, writing high-performance parallel computing code for different hardware platforms is a common requirement. Existing methods require users to have programming experience for specific hardware platforms and manually complete code writing, debugging, and optimization, which requires high professional skills and is inefficient.

[0003] Utilizing large language models to automatically generate parallel computing code is a feasible approach. However, existing code generation methods based on large language models suffer from the following shortcomings: Different hardware platforms impose significantly different constraints on the code, making it difficult for a single prompt word template to adapt to multiple hardware platforms, leading to platform incompatibility issues; the generated code may contain syntax errors, runtime exceptions, or semantic deviations, and the lack of layered verification methods means that low-level errors cannot be intercepted in the early stages; when errors occur in the generated code, there is a lack of effective exception attribution and targeted correction strategies, resulting in inefficient iteration due to blind retries and an inability to identify oscillations and divergences during the iteration process, leading to wasted computing resources. These problems result in insufficient usability of code generated by large language models, making it difficult to meet the actual needs of multi-hardware platform scenarios. Summary of the Invention

[0004] The purpose of this invention is to propose an automatic generation and iterative optimization method for high-performance operators on multiple hardware platforms based on LLM in order to solve the above-mentioned problems.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] A method for automatic generation and iterative optimization of high-performance operators based on LLM across multiple hardware platforms includes: Obtain a natural language description, load the corresponding constraints from the platform constraint set based on the target hardware platform identifier, and assemble the natural language description and the constraints into a prompt word; Input the assembled prompt words into the large language model to obtain the generated code; The generated code is sequentially subjected to structural verification, execution verification, and functional verification. The verification layers are arranged in order of increasing verification cost. When any layer fails verification, the verification of subsequent layers is terminated and the exception information of the current layer is output as the verification result. Based on the verification result, it is determined whether the generated code passes the verification. If it passes, the generated code is output. If it fails, the abnormal information is classified, and a corresponding correction strategy is selected based on the classification result. The correction strategy and the abnormal information are used to assemble correction prompt words and input them into the large language model to obtain the optimized generated code and return to execute the progressive verification.

[0007] Preferably, the platform constraint set is organized into a two-level directory structure according to hardware type and version number. Each constraint information is represented in the form of a triple. The triple includes constraint category, constraint content, and priority. The constraint category includes memory constraints, thread constraints, and instruction set constraints. When loading the constraint conditions, the constraint conditions are injected into the corresponding positions of the prompt words in order of priority from high to low.

[0008] Preferably, a multi-level rollback strategy is adopted when loading the constraints: first, an attempt is made to load constraints that exactly match the target hardware platform identifier; if the exact match fails, the default version of the constraints under the same hardware type is rolled back to load; if the rollback loading still fails, an exception message indicating missing constraints is returned and the process is terminated.

[0009] Preferably, the structural verification includes: performing syntax parsing and static analysis on the generated code to check for syntax errors, undefined variables, and type mismatches; if any problem is detected, the corresponding exception information is output and subsequent verification is terminated. The verification process includes: compiling and running the generated code on the target hardware platform or its simulation environment, monitoring for memory out-of-bounds errors, thread deadlocks, or runtime crashes, and capturing the exception type and location information and terminating subsequent verification if any exception occurs.

[0010] Preferably, the abnormal information is classified as follows: The first level is infrastructure layer exceptions, including compilation failures and environment configuration errors; The second level consists of exceptions at the code execution level, including memory out-of-bounds errors, thread deadlocks, and runtime crashes. The third level is semantic correctness layer anomalies, including inconsistencies in output during functional verification.

[0011] Preferably, the iterative optimization process introduces an iterative state machine, which includes five states: generating, testing, correcting, terminated, and successful. The initial state is generating. When the large language model returns the generated code, it transitions to the testing state. When the verification fails, it transitions to the correcting state. When the optimized generated code re-enters the verification process, it transitions to the testing state. When the verification passes, it transitions to the successful state. When the number of iterations is exhausted or the termination condition is met, it transitions to the terminated state.

[0012] Preferably, the iterative optimization process further incorporates dynamic allocation of the iterative budget: After each iteration, the difference between the number of anomalies in the current round of verification results and the number of anomalies in the previous round is calculated; when the difference is negative, the iteration trend is determined to be convergent, and the current iteration budget is maintained.

[0013] Preferably, after outputting the generated code, the method further includes: The generated code is run on the target hardware platform using multiple sets of test data with different data types and different input sizes, and the execution time corresponding to each set of test data is collected. The speedup matrix is ​​constructed by dividing the execution time of the generated code into rows with data types and columns with input sizes. Multi-dimensional statistical indicators are calculated based on the speedup matrix.

[0014] Preferably, the weighted comprehensive score The calculation method is as follows: ,in The average value of all elements in the speedup matrix is ​​given. It is the minimum value in the speedup ratio matrix. The standard deviation of all elements in the speedup matrix is ​​mapped to the mean after mean normalization based on the range. The value of the interval, , , These are the weights corresponding to the average speedup, minimum speedup, and speedup stability, respectively, and satisfy the following conditions: .

[0015] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. This invention parametrically assembles prompt words by organizing a set of platform constraints according to hardware type and version number. When generating code, the large language model can perceive the memory constraints, thread constraints and instruction set constraints of the target hardware platform, thereby reducing code incompatibility problems caused by platform differences.

[0016] 2. This invention uses a progressive verification method that arranges verification costs from low to high, which can intercept problems such as syntax errors and type mismatches during the structural verification stage, preventing generated code with fundamental defects from entering subsequent verification stages and reducing the computational resource consumption of the verification process. Attached Figure Description

[0017] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0018] Several embodiments of this application will now be described in more detail with reference to the accompanying drawings to enable those skilled in the art to implement this application. This application may be embodied in many different forms and for various purposes and should not be limited to the embodiments set forth herein. These embodiments are provided to make this application thorough and complete, and to fully convey the scope of this application to those skilled in the art. The embodiments described do not limit this application.

[0019] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having a meaning consistent with their meaning in the relevant field and / or the context of this specification, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0020] Example 1 Its specific implementation method is combined with the appendix Figure 1 Please provide a detailed explanation.

[0021] In this embodiment, it includes: Step S100: Obtain natural language description and assemble prompt words based on the platform constraint set of the target hardware platform to generate assembled prompt words.

[0022] The system receives a natural language description from the user, which includes the functional requirements of the computational task and the target hardware platform identifier. Based on the target hardware platform identifier, it loads the corresponding constraints from a pre-stored set of platform constraints. The natural language description and constraints are then assembled into a prompt word, generating the assembled prompt word.

[0023] It should be noted that the platform constraint set is a set of constraint information stored in a two-level directory structure organized by hardware type and version number. Each constraint is represented as a triple, which includes the constraint category, constraint content, and priority. Constraint categories include memory constraints, thread constraints, and instruction set constraints. When loading constraints, they are injected into the corresponding positions of the prompt words in descending order of priority.

[0024] In this embodiment, to improve the fault tolerance of constraint loading, a multi-level rollback strategy is adopted in the loading process. First, it attempts to load constraints that exactly match the target hardware platform identifier; if the exact match fails, it rolls back to load the default version of the constraints under the same hardware type; if the rollback loading still fails, it returns an exception message indicating that the constraint is missing and terminates the process.

[0025] Step S200: Input the assembled prompt words into the large language model to obtain the generated code.

[0026] The assembled prompts are sent to the large language model via an API call. The large language model generates parallel computing code for the target hardware platform based on the assembled prompts and returns the parallel computing code as the generated code.

[0027] Step S300: Perform progressive verification on the generated code and obtain the verification results.

[0028] The generated code undergoes multi-level validation sequentially, with each level ordered from lowest to highest validation cost. If any level fails validation, subsequent levels are terminated, and the exception information for the current level is output as the validation result. When all levels pass validation, a validation pass flag is output as the validation result.

[0029] Step S300 may specifically include: Step S301: Perform structural verification on the generated code and obtain the structural verification results.

[0030] The generated code undergoes syntax parsing and static analysis to check for syntax errors, undefined variables, and type mismatches. If any of these issues are detected, the corresponding exception information is output as the structure verification result, and subsequent verification is terminated. If no issues are detected, a structure verification pass flag is output.

[0031] Step S302: Perform execution verification on the generated code that has passed the structural verification, and obtain the execution verification result.

[0032] The generated code is compiled and run on the target hardware platform or its simulation environment. During execution, it is monitored for memory overflow, thread deadlock, or runtime crashes. If any of these exceptions occur, the exception type and location information are captured as the execution verification result output, and subsequent verification is terminated. If the execution completes normally, an execution verification pass flag is output.

[0033] Step S303: Perform functional verification on the generated code that has passed the execution verification, and obtain the functional verification result.

[0034] Based on the functional requirements described in natural language, a corresponding set of test cases is generated or loaded. The output of the generated code is compared with the expected output in the set of test cases. If inconsistencies are found, the input data, actual output, and expected output of the inconsistencies are output as the functional verification result. If all comparison results are consistent, a functional verification pass indicator is output.

[0035] Step S400: Determine whether the generated code passes the verification based on the verification result; if it passes, output the generated code; if it fails, perform iterative optimization based on the exception information in the verification result, obtain the optimized generated code, and return to step S300.

[0036] Determine if the verification result is a verification pass indicator. If yes, output the generated code as the final code. If the verification result contains abnormal information, classify the abnormal information, select the corresponding correction strategy based on the classification result, assemble correction prompts using the correction strategy and abnormal information, input the correction prompts into the large language model, obtain the optimized generated code, and return the optimized generated code to step S300 for re-verification.

[0037] It should be noted that the classification of anomalies adopts a three-level decision tree structure. The first level is the infrastructure layer anomaly, including compilation failures and environment configuration errors. The corresponding correction strategy is to adjust compilation parameters or environment configuration items and then regenerate. The second level is the code execution layer anomaly, including memory out-of-bounds errors, thread deadlocks, and runtime crashes. The corresponding correction strategy is to inject the anomaly type, anomaly location, and related code snippets into correction prompts, instructing the large language model to perform local corrections for specific anomaly types. The third level is the semantic correctness layer anomaly, including output inconsistencies in functional verification. The corresponding correction strategy is to inject the input data, actual output, and expected output of the inconsistency into correction prompts, instructing the large language model to correct the computational logic.

[0038] In this embodiment of the application, to avoid the iteration process from getting stuck in an invalid loop, the iterative optimization process introduces an iterative state machine and dynamic allocation of the iterative budget.

[0039] The iterative state machine consists of five states: Generating, Testing, Fixing, Terminated, and Successful. The initial state is Generating. It transitions to the Testing state after the large language model returns generated code; it transitions to the Fixing state when validation fails; it transitions to the Testing state when the optimized generated code re-enters validation; it transitions to the Successful state when validation passes; and it transitions to the Terminated state when the number of iterations is exhausted or the termination condition is met.

[0040] The dynamic allocation logic for the iterative budget is as follows: After each iteration, calculate the difference between the number of anomalies in the current round of verification and the number of anomalies in the previous round. When the difference is negative, the iteration trend is considered convergent, and the current iteration budget is maintained. When the difference alternates between positive and negative in two consecutive rounds, the iteration trend is considered oscillating, and the remaining iteration budget is halved. When the difference is positive and occurs for two consecutive rounds, the iteration trend is considered divergent, the iteration is terminated, the current state is transitioned to the terminated state, and the generated code with the highest number of verification layers passed in the most recent iteration and the corresponding anomaly information are output.

[0041] In this embodiment of the application, in order to evaluate the actual performance of the generated code on the target hardware platform, after outputting the generated code in step S400, the following steps are also included: Step S500: Perform a performance evaluation on the generated code and generate a performance profile.

[0042] On the target hardware platform, the generated code was run using multiple sets of test data with different data types and input sizes, and the execution time corresponding to each set of test data was collected. A speedup matrix was constructed by comparing the execution time of the generated code with the execution time of the baseline serial code, with data type as rows and input size as columns. Based on the speedup matrix, multi-dimensional statistical metrics were calculated, including average speedup, minimum speedup, and speedup variance.

[0043] Weights are assigned to statistical indicators across various dimensions, and a weighted composite score is calculated. This weighted composite score is compared to preset grading thresholds to generate tiered release recommendations. These recommendations include recommended release, conditional release, and not recommended release. The speedup matrix, multi-dimensional statistical indicators, weighted composite score, and tiered release recommendations are combined to create a performance profile, which is then output.

[0044] It should be noted that the weighted composite score The calculation method is as follows: ; in, The average value of all elements in the speedup matrix. This is the minimum value in the speedup ratio matrix. To speed up the process, the standard deviation of all elements in the matrix is ​​normalized to the mean based on the range and then mapped to... The value of the interval, , , These are the weights corresponding to the average speedup, minimum speedup, and speedup stability, respectively. For weighted comprehensive scoring, and satisfying Thus It can reflect the degree of stability of the acceleration ratio.

[0045] Example 2 A high-performance computing team at a research institution needs to implement parallel acceleration for large-scale sparse matrix-vector multiplication (SpMV) on a GPU platform. The target hardware platform used by the team is identified as GPU-A100-SM80, and the computation task requires support for float32 data type, with matrix sizes covering... to The system has an order of 1, with a sparsity of 95%. Team members have a background in numerical computation and submit natural language descriptions through this system, hoping to automatically obtain deployable CUDA parallel code.

[0046] Step S100: Platform constraint loading and prompt word assembly The system receives natural language descriptions submitted by researchers, extracts the target hardware platform identifier GPU-A100-SM80, precisely matches the platform constraint set according to hardware type GPU and version number SM80, and loads three types of constraints. Each constraint is stored in the form of a triple and injected into the corresponding position of the prompt word in descending order of priority. Finally, it is assembled with the natural language description into a structured prompt word.

[0047] Table 1. Platform constraint set loading results

[0048] Step S200: Large Language Model Code Generation The assembled prompts are sent to the large language model via an API call. After recognizing the memory, thread, and instruction set constraints of the GPU-A100-SM80, the large language model generates CUDA parallel code for sparse matrix-vector multiplication. The generated code stores the sparse matrix in CSR format, with each thread block processing one row. Shared memory is used to cache some vector data, and the thread bundle size is set to 32. The generated code is then passed as input to step S300 for subsequent verification.

[0049] Step S301: First round of structural verification The system performs structural verification on the generated code, including syntax parsing and static analysis. This round of verification detected two issues: the shared memory array declaration used the undefined macro constant `BLOCK_DIM`, resulting in an undefined variable exception; and the kernel function's return type did not match the caller's expected type, resulting in a type mismatch exception. The system outputs these two exceptions as structural verification results and terminates both the execution verification and functional verification processes.

[0050] Table 2 Structural verification results

[0051] Step S400 First Iteration: Infrastructure Layer Anomaly Correction The verification results contained anomaly information, prompting the system to initiate iterative optimization. Both anomalies belonged to the compilation failure category in the first level (infrastructure layer anomalies) of the three-level decision tree, and the corresponding correction strategy was to adjust the compilation parameters and regenerate. The system injected correction prompts (undefined variable, type mismatch) and anomaly location into the exception type, and input the large language model to obtain the generated code after the first round of optimization. The iterative state machine transitioned from the correction state to the testing state, entering the second round of incremental verification.

[0052] Steps S301 to S302: Second round of verification The generated code after the first round of optimization passed structural verification (no issues were found in syntax parsing and static analysis). The system then entered the execution verification phase, compiling and running the code in a GPU-A100-SM80 simulation environment. During execution, a memory out-of-bounds exception was detected: when the number of non-zero elements in a matrix row exceeded the shared memory cache capacity, vector data reading exceeded the allocated range. The system captured the exception type (memory out-of-bounds) and the exception location (vector cache read segment) as the execution verification result output, terminating the functional verification.

[0053] Table 3 Summary of Results for Each Layer in the Second Round of Validation

[0054] Step S400 Second Iteration: Code Execution Layer Exception Correction The memory out-of-bounds exception belongs to the second level of the decision tree (code execution layer exception). The corresponding correction strategy is to inject the exception type, exception location, and related code snippets into correction prompts, instructing the large language model to perform local corrections on the vector cache read logic. The system generates correction prompts and inputs them into the large language model to obtain the generated code after the second round of optimization. The iterative state machine transitions back to the testing state. The number of exceptions in this round is 1, which is negative compared to the first round (the number of exceptions is 2), indicating convergence in the iteration trend. The current iteration budget is maintained.

[0055] Steps S301 to S303: Third round of verification The generated code, after the second round of optimization, passed structural and execution verification. The system then entered the functional verification phase, loading a set of test cases for sparse matrix-vector multiplication, covering the float32 data type and three input sizes. The output of the generated code was compared with the expected output; if all comparisons were consistent, a functional verification pass indicator was output. The iterative state machine transitioned to the successful state, and the system output the final generated code.

[0056] Table 4 Comparison Results of Functional Verification Test Cases

[0057] Step S500: Performance Assessment and Tiered Release Recommendations The system evaluates the performance of the final generated code. The generated code is run on a GPU-A100-SM80 using both float32 and float64 data types and three input sizes. Execution times are collected and compared with the execution time of a benchmark serial code to construct a speedup matrix. The matrix elements are arranged with data type as rows and input size as columns.

[0058] Table 5 Speedup Ratio Matrix

[0059] Calculate the average speedup ratio based on the speedup ratio matrix. Minimum acceleration ratio The normalized speedup variance is obtained by summing the speedup variance and then normalizing it. Substitute into the formula Calculate the weighted composite score ,in , , The weights corresponding to the average acceleration ratio, minimum acceleration ratio, and acceleration ratio stability are respectively, and satisfy the following conditions: .Will After comparison with the grading threshold, the grading release recommendation generated in this assessment is recommended for release.

[0060] Table 6 Summary of Performance Evaluation Statistical Indicators

[0061] Throughout the implementation process, data begins with natural language descriptions submitted by researchers. Step S100 loads three platform constraints (GPU-A100-SM80) and assembles them into structured prompts. Step S200 then generates initial code from a large language model. In step S301, the initial code is intercepted by structure verification, and correction prompts carrying anomaly locations drive the first iteration to generate corrected code. After passing structure verification, the corrected code is intercepted by execution verification in step S302, and the anomaly type and location of memory out-of-bounds errors are injected again with correction prompts to drive the second iteration. After passing all three layers of verification, the second iteration code generates a performance profile in step S500, including a speedup matrix, multi-dimensional statistical indicators, and tiered release recommendations. The output of each step serves as the direct input to the next step, ensuring that anomaly information is fully transmitted throughout the iteration chain, guaranteeing the continuity and logical consistency of data flow.

[0062] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0063] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0064] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for automatic generation and iterative optimization of high-performance operators on multiple hardware platforms based on LLM, characterized in that, include: Obtain a natural language description, load the corresponding constraints from the platform constraint set based on the target hardware platform identifier, and assemble the natural language description and the constraints into a prompt word; Input the assembled prompt words into the large language model to obtain the generated code; The generated code is sequentially subjected to structural verification, execution verification, and functional verification. The verification layers are arranged in order of increasing verification cost. When any layer fails verification, the verification of subsequent layers is terminated and the exception information of the current layer is output as the verification result. Based on the verification result, it is determined whether the generated code passes the verification. If it passes, the generated code is output. If it fails, the abnormal information is classified, and a corresponding correction strategy is selected based on the classification result. The correction strategy and the abnormal information are used to assemble correction prompt words and input them into the large language model to obtain the optimized generated code and return to execute the progressive verification.

2. The method for automatic generation and iterative optimization of high-performance operators based on LLM across multiple hardware platforms according to claim 1, characterized in that, The platform constraint set is organized into a two-level directory structure according to hardware type and version number. Each constraint information is represented in the form of a triple. The triple includes constraint category, constraint content, and priority. The constraint category includes memory constraints, thread constraints, and instruction set constraints. When loading the constraint conditions, the constraint conditions are injected into the corresponding positions of the prompt words in order of priority from high to low.

3. The method for automatic generation and iterative optimization of high-performance operators based on LLM across multiple hardware platforms according to claim 1, characterized in that, A multi-level fallback strategy is adopted when loading the constraints: first, it attempts to load constraints that precisely match the target hardware platform identifier; If an exact match fails, the system will roll back and load the default version of the constraints for the same hardware type. If the rollback still fails, the system will return an exception message indicating that the constraints are missing and terminate the process.

4. The method for automatic generation and iterative optimization of high-performance operators based on LLM across multiple hardware platforms according to claim 1, characterized in that, Structural verification includes: performing syntax parsing and static analysis on the generated code to check for syntax errors, undefined variables, and type mismatches. If any problem is detected, the corresponding exception information is output and subsequent verification is terminated. The verification process includes: compiling and running the generated code on the target hardware platform or its simulation environment, monitoring for memory out-of-bounds errors, thread deadlocks, or runtime crashes, and capturing the exception type and location information and terminating subsequent verification if any exception occurs.

5. The method for automatic generation and iterative optimization of high-performance operators based on LLM across multiple hardware platforms according to claim 1, characterized in that, The abnormal information is classified as follows: The first level is infrastructure layer exceptions, including compilation failures and environment configuration errors; The second level consists of exceptions at the code execution level, including memory out-of-bounds errors, thread deadlocks, and runtime crashes. The third level is semantic correctness anomalies, including inconsistencies in output during functional verification.

6. The method for automatic generation and iterative optimization of high-performance operators based on LLM across multiple hardware platforms according to claim 1, characterized in that, The iterative optimization process introduces an iterative state machine, which includes five states: generating, testing, revising, terminated, and successful. The initial state is generating. When the large language model returns the generated code, it transitions to the testing state. When the verification fails, it transitions to the revising state. When the optimized generated code re-enters the verification process, it transitions to the testing state. When the verification passes, it transitions to the successful state. When the number of iterations is exhausted or the termination condition is met, it transitions to the terminated state.

7. The method for automatic generation and iterative optimization of high-performance operators based on LLM across multiple hardware platforms according to claim 1, characterized in that, The iterative optimization process also introduces dynamic allocation of the iterative budget: After each iteration, the difference between the number of anomalies in the current round of verification results and the number of anomalies in the previous round is calculated; when the difference is negative, the iteration trend is determined to be convergent, and the current iteration budget is maintained.

8. The method for automatic generation and iterative optimization of high-performance operators based on LLM across multiple hardware platforms according to claim 1, characterized in that, After outputting the generated code, it also includes: The generated code is run on the target hardware platform using multiple sets of test data with different data types and different input sizes, and the execution time corresponding to each set of test data is collected. The speedup matrix is ​​constructed by dividing the execution time of the generated code into rows with data types and columns with input sizes. Multi-dimensional statistical indicators are calculated based on the speedup matrix.

9. The method for automatic generation and iterative optimization of high-performance operators based on LLM across multiple hardware platforms according to claim 1, characterized in that, Weighted composite score The calculation method is as follows: ,in The average value of all elements in the speedup matrix is ​​given. It is the minimum value in the speedup ratio matrix. The standard deviation of all elements in the speedup matrix is ​​mapped to the mean after mean normalization based on the range. The value of the interval, , , These are the weights corresponding to the average speedup, minimum speedup, and speedup stability, respectively, and satisfy the following conditions: .

Images