GPU feature mining and analysis method and system based on computer microarchitecture independence

Abstract

Disclosed in the present invention are a GPU feature mining and analysis method and system based on computer microarchitecture independence. The method comprises: building a target instrumentation library, analyzing a calling sequence of a target application program, and extracting a plurality of levels of performance features, wherein the performance features are high-level features of a program and are independent of a microarchitecture of a processor; analyzing a correlation between the performance features and execution performance of the target application program; and outputting an analysis result according to the obtained correlation, wherein the analysis result reflects a performance bottleneck of the target application program and a corresponding optimization suggestion. The present invention can help developers to adjust and optimize application programs, so as to fully use computing capabilities of GPUs.

Description

GPU feature mining and analysis method and system based on computer microarchitecture independence Technical Field

[0001] The present invention relates to the field of computer technology, and more particularly to a method and system for mining and analyzing GPU features that are independent of computer microarchitecture. 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 a vital role in computationally intensive applications such as scientific simulations, machine learning, and data analysis. A key factor in GPU performance is its microarchitecture, which refers to the internal design and organization of GPU hardware, including compute units, memory hierarchy, and cache configuration. Different GPU microarchitectures significantly impact application performance and energy efficiency. Therefore, a deep understanding and effective analysis of GPU microarchitecture are crucial for optimizing GPU application performance.

[0003] Several tools exist for GPU feature mining, such as NVIDIA's Nsight and AMD's CodeXL. Existing microarchitecture-specific mining tools are typically designed for specific GPU architectures and vendors. This means the same tool may not provide consistent analysis results across different GPU platforms, requiring platform-specific adaptation and optimization. Furthermore, due to differences between different GPU architectures and driver versions, microarchitecture-specific mining tools may be limited to specific versions. Tool functionality and support may change with hardware and software updates, requiring timely upgrades to adapt to new environments. Microarchitecture-specific mining tools provide information about GPU internal operations and performance characteristics, but typically cannot provide complete system-level information. Furthermore, microarchitecture-specific mining tools often require development and debugging at the low-level hardware and software levels. This requires a deep understanding of the GPU architecture and instruction set, as well as hardware and driver debugging and optimization, increasing the complexity of tool development and use and requiring specialized knowledge and experience.

[0004] Analysis reveals that existing GPU feature mining tools primarily focus on the GPU's microarchitecture and compute units, failing to capture microarchitecture-independent features such as the number of basic blocks, memory allocation size, CPU-GPU memory transfer size, instruction frequency, and instruction mix generated during program execution. Different microarchitectures have varying instruction sets, cache architectures, and parallel processing units. These underlying features directly impact program execution and performance. For example, a common approach is performance counter-based analysis. Performance counters are hardware components used to measure hardware and software performance metrics. By collecting and analyzing data from these counters, insights into program performance characteristics during GPU execution can be gained. This approach is relatively independent of microarchitecture details, but interpretation and understanding of the counters' meaning still requires specific microarchitectures. Another approach is sampling analysis, which captures program behavior patterns and features by sampling the GPU state and instruction stream at a constant frequency during program execution. This approach provides information on the instruction flow, memory access patterns, branch prediction, and other aspects of program execution, while remaining relatively independent of the underlying microarchitecture. Furthermore, static analysis methods can also be used to mine microarchitecture-independent GPU features. Static analysis involves analyzing program code without actually executing it to obtain information about its behavior and performance. By analyzing GPU program source code, compiler optimization techniques, and algorithmic characteristics, it is possible to derive microarchitecture-independent feature mining results. While general performance analysis tools and optimization techniques exist, these solutions still need to consider the characteristics of specific microarchitectures to provide accurate results.

[0005] In summary, existing solutions are usually based on methods such as hardware performance counters, sampling analysis, and static analysis, 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.

[0006] Summary of the Invention

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

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

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

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

[0011] Based on the obtained correlation, an analysis result is output, where the analysis result reflects the performance bottleneck of the target application and corresponding optimization suggestions.

[0012] 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:

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

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

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

[0016] Compared to existing technologies, the present invention offers the advantage of a microarchitecture-independent GPU feature mining solution that is applicable to NVIDIA GPU architectures including Kepler, Maxwell, Pascal, and Volta, and to any pre-compiled CUDA, OpenACC, OpenCL, or CUDA-Fortran application. Whether targeting game development, scientific computing, or machine learning, developers can leverage the present invention to gain a deeper understanding of the performance characteristics of their applications on different GPUs, helping them adjust and optimize their applications to fully utilize the GPU's computing power. Furthermore, the present invention provides quantitative data to support decision-making, such as selecting performance optimization strategies and adjusting system configurations. Using this data, researchers can make informed decisions to improve the performance and effectiveness of the entire system.

