A cross-platform workload shrinking and refactoring method, system and application

Abstract

The application discloses a cross-platform workload shrinking and reconstructing method, which comprises the following steps: step one, for the workload to be shrunk and reconstructed, running the workload to be shrunk and reconstructed and sampling the workload to obtain workload key features as the sampling result; step two, constructing an intermediate file structure based on the workload sampling result obtained in step one; and step three, for the intermediate file structure in which the workload key feature result is saved in step two, constructing an executable file for each key simulation point in the workload, namely the workload after shrinking and reconstruction. The application further discloses a workload shrinking and reconstructing system and application for realizing the above method. The method, system and application have wide application value.

Description

Technical Field

[0001] This invention belongs to the fields of computer systems, performance profiling, and system performance optimization technology. It relates to a method, system, and application for scaling up and refactoring workloads by combining instrumentation and multi-threaded sampling simulation, which can run on multiple platforms. Background Technology

[0002] Performance optimization has wide applications in computer systems, primarily improving overall system performance by optimizing software design, implementation, configuration, deployment, and enhancing hardware resource utilization. Considering the real-world application scenarios of computer systems, system optimization is usually performed on specific workloads; therefore, workload-specific characteristic analysis is fundamental to understanding workload behavior and developing performance optimization strategies.

[0003] To pinpoint system performance bottlenecks, it's crucial to accurately and comprehensively analyze the characteristics of the workload. Workload characteristics typically include the hardware and software behavior during workload execution, such as dynamic instruction distribution, performance event counts, hot instructions, hot code segments, and hot functions. These workload characteristics can uncover potential optimization opportunities, providing direction and guidance for optimizing the hardware and software systems.

[0004] Since the actual workload may take too long to run (especially in a simulated environment), it is necessary to sample the actual workload to obtain a smaller or simpler workload that reflects the characteristics of the real workload. A scaled-down workload with similar load characteristics can not only shorten the runtime, but also reduce the difficulty for relevant personnel to perform load analysis and optimization, thereby improving the efficiency of analysis and optimization.

[0005] Sampling is a commonly used application scaling technique. Early research [1], [2] identified patterns in single-threaded applications and used these patterns to scale down large applications into smaller, more representative ones. These techniques significantly reduce the time required to simulate the original large application by accurately predicting the behavior of regions with similar behaviors. The successful application of these techniques demonstrates that sampling is an effective method for reducing workload size while maintaining sufficient accuracy.

[0006] Besides sampling, other techniques can be used to reduce the workload required for detailed simulations, such as input size reduction [3] and benchmark performance test synthesis [4]. While these techniques can reduce the workload required for simulation, they may result in problems such as loss of features in actual operation. Sampling, as a direct and effective method, can preserve the characteristics of the original application and accurately infer performance while reducing the overall simulation burden. By sampling, the time and resource consumption required for simulation can be significantly reduced while maintaining the necessary accuracy, enabling researchers to perform performance analysis and optimization more efficiently and improve the execution efficiency of the application.

[0007] As the number of processor cores increases, multithreaded applications can take full advantage of task and loop parallelism to maximize computational power. However, simulating these large-scale multithreaded applications is very difficult, even on modern simulators. For example, FPGA-based ultrafast simulators [5], while capable of providing detailed implementations, have limited capacity, which restricts the simulation of large processors and massively parallel systems.

[0008] Analyzing multithreaded applications is very difficult[8] because threads can sleep at any time, interfere with each other, and have complex behaviors in regular application parameters, such as thread misalignment with the core and uneven cache distribution. These factors increase the complexity and time consumption of the analysis.

[0009] Therefore, simulating and analyzing large-scale multithreaded applications requires addressing several technical challenges while seeking efficient solutions to reduce simulation time and resource consumption while maintaining necessary accuracy. Workload can be reduced through methods such as sampling, efficiency can be improved by combining optimization algorithms and simulation strategies, and the simulation process can be accelerated by leveraging parallel and distributed computing resources. Overcoming these challenges will enable researchers to better understand and optimize the performance of multithreaded applications, thus advancing the development of computing systems.

[0010] Some early multithreaded sampling solutions[9]-

[11] proved effective in solving thread synchronization problems. Time-based sampling methods

[10] were among the development of sampling techniques for synchronous multithreaded applications. However, the overall simulation speed was still related to the total workload length, which determined the simulation time of the method. Subsequent workload-based multithreaded sampling methods

[12] -

[14] surpassed the performance of time-based sampling, allowing the complexity of the simulation to be tied to the diversity of the application rather than the length of the application. However, these methods did not provide a universal sampling solution for all application types. LoopPoint

[15] addressed this problem to some extent, outperforming time-based sampling and previous workload-based sampling methods in simulating some larger and more representative benchmarks.

[0011] In the past, almost all sampling techniques ultimately required simulators to simulate the sampling results[6],[7]. However, using simulators to simulate sampling results is not convenient for sharing research results among developers. Each deployment of sampling work requires redeploying the development environment, which includes the sampling environment and the simulation environment. The steps are very complicated, and a sampling result that is easy to transfer and run is very important. On the other hand, different simulators have different methods of adapting to workloads. Some simulators in certain environments do not support the sampling files generated by the current mainstream sampling techniques. For example, the AArch64 simulator does not support running Pinball

[16] . Therefore, it is necessary to have a unified adaptation method for various simulators. The method of synthesizing executable files adopted in this paper can solve these two problems well. First, the execution of the executable file does not require any extra load as a medium, and it is very simple to transfer between developers. Second, the executable file is compatible with any simulator that supports running executable files. It does not need to be specially adapted for the sampling results. It can even run independently of the simulator, so the running speed of those sampling results will be faster. Whether running the executable file on an emulator or running it independently of an emulator, using the executable file as the sampling file can achieve excellent results.

[0012] Furthermore, in the past, most sampling techniques were implemented only on a single platform (such as x86 and AArch64). However, in modern computing environments, we often face various types of computing platforms, such as different operating systems, processor architectures, and hardware configurations. In this diverse environment, developers need to be able to perform effective performance analysis and optimization of applications. Sampling tools need to provide consistent interfaces and methods so that developers can perform performance analysis on different platforms, thereby better understanding and optimizing application behavior. Summary of the Invention

