Offload server, offload control method, and offload program

Abstract

An offload server (1) comprises: a request processing load analysis unit (120) that analyzes a request processing load for data actually being used by a user; a representative data selection unit (121) that identifies an application for which the analyzed processing load is highest, and selects representative data from among request data during use of said application; a degree of improvement calculation unit (122) that, on the basis of the selected representative data, determines a new offload pattern by executing an application code analysis unit (112), a PLD processing designation unit (113), an arithmetic strength calculation unit (114), a PLD processing pattern creation unit (115), a performance measurement unit (116), and an execution file creation unit (117), and calculates a performance improvement effect by comparing the processing time and usage frequency of the determined new offload pattern with the processing time and usage frequency of the current offload pattern; and a reconfiguration proposal unit (123) that proposes PLD reconfiguration when the performance improvement effect is a prescribed threshold or higher.

Description

Technical Field

[0001] The present invention relates to an offload server that automatically offloads functional processing to an accelerator such as an FPGA (Field Programmable Gate Array), an offload control method, and an offload program.

Background Art

[0002] In the cloud layer, servers equipped with heterogeneous HW (hardware) such as GPUs (Central Processing Units) and FPGAs (Field Programmable Gate Arrays) (hereinafter referred to as "heterogeneous devices") are increasing. For example, FPGAs are also used in Microsoft (registered trademark)'s Bing search. Thus, by utilizing heterogeneous devices, for example, offloading matrix calculations and the like to GPUs or offloading specific processes such as FFT (Fast Fourier Transform) calculations to FPGAs, high performance is achieved.

[0003] From the prediction of the slowdown of Moore's Law, not only increasing the semiconductor integration density and clock frequency of a single CPU core but also multi-core CPUs that increase the number of cores, heterogeneous hardware such as GPUs (Graphics Processing Units) and FPGAs has come to be used in normal application operations. Microsoft (registered trademark) is working on the use of FPGAs in search and the like. Also, Amazon (registered trademark)'s cloud provides FPGA and GPU instances. Furthermore, the use of small devices such as IoT (Internet of Things) devices as heterogeneous hardware is also increasing.

[0004] However, efficiently utilizing heterogeneous hardware that is not a single-core CPU requires the creation and configuration of programs tailored to the hardware, which is a significant hurdle for most engineers. Multi-core CPUs often require advanced knowledge of OpenMP (Open Multi-Processing), GPUs require CUDA (Compute Unified Device Architecture), FPGAs require OpenCL (Open Computing Language), and IoT devices require assembly language.

[0005] To make better use of heterogeneous hardware, a platform is needed that allows even ordinary engineers without advanced knowledge to maximize its potential. This platform needs to analyze software written by engineers using logic similar to that of a standard CPU, and then appropriately convert and configure it to suit the deployment environment (multi-core CPU, GPU, FPGA, etc.), enabling it to operate in an environment-appropriate manner.

[0006] General-Purpose GPUs (GPGPUs), which utilize the simple computing power of GPUs for general-purpose calculations, have become increasingly popular in recent years. NVIDIA® provides CUDA as an environment for this purpose. Furthermore, OpenCL is a specification that handles heterogeneous hardware such as FPGAs and GPUs in a common way, and many vendors are now supporting OpenCL. Both OpenCL and CUDA programs are written using extensions to the C language. These extensions describe things like the transfer of memory information between FPGAs (called kernels) and the host CPU, but they are said to require more hardware knowledge than standard C.

[0007] To enable the easy use of heterogeneous hardware such as GPUs, even without understanding the syntax of OpenCL or CUDA, the following approaches are being taken: Directives are used to specify lines that perform GPU processing, and based on these directives, the compiler creates binary files for the GPU or multi-core CPU. Furthermore, specifications such as OpenMP and OpenACC are interpreted and executed by compilers such as gcc and PGI.

[0008] FPGAs, GPUs, and multi-core CPUs can be easily utilized using OpenMP and OpenACC, and more finely tuned using OpenCL and CUDA. However, even if these hardware components can be used, performance improvement remains challenging. For example, Intel compilers automatically distribute processing across multiple CPU cores. When automated, Intel compilers find loops that can be processed in parallel within the program and distribute the processing across multiple cores. However, due to data copying and other factors, simply processing loops across multiple cores often does not improve performance. The situation is even more complex with GPUs and FPGAs, as memory configurations differ. Performance improvement requires tuning using OpenCL and CUDA. It also necessitates trial and error in finding appropriate GPU processing locations using tools like gcc. Thus, improving performance using heterogeneous hardware requires technical skills and the effort of trial and error.

[0009] As a way to GPU offload for loop statements, an offloading method using the evolutionary computation technique GA (Genetic Algorithm) has been proposed to automate the search for GPU processing locations for loop statements (Non-Patent Literature 1).

[0010] Furthermore, because compilation takes a long time on FPGAs and measurements cannot be taken repeatedly, a method has been proposed in which candidate loop statements are narrowed down based on the arithmetic strength of the loop statements and the FPGA resource usage during offloading, and then converted to OpenCL for measurement to search for an appropriate pattern (Non-Patent Literature 2). [Prior art documents] [Non-patent literature]

[0011] [Non-Patent Document 1] Y. Yamato, "Study and Evaluation of Improved Automatic GPU Offloading Method," International Journal of Parallel, Emergent and Distributed Systems, Taylor and Francis, DOI: 10.1080 / 17445760.2021.1941010, June 2021. [Non-Patent Document 2] Y. Yamato, "Automatic Offloading Method of Loop Statements of Software to FPGA," International Journal of Parallel, Emergent and Distributed Systems, Taylor and Francis, DOI: 10.1080 / 17445760.2021.1916020, Apr. 2021. [Overview of the project] [Problems that the invention aims to solve]

[0012] In conventional technology, offloading to heterogeneous hardware has mainly been done manually, and automated offloading methods are limited to the technologies described in Non-Patent Documents 1 and 2. Non-patent documents 1 and 2 examine the concept of environment-adaptive software, specifically focusing on GPU and FPGA automatic offloading methods for loop statements and other operations. However, the automatic offloading methods described in Non-Patent Documents 1 and 2 are based on the premise that adaptive processing such as conversion and deployment is performed before the application goes live, and do not anticipate reconfiguration in response to changes in usage characteristics after the application goes live. In other words, Non-Patent Documents 1 and 2 are all technologies for use before the application goes live, and do not consider reconfiguration after the application goes live.

[0013] For example, suppose that before the application went live, the logic to accelerate SQL processing was configured on an FPGA, assuming a large number of SQL queries. However, after going live (for example, six months later), the number of NoSQL queries increased, making it necessary to reconfigure the FPGA logic to accelerate NoSQL processing.

[0014] Thus, a challenge existed in that the system was not designed to be reconfigured after its launch in response to changes in usage characteristics, etc.

[0015] In view of these points, the present invention aims to improve the efficiency of resource utilization in PLDs (e.g., FPGAs) with limited resources by reconfiguring the logic to be more appropriate not only before operation begins but also according to usage characteristics after operation begins. [Means for solving the problem]

[0016] To solve the aforementioned problems, an offload server is provided that offloads specific processing of an application to a PLD (Programmable Logic Device), comprising: an application code analysis unit that analyzes the source code of the application; a PLD processing specification unit that identifies loop statements of the application and, for each identified loop statement, creates and compiles pipeline processing and parallel processing in the PLD using multiple offload processing patterns specified in OpenCL; an arithmetic strength calculation unit that calculates the arithmetic strength of the loop statements of the application; a PLD processing pattern creation unit that, based on the arithmetic strength calculated by the arithmetic strength calculation unit, narrows down loop statements with an arithmetic strength higher than a predetermined threshold as offload candidates and creates a PLD processing pattern; a performance measurement unit that compiles the application of the created PLD processing pattern, places it in an accelerator verification device, and executes performance measurement processing when offloaded to the PLD; and, based on the performance measurement results from the performance measurement processing, selects the PLD with the highest processing performance from the multiple PLD processing patterns. The system comprises: an executable file creation unit that selects a D processing pattern, compiles the PLD processing pattern with the highest processing performance, and creates an executable file; a processing load analysis unit that analyzes the request processing load of data actually used by users; a representative data selection unit that identifies applications with high request processing loads analyzed by the processing load analysis unit and selects representative data from the request data used when those applications are used; an improvement degree calculation unit that determines a new offload pattern based on the representative data selected by the representative data selection unit by executing the application code analysis unit, the PLD processing specification unit, the arithmetic intensity calculation unit, the PLD processing pattern creation unit, the performance measurement unit, and the executable file creation unit, calculates the performance improvement effect by comparing the processing time and usage frequency of the determined new offload pattern with the processing time and usage frequency of the current offload pattern; and a reconstruction proposal unit that proposes a PLD reconstruction if the performance improvement effect is above a predetermined threshold. The processing load analysis unit acquires request data for a predetermined period from the top-loading applications, sorts the data into fixed-size groups to create a frequency distribution, and the representative data selection unit selects one data point from the actual request data corresponding to the mode of the frequency distribution and selects it as the representative data. This offload server is characterized by the following features. [Effects of the Invention]

[0017] According to the present invention, it is possible to reconfigure to a more appropriate logic according to the usage characteristics after the start of operation, and to improve the resource utilization efficiency in a PLD (for example, FPGA) with limited resource amount.

Brief Description of Drawings

[0018] [Figure 1] It is a diagram showing an environment-adaptive software system including an offload server according to an embodiment of the present invention. [Figure 2] It is a functional block diagram showing a configuration example of the offload server according to the above embodiment. [Figure 3] It is a diagram showing the automatic offload process of the offload server according to the above embodiment. [Figure 4] It is a flowchart showing the reconfiguration after the start of operation of the offload server according to the above embodiment. [Figure 5] It is a detailed flowchart of the commercial request data history analysis process of the offload server according to the above embodiment. [Figure 6] It is a detailed flowchart of the extraction process of commercial representative data of the offload server according to the above embodiment. [Figure 7] It is a flowchart for explaining the outline of the operation of the implementation of the offload server according to the above embodiment. [Figure 8] It is a diagram for explaining the outline of the operation of the implementation of the offload server according to the above embodiment. [Figure 9] It is a diagram for explaining the flow from the C code of the offload server according to the above embodiment to the search for the final OpenCL solution. [Figure 10] It is a hardware configuration diagram showing an example of a computer that realizes the functions of the offload server according to an embodiment of the present invention.