[0017] 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 accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0019] FIG1 is a flow chart of a method for mining and analyzing GPU features independent of computer microarchitecture according to an embodiment of the present invention;

[0020] FIG2 is a diagram illustrating a framework for constructing a microarchitecture-independent feature tool according to an embodiment of the present invention;

[0021] FIG3 is a schematic diagram of the Rodinia Instruction Mix distribution according to an embodiment of the present invention;

[0022] FIG4 is a schematic diagram of a Rodinia cache hit rate according to an embodiment of the present invention;

[0023] FIG5 is a schematic diagram of Rodinia Instruction Frequency distribution according to an embodiment of the present invention;

[0024] FIG6 is a schematic diagram of the distribution of the average percentage of Rodinia Instruction Frequency according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that unless otherwise specifically stated, 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.

[0026] 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 part of the specification.

[0027] 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.

[0028] As shown in Figure 1, 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, which 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 analysis results based on the obtained correlation, and the analysis results reflect the performance bottlenecks of the target application and corresponding optimization suggestions.

[0029] To implement the ideas of the above methods, a GPU feature mining tool called MICPAT (Micro-architecture Independent Characteristics Profiling Analysis Tool) was designed. This 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 tune and optimize applications and fully utilize the computing power of the GPU. The innovation of MICPAT lies in providing a feature mining method that is independent of the microarchitecture, helping researchers to deeply analyze the performance characteristics of the program, understand the differences in the program's behavior on different GPU microarchitectures, and perform targeted performance optimization.

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

[0031] 1. Build the environment

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

[0033] As shown in Figure 2, the MICPAT tool is based on NVBit, an open-source GPU binary code analysis tool developed by NVIDIA Labs. NVBit allows developers to write custom analysis plugins, allowing them to extend functionality based on specific needs. During the environment build process, libmicpat.a is a static library file that contains the core functionality and implementation of the MICPAT tool. It is referenced when compiling and linking MICPAT plugins. By linking to the libmicpat.a library, developers can use the APIs and functions provided by MICPAT in their plugin code to analyze, transform, and optimize GPU binary code. micpat.h is the MICPAT tool header file, containing declarations of the APIs and functions provided by MICPAT. Developers must include the micpat.h header file when writing MICPAT plugins and use the functions and structures defined therein to access and manipulate MICPAT functionality. Using the micpat.h header file, developers can understand and use various MICPAT functions, such as registering callback functions, accessing instruction information, and obtaining memory access modes. In summary, libmicpat.a is the core library file for MICPAT, containing the tool's implementation; micpat.h is the header file for MICPAT, providing the API and function declarations required for plugin development. Together, these two files form the basic building blocks of the MICPAT tool, enabling developers to build microarchitecture-independent features.

[0034] nvidiaasm is a key component in the MICPAT toolkit, 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 crucial for gaining a deep understanding and analysis of the performance characteristics and behavior of GPU programs. Using nvidiaasm, MICPAT can parse and process GPU assembly instructions, providing instruction-level analysis, conversion, and optimization capabilities. Specifically, nvidiaasm parses and extracts relevant information about GPU assembly instructions, such as instruction type, operands, and register usage. This information is invaluable 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 substitution, 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, tracing and monitoring the instruction execution flow, helping them locate and resolve issues and errors in GPU programs.

[0035] 2. Building the Model

[0036] In one embodiment, the extracted microarchitecture-independent features primarily include instruction mix, memory hierarchy, basic block count, instruction frequency, and CPU and GPU memory allocation size. These features enable comprehensive program analysis at the instruction, thread, and memory levels, enabling assessment of program adaptability to different microarchitectures, identifying performance bottlenecks, and exploring optimization opportunities.

[0037] Specifically, instruction mix refers to the statistical information about 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 assess the program's adaptability to the instruction sets of different microarchitectures.

[0038] The number of basic blocks in a program's execution refers to the number of basic blocks formed during program execution. A basic block is a continuous sequence of instructions, with branching occurring only at the beginning and end of the block. By analyzing the number of basic blocks, researchers can assess the control flow characteristics of a program and understand its control flow handling capabilities on different microarchitectures.

[0039] Instruction frequency refers to the relative execution frequency of individual instructions during program execution. By analyzing instruction frequency, we can understand the execution status of each instruction in the program and thus evaluate the program's instruction execution efficiency on different microarchitectures.

[0040] The memory hierarchy refers to the access patterns and performance of various storage layers (such as registers, caches, and global memory) used in a program. By analyzing the memory hierarchy, researchers can understand the adaptability of a program to the memory hierarchies of different microarchitectures, identify memory access bottlenecks, and optimize them.

