Performance verification method and device for instruction cache, equipment and medium

Abstract

The invention discloses an instruction cache performance verification method and device, equipment and a medium. Comprising the following steps: generating an intermediate representation of a source code, and respectively generating a first executable file and a second executable file according to the intermediate representation; respectively deleting invalid functions in the first executable file and the second executable file, and performing function arrangement adjustment on the second executable file; the optimized first executable file and the optimized second executable file are loaded into a first processor and a second processor to be executed respectively, and the cache hit rate in the first processor and the cache hit rate in the second processor are monitored; and screening a target source code in the test case according to the cache hit rate monitoring result, and analyzing the performance of the test cache architecture according to the target source code. By the adoption of the technical scheme, interference factors in codes can be eliminated, performance comparison verification is carried out on instruction caches of different cache architectures, and then reliable data support is provided for cache architecture design of the processor.

Description

Technical Field

[0001] This invention relates to the field of cache architecture testing technology, and in particular to a method, apparatus, device and medium for performance verification of instruction cache. Background Technology

[0002] The instruction cache is a high-speed cache component in the processor that stores the instructions to be executed. During the processor design process, the validity of the instruction cache needs to be verified to ensure the processor's instruction fetching efficiency and operational stability.

[0003] In existing technologies, the cache hit rate of instruction cache can be collected and statistically analyzed based on standard test procedures or modeling simulation, thereby indirectly evaluating the performance of instruction cache based on statistical indicators.

[0004] However, existing performance verification methods require a lot of time to compile test programs or model, and it is difficult to isolate irrelevant influencing factors. The test results are easily affected by variables such as code layout and compilation optimization, which cannot meet the needs of processor R&D for accurate evaluation of cache architecture. Summary of the Invention

[0005] This invention provides a method, apparatus, device, and medium for verifying the performance of instruction caches, which can eliminate interference factors in the code, perform performance comparison verification of instruction caches of different cache architectures, and thus provide reliable data support for the design of processor cache architecture.

[0006] According to one aspect of the present invention, a method for verifying the performance of an instruction cache is provided, comprising:

[0007] The source code in the test cases is compiled sequentially to generate an intermediate representation of the source code. Based on the intermediate representation, a first executable file without perturbation and a second executable file with lightweight code layout perturbation are generated respectively.

[0008] Invalid functions are deleted from both the first and second executable files. Based on the function arrangement in the first executable file, the function arrangement in the second executable file is adjusted to generate optimized first and second executable files.

[0009] The optimized first executable file and second executable file are loaded into the first processor equipped with the reference cache architecture and the second processor equipped with the test cache architecture, respectively, and the cache hit rate in the first processor and the second processor is monitored.

[0010] Based on the cache hit rate monitoring results, target source code is selected from the test cases, and the performance of the test cache architecture is analyzed based on the target source code.

[0011] According to another aspect of the present invention, a performance verification apparatus for instruction cache is provided, comprising:

[0012] The executable file generation module is used to compile the source code in the test cases in sequence, generate an intermediate representation of the source code, and generate a first executable file without perturbation and a second executable file with lightweight code layout perturbation injected according to the intermediate representation.

[0013] The executable file optimization module is used to delete invalid functions in the first executable file and the second executable file respectively, and adjust the function arrangement in the second executable file according to the function arrangement in the first executable file to generate optimized first executable file and second executable file;

[0014] The executable file loading module is used to load the optimized first executable file and the second executable file into the first processor equipped with the reference cache architecture and the second processor equipped with the test cache architecture, respectively, and to monitor the cache hit rate in the first processor and the second processor.

[0015] The cache architecture performance analysis module is used to filter target source code in test cases based on cache hit rate monitoring results, and analyze the performance of the test cache architecture based on the target source code.

[0016] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0017] At least one processor; and

[0018] A memory communicatively connected to the at least one processor; wherein,

[0019] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the performance verification method of instruction cache as described in any embodiment of the present invention.

[0020] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the performance verification method of instruction caching according to any embodiment of the present invention.

