Real-time simulation performance evaluation method based on ARMv8 architecture multi-core processor

Abstract

The invention discloses a real-time simulation performance evaluation method based on an ARMv8 architecture multi-core processor, and particularly relates to the technical field of multi-core performance evaluation. Comprising the following steps that a concurrent monitoring module is arranged, and an access instruction sequence and memory barrier instruction information of a processing core are collected; analyzing an address cross relation and time sequence dependence between the access instructions, and generating an instruction rearrangement risk access group; concurrency consistency analysis is carried out on the risk access group, race conditions are identified, and a synchronization mode and memory barrier instruction distribution are recorded; high-intensity concurrent operation is injected into the simulation environment, read-write operation of the shared variables is continuously tracked, and an instruction execution sequence is analyzed; the matching degree under different simulation load conditions is counted, a real-time simulation performance evaluation index for the weak memory model is generated, and the potential consistency problem caused by instruction rearrangement can be accurately recognized.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-core performance evaluation, and more specifically, to a real-time simulation performance evaluation method based on an ARMv8 architecture multi-core processor. Background Art

[0002] The ARMv8 architecture uses a weak memory model to achieve high performance and low power optimization. This model allows out-of-order execution and memory read and write reordering. This memory model significantly improves parallel computing capabilities in multi-core processors, but it also increases the complexity of access to shared variables. Especially in real-time simulation applications, high-frequency access to shared variables by multiple cores may lead to unpredictable execution sequences, which may have a potential impact on the stability and consistency of simulation results. Although existing technologies have tried to ensure memory consistency by using "locks" or "memory barriers", the reliability and applicability of existing methods are still limited in the face of complex instruction reordering problems in multi-core high-concurrency environments.

[0003] In the prior art, how to accurately identify and analyze potential consistency issues caused by instruction reordering in multi-core concurrent operations under a weak memory model will have a significant impact on the accuracy and reliability of real-time simulation performance evaluation. Summary of the invention

[0004] In order to overcome the above-mentioned defects of the prior art, an embodiment of the present invention provides a real-time simulation performance evaluation method based on an ARMv8 architecture multi-core processor to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions: The real-time simulation performance evaluation method based on the ARMv8 architecture multi-core processor includes the following steps: S1: Setting a concurrent monitoring module in the multi-core processor to collect the access instruction sequence of each processing core to the shared variable and the corresponding memory barrier instruction information; S2: Parse the collected access instruction sequence and memory barrier instruction information, and generate an instruction reordering risk access group based on the address cross-relationship and timing dependency between the access instructions; S3: Perform concurrent consistency analysis on the instruction reordering risk access group, identify possible race conditions in the use of low-level hardware primitives, and record the synchronization method and memory barrier instruction distribution corresponding to the access instruction sequence; S4: Inject high-intensity concurrent operation scenarios into the actual simulation environment, use the concurrency monitoring module to continuously track the read and write operations of shared variables, and compare the execution order of each instruction reordering risk access group with the expected order obtained by parsing; S5: Count the execution sequence matching degree of each instruction reordering risk access group under different simulation load conditions, and comprehensively generate real-time simulation performance evaluation indicators under weak memory model conditions.

[0006] In a preferred embodiment, a concurrency monitoring module is set in the multi-core processor to collect the access instruction sequence of each processing core to the shared variable and the corresponding memory barrier instruction information, specifically including: Configure a concurrent monitoring module to record the access operations of each core in the multi-core processor to the shared variables and collect access instruction information, which includes the operation type, target address and the time when it occurs; Capture memory barrier instructions in real time in the concurrency monitoring module, extract the type of memory barrier instructions, the specific location of insertion, and its association with access instructions; The access instruction information and memory barrier instruction information collected by the concurrent monitoring module are summarized, and the collected data is time-corrected based on a unified time base to generate a global record containing all processing core access instruction sequences and memory barrier instruction information.

[0007] In a preferred embodiment, the collected access instruction sequence and memory barrier instruction information are parsed, and an instruction reordering risk access group is generated based on the address intersection relationship and timing dependency between the access instructions, specifically including: Parse the collected access instruction sequence, extract the target address, operation type and occurrence time of each access instruction, and sort the access instructions of the same core according to the occurrence time to form an intra-core access sequence; Based on the analyzed in-core access sequence, identify the cross-relationship of the target address, determine whether multiple cores access the memory address of the same shared variable at the same time, and record the cross-access instruction pairs; Parse the time information of the cross-access instruction pairs, determine whether there is a timing dependency based on the occurrence time of the access instruction and its correlation with the memory barrier instruction, and record the instruction pairs that have a time dependency; The cross-access instruction pairs and the instruction pairs with time dependency are combined, and instruction reordering risk access groups are generated according to the core number, access target address and time sequence.

