Software partitioning device and software partitioning method

Abstract

A software partitioning device (100) comprises: a static information analysis unit (130) that stores static count information for all files without executing an application program; a dynamic log analysis unit (160) that analyzes a log of an executed application program and stores dynamic count information; and an output unit (180) that, on the basis of static file partitioning information and dynamic file partitioning information, divides all files into a plurality of groups according to the closeness of call relationships and outputs the files.

Description

Software division device and software division method

[0001] The present invention relates to a software division device and a software division method.

[0002] With the advancement of AI (Artificial Intelligence), many applications are using servers equipped with heterogeneous hardware such as multi-core CPUs, GPUs (Graphics Processing Units), and FPGAs (Field Programmable Gate Arrays), in addition to CPUs (Central Processing Units) with a small number of cores. For example, Microsoft (registered trademark) is working on using FPGAs for search, and Amazon (registered trademark) is using cloud technology to provide FPGA and GPU instances.

[0003] However, to efficiently utilize heterogeneous hardware, it is necessary to create and configure programs that take into account the hardware characteristics, which is a high hurdle for most software engineers. For example, knowledge of OpenMP (Open Multi-Processing) is often required for multi-core CPUs, CUDA (Compute Unified Device Architecture) for GPUs, OpenCL (Open Computing Language) for FPGAs, and Assembly and IoTPF for IoT (Internet of Things) devices.

[0004] To make better use of heterogeneous hardware, a platform is needed that enables even ordinary software engineers without advanced knowledge to make the most of it.In the future, platforms will be required to automatically analyze software written by engineers using the same logic as a low-core CPU, convert and configure it appropriately for the environment in which it will be applied (GPU, FPGA, IoT device, etc.), and enable it to operate in an environment that is adapted to the environment.

[0005] Therefore, the inventors have proposed a concept of environment-adaptive software that automatically converts, sets resource allocation, and determines placement so that program code written once can be used on GPUs, FPGAs, etc. in the deployment environment. Furthermore, as an element of environment-adaptive software, a method has been proposed for automatically offloading normal program code to GPUs and FPGAs. Furthermore, to accommodate not only accelerators but also resource-limited IoT devices, the inventors have proposed an IoT adaptation method in which users specify the basic service, the code to be computed, and the IoT device, and common processes such as data transmission and storage are discovered and deployed on an IoT Gateway (Gateway) and IoT Platform (IoTPF) to create a service.

[0006] <Prior Art> There is a GPGPU (General Purpose GPU) that uses a GPU for general calculations. NVIDIA (registered trademark) provides CUDA (Compute Unified Device Architecture) as an environment for this. OpenCL is a specification that handles heterogeneous hardware such as FPGAs and GPUs in a common manner. OpenCL and CUDA are extended descriptions of the C language that describe the transfer of memory information between an FPGA or the like called the kernel and a CPU called the host, but require more hardware knowledge than the original C language.

[0007] The following efforts are being made to make it easy to use heterogeneous hardware such as GPUs, even if you do not understand the syntax of OpenCL or CUDA. Directives specify lines for GPU processing, and the compiler creates binary files for GPUs or multi-core CPUs based on the directives. Specifications such as OpenMP and OpenACC are also interpreted and executed using compilers such as gcc and PGI.

[0008] Even if heterogeneous hardware is available, improving performance is currently not easy. For example, there is a compiler called the Intel® Compiler that automatically distributes processing to multiple CPU cores. During automation, Intel compilers and others identify loops within a program that can be processed in parallel and have multiple cores process them. However, simply processing loops in parallel often does not improve performance due to data copying and other factors. When using GPUs or FPGAs rather than multi-core CPUs, the process is more complicated due to different memory types, and performance improvement requires manual tuning using OpenCL or CUDA. The inventor has proposed offloading using a genetic algorithm, an evolutionary computing method, as an effort to automate the search for GPU processing locations in loop statements.

[0009] <IoT Technology> IoT services, which do not use accelerators such as GPUs or FPGAs but rather have many devices with limited resources such as memory, are also examples of the use of heterogeneous hardware. The M2M platform oneM2M has been standardized as an IoT standard. MQTT (Message Queuing Telemetry Transport), which is lighter than HTTP, has been standardized as a protocol for IoT sensors. Many IoT services have been built in factories, agriculture, transportation, healthcare, and other fields. In most cases, sensing data from IoT sensors is aggregated by an IoT gateway (gateway) and sent to the cloud using protocols such as MQTT or HTTP. Common processing such as data aggregation and storage is performed by an IoT platform (platform) on the cloud, and necessary data processing is performed using custom programs or IoT platform functions, with the results displayed to users on a cloud server.

[0010] Non-Patent Document 1 examines environment adaptation. The technology in Non-Patent Document 1 targets the GPU for environment adaptation and is premised on the need for existing code.

[0011] Non-Patent Document 2 realizes an IoT adaptation method that searches for and combines common functions such as data storage and display to create an IoT service when a user specifies a basic service, user-specific processing, and IoT device. The technology in Non-Patent Document 2 is limited to IoT services as its target service.

[0012] Non-Patent Document 3 describes a technology for analyzing large-scale business applications and dividing and visualizing them by function. Non-Patent Document 3 targets large-scale business applications, which differs from small-scale IoT services. However, the aim of analyzing and dividing applications is similar to Non-Patent Document 2. The technology in Non-Patent Document 3 identifies the call destinations and writing programs of a program, weights the relationships, and performs clustering. Furthermore, if database access logs are available, it finds the range that should be executed as a series of processes and corrects the clustering results. It targets large-scale business applications such as ERP (Enterprise Resources Planning), and is characterized by the use of a large amount of information, such as database access logs, for division.