[0041] CPU and GPU memory allocation size refers to the amount of data transferred between the CPU and GPU. By analyzing the CPU and GPU memory allocation size, you can understand the program's data transfer requirements and assess its adaptability to the memory bandwidth and latency of different microarchitectures.

[0042] These features focus on high-level characteristics of a program, independent of the details of the underlying hardware. Therefore, they provide general insights into program performance and behavior, unconstrained by specific microarchitectures. By analyzing these features, developers can gain a macroscopic view of program performance and identify performance bottlenecks and optimization opportunities. For example, instruction mix provides information on the types and frequency of program instructions, helping to optimize instruction-level performance. The number of basic blocks and program execution block size can reveal a program's parallelism and concurrency, providing guidance for parallel optimization.

[0043] 1)Instruction Mix

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

[0045] In one embodiment, mixed statistics of instruction types in GPU programs, known as Instruction Mix, are implemented. By inserting a count function call before each instruction is executed, the frequency of each instruction type during program execution can be counted. Assuming the opcode range is 0-255, a global array, instruction_counts, of size 256 and an initial value of 0, is used. In the count_instruction function, the count of the corresponding opcode is incremented via an atomic increment operation. In the nvbit_at_instruction function, the opcode of each instruction is extracted and an instruction calling the count_instruction function is inserted. This way, the count of the corresponding opcode is incremented each time the instruction is executed. In the nvbit_at_init function, all elements in the instruction_counts array are cleared to zero to initiate 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. This statistical method helps developers understand the usage of various instruction types in GPU programs, thereby optimizing program performance, conducting performance analysis, and guiding hardware design.

[0046] Upon analysis, if the instruction mix has a high proportion of store or control operations, this may indicate that program performance is affected by memory access or control flow. In these cases, developers can improve program performance through strategies such as improving memory access patterns, reducing memory access latency, and optimizing cache utilization. Furthermore, the instruction mix can provide information about the overall structure and behavior of the program. For example, the presence of a large number of branch instructions may indicate complex conditional branch logic within the program. Optimizing conditional branches, such as predicting branches, reducing branch frequency, or using more efficient branch instructions, can improve program execution efficiency. In summary, instruction mix is ​​an important feature that helps developers gain insight into program execution characteristics and provides optimization strategies. By optimizing different instruction types, developers can improve program performance, increase the efficiency of compute-intensive tasks, and optimize memory access and control flow, resulting in more efficient program execution.

[0047] 2)Memory Hierarchy

[0048] For example, collecting the number of cache hits and misses at different levels of the memory hierarchy, as well as the number of main memory accesses, can help assess a program's cache utilization and memory access patterns, thereby understanding the number of cache hits and misses and main memory accesses across the memory hierarchy. Cache is high-speed storage within the memory hierarchy, used to accelerate data access. Collecting cache hit and miss counts at different levels of the memory hierarchy can help understand a program's access patterns across all levels of cache. A high cache hit rate indicates that the program is effectively utilizing the cache, while a high number of cache misses may indicate insufficient cache capacity or poor access patterns. Main memory is the slowest level in the memory hierarchy, and frequent accesses to main memory can result in high latency and bandwidth consumption. Collecting main memory access counts can help assess a program's reliance on main memory. A low number of main memory accesses generally indicates that the program is effectively utilizing the cache, thus reducing main memory accesses. By analyzing these characteristics, we can see that a high cache hit rate and a low number of cache misses generally indicate that the program is making good use of the memory hierarchy and effectively utilizing cache to improve performance. High main memory access counts may indicate that the program is underutilizing cache capacity or has poor access patterns, potentially requiring optimization of cache strategies or memory access patterns. Comparing feature values ​​across different programs or under different optimization strategies can help assess and compare their utilization of the memory hierarchy and guide optimization decisions.

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

[0050] Step S11: Add counters to the MICPAT framework. By modifying the MICPAT framework code, counter logic is inserted into key code sections. These counters are used to record cache hits and misses, as well as main memory accesses. The user needs to determine the access information they need to collect for different levels of cache and main memory, and insert the counter logic at the appropriate locations.

[0051] 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. Users need to use the API functions provided by MICPAT to embed the counter logic into the target program and update the counter value at the appropriate time.

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

[0053] Step S14, analyzing feature data: The exported feature 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.

