Algorithm performance evaluation method, system and device for data stream architecture, and medium

Abstract

The invention relates to the technical field of hardware performance evaluation of a stream architecture, and relates to an algorithm performance evaluation method, system and device for a data stream architecture, and a medium. The method comprises the following steps: receiving a source code of a control flow algorithm, replacing a basic data type in the source code with an agent template type, and generating an instrumented code; compiling and executing the instrumented code on a CPU, capturing and recording instruction execution information in real time through a heavy load operator of the proxy template class, and generating an execution log; reading the execution log, constructing a dynamic data dependency graph, and deducing a parallel scheduling and execution process of an instruction on data flow hardware through discrete event simulation based on a parameterized target data flow hardware model to obtain simulation execution time; and comparing the simulation execution time with the actual measurement time on the CPU to obtain an estimated acceleration factor. According to the method, the acceleration potential of the control flow algorithm on the target data flow system structure can be accurately evaluated.

Description

Technical Field

[0001] This application relates to the field of hardware performance evaluation technology for dataflow architectures, and to a method, system, device, and medium for algorithm performance evaluation of dataflow architectures. Background Technology

[0002] In the field of high-performance computing (HPC), the selection of the computing model is crucial for achieving efficient parallel computing. Currently, the mainstream computing models are mainly divided into two categories: control-flow architecture and dataflow architecture. These two architectures differ significantly in terms of parallel computing capabilities, programming complexity, and applicable scenarios. Control-flow architecture relies on a predefined sequence of instructions to control the execution flow of the program. In this architecture, the execution path of the program is determined by a series of conditional judgments and loop structures, and the parallel computing capability is mainly limited by instruction-level parallelism and the scalability of multi-core processors. Although modern multi-core processors have improved the parallel processing capabilities of control-flow architecture to some extent, their performance is still limited when facing large-scale parallel computing tasks, making it difficult to fully utilize the potential computing power of the hardware. Unlike control-flow architecture, dataflow architecture adopts a data-driven computing model. In this architecture, program execution is triggered by data availability; when the required data is ready, the corresponding computing unit immediately starts execution. Dataflow architecture inherently possesses high parallelism and is particularly suitable for handling large-scale parallel computing tasks. It can execute data-independent operations simultaneously on multiple processing units (PEs), thereby significantly improving computing efficiency.

[0003] However, the programming complexity of dataflow architectures is far greater than that of controlflow architectures, requiring developers to possess advanced parallel programming skills and a deep understanding of hardware. In practical applications, many algorithms and controlflow programs were originally designed for controlflow architectures. With the increasing demand for parallel computing, developers consider migrating these algorithms to dataflow hardware in hopes of achieving better performance acceleration. Before migrating, developers face a key question: how to accurately predict the performance acceleration potential of controlflow algorithms on dataflow hardware? Due to the fundamental differences in execution modes and parallelism between controlflow and dataflow architectures, existing software performance analysis tools (such as Profiler) are primarily designed for controlflow environments and cannot be directly applied to performance prediction for dataflow hardware.

[0004] Specifically, the existing technology has the following shortcomings: Lack of accurate prediction tools: Existing performance analysis tools cannot accurately predict the performance acceleration factor of control flow algorithms on data flow hardware, resulting in developers lacking a scientific basis when making migration decisions.

[0005] High migration risk: Because it is impossible to accurately predict the performance improvement after migration, developers may face the risk that the performance improvement is not obvious or even decreases after migration, thus wasting a lot of human and time costs.

[0006] Hardware selection difficulties: Different data stream hardwares have different performance characteristics, making it difficult for developers to choose the most suitable data stream hardware platform for their algorithms.

[0007] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0008] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0009] This disclosure provides a method, system, apparatus, and medium for evaluating the performance of algorithms in dataflow architectures. This method, through automated code instrumentation, execution log generation, and simulation of scheduling engines, can effectively and accurately evaluate the acceleration potential of control flow algorithms on target dataflow architectures without actual dataflow hardware programming. It helps developers reduce the risks and costs of dataflow development and provides a scientific basis for algorithm optimization and hardware selection.