Modes for Carrying Out the Invention

[0019] Next, the offload server 1 and the like in the mode for carrying out the present invention (hereinafter referred to as "the present embodiment") will be described. In the following description of the specification, an example of applying the invention to an FPGA (Field Programmable Gate Array) as a PLD (Programmable Logic Device) will be explained. The present invention is applicable to programmable logic devices in general.

[0020] (Background explanation) [Environmentally Adaptable Software] The environment-adaptive software executed by the offload server of the present invention has the following characteristics. Specifically, by executing the environment-adaptive software, the offload server automatically converts, configures resources, and determines the deployment of program code that has been written once, so that it can utilize GPUs, FPGAs, multi-core CPUs, etc., present in the deployment environment, thereby enabling the application to run at high performance. Elements of the environment-adaptive software include a method that automatically offloads code loop statements and functional blocks to GPUs and FPGAs, and a method that appropriately allocates the amount of processing resources such as GPUs.

[0021] <Automatic Off-Road System> The applications that we want to offload are diverse. Furthermore, in computationally intensive and time-consuming applications such as image analysis for video processing and machine learning processing for sensor data analysis, loop-based repetitive processing accounts for a significant portion of the time. Therefore, automatically offloading loop statements to an FPGA is a viable target for speeding up the process.

[0022] First, there are fundamental challenges when automatically offloading loop statements to other hardware such as FPGAs. That is, while compilers can identify limitations such as "this loop statement cannot be processed by other hardware such as FPGAs," it is currently difficult for them to identify the suitability of a loop statement for processing on other hardware such as FPGAs. Furthermore, when automatically offloading loop statements to FPGAs, loops with a large number of iterations or high arithmetic intensity (such as the number of calculations) are generally considered more suitable. However, it is difficult to predict the actual performance improvement without measurement. Therefore, manual instruction to offload loop statements to other hardware such as FPGAs is often used, and performance measurements are conducted through trial and error. Therefore, the plan is to narrow down the patterns to be actually measured in performance, place them in the accelerator verification environment, and reduce the number of times performance is measured on the actual FPGA.

[0023] [Reconfiguration of the application after it has gone live] This section explains how to reconfigure an application after it has been put into operation. The automatic offloading methods described in Non-Patent Documents 1 and 2 were based on the premise that adaptive processing such as conversion and deployment was performed before the application was put into operation. Incidentally, with the exception of special applications such as reconfiguring circuits for artificial satellites, there are no examples, even among commercial clouds (such as FPGA instances on Amazon Web Services (AWS)) of reconfiguring FPGA logic according to usage characteristics during application operation ("during operation" is a form of "after operation has started") when using FPGAs to accelerate application servers. This is because reconfiguring FPGA logic during operation is extremely difficult.

[0024] This invention reconfigures the FPGA offload logic (hereinafter referred to as FPGA logic) in response to changes in usage characteristics after the application has started operation. For example, the FPGA logic is reconfigured in response to usage characteristics during operation.

[0025] This invention first involves offloading a standard CPU program to an FPGA and starting operation (<adaptive processing such as conversion and placement before starting operation>). Next, we analyze the request characteristics and modify the FPGA logic in a separate program (<reconfiguration after operational launch>).

[0026] (Embodiment) Figure 1 shows an environment-adaptive software system including an offload server 1 according to this embodiment. The environment-adaptive software system according to this embodiment is characterized by including an offload server 1 in addition to the configuration of conventional environment-adaptive software. The offload server 1 is an offload server that offloads specific processing of an application to an accelerator. The offload server 1 is also communicated with devices located in three layers: cloud layer 2, network layer 3, and device layer 4. A data center 30 is located in cloud layer 2, a network edge 20 is located in network layer 3, and a gateway 10 is located in device layer 4.

[0027] Therefore, the environment-adaptive software system including the offload server 1 according to this embodiment achieves efficiency by appropriately placing functions and offloading processing in each of the device layer, network layer, and cloud layer. Primarily, efficiency is achieved by optimizing function placement by placing functions in appropriate locations in the three layers for processing, and by offloading functional processing such as image analysis to heterogeneous hardware such as GPUs and FPGAs.

[0028] The following describes an example configuration for when the offload server 1 according to this embodiment performs offload processing in the background of user service utilization in the environment-adaptive software system. When providing the service, the plan is to offer it to users on the first day in the form of a trial use, while performing offloaded processing such as image analysis in the background. From the following day onward, the image analysis will be offloaded to an FPGA, enabling the monitoring service to be offered at a reasonable price.

[0029] Figure 2 is a functional block diagram showing an example configuration of the offload server 1 according to an embodiment of the present invention. Offload Server 1 is a device that executes environment-adaptive software processing. As a form of this environment-adaptive software, Offload Server 1 automatically offloads specific processing of an application to an accelerator (<automatic offloading>). Furthermore, Offload Server 1 can connect to the emulator.

[0030] As shown in Figure 2, the offload server 1 is composed of a control unit 11, an input / output unit 12, a storage unit 13, and a verification machine 14 (accelerator verification device).

[0031] The input / output unit 12 consists of a communication interface for sending and receiving information with each device, and an input / output interface for sending and receiving information with input devices such as touch panels and keyboards, and output devices such as monitors.

[0032] The memory unit 13 is composed of a hard disk, flash memory, RAM (Random Access Memory), etc. This memory unit 13 stores the code pattern DB 131, the equipment resource DB 132, and the test case database 133, as well as programs (offload programs) for executing each function of the control unit 11, and information necessary for processing by the control unit 11 (for example, an intermediate language file 134).

[0033] Test case DB133 stores performance test items. Test case DB133 stores information for conducting tests that measure the performance of applications that are being accelerated. For example, for a deep learning application that performs image analysis, it would contain sample images and test items for executing them. The verification machine 14 is equipped with a CPU (Central Processing Unit), GPU, and FPGA (accelerator) as a verification environment for environment adaptation software. In Figure 2, the offload server 1 is configured to include a verification machine 14, but the verification machine 14 may be located outside of the offload server 1.

[0034] 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 CPU (not shown) that loads a program (offload program) stored in the memory unit 13 into RAM and executes it.

[0035] The control unit 11 includes an application code specification unit 111, an application code analysis unit 112, a PLD processing specification unit 113, an arithmetic strength calculation unit 114, a PLD processing pattern creation unit 115, a performance measurement unit 116, an executable file creation unit 117, a production environment deployment unit 118, a performance test extraction and execution unit 119, a request processing load analysis unit 120 (processing load analysis unit), a representative data selection unit 121, an improvement degree calculation unit 122, a reconstruction proposal unit 123, and a user provision unit 124.

[0036] <Application Code Designation Unit 111> The Application Code Designation Unit 111 designates the input application code. Specifically, the Application Code Designation Unit 111 identifies the processing functions (such as image analysis) of the services provided to the user.

[0037] <Application Code Analysis Unit 112> The Application Code Analysis Unit 112 analyzes the source code of the processing function and grasps the structure such as loop statements and FFT library calls.

[0038] <PLD Processing Designation Unit 113> The PLD Processing Designation Unit 113 identifies the loop statements (repetitive statements) of the application, and for each identified loop statement, creates and compiles a plurality of offload processing patterns specified in OpenCL for pipeline processing and parallel processing in the PLD. The PLD Processing Designation Unit 113 includes an Offload Range Extraction Unit (Extract offloadable area) 113a and an Intermediate Language File Output Unit (Output intermediate file) 113b.

[0039] The Offload Range Extraction Unit 113a identifies processing that can be offloaded to the FPGA, such as loop statements and FFT, and extracts intermediate language corresponding to the offload processing.

[0040] The Intermediate Language File Output Unit 113b outputs the extracted intermediate language file 134. The intermediate language extraction is not completed at once, and is repeated for trial execution and optimization for appropriate offload area exploration.

[0041] <Arithmetic Intensity Calculation Unit 114> The arithmetic intensity calculation unit 114 calculates the arithmetic intensity of the loop statements of an application using an arithmetic intensity analysis tool such as the ROSE framework (registered trademark). The arithmetic intensity is the value obtained by dividing the number of floating point operations (floating point number, FN) executed during the operation of the program by the number of bytes accessed to the main memory (FN operations / memory access). The arithmetic intensity is an index that increases when the number of calculations is large and decreases when the number of accesses is large. A process with a high arithmetic intensity is a heavy process for the processor. Therefore, an arithmetic intensity analysis tool is used to analyze the arithmetic intensity of the loop statement. The PLD processing pattern creation unit 115 narrows down the loop statements with high arithmetic intensity as offload candidates.

[0042] An example of the calculation of arithmetic intensity will be described. Assume that the floating point calculation process within one loop is performed 10 times per second (10 FLOPS), and the data used within the loop is 2 bytes. When data of the same size is used for each loop, 10 / 2 = 5 [FLOPS / byte] becomes the arithmetic intensity. 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.

[0043] <PLD processing pattern creation unit 115> Based on the arithmetic intensity calculated by the arithmetic intensity calculation unit 114, the PLD processing pattern creation unit 115 narrows down the 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. In addition, as a basic operation, the PLD processing pattern creation unit 115 creates a PLD processing pattern that excludes loop statements (repetition statements) that cause compilation errors from the offload targets and designates whether to perform PLD processing on repetition statements that do not cause compilation errors.

[0044] · Loop count measurement function The PLD processing pattern creation unit 115, as a loop count measurement function, uses a profiling tool to measure the number of loops in the application's loop statements and narrows down the loop statements to those with high arithmetic intensity and a loop count greater than a predetermined number (hereinafter referred to as high loop count). GNU coverage gcov or similar tools are used to determine the number of loops. Known profiling tools include "GNU Profiler (gprof)" and "GNU Coverage (gcov)". Since both can investigate the execution count of each loop, either can be used.

[0045] Furthermore, since the number of loops is not particularly visible in arithmetic intensity analysis, a profiling tool is used to measure the number of loops in order to detect loops with a high number of loops and high load. Here, high arithmetic intensity indicates whether the processing is suitable for offloading to an FPGA, and the number of loops × arithmetic intensity indicates whether the load related to offloading to an FPGA is high.

