Intermediate-language generation device, method for generating intermediate-language generation, and program

Abstract

To provide a technique of executing intermediate languages in a part of a series of processes and generating intermediate languages as well for the subsequent processes on the basis of the result.SOLUTION: The intermediate-language generation device, when generating an intermediate language for a program in which a repetitive process is described, includes means for generating a second intermediate language by a second compiler, and means for determining, on the basis of the second intermediate language, whether the repetitive process can be reduced. The device also includes means for generating, by a first compiler, a first intermediate language of a program in which the repetitive process has been reduced, on the basis of the second intermediate language, in a case where the repetitive process can be reduced.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to an intermediate language generation device, an intermediate language generation method, and a program. [Background technology]

[0002] There is a library function that receives a user-defined function and performs repeated processing. An example of a user program that includes a user-defined function is shown below.

[0003] (User programs including user-defined functions) #User-defined functions def func(row): return row[“a”] + row[“b”] #Calling library functions tbl[“c”] = tbl.apply(func)

[0004] The user-defined function func(row) receives row data such as tabular data or matrix data as an argument and returns the sum of the values ​​in columns a and b of the received row data. In the user program, the user-defined function func(row) is passed as an argument to the apply function of tbl (Table object), and the result is set in column c of the table indicated by tbl. An example of the library function tbl.apply is shown below.

[0005] (library functions) class Table: def apply(self, func): for row in self.rows: func(row)

[0006] This library function apply(self, func) receives itself (the Table object) and the user-defined function func(row), and calls and executes the user-defined function func(row) for each row of the object. Figure 1 shows an example of the execution result of the above user program for the table A1 to be processed. User-defined functions can be used to implement functionality not provided by the library.

[0007] Let us consider generating an intermediate language for the above user program. In this case, the intermediate language may look like this:

[0008] # Line 0 %1 = get_row(%tbl, 0) %2 = get_scalar(%1, "a") %3 = get_scalar(%2, "b") %4 = add_scalar(%2, %3) %5 = set_row(%result, 0, %4) # Line 1 %6 = get_row(%tbl, 1) %7 = get_scalar(%6, “a”) %8 = get_scalar(%7, "b") %9 = add_scalar(%8, %3) %10 = set_row(%result, 1, %9) (The rest is omitted. Similar intermediate language is generated for each row in the table.)

[0009] get_row(%tbl, 0) is a command to read row 0 of the specified table, get_scalar(%1, "a") is a command to read column a from column %1, add_scalar(%2, %3) is a command to add %2 and %3, and set_row(%result, 0, %4) is a command to set %4 to %result (column c) in row 0. When generating intermediate language for a user program that includes repetitive processing, such as processing each row or column of tabular data or matrix data, instructions must be generated for each repetition. This increases processing costs. Specifically, this can result in slower speeds due to the overhead of generating intermediate language instructions and the overhead of executing the generated instructions, as well as increased memory usage due to a large number of instructions.

[0010] Another example is generating an intermediate language for repetitive processing. When a program is executed, the library function that generates the intermediate language calls a function provided by another library (called the parent library), making it available to user programs as a compatible library. This function is called a fallback. The called function is called a fallback function. From the user's perspective, the library function appears to have the fallback function of the parent library. By using the fallback mechanism, it is possible to supplement missing functions in the library function.

[0011] Below is an example where the above library function does not have an apply function and uses the apply function of the parent library as a fallback function. (library functions that use fallback) class Table: def apply(self, func): parent_table = to_parent(self) def wrapper(parent_row): row = from_parent(parent_row) ret = func(row) return to_parent(ret) result = parent_table.apply(wrapper) return from_parent(result)

[0012] to_parent() is a command that converts the data structure of a library function (your library) to that of the parent library, and from_parent() is a command that converts the data structure of the parent library to that of your library. Library functions that use this fallback pass a wrapper function to the parent library, which describes the process of converting row data from the parent library's data structure to your library's data structure and the process of passing the converted row data to the user-defined function func. The parent library then executes apply, receives the result, and converts the parent library's data structure to your library's data structure. When calling a fallback function, it may not be possible to pass the user-defined function directly to the parent library. In this case, a wrapper function with the added functionality of converting the parent library's data and the library function's data structure is passed to the parent library. Data structure conversion occurs for each row in a table, which increases processing costs. Specifically, there is a high possibility of slower processing speeds and increased memory usage due to the large number of instructions and the large amount of data conversion during fallback.

