Processor performance hardware optimization method, system, electronic device and storage medium

Abstract

The present disclosure provides a processor performance hardware optimization method, system, electronic device, and storage medium, and relates to the field of computer technology. The processor performance hardware optimization method includes: in response to the performance monitoring function for the processor being turned on, controlling all target hardware event controllers on the processor to monitor the real-time performance data of the corresponding hardware events; determining a first degree of deviation between the real-time performance data and the corresponding standard performance data; binding the hardware event corresponding to the first degree of deviation that meets the first threshold to a hardware event counter, and monitoring the target number of corresponding hardware events based on the hardware event counter; determining the performance bottleneck of the processor based on the target number; and optimizing the performance of the processor based on the performance bottleneck. The present disclosure can improve the efficiency and accuracy of performance bottleneck monitoring and improve the performance of the processor.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a method, system, electronic device, and storage medium for optimizing processor performance hardware. Background Art

[0002] Central Processing Unit (CPU) performance monitoring requires collecting application execution information on the system. For example, hardware monitoring technology can be used to directly collect hardware events from the CPU and / or system to identify performance bottlenecks. Based on these performance bottlenecks, the CPU can then optimize aspects of its core microarchitecture, cache architecture, and program architecture. To collect hardware events, modern CPUs implement a dedicated Performance Monitoring Unit (PMU) to monitor various hardware events. Hardware events refer to the behavior of hardware functions within the CPU.

[0003] The traditional method for CPU performance monitoring and optimization is as follows: configure the hardware event counter (EVENT_COUNTER) to the hardware event you want to monitor, start each EVENT_COUNTER and the corresponding hardware event, collect the EVENT_COUNTER values ​​for numerical analysis, and then monitor different hardware events multiple times. Repeat this process to determine the performance bottleneck and optimize the CPU performance based on the performance bottleneck. However, the traditional method for CPU performance monitoring and optimization has the following drawbacks:

[0004] 1. Slow monitoring efficiency: The CPU supports hundreds of hardware events, but the number of EVENT_COUNTER is small, for example, 5. Therefore, using EVENT_COUNTER to cyclically monitor all hardware events is extremely inefficient.

[0005] 2. Low monitoring result accuracy: For example, if the traditional solution monitors hardware event A and determines that there are some bottleneck restrictions in hardware event A, it is concluded that the performance bottleneck of the entire CPU system is in hardware event A. In fact, the real performance bottleneck is in hardware event B that is not monitored. This will cause inaccurate performance bottleneck monitoring results. Even if CPU performance optimization is performed based on the performance bottleneck monitoring results, it is impossible to truly bring out the best performance of the CPU. Summary of the Invention

[0006] The present disclosure provides a processor performance hardware optimization method, system, electronic device, and storage medium to at least solve the above technical problems existing in the prior art.

[0007] According to a first aspect of the present disclosure, a method for processor performance hardware optimization is provided, comprising: in response to activation of a performance monitoring function for a processor, controlling all target hardware event controllers on the processor to monitor real-time performance data of corresponding hardware events; determining a first degree of deviation between the real-time performance data and corresponding standard performance data; binding hardware events corresponding to the first degree of deviation that meet a first threshold to a hardware event counter, and monitoring a target number of corresponding hardware events based on the hardware event counter; determining a performance bottleneck of the processor based on the target number; and optimizing the performance of the processor based on the performance bottleneck.

[0008] In another possible implementation, before determining the first degree of deviation between the real-time performance data and the corresponding standard performance data, the method further includes: running the processor based on a standard test model program to obtain original performance standards corresponding to all hardware events on the processor; determining a second degree of deviation between the original performance standard and the standard performance data; in response to the second degree of deviation satisfying a second threshold, generating warning data of abnormality of the standard performance data and outputting it to the user end; obtaining new standard performance data; the new standard performance data is standard performance data regenerated by the user end based on the warning data, or standard performance data obtained by weighted averaging the original performance standard and the standard performance data.

[0009] In another possible implementation, determining the first degree of deviation between the real-time performance data and the corresponding standard performance data includes: determining the difference between the real-time performance data and the corresponding standard performance data; and determining the ratio of the difference to the standard performance data as the first degree of deviation.

[0010] In another possible implementation, the performance optimization of the processor based on the performance bottleneck includes: in response to the performance bottleneck existing in the core microarchitecture of the processor, monitoring the processing time of each processing stage in the instruction processing flow of the core microarchitecture; and executing corresponding optimization measures for the processing stage whose processing time meets a third threshold.

[0011] In another possible implementation, the monitoring of the processing time of each processing stage in the instruction processing flow of the core microarchitecture includes: monitoring the interval between two instruction fetches in the instruction fetch stage; monitoring the interval between two decodings in the decoding stage; monitoring the time for each execution unit to complete instruction data operations in the execution stage; monitoring the time for each instruction memory access operation in the memory access stage; and monitoring the time for each instruction to be written back to the target storage location of the processor in the write back stage.

[0012] In another possible implementation, the corresponding optimization measures are performed on the processing stages whose processing duration meets the third threshold, including: in response to the processing duration of the instruction fetch stage and the decoding stage meeting the third threshold, the instruction prefetch function is enabled, the instruction issuance width is increased and / or the mapping relationship of the instruction conversion backup buffer ITLB is optimized; the mapping relationship between the virtual address and the physical address corresponding to the instruction is stored in the ITLB; in response to the processing duration of the execution stage and the memory access stage meeting the third threshold, the instruction execution width is increased and / or the mapping relationship of the data conversion backup buffer DTLB is optimized; the mapping relationship between the virtual address and the physical address corresponding to the data is stored in the DTLB; in response to the processing duration of the write-back stage meeting the third threshold, the cache depth of the reorder buffer ROB is increased and / or write-back status fast processing is performed; the write-back status fast processing includes early write-back, register renaming enhancement and / or increased write-back bandwidth.

[0013] In another possible implementation, the performance optimization of the processor based on the performance bottleneck includes: in response to the performance bottleneck existing in the cache architecture of the processor, monitoring the data hit rates corresponding to different cache parts in the cache architecture; the cache parts include a translation lookaside buffer TLB, a first-level cache, and a second-level cache; and executing corresponding optimization measures on the cache parts whose data hit rates meet a fourth threshold.

