Cross-platform workload reduction and reconstruction method, system and application

Abstract

The invention discloses a cross-platform workload reduction and reconstruction method, which comprises the following steps of: 1, aiming at a workload to be reduced and reconstructed, running the workload to be reduced and reconstructed and sampling the workload to obtain a workload key feature as a sampling result; step 2, constructing an intermediate file structure based on a workload sampling result obtained by sampling in the step 1; and step 3, for the intermediate file structure in which the key feature result of the workload is stored in the step 2, constructing an executable file for each key simulation point in the workload, namely reducing the reconstructed workload. The invention further discloses a workload reduction and reconstruction system and application for implementing the method. The method, the system and the application have wide application value.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer systems, performance analysis, and system performance optimization, and relates to a method, system, and application that can run on multiple platforms and combine instrumentation with multi-threaded sampling simulation to reduce and reconstruct workloads. Background Art

[0002] Performance optimization has a wide range of applications in computer systems, mainly improving the overall performance of the system by optimizing the design, implementation, configuration, and deployment of software and improving the resource utilization of hardware. Considering the actual application scenarios of computer systems, system optimization is usually performed for specific workloads. Therefore, feature analysis for specific workloads is the basis for understanding the operating behavior of workloads and formulating performance optimization plans.

[0003] In order to locate the system performance bottleneck, it is necessary to accurately and comprehensively analyze the characteristics of the workload. The workload characteristics usually include the behavior characteristics of the software and hardware during the load operation, such as dynamic instruction distribution during program execution, performance event counts, hot instructions, hot code segments, hot functions, etc. The characteristics of the workload can be used to discover potential optimization space and provide direction and guidance for the optimization of the software and hardware systems.

[0004] Since the running time of the actual workload may be too long (especially in a simulation environment), it is necessary to sample the actual workload to obtain a smaller or simpler workload to reflect the characteristics of the real load. A reduced workload with similar load characteristics can not only shorten the running time, but also reduce the difficulty of load analysis and optimization for relevant personnel, thereby improving the efficiency of analysis and optimization.

[0005] Sampling is a commonly used application reduction technique. Early studies [1], [2] identified regularities in single-threaded applications and used these regularities to reduce large applications to smaller representative applications. These techniques accurately predict the behavior of the original workload by executing regions with similar behaviors, thereby significantly reducing the time required to simulate the original large application. The successful application of these techniques shows that sampling is an effective way to reduce the size of workloads while maintaining sufficient accuracy.

[0006] In addition to sampling, there are other techniques that can be used to reduce the amount of work required for detailed simulation, such as input size reduction [3] and benchmark synthesis [4]. Although these techniques can reduce the amount of work required for simulation, they may suffer from problems such as missing features in actual operations. Sampling is a direct and effective method that can maintain the characteristics of the original application and accurately infer performance while reducing the overall simulation burden. Through sampling, the time and resource consumption required for simulation can be significantly reduced while maintaining the necessary accuracy, allowing researchers to perform performance analysis and optimization more efficiently and improve the execution efficiency of applications.

[0007] As the number of processor cores increases, multithreaded applications can fully exploit task and loop parallelism to unleash their computing power. However, simulating these massively multithreaded applications is very difficult, even on modern simulators. For example, FPGA-based ultra-fast simulators [5] can provide detailed implementations, but their limited capacity restricts simulations of large processors and massively parallel systems.

[0008] The analysis of multithreaded applications is difficult[8] because threads can sleep at any time, threads interfere with each other, and there are complex behaviors in general application parameters, such as thread-to-core misalignment and uneven cache distribution. These factors make the analysis more complex and time-consuming.

[0009] Therefore, simulation and analysis of large multithreaded applications requires addressing multiple technical challenges while seeking efficient solutions to reduce simulation time and resource consumption while maintaining the necessary accuracy. The 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 using parallel and distributed computing resources. Overcoming these challenges will enable researchers to better understand and optimize the performance of multithreaded applications and advance the development of computing systems.

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

[11] have proven effective in solving the thread synchronization problem. In the development of sampling techniques for synchronous multithreaded applications, time-based sampling methods

[10] are one of them. However, the overall simulation speed is still related to the total workload length, which determines the simulation time of this method. Subsequent multithreaded sampling methods based on workload characteristics

[12] -

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

[15] solves this problem to some extent, and its simulation effect on some large and representative benchmarks is better than time-based sampling and previous workload characteristic-based sampling methods.