[0013] As a related technology, Patent Document 1 describes a compilation processing method having a first compiler that reads a source program and generates an intermediate language (also called an intermediate representation (IR)), and a second compiler that reads the generated intermediate language and generates object code. [Prior art documents] [Patent documents]

[0014] [Patent Document 1] Japanese Patent Application Laid-Open No. 2009-26048 Summary of the Invention [Problem to be solved by the invention]

[0015] One of the objects of the present invention is to provide a method for preventing a large number of instructions from being generated when generating an intermediate language for a program including repetitive processing. [Means for solving the problem]

[0016] According to one aspect of the present disclosure, an intermediate language generation device includes: a means for generating an intermediate language for a program in which a repetitive process is described, using a second compiler to generate a second intermediate language from the program; and a means for determining whether the repetitive process can be reduced based on the second intermediate language, and if so, using a first compiler to generate a first intermediate language for the program from which the repetitive process has been reduced, based on the second intermediate language.

[0017] According to one aspect of the present disclosure, an intermediate language generation method generates an intermediate language for a program in which a repetitive process is described by generating a second intermediate language from the program using a second compiler, determining whether the repetitive process can be reduced based on the second intermediate language, and if the repetitive process can be reduced, generating a first intermediate language for the program from which the repetitive process has been reduced using a first compiler based on the second intermediate language.

[0018] According to one aspect of the present disclosure, a program causes a computer to execute a process of generating an intermediate language of a program in which a repetitive process is described, by generating a second intermediate language from the program using a second compiler, determining whether the repetitive process can be reduced based on the second intermediate language, and if the repetitive process can be reduced, generating a first intermediate language of the program from which the repetitive process has been reduced based on the second intermediate language using a first compiler. [Effects of the Invention]

[0019] According to the present disclosure, when generating an intermediate language for a program that includes repetitive processing, it is possible to prevent a large number of instructions from being generated. [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 10 is a diagram illustrating an example of an execution result of a user program. [Figure 2] FIG. 1 illustrates an example of an intermediate language generation device according to an embodiment. [Figure 3] 3A and 3B are diagrams illustrating an outline of an intermediate language generation process and an execution process according to an embodiment. [Figure 4] FIG. 2 is a diagram illustrating an example of a configuration of a front end according to an embodiment. [Figure 5] FIG. 2 is a diagram illustrating an outline of an intermediate language generation process according to the embodiment. [Figure 6] 10 is a flowchart showing an example of an operation example 2 according to the embodiment. [Figure 7] FIG. 10 is a diagram illustrating an example of an operation example 2 according to the embodiment. [Figure 8] FIG. 10 is a diagram illustrating an operation example 3 according to the embodiment. [Figure 9] 10 is a flowchart illustrating an example of an intermediate language generation process according to the embodiment. [Figure 10] FIG. 10 is a diagram illustrating another example of an intermediate language generation device according to the embodiment. [Figure 11] 10 is a flowchart illustrating an example of an operation of the intermediate language generation device according to the embodiment. [Figure 12] FIG. 2 is a diagram illustrating an example of a hardware configuration of an intermediate language generation device according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0021] Hereinafter, an intermediate language generation process according to each embodiment of the present disclosure will be described with reference to the drawings. In the drawings used in the following description, the description of parts not related to the present disclosure may be omitted or not shown. The same or equivalent parts in all drawings will be given the same reference numerals, and common descriptions may be omitted.

[0022] <Embodiment> (System Configuration) FIG. 2 is a diagram illustrating an example of an intermediate language generation device 10 according to the embodiment. The intermediate language generation device 10 includes a program acquisition unit 11, a front-end unit 12, a middleware unit 13, and a back-end unit 14. The program acquisition unit 11 acquires a program to be executed (user program). The front-end unit 12 generates an intermediate language for the user program acquired by the program acquisition unit 11. The front-end unit 12 determines whether or not it is possible to reduce the repetitive processes included in the user program, and if it is possible to reduce the repetitive processes, it generates an intermediate language by changing the repetitive processes to reduced processes. The middleware unit 13 optimizes the intermediate language of the entire user program generated by the front-end unit 12 . The back-end unit 14 executes the intermediate language optimized by the middleware unit 13 .

[0023] FIG. 3 shows an outline of the process of generating and executing an intermediate language by the intermediate language generation device 10. (S1) The program acquisition unit 11 acquires a program (for example, the following user program 0) and passes it to the front-end unit 12.