[0054] For example, the Memory Hierarchy feature is implemented as a cache simulator, primarily used to evaluate cache system performance. Its core algorithms include cache_sim_read and cache_sim_writ. In the cache_sim_read algorithm, the cache line index is first calculated based on a given address. This index is then used to locate the corresponding cache line set and obtain the LRU (least recently used) index of the current set. Next, each cache line in the set is traversed to determine whether a cache line matching the given address exists. If a hit occurs, meaning a cache line matching the address has been found, the hit flag is set to 1, and the LRU index of the current cache line is updated. If a miss occurs, meaning no cache line matching the address exists in the set, the miss counter is incremented, the given address is stored in the cache line pointed to by the current LRU index, and the LRU index is updated. Finally, the access counter is incremented to indicate the completion of a cache access. In the cache_sim_write algorithm, the cache_sim_read algorithm is first called, performing a read operation. This is because a write operation requires checking whether a cache line matching the given address exists in the cache. If the cache line exists, the write operation can be regarded as a hit and the write operation can be performed directly. If the cache line does not exist, the write operation also needs to load the cache line and then perform the write operation.

[0055] In addition to the core algorithm, several global variables are defined to track cache status and performance metrics, such as cache size, line size, and associativity. In the initialization function nvbit_at_init, the number of sets is calculated based on the given cache parameters, and memory is dynamically allocated to store the tag array and LRU array. In the termination function nvbit_at_term, the cache hit and miss rates are calculated, and various cache performance metrics are printed. Overall, a cache simulator is implemented to simulate cache read and write operations and to calculate cache performance metrics, such as hit and miss rates. These metrics are important for evaluating and optimizing cache system performance.

[0056] 3) Basic Block Count

[0057] A basic block is a microarchitecture-independent feature because it remains constant during program execution and is unaffected by the underlying hardware microarchitecture. A basic block is a continuous sequence of instructions within a program. It is the smallest executable unit of code and can only be entered at its beginning instruction and exited at its end. Basic blocks are formed based on a control flow graph, which visualizes the program's execution flow as a directed graph, with basic blocks as nodes.

[0058] Basic blocks, as static features of a program, exhibit the same execution behavior across different microarchitectures. This is because the execution of a basic block depends solely on the order and control flow of the instruction sequence, and is independent of the specific design of the underlying hardware. First, basic blocks are generated through static analysis of the program code and do not involve dynamic execution. Second, basic blocks contain no branch or jump instructions, only sequentially executed instruction sequences. Basic block execution is unaffected by the underlying hardware microarchitecture and does not involve pipeline blocking, branch prediction, cache hits, and other issues. Basic block execution simply follows the sequential execution of the instruction sequence, unaffected by the specific design and optimization strategies of the underlying hardware.

[0059] In one embodiment, an algorithm for counting and counting instructions of basic blocks in a CUDA program is implemented. The algorithm uses instrumentation technology to operate on the first instruction of each basic block when the function is loaded to implement the instruction counting function. 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 is called. This function obtains 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, a call to the count_instrs function is inserted before this instruction, and some parameters are passed, such as the number of instructions in the basic block bb.instrs.size(), the calculated warp level count_warp_level and the basic block identifier local_bb. This completes the instrumentation operation of the instruction counting function.

[0060] 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 in the current basic block and store the result in the global variable basic_block_value. Inside the function, the global warp ID is first obtained and the activity mask of the active thread is calculated. Then the lane ID of the current thread is obtained and the ID of the first active thread is determined. Then the number of active threads is calculated. 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 accumulate 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, hot spot analysis of instructions, etc.

[0061] Basic blocks, as a microarchitecture-independent feature, can be used in areas such as program analysis, performance optimization, and code generation. By analyzing the number of basic blocks and optimizing their execution order and structure, program execution efficiency and performance can be improved while maintaining portability across different microarchitectures. The abstracted program behavior of basic blocks allows developers to focus on the program's algorithms and logic without overly considering the details of the underlying hardware. The analysis results of basic blocks can serve as a guide for performance optimization, allowing complex basic block structures to be restructured or simplified to improve program execution efficiency and throughput. Furthermore, the microarchitecture-independent nature of basic blocks promotes the development of hardware-independent programming, making programs easier to maintain and port, and promoting portability and reusability in software development.

[0062] 4)Instruction Frequency

[0063] Instruction frequency refers to the execution frequency of different instructions in a program. By analyzing instruction frequency, we can understand which instructions are frequently executed and which are less frequently executed. This helps determine instruction-level optimization strategies, such as optimizing frequently executed instructions to improve overall execution efficiency. Instruction frequency is microarchitecture-independent because it is related to the semantics and execution logic of the instructions, rather than the details of the underlying hardware. Instruction frequency calculation is based on static program analysis, calculating the execution frequency by counting the number of occurrences of different instructions in the code. This process is independent of 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, instruction frequency, as a static characteristic of the program, has the same properties across different microarchitectures. The microarchitecture-independent nature of instruction frequency is of great significance for program analysis and optimization. First, by analyzing instruction frequency, we can understand which instructions are frequently executed and which are less frequently executed. This frequency information can guide the development 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 identify and resolve performance bottlenecks. By adjusting instruction-level optimization strategies, overall program performance can be improved.