[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 time a sampling task is deployed, the development environment needs to be redeployed, which includes the sampling environment and the simulation environment. The steps are very complicated. A sampling result that is easy to transfer and run is very important. On the other hand, different simulators have more or less different adaptation methods for workloads. Some simulators in some environments may not support the simulation of sampling files generated by the current mainstream sampling technology. For example, the AArch64 simulator does not support running Pinball

[16] . Therefore, a unified adaptation method is needed for various simulators. The method of synthesizing executable files adopted in this paper can solve these two problems well. First, the running of executable files does not require any extra load as a medium, and it is very simple to transfer between developers. Second, executable files can adapt to any simulator that supports running executable files. There is no need to make special adaptations for sampling results. They can even run without simulators, so that the running speed of those sampling results will be faster. Whether running the executable file on the simulator or running it outside the simulator, using the executable file as the sampling file can achieve good results.

[0012] In the past, most sampling technologies were only implemented on a single platform (such as X86 and AArch64). However, in modern computing environments, we often face a variety of computing platforms, such as different operating systems, processor architectures, and hardware configurations. In such a diverse environment, developers need to be able to effectively analyze and optimize the performance of applications. Sampling tools need to provide consistent interfaces and methods to enable developers to perform performance analysis on different platforms, so as to better understand and optimize the behavior of applications. Summary of the invention

[0013] In order to solve the deficiencies in the prior art, the purpose of the present invention is to provide a multi-platform method, system and application for reducing and reconstructing workloads by combining instrumentation and multi-threaded sampling simulation.

[0014] The present invention provides a cross-platform system for reducing and reconstructing workloads by combining instrumentation and multi-threaded sampling simulation. In this work, the limitations of previous work are overcome, the advantages of current sampling technology are integrated, and the method of synthesizing executable files is used to execute sampling results independently of the simulator. The workload reduction and reconstruction system proposed in the present invention can be built and run on different platforms, reducing the workloads on different platforms into loads with short execution times but similar load characteristics. Since the simulator needs to simulate the behavior of the entire system, including the details of the operating system and hardware, it is relatively time-consuming. In the present invention, executable files are used to simulate sampling points and run directly in the actual execution environment, avoiding the overhead of the simulator, and the performance data of the application can be obtained more quickly and performance analysis can be performed more efficiently.

[0015] Secondly, using executable files to simulate sampling points can provide more accurate performance data. When simulating system behavior, the simulator may not be able to completely restore the real hardware and operating system characteristics, thus introducing certain errors. However, using executable files to simulate sampling points directly runs in the actual execution environment, which can accurately reflect the behavior and performance characteristics of the real system and provide more accurate performance data.

[0016] In addition, the reduced load can have better portability and flexibility. Simulators are often designed for specific hardware and operating systems, so their use on different platforms may be limited. The present invention uses executable files to simulate sampling points, and the reduced load can run on various platforms compatible with the instruction set architecture, which is convenient for performance analysis and optimization in different environments.

[0017] The cross-platform workload reduction and reconstruction method of the present invention includes the steps of workload sampling, construction of an intermediate file structure of workload sampling results, construction of an executable file of a key simulation point of workload, etc.; specifically, it includes the following steps:

[0018] Step 1. For the workload to be reduced and reconstructed, run the workload to be reduced and reconstructed and perform workload sampling, and obtain the key features of the workload as the sampling results; the workload to be reduced and reconstructed includes benchmark test programs, real application loads, etc. Specifically, for the workload, dynamic binary instrumentation is performed to collect the performance data of the workload, and then one or more simulation points are obtained. By recording the key simulation points in the simulation points, the program execution process can be fully observed. The key simulation points refer to simulation points that embody the main functions (other important events) of certain loads, including key function calls, loop iterations, or certain loads. By capturing these key simulation points, the key features 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] is constructed. This intermediate file structure saves the sampling results, including the execution path, state transitions, and key event information of each thread of the multi-threaded program; the key event information includes register data, memory data, instruction run 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 in step 2 that stores the workload sampling results, an executable file is constructed for each key simulation point of the workload, that is, the workload after the reduction and reconstruction. Each key simulation point corresponds to a representative area in the source program. The representative area refers to an area that can represent the performance characteristics of some partial areas of the workload. By testing the performance indicators of the representative area, the performance of the corresponding area in the workload can be reflected. In the present invention, the performance results of the entire workload can be inferred by testing the performance results of each key simulation point. The inversion means that the performance data of all workload slices represented by it can be inferred by testing the performance data of the executable file composed of each key simulation point. The performance data of all slices obtained by the inversion are integrated to obtain the performance data results 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 of the set. The other slices in the set are represented by the key simulation point, which has little effect on the performance change of the entire set; the most representative slice is the representative area. After measuring and obtaining the slice of this representative area, the performance data of this representative area reflects the performance data of all slices of the set it represents, so that the performance data of the set can be obtained. When all sets are weighted by instruction length, the performance data of each work unit is obtained, and finally the performance data of the entire workload can be obtained. Finally, the accuracy of the reduction and reconstruction can be verified by comparing the reversed performance data with the performance data of the original workload; if the reversed performance data is basically consistent with the performance data of the original workload, it means that the generated executable file is the workload after the reduction and reconstruction.

[0021] like Figure 4As shown, in the actual implementation process, 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 block in the slice, and the basic block is a continuous instruction set in the program execution flow; the BBV constitutes the simulation area of ​​the program, and the simulation area represents the activities of various parts of the program during the execution process;

