Evaluation method, device, equipment and medium for performance optimization of general GPU compiler

Abstract

The present disclosure provides a method, device, equipment and medium for evaluating the performance optimization of a general-purpose GPU compiler, wherein the method includes designing test cases covering various types of programs, screening out stable test cases based on automated tools, setting different weights for different test cases, collecting reliable benchmark data, running the screened stable test cases after compiler optimization, comparing them with the benchmark data, using visualization tools to display the changes in performance data, and supporting tracking of bottlenecks affecting compiler performance in debug mode. It can be seen that the present disclosure has designed a comprehensive and efficient general-purpose GPU compiler performance optimization evaluation solution to solve problems in hardware heterogeneity, compilation time, parallelization, memory access optimization, dependency analysis, debugging support, code generation optimization, library support, etc., to ensure that the evaluation of compiler optimization is accurate, comprehensive, and easy to debug and use.

Description

Technical Field

[0001] The present disclosure relates to the field of data processing, and in particular to a method, device, equipment and medium for evaluating performance optimization of a general-purpose GPU compiler. Background Art

[0002] In heterogeneous computing platforms, the purpose of general GPU compiler optimization is to reduce the execution time, memory usage, storage size, and power consumption of programs by performing a series of optimization transformations on the programs. These optimization transformations are implemented through a series of algorithmic logic that can transform programs into semantically equivalent output programs that use fewer resources or execute faster.

[0003] How to verify whether the performance of the compiler has improved or deteriorated after adding function optimization or modifying functions? This requires a complete evaluation plan to verify the performance changes of the compiler. However, the performance of the compiler after optimization is affected by many factors, such as hardware heterogeneity, compilation time, parallelization, memory access optimization, dependency analysis, debugging support, code generation optimization, and library support. Therefore, how to ensure that the evaluation of compiler optimization performance is accurate, comprehensive, easy to debug and use is an urgent problem to be solved. Summary of the invention

[0004] The object of the present invention is to provide a method, apparatus, device and medium for evaluating performance optimization of a general-purpose GPU compiler, so as to at least partially solve the above-mentioned problems.

[0005] According to one aspect of the present disclosure, a method for evaluating performance optimization of a general-purpose GPU compiler is proposed, comprising:

[0006] Design diverse test cases, covering various types of programs, algorithms and library functions, and introduce the ACL calculation library code base.

[0007] Screen stable test cases, use automated tools to execute test cases multiple times, use statistical methods to evaluate the stability of test cases based on historical operation data, and automatically screen out relatively stable test cases.

[0008] Set weights, at least based on actual application scenarios, importance, and hardware heterogeneity, to set different weights for different types of test cases.

[0009] Collect benchmark data. Collect benchmark data under the same hardware configuration and environment. Use Docker containers to isolate the environment. Warm up the general GPU before the compiler runs. Use the average of multiple runs as the benchmark data. Use the normal distribution method to evaluate the reliability of the benchmark data.

[0010] The compiler applies optimizations. Before the compiler applies optimizations, it performs detailed code analysis to ensure that it understands the code structure, dependencies, and potential optimization points. It applies optimizations step by step, monitoring the performance changes at each step to understand the effect of each optimization point.

[0011] The compiler runs the test cases. When running the test cases, it monitors the memory and temperature indicators and uses the performance counter tool to obtain performance data, including at least the number of instructions executed and the cache hit rate.

[0012] Compare compiler performance data and use visualization tools to show changes in performance data.

[0013] In debug mode, enable detailed logging and performance tracing to locate performance issues, and use the compiler performance analysis tools that come with debug mode to analyze compiler performance bottlenecks during code execution.

[0014] In some embodiments, the method further includes, the designing of diversified test cases further includes selecting a streamlined test case set based on historical test data.

[0015] In some embodiments, the method further comprises that the statistical method comprises standard deviation, mean or median.

[0016] According to another aspect of the present disclosure, a general GPU compiler performance optimization evaluation device is provided, comprising:

[0017] Design module, used to design diverse test cases, covering various types of programs, algorithms and library functions, and introducing the ACL calculation library code base,

[0018] The screening module is used to screen stable test cases. It uses automated tools to execute test cases multiple times, uses statistical methods to evaluate the stability of test cases based on historical operation data, and automatically screens out relatively stable test cases.

[0019] A weight setting module is used to set weights, at least based on actual application scenarios, importance and hardware heterogeneity, to set different weights for different types of test cases.