[0021] The technical solution of this invention involves sequentially compiling the source code in the test cases to generate an intermediate representation of the source code. Based on this intermediate representation, a first executable file without perturbations and a second executable file with injected lightweight code layout perturbations are generated. Invalid functions are deleted from both the first and second executable files. The function arrangement in the second executable file is adjusted according to the function arrangement in the first executable file. The optimized first and second executable files are then loaded into a first processor with a reference cache architecture and a second processor with a test cache architecture, respectively, for execution. The cache hit rate in the first and second processors is monitored. Based on the cache hit rate monitoring results, target source code is selected from the test cases, and then... The method of analyzing the performance of test caching architectures can eliminate interference from invalid code during the verification process, avoid invalid code occupying cache space and causing errors in hit rate testing, and eliminate interference from layout differences and avoid the impact of address drift. It ensures that the same instructions are loaded into a fixed location in the cache, ensuring consistent cache behavior in multiple tests and cross-platform tests, thereby improving the accuracy and reliability of verification results. Furthermore, by introducing lightweight layout perturbations, layout perturbation comparison tests can be performed, simulating layout changes caused by compilation optimization and code modification in real-world applications. This can accurately trigger issues such as cache conflicts and performance jitter, and quickly quantify the impact of perturbations on cache effectiveness. It provides data support for the robustness and performance bottleneck analysis of different caching architectures, significantly improving the efficiency of problem localization and analysis.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart of a performance verification method for instruction caching provided in Embodiment 1 of the present invention;

[0025] Figure 2 This is a flowchart of another instruction cache performance verification method provided in Embodiment 2 of the present invention;

[0026] Figure 3This is a schematic diagram of the structure of a performance verification device for an instruction cache provided in Embodiment 3 of the present invention;

[0027] Figure 4 This is a schematic diagram of the structure of an electronic device that implements the instruction cache performance verification method of the present invention. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] Example 1

[0031] Figure 1 This is a flowchart of a method for verifying the performance of an instruction cache according to Embodiment 1 of the present invention. This embodiment is applicable to situations where instruction cache performance verification is performed on a first processor equipped with a reference cache architecture and a second processor equipped with a test cache architecture using an unperturbed executable file and a perturbed executable file. This method can be executed by an instruction cache performance verification device, which can be implemented in hardware and / or software and is generally configured in a computer or processor with data processing capabilities. Figure 1 As shown, the method includes:

[0032] S110. Compile the source code in the test cases in sequence to generate an intermediate representation of the source code, and generate a first executable file without perturbation and a second executable file with lightweight code layout perturbation injected according to the intermediate representation.

[0033] Optionally, test cases can contain multiple source codes, which can cover different functional scenarios, such as computation, logic processing, and data transmission, thereby ensuring that the actual operating environment of the instruction cache can be fully simulated and that the verification results are universal.

[0034] Optionally, after the source code is compiled by the compiler, it will be transformed into an executable file that can be executed by the processor. The intermediate representation is a transitional form of code in the source code compilation process. The intermediate representation retains all the functional logic of the source code, but is freed from the syntax restrictions of the specific programming language, making it convenient for the compiler to modify and optimize it.

[0035] Optionally, lightweight code layout perturbations can be used to change the storage layout or size of the code. These can include adding null instructions, adjusting the instruction order, adding placeholders, etc., which can perturb the code layout without changing the program's functionality or increasing the algorithm's complexity.

[0036] Optionally, an executable file can refer to a final program file that the processor can run directly. For example, it can be an ELF (Executable and Linkable Format) file. An executable file contains machine instructions that the processor can recognize. The instructions are stored in a special code segment and can be executed after being loaded.

[0037] Optionally, the compiler can be invoked to compile each source code file in the test case. The compiler front-end first performs syntax checking and semantic analysis to ensure that the source code is error-free. After passing the checks, the source code is converted into an intermediate representation that can be operated by the compiler.

[0038] Optionally, the first executable file can refer to the executable file generated directly without any layout perturbation after the intermediate representation is generated, without making any modifications to the intermediate representation; the second executable file can refer to the executable file generated by compiling based on the intermediate representation after code layout perturbation. The first executable file and the second executable file have only slight differences in code layout, and are completely identical in all other aspects.

[0039] The process of generating a first executable file without perturbation and a second executable file with lightweight code layout perturbation based on the intermediate representation can include:

[0040] Create an intermediate representation copy and inject a lightweight code layout perturbation into the intermediate representation copy;

[0041] The intermediate representation is compiled to generate the first executable file, and a copy of the intermediate representation with injected lightweight code layout perturbation is compiled to generate the second executable file.

[0042] Optionally, the intermediate representation copy is completely identical to the intermediate representation. The intermediate representation copy serves only as an independent carrier for perturbation operations and does not affect the original intermediate representation. The intermediate representation copy can be perturbed in a way that does not change the program function or increase the algorithm complexity, and only the storage layout or size of the code can be adjusted to simulate the code layout changes in actual applications.