[0046] • OpenCL creation function The PLD processing pattern creation unit 115, as an OpenCL creation function, creates (converts to OpenCL) OpenCL for offloading each selected loop statement to the FPGA. In other words, the PLD processing pattern creation unit 115 compiles OpenCL that offloads the selected loop statements. Furthermore, the PLD processing pattern creation unit 115 lists the loop statements that have shown improved performance compared to the CPU based on performance measurements, and creates OpenCL that combines the loop statements in the list for offloading.

[0047] This section discusses the use of OpenCL. The PLD processing pattern creation unit 115 converts loop statements into a high-level language such as OpenCL. First, it divides the CPU processing program into a kernel (FPGA) and a host (CPU) according to the syntax of a high-level language such as OpenCL. For example, if one of ten for statements is to be processed by the FPGA, that one statement is extracted as a kernel program and written according to the syntax of OpenCL. An example of OpenCL syntax will be described later.

[0048] Furthermore, techniques for speeding up the process can be incorporated during the partitioning process. Generally, techniques for speeding up the process using FPGAs include local memory caching, stream processing, multiple instantiation, loop statement unpacking, nested loop statement merging, and memory interleaving. While these techniques do not always have a definitive effect depending on the loop statement, they are commonly used methods for speeding up the process.

[0049] A kernel created according to the OpenCL C language syntax is executed on a device (e.g., FPGA) by a host program (e.g., CPU) using the OpenCL C language runtime API. The part that calls the kernel function hello() from the host side is the call to clEnqueueTask(), which is one of the OpenCL runtime APIs. The basic flow of OpenCL initialization, execution, and termination written in host code is as follows (steps 1-13). Of these steps, steps 1-10 are the procedures (preparation) up to calling the kernel function hello() from the host side, and step 11 is the execution of the kernel.

[0050] 1. Platform Identification The platform on which OpenCL is running is identified using the `clGetPlatformIDs()` function, which provides platform identification capabilities defined in the OpenCL runtime API.

[0051] 2. Device Identification The `clGetDeviceIDs()` function, which provides device identification capabilities defined in the OpenCL runtime API, is used to identify devices such as GPUs used on the platform.

[0052] 3. Create a context The `clCreateContext()` function, which provides context creation functionality defined in the OpenCL runtime API, is used to create an OpenCL context, which serves as the execution environment for running OpenCL.

[0053] 4. Create a command queue The `clCreateCommandQueue()` function, defined in the OpenCL runtime API, is used to create a command queue, which is necessary to prepare the device for control. In OpenCL, commands are used to interact with the device from the host (issuing kernel execution commands and host-device memory copy commands).

[0054] 5. Create a memory object A memory object is created that can be accessed from the host side using the clCreateBuffer() function, which provides the functionality to allocate memory on a device as defined in the OpenCL runtime API.

[0055] 6. Load the kernel file The kernel executed on the device is controlled by the host program. Therefore, the host program must first load the kernel program. The kernel program consists of binary data created by the OpenCL compiler and source code written in OpenCL C. This kernel file is then loaded (details omitted). Note that the OpenCL runtime API is not used for loading the kernel file.

[0056] 7. Create a program object In OpenCL, kernel programs are recognized as program projects. This process is called program object creation. The `clCreateProgramWithSource()` function, defined in the OpenCL runtime API, is used to create a program object that can be accessed from the host side. To create a program object from a compiled binary sequence of a kernel program, use `clCreateProgramWithBinary()`.

[0057] 8. Build The program object registered as source code is built using the OpenCL C compiler and linker. The program object is built using the `clBuildProgram()` function, which executes a build using the OpenCL C compiler and linker as defined in the OpenCL runtime API. Note that this compilation procedure is unnecessary if the program object is generated from a pre-compiled binary sequence using `clCreateProgramWithBinary()`.

[0058] 9. Create a kernel object A kernel object is created using the `clCreateKernel()` function, which provides kernel object creation functionality as defined in the OpenCL runtime API. Since one kernel object corresponds to one kernel function, 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, each kernel object corresponds one-to-one with one kernel function, so `clCreateKernel()` is called multiple times.

[0059] 10. Kernel argument settings The kernel arguments are set using the clSetKernel() function, which is defined in the OpenCL runtime API and provides the functionality to pass arguments to the kernel (pass values ​​to the arguments of the kernel function). With the preparations complete in steps 1-10 above, we proceed to step 11, where the host executes the kernel on the device.

[0060] 11. Kernel execution Kernel execution (placing commands in the command queue) is an action taken on a device, and therefore acts as a queuing function for the command queue. The command to execute the kernel hello on the device is queued using the clEnqueueTask() function, which provides kernel execution functionality as defined in the OpenCL runtime API. After the command to execute the kernel hello is queued, it will be executed on an executable arithmetic unit on the device.

[0061] 12. Reading from memory objects The `clEnqueueReadBuffer()` function, defined in the OpenCL runtime API, is used to copy data from device-side memory to host-side memory. Similarly, the `clEnqueueWrightBuffer()` function, which copies data from host-side memory to host-side memory, is used to copy data from host-side memory to device-side memory. Note that these functions interact with the device, so the copy command will be queued in the command queue before data copying begins.

[0062] 13. Release Objects Finally, we release all the objects we have created so far. The above explains device execution of a kernel written in accordance with the OpenCL C language.

[0063] • Resource quantity calculation function The PLD processing pattern creation unit 115 calculates the amount of resources to be used by precompiling the created OpenCL as a resource amount calculation function ("First resource amount calculation"). Based on the calculated arithmetic strength and resource amount, the PLD processing pattern creation unit 115 calculates resource efficiency, and based on the calculated resource efficiency, selects c loop statements in each loop statement whose resource efficiency is higher than a predetermined value. The PLD processing pattern creation unit 115 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 from precompilation before the first measurement without precompilation.

[0064] <Performance measurement section 116> The performance measurement unit 116 compiles the created PLD processing pattern application, places it on the verification machine 14, and executes the performance measurement processing when it is offloaded to the PLD. The performance measurement unit 116 includes a binary file deployment unit 116a. The binary file deployment unit 116a deploys (places) executable files derived from the intermediate language to the verification machine 14 equipped with an FPGA.

[0065] The performance measurement unit 116 executes the placed binary file, measures the performance when offloaded, and returns the performance measurement results to the offload range extraction unit 113a. In this case, the offload range extraction unit 113a extracts another PLD processing pattern, and the intermediate language file output unit 113b attempts to measure the performance based on the extracted intermediate language (see symbol aa in Figure 3 below).

[0066] This section will describe specific examples of performance measurement. The PLD processing pattern creation unit 115 narrows down the loop statements to those with high resource efficiency, and the executable file creation unit 117 compiles OpenCL to offload the narrowed-down loop statements. The performance measurement unit 116 measures the performance of the compiled program ("first performance measurement").

[0067] The PLD processing pattern creation unit 115 then lists the loop statements that have been shown to be more efficient than those used by the CPU during performance testing. The PLD processing pattern creation unit 115 combines the loop statements in the list to create OpenCL for offloading. The PLD processing pattern creation unit 115 then calculates the amount of resources to be used by precompiling the combined offloaded OpenCL. Alternatively, instead of pre-compiling, the sum of resource amounts from pre-compilation before the first measurement may be used. The executable file creation unit 117 compiles the combined offload OpenCL, and the performance measurement unit 116 measures the performance of the compiled program ("second performance measurement").

[0068] <Executable file creation section 117> The executable file creation unit 117 selects the PLD processing pattern with the best processing performance from among multiple PLD processing patterns based on the performance measurement results that have been repeated a predetermined number of times, compiles the PLD processing pattern with the best processing performance, and creates an executable file.

[0069] <Production Environment Deployment Section 118> The production environment deployment unit 118 deploys the created executable file to the user's production environment ("Deployment of the final binary file to the production environment"). The production environment deployment unit 118 determines a pattern specifying the final offload area and deploys it to the user's production environment.

[0070] <Performance measurement test extraction and execution unit 119> The performance measurement test extraction and execution unit 119 extracts performance test items from the test case DB 133 after the execution file has been placed, and then executes the performance test. The performance measurement test extraction and execution unit 119, after the execution file has been placed, extracts performance test items from the test case DB 133 to show the performance to the user, and automatically executes the extracted performance tests.

[0071] <Request Processing Load Analysis Unit 120> The request processing load analysis unit 120 analyzes the request processing load of commercial representative data (data actually used by users).

[0072] The request processing load analysis unit 120 calculates the actual processing time and total number of uses from the usage history of each application over a predetermined period.

[0073] The request processing load analysis unit 120 acquires request data from the top-performing applications over a certain period, sorts the data into fixed-size groups, and creates a frequency distribution.

[0074] <Representative Data Selection Section 121> The representative data selection unit 121 identifies the application with the highest processing load, as analyzed by the request processing load analysis unit 120, and selects representative data from the request data used when that application is in use. Specifically, the representative data selection unit 121 selects one data point from the actual request data corresponding to the mode of the data size frequency distribution, as analyzed by the request processing load analysis unit 120, and selects it as representative data.

[0075] <Improvement degree calculation section 122> The improvement calculation unit 122 determines a new offload pattern (a new offload pattern found in the verification environment) based on the representative data selected by the representative data selection unit 121 by executing the application code analysis unit 112, the PLD processing specification unit 113, the arithmetic strength calculation unit 114, the PLD processing pattern creation unit 115, the performance measurement unit 116, and the executable file creation unit 117. It then calculates the performance improvement effect by comparing the processing time and usage frequency of the determined new offload pattern with the processing time and usage frequency of the current offload pattern.

[0076] The improvement calculation unit 122 measures the processing time for the current off-road pattern and several new off-road patterns, and calculates the performance improvement effect based on the frequency of commercial use according to (actual processing reduction time in the verification environment) × (frequency of use in the commercial environment).

[0077] <Reconfiguration proposal section 123> The reconstruction proposal unit 123 proposes PLD reconstruction if the performance improvement effect is above a predetermined threshold.