[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. The performance data of the key simulation point is obtained by collecting data, such as IPC, branch miss rate, etc. The performance data of each key simulation point is used to represent the performance data of the workload slice set corresponding to the key simulation point. By analogy, the performance data of all workload slice sets are obtained, and the performance data of each work unit is obtained by weighting with the instruction length, and finally the performance data of the overall workload is obtained. At this point, the accuracy of the reduction and reconstruction work can be verified by comparing the performance data of the reverse integration with the performance data of the original program; if the performance data of the reverse integration is basically consistent, it means that the reduction and reconstruction work is accurate; if the performance data of the reverse integration is inconsistent, it means that the reduction and reconstruction work is inaccurate.

[0023] The executable file in step three of the present invention has high repeatability, and researchers can repeat it in different environments to perform performance analysis and optimization experiments. Compared with the original program, these executable files that reproduce the original load performance data have a smaller volume and a smaller amount of computation, so the running time is shorter, and because the executable files are actually representative key simulation points of different areas in the original workload, it can also ensure sufficient similarity with the original workload, which is achieved by reducing and reconstructing the workload. Reproduction files can help researchers perform performance evaluation and optimization experiments more quickly, thereby speeding up the research process.

[0024] In addition, if Figure 2 As shown, the present invention can compile and construct workloads on different platforms according to the requirements of program running on different platforms, allowing users to use only the constructed workloads and running methods as inputs of the present invention, meeting the needs of users for shrinking and reconstructing on different platforms, and the operation is simple and convenient.

[0025] Through the above steps, the present invention provides an innovative workload reduction and reconstruction system that can be used across platforms, providing researchers with a powerful tool to deeply analyze the performance of multi-threaded programs. The workload reduction and reconstruction 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 out the key simulation points required for reduction and 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 the corresponding intermediate file for the key simulation points found, so as to facilitate the executable file generation module to synthesize the executable file;

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

[0029] The present invention also provides the application of the above method or system in workload reduction and reconstruction of benchmark performance tests on processor architecture platforms such as AArch64 and X86, application load performance optimization, using an executable file to display the results of the reduction and reconstruction system, workload reduction services, etc.

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

[0031] First, the system of the present invention captures the critical execution paths and events of the workload, and these data are directly generated from the original workload, which is closer to the program and has a higher feature similarity than traditional simulator methods.

[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 path and state transitions of the workload, and can also intuitively understand the partitioning of DCFG and BBV, thereby gaining a deeper understanding of its performance characteristics.

[0033] Finally, the original method of re-running workloads through the simulator was optimized, and the collection of executable files generated by key simulation points can be more flexible and convenient for researchers to use and test.

[0034] In addition, the workload reduction and reconstruction system of the present invention can be applied to different platforms and has higher versatility than traditional workload reduction and reconstruction methods.

[0035] In summary, the present invention provides a cross-platform workload reduction and reconstruction method and system that combines instrumentation and multi-threaded sampling simulation, providing researchers with a powerful tool to deeply analyze the performance of programs. The system has broad application prospects and can be used in different platforms and fields, providing strong support for workload optimization and performance improvement. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of 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 paying any creative work.

[0037] Figure 1 It is a cross-platform flowchart for reducing and refactoring workloads by combining instrumentation with multi-threaded sampling simulation.

[0038] Figure 2 It is a cross-platform user usage flow diagram of different systems that combines instrumentation and multi-threaded sampling simulation to reduce and reconstruct workloads.

[0039] Figure 3 This is a cross-platform work unit definition example diagram for a system that combines instrumentation and multi-threaded sampling simulation to shrink and restructure workloads.

[0040] Figure 4 It is a cross-platform system work unit performance reverse deduction diagram that combines instrumentation and multi-threaded sampling simulation to reduce and reconstruct the workload.

[0041] Figure 5 It is a flow chart of the first embodiment.

[0042] Figure 6 It is a schematic diagram of the performance analysis process of the second embodiment.

[0043] Figure 7 It is a performance comparison diagram of the second embodiment.

[0044] Figure 8 It is a schematic diagram of embodiment 3.

[0045] Fig. 9 It is a use case diagram of Embodiment 4.

[0046] Fig.10 This is a user flow chart of the fourth embodiment. DETAILED DESCRIPTION

[0047] The present invention is further described in detail with reference to the following specific examples and drawings. The process, conditions, experimental methods, etc. for implementing the present invention, except for the contents specifically mentioned below, are all common knowledge and common common sense in the art and are not particularly limited by the present invention.

[0048] The present invention proposes a method that can be run on multiple platforms (such as Figure 2 As shown in Figure 3), a system that combines instrumentation with multi-threaded sampling simulation to shrink and restructure workloads.

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

[0050] Compile the source code of the minification and reconstruction system into minification and reconstruction systems for different platforms;

[0051] Run the executable files to be minified and refactored on the minification and refactoring systems of different platforms;

[0052] The process is divided into two branches according to different platforms, one is the X86 platform and the other is the AArch64 platform. Each branch tests a specific hardware architecture;

[0053] X86 Platform:

[0054] Run the executable file on the X86 platform-based shrinking and reconstruction system to obtain the shrunken executable file; and perform performance verification, including indicators such as IPC (instructions per cycle) and branch miss (branch prediction error);

[0055] Output analysis report: Output analysis report based on performance test results;

[0056] AArch64 Platforms:

[0057] Run the executable file on the AArch64-based shrinking and reconstruction system to obtain the shrunken executable file; and perform performance verification, including IPC and branch miss indicators;

[0058] Output analysis report: Output analysis report based on performance test results;

[0059] The process ends after outputting the analysis report.

[0060] Specifically, the workload to be reduced and reconstructed is sampled, and by recording the key simulation points in the workload, such as key function calls, loop iterations, and the main functions of some loads, the key features of the program execution process are provided as sampling results. Based on the sampling results, the present invention constructs a simple and easy-to-understand Pinball-like intermediate file structure for saving the sampling results. This intermediate file structure contains thread execution paths (such as the execution paths of multi-threaded programs in each thread), state transitions, and key event information. Through this structured representation, researchers can more conveniently analyze and understand the execution process of the workload, revealing the performance bottlenecks and optimization potential therein. Using the sampling results and the intermediate file structure, the present invention also constructs an executable file as the workload after reduction and reconstruction, which can reproduce the operation status and operation results of the workload. These reduced and reconstructed executable files have high repeatability and feature load similarity, and researchers can repeatedly execute them in different environments to perform performance analysis and optimization experiments. Compared to the original programs, these executable files for reproducing workloads have shorter running times, which can help researchers conduct performance evaluation and optimization experiments more quickly, thereby accelerating the research process. In this way, the execution characteristics of the workload can be understood in a shorter time, and effective tools and guidance can be provided for performance analysis and optimization.

[0061] The schematic diagram of the process of the present invention is as follows Figure 1 As shown, the specific implementation of each step is described in detail below:

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

[0063] The specific implementation method of recording the key simulation points in the workload is achieved through sampling technology. In this technology, the present invention uses an efficient sampling method to provide a comprehensive observation of the program execution process by recording the key simulation points in the workload. These key simulation points can be key function calls, loop iterations, or other important events including some of the main functions of the workload. By capturing these points, the 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 data sets.

[0065] To implement sampling, the workload is first divided into a series of work units, or program fragments. A work unit is defined as the amount of work actually completed by one or more groups of workload slices, which can be a loop iteration or other suitable program fragment. Figure 3As shown in the figure, assume that there are many suitable program fragments in a workload. These program fragments are the actual amount of work completed in the entire workload. They can be executed serially or in parallel. Each of these program fragments 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 mechanisms as much as possible

[15] , because it is necessary to perform shrinking and reconstruction on each work unit. If the instruction repetition of each work unit is high and the operation is more regular, then the shrinking and reconstruction effect of the work unit will be better. Therefore, it is necessary to reduce the impact of other factors on the work unit as much as possible.

[0066] In a multi-threaded environment, spin locks consume CPU cycles but do not contribute to the actual work of the workload. Therefore, spin locks are not included in the work unit consideration to ensure that the key simulation points obtained are related to the actual work of the workload, ignoring the impact of spin locks on the actual work of the workload

[15] .

[0067] Loop iteration is chosen as the unit of work because for applications with fixed-size input sets, the number of loops does not change with external factors such as synchronization mechanisms, which ensures the consistency of the unit of work. The division of work units consists of generating the dynamic control flow graph DCFG of the program, which has 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 the last instruction. The edges of DCFG are responsible for connecting two nodes. All the divisions of Extended Basic Block are performed before the actual insertion, which is a static advance insertion.

[0069] (2) Use dynamic stubs to connect the nodes of DCFG to form the entire DCFG graph.

[0070] (3) After generating the DCFG graph, the instruction stream of the program source code is marked to generate a work unit.

[0071] Basic block vector BBV

[18] is a basic method to understand the execution area of ​​an application. BBV is a vector, each dimension of which represents the number of times a program enters a basic block when it is running. In the implementation process of the present invention, the program is decomposed into many basic blocks, each of which contains a series of instructions executed sequentially, and there are no intermediate jumps when entering and exiting, that is, a basic block is a section of code in the program that can be executed continuously from beginning to end without forking.

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

[0073] By slicing the divided work units, a BBV is generated for each slice, the BBV constitutes a simulation area of ​​the program, and in order to align the work unit with the loop boundary, the end of the BBV is set as the entry of the next work unit.

[0074] In the simulation area of ​​the program, the execution information of the thread is recorded by inserting sampling code in the application. The sampling code should be able to capture key information such as thread ID, call stack, timestamp, memory access, etc. When the application is running, each thread will be sampled independently and the execution information will be recorded in the simulation area.

[0075] After sampling, the execution information of 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 determining the area of ​​the selected work unit, a set of slice areas of a specified length is obtained from the work unit. Next, the slices in the set can be clustered to form clusters, and the obtained clustering results can be used to perform workload extrapolation to infer the performance data of the original workload as a whole.

[0077] The slice closest to the centroid of each cluster is selected as the representative of the cluster. The performance characteristics represented by the slice represent the performance characteristics of the entire cluster. These selected slices are the key simulation points of the program, such as Figure 4 The specific clustering method [1] is as follows:

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

[0079] (2) Preset the k value and try the k-means clustering algorithm for low-dimensional data with k values ​​ranging from 1 to 10. Each time k-means is run, a cluster is generated, which divides the data into k different clusters. Generally, in a work unit, if the k value is greater than 10, it means that the performance fluctuation within the work unit is large, and the work unit is not suitable for shrinking and reconstructing.

[0080] (3) For each cluster (k=1...10), the Bayesian Information Criterion (BIC) is used to score the fit of the cluster. 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. The k value that minimizes the BIC score is selected to obtain the best fit to the data while avoiding unnecessary model complexity. This can help ensure the accuracy of the clustering while avoiding overfitting.

[0082] Step 2: Constructed an intermediate file structure for each key simulation point

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

[0084] The components of the intermediate file structure include the following:

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

[0086] Register status: This refers to the register status when the application is executed. These register states include general registers, floating point registers, vector registers, etc. The record of register status can provide context information of application execution.

[0087] Memory image: This refers to the memory access content during the execution of the application. This includes the operations of reading and writing memory, as well as the corresponding memory addresses and data. The record of memory access is very important for analyzing the data dependencies and memory access patterns of the application.

[0088] Threads and call stacks: This refers to the thread information and call stack information when the application is executed. Thread information includes thread ID, thread status, etc., while call stack information includes function call relationships, function parameters, and return values, etc. This information is very helpful for understanding the concurrent behavior and execution path of the application.

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

[0090] Dynamic Control Flow Graph (DCFG): DCFG is a graphical representation used to describe the control flow transition relationship when a program is executed. The sampling results can include the control flow graph of the loop generated by DCFG. The nodes in the DCFG represent the basic blocks in the program, and the edges represent the jump relationship between basic blocks. The DCFG records can help analyze the execution path and control flow behavior of the loop.

[0091] Loop boundary marking and loop region: Loop boundary marking refers to the location of loop boundary in the instruction stream of the original program. Loop boundary marking is obtained by analyzing the DCFG of the program to identify loops and determine the start and end points of the loops. By identifying the start and end points of the loop, the loop region can be obtained, that is, the work unit of the reconstruction work can be reduced.

[0092] A loop region is a code region identified by loop boundary markers, which contains all iterations of a loop. The loop region is the work unit for shrinking and refactoring. Loop iteration is chosen as the work unit because the number of loops for applications with fixed-size input sets does not change with external factors such as synchronization mechanisms, which ensures the consistency of the work unit. The specific format of the loop region consists of the addresses of the program loop start and end points and the number of loop region instructions, which facilitates detailed shrinking and refactoring of the loop region (i.e., work unit) later.

[0093] Step 3: Generate an executable file based on the generated intermediate files

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

[0095] Parsing intermediate files: First, you need to parse the generated intermediate files. The intermediate files contain the execution status of the application (such as register and memory information), instruction sequences, and other related information. By parsing the intermediate files, you can restore the execution track and status of the application.

[0096] Reconstruct the structure of the executable file: Using the intermediate file obtained by parsing, the structure of the original executable file needs to be reconstructed. This includes restoring the code segment, data segment, symbol table, relocation information, etc. By reconstructing the structure of the executable file, the original form of the application can be accurately restored.

[0097] Relocation and repairing symbols: In the generated executable file, there may be instructions and data that need to be relocated. According to the relocation information in the intermediate file, corresponding relocation operations need to be performed to ensure that the instructions and data are in the correct memory location; the relocation refers to the process of adjusting and correcting the address reference relationship between modules when merging different modules or libraries of the program into an executable file during the linking phase. This is because when writing and compiling the code, different modules may be compiled and stored separately in different address spaces of the memory. The task of the linker is to integrate these modules into one address space and solve the address reference problem between modules.

[0098] Linking and building executable files: After completing the above steps, the process of linking and building executable files can be carried out. This includes linking the recovered code segments and data segments together, processing symbol references, and generating a reduced and reconstructed executable file.

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

[0100] Program preheating: During the execution of the source program, before a slice is executed in the source program, the operating system already has a state for executing the slice, such as the branch predictor, so in order to restore the state of the original program execution when the slice is executed alone, it is necessary to preheat the slice before running it. The preheating is performed by forwarding the slice from the intermediate file corresponding to the slice, and interrupts are set using performance measurement tools such as Perf to correctly measure the performance data of the slice itself.

[0101] Inverse performance results: In the original program, different clusters of work unit clusters will be generated after clustering. For each work unit, the BBV closest to the centroid of each cluster is selected as the representative of the cluster and the key simulation point. That is, each key simulation point has a work unit cluster it represents. By testing the performance data of the executable file composed of each key simulation point, the performance data of each work unit in the work unit cluster it represents can be inferred. The performance data of all work unit performance data obtained by inverse inference is the performance data result of the original workload. For example, after shrinking and reconstructing a work unit, two clusters are generated. The slices corresponding to the two BBVs closest to the centroid of the two clusters are selected as the key simulation points of the work unit. By running the two slices, the program execution status of all slices of the corresponding cluster can be reflected respectively. For example, inverse execution time, the execution time of each cluster is the execution time of the representative BBV of the cluster divided by the instruction ratio of the representative BBV of the cluster. After counting the execution time of all clusters, the execution time of the entire program can be inversely inferred.

[0102] Verify accuracy: Evaluate the behavioral differences between the reconstructed workload and the original workload. The reconstructed workload should maintain behavioral characteristics similar to the original workload as much as possible to ensure accuracy. In the present invention, BBV is used to analyze large-scale program behavior, and the reduction and reconstruction are performed by cutting similar BBVs, thereby quantifying multiple performance indicators of this block vector (such as IPC, branch miss rate, and cache miss rate), and comparing these performance indicators to illustrate the effectiveness of the reduction and reconstruction work.

[0103] If the accuracy verification fails to meet the standard, the workload will be marked as a general unsuccessful shrinking and reconstruction state, and the shrinking and reconstruction worker will need to further modify parameters such as the warm-up length to re-verify the effectiveness of the shrinking and reconstruction until the verification result meets the standard.

[0104] Through the above steps, the representative slices are merged according to the execution order of the source program to generate a small workload with a short execution time that can reflect the real load characteristics of the program. The shrinking and reconstruction work is completed.

[0105] Example 1: Workload Reduction and Restructuring of Benchmark Performance Test on AArch64 Platform

[0106] In the performance evaluation scenario, you can directly use the benchmark performance test program to evaluate the performance of the computer system under test. Benchmark performance test programs are a series of representative programs that are usually extracted from real workloads. Benchmark performance tests evaluate the performance of computer systems under certain workloads by giving test scores (usually derived from indicators such as running time and throughput). The behavioral characteristics of the computer running during the benchmark performance test can be used to identify potential software and hardware optimization space in specific application scenarios.

[0107] The system for reducing and reconstructing workloads by combining multi-platform instrumentation and multi-threaded sampling simulation proposed by the present invention is used to reduce and reconstruct a hypothetical benchmark performance test program to illustrate the implementation process of the system of the present invention. The process is as follows: Figure 5 The specific implementation scheme is summarized as follows:

[0108] (1) Run the program and compile it to obtain binary executable code containing symbolic expressions. Use a program analyzer to sample the program and obtain intermediate file data of the synthesized 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 play back an executable file, such as the execution instruction sequence, register status, memory access, thread and call stack, etc. The other part is the data mainly used to reduce the basic unit of the reconstruction workload, such as loop boundary marker data, loop area and other data.

[0110] b) Most of the intermediate file data, such as execution instruction sequence, register status, memory access, thread and call stack data, can be implemented through dynamic binary code instrumentation tools. For loop boundary marker data, loop area and other data, these data are closely related to the content to be replayed later. Therefore, it is necessary to use the execution instruction sequence, memory access and loop boundary obtained from the basic data to reduce the basic unit of the reconstruction workload, and string them together to form vector data of the loop area, so as to facilitate the playback of the clustered key content when generating the executable file from the intermediate file structure.

[0111] (2) The work units obtained in (1) are sliced ​​evenly and the BBV of each slice is generated. The BBV data is then clustered to obtain representative areas in the work unit. These areas reflect the operation status of the work unit. By sorting out the representative areas of all work units, the performance of the entire program can be obtained.

[0112] (3) Generate an executable file with a preheating part based on the existing intermediate file data on the AArch64 platform. And set an interrupt when running each slice using the performance measurement tool to collect performance data of the slice other than the preheating part.

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

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

[0115] Example 2 Application Load Performance Optimization

[0116] In the optimization of large application loads, some loads are too complex to quickly analyze changes in load characteristics to verify the optimization effect. Therefore, it is necessary to adopt a strategy of splitting and reducing the load to find the key optimization points as much as possible. Video encoding performance optimization provides a typical example.

[0117] In video encoding performance optimization, developers need to evaluate the effectiveness of an algorithm, that is, to evaluate the performance of an encoding algorithm and find the bottleneck of the encoding and decoding algorithm. In order to ensure the correctness of the performance evaluation, it is necessary to ensure that the control test is performed on the same input data.

[0118] The present invention can more accurately identify the key loops in the video encoding process, thereby more finely evaluating the performance of the encoding algorithm in the benchmark performance test. Figure 6 As shown:

[0119] (1) Loop identification: For a coding algorithm, the sampling method of the present invention is used to identify the key loops of the test load. These loops 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 encoding performance. These loops may take up most of the encoding time.

[0121] (3) Explore optimization methods: Take performance optimization measures for key loops, such as optimizing loop internal calculations, vectorization, multi-threaded parallel coding, etc. The goal of optimization is to speed up the execution of key loops and improve coding performance.

[0122] By analyzing the key loops of the video stream, exploring optimization methods, and finally using the explored optimization methods to replay the key loops, the performance is compared with the method before optimization. The performance comparison process of loop playback 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 the key loop in the algorithms before and after optimization. By performing loop playback tests on the key loop slices, the performance changes of the key loop before and after optimization can be more clearly explored.

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

[0125] Through the present invention, developers can more accurately find the key points of video encoding algorithm optimization, and provide a performance comparison method dedicated to the key points.

[0126] Example 3: Using an executable file to show the results of shrinking and refactoring the system

[0127] In actual shrinking and reconstruction work, it is generally necessary to perform slice preheating, performance measurement, and early end control operations on each slice in turn. The operation is cumbersome and the performance data needs to be integrated to infer the performance data of the original workload. The present invention provides a feasible solution to arrange and integrate all slices in order, and finally construct an executable file to reflect the final shrinking and reconstruction results. The specific implementation steps are as follows: Figure 8 As shown:

[0128] (1) Constructing .text and data segment allocators: 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 execution errors. Therefore, .text and data segment allocators are required to connect the .text and data segments of all slices 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 preheating, running, and measuring, it is necessary to implant control flow code to manage the preheating, running, and measuring of each slice. In addition, the control flow code also reads the .text segment directory and data segment directory of each slice to ensure that each slice can be obtained by the control flow code.

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

[0131] Through the present invention, the output results of the reduced reconstruction work can be presented to relevant staff in one step, eliminating the tedious work of running different slices multiple times, lowering the threshold for using the present invention and improving convenience.

[0132] Example 4 Workload Reduction Service

[0133] Here is an embodiment of a Web service, which can provide users with remote workload reduction services, reduce the cost of users learning to use reduction and reconstruction tools, and enable users to quickly and conveniently complete their own workload reduction work. Fig. 9 It 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 reconstruction 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 profile and account settings.

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

[0139] Users can upload workload files.

[0140] Users can choose to reduce the parameters of the reconstruction tool, such as preheat length, slice size, etc.

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

[0142] Users can download the resulting minified workload file.

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

[0144] (3) Help module:

[0145] Users can check Help and Documentation for usage guides.

[0146] Users can contact technical support for assistance.

[0147] Fig.10 This is a flowchart of a user performing a reduction reconstruction in the workload reduction service. The contents of the flowchart are as follows:

[0148] Step 1: The user uploads the workload file in the workload reduction and reconstruction module of the workload service;

[0149] Step 2: The user selects the parameters of the narrowing down refactoring tool. The user can select the default parameters or the customized parameters.

[0150] Step 3: The user triggers the execution of the shrinking refactoring tool;

[0151] Step 4: The user gets the reduced workload file and effectiveness report;

[0152] Step 5: The user chooses whether to re-do the shrinking and reconstruction work. If yes, jump to Step 2. If 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 protection content of the present invention is not limited to the above embodiments. Without departing from the spirit and scope of the present invention, changes and advantages that can be thought of by those skilled in the art are included in the present invention and are protected by the attached claims.

Claims

1. A cross-platform workload reduction and reconstruction method, characterized in that: The method comprises the following steps: Step 1: for the workload to be reduced and reconstructed, run the workload to be reduced and reconstructed and perform workload sampling to obtain the workload key features as the sampling results; Step 2: Based on the workload sampling results obtained in step 1, construct an intermediate file structure; Step 3: For the intermediate file structure in step 2 that stores the key feature results of the workload, an executable file is constructed for each key simulation point in the workload, that is, the reconstructed workload is reduced.

2. The workload reduction and reconstruction method according to claim 1, characterized in that: In step one, the performance data of the workload is sampled through a dynamic binary instrumentation method to obtain one or more simulation points, and 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.

3. The workload reduction and reconstruction method according to claim 2, characterized in that: 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; Cluster workload slices with similar performance characteristics into clusters, namely workload slice sets. Each work unit contains one or more workload slice sets. In each workload slice set, a representative slice closest to the centroid of the cluster is selected as the key simulation point. The BBV records the execution frequency of the basic blocks in the slice and constitutes a simulation area of ​​the program. The sampling code is inserted into the simulation area to record the execution information of the thread. The end of each BBV is set as the entrance of the next work unit to align the work unit with the loop boundary.

4. The workload reduction and reconstruction method according to claim 3, characterized in that: The workload is divided into one or more work units, comprising 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, and the assembly code segments do not contain any control flow jump instructions except the last instruction; the edges of the DCFG are responsible for connecting two nodes; Step 2: Use dynamic stubs to connect the nodes of DCFG to form the entire DCFG graph; Step 3: After the DCFG graph is generated, the instruction stream of the program source code is marked to generate a work unit; and / or, The workload slicing clustering comprises the following steps: Step (1), using random linear projection to reduce the dimensionality of BBV data; Step (2), clustering low-dimensional data with k values ​​ranging from 1 to 10 using the k-means clustering algorithm; Step (3): For each cluster, the fit of the cluster is scored using the Bayesian Information Criterion.

5. The workload reduction and reconstruction method according to claim 1, characterized in that: In step 2, the intermediate file structure includes a Pinball structure, which stores the workload sampling results; the intermediate file structure includes the execution path, state transition and key event information of each thread of the multi-threaded program; the key event information includes register data, memory data, and instruction length.

6. The workload reduction and reconstruction method according to claim 1, characterized in that: In step 2, the intermediate file structure includes a program counter, register status, memory image, thread and call stack, timestamp and event record, dynamic control flow graph, loop boundary and loop region; 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 when the application is executed, and the register state includes general registers, floating point registers, and vector registers; the record of the register state provides context information of the application execution; The memory mirror refers to the memory access during the execution of the application, and the memory access includes the operation of reading and writing memory, and the corresponding memory address and data; The memory access records are used to analyze data dependencies and memory access patterns of the application; The thread and call stack refer to the thread information and call stack information when the application is executed; the thread information includes thread ID and thread state; the call stack information includes function call relationship, function parameters and return value; the thread information and call stack information are used to understand the concurrent behavior and execution path of the application; The timestamp is used to measure the execution time and performance of the application, and the event record marks key events in the application; The dynamic control flow graph DCFG is used to describe the control flow conversion relationship when the program is executed; the nodes in the DCFG represent the basic blocks in the program, and the edges represent the jump relationship between the basic blocks; the records of the DCFG help analyze the execution path and control flow behavior of the loop; The loop boundary marker refers to a 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 area refers to a code area determined according to the loop boundary marker, and the code area includes all iterations of a loop.

7. The workload reduction and reconstruction method according to claim 1, characterized in that: In step 3, each key simulation point corresponds to a representative area of ​​the source program, and the performance result of the key simulation point reflects the performance of the corresponding representative area; by testing the performance result of each key simulation point and weighting it with the instruction length of the representative area, the performance data of each work unit is obtained, and finally the performance result of the entire workload is inferred; The step three further comprises the following steps: Step 3.1, parsing the intermediate file: parsing the intermediate file to restore the execution track and status of the application; the intermediate file contains the execution status and instruction sequence of the application; Step 3.2, rebuilding the structure of the executable file: using the intermediate file parsed in step 3.1, rebuilding the structure of the original executable file and restoring the original form of the application; the reconstruction process includes restoring the code segment, data segment, symbol table, and relocation information; Step 3.3, relocate and repair symbols: perform relocation operations based on the relocation information in the intermediate file to ensure that instructions and data are in the correct memory location; Step 3.4: Link and build executable file: Link the recovered code segment and data segment together, process symbol references, and generate a reduced and reconstructed executable file.

8. The workload reduction and reconstruction method according to claim 7, characterized in that: Step three also includes: Step 3.5, program preheating: preheating by forwarding the slice from the intermediate file corresponding to the slice, and setting interrupts using the performance measurement tool to correctly measure the performance data of the slice itself; Step 3.6, reverse inferring the performance results: for each work unit in the work unit clusters of different clusters generated by clustering in the original program, select the BBV closest to the centroid of each cluster as the representative of the cluster as the key simulation point, and reverse infer the performance data of each work unit in the work unit cluster represented by the key simulation point by testing the performance data of the executable file composed of each key simulation point. Integrate all the work unit performance data obtained by reverse inference to obtain the performance data result of the original workload; Step 3.

7. Verify accuracy: Evaluate the behavioral differences between the reconstructed workload and the original workload.

9. A workload reduction and reconfiguration system for implementing the workload reduction and reconfiguration method according to any one of claims 1 to 8, characterized in that: The workload reduction and reconstruction system comprises: 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 out the key simulation points required for reduction and 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 the corresponding intermediate file for the key simulation points found, so as to facilitate the executable file generation module to synthesize the executable file; The executable file generation module is used to generate an executable file for the intermediate file and perform performance verification. If the performance verification is accurate, it means that the generated executable file is the workload after the reconstruction is reduced.

10. The workload reduction and reconstruction method as described in any one of claims 1 to 8, or the workload reduction and reconstruction system as described in claim 9, performs workload reduction and reconstruction for benchmark performance testing on platforms including AArch64 and X86 processor architectures, optimizes application load performance, uses an executable file to display the results of the reduction and reconstruction system, and is applied in workload reduction services.

Images