[0043] S120. Invalid functions are deleted from both the first executable file and the second executable file. Based on the function arrangement in the first executable file, the function arrangement in the second executable file is adjusted to generate optimized first and second executable files.

[0044] Optionally, invalid functions can refer to idle code blocks in the program that are never called and do not affect the implementation of functions, such as redundant utility functions or unused functional module functions.

[0045] Optionally, based on the function arrangement of the first executable file, benchmark parameters such as the starting address of the code segment, the order of the code segment, and the order of the functions within the code segment can be extracted from the first executable file. Then, the second executable file can be adjusted according to the benchmark parameters to achieve operator isolation in complex scenarios. At the same time, it ensures that the same instructions are loaded into the same location in the cache, avoids performance measurement deviations caused by address drift, and finally generates two optimized types of executable files.

[0046] The deletion of invalid functions in both the first and second executable files may include:

[0047] Starting from the entry function of the first executable file and the second executable file respectively, query the call relationship between functions, and identify invalid functions that have not been called in the first executable file and the second executable file based on the call relationship between functions;

[0048] Invalid functions are deleted from both the first executable file and the second executable file.

[0049] Optionally, invalid functions can be filtered out by the linker during the linking stage. Specifically, this includes: taking functions as the smallest unit, starting from the entry function, recursively analyzing function call relationships, marking all valid functions that can be called directly or indirectly, and filtering out invalid functions that have never been called. Then, the object files of the first and second executable files are processed separately to remove the code corresponding to invalid functions, retaining only the instruction set of valid functions. This avoids invalid functions occupying cache space, causing abnormal cache hit rates, and ensuring verification accuracy.

[0050] Specifically, adjusting the function arrangement of the second executable file based on the function arrangement in the first executable file to generate optimized first and second executable files may include:

[0051] Obtain the starting address of each code segment, the order of the code segments, and the order of the functions within each code segment of the first executable file;

[0052] Based on the function arrangement order in each code segment of the first executable file, the target function is identified in the second executable file, copied into the target code segment, and the functions in each code segment of the second executable file are sorted.

[0053] Based on the starting addresses and code segment order of each code segment in the first executable file, the code segments in the second executable file are aligned with the code segments in the first executable file to generate optimized first and second executable files.

[0054] Optionally, parsing the format structure of the first executable file can obtain baseline parameters such as the starting address of its code segment, the order of the code segments, the order of functions within each code segment, and the spacing between functions, which can be used as a unified layout baseline.

[0055] It is understandable that the code layout of the first executable file and the second executable file may be different. For example, function A needs to call function B. The position of function B in the first executable file and the second executable file may be different. Function B may be located in code segment 1 in the first executable file, but in code segment 2 in the second executable file. In this case, the function whose function position differs in the two executable files will be identified as the target function. In order to align the functions in the second executable file and the first executable file, function B can be copied to code segment 1 of the second executable file. At this time, code segment 1 can be used as the target code segment.

[0056] Optionally, copying the target function into the target code segment and sorting the functions in each code segment of the second executable file may include: copying the target function into the target code segment corresponding to the first executable file, and sorting the functions in each code segment of the second executable file according to the function arrangement order of the first executable file to ensure that the relative positions of the functions are consistent.

[0057] Optionally, aligning the code segments in the second executable file with the code segments in the first executable file according to the starting addresses and order of the code segments in the first executable file may include: adjusting the starting addresses of the code segments in the second executable file according to the starting addresses and order of the code segments in the first executable file, so that the code segments in the second executable file are aligned with the corresponding code segments in the first executable file in memory, and performing segment address locking operations on the first and second executable files to fix the starting addresses of the code segments and ensure that the mapping positions of the same instructions are consistent when loaded into the cache.

[0058] It is understandable that the alignment of each code segment in the second executable file with the code segments in the first executable file includes at least sequential alignment. If the address of the second executable file is smaller than that of the first executable file, the starting addresses of each code segment can be guaranteed to be fully aligned; otherwise, at least the sequential alignment of each code segment can be guaranteed.

[0059] S130. The optimized first executable file and the second executable file are loaded into the first processor equipped with the reference cache architecture and the second processor equipped with the test cache architecture, respectively, and the cache hit rate in the first processor and the second processor is monitored.

[0060] Optionally, a reference cache architecture can refer to a standard cache architecture with stable performance and known robustness. It is generally a cache architecture that has been designed and put into normal use and has good performance. The reference cache architecture can be used as a benchmark for testing cache architectures to measure the performance differences of the test cache architectures.

