GPU feature mining analysis method and system based on computer micro-architecture independence

Abstract

The invention discloses a GPU feature mining analysis method and system based on computer micro-system structure independence. The method comprises the steps that a calling sequence of a target application program is analyzed by constructing a target instrumentation library, performance characteristics of multiple levels are extracted, and the performance characteristics are high-level characteristics of the program and are irrelevant to a micro-system architecture of a processor; analyzing the relevance between the performance characteristics and the execution performance of the target application program; according to the obtained relevance, an analysis result is output, and the analysis result reflects the performance bottleneck of the target application program and the corresponding optimization suggestion. According to the method, developers can be helped to adjust and optimize application programs, so that the computing power of the GPU is fully utilized.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and more specifically, to a GPU feature mining and analysis method and system based on computer microarchitecture-independent. Background Art

[0002] Graphics Processing Units (GPUs) are not only used to render high-quality graphics in the gaming and entertainment industries, but also play an important role in computationally intensive applications such as scientific simulations, machine learning, and data analysis. One of the key factors in GPU performance is its microarchitecture, which refers to the internal design and organization of GPU hardware, including computing units, storage hierarchy, cache configuration, etc. Different GPU microarchitectures have a significant impact on the performance and energy efficiency of applications. Therefore, a deep understanding and effective analysis of GPU microarchitecture becomes the key to optimizing GPU application performance.

[0003] In the prior art, there are some tools for GPU feature mining, such as NVIDIA's Nsight, AMD's CodeXL, etc. Existing microarchitecture-related mining tools are usually designed for specific GPU architectures and manufacturers. This means that the same tool may not provide consistent analysis results on different GPU platforms, but requires specific adaptation and optimization for each platform. In addition, due to differences between different GPU architectures and driver versions, microarchitecture-related mining tools may be limited to specific versions. The functions and support of the tools may change with hardware and software updates, and need to be upgraded in time to adapt to the new environment. Microarchitecture-related mining tools provide information about the internal operation and performance characteristics of the GPU, but usually cannot provide complete system-level information. In addition, microarchitecture-related mining tools usually need to be developed and debugged at the underlying hardware and software level. This requires a deep understanding of the GPU architecture and instruction set, as well as debugging and optimization of the hardware and drivers, which increases the complexity of tool development and use, and requires professional knowledge and experience.

[0004] After analysis, it is found that existing GPU feature mining tools mainly focus on the microarchitecture and computing units of the GPU, but fail to capture microarchitecture-independent features such as the number of basic blocks generated by program execution, memory allocation size, CPU and GPU transfer memory size, instruction frequency, and instruction mix. Different microarchitectures have different instruction sets, cache architectures, parallel processing units, and other features. These underlying features have a direct impact on program execution and performance. For example, a common method is performance counter-based analysis. A performance counter is a hardware component used to measure hardware and software performance indicators. By collecting and analyzing the data of these counters, insights into the performance characteristics of a program during execution on the GPU can be obtained. This method is relatively independent of the specific details of the microarchitecture, but it is still necessary to interpret and understand the meaning of the counters according to different microarchitectures. Another method is sampling analysis, which captures the behavior patterns and characteristics of a program by sampling the GPU state and instruction stream at a certain frequency during program execution. This method can provide information about instruction streams, memory access patterns, branch predictions, etc. during program execution, and is relatively independent of the underlying microarchitecture. In addition, static analysis methods can also be used for GPU feature mining that is independent of microarchitecture. Static analysis is the analysis of program code to obtain information about its behavior and performance without actually executing the program. By analyzing the source code, compiler optimization techniques, and algorithm characteristics of GPU programs, some feature mining results that are independent of microarchitecture can be obtained. Despite the existence of the above-mentioned general performance analysis tools and optimization techniques, these solutions still need to consider the characteristics of specific microarchitectures to provide accurate results.

[0005] In summary, existing solutions are usually based on hardware performance counters, sampling analysis, static analysis and other methods, combined with the understanding and modeling of the microarchitecture to draw conclusions on performance analysis and optimization. However, there is currently no GPU feature mining tool that is independent of the microarchitecture. Summary of the invention

[0006] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and provide a GPU feature mining and analysis method and system (or tool) based on computer microarchitecture independent.

[0007] According to a first aspect of the present invention, a GPU feature mining and analysis method based on computer microarchitecture independence is provided. The method comprises the following steps:

[0008] By building a target instrumentation library, the call sequence of the target application is analyzed and multiple levels of performance characteristics are extracted. The performance characteristics are high-level characteristics of the program and are independent of the processor's microarchitecture.

[0009] analyzing a correlation between the performance characteristics and the target application execution performance;

[0010] According to the obtained correlation, an analysis result is output, wherein the analysis result reflects the performance bottleneck of the target application and corresponding optimization suggestions.

[0011] According to a second aspect of the present invention, a GPU feature mining and analysis system based on computer microarchitecture independence is provided. The system comprises:

[0012] Feature extraction module: used to analyze the call sequence of the target application by building a target instrumentation library and extract multiple levels of performance features, which are high-level features of the program and are independent of the processor's microarchitecture;

[0013] Feature analysis module: used to analyze the correlation between the performance feature and the execution performance of the target application program;

[0014] Performance optimization module: used to output analysis results based on the obtained correlations, wherein the analysis results reflect the performance bottlenecks of the target application and corresponding optimization suggestions.

[0015] Compared with the prior art, the advantage of the present invention is that the provided microarchitecture-independent GPU feature mining solution is applicable to the NVIDIA GPU architecture series including Kepler, Maxwell, Pascal and Volta, and is applicable to any pre-compiled CUDA, OpenACC, OpenCL or CUDA-Fortran application. Whether it is for game development, scientific computing or machine learning, developers can use the present invention to gain in-depth understanding of the performance characteristics of applications on different GPUs to help developers adjust and optimize applications and make full use of the computing power of GPUs. In addition, the present invention also provides quantitative data to support decision-making, such as performance optimization strategy selection and system configuration adjustment. Using these data, researchers can make wise decisions to improve the performance and effectiveness of the entire system.

[0016] Further features and advantages of the present invention will become apparent from the following detailed description of exemplary embodiments of the present invention with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.

[0018] Figure 1 is a flow chart of a GPU feature mining and analysis method based on computer microarchitecture independence according to an embodiment of the present invention;

[0019] Figure 2 is a diagram of a micro-architecture independent feature tool construction framework according to an embodiment of the present invention;

[0020] Figure 3 is a schematic diagram of the distribution of Rodinia Instruction Mix according to an embodiment of the present invention;

