WO2017034364A1 - 사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법 - Google Patents

사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법 Download PDF

Info

Publication number
WO2017034364A1
WO2017034364A1 PCT/KR2016/009502 KR2016009502W WO2017034364A1 WO 2017034364 A1 WO2017034364 A1 WO 2017034364A1 KR 2016009502 W KR2016009502 W KR 2016009502W WO 2017034364 A1 WO2017034364 A1 WO 2017034364A1
Authority
WO
WIPO (PCT)
Prior art keywords
code
computing device
application
node
module
Prior art date
Application number
PCT/KR2016/009502
Other languages
English (en)
French (fr)
Inventor
전철용
문지중
이가오
우위안
김락기
라비쉬할뱅거
장용석
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to US15/755,419 priority Critical patent/US10705813B2/en
Publication of WO2017034364A1 publication Critical patent/WO2017034364A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/433—Dependency analysis; Data or control flow analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/47—Retargetable compilers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G06F8/423—Preprocessors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/433—Dependency analysis; Data or control flow analysis
    • G06F8/434—Pointers; Aliasing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load

Definitions

  • the present disclosure relates to a compiler module and a runtime module for efficiently executing an application in a terminal using various computing devices.
  • the terminal may include various processing devices (ie, HW modules) for executing the binary.
  • a representative example of such a computing device is a central processing unit (CPU).
  • the terminal may include a single instruction multiple data (SIMD), a parallel-SIMD, a graphics processing unit (GPU), a general purpose GPU (GPGPU), a digital signal processor (DSP), and the like.
  • SIMD single instruction multiple data
  • GPU graphics processing unit
  • GPU general purpose GPU
  • DSP digital signal processor
  • the developed application operates only according to the instructions (ie, scheduling) determined by the developer.
  • a corresponding code must be written in a language (or API) for the computing device.
  • the developer faces a situation in which synchronization between computing devices must also be considered.
  • the nature of the application depends entirely on the application developer.
  • the characteristics of an application that depends on the developer's implementation method, the resource utilization state of the computing device when the actual application operates in the device, or the data size that the application needs to calculate cannot be easily known by the developer when writing the code. . Therefore, there is a limit in that an application effectively utilizes an in-terminal computing device.
  • the present disclosure dynamically utilizes characteristics of an application and state information (eg, availability and operating frequency) of an in-terminal arithmetic device at the time of application operation, thereby enabling an application to efficiently utilize in-terminal arithmetic device (s). It provides a method and apparatus.
  • the present disclosure also proposes a method and apparatus for analyzing a code portion of an application that can be executed in each computing device, and provides a method and apparatus for reducing the complexity of the analysis task.
  • a method for executing an application using at least one computing device in a terminal device comprising: calculating a processing time of the at least one computing device; Selecting a predetermined number of computing devices on which to execute the application based on a user's preference or the calculated at least one processing time; Determining a workload that minimizes a processing time function determined using a utilization rate corresponding to the determined number of computing devices; And executing the application by applying the determined workload to the predetermined number of computing devices.
  • the present disclosure provides a terminal apparatus having a runtime module configured to perform an application by using at least one computing device, wherein the runtime module is configured to: calculate a processing time of the at least one computing device; Determine a predetermined number of computing devices on which to execute the application based on the calculated at least one processing time, and determine a workload that minimizes the processing time function determined using the usage rate corresponding to the determined predetermined number of computing devices. And a scheduler configured to apply the determined workload to the predetermined number of computing devices to perform the application. And a device monitor for calculating the utilization information.
  • the apparatus according to the present disclosure can effectively use each computing device, thereby accelerating application operating speed and reducing power consumption.
  • the apparatus according to the present disclosure may speed up the compiler's source code dependency (eg, pointer) resolution.
  • source code dependency eg, pointer
  • FIG. 1 illustrates a configuration of an application execution device according to the present disclosure
  • FIG. 2 is a diagram illustrating a constraint graph, source code, and IR that describe the conditions of nodes that the compiler module treats as one node in accordance with the present disclosure
  • FIG. 4 illustrates the effects of determining a computing device to operate according to the present disclosure and determining a workload in terms of resource utilization and energy usage
  • FIG. 5 is a table comparing processing time for each computing device according to an input size of a cache in applying the technique according to the present disclosure
  • FIG. 6 is a diagram illustrating performance (processing time) according to the load sharing ratio when using a CPU and a GPU in applying the technique according to the present disclosure
  • FIG. 7 is a diagram illustrating energy consumption according to a workload when using a CPU and a GPU in applying the technique according to the present disclosure
  • FIG. 8 illustrates performance (processing time) in workload and utilization when using a CPU and GPU in applying the technique according to the present disclosure
  • FIG. 9 is a diagram schematically illustrating an operation of a compiler module according to the present disclosure.
  • a base station is a subject that communicates with a terminal, and may also be referred to as a BS, a NodeB (NB), an eNodB (eNB), an access point (AP), or the like.
  • NB NodeB
  • eNB eNodB
  • AP access point
  • a user equipment is a subject that communicates with a base station and may also be referred to as a UE, a mobile station (MS), a mobile equipment (ME), a device, a terminal, or the like.
  • a terminal apparatus an apparatus having one or more computing devices will be described as a terminal apparatus.
  • the present disclosure provides an operation of an application by dynamically distributing an operation of a corresponding application to the computing device (s) in order to maximize utilization of available resources (computation devices) of a terminal according to an operation characteristic of a software (SW) aspect of the application.
  • SW software
  • the present disclosure provides a compiler portion for generating executable code so that software can be executed on different computing devices, and a runtime SW for enabling actual executable code to operate in consideration of operation characteristics and device state. software) section.
  • the compiler portion may for example be implemented as a compiler module and the runtime SW portion may for example be implemented as a runtime module.
  • the compiler module and the runtime module may be included in one device, such as a user terminal, or may be included in a separate device.
  • the compiler module may be implemented (mounted) in an HW such as a terminal, but may also be implemented in an HW such as a desktop or a server.
  • the runtime module may be implemented (mounted) in the HW, such as a terminal to run an application.
  • Code compiled in a compilation module of a device such as a desktop or a server may be imported to a terminal including a runtime module, and the compiled code may be executed by control or scheduling of the runtime module.
  • a compiler module and a runtime module are implemented in one device such as a terminal will be illustrated, but the scope of the present disclosure is not limited thereto, and also includes a case where each is implemented in a separate device.
  • FIG. 1 is a diagram illustrating a configuration of an application execution device according to the present disclosure.
  • the application execution device may include at least one of two modules, that is, the compiler module 100 and the runtime module 150.
  • the compiler module 100 and the runtime module 150 may be implemented as one module such as a controller.
  • the compiler module may have a compiler infrastructure such as, for example, LLVM (http://llvm.org/).
  • the compiler module 100 receives application source code 102 or compiler directives written in a language such as C or C ++. Examples of the C / C ++ compiler directive may include "#pragma omp parallel” indicating a multicore CPU, "#pragma omp simd” indicating a SIMD, or "#pragma omp target" indicating a GPU.
  • the compiler module of the present disclosure receives source code 102 or directives written in a language such as C or C ++, the application developer may use a language or API for a specific computing device (that is, the developer is a language specific to the computing device). I do not need to write the source code).
  • the compiler module 100 may include a front end module 104.
  • the front end module 104 changes the input source code 102 or directive into code that the compiler module 100 can understand, that is, intermediate code.
  • the intermediate code may be referred to as an intermediate representation (IR).
  • the compiler module 100 may include an analyzer 106.
  • the analysis unit 106 may analyze the source code, collect information of the code, and generate one or more code sections 107 that may be executed in a separate computing device from the source code. Code sections that can be executed on separate computing devices are, for example, code sections that have no dependencies (dependencies) with other code sections.
  • the compiler module 100 may use the information of the collected code to optimally generate executable code for each computing device.
  • the analysis unit 106 may analyze the dependency relationship using a pointer used in C / C ++ source code.
  • the compiler module 100 may analyze data dependencies when an application operates using the analysis result of the pointer, and generate optimized execution code by identifying the dependence of the data.
  • the pointer is also called aliasing.
  • the analysis unit 106 may analyze the source code and create a constraint graph having N nodes using variables and pointers used in the source code.
  • N nodes in which the constraint graph is prepared may have the constraint types illustrated in Table 1.
  • A * b 'means' load' to assign pointer b to the value of a
  • the analysis unit 106 requires a calculation amount corresponding to about O (N 3 ) to analyze the dependency relationship on the N nodes.
  • the analysis unit 106 may be divided into off-line analysis and on-line analysis when analyzing the dependency relationship between the pointers.
  • the offline analysis is an analysis process for generating the constraint graph from the source code
  • the online analysis is an analysis process for identifying the actual correlation from the generated constraint graph, and for example, Anderson's analysis technique may be applied.
  • the analysis unit 106 determines whether two nodes are in a 'cycle relationship' with each other during offline analysis, and treats and analyzes two nodes corresponding to the 'cycle node' as one node.
  • a cycle node is a node in which two nodes are connected to each other in a chain-like form and have no dependency (ie, in a 'cycle relationship') with nodes other than the two nodes.
  • the analysis unit 106 may determine not only the cycle node but also the nodes satisfying the following example conditions as 'nodes without dependency' and merged into one node.
  • the first condition is that node a does not have a predecessor added during online analysis.
  • the top-level pointer variable of the LLVM IR may be a node where no predecessor is added to the on-line analysis.
  • the second condition is that node a is the only one in the constraint graph generated during the off-line analysis. Has a predecessor node b.
  • the third condition is that all point-to sets of node a come from the predecessor node b only. Node a that satisfies the above three conditions may be treated as one node with predecessor node b.
  • the analysis unit 106 may reduce the amount of calculation required for code analysis to about O (N) by merging nodes constituting the code using dependencies in the code analysis.
  • FIG. 2 illustrates a constraint graph, source code, and IR that describe the conditions of nodes that the compiler module according to the present disclosure treats as one node.
  • FIG. 200 An example of an offline constraint graph 200, a code 202 written in C language, and an IR 204 of nodes a and b that satisfy the three conditions are shown in FIG.
  • the compiler module 100 may include a feature extractor 108.
  • the feature extractor 108 determines whether each code section is operable in a specific computing device by using the result analyzed by the analysis unit 106, and the code to be used when the code section is operated with respect to the operable code section. Extract the information.
  • An example of code information extracted by the feature extractor 108 is as follows.
  • the feature extractor 108 selects a section of code operable on a specific computing device based on the input directive (ie, a guide). You can also judge.
  • the compiler module 100 may include a transformation module 110.
  • the conversion unit 110 may be called a parallelization module because it may generate a plurality of codes that enable parallel operations by a plurality of computing devices.
  • the converting unit 110 converts the input source section into a source code suitable for each computing device by using the result analyzed by the analyzing unit 106 or the information extracted by the feature extracting unit 108. . That is, the conversion unit 110 may determine how to convert the code using the analysis result or the extracted information, and convert the source section in consideration of the characteristics of each computing device.
  • 1 is an example of a source code suitable for a computing device, which is a single core source code 112 (Serial), a SIMD source code 114 (SI), and a multi core (classical) source code 116 (M (C)). ), Source code 118 (M (P)) for multicore (polyhydral), source code 120 (CL) for GPU, and source code 122 (M + SI) for multicore + SIMD.
  • loop tiling refers to partitioning a loop operation into at least one unit block (ie, a tile).
  • the conversion unit 110 may determine the size of the tile in consideration of the cache size of the compiler. By doing so, the effect of tiling according to the cache size can be verified in advance, and the rate of cache misses can be reduced.
  • Unrolling is the unrolling of a loop operation that includes a conditional statement (such as an if statement) into a series of instructions without a conditional statement.
  • Unrolling is performed because the computing device does not include a loop operation than it does a loop operation, but it may be more efficient to perform relatively long instructions.
  • Interleaving refers to changing (or distorting) the operation structure of the loop operation by changing the position of an argument included in the loop operation.
  • the source code converted by the converter 110 may include a data structure having 'code characteristics'.
  • the converted source code may be referred to as 'annotated code'.
  • the compiler module 100 constructs a data structure corresponding to the code characteristic and inserts the data structure into the source code. So that it can operate correctly when actually operating.
  • the conversion unit 110 uses the compiler runtime API of the runtime module 150 to enable all of the converted source codes to be operated by the control of the runtime module regardless of the type of the computing device.
  • the compiler module 100 may include a back end module 130.
  • the backend module 130 compiles at least one source code 112, 114, 116, 118, 120, 122 suitable for each computing device to generate at least one executable code (ie, binary) 132, 134, 136. , 138, 140).
  • the runtime module 150 corresponding to the runtime SW portion may execute an application by driving at least one executable code (ie, binary) 132, 134, 136, 138, and 140 in a corresponding computing device.
  • executable code ie, binary
  • the runtime module 150 may include a scheduler 152.
  • the scheduler 152 may monitor the device monitor 154 with system software to check the state of each computing device (eg, utilization, frequency, etc.) before executing the execution code of the computing device. It is used as a service form of SW, and the state information of the computing device can communicate with the compiler runtime module 156 through IPC (inter procedure communication). Examples of the state information of the computing device delivered through the apparatus monitor 154 are shown in the following table.
  • the scheduler 152 collects static information and dynamic information to effectively utilize each computing device, and selects a combination of computing resources (ie, computing devices) to be performed based on the collected information. You can decide.
  • the scheduler 152 determines an efficient workload value to be assigned to the determined combination of computing device (s) and drives executable code at the computing device (s) in accordance with the determined workload.
  • the static information and the dynamic information may be divided into SW information related to the HW information and the source code according to the characteristics.
  • the scheduler 152 may obtain static information related to the source code through the feature extractor 108 of the compiler module 100, and receive static information related to the environment (ie, HW) in advance.
  • the dynamic information is parameters determined when the code is executed.
  • the dynamic information may be utilization rate and operating frequency information for each computing device that the scheduler 152 obtains through the device monitor 154.
  • the scheduler 152 may extract information about the computing characteristic of each computing device and use the same to determine a computing device to perform the extracted information.
  • Information on arithmetic characteristics of each arithmetic device may be configured in the form of the following table using an HW specification or a benchmark for each operation.
  • the total calculation time ie, CPU Total , GPGPU Total , DSP total , ACC Total
  • the operation time may include an integer operation time and a vector operation time.
  • the memory delay time may include a memory read / write delay time and a vector load / store delay time.
  • the data copy overhead may include, for example, the time required for data transfer.
  • time at which the workload is performed in a specific computing device ie, device N
  • device N the time at which the workload is performed in a specific computing device
  • T total (device N ) represents the total computation time of device N
  • T op represents the computation time
  • T vec _op represents the vector computation time
  • T mem _ lat represents the memory latency
  • T vec _ld_st_ lat is the vector load / store delay time
  • T is the branch br operation processing time
  • T data_tr shows a data transfer processing time.
  • Equation 2 When the characteristics of the calculation resources are reflected in Equation 2, they may be expressed as the following Equations.
  • Equation 3 shows the total processing time when the computing device is a single core CPU. In the case of a single core CPU, it can be regarded as 0 because only a calculation takes time and there is almost no overhead time (T data _tr ) due to data copying.
  • Equation 4 shows the total processing time when the computing device is a multi core CPU.
  • the thread count represents the number of threads of the CPU. Since multi-core CPUs create two or more threads and process them in parallel through the created threads, computation time (and branch processing time) is reduced in proportion to the number of threads. However, in a multi-core CPU, the memory accesses of the threads occur at the same time so that the memory latency does not increase.
  • Equation 5 shows the total processing time when the computing device is a SIMD.
  • performance may vary depending on the size of the vector and the size of the data type, and data copy time is rarely required.
  • Equation 6 shows the total processing time when the computing device is an accelerator (accelerator) such as GPGPU or DSP.
  • accelerators such as GPUs or DSPs
  • there is data copy time for accelerators such as GPUs or DSPs
  • the data copy time T data_tr may be zero.
  • the scheduler 152 calculates processing time for other computing devices in the same manner as described above, so that T total (device 1 ), T total (device 2 ), T total (device 3 ),. , T total (device N ) values may be obtained in order, and the obtained processing times may be prioritized by ascending order of performance (ie, processing time size). (For example, T total (device 1 ) ⁇ T total (device 3 ) ⁇ T total (device 2 ))
  • the scheduler 152 may select the top N devices corresponding to the determined priority in consideration of a user's input or preset, and apply the load distribution optimization process to the selected N devices. .
  • N may have a value of two.
  • the scheduler 152 may use real-time available information (ie, dynamic information) for performance prediction.
  • the performance (ie, processing time) of Equations 1 to 6 is calculated based on when the corresponding computing device is 100% usable. However, the computing device is not always 100% available. Accordingly, the scheduler 152 may accurately predict performance by reflecting dynamic information such as utilization information or frequency information of each computing device.
  • the execution speed of the application will be determined by the computing device that takes the longest among the computing devices to which the workload is assigned.
  • Application processing time determined by using the processing time of the longest computing device T workload Can be expressed as the following equation.
  • the scheduler 152 may achieve load balancing optimization for each computing device by determining a sharing ratio ⁇ for minimizing Equation 7 in consideration of real-time available information (that is, utilization rate) for each computing device.
  • the optimal share ratio ⁇ can be determined by the following equation.
  • the runtime module 150 may include a compiler runtime module 156.
  • the compiler runtime module 156 provides a compiler runtime library.
  • the compiler runtime library works closely with compiler module 100 to enable the scheduler to run the executable code (ie, binary) 132, 134, 136, 138, 140 of the application.
  • the runtime module 150 may further include an additional API module 158 of an operating system (OS) level or an OpenCL driver module 160 for driving a GPU.
  • OS operating system
  • OpenCL driver module 160 for driving a GPU.
  • FIG. 3 is a diagram schematically illustrating an operation of a runtime module according to the present disclosure.
  • the runtime module (in particular, the scheduler) may receive static information corresponding to the execution code from the analysis unit of the compiler, and receive dynamic information from the device monitor (300).
  • the runtime module may perform an operation of selecting an arithmetic device to perform an application (302).
  • the runtime module may calculate performance (eg, processing time) for each computing device.
  • the runtime module may sort the calculated performance for each computing device in ascending order.
  • the runtime module may select N computing devices having a high priority as a performing device in consideration of a user's selection.
  • the runtime module may perform a scheduling operation 304 to determine the workload of the selected computing device. For example, the runtime module may determine an application processing time T workload using utilization or frequency information. The runtime module may determine workloads ⁇ 1 , ⁇ 2 , ⁇ 3 ,... That minimize the T workload .
  • the runtime module applies the determined workload ⁇ to each computing device to drive application execution code (606).
  • FIG. 4 is a diagram illustrating the effects of determining a computing device to operate according to the present disclosure and determining a workload in terms of resource utilization and usage energy.
  • FIGS. 4 (a) and 4 (b) show the results when the selection of the runtime module and the workload determination operation are not applied
  • FIGS. 4 (c) and 4 (d) show the selection and workload of the runtime module. The result when the decision operation is applied is shown.
  • FIG. 4C when there is an application of the runtime module of the present disclosure, as shown in FIG. 4C, it is found that the utilization rates of the GPU 410 and the multicore CPU 412 approach a value of 0 before the end of the measurement time period. Can be. That is, in FIG. 4C, it can be seen that the operation time of the computing device is reduced by half compared to FIG. 4A. This means a 2x improvement in operating speed. In addition, it can be seen that the energy consumption 412 of FIG. 4 (d) decreases rapidly compared to the energy consumption of FIG. 4 (b).
  • the application of the runtime module according to the present disclosure has the effect of improving the operation speed of the application and reducing the energy consumption (power consumption).
  • 5 is a table comparing processing time for each computing device according to an input size of a cache when applying the technique according to the present disclosure.
  • the runtime module may select a computing device.
  • FIG. 6 is a diagram illustrating the performance (processing time) according to the load sharing ratio when using the CPU and GPU in applying the technique according to the present disclosure.
  • the CPU and GPU exhibit a minimum processing time when the load is shared at a ratio of about 63:37.
  • FIG. 7 is a diagram illustrating energy consumption according to a workload when using a CPU and GPU in applying the technique according to the present disclosure.
  • FIG. 8 is a diagram illustrating performance (processing time) in workload and utilization when using a CPU and GPU in applying the technique according to the present disclosure.
  • FIG. 9 is a diagram schematically illustrating an operation of a compiler module according to the present disclosure.
  • An operation described in FIG. 9 may be performed before an operation of the runtime module described in FIG. 3, and may be the same device (eg, a terminal device) or a separate device (eg, a server) as the runtime module. , A desktop module, etc.).
  • the compiler module changes the application source code into intermediate code (ie, IR) that the compiler can understand (900).
  • the compiler module analyzes the dependencies included in the IR and generates (905) a section of code from the IR that can be executed at each computing device.
  • the compiler module translates the code section into source code specific to the computing device (910).
  • the compiler module may further perform an operation of extracting code information from the code section.
  • the converted source code may include a code characteristic to be used by the runtime module to execute the executable code in the form of a data structure.
  • the compiler module may compile the converted source code to generate executable code suitable for each computing device (915).
  • the compiler module provides the generated executable code to a runtime module, allowing the runtime module to execute the executable code on each computing device.
  • Table 7 shows the analysis performance of the compiler analysis unit according to the present disclosure.
  • the analysis time is reduced from 40.1 seconds to 4.7 seconds in the existing analysis method, and the number of analysis nodes is reduced from 79,001 to 36,479 in the existing analysis method. have.
  • the accumulated weighted algorithm was used for testing.
  • FIGS. 1 to 9 are not intended to limit the scope of the present disclosure. That is, all of the components, or steps of the operations described in FIGS. 1 to 9 should not be interpreted as essential components for the implementation of the present disclosure, and a range that does not impair the essence of the present disclosure even if only some of the components are included. It can be implemented within.
  • the above-described operations can be realized by providing a memory device storing the corresponding program code to an entity, a function, a base station, or any component in the terminal device of the communication system. That is, the controller of the entity, the function, the base station, or the terminal device can execute the above-described operations by reading and executing the program code stored in the memory device by the processor or the CPU.
  • the various components, modules, etc. of an entity, function, base station, or terminal device described herein may be a hardware circuit, for example, a complementary metal oxide semiconductor based logic circuit. And hardware circuitry such as firmware and a combination of software and / or hardware and software embedded in firmware and / or machine readable media.
  • various electrical structures and methods may be implemented using transistors, logic gates, and electrical circuits such as application specific semiconductors.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