[0064] In one embodiment, an algorithm for counting instruction execution frequency in GPU programs is implemented. This algorithm counts instructions that meet a specific condition by inserting a count function call before instruction execution and storing the result in a global array. First, a constant MAX_OPCODES is defined to represent the maximum number of opcodes, with a value of 16*1024. Then, a global array frequency is declared to record the execution frequency of each opcode, with an array size of MAX_OPCODES. Next, a count_instrs function is defined to perform instruction counting. This function obtains the active thread mask active_mask, indicating which threads are currently active. Then, based on a given condition, it calculates the thread mask predicate_mask that meets the condition. The current thread's laneid is obtained, indicating the thread's position within its warp. The first_laneid of the first active thread is calculated, and the number of threads that meet the condition, num_threads, is calculated. In the conditional judgment, if the current thread's laneid is equal to the first_laneid of the first active thread, the instruction count operation is performed. If warp-level instruction counts are required and the number of threads meeting the condition is greater than 0, an atomic operation increments frequency[instr_type] by 1. Otherwise, frequency[instr_type] is incremented by the number of threads meeting the condition. A call to the count_instrs function with constant parameters 1, instr_type, and count_warp_level is inserted before each instruction i. This algorithm implements frequency counting by inserting calls to the count function before instructions that meet specific conditions and storing the results in a global array.

[0065] The microarchitecture-independent nature of instruction frequency also plays an important role in guiding compiler optimization and code generation. Compilers 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 instruction frequency information, compilers can rationally arrange the execution order of instructions and reduce dependencies between instructions, thereby improving instruction-level parallelism and overall execution efficiency. Furthermore, the microarchitecture-independent nature of instruction frequency promotes program portability and reusability. By analyzing instruction frequency 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 a program, optimize high-frequency instructions, and maintain consistent performance across different microarchitectures. This microarchitecture-independent optimization strategy reduces dependence on underlying hardware details, improving code reusability and maintainability. The microarchitecture-independent nature of instruction frequency also plays an important role in guiding compiler optimization and code generation. Compilers can use instruction frequency information 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, thereby improving overall execution efficiency.

[0066] 5)Memory Allocation Size

[0067] The memory transfer size between the CPU and GPU refers to the amount of data involved in transferring data between the two. First, the size of memory transfers between the CPU and GPU is closely related to the program's data processing. In GPU computing, data is typically transferred from host memory (CPU memory) to device memory (GPU memory), or from device memory back to host memory. The size of these data transfers directly affects the time and cost of these transfers. By statically analyzing program code, users can determine the size of memory transfers between the CPU and GPU, thereby understanding the scale and frequency of these transfers. Second, the size of memory transfers between the CPU and GPU is closely related to the relationship between data parallelism and computational load. In data-intensive computing, large amounts of data need to be transferred between the CPU and GPU to enable parallel computing. By analyzing memory transfer size, users can understand the data flow between the CPU and GPU, thereby guiding program optimization strategies. For example, for programs with frequent data transfers, techniques such as data reuse, data compression, or data sharding can be considered to reduce the amount of data transferred, thereby lowering the cost of the transfer.

[0068] In one embodiment, an algorithm is implemented to capture different CUDA events during the execution of a CUDA application through the callback function nvbit_at_cuda_event. Depending on 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 the 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 the 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.

[0069] Furthermore, the size of CPU and GPU memory transfers is also crucial for optimizing program performance. Data transfers are often a bottleneck for compute-intensive programs because they consume time and bandwidth. By analyzing transfer sizes, users can identify data transfer bottlenecks and implement targeted optimizations. For example, techniques such as data compression, asynchronous transfers, and data prefetching can be used to reduce transfer time and costs, thereby improving program execution efficiency. Finally, the microarchitecture-independent nature of CPU and GPU memory transfer sizes also promotes program portability and reusability. Because memory transfer sizes are related to program data processing, the same program and dataset may require different memory transfer sizes on different microarchitectures. Static analysis of program code can reveal memory transfer sizes for different microarchitectures, guiding the development of optimization strategies. This microarchitecture-independent optimization strategy reduces reliance on underlying hardware details and improves code portability and maintainability.

[0070] 3. Run the model