[0024] (User program 0) d = mat_mul(a, b) e = mat_mul(a, c) f = mat_add(d, e) print(mat_eval(f))

[0025] Here, mat_mul, mat_add, and mat_eval are functions included in the library that uses the intermediate language. mat_mul is a library function that generates an intermediate language that performs the multiplication of arguments. mat_mul(a, b) generates an intermediate language that performs a × b (it only generates the intermediate language and does not perform the a × b operation). mat_add is a library function that generates an intermediate language that performs the addition of arguments. mat_add(d, e) generates an intermediate language that performs d + e (it only generates the intermediate language and does not perform the d + e operation). mat_eval is a function that instructs the execution of the generated intermediate language. When mat_eval(f) is called, the intermediate language that calculates f is executed (deferred execution). The d + e operation is performed at this time. The intermediate language for calculating d and e, which are necessary for the f operation, is also executed, and a × b and a × c are performed.

[0026] (S2) The front-end unit 12 generates an intermediate language. The front-end unit 12 outputs the generated intermediate language to the middleware unit 13. (Example of the generated intermediate language for user program 0) %d = mul(%a, %b) %e = mul(%a, %c) %f = add(%d, %e)

[0027] (S3) The middleware unit 13 optimizes the intermediate language. In this example, a×b+a×c can also be written as a×(b+c), and since a×(b+c) requires less computation, the middleware unit 13 optimizes the intermediate language, for example, as follows. The middleware unit 13 outputs the optimized intermediate language to the backend unit 14. (Example of optimized intermediate language) %d = add(%b, %c) %f = mul(%a, %d)

[0028] (S4) The back-end unit 14 executes the intermediate language. The back-end unit 14 executes mat_eval(f). At this time, the intermediate language generated up to the previous stage is executed (delayed execution). Because it is abstracted by the intermediate language, the user program can be executed on various platforms such as a CPU and a GPU without changing the user program.

[0029] Next, a description will be given of the configuration of the front end unit 12 having a function for preventing a large number of instructions from being generated when generating an intermediate language for a program including repetitive processing.

[0030] FIG. 4 is a diagram showing an example of the configuration of the front end unit 12. As shown in FIG. The front end unit 12 includes a first compiler 121, a second compiler 122, and a control unit 123.

[0031] The first compiler 121 generates an intermediate language for a program using a define-by-run method. Generating an intermediate language using the define-by-run method is a method of generating an intermediate language that means the execution of a command, function, etc. written in a program when the function, etc. is called. As described above, the generated intermediate language is later executed by the back-end unit 14 (delayed execution). The first compiler 121 generates the intermediate language based on the determination result of the control unit 123.

[0032] The second compiler 122 generates an intermediate language for a program using an ahead-of-time compilation method. An example of an ahead-of-time compilation method is a compiler for the C language. While the first compiler 121 converts functions and the like written in a user program into an intermediate language when they are executed (for example, if there is code branched by an if statement, only the code that passes through the branch is generated in intermediate language, and no intermediate language is generated for code that does not pass because it does not meet the condition of the if statement), the second compiler 122 analyzes the entire source code and converts it into an intermediate language (an intermediate language for the entire if statement block is generated). For example, if the user program includes a repetitive process, the first compiler 121 expands the repetitive process using an interpreter method and generates an intermediate language for each repetition, while the second compiler 122 converts the code for the repetitive process directly into an intermediate language. The second compiler 122 does not require domain-specific knowledge of tabular data processing libraries such as matrices, tables, or tables; it only requires knowledge of programming languages ​​and type inference. Hereinafter, the intermediate language generated by the first compiler 121 will be referred to as the first intermediate language, and the intermediate language generated by the second compiler will be referred to as the second intermediate language.