[0021] Figure 4 is a schematic diagram of Rodinia cache hit rate according to an embodiment of the present invention;

[0022] Figure 5 is a schematic diagram of Rodinia Instruction Frequency distribution according to an embodiment of the present invention;

[0023] Figure 6 2 is a schematic diagram of the distribution of the average value percentage of Rodinia Instruction Frequency according to an embodiment of the present invention. DETAILED DESCRIPTION

[0024] Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that the relative arrangement of components and steps, numerical expressions and numerical values ​​set forth in these embodiments do not limit the scope of the present invention unless otherwise specifically stated.

[0025] Technologies, methods, and equipment known to ordinary technicians in the relevant art may not be discussed in detail, but where appropriate, the technologies, methods, and equipment should be considered as part of the specification.

[0026] In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not limiting. Therefore, other examples of the exemplary embodiments may have different values.

[0027] See also Figure 1 As shown, in general, the provided GPU feature mining and analysis method based on computer microarchitecture independence includes: step S110, by building a target instrumentation library, analyzing the call sequence of the target application and extracting multiple levels of performance characteristics, the performance characteristics are high-level characteristics of the program and are independent of the processor's microarchitecture; step S120, analyzing the correlation between the performance characteristics and the execution performance of the target application; step S130, outputting the analysis results based on the obtained correlation, the analysis results reflect the performance bottlenecks of the target application and corresponding optimization suggestions.

[0028] To implement the idea of ​​the above method, a GPU feature mining tool MICPAT (Micro-architecture Independent Characteristics Profiling Analysis Tool) based on computer microarchitecture is designed. The tool is applicable to NVIDIA GPU architecture series including Kepler, Maxwell, Pascal and Volta, and is applicable to any pre-compiled CUDA, OpenACC, OpenCL or CUDA-Fortran application. MICPAT provides a unified interface and method, enabling developers to perform consistent feature analysis on different GPU platforms, thereby providing information about performance bottlenecks and optimization suggestions to help developers adjust and optimize applications and fully utilize the computing power of the GPU. The innovation of MICPAT is that it provides a feature mining method that is independent of microarchitecture, helping researchers to deeply analyze the performance characteristics of programs, understand the behavioral differences of programs on different GPU microarchitectures, and perform targeted performance optimization.

[0029] In the following, the design process of the feature mining tool MICPAT will be explained in detail, which generally includes setting up the environment, building the model, and running the model.

[0030] 1. Build the environment

[0031] In computer science, microarchitecture-independent features refer to features or properties that are unrelated to the microarchitecture of a computer processor, such as instruction set architecture, pipeline design, cache structure, etc. These features are independent of the specific implementation details of the underlying processor and are universal for program design and optimization.

[0032] Combination Figure 2As shown in the figure, the MICPAT tool is developed based on NVBit, an open source GPU binary code analysis tool developed by NVIDIA Labs. NVBit provides developers with the ability to write custom analysis plug-ins, and developers can expand functions according to specific needs. During the environment construction process, libmicpat.a is a static library file that contains the core functions and implementation of the MICPAT tool. It is a library file that needs to be referenced when compiling and linking the MICPAT plug-in. By linking the libmicpat.a library, developers can use the APIs and functions provided by MICPAT in the plug-in code to implement analysis, conversion, and optimization of GPU binary code. micpat.h is the header file of the MICPAT tool, which contains the declaration of the APIs and functions provided by MICPAT. Developers need to include the micpat.h header file when writing MICPAT plug-ins, and use the functions and structures defined in it to access and operate the functions of MICPAT. Using the micpat.h header file, developers can understand and use the various functions provided by MICPAT, such as registering callback functions, accessing instruction information, and obtaining memory access modes. In summary, libmicpat.a is the core library file of MICPAT, which contains the implementation of the tool; micpat.h is the header file of MICPAT, which provides the API and function declarations required for plug-in development. These two files together form the basic building blocks of the MICPAT tool, allowing developers to build features that are independent of microarchitecture.

[0033] In the MICPAT tool building, nvidiaasm is an important component used to process and analyze GPU assembly instructions. It was added to MICPAT to provide analysis and conversion capabilities at the GPU assembly instruction level. GPU assembly instructions are the lowest-level instructions executed on the GPU, and are very important for in-depth understanding and analysis of the performance characteristics and behaviors of GPU programs. By using nvidiaasm, MICPAT can parse and process GPU assembly instructions and provide analysis, conversion, and optimization capabilities at the instruction level. Specifically, nvidiaasm can parse and extract relevant information about GPU assembly instructions, such as instruction type, operands, register usage, etc. This information is very useful for instruction-level performance analysis and optimization. nvidiaasm can convert and optimize GPU assembly instructions. For example, it can implement optimization techniques such as instruction replacement, instruction insertion, and loop unrolling to improve the performance and efficiency of GPU programs. nvidiaasm can help developers debug at the GPU assembly instruction level, thereby providing tracking and monitoring of the instruction execution process, helping developers locate and solve problems and errors in GPU programs.

[0034] 2. Model Building

[0035] In one embodiment, the extracted features that are independent of microarchitecture mainly include instruction mix, memory hierarchy, basic block count, instruction frequency, and CPU and GPU memory allocation size. These features provide the ability to comprehensively analyze programs from the instruction level, thread level, and memory level, and can evaluate the adaptability of programs to different microarchitectures, find performance bottlenecks, and explore optimization opportunities.

[0036] Specifically, instruction mix refers to the statistical information of the types of instructions used during program execution and their relative frequencies. By analyzing instruction mix, researchers can understand the usage of different types of instructions in a program and thus evaluate the adaptability of the program to the instruction sets of different microarchitectures.

[0037] The number of basic blocks in program execution refers to the number of basic blocks formed during the execution of a program. A basic block is a set of continuous instruction sequences, in which branches only occur at the beginning and end of the block. By analyzing the number of basic blocks, researchers can evaluate the control flow characteristics of the program and understand its control flow processing capabilities for different microarchitectures.

[0038] Instruction frequency refers to the relative execution frequency of each instruction during the program execution process. By analyzing the instruction frequency, we can understand the execution status of each instruction in the program, and thus evaluate the instruction execution efficiency of the program for different microarchitectures.

[0039] The memory hierarchy refers to the access patterns and performance of various storage hierarchies used in a program, such as registers, caches, global memory, etc. By analyzing the memory hierarchy, researchers can understand the adaptability of programs to the memory hierarchies of different microarchitectures, find the bottleneck of memory access and optimize it.