[0061] Optionally, the test cache architecture can refer to the cache architecture whose performance is to be verified. Generally, it can refer to the cache architecture installed in a currently designed processor that is not in normal use. By comparing it with the reference cache architecture, the stability of the cache architecture can be evaluated.

[0062] Optionally, cache hit rate can refer to the probability that the processor successfully finds the required instruction from the cache. The calculation logic is: (number of cache hits ÷ total number of instruction accesses) × 100%. The higher the hit rate, the better the cache performance.

[0063] Optionally, the optimized first executable file can be loaded into the first processor and the second processor respectively for execution, and the optimized second executable file can also be loaded into the first processor and the second processor respectively for execution. The performance counters built into the two processors can be enabled to monitor the access data of the instruction cache. The access data of the instruction cache can include the total number of instruction accesses, the number of cache hits, and the number of cache misses. Then, the hit rate of the four executions can be calculated based on the access data of the instruction cache.

[0064] S140. Based on the cache hit rate monitoring results, select target source code in the test cases, and analyze the performance of the test cache architecture based on the target source code.

[0065] Optionally, the target source code can refer to key source code that can expose cache performance issues. It can include source code that can significantly reduce the cache hit rate of the test caching architecture, or it can include extreme test cases that affect the cache hit rate of the reference caching architecture.

[0066] Optionally, it can analyze the functional scenarios of the target source code, such as high-frequency calls and large-scale data operations. Combined with the hit rate monitoring results, it can analyze and test the robustness of the cache architecture, determine the reasons for low or large hit rates, and generate a comprehensive performance report based on the multi-dimensional analysis results to provide support for cache architecture optimization.

[0067] The technical solution of this invention involves sequentially compiling the source code in the test cases to generate an intermediate representation of the source code. Based on this intermediate representation, a first executable file without perturbations and a second executable file with injected lightweight code layout perturbations are generated. Invalid functions are deleted from both the first and second executable files. The function arrangement in the second executable file is adjusted according to the function arrangement in the first executable file. The optimized first and second executable files are then loaded into a first processor with a reference cache architecture and a second processor with a test cache architecture, respectively, for execution. The cache hit rate in the first and second processors is monitored. Based on the cache hit rate monitoring results, target source code is selected from the test cases, and then... The method of analyzing the performance of test caching architectures can eliminate interference from invalid code during the verification process, avoid invalid code occupying cache space and causing errors in hit rate testing, and eliminate interference from layout differences and avoid the impact of address drift. It ensures that the same instructions are loaded into a fixed location in the cache, ensuring consistent cache behavior in multiple tests and cross-platform tests, thereby improving the accuracy and reliability of verification results. Furthermore, by introducing lightweight layout perturbations, layout perturbation comparison tests can be performed, simulating layout changes caused by compilation optimization and code modification in real-world applications. This can accurately trigger issues such as cache conflicts and performance jitter, and quickly quantify the impact of perturbations on cache effectiveness. It provides data support for the robustness and performance bottleneck analysis of different caching architectures, significantly improving the efficiency of problem localization and analysis.

[0068] Example 2

[0069] Figure 2 This is a flowchart illustrating a performance verification method for instruction caches according to Embodiment 2 of the present invention. Based on the above embodiments, this embodiment specifically describes the performance verification method for instruction caches. Figure 2 As shown, the method includes:

[0070] S210. Compile the source code in the test cases one by one to generate an intermediate representation of the source code.

[0071] S220. Create an intermediate representation copy and inject a lightweight code layout perturbation into the intermediate representation copy.

[0072] S230. Compile the intermediate representation to generate the first executable file, and compile the intermediate representation copy that has been injected with lightweight code layout perturbation to generate the second executable file.

[0073] Injecting lightweight code layout perturbations into the intermediate representation copy may include at least one of the following:

[0074] Add no-operation instructions to the non-critical execution path inside the first function;

[0075] Add a placeholder instruction at the end of the second function.

[0076] Optionally, a no-operation instruction can refer to a NOP instruction. A no-operation instruction is a placeholder instruction that does not perform any operations or change the program state. It only occupies storage space and does not affect the program's functionality or execution result. Instruction placeholders can refer to code filling blocks without actual functionality. They are only used to adjust the size and relative position of functions or code segments and do not participate in logical operations.

[0077] Optionally, both the first function and the second function can represent any function in the intermediate representation copy. The first function and the second function can be randomly selected, and there is no limit to the number of the first function and the second function; there can be one or more.