[0033] The control unit 123 analyzes the second intermediate language generated by the second compiler 122 to determine whether the repetitive processing can be replaced with a batch processing, and if so, rewrites the processing in the second intermediate language accordingly. For example, suppose there is a processing step for a table having columns A, B, and C. The processing step reads data from columns A and B and calculates the sum of the two data points, repeating the process for the number of rows in the table. If a function or method is provided that performs this processing on the entire table without regard to the number of rows, the control unit 123 determines that the processing of repeatedly accessing rows written in the original program (library function) can be replaced with a function (batch processing) that performs this processing on the entire table. If such a function or method is not provided, the control unit 123 determines that the processing cannot be replaced. If the control unit 123 determines that the replacement with a batch processing is possible, it replaces the repetitive processing in the second intermediate language with a batch processing. The first compiler 121 generates a first intermediate language from the second intermediate language after the replacement. If the control unit 123 determines that replacement with batch processing is not possible, the first compiler 121 generates an intermediate language for processing each line for the number of repetitions. Furthermore, the control unit 123 determines whether a wrapper function is necessary when a fallback function is used in the library function as in the above example. If a wrapper function is not necessary, the control unit 123 rewrites the library function in a second intermediate language without the wrapper function when calling the fallback function, and passes the second intermediate language of the library function omitting the wrapper function to the first compiler 121. The first compiler 121 generates a first intermediate language based on the second intermediate language.

[0034] FIG. 5 shows an overview of the process of generating an intermediate language according to this embodiment. The front-end unit 12 uses the second compiler 122 to generate a second intermediate language of a user-defined function using an ahead-of-time compilation method (Operation Example 1). The control unit 123 determines whether it is possible to replace a repetitive process with a batch process based on the second intermediate language, and performs the replacement if possible. The first compiler 121 generates a first intermediate language based on the results of the determination and replacement by the control unit 123 (Operation Example 2). Furthermore, if the program uses a fallback function, the control unit 123 determines whether it is possible to remove a wrapper function when calling the fallback function, and removes the wrapper function if possible. The first compiler 121 generates a first intermediate language including a fallback based on the results of the determination by the control unit 123 (Operation Example 3). Operation Examples 1 to 3 will be described below using examples.

[0035] (Example 1) Conversion into the second intermediate language by the second compiler 122 will now be described. (user-defined functions) def func(row): return row[“a”] + row[“b”] The second compiler 122 generates the following intermediate language from this user-defined function:

[0036] (Second intermediate language) $row:row = getarg(0) $1:scalar = getitem($row:row, “a”:str) $2:scalar = getitem($row:row, “b”:str) $3:scalar = add($1:scalar, $2:scalar) return $3:scalar

[0037] Conversion to the second intermediate language is used to understand the structure of user-defined functions and analyze whether it is possible to replace repetitive processing and whether it is possible to omit wrapper functions when calling fallback functions. Therefore, generating the second intermediate language does not require domain-specific knowledge of tabular data processing libraries; knowledge of programming languages ​​and type inference is sufficient. For example, the getitem command does not need to mean "extract a column from row data." It only needs to be converted into an intermediate language (second intermediate language) that means calling the `__getitem__` method of the variable row in a programming language (e.g., Python). Furthermore, the second compiler 122 does not call a function, but instead reads the function's source code and generates the intermediate language.

[0038] (Example 2) Next, we will explain the operation of generating a first intermediate language that reduces repetitive processing based on the second intermediate language generated in operation example 1, but before that, we will explain that the processing for a row in the above user-defined function can be rewritten as processing for the entire table.

[0039] (user program) #User-defined functions def func(row): return row[“a”] + row[“b”] #Calling library functions tbl[“c”] = tbl.apply(func)

[0040] Specifically, it is assumed that the above user program can also be written as follows: (Another way to write a user program) tbl[“c”] = tbl[“a”] + tbl[“b”]

[0041] Here, tbl["a"] is a library function that reads all data in column A of the table. If written in this way instead of calling the library function apply and passing a user-defined function, the following first intermediate language can be generated by the first compiler 121. The following first intermediate language is independent of the number of lines, so there is no increase in overhead as there is no need to generate instructions for the number of lines.

[0042] (Intermediate language for writing user programs in a different way) %1 = project(%tbl, “a”) %2 = project(%tbl, “b”) %3 = add(%1, %2) %4 = setitem(%tbl, “c”, %3)

[0043] In the following description, it is assumed that the control unit 123 has knowledge of commands that access the entire column. Next, an operational example 2 will be described with reference to the flowchart of FIG.

[0044] The control unit 123 refers to the second intermediate language and determines whether the user-defined function can be executed on the entire table (S11). The control unit 123 determines whether the command can be executed on the table when the following second intermediate language is executed row by row. "Executable on a table" means that the result is the same when the second intermediate language processing is executed on all rows as when the command is executed once on the table.

[0045] (Second Intermediate Language (Reprinted)) $row:row = getarg(0) $1:scalar = getitem($row:row, “a”:str) $2:scalar = getitem($row:row, “b”:str) $3:scalar = add($1:scalar, $2:scalar) return $3:scalar