[0014] In another possible implementation, the corresponding optimization measures are performed on the cache portion whose data hit rate meets the fourth threshold, including: in response to the data hit rate of the TLB meeting the fourth threshold, based on the rule of software sending virtual addresses, the page table storing the mapping relationship between virtual addresses and physical addresses in the double data rate DDR memory is updated to the TLB; in response to the data hit rate of the first-level cache meeting the fourth threshold, based on the rule of system bus sending addresses, the corresponding access address in the second-level cache or the DDR memory is updated to the first-level cache; in response to the data hit rate of the second-level cache meeting the fourth threshold, based on the rule of system bus sending addresses, the corresponding access address in the DDR memory is updated to the second-level cache.

[0015] According to a second aspect of the present disclosure, a processor performance hardware optimization system is provided, comprising: a bottleneck analysis controller for, in response to activation of a performance monitoring function for a processor, controlling all target hardware event controllers on the processor to monitor real-time performance data of corresponding hardware events; determining a first degree of deviation between the real-time performance data and corresponding standard performance data; binding hardware events corresponding to the first degree of deviation that meet a first threshold to a hardware event counter, and monitoring a target number of corresponding hardware events based on the hardware event counter; determining a performance bottleneck of the processor based on the target number; and a performance optimizer for optimizing the performance of the processor based on the performance bottleneck.

[0016] In another possible implementation, the bottleneck analysis controller is further used to: run the processor based on a standard test model program to obtain original performance standards corresponding to all hardware events on the processor; determine a second degree of deviation between the original performance standard and the standard performance data; in response to the second degree of deviation satisfying a second threshold, generate warning data of abnormality of the standard performance data and output it to the user end; obtain new standard performance data; the new standard performance data is standard performance data regenerated by the user end based on the warning data, or standard performance data obtained by weighted averaging the original performance standard and the standard performance data.

[0017] In another possible implementation, the bottleneck analysis controller is further configured to: determine a difference between the real-time performance data and corresponding standard performance data; and determine a ratio of the difference to the standard performance data as the first deviation degree.

[0018] In another possible embodiment, the performance optimizer includes a microarchitecture controller, which is used to: in response to the performance bottleneck existing in the core microarchitecture of the processor, monitor the processing time of each processing stage in the instruction processing flow of the core microarchitecture; and execute corresponding optimization measures for the processing stage whose processing time meets a third threshold.

[0019] In another possible embodiment, the microarchitecture controller is also used to: monitor the interval between two instruction fetches in the instruction fetch stage; monitor the interval between two decodings in the decoding stage; monitor the time it takes for each execution unit to complete instruction data operations in the execution stage; monitor the time it takes for each instruction to access the memory in the memory access stage; and monitor the time it takes for each instruction to be written back to the target storage location of the processor in the write back stage.

[0020] According to a third aspect of the present disclosure, an electronic device is provided, comprising: the processor performance hardware optimization system described in the present disclosure.

[0021] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause the computer to execute the method described in the present disclosure.

[0022] The processor performance hardware optimization method, system, electronic device, and storage medium disclosed herein, when monitoring processor performance, will synchronously monitor the real-time performance data of all hardware events, obtain comprehensive performance bottlenecks of the processor, and improve the efficiency and accuracy of performance bottleneck monitoring; and based on the performance bottlenecks, the processor's core microarchitecture and cache architecture are targetedly optimized to improve processor performance.

[0023] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The above and other objects, features and advantages of the exemplary embodiments of the present disclosure will become readily understood by reading the detailed description below with reference to the accompanying drawings, in which several embodiments of the present disclosure are shown by way of example and not limitation, wherein:

[0025] In the drawings, the same or corresponding reference numerals denote the same or corresponding parts.

[0026] Figure 1 The schematic diagram shows a process flow of a method for optimizing processor performance hardware according to an embodiment of the present disclosure. Figure 1 ;

[0027] Figure 2 A schematic diagram of a process flow of a processor performance hardware optimization method according to an embodiment of the present disclosure is shown. Figure 2 ;

[0028] Figure 3 A schematic diagram of a process flow of a processor performance hardware optimization method according to an embodiment of the present disclosure is shown. Figure 3 ;

[0029] Figure 4 A schematic diagram of the structure of a processor performance optimization system in the prior art is shown;

[0030] Figure 5 A schematic diagram of the structure of a processor performance hardware optimization system according to an embodiment of the present disclosure is shown;

[0031] Figure 6 A schematic diagram of the structure of a cache architecture controller according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0032] To make the purposes, features, and advantages of the present disclosure more apparent and understandable, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present disclosure without creative work shall fall within the scope of protection of the present disclosure.

[0033] Figure 4 A schematic diagram of the structure of a processor performance optimization system in the prior art is shown. Figure 4 As shown, the traditional CPU main structure includes a processing core Core. If it is a multi-core processor, there will be multiple cores, that is, Figure 4 Core0-CoreN in the CPU. The processor core is connected to the L1 cache and L2 cache, which together form the CPU's cache system. The L2 cache is connected to double data rate (DDR) memory. The Performance Monitoring Controller (PMC) monitors the performance of the entire system. The hardware event controller (Event_Ctrl) stores a large amount of data and is distributed across various functional modules of the CPU. It monitors hardware events at different levels of the CPU structure. For example, the hardware event controller at the processor core level can monitor the instructions per cycle (IPC), front-end pipeline stall efficiency, and back-end pipeline stall efficiency within the core. The hardware event controller at the L1 cache level can monitor the L1 cache hit rate and the number of load / store memory operations.

[0034] The user or software controls the hardware event counter (EVENT_COUNTER) in the PMC, configures it to the hardware event you want to monitor, starts each EVENT_COUNTER and the corresponding hardware event, collects the EVENT_COUNTER value for numerical analysis, and then monitors different hardware events multiple times. Repeating the above process, you can conclude that the performance bottleneck has occurred. Traditional CPU performance monitoring has the problems of slow monitoring efficiency and low monitoring accuracy.

[0035] Figure 1 A schematic diagram of a process flow of a processor performance hardware optimization method according to an embodiment of the present disclosure is shown. Figure 1 ,like Figure 1 As shown, a processor performance hardware optimization method includes:

[0036] Step S101 : In response to the performance monitoring function for the processor being enabled, all target hardware event controllers on the processor are controlled to monitor real-time performance data of corresponding hardware events.

[0037] In this embodiment, when a user or system activates the processor's performance monitoring function, all target hardware event controllers on the processor are activated. The target hardware event controllers are responsible for monitoring real-time performance data for the corresponding hardware events. For example, hardware event controller A monitors the L1 cache hit rate, while hardware event controller B monitors the number of instructions per cycle (IPC). The processor may be a RISC-V CPU, which is a multi-core Reduced Instruction Set Computing (RISC)-based CPU. The target hardware event controllers may be some or all of the hardware event controllers in the processor. The hardware event controllers corresponding to the hardware events of interest to the user may be identified as target hardware event controllers, while the hardware event controllers corresponding to hardware events the user does not want to be aware of may be blocked, resulting in the user not receiving results from the blocked hardware event controllers.

[0038] In traditional optimization schemes, hardware event controllers monitor corresponding hardware events. They only begin operating after the software has issued a configuration and enabled the corresponding hardware event controller. However, in this embodiment, after the software enables the processor's PMC, all hardware event controllers on the processor begin operating. Furthermore, a user-configurable monitoring time (T_Monitor) can be set for the hardware event controllers. After T_Monitor is reached, all hardware event controllers cease operation.

[0039] Step S102: determining a first deviation degree between the real-time performance data and the corresponding standard performance data.

[0040] In this embodiment, real-time performance data (Real_performance) refers to the actual performance of the current hardware event collected by the hardware event controller during monitoring. Standard performance data (Basic_performance) is the performance benchmark that the user or system pre-sets and expects the hardware event to achieve. The difference between the real-time performance data and the standard performance data can be calculated and determined as the first deviation degree. For example, if the standard performance data for hardware event A is 90% and the real-time performance data is 85%, the first deviation degree is 90%-85%. The first deviation degree reflects the gap between the actual performance of the current hardware event and the expected performance, providing a quantitative basis for subsequent performance bottleneck determination. Different hardware events can correspond to different standard performance data. For example, if hardware event controller C monitors the L1 hit rate and hardware event controller D monitors the IPC, the standard performance data for hardware event controller C can be configured to be 90%, while the standard performance data for hardware event controller D can be configured to be 3.

[0041] Step S103 : Bind a hardware event corresponding to a first deviation degree that meets a first threshold to a hardware event counter, and monitor a target number of times of the corresponding hardware event based on the hardware event counter.

[0042] In this embodiment, the first threshold is a preset value used to screen out hardware events whose actual performance is significantly different from the standard performance. When the first deviation degree of a hardware event exceeds the first threshold, it indicates that the real-time performance of the hardware event is significantly different from the expectation, which may be a potential source of a performance bottleneck. The hardware event can then be bound to a hardware event counter (EVENT_COUNTER). The hardware event counter is used to record the target number of times the hardware event occurs within a certain period of time, that is, the frequency of occurrence of the hardware event. The target number represents the number of times the real-time performance data of the corresponding hardware event does not meet the standard performance data, and can be used to analyze performance bottlenecks.

[0043] Step S104: determining the performance bottleneck of the processor based on the target number.

[0044] In this embodiment, based on the target number of times recorded by the hardware event counter, it is possible to determine which hardware events occur frequently and exhibit poor performance. Hardware events with high target numbers are more likely to represent processor performance bottlenecks. For example, if the target number of hardware event A is much higher than that of other hardware events, and its first deviation degree is also large, then hardware event A can be determined to be the performance bottleneck of the current processor.

[0045] Step S105: Optimize the performance of the processor based on the performance bottleneck.

[0046] In this embodiment, after identifying the processor's performance bottleneck, appropriate optimization measures are taken based on the specific circumstances of the bottleneck. For example, if the performance bottleneck is caused by a low L1 cache hit rate, cache management strategies can be optimized, such as adjusting the cache size and improving the cache replacement algorithm. If the performance bottleneck is caused by inefficient instruction execution, instruction scheduling can be optimized, such as increasing the depth of the instruction pipeline. By optimizing performance bottlenecks, the overall performance of the processor can be effectively improved, allowing it to better meet application requirements.

[0047] In the present disclosure, hardware self-monitoring of processor performance bottlenecks is implemented, and the performance bottlenecks of all hardware events are ranked, thus finding the real performance bottleneck on the processor. Compared with traditional solutions, it can greatly speed up performance monitoring and improve the accuracy of performance monitoring.

[0048] In another embodiment, before step S102 of "determining a first degree of deviation between real-time performance data and corresponding standard performance data", a method for optimizing processor performance hardware further includes:

[0049] The processor is run based on a standard test model program to obtain the original performance standards corresponding to all hardware events on the processor.

[0050] In this embodiment, to ensure the accuracy of standard performance data, the present invention uses a standard test model program to run the processor. The standard test model program is a representative test program that comprehensively covers various processor functions. By running this program, the original performance standards (Basic_performance_model) of all hardware events on the processor under standard test conditions can be obtained. For example, after running the standard test model program, the original performance standard for hardware event A is 88%, the original performance standard for hardware event B is 3.2, and so on.

[0051] A second degree of deviation of the original performance standard from the standard performance data is determined.

[0052] In this embodiment, the original performance standard obtained by the standard test model program is compared with the standard performance data preset by the user or the system, and the difference between them is calculated. This difference is then determined as the second degree of deviation. For example, if the original performance standard of hardware event A is 88%, and the standard performance data set by the user is 90%, then the second degree of deviation is 90%-88%. The second degree of deviation reflects the difference between the standard performance data set by the user and the original performance standard obtained by the actual test, and is used to determine the rationality of the standard performance data.

[0053] In response to the second deviation degree meeting the second threshold, warning data indicating that the standard performance data is abnormal is generated and output to the user terminal.

[0054] In this embodiment, the second threshold is a preset value used to determine whether the standard performance data is abnormal. When the second deviation exceeds the second threshold, it indicates that there is a significant difference between the standard performance data set by the user and the original performance standard obtained in actual testing. This may be due to reasons such as unreasonable user settings or changes in the test environment. In this case, warning data indicating abnormal standard performance data is generated and output to the user terminal, reminding the user that there may be problems with the standard performance data and that reassessment or adjustment is required.