[0013] Y. Yamato, “Study and Evaluation of Improved Automatic GPU Offloading Method,” International Journal of Parallel, Emergent and Distributed Systems, Taylor and Francis, DOI: 10.1080 / 17445760.2021.1941010, June 2021.Y. Yamato, “A study for environmental adaptation of IoT devices,” 2023 Eleventh International Symposium on Computing and Networking Workshops (CANDARW 2023), pp. 14-19, Nov. 2023.M. Kamimura, K. Yano, T. Hatano and A. Matsuo, "Extracting Candidates of Microservices from Monolithic Application Code," 2018 25th Asia-Pacific Software Engineering Conference (APSEC), pp.571-580, 2018.

[0014] Non-Patent Document 1 targets environmental adaptation to GPUs and FPGAs, and does not consider IoT. Non-Patent Document 2 improves development efficiency using an IoT framework specialized for a development method called microservices. Generally, specialized knowledge is required for development when using IoTPF from a major cloud service provider. Even with an IoT framework, like development using IoTPF, there are effects such as increasing productivity, but specialized knowledge is required depending on the specialized method or target. Non-Patent Document 3 does not allow for dividing and adding functions even for small-scale applications that do not use a database or applications that do not require persistence, and is not suitable for using simple information for analysis.

[0015] Furthermore, Non-Patent Documents 1 and 2 use environment-adaptive software to automatically convert existing code and operate it appropriately. In this case, application changes are almost always based on the assumption that Open Source Software (OSS), whose source code is publicly available, is used to analyze existing code. Therefore, while conventionally, code analysis has allowed IoT GWs and IoT PFCs to be used in the right places, automatic construction is limited to IoT services, making it difficult to use general-purpose programs other than IoT services in the right places.

[0016] Furthermore, when users add or change their own processing to a general-purpose program, the impact of the changes often has a wide reach in applications with many lines of code, and there is a problem in that adding or changing something requires a lot of work to check whether it affects related functions.

[0017] The present invention has been made in view of the above points, and an object of the present invention is to make it possible to easily add functions to general-purpose programs.

[0018] In order to solve the above-mentioned problems, a software division device for dividing an application program includes a syntax analysis unit that performs syntax analysis on source code of the application program to be analyzed, a static information analysis unit that counts, for all files without running the application program, information on call relationships between functions obtained by the syntax analysis and information on associations indicating whether the functions are to be written to the same data, and stores the information as static count information, a static division information calculation unit that calculates static file division information based on the static count information counted by the static information analysis unit and a predetermined division logic, an application execution unit that executes the application program in accordance with sample test case information designated by a user, and a static information analysis unit that calculates static file division information based on the static count information counted by the static information analysis unit and a predetermined division logic ... The software division device is characterized by comprising: a dynamic log analysis unit that analyzes the log of the application program executed by the application execution unit, counts the call relationship information between functions obtained by the syntax analysis and the related information indicating whether the functions are written to the same data, and stores them as dynamic count information; a dynamic division information calculation unit that calculates dynamic file division information based on the dynamic count information counted by the dynamic log analysis unit and a predetermined division logic; and an output unit that divides all of the files into multiple groups based on the closeness of the call relationship based on the static file division information analyzed by the static division information calculation unit and the dynamic file division information analyzed by the dynamic division information calculation unit, and outputs the group.

[0019] According to the present invention, functions can be easily added to a general-purpose program.

[0020] FIG. 1 is a diagram showing an example of the configuration of a software dividing device according to an embodiment of the present invention. FIG. 2 is a diagram explaining an overall picture of environment adaptive software of the software dividing device according to an embodiment of the present invention. FIG. 3 is a flowchart showing the software division process of the software dividing device according to an embodiment of the present invention. FIG. 4 is a diagram explaining static analysis operations during automatic division of a general-purpose program by the software dividing device according to an embodiment of the present invention. FIG. 5 is a diagram explaining dynamic analysis operations during automatic division of a general-purpose program by the software dividing device according to an embodiment of the present invention. FIG. 6 is a diagram showing an evaluation environment for the software dividing device and software division method according to an embodiment of the present invention. FIG. 7 is a diagram showing, in a table, the number of divided groups, the number of lines in the group to which a new function is added to each application, and the number of lines in the entire application when automatically divided by the software dividing device according to an embodiment of the present invention. FIG. 8 is a hardware configuration diagram showing an example of a computer that realizes the functions of the software dividing device according to an embodiment of the present invention.

[0021] Next, a software dividing device and the like in an embodiment of the present invention (hereinafter referred to as the "present embodiment") will be described. In the following description of the specification, an example in which the present invention is applied to environment-adaptive software will be described. The present invention is generally applicable to application division for adding user functions. FIG. 1 is a diagram showing an example of the configuration of a software dividing device according to an embodiment of the present invention. As shown in FIG. 1, a network system 1 includes a PC (Personal Computer) 2 that executes software having application code 20, a LAN 3 (network), and a software dividing device 100 connected to the PC 2 via the LAN 3. A server (cloud), not shown, is connected to the network 3, for example, via the Internet 4.

[0022] [Software dividing device 100] The software dividing device 100 divides an application to the extent that a change will have an effect, based on static analysis results obtained by performing static analysis on information having a call relationship from a group of generic program codes, and dynamic analysis results obtained by actually executing the application in accordance with a sample test case specified by a user. The software dividing device 100 includes an input receiving unit 110, an application syntax analysis unit 120 (syntax analysis unit), an application static information analysis unit 130 (static information analysis unit), an application static division information calculation unit 140 (static division information calculation unit), an application execution unit 150, an application dynamic log analysis unit 160 (dynamic log analysis unit), an application dynamic division information calculation unit 170 (dynamic division information calculation unit), and an output unit 180.

[0023] The input receiving unit 110 receives input of the source code of the application to be analyzed and sample test case information designated by the user.

[0024] The application syntax analysis unit 120 (syntax analysis unit) parses source code to obtain information such as reference relationships. Parsing refers to analyzing the syntax of a document according to certain rules, and in the case of the C language, Clang is used, and in the case of Python, ast, etc. is used.