[0040] The CPU and GPU memory allocation size refers to the data size involved in data transfer between the CPU and GPU. By analyzing the CPU and GPU memory allocation size, you can understand the program's needs for data transfer and evaluate its adaptability to memory bandwidth and latency of different microarchitectures.

[0041] The above features focus on high-level characteristics of the program and are independent of the details of the underlying hardware. Therefore, they can provide general insights into program performance and behavior without being restricted by a specific microarchitecture. By analyzing these features, developers can gain a macroscopic view of program performance and identify performance bottlenecks and optimization opportunities. For example, instruction mix can provide information about program instruction types and usage frequency, helping to optimize instruction-level performance; the number of basic blocks and program execution block size can reveal the parallelism and concurrency of the program, providing guidance for parallel optimization.

[0042] 1)Instruction Mix

[0043] Instruction Mix is ​​a feature that measures the proportion of different types of instructions in a program. It provides information about the relative distribution of computation, storage, and control operations in a program. By analyzing instruction mix, users can gain insight into the execution characteristics of a program, identify possible performance bottlenecks, and determine targeted optimization directions. In compute-intensive applications, a high proportion of computational operations in the instruction mix means that the performance of the program may be limited by compute-intensive tasks. By deeply analyzing the type and frequency of computational operations, developers can optimize for these compute-intensive operations to improve the execution efficiency of the program. For example, one optimization strategy is to use more efficient algorithms and data structures for high-frequency computational operations to reduce the complexity and overhead of computational operations. In addition, the performance of computational operations can be further improved by optimizing data access patterns, reducing unnecessary computations, and increasing parallelism.

[0044] In one embodiment, mixed statistics of instruction types in GPU programs, namely Instruction Mix, are implemented. By inserting a call to a counting function before each instruction is executed, the frequency of occurrence of each instruction type during program execution can be counted. Assuming that the range of the opcode is 0-255, a global array instruction_counts is used, whose size is 256 and the initial value is 0. In the count_instruction function, the count of the corresponding opcode is increased by an atomic plus one operation. In the nvbit_at_instruction function, the opcode of each instruction is extracted, and an instruction to call the count_instruction function is inserted. In this way, the count of the corresponding opcode will increase each time the instruction is executed. In the nvbit_at_init function, all elements of the instruction_counts array are cleared to zero in order to perform a new round of instruction counting. In the nvbit_at_term function, the instruction_counts array is traversed and elements greater than 0 are printed. Through this statistical method, developers can understand the usage of various instruction types in GPU programs, thereby optimizing program performance, performing performance analysis, and guiding hardware design.

[0045] After analysis, if the storage or control operations account for a high proportion in the instruction mix, this may indicate that the performance of the program is affected by storage access or control flow. For these situations, developers can improve the performance of the program through strategies such as improving storage access patterns, reducing memory access latency, and optimizing cache utilization. In addition, instruction mixing can also provide information about the overall structure and behavior of the program. For example, if there are a large number of branch instructions, it may mean that there is complex conditional branch logic in the program. By optimizing conditional branches, such as predicting branches, reducing branch frequency, or using more effective branch instructions, the execution efficiency of the program can be improved. In short, instruction mixing, as an important feature, can help developers gain in-depth understanding of the execution characteristics of the program and provide optimization directions. By optimizing different types of instructions, developers can improve the performance of the program, improve the execution efficiency of compute-intensive tasks, and optimize storage access and control flows, thereby achieving more efficient program execution.

[0046] 2)Memory Hierarchy

[0047] For example, the number of cache hits and misses at different levels and the number of accesses to main memory are collected. This can help evaluate the cache utilization and memory access pattern of the program, thereby understanding the number of cache hits and misses and main memory accesses of the program to the memory hierarchy. Cache is a high-speed storage in the memory hierarchy that is used to speed up access to data. Collecting the number of cache hits and misses at different levels can understand the access pattern of the program at each level of cache. A higher cache hit rate indicates that the program effectively utilizes the cache, while a higher number of cache misses may mean that the cache capacity is insufficient or there is a bad access pattern. Main memory is the slowest level in the memory hierarchy, and frequent access to main memory may cause high latency and bandwidth consumption. Collecting the number of main memory accesses can evaluate the degree of dependence of the program on main memory. Fewer main memory accesses usually indicate that the program effectively utilizes the cache, thereby reducing access to main memory. By analyzing these characteristics, it can be seen that a higher cache hit rate and a lower number of cache misses usually indicate that the program makes good use of the memory hierarchy and can effectively use the cache to improve performance. High main memory access times may indicate that the program does not have enough cache capacity or has poor access patterns, and may need to optimize cache strategies or memory access patterns. Comparing feature values ​​under different programs or different optimization strategies can help evaluate and compare their utilization of the memory hierarchy and guide optimization decisions.

[0048] In one embodiment, implementing the collection of memory hierarchy features in MICPAT includes the following steps:

[0049] Step S11, add counters in the MICPAT framework: insert counter logic in key code segments by modifying the code of the MICPAT framework. These counters are used to record the number of cache hits and misses, as well as the number of accesses to the main memory. The user needs to determine the access information of different levels of cache and main memory that needs to be collected, and insert the counter logic in the corresponding position.

[0050] Step S12, update the counter value: During program execution, whenever a cache hit, miss, or main memory access occurs, the corresponding counter value should be updated. The user needs to use the API function provided by MICPAT to embed the counter logic into the target program and update the counter value at the appropriate time.

[0051] Step S13, exporting the collected feature data: After the program is executed, the collected feature data is exported to an external file through the export function provided by the MICPAT framework. These feature data may include the number of cache hits and misses at different levels, and the number of accesses to the main memory.

[0052] Step S14, analyzing characteristic data: The exported characteristic data can be further analyzed and evaluated. Users can use statistical tools or custom scripts to calculate indicators such as cache hit rate, miss rate, and memory access pattern. These indicators will help users understand the program's utilization of the memory hierarchy, evaluate cache utilization, and find possible optimization directions. The core algorithm of this memory hierarchy feature is a cache simulator based on the LRU (least recently used) replacement strategy, which is used to simulate the read and write operations of cache lines under given parameters and count the cache hit rate and miss rate. By analyzing the statistical results, the impact of different cache parameters on program performance can be evaluated and the cache utilization efficiency of the program can be optimized.