[0013] To address the shortcomings of existing technologies, the purpose of this invention is to provide a multi-platform method, system, and application for scaling up and refactoring workloads by combining instrumentation and multi-threaded sampling simulation.

[0014] This invention provides a cross-platform system for workload reduction and refactoring that combines instrumentation and multi-threaded sampling simulation. This work overcomes the limitations of previous efforts, integrates the advantages of current sampling techniques, and utilizes a method of synthesizing executable files to execute sampling results outside of simulators. The workload reduction and refactoring system proposed in this invention can be built and run on different platforms, reducing workloads on different platforms to those with shorter execution times but similar load characteristics. Since simulators need to simulate the behavior of the entire system, including operating system and hardware details, this is time-consuming. In contrast, this invention uses executable files to simulate sampling points, running directly in the actual execution environment, avoiding simulator overhead, and enabling faster acquisition of application performance data and more efficient performance analysis.

[0015] Secondly, using executable files to simulate sampling points can provide more accurate performance data. Simulators, when simulating system behavior, may not be able to fully replicate the characteristics of real hardware and operating systems, thus introducing some errors. However, using executable files to simulate sampling points runs directly in the actual execution environment, accurately reflecting the behavior and performance characteristics of the real system and providing more accurate performance data.

[0016] Furthermore, the scaled-down workload offers better portability and flexibility. Emulators are often designed for specific hardware and operating systems, which can limit their use across different platforms. This invention uses an executable file to simulate sampling points, allowing the scaled-down workload to run on various instruction set architecture-compatible platforms, facilitating performance analysis and optimization in different environments.

[0017] The cross-platform workload reduction and reconstruction method in this invention includes steps such as workload sampling, construction of intermediate file structure of workload sampling results, and construction of executable files for key simulation points of the workload; specifically, it includes the following steps:

[0018] Step 1: For the workload to be scaled down and refactored, run the workload and sample it, obtaining key characteristics of the workload as the sampling results. The workload to be scaled down and refactored includes benchmark programs, real application workloads, etc. Specifically, for the workload, dynamic binary instrumentation is performed to collect performance data of the workload, thereby obtaining one or more simulation points. By recording the key simulation points, the program execution process can be comprehensively observed. The key simulation points refer to simulation points that embody key function calls, loop iterations, or the main functions of certain workloads (other important events). By capturing these key simulation points, the key characteristics of the workload can be obtained.

[0019] Step 2: Based on the workload sampling results obtained in Step 1, a simple and easy-to-understand intermediate file structure similar to Pinball

[16] was constructed. This intermediate file structure saves the sampling results, including the execution path, state transitions, and key event information of the multi-threaded program in each thread; the key event information includes register data, memory data, instruction execution length, etc. Through this structured representation, researchers can more easily analyze and understand the execution process of the workload, thereby revealing the performance bottlenecks and optimization potential.

[0020] Step 3: Using the intermediate file structure containing the workload sampling results from Step 2, construct an executable file for each key simulation point of the workload, i.e., the reduced and reconstructed workload. Each key simulation point corresponds to a representative region in the source program. The representative region refers to a region that can represent the performance characteristics of certain parts of the workload. By testing the performance indicators of the representative region, the performance of the corresponding region in the workload can be reflected. In this invention, the performance results of the entire workload can be inferred by testing the performance results of each key simulation point. The inference refers to the inference that the performance data of all workload slices it represents can be inferred by testing the performance data of the executable file formed by each key simulation point. Integrating the performance data of all the inferred slices is the performance data result of the original workload. In the actual implementation process, the workload can first be divided into many slices to form one or more sets of slices containing similar performance characteristics. Since the performance characteristics of the slices within these sets are similar, the most representative slice (i.e., the key simulation point) in the set is selected to represent all slices in the set. Other slices in the set are represented by the key simulation point, and the impact on the performance change of the entire set is minimal; the most representative slice is the representative region. Once a slice of this representative region is obtained through measurement, its performance data reflects the performance data of all slices in the set it represents. This allows us to obtain the performance data for the entire set. By weighting all sets by instruction length, we obtain the performance data for each work unit, ultimately yielding the overall workload performance data. Finally, comparing the inversely derived performance data with the original workload's performance data verifies the accuracy of the downsizing and refactoring. If the inversely derived performance data is substantially consistent with the original workload's performance data, then the generated executable file represents the downsizing and refactored workload.

[0021] like Figure 4As shown, in actual implementation, a complete workload can be divided into one or more work units. Each work unit slice generates one or more workload slices, and a basic block vector (BBV) is generated for each workload slice. The BBV records the execution frequency of the basic blocks in the slice. The basic block is a continuous set of instructions in the program execution flow. The BBV constitutes the simulation region of the program, which represents the activity of each part of the program during execution.

[0022] Workload slices with similar performance characteristics are clustered into clusters, i.e., workload slice sets. Each work unit contains one or more workload slice sets. A representative slice is selected from each workload slice set as a key simulation point. Performance data such as IPC and branch miss rate are obtained by collecting data from the key simulation point. The performance data of each key simulation point represents the performance data of the workload slice set corresponding to that key simulation point. This process is repeated to obtain the performance data of all workload slice sets. The performance data of each work unit is obtained by weighting the data with instruction length, and finally, the performance data of the overall workload is obtained. At this point, the accuracy of the narrowing down the refactoring can be verified by comparing the back-integrated performance data with the performance data of the original program. If the back-integrated performance data is basically consistent, the narrowing down the refactoring is accurate; if the back-integrated performance data is inconsistent, the narrowing down the refactoring is inaccurate.

[0023] The executable files in step three of this invention exhibit high reproducibility, allowing researchers to repeatedly execute them in different environments for performance analysis and optimization experiments. Compared to the original program, these executable files, which reproduce the performance data of the original workload, are smaller in size and computational load, resulting in shorter runtimes. Furthermore, since these executable files are essentially representative key simulation points from different regions of the original workload, they maintain sufficient similarity to the original workload, achieved through workload scaling and reconstruction. These reproducible files enable researchers to conduct performance evaluations and optimization experiments more quickly, thereby accelerating the research process.

[0024] In addition, such as Figure 2 As shown, this invention can compile and build workloads on different platforms according to the requirements of program operation on different platforms, allowing users to use only the built workload and running method as input to this invention, which meets the user's need for scaling up and refactoring on different platforms, and is simple and convenient to operate.