[0010] In some embodiments, the method includes: Receive the source code of the control flow algorithm, replace the basic data types in the source code with proxy template classes that overload arithmetic and logical operators, and insert path marker function calls after the control structure to generate instrumented code; The instrumented code is compiled and executed on the CPU. The overloaded operators of the proxy template class are used to capture and record instruction execution information in real time, generating a structured execution log containing instruction unique identifiers, operation types, and operand dependencies. The execution log is read, a dynamic data dependency graph is constructed, and based on the parameterized target data flow hardware model, the parallel scheduling and execution process of instructions on the data flow hardware is deduced through discrete event simulation to obtain the simulated execution time. The estimated acceleration factor is obtained by comparing the simulated execution time with the actual measured time on the CPU.

[0011] Preferably, the path marking function call is used to generate a static identifier during program execution and map the executed instructions back to their locations in the source code.

[0012] Preferably, the structured execution log operand dependencies record the output results of previous instructions on which the input operands of the current instruction depend.

[0013] Preferably, the parameterized target data stream hardware model includes at least the number of processing units and the computational latency period for different types of operations.

[0014] Preferably, the discrete event simulation specifically includes the following steps: (1) Initialize the simulation environment, input the dynamic data dependency graph and hardware model parameters, and set the virtual clock, event queue, ready instruction queue and processing unit resource pool; (2) Advance the virtual clock to the next event occurrence time, process the instruction completion event at the current time, release the corresponding processing unit resources, and update the data dependency state of the downstream node of the instruction; (3) Scan the dynamic data dependency graph and move all nodes whose data dependencies have been satisfied into the ready instruction queue; (4) If the ready instruction queue is not empty and the processing unit resource pool has available resources, then a processing unit is allocated to the ready node, and a new instruction completion event is generated in the event queue according to the operation delay. (5) Repeat steps (2) to (4) until the event queue and ready instruction queue are empty. The simulation ends and the total simulation execution time and performance statistics are output.

[0015] Preferably, the estimated acceleration factor is obtained by dividing the measured time on the CPU by the simulated execution time.

[0016] In some embodiments, the algorithm performance evaluation system for a dataflow architecture includes: The code instrumentation module receives source code and generates instrumented code by replacing data types and insertion path markers; The execution and logging module is used to execute the instrumented code on the CPU and generate an execution log that records the instructions and their data dependencies. The data flow evaluation module is used to read the execution log, construct a dynamic data dependency graph, and calculate the estimated acceleration factor by simulating the parallel execution process through a hardware model and a scheduling engine.

[0017] Preferably, the data flow evaluation module further includes a configurable hardware model library for storing performance parameters of different data flow hardware architectures.

[0018] In some embodiments, the apparatus for the algorithm performance evaluation method for a dataflow architecture includes a processor and a memory storing program instructions, the processor being configured to execute the algorithm performance evaluation method for a dataflow architecture when running the program instructions.

[0019] In some embodiments, the storage medium stores program instructions that, when executed, perform the algorithm performance evaluation method for a data flow architecture.

[0020] The present disclosure provides a method, system, apparatus, and medium for evaluating algorithm performance in dataflow architectures, which can achieve the following technical effects: This invention generates high-fidelity execution logs through automated code instrumentation and combines them with a dynamic data dependency graph (DDG) and a parameterized hardware model to quantitatively predict the performance acceleration potential of control flow algorithms on dataflow hardware. This quantitative prediction capability enables developers to accurately assess performance improvements before migration, avoiding wasted development resources due to insignificant performance gains and significantly reducing the risks of dataflow development.

[0021] The Dynamic Data Dependency Graph (DDG) constructed in this invention can clearly display the data dependencies between instructions in an algorithm. Combined with parallel execution simulation of a scheduling engine, it can accurately identify potential performance bottlenecks. This bottleneck analysis capability provides developers with targeted optimization directions, such as adjusting the instruction execution order or optimizing the data dependency structure, thereby improving the actual performance of the algorithm on dataflow hardware.

[0022] This invention, through a configurable hardware model library, allows developers to simulate the impact of different dataflow hardware (such as hardware with different numbers of PEs or different operating latencies) on algorithm performance. This flexibility helps developers select the most cost-effective hardware platform based on their actual needs, avoiding performance waste caused by hardware incompatibility and optimizing the efficiency of computing resource configuration.