[0025] The application static information analysis unit 130 (static information analysis unit) counts, for all files without running the application program, information on the call relationships between functions obtained by syntax analysis and information on associations indicating whether the functions write to the same data, and stores the count information. The application static information analysis unit 130 counts, as count information, the call relationships between functions and the fact that certain functions write to the same data.

[0026] The application static division information calculation unit 140 (static division information calculation unit) calculates static file division information (file division information in static analysis) based on the static count information counted by the application static information analysis unit 130 and a predetermined division logic. The application static division information calculation unit 140 calculates static file division information such as grouping files that are called three or more times into the same group.

[0027] The application execution unit 150 executes the application in accordance with the sample test case information specified by the user.

[0028] The application dynamic log analysis unit 160 (dynamic log analysis unit) analyzes the log information of the application executed by the application execution unit 150. Specifically, the application dynamic log analysis unit 160 analyzes the log of the application program executed by the application execution unit 150, counts the call relationship information between functions obtained by syntax analysis and the related information indicating whether the functions write to the same data, and stores the count information as dynamic count information. For example, the application dynamic log analysis unit 160 counts the call relationships between functions and extracts database access logs and file access logs to discover data access instructions that are executed consecutively. In this case, the application dynamic log analysis unit 160 also finds the program range that is executed as a series of processes, etc.

[0029] In addition, the application dynamic log analysis unit 160 analyzes the log, extracts data access commands that are being executed continuously, obtains the program range that is being executed as a series of processes, and passes it to the application dynamic division information calculation unit 170.

[0030] The application dynamic division information calculation unit 170 (dynamic division information calculation unit) calculates dynamic file division information (file division information in dynamic analysis) based on the dynamic count information counted by the application dynamic log analysis unit 160 and a predetermined division logic. The application dynamic division information calculation unit 170 calculates dynamic file division information such as grouping files that have been called even once into the same group.

[0031] Furthermore, the application dynamic division information calculation unit 170 calculates dynamic file division information based on the program range acquired by the application dynamic log analysis unit 160 .

[0032] The output unit 180 groups and displays files based on the static file division information and the dynamic file division information. Specifically, the output unit 180 outputs all files into multiple groups based on the density of call relationships based on the static file division information analyzed by the application static division information calculation unit 140 and the dynamic file division information analyzed by the application dynamic division information calculation unit 170. As the groups divided by the density of call relationships, the output unit 180 groups files that are called at least once as a result of dynamic analysis into groups of files with functions with high density. As a result of static analysis, files that are called three or more times are grouped into groups of files with functions with high density, and files that are called two or less times are left as files with functions with low density. Note that the output by the output unit 180 is not limited to display, and can include printouts and distribution of output information over a network, etc.

[0033] The environment adaptation operation of the software dividing apparatus 100 configured as described above will now be described.

[0034] [Environment Adaptive Operation] The software dividing device 100 of this embodiment is an example in which the environment adaptive processing of user application logic is applied as a component technology of environment adaptive software. FIG. 2 is a diagram illustrating an overall view of the environment adaptive software of the software dividing device 100. Note that the environment adaptive processing of the software dividing device 100 shown in FIG. 2 is the same before operation starts and when reconfigured after operation starts. However, the difference is that the data handled before operation starts is expected usage data, whereas the data handled after operation starts is data actually used commercially (commercial representative data). The server 101 shown in FIG. 2 is a device that executes the environment adaptive software processing of the software dividing device 100. The server 101 can also be connected to an emulator.

[0035] As shown in FIG. 2, the server 101 includes the software dividing apparatus 100, an input / output unit 220, a storage unit 230, and a verification machine 10.

[0036] The input / output unit 220 is composed of a communication interface for sending and receiving information between various devices, etc., and an input / output interface for sending and receiving information between input devices such as a touch panel and a keyboard, and output devices such as a monitor.

[0037] The storage unit 230 is configured with a hard disk, flash memory, RAM (Random Access Memory), etc. The storage unit 230 stores a code pattern DB 231, an equipment resource DB 232, and a test case DB (Test Case Database) 233, and also temporarily stores programs for executing the functions of the control unit and information required for processing by the control unit (for example, an intermediate language file 234).

[0038] The code pattern DB 231 accumulates code patterns used when the server 101 analyzes source code for application processing functions. The equipment resource DB 232 stores pre-prepared information such as the prices and resources of servers and other resources held by businesses, as well as information on the extent to which they are being used. The test case DB 233 stores performance test items. The test case DB 233 stores information for conducting tests to measure the performance of applications that are being accelerated. For example, in the case of a deep learning application for image analysis processing, the information stored would be sample images and test items for executing them. The code pattern DB 231, equipment resource DB 232, and test case DB 233 are platform functions used when the server 101 executes environment-adaptive software processing.

[0039] The verification machine 10 includes a CPU, a GPU, an FPGA (accelerator), and an IoT Gateway (IoT Gateway) as a verification environment for the environment-adaptive software. Although the server 101 is shown in FIG. 2 as including the verification machine 10, the verification machine 10 may be located outside the server 101.

[0040] The software dividing apparatus 100 is a control unit that is responsible for overall control. The software dividing apparatus 100 is realized, for example, by a CPU (not shown) expanding a program stored in the storage unit 230 into a RAM and executing the program.

[0041] 2, the server 101 is applied to the elemental technologies of the environment-adaptive software. The server 101 has a software dividing apparatus 100 that executes environment-adaptive software processing, a code pattern DB 231, an equipment resource DB 232, a test case DB 233, an intermediate language file 234, and a verification machine 10.

[0042] The software dividing apparatus 100 acquires application code 20 used by a user. The user uses a commercial environment (application environment) 240. The commercial environment (application environment) 240 uses, for example, an IoT GW 241, a device having a CPU-GPU 242, a device having a CPU-FPGA 243, and a device having a CPU 244 as various devices. The server 101 can automatically offload functional processing to accelerators in the device having a CPU-GPU 242 and the device having a CPU-FPGA 243.