[0020] The collection module is used to collect benchmark data. Benchmark data is collected under the same hardware configuration and environment. The Docker container is used to isolate the environment. Before the compiler runs, the general GPU is preheated. The average value of multiple runs is used as the benchmark data, and the normal distribution method is used to evaluate the reliability of the benchmark data.

[0021] The application optimization module is used for compiler application optimization. Before the compiler applies optimization, it performs detailed code analysis to ensure that the code structure, dependencies, and potential optimization points are understood. The optimization is applied step by step, and the performance changes of each step are monitored to understand the effect of each optimization point.

[0022] The run module is used by the compiler to run test cases. When running test cases, it monitors memory and temperature indicators and uses performance counter tools to obtain performance data, including at least the number of instruction executions and cache hit rate.

[0023] The comparison module is used to compare compiler performance data and use visualization tools to display performance data changes.

[0024] The debug module is used to enable detailed logging and performance tracking in debug mode, locate performance problems, and analyze compiler performance bottlenecks during code execution using the compiler performance analysis tools that come with debug mode.

[0025] In some embodiments, the apparatus further includes, the designing of diversified test cases further including selecting a streamlined set of test cases based on historical test data.

[0026] In some embodiments, the device further includes that the statistical method includes standard deviation, mean or median.

[0027] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor executes the steps in the method of any of the above embodiments by calling the computer program stored in the memory.

[0028] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program executes the steps in any of the above method embodiments when executed by a processor.

[0029] The present disclosure provides a method, device, equipment and medium for evaluating the performance optimization of a general-purpose GPU compiler, wherein the method includes designing test cases covering various types of programs, screening out stable test cases based on automated tools, setting different weights for different test cases, collecting reliable benchmark data, running the screened stable test cases after compiler optimization, comparing them with the benchmark data, using visualization tools to display the changes in performance data, and supporting tracking of bottlenecks affecting compiler performance in debug mode. It can be seen that the present disclosure has designed a comprehensive and efficient general-purpose GPU compiler performance optimization evaluation solution to solve problems in hardware heterogeneity, compilation time, parallelization, memory access optimization, dependency analysis, debugging support, code generation optimization, library support, etc., to ensure that the evaluation of compiler optimization is accurate, comprehensive, and easy to debug and use. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 A schematic diagram of a method for evaluating performance optimization of a general-purpose GPU compiler provided in an embodiment of the present application.

[0031] Figure 2 A schematic diagram of the changes in compiler performance data provided in an embodiment of the present application.

[0032] Figure 3 A schematic diagram of a general GPU compiler performance optimization evaluation device provided in an embodiment of the present application.

[0033] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0035] In the description of the present invention, it should be understood that the terms "upper", "upper", "lower", "front", "rear", etc., indicating the orientation or positional relationship are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In the description of the invention, "plurality" means two or more, unless otherwise precisely and specifically specified.

[0036] General GPU compiler optimization is widely used. The impact of function optimization or function modification on compiler performance is often difficult to accurately evaluate, because it is often affected by many factors and there are many difficulties in verifying compiler performance changes. For example, adding a loop unrolling optimization function to the compiler will significantly improve the execution of programs containing loops, but it may introduce additional overhead for programs without loops. This is just one of the difficulties. There are other difficulties as follows:

[0037] 1. Hardware heterogeneity: General GPU compilers need to take hardware architecture design into consideration. Each GPU architecture has its own characteristics and different code structures need to be optimized to achieve the best performance.

[0038] 2. Compilation time: Compilation for a large code base can be very time-consuming, especially during iterative development. Compiler performance evaluation needs to consider how to optimize compilation time to improve development efficiency.

[0039] 3. Parallelization: Implementing parallelization in a compiler is a complex task, and performance evaluation needs to focus on whether the generated code effectively utilizes the parallel computing capabilities of the GPU.

[0040] 4. Memory access optimization: In GPU programming, different memory access patterns have a huge impact on performance. Compiler performance evaluation needs to focus on whether memory access latency is effectively minimized and whether appropriate memory hierarchy optimization is adopted.

[0041] 5. Dependency analysis: For large-scale code bases, correctly analyzing dependencies is crucial for optimizing code generation. The compiler needs to accurately understand the dependencies between functions so that they can be executed in parallel effectively.

[0042] 6. Debugging support: Debugging in GPU programming is relatively complex. Performance evaluation needs to consider how to provide effective debugging support so that developers can locate and solve performance problems more quickly and easily.