[0071] 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 function to be analyzed and modified and the related operations. Then, using the compiler tools provided by MICPAT, the instrumentation source file is compiled into a target instrumentation library. This library contains the binary code for the instrumentation logic. At the same time, using the compiler tools provided by MICPAT, the target CUDA application is compiled into a binary executable file. This compilation process links the target application with the MICPAT runtime library.

[0072] When running the target application, specify the path to 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 a specified shared library at program load time. LD_PRELOAD loads the specified shared library into the process's address space when the application loads, prioritizing it over other libraries. This allows the function implementations in the target instrumentation library to override the system's default implementations, enabling instrumentation of CUDA functions. Library function linking is the process of associating the application with the required library functions. During the compilation process, the compiler matches function calls to library functions to ensure that the program can call the required functions. Library functions can be statically linked libraries (.a files) or dynamically linked libraries (.so files). A .so file is a dynamic link library file containing compiled binary code and function symbols. It can be loaded into the process's address space 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.

[0073] A statically linked library is copied into the final executable during compilation, so the executable contains all the required function code. This approach makes the executable relatively independent, without relying on external library files. However, statically linked libraries have the disadvantage of increasing the executable file size and causing code duplication when the same library functions are used in multiple executables. Dynamically linked libraries are loaded into the process's address space at runtime and parsed and linked by the dynamic linker. This approach allows multiple executables to share the same library file, reducing code redundancy. Dynamically linked libraries typically have the extension .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 application's address space at runtime. This allows developers to modify application behavior by replacing or redirecting specific functions without modifying the original application. The LD_PRELOAD mechanism is particularly useful for instrumenting and debugging applications. By setting the LD_PRELOAD environment variable, developers can load a specified .so file into their application, overwriting the original application's function implementations. This allows developers to modify the behavior of an application at runtime, adding custom logic, performance analysis code, memory allocation tracking, and other features without having to modify the source code.

[0074] It's important to note that LD_PRELOAD only affects function calls resolved through the dynamic linker. It has no effect on directly called functions or statically linked functions. Furthermore, libraries loaded with LD_PRELOAD may introduce different versions of function implementations, potentially leading to symbol conflicts or inconsistent behavior. Therefore, caution is advised when using LD_PRELOAD to ensure that the library files are compatible with the target application and that symbol resolution and linking issues are handled correctly.

[0075] IV. Experimental Verification Results

[0076] To further understand the effects of the present invention, an experimental verification was performed. The experimental operating environment is the Ubuntu 18.04 operating system, NVIDIA driver version 418.40, CUDA version 10.2, and LLVM version 7.0. During the build process, the environment variables MICPAT_ROOT, LLVM_HOME, and CUDA_HOME are added to the system's PATH environment variable. Then, the sample code designed using MICPAT was used for verification.

[0077] 1) Instruction Mix Feature Analysis

[0078] 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 a variety of fields, including image processing, data mining, physical simulation, and graph algorithms. This paper analyzes the Instruction Mix feature of the Rodinia program in detail and, based on this analysis, conducts in-depth optimization analysis to improve the program's execution efficiency and performance.

[0079] Figure 3 shows the Rodinia Instruction Mix distribution. As shown in Figure 3, the following observations are made: First, Integer instructions account for the highest proportion, reaching 37.18%, indicating a significant presence of integer operations in Rodinia programs. To address this, integer optimization techniques, such as loop unrolling and bitwise optimization, can be considered to improve the program's integer computation efficiency. Second, Floating Point instructions account for a relatively low proportion of 15.58%, but still contain a significant proportion of floating-point operations. To address this, floating-point optimization techniques, such as utilizing the SIMD instruction set and reducing unnecessary floating-point operations, can be used to improve the program's floating-point computation performance. Furthermore, Control instructions account for 10.21%, indicating a significant proportion of control flow instructions, such as conditional branches and loops. To address this, optimization of algorithms and control flow structures can be considered to reduce branch prediction errors and improve the program's control flow efficiency. Furthermore, Movement instructions account for 14.89%, indicating a high proportion of data movement operations, such as loads and stores. To address this issue, data access patterns and memory layout can be optimized to reduce data movement and improve data access efficiency. Other instruction types (Vector, Conversion, Predicate, Texture, Compute Load / Store Instructions, Surface Memory, and Miscellaneous) have a relatively low percentage, indicating that these instructions are less commonly used.

[0080] 2) Memory Hierarchy Feature Analysis

[0081] The Memory Hierarchy feature simulates cache operating principles, including cache hit and miss determination and replacement strategies, using data structures and algorithms, independent of specific hardware implementations. This means consistent cache behavior simulation is provided regardless of the microarchitecture or hardware platform. As a result, developers can conduct cache performance evaluation, algorithm optimization, and system design in diverse environments without being constrained by a specific microarchitecture. This microarchitecture-independent feature enables broader code applicability and portability.