[0078] <User-provided section 124> The user provision unit 124 presents the user with information such as price and performance based on the performance test results ("Provision of Price and Performance Information to the User"). The test case DB 133 stores data for automatically performing tests to measure the performance of the application. The user provision unit 124 presents the user with the price of the entire system, which is determined from the results of executing the test data in the test case DB 133 and the unit prices of each resource used in the system (virtual machines, FPGA instances, GPU instances, etc.). The user decides whether to start billing for the service based on the presented price and performance information.

[0079] The following describes the automatic offload operation of offload server 1, which is configured as described above. The offload server 1 according to this embodiment is characterized by its ability to perform reconfiguration of the FPGA logic after it has been put into operation. The automatic offload processing performed by the offload server 1 as a form of environment-adaptive software is the same before and after the reconfiguration. That is, the automatic offload processing of the offload server 1 shown in Figure 3 is the same before and after the reconfiguration, but the difference is that before the reconfiguration the data handled is expected usage data, whereas after the reconfiguration the data handled is data that is actually used commercially (commercial representative data).

[0080] [Automatic Offload Operation] The offload server 1 of this embodiment is an example of applying FPGA automatic offloading of user application logic as an elemental technology of environment-adaptive software. Figure 3 shows the automatic offloading process of offload server 1. The automatic offloading process in Figure 3 is the same before and after the reconfiguration process.

[0081] As shown in Figure 3, the offload server 1 is applied to the elemental technology of the environment-adaptive software. The offload server 1 includes a control unit (automatic offload function unit) 11 that executes environment-adaptive software processing, a code pattern DB 131, an equipment resource DB 132, a test case DB 133, an intermediate language file 134, and a verification machine 14.

[0082] Offload server 1 retrieves the application code 130 that the user will use.

[0083] The user utilizes the OpenIoT resources 15, which are a commercial environment, such as various devices 151, a device 152 with a CPU-GPU, a device 153 with a CPU-FPGA, and a device 154 with a CPU. The offload server 1 automatically offloads the functional processing to the accelerators of the device 152 with a CPU-GPU and the device 153 with a CPU-FPGA.

[0084] Offload Server 1 executes environment-adapted software processing by integrating platform functions consisting of Code Pattern DB131, Equipment Resource DB132, and Test Case DB133, based on the environment adaptation functions of the commercial and verification environments provided by the service provider.

[0085] The operation of each part of the automatic offload operation (before operation begins) will be explained below, referring to the step numbers in Figure 3. [Automatic offload operation (before operation begins)] First, we perform the necessary steps before launching the application: code conversion, resource allocation adjustments, deployment location adjustments, and verification.

[0086] <Step S11: Specify application code: Specify application code> In step S11, the application code specification unit 111 (see Figure 2) identifies the processing function (image analysis, etc.) of the service provided to the user. Specifically, the application code specification unit 111 specifies the input application code.

[0087] <Step S12: Analyze application code> In step S12, the application code analysis unit 112 (see Figure 2) analyzes the source code of the processing function and understands its structure, such as loop statements and FFT library calls.

[0088] <Step S21: Extract offloadable area> In step S21, the PLD processing specification unit 113 (see Figure 2) identifies the loop statements (repeating statements) of the application, specifies parallel processing or pipeline processing in the FPGA for each repeating statement, and compiles it using a high-level synthesis tool. Specifically, the offload range extraction unit 113a (see Figure 2) identifies the processes that can be offloaded to the FPGA, such as loop statements, and extracts OpenCL as an intermediate language corresponding to the offload processing.

[0089] <Step S22: Output intermediate file: Output of intermediate language file> In step S22, the intermediate language file output unit 113b (see Figure 2) outputs an intermediate language file 134. Intermediate language extraction is not a one-time process; it is iteratively performed to optimize execution and find appropriate offload areas.

[0090] <Step S23: Compile error: Create PLD processing pattern> In step S23, the PLD processing pattern creation unit 115 (see Figure 2) creates a PLD processing pattern that excludes loop statements that produce compilation errors from offloading, and specifies whether or not to perform FPGA processing on repeating statements that do not produce compilation errors.

[0091] <Step S31: Deploy binary files: Placement of executable files> In step S31, the binary file placement unit 116a (see Figure 2) deploys the executable file derived from the intermediate language to the verification machine 14 equipped with an FPGA. The binary file placement unit 116a then starts the deployed file, executes the assumed test cases, and measures the performance when offloaded.

[0092] <Step S32: Measure performances: Performance measurement for appropriate pattern search> In step S32, the performance measurement unit 116 (see Figure 2) executes the deployed file and measures the performance when it is offloaded. To make the offload area more appropriate, the performance measurement results are returned to the offload range extraction unit 113a, which then extracts a different pattern. The intermediate language file output unit 113b then attempts performance measurement based on the extracted intermediate language (see symbol aa in Figure 3). The performance measurement unit 116 repeatedly performs performance measurements in the verification environment and finally determines the code pattern to be deployed.

[0093] As shown by the symbol aa in Figure 3, the control unit 11 repeatedly executes steps S12 to S23 described above. The automatic offload function of the control unit 11 can be summarized as follows: The PLD processing specification unit 113 identifies the loop statements (repeating statements) of the application, specifies parallel processing or pipeline processing in the FPGA using OpenCL for each repeating statement, and compiles it using a high-level synthesis tool. The PLD processing pattern creation unit 115 then excludes loop statements that produce compilation errors from offloading, and creates a PLD processing pattern that specifies whether or not to perform PLD processing on loop statements that do not produce compilation errors. The binary file placement unit 116a then compiles the application of the corresponding PLD processing pattern and places it on the verification machine 14, and the performance measurement unit 116 executes performance measurement processing on the verification machine 14. The executable file creation unit 117 selects the pattern with the best processing performance from among multiple PLD processing patterns based on the performance measurement results that have been repeated a predetermined number of times, compiles the selected pattern, and creates an executable file.

[0094] <Step S41: Determining the resource size> The control unit 11 determines the resource size (see reference numeral bb in Figure 3).

[0095] <Step S51: Selecting a suitable location> The control unit 11 selects an appropriate location by referring to the equipment resource DB 132.

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

[0097] <Step S62: Extract performance test cases and run automatically: Test case extraction and health check> In step S62, the performance measurement test extraction and execution unit 119, after placing the executable file, extracts performance test items from the test case DB 133 to show the performance to the user, and automatically executes the extracted performance tests.

[0098] <Step S63: Provide price and performance information to a user to help them decide whether to start using the service.> In step S63, the user provision unit 124 presents the user with information such as price and performance based on the performance test results. The user then decides to start using the service based on the presented information such as price and performance.

[0099] Steps S11 to S63 described above are performed in the background while the user is using the service, and are intended to be performed, for example, during the first day of trial use. Furthermore, in order to reduce costs, the processing performed in the background may be limited to GPU / FPGA offloading only.

[0100] As described above, when applied to the elemental technologies of environment-adaptive software, the control unit (automatic offload function unit) 11 of the offload server 1 extracts the areas to be offloaded from the source code of the application used by the user and outputs intermediate language for the purpose of offloading functional processing (steps S11 to S23). The control unit 11 places and executes the executable file derived from the intermediate language on the verification machine 14 to verify the offload effect (steps S31 to S32). After repeating the verification and determining the appropriate offload area, the control unit 11 deploys the executable file to the actual production environment provided to the user and provides it as a service (steps S41 to S63).

[0101] In the above description, a processing flow that collectively performs code conversion, resource amount adjustment, and placement location adjustment, which are necessary for environmental adaptation, has been described. However, it is not limited to this, and it is also possible to extract only the processing to be performed. For example, when only code conversion for FPGA is to be performed, only the necessary parts such as the environmental adaptation function and verification environment in steps S11 to S31 above may be used.

[0102] <FPGA Automatic Offloading> The above-described code analysis is performed on the application code using a syntax analysis tool such as Clang. Since code analysis requires analysis assuming the device to be offloaded, generalization is difficult. However, it is possible to grasp the structure of the code such as loop statements and variable reference relationships, or to grasp that it is a functional block that performs FFT processing as a functional block, or that a library that performs FFT processing is called. It is difficult for the offloading server to automatically determine the functional block. It is also possible to grasp this through similarity determination using a similar code detection tool such as Deckard. Here, Clang is a tool for C / C++, but it is necessary to select a tool according to the language to be analyzed.

[0103] Also, when offloading the processing of an application, in each of the GPU, FPGA, IoT GW, etc., consideration according to the offloading destination is required. Generally, it is difficult to automatically discover the setting that achieves the maximum performance regarding performance. Therefore, the offloading pattern is tried by repeating performance measurement several times in the verification environment to find a pattern that can be speeded up.

[0104] The above is the description of [Automatic Offloading Operation (Before Operation Start)]. Summarizing the automatic offloading operation (before operation start) is as follows. Steps S11, S12 in Figure 3: Code analysis Steps S21 to S23 in Figure 3: Extraction of offloadable parts Steps S31 to S32 in Figure 3: Search for appropriate offload parts Step S41 in Figure 3: Resource amount adjustment Step S51 in Figure 3: Adjusting the placement location Steps S61-S63 in Figure 3: Executable file placement and operation verification.

[0105] Steps S11 to S63 described above involve code conversion, resource allocation adjustment, deployment location adjustment, and verification, which are necessary before the application can be put into operation.

[0106] [Automatic offload operation (after commencement of operation)] Next, referring to the step numbers in Figure 3, we will explain the operation of each part of the automatic offload operation (after the start of operation). As described above, offload server 1 performs the reconfiguration of the FPGA logic after it has been put into operation. Post-launch reconfiguration involves analyzing usage characteristics and other factors after the application goes live, and performing necessary reconfigurations. The reconfigurations target the same areas as before launch: code conversion, resource allocation adjustments, and deployment location adjustments.

[0107] <Basic policy for reconfiguring FPGAs in operation> First, I will describe the basic policy for reconfiguring FPGAs in operation. The method shown in Figure 3 (see the flowchart in Figure 4 below for details) allows for the automatic offloading of loop statements suitable for FPGAs in a user-specified application to the FPGA. After offloading to the user's commercial environment, the actual performance and price in the commercial environment are verified, and the user begins using the application. However, the performance optimization test cases (items measured when comparing performance across multiple offload patterns) use pre-operational usage data specified by the user, and may deviate significantly from the actual data used after operation begins.