[0078] S240. Starting from the entry function of the first executable file and the second executable file respectively, query the call relationship between functions, and identify invalid functions that have not been called in the first executable file and the second executable file based on the call relationship between functions.

[0079] S250. Invalid functions are deleted from both the first executable file and the second executable file.

[0080] S260. Obtain the starting address of each code segment of the first executable file, the order of the code segments, and the order of the functions within each code segment.

[0081] Optionally, the code segment start address can refer to the starting storage location of the code segment in the executable file in memory. The start address can determine the mapping location of the instructions loaded into the cache.

[0082] S270. Based on the function arrangement order in each code segment of the first executable file, identify the target function in the second executable file, copy the target function into the target code segment, and sort the functions in each code segment of the second executable file.

[0083] S280. Based on the starting address of each code segment and the order of the code segments in the first executable file, align each code segment in the second executable file with each code segment in the first executable file to generate the optimized first executable file and the second executable file.

[0084] S290. The optimized first executable file and the second executable file are loaded into the first processor equipped with the reference cache architecture and the second processor equipped with the test cache architecture, respectively, and the cache hit rate in the first processor and the second processor is monitored.

[0085] S2100. Based on the cache hit rate monitoring results, select target source code in the test cases, and analyze the performance of the test cache architecture based on the target source code.

[0086] Among these methods, selecting target source code from test cases based on cache hit rate monitoring results can include:

[0087] The first cache hit rate when the first processor executes the first executable file, the second cache hit rate when the second processor executes the second executable file, and the third cache hit rate when the second processor executes the first executable file and the fourth cache hit rate when the second processor executes the second executable file;

[0088] Calculate the first hit rate difference between the first processor executing the second executable file and the second hit rate difference between the second processor executing the second executable file and the first executable file, and calculate the absolute value of the hit rate difference between the second processor and the first processor based on the first hit rate difference and the second hit rate difference;

[0089] If any of the following conditions are met, the source code used to generate the first executable file and the second executable file will be determined as the target source code:

[0090] The absolute value of the hit rate difference is greater than the first threshold;

[0091] The first cache hit rate, second cache hit rate, third cache hit rate, or fourth cache hit rate is less than the second threshold.

[0092] Optionally, the difference between the second cache hit rate and the first cache hit rate can be used as the first hit rate difference between the first processor executing the second executable file and executing the first executable file; the difference between the fourth cache hit rate and the third cache hit rate can be used as the second hit rate difference between the second processor executing the second executable file and executing the first executable file; the absolute value of the difference between the second hit rate difference and the first hit rate difference can be used as the absolute value of the hit rate difference between the second processor and the first processor.

[0093] Optionally, the first threshold and the second threshold can be set based on experience. The first threshold can be used to determine whether the performance of the second processor is significantly lower than that of the first processor when the second processor processes the same test case. The second threshold can refer to the preset minimum acceptable hit rate, which is used to determine whether the basic performance of the cache meets the standard.

[0094] Understandably, if the absolute value of the hit rate difference between the second processor and the first processor is greater than the first threshold, it means that the second processor's performance is significantly improved or significantly worse than the first processor when processing the source code. Regardless of whether the second processor's performance is better or worse, by analyzing the source code and the differences in cache architecture between the second and first processors, the performance differences of different cache architectures in the usage scenario of the source code can be clarified. This allows for targeted modification of the second processor's cache architecture or provides a basis for subsequent cache architecture design.

[0095] Furthermore, if the third or fourth cache hit rate is less than the second threshold, it indicates that the second processor has a low hit rate for this source code, and there is a performance bottleneck for this type of source code. Therefore, the test cache architecture can be analyzed based on the source code. If the first or second cache hit rate is less than the second threshold, it indicates that the source code is an extreme test case of the reference cache architecture. Similarly, the execution of the test cache architecture can be analyzed by referring to the test cache architecture.

[0096] The performance analysis of the test caching architecture based on the target source code may include:

[0097] Analyze the target source code, determine its functional scenarios, and conduct multi-dimensional analysis of the test cache architecture based on the cache hit rate monitoring results and the functional scenarios of the target source code.

[0098] Optionally, core features of the target source code can be identified using code analysis tools, including but not limited to: function call frequency, instruction complexity, data access patterns, and functional types, and then the actual application scenario corresponding to the target source code can be determined based on the core features of the target source code.