[0043] 7. Code generation optimization: The compiler needs to be able to generate efficient GPU code, including taking advantage of hardware features, reducing unnecessary instructions, etc. Performance evaluation needs to focus on whether the generated code has achieved the best performance level.

[0044] 8. Code reuse and library support: In general GPU programming, various libraries are usually used to accelerate development, such as cuBLAS, cuFft, cuDNN, etc. Compiler performance evaluation needs to ensure that calls to these libraries are effectively optimized to obtain the best overall performance.

[0045] The existing performance evaluation scheme is simply repeated execution, but this does not understand the hardware characteristics and functions, and the final results may be incorrect. In general, the performance evaluation of general GPU compilers is a complex and challenging task that requires comprehensive consideration of hardware heterogeneity, compilation time, parallelization, memory access optimization, dependency analysis, debugging support, code reuse, and library support.

[0046] Based on this, the present application embodiment provides a method for evaluating the performance optimization of a general-purpose GPU compiler. Figure 1 , including the following steps:

[0047] Step S1, design diversified test cases, which cover various types of programs, algorithms and library functions, and introduce the ACL computing library code base.

[0048] In step S1, different types of use cases are considered, such as compiler features, general benchmark test sets (gpu-benches, gpu-rodinia, etc.), common algorithms such as machine learning algorithms, etc., to ensure the diversity of test cases, and the test of the ACL computing library code base is introduced. ACL (The Arm Compute Library) is an open source high-performance computing library of ARM, which provides a series of computing functions and algorithms, including the implementation of many modern machine learning algorithms, which can be used for tasks in fields such as deep learning; such as Blas (basic linear algebra subroutines), fft (fast Fourier transform), Dnn (deep neural network), etc., to simulate real projects and ensure the performance of the compiler when processing actual projects. For each test case, its input, expected output and actual output are recorded to ensure the comprehensiveness and accuracy of the test case. In some embodiments, based on historical data, a streamlined test set is selected to make debugging easier and find problems faster.

[0049] Step S2, screening stable test cases, using automated tools to execute test cases multiple times, using statistical methods based on historical operation data to evaluate the stability of test cases, and automatically screening out relatively stable test cases.

[0050] In step S2, the stability of the test case is evaluated using statistical methods such as standard deviation, mean, and median. In some embodiments, a variance analysis method (such as ANOVA) is used to perform a more in-depth stability analysis on the performance data of the test case. For each test case, the standard deviation, mean, and other statistical values ​​of its performance data are calculated. In some embodiments, in addition to the standard deviation, other statistical methods, such as mean, median, etc., can be used to evaluate the stability of the test case.

[0051] Step S3, setting weights, at least based on actual application scenarios, importance and hardware heterogeneity, setting different weights for different types of test cases.

[0052] In step S3, weights are set for different types of test cases according to the actual application scenarios and importance of the test cases. Appropriate hardware-related weights are set for each test case according to hardware heterogeneity. Weights are set for each test case to ensure that the weights meet the requirements of actual scenarios and hardware heterogeneity.

[0053] In some embodiments, weights may be set for functional modules and test cases respectively. Table 1 is an example of setting weights for modules. Table 2 is an example of setting weights for test cases.

[0054] Table 1

[0055]

[0056] Table 2

[0057]

[0058] Step S4, collect benchmark data, collect benchmark data under the same hardware configuration and environment, use Docker container to isolate the environment, preheat the general GPU before the compiler runs, use the average value of multiple runs as benchmark data, and use the normal distribution method to evaluate the reliability of the benchmark data.

[0059] In step S4, when collecting benchmark data, ensure that it is performed under the same hardware configuration and environment. You can use Docker containers to eliminate the impact of external factors on performance evaluation. Before running, you need to consider the warmup of the general GPU. Use the average value of multiple runs as the benchmark data to improve the reliability of the data. At the same time, analyze the data of multiple runs and use normal distribution to evaluate whether the benchmark data is reliable.

[0060] Step S5, the compiler applies optimization. Before the compiler applies optimization, it performs detailed code analysis to ensure that the code structure, dependencies, and potential optimization points are understood, and the optimization is applied step by step, monitoring the performance changes of each step to understand the effect of each optimization point.

[0061] In step S5, before applying the optimization, a detailed code analysis is performed to ensure that the code structure, dependencies, and potential optimization points are understood, and the optimization is applied step by step, monitoring the performance changes of each step to understand the effect of each optimization point.