[0008] In a preferred embodiment, concurrent consistency analysis is performed on the access instruction reordering risk access group to identify possible race conditions in the use of low-level hardware primitives, and the synchronization mode and memory barrier instruction distribution corresponding to the access instruction sequence are recorded, specifically including: Classifying the access instructions in the access instruction reordering risk access group, and dividing the access instructions in the access instruction reordering risk access group into a read access instruction group, a write access instruction group, and a mixed operation access instruction group according to the operation type, target address, and occurrence time of the access instructions; For the access instructions in each group, the usage of low-level hardware primitives is parsed, including marking the dependency, scope, and execution order of the hardware access instructions; On the basis of grouping, according to the target address and time relationship between access instructions, analyze whether there are potential race conditions for access instructions on the same target address, including the situation where multiple cores access the same target address at the same time and the memory barrier instruction fails to cover all access instructions; The synchronization mode involved in the access instruction sequence of each group is recorded, including the type of synchronization mode, the synchronization scope and the specific access instructions it acts on.

[0009] In a preferred embodiment, a high-intensity concurrent operation scenario is injected into the actual simulation environment, and the concurrent monitoring module is used to continuously track the read and write operations of shared variables, and the execution order of each instruction reordering risk access group is compared with the expected order obtained by parsing, specifically including: Build an actual simulation environment and set up multi-core high-concurrency operation scenarios, including defining the target address range of shared variables and assigning access operation tasks to each core to ensure that multiple cores can perform read and write operations simultaneously; Inject high-intensity concurrent load into the simulation scenario and set each core to access the shared variables at randomized time intervals; The concurrent monitoring module is used to continuously track all read and write operations of shared variables, record the operation type, target address and execution time of each access, and generate a complete access instruction sequence; Compare the access instruction sequence recorded by the trace with the expected sequence obtained by analysis to analyze whether there is instruction reordering in the actual execution sequence; The instruction reordering detected in the comparison results is stored in the form of structured data, recording the cause, impact scope and access instruction number involved of each instruction reordering.

[0010] In a preferred embodiment, the execution sequence matching degree of each instruction reordering risk access group under different simulation load conditions is counted to comprehensively generate a real-time simulation performance evaluation index under weak memory model conditions, specifically including: Set multiple load conditions in the simulation environment, including high-intensity load, medium-intensity load, and low-intensity load. Under each load condition, adjust the access frequency and operation interval of multiple cores to shared variables to form different concurrent scenarios. For each instruction reordering risk access group under each load condition, the actual execution order of the access instruction sequence is compared with the expected order, and the execution order matching degree of each group of access instructions is recorded. The execution order matching degree is determined by comparing whether the actual execution order is consistent with the expected order obtained by analysis; Based on the matching data of various load conditions, real-time simulation performance evaluation indicators for the weak memory model are generated. The real-time simulation performance evaluation indicators include the execution consistency of each instruction reordering risk access group under different load conditions, the frequency of instruction reordering, and the instruction execution time deviation.

[0011] In a preferred embodiment, under high-intensity load conditions, each core frequently accesses the shared variable at a minimum time interval to simulate an extremely high-concurrency environment; under medium-intensity load conditions, each core accesses the shared variable at a relatively balanced time interval; under low-intensity load conditions, each core accesses the shared variable at a larger time interval to simulate a low-concurrency environment; Under each load condition, the access time interval between cores to shared variables is adjusted by introducing a randomization mechanism; the access order and time interval between cores are generated by a random function.

[0012] The technical effects and advantages of the real-time simulation performance evaluation method based on the ARMv8 architecture multi-core processor of the present invention are as follows: 1. By setting up a concurrent monitoring module, the access instruction sequence and memory barrier instruction information in the multi-core processor are accurately collected, the address cross-relationship and timing dependency between access instructions are analyzed, and the instruction reordering risk access group is constructed. This mechanism enables the dependency relationship and risk area of ​​key instructions to be clearly located, laying a solid data foundation for subsequent consistency analysis and performance evaluation. Compared with the prior art, the technical means of the present invention have higher accuracy and applicability, especially in high-intensity concurrent operation scenarios, it can effectively identify potential race conditions.

[0013] 2. Inject high-intensity concurrent operations under various load conditions in the actual simulation environment, dynamically track the instruction execution order and compare it with the expected order obtained by analysis, so as to accurately calculate the matching degree and reordering frequency of instruction execution. Combined with the evaluation results of multiple load scenarios, a real-time simulation performance evaluation index for a weak memory model is generated, which can fully reflect the execution consistency of each instruction reordering risk access group under different conditions. The method of the present invention provides a highly targeted and data-transparent evaluation tool, which not only improves the reliability of simulation performance evaluation, but also provides a guiding basis for the memory consistency optimization of multi-core processors, significantly expanding the application scope of real-time simulation under a weak memory model. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1It is a schematic diagram of the real-time simulation performance evaluation method based on the ARMv8 architecture multi-core processor of the present invention. DETAILED DESCRIPTION