[0025] Through the above steps, this invention provides an innovative workload reduction and refactoring system that can be used across platforms, offering researchers a powerful tool for in-depth analysis of the performance of multithreaded programs. The workload reduction and refactoring system includes: a key simulation point generation module, an intermediate file generation module, and an executable file generation module.

[0026] The key simulation point generation module is used to perform performance sampling on the original workload, find the key simulation points required for narrowing down the reconstruction, and pass the information of the key simulation points to the intermediate file generation module.

[0027] The intermediate file generation module is used to generate corresponding intermediate files for the key simulation points found, so that the executable file generation module can synthesize the executable file.

[0028] The executable file generation module is used to generate an executable file from the intermediate file and perform performance verification. If the performance verification is accurate, it means that the generated executable file is the reduced and refactored workload.

[0029] This invention also provides applications of the above-mentioned methods or systems in workload reduction and reconstruction for benchmark performance testing on processor architecture platforms such as AArch64 and X86, application workload performance optimization, using an executable file to display the results of the reduction and reconstruction system, and workload reduction services.

[0030] The beneficial effects of this invention include: compared with traditional simulation and performance analysis methods, the method and system of this invention have the following advantages:

[0031] First, the system of the present invention captures the key execution paths and events of the workload, and this data is directly generated by the original workload, which is closer to the program and has a higher feature similarity than the traditional simulator method.

[0032] Secondly, the introduction of the intermediate file structure makes the sampling results easier to understand and analyze. Through this structured representation, researchers can easily navigate and query the execution paths and state transitions of the workload, and also intuitively understand the division between DCFG and BBV, thus gaining a deeper understanding of their performance characteristics.

[0033] Finally, the original method of having to rerun the workload through a simulator was optimized. The set of executable files generated using key simulation points can be used and tested by researchers in a more flexible and convenient way.

[0034] Furthermore, the workload reduction and refactoring system of the present invention can be applied to different platforms, and its versatility is higher than that of traditional workload reduction and refactoring methods.

[0035] In summary, this invention provides a cross-platform workload reduction and refactoring method and system that combines instrumentation and multi-threaded sampling simulation, offering researchers a powerful tool for in-depth analysis of program performance. This system has broad application prospects and can be used on different platforms and in various fields, providing strong support for workload optimization and performance improvement. Attached Figure Description

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

[0037] Figure 1 It is a cross-platform flowchart that combines instrumentation and multi-threaded sampling simulation to scale down and refactor the workload.

[0038] Figure 2 It is a cross-platform user flow diagram of different systems that combines instrumentation and multi-threaded sampling simulation to scale down and refactor the workload.

[0039] Figure 3 This is an example diagram of the working unit definition for a cross-platform system that combines instrumentation and multi-threaded sampling simulation to scale down and refactor the workload.

[0040] Figure 4 It is a cross-platform diagram illustrating the performance backtesting of system work units by combining instrumentation and multi-threaded sampling simulation to scale down and refactor the workload.

[0041] Figure 5 This is a flowchart of Example 1.

[0042] Figure 6 This is a schematic diagram of the performance analysis process in Example 2.

[0043] Figure 7 This is a schematic diagram comparing the performance of Example 2.

[0044] Figure 8 This is a schematic diagram of Example 3.

[0045] Figure 9 This is a use case diagram for Example 4.

[0046] Figure 10 This is the user flow diagram for Example 4. Detailed Implementation

[0047] The present invention will be further described in detail below with reference to the specific embodiments and accompanying drawings. Except for the contents specifically mentioned below, the processes, conditions, and experimental methods for implementing the present invention are all common knowledge and general knowledge in the art, and the present invention does not have any particular limitations.

[0048] This invention proposes a method that can run on multiple platforms (such as...). Figure 2 (As shown), a system that combines instrumentation and multi-threaded sampling simulation to scale up and refactor the workload.

[0049] Figure 2 In this process, the workflow starts from the "Start" node;

[0050] Compile the source code of the scaled-down refactoring system into scaled-down refactoring systems for different platforms;

[0051] Run the executable file to be scaled down and refactored on scaled-down and refactored systems on different platforms;

[0052] The process is divided into two branches based on different platforms: one for the x86 platform and the other for the AArch64 platform. Each branch is tested for a specific hardware architecture.

[0053] X86 platform:

[0054] Run the executable file to be executed on a scaled-down refactored system based on the x86 platform to obtain the scaled-down executable file; and perform performance verification, including metrics such as IPC (instructions per cycle) and branch miss (branch prediction error);

[0055] Output Analysis Report: An analysis report is generated based on the performance test results;

[0056] AArch64 platform:

[0057] Run the executable file to be executed on the scaled-down and refactored system based on the AArch64 platform to obtain the scaled-down executable file; and perform performance verification, including metrics such as IPC and branch miss.

[0058] Output Analysis Report: An analysis report is generated based on the performance test results;

[0059] The process ends after the analysis report is output.

[0060] Specifically, the workload to be scaled down and refactored is sampled. By recording key simulation points in the workload, such as key function calls, loop iterations, and some main functions of the workload, key features of the program execution process are provided as sampling results. Based on the sampling results, this invention constructs a simple and easy-to-understand pinball-like intermediate file structure to store the sampling results. This intermediate file structure includes thread execution paths (e.g., the execution paths of each thread in a multi-threaded program), state transitions, and key event information. Through this structured representation, researchers can more easily analyze and understand the execution process of the workload, revealing performance bottlenecks and optimization potential. Using the sampling results and the intermediate file structure, this invention also constructs executable files as the scaled-down and refactored workload. These executable files can reproduce the operation and results of the workload. These scaled-down and refactored executable files have high repeatability and similarity of characteristic workloads, allowing researchers to repeatedly execute them in different environments for performance analysis and optimization experiments. Compared to the original program, these executables for reproducing workloads have shorter runtimes, enabling researchers to conduct performance evaluations and optimization experiments more quickly, thus accelerating the research process. This approach allows for a faster understanding of the workload's execution characteristics and provides effective tools and guidance for performance analysis and optimization.

[0061] A flowchart illustrating the method proposed in this invention is shown below. Figure 1 As shown, the specific implementation methods for each step are described in detail below:

[0062] Step 1: Record key simulation points in the workload

[0063] The specific implementation of recording key simulation points in a workload is achieved through sampling techniques. In this technique, the present invention uses an efficient sampling method to provide a comprehensive observation of the program execution process by recording key simulation points in the workload. These key simulation points can be critical function calls, loop iterations, or other important events that include some of the main functions of the workload. By capturing these points, key characteristics of the workload can be obtained.

[0064] Specifically, the method of the present invention samples an executable file, so the input of the method of the present invention is the executable file and its corresponding running commands and dataset.

[0065] To implement sampling, the workload is first divided into a series of work units, or program segments. A work unit is defined as a set or more workload slices that actually perform the work; it can be a loop iteration or other suitable program segment. Figure 3As shown, suppose there are many suitable program segments in a certain workload. These program segments are the actual amount of work done in the entire workload. They can be executed serially or in parallel. Each of these program segments is defined as a work unit. In addition, it is necessary to ensure that the work unit is not affected by external factors such as synchronization mechanism

[15] because it is necessary to shrink and refactor each work unit. If the instruction repetition of each work unit is high and the operation is more regular, then the shrink and refactoring effect of the work unit will be better. Therefore, it is necessary to minimize the influence of other factors on the work unit.

[0066] In a multi-threaded environment, spinlocks consume CPU cycles but do not contribute to the actual work of the workload. Therefore, spinlocks are not included when considering work units to ensure that the obtained key simulation points are related to the actual work of the workload and to ignore the impact of spinlocks on the actual work of the workload

[15] .

[0067] Loop iteration is chosen as the unit of work because for applications with a fixed-size input set, the number of iterations is unaffected by external factors such as synchronization mechanisms, ensuring the consistency of the unit of work. The division of the unit of work is constituted by generating the program's Dynamic Control Flow Graph (DCFG), which involves three specific steps:

[0068] (1) First, determine the nodes (Extended Basic Block) and edges of DCFG: The nodes (Extended Basic Block) of DCFG are defined as segments of assembly code. This assembly code segment does not contain any control flow jump instructions except for the last instruction. The edges of DCFG are responsible for connecting two nodes. All Extended Basic Blocks are divided before actual instrumentation, which is a static pre-instrumentation.

[0069] (2) The nodes of the DCFG are connected by dynamic pegboards to form the entire DCFG diagram.

[0070] (3) Mark the instruction flow of the program source code after generating the DCFG diagram to generate working units.

[0071] The Basic Block Vector (BBV)

[18] is a fundamental method for understanding the execution region of an application. BBV is a vector in which each dimension represents the number of times a program enters a basic block during runtime. In the implementation of this invention, the program is decomposed into many basic blocks, each containing a series of sequentially executed instructions, and there are no intermediate jumps when entering and exiting. That is, a basic block is a piece of code in the program that can be executed continuously from beginning to end without branching.

[0072] For example, if a work unit consistently calls a function, the dimension value corresponding to the first basic block of that function will be relatively large. Similarly, if a branch tends to jump, the value of the basic block that consistently jumps to that branch will be relatively large. If two work units have similar values ​​on the same branch or function call, their execution paths will be similar, or in other words, their instruction execution performance data will be quite close.

[0073] The work units are divided into slices, and a BBV is generated for each slice. The BBV constitutes the simulation region of the program, and in order to align the work units with the loop boundaries, the end of the BBV is set as the entry point of the next work unit.

[0074] In the simulation area of ​​the program, sampling code is inserted into the application to record thread execution information. The sampling code should be able to capture key information such as thread ID, call stack, timestamp, and memory access. During application runtime, each thread is sampled independently, and its execution information is recorded in the simulation area.

[0075] After sampling, execution information for each thread will be obtained. This information can be stored in memory or written to a file for subsequent processing and analysis.

[0076] After analyzing the application and identifying the region of the selected work unit, a set of slice regions of a specified length is obtained from the work unit. Next, the slices within the set can be clustered to form clusters, and the obtained clustering results can be used for workload extrapolation to infer the overall performance data of the original workload.

[0077] The slice closest to the centroid of each cluster is selected as the representative of that cluster. The performance characteristics represented by this slice indicate the overall performance characteristics of the cluster. These selected slices are the key simulation points of the program, such as... Figure 4 As shown. The specific clustering methods [1] are as follows:

[0078] (1) Use random linear projection to reduce the dimensionality of BBV data, for example, to 15 dimensions.

[0079] (2) Preset the value of k and try the k-means clustering algorithm on low-dimensional data with k values ​​from 1 to 10. Each run of k-means will generate a cluster, which divides the data into k different clusters. Generally, if the value of k is greater than 10 in a working unit, it indicates that the performance of the working unit fluctuates greatly, and the working unit is not suitable for shrinking and refactoring.

[0080] (3) For each cluster (k = 1...10), the Bayesian Information Criterion (BIC) is used to score the cluster fit. The k value with the best score is selected to ensure the accuracy of the clustering.

[0081] In cluster analysis, the Bayesian Information Criterion (BIC) can be used to determine the optimal number of clusters. For each possible number of clusters (k value), a BIC score can be calculated. Choosing the k value that minimizes the BIC score achieves a best fit to the data while avoiding unnecessary model complexity. This helps ensure clustering accuracy while preventing overfitting.

[0082] Step 2: An intermediate file structure was constructed for each key simulation point.

[0083] Intermediate file structure is a high-level file structure that records application execution. It contains information related to the execution status of the application and the results of workload sampling.

[0084] The intermediate file structure comprises the following components:

[0085] Program counter: Used to store the address of the instruction being executed. It is a part of the CPU and is used to track the execution location of the program.

[0086] Register state: This refers to the register state during application execution. These register states include general-purpose registers, floating-point registers, vector registers, etc. Recording register states provides context information about application execution.

[0087] Memory image: This refers to the memory access content during application execution. This includes read and write operations to memory, along with the corresponding memory addresses and data. Recording memory accesses is crucial for analyzing an application's data dependencies and memory access patterns.

[0088] Threads and Call Stack: This refers to the thread information and call stack information during application execution. Thread information includes thread ID, thread state, etc., while call stack information includes function call relationships, function parameters, and return values. This information is very helpful in understanding the concurrent behavior and execution path of an application.