[0023] This invention automates the entire process from code instrumentation and log generation to simulation evaluation. Developers only need to submit the source code and select the hardware model to obtain the estimated acceleration factor and performance statistics. This automated toolchain significantly reduces the workload of manual analysis, shortens the evaluation cycle of algorithm migration, and improves overall development efficiency.

[0024] The programming complexity of dataflow architectures is relatively high. However, this invention, through simulation evaluation, allows developers to assess the migration value without needing in-depth knowledge of the low-level hardware details of dataflow systems. This reduction in technical barriers facilitates the migration of control flow algorithms to dataflow architectures, promoting the application of dataflow computing technology in a wider range of fields.

[0025] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0026] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of an algorithm performance evaluation system architecture for a dataflow architecture provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram illustrating the design and execution process of a scheduling engine in an algorithm performance evaluation method for a dataflow architecture provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram illustrating the DDG generation principle of the vector dot product process provided in this embodiment of the disclosure; Figure 5 This is a schematic diagram of the device structure provided in an embodiment of this disclosure. Detailed Implementation

[0027] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0028] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0029] Unless otherwise stated, the term "multiple" means two or more.

[0030] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0031] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0032] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.

[0033] Example 1 like Figure 1 As shown, a method for evaluating algorithm performance in dataflow architectures is presented. This method involves deep analysis of source code written in a control flow language to predict and quantify potential performance acceleration factors when executed on dataflow hardware, and to identify potential performance bottlenecks. This invention aims to help developers determine the value of algorithm migration, select suitable hardware platforms, and guide subsequent optimization directions. The method includes: S1: Receive the source code of the control flow algorithm, replace the basic data types in the source code with proxy template classes that overload arithmetic and logical operators, insert path marker function calls after the control structure, and generate instrumented code; S2: Compile and execute the instrumented code on the CPU, capture and record instruction execution information in real time through the overloaded operators of the proxy template class, and generate a structured execution log containing instruction unique identifiers, operation types and operand dependencies; S3: Read the execution log, construct a dynamic data dependency graph, and based on the parameterized target data flow hardware model, deduce the parallel scheduling and execution process of instructions on the data flow hardware through discrete event simulation to obtain the simulated execution time; S4: The estimated acceleration factor is obtained by comparing the simulated execution time with the actual measured time on the CPU.

[0034] As a refinement of the above embodiments, the path marking function call is used to generate a static identifier during program execution and map the executed instructions back to their locations in the source code.

[0035] As a refinement of the above embodiments, the structured execution log operand dependencies record the output results of previous instructions on which the input operands of the current instruction depend.

[0036] As a refinement of the above embodiments, the parameterized target data stream hardware model includes at least the number of processing units and the computational latency period for different types of operations.

[0037] As a refinement of the above embodiments, such as Figure 3 As shown, the discrete event simulation specifically includes the following steps: (1) Initialize the simulation environment, input the dynamic data dependency graph and hardware model parameters, and set the virtual clock, event queue, ready instruction queue and processing unit resource pool.

[0038] Specifically, the input parameters are the data dependency graph (DDG) and the hardware model (HM), where the hardware model includes parameters such as the number of physical objects (PEs) (N) and the operation latency. The virtual clock (T_sim) is set to 0, and an empty event queue (EQ), a resource pool (PE_Pool) containing N available PEs, and an empty ready queue (ReadyQ) are created.

[0039] (2) Advance the virtual clock to the next event time, process the instruction completion event at the current time, release the corresponding processing unit resources, return it to the PE resource pool, and update the data dependency state of the downstream node of the instruction.

[0040] (3) Scan the dynamic data dependency graph and move all nodes whose data dependencies have been satisfied into the ready instruction queue.

[0041] (4) If the ready instruction queue is not empty and the processing unit resource pool has available resources, then a processing unit is allocated to the ready node, and a new instruction completion event is generated in the event queue according to the operation delay.

[0042] Specifically, if the Ready queue (ReadyQ) is not empty and the PE resource pool (PE_Pool) has available PEs, then a node is taken from the Ready queue (ReadyQ) and an available PE is assigned to it. The completion time of the node (T_sim + corresponding operation delay) is calculated, and an "instruction completed" event for that time point is added to the event queue (EQ).

[0043] (5) Repeat steps (2) to (4) until the event queue and ready instruction queue are empty. The simulation ends and the total simulation execution time and performance statistics are output.