[0062] Step S6, the compiler runs the test case. When running the test case, the compiler monitors the memory and temperature indicators and uses the performance counter tool to obtain performance data, including at least the number of instruction executions and the cache hit rate.

[0063] In step S6, when running the test case, monitor indicators such as memory and temperature to ensure that the hardware performance is fully utilized. Consider using tools such as performance counters to obtain more detailed performance data, such as the number of instruction executions, cache hit rate, etc., so as to comprehensively evaluate the performance changes and impacts.

[0064] Step S7, comparing compiler performance data, and using a visualization tool to display changes in performance data.

[0065] In addition to direct numerical comparison, visualization tools can also be used to display changes in performance data to more intuitively understand the optimization effect. In some embodiments, statistical significance tests are used to ensure that the performance data obtained are statistically significant changes.

[0066] See also Figure 2 ,This embodiment evaluates the changes in compiler performance data under the optimization of each module.

[0067] Step S8, debug mode. In debug mode, detailed logging and performance tracking are enabled to locate performance problems. Compiler performance analysis tools that match the debug mode are used to analyze compiler performance bottlenecks during code execution.

[0068] In step S8, in order to further accurately evaluate and locate factors that affect performance, detailed logging and performance tracking are enabled in debug mode, and a performance analysis tool that matches the debug mode is provided, so as to more accurately locate and analyze compiler performance bottlenecks during code execution.

[0069] It can be seen that the GPU compiler optimization evaluation scheme of this embodiment comprehensively and deeply evaluates the performance of the general GPU compiler through a systematic method, thereby optimizing the program's execution time, memory usage, storage size, and power consumption.

[0070] Accordingly, the embodiment of the present disclosure also provides a general GPU compiler performance optimization evaluation device, such as Figure 3 As shown, the device includes: a design module for designing diversified test cases, the test cases cover various types of programs, algorithms and library functions, and introduces the ACL calculation library code base,

[0071] The screening module is used to screen stable test cases. It uses automated tools to execute test cases multiple times, uses statistical methods to evaluate the stability of test cases based on historical operation data, and automatically screens out relatively stable test cases.

[0072] A weight setting module is used to set weights, at least based on actual application scenarios, importance and hardware heterogeneity, to set different weights for different types of test cases.

[0073] The collection module is used to collect benchmark data. Benchmark data is collected under the same hardware configuration and environment. The Docker container is used to isolate the environment. Before the compiler runs, the general GPU is preheated. The average value of multiple runs is used as the benchmark data, and the normal distribution method is used to evaluate the reliability of the benchmark data.

[0074] The application optimization module is used for compiler application optimization. Before the compiler applies optimization, it performs detailed code analysis to ensure that the code structure, dependencies, and potential optimization points are understood. The optimization is applied step by step, and the performance changes of each step are monitored to understand the effect of each optimization point.

[0075] The run module is used by the compiler to run test cases. When running test cases, it monitors memory and temperature indicators and uses performance counter tools to obtain performance data, including at least the number of instruction executions and cache hit rate.

[0076] The comparison module is used to compare compiler performance data and use visualization tools to display performance data changes.

[0077] The debug module is used to enable detailed logging and performance tracking in debug mode, locate performance problems, and analyze compiler performance bottlenecks during code execution using the compiler performance analysis tools that come with debug mode.

[0078] Among them, the specific steps of the above-mentioned device executing the compiler performance optimization evaluation method can refer to the description in the above-mentioned method embodiment, and will not be repeated here.

[0079] Accordingly, an embodiment of the present application further provides an electronic device, which may be a terminal or a server. Figure 4 As shown, Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0080] The electronic device 400 includes a processor 401 having one or more processing cores, a memory 402 having one or more computer-readable storage media, and a computer program stored in the memory 402 and executable on the processor. The processor 401 is electrically connected to the memory 402. Those skilled in the art will appreciate that the electronic device structure shown in the figure does not limit the electronic device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0081] The processor 401 is the control center of the electronic device 400. It uses various interfaces and lines to connect various parts of the entire electronic device 400, and executes various functions of the electronic device 400 and processes data by running or loading software programs (computer programs) and / or units stored in the memory 402, and calling data stored in the memory 402, thereby monitoring the electronic device 500 as a whole.

[0082] In the embodiment of the present application, the processor 401 in the electronic device 400 will load instructions corresponding to the processes of one or more application programs into the memory 402 according to the following steps, and the processor 401 will run the application programs stored in the memory 402 to implement various functions:

[0083] Design diverse test cases, covering various types of programs, algorithms and library functions, and introduce the ACL calculation library code base.

[0084] Screen stable test cases, use automated tools to execute test cases multiple times, use statistical methods to evaluate the stability of test cases based on historical operation data, and automatically screen out relatively stable test cases.

[0085] Set weights, at least based on actual application scenarios, importance, and hardware heterogeneity, to set different weights for different types of test cases.

[0086] Collect benchmark data. Collect benchmark data under the same hardware configuration and environment. Use Docker containers to isolate the environment. Warm up the general GPU before the compiler runs. Use the average of multiple runs as the benchmark data. Use the normal distribution method to evaluate the reliability of the benchmark data.

[0087] The compiler applies optimizations. Before the compiler applies optimizations, it performs detailed code analysis to ensure that it understands the code structure, dependencies, and potential optimization points. It applies optimizations step by step, monitoring the performance changes at each step to understand the effect of each optimization point.

[0088] The compiler runs the test cases. When running the test cases, it monitors the memory and temperature indicators and uses the performance counter tool to obtain performance data, including at least the number of instructions executed and the cache hit rate.

[0089] Compare compiler performance data and use visualization tools to show changes in performance data.

[0090] In debug mode, enable detailed logging and performance tracing to locate performance issues, and use the compiler performance analysis tools that come with debug mode to analyze compiler performance bottlenecks during code execution.

[0091] The specific implementation of the above operations can be found in the aforementioned embodiments, which will not be described in detail here.

[0092] Optional, such as Figure 4 As shown, the electronic device 400 further includes: an evaluation module 403, a communication module 404, an input unit 405 and a power supply 406. The processor 401 is electrically connected to the interrupt reporting module 403, the communication module 404, the input unit 405 and the power supply 406 respectively. Those skilled in the art can understand that Figure 4 The electronic device structure shown in the figure does not constitute a limitation of the electronic device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0093] The evaluation module 403 may be used to implement the evaluation of general GPU compiler performance optimization.

[0094] The communication module 404 can be used to communicate with other devices.

[0095] The input unit 405 may be used to receive input numbers, character information or user feature information (such as fingerprint, iris, facial information, etc.), and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.

[0096] The power supply 406 is used to supply power to various components of the electronic device 400. Optionally, the power supply 406 can be logically connected to the processor 401 through a power management system, so that the power management system can manage charging, discharging, and power consumption. The power supply 406 can also include one or more DC or AC power supplies, recharging systems, power failure detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0097] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0098] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0099] To this end, an embodiment of the present application provides a computer-readable storage medium, in which a plurality of computer programs are stored, and the computer program can be loaded by a processor to execute the steps of a general GPU compiler performance optimization evaluation method provided in an embodiment of the present application. For example, the computer program can execute the following steps:

[0100] Design diverse test cases, covering various types of programs, algorithms and library functions, and introduce the ACL calculation library code base.

[0101] Screen stable test cases, use automated tools to execute test cases multiple times, use statistical methods to evaluate the stability of test cases based on historical operation data, and automatically screen out relatively stable test cases.

[0102] Set weights, at least based on actual application scenarios, importance, and hardware heterogeneity, to set different weights for different types of test cases.

[0103] Collect benchmark data. Collect benchmark data under the same hardware configuration and environment. Use Docker containers to isolate the environment. Warm up the general GPU before the compiler runs. Use the average of multiple runs as the benchmark data. Use the normal distribution method to evaluate the reliability of the benchmark data.

[0104] The compiler applies optimizations. Before the compiler applies optimizations, it performs detailed code analysis to ensure that it understands the code structure, dependencies, and potential optimization points. It applies optimizations step by step, monitoring the performance changes at each step to understand the effect of each optimization point.

[0105] The compiler runs the test cases. When running the test cases, it monitors the memory and temperature indicators and uses the performance counter tool to obtain performance data, including at least the number of instructions executed and the cache hit rate.

[0106] Compare compiler performance data and use visualization tools to show changes in performance data.

[0107] In debug mode, enable detailed logging and performance tracing to locate performance issues, and use the compiler performance analysis tools that come with debug mode to analyze compiler performance bottlenecks during code execution.

[0108] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0109] The computer-readable storage medium may include: a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0110] Since the computer program stored in the storage medium can execute the steps in any of the general-purpose GPU compiler performance optimization evaluation methods provided in the embodiments of the present application, the beneficial effects that can be achieved by any of the general-purpose GPU compiler performance optimization evaluation methods provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.