[0089] Timestamps and event logs: Timestamps can be used to measure the execution time and performance of an application, while event logs can mark key events in the application, such as synchronization operations, lock acquisition and release, etc.

[0090] Dynamic Control Flow Graph (DCFG): A DCFG is a graphical representation used to describe the control flow transitions during program execution. Sampling results can include control flow graphs of loops generated by DCFG. Nodes in a DCFG represent basic blocks in the program, and edges represent transitions between these blocks. Records in a DCFG can help analyze the execution paths and control flow behavior of loops.

[0091] Loop Boundary Markers and Loop Regions: Loop boundary markers are the locations that identify loop boundaries in the instruction flow of the original program. Loop boundary markers are obtained by analyzing the program's DCFG (Distributed Function Chart) to identify loops and determine their start and end points. Identifying the start and end points of loops allows us to determine the loop region, thus narrowing down the work units for refactoring.

[0092] A loop region is a code segment defined by loop boundary markers, containing all iterations of a loop. The loop region serves as the unit of work for narrowing down refactoring. Loop iterations are chosen as the unit of work because, for applications with a fixed-size input set, the number of loop iterations remains unchanged regardless of external factors such as synchronization mechanisms, ensuring consistency within the unit of work. The specific format of a loop region consists of the addresses of the loop's start and end points, as well as the number of instructions within the loop region, facilitating detailed narrowing down of the loop region (i.e., the unit of work) later.

[0093] Step 3: Generate an executable file from the generated intermediate files.

[0094] The specific steps for generating an executable file from the intermediate files can be performed as follows:

[0095] Parsing intermediate files: First, the generated intermediate files need to be parsed. These files contain the application's execution state (such as register and memory information), instruction sequences, and other relevant information. By parsing the intermediate files, the application's execution trajectory and state can be reconstructed.

[0096] Reconstructing the executable file structure: Using the intermediate files obtained from parsing, it is necessary to reconstruct the structure of the original executable file. This includes restoring the code segment, data segment, symbol table, relocation information, etc. By rebuilding the executable file structure, the original form of the application can be accurately restored.

[0097] Relocation and Symbol Repair: The generated executable file may contain instructions and data that require relocation. Based on the relocation information in the intermediate files, corresponding relocation operations are performed to ensure that the instructions and data are in the correct memory locations. Relocation refers to the process of adjusting and correcting the address reference relationships between different modules during the linking stage when merging different modules or libraries into a single executable file. This is because different modules may be compiled separately and stored in different address spaces in memory during code writing and compilation. The linker's task is to integrate these modules into a single address space and resolve the address reference problems between modules.

[0098] Linking and building the executable: After completing the above steps, the process of linking and building the executable can proceed. This includes linking the restored code and data segments together, handling symbolic references, and generating a smaller, refactored executable.

[0099] After obtaining the scaled-down and reconstructed executable file, the executable file is verified as follows:

[0100] Program warm-up: During the execution of the source program, before a slice is executed, the operating system already has a state for executing that slice, such as the branch predictor. To ensure that the slice can reproduce the original program's execution state when executed independently, a warm-up is required before running the slice. This is done by truncating the intermediate files corresponding to the slice and using performance measurement tools such as Perf to set interrupts to accurately measure the slice's performance data.

[0101] Performance backtesting: In the original program, clustering generates different clusters of work units. For each work unit, the BBV closest to the centroid of each cluster is selected as the representative of that cluster, serving as a key simulation point. Each key simulation point represents a specific work unit cluster. By testing the performance data of the executable file formed by each key simulation point, the performance data of each work unit within its represented cluster can be backtested. Integrating all the backtested work unit performance data yields the original workload's performance data. For example, after scaling down and refactoring a work unit, two clusters are generated. The slices corresponding to the two BBVs closest to the centroids of these two clusters are selected as the key simulation points for that work unit. Running these two slices reflects the program execution of all slices within their respective clusters. For instance, to backtest the execution time, the execution time of each cluster is the execution time of the representative BBV of that cluster divided by the instruction ratio of that representative BBV. By statistically analyzing the execution times of all clusters, the execution time of the entire program can be deduced.

[0102] Verifying Accuracy: Evaluate the behavioral differences between the refactored workload and the original workload. The refactored workload should maintain behavioral characteristics as similar as possible to the original workload to ensure accuracy. This invention uses BBV to analyze large-scale program behavior and performs refactoring by reducing similar BBVs. Therefore, multiple performance metrics of the block vector (such as IPC, branch miss rate, and cache miss rate) are quantified, and the effectiveness of the refactoring is demonstrated by comparing these performance metrics.

[0103] If the accuracy verification fails, the workload will be marked as a general downsizing refactoring failure. Downsizing refactoring workers will need to further modify parameters such as the warm-up length to re-verify the effectiveness of the downsizing refactoring until the verification results meet the standards.

[0104] By following the steps above, representative slices are merged according to the execution order of the source code, generating a smaller workload that reflects the true load characteristics of the program and has a shorter execution time. This completes the reduction and refactoring process.

[0105] Example 1: Workload scaling and refactoring for benchmark performance testing on the AArch64 platform.

[0106] In performance evaluation scenarios, benchmark performance testing programs can be directly used to evaluate the performance of the computer system under test. Benchmark performance testing programs are a series of representative programs, typically extracted from real-world workloads. Benchmark performance tests assess the performance of a computer system under a specific workload by providing test scores (usually derived from metrics such as runtime and throughput). By observing the behavioral characteristics of the computer during benchmark performance testing, potential software and hardware optimization opportunities for specific application scenarios can be identified.

[0107] Using the multi-platform system proposed in this invention, which combines instrumentation and multi-threaded sampling simulation for workload scaling and reconstruction, a hypothetical benchmark performance test program is scaled and reconstructed to illustrate the implementation process of the system described in this invention. The process is as follows: Figure 5 As shown. The specific implementation plan is summarized as follows:

[0108] (1) Run the program, compile it to obtain binary executable code containing symbolic representations, use a program analyzer to sample the program, and obtain intermediate file data for synthesizing the executable file. The specific steps are as follows:

[0109] a) First, the intermediate file data is divided into two categories. One part is the basic data required to replay an executable file, such as the execution instruction sequence, register status, memory access, threads, and call stack. The other part is the data that is mainly based on reducing the basic unit of the refactoring workload, such as loop boundary marker data and loop region data.