[0053] For example, the Memory Hierarchy feature is implemented as a cache simulator, which is mainly used to evaluate the performance of cache systems. The core algorithms include cache_sim_read and cache_sim_writ. In the cache_sim_read algorithm, the index of the cache line is first calculated based on the given address. Then, the corresponding cache line set is found through the index, and the LRU (least recently used) index of the current set is obtained. Next, each cache line in the set is traversed to determine whether there is a cache line with the same address as the given address. If there is a hit, that is, a cache line matching the address is found, the hit flag is set to 1, and the LRU index of the current cache line is updated. If there is a miss, that is, there is no cache line matching the address in the set, the miss counter is incremented by 1, and the given address is stored in the cache line pointed to by the current LRU index, and then the LRU index is updated. Finally, the access counter is incremented by 1, indicating that a cache access is completed. In the cache_sim_write algorithm, it first calls the cache_sim_read algorithm, that is, the read operation is performed first. This is because the write operation needs to first check whether there is a cache line matching the given address in the cache. If it exists, the write operation can be regarded as a hit and the write operation can be performed directly. If it does not exist, the write operation also needs to load the cache line and then perform the write operation.

[0054] In addition to the core algorithm, some global variables are defined to track the state and performance indicators of the cache, such as cache size, line size, associativity, etc. In the initialization function nvbit_at_init, the number of sets is calculated according to the given cache parameters, and memory is dynamically allocated to store the tag array and LRU array. In the terminal function nvbit_at_term, the cache hit rate and miss rate are calculated, and the various performance indicators of the cache are printed out. In general, a cache simulator is implemented to simulate the read and write operations of the cache, and the performance indicators of the cache, such as hit rate and miss rate, are counted. These indicators are of great significance for evaluating and optimizing the performance of the cache system.

[0055] 3) Basic Block Count

[0056] Basic blocks are a microarchitecture-independent feature because they remain unchanged during the execution of a program and are not affected by the underlying hardware microarchitecture. A basic block is a sequence of continuous instructions in a program. It is the smallest execution unit of the code and can only be entered at the beginning instruction and can be left at the end instruction. The formation of basic blocks is divided according to the control flow graph, which visualizes the execution flow of the program as a directed graph, with basic blocks as nodes.

[0057] As a static feature of the program, basic blocks have the same execution behavior under different microarchitectures. This is because the execution of basic blocks depends only on the order of the instruction sequence and the control flow, and has nothing to do with the specific design of the underlying hardware. First, the formation of basic blocks is obtained by static analysis of the program code, and does not involve dynamic execution. Secondly, there are no branch or jump instructions inside the basic block, only a sequence of instructions that are executed sequentially. The execution of basic blocks is not affected by the underlying hardware microarchitecture, and does not involve operations such as pipeline blocking, branch prediction, and cache hits. The execution of basic blocks only needs to be executed one by one in the order of the instruction sequence, and is not affected by the specific design and optimization strategy of the underlying hardware.

[0058] In one embodiment, an algorithm for counting and counting instructions of basic blocks in a CUDA program is implemented. The algorithm uses the plug-in technique to operate on the first instruction of each basic block when the function is loaded to implement the function of instruction counting. The core of the algorithm is two functions: count_instrs and nvbit_at_function_first_load. First, when the function is loaded, the nvbit_at_function_first_load function will be called. This function will obtain the static instruction control flow graph cfg of the current function. Then, by iterating each basic block bb, the first instruction i of the basic block is obtained. Next, the call of the count_instrs function is inserted before this instruction, and some parameters are passed, such as the number of instructions of the basic block bb.instrs.size(), the calculation of the warp level count_warp_level and the basic block identifier local_bb. In this way, the plug-in operation of the instruction counting function is completed.

[0059] Next is the count_instrs function. It is inserted and called at the first instruction of each basic block. The function is to count the number of instructions of the current basic block and store the result in the global variable basic_block_value. Inside the function, first obtain the global warp id and calculate the activity mask of the active thread. Then obtain the lane id of the current thread and determine the id of the first active thread. Then calculate the number of active threads. Only the first active thread performs atomic operations, it will index the global variable basic_block_value according to the basic block identifier bb and add the number of active threads to the corresponding position. Finally, the purpose of the entire algorithm is to count the instructions of each basic block in the CUDA program and store the counting result in the global variable basic_block_value. In this way, the present invention can perform subsequent analysis and use based on these statistical results, such as the execution frequency of the basic block, the hot spot analysis of the instruction, etc.

[0060] As a microarchitecture-independent feature, basic blocks can be used in fields such as program analysis, performance optimization, and code generation. By analyzing the number of basic blocks and optimizing the execution order and structure of basic blocks, the execution efficiency and performance of the program can be improved, and the portability under different microarchitectures can be maintained. The abstract program behavior of basic blocks allows developers to focus more on the algorithm and logic of the program without having to consider too much about the details of the underlying hardware. The analysis results of basic blocks can be used as a guide for performance optimization, and complex basic block structures can be refactored or simplified to improve the execution efficiency and throughput of the program. In addition, the microarchitecture-independent nature of basic blocks also promotes the development of hardware-independent programming, making programs easier to maintain and port, and promoting the portability and reusability of software development.

[0061] 4)Instruction Frequency

[0062] Instruction frequency refers to the execution frequency of different instructions in a program. By analyzing the instruction frequency, we can understand which instructions in the program are frequently executed and which are executed less frequently, which helps to determine the optimization strategy at the instruction level, such as optimizing frequently executed instructions to improve the overall execution efficiency. Instruction frequency has the characteristics of being independent of microarchitecture, because it is related to the semantics and execution logic of the instructions, but not to the details of the underlying hardware. The calculation of instruction frequency is based on the static analysis of the program, and the execution frequency is obtained by counting the number of times different instructions appear in the code. This process does not depend on the specific design and execution characteristics of the underlying hardware. Regardless of the microarchitecture, the instruction sequence in the program code is fixed, and the semantics and execution logic of the instructions are also unchanged. Therefore, as a static feature of the program, instruction frequency has the same properties under different microarchitectures. The microarchitecture-independent nature of instruction frequency is of great significance for program analysis and optimization. First, by analyzing the instruction frequency, we can understand which instructions in the program are frequently executed and which are executed less frequently. This frequency information can guide the formulation of optimization strategies. Optimizing frequently executed instructions, such as using more efficient algorithms, data structures, or instruction reordering, can improve program execution efficiency. Secondly, instruction frequency analysis can reveal program execution characteristics and performance bottlenecks, helping to discover and resolve performance bottlenecks. By adjusting instruction-level optimization strategies, the overall performance of the program can be improved.