[0111] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0112] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0113] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0114] The embodiments of the present invention are described in detail above with reference to the accompanying drawings, but the present invention is not limited to the described embodiments. For those skilled in the art, various changes, modifications, substitutions and variations of these embodiments are made without departing from the principles and spirit of the present invention, and still fall within the scope of protection of the present invention.

Claims

1. A general GPU compiler performance optimization evaluation method, characterized in that: The method comprises: Design diverse test cases, covering various types of programs, algorithms and library functions, and introduce the ACL calculation library code base. Screen stable test cases, use automated tools to execute test cases multiple times, use statistical methods to evaluate the stability of test cases based on historical operation data, and automatically screen out relatively stable test cases. Set weights, at least based on actual application scenarios, importance, and hardware heterogeneity, and set different weights for different types of test cases; Set weights for different types of test cases based on actual application scenarios and importance of test cases; Set appropriate hardware-related weights for each test case based on hardware heterogeneity, and set weights for each test case; Collect benchmark data. Collect benchmark data under the same hardware configuration and environment. Use Docker containers to isolate the environment. Warm up the general GPU before the compiler runs. Use the average of multiple runs as the benchmark data. Use the normal distribution method to evaluate the reliability of the benchmark data. The compiler applies optimizations. Before the compiler applies optimizations, it performs detailed code analysis to ensure that it understands the code structure, dependencies, and potential optimization points. It applies optimizations step by step, monitoring the performance changes at each step to understand the effect of each optimization point. The compiler runs the test cases. When running the test cases, it monitors the memory and temperature indicators and uses the performance counter tool to obtain performance data, including at least the number of instructions executed and the cache hit rate. Compare compiler performance data and use visualization tools to show changes in performance data. In debug mode, enable detailed logging and performance tracing to locate performance issues, and use the compiler performance analysis tools that come with debug mode to analyze compiler performance bottlenecks during code execution.

2. The method according to claim 1, characterized in that: The designing of diversified test cases also includes selecting a streamlined test case set based on historical test data.

3. The method according to claim 1, characterized in that: The statistical methods include standard deviation, mean or median.

4. A general purpose GPU compiler performance optimization evaluation device, characterized in that: The device comprises: Design module, used to design diverse test cases, covering various types of programs, algorithms and library functions, and introducing the ACL calculation library code base, The screening module is used to screen stable test cases. It uses automated tools to execute test cases multiple times, uses statistical methods to evaluate the stability of test cases based on historical operation data, and automatically screens out relatively stable test cases. A weight setting module, used to set weights, at least based on actual application scenarios, importance and hardware heterogeneity, to set different weights for different types of test cases, according to the actual application scenarios and importance of the test cases, to set weights for different types of test cases; according to hardware heterogeneity, to set appropriate hardware-related weights for each test case, and to set weights for each test case; The collection module is used to collect benchmark data. Benchmark data is collected under the same hardware configuration and environment. The Docker container is used to isolate the environment. Before the compiler runs, the general GPU is preheated. The average value of multiple runs is used as the benchmark data, and the normal distribution method is used to evaluate the reliability of the benchmark data. The application optimization module is used for compiler application optimization. Before the compiler applies optimization, it performs detailed code analysis to ensure that the code structure, dependencies, and potential optimization points are understood. The optimization is applied step by step, and the performance changes of each step are monitored to understand the effect of each optimization point. The run module is used by the compiler to run test cases. When running test cases, it monitors memory and temperature indicators and uses performance counter tools to obtain performance data, including at least the number of instruction executions and cache hit rate. The comparison module is used to compare compiler performance data and use visualization tools to display performance data changes. The debug module is used to enable detailed logging and performance tracking in debug mode, locate performance problems, and analyze compiler performance bottlenecks during code execution using the compiler performance analysis tools that come with the debug mode.

5. The device according to claim 4, characterized in that The device also includes: The designing of diversified test cases also includes selecting a streamlined test case set based on historical test data.

6. The device according to any one of claims 4 to 5, characterized in that: The device also includes: The statistical methods include standard deviation, mean or median.

7. An electronic device, characterized in that: It comprises a memory storing executable program code and a processor coupled to the memory; wherein the processor calls the executable program code stored in the memory to execute the method according to any one of claims 1 to 3.

8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 3 is performed.

Images