[0015] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0016] Example: Figure 1 The present invention provides a real-time simulation performance evaluation method based on an ARMv8 architecture multi-core processor, which includes the following steps: S1: A concurrency monitoring module is set in the multi-core processor to collect the access instruction sequence of each processing core to the shared variable and the corresponding memory barrier instruction information.

[0017] S2: parse the collected access instruction sequence and memory barrier instruction information, and generate an instruction reordering risk access group based on the address cross-relationship and timing dependency between the access instructions.

[0018] S3: Perform concurrent consistency analysis on the instruction reordering risk access group, identify possible race conditions in the use of low-level hardware primitives, and record the synchronization method and memory barrier instruction distribution corresponding to the access instruction sequence.

[0019] S4: Inject high-intensity concurrent operation scenarios into the actual simulation environment, use the concurrency monitoring module to continuously track the read and write operations of shared variables, and compare the execution order of each instruction reordering risk access group with the expected order obtained by analysis.

[0020] S5: Count the execution sequence matching degree of each instruction reordering risk access group under different simulation load conditions, and comprehensively generate real-time simulation performance evaluation indicators under weak memory model conditions.

[0021] A concurrency monitoring module is set up in the multi-core processor to collect the access instruction sequence of each processing core to the shared variable and the corresponding memory barrier instruction information, including: Configure the concurrent monitoring module to record the access operations of each core in the multi-core processor to the shared variables and collect access instruction information, which includes the operation type, target address and the time when it occurs: First, a concurrency monitoring module is deployed in the multi-core processor. This module directly accesses the hardware performance counters or instruction tracking interface (such as ARM's ETM or similar mechanisms) of the multi-core processor to record the shared variable access instructions involved in the execution of each core. The specific record content includes: the operation type of the access instruction, the target address, and the time when the access instruction occurs.

[0022] The operation type indicates the function of the access instruction, such as read (Load), write (Store), or update (Update). This information is obtained by decoding the processor instruction stream and is associated with a specific memory address range of the shared variable.

[0023] The target address records the specific memory location accessed, which is used for subsequent analysis of the cross-relationship between instructions. The target address is extracted from the processor's address bus or cache access record by hardware probe or software instrumentation.

[0024] The time of occurrence is obtained through the concurrent monitoring module and the global clock synchronization mechanism of the multi-core processor to ensure the time accuracy of the recorded data. The time information is stored with nanosecond accuracy to facilitate the subsequent analysis of the timing dependencies between instructions.

[0025] In the concurrency monitoring module, memory barrier instructions are captured in real time to extract the type of memory barrier instructions, the specific location where they are inserted, and their relationship with access instructions: The concurrency monitoring module needs to capture the memory barrier instructions executed by each core in the multi-core processor in real time. These barrier instructions are used to coordinate the memory access order between cores, and are therefore an important basis for analyzing the risk of instruction reordering. The process of capturing memory barrier instructions includes the following aspects: Identify the type of barrier instruction: By analyzing the binary encoding of the instruction, the specific type of barrier instruction is determined, such as global barrier (DMB), data synchronization barrier (DSB) or instruction synchronization barrier (ISB). These types indicate the scope and priority of the barrier.

[0026] Extraction of insertion position: Record the position of the barrier instruction in the access instruction sequence and clarify its order in the execution sequence. The insertion position is obtained by real-time parsing of instruction pipeline information or instruction tracking logs.

[0027] Analysis of associated access instructions: The association between the captured barrier instruction and the previous and next access instructions is the key to the subsequent generation of the instruction dependency model. Specifically, it is necessary to determine which shared variable access instructions the barrier instruction affects, and whether there is an overwrite or incomplete protection.

[0028] The information captured by the barrier instruction is cross-matched with the access instruction information, providing complete data input for subsequent parsing and analysis.

[0029] The access instruction information and memory barrier instruction information collected by the concurrent monitoring module are summarized, and the collected data is time-corrected based on a unified time base to generate a global record containing all processing core access instruction sequences and memory barrier instruction information: The access instruction information and memory barrier instruction information are stored in association with each other according to the core number, timestamp, target address and other fields to form a unified data structure. The data is stored in the form of event logs, and each record contains the instruction type, target address, timestamp and barrier association information.

[0030] Since each core in a multi-core processor may have an independent local clock, the collected data must be time-corrected to generate a globally consistent time base. The time correction process is based on the global clock source provided by the processor or implemented through an external synchronization signal.

[0031] By sorting the time-corrected data, a complete global access instruction sequence and global memory barrier instruction information are formed. The access instruction sequence is arranged in chronological order, and the memory barrier instruction is inserted into the access instruction sequence as a marker to clarify its scope and position.

[0032] The generated global access records are stored in the storage unit of the concurrent monitoring module in the form of structured data. The storage format includes but is not limited to JSON, CSV or binary log files, so that they can be read efficiently during subsequent parsing and analysis. The security and consistency of the data must be ensured during the storage process to avoid affecting the accuracy of subsequent steps due to storage delays or data loss.

[0033] The collected access instruction sequence and memory barrier instruction information are parsed, and the instruction reordering risk access group is generated based on the address cross-relationship and timing dependency between the access instructions, including: Parse the collected access instruction sequence, extract the target address, operation type and occurrence time of each access instruction, and sort the access instructions of the same core according to the occurrence time to form the access sequence within the core: Extract target address: For each access instruction, parse its target address information from the access record. The target address refers to the memory location operated by the access instruction, which is used to determine whether the access instruction involves shared variables. When parsing, ensure that the target addresses of all instructions are consistent with the collected shared variable address range, otherwise filter to remove irrelevant instructions.

[0034] Extract operation type: The operation type defines the function of the access instruction, including read operation (Load), write operation (Store), and update operation (Update). Extract the operation type information by decoding the instruction opcode and mark it in the parsing result for subsequent analysis.

[0035] Extraction time: Each access instruction is accompanied by a timestamp, which indicates the specific time when the instruction is executed by the processing core. The timestamp is generated synchronously with the global time base by the concurrent monitoring module to ensure the consistency of time information between different cores. The timestamp is parsed and associated with the instruction to form the complete time information of the instruction.

[0036] The access instructions of the same core are sorted according to the timestamp to generate the access sequence within the core. The sorted access sequence will be used as the basic data for subsequent analysis to identify the address cross-relationship and timing dependency between instructions.

[0037] Based on the parsed in-core access sequence, identify the cross-relationship of the target address, determine whether multiple cores access the memory address of the same shared variable at the same time, and record the cross-access instruction pairs: Determine the address cross relationship: Cross-compare the access instructions of each core with the access instructions of other cores to identify whether multiple cores access the same target address at the same time. The identification of the cross relationship is completed by matching the target address, that is, if the target addresses of two instructions are the same, it is determined that there is an address cross relationship.

[0038] Once the address crossover relationship is identified, the related access instruction pairs are recorded. Each crossover access instruction pair contains information of two instructions, including core number, target address, operation type and occurrence time.

[0039] If there are cross-relationships between multiple instruction pairs between two cores, they need to be further filtered based on timestamps to retain only instruction pairs with potential impact, such as cross-relationships that occurred recently or covered a larger time window.

[0040] Parse the time information of the cross-access instruction pairs, determine whether there is a timing dependency based on the occurrence time of the access instruction and its correlation with the memory barrier instruction, and record the instruction pairs that have a time dependency: Compare the timestamps of the two instructions in the cross-access instruction pair and calculate their time difference. If the time difference is lower than a certain threshold, there may be a potential timing conflict. For example, if the time difference is less than the minimum time unit for instruction processing, it may cause access overlay; if the time difference exceeds a certain range, it can be regarded as an irrelevant instruction.

[0041] Compare the timestamp of the cross-access instruction pair with the insertion time of the memory barrier instruction. If the cross-access instruction pair is within the scope of the same barrier instruction, it is considered that the barrier instruction may affect its dependency; otherwise, it is recorded as an unprotected cross-access instruction pair.

[0042] The identified time-related cross-access instruction pairs are marked and their time dependency is recorded.

[0043] Combine the cross-access instruction pairs and the instruction pairs with time dependency, and generate the instruction reordering risk access group according to the core number, access target address and time sequence: For the cross-access instruction pairs of the same target address, check whether they have a time dependency relationship. If both the cross-relationship and the time dependency conditions are met, the instruction pair is included in the reorder risk access group.

[0044] The instructions in the risky access group are sorted by core number, target address and time order. After sorting, they are grouped by target address, and each group represents an independent risky access set.

[0045] The generated instruction reordering risk access group is stored in the form of structured data. The specific storage format includes but is not limited to JSON files or relational database tables. The stored data must include information such as instruction pair number, core number, target address, time difference, barrier association, etc. to ensure that the data is complete and convenient for subsequent analysis.

[0046] Perform concurrent consistency analysis on the access instruction reordering risk access group, identify possible race conditions in the use of low-level hardware primitives, and record the synchronization method and memory barrier instruction distribution corresponding to the access instruction sequence, including: The access instructions in the access instruction reordering risk access group are classified into a read access instruction group, a write access instruction group, and a mixed operation access instruction group according to the operation type, target address, and occurrence time of the access instructions: The operation type of each access instruction can be divided into read operation, write operation and mixed operation. For example, if an access instruction reads the value of a shared variable, it is classified as a read operation; if it writes a new value to a shared variable, it is classified as a write operation; if it contains both read and write, it is a mixed operation.

[0047] The target address is extracted from the access instructions to identify the memory location involved in each instruction. The target address is used in the classification process to determine whether the access instructions operate on the same shared variable.

[0048] After sorting the access instructions in chronological order, they are grouped according to the operation type and target address. The grouping results form three main sets: read access instruction group, write access instruction group and mixed operation access instruction group.

[0049] For each access instruction in a group, the usage of low-level hardware primitives is parsed, including marking the dependency, scope, and execution order of hardware access instructions: Dependencies: Determine whether access instructions depend on specific hardware primitives (such as load and store instructions), and record the calling order and dependency chain between hardware primitives. For example, some access instructions may depend on load access instructions to complete data acquisition, or depend on storage access instructions to complete write operations.

[0050] Scope: Determines the scope of the hardware primitives that each access instruction depends on to affect the shared variable. Scope includes the target address range, time range, and the degree to which the primitive covers other instructions. For example, some hardware primitives may only be effective for specific shared variable addresses and will not affect data access at other addresses.

[0051] Execution order: Analyze the specific position of each access instruction and the hardware primitives it depends on in the execution sequence, and record their execution order to ensure that the execution logic of the instruction stream can be accurately reproduced in subsequent consistency analysis.

[0052] On a grouping basis, according to the target address and time relationship between access instructions, analyze whether there are potential race conditions for access instructions on the same target address, including multiple cores accessing the same target address at the same time and memory barrier instructions failing to cover all access instructions: Target address conflict: If multiple cores execute access instructions to the same shared variable at the same target address at the same time (such as read and write or write and write at the same time), a race condition may occur. The identification of the race condition is determined by the overlap of the access time of the target address.

[0053] Memory barrier instruction coverage analysis: Determine whether the access instruction is covered by the memory barrier instruction. For example, some memory barrier instructions may only act on part of the target address, causing some access instructions to fail to be synchronized correctly, thus generating potential race conditions.

[0054] Record the synchronization mode involved in the access instruction sequence of each group, including the type of synchronization mode, the synchronization scope and the specific access instructions it acts on: Synchronization method type: records the synchronization method used in each access instruction group (such as lock mechanism, barrier instruction, etc.).

[0055] Synchronization scope: describes the scope of the synchronization method, including the target address and time period covered.

[0056] Associated access instructions: Indicates the association between the synchronization method and the specific access instruction. For example, some synchronization methods only protect some access instructions and fail to fully cover the entire group.

[0057] Record the distribution of memory barrier instructions in the access instruction sequence, including the location of each memory barrier instruction and the range of access instructions it affects: Position labeling: Mark the specific position of each memory barrier instruction in the access instruction sequence.

[0058] Impact scope: describes the access instruction range affected by each memory barrier instruction, as well as the access instruction range not covered.

[0059] For example, "Barrier 1" is located after the third access instruction. "Affected range" describes the access instruction numbers covered by the barrier instruction, for example, "Barrier 1" covers the first to third access instructions. "Uncovered range" records the access instructions that are not protected by the barrier instruction, for example, "Barrier 1" does not cover the fourth to fifth access instructions. Through these records, the distribution of memory barrier instructions is ensured to be clear and traceable in subsequent analysis.

[0060] Inject high-intensity concurrent operation scenarios into the actual simulation environment, use the concurrency monitoring module to continuously track the read and write operations of shared variables, and compare the execution order of each instruction reorder risk access group with the expected order obtained by analysis, including: Build an actual simulation environment and set up a multi-core high-concurrency operation scenario, including defining the target address range of shared variables and assigning access operation tasks to each core to ensure that multiple cores can perform read and write operations simultaneously: According to the actual application requirements in the simulation environment, clarify the target address range of shared variables in memory, for example, limit shared variables to continuous memory blocks to facilitate subsequent tracking and comparison of instruction operations. For example, assuming that shared variables are stored in the address range "0x1000–0x1FFF", this range needs to be used as the shared memory area in the simulation environment.

[0061] Assign specific access operation tasks to each core to ensure that there is a certain degree of competition between the cores for the operations on shared variables, for example: Core 1 performs frequent read operations on shared variables; core 2 performs write operations on shared variables; and core 3 performs mixed read and write operations simultaneously.

[0062] The multi-core scheduling function of the processor is called to start multiple cores running in parallel, so that they perform operations on shared variables in the same time period, simulating typical behaviors in high-concurrency scenarios.

[0063] Inject high-intensity concurrent loads into the simulation scenario and set each core to access shared variables at randomized time intervals to increase the competitiveness between access instructions: Each core's access to the shared variable is controlled by randomly generated time intervals. For example, each core randomly performs read or write operations at different time points to disrupt the order of instructions and thus create potential conflicts. For example: core 1 reads the shared variable after a time interval of 100 nanoseconds; core 2 writes the shared variable after a time interval of 50 nanoseconds; core 3 reads and writes the shared variable after a time interval of 150 nanoseconds.

[0064] According to the concurrency requirements of the target application scenario, gradually increase the frequency of core access to shared variables to simulate the change from light load to high load. For example, the access frequency of each core can be gradually increased from 100 times / second to 1000 times / second.

[0065] During the process of injecting high-intensity loads, the load changes of each core are recorded, including time intervals and access frequencies, so as to facilitate the subsequent analysis of the sequential relationship between instructions.

[0066] The concurrent monitoring module is used to continuously track all read and write operations of shared variables, record the operation type, target address and execution time of each access, and generate a complete access instruction sequence: Each time a core accesses a shared variable, the concurrent monitoring module records the operation type, including read and write. For example: time T1, core 1, read variable X; time T2, core 2, write variable X.

[0067] The concurrent monitoring module also records the target address of each access operation to ensure that the location of the shared variable in the memory can be accurately located. For example: time T1, core 1, address "0x1010"; time T2, core 2, address "0x1010".

[0068] Add an accurate timestamp to each access operation to record the time it occurred. For example: time T1 = 10 nanoseconds; time T2 = 15 nanoseconds.

[0069] Combine the recorded operation type, target address, and execution time to form a complete access instruction sequence. For example: Core 1 access instruction sequence: [read 0x1010 T1], [write 0x1020 T2]; core 2 access instruction sequence: [read 0x1010 T3], [write 0x1020 T4].

[0070] Compare the access instruction sequence recorded in the trace with the expected sequence obtained by parsing to analyze whether there is instruction reordering in the actual execution sequence: Import the expected order of access instructions from the parsing module, and the expected order is sorted by strict address and time dependencies. For example: expected order: [read 0x1010 core 1 T1] → [write 0x1010 core 2 T2].

[0071] Import the actual execution order of access instructions from the concurrency monitoring module and compare it with the expected order one by one. For example: the actual order: [write 0x1010 core 2 T2] → [read 0x1010 core 1 T3].

[0072] If the actual order is inconsistent with the expected order, it is recorded as an instruction reordering phenomenon. For example, in the above example, the actual order is reordered because the write operation of core 2 is executed before the read operation of core 1.

[0073] The instruction reordering detected in the comparison results is stored in the form of structured data, recording the cause, impact scope and access instruction number involved of each instruction reordering: Record the cause of each instruction reordering phenomenon, for example, the access order of two cores conflicts due to the failure of memory barrier instructions to take effect correctly.

[0074] Describe the scope of the impact of instruction reordering on shared variables, including the affected target address and the specific number of the instruction. For example: address range: [0x1010]; affected instructions: [read core 1 T1], [write core 2 T2].

[0075] Store the rearranged data in a structured data format, such as JSON or CSV, to ensure that it can be easily retrieved and used in subsequent analysis.

[0076] The execution sequence matching degree of each instruction reordering risk access group under different simulation load conditions is counted, and the real-time simulation performance evaluation indicators under weak memory model conditions are comprehensively generated, including: In the simulation environment, multiple load conditions are set, including high-intensity load, medium-intensity load, and low-intensity load. Under each load condition, the access frequency and operation interval of multiple cores to shared variables are adjusted to form different concurrent scenarios: High-intensity load: Under high-intensity load conditions, each core frequently accesses shared variables with a minimum time interval to simulate an extremely high-concurrency environment. For example, the access frequency of each core is set to 1000 times per second, and the operation interval between each access is less than 10 microseconds.

[0077] Moderate load: Under moderate load conditions, each core accesses the shared variable at a relatively balanced time interval. For example, each core accesses the shared variable 500 times per second, with an operation interval between 10 microseconds and 50 microseconds.

[0078] Low-intensity load: Under low-intensity load conditions, each core accesses the shared variable at a larger time interval to simulate a low-concurrency environment. For example, the access frequency of each core is set to 100 times per second, and the operation interval is greater than 50 microseconds.

[0079] Under each load condition, the time interval between cores accessing shared variables is adjusted by introducing a randomization mechanism. For example, the access order and time interval between cores can be generated by a random function, thus more realistically simulating the non-deterministic operation mode of multiple cores.

[0080] For each instruction reordering risk access group under each load condition, the actual execution order of the access instruction sequence is compared with the expected order, and the execution order matching degree of each group of access instructions is recorded. The execution order matching degree is determined by comparing whether the actual execution order is consistent with the expected order obtained by analysis: From the access instruction sequence collected in the simulation environment, the actual execution order of the instruction reorder risk access group is obtained. For example, the actual order of instruction group 1 is: [Read 0x1000, time 10 microseconds] → [Write 0x1000, time 15 microseconds]; the actual order of instruction group 2 is: [Write 0x2000, time 20 microseconds] → [Read 0x2000, time 25 microseconds].

[0081] According to the expected order generated by the above parsing steps, the access order of each instruction group is defined. For example, the expected order of instruction group 1 is: [Read 0x1000, time 10 microseconds] → [Write 0x1000, time 15 microseconds]; the expected order of instruction group 2 is: [Read 0x2000, time 20 microseconds] → [Write 0x2000, time 25 microseconds].

[0082] The execution order matching degree is calculated by the following formula: ;in, Indicates the execution order matching degree, Indicates the number of instruction pairs in the actual order that match the expected order, Indicates the total number of instruction pairs.

[0083] For each instruction reordering risk access group, the matching degree is calculated based on the difference between the actual execution order and the expected order. For example, if there are 2 instruction pairs in instruction group 1 and the actual order is exactly the same as the expected order, the matching degree is 1; if there are 2 instruction pairs in instruction group 2, but only 1 is consistent with the expected order, the matching degree is 0.5.

[0084] Calculate the average execution order matching degree of each instruction reordering risk access group under each load condition. The matching degree data includes the statistical results of complete matching, incomplete matching and non-matching: For the matching data of each instruction group, please refer to Table 1 Instruction Group Matching Table: Table 1 Instruction group matching table

[0085] The average matching degree is the ratio of the sum of the execution order matching degrees of all instruction groups to the total number of instruction groups.

[0086] Based on the matching degree data of various load conditions, the real-time simulation performance evaluation indicators for the weak memory model are generated. The real-time simulation performance evaluation indicators include the execution consistency of each instruction reordering risk access group under different load conditions, the frequency of instruction reordering, and the instruction execution time deviation: Execution consistency: The average matching degree of each instruction group under different load conditions is calculated. For example, the average matching degree of high-intensity load is 0.75; the average matching degree of medium-intensity load is 0.8; and the average matching degree of low-intensity load is 1.0.

[0087] Statistics are collected for the total number of instruction reorderings and their percentages under all load conditions. For example, instruction reordering occurs 10 times in a high-intensity load, accounting for 50%; instruction reordering occurs 5 times in a medium-intensity load, accounting for 25%.

[0088] Calculate the deviation between the actual execution time and the expected execution time: ;in, Indicates the time deviation, Indicates the actual execution time. Indicates the expected execution time.

[0089] It is worth noting that the present invention is designed for the ARMv8 architecture, and its applicability stems from the default weak memory model of ARMv8, which allows out-of-order execution and memory read and write reordering to optimize high-performance and low-power applications. However, this weak sequential consistency is more likely to cause instruction reordering and consistency problems in a high-concurrency environment, so a special evaluation method is required. In contrast, other ARM architectures such as ARMv7 use more strong consistency strategies, and the impact of out-of-order execution and memory reordering is relatively small, and will not cause the same degree of synchronization problems as ARMv8. The solution of the present invention is deeply customized for the characteristics of the ARMv8 architecture, and can effectively cope with the simulation consistency challenges brought by its unique memory model.

[0090] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters and thresholds in the formula are set by technicians in this field according to actual conditions.

[0091] The above embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination thereof. When implemented by software, the above embodiments may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or may be transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media sets. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium may be a solid-state hard disk.

[0092] Those of ordinary skill in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0093] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0094] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0095] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, and may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0096] In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0097] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0098] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0099] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A real-time simulation performance evaluation method based on an ARMv8 architecture multi-core processor, characterized in that: The steps include: S1: Setting a concurrent monitoring module in the multi-core processor to collect the access instruction sequence of each processing core to the shared variable and the corresponding memory barrier instruction information; S2: Parse the collected access instruction sequence and memory barrier instruction information, and generate an instruction reordering risk access group based on the address cross-relationship and timing dependency between the access instructions; S3: Perform concurrent consistency analysis on the instruction reordering risk access group, identify possible race conditions in the use of low-level hardware primitives, and record the synchronization method and memory barrier instruction distribution corresponding to the access instruction sequence; S4: Inject high-intensity concurrent operation scenarios into the actual simulation environment, use the concurrency monitoring module to continuously track the read and write operations of shared variables, and compare the execution order of each instruction reordering risk access group with the expected order obtained by parsing; S5: Count the execution sequence matching degree of each instruction reordering risk access group under different simulation load conditions, and comprehensively generate real-time simulation performance evaluation indicators under weak memory model conditions.