[0110] b) For most intermediate file data, such as execution instruction sequences, register states, memory accesses, threads, and call stacks, dynamic binary code instrumentation tools can be used. For data such as loop boundary markers and loop regions, these data are closely related to the content to be replayed later. Therefore, it is necessary to use the execution instruction sequences, memory accesses, and loop boundaries obtained from the basic data to form vector data of loop regions by concatenating the basic units of data to reduce the refactoring workload. This makes it easier to target the key content after clustering for replay when generating the executable file from the intermediate file structure.

[0111] (2) The working units obtained in (1) are averaged and sliced, and the BBV of each slice is generated. Then the BBV data is clustered to obtain the representative regions in the working unit. These regions reflect the operation of the working unit. By sorting out the representative regions of all working units, the performance of the whole program can be obtained.

[0112] (3) Generate an executable file with a preheating section on the AArch64 platform based on the existing intermediate file data. Furthermore, use a performance measurement tool to set an interrupt during the execution of each slice to collect performance data for the portion of the slice excluding the preheating section.

[0113] (4) Combine all the slices in order into a small executable file. This executable file can reflect the performance data of the original program, such as IPC, cache miss rate, branch miss rate, etc., and the execution time is shorter.

[0114] Furthermore, this embodiment can also be deployed on other platforms to achieve the same effect.

[0115] Example 2: Application of Load Performance Optimization

[0116] In optimizing large application workloads, when some workloads are too complex to quickly analyze changes in load characteristics to verify optimization effectiveness, a strategy of splitting and reducing the workload is needed to identify key optimization points. Video coding performance optimization provides a typical example.

[0117] In video coding performance optimization, developers need to evaluate the effectiveness of an algorithm, that is, assess the performance of an encoding algorithm and identify bottlenecks in the encoding and decoding algorithms. To ensure the accuracy of the performance evaluation, control tests need to be conducted on the same input data.

[0118] Using this invention, critical loops in the video encoding process can be identified more accurately, thereby enabling a more refined evaluation of the encoding algorithm's performance in benchmark tests. The performance analysis and optimization process is as follows: Figure 6 As shown:

[0119] (1) Cycle identification: For an encoding / decoding algorithm, the key cycles of the test load are identified by the sampling method of this invention. These cycles may include core steps such as image transformation, quantization, and entropy coding.

[0120] (2) Critical loop analysis: Based on the identified loop points, critical loop analysis is performed to determine which loops have the greatest impact on coding performance. These loops may consume most of the coding time.

[0121] (3) Explore optimization methods: For critical loops, take performance optimization measures, such as optimizing internal loop calculations, vectorization, and multi-threaded parallel coding. The goal of optimization is to accelerate the execution of critical loops and improve coding performance.

[0122] By performing critical loop analysis on the video stream, optimization methods were explored. Finally, the optimized methods were used to replay the critical loops, and their performance was compared with that of the original method. The performance comparison process for loop replay is as follows: Figure 7 As shown:

[0123] (1) Loop playback: After optimization, the same input video stream is used to generate corresponding key loop slices for key loops in the algorithms before and after optimization. By performing loop playback tests on the key loop slices, the performance changes for the key loop before and after optimization can be explored more clearly.

[0124] (2) Furthermore, by comparing the encoding time, bit rate, video quality, and other indicators of various encoding algorithms, the performance improvement of optimization can be accurately evaluated, and a corresponding optimization report can be generated.

[0125] This invention allows developers to more accurately identify key points for optimizing video coding algorithms and provides a proprietary performance comparison method for these key points.

[0126] Example 3 uses an executable file to demonstrate the results of scaling up the refactoring system.

[0127] In practical downsizing and refactoring, it is generally necessary to perform operations such as slice preheating, performance measurement, and early termination of slices sequentially for each slice. This process is cumbersome and requires the integration of performance data to deduce the performance data of the original workload. This invention provides a feasible solution to arrange and integrate all slices in sequence, ultimately constructing an executable file that reflects the final downsizing and refactoring result. Specific implementation steps are as follows: Figure 8 As shown:

[0128] (1) Constructing the .text and data segment allocator: If the .text and data segments of all slices are merged together, it will inevitably lead to duplicate address segments, which will eventually cause program errors. Therefore, the .text and data segment allocator is needed to connect the .text and data segments of all slices together in a safe way and generate a directory to ensure that the .text and data segments of all slices can be found.

[0129] (2) Implanting control flow code for running slices: Because each slice has a unique way of warming up, running and measuring, it is necessary to implant control flow code to manage the warm-up, running and measuring of each slice. In addition, the control flow code will also read the .text section directory and data section directory of each slice to ensure that each slice can be accessed by the control flow code.

[0130] (3) Verification and testing: After generating the merged executable file, test and verify it to ensure that it works as expected and that the merged data is correct.

[0131] This invention allows the results of the reduced reconstruction work to be presented to relevant personnel in one step, eliminating the tedious work of running different slices multiple times, lowering the threshold for using this invention and improving its convenience.

[0132] Example 4: Workload Shrinking Service

[0133] This document provides an example of a web service that enables users to remotely shrink their workloads, reducing the cost for users to learn and use shrinking and refactoring tools, and allowing users to quickly and conveniently complete their own workload shrinking tasks. Figure 9 This is the workload reduction service. You can see the specific service content of the workload reduction service in detail. The following is a description of the use case diagram:

[0134] The specific service content is divided into three modules: user management module, workload reduction and restructuring module, and help module.

[0135] (1) User Management Module:

[0136] Users can perform the following use cases: register an account and log in to an account.

[0137] Users can manage their profiles and account settings.

[0138] (2) Workload reduction and refactoring module:

[0139] Users can upload workload files.

[0140] Users can choose to reduce the parameters of the refactoring tool, such as warm-up length and slice size.

[0141] • The user triggers the execution of the shrink refactoring tool.

[0142] Users can download the generated, scaled-down workload file.

[0143] Users can view their history and uploaded workload files.

[0144] (3) Help module:

[0145] Users can refer to the help and documentation for usage guidelines.

[0146] Users can contact technical support for assistance.