본 개시는 단말 장치에서 적어도 하나의 연산 디바이스를 이용하여 어플리케이션을 수행하는 방법에 있어서, 상기 적어도 하나의 연산 디바이스의 처리 시간을 계산하는 동작; 사용자의 선호도 또는 상기 계산된 적어도 하나의 처리 시간에 근거하여 상기 어플리케이션을 수행할 소정 개수의 연산 디바이스를 선택하는 동작; 상기 결정된 소정 개수의 연산 디바이스에 상응하는 사용률을 이용하여 결정되는 처리시간 함수를 최소화하는 워크로드를 결정하는 동작; 및 상기 소정 개수의 연산 디바이스에 상기 결정된 워크로드를 적용하여 상기 어플리케이션을 실행하는 동작을 포함하는 방법을 제공한다.

Description

사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법
본 개시는 다양한 연산 디바이스를 사용하는 단말에서 어플리케이션을 효율적으로 실행시키기 위한 컴파일러 모듈 및 런타임 모듈에 관련된 것이다.
사용자 어플리케이션을 단말과 같은 장치에서 동작시키기 위해서는 프로그램 언어로 작성되는 어플리케이션의 코드를 컴파일하는 과정 및 컴파일된 바이너리(즉, 실행 코드)를 실행하는 과정 등이 필요하다.
단말 내에는 바이너리를 실행하는 다양한 연산 디바이스(processing device)(즉, HW 모듈)를 포함할 수 있는데. 이러한 연산 디바이스의 대표적인 예는 CPU(central processing unit)이다. 상기 단말에는 상기 CPU 외에도, SIMD(single instruction multiple data), Parallel-SIMD, GPU(graphic processing unit), GPGPU(general purpose GPU), 또는 DSP(digital signal processor) 등이 포함될 수 있다.
아직까지, 단말 내 다양한 연산 디바이스들을 효과적으로 활용하기 위한 시도는 어플리케이션 개발자에 의해서만 수행되고 있다. 단말 내 연산 디바이스들에서 동작하는 어플리케이션은 HW(hardware) 특정적인(즉, 연산 디바이스에 특정적인) API(application programmable interface) (예를 들어, GPU의 경우 OpenCL)를 이용하여 개발된다. 즉, 상기 연산 디바이스를 위한 어플리케이션은 일반적으로 많이 사용되는 프로그램 언어 (C/C++, Java 등)와는 다른 언어를 통해 개발된다. 상기 HW 특정적인 API는 해당 어플리케이션이 해당 연산 디바이스에서 동작할 수 있도록 해주는 툴(Tool)의 역할은 충실히 수행하지만, 연산 디바이스들을 동시에 효율적으로 활용하는 것은 오로지 어플리케이션 개발자의 수작업에 의해 구현되고 있는 것이 현실이다.
따라서, 개발된 어플리케이션은 개발자에 의해 정해진 지시(즉, 스케줄링)에 따라서만 동작하게 된다. 다시 말해, 어플리케이션 개발자가 어플리케이션의 특정 코드를 특정 연산 디바이스에 동작 시키기 위해서는 상기 연산 디바이스를 위한 언어(또는 API)로 해당하는 코드를 작성해야 한다. 또한, 상기 개발자는 연산 디바이스들간의 동기화도 고려해야만 하는 상황을 직면한다.
어플리케이션의 특성은 어플리케이션 개발자에 전적으로 의존할 수 밖에 없다. 또한, 개발자의 구현 방식에 따라 달라지는 어플리케이션의 특성, 실제 어플리케이션이 장치 내에서 동작할 때의 연산 디바이스의 자원 활용 상태, 또는 어플리케이션이 계산해야 하는 데이터 크기 등은 개발자가 코드 작성시에는 쉽게 알 수 없다. 따라서, 어플리케이션이 단말 내 연산 디바이스를 효과적으로 활용하는 데는 한계가 있다.
본 개시는 어플리케이션의 특성과 어플리케이션 동작시의 단말 내 연산 디바이스의 상태 정보(예를 들어, 가용율, 동작 주파수) 등을 동적으로 이용함으로써, 어플리케이션이 단말 내 연산 디바이스(들)를 효율적으로 활용하게 하는 방법 및 장치를 제공한다.
또한 본 개시는, 각 연산 디바이스에서 수행 가능한 어플리케이션의 코드 부분을 분석하는 방법 및 장치를 제안하고, 상기 분석 작업의 복잡도를 감소시키는 방법 및 장치를 제공한다.
단말 장치에서 적어도 하나의 연산 디바이스를 이용하여 어플리케이션을 수행하는 방법에 있어서, 상기 적어도 하나의 연산 디바이스의 처리 시간을 계산하는 동작; 사용자의 선호도 또는 상기 계산된 적어도 하나의 처리 시간에 근거하여 상기 어플리케이션을 수행할 소정 개수의 연산 디바이스를 선택하는 동작; 상기 결정된 소정 개수의 연산 디바이스에 상응하는 사용률을 이용하여 결정되는 처리시간 함수를 최소화하는 워크로드를 결정하는 동작; 및 상기 소정 개수의 연산 디바이스에 상기 결정된 워크로드를 적용하여 상기 어플리케이션을 실행하는 동작을 포함하는 방법을 제안한다.
또한 본 개시는 적어도 하나의 연산 디바이스를 이용하여 어플리케이션을 수행하도록 구성된 런타임 모듈을 구비하는 단말 장치에 있어서, 상기 런타임 모듈은: 상기 적어도 하나의 연산 디바이스의 처리 시간을 계산하고, 사용자의 선호도 또는 상기 계산된 적어도 하나의 처리 시간에 근거하여 상기 어플리케이션을 수행할 소정 개수의 연산 디바이스를 결정하고, 상기 결정된 소정 개수의 연산 디바이스에 상응하는 사용률을 이용하여 결정되는 처리시간 함수를 최소화하는 워크로드를 결정하고, 상기 소정 개수의 연산 디바이스에 상기 결정된 워크로드를 적용하여 상기 어플리케이션을 수행하는 스케줄러; 및 상기 사용률 정보를 산출하는 장치 모니터를 포함하는 단말 장치를 제안한다.
본 개시에 따른 장치는 각각의 연산 디바이스를 효과적으로 사용하게 됨으로써, 어플리케이션 동작 속도를 가속하고, 소비 전력을 감소시킬 수 있다.
본 개시에 따른 장치는 컴파일러의 소스 코드 의존 관계 (예, 포인터) 분석 속도를 향상시킬 수 있다.
도 1은 본 개시에 따른 어플리케이션 실행 디바이스의 구성을 예시하는 도면;
도 2는 본 개시에 따른 컴파일러 모듈이 하나의 노드로 취급하는 노드 들의 조건을 설명하는 제약 그래프, 소스 코드 및 IR을 예시하는 도면;
도 3은 본 개시에 따른 런타임 모듈의 동작을 개략적으로 설명하는 도면;
도 4는 본 개시에 따라서 동작할 연산 디바이스를 결정하고 워크로드를 결정한 경우의 효과를 자원 사용률 및 사용 에너지 관점에서 예시하는 도면;
도 5는 본 개시에 따른 기법을 적용함에 있어서, 캐쉬의 입력 크기에 따른 연산 디바이스 별 처리 시간을 비교하는 표;
도 6은 본 개시에 따른 기법을 적용함에 있어서, CPU 및 GPU를 이용하는 경우의 부하 분담율에 따른 성능(처리 시간)을 예시하는 도면;
도 7은 본 개시에 따른 기법을 적용함에 있어서, CPU 및 GPU를 이용하는 경우의 워크로드에 따른 에너지 소비량을 예시하는 도면;
도 8은 본 개시에 따른 기법을 적용함에 있어서, CPU 및 GPU를 이용하는 경우에 워크로드와 사용률에 성능(처리시간)을 예시하는 도면;
도 9는 본 개시에 따른 컴파일러 모듈의 동작을 개략적으로 설명하는 도면이다.
이하, 첨부된 도면들을 참조하여 본 개시의 실시예를 상세하게 설명한다. 하기에서 본 개시를 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로써 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
본 개시의 자세한 설명에 앞서, 본 명세서에서 사용되는 몇 가지 용어들에 대해 해석 가능한 의미의 예를 제시한다. 하지만, 아래 제시하는 해석 예로 한정되는 것은 아님을 주의하여야 한다.
기지국(Base Station)은 단말과 통신하는 일 주체로서, BS, NodeB(NB), eNodB(eNB), AP(Access Point) 등으로 지칭될 수도 있다.
단말(User Equipment)은 기지국과 통신하는 일 주체로서, UE, 이동국(Mobile Station; MS), 이동장비(Mobile Equipment; ME), 디바이스(device), 터미널(terminal) 등으로 지칭될 수도 있다. 본 개시에서는 하나 이상의 연산 디바이스를 구비하는 장치를 단말 장치로 설명할 것이다.
본 개시는 어플리케이션의 소프트웨어(software; SW) 측면의 연산 특성에 따라 단말의 가용 자원(연산 디바이스들)을 최대한 활용하기 위해, 해당 어플리케이션의 연산을 연산 디바이스(들)에 동적으로 분배하여 어플리케이션의 동작 성능을 향상시키는 기법을 제안하고자 한다.
이를 위해 본 개시는, 소프트웨어를 각기 다른 연산 디바이스에서 수행할 수 있게 실행 코드를 생성 할 수 있도록 하는 컴파일러 부분과, 실제 실행 코드를 연산 특성 및 장치의 상태를 고려하여 동작 할 수 있도록 하는 런타임 SW(software) 부분을 설명한다.
디바이스 관점에서, 상기 컴파일러 부분은 예를 들어 컴파일러 모듈로 구현될 수 있고, 상기 런타임 SW 부분은 예를 들어 런타임 모듈로 구현될 수 있다. 상기 컴파일러 모듈과 런타임 모듈은 사용자 단말과 같은 하나의 디바이스에 포함될 수도 있고, 별도의 디바이스에 포함될 수도 있다. 예를 들어, 컴파일러 모듈은 단말과 같은 HW에서 구현될(탑재될) 수 있지만, 데스크탑 또는 서버와 같은 HW에 구현될 수도 있다. 또한, 상기 런타임 모듈은 어플리케이션을 구동하고자 하는 단말과 같은 HW에서 구현될(탑재될) 수 있다. 데스크탑 또는 서버와 같은 디바이스의 컴파일 모듈에서 컴파일된 코드는 런타임 모듈을 포함하는 단말에게 임포팅(importing)되고, 상기 컴파일된 코드는 상기 런타임 모듈의 제어 또는 스케줄링에 의해 실행될 수 있다. 이하에서는, 단말과 같은 하나의 디바이스에서 컴파일러 모듈과 런타임 모듈이 구현되는 경우를 예시할 것이나, 본 개시의 권리범위는 이에 한정되는 것은 아니고, 별개의 디바이스에서 각각 구현되는 경우도 포함한다.
도 1은 본 개시에 따른 어플리케이션 실행 디바이스의 구성을 예시하는 도면이다.
본 개시에 따른 어플리케이션 실행 디바이스는 두 가지 모듈 즉, 컴파일러 모듈(100) 및 런타임 모듈(150) 중 적어도 하나를 포함할 수 있다. 상기 컴파일러 모듈(100) 및 런타임 모듈(150)은 제어부(controller)와 같은 하나의 모듈로 구현될 수 있다.
상기 컴파일러 모듈은 예를 들어, LLVM(http://llvm.org/)과 같은 컴파일러 기반구조(infrastructure)를 가질 수 있다. 상기 컴파일러 모듈(100)은 C 또는 C++과 같은 언어로 작성된 어플리케이션 소스 코드(102) 또는 컴파일러 지시어를 입력받는다. 상기 C/C++ 컴파일러 지시어의 예로는, 멀티코어 CPU를 지시하는 "#pragma omp parallel", SIMD를 지시하는 "#pragma omp simd" 또는 GPU를 지시하는 "#pragma omp target" 등이 있을 수 있다.
본 개시의 컴파일러 모듈은 C 또는 C++과 같은 언어로 작성된 소스 코드(102)나 지시어를 입력 받으므로, 어플리케이션 개발자는 특정 연산 디바이스만을 위한 언어나 API로 (즉, 개발자는 상기 연산 디바이스에 특정적인 언어나 API) 소스 코드를 작성할 필요가 없다.
상기 컴파일러 모듈(100)은 프론트엔드 모듈(104)을 포함할 수 있다. 상기 프론트엔드 모듈(104)은 상기 입력된 소스 코드(102) 또는 지시어를 상기 컴파일러 모듈(100)이 이해할 수 있는 코드 즉, 중간 코드(intermediate code)로 변경한다. 상기 중간 코드는 중간 표현(IR; intermediate representation)이라 호칭될 수 있다.
상기 컴파일러 모듈(100)는 분석부(analyzer)(106)를 포함할 수 있다. 상기 분석부(106)는 상기 소스 코드를 분석하여 코드의 정보를 수집하고, 상기 소스 코드로부터 별개의 연산 디바이스에서 실행될 수 있는 하나 이상의 코드 섹션(section)(107)을 생성할 수 있다. 별개의 연산 디바이스에서 실행될 수 있는 코드 섹션이란 예를 들어, 타 코드 섹션과 의존성(종속성)이 없는 코드 섹션이다. 상기 컴파일러 모듈(100)은 각 연산 디바이스용 실행 코드를 최적으로 생성하는데 있어서 상기 수집된 코드의 정보를 사용할 수 있다.
특히, 상기 분석부(106)는 C/C++ 소스 코드에서 사용되고 있는 포인터(pointer)를 이용하여 의존 관계를 분석할 수 있다. 상기 컴파일러 모듈(100)은 상기 포인터의 분석 결과를 이용하여 어플리케이션이 동작할 때 데이터 의존성을 분석할 수 있고, 상기 데이터의 의존성을 파악함으로써 최적화된 실행 코드를 생성할 수 있다. 여기서, 상기 포인터는 알리아싱(aliasing)이라고 불리기도 한다.
한편, 상기 포인터의 분석은 데이터 의존성을 분석하는 작업이므로 전체 컴파일 시간에 많은 영향을 준다. 상기 분석부(106)의 예시적 분석 과정이 설명된다.
상기 분석부(106)는 소스 코드를 분석하고 상기 소스 코드에서 사용되는 변수 및 포인터 등을 이용하여 N개의 노드(node)를 갖는 제약 그래프(Constraint Graph)를 작성할 수 있다. 이때 상기 제약 그래프가 작성되는 N개의 노드는 표 1에서 예시되는 제약 유형을 가질 수 있다.
Figure PCTKR2016009502-appb-T000001
여기서, "a = &b"는 변수 b의 '주소(address)'를 a 의 값으로 할당하는 것을 의미하고, "a = b"는 변수 b의 값을 a의 값으로 할당하는 '카피(copy)'를 의미하고, "a = *b"는 a 의 값으로 포인터 b를 할당하는 '로드(load)'를 의미하고, "*a = b"는 포인터 a에게 b의 값을 할당하는 '저장(store)'을 의미한다.
상기 분석부(106)가 N개의 노드에 대한 의존 관계를 분석하는 데는 약 O(N3)에 해당하는 계산량이 요구된다. 계산량을 줄이기 위해, 본 개시에 따른 상기 분석부(106)는 포인터들 사이의 의존 관계를 분석할 때 오프라인(Off-line) 분석과 온라인(On-line) 분석으로 구분하여 분석할 수 있다. 오프라인 분석이란 소스 코드로부터 상기 제약 그래프를 생성하는 분석 과정이고, 온라인 분석은 상기 생성된 제약 그래프로부터 실제 연관성을 파악하는 분석 과정으로써 예를 들어 앤더슨 분석(Andersen's analysis) 기법이 적용될 수 있다.
구체적으로, 상기 분석부(106)는 오프라인 분석 시에 2 개의 노드들이 서로 '사이클(cycle) 관계'에 있는지 파악하여, '사이클 노드'에 해당하는 2 개의 노드를 하나의 노드로 취급하고 분석할 수 있다. 여기서, 사이클 노드란 2 개의 노드가 체인과 같은 형태로 서로 연결되어 있어서, 상기 2 개의 노드 이외의 노드와는 의존성이 없는 (즉, '사이클 관계'의) 노드이다.
또한, 상기 분석부(106)는 상기 사이클 노드 뿐만 아니라 다음의 예시적 조건이 만족하는 노드를 '의존성 없는 노드'로 판단하여 하나의 노드로 병합할 수 있다. 첫째 조건은, 상기 노드 a는 온라인 분석(online analysis) 시 선행자(predecessor)가 추가되지 않는 것이다. (예를 들어, LLVM IR의 탑 레벨 포인터 변수는 온라인 분석 시 선행자가 추가되지 않는 노드일 수 있다.) 둘째 조건은, 상기 노드 a는 오프라인 분석 시 생성된 제약 그래프(constraint graph)에서 단 하나의 선행자 노드 b를 갖는 것이다. 셋째 조건은, 상기 노드 a의 모든 포인터(point-to set)는 상기 선행자 노드 b로부터(만) 오는 것이다. 위 3가지 조건들을 만족하는 노드 a는 선행자(predecessor) 노드 b와 하나의 노드로 취급될 수 있다.
이와 같이 상기 분석부(106)는 코드 분석 시에 의존성을 이용하여 코드를 구성하는 노드들을 병합함으로써, 코드 분석에 요구되는 계산량을 약 O(N)으로 줄일 수 있다.
도 2는 본 개시에 따른 컴파일러 모듈이 하나의 노드로 취급하는 노드 들의 조건을 설명하는 제약 그래프, 소스 코드 및 IR을 예시한다.
상기 3 개의 조건을 만족하는 노드 a와 노드 b의 오프라인 제약 그래프(offline constraint graph)(200), C 언어로 작성된 코드(202) 및 IR(204)의 예제가 도 2에서 도시된다.
상기 컴파일러 모듈(100)은 특징 추출부(feature extractor)(108)를 포함할 수 있다. 상기 특징 추출부(108)는 상기 분석부(106)에서 분석한 결과를 이용하여 각각의 코드 섹션이 특정 연산 디바이스에서 동작 가능한지 판단하며, 동작 가능한 코드 섹션에 대해 상기 코드 섹션이 동작할 때 사용될 코드 정보를 추출한다. 상기 특징 추출부(108)가 추출하는 코드 정보의 예는 아래와 같다.
Figure PCTKR2016009502-appb-T000002
개발자에 의해 지정된 컴파일러의 지시어가 상기 소스 코드와 함께 입력되었을 경우라면, 상기 특징 추출부(108)는 상기 입력된 지시어 (즉, 가이드(guide))에 근거하여 특정 연산 디바이스에서 동작 가능한 코드 섹션을 판단할 수도 있다.
상기 컴파일러 모듈(100)은 변환부(transformation module)(110)를 포함할 수 있다. 상기 변환부(110)는 다수의 연산 디바이스에 의한 병렬 작업을 가능하게 하는 다수의 코드를 생성할 수 있으므로 병렬화부(parallelization module)로 호칭되기도 한다.
상기 변환부(110)는, 상기 분석부(106)에서 분석한 결과 또는 상기 특징 추출부(108)에서 추출한 정보를 이용하여, 상기 입력된 소스 섹션을 각각의 연산 디바이스에 적합한 소스 코드로 변환한다. 즉, 상기 변환부(110)는 상기 분석 결과 또는 추출한 정보를 이용하여 어떻게 코드를 변환할지를 결정하고, 각 연산 디바이스의 특성을 고려하여 소스 섹션을 변환할 수 있다. 도 1은, 연산 디바이스에 맞는 소스 코드의 예로써, 싱글 코어용 소스 코드(112; Serial), SIMD용 소스 코드(114; SI), 멀티 코어(classical)용 소스 코드(116; M(C)), 멀티코어(폴리히드럴)용 소스코드(118; M(P)), GPU용 소스 코드(120; CL) 및 멀티코어+SIMD용 소스 코드(122; M+SI)를 도시하고 있다.
구체적으로, 상기 변환부(110)는 상기 소스 섹션을 변환할 때, 상기 분석 결과(즉, 추출한 코드 정보)를 이용하여 루프 타일링(loop tiling), 언롤링(unrolling) 또는 인터리빙(inter-leaving)(즉, skewing) 과 같은 코드 변환 기법 중 적어도 하나를 적용할 수 있다. 루프 타일링이란, 루프 연산을 적어도 하나의 단위 블록(즉, 타일)으로 부분화(partitioning)하는 것을 말한다. 상기 변환부(110)은 상기 컴파일러의 캐쉬(cache) 크기를 고려하여 타일(tile)의 크기를 결정할 수 있다. 이렇게 함으로써, 캐쉬 크기에 따른 타일링의 효과를 미리 검증할 수 있고, 캐쉬 손실(cache miss)의 비율을 줄일 수 있다. 언롤링은 조건문(예를 들어, if 문)이 포함되는 루프 연산을 조건문이 없도록 일련의 명령어들로 풀어서 쓰는 것을 말한다. 언롤링은 연산 디바이스가 루프 연산을 수행하는 것보다 루프 연산을 포함하지 않지만 상대적으로 긴 명령어들을 수행하는 것이 더 효율적일 수 있기에 수행된다. 인터리빙은 루프 연산에 포함되는 인자(argument)의 위치를 변경하는 등으로 루프 연산의 연산 구조를 변경(또는 왜곡)하는 것을 말한다.
상기 변환부(110)에 의해 변환된 소스 코드는 '코드 특성'을 갖는 데이터 구조를 포함할 수 있다. 따라서, 상기 변환된 소스 코드는 '주석달린 코드(annotated code)'라고 호칭될 수도 있다. 런타임 모듈(150)이 어플리케이션의 동작 시 적절한 소스 코드를 사용할 수 있도록 하기 위해, 상기 컴파일러 모듈(100)은 상기 코드 특성에 해당하는 데이터 구조(structure)를 구성하고 상기 데이터 구조를 상기 소스 코드에 삽입하여 실제로 동작 시 정확하게 동작할 수 있게 한다. 이때, 상기 변환부(110)는 런타임 모듈(150)의 컴파일러 런타임 API를 사용함으로써, 모든 변환된 소스 코드가 연산 디바이스의 종류에 관계 없이 상기 런타임 모듈의 제어에 의해 동작할 수 있게 한다.
코드 특성의 데이터 구조의 예는 다음 표와 같다.
Figure PCTKR2016009502-appb-T000003
상기 컴파일러 모듈(100)은 백엔드 모듈(130)을 포함할 수 있다. 상기 백엔드 모듈(130)은 각각의 연산 디바이스에 적합한 적어도 하나의 소스 코드(112, 114, 116, 118, 120, 122)를 컴파일하여 적어도 하나의 실행 코드(즉, 바이너리)(132, 134, 136, 138, 140)을 생성할 수 있다.
이어서, 단말의 런타임 SW 부분에 대해 설명한다.
런타임 SW 부분에 해당하는 런타임 모듈(150)은 적어도 하나의 실행 코드(즉, 바이너리)(132, 134, 136, 138, 140)을 상응하는 연산 디바이스에서 구동시킴으로써 어플리케이션을 실행시킬 수 있다.
상기 런타임 모듈(150)은 스케줄러(152)를 포함할 수 있다. 상기 스케줄러(152)는 상기 연산 디바이스의 실행 코드의 실행 전에 각 연산 디바이스의 상태(예를 들어, 사용률(utilization), 주파수(frequency) 등)를 확인하기 위해 장치 모니터(154)를 시스템 소프트웨어(system SW)의 서비스 형태로 이용하며, 상기 연산 디바이스의 상태 정보를 컴파일러 런타임 모듈(156)과 IPC(inter procedure communication)를 통해 통신할 수 있다. 상기 장치 모니터(154)를 통해 전달되는 연산 디바이스의 상태 정보의 예는 다음 표와 같다.
Figure PCTKR2016009502-appb-T000004
상기 스케줄러(152)는 각각의 연산 디바이스를 효과적으로 활용하기 위해 정적(static) 정보와 동적(dynamic) 정보를 수집하고, 상기 수집된 정보에 근거하여 수행시킬 연산 자원(즉, 연산 디바이스)의 조합을 결정할 수 있다. 상기 스케줄러(152)는 상기 결정된 조합의 연산 디바이스(들)에 할당될 효율적인 워크로드(workload; 작업 분담률) 값을 결정하고, 상기 결정된 워크로드에 따라서 실행 코드를 상기 연산 디바이스(들)에서 구동시킨다. 상기 정적 정보와 동적 정보는 성격에 따라서 HW 정보와 소스 코드에 관련된 SW 정보로 나뉠 수 있다.
상기 스케줄러(152)는 소스 코드와 관련된 정적 정보를 컴파일러 모듈(100)의 특징 추출부(108)를 통해 얻을 수 있고, 환경(즉, HW)에 관련된 정적 정보는 미리 입력받을 수 있다.
동적 정보는, 코드가 수행될 때 정해지는 파라미터들로써, 예로써 상기 스케줄러(152)가 장치 모니터(154)를 통해 획득하는 각 연산 디바이스 별 사용률 정보 및 동작 주파수 정보 등이 될 수 있다.
정적 정보와 동적 정보의 예는 다음 표와 같다.
Figure PCTKR2016009502-appb-T000005
명령 별 처리 시간은 연산 디바이스별로 다르기 때문에, 상기 스케줄러(152)는 각 연산 디바이스별 연산 특성에 대한 정보를 추출하고 상기 추출된 정보를 수행할 연산 디바이스 결정에 이용할 수 있다. 각 연산 디바이스별 연산 특성에 대한 정보는 HW 사양(HW spec.) 또는 각 동작 별 벤치마크(benchmark)를 이용하여 다음의 표와 같은 형태로 구성될 수 있다.
Figure PCTKR2016009502-appb-T000006
상기 스케줄러(152)는, i) 사용자 선호도 또는 ii) 성능 예측에 따라 결정되는 순위(즉, priority) 에 근거하여, 어플리케이션의 동작을 위해 워크로드를 부과할 N개의 연산 디바이스를 선택할 수 있다. (예를 들어, N= 2) 사용자 선호도를 반영할 경우 상기 스케줄러(152)는 상기 사용자에 의해 선택된 연산 디바이스를 사용할 것으로 결정할 수 있고, 성능 예측 결과를 이용하는 경우 상기 스케줄러(152)는 연산 디바이스 별 성능(performance)을 예측하고 예측 결과에 따라 사용할 연산 디바이스를 결정할 수 있다. 예를 들어, 성능 예측에 따라서 결정되는 순위는 상기 표 6에 의해 결정되는 연산 디바이스별 총 연산 시간 (즉, CPUTotal, GPGPUTotal, DSPtotal, ACCTotal)을 오름차순으로 정렬한 순서로 결정될 수 있다. 이때, 총 연산 시간이 가장 작은 연산 디바이스의 우선 순위가 가장 높다.
상기 표 6의 연산 디바이스 별 성능 예측에 사용되는 수식을 설명한다.
Figure PCTKR2016009502-appb-M000001
상기 연산 시간은 정수(integer) 연산 시간과 벡터(vector) 연산 시간을 포함할 수 있다. 상기 메모리 지연 시간은 메모리 읽기(read)/쓰기(write) 지연 시간과 벡터 로드(load)/저장(store) 지연 시간을 포함할 수 있다. 상기 데이터 카피 오버헤드는 예를 들어 데이터 전송(transfer)에 소요되는 시간을 포함할 수 있다.
구체적으로, 특정 연산 디바이스(즉, 디바이스 N)에서 워크로드가 수행되는 시간은 다음 수학식과 같이 정리될 수 있다.
Figure PCTKR2016009502-appb-M000002
여기서 Ttotal(device N)은 디바이스 N의 총 연산 시간을 나타내고, Top는 연산(명령어) 처리 시간을, Tvec _op는 벡터 연산 처리 시간을, Tmem _ lat는 메모리 지연 시간을, Tvec _ld_st_ lat는 벡터 로드/저장 지연 시간을, Tbr은 분기 연산 처리 시간을, Tdata_tr은 데이터 전송 처리 시간을 나타낸다.
상기 수학식 2에 연산 자원별 특성을 반영하면 이하의 수학식들과 같이 표현될 수 있다.
Figure PCTKR2016009502-appb-M000003
수학식 3은 연산 디바이스가 싱글(single) 코어 CPU일 경우의 총 처리시간을 나타낸다. 싱글 코어 CPU의 경우 연산에만 시간이 소요되고 데이터 카피로 인한 오버헤드 시간(Tdata _tr)은 거의 없으므로 0으로 간주할 수 있다.
Figure PCTKR2016009502-appb-M000004
수학식 4는 연산 디바이스가 멀티(multi) 코어 CPU일 경우의 총 처리시간을 나타낸다. 여기서, Threadcount는 CPU의 쓰레드 개수를 나타낸다. 멀티 코어 CPU는 2 개 이상의 쓰레드를 생성하여 생성된 쓰레드들을 통해 병렬로 연산 처리하기 때문에 연산 시간 (및 분기 처리 시간)은 쓰레드의 개수에 비례하여 줄어든다. 하지만, 멀티 코어 CPU에서 상기 쓰레드들의 메모리 접근은 동시에 일어나므로 메모리 지연 시간이 증가하지는 않는다.
Figure PCTKR2016009502-appb-M000005
수학식 5는 연산 디바이스가 SIMD일 경우의 총 처리시간을 나타낸다. SIMD의 경우 벡터의 크기와 데이터 타입 크기에 따라 성능이 다를 수 있고, 데이터 카피 시간은 거의 소요되지 않는다.
Figure PCTKR2016009502-appb-M000006
수학식 6은 연산 디바이스가 GPGPU 또는 DSP와 같은 엑셀러레이터(Accelerator; 가속기)인 경우의 총 처리 시간을 나타낸다. GPU 또는 DSP와 같은 엑셀러레이터의 경우 데이터 카피 시간이 존재한다. 그러나, CPU와 GPU가 같이 사용할 수 있는 공유 메모리(shared memory)가 지원되는 경우라면, 데이터 카피 시간(Tdata_tr)은 0이 될 수도 있다.
상기 스케줄러(152)는 위와 같은 방식으로 다른 연산 디바이스에 대해서도 처리 시간을 계산하여, N개의 연산 디바이스에 대한 Ttotal(device1), Ttotal(device2), Ttotal(device3), ... , Ttotal(deviceN) 값들을 차례대로 구하고, 상기 구해진 처리시간들을 성능(즉, 처리 시간 크기) 순서로 오름차순 정렬하여 우선 순위를 매길 수 있다. (예를 들어, Ttotal(device1) < Ttotal(device3) < Ttotal(device2))
상기 스케줄러(152)는 사용자의 입력 또는 사전 설정을 고려하여 상기 결정된 우선 순위에 해당하는 상위 N개의 디바이스를 선택하고, 상기 선택된 N개의 디바이스에 대한 부하 분산(load distribution) 최적화 과정에 적용할 수 있다. 바람직하게는, N은 2의 값을 가질 수 있다.
상기 선택된 N개의 연산 디바이스를 실시간에 효율적으로 운용하기 위해서는 정확한 성능의 예측이 필요하며, 상기 스케줄러(152)는 실시간 가용 정보(즉, 동적 정보)를 성능 예측에 이용할 수 있다. 상기 수학식 1 내지 수학식 6의 성능(즉, 처리 시간)은 해당 연산 디바이스를 100% 사용 가능했을 때를 기준으로 산정한 것이다. 그러나, 해당 연산 디바이스가 항상 100% 사용 가능하지는 않다. 따라서, 상기 스케줄러(152)는 각 연산 디바이스의 사용률(utilization) 정보 또는 주파수(frequency) 정보와 같은 동적 정보를 반영하여 보다 정확하게 성능을 예측할 수 있다.
주어진 워크로드(workload)를 분할하여 연산 디바이스들에 할당하는 경우, 워크로드가 할당된 연산 디바이스들 중 가장 오래 걸리는 연산 디바이스에 의해 어플리케이션의 수행 속도가 결정될 것이다. 가장 오래 걸리는 연산 디바이스의 처리 시간을 이용하여 결정되는 어플리케이션 처리 시간 Tworkload 은 다음 수학식과 같이 표현될 수 있다.
Figure PCTKR2016009502-appb-M000007
여기서, α 는 부하 분산에 의해 결정되는 연산 디바이스의 부하 분담율을 나타내며 α1 + α2 + α3 + ... = 1 이다. β는 정규화된(normalized) 사용률을 나타낸다. β 는, 연산 디바이스가 아이들(idle) 상태일 때 0의 값을 갖고, 상기 연산 디바이스가 풀(full)로 사용중일 때 1의 값을 갖는 것으로 가정된다. (0<= β <1)
따라서, 상기 스케줄러(152)는 연산 디바이스 별 실시간 가용 정보(즉, 사용률)를 고려하여 상기 수학식 7을 최소화하는 분담율 α를 결정하는 것으로써, 연산 디바이스별 부하 분산 최적화를 달성할 수 있다. 상기 최적의 분담률 α는 다음의 수학식에 의해 결정될 수 있다.
Figure PCTKR2016009502-appb-M000008
상기 런타임 모듈(150)은 컴파일러 런타임 모듈(156)을 포함할 수 있다. 상기 컴파일러 런타임 모듈(156)은 컴파일러 런타임 라이브러리를 제공한다. 상기 컴파일러 런타임 라이브러리는 컴파일러 모듈(100)와 밀접하게 연동하여 상기 스케줄러가 상기 어플리케이션의 실행 코드(즉, 바이너리)(132, 134, 136, 138, 140)를 구동할 수 있게 한다.
선택적으로, 상기 런타임 모듈(150)은 OS(operation system) 레벨의 추가적인 API 모듈(158) 또는 GPU 구동을 위한 OpenCL 드라이버 모듈(160)를 더 포함할 수도 있다.
도 3은 본 개시에 따른 런타임 모듈의 동작을 개략적으로 설명하는 도면이다.
런타임 모듈(특히, 스케줄러)은 컴파일러의 분석부로부터 실행 코드에 상응하는 정적 정보를 입력받을 수 있고, 장치 모니터로부터 동적 정보를 입력받을 수 있다(300).
상기 런타임 모듈은 어플리케이션을 수행할 연산 디바이스를 선택하는 동작을 수행할 수 있다(302). 구체적으로, 상기 런타임 모듈은 연산 디바이스 별로 성능 (예를 들어, 처리 시간)을 계산할 수 있다. 상기 런타임 모듈은 상기 계산된 연산 디바이스 별 성능을 오름차순으로 정렬할 수 있다. 상기 런타임 모듈은 사용자의 선택을 고려하여 우선 순위가 높은 N 개의 연산 디바이스를 수행 디바이스로 선택할 수도 있다.
상기 런타임 모듈은 선택된 연산 디바이스의 워크로드를 결정하는 스케줄링 동작을 수행할 수 있다(304). 예를 들어, 상기 런타임 모듈은 사용률 또는 주파수 정보를 이용하여 어플리케이션 처리 시간 Tworkload를 결정할 수 있다. 상기 런타임 모듈은 상기 Tworkload를 최소화하는 워크로드 α1, α2, α3 , ... 를 결정할 수 있다.
상기 런타임 모듈은 상기 결정된 워크로드 α를 각 연산 디바이스에 적용하여, 어플리케이션 실행 코드를 구동한다(606).
도 4는 본 개시에 따라서 동작할 연산 디바이스를 결정하고 워크로드를 결정한 경우의 효과를 자원 사용률 및 사용 에너지 관점에서 예시하는 도면이다.
도 4(a) 및 도 4(b)는 런타임 모듈의 선택과 워크로드 결정 동작이 적용되지 않는 경우의 결과를 나타내고, 도 4(c) 및 도 4(d)는 런타임 모듈의 선택과 워크로드 결정 동작이 적용된 경우의 결과를 나타내고 있다.
도 4(a) 및 도 4(b)에서 알 수 있는 바와 같이, 런타임 모듈의 적용이 없는 경우에는, 측정 시구간 전체 동안 GPU(400) 및 멀티코어 CPU(402)의 사용률이 일정 수준에서 지속되고, 이로 인해 에너지 소비(404)도 측정 시구간 전체 동안에 일정하게 유지됨을 알 수 있다.
반면, 본 개시의 런타임 모듈의 적용이 있는 경우에는, 도 4(c) 에서 보여지듯이, GPU(410) 및 멀티코어 CPU(412)의 사용률이 측정 시구간 종료 전에 0의 값에 근접하는 것을 알 수 있다. 즉, 도 4(c) 에서는 연산 디바이스의 동작 시간이 도 4(a) 에 비해 절반 수준으로 감소함을 알 수 있다. 이는 동작 속도의 2배 향상을 의미한다. 또한 도 4(d) 에서의 에너지 소비(412)는 도 4(b)의 에너지 소비에 비해 빠른 속도로 감소함을 알 수 있다.
따라서, 본 개시의 따른 런타임 모듈의 적용은 어플리케이션의 동작 속도 향상과 소비 에너지(소비 전력)을 감소시키는 효과가 있다.
도 5는 본 개시에 따른 기법을 적용함에 있어서, 캐쉬의 입력 크기에 따른 연산 디바이스 별 처리 시간을 비교하는 표이다.
도 5를 참고하면, 캐쉬의 입력(input) 크기가 30K 인 경우에는 Serial 모드(즉, 싱글 코어 CPU)의 계산 시간(500)이 가장 작음을 알 수 있고, 상기 입력 크기라 3000K인 경우에는 Parallel-SIMD 모드 (즉, SIMD 및 CPU)의 계산 시간(502)이 가장 작음을 알 수 있다. 따라서, 캐쉬 입력 크기에 따른 성능 정보를 감안하여, 런타임 모듈은 연산 디바이스를 선택할 수도 있을 것이다.
도 6은 본 개시에 따른 기법을 적용함에 있어서, CPU 및 GPU를 이용하는 경우의 부하 분담율에 따른 성능(처리 시간)을 예시하는 도면이다.
도 6을 참고하면, CPU와 GPU는 약 63:37의 비율로 부하를 분담시킬 경우에 최소 처리 시간을 나타냄을 알 수 있다.
도 7은 본 개시에 따른 기법을 적용함에 있어서, CPU 및 GPU를 이용하는 경우의 워크로드에 따른 에너지 소비량을 예시하는 도면이다.
도 7을 참고하면, CPU와 GPU는 약 65:35의 비율로 부하를 분담시킬 경우에 최소의 에너지를 소비함을 알 수 있다.
도 8은 본 개시에 따른 기법을 적용함에 있어서, CPU 및 GPU를 이용하는 경우에 워크로드와 사용률에 성능(처리시간)을 예시하는 도면이다.
도 8에서, 사용률 β 가 0에 가까울수록 그래프들은 아래쪽으로 위치한다. 도 8을 참고하면, 사용률과 부하 분담율에 따라서 다양한 처리시간 결과를 나타냄을 알 수 있다.
도 9는 본 개시에 따른 컴파일러 모듈의 동작을 개략적으로 설명하는 도면이다.
도 9에서 설명되는 동작은, 도 3에서 설명된 런타임 모듈의 동작 이전에 수행될 수 있는 동작로써, 상기 런타임 모듈과 동일한 장치(예를 들어, 단말 장치) 또는 별개의 장치(예를 들어, 서버, 데스크탑 등)에 구현되는 컴파일러 모듈에서 수행될 수 있다.
상기 컴파일러 모듈은 어플리케이션 소스 코드를 컴파일러가 이해할 수 있는 중간 코드 (즉, IR)로 변경한다(900).
상기 컴파일러 모듈은 상기 IR에 포함되는 의존 관계를 분석하고, 상기 IR로부터 연산 디바이스 각각에서 실행될 수 있는 코드 섹션을 생성한다(905).
상기 컴파일러 모듈은 상기 코드 섹션을 연산 디바이스에 특정적인(적합한) 소스 코드로 변환한다(910). 이때, 상기 컴파일러 모듈은 상기 코드 섹션으로부터 코드 정보를 추출하는 동작을 더 수행할 수 있다. 또한, 상기 변환된 소스 코드에는 런타임 모듈이 실행 코드를 수행하는 데에 이용할 코드 특성이 데이터 구조의 형태로 포함될 수 있다.
상기 컴파일러 모듈은 상기 변환된 소스 코드를 컴파일하여 각 연산 디바이스에 적합한 실행 코드로 생성할 수 있다(915).
상기 컴파일러 모듈은 상기 생성된 실행 코드를 런타임 모듈에게 제공함으로써, 상기 런타임 모듈이 각각의 연산 디바이스에서 상기 실행 코드를 실행할 수 있게 한다.
표 7은 본 개시에 따른 컴파일러 분석부의 분석 성능을 나타낸다.
Figure PCTKR2016009502-appb-T000007
표 7를 참고하면, 본 개시에 따른 분석 기법을 적용할 경우, 분석 시간이 기존 분석 방법의 40.1 초에서 4.7 초로 감소되고, 분석 노드의 개수는 기존 분석 방법의 79,001 개에서 36,479 개로 감소됨을 알 수 있다. 표 7에서는, 테스트를 위해 어큐뮬레이트 웨이티드 알고리즘이 이용되었다.
상기 도 1 내지 도 9가 예시하는 장치 구성도, 제어 방법의 예시도, 성능 예시도는 본 개시의 권리범위를 한정하기 위한 의도가 없음을 유의하여야 한다. 즉, 상기 도 1 내지 도 9에 기재된 모든 구성부, 또는 동작의 단계가 본 개시의 실시를 위한 필수구성요소인 것으로 해석되어서는 안되며, 일부 구성요소 만을 포함하여도 본 개시의 본질을 해치지 않는 범위 내에서 구현될 수 있다.
앞서 설명한 동작들은 해당 프로그램 코드를 저장한 메모리 장치를 통신 시스템의 엔터티, 기능(Function), 기지국, 또는 단말 장치 내의 임의의 구성부에 구비함으로써 실현될 수 있다. 즉, 엔터티, 기능(Function), 기지국, 또는 단말 장치의 제어부는 메모리 장치 내에 저장된 프로그램 코드를 프로세서 혹은 CPU에 의해 읽어내어 실행함으로써 앞서 설명한 동작들을 실행할 수 있다.
본 명세서에서 설명되는 엔터티, 기능(Function), 기지국, 또는 단말 장치의 다양한 구성부들과, 모듈(module)등은 하드웨어(hardware) 회로, 일 예로 상보성 금속 산화막 반도체(complementary metal oxide semiconductor) 기반 논리 회로와, 펌웨어(firmware)와, 소프트웨어(software) 및/혹은 하드웨어와 펌웨어 및/혹은 머신 판독 가능 매체에 삽입된 소프트웨어의 조합과 같은 하드웨어 회로를 사용하여 동작될 수도 있다. 일 예로, 다양한 전기 구조 및 방법들은 트랜지스터(transistor)들과, 논리 게이트(logic gate)들과, 주문형 반도체와 같은 전기 회로들을 사용하여 실시될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 안되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. 단말 장치에서 적어도 하나의 연산 디바이스를 이용하여 어플리케이션을 수행하는 방법에 있어서,
    상기 적어도 하나의 연산 디바이스의 처리 시간을 계산하는 동작;
    사용자의 선호도 또는 상기 계산된 적어도 하나의 처리 시간에 근거하여 상기 어플리케이션을 수행할 소정 개수의 연산 디바이스를 선택하는 동작;
    상기 결정된 소정 개수의 연산 디바이스에 상응하는 사용률을 이용하여 결정되는 처리시간 함수를 최소화하는 워크로드를 결정하는 동작; 및
    상기 소정 개수의 연산 디바이스에 상기 결정된 워크로드를 적용하여 상기 어플리케이션을 실행하는 동작을 포함하는 방법.
  2. 제1항에 있어서,
    상기 어플리케이션의 소스 코드를 IR(intermediate representation)로 변경하는 동작;
    상기 IR을 분석하고, 상기 IR로부터 별개의 연산 디바이스에서 실행될 수 있는 적어도 하나의 코드 섹션을 생성하는 동작;
    상기 적어도 하나의 코드 섹션을 연산 디바이스에 특정적인 소스 코드로 변환하는 동작; 및
    상기 변환된 소스 코드를 컴파일하여 상기 연산 디바이스에 특정적인 실행 코드를 생성하는 동작을 더 포함하는 방법.
  3. 제2항에 있어서,
    상기 IR로부터 별개의 연산 디바이스에서 실행될 수 있는 적어도 하나의 코드 섹션을 생성하는 동작은:
    상기 IR에 포함되는 의존 관계를 분석하는 동작; 및
    상기 IR 중 상기 의존 관계가 없는 노드를 포함하는 코드 섹션을 상기 별개의 연산 디바이스에서 실행될 수 있는 상기 코드 섹션으로써 생성하는 동작을 포함함을 특징으로 하는 방법.
  4. 제3항에 있어서,
    상기 의존 관계를 분석함에 있어서, 사이클 관계에 있는 적어도 2개의 노드는 하나의 노드로 취급됨을 특징으로 하는 방법.
  5. 제2항에 있어서,
    상기 생성된 코드 섹션으로부터 코드 정보를 추출하는 동작을 더 포함하되,
    상기 코드 정보는 상기 코드 섹션 내의 명령에 관련된 정보 및 캐쉬 전송 데이터 양의 정보 중 적어도 하나를 포함함을 특징으로 하는 방법.
  6. 제2항에 있어서,
    상기 변환된 소스 코드는 코드 특성에 해당하는 데이터 구조를 포함하고,
    상기 코드 특성은 동시 사용여부, 수행될 실행코드, 쓰레드 개수, 및 실행코드 별 데이터 범위 정보 중 적어도 하나를 포함함을 특징으로 하는 방법.
  7. 제1항에 있어서,
    상기 적어도 하나의 연산 디바이스는 싱글 코어 CPU(central processing unit), SIMD(single instruction multiple data), Parallel-SIMD, GPU(graphic processing unit), GPGPU(general purpose GPU), 및 DSP(digital signal processor) 중 적어도 2개를 포함함을 특징으로 하는 방법.
  8. 제2항에 있어서, 상기 어플리케이션의 소스 코드는 C 또는 C++ 언어로 작성되는 하나의 소스 코드임을 특징으로 하는 방법.
  9. 제1항에 있어서,
    상기 사용자 선호도는 컴파일러 지시어에 의해 입력됨을 특징으로 하는 방법.
  10. 제3항에 있어서,
    상기 의존 관계를 분석함에 있어서, 온라인 분석 시 선행자가 추가되지 않는 제1 노드, 및 오프라인 분석 시 상기 제1 노드가 갖는 하나의 선행자 노드인 제2 노드가 하나의 노드로 병합되고,
    상기 제1 노드의 모든 포인터는 상기 제2 노드로부터만 오는 것을 특징으로 하는 방법.
  11. 적어도 하나의 연산 디바이스를 이용하여 어플리케이션을 수행하도록 구성된 런타임 모듈을 구비하는 단말 장치에 있어서, 상기 런타임 모듈은:
    상기 적어도 하나의 연산 디바이스의 처리 시간을 계산하고, 사용자의 선호도 또는 상기 계산된 적어도 하나의 처리 시간에 근거하여 상기 어플리케이션을 수행할 소정 개수의 연산 디바이스를 결정하고, 상기 결정된 소정 개수의 연산 디바이스에 상응하는 사용률을 이용하여 결정되는 처리시간 함수를 최소화하는 워크로드를 결정하고, 상기 소정 개수의 연산 디바이스에 상기 결정된 워크로드를 적용하여 상기 어플리케이션을 수행하는 스케줄러; 및
    상기 사용률 정보를 산출하는 장치 모니터를 포함하는 단말 장치.
  12. 제11항에 있어서,
    상기 어플리케이션의 소스 코드를 IR(intermediate representation)로 변경하고, 상기 IR을 분석하여, 상기 IR로부터 별개의 연산 디바이스에서 실행될 수 있는 적어도 하나의 코드 섹션을 생성하고, 상기 적어도 하나의 코드 섹션을 연산 디바이스에 특정적인 소스 코드로 변환하고, 상기 변환된 소스 코드를 컴파일하여 상기 연산 디바이스에 특정적인 실행 코드를 생성하는 컴파일러 모듈을 더 포함하는 단말 장치.
  13. 제12항에 있어서,
    상기 컴파일러 모듈은, 상기 IR에 포함되는 의존 관계를 분석하여, 상기 IR 중 상기 의존 관계가 없는 노드를 포함하는 코드 섹션을 상기 별개의 연산 디바이스에서 실행될 수 있는 상기 코드 섹션으로써 생성함을 특징으로 하는 단말 장치.
  14. 제13항에 있어서,
    상기 컴파일러 모듈은, 상기 의존 관계를 분석할 때, 사이클 관계에 있는 적어도 2개의 노드를 하나의 노드로 취급함을 특징으로 하는 단말 장치.
  15. 제11항에 있어서,
    상기 런타임 모듈은, 상기 제5항 내지 제10항 중 어느 한 항의 방법을 수행함을 특징으로 하는 단말 장치.