2. The real-time simulation performance evaluation method based on the ARMv8 architecture multi-core processor according to claim 1 is characterized in that: A concurrency monitoring module is set up in the multi-core processor to collect the access instruction sequence of each processing core to the shared variable and the corresponding memory barrier instruction information, including: Configure a concurrent monitoring module to record the access operations of each core in the multi-core processor to the shared variables and collect access instruction information, which includes the operation type, target address and the time when it occurs; Capture memory barrier instructions in real time in the concurrency monitoring module, extract the type of memory barrier instructions, the specific location of insertion, and its association with access instructions; The access instruction information and memory barrier instruction information collected by the concurrent monitoring module are summarized, and the collected data is time-corrected based on a unified time base to generate a global record containing all processing core access instruction sequences and memory barrier instruction information.

3. The real-time simulation performance evaluation method based on the ARMv8 architecture multi-core processor according to claim 1 is characterized in that: The collected access instruction sequence and memory barrier instruction information are parsed, and the instruction reordering risk access group is generated based on the address cross-relationship and timing dependency between the access instructions, including: Parse the collected access instruction sequence, extract the target address, operation type and occurrence time of each access instruction, and sort the access instructions of the same core according to the occurrence time to form an intra-core access sequence; Based on the analyzed in-core access sequence, identify the cross-relationship of the target address, determine whether multiple cores access the memory address of the same shared variable at the same time, and record the cross-access instruction pairs; Parse the time information of the cross-access instruction pairs, determine whether there is a timing dependency based on the occurrence time of the access instruction and its correlation with the memory barrier instruction, and record the instruction pairs that have a time dependency; The cross-access instruction pairs and the instruction pairs with time dependency are combined, and instruction reordering risk access groups are generated according to the core number, access target address and time sequence.