[0046] In the above process, the values ​​of each row are obtained using getitem($row:row, "a":str) and getitem($row:row, "b":str), and the sum of the obtained values ​​is calculated using add($1:scalar, $2:scalar). Since the result is the same whether this process is repeated row by row or performed for the entire table, the control unit 123 determines that the user-defined function can be executed for the entire table. An example in which a user-defined function cannot be executed for the entire table is shown below.

[0047] (Example where commands for each row cannot be replaced with commands for the table) s = 0 def func(row): s += row["a"] return row["b"] + s tbl[“c”] = tbl.apply(func)

[0048] In this example, the data in column a of each row is added to the external variable s one after another. The processing for a row is affected by the value of the data in column a of the previous row, so the processing for each row is not independent. In such a case, the control unit 123 determines that the user-defined function func() cannot be executed on the entire table. The control unit 123 may determine that the repetitive processing cannot be replaced with a batch processing if an external variable or external function is used in the repetitive processing.

[0049] Returning to the example where the user-defined function is executable for the entire table, if it is determined that the function is executable (S12; Yes), the control unit 123 converts the second intermediate language of the user-defined function into a table execution (S13). The control unit 123 converts the second intermediate language shown in "(Second intermediate language (listed again))" above, for example, as follows:

[0050] (Second intermediate language after type conversion) $row:table = getarg(0) $1:column = getitem($row:table, “a”:str) $2:column = getitem($row:table, “b”:str) $3:column = add($1:column, $2:column) return $3:column

[0051] In "(Second intermediate language after type conversion)", the data type of the argument received by getarg(0), which means to obtain the zeroth argument described in the first line of "(Second intermediate language (repeated))", is converted from row type to table type ($row:row → $row:table, where $row is the variable name and the part after the : indicates the data type of the variable $row. The same applies below). Also, in lines 2 to 4, the data types of the data obtained by getitem and the data added by add are converted from scalar type to column type (e.g., $1:scalar → $1:column). As a result, the process of reading and adding data for each row is converted to a second intermediate language in which the process of reading and adding data for the entire column is executed. The control unit 123 instructs the first compiler 121 to generate a first intermediate language from the converted second intermediate language.

[0052] A first intermediate language is generated from the converted second intermediate language (S14). The first compiler 121 reads "(type-converted second intermediate language)" and follows it line by line, generating an intermediate language (first intermediate language) for executing the original programming language (e.g., Python) according to the meaning of each instruction in the second intermediate language. For example, the first compiler 121 reads the first two lines of "(type-converted second intermediate language)" line by line, and determines that for the first line, a table (table is a data type provided by the library) should be assigned to the variable $row. For the second line, it determines that tbl["a"], a column extraction function for table data provided by the library, can be used, and generates a first intermediate language "%1 = project(%tbl, "a")" using the define-by-run method. The first compiler 121 similarly converts the second intermediate language to the first intermediate language for subsequent processes, generating the following first intermediate language:

[0053] (First intermediate language) $row:table = getarg(0) $1:column = getitem($row:table, “a”:str) $2:column = getitem($row:table, “b”:str) $3:column = add($1:column, $2:column) return $3:column

[0054] When the first intermediate language is generated, the control unit 123 determines that the generation of the first intermediate language has been successful (S15). On the other hand, if it is determined that the user-defined function is not executable on the entire table (S12; No), the control unit 123 determines that the generation of the first intermediate language has failed (S16). A diagram summarizing the second operation example up to this point is shown in Figure 7.

[0055] (Example 3) Next, operation example 3 will be described. Operation example 3 is a process that is executed when generation of the first intermediate language fails. In operation example 3, when a library function uses a fallback function, it is determined whether the wrapper function can be omitted when calling the fallback function, and if it can be omitted, a first intermediate language that omits the wrapper function is generated.