[0044] As a refinement of the above embodiments, the estimated acceleration factor is obtained by dividing the measured time on the CPU by the simulated execution time.

[0045] Example 2 like Figure 4 As shown, this embodiment uses the calculation of the vector dot product under control flow as an example to illustrate the system's execution process. The formula for calculating the vector dot product is as follows, where A and B are two vectors, R is the result scalar, and n represents the length of the vector.

[0046] , (1) C++ code for calculating the dot product of control flow: floatdot_product(float*a,float*b,intsize){ floatsum = 0.0f; for(int i=0;i <size;++i){ sum = sum + a[i] * b[i]; } returnsum; } (2) The process of automated code instrumentation. The first step is type replacement, where all float type variables (sum) inside the function are replaced with DataflowProxyVar. <float>The function signature and parameters will also be adjusted accordingly. The second is path mark injection: MarkExecutionPath() calls are inserted at the function entry point and the loop entry point, and a unique static ID is assigned (e.g., the function entry ID is 201, and the loop ID is 202).

[0047] DataflowProxyVar <float>dot_product_instrumented( DataflowProxyVar <float>*a, DataflowProxyVar <float>*b, intsize ){ MarkExecutionPath(201); / / Mark the function entry path DataflowProxyVar <float>sum = 0.0f; MarkExecutionPath(202); / / Mark the path of the loop body for(int i=0;i <size;++i){ The runtime library will combine the static ID '202' and the loop variable 'i' to generate a unique dynamic path ID. DataflowProxyVar <float>product = a[i] * b[i]; sum = sum + product; } returnsum; } (3) The program is executed on the CPU. The evaluator works in the background and generates a record for each instruction executed by the overloaded operator. After execution, an execution log is generated: In the following log, iuid represents a unique instruction ID, in the format of static path ID_dynamic part_sequence number; operands are the IUIDs of the dependent instructions, such as const_A0 representing constants from the input. [ / / Initial sum = 0.0f; (path 201, instruction 1) {"iuid":"201_1","op":"ASSIGN_CONST","operands":[],"value":0.0}, / / ---Loop i=0(dynamic path ID:202_0)--- / / product=a[0]*b[0];(2.0*5.0) {"iuid":"202_0_1","op":"FMUL","operands":["const_A0","const_B0"]}, / / sum = sum + product; {"iuid":"202_0_2","op":"FADD","operands":["201_1","202_0_1"]}, / / ---Loop i=1(dynamic path ID:202_1)--- / / product=a[1]*b[1];(3.0*6.0) {"iuid":"202_1_1","op":"FMUL","operands":["const_A1","const_B1"]}, / / sum = sum + product; {"iuid":"202_1_2","op":"FADD","operands":["202_0_2","202_1_1"]}, / / ---Loop i=2(dynamic path ID:202_2)--- / / product=a[2]*b[2];(4.0*7.0) {"iuid":"202_2_1","op":"FMUL","operands":["const_A2","const_B2"]}, / / sum = sum + product; {"iuid":"202_2_2","op":"FADD","operands":["202_1_2","202_2_1"]} ] (4) Data flow simulation and evaluation The analysis and simulation engine reads the aforementioned log file and loads a user-defined parameterized hardware model file, hardware_model.xml. This hardware model parameter file provides the necessary hardware-related information. An example is shown below: <dataflowhardware> <PE_Count>2< / PE_Count> <!--There are 2 parallel processing units--> <latencies> <Operation type="FMUL" cycles="2" / > <!--Floating-point multiplication requires 2 clock cycles--> <Operation type="FADD" cycles="1" / > <!--Floating-point addition requires 1 clock cycle--> < / latencies> < / dataflowhardware> (5) Construct a data dependency graph (DDG) Based on the operands field of the log, the system constructs the data dependency graph (DDG) for the algorithm.

[0049] As shown in the diagram, the three multiplication operations are independent and can be executed in parallel. The three addition operations form a sequential dependency chain.

[0050] (6) Event-driven scheduling simulation The CPU-side simulator simulates the execution process of the data flow architecture, and then monitors the execution status of each step on the CPU side.