[0063] In one embodiment, an algorithm for counting instruction execution frequency in a GPU program is implemented. The algorithm counts instructions that meet specific conditions by inserting a call to a counting function before the instruction is executed, and stores the result in a global array. First, a constant MAX_OPCODES is defined to represent the maximum number of opcodes, and its value is 16*1024. Then, a global array frequency is declared to record the execution frequency of each opcode, and the array size is MAX_OPCODES. Next, a count_instrs function is defined to perform instruction counting. The function obtains the active thread mask active_mask, which indicates which threads are currently active. Then, the thread mask predicate_mask that meets the condition is calculated according to a given condition. The laneid of the current thread is obtained, indicating the position of the thread in the warp. The first_laneid of the first thread in the active thread is calculated, and the number of threads that meet the condition, num_threads, is calculated. In the conditional judgment, if the laneid of the current thread is equal to the first_laneid of the first thread in the active thread, the instruction counting operation is performed. If the warp-level instruction count needs to be calculated and the number of threads that meet the condition is greater than 0, use an atomic operation to add one to frequency[instr_type]; otherwise, add the number of threads that meet the condition to frequency[instr_type]. An instruction to call the count_instrs function is inserted before each instruction i, and constant parameters 1, instr_type, and count_warp_level are added. The algorithm implements frequency counting by inserting a call to the counting function before instructions that meet specific conditions, and stores the result in a global array.

[0064] The microarchitecture-independent nature of instruction frequency also plays an important guiding role in compiler optimization and code generation. The compiler can analyze instruction frequency to perform optimization operations such as instruction scheduling, register allocation, and code reordering to improve the execution efficiency and performance of the generated machine code. Based on the information of instruction frequency, the compiler can reasonably arrange the execution order of instructions and reduce the dependencies between instructions, thereby improving instruction-level parallelism and overall execution efficiency. In addition, the microarchitecture-independent nature of instruction frequency also promotes the portability and reusability of programs. By performing instruction frequency analysis on different microarchitectures and optimizing based on the results, developers can write more versatile and portable code. The results of instruction frequency analysis can help developers understand the performance characteristics of the program, optimize high-frequency instructions, and maintain consistent performance on different microarchitectures. This microarchitecture-independent optimization strategy can reduce dependence on underlying hardware details and improve code reusability and maintainability. The microarchitecture-independent nature of instruction frequency also plays an important guiding role in compiler optimization and code generation. The compiler can use the information of instruction frequency to perform optimization operations such as instruction scheduling, register allocation, and code reordering to improve the execution efficiency and performance of the generated machine code. By properly arranging the execution order of instructions and reducing the dependencies between instructions, the compiler can increase instruction-level parallelism and thus improve overall execution efficiency.

[0065] 5)Memory Allocation Size

[0066] The memory transfer size between the CPU and GPU refers to the size of data involved when data is transferred between the CPU and GPU. First, the CPU and GPU memory transfer size is closely related to the data processing of the program. In GPU computing, data is usually transferred from the host memory (CPU memory) to the device memory (GPU memory), or from the device memory back to the host memory. The size of these data transfers directly affects the time and cost of the transfer. By statically analyzing the program code, users can determine the memory transfer size between the CPU and GPU to understand the scale and frequency of the transfer. Secondly, the CPU and GPU memory transfer size is closely related to the relationship between data parallelism and computing load. In data-intensive computing, a large amount of data needs to be transferred between the CPU and GPU for parallel computing. By analyzing the memory transfer size, users can understand the flow of data between the CPU and GPU, thereby guiding the optimization strategy of the program. For example, for programs that frequently perform data transfer, you can consider using technologies such as data reuse, data compression, or data sharding to reduce the amount of data transferred, thereby reducing the cost of transmission.

[0067] In one embodiment, an algorithm for capturing different CUDA events through a callback function nvbit_at_cuda_event during the execution of a CUDA application is implemented. According to the type of event (cbid), the corresponding operation is performed. Specifically, when cbid is API_CUDA_cuMemAlloc_v2, it indicates that a CUDA memory allocation operation has occurred. The callback function tracks the number of allocations and adds the allocated memory address and size to tracking_map. When cbid is API_CUDA_cuMemFree_v2, it indicates that a CUDA memory release operation has occurred. The callback function tracks the number of releases and deletes the corresponding memory address from tracking_map. When cbid is API_CUDA_cuMemcpyHtoD_v2, it indicates that a memory copy operation from the host to the device has occurred. The callback function prints relevant information. In general, by tracking memory allocation and release operations and recording relevant information during the execution of a CUDA application, program performance can be further analyzed and debugged.

[0068] In addition, the size of CPU and GPU memory transfers is also of great significance for program performance optimization. Data transfer is usually one of the bottlenecks of compute-intensive programs because data transfer consumes time and bandwidth. By analyzing the transfer size, users can determine the bottleneck of data transfer and optimize it in a targeted manner. For example, data compression, asynchronous transmission, data prefetching and other technologies can be used to reduce the time and cost of transmission, thereby improving the execution efficiency of the program. Finally, the microarchitecture-independent nature of CPU and GPU memory transfer sizes also promotes the portability and reusability of programs. Since the memory transfer size is related to the data processing of the program, different sizes of memory transfers may be required for the same program and data set on different microarchitectures. By statically analyzing the program code, the memory transfer size under different microarchitectures can be obtained, thereby guiding the formulation of optimization strategies. This microarchitecture-independent optimization strategy can reduce the dependence on the underlying hardware details and improve the portability and maintainability of the code.

[0069] 3. Run the model

[0070] For example, when using MICPAT for compilation and runtime, first, you need to prepare the environment, that is, install the MICPAT tool in the CUDA development environment. Next, the developer needs to write an instrumentation source file, which contains the instrumentation logic for the target CUDA function. This instrumentation source file describes the functions that need to be analyzed and modified and the related operations. Then, use the compiler tools provided by MICPAT to compile the instrumentation source file into a target instrumentation library. This library contains the binary code for the instrumentation logic. At the same time, use the compiler tools provided by MICPAT to compile the target CUDA application into a binary executable file. This compilation process will link the target application with the MICPAT runtime library.

[0071] When running the target application, specify the path of the target instrumentation library as the library to be preloaded by setting the LD_PRELOAD environment variable. LD_PRELOAD is an environment variable for the dynamic linker that allows developers to preload the specified shared library when the program is loaded. The role of LD_PRELOAD is to load the specified shared library into the address space of the process when the application is loaded, and load it before other libraries. In this way, the function implementation in the target instrumentation library will override the system default function implementation, thereby implementing the instrumentation of the CUDA function. Library function linking is the process of associating the application with the required library function. During the compilation process, the compiler matches the function call with the library function to ensure that the program can call the required function. The library function can be a static link library (.a file) or a dynamic link library (.so file). .so file refers to a dynamic link library file that contains compiled binary code and function symbols. It can be loaded into the address space of the process at runtime and parsed and linked by the dynamic linker. By using LD_PRELOAD to load a .so file, you can preload the specified library at runtime, thereby modifying the behavior of the application without modifying the source code.