[0147] Figure 10 This is a flowchart of a user's scaling down and refactoring process in a workload scaling service. The flowchart is shown below:

[0148] Step 1: Users upload workload files in the workload reduction and refactoring module of the workload service;

[0149] Step 2: Users select the parameters for narrowing down the refactoring tool; they can choose the default parameters or customize the parameters.

[0150] Step 3: The user triggers the execution of the scale-down refactoring tool;

[0151] Step 4: Users receive reduced workload files and validity reports;

[0152] Step 5: The user chooses whether to re-scale and reconstruct the work. If they choose yes, they will skip to Step 2. If they choose no, the process ends.

[0153] References

[0154] [1] T. Sherwood, E. Perelman, G. Hamerly, and B. Calder, "Automatically characterizing large scale program behavior," in International Conference on Architectural Support for Programming Languages ​​and Operating Systems (ASPLOS), Oct. 2002, pp. 45–57.

[0155] [2]R.E.Wunderlich,T.F.Wenisch,B.Falsafi,and J.C.Hoe,“SMARTS:Accelerating microarchitecture simulation via rigorous statistical sampling,”in International Symposium on ComputerArchitecture(ISCA),Jun.2003,pp.84–97.

[0156] [3]A.J.KleinOsowski and D.J.Lilja,“Minnespec:A new SPEC benchmarkworkload for simulation-basedcomputer architecture research,”ComputerArchitecture Letters(CAL),vol.1,no.1,pp.7–7,2002.

[0157] [4]R.H.Bell and L.K.John,“Improved automatic testcase synthesis forperformance model validation,”inInternational Conference on Supercomputing(SC),Jun.2005,pp.111–120.

[0158] [5]S.Karandikar,H.Mao,D.Kim,D.Biancolin,A.Amid,D.Lee,N.Pemberton,E.Amaro,C.Schmidt,A.Chopra,Q.Huang,K.Kovacs,B.Nikolic,R.Katz,J.Bachrach,andK.Asanovic,“FireSim:FPGA-accelerated cycle-exact scale-out system simulationin the public cloud,”in International Symposiumon ComputerArchitecture(ISCA),Jun.2018,pp.29–42.

[0159] [6]T.E.Carlson,W.Heirman,and L.Eeckhout,“Sniper:Exploring the levelof abstraction for scalable andaccurate parallel multi-core simulation,”inInternational Conference for High Performance Computing,Networking,StorageandAnalysis(SC),Nov.2011,pp.52:1–52:12.

[0160] [7]D.Sanchez and C.Kozyrakis,“ZSim:Fast and accuratemicroarchitectural simulation of thousand-coresystems,”in InternationalSymposium on ComputerArchitecture(ISCA),Jun.2013,pp.475–486.

[0161] [8]A.Alameldeen and D.Wood,“Variability in architectural simulationsof multi-threaded workloads,”inInternational Symposium on High-PerformanceComputerArchitecture(HPCA),Feb.2003,pp.7–18.

[0162] [9]T.F.Wenisch,R.E.Wunderlich,M.Ferdman,A.Ailamaki,B.Falsafi,andJ.C.Hoe,“SimFlex:Statistical sampling ofcomputer system simulation,”IEEEMicro,vol.26,no.4,pp.18–31,2006.

[0163]

[10] E.K.Ardestani and J.Renau,“ESESC:A fast multicore simulator usingtime-based sampling,”inInternational Symposium on High PerformanceComputerArchitecture(HPCA),Feb.2013,pp.448–459.

[0164]

[11] T.E.Carlson,W.Heirman,and L.Eeckhout,“Sampled simulation ofmulti-threaded applications,”inInternational Symposium on PerformanceAnalysisofSystems and Software(ISPASS),Apr.2013,pp.2–12.

[12] T.E.Carlson,W.Heirman,K.Van Craeynest,and L.Eeckhout,“BarrierPoint:Sampled simulation ofmulti-threaded applications,”in

[0165]

[13] T.Grass,A.Rico,M.Casas,M.Moreto,and E.Ayguad′e,“TaskPoint:Sampledsimulation oftask-basedprograms,”in International Symposium on PerformanceAnalysis of Systems and Software(ISPASS),Apr.2016,pp.296–306.

[0166]

[14] T.Grass,T.E.Carlson,A.Rico,G.Ceballos,E.Ayguad′e,M.Casas,andM.Moreto,“Sampledsimulation oftask-basedprograms,”Transactions on Computers(TC),vol.68,no.2,pp.255–269,2019.

[0167]

[15] A.Sabu,H.Patil,W.Heirman and T.E.Carlson,"LoopPoint:Checkpoint-driven Sampled Simulation for Multi-threaded Applications,"2022IEEEInternational Symposium on High-Performance Computer Architecture(HPCA),Seoul,Korea,Republic of,2022,pp.604-618,doi:10.1109 / HPCA53966.2022.00051.

[16] H.Patil and T.E.Carlson,“Pinballs:portable and shareable user-levelcheckpoints for reproducible analysis and simulation,”in Workshop onReproducible Research Methodologies(REPRODUCE),Feb.2014.

[0168]

[17] C.Yount,H.Patil,and M.S.Islam,“Graph-matching-basedsimulationregion selection for multiple binaries,”in International Symposiumon Performance Analysis of Systems and Software(ISPASS),Mar.2015,pp.52–61.

[0169]

[18] T.Sherwood,E.Perelman,and B.Calder.Basic block distributionanalysis to findperiodic behavior and simulation points in applications.InInternational Conference on Parallel Architectures and CompilationTechniques,September 2001.

[0170] The scope of protection of this invention is not limited to the above embodiments. Any variations and advantages that can be conceived by those skilled in the art without departing from the spirit and scope of this invention are included in this invention and are protected by the appended claims.

Claims