[0055] Obtain new standard performance data; the new standard performance data is standard performance data regenerated by the user end based on the warning data, or standard performance data obtained by weighted averaging the original performance standard and the standard performance data.

[0056] In this embodiment, after receiving the warning data, the user terminal can regenerate the standard performance data according to the actual situation. The new standard performance data can be reset by the user based on new test results or experience, or it can be obtained by weighted averaging the original performance standard and the standard performance data set by the user. For example, if the user believes that the original performance standard is closer to the actual operating conditions, the original performance standard can be used as the new standard performance data, or a new standard performance data can be reissued; if the user has not issued new standard performance data for a long time, the original performance standard can be weighted averaged with the standard performance data set by the user to obtain a new standard performance data. In this way, the accuracy and rationality of the standard performance data can be ensured, providing a reliable basis for subsequent performance monitoring and optimization.

[0057] In another embodiment, step S102 of “determining a first degree of deviation between the real-time performance data and the corresponding standard performance data” includes:

[0058] Determine the difference between the real-time performance data and the corresponding standard performance data; and determine the ratio of the difference to the standard performance data as a first deviation degree.

[0059] In this embodiment, when calculating the first degree of deviation, the difference between the real-time performance data and the standard performance data is first calculated. For example, for hardware event A, the real-time performance data is 85% and the standard performance data is 90%, then the difference is 90%-85%=5%. The difference reflects the absolute gap between the real-time performance data and the standard performance data, and is the basic data for calculating the first degree of deviation. The ratio of the difference to the standard performance data is then determined as the first degree of deviation. Taking hardware event A as an example, the difference is 5% and the standard performance data is 90%, then the first degree of deviation is 5% / 90%≈0.056. The first degree of deviation is expressed in the form of a ratio, which can more intuitively reflect the relative gap between the real-time performance data and the standard performance data, and is convenient for subsequent performance bottleneck judgment and optimization decisions. It should be emphasized that the second degree of deviation is calculated in a similar manner to the first degree of deviation, and will not be repeated here.

[0060] Figure 2 A schematic diagram of a process flow of a processor performance hardware optimization method according to an embodiment of the present disclosure is shown. Figure 2 ,like Figure 2 As shown, a processor performance hardware optimization method includes:

[0061] Step S201 : In response to the performance monitoring function for the processor being enabled, all target hardware event controllers on the processor are controlled to monitor real-time performance data of corresponding hardware events.

[0062] Step S202: determining a first deviation degree between the real-time performance data and the corresponding standard performance data.

[0063] Step S203 : Bind a hardware event corresponding to a first deviation degree that meets a first threshold to a hardware event counter, and monitor a target number of times of the corresponding hardware event based on the hardware event counter.

[0064] Step S204: determining the performance bottleneck of the processor based on the target number.

[0065] The specific implementation details of steps S201 to S204 are similar to those of steps S101 to S104 and are not repeated here.

[0066] Step S205 , in response to a performance bottleneck existing in the core micro-architecture of the processor, monitoring the processing time of each processing stage in the instruction processing flow of the core micro-architecture.

[0067] In this embodiment, when it is determined that the performance bottleneck exists in the core micro-architecture of the processor, the instruction processing flow of the core micro-architecture is further monitored. The instruction processing flow of the core micro-architecture generally includes stages such as instruction fetch, decoding, execution, memory access and write back. By monitoring the processing time of each processing stage, the performance of the core micro-architecture at different stages can be analyzed in detail. For example, the interval between two instruction fetches in the instruction fetch stage, the interval between two decodings in the decoding stage, the time it takes for each execution unit to complete instruction data calculations in the execution stage, the time it takes for each instruction to access memory in the memory access stage, and the time it takes for each instruction to be written back to the target storage location of the processor in the write back stage are monitored. These processing time data provide a detailed performance analysis basis for the optimization of the core micro-architecture. Among them. The instruction fetch stage is used to read instructions from memory according to the value of the program counter (PC); the decoding stage is used to send the instruction in the instruction register to the decoder for decoding. The decoder converts the instruction into a series of control signals. These control signals are used to control other components of the CPU to perform corresponding operations; the execution stage is used to coordinate the various components of the CPU to perform the operations specified by the instruction according to the control signals generated in the decoding stage; the memory access stage is used if the instruction needs to read data from the memory or write data to the memory, the CPU will perform memory access operations at this stage; the write back stage is used to write the result of the instruction execution back to the CPU register or memory. If it is an arithmetic operation instruction, the result will be written back to the destination register. If it is a data transfer instruction, the data will be written to the memory or other destination.

[0068] Step S206: executing corresponding optimization measures for the processing phase whose processing duration meets the third threshold.

[0069] In this embodiment, the third threshold is a preset value used to determine whether the processing duration of a processing stage is abnormal. When the processing duration of a processing stage exceeds the third threshold, it indicates that this stage may be the location of a core microarchitecture performance bottleneck. Optimization measures are taken according to different processing stages. For example, if the processing duration of the instruction fetch and decode stages exceeds the third threshold, instruction prefetching can be enabled, the instruction issue width can be increased, and / or the mapping relationship of the instruction translation lookaside buffer (ITLB) can be optimized. If the processing duration of the execute and memory access stages exceeds the third threshold, the instruction execution width can be increased and / or the mapping relationship of the data translation lookaside buffer (DTLB) can be optimized. If the processing duration of the writeback stage exceeds the third threshold, the cache depth of the reorder buffer (ROB) can be increased and / or writeback status fast processing can be performed. By optimizing performance bottlenecks in processing stages, the performance of the core microarchitecture can be effectively improved, thereby improving the overall performance of the processor.

[0070] In another embodiment, the step S205 of “monitoring the processing time of each processing stage in the instruction processing flow of the core micro-architecture” includes:

[0071] Monitor the interval between two instruction fetches in the instruction fetch phase.