[0056] When calling a fallback function, the control unit 123 determines whether a wrapper function is necessary for fallback. If a wrapper function is not necessary, the control unit 123 passes the user-defined function as is (without data conversion) to the parent library for fallback, thereby reducing data conversion overhead. For example, the control unit 123 checks whether each command in the second intermediate language uses an external variable (a variable defined outside the function). If no external variable is used, the control unit 123 determines that data conversion is not necessary because library data is not used in the user-defined function, and therefore a wrapper function is not necessary. For example, assume that the above "second intermediate language (listed again)" is the intermediate language of a program that uses a fallback function. The control unit 123 determines that data conversion is not necessary for the processing in lines 2 to 4 because the processing is completed within the row passed as an argument. For example, in the following user-defined function, the external variable x is added to the value of column B of each row. In such a case, a wrapper function is required because the data structure of the external variable x in the library function and the data in each row in the parent library must match. For example, if an external variable or an external function is used in the repetitive processing, the control unit 123 may determine that the wrapper function cannot be omitted. If the wrapper function can be omitted, the control unit 123 instructs the first compiler 121 to convert the second intermediate language generated by the second compiler 122 into content in which the wrapper function is omitted and to convert the converted second intermediate language into the first intermediate language. If the wrapper function cannot be omitted, the control unit 123 instructs the first compiler 121 to convert the second intermediate language generated by the second compiler 122 into the first intermediate language. The first compiler 121 generates the first intermediate language from the second intermediate language.

[0057] (User program that uses external variables in user-defined functions) #x is an external variable x = def func(row): return row["b"] + x #apply is a fallback function tbl[“c”] = tbl.apply(func)

[0058] FIG. 8 shows an example of a general library function when a fallback function is called and a library function when the wrapper function is omitted. Function 81 in FIG. 8 is a general library function, and function 82 is a library function in which the wrapper function is omitted. When the control unit 123 determines that the wrapper function can be omitted, the first compiler 121 generates a first intermediate language corresponding to function 82 in FIG. 8 from a second intermediate language (not shown). When the control unit 123 determines that the wrapper function cannot be omitted, the first compiler 121 generates a first intermediate language corresponding to function 81 in FIG. 8 from a second intermediate language (not shown). The method of generating the first intermediate language from the second intermediate language is to traverse the second intermediate language line by line, as described in Operation Example 2, and generate a first intermediate language for executing the original programming language according to the meaning of each instruction in the second intermediate language.

[0059] (operation) Next, with reference to FIG. 9, an intermediate language generation process that suppresses the generation of a large number of instructions when generating an intermediate language for a repetitive process will be described, taking as an example a case where the target of the repetitive process is a user-defined function. FIG. 9 is a flowchart illustrating an example of an intermediate language generation process according to the embodiment. First, the second compiler 122 generates a second intermediate language from the user-defined function (S21). For example, if the user-defined function uses an instruction that is not supported by the second compiler, it may not be possible to generate the second intermediate language. In such a case, generation of the second intermediate language fails. If generation of the second intermediate language fails (S22; No), the process proceeds to step S29, which will be described later. If generation of the second intermediate language is successful (S22; Yes), the control unit 123 determines whether the processing of the user-defined function can be applied to the entire table (S23). This process is similar to S11 in FIG. 6. If it is applicable (S24; Yes), the first compiler 121 generates a first intermediate language in which the processing of the user-defined function is applied to the entire table (S25). This process is similar to S13 to S15 in FIG. 6. In this case, repeated processing is eliminated, which significantly reduces overhead and enables the fastest processing.

[0060] If the processing of the user-defined function is not applicable to the entire table (S24; No), the control unit 123 determines from the second intermediate language whether a fallback function is used in the user-defined function. If a fallback function is used, the control unit 123 determines whether a wrapper function is required (S26). For example, if the instruction in the second intermediate language indicates whether a parent library is to be called, and if the parent library is called, the control unit 123 determines that a fallback function is used. Furthermore, as described in the above embodiment, if a user-defined function is passed to a fallback function and executed on the parent library side, the control unit 123 determines whether a wrapper function is required or can be omitted depending on whether the user-defined function uses external variables. If a wrapper function is not required (S27; No), the control unit 123 modifies the second intermediate language to omit the wrapper function, and the first compiler 121 generates a first intermediate language that executes fallback without a wrapper function from the modified second intermediate language (S28). In this case, the overhead of data conversion using a wrapper function can be reduced.

[0061] If a wrapper function is needed (S27; Yes), the first compiler 121 generates a first intermediate language that executes fallback with the wrapper function from the second intermediate language generated by the second compiler 122 (S29). The process of S29 is also executed if the result of S22 is No or if the fallback function is not used in the user-defined function. The first intermediate language generated in step S29 is the same as the intermediate language generated by general processing using the define-by-run method.