[0043] The software division device 100 executes environment-adaptive software processing based on the environment-adaptive functions of the commercial environment and verification environment provided by the business operator, and further integrates platform functions consisting of a code pattern DB 231, an equipment resource DB 232, and a test case DB 233.

[0044] Below, the operation of each part before operation starts will be explained with reference to the step numbers in Figure 2. As heterogeneous hardware, offloading to accelerators such as GPUs, FPGAs, and multi-core CPUs will be explained. [Offloading to accelerators] First, code conversion, adjustment of resource amounts, adjustment of placement locations, and verification, which are necessary before the application can be started, are performed.

[0045] <Step S11: Specify application code> In step S11, the processing function (image analysis, etc.) of the service provided to the user is specified. Specifically, the control unit (software dividing apparatus 100) specifies the input application code 20.

[0046] <Step S12: Analyze application code> In step S12, the control unit analyzes the source code of the processing function and understands the structure of loop statements, FFT library calls, and the like.

[0047] <Step S21: Extract offloadable area> In step S21, the control unit identifies loop statements (repeated statements) of the application, specifies parallel processing or pipeline processing in the FPGA for each repetitive statement, and compiles it using a high-level synthesis tool.

[0048] <Step S22: Output intermediate file> In step S22, the control unit outputs the intermediate language file 234. The intermediate language extraction is not completed once and is repeated to try and optimize the execution for searching for an appropriate offload area.

[0049] <Step S23: Compile error: Create PLD processing pattern> In step S23, the control unit creates a PLD processing pattern that excludes loop statements that result in a compilation error from being offloaded, and specifies whether or not to perform FPGA processing on repetitive statements that do not result in a compilation error.

[0050] As indicated by the symbol aa in FIG. 2, the control unit repeatedly executes steps S12 to S23.

[0051] <Step S31: Deploy binary files: Deploying executable files> In step S31, the control unit deploys executable files derived from the intermediate language to the FPGA-equipped verification machine 10. The deployed files are started, and assumed test cases are executed to measure the offloaded performance.

[0052] <Step S32: Measure performance: Measure performance for appropriate pattern search> In step S32, the control unit executes the arranged file and measures the performance when offloaded.

[0053] <Step S41: Determining Resource Size> The control unit determines the resource size (see symbol bb in FIG. 2).

[0054] <Step S51: Selection of an appropriate installation location> The control unit refers to the facility resource DB 232 and selects an appropriate installation location.

[0055] <Step S61: Deploy final binary files to production environment: Deploying final files to a commercial environment> In step S61, the control unit determines a pattern specifying a final offload area, and deploys it to a production environment for the user.

[0056] <Step S62: Extract performance test cases and run automatically: Extract test cases and check normality> In step S62, after placing the executable file, the control unit extracts performance test items from the test case DB 233 and automatically runs the extracted performance tests to show the performance to the user.

[0057] <Step S63: Provide price and performance to a user to judge: Present price and performance to a user to judge whether to start using the service> In step S63, the control unit presents information such as price and performance based on the performance test results to the user. The user can then decide whether to charge for the service and whether to start using it based on the presented information such as price and performance.

[0058] The above steps S11 to S63 are assumed to be performed in the background while the user is using the service, for example, during the first day of trial use. In addition, to reduce costs, the background processing may be limited to GPU / FPGA offloading.

[0059] In this way, steps S11 to S63 analyze the code, convert the code according to the deployment environment, adjust the amount of resources, adjust the deployment location, and perform verification in a series of processes before starting operation of the application. Then, step S71 analyzes the actual usage characteristics over a long period of time after the application has started to be used, and performs the necessary reconfiguration.

[0060] We have described automatic offloading of accelerators such as GPUs, FPGAs, and multi-core CPUs as heterogeneous hardware. Next, we will discuss automatic partitioning of general-purpose programs.

[0061] [Easy to add and modify services] The inventor has proposed environment-adaptive software that automatically converts existing code to suit the environment and allows it to operate appropriately. However, conversions almost always require the use of OSS or similar software to analyze existing code. Therefore, we have made it possible to easily add functions to general-purpose programs. This will greatly increase the scope of environment-adaptive programs, such as programs in which users add their own functions to OSS or similar software.

[0062] Consider adding or modifying a user-defined process to a general-purpose program. For applications with a considerable number of lines of code, the impact of the changes often extends over a wide area, requiring significant work to check whether the changes affect related functions. This invention simplifies service addition and modification by dividing the application based on the related processes and localizing the changes based on the division boundaries.

[0063] [Details of software partitioning method] <Summary> There are two methods for analyzing applications: static analysis and dynamic analysis. Static analysis is an analytical method that looks at relationships such as function calls and writes in source code without actually running the application. Static analysis first makes it possible to understand the call relationships between functions. Next, it can also determine whether a function writes to the same data. Generally, functions that have a call relationship, or functions that write to and use the same data, are closely related, so they need to be grouped when partitioning. However, static analysis, which does not run the application, also analyzes cases that are not actually used by the user.

[0064] On the other hand, dynamic analysis is an analysis technique in which an application is actually run using sample test cases and information such as execution logs is viewed. With dynamic analysis, even when it comes to the call relationships between functions, it is possible to extract the call relationships between functions actually used in the sample test cases specified by the user. Furthermore, in the case of applications that use a database (DB), it is possible to extract DB access logs to discover data access commands that are executed consecutively and find the program range that is executed as a series of processes. Even in the case of file access rather than DB access, it is possible to find the program range that is executed as a series of processes from file access logs. However, the number of test cases that are actually run in dynamic analysis depends on the number of samples.