[0108] Therefore, in the following sections, we will consider reconfiguring the FPGA logic while minimizing user impact if the usage pattern after the system goes live differs from the initial assumptions, and performance can be improved by offloading different logic to the FPGA. Reconfiguration may involve changing to offloading different loop statements within the same application, or it may involve offloading a different application altogether.

[0109] There are two methods for reconfiguring an FPGA: dynamic reconfiguration and static reconfiguration. Dynamic reconfiguration is a technique that changes the circuit configuration while the FPGA is running, and the downtime for rewriting is on the order of milliseconds. On the other hand, static reconfiguration is a technique that changes the circuit configuration after stopping the FPGA, and the downtime is about 1 second. Whether to adopt dynamic or static reconfiguration depends on the user impact of the downtime, and the reconfiguration method provided by the FPGA vendor should be selected. However, since downtime occurs in both methods, and rewriting to a different logic requires operational verification testing, reconfiguration should not be performed frequently, and restrictions should be placed on it, such as proposing it only when the effect exceeds a certain threshold.

[0110] The reconfiguration under consideration begins with an analysis of request trends over a certain period (e.g., one month). By analyzing request trends, we identify whether there are any applications that have a higher processing load than or are equivalent to the currently offloaded applications. Next, we conduct FPGA offload optimization trials in a verification environment (Figure 3) using actual commercially used data (data actually used by users) rather than hypothetical usage data for requests with high processing loads.

[0111] The verification process determines whether the newly discovered off-road pattern offers a significant improvement over the current pattern by checking whether the calculated processing time and usage frequency exceed or fall below a threshold. If the calculated processing time and usage frequency exceed the threshold, a reconfiguration is proposed to the user. After user approval, the commercial environment is reconfigured, but with the aim of minimizing user impact as much as possible. If the calculated processing time and usage frequency fall below the threshold, no reconfiguration proposal is made to the user.

[0112] <Flowchart showing reconfiguration after operational commencement> Figure 4 is a flowchart showing the reconfiguration of Offload Server 1 after it has been put into operation. This is an example applied to FPGA reconfiguration. In step S71, the request processing load analysis unit 120 analyzes the request processing load of data actually used by users. The detailed flow of the commercial request data history analysis process is shown later in Figure 5.

[0113] In step S72, the representative data selection unit 121 extracts offload patterns that speed up test cases of commercial representative data for multiple top-performing applications through verification environment measurements. Specifically, the representative data selection unit 121 selects one data point from the actual request data corresponding to the mode of the data size frequency distribution analyzed by the request processing load analysis unit 120, and selects it as representative data. In steps S71 to S72 above, the applications with the highest load are selected.

[0114] In step S73, the improvement calculation unit 122 determines a new offload pattern (a new offload pattern found in the verification environment) based on the representative data selected by the representative data selection unit 121 by executing the application code analysis unit 112, the PLD processing specification unit 113, the arithmetic strength calculation unit 114, the PLD processing pattern creation unit 115, the performance measurement unit 116, and the executable file creation unit 117. It then calculates the performance improvement effect by comparing the processing time and usage frequency of the determined new offload pattern with the processing time and usage frequency of the current offload pattern.

[0115] In other words, the improvement calculation unit 122 measures the processing time of the current off-road pattern and the extracted new off-road patterns, and determines the performance improvement effect based on the frequency of commercial use. Specifically, the improvement calculation unit 122 calculates (actual processing reduction time in the verification environment) × (frequency of commercial use) ... equation (1) for the current off-road pattern using test cases with representative commercial data. Then, the improvement calculation unit 122 calculates (actual processing reduction time in the verification environment) × (frequency of commercial use) ... equation (2) for the multiple new off-road patterns. The detailed flow of the extraction process for representative commercial data will be shown later in Figure 6.

[0116] Thus, in step S73, for applications that are offloaded to the FPGA, an improvement coefficient is applied to calculate the case where the application is not offloaded, and the comparison is made after correcting it to only include CPU processing. Also, when selecting representative data, the mode of the data size is used because the average data size may differ significantly from the actual usage data.

[0117] In step S74, the reconstruction proposal unit 123 determines whether to propose a reconstruction based on whether the performance improvement effect of the new off-road pattern is equal to or greater than a predetermined threshold for the current off-road pattern. Specifically, the reconstruction proposal unit 123 calculates the result of equation (2) / the result of equation (1) for multiple off-road patterns. The reconstruction proposal unit 123 then checks whether the result of equation (2) / the result of equation (1) is equal to or greater than a predetermined threshold. If the result of equation (2) / the result of equation (1) is equal to or greater than the predetermined threshold, it proposes a reconstruction; otherwise, it does nothing (does not propose a reconstruction).

[0118] In step S75, the reconfiguration proposal unit 123 proposes to the contract user that they perform FPGA reconfiguration and obtains a response from the contract user indicating OK / NG for performing FPGA reconfiguration.

[0119] In step S76, the control unit 11 performs the static reconstruction described above by starting a separate OpenCL in the commercial environment and terminates the processing of this flow. Specifically, the control unit 11 first compiles the new offload pattern. Next, the control unit 11 stops the operation of the current offload pattern and starts the operation of the new offload pattern.

[0120] Figure 5 is a detailed flowchart of the commercial request data history analysis process, which is the subroutine for step S71 in Figure 4. When called by the subroutine call in step S71 of Figure 4, in step S81 the request processing load analysis unit 120 calculates the actual processing time and the total number of uses from the usage history of each application over a certain period (long time; for example, one month). However, for applications that are FPGA offloaded, the processing time as if they were not offloaded is calculated provisionally. An improvement coefficient is obtained from the test history of assumed usage data before the start of operation by (actual processing time when only CPU processing is performed) / (actual processing time when FPGA offloading is performed). The request processing load analysis unit 120 uses the sum of the values ​​obtained by multiplying the actual processing time by the improvement coefficient as the total processing time to be used for comparison.

[0121] In step S82, the request processing load analysis unit 120 compares the total actual processing time across all applications.

[0122] In step S83, the request processing load analysis unit 120 sorts the requests by total processing time and identifies the top-performing applications in terms of processing time load.

[0123] In step S84, the request processing load analysis unit 120 acquires request data for a certain period (short period: 12 hours, etc.) of the top-loading applications, sorts the data into groups of a certain size, creates a frequency distribution, and returns to step S71 in Figure 4.

[0124] Figure 6 is a detailed flowchart of the commercial representative data extraction process, which is the subroutine for step S73 in Figure 4. When called by the subroutine call in step S73 of Figure 4, in step S91 the improvement calculation unit 122 selects a predetermined number (in this case, four) of for statements with high arithmetic intensity from the top-loading applications.

[0125] In step S92, the improvement calculation unit 122 creates 4OpenCL that offloads four for statements, precompiles them, calculates resource usage, and selects the three for statements with the highest arithmetic strength / resource usage. As a result, 3OpenCL that offloads three for statements is selected.

[0126] In step S93, the improvement calculation unit 122 measures the performance of 3OpenCL using representative data. For example, the improvement calculation unit 122 creates an OpenCL by combining the two highest-performing for statements and measures its performance in the same way.

[0127] In step S94, the improvement calculation unit 122 returns to step S72 in Figure 4, with the off-road pattern with the highest speed in 4 measurements as the solution.

[0128] [Implementation and Usage Tools] An implementation for verifying the effectiveness of this embodiment will be described. To verify the effectiveness of FPGA reconfiguration, the target application will be a C / C++ language application, and the FPGA used will be an Intel PAC D5005 ("Intel" is a registered trademark) (Intel Stratix 10 GX FPGA). The machine used for compilation will be a DELL EMC PowerEdge R740 ("DELL" is a registered trademark) (CPU: Intel Xeon Bronze 3206R x 2, RAM: 32GB RDIMM x 4).

[0129] FPGA processing uses Intel Acceleration Stack Version 2.0 ("Intel" is a registered trademark) (Intel FPGA SDK for OpenCL, Intel Quartus Prime). The Intel Acceleration Stack enables high-level synthesis (HLS) by having two software components work together to interpret not only standard OpenCL but also Intel-specific pragmas, etc. Furthermore, the Intel Acceleration Stack interprets OpenCL code that describes the kernel program processed by the FPGA and the host program processed by the CPU. In addition, the Intel Acceleration Stack outputs information such as resource usage, performs FPGA wiring, and enables FPGA operation.

[0130] For parsing C / C++ languages, the LLVM / Clang 6.0 parsing library (python binding of libClang®) is used.

[0131] FPGA offloading uses arithmetic strength and loop count to refine the for loop. For example, the ROSE compiler framework 0.9 is used for arithmetic strength analysis, and the gcov profiler is used for loop count analysis.

[0132] [Implementation Notes] I will provide further details about the implementation. For implementation, before going live, FPGA offloading is performed using the same operation as the pre-launch implementation tool. For reconfiguration during operation (which is a form of "after operation has started"), the system is implemented to sequentially execute the processing steps in the flowcharts showing reconfiguration after operation has started, as shown in Figures 4 to 6.

[0133] The following explains the details decided upon during implementation, supplementing the flowcharts in Figures 4 through 6. First, in the load analysis step S71 in Figure 4, request data over a certain period (long term) is analyzed to identify the top-performing applications, and then actual request data for those applications over a certain period (short term) is obtained.

[0134] Here, the number of top-loading applications and the time period are left to the operator's discretion, providing flexibility. However, the above-mentioned long period assumes a span of one month or more. Conversely, the above-mentioned short period assumes a short span such as 12 hours. In the request data analysis, the actual processing time and number of uses of applications are totaled, which is obtained using the Linux™ time command. The time command logs the actual elapsed time of each application, so the value can be calculated by combining the number of logs and the total time.

[0135] In step S72 of Figure 4, representative data selection (before operation begins), actual request data from the top-performing applications over a certain period (short term) is sorted into fixed-size groups to create a frequency distribution. At this time, the number of classes in the frequency distribution is determined by Sturges' rule. Sturges' rule states that when the number of times an application is used is n (where n is any natural number), it is appropriate to set the number of classes to 1 + log2n. To use Sturges' rule, it is necessary to determine the number of classes, select the most frequent class, and then select one representative data from the most frequent class. When selecting representative data, the data with the data size closest to the median value of the class is selected as the representative data.