4. The real-time simulation performance evaluation method based on the ARMv8 architecture multi-core processor according to claim 1 is characterized in that: Perform concurrent consistency analysis on the access instruction reordering risk access group, identify possible race conditions in the use of low-level hardware primitives, and record the synchronization method and memory barrier instruction distribution corresponding to the access instruction sequence, including: Classifying the access instructions in the access instruction reordering risk access group, and dividing the access instructions in the access instruction reordering risk access group into a read access instruction group, a write access instruction group, and a mixed operation access instruction group according to the operation type, target address, and occurrence time of the access instructions; For the access instructions in each group, the usage of low-level hardware primitives is parsed, including marking the dependency, scope, and execution order of the hardware access instructions; On the basis of grouping, according to the target address and time relationship between access instructions, analyze whether there are potential race conditions for access instructions on the same target address, including the situation where multiple cores access the same target address at the same time and the memory barrier instruction fails to cover all access instructions; The synchronization mode involved in the access instruction sequence of each group is recorded, including the type of synchronization mode, the synchronization scope and the specific access instructions it acts on.

5. The real-time simulation performance evaluation method based on the ARMv8 architecture multi-core processor according to claim 1 is characterized in that: Inject high-intensity concurrent operation scenarios into the actual simulation environment, use the concurrency monitoring module to continuously track the read and write operations of shared variables, and compare the execution order of each instruction reorder risk access group with the expected order obtained by analysis, including: Build an actual simulation environment and set up multi-core high-concurrency operation scenarios, including defining the target address range of shared variables and assigning access operation tasks to each core to ensure that multiple cores can perform read and write operations simultaneously; Inject high-intensity concurrent load into the simulation scenario and set each core to access the shared variables at randomized time intervals; The concurrent monitoring module is used to continuously track all read and write operations of shared variables, record the operation type, target address and execution time of each access, and generate a complete access instruction sequence; Compare the access instruction sequence recorded by the trace with the expected sequence obtained by analysis to analyze whether there is instruction reordering in the actual execution sequence; The instruction reordering detected in the comparison results is stored in the form of structured data, recording the cause, impact scope and access instruction number involved of each instruction reordering.