[0065] The environment-adaptive software shown in FIG. 2 has been described as an example of performing automatic GPU offloading. However, in such environment-adaptive software, while static analysis can determine whether computation can be performed on a GPU, the performance of GPU processing typically cannot be determined without actually measuring it using dynamic analysis. Dynamic analysis is an important element for providing unique support for each individual user, as it involves actually running sample test cases used by the user to measure performance. Therefore, the software dividing apparatus 100 of this embodiment performs automatic division of a general-purpose program by combining static and dynamic analysis to support individual users.

[0066] [Software Division Processing] Fig. 3 is a flowchart showing the software division processing of the software dividing apparatus 100. Figs. 4 and 5 are diagrams explaining the analysis operation during automatic division of a general-purpose program. Fig. 4 shows all files except the main function in the static analysis operation, and Fig. 5 shows the logs and data generated by sample test case execution in the dynamic analysis operation. In step S1 of Fig. 3, the input receiving unit 110 receives input of the source code of the application to be analyzed and sample test case information specified by the user.

[0067] In step S2, the application syntax analysis unit 120 parses the source code to obtain information such as reference relationships. The application syntax analysis unit 120 performs syntax analysis using Clang in the case of the C language, and ast in the case of Python.

[0068] In step S3, the application static information analysis unit 130 counts, for all files without running the application program, the call relationship information between functions obtained by syntax analysis and the association information indicating whether the functions write to the same data, and stores the count information. Here, the application static information analysis unit 130 counts the call relationship between functions and the fact that a certain function writes to the same data as the count information.

[0069] In step S4, the application static division information calculation unit 140 calculates static file division information (file division information in static analysis) based on the static count information counted by the application static information analysis unit 130 and a predetermined division logic. For example, the application static division information calculation unit 140 may group files that are called three or more times into the same group.

[0070] As shown in Figure 4, assume that functions a1, a2, a3, ... are defined in file 301 (file A), and functions b1, b2, b3, ... are defined in file 302 (file B). In static analysis, when function a1, which is called from the Main function, calls function b2 (arrow aa in Figure 4), and there is a response (arrow bb in Figure 4), AB is incremented by one. This is then counted for all files (here, file 303 (file N)). As a result, the analysis results are AB: 20, AC: 30, BA: 10, etc.

[0071] Returning to the flow of FIG. 3, in step S5, the application execution unit 150 executes the application in accordance with the sample test case information specified by the user.

[0072] In step S6, the application dynamic log analysis unit 160 analyzes the log information of the executed application. For example, the application dynamic log analysis unit 160 counts function call relationships, extracts database access logs and file access logs, and finds data access commands that are executed consecutively. In this case, the application dynamic log analysis unit 160 also finds the program range that is executed as a series of processes.

[0073] In step S7, the application dynamic division information calculation unit 170 calculates dynamic file division information (file division information in dynamic analysis) based on the dynamic count information counted by the application dynamic log analysis unit 160 and a predetermined division logic. The application dynamic division information calculation unit 170 may, for example, group files that have been called even once into the same group.

[0074] As shown in Figure 5, assume there are log and data files 401 and 402 generated by the execution of a sample test case. In dynamic analysis, after a certain number of sample tests have been executed, if function a1 called from the Main function calls b2, for example, 10 times (arrow cc in Figure 5), and a response is received (arrow dd in Figure 5), AB is incremented by 10. This is counted for the number of sample tests executed. As a result, the analysis results may be AB: 10, AC: 20, etc. First, static analysis and dynamic analysis operate independently and are processed without any correlation, resulting in separate outputs for static analysis and dynamic analysis. The division logic in dynamic analysis is to group files that have been called at least once in the same group. All files that have been called zero times are left in the same group. The division logic in static analysis is to group files that have been called three or more times in the same group. All files that have been called two or fewer times in the same group are left in the same group.

[0075] For example, if the total number of files is A, B, C, D, E, F, G, H, and I, and the call relationships C → B, B → A, E → D, and G → F are found once in dynamic analysis, then A, B, and C will be in group i, D and E will be in group ii, F and G will be in group iii, and H and I will be in group iv. This is the result for dynamic analysis. On the other hand, if the static analysis results in the call relationships B → A and E → D being found three or more times, and the others being found two or less times, then A and B will be in group i, D and E will be in group ii, and C, F, G, H, and I will be in group iii. This is the result for static analysis. As you can see, the results of static analysis and dynamic analysis can sometimes differ.

[0076] In this way, by dividing the output into multiple groups based on the density of the call relationships, files that have call relationships in the sample test cases specified by the user in dynamic analysis will always be in the same group. Also, when all files are analyzed in static analysis, files that have a certain number of call relationships (three or more) will also be in the same group. All files with stand-alone functions that are not closely related to other functions will be grouped together in the remaining group.

[0077] Returning to the flow of FIG. 3 , in step S8, the output unit 180 divides all files into multiple groups based on the depth of the call relationships based on the static file division information analyzed by the application static division information calculation unit 140 and the dynamic file division information analyzed by the application dynamic division information calculation unit 170, and outputs the divided files, thereby completing the processing of this flow. As a result of the dynamic analysis, the output unit 180 divides files that are called at least once into groups of files with functions that have a high degree of closeness, as groups to be divided into groups based on the closeness of the call relationships. As a result of the static analysis, the output unit 180 divides files that are called three or more times into groups of files with functions that have a high degree of closeness, and leaves files that are called two or less times as groups of files with functions that have a low degree of closeness. In this way, the output unit 180 divides all files into multiple groups based on the closeness of the call relationships and outputs the divided files.

[0078] [Implementation] The target of verification for automatic division is a C language application, and Clang is used for C language analysis. GDB (GNU Debugger) is used for debugging, such as program tracing. The implementation for analyzing C language applications is done in Python3. The implementation receives source code files and sample test case information as input, and outputs group information for static analysis and group information for dynamic analysis. The group information consists of divided groups and the files belonging to them, in the form of i (A, B, C) above and ii (D, E) above. The set number of times the sample test cases are executed is set to 10.