[0072] In this embodiment, during the instruction fetch phase of the core microarchitecture, the interval between two instruction fetches is monitored. This interval can be determined based on the number of clock cycles (T_Cycle_fetch) between the two fetches. This interval reflects the efficiency of the instruction fetch operation. A long interval may indicate a bottleneck in the instruction fetch operation, such as a low instruction cache hit rate or insufficient instruction prefetching. By monitoring the interval, performance issues during the instruction fetch phase can be promptly identified, providing a basis for subsequent optimization measures.

[0073] Monitor the interval between two decodings during the decoding phase.

[0074] In this embodiment, during the decoding phase, the duration between two decoding operations is monitored. This duration can be determined by measuring the number of clock cycles between the two decoding operations (T_Cycle_decode). The decoding interval reflects the speed of instruction decoding. A long decoding interval may indicate low decoder efficiency, such as high instruction complexity or inappropriate decoder design. By monitoring the decoding interval, performance during the decoding phase can be accurately assessed, providing a reference for further performance optimization.

[0075] Monitor the time it takes for each execution unit to complete instruction data operations during the execution phase.

[0076] In this embodiment, during the execution phase, the time it takes for each execution unit to complete the instruction data operation is monitored, and the time it takes to complete the instruction data operation can be determined by the clock cycle in which each execution unit completes the instruction data operation. The execution time reflects the computational efficiency of the execution unit. If the execution time of an execution unit is long, it may mean that the execution unit has a performance bottleneck, such as an excessively high load on the execution unit or complex instruction dependencies. By monitoring the execution time, the performance bottleneck of the execution phase can be determined, providing data support for optimizing the performance of the execution unit.

[0077] Monitor the duration of memory access operations of each instruction in the memory access stage.

[0078] In this embodiment, during the memory access phase, the duration of the memory access operation of each instruction is monitored. The duration of the memory access operation can be determined by the clock cycles occupied by each instruction memory access operation. The memory access duration reflects the efficiency of the memory access operation. If the memory access duration is long, it may indicate a bottleneck in the memory access operation, such as a low cache hit rate or high memory latency. By monitoring the memory access duration, performance issues in the memory access phase can be discovered in a timely manner, providing a basis for optimizing memory access operations.

[0079] The length of time during the write-back phase for each instruction to be written back to the target memory location of the processor is monitored.

[0080] In this embodiment, during the write-back phase, the duration of each instruction being written back to the processor's target storage location is monitored. The duration of each instruction being written back to the processor's target storage location (e.g., a register or memory) can be used to determine the clock cycles occupied by the instruction being written back to the processor's target storage location. The write-back duration reflects the efficiency of the write-back operation. A long write-back duration may indicate a bottleneck in the write-back operation, such as an overly long write-back queue or insufficient write-back bandwidth. By monitoring the write-back duration, the performance of the write-back phase can be accurately assessed, providing a reference for further performance optimization.

[0081] In another embodiment, step S206 of “executing corresponding optimization measures for the processing stage whose processing duration meets the third threshold” includes:

[0082] In response to the processing time of the instruction fetch stage and the decoding stage meeting the third threshold, the instruction prefetch function is enabled, the instruction issuance width is increased and / or the mapping relationship of the instruction translation backup buffer ITLB is optimized; the ITLB stores the mapping relationship between the virtual address and the physical address corresponding to the instruction.

[0083] In this embodiment, when the processing time of the instruction fetch and decode stages exceeds a third threshold, it indicates that these two stages may have performance bottlenecks. In this case, the instruction prefetch function can be enabled to preload subsequent instructions into the instruction cache, reducing instruction fetch latency; the instruction issue width can be increased to improve the parallel processing capability of instructions; and the mapping relationship of the instruction translation lookaside buffer (ITLB) can be optimized to improve the efficiency of instruction address translation. The processing time of the instruction fetch and decode stages meeting the third threshold can mean that the ratio of the processing time of the instruction fetch stage to the total processing time of all processing stages in the instruction processing flow is greater than a certain threshold, the ratio of the processing time of the decode stage to the total processing time of all processing stages in the instruction processing flow is greater than a certain threshold, or the ratio of the sum of the processing time of the instruction fetch and decode stages to the total processing time of all processing stages in the instruction processing flow is greater than a certain threshold.

[0084] In response to the processing time of the execution phase and the memory access phase meeting the third threshold, the instruction execution width is increased and / or the mapping relationship of the data translation backup buffer DTLB is optimized; the DTLB stores the mapping relationship between the virtual address and the physical address corresponding to the data.

[0085] In this embodiment, when the processing time of the execution phase and the memory access phase exceeds a third threshold, it indicates that these two phases may have performance bottlenecks. In this case, the instruction execution width can be increased to improve the parallel processing capability of the execution unit; and the mapping relationship of the data translation lookaside buffer (DTLB) can be optimized to improve the efficiency of data address translation. These optimization measures can effectively improve the performance of the execution and memory access phases, thereby improving the overall performance of the core microarchitecture. The processing time of the execution phase and the memory access phase meeting the third threshold can mean that the ratio of the execution phase processing time to the total duration of all processing phases in the instruction processing flow is greater than a certain threshold, the ratio of the memory access phase processing time to the total duration of all processing phases in the instruction processing flow is greater than a certain threshold, or the ratio of the sum of the execution phase and the memory access phase processing time to the total duration of all processing phases in the instruction processing flow is greater than a certain threshold.

[0086] In response to the processing time of the write-back phase meeting the third threshold, the cache depth of the reorder buffer (ROB) is increased and / or write-back status fast processing is performed; write-back status fast processing includes early write-back, register renaming enhancement and / or increased write-back bandwidth.

[0087] In this embodiment, when the write-back processing duration exceeds a third threshold, it indicates a potential performance bottleneck. In this case, the cache depth of the reorder buffer (ROB) can be increased to improve the buffering capacity of write-back operations. Faster write-back status processing can also be performed, such as early write-back, register renaming enhancements, and / or increased write-back bandwidth. These optimization measures can effectively improve write-back performance, thereby enhancing the overall performance of the core microarchitecture.

[0088] As RISC-V CPUs are increasingly used in professional computing, scientific computing and other fields, one feature of these fields is that their program architecture is relatively fixed, that is, the software programs running on RISC-V CPUs are relatively fixed. However, the core microarchitecture of RISC-V CPUs may not necessarily be able to perform optimally under the current software architecture. Through the present disclosure, the core microarchitecture of RISC-V CPUs can be adjusted to the optimal performance state.

