JP7324027B2 - Profiling method - Google Patents

Description

The present invention relates to a method for profiling (performance analysis) of accelerators in multi-core environments.

Profiling is widely used as a means of performing performance analysis and optimization of programs executed on computers (eg, Patent Document 1). Profiling is effective in analyzing the running frequency of program code, time distribution, calling relationship frequency inside the program, and the like. For example, by profiling, the usage status of resources during program execution (hereinafter referred to as "profile information") is acquired. Based on the profile information, it is possible to grasp the code range in which the execution period is long in the program, the execution status of the program at the time of a predetermined event, and the like.

JP 2011-118596 A

However, the conventional profiling method as described above is intended for a system that operates on an operating system (OS) on an information processing device. In contrast, an object of the present disclosure is to provide a method of profiling in a multi-core environment in which some tasks are executed by an OS-unmanaged accelerator.

The present disclosure employs the following technical means to solve the above problems. The symbols in parentheses described in the claims and this section are an example showing the correspondence relationship with the specific means described in the embodiment described later as one aspect, and limit the technical scope of the present invention. not something to do.

The profiling method according to the present disclosure comprises a step of exporting from a computer in a development environment an execution program for an accelerator compiled by the computer (S10); is an environment different from the compilation environment), and storing conversion information between the environments in a runtime library that absorbs the difference between the development environment and the execution environment (S11); a step (S12) of causing an application executed on the host CPU to execute processing of an execution program on the accelerator via the runtime library; It comprises a step (S13) of acquiring a state (status) and a step (S14) of said application writing at least part of said status to a log file.

According to the present disclosure, by storing conversion information between environments in the runtime library, accelerator profiling of the execution environment executed via the runtime library can be performed.

It is a figure which shows the profile method of this Embodiment. 1 is a diagram illustrating an example of a configuration of an SoC in an execution environment; FIG. FIG. 10 is a diagram showing a sequence for acquiring profiling information in the SoC of the execution environment;

Hereinafter, this embodiment will be described with reference to the accompanying drawings. In order to facilitate understanding of the description, the same constituent elements in each drawing are denoted by the same reference numerals as much as possible, and overlapping descriptions are omitted.

FIG. 1 is a diagram showing the procedure of the profiling method of this embodiment. The profiling method of this embodiment is a method of profiling the execution status in the execution environment when the development environment and the execution environment are different. The execution environment assumed in the profiling method of the present embodiment is an SoC (System on Chip) 1 equipped with a multi-core environment accelerator (denoted as "ACC" in FIG. 1).

FIG. 2 is a diagram showing an example of the configuration of SoC 1 of the execution environment. SoC 1 includes host CPU 21 , accelerator 10 , event handler 20 , ROM 22 , RAM 23 and external interface 24 . The host CPU 21, the accelerator 10, the ROM 22, the RAM 23, and the external interface 24 are connected to a system bus 25 and can exchange information with each other through the system bus 25. FIG.

The host CPU 21 performs data processing and supports the OS of SoC1. The ROM 22 is a read-only memory. The RAM 23 is a read/write memory. The external interface 24 is, for example, an interface for communicating with external devices such as a camera and an ultrasonic sensor.

The accelerator 10 has a role as an individual master that handles the computational load of the host CPU 21 of SoC 1 . The accelerator 10 can independently fetch instructions. The accelerator 10 is also connected to an event handler 20 that generates interrupt processing, and supports interrupts generated by the event handler 20 .

Returning to FIG. 1, the description continues. The development environment computer (PC), like the execution environment, has a CPU and an accelerator. The accelerator of the PC in the development environment (denoted as "ACC" in FIG. 1) is the same accelerator as the SoC 1 in the execution environment. In the development environment, the execution program for the accelerator used in the execution environment is developed. An execution program of an accelerator developed in the development environment is imported into SoC1 of the execution environment, and processing is executed on the accelerator. The CPU and the application executed by the CPU are different between the computer in the development environment and the SoC 1 in the execution environment.

In the development environment, the compiler for the computer and the compiler for the accelerator are implemented in an integrated form. On the other hand, the execution environment SoC 1 is composed of a main processing part for executing applications and a runtime library for controlling the accelerator 10 . Note that the run-time library is a library that always exists and is used simultaneously with the application when the computer program is executed. In this embodiment, a runtime library is a software module that connects an application and an execution program.