PCT/KR2016/009502 2015-08-26 2016-08-26 사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법 WO2017034364A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/755,419 US10705813B2 (en) 2015-08-26 2016-08-26 Technique for dynamically controlling processing devices in accordance with characteristic of user application

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020150120484A KR102402584B1 (ko) 2015-08-26 2015-08-26 사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법
KR10-2015-0120484 2015-08-26

Publications (1)

Publication Number Publication Date
WO2017034364A1 true WO2017034364A1 (ko) 2017-03-02

Family

ID=58100634

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/009502 WO2017034364A1 (ko) 2015-08-26 2016-08-26 사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법

Country Status (3)

Country Link
US (1) US10705813B2 (ko)
KR (1) KR102402584B1 (ko)
WO (1) WO2017034364A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107704234A (zh) * 2017-08-22 2018-02-16 北京三快在线科技有限公司 前端工程构建方法、装置、电子设备及可读存储介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102402584B1 (ko) * 2015-08-26 2022-05-27 삼성전자주식회사 사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법
US10824635B2 (en) 2019-01-30 2020-11-03 Bank Of America Corporation System for dynamic intelligent code change implementation
US10768907B2 (en) * 2019-01-30 2020-09-08 Bank Of America Corporation System for transformation prediction with code change analyzer and implementer
US10853198B2 (en) * 2019-01-30 2020-12-01 Bank Of America Corporation System to restore a transformation state using blockchain technology
US10956137B2 (en) * 2019-06-10 2021-03-23 International Business Machines Corporation Compiling source code using source code transformations selected using benchmark data
US20230185605A1 (en) * 2021-12-15 2023-06-15 Imam Abdulrahman Bin Faisal University Dynamic scheduler for internet-of-things based smart environments
CN117311728B (zh) * 2023-09-27 2024-07-19 北京计算机技术及应用研究所 一种OpenCL自动转译方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130003836A (ko) * 2011-07-01 2013-01-09 한국과학기술연구원 어플리케이션 배포 시스템 및 방법
KR20130021172A (ko) * 2011-08-22 2013-03-05 삼성전자주식회사 단말 및 그 단말에서 어플리케이션 수행 방법
US20140165077A1 (en) * 2011-07-14 2014-06-12 Siemens Corporation Reducing The Scan Cycle Time Of Control Applications Through Multi-Core Execution Of User Programs
US20140237457A1 (en) * 2008-06-06 2014-08-21 Apple Inc. Application programming interfaces for data parallel computing on multiple processors
US20150199787A1 (en) * 2014-01-13 2015-07-16 Red Hat, Inc. Distribute workload of an application to a graphics processing unit

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7039908B2 (en) 2002-06-26 2006-05-02 Microsoft Corporation Unification-based points-to-analysis using multilevel typing
JP4711672B2 (ja) * 2004-12-24 2011-06-29 富士通株式会社 情報処理方法及びプログラム
JP4377899B2 (ja) * 2006-09-20 2009-12-02 株式会社東芝 リソース管理装置及びプログラム
JP4249780B2 (ja) 2006-12-26 2009-04-08 株式会社東芝 リソースを管理する装置、およびプログラム
KR100969322B1 (ko) * 2008-01-10 2010-07-09 엘지전자 주식회사 멀티 그래픽 컨트롤러를 구비한 데이터 처리 장치 및 이를이용한 데이터 처리 방법
JP5238525B2 (ja) * 2009-01-13 2013-07-17 株式会社東芝 リソースを管理する装置、およびプログラム
US8021909B2 (en) 2010-01-13 2011-09-20 Atomic Energy Council - Institute Of Nuclear Research Method for making a planar concentrating solar cell assembly with silicon quantum dots
US8789061B2 (en) * 2010-02-01 2014-07-22 Ca, Inc. System and method for datacenter power management
JP5510543B2 (ja) * 2010-06-30 2014-06-04 富士通株式会社 情報処理装置の使用量解析方法、情報処理システム及びそのプログラム
US20120192200A1 (en) 2011-01-21 2012-07-26 Rao Jayanth N Load Balancing in Heterogeneous Computing Environments
JP5772948B2 (ja) * 2011-03-17 2015-09-02 富士通株式会社 システムおよびスケジューリング方法
JP5949506B2 (ja) 2012-11-30 2016-07-06 富士通株式会社 分散処理方法、情報処理装置、及びプログラム
JP6060756B2 (ja) * 2013-03-18 2017-01-18 富士通株式会社 周波数制御装置、周波数制御方法および周波数制御プログラム
KR102270239B1 (ko) 2014-08-07 2021-06-28 삼성전자 주식회사 전자장치에서 소프트웨어를 실행하기 위한 방법 및 장치
US9513967B2 (en) * 2014-09-18 2016-12-06 International Business Machines Corporation Data-aware workload scheduling and execution in heterogeneous environments
US11481298B2 (en) * 2015-01-20 2022-10-25 Sap Se Computing CPU time usage of activities serviced by CPU
KR102402584B1 (ko) * 2015-08-26 2022-05-27 삼성전자주식회사 사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법
WO2017039393A1 (en) * 2015-09-03 2017-03-09 Samsung Electronics Co., Ltd. Method and apparatus for adaptive cache management
US10025624B2 (en) * 2016-03-30 2018-07-17 International Business Machines Corporation Processing performance analyzer and process manager

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140237457A1 (en) * 2008-06-06 2014-08-21 Apple Inc. Application programming interfaces for data parallel computing on multiple processors
KR20130003836A (ko) * 2011-07-01 2013-01-09 한국과학기술연구원 어플리케이션 배포 시스템 및 방법
US20140165077A1 (en) * 2011-07-14 2014-06-12 Siemens Corporation Reducing The Scan Cycle Time Of Control Applications Through Multi-Core Execution Of User Programs
KR20130021172A (ko) * 2011-08-22 2013-03-05 삼성전자주식회사 단말 및 그 단말에서 어플리케이션 수행 방법
US20150199787A1 (en) * 2014-01-13 2015-07-16 Red Hat, Inc. Distribute workload of an application to a graphics processing unit

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107704234A (zh) * 2017-08-22 2018-02-16 北京三快在线科技有限公司 前端工程构建方法、装置、电子设备及可读存储介质