[0079] [Evaluation] We confirm that the software dividing device 100 of this embodiment can automatically divide a sample application and that this automatic division reduces the scope of checking the impact of changes when a user adds a function, by checking the number of lines of program code.

[0080] <Evaluation targets and evaluation methods> The evaluation targets will be the Himeno benchmark for fluid calculations, NAS.FT for Fourier transforms, and Darknet, a deep learning framework, which have been frequently used to verify environmental adaptation in C language applications. The Himeno benchmark is benchmark software used to measure the performance of incompressible fluid analysis, and solves the Poisson equation using the Jacobi iteration method. The Himeno benchmark is frequently used for manual acceleration on GPUs. In the sample test case, sample tests will be performed using data with a data size of LARGE (512*256*256). Fourier transform processing is also used in various monitoring situations, such as analyzing vibration frequencies.

[0081] NAS.FT is an open-source application for FFT processing. Considering an application that transfers sensor data over a network, to reduce network costs, the desired FFT processing is performed on the edge device in advance and only the results are sent. The sample test case used was the one included with NAS.FT, with a grid size of 256 x 256 x 128 and six iterations.

[0082] Darknet is a neural network framework written in C. Darknet is based on image processing, but can also perform various other processes such as classification and detection. Darknet is equipped with object detection and image processing functions, to which users can add their own functions. The sample test case uses a detection function called "detection," which is a sample process built into Darknet, and an image processing function called "nightmare."

[0083] All three applications, Himeno Benchmark, NAS.FT, and Darknet, are applications to which users are expected to add their own unique functions. These applications are used to confirm the automatic segmentation in this embodiment. In the automatic segmentation of this embodiment, the application code files and sample test case information are input into the tool implemented according to the above [Implementation]. After input, an analysis is performed, and the segmentation groups for the three applications in the case of static analysis and dynamic analysis are displayed (step S8 in Figure 3). This allows the total number of lines in the original application and the number of lines in the segmented applications to be counted and compared.

[0084] <Evaluation Environment> FIG. 6 illustrates an evaluation environment for the software division device and software division method, and is an example of application to the environment-adaptive software of FIG. 2. The upper diagram of FIG. 6 shows a verification machine 10 and a client 30 connected via a LAN 3, and the lower diagram of FIG. 6 shows detailed specifications of the verification machine 10 and the client 30. The verification machine 10 implements an environment-adaptive function 10a by executing environment-adaptive software stored in the RAN via a hardware CPU. The CPU also offloads specific processing to the accelerator's GPU and receives calculation results from the GPU. The client 30 sends a general-purpose program file 30a (including application source code, sample test case information specified by the user, and log and data files generated by sample test case execution) to the verification machine 10 and receives results from the verification machine 10.

[0085] The software dividing apparatus 100 of this embodiment performs static and dynamic analysis of a group of general-purpose program codes and divides them based on information on call relationships, but does not speed up the environment adaptation process. In this respect, it can be said that the tool can be run on any machine, but since static and dynamic analyses take a long time, it must run on a machine with sufficient specifications.

