Offload server, offload control method, and offload program

Abstract

An offload server (1) is provided with: a parallel processing pattern creation unit (117) that creates a parallel processing pattern for excluding loop statements that generate compile errors from being offloaded, and specifying whether or not to perform parallel processing on loop statements that do not generate compile errors; a performance measurement unit (118) that compiles application programs for the parallel processing pattern, allocates the compiled application programs to an accelerator verification device, and performs performance measurement processing when the offload to the accelerator is implemented; and an allocation reconfiguration unit (180) that reconfigures the allocation locations of a group of application programs, the allocation of which has been requested by a plurality of users who request the allocation of applications that is to be reconfigured, according to a linear programming formula for reconfiguration of set allocated application programs.

Description

[Technical Field]

[0001] The present invention relates to an offload server, an offload control method, and an offload program that automatically offloads functional processing to accelerators such as GPUs (Graphics Processing Units) and FPGAs (Field Programmable Gate Arrays) and places the converted application programs (hereinafter referred to as applications as appropriate) in appropriate locations. [Background technology]

[0002] The use of heterogeneous computing resources other than CPUs (Central Processing Units) is increasing. For example, image processing is being performed on servers equipped with GPUs (accelerators), and signal processing is being accelerated using FPGAs (accelerators). FPGAs are programmable gate arrays that can be configured by designers after manufacturing, and are a type of PLD (Programmable Logic Device). Amazon Web Services (AWS) (registered trademark) offers GPU instances and FPGA instances, and these resources can be used on demand. Microsoft (registered trademark) is using FPGAs to make searches more efficient.

[0003] Using service integration technologies, it is expected that a wide variety of applications will be created, and by utilizing more advanced hardware, it is also expected that the performance of running applications will increase. However, this requires programming and configuration tailored to the hardware on which they will be running. For example, knowledge of many technologies such as CUDA (Compute Unified Device Architecture) and OpenCL (Open Computing Language) is required, which is a high hurdle. OpenCL is an open API (Application Programming Interface) that allows all computing resources (not limited to CPUs and GPUs) to be handled uniformly without being tied to specific hardware.

[0004] To make it easy to use GPUs and FPGAs in user applications, the following is required: When deploying general-purpose applications such as image processing and encryption processing to an environment, it is desirable for the platform to analyze the application logic and automatically offload processing to the GPU or FPGA.

[0005] CUDA, a development environment for GPGPUs (General Purpose GPUs), which use the computing power of GPUs for purposes other than image processing, is being developed. CUDA is a development environment for GPGPUs. OpenCL has also emerged as a standard for unifying heterogeneous hardware such as GPUs, FPGAs, and many-core CPUs.

[0006] CUDA and OpenCL are programmed using an extension of the C language. However, it is difficult to write code that requires copying and releasing memory between devices such as GPUs and the CPU. In reality, there are not many engineers who can use CUDA or OpenCL proficiently.

[0007] To simplify GPGPU implementation, there is a directive-based technology that specifies loop statements and other sections that should be processed in parallel, and the compiler converts them into device-ready code according to the directives. Technical specifications include OpenACC (Open Accelerator), and compilers include the PGI Compiler (registered trademark). For example, when using OpenACC, the user specifies parallel processing for code written in C / C++ / Fortran using OpenACC directives. The PGI Compiler checks the parallelizability of the code, generates executable binaries for the GPU and the CPU, and modularizes them into execution modules. The IBM JDK (registered trademark) supports a function that offloads parallel processing specifications based on the Java (registered trademark) lambda format to the GPU. Using these technologies, programmers do not need to be aware of things like data allocation to GPU memory. In this way, technologies such as OpenCL, CUDA, and OpenACC make it possible to offload processing to GPUs and FPGAs.

[0008] However, even if offload processing itself becomes possible, there are many challenges in offloading it appropriately. For example, there are compilers with automatic parallelization functions, such as the Intel Compiler (registered trademark). Automatic parallelization involves extracting parallel processing units such as for statements (loop statements) from the program. However, when running in parallel using a GPU, performance often falls short due to the overhead of data exchange between the CPU and GPU memory. To speed up processing using a GPU, skilled personnel are required to tune OpenCL or CUDA, or to search for appropriate parallel processing units using a PGI compiler, etc. For this reason, it is difficult for unskilled users to improve the performance of their applications using GPUs, and even when using automatic parallelization technology, it takes a long time to start using it due to trial and error tuning, such as whether or not to parallelize for statements.

[0009] Regarding placement, there is research into optimizing the embedding location of a VN (Virtual Network) for a group of servers on a network to optimize the use of network resources (see Non-Patent Document 1). In Non-Patent Document 1, the optimal placement of a VN is determined taking communication traffic into consideration. However, this research targets a single-resource virtual network, and aims to reduce carrier equipment costs and overall response time, without considering conditions such as the processing time of individually different applications or the cost and response time requirements of individual users.

[0010] Non-Patent Document 2 is an example of an effort to automate the trial and error process for parallel processing. Non-Patent Document 2 proposes environment adaptive software that aims to run applications at high performance by automatically performing conversion and resource configuration so that code written once can utilize GPUs, FPGAs, many-core CPUs, etc. present in the deployment environment. Additionally, Non-Patent Document 2 proposes a method for automatically offloading loop statements in application code to a GPU as an element of the environment adaptive software and evaluates the performance improvement achieved.

[0011] Non-Patent Document 3 proposes a method for automatically offloading loop statements in application code to FPGA as an element of environment adaptive software and evaluates the performance improvement. Non-Patent Document 4 evaluates a method for optimizing the amount of resources (such as the number of virtual machine cores) for executing an application after automatic conversion for a GPU or the like as an element of environment adaptive software. [Prior art documents] [Non-patent literature]

[0012] [Non-Patent Document 1] Kota Kawashima, Tatsuya Otoshi, Yuichi Oshita, and Masayuki Murata, "A Scalable Virtual Network Embedding Method Based on Distributed Model Predictive Control," IEICE Technical Report, vol.115, pp.19-24, 2015. [Non-patent document 2] Y. Yamato, “Study of parallel processing area extraction and data transfer number reduction for automatic GPU offloading of IoT applications,” Journal of Intelligent Information Systems, Springer, DOI: 10.1007 / s10844-019-00575-8, Aug. 2019. (Electronic Publishing) Vol.54, No.3, pp.567-584, May 2020. (Print Publishing) [Non-patent document 3] Y. Yamato, “Automatic Offloading Method of Loop Statements of Software to FPGA,” International Journal of Parallel, Emergent and Distributed Systems, Taylor & Francis, DOI: 10.1080 / 17445760.2021.1916020, Apr. 2021. [Non-patent document 4] Y. Yamato, “Arranging resource amount after automatic GPU offloading,” The Ninth International Symposium on Computing and Networking (CANDAR 2021), Nov. 2021. Summary of the Invention [Problem to be solved by the invention]

[0013] Non-Patent Documents 1 to 4 mainly evaluate the reduction in processing time during automatic offloading. When offloading processing to heterogeneous devices such as GPUs and FPGAs, there is a problem in that there are no proposals for running the converted applications in a way that meets user requirements (price, response time).

[0014] In view of these points, the present invention has been made, and when an application is automatically converted so that it can be deployed on an offload device such as a GPU or FPGA, the converted application can be optimally deployed while satisfying the user's requirements for cost or response time. Another object of the present invention is to improve the satisfaction of multiple users who request the deployment of applications to be reconfigured by reconfiguring the deployment after operation has begun. [Means for solving the problem]

[0015] In order to solve the above-mentioned problems, an offload server that offloads specific processing of an application program to an accelerator comprises: an application code analysis unit that analyzes source code of the application program; a data transfer specification unit that analyzes reference relationships of variables used in loop statements of the application program and, for data that may be transferred outside the loop, specifies data transfer using an explicit specification line that explicitly specifies data transfer outside the loop; a parallel processing specification unit that identifies loop statements of the application program and compiles each of the identified loop statements by specifying a parallel processing specification statement in the accelerator; a parallel processing pattern creation unit that creates a parallel processing pattern that excludes loop statements that produce a compilation error from being offloaded and specifies whether or not to perform parallel processing on loop statements that do not produce a compilation error; a performance measurement unit that compiles the application program of the parallel processing pattern, deploys it on an accelerator verification device, and executes processing for measuring performance when offloaded to the accelerator; and a deployment reconfiguration unit that, for deployed application programs, reconfigures the deployment locations of application programs requested to be deployed by multiple users who request the deployment of applications to be reconfigured, in accordance with a linear programming formula for reconfiguration. [Effects of the Invention]

[0016] According to the present invention, when an application is automatically converted so that it can be deployed on an offload device such as a GPU or FPGA, the converted application can be optimally deployed to meet the user's requirements for cost or response time. Furthermore, by reconfiguring the deployment after the start of operation, the satisfaction of multiple users who request the deployment of the application to be reconfigured can be improved. [Brief explanation of the drawings]

[0017] [Figure 1] 2 is a functional block diagram showing an example of the configuration of an offload server according to the first embodiment of the present invention; FIG. [Figure 2] FIG. 4 is a diagram illustrating an automatic offload process using an offload server according to the first embodiment. [Figure 3] FIG. 10 is a diagram showing a search image of a control unit (automatic offload function unit) by Simple GA of the offload server according to the first embodiment. [Figure 4] FIG. 10 is a diagram illustrating an example of a normal CPU program of a comparative example. [Figure 5] FIG. 10 is a diagram illustrating an example of a loop statement when data is transferred from a CPU to a GPU using a simple CPU program of a comparative example. [Figure 6] FIG. 10 is a diagram illustrating an example of a loop statement for transferring data from a CPU to a GPU when the offload server is nested and integrated according to the first embodiment. [Figure 7] FIG. 10 is a diagram illustrating an example of a loop statement for transferring data from a CPU to a GPU when transfer integration of an offload server according to the first embodiment is performed. [Figure 8] FIG. 10 is a diagram illustrating an example of a loop statement when transferring data from a CPU to a GPU in a case where transfers of an offload server according to the first embodiment are integrated and a temporary area is used. [Figure 9A] 10 is a flowchart illustrating an outline of an operation performed by an offload server according to the first embodiment. [Figure 9B] 10 is a flowchart illustrating an outline of an operation performed by an offload server according to the first embodiment. [Figure 10] 10 is a flowchart illustrating the setting of resource ratios and resource amounts added after a GPU offload attempt by the offload server according to the first embodiment, and the placement of new applications. [Figure 11] FIG. 2 is a diagram illustrating an example of a topology of a computing node of an offload server according to the first embodiment. [Figure 12] 10 is a graph showing changes in the number of deployed applications with respect to the average response time of the offload server according to the first embodiment. [Figure 13]10 is a flowchart of a reconfiguration for an overall optimal placement taking into consideration the placement status of other users of offload servers according to the first embodiment. [Figure 14] 10 is a graph showing changes in the number of actually configured applications of an offload server according to the first embodiment. [Figure 15] 10 is a graph showing changes in Rk after / Rk before+Pk after / Pk before of an application that has been actually reconfigured on the offload server according to the first embodiment. [Figure 16] FIG. 10 is a functional block diagram showing an example of the configuration of an offload server according to a second embodiment of the present invention. [Figure 17] 10 is a flowchart illustrating an outline of an operation performed by an offload server according to the second embodiment. [Figure 18] 10 is a flowchart showing a performance measurement process of a performance measurement unit of the offload server according to the second embodiment. [Figure 19] FIG. 11 is a diagram illustrating a search image of a PLD processing pattern creation unit of an offload server according to the second embodiment. [Figure 20] FIG. 10 is a diagram illustrating a flow from the C code of the offload server to the search for the final OpenCL solution according to the second embodiment. [Figure 21] FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of an offload server according to each embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0018] An offload server according to an embodiment of the present invention (hereinafter referred to as "the present embodiment") will be described below with reference to the drawings. (Basic concept of the present invention for automatic offloading) To embody the concept of environment-adaptive software, the present inventor has hitherto proposed methods for automatic GPU offloading of loop statements in programs, automatic FPGA offloading, and optimization of execution resources for conversion applications (see Non-Patent Documents 2, 3, and 4). Based on the study of the elemental technologies in these Non-Patent Documents 2, 3, and 4, the basic concept of the present invention will be described.

[0019] <Optimization of the resource ratio between the CPU and the offloading device> First, the optimization of the resource ratio between the CPU and the offloading device after the program conversion that can be offloaded to the device will be described. By the methods of Non-Patent Document 2 and the like, a normal program can be automatically offloaded to an offloading device such as a GPU or an FPGA. Currently, multi-core CPUs and many-core CPUs can be flexibly allocated a certain percentage of all cores through virtualization using virtual machines or containers. Similarly, for GPUs, virtualization similar to that of CPUs has been carried out in recent years, and operations such as allocating a certain percentage of all cores of the GPU are becoming possible. Regarding FPGAs, the resource usage amount is often represented by the number of settings of Look Up Tables and Flip Flops, and unused gates can be used for other purposes.

[0020] Thus, it is possible to operate using a part of all resources for CPUs, GPUs, and FPGAs, and appropriately optimizing the resources of the CPU and the offloading device according to the application is important for improving cost performance.

[0021] Also, using the methods of Non-Patent Document 2 and the like, an application can be converted into code for CPU and GPU processing. However, even if the code itself is appropriate, if the resource amounts of the CPU and the GPU are not in an appropriate balance, performance will not be achieved. For example, when performing a certain process, if the processing time of the CPU is 1000 seconds and the processing time of the GPU is 1 second, even if the process that can be offloaded is accelerated to some extent by the GPU, the CPU will be the bottleneck overall.

[0022] Furthermore, in Non-Patent Document 5, "K. Shirahata, H. Sato and S. Matsuoka, "Hybrid Map Task Scheduling for GPU-Based Heterogeneous Clusters," IEEE Second International Conference on Cloud Computing Technology and Science (CloudCom), pp. 733-740, December 2010," when tasks are processed using a CPU and a GPU in a MapReduce (registered trademark) framework, the map tasks are allocated so that the execution times of the CPU and the GPU are the same, thereby improving overall performance.

[0023] The inventors came up with the idea of ​​determining the resource ratio between the CPU and the offload device as follows: In other words, to prevent processing in any device from becoming a bottleneck, and with reference to the above-mentioned non-patent documents, the resource ratio between the CPU and the offload device (hereinafter referred to as "resource ratio") is determined based on the processing time of the test case so that the processing time of the CPU and the offload device are of the same order of magnitude.

[0024] Furthermore, the present inventors employ a method for gradually increasing the speed of code based on performance measurement results in a verification environment during automatic offloading, similar to the method described in Non-Patent Document 2. The reason for this is that performance varies significantly not only depending on the code structure but also on the specifications of the hardware used to actually process the code, data size, loop count, and other aspects of the actual processing. Furthermore, performance is difficult to predict statically, and dynamic measurement is required. Therefore, since performance measurement results are already available in a verification environment during code conversion, the resource ratio is determined using these results.

[0025] When performing performance measurement, measurements are taken by specifying test cases. For example, if the processing time of a test case in a verification environment is 10 seconds for CPU processing and 5 seconds for GPU processing, the resources on the CPU side are considered to be about twice as much for the same processing time. Therefore, the resource ratio is 2:1. For user requirements such as wanting to accelerate a certain process through offloading, test cases including that process are prepared, and the user requirements are reflected by accelerating the test cases using methods such as Non-Patent Document 2.

[0026] <Determination of Resource Amounts of CPU and Offloading Devices and Automatic Verification> Next, the determination and automatic verification of the resource amounts of the CPU and offloading devices (hereinafter referred to as "resource amounts") will be described. When the resource ratio is determined by the above <Optimization of Resource Ratio between CPU and Offloading Device>, next, the application is deployed to the commercial environment. When deploying to the commercial environment, the resource amounts are determined while keeping (maintaining) the resource ratio as much as possible to meet the cost requirements specified by the user. For example, regarding the CPU, assume that 1 VM costs 1000 yen per month, the GPU costs 4000 yen per month, and the appropriate resource ratio is 2:1. And assume that the user's budget is within 10000 yen per month. In this case, even if the resource ratio is 2:1, it is within the user's budget of 10000 yen per month. So, the resource amounts while keeping the appropriate resource ratio of 2:1, that is, the CPU is "2" and the GPU is "1" are secured and deployed to the commercial environment. Also, if the user's budget is within 5000 yen per month, the appropriate resource ratio of 2:1 cannot be maintained. In this case, as the resource amounts, the CPU is "1" and the GPU is "1" are secured and deployed.

[0027] After securing resources in a commercial environment and deploying a program, automatic verification is performed to confirm that the program works before users can use it. In automatic verification, performance verification test cases and regression test cases are executed. Performance verification test cases are executed using an automatic test execution tool such as Jenkins (registered trademark) based on assumed test cases specified by the user, and processing time, throughput, and the like are measured. Regression test cases are executed by acquiring information about software such as middleware and the OS installed in the system and executing corresponding regression tests using Jenkins or the like. Studies on how to perform these automatic verifications with fewer test case preparations have been conducted in, for example, Non-Patent Document 6 (Y. Yamato, “Automatic verification technology of software patches for user virtual environments on IaaS cloud,” Journal of Cloud Computing, Springer, 2015, 4:4, DOI: 10.1186 / s13677-015-0028-6, Feb. 2015.), and the technology in Non-Patent Document 6 is used.

[0028] The performance verification test cases check whether the calculation results are invalid even when offloading is used. The performance verification test cases also check the difference in calculation results compared to when offloading is not used. For example, the PGI compiler that processes GPUs uses APIs (Application Programming Interfaces) called PGI_compare (registered trademark) and acc_compare (registered trademark) of the PCAST ​​(registered trademark) function to check the difference in calculation results when using and not using a GPU. Note that there are cases where the calculation results do not match perfectly even if parallel processing is offloaded correctly due to differences in rounding errors between GPUs and CPUs, etc. For this reason, for example, checks are performed according to the IEEE 754 specifications, and the user is informed of whether the difference is acceptable and asked to confirm.

[0029] As a result of the automated verification, the user is presented with information such as the processing time and throughput of the performance verification test cases, the difference in calculation results, and the results of the regression tests. The user is also presented with the secured resources (number of VMs, specifications, etc.) and their prices, and the user can refer to this information to decide whether to start operation.

[0030] <Resources, resource ratios, test case processing time> The resources, resource ratios, and test case processing times in this embodiment will be described below. About resources CPUs, GPUs, FPGAs, etc. are now being provided as instances of virtual resources. Resources include the number of CPU cores, clock speed, memory capacity, disk size, the number of GPU cores, clock speed, memory capacity, and FPGA gate size (units of LE (registered trademark) for Intel (registered trademark) and LC (registered trademark) for Xilinx (registered trademark)). Cloud computing providers package these resources and provide them in the form of small-sized virtual machines or GPU instances. When virtualizing, the number of instances used can be said to be the amount of resources used.

[0031] About resource ratio The ratio of the number of CPU, GPU, and FPGA instances is the resource ratio. If the number of instances is 1, 2, or 3, the resource ratio is 1:2:3.

[0032] Test case processing time This embodiment searches for and finds an offload pattern that speeds up a test case specified by a user. For a DB (database), the test case is the number of transaction processes such as TPC-C (registered trademark), and for an FFT, it is the execution of a Fourier transform process on sample data. The processing time is the execution time when the sample process is executed. For example, the processing time for process A was 10 seconds before offloading, but became 2 seconds after offloading, and the execution times when the process was executed on the CPU and when it was executed on the offload device are obtained.

[0033] <Loop statement detection> Currently, it is difficult for a compiler to determine whether a loop statement is suitable for GPU parallel processing. It is difficult to predict the performance and power consumption that will result from offloading to the GPU without actually measuring it. For this reason, instructions to offload this loop statement to the GPU are manually entered, and measurements are conducted through trial and error. This invention automatically finds suitable loop statements to offload to a GPU using a genetic algorithm (GA), an evolutionary computing technique. Specifically, it geneticizes parallelizable loop statements by assigning a value of 1 when the loop is executed by a GPU and a value of 0 when the loop is executed by a CPU, and then repeatedly measures the loop in a verification environment to search for suitable patterns.