[0099] Optionally, multi-dimensional analysis of the test caching architecture may include analysis of robustness, basic performance, and scenario adaptability.

[0100] Optionally, if the first cache hit rate, second cache hit rate, third cache hit rate, or fourth cache hit rate is less than the second threshold, it indicates that the basic caching efficiency of the caching architecture is insufficient for the target source code. In this case, the core parameters such as cache capacity and mapping strategy of the two caching architectures can be compared to determine how to optimize the caching architecture.

[0101] Optionally, the functional scenarios of the target source code can be considered to determine whether the test cache architecture is unsuitable for specific functional scenarios, and then the test cache architecture can be optimized based on the specific functional scenarios.

[0102] The technical solution of this invention involves sequentially compiling the source code in the test cases to generate an intermediate representation of the source code. Based on this intermediate representation, a first executable file without perturbations and a second executable file with injected lightweight code layout perturbations are generated. Invalid functions are deleted from both the first and second executable files. The function arrangement in the second executable file is adjusted according to the function arrangement in the first executable file. The optimized first and second executable files are then loaded into a first processor with a reference cache architecture and a second processor with a test cache architecture, respectively, for execution. The cache hit rate in the first and second processors is monitored. Based on the cache hit rate monitoring results, target source code is selected from the test cases, and then... The method of analyzing the performance of test caching architectures can eliminate interference from invalid code during the verification process, avoid invalid code occupying cache space and causing errors in hit rate testing, and eliminate interference from layout differences and avoid the impact of address drift. It ensures that the same instructions are loaded into a fixed location in the cache, ensuring consistent cache behavior in multiple tests and cross-platform tests, thereby improving the accuracy and reliability of verification results. Furthermore, by introducing lightweight layout perturbations, layout perturbation comparison tests can be performed, simulating layout changes caused by compilation optimization and code modification in real-world applications. This can accurately trigger issues such as cache conflicts and performance jitter, and quickly quantify the impact of perturbations on cache effectiveness. It provides data support for the robustness and performance bottleneck analysis of different caching architectures, significantly improving the efficiency of problem localization and analysis.

[0103] Example 3

[0104] Figure 3 This is a schematic diagram of the structure of a performance verification device for an instruction cache provided in Embodiment 3 of the present invention. Figure 3As shown, the device includes: an executable file generation module 310, an executable file optimization module 320, an executable file loading module 330, and a cache architecture performance analysis module 340.

[0105] The executable file generation module 310 is used to compile the source code in the test cases in sequence, generate an intermediate representation of the source code, and generate a first executable file without perturbation and a second executable file with lightweight code layout perturbation injected according to the intermediate representation.

[0106] The executable file optimization module 320 is used to delete invalid functions in the first executable file and the second executable file respectively, and adjust the function arrangement in the second executable file according to the function arrangement in the first executable file to generate optimized first executable file and second executable file.

[0107] The executable file loading module 330 is used to load the optimized first executable file and the second executable file into the first processor equipped with the reference cache architecture and the second processor equipped with the test cache architecture, respectively, and to monitor the cache hit rate in the first processor and the second processor.

[0108] The cache architecture performance analysis module 340 is used to filter target source code in test cases based on cache hit rate monitoring results, and analyze the performance of the test cache architecture based on the target source code.

[0109] The technical solution of this invention involves sequentially compiling the source code in the test cases to generate an intermediate representation of the source code. Based on this intermediate representation, a first executable file without perturbations and a second executable file with injected lightweight code layout perturbations are generated. Invalid functions are deleted from both the first and second executable files. The function arrangement in the second executable file is adjusted according to the function arrangement in the first executable file. The optimized first and second executable files are then loaded into a first processor with a reference cache architecture and a second processor with a test cache architecture, respectively, for execution. The cache hit rate in the first and second processors is monitored. Based on the cache hit rate monitoring results, target source code is selected from the test cases, and then... The method of analyzing the performance of test caching architectures can eliminate interference from invalid code during the verification process, avoid invalid code occupying cache space and causing errors in hit rate testing, and eliminate interference from layout differences and avoid the impact of address drift. It ensures that the same instructions are loaded into a fixed location in the cache, ensuring consistent cache behavior in multiple tests and cross-platform tests, thereby improving the accuracy and reliability of verification results. Furthermore, by introducing lightweight layout perturbations, layout perturbation comparison tests can be performed, simulating layout changes caused by compilation optimization and code modification in real-world applications. This can accurately trigger issues such as cache conflicts and performance jitter, and quickly quantify the impact of perturbations on cache effectiveness. It provides data support for the robustness and performance bottleneck analysis of different caching architectures, significantly improving the efficiency of problem localization and analysis.