[0082] Figure 4 shows a diagram of Rodinia's cache hit rate. First, different Rodinia programs exhibit varying cache hit rates. Each program's cache hit rate fluctuates within a certain range, ranging from a low of 36.21% (nw) to a high of 99.22% (huffman). On average, the cache hit rate for these Rodinia programs is approximately 50%. Some programs, such as bfs (51.69%), dwt2d (71.26%), and leukocyte (99.22%), have cache hit rates slightly above 50%. Other programs, such as kmeans (37.09%), particlefilter (44.50%), and cfd (37.91%), have cache hit rates slightly below 50%. Second, several programs, such as huffman (99.22%) and lavaMD (94.31%), exhibit high cache hit rates, indicating that they effectively utilize the cache and reduce main memory accesses. 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 a least recently used (LRU) replacement strategy to manage data blocks in the cache. By maintaining an LRU counter for each data block, the least recently used block can be determined and replaced to maintain efficient cache utilization. The Memory Hierarchy feature has been proven to help analyze and evaluate cache performance, further understand cache behavior, optimize algorithms or system design, and thus improve program performance and efficiency.

[0083] 3) Basic Block Count Feature Analysis

[0084] Basic Block Count reflects the control flow complexity of a program. If a program has a large number of basic blocks, it indicates a complex control flow, including multiple branches and jump statements. This can lead to increased branch prediction errors, thus affecting program performance. Basic Block Count can help understand the structure and logic of a program. By analyzing the number and order of basic blocks, we can obtain the control flow graph of the program and understand the dependencies and execution order between different parts of the program. Table 1 shows an example of basic block count statistics.

[0085] Table 1 Number of Rodinia basic blocks

[0086] Table 1 lists the statistics of the number of basic blocks in Rodinia programs. The number of basic blocks is an important indicator of program complexity and structure. Table 1 shows significant differences in the number of basic blocks between different Rodinia programs. For example, the backprop program has only three basic blocks, while the myocyte program has 702 basic blocks, a significant difference. This indicates that different programs have distinct structural differences, involving different algorithms or implementations. Furthermore, there may be a correlation between the number of basic blocks and the computational complexity and parallelism of a program. A fewer number of basic blocks indicates a simpler program with a more limited computational task, while a larger number of basic blocks indicates a more complex program with more computational tasks and data dependencies. This provides important guidance for program performance optimization and parallelization design. Programmers can adjust optimization strategies based on the difference in the number of basic blocks, selecting appropriate optimization methods and parallelization modes for different program structures. Furthermore, the number of basic blocks can also reflect the control flow and loop structure within a program. For example, programs with a larger number of basic blocks often contain more complex conditionals and loop structures, requiring more sophisticated control flow analysis and optimization. This is very important for improving program performance and maintaining it.

[0087] In summary, basic block analysis of Rodinia programs provides valuable information about program complexity, computational complexity, parallelism, and control flow. This helps inform decision-making regarding program optimization and parallelization, providing a valuable basis for improving program performance and efficiency.

[0088] 4) Instruction Frequency Feature Analysis

[0089] Instruction frequency is a metric that measures how often various instruction types are used during program execution. By analyzing the instruction frequency of Rodinia programs, we can understand the usage of different instruction types within the program, thereby revealing the program's computational characteristics and performance bottlenecks.

[0090] Figure 5 shows the instruction frequency data for each program in the Rodinia benchmark. The following conclusions can be drawn. First, different Rodinia programs exhibit significant differences in instruction frequency. The instruction usage patterns of different programs vary, reflecting their computational characteristics and algorithmic designs. For example, in the hotspot3D program, over 40% of the instruction frequencies are concentrated in the range [40%-100%], while in the cfd program, over 50% of the instruction frequencies are concentrated in the ranges [20%-30%] and [40%-100%]. Second, some programs have high instruction frequencies concentrated in narrower ranges, indicating that these programs are more intensively executed on specific instruction types. For example, in the srad_v1 program, over 60% of the instruction frequencies are concentrated in the range [0%-5%], indicating that this program primarily relies on a few instruction types for computation. Furthermore, some programs have relatively balanced instruction frequency distributions. For example, the backprop and particlefilter programs both use a certain percentage of instruction frequencies across different instruction frequency ranges, with no clear trend of concentration. This suggests that these programs have relatively balanced computational requirements across different instruction types. Finally, some programs have lower instruction frequencies, especially in the range of [0%, 5%] and [5%, 10%]. This indicates that these programs use less of certain instruction types, perhaps because their computational processes are simpler or they use more efficient computational techniques or optimization strategies.