[0072] Static link libraries are copied into the final executable file during compilation, so the executable file contains all the required function codes. This makes the executable file relatively independent and does not rely on external library files. However, the disadvantage of static link libraries is that they increase the size of the executable file and cause code duplication when the same library functions are used in multiple executable files. Dynamic link libraries are loaded into the address space of the process at runtime and parsed and linked by the dynamic linker. This allows multiple executable files to share the same library file, reducing code redundancy. The extension of the dynamic link library is usually .so (on Linux and Unix systems) or .dll (on Windows systems). When LD_PRELOAD is used to load a .so file, it preloads the specified library into the address space of the application at runtime. This allows developers to change the behavior of the application by replacing or redirecting specific functions without modifying the original application. The LD_PRELOAD mechanism is very useful for instrumenting and debugging applications. By setting the LD_PRELOAD environment variable, developers can load the specified .so file into the application and overwrite the function implementation in the original application. This allows developers to modify the behavior of an application at runtime, adding custom logic, profiling code, memory allocation tracking, and more, without having to modify the source code.

[0073] It is important to note that LD_PRELOAD only affects function calls that are resolved through the dynamic linker. LD_PRELOAD will not take effect for functions that are called directly or statically linked. In addition, libraries loaded with LD_PRELOAD may introduce different versions of function implementations, which may cause symbol conflicts or inconsistent behavior. Therefore, you need to be careful when using LD_PRELOAD to ensure that the library file is compatible with the target application and that symbol resolution and linking issues are handled correctly.

[0074] 4. Experimental Verification Results

[0075] In order to further understand the effect of the present invention, experimental verification was carried out. The operating environment of the experiment is Ubuntu 18.04 operating system, NVIDIA driver version is 418.40, CUDA version is 10.2, and LLVM version is 7.0. During the construction process, the environment variables of MICPAT_ROOT, LLVM_HOME and CUDA_HOME are added to the PATH environment variable of the system. Then, the sample code designed by MICPAT is used for verification.

[0076] 1)Instruction Mix Feature Analysis

[0077] The Rodinia benchmark suite contains a series of applications and kernels that can be used to evaluate the performance and effectiveness of parallel computing systems. The Rodinia suite covers applications in multiple fields, including image processing, data mining, physical simulation, graph algorithms, etc. This paper analyzes the Instruction Mix feature of the Rodinia program in detail, and conducts in-depth optimization analysis based on this, aiming to improve the execution efficiency and performance of the program.

[0078] Figure 3 This is a schematic diagram of the Rodinia Instruction Mix distribution. Figure 3 It can be seen that: First, the Integer instruction type accounts for the highest proportion, reaching 37.18%, which indicates that there are a large number of integer operations in the Rodinia program. In view of this feature, integer optimization techniques, such as loop unrolling and bit operation optimization, can be considered to improve the integer calculation efficiency of the program. Secondly, the Floating Point instruction type accounts for 15.58%, which is relatively low, but there is still a certain proportion of floating-point operations. In view of this feature, floating-point operation optimization techniques can be used, such as using SIMD instruction sets and reducing unnecessary floating-point operations, to improve the floating-point calculation performance of the program. In addition, the Control instruction type accounts for 10.21%, indicating that there is a certain proportion of control flow instructions in the program, such as conditional branches and loops. In view of this feature, it is possible to consider optimizing algorithms and control flow structures to reduce branch prediction errors and improve the control flow efficiency of the program. At the same time, the Movement instruction type accounts for 14.89%, indicating that there are more data movement operations in the program, such as data loading and storage. In view of this feature, the data access mode and memory layout can be optimized to reduce data movement and improve data access efficiency. The proportion of other instruction types (Vector, Conversion, Predicate, Texture, Compute Load / Store Instructions, Surface Memory, Miscellaneous) is relatively low, indicating that instructions in these areas are less used.

[0079] 2) Memory Hierarchy Feature Analysis

[0080] The Memory Hierarchy feature simulates the working principle of the cache by using data structures and algorithms, including the judgment of cache hits and misses, replacement strategies, etc., without relying on specific hardware implementations. This means that consistent cache behavior simulation can be provided regardless of the microarchitecture or hardware platform on which it runs. Therefore, developers can perform cache performance evaluation, algorithm optimization, and system design in different environments without being restricted by a specific microarchitecture. This microarchitecture-independent feature makes the code more widely applicable and portable.

[0081] Figure 4 This is a diagram of Rodinia cache hit rate. First, different Rodinia programs perform differently in cache hit rate. The cache hit rate of each program fluctuates within a certain range, ranging from the lowest 36.21% (nw) to the highest 99.22% (huffman). On average, the cache hit rate of these Rodinia programs is about 50%. Among them, some programs have a cache hit rate slightly higher than 50%, such as bfs (51.69%), dwt2d (71.26%), and leukocyte (99.22%). The cache hit rate of other programs is slightly lower than 50%, such as kmeans (37.09%), particlefilter (44.50%), and cfd (37.91%). Second, several programs show a high cache hit rate, such as huffman (99.22%) and lavaMD (94.31%), which means that they are able to effectively utilize the cache and reduce access to main memory. Finally, some other programs have lower cache hit rates, such as kmeans (37.09%), particlefilter (44.50%), and cfd (37.91%). This may be because the memory access patterns of these programs are more complex, or the data access patterns are not localized enough, resulting in more cache misses. The Memory Hierarchy feature uses the least recently used LRU replacement strategy to manage data blocks in the cache. By maintaining the LRU counter for each data block, the least recently used block can be determined and replaced to maintain efficient use of the cache. It has been proven that the Memory Hierarchy feature helps to analyze and evaluate the performance of the cache, further understand the behavior of the cache, optimize the algorithm or system design, and thus improve the performance and efficiency of the program.

[0082] 3) Basic Block Count feature analysis

[0083] Basic Block Count reflects the control flow complexity of a program. If a program has a large number of basic blocks, it means that the control flow of the program is complex and contains multiple branches and jump statements. This may lead to an increase in branch prediction errors, thereby affecting the performance of the program. Basic Block Count can help understand the structure and logic of the program. By analyzing the number and order of basic blocks, the control flow graph of the program can be obtained, and the dependencies and execution order between different parts of the program can be understood. Table 1 is an example of the statistics of the number of basic blocks.