In the execution environment, the runtime library bridges the difference between the development environment and the execution environment. Since the CPU and application in the execution environment are different from the CPU and application in the development environment, there is a problem that profiling information that can be interpreted by the application cannot be acquired.

In the profiling method of the present embodiment, in order to solve this problem, the runtime library stores information for converting the difference between the development environment and the execution environment, and the application is executed via the runtime library. Acquire the state (status) of the accelerator 10 inside. Specifically, when the information of the accelerator 10 acquired by the application becomes information that cannot be interpreted by the application, it is converted into information that can be interpreted by the application via the runtime library. If the information of the accelerator 10 obtained by the application is a physical address and the physical address cannot be interpreted by the application, it is converted to a logical address that can be interpreted by the application via the runtime library.

The operation of the profiling method of this embodiment will be described. As shown in FIG. 1, a development environment computer exports a compiled execution program (binary) (S10), and an execution environment SoC 1 imports the exported execution program (S11). When the execution program is imported into the SoC 1 of the execution environment, the conversion information between the environments is stored in the runtime library. As an example, memory value attribute information such as memory address, size, instructions and rewritable data of the execution environment to which the binary of the execution program is mapped is stored.

The accelerator 10 performs processing by executing an execution program according to instructions from the application (S12). At this time, the information of the accelerator 10 is hidden in the runtime library and cannot be seen from the host CPU 21 . For example, the physical address of the execution environment is changed for the execution environment by rewriting the address translation table when the execution file is imported. In the profiling method of this embodiment, the runtime library is provided with a function that allows the host CPU 21 to acquire information that is hidden during execution. The runtime library converts the information of the accelerator 10 into logical information that can be interpreted by the application, and performs profiling of the accelerator 10 (S13). The host CPU 21 writes the information converted by the runtime library into the log file (S14). The execution status of SoC 1 can be profiled by reading this log file into the development environment computer (S15) and viewing the log file with the viewer of the development environment computer.

FIG. 3 is a diagram showing a sequence for acquiring profiling information in SoC1 of the execution environment. First, the host CPU 21 generates a log file in which profiling information is written (S20). Next, the host CPU 21 executes the application and instructs the accelerator 10 to start executing the application (S21). Upon receiving this, the accelerator 10 performs processing (S22). When the processing ends, the accelerator 10 interrupts the application and notifies the end of the processing.

The profile function of the application sends a command to read the status to the accelerator 10 (S23), and the accelerator 10 reads the status and sends it to the application (S24).

The profiling function of the application asks the run-time library to convert values that cannot be interpreted by the application among the read data. For example, the physical address is sent to the runtime library (S25), and the virtual address corresponding to the physical address is obtained from the runtime library (S26). Then, the profile function generates log data based on the obtained virtual address (S27), and writes the generated log data to the profile log file (S28). In this way, the execution status of the accelerator 10 is converted into logical information and written to the log file. Subsequently, the host CPU instructs the accelerator 10 to start execution (S29), the accelerator 10 is executed, and the above process is repeated to generate a profile log file.

It is useful as a method for profiling accelerators in multi-core environments.

1... SoC, 10... accelerator, 20... event handler,
21... Host CPU, 22... ROM, 23... RAM,
24: external interface, 25: system bus

Claims (3)

a step of exporting, from a computer in a development environment, an execution program for an accelerator compiled by the computer (S10);
importing the execution program into an execution environment having a host CPU and an accelerator (the execution environment is an environment different from the development environment); a step (S11) of storing the conversion information of
a step of causing an application executed on the host CPU to execute processing of an execution program on the accelerator via the runtime library in the execution environment (S12);
a step (S13) in which the application acquires the state (status) of the accelerator being executed via the runtime library;
said application writing (S14) at least part of said status to a log file;
A profiling method comprising: If the accelerator information obtained by the application is information that cannot be interpreted by the application, converting it into information that can be interpreted by the application via the runtime library;
the application writing information translated by the runtime library to the log file;
The profiling method of claim 1, comprising: If the accelerator information obtained by the application is a physical address and the physical address becomes information that cannot be interpreted by the application, converting it into a logical address that can be interpreted by the application via the runtime library;
said application writing said logical address to said log file;
3. The profiling method of claim 2, comprising:

Images