[0091] Figure 6 shows the average frequency distribution of all Rodinia programs across various frequency ranges. As shown in Figure 6, the average values ​​for the higher frequency ranges ([10%-20%), [20%-30%), and [30%-40%) are relatively low, while the average values ​​for the lower frequency ranges ([0%-5%) and [5%-10%) are relatively high. This indicates that instructions in the higher frequency ranges are less frequently used in the program, while instructions in the lower frequency ranges are more frequently used. The trend of the average values ​​reflects the overall distribution of instruction usage. The experimental data shows that instruction frequency gradually decreases with increasing frequency range, showing a decreasing trend. This indicates that in Rodinia programs, instruction usage is more concentrated in the lower frequency ranges, and instruction usage decreases as the frequency range increases.

[0092] In summary, instruction frequency analysis of Rodinia programs reveals the instruction usage patterns and characteristics of different programs. This is crucial for understanding a program's computational characteristics, performance bottlenecks, and optimization potential. Analysis of Rodinia program instruction frequency ranges and average values ​​reveals instruction usage and distribution characteristics within different frequency ranges. Further research and analysis will allow us to develop targeted optimization strategies tailored to the instruction frequency characteristics of different programs, thereby improving their execution efficiency and performance.

[0093] 5) Memory Allocation Size Feature Analysis

[0094] Memory management is crucial for optimizing GPU performance and efficiency. The Memory Allocation Size trait tracks memory allocation and deallocation operations within a program. This is crucial for understanding a program's memory usage, detecting memory leaks, and optimizing memory management. By recording the addresses, sequences, and sizes of allocated and deallocated memory blocks, memory usage analysis and performance tuning can be performed. In the memory allocation and deallocation callback functions, the Memory Allocation Size trait prints information about memory operations, including the addresses and sizes of allocated / deallocated memory blocks. This is extremely useful for monitoring and debugging memory operations in real time during program execution. By viewing the printed information, developers can understand the order in which memory operations occurred, the locations of the operations, and the memory sizes involved, helping to identify memory issues and optimize memory usage.

[0095] Analysis of the experimental results reveals the following conclusions. First, regarding memory allocation, the "Found an allocation!" statement indicates that a memory allocation operation has been detected. Each time a memory allocation is detected, the address and size of the allocated memory block are printed. For example, the first print statement indicates that a memory block of 67,186,720 bytes (approximately 64MB) was allocated at address 0x7f028e000000. Subsequent print statements also indicate other memory allocation operations, with varying sizes and addresses. Second, regarding memory copy operations (HtoD), the analysis results also indicate host-to-device memory copy operations, indicated by the "Encountered a memcpy HtoD!" statement. Each time this operation is encountered, the source memory address, destination device memory address, and the number of bytes copied are printed. For example, the first print statement indicates that 67,186,720 bytes of data were copied from host address 0x7f02a3fec010 to device address 0x7f028e000000. Furthermore, regarding memory freeing, the code prints "Found a free!" to indicate when a memory free operation has been detected. Each time a memory free operation is detected, the address of the freed memory block is printed. For example, the first print statement indicates that the memory block at address 0x7f0292200000 was freed. Finally, regarding 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 statement displays information for 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 program's memory usage and identify memory issues such as memory leaks, duplicate releases, or uninitialized memory accesses. Furthermore, this tracked information can 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, data transfer overhead can be reduced by using more efficient data transfer techniques, data compression, or data reuse. Finally, for algorithms with frequent data exchange, data locality optimization can be considered during the design phase to reduce the number of data transfers between the host and device.

[0097] In summary, the present invention can provide a GPU feature mining and analysis system (or tool) based on a computer microarchitecture that is independent of the computer microarchitecture, which is used to implement one or more aspects of the above-mentioned 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 characteristics, wherein the performance characteristics are high-level characteristics 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 characteristics and the execution performance of the target application; and 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 corresponding optimization suggestions.

[0098] It should be noted that, without departing from 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, the above embodiments may be further extended to accommodate other GPU architectures, providing performance optimization tools for developers of different architectures. In addition, the MICPAT feature mining method may also be applied to the following fields, including but not limited to:

[0099] 1) In fields such as 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) MICPAT's feature analysis results can be used for performance tuning and software optimization. Based on the macroscopic view and performance bottleneck identification provided by MICPAT, developers can make targeted improvements to their programs, optimizing performance at the instruction level, parallelism, memory access, and other aspects to improve overall program performance.

[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 thereof.

[0104] While various embodiments of the present invention have been described above, the foregoing description is intended to be illustrative, non-exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or technological improvements in the marketplace, or to enable others skilled 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