Also Published As

Publication number Publication date
US20180253291A1 (en) 2018-09-06
KR102402584B1 (ko) 2022-05-27
US10705813B2 (en) 2020-07-07
KR20170024898A (ko) 2017-03-08

Similar Documents

Publication Publication Date Title
WO2017034364A1 (ko) 사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법
KR101085330B1 (ko) 컴파일 방법 및 컴파일러
US8643656B2 (en) Energy-aware task consolidation on graphics processing unit (GPU)
Raman et al. Parcae: a system for flexible parallel execution
US20070074217A1 (en) Scheduling optimizations for user-level threads
US20070294693A1 (en) Scheduling thread execution among a plurality of processors based on evaluation of memory access data
TWI507990B (zh) 多核心指令集模擬之高平行化同步方法
Chen et al. TEST: a tracer for extracting speculative threads
Liu et al. Task assignment with cache partitioning and locking for wcet minimization on mpsoc
US20060136878A1 (en) Method and apparatus for enabling compiler and run-time optimizations for data flow applications in multi-core architectures
Li et al. Energy-aware workload consolidation on GPU
Pathania et al. Optimal greedy algorithm for many-core scheduling
Tanaka et al. mruby--Rapid Software Development for Embedded Systems
Mandelli et al. A distributed energy-aware task mapping to achieve thermal balancing and improve reliability of many-core systems
Stoutchinin et al. Stream drive: A dynamic dataflow framework for clustered embedded architectures
CN110955503A (zh) 任务调度方法及装置
Sakurai et al. Towards a statically scheduled parallel execution of an FRP language for embedded systems
Bari et al. Performance and energy impact of openmp runtime configurations on power constrained systems
Kumar et al. An approach for compiler optimization to exploit instruction level parallelism
Prakash et al. Rapid memory-aware selection of hardware accelerators in programmable SoC design
Fujita et al. CHARM-SYCL: New Unified Programming Environment for Multiple Accelerator Types
Yu et al. General data structure expansion for multi-threading
Yang et al. Improvement of workload balancing using parallel loop self-scheduling on Intel Xeon Phi
WO2013115561A1 (ko) 데이터 처리 시스템 및 그 시스템에서 데이터 시뮬레이션 방법
Deodhar et al. Compiler assisted load balancing on large clusters

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16839652

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15755419

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16839652

Country of ref document: EP

Kind code of ref document: A1