[0062] (effect) As described above, according to this embodiment, when generating an intermediate language for a program including repetitive processing, it is possible to prevent the generation of a large number of instructions and reduce processing costs and computer resource consumption. More specifically, by converting the processing content of a process that repeatedly executes a user-defined function on a portion of data in an entire table, such as a row, into a batch process on the entire data in the table, which is configured by collecting the portion, and generating an intermediate language, it is possible to prevent the generation of a large number of instructions. Furthermore, with regard to a process that falls back from a process that repeatedly executes a user-defined function on a portion of data in the entire table, it is possible to prevent the generation of a large number of instructions (data conversion instructions) by performing data conversion not in units of partial data but in units of the entire data configured by collecting the partial data.

[0063] While the above embodiment has exemplified the replacement of processing for each row of tabular data with processing for the entire table (all rows of the table), if the program to be executed contains repetitive processing for each column of tabular data, this embodiment may be applied to replace processing for each column with processing for the entire table (all columns of the table) to generate a first intermediate language. Furthermore, not only when repetitive processing for each column or row of tabular data is repeated for all columns or all rows, but also when it is executed for some columns or some rows, if a function or the like is provided that performs processing collectively for a range of columns or a range of rows to be processed, this embodiment can be applied to replace the repetitive processing with this function, thereby preventing an increase in the overhead of generating an intermediate language and the generation of a large number of instructions.

[0064] <Other embodiments> FIG. 10 is a diagram illustrating another example of an intermediate language generation device according to the embodiment. The intermediate language generation device 800 includes a first means 801 and a second means 802. The second means 802 generates a second intermediate language by a second compiler when generating an intermediate language for a program in which a repetitive process is described. A first means 801 determines whether the repetitive processing can be reduced based on the second intermediate language, and if it can be reduced, generates a first intermediate language in which the repetitive processing has been reduced by a first compiler. The front-end unit 12 including the first compiler 121 and the control unit 123 is an example of the first means 801 . The front end unit 12 including the second compiler 122 is an example of the second means 802 .

[0065] FIG. 11 is a flowchart showing an example of the operation of the intermediate language generation device according to the embodiment. The second means 802 generates a second intermediate language by a second compiler when generating an intermediate language for a program in which a repetitive process is described (step S801). The first means 801 determines whether the repetitive processing can be reduced based on the second intermediate language (step S802), and if it can be reduced, generates a first intermediate language in which the repetitive processing has been reduced using a first compiler (step S803). Intermediate language generation method.

[0066] FIG. 12 is a diagram illustrating an example of a hardware configuration of the intermediate language generation device according to the embodiment. The computer 900 includes a CPU 901, a main memory device 902, an auxiliary memory device 903, an input / output interface 904, and a communication interface 905. The above-described intermediate language generation devices 10, 800 are implemented in the computer 900. The above-described functions are stored in the auxiliary memory device 903 in the form of a program. The CPU 901 reads the program from the auxiliary memory device 903, loads it into the main memory device 902, and executes the above-described processing in accordance with the program. The CPU 901 also allocates a storage area in the main memory device 902 in accordance with the program. The CPU 901 also allocates a storage area in the auxiliary memory device 903 for storing data being processed in accordance with the program.

[0067] A program for implementing all or part of the functions of the intermediate language generation device 10, 800 may be recorded on a computer-readable recording medium, and the program may be loaded into a computer system and executed to perform processing by each functional unit. The term "computer system" as used herein includes hardware such as an OS and peripheral devices. Furthermore, if a WWW system is used, the term "computer system" also includes the homepage provision environment (or display environment). Furthermore, the term "computer-readable recording medium" refers to portable media such as CDs, DVDs, and USBs, as well as storage devices such as hard disks built into the computer system. Furthermore, if the program is distributed to the computer 900 via a communication line, the computer 900 that receives the program may load the program into the main storage device 902 and execute the above-described processing. Furthermore, the program may be for implementing part of the above-described functions, or may be capable of implementing the above-described functions in combination with a program already stored in the computer system.

[0068] Although one embodiment of the present disclosure has been described in detail above with reference to the drawings, the specific configuration is not limited to the above, and various design modifications are possible within the scope of the gist of the present invention. Furthermore, one aspect of the present disclosure may be modified in various ways within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present disclosure. Furthermore, configurations in which elements described in the above embodiments and variations are substituted with elements that achieve the same effect are also included. Furthermore, each embodiment may be combined with other embodiments as appropriate.

[0069] Some or all of the above embodiments can be described as, but are not limited to, the following supplementary notes.