6. The real-time simulation performance evaluation method based on the ARMv8 architecture multi-core processor according to claim 1 is characterized in that: The execution sequence matching degree of each instruction reordering risk access group under different simulation load conditions is counted, and the real-time simulation performance evaluation indicators under weak memory model conditions are comprehensively generated, including: Set multiple load conditions in the simulation environment, including high-intensity load, medium-intensity load, and low-intensity load. Under each load condition, adjust the access frequency and operation interval of multiple cores to shared variables to form different concurrent scenarios. For each instruction reordering risk access group under each load condition, the actual execution order of the access instruction sequence is compared with the expected order, and the execution order matching degree of each group of access instructions is recorded. The execution order matching degree is determined by comparing whether the actual execution order is consistent with the expected order obtained by analysis; Based on the matching data of various load conditions, real-time simulation performance evaluation indicators for the weak memory model are generated. The real-time simulation performance evaluation indicators include the execution consistency of each instruction reordering risk access group under different load conditions, the frequency of instruction reordering, and the instruction execution time deviation.

7. The real-time simulation performance evaluation method based on the ARMv8 architecture multi-core processor according to claim 6 is characterized in that: Under high-intensity load conditions, each core frequently accesses shared variables at the minimum time interval to simulate an extremely high-concurrency environment; under medium-intensity load conditions, each core accesses shared variables at a relatively balanced time interval; under low-intensity load conditions, each core accesses shared variables at a larger time interval to simulate a low-concurrency environment; Under each load condition, the access time interval between cores to shared variables is adjusted by introducing a randomization mechanism; the access order and time interval between cores are generated by a random function.

Images