[0136] In step S72 of Figure 4, representative data selection (after operation commencement), FPGA offloading is performed on the top-loading applications using the selected representative data, in the same processing as before operation commencement. The difference from before operation commencement is that the test cases used for performance measurement use commercially available representative data instead of expected usage data.

[0137] In step S73 of Figure 4, the improvement calculation requires examining the improvement effect when the commercial environment is reconfigured with the new off-road pattern. Since this is before the user proposal for reconfiguration, verification must be performed on the verification environment server. The improvement calculation unit 122 measures the improvement per processing run using representative commercial data and calculates the overall improvement using the commercial usage frequency. The improvement calculation unit 122 then compares the extent of the effect when the commercial environment is reconfigured.

[0138] In step S74 of Figure 4, the reconstruction proposal unit 123 does not propose a reconstruction to the user if the calculation result of equation (2) / calculation result of equation (1) is less than a predetermined threshold. Since frequent reconstruction proposals would be inconvenient for the user, the threshold for effect improvement is set to a value sufficiently greater than 1, thereby suppressing the frequent occurrence of reconstruction proposals and leaving only cases of truly effective reconstruction. The reconstruction threshold is a variable-setting implementation; for example, it can be set to 1.5.

[0139] In step S75 of Figure 4, the reconfiguration proposal unit 123 proposes reconfiguration to the user, providing information on price changes or improvement effects. The information on price changes or improvement effects includes the price change resulting from the reconfiguration, or how many times the improvement effect was in the verification environment even without a price change. This allows the contract user to decide whether it is better to reconfigure.

[0140] In step S76 of Figure 4, the control unit 11 performs the reconfiguration using the static reconfiguration function of OpenCL. The static reconfiguration function is implemented in a way that causes a downtime of about 1 second. If it is desired to reduce the downtime to the order of milliseconds, a dynamic reconfiguration function, such as the dynamic partial reconfiguration function of Intel FPGA®, may be used. The above explains the automatic offload operation (after the start of operation).

[0141] Next, we will explain FPGA offloading techniques for loop statements in application software. Figure 7 is a flowchart illustrating the operation overview of Offload Server 1. In step S101, the application code analysis unit 112 analyzes the source code that the application wants to offload. The application code analysis unit 112 analyzes loop statements and variable information according to the language of the source code.

[0142] In step S102, the PLD processing specification unit 113 identifies the loop statements and reference relationships of the application.

[0143] Next, the PLD processing pattern creation unit 115 narrows down the candidates for which FPGA offloading should be attempted for the identified loop statements. Arithmetic strength is one indicator of whether or not offloading is effective for a loop statement. In step S103, the arithmetic intensity calculation unit 114 calculates the arithmetic intensity of the application's loop statement using an arithmetic intensity analysis tool. Arithmetic intensity is an indicator that increases with a large number of calculations and decreases with a large number of accesses; processes with high arithmetic intensity are heavy processes for the processor.

[0144] Therefore, an arithmetic intensity analysis tool is used to analyze the arithmetic intensity of loop statements, and loop statements with high density are narrowed down as offload candidates. The ROSE framework is used for arithmetic intensity analysis. Loops with a large number of iterations also result in heavy processing. The number of iterations is analyzed using a profiler, and loop statements with a large number of iterations are also narrowed down as offload candidates. gcov is used for loop count analysis.

[0145] Even highly arithmetic-intensive loop statements can be problematic if they consume excessive FPGA resources when processed on an FPGA. Therefore, this paper describes how to calculate the resource requirements when processing highly arithmetic-intensive loop statements on an FPGA. The process of compiling to an FPGA involves converting from a high-level language such as OpenCL to a hardware description language such as HDL (Hardware Description Language), and then performing actual routing and other processing based on this. While routing and other processing take a considerable amount of time, reaching the intermediate stage of HDL only takes a few minutes. Even at the intermediate stage of HDL, it is possible to determine the resources used by the FPGA, such as flip-flops and look-up tables. Therefore, by looking at the intermediate stage of HDL, the FPGA resources to be used can be determined at the HDL level, and the amount of resources used can be determined in a short time (the amount of resources used can be determined in a short time even before compilation is complete).

[0146] Therefore, in this embodiment, the PLD processing pattern creation unit 115 first calculates the resource amount by converting the target loop statement into a high-level language such as OpenCL. Also, since the arithmetic intensity and resource amount when the loop statement is offloaded are determined, the resource efficiency is defined as arithmetic intensity / resource amount or arithmetic intensity × loop count / resource amount. Then, loop statements with high resource efficiency are further narrowed down as offload candidates. Here, when converting loop statements to OpenCL language, the CPU processing program is divided into kernel (FPGA) and host (CPU) according to OpenCL syntax.

[0147] Next, several highly resource-efficient loop statements are narrowed down, and patterns are created using these to measure performance (described later). A certain number of patterns of the narrowed-down single loop statements and their combinations are created and compiled to run on the FPGA. Finally, the performance of the compiled multiple patterns is measured in the verification environment, and the fastest pattern is selected as the solution.

[0148] Returning to the flow in Figure 4, in step S104, the PLD processing pattern creation unit 115 measures the number of loops in the application's loop statement using profiling tools such as gcov and gprof.

[0149] In step S105, the PLD processing pattern creation unit 115 narrows down the loop statements to those with high arithmetic strength and a high number of loop iterations.

[0150] In step S106, the PLD processing pattern creation unit 115 creates OpenCL to offload each of the narrowed-down loop statements to the FPGA.

[0151] Here, we will provide some supplementary explanation regarding the OpenCLization of loop statements (creation of OpenCL). In other words, when converting loop statements to a higher-level language such as OpenCL, two processes are necessary. First, the CPU processing program is divided into a kernel (FPGA) and a host (CPU) according to the syntax of a higher-level language such as OpenCL. Second, techniques for speeding up the process are incorporated during this division. Generally, techniques for speeding up using FPGAs include local memory caching, stream processing, multiple instantiation, loop statement unpacking, nested loop statement merging, and memory interleaving. While these do not always have an absolute effect depending on the loop statement, they are commonly used as methods for speeding up the process.

[0152] Next, several resource-efficient loop statements have been selected, and the required number of offload patterns are created using these to measure their performance. FPGA acceleration can be achieved by concentrating FPGA resources on a single process, or by distributing FPGA resources across multiple processes. A certain number of selected single-loop statement patterns are created and precompiled as a preliminary step before they run on the actual FPGA.

[0153] In step S107, the PLD processing pattern creation unit 115 precompiles the created OpenCL and calculates the amount of resources to be used ("First resource amount calculation").

[0154] In step S108, the PLD processing pattern creation unit 115 narrows down the loop statements to those with high resource efficiency.

[0155] In step S109, the executable file creation unit 117 compiles OpenCL to offload the narrowed-down loop statements.

[0156] In step S110, the performance measurement unit 116 measures the performance of the compiled program using user usage data (data actually used by the user; commercial representative data) ("first performance measurement").

[0157] In step S111, the PLD processing pattern creation unit 115 lists the loop statements that have been measured for performance and have shown improved performance compared to the CPU.

[0158] In step S112, the PLD processing pattern creation unit 115 creates OpenCL that combines loop statements from a list to perform offloading. In step S113, the PLD processing pattern creation unit 115 calculates the amount of resources to be used by precompiling with OpenCL for the combined offload ("Second resource amount calculation"). Alternatively, the sum of the resource amounts from precompilation before the first measurement may be used instead of precompilation. This reduces the number of precompilation steps.

[0159] In step S114, the executable file creation unit 117 compiles the combined OpenCL for offloading.

[0160] In step S115, the performance measurement unit 116 measures the performance of the compiled program using user usage data (data actually used by the user; commercial representative data) ("second performance measurement").

[0161] In step S116, the production environment deployment unit 118 selects the pattern with the best performance from the first and second measurements and terminates the processing of this flow.

[0162] Thus, FPGA automatic loop offloading focuses on loop statements with high arithmetic strength and loop count, and high resource efficiency, creating offload patterns (see Figure 8), and then performing high-speed pattern search through actual measurements in a verification environment. In the case of GPUs, the GA was used to test combinations for most loop statements, and the optimal pattern was searched for after performing measurements on a scale of 1000 times. In FPGAs, compilation takes more than 6 hours, so the number of performance measurements is limited for the search.

[0163] [Example of creating an off-road pattern] Figure 8 shows the search image of the PLD processing pattern creation unit 115. The control unit (automatic offload function unit) 11 (see Figure 2) analyzes the application code 130 (see Figure 3) used by the user and checks whether for statements can be parallelized from the code patterns 141 of the application code 130, as shown in Figure 8. As indicated by the symbol a in Figure 8, if four for statements are found from the code patterns 141, one digit is assigned to each for statement, in this case four digits of 1 or 0 for 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., if processing is performed by the CPU).

[0164] [The process from C code to finding the final OpenCL solution] The procedure AF in Figure 9 illustrates the flow from the C code to the search for the final OpenCL solution. The application code analysis unit 112 (see Figure 2) syntactically analyzes the "C code" shown in step A of Figure 9 (see symbol b in Figure 9), and the PLD processing specification unit 113 (see Figure 2) identifies the "loop statement and variable information" shown in step B of Figure 9 (see Figure 8).

[0165] The arithmetic intensity calculation unit 114 (see FIG. 2) performs arithmetic intensity analysis (Arithmetic Intensity analysis) on the specified "loop statement, variable information" using an arithmetic intensity analysis tool. The PLD processing pattern creation unit 115 narrows down the loop statements with high arithmetic intensity as offload candidates. Further, the PLD processing pattern creation unit 115 performs profiling analysis (see reference symbol c in FIG. 9) using a profiling tool to further narrow down the loop statements with high arithmetic intensity and high loop counts. Then, the PLD processing pattern creation unit 115 creates (OpenCLizes) OpenCL for offloading each narrowed-down loop statement to the FPGA. Furthermore, at the time of OpenCLization, speed-up techniques such as unfolding are introduced together with code splitting (described later).