[0086] <Results and Discussion> Figure 7 shows the number of divided groups, the number of lines in the group to which new functions are added, and the total number of lines in the entire application after automatic division for the three applications mentioned above. Here, if the number of divided groups differs between static analysis and dynamic analysis, the division is made to create smaller groups. For example, if all files are A, B, C, D, E, F, and G, and the static analysis divides the files into AB, CDEFG and the dynamic analysis divides the files into ABCDE and FG, the files are divided into AB, CDE, and FG. As shown in Figure 7, the Himeno benchmark was not divided (Divided group # "1"), and the new function addition group had 166 lines (target group code # "166") compared to the total of 166 lines (total code # "166").

[0087] NAS.FT is divided into six parts (Divided group #6), with a total of 1,547 lines (total code #1,547) and 723 lines (target group code #723) for the new feature addition group. Darknet is divided into six parts (Divided group #6), with a total of 24,834 lines (total code #24,834) and 2,366 lines (target group code #2,366) for the new feature addition group.

[0088] Although the Himeno benchmark was not split due to its small size, NAS.FT and Darknet were automatically split effectively. This reduces the scope of checks when users add their own processing, making it easier to add and change functions.

[0089] Considering the cost. The Himeno benchmark was small and could not be split, but the number of lines to be checked when adding a feature to NAS.FT was reduced to less than half, and to less than one-tenth for Darknet. By reducing the number of lines to be checked when adding a feature, the workload for impact confirmation is reduced, and modification costs can be reduced.

[0090] [Hardware Configuration] The software dividing apparatus 100 according to this embodiment is realized by a computer 900 having a configuration as shown in Fig. 8, for example. The verification machine 10 shown in Fig. 2 is located outside the software dividing apparatus 100. Fig. 8 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the software dividing apparatus 100. The computer 900 has a CPU 910, a RAM 920, a ROM 930, a HDD 940, a communication interface (I / F) 950, an input / output interface (I / F) 960, and a media interface (I / F) 970.

[0091] The CPU 910 operates and controls each unit based on programs stored in the ROM 930 or the HDD 940. The ROM 930 stores a boot program executed by the CPU 910 when the computer 900 starts up, programs that depend on the hardware of the computer 900, and the like.

[0092] The HDD 940 stores programs executed by the CPU 910, data used by such programs, etc. The communication interface 950 receives data from other devices via the communication network 80 and sends it to the CPU 910, and transmits data generated by the CPU 910 to other devices via the communication network 80.

[0093] The CPU 910 controls output devices such as a display and a printer, and input devices such as a keyboard and a mouse, via the input / output interface 960. The CPU 910 acquires data from the input devices via the input / output interface 960. The CPU 910 also outputs generated data to the output devices via the input / output interface 960.

[0094] The media interface 970 reads a program or data stored in the recording medium 980 and provides it to the CPU 910 via the RAM 920. The CPU 910 loads the program or data from the recording medium 980 onto the RAM 920 via the media interface 970 and executes the loaded program. The recording medium 980 is, for example, an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical Disc), a tape medium, a magnetic recording medium, or a semiconductor memory.

[0095] For example, when a computer 900 functions as the software dividing apparatus 100 according to this embodiment, a CPU 910 of the computer 900 executes programs loaded onto a RAM 920 to realize the functions of each unit of the software dividing apparatus 100. Furthermore, a HDD 940 stores data for each unit of the software dividing apparatus 100. The CPU 910 of the computer 900 reads and executes these programs from a recording medium 980, but as another example, these programs may be acquired from another device via a communication network 80.

[0096] [Effects] As described above, the software dividing apparatus 100 (FIG. 1) according to this embodiment is a software dividing apparatus 100 for dividing an application program, and includes an application syntax analysis unit 120 for analyzing the syntax of the source code of the application program to be analyzed, an application static information analysis unit 130 for counting, for all files without running the application program, information on call relationships between functions obtained by the syntax analysis and information on associations indicating whether the functions are to be written to the same data, and storing the information as static count information, an application static division information calculation unit 140 for calculating static file division information based on the static count information counted by the application static information analysis unit 130 and a predetermined division logic, and an application static division information calculation unit 140 for dividing the application program according to sample test case information designated by a user. the application dynamic log analysis unit 160 that analyzes the log of the application program executed by the application execution unit 150, counts the call relationship information between functions obtained by syntax analysis and the related information indicating whether the functions are written to the same data, and stores the counted information as dynamic count information; the application dynamic division information calculation unit 170 that calculates dynamic file division information based on the dynamic count information counted by the application dynamic log analysis unit 160 and a predetermined division logic; and the output unit 180 that divides all files into a plurality of groups according to the density of the call relationships based on the static file division information analyzed by the application static division information calculation unit 140 and the dynamic file division information analyzed by the application dynamic division information calculation unit 170, and outputs the grouped files.

[0097] Non-Patent Documents 1 and 2 describe automatic GPU offloading, etc. While static analysis can determine whether a computation can be performed on a GPU, the performance of GPU processing typically cannot be determined without actual measurements. On the other hand, when a user adds or modifies a unique process that the user wants to perform to a general-purpose program, the impact of the change often extends over a wide area in applications with many lines of code, and the addition or modification requires a significant amount of work to check whether the related functions are affected.

[0098] In this embodiment, an application is divided by related processes and changes are localized based on the division boundaries, thereby facilitating the addition and modification of services. Specifically, the software dividing device 100 divides the application within the scope of the impact of the change based on the static analysis results obtained by performing static analysis based on information with call relationships from a group of generic program code and the dynamic analysis results obtained by actually running the application according to sample test cases specified by the user. The division results, which are the combination of static analysis and dynamic analysis, are then output, divided into multiple groups according to the density of the call relationships.

[0099] By limiting the impact of application additions and changes to the split range, users can reduce the amount of checking to see if the changes affect related functions when adding or changing an application, making it easier for users to add functions. For example, as shown in Figure 7, comparing the number of lines in the split files with the original files makes it clear that the number of lines to be checked when adding a function is reduced to 1 / 2 to 1 / 10 or less. By reducing the number of lines to be checked when adding a function, the range of change impact checks required when adding a desired process is reduced. This reduces the amount of work required to check the impact, thereby reducing modification costs.

[0100] As a result, not only does it become easier for users to create programs with their own unique functions, but the prerequisites for using OSS and other programs are relaxed, greatly increasing the scope of applications for general-purpose programs and environmental adaptation. By automatically dividing general-purpose programs and facilitating the addition of functions, it is now possible to first customize an application by adding functions for one's own use, and then offload the application to an accelerator such as a GPU or FPGA. This increases the scope of environmental adaptation and greatly improves convenience.

[0101] In the software division device 100 (Figure 1) of this embodiment, the application dynamic log analysis unit 160 analyzes the log, extracts data access commands that are being executed continuously, and obtains the program range that is being executed as a series of processes, and the application dynamic division information calculation unit 170 calculates dynamic file division information based on the program range.

[0102] By doing this, we can understand the call relationships between files containing functions through analysis in both static states where the program is not running and dynamic states where it is running, and output a division of unrelated file groups. The analysis itself uses function call relationships, and we have confirmed that this is sufficient for division. In particular, by calculating dynamic file division information based on the program range, more detailed analysis is possible using additional information such as writing to the same data, database and file access logs, and continuous execution.

[0103] In the software dividing device 100 (FIG. 1) according to this embodiment, static analysis and dynamic analysis operate independently and are processed without any correlation, with the divided groups in the case of static analysis and the divided groups in the case of dynamic analysis being separate outputs. The division logic in dynamic analysis places files that have been called at least once in the same group as a result of the dynamic analysis. All files that have been called zero times are left in the same group. The division logic in static analysis places files that have been called three or more times in the same group as a result of the static analysis. All files that have been called two or fewer times in the same group as a result of the static analysis.

[0104] That is, the software dividing apparatus 100 divides files into groups based on the density of the call relationships as follows: As a result of dynamic analysis, files that are called at least once are grouped together with files of functions with high density, and other files are left as they are; as a result of static analysis, files that are called three or more times are grouped together with files of functions with high density, and files that are called two or less times are grouped together with files of functions with low density, and other files are left as they are;

[0105] This reduces the scope of the impact of changes that must be confirmed when adding desired processing. It also makes it possible to customize an application by adding functions for one's own use, and then offload the changes to an accelerator such as a GPU or FPGA.

[0106] In the software dividing device 100 (FIG. 1) according to this embodiment, the output unit 180 divides the files into groups based on the density of the call relationships. As a result of the dynamic analysis, files that are called even once are grouped together as files of functions with a high density of calls, and files that are not called as a result of the dynamic analysis are left as files of functions with a low density of calls and grouped together.

[0107] By doing this, the results of dynamic analysis can be used to narrow the scope of the impact of changes when adding desired processing. Dynamic analysis can also extract the call relationships between functions, even for functions that are actually used in sample test cases specified by the user. This makes it possible to first customize an application by adding custom functions, and then offload the work to an accelerator such as a GPU or FPGA.

[0108] In the software dividing device 100 (FIG. 1) according to this embodiment, the output unit 18 divides the files into groups based on the density of the call relationships. As a result of the static analysis, files that are called three or more times are grouped together as files of functions with a high density of calls, and files that are called two or less times are grouped together as files of functions with a low density of calls.

[0109] By doing this, the results of static analysis can be used to narrow the scope of the impact of changes when adding desired processing. Static analysis allows you to understand the relationships between source code function calls and writes without actually running the application. It is also possible to first customize an application by adding your own functions, and then offload the results to an accelerator such as a GPU or FPGA.

[0110] The present invention is not limited to the above-described embodiments, and includes other modifications and applications without departing from the spirit of the present invention as defined in the claims. Furthermore, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0111] In addition, in the above embodiment, the names software division device and software division method are used, but this is for convenience of explanation, and the name of the device may also be application division device, general-purpose program automatic division device, etc., and the name of the method may also be general-purpose program division method, etc.