[0084] Table 1 Number of Rodinia basic blocks

[0085]

[0086] According to the statistical results of the number of basic blocks of Rodinia programs listed in Table 1. The number of basic blocks is one of the important indicators for measuring program complexity and structure. It can be observed from Table 1 that there are significant differences in the number of basic blocks between different Rodinia programs. For example, the backprop program has only 3 basic blocks, while the myocyte program has 702 basic blocks, which is a huge difference between the two. This shows that different programs have obvious differences in structure, involving different algorithms or implementation methods. Secondly, there may be a certain correlation between the number of basic blocks and the computational complexity and parallelism of the program. A smaller number of basic blocks means that the program is simpler and the computational tasks are relatively simple, while a larger number of basic blocks means that the program is more complex, involving more computational tasks and data dependencies. This has important guiding significance for program performance optimization and parallel design. Programmers can adjust the optimization strategy according to the difference in the number of basic blocks, and choose appropriate optimization methods and parallel modes for different program structures. In addition, the number of basic blocks can also reflect the control flow and loop structure in the program. For example, programs with a large number of basic blocks often contain more complex conditional judgments and loop structures, requiring more sophisticated control flow analysis and optimization. This is very important for improving program performance and maintainability.

[0087] In summary, based on the basic block number analysis of Rodinia programs, we can obtain important information about program complexity, computational complexity, parallelism, and control flow. This helps the decision-making process of program optimization and parallelization design, and provides a useful reference for improving program performance and efficiency.

[0088] 4)Instruction Frequency Feature Analysis

[0089] Instruction Frequency is an indicator that measures the frequency of use of various instruction types during program execution. By analyzing the instruction frequency of Rodinia programs, we can understand the usage of different instruction types in the program, thereby revealing the program's computing characteristics and performance bottlenecks.

[0090] Figure 5 Based on the instruction frequency data of each program in the Rodinia benchmark set, the following conclusions can be drawn. First, there are obvious differences in instruction frequency between different Rodinia programs. The instruction usage patterns of different programs are different, reflecting their computing characteristics and algorithm design. For example, more than 40% of the instruction frequencies in the hotspot3D program are concentrated in the range of [40%, 100%], while more than 50% of the instruction frequencies in the cfd program are concentrated in the range of [20%, 30%] and [40%, 100%]. Second, some programs have higher instruction frequencies concentrated in a narrower range, indicating that these programs are more intensively executed on specific types of instructions. For example, more than 60% of the instruction frequencies in the srad_v1 program are concentrated in the range of [0%, 5%], indicating that the program mainly relies on a few types of instructions for calculation. In addition, some programs have relatively balanced instruction frequency distributions. For example, the backprop and particlefilter programs have a certain proportion of usage in different instruction frequency ranges, without an obvious concentration trend. This shows that these programs have relatively balanced computing needs on different types of instructions. Finally, some programs have lower instruction frequencies, especially in the range of [0%, 5%] and [5%, 10%]. This indicates that these programs use less instruction types, perhaps because their computational process is simpler or they use more efficient computational techniques or optimization strategies.

[0091] Figure 6 is the average distribution of the average instruction frequency of all Rodinia programs in each interval. Figure 6 It can be seen that the average values ​​of the higher frequency intervals ([10%, 20%), [20%, 30%) and [30%, 40%) are relatively low, while the average values ​​of the lower frequency intervals ([0, 5%) and [5%, 10%) are relatively high. This shows that the instructions in the higher frequency intervals are used less frequently in the program, while the instructions in the lower frequency intervals are used more frequently. The trend of the average value reflects the overall distribution of instruction usage. From the experimental data, it can be seen that the instruction frequency gradually decreases with the increase of the interval, showing a decreasing trend. This shows that in the Rodinia program, the use of instructions is more concentrated in the lower frequency interval, and as the frequency interval increases, the use of instructions gradually decreases.

[0092] In summary, based on the instruction frequency analysis of Rodinia programs, we can derive the instruction usage patterns and characteristics of different programs. This is of great significance for understanding the computational characteristics, performance bottlenecks, and optimization potential of programs. Based on the instruction frequency interval and average value analysis of Rodinia programs, we can derive the instruction usage and distribution characteristics of different frequency intervals. Through further research and analysis, we can propose targeted optimization strategies based on the instruction frequency characteristics of different programs to improve the execution efficiency and performance of the programs.

[0093] 5) Memory Allocation Size Feature Analysis

[0094] Memory management is critical to optimizing the performance and efficiency of the GPU, and the Memory Allocation Size feature can track memory allocation and release operations in the program. This is very important for understanding the memory usage of the program, detecting memory leaks, and optimizing memory management. By recording the addresses, ordinals, and sizes of allocated and released memory blocks, memory usage analysis and performance tuning can be performed. In the callback functions of memory allocation and release, the Memory Allocation Size feature prints information about memory operations, including the addresses and sizes of allocated / released memory blocks. This is very useful for real-time monitoring and debugging memory operations during program execution. Developers can view the printed information to understand the order in which memory operations occur, the location of the operations, and the memory sizes involved to help identify memory problems and optimize memory usage.

[0095] By analyzing the experimental results, the following conclusions can be drawn. First, in terms of memory allocation, the "Foundan allocation!" statement is printed to indicate that a memory allocation operation has been found. Each time a memory allocation is found, the address and size of the allocated memory block are printed. For example, the first print statement shows that a memory block of 67186720 bytes (about 64MB) is allocated at the address 0x7f028e000000. Subsequent print statements also show other memory allocation operations, and the sizes and addresses of the allocations are also different. Second, in terms of memory copy HtoD, the analysis results also show the copy operation of memory from the host to the device, which is indicated by printing the "Encountered a memcpy HtoD!" statement. Each time this operation is encountered, the source memory address, the target device memory address, and the number of bytes copied are printed. For example, the first print statement shows the operation of copying 67186720 bytes of data from the host address 0x7f02a3fec010 to the device address 0x7f028e000000. In addition, in terms of memory release, the code indicates that a memory release operation has been found by printing the statement "Found a free!". Each time a memory release is found, the address of the memory block being released is printed. For example, the first print statement shows that the memory block at address 0x7f0292200000 is released. Finally, in terms of memory tracking records, the analysis results also include the printing of memory tracking records. By printing the contents of tracking_map, the address, sequence number, and size of the tracked memory block are displayed. Each print will display information about all tracked memory blocks.

[0096] In summary, by tracking and recording memory allocation, release, and copy operations in CUDA programs and printing relevant information about these operations, developers can understand the memory usage of the program and locate memory problems, such as memory leaks, repeated releases, or uninitialized memory accesses. In addition, the information recorded can also be used to further analyze and optimize the program's memory management to improve performance and efficiency. Optimizing memory management strategies and reducing the frequency of memory allocation and release operations can reduce memory consumption and improve program performance. Secondly, for frequent data transfer operations, the overhead of data transfer can be reduced by using more efficient data transfer technologies, data compression, or data reuse. Finally, for algorithms with frequent data exchange, data locality optimization can be considered in the design phase to reduce the number of data transfers between the host and the device.

[0097] In summary, the present invention can provide a GPU feature mining and analysis system (or tool) based on computer microarchitecture independence, which is used to implement one or more aspects of the above method. For example, the system includes: a feature extraction module, which is used to analyze the call sequence of the target application by building a target instrumentation library, and extract multiple levels of performance features, wherein the performance features are high-level features of the program and are independent of the processor's microarchitecture; a feature analysis module, which is used to analyze the correlation between the performance features and the execution performance of the target application; a performance optimization module, which is used to output analysis results based on the obtained correlation, wherein the analysis results reflect the performance bottlenecks of the target application and the corresponding optimization suggestions.

[0098] It should be noted that, without violating the spirit and scope of the present invention, those skilled in the art may make appropriate changes or modifications to the above embodiments. For example, it can be further extended to adapt to other GPU architectures and provide performance optimization tools for developers of different architectures. In addition, the feature mining method of MICPAT can also be applied to the following fields, including but not limited to:

[0099] 1) In the fields of high-performance computing, data analysis, and machine learning, MICPAT's feature extraction and analysis methods can be used to evaluate the adaptability and performance characteristics of algorithms or models in different hardware environments, thereby guiding optimization decisions.