[0166] <Specific Example of "High Arithmetic Intensity, OpenCLization" (Part 1): Procedure C> For example, when five for loops (assignment of 4-digit 1 or 0) are found from the code pattern 141 (see FIG. 5) of the application code 130, four are narrowed down (selected) by arithmetic intensity analysis. That is, as shown by reference symbol d in FIG. 9, the offload patterns "10000", "01000", "00010", and "00001" of four for loops are narrowed down from the five for loops.

[0167] <Example of "Unfolding" Executed Together with Code Splitting at the Time of OpenCLization> In the case of data transfer from the FPGA to the CPU, for the loop statement [k = 0; k < 10; k++] described on the CPU program side { } At the upper part of this loop statement, \pragma unroll is instructed. That is, \pragma unroll for(k = 0; k < 10; k++){ } It is described as such.

[0168] If you instruct the unroll command using syntax compatible with Intel or Xilinx® tools such as \pragma unroll, in the above example, it can be pipelined by unrolling i=0, i=1, i=2. This will use 10 times more resources, but can result in faster execution. Additionally, the number of items to unroll can be specified as 5, rather than the total number of loop iterations. In this case, each 2-loop iteration will be unrolled into 5 items. This concludes the explanation of the "development" example.

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

[0170] In Figure 9, at code e, the PLD processing pattern creation unit 115 compiles OpenCL to offload the narrowed-down loop statement.

[0171] <Specific example of "high arithmetic strength, OpenCL implementation" (Part 2)> As shown by the symbol e in Figure 9, from the four offload patterns "10000", "01000", "00010", and "00001" narrowed down by arithmetic intensity analysis, the resource efficiency analysis described above narrows it down to three offload patterns "10000", "00010", and "00001". The above explains the "high arithmetic intensity, OpenCL conversion" procedure shown in step C of Figure 6.

[0172] For the "resource-efficient loop statement" shown in step D of Figure 9, the performance measurement unit 116 measures the performance of the compiled program ("first performance measurement"). The PLD processing pattern creation unit 115 then lists the loop statements that have shown improved performance compared to the CPU, based on the performance measurements. Similarly, resource usage is calculated, offload OpenCL compilation is performed, and the performance of the compiled program is measured.

[0173] <Specific Examples of "High Arithmetic Strength, OpenCL Implementation" (Part 3)> As shown by the symbol f in Figure 9, the first measurement is performed for three off-road patterns "10000", "00010", and "00001". If the performance of "10000" and "00010" is higher in the first measurement, a second measurement is performed for the combination of "10000" and "00010".

[0174] In Figure 9, at symbol g, the executable file creation unit 117 compiles OpenCL (main compilation) to offload the narrowed-down loop statement.

[0175] The "measurement of combination patterns" shown in step E of Figure 9 refers to measuring verification patterns for candidate loop statements individually, and then for their combinations.

[0176] <Specific Examples of "High Arithmetic Strength, OpenCL Implementation" (Part 4)> As shown by the symbol h in Figure 9, a second measurement is performed on "10010," which is the combination of "10000" and "00010." After two measurements, "00010," which had the highest speed among the first and second measurements, was selected (see the symbol i in Figure 9). In such cases, "00010" becomes the final solution. However, there are cases where a combination pattern cannot be measured due to resource limitations. In this case, it is acceptable to skip the combination and simply select the one with the highest speed from the individual results.

[0177] Based on the above, "00010" (see symbol j in Figure 9) is selected as the "OpenCL final solution" shown in step F of Figure 9.

[0178] <Deployment> The final OpenCL solution, using the highest-performing PLD processing pattern, will be redeployed to the production environment and provided to users.

[0179] [Implementation Example] Let's explain an implementation example. FPGAs such as the Intel PAC with Intel Arria10 GX FPGA can be used. FPGA processing can utilize tools such as the Intel Acceleration Stack (Intel FPGA SDK for OpenCL, Quartus Prime Version). The Intel FPGA SDK for OpenCL is a high-level synthesis tool (HLS) that interprets not only standard OpenCL but also Intel-specific #pragma and other syntax. In the implementation example, the system interprets OpenCL code containing a kernel to be processed by the FPGA and a host program to be processed by the CPU, outputs information such as resource usage, performs FPGA wiring, and makes the system operable on the FPGA. Even a small program of about 100 lines takes about 3 hours to run on an actual FPGA. However, if the resource usage exceeds the limit, an error will occur sooner. Also, if the OpenCL code cannot be processed by the FPGA, an error will be output after several hours.

[0180] In the implementation example, upon receiving a request to use a C / C++ application, the system first analyzes the application's code to identify for loops and understand the program structure, including the variables and data used within those loops. For syntax analysis, LLVM / Clang parsing libraries can be used.

[0181] In the implementation example, to estimate the FPGA offload effect of each loop statement, an arithmetic strength analysis tool is executed to obtain an arithmetic strength index determined by the number of calculations, accesses, etc. The ROSE framework or similar tools can be used for arithmetic strength analysis. Only the loop statements with the highest arithmetic strength should be targeted. Next, we use a profiling tool such as gcov to obtain the number of loop iterations for each loop. We then narrow down the candidates to the loop statements with the highest 'a' values ​​based on arithmetic strength × number of loop iterations.

[0182] In the implementation example, OpenCL code is then generated to offload to the FPGA for each high-arithmetic-intensity loop statement. The OpenCL code is divided so that the relevant loop statement becomes the FPGA kernel, and the rest becomes the CPU host program. When creating the FPGA kernel code, a certain number b of loop statements may be unpacked as a technique to speed up the process. Loop statement unpacking increases the amount of resources used, but it is effective in speeding up the process. Therefore, the number of unpacked statements is limited to a certain number b to prevent the amount of resources used from becoming enormous.

[0183] In the implementation example, the following steps involve precompiling 'a' OpenCL code snippets using the Intel FPGA SDK for OpenCL to calculate the amount of resources used, such as Flip Flop and Look Up Table. The amount of resources used is displayed as a percentage of the total resources. Here, the resource efficiency of each loop statement is calculated based on the arithmetic intensity and resource amount, or the arithmetic intensity, loop count, and resource amount. For example, a loop statement with an arithmetic intensity of 10 and a 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 a resource amount of 0.3 has a resource efficiency of 3 / 0.3=10, with the former being more efficient. Alternatively, the resource efficiency can be calculated by multiplying the loop count by the value of the loop statement. For each loop statement, the 'c' statements with the highest resource efficiency are selected.

[0184] In the implementation example, the next step is to create patterns to be measured, using c loop statements as candidates. For example, if the first and third loops are resource-efficient, then OpenCL patterns are created to offload loop 1 and loop 3, and their performance is measured. If speedup is achieved by offloading multiple single loop statements (for example, if both loops 1 and 3 are speedup), then an OpenCL pattern is created using that combination, and its performance is measured (for example, a pattern that offloads both loops 1 and 3).

[0185] When creating combinations of single loops, the amount of resources used also becomes part of the combination. Therefore, if it does not fall within the upper limit, that combination pattern will not be created. Once d patterns, including combinations, have been created, performance measurements will be performed on a server equipped with an FPGA in the verification environment. For performance measurement, the sample processing specified by the application to be accelerated will be performed. For example, in the case of a Fourier transform application, the transformation processing on sample data will be used as a benchmark for performance measurement. In the implementation example, the fastest pattern among multiple measurement patterns is selected as the solution at the end.

[0186] [Hardware configuration] The offload server 1 according to this embodiment is implemented by a computer 900 with a configuration such as that shown in Figure 10. The verification machine 14 shown in Figure 2 is located outside the offload server 1. Figure 10 is a hardware configuration diagram showing an example of a computer 900 that implements the functions of offload server 1. Computer 900 has a CPU 910, RAM 920, ROM 930, HDD 940, communication interface (I / F: Interface) 950, input / output interface (I / F) 960, and media interface (I / F) 970.

[0187] The CPU 910 operates based on programs stored in the ROM 930 or HDD 940, controlling various components. The ROM 930 stores boot programs executed by the CPU 910 when the computer 900 starts up, as well as programs that depend on the computer 900's hardware.

[0188] The HDD940 stores programs executed by the CPU910, as well as data used by such programs. The communication interface950 receives data from other devices via the communication network80 and sends it to the CPU910, and transmits data generated by the CPU910 to other devices via the communication network80.

[0189] The CPU 910 controls output devices such as displays and printers, and input devices such as keyboards and mice, via the input / output interface 960. The CPU 910 acquires data from input devices via the input / output interface 960. The CPU 910 also outputs the generated data to output devices via the input / output interface 960.

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

[0191] For example, when computer 900 functions as an offload server 1 according to this embodiment, the CPU 910 of computer 900 implements the functions of each part of the offload server 1 by executing programs loaded onto RAM 920. The HDD 940 stores data from each part of the offload server 1. The CPU 910 of computer 900 reads and executes these programs from the recording medium 980, but as another example, these programs may be obtained from other devices via the communication network 80.

[0192] [effect] As described above, the offload server 1 according to this embodiment includes: an application code analysis unit 112 that analyzes the source code of the application; a PLD processing specification unit 113 that identifies loop statements in the application and creates and compiles multiple offload processing patterns that specify pipeline processing and parallel processing in PLD using OpenCL for each identified loop statement; an arithmetic strength calculation unit 114 that calculates the arithmetic strength of the loop statements in the application; a PLD processing pattern creation unit 115 that, based on the arithmetic strength calculated by the arithmetic strength calculation unit 114, narrows down loop statements with an arithmetic strength higher than a predetermined threshold as offload candidates and creates a PLD processing pattern; a performance measurement unit 116 that compiles the application of the created PLD processing pattern, places it in the accelerator verification device 14, and executes performance measurement processing when offloaded to PLD; an executable file creation unit 117 that, based on the performance measurement results from the performance measurement processing, selects the PLD processing pattern with the highest processing performance from the multiple PLD processing patterns, compiles the PLD processing pattern with the highest processing performance, and creates an executable file; and the actual user A request processing load analysis unit 120 analyzes the request processing load of the data being used; a representative data selection unit 121 identifies the applications with the highest processing loads analyzed by the request processing load analysis unit 120 and selects representative data from the request data used when those applications are in use; a new offload pattern (a new offload pattern found in the verification environment) is determined based on the representative data selected by the representative data selection unit 121 by executing the application code analysis unit 112, the PLD processing specification unit 113, the arithmetic strength calculation unit 114, the PLD processing pattern creation unit 115, the performance measurement unit 116, and the executable file creation unit 117; an improvement degree calculation unit 122 calculates the performance improvement effect by comparing the processing time and usage frequency of the determined new offload pattern with the processing time and usage frequency of the current offload pattern; and an improvement degree calculation unit 122 calculates the performance improvement effect by comparing the processing time and usage frequency of the new offload pattern (a new offload pattern found in the verification environment) with the processing time and usage frequency of the current offload pattern based on the representative data selected by the representative data selection unit 121.The system includes a reconstruction proposal unit 123 that proposes PLD reconstruction when the performance improvement effect exceeds a predetermined threshold.