[0051] T_sim=0. Mul0-1 is assigned to PE0-1, execution begins. T_sim=2. After Mul0-1 finishes execution, PE0-1 is idle. The dependencies mul0 and mul1 of add0 and add1 meet the conditions, so mul2 is assigned to PE0 and add0 is assigned to PE1.

[0052] T_sim=3. ADD0 completes. PE1 becomes idle. Another dependency of ADD1 (ADD0) is satisfied. Both dependencies of ADD1 (MUL1, ADD0) are satisfied. Assign ADD1 to PE1. T_sim=4. MUL2 and ADD1 complete simultaneously. PE1 and PE0 become idle. Both dependencies of ADD2 (ADD1, MUL2) are satisfied. ADD2 is assigned to PE1.

[0053] T_sim=5. ADD2 complete, all instructions executed.

[0054] The final result shows that, on this data stream hardware, the calculation takes 5 clock cycles to complete.

[0055] (7) Acceleration factor calculation and bottleneck analysis T_dataflow (simulation execution time) = 5 clock cycles.

[0056] T_controlflow (measured time on CPU): Each floating-point operation (multiplication or addition) on the CPU takes 1 clock cycle. The original code has 3 multiplications and 3 additions, for a total of 6 operations, therefore T_controlflow ≥ 6 clock cycles.

[0057] Acceleration factor: T_controlflow / T_dataflow=6 / 5=1.2.

[0058] Example 3 like Figure 2 As shown, an algorithm performance evaluation system for dataflow architecture includes: The code instrumentation module receives source code and generates instrumented code by replacing data types and insertion path markers.

[0059] Specifically, this module is responsible for processing user-provided source code based on control flow. It automatically replaces basic data types (such as float) in the source code with the proxy template class defined in this invention. This proxy template class overloads all arithmetic and logical operators. Simultaneously, it scans the code for control structures such as if and for loops and inserts specific function calls after them.

[0060] The execution and logging module is used to execute the instrumented code on the CPU and generate an execution log that records the instructions and their data dependencies.

[0061] Specifically, after the injected program is compiled, it is executed on the host's CPU. During execution, the overloaded operators of the proxy class send detailed information about each arithmetic instruction to the log generator, ultimately generating a structured execution log file. The log contains a unique instruction identifier (iuid), used to map the executed instruction back to its source code location; the operation type, identifying the type of operation performed; and operand dependencies, used to record which previous instructions' outputs the input operands of the current instruction originated from.

[0062] The data flow evaluation module (simulation scheduling engine) is used to read the execution log, construct a dynamic data dependency graph, and deduce the parallel execution process based on the hardware model through the simulation scheduling engine to calculate the estimated acceleration factor.

[0063] Specifically, this module reads the execution log and accesses a configurable dataflow hardware performance model library (which defines the key characteristics of the hardware). Based on the data dependency graph in the log and the hardware model, the evaluator simulates the parallel execution of instructions on the dataflow hardware, calculates the estimated execution time, and finally outputs a performance acceleration factor.

[0064] As a refinement of the above embodiments, the data flow evaluation module further includes a configurable hardware model library for storing performance parameters of different data flow hardware architectures.

[0065] Example 4 Combination Figure 5 As shown, this disclosure provides an algorithm performance evaluation device 300 for a dataflow architecture, including a processor 304 and a memory 301. Optionally, the device may further include a communication interface 302 and a bus 303. The processor 304, communication interface 302, and memory 301 can communicate with each other via the bus 303. The communication interface 302 can be used for information transmission. The processor 304 can call logical instructions in the memory 301 to execute the algorithm performance evaluation method for a dataflow architecture described in the above embodiment.

[0066] Furthermore, the logic instructions in the aforementioned memory 301 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0067] The memory 301, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 304 executes functional applications and data processing by running the program instructions / modules stored in the memory 301, that is, it implements the algorithm performance evaluation method for the dataflow architecture in the above embodiments.

[0068] The memory 301 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 301 may include high-speed random access memory and may also include non-volatile memory.

[0069] This disclosure provides a computer-readable storage medium storing computer-executable instructions configured to execute the above-described algorithm performance evaluation method for a dataflow architecture.

[0070] The aforementioned computer-readable storage medium may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

[0071] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this disclosure. The aforementioned storage medium can be a non-transitory storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code. It can also be a transient storage medium.