[0089] Figure 3 A schematic diagram of a process flow of a processor performance hardware optimization method according to an embodiment of the present disclosure is shown. Figure 3 ,like Figure 3 As shown, a processor performance hardware optimization method includes:

[0090] Step S301 : In response to the performance monitoring function for the processor being enabled, all target hardware event controllers on the processor are controlled to monitor real-time performance data of corresponding hardware events.

[0091] Step S302: determining a first deviation degree between the real-time performance data and the corresponding standard performance data.

[0092] Step S303 : Bind a hardware event corresponding to a first deviation degree that meets a first threshold to a hardware event counter, and monitor a target number of times of the corresponding hardware event based on the hardware event counter.

[0093] Step S304: determining the performance bottleneck of the processor based on the target number.

[0094] The specific implementation details of steps S301 to S304 are similar to those of steps S101 to S104 and are not repeated here.

[0095] Step S305 , in response to a performance bottleneck existing in the cache architecture of the processor, monitoring data hit rates corresponding to different cache parts in the cache architecture.

[0096] In this embodiment, when a performance bottleneck is determined to exist within the processor's cache architecture, the data hit rates of different cache components within the cache architecture are further monitored. Cache components typically include the translation lookaside buffer (TLB), level 1 cache (L1 cache), and level 2 cache (L2 cache). By monitoring the TLB hit rate, the L1 cache hit rate, and the L2 cache hit rate, the performance of the cache architecture at different levels can be analyzed in detail. For example, the hit rate of virtual addresses issued by software to be accessed in the TLB and successfully queried for physical addresses in the TLB can be monitored; the hit rate of accesses to data in the L1 cache issued by the system bus can be monitored; and the hit rate of accesses to data in the L2 cache issued by the system bus can be monitored. This hit rate data provides a detailed performance analysis basis for subsequent cache architecture optimization.

[0097] This embodiment can be implemented by a cache architecture controller. Figure 6 FIG. 1 shows a schematic diagram of the structure of the cache architecture controller according to an embodiment of the present disclosure. Figure 6 As shown, the cache architecture controller includes Hit_Detect_0, Hit_Detect_1, Hit_Detect_2 and Data_Prefetch, wherein Hit_Detect_0, i.e., the first access hit monitoring module, is used to monitor the hit rate of the virtual address to be accessed by the software in the TLB and the corresponding physical address to be queried in the TLB. When Hit_Detect_0 monitors that the hit rate of the virtual address accessed by the software in the TLB is lower than a certain threshold, such as 80%, an alarm signal is sent to Data_Prefetch, i.e., the data prefetch module; Hit_Detect_1, i.e., the second access hit monitoring module, has the function of monitoring the data hit rate hit_L1 in the L1 Cache issued by the system bus, i.e., the probability that the data to be accessed by the software can be queried in the local L1 Cache. When it is monitored that hit_L1 is less than a certain threshold, such as 75%. An alarm signal is sent to Data_Prefetch. Hit_Detect_2, the third access hit monitoring module, monitors the hit rate (hit_L2) of L2 cache accesses sent by the system bus. This is the probability that the data to be accessed by the software can be found in the local L2 cache. If hit_L2 is less than a certain threshold, such as 70%, an alarm signal is sent to Data_Prefetch.

[0098] Step S306: executing corresponding optimization measures on the cache portion whose data hit rate meets the fourth threshold.

[0099] In this embodiment, this step can be performed by Figure 6In the Data_Prefetch implementation, the fourth threshold is a preset value used to determine whether the data hit rate of a cache section is abnormal. When the data hit rate of a cache section falls below the fourth threshold, it indicates that this cache section may have a performance bottleneck. Optimization measures are implemented for different cache sections. For example, if the TLB data hit rate falls below the fourth threshold, the page table storing the mapping between virtual addresses and physical addresses in the double data rate (DDR) memory can be updated to the TLB based on software rules for sending virtual addresses (such as sequential access or fixed-step jump access). If the L1 cache data hit rate falls below the fourth threshold, the corresponding access address in the L2 cache or DDR memory can be updated to the L1 cache based on system bus address transmission rules (such as sequential access or fixed-step jump access). If the L2 cache data hit rate falls below the fourth threshold, the corresponding access address in the DDR memory can be updated to the L2 cache based on system bus address transmission rules. By optimizing cache performance bottlenecks, the performance of the cache architecture can be effectively improved, thereby enhancing overall processor performance.

[0100] In another embodiment, step S306 of “performing corresponding optimization measures on the cache portion whose data hit rate meets the fourth threshold” includes:

[0101] In response to the data hit rate of the TLB meeting a fourth threshold, based on a rule of sending virtual addresses by software, a page table storing a mapping relationship between virtual addresses and physical addresses in the double data rate DDR memory is updated to the TLB.

[0102] In this embodiment, when the TLB data hit rate falls below a fourth threshold, it indicates a possible TLB performance bottleneck. In this case, based on the rules for software sending virtual addresses, the page table in the DDR memory that stores the mapping between virtual addresses and physical addresses is updated to the TLB. For example, if the software frequently accesses certain virtual addresses and these addresses have a low hit rate in the TLB, the page table entries corresponding to these addresses can be loaded from the DDR memory into the TLB, improving the TLB hit rate and reducing the number of memory accesses, thereby enhancing the performance of the cache architecture.

[0103] In response to the data hit rate of the first-level cache meeting the fourth threshold, based on the rule of sending addresses on the system bus, the corresponding access address in the second-level cache or the DDR memory is updated to the first-level cache.

[0104] In this embodiment, when the data hit rate of the L1 cache falls below a fourth threshold, it indicates that there may be a performance bottleneck in the L1 cache. In this case, the corresponding access addresses in the L2 cache or DDR memory are updated to the L1 cache according to the rules for sending addresses on the system bus. For example, if the system bus frequently accesses certain addresses and the hit rate of these addresses in the L1 cache is low, the data corresponding to these addresses can be prefetched from the L2 cache into the L1 cache. If these addresses are not in the L2 cache, they can be prefetched from the DDR memory into the L1 cache and simultaneously stored in the L2 cache to maintain data consistency. This improves the hit rate of the L1 cache, reduces the number of accesses to the L2 cache or DDR memory, and thereby enhances the performance of the cache architecture.