1. A cross-platform workload reduction and refactoring method, characterized in that, The method includes the following steps: Step 1: For the workload to be scaled down and restructured, run the workload to be scaled down and restructured and perform workload sampling to obtain the key features of the workload as the sampling results. Step 2: Based on the workload sampling results obtained in Step 1, construct the intermediate file structure; Step 3: For the intermediate file structure that stores the key feature results of the workload in Step 2, build an executable file for each key simulation point in the workload, that is, reduce the reconstructed workload. The reduced reconstructed workload can run on different types of processor architecture platforms. In step one, the performance data of the workload is sampled using a dynamic binary instrumentation method to obtain one or more simulation points. The key simulation points are recorded to comprehensively observe the program execution process. The key simulation points correspond to the key features in the workload, including key function calls, loop iterations, and load functions. The workload is divided into one or more work units. Each work unit slice generates one or more workload slices, and a basic block vector (BBV) is generated for each workload slice. Workload slices with similar performance characteristics are clustered into clusters, i.e., workload slice sets. Each work unit contains one or more workload slice sets. In each workload slice set, a representative slice that is closest to the centroid of the cluster is selected as the key simulation point. The BBV records the execution frequency of basic blocks in the slice and constitutes the simulation region of the program. Sampling code is inserted into the simulation region to record the execution information of the threads. The end of each BBV is set as the entry point for the next work unit, aligning the work unit with the loop boundary. Dividing the workload into one or more work units includes the following steps: Step 1: Static instrumentation determines the nodes and edges of the Dynamic Control Flow Graph (DCFG); the nodes of the DCFG refer to assembly code segments, which do not contain any control flow jump instructions except for the last instruction; the edges of the DCFG are responsible for connecting two nodes. Step 2: Connect the nodes of the DCFG using dynamic instrumentation to form the entire DCFG diagram; Step 3: After generating the DCFG diagram, mark the instruction flow of the program source code to generate working units; And / or, The workload slice clustering includes the following steps: Step (1): Use random linear projection to reduce the dimensionality of the BBV data; Step (2): Cluster the low-dimensional data with k values ​​from 1 to 10 using the k-means clustering algorithm; Step (3): For each cluster, the Bayesian information criterion is used to score the fit of the cluster; In step two, the intermediate file structure includes a program counter, register states, memory image, threads and call stacks, timestamps and event logs, dynamic control flow graph, loop boundary markers and loop regions; The program counter is used to store the address of the instruction being executed, and can track the execution position of the program; The register state refers to the register state during application execution, including general-purpose registers, floating-point registers, and vector registers; the record of the register state provides context information for application execution. The memory image refers to memory access during application execution, which includes operations of reading and writing to memory, as well as the corresponding memory addresses and data; The memory access records are used to analyze the application's data dependencies and memory access patterns; The threads and call stack refer to the thread information and call stack information during application execution; the thread information includes thread ID and thread state; the call stack information includes function call relationships, function parameters, and return values; the thread information and the call stack information are used to understand the concurrent behavior and execution path of the application. The timestamps are used to measure the execution time and performance of the application, and the event logs mark key events in the application; The Dynamic Control Flow Graph (DCFG) is used to describe the control flow transitions during program execution; nodes in the DCFG represent basic blocks in the program, and edges represent jump relationships between basic blocks; the records in the DCFG help analyze the execution path and control flow behavior of loops. The loop boundary marker refers to the location that identifies the loop boundary in the instruction stream of the original program; The loop boundary marker is obtained by analyzing the DCFG of the program to identify the loop and determine the start and end points of the loop; the loop region refers to a code region determined according to the loop boundary marker, and the code region contains all iterations of a loop; In step three, each key simulation point corresponds to a representative region of the source program, and the performance results of the key simulation point reflect the performance of the corresponding representative region. By testing the performance results of each key simulation point and weighting them with the instruction length of the representative region as the weight, the performance data of each working unit is obtained, and finally the performance results of the entire workload are inferred. Step three further includes the following steps: Step 3.1: Parse intermediate files: Parse intermediate files to reconstruct the execution trajectory and state of the application; the intermediate files contain the execution state and instruction sequence of the application; Step 3.2: Reconstruct the structure of the executable file: Using the intermediate file parsed in Step 3.1, reconstruct the structure of the original executable file to restore the original form of the application; the reconstruction process includes restoring the code segment, data segment, symbol table, and relocation information; Step 3.3, Relocation and Symbol Repair: Based on the relocation information in the intermediate file, perform relocation operations to ensure that instructions and data are in the correct memory locations; Step 3.4, Linking and Building the Executable: Link the restored code and data segments together, handle symbolic references, and generate a smaller, refactored executable.

2. The workload reduction and refactoring method as described in claim 1, characterized in that, In step two, the intermediate file structure includes a pinball structure that stores the workload sampling results; the intermediate file structure includes the execution path, state transitions, and key event information of the multi-threaded program in each thread; the key event information includes register data, memory data, and instruction length.

3. The method as described in claim 1, characterized in that, Step three also includes: Step 3.5, Program Warm-up: Warm-up is performed by truncating the intermediate file corresponding to the slice forward. An interrupt is set using a performance measurement tool to accurately measure the performance data of the slice itself. Step 3.6, Back-engineering performance results: For each working unit in the different clusters of working units generated by clustering in the original program, select the BBV closest to the centroid of each cluster as the representative of that cluster as the key simulation point. By testing the performance data of the executable file composed of each key simulation point, back-engineer the performance data of each working unit in the working unit cluster represented by the key simulation point. Integrate all the back-engineered working unit performance data to obtain the performance data result of the original workload. Step 3.7, Verify accuracy: Evaluate the behavioral differences between the refactored workload and the original workload.

4. A workload reduction and refactoring system for implementing the cross-platform workload reduction and refactoring method as described in any one of claims 1-3, characterized in that, The workload reduction and reconstruction system includes: a key simulation point generation module, an intermediate file generation module, and an executable file generation module; The key simulation point generation module is used to perform performance sampling on the original workload, find the key simulation points required for narrowing down the reconstruction, and pass the information of the key simulation points to the intermediate file generation module. The intermediate file generation module is used to generate corresponding intermediate files for the key simulation points found, so that the executable file generation module can synthesize the executable file. The executable file generation module is used to generate an executable file from the intermediate file and perform performance verification. If the performance verification is accurate, it means that the generated executable file is the scaled-down and refactored workload, which can run on different types of processor architecture platforms.

5. The cross-platform workload reduction and refactoring method as described in any one of claims 1-3, or the workload reduction and refactoring system as described in claim 4, which performs benchmark performance testing on platforms including AArch64 and X86 processor architectures, performs workload reduction and refactoring, optimizes application load performance, uses an executable file to demonstrate the results of the reduction and refactoring system, and applies the workload reduction service.

Images