[0072] The foregoing description and accompanying drawings fully illustrate embodiments of this disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the terminology used in this application is for describing embodiments only and is not intended to limit the claims. As used in the description of embodiments and claims, the singular forms "a," "an," and "the" are intended to equally include the plural forms unless the context clearly indicates otherwise. Similarly, the term "and / or" as used in this application refers to any and all possible combinations of one or more of the associated listed elements. Additionally, when used in this application, the term "comprise" and its variations "comprises" and / or "comprising" refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase "comprising a…" does not exclude the presence of other identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0073] Those skilled in the art will recognize that the units and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0074] The methods and products disclosed in the embodiments herein (including but not limited to devices, equipment, etc.) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0075] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.< / float> < / float> < / float> < / float> < / float> < / float>

Claims

1. A method for evaluating algorithm performance in dataflow architectures, characterized in that, Includes the following steps: Receive the source code of the control flow algorithm, replace the basic data types in the source code with proxy template classes that overload arithmetic and logical operators, and insert path marker function calls after the control structure to generate instrumented code; The instrumented code is compiled and executed on the CPU. The overloaded operators of the proxy template class are used to capture and record instruction execution information in real time, generating a structured execution log containing instruction unique identifiers, operation types, and operand dependencies. The execution log is read, a dynamic data dependency graph is constructed, and based on the parameterized target data flow hardware model, the parallel scheduling and execution process of instructions on the data flow hardware is deduced through discrete event simulation to obtain the simulated execution time. The estimated acceleration factor is obtained by comparing the simulated execution time with the actual measured time on the CPU.

2. The algorithm performance evaluation method for dataflow architecture according to claim 1, characterized in that, The path marking function call is used to generate static identifiers during program execution and map the executed instructions back to their locations in the source code.

3. The algorithm performance evaluation method for dataflow architecture according to claim 1, characterized in that, The structured execution log operand dependencies record the output results of previous instructions that the input operands of the current instruction depend on.

4. The algorithm performance evaluation method for dataflow architecture according to claim 1, characterized in that, The parameterized target data stream hardware model includes at least the number of processing units and the computational latency period for different types of operations.

5. The algorithm performance evaluation method for dataflow architecture according to claim 1, characterized in that, The discrete event simulation specifically includes the following steps: (1) Initialize the simulation environment, input the dynamic data dependency graph and hardware model parameters, and set the virtual clock, event queue, ready instruction queue and processing unit resource pool; (2) Advance the virtual clock to the next event occurrence time, process the instruction completion event at the current time, release the corresponding processing unit resources, and update the data dependency state of the downstream node of the instruction; (3) Scan the dynamic data dependency graph and move all nodes whose data dependencies have been satisfied into the ready instruction queue; (4) If the ready instruction queue is not empty and the processing unit resource pool has available resources, then a processing unit is allocated to the ready node, and a new instruction completion event is generated in the event queue according to the operation delay. (5) Repeat steps (2) to (4) until the event queue and ready instruction queue are empty. The simulation ends and the total simulation execution time and performance statistics are output.

6. The algorithm performance evaluation method for dataflow architecture according to claim 1, characterized in that, The estimated acceleration factor is obtained by dividing the actual time on the CPU by the simulated execution time.

7. A performance evaluation system for algorithms in dataflow architectures, characterized in that, Performing the algorithm performance evaluation method for a dataflow architecture as described in any one of claims 1-6, comprising: The code instrumentation module receives source code and generates instrumented code by replacing data types and insertion path markers; The execution and logging module is used to execute the instrumented code on the CPU and generate an execution log that records the instructions and their data dependencies. The data flow evaluation module is used to read the execution log, construct a dynamic data dependency graph, and calculate the estimated acceleration factor by simulating the parallel execution process through a hardware model and a scheduling engine.

8. The system according to claim 7, characterized in that, The data flow evaluation module further includes a configurable hardware model library for storing performance parameters of different data flow hardware architectures.

9. An algorithm performance evaluation device for a dataflow architecture, comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to, when running the program instructions, execute the algorithm performance evaluation method for a dataflow architecture as described in any one of claims 1 to 6.

10. A storage medium storing program instructions, characterized in that, When the program instructions are executed, they perform the algorithm performance evaluation method for dataflow architecture as described in any one of claims 1 to 7.

Images