[0105] In response to the data hit rate of the secondary cache meeting a fourth threshold, based on a rule of sending addresses on the system bus, the corresponding access address in the DDR memory is updated to the secondary cache.

[0106] In this embodiment, when the L2 cache data hit rate falls below a fourth threshold, it indicates a potential L2 cache performance bottleneck. In this case, the corresponding access addresses in the DDR memory are updated to the L2 cache based on the system bus address transmission rules. For example, if the system bus frequently accesses certain addresses and the hit rate of these addresses in the L2 cache is low, the data corresponding to these addresses can be prefetched from the DDR memory to the L2 cache. This improves the L2 cache hit rate, reduces the number of DDR memory accesses, and thus enhances cache architecture performance.

[0107] Figure 5 FIG. 1 shows a schematic diagram of a processor performance hardware optimization system according to an embodiment of the present disclosure. Figure 5 As shown, a processor performance hardware optimization system includes:

[0108] A bottleneck analysis controller (Bottleneck_Analysis_Ctrl) is configured to, in response to the performance monitoring function being enabled for the processor, control all target hardware event controllers on the processor to monitor real-time performance data of corresponding hardware events; determine a first degree of deviation between the real-time performance data and corresponding standard performance data; bind hardware events corresponding to the first degree of deviation that meets a first threshold to a hardware event counter, monitor a target number of times for the corresponding hardware events based on the hardware event counter; and determine a performance bottleneck of the processor based on the target number of times;

[0109] Performance optimizer, used to optimize processor performance based on performance bottlenecks.

[0110] In one possible implementation, the bottleneck analysis controller is further used to: run the processor based on a standard test model program to obtain original performance standards corresponding to all hardware events on the processor; determine a second degree of deviation between the original performance standard and the standard performance data; in response to the second degree of deviation meeting a second threshold, generate warning data of abnormal standard performance data and output it to the user end; obtain new standard performance data; the new standard performance data is standard performance data regenerated by the user end based on the warning data, or standard performance data obtained by weighted averaging the original performance standard and the standard performance data.

[0111] In one possible implementation, the bottleneck analysis controller is further configured to: determine a difference between the real-time performance data and the corresponding standard performance data; and determine a ratio of the difference to the standard performance data as the first deviation degree.

[0112] In one embodiment, the performance optimizer includes a microarchitecture controller (Micro_Ctrl), which is used to: in response to a performance bottleneck existing in the core microarchitecture of the processor, monitor the processing time of each processing stage in the instruction processing flow of the core microarchitecture; and execute corresponding optimization measures for the processing stage whose processing time meets a third threshold.

[0113] In one embodiment, the microarchitecture controller is also used to: monitor the interval between two instruction fetches in the instruction fetch stage; monitor the interval between two decodings in the decoding stage; monitor the time it takes for each execution unit to complete instruction data operations in the execution stage; monitor the time it takes for each instruction to access the memory in the memory access stage; and monitor the time it takes for each instruction to be written back to the target storage location of the processor in the write back stage.

[0114] In one embodiment, the microarchitecture controller is further used to: in response to the processing time of the instruction fetch stage and the decoding stage meeting a third threshold, enable the instruction prefetch function, increase the instruction issuance width and / or optimize the mapping relationship of the instruction conversion backup buffer ITLB; the ITLB stores the mapping relationship between the virtual address and the physical address corresponding to the instruction; in response to the processing time of the execution stage and the memory access stage meeting the third threshold, increase the instruction execution width and / or optimize the mapping relationship of the data conversion backup buffer DTLB; the DTLB stores the mapping relationship between the virtual address and the physical address corresponding to the data; in response to the processing time of the write back stage meeting the third threshold, increase the cache depth of the reorder buffer ROB and / or perform fast write back status processing; the fast write back status processing includes early write back, register renaming enhancement and / or increase the write back bandwidth.

[0115] In one embodiment, the performance optimizer includes a cache architecture controller (Cache_Ctrl), which is used to: in response to a performance bottleneck existing in the cache architecture of the processor, monitor data hit rates corresponding to different cache parts in the cache architecture; the cache parts include a translation lookaside buffer TLB, a first-level cache, and a second-level cache; and perform corresponding optimization measures on the cache parts whose data hit rates meet a fourth threshold.

[0116] In one embodiment, the cache architecture controller is further used to: in response to the data hit rate of the TLB meeting a fourth threshold, based on the rule of software sending virtual addresses, update the page table storing the mapping relationship between virtual addresses and physical addresses in the double data rate DDR memory to the TLB; in response to the data hit rate of the first-level cache meeting the fourth threshold, based on the rule of system bus sending addresses, update the corresponding access address in the second-level cache or DDR memory to the first-level cache; in response to the data hit rate of the second-level cache meeting the fourth threshold, based on the rule of system bus sending addresses, update the corresponding access address in the DDR memory to the second-level cache.

[0117] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions of this disclosure can be achieved, and this document is not limited here.

[0118] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout the present disclosure, "plurality" means two or more, unless otherwise specifically defined.

[0119] The above description is merely a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. A method for optimizing processor performance hardware, characterized in that: The method comprises: In response to the performance monitoring function for the processor being enabled, controlling all target hardware event controllers on the processor to monitor real-time performance data of corresponding hardware events; determining a first degree of deviation between the real-time performance data and corresponding standard performance data; Binding a hardware event corresponding to the first deviation degree that meets a first threshold to a hardware event counter, and monitoring a target number of times of the corresponding hardware event based on the hardware event counter; determining a performance bottleneck of the processor based on the target number; Optimizing the performance of the processor based on the performance bottleneck; The performing performance optimization on the processor based on the performance bottleneck includes: In response to the performance bottleneck existing in the core micro-architecture of the processor, monitoring the processing time of each processing stage in the instruction processing flow of the core micro-architecture; the processing stages include an instruction fetch stage, a decode stage, an execute stage, a memory access stage, and a write-back stage; In response to the processing time of the instruction fetch stage and the decoding stage meeting a third threshold, enabling an instruction prefetch function, increasing the instruction issue width, and / or optimizing a mapping relationship of an instruction translation lookaside buffer (ITLB); the ITLB stores a mapping relationship between a virtual address and a physical address corresponding to an instruction; In response to the processing time of the execution phase and the memory access phase meeting a third threshold, increasing the instruction execution width and / or optimizing the mapping relationship of the data translation lookaside buffer (DTLB); the DTLB stores the mapping relationship between the virtual address and the physical address corresponding to the data; In response to the processing time of the write-back phase meeting a third threshold, the cache depth of the reorder buffer (ROB) is increased and / or write-back status fast processing is performed; the write-back status fast processing includes early write-back, register renaming enhancement and / or increased write-back bandwidth.