[0070] (Appendix 1) An intermediate language generation device comprising: means for generating an intermediate language of a program in which a repetitive process is described, using a second compiler to generate a second intermediate language from the program; and means for determining whether the repetitive process can be reduced based on the second intermediate language, and if so, using a first compiler to generate a first intermediate language of a program in which the repetitive process has been reduced from the program, based on the second intermediate language.

[0071] (Appendix 2) An intermediate language generation device as described in Appendix 1, wherein the first compiler generates the first intermediate language using a define-by-run method, and the second compiler generates the second intermediate language using an ahead-of-time method.

[0072] (Appendix 3) In the intermediate language generation device described in Appendix 1 or Appendix 2, when the program is executing processing targeting rows or columns of tabular data during the repetitive processing, the means for generating the first intermediate language determines whether the processing targeting the rows or columns can be replaced with processing performed on all of the tabular data at once, and if so, generates, by the first compiler, a first intermediate language of a program in which the repetitive processing of the program has been replaced with processing performed on all of the tabular data at once.

[0073] (Appendix 4) This is an intermediate language generation device described in any of Appendix 1 to Appendix 3, wherein, when the program calls an external library that requires data conversion during the repetitive processing, the means for generating the first intermediate language determines whether the data conversion processing required to call the external library can be reduced, and if it can be reduced, generates a first intermediate language of the program in which the data conversion processing has been reduced by the first compiler.

[0074] (Appendix 5) This is an intermediate language generation method in which, when generating an intermediate language for a program in which a repetitive process is described, a second intermediate language is generated from the program by a second compiler, and based on the second intermediate language, it is determined whether the repetitive process can be reduced, and if it can be reduced, a first intermediate language of a program in which the repetitive process has been reduced from the program by a first compiler is generated based on the second intermediate language.

[0075] (Appendix 6) This is a program that causes a computer to execute the following process: when generating an intermediate language for a program in which a repetitive process is described, a second intermediate language for the program is generated by a second compiler; based on the second intermediate language, it is determined whether the repetitive process can be reduced; and if so, a first compiler generates a first intermediate language for a program in which the repetitive process has been reduced from the program, based on the second intermediate language. [Explanation of symbols]

[0076] 10. Intermediate language generator 11. Program Acquisition Department 12 Front end 121...The First Compiler 122...Second Compiler 123 Control unit 13. Middleware Department 14 Back-end section 800 Intermediate language generator 801...First means 802...Second method 900···Computer 901 CPU 902...Main memory 903...Auxiliary storage device 904 Input / Output Interface 905···Communication Interface

Claims

1. a means for generating an intermediate language from a program in which a repetitive process is described by using a second compiler; a means for determining whether the repetitive processing can be reduced based on the second intermediate language, and if so, generating a first intermediate language of the program in which the repetitive processing has been reduced based on the second intermediate language by a first compiler; An intermediate language generation device comprising:

2. the first compiler generates the first intermediate language in a define-by-run manner; the second compiler generates the second intermediate language in an ahead-of-time manner; The intermediate language generation device according to claim 1 .

3. When the program executes processing for rows or columns of tabular data during the repetitive processing, the means for generating the first intermediate language determines whether the processing for the rows or columns can be replaced with processing performed collectively on all of the tabular data, and if so, generates, by the first compiler, a first intermediate language for a program in which the repetitive processing of the program has been replaced with processing performed collectively on all of the tabular data.

3. The intermediate language generation device according to claim 1.

4. When the program calls an external library that requires data conversion during the repetitive processing, the means for generating the first intermediate language determines whether or not the data conversion process required to call the external library can be reduced, and if so, generates a first intermediate language of the program in which the data conversion process has been reduced by the first compiler.

3. The intermediate language generation device according to claim 1.

5. When generating an intermediate language for a program in which a repetitive process is described, a second intermediate language is generated from the program by a second compiler; determining whether the repetitive processing can be reduced based on the second intermediate language, and if so, generating a first intermediate language of the program in which the repetitive processing has been reduced based on the second intermediate language by a first compiler; Intermediate language generation method.

6. On the computer, When generating an intermediate language for a program in which a repetitive process is described, a second intermediate language is generated from the program by a second compiler; a process of determining whether the repetitive processing can be reduced based on the second intermediate language, and if so, generating a first intermediate language of the program in which the repetitive processing has been reduced based on the second intermediate language by a first compiler; A program that executes the following.

Images