[0193] By doing so, the offload server 1 can be reconfigured to a more appropriate logic not only before operation begins, but also according to usage characteristics after operation begins, thereby improving the efficiency of resource utilization in a PLD (e.g., FPGA) with limited resources. In detail, the offload server 1 can reconfigure the FPGA logic in response to changes in usage characteristics after the application has started operation. Therefore, if the data used after the start of operation may deviate significantly from the actual data used, for example, if the usage pattern after the start of operation differs from the initial assumption and performance can be improved by offloading a different logic to the FPGA, the FPGA logic can be reconfigured with minimal impact on the user. Furthermore, reconfiguration may involve changing the offloading of different loop statements within the same application, or it may involve changing the offloading of a different application altogether. The targets of reconfiguration are numerous, including GPUs, FPGA offload logic, resource usage, and location.

[0194] In the offload server 1 according to this embodiment, the request processing load analysis unit 120 is characterized by calculating the actual processing time and the total number of uses from the usage history of each application over a predetermined period.

[0195] By doing so, the offload server 1 can analyze the request processing load of data actually used by users from the usage history of each application over a certain period of time.

[0196] In the offload server 1 according to this embodiment, the request processing load analysis unit 120 calculates an improvement coefficient from the test history of assumed usage data before the start of operation by (actual processing time when only CPU processing is performed) / (actual processing time when PLD offloading is performed), and the sum of the values ​​obtained by multiplying the actual processing time by the improvement coefficient is used as the total processing time for comparison.

[0197] By doing this, when Offload Server 1 selects a top-loading application, it can calculate the processing time if the application were not offloaded by multiplying it by an improvement coefficient, thereby correcting the comparison to only CPU processing. Since the processing time for the non-offloaded case is corrected by multiplying it by the improvement coefficient, a more accurate actual processing time can be calculated.

[0198] In the offload server 1 according to this embodiment, the request processing load analysis unit 120 acquires request data for a predetermined period from the top-loading applications, sorts the data into fixed-size groups to create a frequency distribution, and the representative data selection unit 130 selects one data from the actual request data corresponding to the mode of the frequency distribution and selects it as representative data.

[0199] By doing this, when offload server 1 selects representative data, even if the average data size may differ significantly from the actual data used, it can select more appropriate representative data by using the mode of the data size.

[0200] In the offload server 1 according to this embodiment, the improvement calculation unit 122 measures the processing time of the current offload pattern and a plurality of new offload patterns, and calculates the performance improvement effect based on the frequency of commercial use according to (actual processing reduction time in the verification environment) × (frequency of use in the commercial environment).

[0201] By doing this, Offload Server 1 can calculate (reduced processing time in the verification environment) and (frequency of use in the commercial environment) for multiple new offload patterns, and then calculate (reduced processing time in the verification environment) and (frequency of use in the commercial environment) for the current offload pattern. By dividing the former by the latter, it can determine a more accurate performance improvement effect using the two parameters of processing time and frequency of use.

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

[0203] In this way, each of the functions of the offload server 1 described above can be implemented using a general-purpose computer.

[0204] 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 by known methods. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings can be arbitrarily changed unless otherwise specified. Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0205] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. Alternatively, each of the above configurations and functions may be implemented in software that allows the processor to interpret and execute programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in 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, an SD (Secure Digital) card, or an optical disc.

[0206] Furthermore, in this embodiment, any FPGA that can offload FPGA processing is acceptable.

[0207] Furthermore, while the `for` statement is used as an example of a loop statement in this embodiment, other statements such as `while` and `do-while` are also included. However, the `for` statement, which specifies the loop continuation conditions, is more suitable. [Explanation of Symbols]

[0208] 1 Offload Server 11 Control Unit 12 Input / output section 13 Storage section 14. Verification Machine (Accelerator Verification Device) 15 OpenIoT Resources 111 Application Code Specification Section 112 Application Code Analysis Department 113 PLD Processing Specification Section 113a Off-road range extraction unit 113b Intermediate language file output section 114 Arithmetic strength calculation section 115 PLD Processing Pattern Creation Unit 116 Performance measurement section 116a Binary file placement section 117 Executable file creation section 118 Production Environment Deployment Section 119 Performance Measurement Test Extraction and Execution Unit 120 Request Processing Load Analysis Department (Processing Load Analysis Department) 121 Representative Data Selection Department 122 Improvement level calculation section 123 Reconstruction Proposal Department 124 User Support Department 130 Application Code 131 Code Pattern Database 132 Equipment Resource Database 133 Test Case Database 134 Intermediate language files 151 Various Devices A device with 152 CPUs and GPUs 153 Devices with CPU-FPGA A device with 154 CPUs

Claims

1. An offload server that offloads specific processing of an application to a PLD (Programmable Logic Device), The application code analysis unit analyzes the source code of the application, A PLD processing specification unit identifies loop statements in the aforementioned application, and for each identified loop statement, creates and compiles pipeline processing and parallel processing in the PLD using multiple offload processing patterns specified in OpenCL, An arithmetic strength calculation unit calculates the arithmetic strength of the loop statement of the aforementioned application, Based on the arithmetic intensity calculated by the arithmetic intensity calculation unit, a PLD processing pattern creation unit narrows down loop statements whose arithmetic intensity is higher than a predetermined threshold as offload candidates and creates a PLD processing pattern. A performance measurement unit compiles the application of the created PLD processing pattern, places it in an accelerator verification device, and executes performance measurement processing when it is offloaded to the PLD. An executable file creation unit selects the PLD processing pattern with the highest processing performance from a plurality of PLD processing patterns based on the performance measurement results obtained by the aforementioned performance measurement process, compiles the PLD processing pattern with the highest processing performance, and creates an executable file. A processing load analysis unit analyzes the processing load of data requests actually used by users, The processing load analysis unit identifies applications with high request processing loads, and the representative data selection unit selects representative data from the request data used when those applications are in use. Based on the representative data selected by the representative data selection unit, a new offload pattern is determined by executing the application code analysis unit, the PLD processing specification unit, the arithmetic intensity calculation unit, the PLD processing pattern creation unit, the performance measurement unit, and the executable file creation unit, and an improvement degree calculation unit calculates the performance improvement effect by comparing the processing time and usage frequency of the determined new offload pattern with the processing time and usage frequency of the current offload pattern. The system includes a reconstruction proposal unit that proposes PLD reconstruction when the performance improvement effect is equal to or greater than a predetermined threshold, The aforementioned processing load analysis unit, The system retrieves request data from the top-loaded applications over a specified period, sorts the data into fixed size groups, and creates a frequency distribution. The aforementioned representative data selection unit, From the actual request data corresponding to the mode of the frequency distribution, one data point is selected and designated as the representative data point. An offload server characterized by the following features.

2. The aforementioned processing load analysis unit, The total processing time and number of uses are calculated from the usage history of each application over a specified period. The offload server according to feature 1.

3. The aforementioned processing load analysis unit, Based on test history using pre-operational usage data, an improvement coefficient is calculated by (actual processing time with CPU processing only) / (actual processing time with PLD offloading), and the sum of the values ​​obtained by multiplying the actual processing time by the improvement coefficient is used for comparison. The offload server according to feature 1.

4. The aforementioned improvement degree calculation unit, The processing times for the current off-road pattern and multiple new off-road patterns are measured, and the performance improvement effect based on the frequency of commercial use is calculated according to (actual processing reduction time in the verification environment) × (frequency of use in the commercial environment). The offload server according to feature 1.

5. An offload control method for an offload server that offloads specific processing of an application to a PLD (Programmable Logic Device), The aforementioned offload server is Application code analysis steps involve analyzing the source code of an application, A PLD processing specification step involves identifying loop statements in the aforementioned application, and for each identified loop statement, creating and compiling pipeline processing, parallel processing, and expansion processing in the PLD using multiple offload processing patterns specified in OpenCL, and The arithmetic strength calculation step of the loop statement of the aforementioned application, Based on the calculated arithmetic intensity, a PLD processing pattern creation step is performed to narrow down loop statements whose arithmetic intensity is higher than a predetermined threshold as offload candidates and create a PLD processing pattern. A performance measurement step involves compiling the application of the created PLD processing pattern, placing it in an accelerator verification device, and executing performance measurement processing when the processing is offloaded to the PLD. Based on the performance measurement results obtained from the performance measurement process, the PLD processing pattern with the highest processing performance is selected from a plurality of PLD processing patterns, and the PLD processing pattern with the highest processing performance is compiled to create an executable file; The process involves analyzing the request processing load of data actually used by users, obtaining request data from the top-performing applications for a specified period, and creating a frequency distribution by sorting the data into fixed size groups. The process involves identifying the applications with the highest request processing loads after analysis, and selecting representative data from the request data used by those applications, by selecting one data point from the actual request data corresponding to the mode of the frequency distribution, and selecting it as the representative data point. Based on the selected representative data, a new off-road pattern is determined by executing the application code analysis step, the PLD processing specification step, the arithmetic intensity calculation step, the PLD processing pattern creation step, the performance measurement step, and the executable file creation step; the processing time and usage frequency of the determined new off-road pattern are compared with the processing time and usage frequency of the current off-road pattern to calculate the performance improvement effect; If the performance improvement effect is greater than or equal to a predetermined threshold, the step of proposing PLD reconstruction is performed. An off-road control method characterized by the following:

6. An offload program for causing a computer to function as an offload server according to any one of claims 1 to 4.

Images