[0034] (First embodiment) Next, the offload server 1 and the like in an embodiment of the present invention (hereinafter referred to as "the present embodiment") will be described.

[0035] [Automatic GPU offloading of loop statements] FIG. 1 is a functional block diagram showing an example of the configuration of an offload server 1 according to the first embodiment of the present invention. The offload server 1 is a device that automatically offloads specific processing of an application to an accelerator. As shown in FIG. 1, the offload server 1 includes a control unit 11, an input / output unit 12, a storage unit 13, and a verification machine 14 (accelerator verification device).

[0036] The input / output unit 12 is composed of a communication interface for transmitting and receiving information to and from each device, etc., and an input / output interface for transmitting and receiving information to and from input devices such as a touch panel and a keyboard, and output devices such as a monitor.

[0037] The memory unit 13 is composed of a hard disk, flash memory, RAM (Random Access Memory), etc., and temporarily stores programs (offload programs) for executing each function of the control unit 11 and information necessary for processing by the control unit 11 (for example, intermediate language file 133).

[0038] The storage unit 13 includes a test case database 131, a facility resource database 132, and an intermediate language file 133.

[0039] The test case DB 131 stores data of test items corresponding to the software to be verified. For example, in the case of a database system such as MySQL, the test item data is data of a transaction test such as TPC-C.

[0040] The facility resource DB 132 stores information prepared in advance about resources such as servers held by the business operator, including their prices, as well as information about their usage. For example, the information may show that there are 10 servers that can accommodate three GPU instances, each costing 5,000 yen per month, and that two of the 10 servers, A and B, are fully utilized, while one server, C, is using only one instance. This information is used to determine the amount of resources to be secured when a user specifies operational conditions (cost, performance, etc.). The user operational conditions are cost conditions (e.g., a monthly budget of 10,000 yen or less) and performance conditions (e.g., a transaction throughput of TPC-C or the like, or a sample Fourier transform processing time per thread, within a certain number of seconds, etc.) specified by the user when requesting offloading.

[0041] The intermediate language file 133 temporarily stores information required for processing by the control unit 11 in the form of a programming language that exists between a high-level language and a machine language.

[0042] The verification machine 14 includes a CPU, a GPU, and an FPGA as a verification environment for the environment-adaptive software.

[0043] The control unit 11 is an automatic offloading function that controls the entire offload server 1. The control unit 11 is realized, for example, by a central processing unit (CPU) (not shown) expanding an application program (offload program) stored in the storage unit 13 into RAM and executing it.

[0044] The control unit 11 includes an application code specification unit (Specify application code) 111, an application code analysis unit (Analyze application code) 112, a data transfer specification unit 113, a parallel processing specification unit 114, a resource ratio determination unit 115, a resource amount setting unit 116, an arrangement setting unit 170, an arrangement reconfiguration unit 180, a parallel processing pattern creation unit 117, a performance measurement unit 118, an executable file creation unit 119, a production environment deployment unit (Deploy final binary files to production environment) 120, a performance measurement test extraction execution unit (Extract performance test cases and run automatically) 121, and a user provision unit (Provide price and performance to a user to judge) 122.

[0045] <Application code designation section 111> The application code designation unit 111 designates the input application code. Specifically, the application code designation unit 111 passes the application code written in the received file to the application code analysis unit 112.

[0046] <Application Code Analysis Unit 112> The application code analysis unit 112 analyzes the source code of the processing function and understands the structure of loop statements, FFT library calls, and the like.