[0110] Based on the above embodiments, the executable file generation module 310 can be specifically used for:

[0111] Create an intermediate representation copy and inject a lightweight code layout perturbation into the intermediate representation copy;

[0112] The intermediate representation is compiled to generate the first executable file, and a copy of the intermediate representation with injected lightweight code layout perturbation is compiled to generate the second executable file.

[0113] Based on the above embodiments, the executable file generation module 310 can be further specifically used to perform at least one of the following:

[0114] Add no-operation instructions to the non-critical execution path inside the first function;

[0115] Add a placeholder instruction at the end of the second function.

[0116] Based on the above embodiments, the executable file optimization module 320 may include an invalid function deletion unit and a function arrangement unit;

[0117] Invalid function deletion units can be specifically used for:

[0118] Starting from the entry function of the first executable file and the second executable file respectively, query the call relationship between functions, and identify invalid functions that have not been called in the first executable file and the second executable file based on the call relationship between functions;

[0119] Invalid functions are deleted from both the first executable file and the second executable file.

[0120] Based on the above embodiments, the function arrangement unit can be specifically used for:

[0121] Obtain the starting address of each code segment, the order of the code segments, and the order of the functions within each code segment of the first executable file;

[0122] Based on the function arrangement order in each code segment of the first executable file, the target function is identified in the second executable file, copied into the target code segment, and the functions in each code segment of the second executable file are sorted.

[0123] Based on the starting addresses and code segment order of each code segment in the first executable file, the code segments in the second executable file are aligned with the code segments in the first executable file to generate optimized first and second executable files.

[0124] Based on the above embodiments, the cache architecture performance analysis module 340 may include a target source code identification unit and a performance analysis unit.

[0125] The target source code identification unit can be specifically used for:

[0126] The first cache hit rate when the first processor executes the first executable file, the second cache hit rate when the second processor executes the second executable file, and the third cache hit rate when the second processor executes the first executable file and the fourth cache hit rate when the second processor executes the second executable file;

[0127] Calculate the first hit rate difference between the first processor executing the second executable file and the second hit rate difference between the second processor executing the second executable file and the first executable file, and calculate the absolute value of the hit rate difference between the second processor and the first processor based on the first hit rate difference and the second hit rate difference;

[0128] If any of the following conditions are met, the source code used to generate the first executable file and the second executable file will be determined as the target source code:

[0129] The absolute value of the hit rate difference is greater than the first threshold;

[0130] The first cache hit rate, second cache hit rate, third cache hit rate, or fourth cache hit rate is less than the second threshold.

[0131] Based on the above embodiments, the performance analysis unit can be specifically used for:

[0132] Analyze the target source code, determine its functional scenarios, and conduct multi-dimensional analysis of the test cache architecture based on the cache hit rate monitoring results and the functional scenarios of the target source code.

[0133] The instruction cache performance verification device provided in this embodiment of the invention can execute the instruction cache performance verification method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0134] Example 4

[0135] Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0136] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0137] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0138] Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the instruction cache performance verification method described in the embodiments of the present invention. That is:

[0139] The source code in the test cases is compiled sequentially to generate an intermediate representation of the source code. Based on the intermediate representation, a first executable file without perturbation and a second executable file with lightweight code layout perturbation are generated respectively.

[0140] Invalid functions are deleted from both the first and second executable files. Based on the function arrangement in the first executable file, the function arrangement in the second executable file is adjusted to generate optimized first and second executable files.

[0141] The optimized first executable file and second executable file are loaded into the first processor equipped with the reference cache architecture and the second processor equipped with the test cache architecture, respectively, and the cache hit rate in the first processor and the second processor is monitored.

[0142] Based on the cache hit rate monitoring results, target source code is selected from the test cases, and the performance of the test cache architecture is analyzed based on the target source code.

[0143] In some embodiments, the instruction cache performance verification method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the instruction cache performance verification method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the instruction cache performance verification method by any other suitable means (e.g., by means of firmware).

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

[0145] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

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

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