2. The method according to claim 1, characterized in that Before determining a first degree of deviation between the real-time performance data and the corresponding standard performance data, the method further includes: Running the processor based on a standard test model program to obtain original performance standards corresponding to all hardware events on the processor; determining a second degree of deviation of the original performance standard from the standard performance data; In response to the second deviation degree meeting a second threshold, generating warning data indicating that the standard performance data is abnormal and outputting the warning data to a user terminal; Acquire new standard performance data; the new standard performance data is standard performance data regenerated by the user terminal based on the warning data, or standard performance data obtained by weighted averaging the original performance standard and the standard performance data.

3. The method according to claim 1, characterized in that Determining a first degree of deviation between the real-time performance data and the corresponding standard performance data includes: Determining a difference between the real-time performance data and corresponding standard performance data; A ratio of the difference to the standard performance data is determined as the first deviation degree.

4. The method according to claim 1, wherein The monitoring of the processing time of each processing stage in the instruction processing flow of the core micro-architecture includes: Monitor the interval between two finger fetches during the finger fetch phase; Monitor the interval between two decodings during the decoding phase; Monitor the time it takes for each execution unit to complete instruction data operations during the execution phase; Monitor the duration of memory access operations of each instruction in the memory access phase; The length of time during the write-back phase for each instruction to be written back to a target memory location of the processor is monitored.

5. The method according to claim 1, wherein The performing performance optimization on the processor based on the performance bottleneck includes: In response to the performance bottleneck existing in the cache architecture of the processor, monitoring data hit rates corresponding to different cache parts in the cache architecture; the cache parts include a translation lookaside buffer (TLB), a level 1 cache, and a level 2 cache; A corresponding optimization measure is performed on the cache portion whose data hit rate meets the fourth threshold.

6. The method according to claim 5, characterized in that The performing corresponding optimization measures on the cache portion whose data hit rate meets the fourth threshold includes: In response to a data hit rate of the TLB meeting a fourth threshold, based on a rule for sending virtual addresses by software, updating a page table storing a mapping relationship between virtual addresses and physical addresses in a double data rate (DDR) memory into the TLB; In response to a data hit rate of the first-level cache meeting a fourth threshold, based on a rule of sending addresses on a system bus, updating a corresponding access address in the second-level cache or the DDR memory into the first-level cache; In response to the data hit rate of the secondary cache meeting a fourth threshold, based on a rule of sending addresses on a system bus, the corresponding access address in the DDR memory is updated to the secondary cache.

7. A processor performance hardware optimization system, characterized in that: The system comprises: A bottleneck analysis controller is configured to, in response to the performance monitoring function for the processor being enabled, control all target hardware event controllers on the processor to monitor real-time performance data of corresponding hardware events; determine a first degree of deviation between the real-time performance data and corresponding standard performance data; bind hardware events corresponding to the first degree of deviation that meet a first threshold to a hardware event counter, monitor a target number of corresponding hardware events based on the hardware event counter; and determine a performance bottleneck of the processor based on the target number of times; A performance optimizer, configured to optimize the performance of the processor based on the performance bottleneck; The performance optimizer includes a micro-architecture controller, and the micro-architecture controller is used to: In response to the performance bottleneck existing in the core micro-architecture of the processor, monitoring the processing time of each processing stage in the instruction processing flow of the core micro-architecture; the processing stages include an instruction fetch stage, a decode stage, an execute stage, a memory access stage, and a write-back stage; In response to the processing time of the instruction fetch stage and the decoding stage meeting a third threshold, enabling an instruction prefetch function, increasing the instruction issue width, and / or optimizing a mapping relationship of an instruction translation lookaside buffer (ITLB); the ITLB stores a mapping relationship between a virtual address and a physical address corresponding to an instruction; In response to the processing time of the execution phase and the memory access phase meeting a third threshold, increasing the instruction execution width and / or optimizing the mapping relationship of the data translation lookaside buffer (DTLB); the DTLB stores the mapping relationship between the virtual address and the physical address corresponding to the data; In response to the processing time of the write-back phase meeting a third threshold, the cache depth of the reorder buffer (ROB) is increased and / or write-back status fast processing is performed; the write-back status fast processing includes early write-back, register renaming enhancement and / or increased write-back bandwidth.

8. The system according to claim 7, characterized in that The bottleneck analysis controller is further configured to: Running the processor based on a standard test model program to obtain original performance standards corresponding to all hardware events on the processor; determining a second degree of deviation of the original performance standard from the standard performance data; In response to the second deviation degree meeting a second threshold, generating warning data indicating that the standard performance data is abnormal and outputting the warning data to a user terminal; Acquire new standard performance data; the new standard performance data is standard performance data regenerated by the user terminal based on the warning data, or standard performance data obtained by weighted averaging the original performance standard and the standard performance data.

9. The system according to claim 7, wherein: The bottleneck analysis controller is further configured to: Determining a difference between the real-time performance data and corresponding standard performance data; A ratio of the difference to the standard performance data is determined as the first deviation degree.

10. The system according to claim 7, wherein: The micro-architecture controller is further configured to: Monitor the interval between two finger fetches during the finger fetch phase; Monitor the interval between two decodings during the decoding phase; Monitor the time it takes for each execution unit to complete instruction data operations during the execution phase; Monitor the duration of memory access operations of each instruction in the memory access phase; The length of time during the write-back phase for each instruction to be written back to a target memory location of the processor is monitored.

11. An electronic device, characterized in that: include: The processor performance hardware optimization system according to any one of claims 7 to 10.

12. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 6.

Images