[0112] The software division process described above can also be realized by a program for executing this software division process, which program is stored on a computer-readable recording medium.

[0113] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. Furthermore, the above-described configurations, functions, etc. may be implemented by software that causes a processor to interpret and execute programs that implement the respective functions. Information such as programs, tables, and files that implement the respective functions may be stored in a memory, a recording device such as a hard disk or a solid-state drive (SSD), or a recording medium such as an integrated circuit (IC) card, a secure digital (SD) card, or an optical disk. Furthermore, in this specification, processing steps describing chronological processing include not only processing performed chronologically in the order described, but also processing that is not necessarily performed chronologically but is performed in parallel or individually (e.g., parallel processing or object processing).

[0114] DESCRIPTION OF SYMBOLS 1 Network system 2 PC 3 LAN (network) 10 Verification machine 20 Application code 30a Program file 100 Software division device 101 Server 110 Input reception unit 120 Application syntax analysis unit (syntax analysis unit) 130 Application static information analysis unit (static information analysis unit) 140 Application static division information calculation unit (static division information calculation unit) 150 Application execution unit 160 Application dynamic log analysis unit (dynamic log analysis unit) 170 Application dynamic division information calculation unit (dynamic division information calculation unit) 180 Output unit 220 Input / output unit 230 Storage unit 231 Code pattern DB 232 Equipment resource DB 233 Test case DB 234 Intermediate language file 240 Commercial environment 241 Device having CPU-GPU 242 Device having CPU-FPGA 243 Device having CPU Files 301 to 303, 401, and 402

Claims

1. A software division device for dividing an application program, comprising: a syntax analysis unit that performs syntax analysis on the source code of the application program to be analyzed; a static information analysis unit that counts, for all files without running the application program, information on the call relationships between functions obtained by the syntax analysis and information on the association of functions that are to be written to the same data, and stores the information as static count information; a static division information calculation unit that calculates static file division information based on the static count information counted by the static information analysis unit and a predetermined division logic; an application execution unit that executes the application program in accordance with sample test case information specified by a user; a dynamic log analysis unit that analyzes the log of the application program executed by the application execution unit, counts information on the call relationships between functions obtained by the syntax analysis and information on the association of functions that are to be written to the same data, and stores the information as dynamic count information; and a dynamic division information calculation unit that calculates dynamic file division information based on the dynamic count information counted by the dynamic log analysis unit and a predetermined division logic. and an output unit that divides all of the files into a plurality of groups based on the density of call relationships, based on the static file division information analyzed by the static division information calculation unit and the dynamic file division information analyzed by the dynamic division information calculation unit, and outputs the groups.

2. The software division device described in claim 1, characterized in that the dynamic log analysis unit analyzes the log, extracts data access commands that are executed continuously, and obtains the program range that is executed as a series of processes, and the dynamic division information calculation unit calculates the dynamic file division information based on the program range.

3. The software division device according to claim 1, characterized in that the output unit divides the groups into groups based on the closeness of the call relationships by: grouping files that are called even once as files of functions with a high degree of closeness as a result of the dynamic analysis, and grouping files that are not called as files of functions with a low degree of closeness as a result of the dynamic analysis.

4. The software division device according to claim 1, characterized in that the output unit divides the groups into groups based on the density of the call relationships by: grouping files that are called three or more times as a result of static analysis as files of functions with a high density of calls, and grouping files that are called two or less times as files of functions with a low density of calls.

5. A software division method for a software division device that divides an application program, comprising: a syntax analysis step of syntactically analyzing source code of the application program to be analyzed; a static information analysis step of counting, for all files without running the application program, information on call relationships between functions obtained by the syntax analysis and information on associations indicating whether the functions are to be written to the same data, and storing the counted information as static count information; a static division information calculation step of calculating static file division information based on the static count information counted in the static information analysis step and a predetermined division logic; an execution step of executing the application program in accordance with sample test case information specified by a user; a dynamic log analysis step of analyzing a log of the application program executed in the execution step, counting information on call relationships between functions obtained by the syntax analysis and information on associations indicating whether the functions are to be written to the same data, and storing the counted information as dynamic count information; and a dynamic division information calculation step of calculating dynamic file division information based on the dynamic count information counted in the dynamic log analysis step and a predetermined division logic. an output step of dividing all of the files into a plurality of groups based on the density of call relationships, based on the static file division information analyzed in the static division information calculation step and the dynamic file division information analyzed in the dynamic division information calculation step, and outputting the groups.

Images