[0148] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0149] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0150] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0151] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method of performance verification of an instruction cache, characterized by, The method comprises the following steps: Compiling the source code in the test case in sequence, generating an intermediate representation of the source code, and generating a first executable file without added disturbance and a second executable file with injected lightweight code layout disturbance according to the intermediate representation; Respectively deleting invalid functions in the first executable file and the second executable file, and adjusting the function arrangement of the second executable file according to the function arrangement mode in the first executable file to generate optimized first and second executable files; Loading the optimized first and second executable files into a first processor with a reference cache architecture and a second processor with a test cache architecture respectively for execution, and monitoring the cache hit rate in the first and second processors; According to the cache hit rate monitoring result, target source code is screened in the test case, and the performance of the test cache architecture is analyzed according to the target source code.

2. The method of claim 1, wherein, According to the intermediate representation, a first executable file without added disturbance and a second executable file with injected lightweight code layout disturbance are generated, which comprises: Creating an intermediate representation copy and injecting lightweight code layout disturbance into the intermediate representation copy; Compiling the intermediate representation to generate the first executable file, and compiling the intermediate representation copy with injected lightweight code layout disturbance to generate the second executable file.

3. The method of claim 2, wherein, Injecting lightweight code layout disturbance into the intermediate representation copy comprises at least one of the following: Adding a null operation instruction in a non-critical execution path inside a first function; Adding an instruction placeholder at the end of a second function.

4. The method of claim 1, wherein, Respectively deleting invalid functions in the first executable file and the second executable file, which comprises: Starting from the entry function of the first executable file and the second executable file respectively, the calling relationship between functions is queried, and according to the calling relationship between functions, invalid functions in the first executable file and the second executable file that are not called are identified; Respectively deleting invalid functions in the first executable file and the second executable file.

5. The method of claim 1, wherein, According to the function arrangement mode in the first executable file, the function arrangement of the second executable file is adjusted to generate optimized first and second executable files, which comprises: Obtaining the starting address of each code segment of the first executable file, the arrangement order of the code segments, and the arrangement order of the functions in each code segment; According to the arrangement order of the functions in each code segment of the first executable file, target functions are identified in the second executable file, the target functions are copied to target code segments, and the functions in each code segment of the second executable file are sorted; According to the starting address of each code segment of the first executable file and the arrangement order of the code segments, the code segments in the second executable file are aligned with the code segments in the first executable file to generate optimized first and second executable files.

6. The method of claim 1, wherein, According to the cache hit rate monitoring result, target source code is screened in the test case, which comprises: acquire a first cache hit rate when the first processor executes the first executable file, a second cache hit rate when the first processor executes the second executable file, a third cache hit rate when the second processor executes the first executable file, and a fourth cache hit rate when the second processor executes the second executable file; calculate a first hit rate difference of the second executable file compared with the first executable file executed by the first processor, and a second hit rate difference of the second executable file compared with the first executable file executed by the second processor, and calculate an absolute value of a hit rate difference of the second processor compared with the first processor according to the first hit rate difference and the second hit rate difference; if any of the following conditions is met, the source code used to generate the first executable file and the second executable file is determined as target source code: the absolute value of the hit rate difference is greater than a first threshold value; the first cache hit rate, the second cache hit rate, the third cache hit rate, or the fourth cache hit rate is less than a second threshold value.

7. The method of claim 1, wherein, analyze the performance of the test cache architecture according to the target source code, including: parsing the target source code to determine the functional scenario of the target source code, and performing multi-dimensional analysis on the test cache architecture according to the cache hit rate monitoring result corresponding to the target source code and the functional scenario of the target source code.

8. A performance verification device for instruction cache, characterized in that, including: an executable file generation module configured to compile the source code in the test case in sequence, generate an intermediate representation of the source code, and generate a first executable file without adding perturbation and a second executable file injected with lightweight code layout perturbation according to the intermediate representation; an executable file optimization module configured to delete invalid functions in the first executable file and the second executable file respectively, and adjust the function arrangement of the second executable file according to the function arrangement of the first executable file to generate optimized first executable file and second executable file; an executable file loading module configured to load the optimized first executable file and the second executable file into the first processor with the reference cache architecture and the second processor with the test cache architecture respectively for execution, and monitor the cache hit rate in the first processor and the second processor; a cache architecture performance analysis module configured to filter target source code in the test case according to the cache hit rate monitoring result, and analyze the performance of the test cache architecture according to the target source code.

9. An electronic device, comprising: The electronic device includes: at least one processor; and a memory connected in communication with the at least one processor; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the instruction cache performance verification method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for causing the processor to execute the instruction cache performance verification method of any one of claims 1-7 when executed. The computer readable storage medium stores computer instructions for causing the processor to execute the instruction cache performance verification method of any one of claims 1-7 when executed.

Images