[0047] <Data transfer designation unit 113> The data transfer specification unit 113 analyzes the reference relationships of variables used in loop statements of the application program, and for data that may be transferred outside the loop, specifies the data transfer using an explicit specification line (such as #pragma acc kernels, #pragma acc data copyin(a,b), #pragma acc data copyout(a,b), #pragma acc parallel loop, or #pragma acc parallel loop vector, which will be described later) that explicitly specifies the data transfer outside the loop.

[0048] <Parallel processing designation unit 114> The parallel processing specification unit 114 identifies loop statements (repeated statements) in the application program, and compiles each loop statement by specifying a parallel processing specification statement for the accelerator. The parallel processing specification unit 114 includes an offloadable area extraction unit (Extract offloadable area) 114a and an intermediate language file output unit (Output intermediate file) 114b.

[0049] The offload range extraction unit 114a identifies processes that can be offloaded to the GPU / FPGA, such as loop statements and FFTs, and extracts intermediate languages ​​corresponding to the offload processes. The intermediate language file output unit 114b outputs the extracted intermediate language file 133. The intermediate language extraction is not completed once and for all, but is repeated to perform trial and error to search for an appropriate offload area and to optimize the execution.

[0050] <Resource ratio determination unit 115> The resource ratio determination unit 115 determines the processing times of the CPU and offload device (test case CPU processing time and offload device processing time) as a resource ratio based on the performance measurement results (described later). Specifically, the resource ratio determination unit 115 determines the resource ratio so that the processing times of the CPU and offload device are of the same order. Furthermore, if the difference between the processing times of the CPU and offload device is equal to or greater than a predetermined threshold, the resource ratio determination unit 115 sets the resource ratio to a predetermined upper limit value.

[0051] <Resource Amount Setting Unit 116> The resource amount setting unit 116 sets the resource amounts of the CPU and offload devices based on the determined resource ratio so as to satisfy a predetermined cost condition (described later). Specifically, the resource amount setting unit 116 maintains the determined resource ratio and sets the maximum resource amount that satisfies the predetermined cost condition. Furthermore, if the predetermined cost condition is not satisfied by setting the minimum resource amount while maintaining the determined resource ratio, the resource amount setting unit 116 changes the resource ratio and sets the resource amounts of the CPU and offload devices to values ​​smaller than (for example, the minimum) that satisfy the cost condition.

[0052] <Placement setting section 170> When the placement setting unit 170 places the converted application on one of the cloud server, carrier edge server, and user edge server on the network in accordance with the cost or response time conditions specified by the user, the placement setting unit 170 calculates and sets the placement location of the application based on a linear programming equation with the device and link costs, the computational resource upper limit, and the bandwidth upper limit as constraints and the computational resource cost or the response time as an objective function. Specifically, the placement setting unit 170 calculates and sets the placement destination of the new application (the APL placement location) using a linear programming method based on the server and link specification information and the placement information of existing applications stored in the facility resource DB 132. The linear programming method uses, for example, the objective functions and constraints of the linear programming equations shown in Equations (1), (5), (3), and (4) below. The linear programming equations shown in Equations (1), (5), (3), and (4) below are stored in the facility resource DB 132, and the placement setting unit 170 reads them from the facility resource DB 132 and expands them in a memory processed by the placement setting unit 170.

[0053] <Placement reconfiguration unit 180> The placement reconfiguration unit 180 reconfigures the placement locations of the application programs that have been requested to be placed by multiple users who request the placement of the applications to be reconfigured, in accordance with the linear programming formulas for reconfiguration (see formulas (7), (1), (5), (3), and (4) below) for the placed application programs that have been set by the placement setting unit 170.

[0054] The placement reconfiguration unit 180 uses the sum of the application programs shown in equation (7) below as an objective function (see objective function for user satisfaction evaluation), calculates the placement that minimizes the objective function, and collectively relocates the application programs to the positions determined by the calculation.

[0055] <Parallel processing pattern creation unit 117> The parallel processing pattern creation unit 117 creates a parallel processing pattern that excludes loop statements (repeated statements) that result in compilation errors from being offloaded, and specifies whether or not to process repetitive statements that do not result in compilation errors in parallel.

[0056] <Performance measurement section 118> The performance measurement unit 118 compiles an application program of a parallel processing pattern, places it on the verification machine 14, and executes a process for measuring performance when offloaded to the accelerator. The performance measurement unit 118 includes a binary file deployment unit (Deploy binary files) 118a. The binary file deployment unit 118a deploys (places) an executable file derived from an intermediate language on the verification machine 14 equipped with a GPU and FPGA.

[0057] The performance measurement unit 118 executes the allocated binary file, measures the performance when offloaded, and returns the performance measurement results to the offload range extraction unit 114a. In this case, the offload range extraction unit 114a extracts another parallel processing pattern, and the intermediate language file output unit 114b attempts performance measurement based on the extracted intermediate language (see symbol a in Figure 2, which will be described later).

[0058] <Executable File Creation Unit 119> The executable file creation unit 119 selects multiple parallel processing patterns with high processing performance from the multiple parallel processing patterns based on the performance measurement results repeated a predetermined number of times, crosses the high-performance parallel processing patterns, and creates multiple other parallel processing patterns by mutation processing.The executable file creation unit 119 then performs new performance measurements, and after the specified number of performance measurements, selects the parallel processing pattern with the highest processing performance from the multiple parallel processing patterns based on the performance measurement results, compiles the parallel processing pattern with the highest processing performance, and creates an executable file.

[0059] <Production Environment Deployment Department 120> The production environment deployment unit 120 deploys the created executable file in the production environment for the user ("Deployment of final binary file in production environment"). The production environment deployment unit 120 determines a pattern specifying the final offload area and deploys it in the production environment for the user.

[0060] <Performance measurement test extraction execution unit 121> After the executable file is deployed, the performance measurement test extraction execution unit 121 extracts performance test items from the test case DB 131 and executes the performance test ("Deployment of final binary file to production environment"). After arranging the executable file, the performance measurement test extraction execution unit 121 extracts performance test items from the test case DB 131 and automatically executes the extracted performance tests in order to show the performance to the user.

[0061] <User provision section 122> The user providing unit 122 presents the user with information such as price and performance based on the performance test results ("Providing information such as price and performance to the user"). Performance test items are stored in the test case DB 131. The user providing unit 122 presents the user with data such as price and performance, along with the performance test results, based on the results of the performance tests corresponding to the test items stored in the test case DB 131. The user decides whether to start paying for the service based on the presented information such as price and performance. Here, for bulk deployment to the production environment, the technology in Non-Patent Document 7 (Y. Yamato, M. Muroi, K. Tanaka and M. Uchimura, “Development of Template Management Technology for Easy Deployment of Virtual Resources on OpenStack,” Journal of Cloud Computing, Springer, 2014, 3:7, DOI: 10.1206 / s13677-014-0007-3, 12 pages, June 2014.) can be used, and for automated performance testing, the technology in the aforementioned Non-Patent Document 6 can be used.

[0062] [Application of genetic algorithms] The offload server 1 can use GA (Genetic Algorithms) for optimizing offloading. The offload server 1 when using GA is configured as follows: That is, the parallel processing specification unit 114 determines the number of loop statements (repeated statements) that do not cause a compilation error based on a genetic algorithm as the gene length. The parallel processing pattern creation unit 117 maps whether or not accelerator processing is possible to the gene pattern by setting either 1 or 0 when accelerator processing is possible, and the other 0 or 1 when accelerator processing is not possible.

[0063] The parallel processing pattern creation unit 117 prepares a specified number of gene patterns by randomly creating each gene value as 1 or 0. The performance measurement unit 118 compiles application code specifying a parallel processing specification statement for the accelerator for each individual, and places the compiled code on the verification machine 14. The performance measurement unit 118 executes a performance measurement process on the verification machine 14.

[0064] Here, if a gene with the same parallel processing pattern as before appears in an intermediate generation, the performance measurement unit 118 does not compile the application code corresponding to that parallel processing pattern or measure its performance, but uses the same value as the performance measurement value. Furthermore, the performance measurement unit 118 treats application code that causes a compilation error and application code for which performance measurement does not end within a predetermined time as a timeout, and sets the performance measurement value to a predetermined time (long time).

[0065] The executable file creation unit 119 measures the performance of all individuals and evaluates them so that the shorter the processing time, the higher the fitness. From all individuals, the executable file creation unit 119 selects those with fitness higher than a predetermined value (for example, the top n% of the total number, or the top m of the total number, where n and m are natural numbers) as high-performance individuals, and performs crossover and mutation on the selected individuals to create the next generation of individuals. After completing processing for the specified number of generations, the executable file creation unit 119 selects the parallel processing pattern with the highest performance as a solution.

[0066] The automatic offload operation of the offload server 1 configured as above will now be described. [Automatic offloading operation] FIG. 2 is a diagram showing an automatic offload process using the offload server 1. As shown in FIG. 2, the offload server 1 is applied to the elemental technology of environment adaptive software. The offload server 1 has a control unit (automatic offload function unit) 11, a test case DB 131, an equipment resource DB 132, an intermediate language file 133, and a verification machine 14. The offload server 1 acquires an application code 125 used by the user.

[0067] A user is, for example, a person who has signed a contract to use various devices (Device 151, device with CPU-GPU 152, device with CPU-FPGA 153, device with CPU 154). The offload server 1 automatically offloads functional processing to accelerators such as a device 152 having a CPU-GPU and a device 153 having a CPU-FPGA.

[0068] The operation of each part will be explained below with reference to the step numbers in FIG. <Step S11: Specify application code> In step S11, the application code designation unit 111 (see FIG. 1) passes the application code described in the received file to the application code analysis unit 112.

[0069] <Step S12: Analyze application code> In step S12, the application code analysis unit 112 (see FIG. 1) analyzes the source code of the processing function and understands the structure of loop statements, FFT library calls, and the like.

[0070] <Step S13: Extract offloadable area> In step S13, the parallel processing specification unit 114 (see FIG. 1) identifies loop statements (repeated statements) in the application, and compiles each repetitive statement by specifying a parallel processing specification statement for the accelerator. Specifically, the offload range extraction unit 114a (see FIG. 1) identifies processes that can be offloaded to the GPU / FPGA, such as loop statements and FFT, and extracts an intermediate language corresponding to the offloaded process.

[0071] <Step S14: Output intermediate file> In step S14, the intermediate language file output unit 114b (see FIG. 1) outputs the intermediate language file 133. The intermediate language extraction is not completed once and for all, but is repeated to try and optimize the execution in order to search for an appropriate offload area.

[0072] <Step S15: Compile error> In step S15, the parallel processing pattern creation unit 117 (see FIG. 1) creates a parallel processing pattern that excludes loop statements that result in compilation errors from being offloaded, and specifies whether or not to perform parallel processing on iterative statements that do not result in compilation errors.

[0073] <Step S21: Deploy binary files> In step S21, the binary file placement unit 118a (see FIG. 1) deploys an executable file derived from the intermediate language to the verification machine 14 equipped with a GPU and FPGA.

[0074] <Step S22: Measure performance> In step S22, the performance measurement unit 118 (see FIG. 1) executes the arranged file and measures the performance when offloaded. To determine the appropriate offload area, the performance measurement results are returned to the offload range extraction unit 114a, which then extracts another pattern.The intermediate language file output unit 114b then attempts to measure performance based on the extracted intermediate language (see symbol a in FIG. 2).

[0075] As indicated by symbol a in FIG. 2, the control unit 11 repeatedly executes steps S12 to S22. The automatic offload function of the control unit 11 can be summarized as follows: The parallel processing specification unit 114 identifies loop statements (repeated statements) in the application program, specifies a statement specifying parallel processing in the GPU for each repeated statement, and compiles the result. The parallel processing pattern creation unit 117 creates a parallel processing pattern that excludes loop statements that generate compilation errors from offloading and specifies whether or not to perform parallel processing on loop statements that do not generate compilation errors. The binary file allocation unit 118a then compiles the application program of the corresponding parallel processing pattern and allocates it to the verification machine 14. The performance measurement unit 118 executes the performance measurement process on the verification machine 14. The executable file creation unit 119 selects a pattern with the highest processing performance from multiple parallel processing patterns based on the performance measurement results obtained by repeating the process a predetermined number of times, compiles the selected pattern, and creates an executable file.

[0076] <Step S23: Setting resource amount according to user operation conditions> In step S23, the control unit 11 sets the resource amounts based on the user operation conditions. That is, the resource ratio determination unit 115 of the control unit 11 determines the resource ratio between the CPU and the offload device. Then, the resource amount setting unit 116 refers to the information in the facility resource DB 132 based on the determined resource ratio and sets the resource amounts of the CPU and the offload device so as to satisfy the user operation conditions (described later with reference to FIG. 10).

[0077] <Step S24: Deploy final binary files to production environment> In step S24, the production environment deployment unit 120 determines a pattern that specifies the final offload area, and deploys it in the production environment for the user.

[0078] <Step S25: Extract performance test cases and run automatically> In step S25, after arranging the executable file, the performance measurement test extraction execution unit 121 extracts performance test items from the test case DB 131 to show the performance to the user, and automatically executes the extracted performance tests.

[0079] <Step S26: Provide price and performance to a user to judge> In step S26, the user providing unit 122 presents the user with information such as price and performance based on the performance test results. The user decides whether to start paying for the service based on the presented information such as price and performance.

[0080] The above steps S11 to S26 are assumed to be performed, for example, in the background of the user's use of the service, for example, during the first day of the trial use.

[0081] As described above, when applied to the elemental technology of environment-adaptive software, the control unit (automatic offload function unit) 11 of the offload server 1 extracts an area to be offloaded from the source code of the application program used by the user and outputs an intermediate language to offload functional processing (steps S11 to S15). The control unit 11 places and executes an executable file derived from the intermediate language on the verification machine 14, and verifies the offload effect (steps S21 to S22). After repeating the verification and determining an appropriate offload area, the control unit 11 deploys the executable file in the production environment that will actually be provided to the user, and provides it as a service (steps S23 to S26).

[0082] [Automatic GPU offloading using GA] GPU automatic offloading is a process in which steps S12 to S22 in FIG. 2 are repeated for the GPU to obtain the offload code to be deployed in step S23.

[0083] GPUs generally do not guarantee latency, but they are devices suited to increasing throughput through parallel processing. Typical applications involve a lot of repetitive processing, such as encryption, image processing for camera video analysis, and machine learning processing for analyzing large amounts of sensor data. Therefore, the goal is to speed up applications by automatically offloading repetitive statements to the GPU.

[0084] However, as described in the prior art, appropriate parallel processing is necessary for speedup. In particular, when using a GPU, due to memory transfers between the CPU and GPU, performance often cannot be achieved unless the data size and loop count are large. Furthermore, depending on factors such as the timing of memory data transfers, the combination of individual loop statements (repeated statements) that can be accelerated in parallel may not be the fastest. For example, if there are 10 "for" statements (repeated statements), and only statements 1, 5, and 10 can be accelerated compared to a CPU, the combination of statements 1, 5, and 10 may not necessarily be the fastest.

[0085] To properly specify parallel regions, there have been attempts to optimize the parallelism of for statements by trial and error using the PGI compiler. However, this trial and error process requires a lot of work, and when providing this as a service, it slows down the start of user adoption and increases costs.

[0086] Therefore, in this embodiment, appropriate offload areas are automatically extracted from general-purpose programs that do not assume parallelization. To achieve this, parallelizable "for" statements are first checked, and then performance verification trials are repeated in a verification environment using GA for the parallelizable "for" statements to search for appropriate areas. By narrowing down to parallelizable "for" statements and then retaining and recombining parallel processing patterns that can be accelerated in the form of genetic parts, it is possible to efficiently search for patterns that can be accelerated from the vast number of possible parallel processing patterns.

[0087] [Search image of control unit (automatic offload function unit) 11 using Simple GA] 3 is a diagram showing a search image of the control unit (automatic offload function unit) 11 using Simple GA. FIG. 3 shows a search image of processing and gene sequence mapping of a for statement. GA is a combinatorial optimization method that mimics the evolutionary process of living organisms. The GA flowchart is as follows: initialization → evaluation → selection → crossover → mutation → termination decision. In this embodiment, a simple GA with simplified processing is used among GAs. Simple GA is a simplified GA in which genes are limited to 1 and 0, and roulette wheel selection, one-point crossover, and mutation reverse the value of one gene.

[0088] <Initialization> During initialization, after checking whether all for statements in the application code can be parallelized, parallelizable for statements are mapped to the gene array. If GPU processing is used, the value is set to 1, and if not, the value is set to 0. A specified number of individuals, M, is prepared for the gene, and 1 or 0 is randomly assigned to each for statement. Specifically, the control unit (automatic offload function unit) 11 (see Figure 1) acquires the application code 125 (see Figure 2) used by the user, and as shown in Figure 3, checks whether or not the for statements can be executed in parallel from the code patterns 141 of the application code 125. As shown in Figure 3, if five for statements are found from the code pattern 141 (see symbol b in Figure 3), one digit is randomly assigned to each for statement, in this case five digits of 1 or 0 for the five for statements. For example, 0 is assigned for processing by the CPU, and 1 is assigned for output to the GPU. However, at this stage, 1 or 0 is randomly assigned. The code corresponding to the gene length is 5 digits, and the 5-digit code for the gene length is 2 5 =32 patterns, for example, 10001, 10010, .... In Fig. 3, the circles (○ marks) in the code pattern 141 are shown as an image of the code.

[0089] <Evaluation> In the evaluation, deployment and performance measurement are performed (see symbol c in FIG. 3). That is, the performance measurement unit 118 (see FIG. 1) compiles the code corresponding to the gene, deploys it on the verification machine 14, and executes it. The performance measurement unit 118 performs benchmark performance measurement. It increases the fitness of genes with patterns (parallel processing patterns) that have good performance.

[0090] <Select> In the selection, high performance code patterns are selected based on the fitness (see symbol d in FIG. 3). The performance measurement unit 118 (see FIG. 1) selects a specified number of genes with high fitness based on the fitness. In this embodiment, roulette wheel selection according to the fitness and elite selection of the genes with the highest fitness are performed. FIG. 3 shows, as a search image, that the number of circles (◯) in the selected code patterns (Select code patterns) 142 has been reduced to three.

[0091] <Crossover> In crossover, some genes are exchanged at a certain point between selected individuals at a certain crossover rate Pc to create offspring individuals. The genes of a roulette-selected pattern (parallel processing pattern) are crossed with those of another pattern. The position of the single-point crossover is arbitrary; for example, crossover is performed at the third digit of the five-digit code above.

[0092] <Mutation> Mutation involves changing the value of each gene in an individual from 0 to 1 or from 1 to 0 at a constant mutation rate Pm. Furthermore, mutation is introduced to avoid local solutions, although mutation may not be performed to reduce the amount of calculation.

[0093] <End determination> As shown in Figure 3, the next generation code patterns after crossover and mutation are generated (see symbol e in Figure 3). In the termination determination, the process is terminated after repeating the specified number of generations T times, and the gene with the highest fitness is taken as the solution. For example, performance is measured and the three fastest ones are selected: 10010, 01001, and 00101. These three are then recombined using GA in the next generation, for example by crossing the first and second patterns to create a new pattern (parallel processing pattern) 11011. At this time, the recombined pattern is mutated by automatically changing 0 to 1. The above process is repeated to find the fastest pattern. A specified generation (for example, 20th generation) is decided, and the pattern remaining in the final generation is designated as the final solution.

[0094] <Deployment> The parallel processing pattern with the highest processing performance corresponding to the gene with the highest fitness is then deployed again to the production environment and provided to the user.

[0095] <Supplementary explanation> This section explains the case where there are a considerable number of "for" statements (loop statements; repetitive statements) that cannot be offloaded to the GPU. For example, even if there are 200 "for" statements, only about 30 can be offloaded to the GPU. Here, we will exclude those that will result in an error and perform GA on these 30 statements.

[0096] OpenACC has a compiler that extracts bytecode for GPUs and executes it for GPU offloading by specifying the directive #pragma acc kernels. By writing a for statement command in this #pragma, you can determine whether the for statement will run on a GPU.

[0097] For example, if you are using C / C++, the C / C++ code is analyzed to find for statements. When a for statement is found, it is written to the for statement using OpenACC parallel processing syntax, such as #pragma acc kernels, #prama acc parallel loop, or #prama acc parallel loop vector. In detail, for statements are inserted into #pragma acc kernels, #prama acc parallel loop, or #prama acc parallel loop vector one by one, and the code is compiled. If an error occurs, the for statement cannot be processed by the GPU, so it is excluded.

[0098] In this way, the remaining for statements are found. The one that does not produce an error is taken as the length (gene length). If there are five for statements without errors, the gene length is 5, and if there are 10 for statements without errors, the gene length is 10. Note that parallel processing is not possible when there is a data dependency such that the previous processing is used for the next processing. This is the preparation stage. Next, we will perform the GA process.

[0099] A code pattern with a gene length corresponding to the number of for statements is obtained. First, parallel processing patterns 10010, 01001, 00101, ... are randomly assigned. GA processing is performed and compilation is performed. At this time, an error may occur even though the for statements can be offloaded. This occurs when the for statements are hierarchical (GPU processing is possible if either is specified). In this case, the for statement that caused the error can be left as it is. Specifically, one method is to make it take longer to process, causing a timeout.

[0100] It is deployed on the verification machine 14 and benchmarked, for example, for image processing, and the shorter the processing time, the higher the fitness is evaluated. For example, the processing time is raised to the power of -1 / 2, with 1 second being rated as 1, 100 seconds being 0.1, and 0.01 seconds being 10. The highly adaptable patterns are selected, for example, 3 to 5 are selected from 10 patterns, and then a new chord pattern is created by rearranging them. At this time, it is possible that the same pattern as before is created during the creation process. In this case, there is no need to perform the same benchmark, so the same data as before is used. In this embodiment, the chord patterns and their processing times are stored in the storage unit 13. This concludes the explanation of the search image of the control unit (automatic offload function unit) 11 using Simple GA. Next, a batch processing method for data transfer will be described.

[0101] [Batch processing method for data transfer] <Basic Concept> In order to reduce CPU-GPU transfers, nested loop variables are transferred as high-level as possible. In addition, the present invention consolidates the timing of many variable transfers and further reduces transfers that are automatically transferred by the compiler. To reduce transfers, variables that can be transferred to the GPU at the same time are transferred not only on a nested basis, but also in batches. For example, unless the variables are ones that require the GPU processing results to be processed on the CPU and then reprocessed on the GPU, it is possible to send variables defined on the CPU that are used in multiple loop statements to the GPU in batches before GPU processing begins, and then return them to the CPU after all GPU processing is complete.

[0102] During code analysis, the reference relationships between loops and variables are identified. From the results, for variables defined in multiple files, the GPU and CPU processing is not nested, and for variables that can be processed separately from the CPU, the OpenACC data copy statement is used to specify that they be transferred in a batch. Variables are transferred in bulk before GPU processing begins, and variables that do not need to be transferred at the time of loop statement processing are explicitly indicated as not needing to be transferred using data present. When transferring data between the CPU and GPU, a temporary area is created (#pragma acc declare create), the data is stored in the temporary area, and then the transfer is instructed by synchronizing the temporary area (#pragma acc update).

[0103] <Comparative Example> First, a comparative example will be described. The comparative examples are a normal CPU program (see Figure 4), a simple GPU program (see Figure 5), and a nested program (Non-Patent Document 2) (see Figure 6). <1> ~ <4> The symbols etc. are added for the convenience of explanation (the same applies to other drawings and their explanations). The loop statement in the normal CPU program shown in Figure 4 is written in the CPU program, <1> Loop [for(i=0; i<10; i++)] { } Among them, <2> Loop [for(j=0; j<20; j++)] { The symbol f in Figure 4 is <2> This is the setting of variables a and b in the loop. Also, <3> Loop [for(k=0; k<30; k++)] { } and, <4> Loop [for(l=0; l<40; l++)] { } The symbol g in Figure 4 is <3> The setting of variables c and d in the loop, and the symbol h in Figure 4 is <4> This is the setting of variables e and f in the loop. The normal CPU program shown in Figure 4 is executed by the CPU (without using the GPU).

[0104] Figure 5 shows the loop statements when the normal CPU program shown in Figure 4 is used with a simple GPU to transfer data from the CPU to the GPU. There are two types of data transfer: data transfer from the CPU to the GPU and data transfer from the GPU to the CPU. Below, we will take data transfer from the CPU to the GPU as an example. The simple GPU-utilizing loop statement shown in Figure 5 is written in the CPU program, <1> Loop [for(i=0; i<10; i++)] { } Among them, <2> Loop [for(j=0; j<20; j++)] { There is. Furthermore, as shown in symbol i of FIG. <1> Loop [for(i=0; i<10; i++)] { Above the}, parallel processing parts such as for statements by the PGI compiler are specified with the OpenACC directive #pragma acc kernels (parallel processing specification statement). As shown in the dashed box containing the symbol i in Figure 5, data is transferred from the CPU to the GPU by #pragma acc kernels. In this case, a and b are transferred at this timing, so they are transferred 10 times.

[0105] Also, as shown by symbol j in Figure 5, <3> Loop [for(k=0; k<30; k++)] { Above the}, the OpenACC directive #pragma acc kernels is used to specify parallel processing parts such as for statements by the PGI compiler. As shown in the dashed box containing symbol j in Figure 5, c and d are transferred at this timing by #pragma acc kernels.

[0106] where: <4> Loop [for(l=0; l<40; l++)] { Do not specify #pragma acc kernels above the}. This loop is not GPU processed because it is inefficient to process it using the GPU.

[0107] FIG. 6 is a diagram showing loop statements in the case of data transfer from the CPU to the GPU and from the GPU to the CPU by nested consolidation (Non-Patent Document 2). In the loop statement shown in Figure 6, a data transfer directive from the CPU to the GPU, in this case #pragma acc data copyin(a,b) of the copyin clause for variables a and b, is inserted at the position indicated by symbol k in Figure 6. Note that in this specification, parentheses () are used around copyin(a,b) for notational reasons. The same notation is used for copyout(a,b) and datacopyin(a,b,c,d) described below. The above #pragma acc data copyin(a,b) is the top-level loop that does not include the setting and definition of variable a (here, <1> Loop [for(i=0; i<10; i++)] { }) Since a and b are transferred at the timing shown in the dashed-dotted box including the symbol k in FIG. 6, one transfer occurs.

[0108] In addition, in the loop statement shown in Figure 6, a data transfer instruction line from the GPU to the CPU, in this case #pragma acc data copyout(a,b) of the copyout clause for variables a and b, is inserted at the position indicated by symbol l in Figure 6. The above #pragma acc data copyout(a,b) is <1> Loop [for(i=0; i<10; i++)] { } is specified at the bottom.

[0109] In this way, when transferring data from the CPU to the GPU, the data transfer is explicitly specified by inserting #pragma acc data copyin(a,b) in the copyin clause of variable a at the position mentioned above. This allows data transfer to be performed in bulk in the highest level loop possible, avoiding the inefficient transfer of data for each loop, as in the simple GPU-using loop statement shown in Figure 5.

[0110] <Embodiment> Next, the present embodiment will be described. 《Indicate variables that do not need to be transferred using data present》 In this embodiment, for variables defined in multiple files, GPU processing and CPU processing are not nested, and variables that can be separated into CPU processing and GPU processing are specified to be transferred in bulk using the OpenACC data copy statement. In addition, variables that are transferred in bulk and do not need to be transferred at that time are explicitly indicated using data present.

[0111] 7 is a diagram showing a loop statement based on the transfer batching during CPU-GPU data transfer according to this embodiment, which corresponds to the nest batching in FIG. 6 of the comparative example. In the loop statement shown in Figure 7, a data transfer directive from the CPU to the GPU, in this case #pragma acc datacopyin(a,b,c,d) in the copyin clause for variables a, b, c, and d, is inserted at the position indicated by symbol m in Figure 7. The above #pragma acc data copyin(a,b,c,d) is the top-level loop that does not include the setting and definition of variable a (here, <1> Loop [for(i=0; i<10; i++)] { })

[0112] In this way, for variables defined in multiple files, where GPU processing and CPU processing are not nested and where CPU processing and GPU processing can be separated, the OpenACC data copy statement #pragma acc data copyin(a,b,c,d) is used to specify that the variables be transferred in a batch. Since a, b, c, and d are transferred at the timing shown in the dashed-dotted box including symbol m in FIG. 7, one transfer occurs.

[0113] Then, the variables are transferred in bulk using the above #pragma acc data copyin(a,b,c,d), and variables that do not need to be transferred at that time are specified using the data present statement #pragma acc data present (a,b), which explicitly indicates that the variables are already present in the GPU at the time shown in the dashed-dotted-line box containing the symbol n in Figure 7.

[0114] The variables are transferred in bulk using the above #pragma acc data copyin(a,b,c,d), and variables that do not need to be transferred at that time are specified using the data present statement #pragma acc data present(c,d), which explicitly indicates that the variables are already present in the GPU at the time shown in the dashed-dotted-line box containing the symbol o in Figure 7. <1> , <3> When the loop is processed by the GPU and the GPU processing is completed, the data transfer directive from the GPU to the CPU, in this case #pragma acc datacopyout(a,b,c,d) in the copyout clause of variables a,b,c,d, is executed as shown in Figure 7. <3> Insert at position p where the loop ended.

[0115] By specifying batch transfer, variables that can be batch transferred are transferred in bulk, and variables that have already been transferred and do not need to be transferred are explicitly specified using data present, reducing transfers and making offloading more efficient. However, even if OpenACC instructs transfer, depending on the compiler, the compiler may automatically determine and transfer. Automatic transfer by the compiler is an event that differs from OpenACC instructions and refers to an event where transfer between the CPU and GPU is automatically performed at the compiler's discretion, even though it is not actually necessary.

[0116] Temporary data storage 8 is a diagram showing a loop statement with transfer bundling during CPU-GPU data transfer in this embodiment, which corresponds to the nest bundling and explicit specification of variables that do not require transfer in FIG. In the loop statement shown in Figure 8, the OpenACC declare create statement #pragma acc declare create, which creates a temporary area during CPU-GPU data transfer, is specified at the position indicated by symbol q in Figure 8. As a result, a temporary area is created (#pragma acc declare create) during CPU-GPU data transfer, and the data is stored in the temporary area.

[0117] In addition, the transfer is instructed by specifying the OpenACC declare create statement #pragma acc update to synchronize the temporary area at the position indicated by the symbol r in Figure 8.

[0118] In this way, by creating a temporary area, initializing parameters in the temporary area, and using it for CPU-GPU transfer, unnecessary CPU-GPU transfer is blocked. This reduces transfers that are unintended by OpenACC instructions but degrade performance.

[0119] [GPU offload processing] The above-described data transfer batch processing method allows for the extraction of loop statements suitable for offloading, and makes it possible to avoid inefficient data transfer. However, even if the above data transfer batch processing method is used, there are still programs that are not suitable for GPU offloading. Effective GPU offloading requires a large number of loops in the offloaded process.

[0120] Therefore, in this embodiment, a profiling tool is used to investigate the number of loops as a preliminary step to a full-scale offload processing search. Using a profiling tool makes it possible to investigate the number of times each line is executed, so it is possible to pre-allocate programs, for example, by targeting programs with loops of 50 million or more as targets for offload processing search. This is explained in detail below (some of the content overlaps with that described in FIG. 2).

[0121] In this embodiment, first, the application code analysis unit 112 (FIG. 1) analyzes the application and identifies loop statements such as for, do, while, etc. Next, a sample process is executed, and a profiling tool is used to check the number of loops in each loop statement, and a decision is made as to whether to perform a full search based on whether there are loops exceeding a certain value.

[0122] If it is decided to conduct a full-scale search, the GA process begins (see Figure 2). In the initialization step, after checking whether all loop statements in the application code can be parallelized, parallelizable loop statements are mapped to the gene array as 1 if they can be processed by the GPU, or 0 if they cannot. A specified number of genes are prepared, and each gene value is randomly assigned a value of 1 or 0.

[0123] Here, in the code corresponding to the gene, an explicit instruction for data transfer (#pragma acc data copyin / copyout / copy) is added based on the variable data reference relationship within the loop statement specified to be processed by GPU.

[0124] In the evaluation step, the code corresponding to the gene is compiled, deployed to a verification machine, and executed to measure benchmark performance. Then, the fitness of genes with good performance patterns is increased. As described above, parallel processing directives (e.g., see symbol f in Figure 4) and data transfer directives (e.g., see symbol h in Figure 4, symbol i in Figure 5, and symbol k in Figure 6) are inserted into the code corresponding to the gene.

[0125] In the selection step, genes with high fitness are selected for a specified number of individuals based on fitness. In this embodiment, roulette wheel selection according to fitness and elite selection of the genes with the highest fitness are performed. In the crossover step, some genes are exchanged at a certain point between the selected individuals at a certain crossover rate Pc to create offspring individuals. In the mutation step, the value of each gene of the individuals is changed from 0 to 1 or from 1 to 0 at a certain mutation rate Pm.

[0126] Once the mutation step is complete and the specified number of genes for the next generation have been created, an explicit instruction for data transfer is added, as in the initialization step, and the evaluation, selection, crossover, and mutation steps are repeated.

[0127] Finally, in the termination determination step, the process is terminated after the specified number of generations, and the gene with the highest fitness is taken as the solution. The code pattern with the highest performance corresponding to the gene with the highest fitness is then deployed to the production environment and provided to the user.

[0128] The following describes the implementation of the offload server 1. This implementation is intended to confirm the effectiveness of this embodiment. [implementation] We explain the implementation of automatic offloading of C / C++ applications using the general-purpose PGI compiler. In this implementation, the purpose is to confirm the effectiveness of GPU automatic offloading, so the target application is a C / C++ language application, and the GPU processing itself is explained using the conventional PGI compiler.

[0129] The C / C++ language is one of the most popular languages ​​for developing OSS (Open Source Software) and proprietary software, and many applications are developed in C / C++. To verify the offloading of applications used by general users, we used general-purpose OSS applications such as encryption and image processing.

[0130] GPU processing is performed by the PGI compiler. The PGI compiler is a compiler for C / C++ / Fortran that interprets OpenACC. In this embodiment, parallelizable processing sections such as for statements are specified using the OpenACC directive #pragma acc kernels (parallel processing specification statement). This extracts bytecode for the GPU, and by executing it, GPU offloading becomes possible. Furthermore, an error is issued when there is a dependency between data in a for statement that makes parallel processing impossible, or when multiple levels of nested for statements are specified. In addition, explicit data transfer instructions are possible using directives such as #pragma acc data copyin / copyout / copy.

[0131] In accordance with the above specification of #pragma acc kernels (parallel processing specification statement), explicit data transfer instructions are given by inserting #pragma acc data copyout(a[…]) in the OpenACC copyin clause at the above-mentioned position.

[0132] <Implementation Overview> An overview of the implementation will be explained. The implementation does the following: Before starting the process of the flow shown in Figure 9A-B below, prepare the C / C++ application to be accelerated and a benchmark tool to measure its performance.

[0133] In the implementation, when a request to use a C / C++ application is received, the system first analyzes the code of the C / C++ application to find for statements and understands the program structure, such as the variable data used within the for statements. For syntax analysis, it uses LLVM / Clang syntax analysis libraries, etc.

[0134] In the implementation, first, to obtain a prospect of whether the application will benefit from GPU offloading, a benchmark is run and the number of loops of the for statement identified by the above syntax analysis is determined. To determine the number of loops, tools such as gcov from GNU Coverage are used. Known profiling tools include "GNU Profiler (gprof)" and "GNU Coverage (gcov)." Either can be used, as both can investigate the number of times each line is executed. The number of executions can be set to only target applications with a loop count of 10 million or more, for example, but this value is configurable.

[0135] General-purpose CPU applications are not implemented with parallelization in mind. Therefore, it is necessary to first eliminate for statements that cannot be processed by the GPU. Therefore, for each for statement, we attempt to insert the #pragma acc kernels, #prama acc parallel loop, or #prama acc parallel loop vector directives for GPU processing, and determine whether an error occurs during compilation. There are several types of compilation errors. These include when an external routine is called within a for statement, when different levels of a nested for statement are specified overlappingly, when a process exits the for statement midway using break, or when there is data dependency in the data in the for statement. Compilation errors vary widely depending on the application, and there may be other errors besides those listed above. However, compilation errors are not handled, and no #pragma directives are inserted.

[0136] Compilation errors are difficult to automatically address, and even if they are addressed, they are often ineffective. External routine calls can sometimes be avoided by using #pragma acc routine, but many external calls are libraries, and even if they are included in GPU processing, the calls become a bottleneck and performance is hindered. Because each "for" statement is tried, nesting errors do not result in compilation errors. Also, if you exit midway using break, etc., parallel processing requires that the loop count be fixed, requiring program modification. Parallel processing itself is not possible if there is data dependency.

[0137] Here, if the number of loop statements that do not cause an error when processed in parallel is a, a is the gene length. A gene of 1 corresponds to the presence of a parallel processing directive, and a gene of 0 corresponds to the absence of a parallel processing directive, and the application code is mapped to a gene of length a.

[0138] Next, a gene array for the specified number of individuals is prepared as the initial value. As explained in Figure 3, each gene value is created by randomly assigning 0 and 1. Depending on the prepared gene array, if the gene value is 1, the directives \#pragma acc kernels, \#pragma acc parallel loop, and \#pragma acc parallel loop vector that specify GPU processing are inserted into the C / C++ code. The reason that single loops etc. are not made parallel is because kernels offer better performance for the PGI compiler when performing the same processing. At this stage, the part of the code corresponding to a certain gene that will be processed by the GPU is decided.

[0139] The C / C++ code with parallel processing and data transfer directives inserted is compiled with the PGI compiler on a machine equipped with a GPU. The compiled executable is deployed and performance and power consumption are measured using a benchmark tool.

[0140] After benchmark performance measurements are taken for all individuals, the fitness of each gene sequence is set according to the benchmark processing time and power consumption. Individuals to be retained are selected according to the fitness settings. The selected individuals are then subjected to GA processes including crossover, mutation, and direct copying to create the next generation of individuals.

[0141] The next generation of individuals undergoes directive insertion, compilation, performance measurement, fitness setting, selection, crossover, and mutation processes. If a gene with the same pattern as before is generated during the GA process, compilation and performance measurement are not performed on that individual, and the same measurement value as before is used.

[0142] After the GA process is completed for the specified number of generations, the C / C++ code with directives that corresponds to the gene sequence with the best performance is taken as the solution.

[0143] Among these, the number of individuals, number of generations, crossover rate, mutation rate, fitness setting, and selection method are GA parameters and are specified separately.By automating the above processes, the proposed technology enables the automation of GPU offloading, which previously required the time and skills of specialized engineers.

[0144] 9A-B are flowcharts outlining the operation of the above-described implementation, and FIGS. 9A and 9B are connected by a connector. The following process is performed using the OpenACC compiler for C / C++.

[0145] <Code Analysis> In step S101, the application code analysis unit 112 (see FIG. 1) performs code analysis of the C / C++ application.

[0146] <Loop statement identification> In step S102, the parallel processing specification unit 114 (see FIG. 1) identifies loop statements and reference relationships in the C / C++ application.

[0147] <Parallel processing of loop statements> In step S103, the parallel processing specification unit 114 checks whether each loop statement can be processed by the GPU (#pragma acc kernels).

[0148] <Repeat loop statement> The control unit (automatic offload function unit) 11 repeats the processing of steps S105 to S116 between the loop start point of step S104 and the loop end point of step S117 for the number of loop statements.

[0149] <Repeating the number of loops (part 1)> The control unit (automatic offload function unit) 11 repeats the processing of steps S106-S107 between the loop start point of step S105 and the loop end point of step S108 for the number of loop statements. In step S106, the parallel processing specification unit 114 specifies GPU processing (#pragma acc kernels) in OpenACC for each loop statement and compiles it. In step S107, if an error occurs, the parallel processing specification unit 114 checks the possibility of GPU processing using the following directive (#pragma acc parallel loop).

[0150] <Repeating the number of loops (part 2)> The control unit (automatic offload function unit) 11 repeats the processing of steps S110-S111 between the loop start point of step S109 and the loop end point of step S112 for the number of loop statements. In step S110, the parallel processing specification unit 114 specifies GPU processing (#pragma acc parallel loop) in OpenACC for each loop statement and compiles it. In step S111, if an error occurs, the parallel processing specification unit 114 checks the possibility of GPU processing using the following directive (#pragma acc parallel loop vector).

[0151] <Repeating the number of loops (part 3)> The control unit (automatic offloading function unit) 11 repeats the processes of steps S114 - S115 for the number of loop statements between the loop start of step S113 and the loop end of step S116. In step S114, the parallel processing specification unit 114 specifies GPU processing (#pragma acc parallel loop vector) with OpenACC for each loop statement and compiles it. In step S115, when there is an error, the parallel processing specification unit 114 removes the GPU processing instruction sentence from the loop statement.

[0152] <Count of for loop statements> In step S118, the parallel processing specification unit 114 counts the number of loop statements (here, for loop statements) without compilation errors and uses it as the gene length.

[0153] <Prepare specified population pattern> Next, as an initial value, the parallel processing specification unit 114 prepares a gene array of the specified population size. Here, it is created by randomly assigning 0 and 1. In step S119, the parallel processing specification unit 114 maps the C / C++ application code to the genes and prepares the specified population pattern. According to the prepared gene array, when the value of the gene is 1, a directive for specifying parallel processing is inserted into the C / C++ code (for example, refer to the #pragma directive in Figure 3).

[0154] The control unit (automatic offloading function unit) 11 repeats the processes of steps S121 - S130 for the specified number of generations between the loop start of step S120 in Figure 9B and the loop end of step S131. Also, in the repetition of the specified number of generations, the processes of steps S122 - S125 are repeated for the specified population size between the loop start of step S121 and the loop end of step S126. That is, within the repetition of the specified number of generations, the repetition of the specified population size is processed in a nested state.

[0155] <Specify data transfer> In step S122, the data transfer specification unit 113 specifies a data transfer using explicit directive lines (#pragma acc data copy / copyin / copyout / present and #pragma acc declarecreate, #pragma acc update) based on the variable reference relationship.

[0156] <Compile> In step S123, the parallel processing pattern creation unit 117 (see FIG. 1) compiles the C / C++ code with directives specified according to the gene pattern using a PGI compiler. That is, the parallel processing pattern creation unit 117 compiles the created C / C++ code using a PGI compiler on the verification machine 14 equipped with a GPU. Here, a compilation error may occur when multiple nested for statements are specified in parallel. In this case, the error is treated the same as when the processing time during performance measurement times out.

[0157] In step S124, the performance measurement unit 118 (see FIG. 1) deploys the executable file to the verification machine 14 equipped with a CPU and a GPU. In step S125, the performance measurement unit 118 executes the allocated binary file and measures the benchmark performance when offloaded.

[0158] Here, in intermediate generations, genes with the same pattern as before are not measured, and the same values ​​are used. In other words, if a gene with the same pattern as before is generated during the GA process, the individual is not compiled or its performance is not measured, and the same measured values ​​as before are used.

[0159] In step S127, the performance measurement unit 118 (see FIG. 1) measures the processing time.

[0160] In step S128, the performance measurement unit 118 sets an evaluation value based on the measured processing time.

[0161] In step S129, the executable file creation unit 119 (see FIG. 1) evaluates the individual so that the shorter the processing time, the higher the fitness, and selects the individual with the highest performance. The executable file creation unit 119 selects a pattern with a short processing time and low power consumption as a solution from the multiple measured patterns.

[0162] In step S130, the executable file creation unit 119 performs crossover and mutation processes on the selected individuals to create the next generation of individuals. The executable file creation unit 119 performs compilation, performance measurement, fitness setting, selection, crossover, and mutation processes on the next generation of individuals. That is, after benchmark performance measurement for all individuals, the fitness of each gene sequence is set according to the benchmark processing time. Individuals to be kept are selected according to the set fitness. The executable file creation unit 119 performs GA processing, including crossover, mutation, and direct copy, on the selected individuals to create the next generation of individuals.

[0163] In step S132, the executable file creation unit 119 determines the C / C++ code corresponding to the gene sequence with the highest performance (parallel processing pattern with the highest performance) as a solution after the GA processing for the specified number of generations is completed.

[0164] <GAのパラメータ> The above-mentioned number of individuals, number of generations, crossover rate, mutation rate, fitness setting, and selection method are GA parameters. The GA parameters may be set, for example, as follows: The parameters and conditions for the Simple GA to be executed can be, for example, as follows: Gene length: Number of parallelizable loop statements Number of individuals M: gene length or less Number of generations T: gene length or less Relevance: (processing time) (-1 / 2)

[0165] With this setting, the shorter the benchmark processing time, the higher the fitness. Also, by including the (-1 / 2) power of the processing time in the fitness calculation, it is possible to prevent the fitness of a specific individual with a short processing time from becoming too high, narrowing the search range. Also, if the performance measurement does not end within a certain time, a timeout is triggered, and the fitness is calculated assuming a processing time of 1000 seconds or the like (long time). This timeout period can be changed according to the performance measurement characteristics. Selection: Roulette selection However, elite preservation is also performed, in which the genes with the highest fitness in each generation are preserved in the next generation without crossover or mutation. Crossover rate Pc:0.9 Mutation rate Pm: 0.05

[0166] <Cost performance> This section discusses the cost-effectiveness of the automatic offloading function. Looking only at the hardware price of a GPU board such as NVIDIA Tesla, the price of a machine equipped with a GPU is approximately twice that of a normal CPU-only machine. However, in general, when it comes to costs for data centers, the costs of hardware and system development are less than one-third, operational costs such as electricity bills and maintenance and operation systems are more than one-third, and other costs such as service orders are about one-third. In this embodiment, the performance of time-consuming processes in applications such as encryption processing and image processing can be more than doubled. Therefore, even if the price of the server hardware itself doubles, sufficient cost effectiveness can be expected.

[0167] In this embodiment, applications with many loops and long execution times are identified in advance using gcov, gprof, etc., and offloading is attempted. This makes it possible to find applications that can be efficiently accelerated.

[0168] <Time until the start of production service> We will explain the time until the actual service can be used. If one performance measurement from compilation takes about three minutes, a GA with 20 individuals and 20 generations would take up to 20 hours to find a solution. However, because the compilation and measurement of the same genetic pattern as before is omitted, the solution can be completed in less than eight hours. In reality, many cloud, hosting, and network services require about half a day to start using the service. In this embodiment, automatic offloading is possible within half a day, for example. Therefore, if automatic offloading within half a day allows for trial use at first, it is expected that user satisfaction will be sufficiently increased.

[0169] To search for the offloaded portion in a shorter time, it is possible to measure performance in parallel using multiple verification machines, each corresponding to the number of individuals. Adjusting the timeout period depending on the application can also shorten the time. For example, a timeout period can be set if the offloaded processing takes twice as long as the CPU execution time. Furthermore, the greater the number of individuals and the number of generations, the greater the likelihood of finding a high-performance solution. However, maximizing each parameter requires compilation and performance benchmarking for the number of individuals multiplied by the number of generations. This increases the time required to start using the production service. In this embodiment, the GA is run with a small number of individuals and generations, but by setting the crossover rate Pc to a high value of 0.9 and searching a wide area, a solution with a certain level of performance can be found quickly.

[0170] [Expand directive] In this embodiment, directives are expanded to increase the number of applicable applications. Specifically, directives specifying GPU processing are expanded to include the parallel loop directive and the parallel loop vector directive in addition to the kernels directive. In the OpenACC standard, kernels are used for single loops and tightly nested loops. Parallel loops are used for loops including non-tightly nested loops. Parallel loop vectors are used for loops that cannot be parallelized but can be vectorized. Here, a tightly nested loop is a simple loop where, for example, when two loops that increment i and j are nested in a nested loop, processing using i and j is performed in the lower loop, but not in the upper loop. Also, in implementations such as the PGI compiler, the difference between kernels and parallel is that the decision to parallelize is made by the compiler, while the decision to parallelize is made by the programmer.

[0171] Therefore, in this embodiment, kernels are used for single, tightly nested loops, parallel loops are used for non-tightly nested loops, and parallel loop vectors are used for loops that cannot be parallelized but can be vectorized. There is a concern that using the parallel directive may result in less reliable results than with kernels. However, we plan to run a sample test on the final offload program, check the difference in results with the CPU, and show the results to the user for confirmation. Since CPUs and GPUs have different hardware, there are differences in the number of significant digits and rounding errors, so even with kernels, it is necessary to check the difference in results with the CPU.

[0172] [Flowchart for setting resource ratios and resource amounts, and deploying new applications] 10 is a flowchart illustrating the process of setting the resource ratio and resource amount added after a GPU offload attempt and the placement of a new application. The flowchart shown in FIG. 10 is executed after the GPU offload attempt shown in FIGS. 9A-B.

[0173] In step S51, the resource ratio determination unit 115 acquires the user operation conditions, the test case CPU processing time, and the offload device processing time. The user operation conditions are specified by the user when specifying the code that the user wants to offload. The resource amount setting unit 116 uses the user operation conditions when determining the resource amount by referring to the information in the facility resource DB 132.

[0174] <Processing of resource ratio determination unit 115> In step S52, the resource ratio determination unit 115 determines the ratio of the processing time between the CPU and the offload device (test case CPU processing time and offload device processing time) as the resource ratio based on the performance measurement results.

[0175] By using this automatic offloading, performance measurement results in the verification environment are already obtained when code conversion is performed. Using these performance measurement results, the resource ratio determination unit 115 determines the resource ratio between the CPU and the offload device. Specifically, it determines an appropriate resource ratio based on the ratio of the processing time between the CPU and the offload device in the verification environment. For example, if the test case processing time in the verification environment is 10 seconds for CPU processing and 5 seconds for GPU processing, the resource ratio is CPU:GPU=2:1.

[0176] The resource ratio determination unit 115 determines a resource ratio so that the processing times of the CPU and the offload device are of the same order. By determining the resource ratio so that the processing times of the CPU and the offload device are of the same order, the processing times of the CPU and the offload device can be made equal, and the amount of resources can be set appropriately even in a mixed environment where the CPU and accelerators are GPUs, FPGAs, many-core CPUs, etc.

[0177] If the difference in processing time between the CPU and the offload device is equal to or greater than a predetermined threshold, the resource ratio determination unit 115 sets the resource ratio to a predetermined upper limit. That is, if the difference in processing time between the CPU and the offload device in the verification environment is, for example, 10 times or more, setting the resource ratio to 10 times or more will lead to a deterioration in cost performance. In this case, for example, a resource ratio of 5:1 is set as the upper limit (the upper limit is a resource ratio of 5:1 in processing time). Setting an upper limit on the resource ratio makes it possible to prevent a significant increase in the number of VMs.

[0178] <Processing of resource amount setting unit 116> In step S53, the resource amount setting unit 116 sets the resource amount based on the user operation conditions and the appropriate resource ratio. That is, the resource amount setting unit 116 determines the resource amount while keeping the resource ratio as much as possible so as to satisfy the cost conditions specified by the user.

[0179] The resource amount setting unit 116 maintains an appropriate resource ratio and sets the maximum resource amount that satisfies the user's operational conditions. To give a specific example, assume that the appropriate resource ratio is 1,000 yen / month for one CPU VM and 4,000 yen / month for a GPU, with a resource ratio of 2:1, and that the user has a monthly budget of 10,000 yen or less. In this case, two CPUs and one GPU are allocated to the commercial environment.

[0180] If the user's operational conditions are not met even with the minimum resource amount that maintains the resource ratio, the resource amount setting unit 116 breaks the resource ratio and sets the resource amount for the CPU and offload device to the minimum so as to meet the cost conditions. To give a specific example, assume that the CPU 1VM costs 1,000 yen / month and the GPU costs 4,000 yen / month, a resource ratio of 2:1 is appropriate, and the user has a monthly budget of 5,000 yen or less. In this case, since the user's budget is insufficient, the resource ratio cannot be maintained, but the resource amount for the CPU and offload device is set smaller, i.e., 1 CPU and 1 GPU are allocated.

[0181] After the processing of step S53 above is completed and resources are secured and allocated in the commercial environment, the automatic verification described in Fig. 2 is executed to check performance and cost before the user uses the resources. This makes it possible to secure resources in the commercial environment, and after automatic verification, present the performance and cost to the user.

[0182] <Summary of resource ratio and resource amount settings> To optimize the resource ratio, performance measurement results are used when determining the offload pattern solution. For implementation, the resource ratio is determined based on the test case processing time so that the CPU and GPU processing times are of the same order. For example, if the test case processing time is 10 seconds for CPU processing and 5 seconds for GPU processing, the CPU resources are considered to be doubled to achieve approximately the same processing time, so the resource ratio is 2:1. Note that since the number of virtual machines, etc. is an integer, the resource ratio is rounded off to an integer when calculated from the processing time.

[0183] Once the resource ratio has been determined, the next step is to set the resource amount when deploying applications to a commercial environment. The implementation determines the resource amount by maintaining the resource ratio as much as possible and determining the number of VMs, etc., so as to satisfy the cost requirements specified by the user when requesting offloading. Specifically, the maximum number of VMs, etc. is selected while maintaining the resource ratio within the cost range.

[0184] For example, if a CPU costs 1,000 yen / month for one VM and 4,000 yen / month for a GPU, with a resource ratio of 2:1, and the user has a monthly budget of less than 10,000 yen, then 2 CPUs and 1 GPU are allocated. Also, if the resource ratio cannot be maintained within the cost range, the resource amounts are set starting from 1 CPU and 1 GPU unit to get as close to the appropriate resource ratio as possible. For example, if the monthly budget is less than 5,000 yen, then the resource ratio cannot be maintained, but 1 CPU and 1 GPU are allocated. Once the resource amount is set, the implementation allocates CPU and GPU resources, for example, using the virtualization functions of Xen Server.

[0185] In step S54, the placement setting unit 170 calculates and sets the placement destination of the new application (placement location of the APL) using a linear programming method based on the server and link specification information in the facility resource DB 132 and the placement information of the existing application.

[0186] [Optimal placement of converted applications] The offload server 1 of this embodiment optimizes the placement location of a CPU program when it is offloaded to a device such as a GPU so that the application meets the user's requirements for cost, etc., and operates with short response times, etc.

[0187] <Optimizing application placement> This embodiment assumes that applications can be deployed not only in the cloud but also at the network edge and user edge. However, compared to the cloud, the concentration of servers at the network edge and user edge is lower and they are more dispersed. For this reason, the cost of computing resources is higher than that of the cloud. That is, although the price of hardware such as CPUs and GPUs is generally constant regardless of the location, the data center that operates the cloud can collectively monitor and control the air conditioning of the aggregated servers, which results in lower operating costs. For example, a simple topology of computing node links is shown in FIG.

[0188] Fig. 11 is a diagram showing an example of a topology of a computing node. Fig. 11 shows a topology used in IoT systems, where data is sent from IoT devices that collect data in a user environment to a user edge, and then sent to a cloud via a network edge, where the analysis results are viewed by company executives.

[0189] As shown in Figure 11, the topology in which applications are deployed is composed of three layers, with the number of locations in the cloud layer (e.g., data center) being "2" (n13, n14), the number of locations in the carrier edge layer (e.g., exchange) being "3", the number of locations in the user edge layer (e.g., user environment) being "4" (n6-n9), and the number of locations in the input node being "5" (n1-n5). In anticipation of applications such as IoT, IoT data (such as pollen sensors and body temperature sensors, which are IoT devices) is collected from the input node to the user edge, and depending on the characteristics of the application (such as response time requirements), analysis is performed at the user edge or carrier edge, or the data is uploaded to the cloud for further analysis. The output node is "1" (n15), and the analysis results are viewed by company executives. For example, if the input node is IoT data (pollen sensor), the statistical and analytical results of the output node are reviewed by a person in charge at the Japan Meteorological Agency. 11 is just an example, and the arrangement topology may be, for example, five layers. In reality, the number of user edges and carrier edges may be several tens to several hundreds.

[0190] Computing nodes are divided into three types: CPU, GPU, and FPGA. Nodes equipped with GPUs or FPGAs also have a CPU, but they are provided as GPU instances or FPGA instances that also include CPU resources using virtualization technology (e.g., NVIDIA vGPU).

[0191] Applications are deployed in the cloud, carrier edge, or user edge, and the closer to the user environment, the shorter the response time becomes, but the higher the cost of computational resources becomes. In this embodiment, applications converted for GPUs or FPGAs are deployed, and when deploying them, users can issue two types of requests. The first is a cost requirement, which specifies the allowable cost of computing resources to run an application, such as running it for less than 5,000 yen per month. The second is a response time requirement, which specifies the allowable response time when running an application, such as returning a response within 10 seconds. In traditional facility design, for example, the location of a server that accommodates a virtual network is planned based on long-term trends such as traffic growth.

[0192] This embodiment has the following features (1) and (2): (1) The applications to be deployed are not statically determined, but are automatically converted for GPU or FPGA, and patterns suitable for the usage are extracted through actual measurements using GA, etc. Therefore, the code and performance of the application can change dynamically. (2) It is not enough to reduce only the carrier's equipment costs and overall response time; it is also necessary to satisfy individual user requirements for the cost of computing resources and response time. In addition, application placement policies can change dynamically.

[0193] Taking into account the above features (1) and (2), application placement in this embodiment involves converting an application when a user requests placement, and then sequentially placing the converted application on the appropriate server at that time. If converting an application does not improve cost performance, the application before conversion is placed. For example, if a GPU instance costs twice as much as a CPU instance, and conversion does not improve performance by more than two times, it is better to place the application before conversion. Also, if the computational resources and bandwidth have already been used up to their limits, placement on that server may not be possible.

[0194] <Linear programming formula for optimal application placement> In this embodiment, a linear programming method is formulated to calculate an appropriate placement location for an application. Specifically, the linear programming method uses parameters of the linear programming formulas shown in [Formula 1] (the following formulas (1) to (4)) and [Formula 2] (the following formulas (3) to (6)).

[0195] Here, the cost of devices and links, the upper limits of computational resources, and the upper limits of bandwidth depend on the servers and networks prepared by the service provider. Therefore, these parameter values ​​are set in advance by the service provider. The amount of computational resources, bandwidth, data capacity, and processing time used by the application when offloaded are determined by the measured values ​​in the offload pattern finally selected in tests in the verification environment before automatic conversion, and are automatically set by the environment adaptation function. Depending on whether the user request is a cost request for a computational resource or a response time request, the objective function and constraint conditions in the parameters of the linear programming equation change.

[0196] - Linear programming parameters based on cost requirements If the cost requirement requires placement within a certain amount per month, the parameters of the linear programming formula shown below in [Formula 1] are used.

[0197]

number

[0198] The objective function is to minimize the response time in equation (1). The cost of the computational resources in equation (2) is one of the constraints. In addition, there are additional constraints, such as whether the server resource limit is exceeded in equations (3) and (4).

[0199] · Linear programming parameters based on response time requirements If the response time requirement requires placement within a certain number of seconds of the application response time, the parameters of the linear programming formula shown in the following [Formula 2] are used.

[0200]

number

[0201] The objective function is to minimize the cost of computational resources in equation (5), which corresponds to equation (2). The response time in seconds in equation (6), which corresponds to equation (1), is one of the constraints. In addition, the constraints in equations (3) and (4) are also added.

[0202] ·Explanation of parameters in linear programming equations Equations (1) and (6) are equations for calculating the response time of application k. In the case of equation (1), Rk is the objective function, and in the case of equation (6), Rk is the constraint that sets the upper limit specified by the user.

[0203] Equations (2) and (5) are equations for calculating the cost (price) Pk of running application k. In the case of equation (2), Pk is a constraint that sets an upper limit specified by the user, and in the case of equation (5), Pk is an objective function.

[0204] Equations (3) and (4) are constraints that set upper limits on computational resources and communication bandwidth. They are calculated including applications deployed by others, and prevent the resource limits from being exceeded by the deployment of an application by a new user.

[0205] The appropriate application placement can be calculated by deriving solutions to the linear programming equations (1) to (4) and (3) to (6) using a linear programming solver such as GLPK (Gnu Linear Programming Kit) or CPLEX (IBM Decision Optimization) for different conditions such as network topology, converted application type (cost increase and performance increase for CPU, etc.), user requirements, and already deployed applications. After the appropriate placement calculation, actual placement is performed sequentially for multiple users, and multiple applications are placed based on the requirements of each user.

[0206] As described above, when a new application placement request is made, calculations are made based on linear programming formulas and the applications are placed in order, thereby enabling placement that satisfies the user's requests. Here, application programs are placed sequentially on a first-come, first-served basis, but the optimal placement of already placed application programs is recalculated periodically, for example, every 100 applications. Then, the placement that minimizes the objective function is calculated according to the cost and response time specified by the user, and the applications can be relocated to the positions determined by the calculation.

[0207] [evaluation] We confirmed that multiple applications were properly deployed by changing several conditions using the free solver GLPK (registered trademark) based on a linear programming equation, which is one type of linear programming method.

[0208] <Evaluation conditions> Target applications The application to be deployed performs image processing using Fourier transform, which is expected to be used by many users. Fourier transform processing (FFT) is used in various situations in IoT monitoring, such as analyzing vibration frequencies. NAS.FT (https: / / www.nas.nasa.gov / publications / npb.html) (registered trademark) is an open-source application for FFT processing. It performs calculations on the built-in sample test of 2048 x 2048 size. When considering IoT applications that transfer data from devices over a network, it is expected that the device will perform primary analysis such as FFT processing before sending the data to reduce network costs.

[0209] MRI-Q (http: / / impact.crhc.illinois.edu / parboil / ) (registered trademark) calculates the matrix Q that represents the scanner configuration for calibration used in 3D MRI reconstruction algorithms in non-Cartesian space. In IoT environments, image processing is often required for automatic monitoring from camera videos, and there is a need for automatic offloading of image processing. MRI-Q is a C application that executes 3D MRI image processing during performance measurement, measuring processing time using large 64x64x64 sample data. CPU processing is written in C, and FPGA processing is based on OpenCL (registered trademark). Using the GPU and FPGA automatic offloading technology of this embodiment, NAS.FT can be accelerated using a GPU, and MRI-Q can be accelerated using an FPGA, which are 5 times and 7 times faster than a CPU, respectively.

[0210] Evaluation method The topology for deploying applications is composed of three layers as shown in Figure 11, with five cloud layer locations, 20 carrier edge layers, 60 user edge layers, and 300 input nodes. Assuming applications such as IoT, IoT data is collected from the input node to the user edge, and depending on the characteristics of the application (such as response time requirements), analysis is performed at the user edge or carrier edge, or the data is uploaded to the cloud for analysis and processing.

[0211] Based on the parameters of the linear programming formula shown in [Formula 1] and [Formula 2], for example, 1,000 applications are deployed based on user requirements. The applications are IoT applications that are assumed to analyze data generated from input nodes. Deployment requests are generated randomly from the input nodes (assuming there are 300 of them). For example, the number of placement requests is NAS.FT:MRI-Q = 3:1, and 1,000 placement requests are made for the application. Furthermore, when making a placement request, a price condition or a response time condition is selected for each application as a user requirement. For NAS.FT, the maximum price is set to 7,000 yen, 8,500 yen, or 10,000 yen per month, and the maximum response time is set to 6 seconds, 7 seconds, or 10 seconds. For MRI-Q, the maximum price is set to 12,500 yen or 20,000 yen per month, and the maximum response time is set to 4 seconds or 8 seconds.

[0212] There are three variations in user requests. Pattern 1: In NAS.FT, 1 / 6 of the 6 types of requests are selected, and in MRI-Q, 1 / 4 of the 4 types of requests are selected. Pattern 2: The request selects the condition with the lowest price as the upper limit (first 7,000 yen, then 12,500 yen), and if there are no vacancies, the next lowest price condition is used. Pattern 3: The request selects the condition with the upper limit of the minimum response time (first 6 seconds, then 4 seconds), and if there is no availability, the next fastest response time condition is used. An example of applying a user request to NAS.FT and MRI-Q will be described later.

[0213] Placement simulation The placement is performed through simulation experiments using the solver GLPK5.0 (registered trademark) as an evaluation tool. The simulation uses an evaluation tool to simulate large-scale network placement. During actual use, when an application offload request is received, an offload pattern is created through repeated performance tests using a verification environment, and the appropriate amount of resources is determined based on the results of the performance test in the verification environment (see Figure 10). Then, an appropriate placement is determined using GLPK or similar software in response to the user's request, and normality confirmation tests and performance tests are automatically performed upon actual deployment. The results and price are presented to the user, and use begins after the user makes a decision.

[0214] Figure 12 is a graph showing the change in the number of deployed applications over the average response time. Figure 12 shows the average response time and the number of deployed applications for the above three patterns. It was confirmed that in pattern 2, the cloud is filled first, and in pattern 3, the edge is filled first. In pattern 1, when various requests come in, the allocation is done to meet the user requirements. As shown in Figure 12, in Pattern 2, up to about 400 placements, all are placed in the cloud, and the average response time remains the slowest, but as the cloud fills up, it gradually decreases. In pattern 3, NAS.FT is deployed from the user edge, and MRI-Q is deployed from the carrier edge. This results in the shortest average response time. However, as the number increases, they are also deployed in the cloud, which slows the average response time. In pattern 2, the average response time is between that of patterns 1 and 3, and they are deployed according to user requests. Therefore, in pattern 2, the average response time is appropriately reduced compared to pattern 1, where everything is initially deployed in the cloud.

[0215] In this way, software is automatically adapted to the deployment environment, and when it is automatically offloaded to a GPU, etc., it meets the user's cost and response time requirements. In other words, the program is converted so that it can be processed by a device such as a GPU, and after the amount of resources to be assigned is determined, the converted application is optimally deployed.

[0216] In summary, first, the application's data usage, amount of computational resources, bandwidth, and processing time are set from data from performance tests conducted in a verification environment during program conversion. The appropriate placement of applications is calculated based on linear programming equations using values ​​set for each converted application and values ​​such as pre-set server and link costs. When placing applications, the user specifies price and response time requests, with one side acting as a constraint and the other as an objective function. The linear programming solver calculates the appropriate placement, and the proposed method presents the user with the price and other information for placing resources in the calculated location, and usage begins after the user agrees.

[0217] For applications automatically offloaded to GPUs and FPGAs, the system calculates the optimal placement by changing the price conditions, response time conditions, number of applications to be placed, etc. requested by the user. This makes it possible to place applications in accordance with user requests.

[0218] The above describes the placement of applications after automatic conversion, with individual optimal placement according to the requirements of each individual user. Below, we will explain the overall optimal placement that takes into account the placement status of other users.

[0219] [Application deployment reconfiguration] <Need for reconfiguration> The need for reconstruction is discussed. The computational node link assumes a three-layer topology consisting of user edge, carrier edge, and cloud (see Figure 11, etc.). Computational nodes are divided into three types: CPU, GPU, and FPGA. Nodes equipped with GPUs or FPGAs are provided as GPU or FPGA instances using virtualization technology, including CPU resources. For example, the placement of servers accommodating virtual networks was planned based on long-term trends such as traffic increases. In contrast, adaptive software has two distinct features. First, placement applications are not statically determined; they are automatically converted for GPUs and FPGAs, and patterns suited to usage patterns are extracted through actual measurements using genetic algorithms and other methods. This means that application code and performance can change dynamically. Second, application placement policies can change dynamically, as it is not enough to simply reduce carrier equipment costs and overall response time; individual user requirements for response time and price must be met.

[0220] Taking these two characteristics into consideration, we have described a linear programming method for calculating placement that satisfies the user's response time and price requirements. Specifically, this linear programming method uses the linear programming parameters shown in [Equation 1] (the above equations (1) to (4)) and [Equation 2] (the following equations (3) to (6)). When a user requests placement of an application, the response time and price of the converted application are formulated, and either the response time or the price is minimized as the objective function.

[0221] However, if applications are allocated according to the response time and price requirements of individual users, it is basically a first-come, first-served basis. For example, if only low cost is prioritized, the cloud will be filled up, and if only speed is prioritized, the edge will be filled up. Once the cloud or edge is filled up, it will be necessary to allocate applications to another server. Therefore, in order to alleviate this first-come, first-served allocation, allocation reconfiguration is carried out not only before operation starts but also after operation starts. In this embodiment, the layout is reconfigured after the start of operation, thereby improving the satisfaction of multiple users who are the targets of the reconfiguration.

[0222] <Formulation of linear programming method> In this embodiment, a reconfiguration method for reconfiguring an application to an appropriate location, taking into account the deployment status of other users, will be described. The formulation of a linear programming method will also be described. The reconstruction is carried out using the following method. For each allocation of a certain number of applications (e.g., 100 applications), trial calculations are performed to reconfigure the allocation of a certain number of applications (all applications or 100 applications, etc.) in a way that satisfies the initial requirements of multiple users. This improves the satisfaction of user groups determined by changes in response time and price. Reconfiguration is performed only if the trial calculations for reconfiguration show that the effect of reconfiguration is high, such as when the change in satisfaction exceeds a certain threshold. Since actual reconfiguration requires changing the application execution server, methods such as live migration are used to minimize the impact on users. The linear programming formula and parameters for reconfiguration are shown in the following formula (7), as well as the formulas (1), (5), (3), and (4).

[0223]

number

[0224] Equation (1) expresses the response time R k The response time before reconfiguration is R k before The response time after the reconfiguration is called R k after It is called. Equation (5) expresses the price Pk of the placement application. The price before reconfiguration is Pk before The price after reconstruction is called P k after It is called. Equations (1) and (5) can be constraints or objective functions depending on the response time and price requirements of the user requesting application placement (see below). Furthermore, whether the server resource limits in equations (3) and (4) are exceeded is added as a constraint.

[0225] First, the new layout is performed according to formulas (1), (5), (3), and (4). When placing a request, the user can specify either or both of the response time and price requirements. k upper (where upper is a general term for superscripts) or price request P k upper or both. k When upper is specified, R in formula (1) k ≦R k The upper is the constraint, and equation (5) is the objective function. P k When upper is specified, P in formula (5) k ≦P k The upper is the constraint, and equation (1) is the objective function. k upper and P k When both upper and lower are specified, R in Eq. (1) k ≦R k upper, P in Eq. (5) k ≦P kBoth upper and lower are constraints, and R in Eq. (1) k and P in equation (5) k The user specifies which of the following is the objective function to be minimized. Equations (3) and (4) are constraints in both cases.

[0226] Equations (3) and (4) are constraints that set the upper limit of computational resources and communication bandwidth. They are calculated including applications deployed by other users, and prevent the resource limit from being exceeded by the deployment of a new user's application. New deployment is performed by sequentially calculating equations (1), (5), (3), and (4) in response to a user's deployment request.

[0227] <Reconfiguration> Next, a description will be given of reconfiguration for an overall optimal placement that takes into account the placement status of other users. The reconstruction is calculated according to equations (7), (1), (5), (3), and (4), but in particular, a new calculation of the value S corresponding to the user satisfaction level in equation (7) is added. As the satisfaction of individual users, the response time before reconfiguration is set as 1 point and the price as 1 point. k before is the response time after reconstruction R k after If the response time is increased by X times, X is the value related to the response time satisfaction. Also, the price before reconfiguration P k before is the reconstructed price P k after If the price is increased by Y times, Y is the value related to price satisfaction.

[0228] The objective function of the reconfiguration trial calculation is a value related to the user group satisfaction of a certain number of applications to be reconfigured, and the allocation that minimizes the sum of (X + Y) for multiple applications is calculated. The specific content of the objective function is the value S corresponding to the user satisfaction in equation (7). Furthermore, if the user specifies only one of the constraints at the time of new placement, only one of the formulas (1) and (5) is specified in the application.

[0229] Based on the linear programming equations (7), (1), (5), (3), and (4), the effect of the reconstruction is calculated by deriving a solution using a linear programming solver such as GLPK (registered trademark) or CPLEX (IBM Decision Optimization) (registered trademark).

[0230] The number of applications to be reconfigured is a fixed value, and may not be all applications. The solver calculation time increases as the number of applications to be reconfigured increases. Therefore, the setting of the fixed number of applications is variable, and optimization of 100 applications for every 100 placements or optimization of all applications at once is determined by adjusting the size according to the solver calculation time.

[0231] [evaluation] <Evaluation conditions> Target applications The deployment application will be Fourier transform and image processing, which are expected to be used by many users. Fourier transform processing FFT (Fast Fourier Transform) is used in various IoT monitoring situations, such as vibration frequency analysis. NAS.FT (registered trademark) is one of the open source applications for FFT processing. It will perform calculations on the built-in sample test with a size of 2048 x 2048. MRI-Q (registered trademark) calculates the matrix Q, which represents the scanner configuration for calibration used in 3D MRI reconstruction algorithms in non-Cartesian space. During performance measurement, MRI-Q executes 3D MRI image processing and measures processing time using large 64x64x64 sample data.

[0232] This GPU and FPGA automatic offloading technology enables NAS.FT to be accelerated using GPUs, and MRI-Q to be accelerated using FPGAs, achieving 5x and 7x the performance, respectively, of a CPU.

[0233] [evaluation] <Evaluation method> The evaluation method will be explained. The topology in which applications are deployed is composed of three layers as shown in Figure 11, with five cloud layer locations, 20 carrier edge layers, 60 user edge layers, and 300 input nodes. At each site, the cloud will have eight CPU servers, four GPUs with 16GB RAM, and two FPGAs. The carrier edge will have four CPU servers, two GPUs with 8GB RAM, and one FPGA. The user edge will have two CPU servers and one GPU with 4GB RAM.

[0234] The monthly costs for using all resources of one server (GPU with 16GB RAM) are set at 50,000 yen, 100,000 yen, and 120,000 yen for the cloud. Due to the aggregation effect, the carrier edge and user edge are more expensive, and the monthly costs are set at 1.25 and 1.5 times that of the cloud. For links, a bandwidth of 100Mbps is secured between the cloud and carrier edge, and 10Mbps between the carrier edge and user edge. For link costs, a 100Mbps link costs 8,000 yen per month, and a 10Mbps link costs 3,000 yen per month.

[0235] The resources used by the applications, such as processing time, are values ​​actually used when offloading to the GPU and FPGA. For NAS.FT, the resource usage is 1GB of GPU RAM, 2Mbps bandwidth, 0.2MB of transferred data, and 5.8 seconds of processing time. For MRI-Q, the resource usage is 10% of the FPGA server (the number of flip flops, look up tables, etc. used is the FPGA resource usage), 1Mbps bandwidth, 0.15MB of transferred data, and 2.0 seconds of processing time.

[0236] First, 900 new applications will be deployed. The application is assumed to analyze data generated from the input nodes, and placement requests are randomly generated from 300 input nodes. The ratio of placement requests is NAS.FT:MRI-Q = 3:1, and the application is placed 900 times.

[0237] When requesting placement, users can select either price or response time, or both, as requirements. For NAS.FT, the price limit can be set to a maximum of 7,500 yen (a), 8,500 yen (b), or 10,000 yen (c) per month, and the response time limit can be set to 6 seconds (A), 7 seconds (B), or 10 seconds (C). For MRI-Q, the price limit can be set to a maximum of 12,500 yen (x) or 20,000 yen (y) per month, and the response time limit can be set to 4 seconds (X) or 8 seconds (Y).

[0238] In NAS.FT, for example, assume that there are 12 types of user requests: request a, request b, request c, request A, request B, request C, request aC, request bB, request bC, request cA, request cB, and request cC. In MRI-Q, for example, assume that there are 7 types of user requests: request x, request y, request X, request Y, request xY, request yX, and request yY. As user requests, NAS.FT selects user requests a, b, c, A, B, C, aC, bB, bC, cA, cB, cC with a probability of 1 / 12 each, while MRI-Q selects user requests x, y, X, Y, xY, yX, yY with a probability of 1 / 7 each. When the user upper limit request is one index, minimizing another index becomes the objective function, and when there are two indexes, one is randomly selected and its minimization becomes the objective function. After the above 900 applications are deployed, a certain number of applications are reconfigured every 100 applications. The number of deployed applications in each deployment cycle is fixed at 100, but the number of reconfigured applications is varied to 100, 200, and 400 applications, and user satisfaction is calculated.

[0239] <Flowchart> FIG. 13 is a flowchart of the reconfiguration for the overall optimal placement taking into consideration the placement status of other users. In step S61, the allocation reconfiguration unit 180 determines whether or not to perform reconfiguration after the start of operation. A method for determining whether to perform reconfiguration after the start of operation will now be described. The cloud or edge service provider can decide and set whether to perform a reconfiguration calculation, for example, every 100 application deployments, and the reconfiguration unit 180 (FIG. 16) can be started and perform the reconfiguration calculation every determined number of deployments. If the result of the reconfiguration calculation shows that the average value of S does not fall below 2, no improvement will be made and so no reconfiguration will be performed. Alternatively, a threshold may be set, such that reconfiguration will only be performed when the average value of S is 2 or less. When reconfiguring after the start of operation, the arrangement reconfiguration unit 180 acquires individual user arrangement information in step S62. In step S63, the placement reconfiguration unit 180 derives a solution using a linear programming solver such as GLPK (registered trademark) or CPLEX (IBM Decision Optimization) (registered trademark) based on the linear programming equations (7), (1), (5), (3), and (4), thereby calculating the effect of the reconfiguration and ending the processing of this flow.

[0240] <Result> The experiment was performed by simulation using the solver GLPK5.0 (registered trademark). Regarding calculation time, new placement only requires sequential calculation and placement of a total of 500 items, which takes less than one minute. On the other hand, the reconfiguration time increases as the number of applications to be reconfigured increases, resulting in an increase in the number of linear programming conditional expressions. However, with 100 applications, the reconfiguration time is less than 10 seconds, and even with 400 applications, it is completed in less than one minute.

[0241] 14 is a graph showing the change in the number of actually configured applications. The horizontal axis represents the number of applications to be reconfigured, and the vertical axis represents the number of applications that were actually reconfigured. As shown in Figure 14, although there is some variation, it can be seen that approximately 10% of the applications targeted for reconfiguration were actually reconfigured. In new placement, an optimal placement is individually performed for each application, but in reconfiguration, by calculating the optimal placement for multiple applications at once, it can be seen that to a certain extent applications that can be reconfigured can be found.

[0242] Figure 15 shows the R of the reconstructed application. k after / R k before +P k after / P k before The graph shows the change in the R of the reconfigured applications. k after / R k before +P k after / P k before The vertical axis shows the average value of As shown in Figure 15, the reconfigured application is k after / R k before +P k after / P k before It can be seen that the average has improved to about 1.96. This value is not a significant improvement from 2, but for example, when NAS.FT is relocated from the carrier edge to the cloud, the response time goes from 6.6 seconds to 7.4 seconds, but the price goes from approximately 8,400 yen to approximately 7,000 yen, so the value goes from 2 to 1.954. As shown in Figure 15, this value is almost constant regardless of the number of applications to be reconfigured, which shows that it is not necessary to target all applications for reconfiguration.

[0243] <Consideration> We have explained above the method for reconfiguring to achieve an overall optimal placement by taking into account the placement status of other users. As shown in Figures 14 and 15, the effectiveness of in-operation reconfiguration was confirmed. In addition to placement, in-operation reconfiguration can also be used to change the offload logic to GPUs or FPGAs, change the resource balance, etc., widening the scope of environmental adaptation in response to operational changes. By using the above-mentioned overall optimization method that takes into account the placement status of other users, even applications that were individually placed optimally at the time of new placement can be reconfigured, and approximately 10% of applications can be reconfigured using R kafter / R k before +P k after / P k before is set to 2 or less, allowing for improvements in indicators directly linked to satisfaction such as response time and price even after operation has begun. Because this value is nearly constant regardless of the number of reconfiguration targets, and because the calculation time does not increase significantly even if the number of reconfiguration targets increases, it is thought that the number of reconfiguration calculations, etc., can be set according to the business timing of obtaining reconfiguration proposals and permission from users of the application to be reconfigured. When new deployments are made, deployments can be made in accordance with user requests compared to naive deployments to the cloud or edge, so new deployments and post-launch reconfigurations enable operation with high user satisfaction.

[0244] <Summary> In this way, as a new element of environmentally adaptive software, we have realized a reconfiguration method that improves the satisfaction of target users by taking into account the app placement status of other users and rearranging apps after operation begins. In summary, this reconfiguration method uses linear programming techniques to perform trial calculations with the objective function of improving user satisfaction for the application to be reconfigured. Specifically, after satisfying the user response time and price requirements, the method calculates user satisfaction determined from the response time and price when reconfigured, and uses a linear programming solver to find a solution for the multiple applications to be reconfigured. Simulation experiments were conducted assuming multiple types of applications, and the improvement in user satisfaction when reconfigured using this reconfiguration method was confirmed, confirming its effectiveness.

[0245] (Second embodiment) Next, the offload server 1A and the like in the second embodiment of the present invention will be described. The second embodiment is an example in which the present invention is applied to automatic FPGA offloading of loop statements. In this embodiment, an example will be described in which the present invention is applied to an FPGA (Field Programmable Gate Array) as a PLD (Programmable Logic Device), but the present invention is applicable to programmable logic devices in general.

[0246] (Explanation of the principle) Because it is difficult to predict which loops will be faster when offloaded to an FPGA, we propose automatic measurement in a verification environment similar to that for GPUs. However, since it takes several hours or more to compile OpenCL and run it on an FPGA, repeated measurements using GA with GPU automatic offloading would require enormous processing time and are not possible. Therefore, we narrow down the loop statements that are candidates for offloading to the FPGA before performing measurements. Specifically, we use an arithmetic intensity analysis tool such as ROSE (registered trademark) to extract loop statements with high arithmetic intensity from the discovered loop statements. Furthermore, we use a profiling tool such as gcov (registered trademark) to extract loop statements with a high number of loops.

[0247] Loop statements with high arithmetic intensity or loop counts are selected as candidates for conversion to OpenCL. When converting to OpenCL, the CPU processing program is divided into the kernel (FPGA) and host (CPU) according to the OpenCL grammar. The OpenCL created for the candidate loop statements is precompiled to find loop statements with high resource efficiency. This is because the resources to be created are known during compilation, so loop statements can be further narrowed down to those that use sufficiently few resources. Several candidate loop statements remain, and these are used to measure performance and power consumption. The selected single loop statements are compiled and measured, and for those single loop statements that can be further accelerated, combination patterns are created and a second measurement is performed. From the multiple patterns measured, the pattern with the shortest time and lowest power consumption is selected as the solution.

[0248] Regarding FPGA offloading of loop statements, we narrow down the options using arithmetic strength, etc., then perform measurements and improve the evaluation value of low-power patterns to automatically increase speed and reduce power consumption.

[0249] FIG. 16 is a functional block diagram showing a configuration example of an offload server 1A according to the second embodiment of the present invention. In the description of this embodiment, the same components as those in FIG. 1 are denoted by the same reference numerals, and the description of overlapping parts is omitted. The offload server 1A is a device that automatically offloads specific processing of an application to an accelerator. Also, the offload server 1A can be connected to an emulator. As shown in FIG. 16, the offload server 1A includes a control unit 21, an input / output unit 12, a storage unit 13, and a verification machine 14 (Verification machine) (device for accelerator verification).

[0250] The control unit 21 is an automatic offloading function unit that controls the entire offload server 1A. The control unit 21 is realized, for example, by a CPU (not shown) expanding and executing a program (offloading program) stored in the storage unit 13 in the RAM.

[0251] The control unit 21 includes an application code specifying unit (Specify application code) 111, an application code analyzing unit (Analyze application code) 112, a PLD processing specifying unit 213, an arithmetic intensity calculating unit 214, an arrangement setting unit 170, an arrangement reconfiguration unit 180, a PLD processing pattern creating unit 215, a performance measuring unit 118, an execution file creating unit 119, a production environment deployment unit (Deploy final binary files to production environment) 120, a performance measurement test extraction execution unit (Extract performance test cases and run automatically) 121, and a user providing unit (Provide price and performance to a user to judge) 122.

[0252] <PLD processing specifying unit 213> The PLD processing specification unit 213 identifies loop statements (repeated statements) of the application, and for each identified loop statement, creates and compiles a plurality of offload processing patterns that specify pipeline processing and parallel processing in the PLD using OpenCL. The PLD processing designation unit 213 includes an offloadable area extraction unit (Extract offloadable area) 213a and an intermediate language file output unit (Output intermediate file) 213b.

[0253] The offload range extraction unit 213a identifies processes that can be offloaded to FPGA, such as loop statements and FFT, and extracts intermediate languages ​​corresponding to the offloaded processes.

[0254] The intermediate language file output unit 213b outputs the extracted intermediate language file 133. The intermediate language extraction is not completed once and for all, but is repeated to perform trial and error execution and optimize the search for an appropriate offload area.

[0255] <Arithmetic strength calculation unit 214> The arithmetic intensity calculation unit 214 calculates the arithmetic intensity of a loop statement in an application using an arithmetic intensity analysis tool such as the ROSE framework (registered trademark). The arithmetic intensity is the number of floating point operations (FN) executed during program execution divided by the number of bytes accessed in main memory (FN operations / memory accesses). Arithmetic intensity is an index that increases with the number of calculations and decreases with the number of accesses, and processes with high arithmetic intensity are heavy on the processor. Therefore, an arithmetic intensity analysis tool is used to analyze the arithmetic intensity of loop statements. The PLD processing pattern creation unit 215 narrows down loop statements with high arithmetic intensity to offload candidates.

[0256] An example of calculating the arithmetic strength is given below. Assume that in one loop, floating-point calculation processing is performed 10 times (10 FLOP), and the data used in the loop is 2 bytes. When data of the same size is used for each loop, the arithmetic intensity is 10 / 2 = 5 [FLOP / byte]. Note that since the loop count is not considered in the arithmetic intensity, in this embodiment, in addition to the arithmetic intensity, the loop count is also considered for narrowing down.

[0257] <PLD processing pattern creation unit 215> Based on the arithmetic intensity calculated by the arithmetic intensity calculation unit 214, the PLD processing pattern creation unit 215 narrows down loop statements with an arithmetic intensity higher than a predetermined threshold (hereinafter, appropriately referred to as high arithmetic intensity) as offload candidates, and creates a PLD processing pattern. Also, as a basic operation, the PLD processing pattern creation unit 215 creates a PLD processing pattern that excludes loop statements (iteration statements) that cause compilation errors from being offloaded targets, and designates whether to perform PLD processing on iteration statements that do not cause compilation errors.

[0258] · Loop count measurement function As a loop count measurement function, the PLD processing pattern creation unit 215 measures the loop count of the loop statements of the application using a profiling tool, and narrows down loop statements with high arithmetic intensity and a loop count greater than a predetermined number (hereinafter, appropriately referred to as high loop count) among the loop statements. To grasp the loop count, gcov of GNU coverage or the like is used. As profiling tools, "GNU profiler (gprof)" and "GNU coverage (gcov)" are known. Since both can investigate the execution count of each loop, either can be used.

[0259] Also, in arithmetic intensity analysis, the loop count is not particularly visible. Therefore, to detect loops with a large loop count and high load, a profiling tool is used to measure the loop count. Here, the height of the arithmetic intensity represents whether the processing is suitable for offloading to the FPGA, and the loop count × arithmetic intensity represents whether the load related to offloading to the FPGA is high.

[0260] OpenCL (intermediate language) creation function The PLD processing pattern creation unit 215, as an OpenCL creation function, creates OpenCL for offloading each of the narrowed-down loop statements to the FPGA (OpenCLization). That is, the PLD processing pattern creation unit 215 compiles OpenCL for offloading the narrowed-down loop statements. The PLD processing pattern creation unit 215 also lists loop statements that have higher performance than the CPU among the performance measurements, and combines the loop statements in the list to create OpenCL for offloading.

[0261] We will discuss OpenCL conversion. The PLD processing pattern creation unit 215 converts the loop statement into a high-level language such as OpenCL. First, the CPU processing program is divided into the kernel (FPGA) and the host (CPU) according to the grammar of the high-level language such as OpenCL. For example, if one of ten "for" statements is to be processed by FPGA, that one is extracted as a kernel program and written according to the grammar of OpenCL. An example of the grammar of OpenCL will be described later.

[0262] Furthermore, when dividing, techniques for further speedup can be incorporated. Generally, techniques for speedup using FPGAs include local memory cache, stream processing, multiple instantiation, loop unrolling, merging nested loops, and memory interleaving. These techniques are often used to speed up the process, although they may not be absolutely effective for some loops.

[0263] Kernels written according to the OpenCL C language syntax are executed on a device (e.g., FPGA) by a host (e.g., CPU) program using the OpenCL C language runtime API. The kernel function hello() is called from the host by calling clEnqueueTask(), one of the OpenCL runtime APIs. The basic flow of OpenCL initialization, execution, and termination written in the host code consists of the following steps 1 to 13. Of these steps 1 to 13, steps 1 to 10 are the procedure (preparation) until the kernel function hello() is called from the host side, and step 11 is the execution of the kernel.

[0264] 1. Platform Identification The platform on which OpenCL runs is identified using the function clGetPlatformIDs(), which provides platform identification functionality defined in the OpenCL runtime API.

[0265] 2. Device Identification The device such as a GPU to be used on the platform is identified using the function clGetDeviceIDs(), which provides device identification functionality defined in the OpenCL runtime API.

[0266] 3. Creating a context An OpenCL context, which is the execution environment for running OpenCL, is created using the function clCreateContext(), which provides a context creation function defined in the OpenCL runtime API.

[0267] 4. Create a command queue A command queue is created in preparation for controlling the device using the clCreateCommandQueue() function, which provides the command queue creation functionality defined in the OpenCL runtime API. In OpenCL, the host issues commands to the device (issuing kernel execution commands and memory copy commands between the host and device) through the command queue.

[0268] 5. Create a memory object A memory object that allows the host to reference the memory object is created using the function clCreateBuffer(), which provides the functionality to allocate memory on the device defined in the OpenCL runtime API.

[0269] 6. Loading the kernel file The execution of the kernel executed on the device is controlled by the host program. For this reason, the host program must first load the kernel program. The kernel program can be binary data created by the OpenCL compiler or source code written in OpenCL C. This kernel file is loaded (description omitted). Note that the OpenCL runtime API is not used when loading the kernel file.

[0270] 7. Create a program object In OpenCL, a kernel program is recognized as a program object, and this procedure is called program object creation. Create a program object that allows you to reference a memory object from the host side using the clCreateProgramWithSource() function, which provides program object creation functionality defined in the OpenCL runtime API. To create a program object from a compiled binary sequence of a kernel program, use clCreateProgramWithBinary().

[0271] 8. Build The program object registered as source code is built using the OpenCL C compiler and linker. A program object is built using the clBuildProgram() function, which executes builds using the OpenCL C compiler and linker defined in the OpenCL runtime API. Note that if a program object is created from a compiled binary sequence using clCreateProgramWithBinary(), this compilation step is not necessary.

[0272] 9. Creating a kernel object A kernel object is created using the clCreateKernel() function, which provides kernel object creation functionality defined in the OpenCL runtime API. One kernel object corresponds to one kernel function, so the name of the kernel function (hello) is specified when creating the kernel object. Also, if multiple kernel functions are written as a single program object, one kernel object corresponds one-to-one to one kernel function, so clCreateKernel() is called multiple times.

[0273] 10. Kernel Argument Settings The kernel arguments are set using the clSetKernel() function, which provides the ability to provide arguments to the kernel defined in the OpenCL runtime API (passing values ​​to the arguments of the kernel function). Now that the above steps 1 to 10 are complete, we move on to step 11, where the host runs the kernel on the device.

[0274] 11. Kernel execution Kernel execution (submission to the command queue) acts on the device, and therefore is a queuing function for the command queue. The function clEnqueueTask(), which provides the kernel execution functionality defined in the OpenCL runtime API, is used to queue a command to execute the kernel hello on the device. After the command to execute the kernel hello is queued, it will be executed on an executable computing unit on the device.

[0275] 12. Reading from a memory object Data is copied from the device memory area to the host memory area using the clEnqueueReadBuffer() function, which provides the functionality to copy data from device memory to host memory, defined in the OpenCL runtime API. Also, data is copied from the host memory area to the device memory area using the clEnqueueWrightBuffer() function, which provides the functionality to copy data from the host to client memory. Note that these functions act on the device, so the copy command is queued in the command queue once before data copying begins.

[0276] 13. Object release Finally, release the various objects that you have created so far. Above, we have explained device execution of kernels written in accordance with the OpenCL C language.

[0277] -Resource amount calculation function As a resource amount calculation function, the PLD processing pattern creation unit 215 precompiles the created OpenCL and calculates the amount of resources to be used ("first resource amount calculation"). The PLD processing pattern creation unit 215 calculates resource efficiency based on the calculated arithmetic strength and resource amount, and selects c loop statements whose resource efficiency is higher than a predetermined value from each loop statement based on the calculated resource efficiency. The PLD processing pattern creation unit 215 calculates the amount of resources to be used by precompiling with the combined offload OpenCL ("second resource amount calculation"). Here, it is also possible to use the sum of the resource amounts used in precompilation before the first measurement without precompiling.

[0278] <Performance measurement section 118> The performance measurement unit 118 compiles the created application of the PLD processing pattern, places it on the verification machine 14, and executes the processing for performance measurement when offloaded to the PLD.

[0279] The performance measurement unit 118 executes the allocated binary file, measures the performance when offloaded, and returns the performance measurement results to the offload range extraction unit 213a. In this case, the offload range extraction unit 213a extracts another PLD processing pattern, and the intermediate language file output unit 213b attempts performance measurement based on the extracted intermediate language (see symbol a in FIG. 2).

[0280] The performance measurement unit 118 includes a binary file deployment unit (Deploy binary files) 118a. The binary file deployment unit 118a deploys (places) an executable file derived from the intermediate language on the verification machine 14 equipped with a GPU.

[0281] A specific example of performance measurement will be described. The PLD processing pattern creation unit 215 narrows down loop statements with high resource efficiency, and compiles OpenCL that offloads the loop statements narrowed down by the executable file creation unit 119. The performance measurement unit 118 measures the performance of the compiled program ("first performance measurement").

[0282] The PLD processing pattern creation unit 215 then creates a list of loop statements that have improved performance compared to the CPU among the performance measurements. The PLD processing pattern creation unit 215 combines the loop statements in the list to create an OpenCL for offloading. The PLD processing pattern creation unit 215 precompiles the combined offload OpenCL and calculates the amount of resources to be used. Note that, instead of pre-compiling, the sum of the resource amounts pre-compiled before the first measurement may be used. The executable file creation unit 119 compiles the combined offload OpenCL, and the performance measurement unit 118 measures the performance of the compiled program ("second performance measurement").

[0283] <Executable File Creation Unit 119> The executable file creation unit 119 selects the PLD processing pattern with the highest evaluation value from the plurality of PLD processing patterns based on the measurement results of the processing time repeated a predetermined number of times, and compiles the PLD processing pattern with the highest evaluation value to create an executable file.

[0284] The automatic offload operation of the offload server 1A configured as above will now be described. [Automatic offloading operation] The offload server 1A of this embodiment is an example in which the FPGA automatic offload of user application logic is applied as an elemental technology of environment adaptive software. The automatic offload processing of the offload server 1A will be described with reference to FIG. 2, the offload server 1A is applied to the elemental technology of environment adaptive software. The offload server 1A has a control unit (automatic offload function unit) 11, a test case DB 131, an intermediate language file 133, and a verification machine 14. The offload server 1A acquires an application code 125 used by the user.

[0285] A user uses, for example, various devices 151, a device having a CPU-GPU 152, a device having a CPU-FPGA 153, and a device having a CPU 154. The offload server 1A automatically offloads functional processing to accelerators of the device having a CPU-GPU 152 and the device having a CPU-FPGA 153.

[0286] The operation of each part will be explained below with reference to the step numbers in FIG. <Step S21: Specify application code> In step S21, the application code designation unit 111 (see FIG. 16) identifies the processing function (image analysis, etc.) of the service provided to the user. Specifically, the application code designation unit 111 designates the input application code 125.

[0287] <Step S12: Analyze application code> In step S12, the application code analysis unit 112 (see FIG. 16) analyzes the source code of the processing function and grasps the structure of the use of a specific library, such as a loop statement or an FFT library call.

[0288] <Step S13: Extract offloadable area> In step S13, the PLD processing specification unit 213 (see FIG. 16) identifies loop statements (repeated statements) in the application, specifies parallel processing or pipeline processing in FPGA for each repetitive statement, and compiles it with a high-level synthesis tool. Specifically, the offload range extraction unit 213a (see FIG. 16) identifies processing that can be offloaded to FPGA, such as loop statements, and extracts OpenCL as an intermediate language corresponding to the offload processing.

[0289] <Step S14: Output intermediate file> In step S14, the intermediate language file output unit 213b (see FIG. 16) outputs the intermediate language file 133. The intermediate language extraction is not completed once and for all, but is repeated to perform trial and error execution and optimize the search for an appropriate offload area.

[0290] <Step S15: Compile error> In step S15, the PLD processing pattern creation unit 215 (see FIG. 16) creates a PLD processing pattern that excludes loop statements that cause compilation errors from being offloaded, and specifies whether or not to perform FPGA processing on iterative statements that do not cause compilation errors.

[0291] <Step S21: Deploy binary files> In step S21, the binary file placement unit 118a (see FIG. 16) deploys an executable file derived from the intermediate language to the verification machine 14 equipped with an FPGA. The binary file placement unit 118a starts the placed file, executes assumed test cases, and measures the performance when offloaded.

[0292] <Step S22: Measure performance> In step S22, the performance measurement unit 118 (see FIG. 16) executes the arranged file and measures the performance and power consumption when offloaded. To determine the offload area more appropriately, the performance measurement results are returned to the offload range extraction unit 213a, which then extracts another pattern.The intermediate language file output unit 213b then attempts performance measurement based on the extracted intermediate language (see symbol a in FIG. 2).The performance measurement unit 118 repeats performance and power consumption measurements in the verification environment and ultimately determines the code pattern to be deployed.

[0293] As indicated by the symbol a in FIG. 2, the control unit 21 repeatedly executes steps S12 to S22. The automatic offload function of the control unit 21 can be summarized as follows: The PLD processing specification unit 213 identifies loop statements (repeated statements) in the application, specifies parallel processing or pipeline processing in FPGA for each repetitive statement in OpenCL (an intermediate language), and compiles the statements using a high-level synthesis tool. The PLD processing pattern creation unit 215 then creates a PLD processing pattern that excludes loop statements that generate compilation errors from offloading and specifies whether or not to perform PLD processing for loop statements that do not generate compilation errors. The binary file allocation unit 118a then compiles the application of the corresponding PLD processing pattern and allocates it to the verification machine 14, and the performance measurement unit 118 executes the performance measurement processing on the verification machine 14. The executable file creation unit 119 selects the highest evaluation value (e.g., evaluation value=(processing time)) from among multiple PLD processing patterns based on the performance measurement results repeated a predetermined number of times. -1 / 2It selects the pattern with the highest match rate and compiles it to create an executable file.

[0294] <Step S23: Deploy final binary files to production environment> In step S23, the production environment deployment unit 120 determines a pattern that specifies the final offload area, and deploys it in the production environment for the user.

[0295] <Step S24: Extract performance test cases and run automatically> In step S24, after arranging the executable file, the performance measurement test extraction execution unit 121 extracts performance test items from the test case DB 131 and automatically executes the extracted performance tests in order to show the performance to the user.

[0296] <Step S25: Provide price and performance to a user to judge> In step S25, the user providing unit 122 presents the user with information such as price and performance based on the performance test results. The user decides whether to start paying for the service based on the presented information such as price and performance.

[0297] The above steps S21 to S25 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.

[0298] As described above, when applied to the elemental technology of environment-adaptive software, the control unit (automatic offload function unit) 21 of the offload server 1A extracts an area to be offloaded from the source code of the application used by the user and outputs an intermediate language to offload functional processing (steps S12 to S15). The control unit 21 places and executes an executable file derived from the intermediate language on the verification machine 14, and verifies the offload effect (steps S21 to S22). After repeating the verification and determining an appropriate offload area, the control unit 21 deploys the executable file in the production environment that will actually be provided to the user, and provides it as a service (step S26).

[0299] In the above, a processing flow for collectively performing code conversion, resource amount adjustment, and placement location adjustment, which are necessary for environment adaptation, has been described, but it is not limited to this, and it is also possible to extract only the processing you want to perform. For example, if you only want to perform code conversion for FPGA, you can use only the necessary parts of the above steps S21 to S25, such as the environment adaptation function and verification environment.

[0300] [FPGA automatic offloading] The code analysis described above uses a syntax analysis tool such as Clang to analyze application code. Because code analysis requires analysis that takes into account the offloading device, it is difficult to generalize. However, it is possible to understand the code structure, such as loop statements and variable reference relationships, and to determine whether a function block performs FFT processing or whether it calls a library that performs FFT processing. It is difficult for the offload server to automatically determine the function block. This can also be determined by using a similar code detection tool such as Deckard to determine similarity. While Clang is a tool for C / C++, it is necessary to select a tool that is appropriate for the language being analyzed.

[0301] Furthermore, when offloading application processing, consideration must be given to the offload destination, such as the GPU, FPGA, or IoT GW. Generally, it is difficult to automatically discover the settings that maximize performance in one go. For this reason, offload patterns are tested by repeating performance measurements in a verification environment several times to find a pattern that can increase speed.

[0302] Below, we will explain a method for offloading loop statements in application software to FPGAs. [flowchart] FIG. 17 is a flowchart for explaining the outline of the operation of the offload server 1A. In step S201, the application code analysis unit 112 analyzes the source code of the application to be offloaded. The application code analysis unit 112 analyzes information about loop statements and variables according to the language of the source code.

[0303] In step S202, the PLD processing specification unit 213 identifies the loop statements and reference relationships of the application.

[0304] Next, the PLD processing pattern creation unit 215 narrows down the candidates for whether or not to attempt FPGA offloading for the identified loop statement. Arithmetic strength is one indicator of whether or not offloading is effective for a loop statement. In step S203, the arithmetic strength calculation unit 214 calculates the arithmetic strength of the loop statements of the application using an arithmetic strength analysis tool. Arithmetic strength is an index that increases as the number of calculations increases and decreases as the number of accesses increases, and processing with high arithmetic strength is heavy for the processor. Therefore, the arithmetic strength of the loop statements is analyzed using the arithmetic strength analysis tool, and loop statements with high density are narrowed down to offload candidates. Therefore, the arithmetic strength of the loop statements is analyzed using the arithmetic strength analysis tool, and loop statements with high density are narrowed down to offload candidates.

[0305] Even if a loop statement has high arithmetic strength, it is a problem if it consumes excessive FPGA resources when processed by FPGA. Therefore, we will describe how to calculate the amount of resources required when processing a high arithmetic strength loop statement on FPGA. When compiling to FPGA, the process involves converting from a high-level language such as OpenCL to a hardware description level such as HDL, and then performing the actual wiring process based on that. At this time, the wiring process takes a significant amount of time, but it only takes a few minutes to reach the intermediate stage of HDL. Even at the intermediate stage of HDL, the resources used by the FPGA, such as flip flops and look-up tables, can be determined. Therefore, by looking at the intermediate stage of HDL, the amount of resources used can be determined in a short time, even before compilation is complete.

[0306] Therefore, in this embodiment, the PLD processing pattern creation unit 215 converts the target loop statement into a high-level language such as OpenCL and first calculates the resource amount. Then, since the arithmetic intensity and resource amount when the loop statement is offloaded are determined, the resource efficiency is calculated as arithmetic intensity / resource amount or arithmetic intensity x loop count / resource amount. Then, the offload candidates are further narrowed down to loop statements with high resource efficiency.

[0307] Returning to the flow of FIG. 17, in step S204, the PLD processing pattern creation unit 215 measures the number of loops in the loop statement of the application using a profiling tool such as gcov or gprof. In step S205, the PLD processing pattern creation unit 215 narrows down the loop statements to those with high arithmetic strength and a large number of loops.

[0308] In step S206, the PLD processing pattern creation unit 215 creates OpenCL for offloading each of the narrowed down loop statements to the FPGA.

[0309] Here, we will provide additional information on converting loop statements to OpenCL (creating OpenCL). Converting loop statements to a high-level language such as OpenCL requires two processes. One is to divide the CPU processing program into the kernel (FPGA) and the host (CPU) according to the grammar of the high-level language such as OpenCL. The other is to incorporate techniques to increase speed when dividing the program. Generally, methods for increasing speed using FPGAs include local memory cache, stream processing, multiple instantiation, loop unrolling, merging nested loops, and memory interleaving. While these methods may not be absolutely effective for some loop statements, they are commonly used as speed-up techniques.

[0310] Next, several highly resource-efficient loop statements are selected, and then a number of offload patterns are created using these to measure performance. Acceleration on FPGAs can be achieved by concentrating FPGA resources on a single process, or by distributing FPGA resources across multiple processes. A fixed number of patterns for the selected single loop statements are created, and then precompiled as a preliminary step to running them on the actual FPGA.

[0311] In step S207, the PLD processing pattern creation unit 215 precompiles the created OpenCL and calculates the amount of resources to be used ("first resource amount calculation").

[0312] In step S208, the PLD processing pattern creation unit 215 narrows down the loop statements with high resource efficiency.

[0313] In step S209, the executable file creation unit 119 compiles OpenCL that offloads the narrowed-down loop statements.

[0314] In step S210, the performance measurement unit 118 measures the performance of the compiled program ("first performance measurement"). Since several candidate loop statements remain, the performance measurement unit 118 uses them to measure the performance (see the subroutine in FIG. 18 for details).

[0315] In step S211, the PLD processing pattern creation unit 215 creates a list of loop statements that have been measured and have higher performance than the CPU.

[0316] In step S212, the PLD processing pattern creation unit 215 creates an OpenCL that combines list loop statements to perform offloading. In step S213, the PLD processing pattern creation unit 215 calculates the amount of resources to be used by precompiling the combined offload OpenCL ("second resource amount calculation"). Note that it is also possible to use the sum of the resource amounts obtained by precompiling before the first measurement without precompiling. This can reduce the number of times precompiling is performed.

[0317] In step S214, the executable file creation unit 119 compiles the combined offload OpenCL.

[0318] In step S215, the performance measurement unit 118 measures the performance of the compiled program ("second performance measurement"). The performance measurement unit 118 compiles and measures the selected single loop statement, and then creates combination patterns for the single loop statements that have been speeded up, and performs the second performance measurement (see the subroutine in FIG. 18 for details).

[0319] In step S216, the production environment deployment unit 120 selects the pattern with the best performance from the first and second measurements, and ends the processing of this flow. Among the multiple patterns measured, a short-time pattern is selected as a solution.

[0320] In this way, the FPGA automatic offloading of loop statements is performed by narrowing down the offloading patterns to loop statements with high arithmetic intensity and loop count, which are highly resource efficient, and then searching for high-speed patterns through actual measurements in a verification environment (see Figure 17).

[0321] 18 is a flowchart showing the performance and power consumption measurement process of the performance measurement unit 118. This flow is called and executed by the subroutine call of step S210 or step S215 in FIG.

[0322] In step S301, the performance measurement unit 118 measures the processing time required for FPGA offloading.

[0323] In step S302, the performance measurement unit 118 sets an evaluation value based on the measured processing time.

[0324] In step S303, the performance measurement unit 118 measures the performance of the pattern with the high evaluation value, which is evaluated so that the higher the evaluation value of an individual, the higher the fitness, and then returns to step S210 or step S215 in FIG.

[0325] [Example of creating an off-road pattern] FIG. 19 is a diagram showing a search image of the PLD processing pattern creation unit 215. The control unit (automatic offload function unit) 21 (see FIG. 16) analyzes the application code 125 (see FIG. 2) used by the user, and checks whether or not for statements can be used in parallel from the code patterns 241 of the application code 125, as shown in FIG. 19. As shown by the symbol r in FIG. 19, if four for statements are found from the code pattern 241, one digit is assigned to each for statement, in this case four digits of 1 or 0 are assigned to the four for statements. Here, 1 is assigned if FPGA processing is performed, and 0 is assigned if FPGA processing is not performed (i.e., processing is performed by the CPU).

[0326] [The process from C code to the search for the final OpenCL solution] The procedures A - F in FIG. 20 are diagrams explaining the flow from C code to the search for the final OpenCL solution. The application code analysis unit 112 (see FIG. 16) syntax - analyzes the "C code" shown in procedure A of FIG. 20 (<syntax - analysis>: see reference symbol s in FIG. 20), and the PLD processing specification unit 213 (see FIG. 16) identifies the "loop statement, variable information" shown in procedure B of FIG. 20 (see reference symbol t in FIG. 20).

[0327] The arithmetic intensity calculation unit 214 (see FIG. 16) performs arithmetic intensity analysis (Arithmetic Intensity analysis) on the identified "loop statement, variable information" using an arithmetic intensity analysis tool (see reference symbol u in FIG. 20). The PLD processing pattern creation unit 215 narrows down the loop statements with high arithmetic intensity as offload candidates. Furthermore, the PLD processing pattern creation unit 215 performs profiling analysis (Profiling analysis) using a profiling tool to further narrow down the loop statements with high arithmetic intensity and high loop counts.

[0328] Then, the PLD processing pattern creation unit 215 creates (OpenCL -izes) OpenCL for offloading each of the narrowed - down loop statements to the FPGA (see reference symbol v in FIG. 20). Furthermore, at the time of OpenCL -ization, high - speed techniques such as code splitting and unfolding are introduced (described later).

[0329] <Specific example of "high arithmetic intensity, OpenCL -ization" (Part 1): Procedure C> For example, when four for loops (assignment of 4 - digit 1 or 0) are found from the code pattern 241 (see FIG. 19) of the application code 125 (see FIG. 2), three are narrowed down (selected) by arithmetic intensity analysis. That is, as shown by reference symbol u in FIG. 20, from the four for loops, the offload patterns "1000", "0010", and "0001" of three for loops are narrowed down.

[0330] <Example of "unfolding" executed together with code splitting at the time of OpenCL -ization> When transferring data from FPGA to CPU, the loop statement written in the CPU program is [k=0; k<10; k++] { } In the above, specify \pragma unroll at the top of this loop statement. \pragma unroll for(k=0; k<10; k++){ } It is written as follows.

[0331] If you specify unroll using syntax that is compatible with Intel or Xilinx (registered trademark) tools, such as \pragma unroll, the above example can be expanded to i=0, i=1, i=2 and executed in a pipeline. This will use 10 times the amount of resources, but may be faster. In addition, the number of loops to be expanded with unroll can be specified to be 5 instead of the total number of loops, in which case each loop will be expanded twice to 5 loops. This concludes the explanation of the "expansion" example.

[0332] Next, the PLD processing pattern creation unit 215 further narrows down the loop statements with high arithmetic strength that have been narrowed down as offload candidates using the amount of resources. That is, the PLD processing pattern creation unit 215 calculates the amount of resources, and analyzes resource efficiency (= arithmetic strength / resource amount during FPGA processing, or arithmetic strength × number of loops / resource amount during FPGA processing) from the offload candidates of loop statements with high arithmetic strength to extract loop statements with high resource efficiency.

[0333] At symbol v in FIG. 20, the PLD processing pattern creation unit 215 compiles (<precompiles>) OpenCL for offloading the narrowed-down loop statements.

[0334] <Example of "High Arithmetic Strength, OpenCL" (Part 2)> As shown by symbol u in Figure 20, the four offload patterns "1000", "0100", "0010", and "0001" narrowed down by the arithmetic intensity analysis are narrowed down to three offload patterns "1000", "0010", and "0001" by the resource efficiency analysis. The above has described "high arithmetic strength, OpenCL implementation" shown in step C of FIG.

[0335] For the "loop statement with high resource efficiency" shown in step D of FIG. 20, the performance measurement unit 118 measures the performance of the compiled program ("first performance measurement"). The PLD processing pattern creation unit 215 then lists the loop statements whose performance has been measured and whose performance has been improved compared to the CPU. Thereafter, the resource amount is calculated, offload OpenCL compilation is performed, and the performance of the compiled program is measured in the same manner.

[0336] <Example of "High Arithmetic Strength, OpenCL" (Part 3)> As shown by symbol w in Figure 20, a first measurement is performed for the three offload patterns "1000," "0010," and "0001." If the performance of "1000" and "0010" is found to be higher among the three measurements, a second measurement is performed for the combination of "1000" and "0010."

[0337] At the symbol x in FIG. 20, the executable file creation unit 119 compiles (<main compilation>) OpenCL for offloading the narrowed-down loop statement.

[0338] The "measurement of combination patterns" shown in step E of FIG. 20 refers to measuring the verification patterns for each candidate loop statement and then for the combination of the candidate loop statements.

[0339] <Example of "High Arithmetic Strength, OpenCL" (Part 4)> As shown by symbol y in Figure 20, a second measurement is made for "1010", which is a combination of "1000" and "0010". Two measurements are made, and as a result, "0010" is selected as it has the highest speed between the first and second measurements. In such a case, "0010" becomes the final solution. Here, there are cases where a combination pattern cannot be measured due to resource limitations. In this case, it is possible to skip the combination and simply select the fastest one from the individual results.

[0340] In the case of symbol z in FIG. 20, the performance measuring unit 118 selects (<selects>) "0010" which has the best maximum speed between the first and second measurements.

[0341] As a result of the above, "0010" (see symbol aa in FIG. 20) of the "OpenCL final solution" shown in step F in FIG. 20 was selected.

[0342] <Deployment> The final OpenCL solution, the PLD processing pattern with the highest processing performance, will be redeployed to a production environment and provided to users.

[0343] [Implementation example] An implementation example is explained. FPGAs such as Intel PAC with Intel Arria10 GX FPGA can be used. FPGA processing can use the Intel Acceleration Stack (Intel FPGA SDK for OpenCL, Quartus Prime Version), etc. The Intel FPGA SDK for OpenCL is a high-level synthesis tool (HLS) that interprets standard OpenCL as well as Intel-specific #pragmas. In the implementation example, the OpenCL code that describes the kernel to be processed by the FPGA and the host program to be processed by the CPU is interpreted, information such as resource usage is output, and the FPGA wiring is performed so that it can run on the FPGA. Even a small program of about 100 lines can take as long as three hours to run on an actual FPGA. However, if the resource usage is exceeded, an error will be displayed early on. Also, if the OpenCL code cannot be processed by the FPGA, an error will be displayed after several hours.

[0344] In the implementation example, when a request to use a C / C++ application is received, the code of the C / C++ application is first analyzed to find for statements and understand the program structure, such as variable data used within the for statements. For syntax analysis, LLVM / Clang syntax analysis libraries can be used.

[0345] In the implementation example, next, to obtain a prediction of whether each loop statement will benefit from FPGA offloading, an arithmetic intensity analysis tool is run to obtain an index of arithmetic intensity determined by the number of calculations, number of accesses, etc. The ROSE framework, etc., can be used for arithmetic intensity analysis. Only loop statements with the highest arithmetic intensity are targeted. Next, we use a profiling tool such as gcov to obtain the loop count for each loop. We narrow down the candidates to the top a loop statements based on the product of arithmetic strength and loop count.

[0346] In the implementation example, OpenCL code to be offloaded to FPGA is then generated for each loop statement with high arithmetic intensity. The OpenCL code is divided into the relevant loop statement as an FPGA kernel and the rest as a CPU host program. When creating the FPGA kernel code, a fixed number b of loop statements can be unrolled as a speed-up technique. Although loop unrolling increases the amount of resources required, it is effective in increasing speed. Therefore, the number of loops unrolled is limited to a fixed number b so that the amount of resources does not become excessive.

[0347] In this implementation example, the Intel FPGA SDK for OpenCL is then used to precompile a number of OpenCL codes and calculate the amount of resources used, such as flip flops and look-up tables. The amount of resources used is displayed as a percentage of the total resource amount. The resource efficiency of each loop statement is then calculated from the arithmetic intensity and resource amount, or the arithmetic intensity, number of loops, and resource amount. For example, a loop statement with an arithmetic intensity of 10 and resource amount of 0.5 has a resource efficiency of 10 / 0.5 = 20, while a loop statement with an arithmetic intensity of 3 and resource amount of 0.3 has a resource efficiency of 3 / 0.3 = 10, with the former being higher. Alternatively, the resource efficiency can be calculated by multiplying the number of loops. For each loop statement, c statements with the highest resource efficiency are selected.

[0348] In the implementation example, next, c loop statements are selected as candidates and patterns to be measured are created. For example, if the first and third loops are highly resource efficient, OpenCL patterns are created to offload loop 1 and loop 3, respectively, and then compiled and performance is measured. If speed can be improved by offloading multiple single loop statements (for example, if both loops 1 and 3 are faster), an OpenCL pattern for that combination is created, compiled, and performance is measured (for example, a pattern that offloads both loops 1 and 3).

[0349] When creating a combination of single loops, the amount of resources used is also a combination. For this reason, if it does not fit within the upper limit, that combination pattern will not be created. After creating d patterns, including combinations, performance is measured on a server equipped with an FPGA in the verification environment. Performance is measured by performing sample processing specified in the application to be accelerated. For example, if it is a Fourier transform application, performance is measured by benchmarking the conversion processing on sample data. In the implementation example, the fastest pattern among the multiple measurement patterns is finally selected as the solution.

[0350] In the second embodiment, the same "resource amount determination and allocation determination" as described in the first embodiment is also executed (description omitted).

[0351] [evaluation] Explain the evaluation. The second embodiment's "FPGA automatic offloading of loop statements" can be evaluated in the same way as the first embodiment's "GPU automatic offloading of loop statements."

[0352] <Evaluation target> In the second embodiment of [FPGA automatic offloading of loop statements], the evaluation target is MRI-Q for MRI (Magnetic Resonance Imaging) image processing. MRI-Q calculates the matrix Q that represents the scanner configuration used in 3D MRI reconstruction algorithms in non-Cartesian space. MRI-Q is written in C, and during performance measurement it processes 3D MRI images and measures the processing time using large (maximum) 64x64x64 size data. CPU processing is done using C, and FPGA processing is based on OpenCL.

[0353] <Evaluation method> The target application code is input, and loop statement offloading recognized by Clang or similar is attempted for the destination GPU or FPGA to determine the offload pattern. During this process, the processing time and power consumption are measured. For the final offload pattern, the change in power consumption over time is obtained, and the power savings compared to processing entirely on the CPU are confirmed. In the second embodiment of [FPGA automatic offloading of loop statements], GA is not performed, and arithmetic strength and the like are used to narrow down the measurement patterns to four patterns. Offloadable loop statements: MRI-Q 16 Pattern compatibility: The shorter the processing time, the higher the evaluation value, and the higher the compatibility. In the second embodiment, MRI-Q can also improve cost and response time compared to a layout that simply prioritizes low cost or response time, as shown in Figure 12 above.

[0354] In the first embodiment, the layout reconfiguration unit 180 reconfigures the placement locations of application programs requested for placement by multiple users to be reconfigured, in accordance with linear programming equations for reconfiguration (see equations (7), (1), (5), (3), and (4)) for the placed application programs set by the placement setting unit 170. In the second embodiment, as in the first embodiment, the layout reconfiguration unit 180 also executes the reconfiguration process.

[0355] [Hardware configuration] The offload server according to the first and second embodiments is realized by a computer 900, which is a physical device having a configuration as shown in FIG. 21, for example. 21 is a hardware configuration diagram showing an example of a computer that realizes the functions of the offload servers 1 and 1 A. The computer 900 has a CPU 901, a RAM 902, a ROM 903, an HDD 904, an accelerator 905, an input / output interface (I / F) 906, a media interface (I / F) 907, and a communication interface (I / F: Interface) 908.

[0356] The accelerator 905 is an accelerator (device) that processes at high speed at least one of data from the communication I / F 908 and data from the RAM 902. For example, the accelerator 905 is an accelerator for the various devices 151, the device having a CPU-GPU 152, the device having a CPU-FPGA 153, and the device having a CPU 154 in FIG. The accelerator 905 may be of a type (look-aside type) that executes processing from the CPU 901 or RAM 902 and then returns the execution result to the CPU 901 or RAM 902. On the other hand, the accelerator 905 may be of a type (in-line type) that performs processing between the communication I / F 908 and the CPU 901 or RAM 902.

[0357] The accelerator 905 is connected to an external device 915 via a communication I / F 908. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data from and to a recording medium 917.

[0358] The CPU 901 operates based on a program stored in the ROM 903 or HDD 904, and executes a program (also called an application or an abbreviation thereof) loaded into the RAM 902, thereby controlling each processing unit of the offload servers 1, 1A shown in Figures 1 and 16. This program can also be distributed via a communication line or recorded on a recording medium 917 such as a CD-ROM and distributed. The ROM 903 stores a boot program executed by the CPU 901 when the computer 900 is started, programs that depend on the hardware of the computer 900, and the like.

[0359] The CPU 901 controls an input / output device 916, which is made up of input units such as a mouse and a keyboard, and output units such as a display and a printer, via an input / output I / F 906. The CPU 901 acquires data from the input / output device 916 via the input / output I / F 906, and outputs generated data to the input / output device 916. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

[0360] The HDD 904 stores programs executed by the CPU 901 and data used by the programs. The communication I / F 908 receives data from other devices via a communication network (e.g., a network) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0361] The media I / F 907 reads a program or data stored in the recording medium 917 and outputs it to the CPU 901 via the RAM 902. The CPU 901 loads a program related to a target process from the recording medium 917 onto the RAM 902 via the media I / F 907, and executes the loaded program. The recording medium 917 is 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 magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.

[0362] For example, when a computer 900 functions as the offload server 1, 1A according to the first and second embodiments, a CPU 901 of the computer 900 executes a program loaded onto a RAM 902 to realize the functions of the offload server 1, 1A. Furthermore, data stored in the RAM 902 is stored in an HDD 904. The CPU 901 reads and executes a program related to a target process from a recording medium 912. Alternatively, the CPU 901 may read a program related to a target process from another device via a communication network.

[0363] [effect] As described above, the offload server 1 (see FIG. 1) according to the first embodiment is an offload server that offloads specific processing of an application program to an accelerator, and includes an application code analysis unit 112 that analyzes the source code of the application program, a data transfer specification unit 113 that analyzes the reference relationships of variables used in loop statements of the application program and specifies data transfer using an explicit specification line that explicitly specifies data transfer outside the loop for data that may be transferred outside the loop, a parallel processing specification unit 114 that identifies loop statements of the application program and specifies a parallel processing specification statement in the accelerator for each identified loop statement to compile it, and a compilation unit 115 that checks whether a compilation error occurs. The system includes a parallel processing pattern creation unit 117 that creates a parallel processing pattern that excludes loop statements that result in a compilation error from being offloaded and specifies whether or not to perform parallel processing on loop statements that do not result in a compilation error; a performance measurement unit 118 that compiles an application program of the parallel processing pattern, places it on an accelerator verification device, and executes processing for measuring performance when offloaded to the accelerator; and a placement reconfiguration unit 180 that reconfigures the placement locations of application programs that have been requested to be placed by multiple users who request the placement of applications to be reconfigured, for the placed application programs, in accordance with linear programming equations for reconfiguration (see equations (7), (1), (5), (3), and (4)).

[0364] In this way, the satisfaction of a plurality of users who request the placement of applications to be reconfigured can be improved by reconfiguring the placement after the start of operation. In other words, if applications are allocated according to the response time and price requirements of individual users, it is basically a first-come, first-served situation. For example, if low cost is the priority, the cloud will be filled, and if speed is the priority, the edge will be filled, and once filled, allocation to another server will be necessary. Therefore, the offload server 1 (see Figure 1) is equipped with an allocation reconfiguration unit 180, which performs allocation reconfiguration not only before operation starts but also after operation starts. This alleviates the first-come, first-served allocation and improves the satisfaction of multiple users requesting the allocation of applications to be reconfigured.

[0365] This invention enables an overall optimal placement of applications automatically offloaded to a GPU or FPGA, which satisfies the user's requested price and response time conditions, and takes into account the app placement status of other users, thereby improving overall user satisfaction linked to price and response time.

[0366] The offload server 1A (see FIG. 16) according to the second embodiment is an offload server that offloads specific processing of an application program to a PLD, and includes an application code analysis unit 112 that analyzes the source code of the application program, a PLD processing specification unit 213 that specifies loop statements in the application program and creates pipeline processing and parallel processing in the PLD for each specified loop statement according to a plurality of offload processing patterns specified in OpenCL, and compiles the loop statement, an arithmetic strength calculation unit 214 that calculates the arithmetic strength of the loop statement of the application program, and a PLD processing unit 215 that calculates the arithmetic strength of the loop statement based on the arithmetic strength calculated by the arithmetic strength calculation unit 214. The system includes a PLD processing pattern creation unit 215 that narrows down loop statements higher than a certain threshold as offload candidates and creates a PLD processing pattern; a performance measurement unit 118 that compiles an application program of the created PLD processing pattern, places it on an accelerator verification device, and executes processing for measuring performance when offloaded to a PLD; and a placement reconfiguration unit 180 that reconfigures the placement locations of application programs requested for placement by multiple users who request placement of applications to be reconfigured, for the placed application programs, in accordance with linear programming equations for reconfiguration (see equations (7), (1), (5), (3), and (4)).

[0367] This reduces the number of performance measurements required by narrowing down the patterns to be actually measured, then deploying them in a verification environment, compiling them, and measuring performance on an actual PLD (e.g., FPGA). This allows for high-speed automatic offloading of application loop statements to the PLD. The system then calculates the optimal placement of the converted application on a cloud server, carrier edge server, or user edge server on the network by changing the price and response time conditions, the number of applications deployed, and other factors requested by the user. This allows the converted application to be optimally placed in accordance with user requests while satisfying the computational resource cost or response time requirements. Furthermore, the placement reconfiguration unit 180 can reconfigure the placement after operation begins, thereby improving the satisfaction of multiple users requesting the placement of the application to be reconfigured.

[0368] In the offload server 1 according to the first embodiment (see FIG. 1) and / or the offload server 1A according to the second embodiment (see FIG. 16), when a converted application program is placed on a cloud server, a carrier edge server, or a user edge server on a network in accordance with the cost or response time conditions specified by the user, a placement setting unit 170 is provided which calculates and sets the placement location of the application program based on a linear programming equation in which the device and link costs, the computational resource upper limit, and the bandwidth upper limit are constraints and the computational resource cost or the response time is an objective function, and a placement reconfiguration unit 180 reconfigures the placement locations of application programs requested for placement by multiple users requesting placement of the application to be reconfigured, for the placed application programs set by the placement setting unit 170, in accordance with the linear programming equation for reconfiguration.

[0369] In this way, for applications automatically offloaded to accelerators such as GPUs and FPGAs, the system calculates an optimal allocation for placing the converted applications on either a cloud server, a carrier edge server, or a user edge server on the network by changing the price conditions, response time conditions, number of applications to be deployed, etc. requested by the user. This makes it possible to realize an optimal allocation according to user requests by satisfying the requirements of computational resource cost or response time. Then, the allocation reconfiguration unit 180 reconfigures the allocation after operation starts, thereby improving the satisfaction of multiple users who request the allocation of the applications to be reconfigured.

[0370] In the offload servers 1, 1A according to the first and second embodiments, the placement setting unit 170 is characterized in that when placing an application program on the server, it calculates a placement that minimizes the cost of computing resources or a placement that minimizes the response time.

[0371] In this way, the converted application can be optimally deployed to meet the requirements of computational resource cost or response time.

[0372] In the offload servers 1, 1A according to the first and second embodiments, the placement reconfiguration unit 180 uses the sum of the application programs related to the user satisfaction evaluation shown in equation (7) as an objective function, calculates a placement that minimizes the objective function, and collectively relocates the application programs to the location determined by the calculation.

[0373] By doing so, the placement reconfiguration unit 180 can obtain the objective function R k after / R k before +P k after / P k before According to the k after / R kbefore +P k after / P k before ) is calculated. Thus, the value S corresponding to the user satisfaction level in equation (7) is calculated, and the overall user satisfaction level can be improved.

[0374] The present invention provides an offload program for causing a computer to function as the offload server.

[0375] In this way, it is possible to realize the functions of the offload servers 1 and 1A using a general computer.

[0376] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method.In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. Furthermore, the components of each device shown in the figure are conceptual functional components and do not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0377] 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. The above-described configurations, functions, etc. may also be implemented by software that causes a processor to interpret and execute programs that implement the respective functions. Information on programs, tables, files, etc. that implement the respective functions may be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC (Integrated Circuit) card, SD (Secure Digital) card, or optical disk.

[0378] In this embodiment, a genetic algorithm (GA) is used to find a solution to a combinatorial optimization problem within a limited optimization period, but any optimization method may be used, such as local search, dynamic programming, or a combination of these.

[0379] Although this embodiment uses an OpenACC compiler for C / C++, any compiler that can offload GPU processing can be used. For example, Java Lambda (registered trademark) GPU processing or IBM Java 9 SDK (registered trademark) can be used. Note that the parallel processing specification statement depends on these development environments. For example, Java (registered trademark) has made it possible to write parallel processing in lambda format since Java 8. IBM (registered trademark) provides a JIT compiler that offloads parallel processing written in lambda format to a GPU. In Java, this can be used to achieve similar offloading by tuning the GA to determine whether or not to convert loop processing to lambda format.

[0380] In addition, in this embodiment, a for statement is used as an example of a repetitive statement (loop statement), but other statements such as a while statement or a do-while statement are also included. However, a for statement that specifies the continuation condition of the loop is more suitable. [Explanation of symbols]

[0381] 1,1A Offload Server 11,21 Control unit 12 Input / output section 13 Storage section 14 Verification machine (accelerator verification device) 111 Application code designation section 112 Application Code Analysis Unit 113 Data transfer specification section 114 Parallel processing specification section 114a, 213a Off-road range extraction section 114b,213b Intermediate language file output section 115 Resource ratio determination unit 116 Resource amount setting section 117 Parallel Processing Pattern Creation Unit 118 Performance measurement section 118a Binary file placement section 119 Executable File Creation Department 120 Production Environment Deployment Department 121 Performance Measurement Test Extraction Execution Department 122 User Provision Department 125 Application Code 131 Test Case DB 132 Facility Resource DB 133 Intermediate Language Files 151 Various Devices 152 CPU-GPU devices 153 Devices with CPU-FPGA 154 Devices with CPUs 170 Placement setting section 180 Placement reconfiguration unit 213 PLD processing specification part 214 Arithmetic strength calculation section 215 PLD Processing Pattern Creation Department 905 Accelerator S Value corresponding to user satisfaction (objective function for user satisfaction evaluation) (linear programming formula for reconstruction)

Claims

1. An offload server that offloads specific processing of an application program to an accelerator, an application code analysis unit that analyzes the source code of the application program; a data transfer specification unit that analyzes reference relationships between variables used in a loop statement of the application program, and specifies data transfer using an explicit specification line that explicitly specifies data transfer outside the loop for data that may be transferred outside the loop; a parallel processing specification unit that specifies loop statements in the application program, and compiles each of the specified loop statements by specifying a parallel processing specification statement in the accelerator; a parallel processing pattern creation unit that creates a parallel processing pattern that excludes loop statements that generate a compilation error from being offloaded and specifies whether or not to perform parallel processing on loop statements that do not generate a compilation error; a performance measurement unit that compiles the application program of the parallel processing pattern, arranges it in an accelerator verification device, and executes a process for performance measurement when the application program is offloaded to the accelerator; a placement reconfiguration unit that reconfigures placement locations of application programs that have already been placed and that have been requested to be placed by a plurality of users who request placement of applications to be reconfigured, in accordance with a linear programming formula for reconfiguration; An offload server comprising:

2. An offload server that offloads specific processing of an application program to a PLD (Programmable Logic Device), an application code analysis unit that analyzes the source code of the application program; a PLD processing specification unit that specifies loop statements in the application program, and creates pipeline processing and parallel processing in the PLD for each of the specified loop statements according to a plurality of offload processing patterns specified by OpenCL, and compiles the PLD; an arithmetic strength calculation unit that calculates the arithmetic strength of a loop statement of the application program; a PLD processing pattern creation unit that narrows down loop statements having arithmetic strengths higher than a predetermined threshold as offload candidates based on the arithmetic strengths calculated by the arithmetic strength calculation unit, and creates a PLD processing pattern; a performance measurement unit that compiles the application program of the created PLD processing pattern, arranges the application program in an accelerator verification device, and executes a process for performance measurement when the application program is offloaded to the PLD; a placement reconfiguration unit that reconfigures placement locations of application programs that have already been placed and that have been requested to be placed by a plurality of users who request placement of applications to be reconfigured, in accordance with a linear programming formula for reconfiguration; An offload server comprising:

3. a placement setting unit that, when placing the converted application program on one of a cloud server, a carrier edge server, and a user edge server on a network in accordance with a cost or response time condition designated by a user, calculates and sets a placement location for the application program based on a linear programming equation in which device and link costs, upper limits of computational resources, and upper limits of bandwidth are constraints and the cost of computational resources or the response time is an objective function; The placement reconfiguration unit reconfigures placement locations of application programs that have been requested to be placed by a plurality of users who request placement of applications to be reconfigured, in accordance with a linear programming formula for reconfiguration for the placed application programs set by the placement setting unit.

3. The offload server according to claim 1 or 2.

4. The placement setting unit calculates a placement that minimizes the cost of computing resources or the response time when placing application programs on a server. The offload server according to claim 3 .

5. The reconfiguration unit uses the sum of the application programs related to the user satisfaction evaluation expressed by the following formula as an objective function, calculates an arrangement that minimizes the objective function, and collectively reconfigures the application programs to the positions determined by the calculation. [Equation 3] 3. The offload server according to claim 1 or 2.

6. An offload control method for an offload server that offloads specific processing of an application program to an accelerator, comprising: The offload server analyzing the source code of the application program; a step of analyzing reference relationships of variables used in a loop statement of the application program, and specifying data transfer using an explicit specification line that explicitly specifies data transfer outside the loop for data that may be transferred outside the loop; Identifying loop statements in the application program, and compiling each of the identified loop statements by specifying a parallel processing specification statement for the accelerator; creating a parallel processing pattern that excludes loop statements that generate a compilation error from being offloaded and specifies whether or not to perform parallel processing on loop statements that do not generate a compilation error; a step of compiling the application program of the parallel processing pattern, distributing the application program in an accelerator verification device, and executing a process for measuring performance when the application program is offloaded to the accelerator; and reconfiguring the placement locations of application programs requested by a plurality of users requesting placement of applications to be reconfigured, in accordance with a linear programming formula for reconfiguration, for the application programs that have already been placed. An off-road control method comprising:

7. An offload control method for an offload server that offloads specific processing of an application program to a PLD (Programmable Logic Device), comprising: The offload server analyzing the source code of the application program; Identifying loop statements of the application program, and for each of the identified loop statements, creating pipeline processing and parallel processing in the PLD according to a plurality of offload processing patterns specified in OpenCL, and compiling the PLD; calculating the arithmetic strength of a loop statement of the application program; based on the calculated arithmetic strength, narrowing down loop statements having arithmetic strengths higher than a predetermined threshold as offload candidates, and creating a PLD processing pattern; a step of compiling the application program of the created PLD processing pattern, disposing the application program in an accelerator verification device, and executing a process for measuring performance when offloaded to the PLD; and reconfiguring the placement locations of application programs requested by a plurality of users requesting placement of applications to be reconfigured, in accordance with a linear programming formula for reconfiguration, for the application programs that have already been placed. An off-road control method comprising:

8. An offload program for causing a computer to function as the offload server according to claim 1 or 2.

Images