[0100] 2) MICPAT can be used as a teaching and research tool to help students and researchers gain a deeper understanding of the performance characteristics of GPU programs and microarchitecture-related factors.

[0101] 3) The feature analysis results of MICPAT can be used for performance tuning and software optimization. Developers can improve programs in a targeted manner based on the macro view and performance bottleneck identification provided by MICPAT, optimize the performance of instruction level, parallelism, memory access, etc., to improve the overall performance of the program.

[0102] The present invention may be a system, a method and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present invention.

[0103] Computer readable storage media can be tangible devices that can hold and store instructions used by instruction execution devices. Computer readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the above.

[0104] Embodiments of the present invention have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the marketplace, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein. The scope of the present invention is defined by the appended claims.

Claims

1. A GPU feature mining and analysis method based on computer microarchitecture-independent, comprising the following steps: By building a target instrumentation library, the call sequence of the target application is analyzed and multiple levels of performance characteristics are extracted. The performance characteristics are high-level characteristics of the program and are independent of the processor's microarchitecture. analyzing a correlation between the performance characteristics and the target application execution performance; According to the obtained correlation, an analysis result is output, wherein the analysis result reflects the performance bottleneck of the target application and corresponding optimization suggestions.

2. The method according to claim 1, characterized in that The performance characteristics cover three levels: instruction level, thread level and memory level, including instruction mix, number of program execution basic blocks, instruction frequency, memory hierarchy, and CPU and GPU memory allocation size. The instruction mix represents the statistical information of the instruction types used during program execution and their relative frequencies; the number of program execution basic blocks represents the number of basic blocks formed during the execution of the program; the instruction frequency represents the relative execution frequency of each instruction during the execution of the program; the memory hierarchy represents the access mode and performance of each storage hierarchy used by the program; the CPU and GPU memory allocation size represents the data size involved in data transmission between the CPU and the GPU.

3. The method according to claim 2, characterized in that The storage hierarchy includes register, cache and global memory levels. For the memory hierarchy, the number of cache hits and misses at different levels and the number of accesses to the main memory are collected.

4. The method according to claim 1, characterized in that: The target application includes a CUDA, OpenACC, OpenCL, or CUDA-Fortran application, and the microarchitecture is an NVIDIA GPU architecture family including Kepler, Maxwell, Pascal, or Volta.

5. The method according to claim 2, characterized in that: For the performance bottleneck of the instruction mix, the corresponding optimization suggestions include improving storage access mode, reducing memory access latency, optimizing cache utilization, optimizing conditional branches, and optimizing instruction types; for the performance bottleneck of the number of basic blocks of program execution, the corresponding optimization suggestion is to optimize the execution order and structure of basic blocks; for the performance bottleneck of the instruction frequency, the corresponding optimization suggestion is to perform instruction scheduling, register allocation or code reordering based on instruction frequency information; For the performance bottleneck of the memory hierarchy, the corresponding optimization suggestions include: optimizing memory management strategy, optimizing memory access mode, reducing memory allocation, reducing the frequency of release operations, data compression, data reuse, data locality optimization, reducing the number of data transmissions between the host and the device, one or more of the following; for the performance bottleneck of the CPU and GPU memory allocation size, the corresponding optimization suggestions include one or more of data reuse, data compression, data sharding, asynchronous transmission, and data prefetching.

6. The method according to claim 5, characterized in that During the feature extraction process, for the memory hierarchy, a least recently used LRU replacement strategy is used to manage the data blocks in the cache, and a least recently used block is determined for replacement by maintaining an LRU counter for each data block.

7. The method according to claim 3, characterized in that For the memory hierarchy, collecting the number of cache hits, the number of misses, and the number of accesses to the main memory at different levels includes: For the target application, the counter logic is embedded in the set position by using the API function. The counter is used to record the number of cache hits and misses, as well as the number of accesses to the main memory. During program execution, whenever a cache hit, miss, or main memory access occurs, the corresponding counter value is updated; After the program is executed, the collected characteristic data of the number of cache hits and misses at different levels and the number of accesses to the main memory are exported to an external file; Use statistical tools or custom scripts to further analyze and evaluate the exported feature data, including calculating cache hit rates, miss rates, and memory access patterns.

8. A GPU feature mining and analysis system based on computer microarchitecture independence, comprising: Feature extraction module: used to analyze the call sequence of the target application by building a target instrumentation library and extract multiple levels of performance features, which are high-level features of the program and are independent of the processor's microarchitecture; Feature analysis module: used to analyze the correlation between the performance feature and the execution performance of the target application program; Performance optimization module: used to output analysis results based on the obtained correlations, wherein the analysis results reflect the performance bottlenecks of the target application and corresponding optimization suggestions.

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

10. A computer device comprising a memory and a processor, wherein a computer program capable of running on the processor is stored in the memory, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

Images