WO2008105558A1 - メモリ管理方法、情報処理装置、プログラムの作成方法及びプログラム - Google Patents

メモリ管理方法、情報処理装置、プログラムの作成方法及びプログラム Download PDF

Info

Publication number
WO2008105558A1
WO2008105558A1 PCT/JP2008/053891 JP2008053891W WO2008105558A1 WO 2008105558 A1 WO2008105558 A1 WO 2008105558A1 JP 2008053891 W JP2008053891 W JP 2008053891W WO 2008105558 A1 WO2008105558 A1 WO 2008105558A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
program
memory
block
processor
Prior art date
Application number
PCT/JP2008/053891
Other languages
English (en)
French (fr)
Inventor
Hironori Kasahara
Keiji Kimura
Hirofumi Nakano
Takumi Nito
Takanori Maruyama
Tsuyoshi Miura
Tomohiro Tagawa
Original Assignee
Waseda University
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 Waseda University filed Critical Waseda University
Priority to US12/525,404 priority Critical patent/US8438359B2/en
Priority to CN2008800037808A priority patent/CN101601017B/zh
Priority to KR1020097017059A priority patent/KR101186174B1/ko
Priority to GB0914592.1A priority patent/GB2459802B/en
Publication of WO2008105558A1 publication Critical patent/WO2008105558A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • 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/5033—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 data affinity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/0284—Multiple user address space allocation, e.g. using different base addresses
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
    • G06F12/0646—Configuration or reconfiguration
    • 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/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G06F8/453—Data distribution
    • 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]
    • 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/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • 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/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022—Mechanisms to release resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/48—Indexing scheme relating to G06F9/48
    • G06F2209/483—Multiproc
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5017—Task decomposition

Definitions

  • the present invention relates to a memory management method in a multiprocessor system composed of a plurality of processor cores, and in particular, based on information acquired by a compiler, data accessed by a processor is a divided area of the memory. On how to assign to. Background art
  • Multi-core processor with multiple processor cores integrated on a single chip The power has been announced one after another by each microprocessor manufacturer.
  • chips multiprocessor The power has been announced one after another by each microprocessor manufacturer.
  • information appliances and devices embedded eg, mobile phones, game machines, car navigation systems, digital television receivers, HD DZD VD recorders) : Coders, players, etc.
  • multi-core microprocessors there is a trend toward multi-core microprocessors.
  • multi-core processors are now being used in almost all information devices from information appliances to supercomputers, and it is expected that multi-core processors will be incorporated into more information devices in the future.
  • Multi-core processors can utilize not only fine-grained instruction level parallelism but also more parallel loop-level parallelism, coarser-grained parallelism between loops, and coarse-grained task parallelism between functions . In this way, multi-core processors can improve processor performance by utilizing greater parallelism. This is advantageous in that Multi-core processors can achieve the same performance using n processor cores. Therefore, by reducing the applied frequency to 1 / n and reducing the applied voltage, power consumption (2 It is also advantageous in that it can be kept low.
  • Multi-grain parallelization combines the parallelism of all statements at the statement level, loop level, and coarser levels (for example, between loops, between subroutines, and between basic blocks) to extract parallelism through the earliest executable condition analysis.
  • Japanese Patent Laid-Open No. 2 0 0 1-1 7 5 6 19 Disclosure of the invention
  • the data size used by one loop is often larger Ri by the size of the local memory, c this when the load of the data and Suta has occurred in the loop, the processor then uses data Need to wait until it is ready There was an overhead of processing by the processor.
  • the processing performance will not improve much even if the programs are parallelized. This is because the memory wall problem is that even if the processor runs faster, the data used by the processor cannot be supplied to the memory at the appropriate timing due to the increase in the difference between the processing speed of the processor and the memory access speed. This is because
  • the memory capacity of the memory close to the processor is small, so when large data is required, it is necessary to divide the data and place it in the memory. Furthermore, since data transfer between memories takes time, it is necessary to schedule the program processing order so that the data in the memory can be reused. In addition, it is necessary to use a DMA controller to hide the overhead when transferring data between memories.
  • the compiler Information on the execution order of tasks in the program is obtained, and data dependency relationships (definition and reference relationships) between tasks are also analyzed. Also, once branching is determined, you can see programs that use the same data. In this way, the information acquired by the compiler can be used to determine when the data stored in the memory is used, and the data can be reused between multiple tasks.
  • data is arranged efficiently so that processing can be continued while keeping data stored in a high-speed memory arranged near the processor as long as possible.
  • the necessary data is stored in a high-speed memory near the processor, and unnecessary data is sequentially transferred to a low-speed but large-capacity memory.
  • data is divided and allocated to the local memory. Also, in order to make the data stored in the local memory usable for a long period of time, the data to be expelled is determined based on the information held by the compiler (information on when and where the data is used). Also, schedule the DMA to load the necessary data first.
  • present invention can be applied not only to memory management in the same type of processor, but also to memory management in different types of heterogeneous multiprocessors.
  • the management of the storage area of the memory is facilitated, so that the arrangement of data in the local memory and the distributed shared memory can be optimized.
  • the data stored in the memory can be reused, and the data transfer between the memories can be reduced.
  • FIG. 1 is a configuration diagram of a single-chip multi-core processor according to an embodiment of the present invention.
  • FIG. 2 is an explanatory diagram of multigrain parallel processing according to the embodiment of this invention.
  • FIG. 3 is an explanatory diagram of a macro flow graph according to the embodiment of this invention.
  • FIG. 4 is an explanatory diagram outlining local memory management according to the embodiment of this invention.
  • FIG. 5 is an explanatory diagram of a state of dividing the storage area of the memory according to the embodiment of this invention.
  • FIG. 6 is an explanatory diagram of the sweep priority of the memory according to the embodiment of this invention.
  • FIG. 7 is an explanatory diagram of changes in variables loaded in the memory according to the embodiment of this invention.
  • FIG. 8 is an explanatory diagram of a specific example of a loop division procedure according to the embodiment of this invention.
  • FIG. 9 is an explanatory diagram of a specific example of a loop division procedure according to the embodiment of this invention.
  • FIG. 10 is an explanatory diagram of a specific example of a loop division procedure according to the embodiment of this invention.
  • FIG. 11 is an explanatory diagram of a specific example of a loop division procedure according to the embodiment of this invention.
  • FIG. 12 is an explanatory diagram of a specific example of the procedure for determining the block size according to the embodiment of this invention.
  • FIG. 13 is an explanatory diagram of a specific example of the procedure for determining the block size according to the embodiment of this invention.
  • FIG. 14 is an explanatory diagram of a specific example (before distribution) of generating a local memory management macro task according to the embodiment of the present invention.
  • FIG. 15 is an explanatory diagram of a specific example (after distribution) of generating a local memory management macro task according to the embodiment of the present invention.
  • FIG. 16 shows an example of a template creation procedure according to the embodiment of the present invention.
  • FIG. 17 is an explanatory diagram of the state of the local memory to which the template according to the embodiment of this invention is mapped.
  • FIG. 18 is an explanatory diagram of the state of the local memory to which the template according to the embodiment of this invention is mapped.
  • Fig. 1 9 A and Fig. 1 9 B are examples of creating a code image according to the embodiment of the present invention It is explanatory drawing of the state 1).
  • FIG. 2 OA and FIG. 20B are explanatory diagrams of a creation example (state 2) of the code image according to the embodiment of the present invention.
  • FIG. 21A and FIG. 21B are explanatory diagrams of a code image creation example (state 3) according to the embodiment of the present invention.
  • 22A and 22B are explanatory diagrams of a code image creation example (state 4) according to the embodiment of the present invention.
  • FIG. 23A and FIG. 23B are explanatory diagrams of a code image creation example (state 5) according to the embodiment of the present invention.
  • FIG. 24A and FIG. 24B are explanatory diagrams of a code image creation example (state 6) according to the embodiment of the present invention.
  • FIG. 25A and FIG. 25B are explanatory diagrams of a creation example (state 7) of the code image according to the embodiment of the present invention.
  • FIG. 26A and FIG. 26B are explanatory diagrams of a creation example (state 8) of the code image according to the embodiment of the present invention.
  • FIG. 27A and FIG. 27B are explanatory diagrams of a code image creation example (state 9) according to the embodiment of the present invention.
  • FIG. 28A and FIG. 28B are explanatory diagrams of a creation example (state 10) of the code image according to the embodiment of the present invention.
  • FIG. 29A and FIG. 29B are explanatory diagrams of a code image creation example (state 11) according to the embodiment of the present invention.
  • FIG. 3 OA and FIG. 30B are explanatory diagrams of a code image creation example (state 12) according to the embodiment of the present invention.
  • FIG. 31A and FIG. 31B are explanatory diagrams of a code image creation example (state 13) according to the embodiment of the present invention.
  • FIG. 3 2 A and FIG. 3 2 B are explanatory diagrams of a code image creation example (state 14) according to the embodiment of the present invention.
  • FIGS. 33A and 33B are explanatory diagrams of a code image creation example (state 15) according to the embodiment of the present invention.
  • FIGS. 34A and 34B are explanatory diagrams of a code image creation example (state 16) according to the embodiment of the present invention.
  • the present invention manages a memory storage area based on information acquired by a compiler through program analysis.
  • the compiler compiles a program, it obtains program information.
  • the compiler can obtain information on data used in the program, information on timing when the data is next used, and information on a processor on which the data is used by analyzing the program. . That is, the timing at which data is used by the program can be acquired.
  • the first feature of the present invention is to manage the allocation of memory storage areas based on information obtained by analyzing a program. ,
  • the compiler has information on the execution schedule of the program (eg, processing of each nested hierarchy), so it can obtain information on when the data is accessed. Therefore, the memory storage area can be optimally allocated to the data based on the program execution schedule, so that the data transfer can be minimized.
  • the processor does not stop waiting for data to be supplied to memory, and the compiler can obtain information on when the data is accessed by the program, so that data that is no longer needed or immediately Data that is not accessed can be identified, and data that is no longer needed by the DMA controller or data that is not immediately accessed can be swept from the memory storage area (store).
  • the data sweep based on this future information does not sweep out data that has not been used recently but may be used immediately. Can optimize data usage and reduce data transfer between memories.
  • the second feature of the present invention is that the timing for transferring data to and / or from the memory is determined based on information obtained by analyzing the program.
  • the memory area is divided into fixed-size blocks, and data is allocated to each block.
  • the size of the block into which the storage area is divided is determined appropriately depending on the nature of the program acquired at compilation (array size used in the program, array shape, program execution pattern, etc.).
  • the block size should be an integer multiple (eg, a multiple of 2).
  • the third feature of the present invention is that data is allocated by dividing the storage area of the memory into blocks of an appropriate size based on information obtained by analyzing the program. Dividing the storage area into fixed-size blocks according to the characteristics of the program is not possible with hardware or OS (Operating System). This is because when a storage area is divided by hardware or OS, it is always divided at a fixed size.
  • OS Operating System
  • the size of the data may vary, so prepare blocks of multiple sizes to fit the size of the data used in the program. Then change the size of the block allocated to fit the size of the data.
  • the program is divided in accordance with the division of the data necessary for program execution (data that must be stored in memory at a certain moment is called “working set”). For example, if you divide the loop in half, the data used is also halved.
  • the fourth feature of the present invention is that the number of divisions of the program is determined so that the working set is placed in the memory storage area based on the information obtained by analyzing the program. For example, dividing a program involves dividing a large loop and repeatedly executing a loop of small units.
  • multi-dimensional array variables are usually used in multiple loops.
  • assign a multidimensional array variable to a fixed-size block with a one-dimensional address space assign a multidimensional array template to the one-dimensional block.
  • the shape and size of this multidimensional array template is determined based on the shape and size of the array variables used in the program.
  • the fifth feature of the present invention is that a template assigned to a block is determined based on information obtained by analyzing a program. As a result, it is possible to assign an arbitrary array to an arbitrary address in the memory while avoiding the trouble of converting the subscript of the array variable and the complexity of the program.
  • the use of data will be specifically described.
  • the definition of data (calculation and storage of data in memory)
  • the memory management in (2) is also within the scope of the present invention. That is, the present invention is applicable to data access including both use and definition of data.
  • FIG. 1 is a configuration diagram of a single chip multi-core processor according to an embodiment of the present invention. It is.
  • the single chip multiprocessor 10 includes a plurality of multicore chips (CMP 0,..., CMPm) 1 including a plurality of processor cores (PC 0, PC 1, “', PCn) 1 6.
  • CMP 0,..., CMPm multicore chips
  • PC 0, PC 1, “', PCn) 1 processor cores
  • PC 0, PC 1, “', PCn) 1 processor cores
  • PC 0, PC 1, “', PCn) 1 processor cores
  • C SM0, ⁇ , C SM j Multiple centralized shared memories
  • I / O control I / O control
  • I / OCSP I / O control
  • I / OCSP k Inter-chip connection network
  • the chip-to-chip network 1 2 is realized by existing connection technology (cross burst, bus, multi-stage network, etc.), and includes multiple processor cores 16, multiple centralized shared memories 14 and input / output chips 18. Connecting.
  • the centralized shared memory 14 is shared by all the processor cores 16 in the system and is accessible from each processor core 16.
  • the centralized shared memory 14 complements the centralized shared memory 28 provided in the multi-core chip 10.
  • Each multi-core chip 10 includes a plurality of processor cores (PC) 16, a centralized shared memory (C SMZL 2 C a c h e) 28, and an intra-chip connection network (In t ra a CC N) 34.
  • Each processor core 16 has a CPU 20, distributed shared memory (DSM) 2 2, low power program memory (L PM I—C a c h) 24, local memory
  • LDMZD—c a c h e data transfer controller
  • N I network interface
  • F VR power control register
  • the CPU 20 is not particularly limited as long as it can perform integer arithmetic and floating point arithmetic.
  • a single load RISC architecture CPU with a simple data load and store architecture can be used.
  • a superscalar processor, a VL IW processor, or the like can also be used.
  • the distributed shared memory (DSM) 2 2 is composed of a dual port memory. Data can be directly read from and written to other processor cores 16 via the data transfer controller 30 and data transfer between tasks. Used for.
  • the local program memory (LPM) 24 caches the instructions to be executed by prefetching them from other memories according to the task execution order determined by the scheduler. Depending on the characteristics of the program, it can also be used as a normal data cache memory, and it can also be used as a cache to reduce hit misses.
  • LDM Local data memory
  • LDM 26 is memory that can be accessed only within each processor core 16 and stores data (eg, array variables) used by tasks assigned to each processor core 16 To do. The local data memory 26 can be switched to the L1 data cache.
  • the data transfer controller (DTC) 30 is configured by a known DMA controller, and transfers instructions to be executed and data to be used between memories in accordance with timings determined by the scheduler. Specifically, local memory 26 on its own or other processor core 16, distributed shared memory 22 on its own and other processor cores 16, centralized shared memory 2 on its own and other multi-core chips 10 8, and data is transferred between centralized shared memories 14 provided on other chips.
  • the broken line between the local data memory 26 and the data transfer controller 30 can be configured so that the data transfer controller 30 can access the local data memory 26 depending on the use of the single chip multiprocessor. It is good. In such a case, a C P U 20 force transfer instruction can be given to the data transfer controller 30 via the local data memory 26. In addition, C P U 20 can check the transferred data after the transfer is completed.
  • the CPU 20 instructs the data transfer controller 30 to transfer data via the local data memory 26, the distributed shared memory 22 or a dedicated buffer (not shown). To do.
  • the data transfer controller 30 reports the end of data transfer to the CPU 20 via the local data memory 26, the distributed shared memory 22 or a dedicated buffer (not shown).
  • which memory or buffer is used is determined at the time of designing the processor according to the purpose of the processor. Alternatively, multiple hard-duty methods may be prepared so that the compiler or the user can use the software properly according to the characteristics of the program.
  • the data transfer instruction to the data transfer controller 30 (for example, from what address to how many bytes of data is stored or loaded, and the data transfer mode (continuous data transfer, stride transfer, etc.))
  • the compiler stores the data transfer instruction in memory or a dedicated buffer, and issues only an instruction for which data transfer instruction is executed when the program is executed, so that an overhead for driving the data transfer controller 30 can be obtained. It is desirable to reduce
  • the network interface (N I) 3 2 is connected to the intra-chip coupling network 3 4 in order to enable communication between the processor cores 16 in each multi-core chip 10.
  • the intra-chip coupling network 3 4 is connected to the inter-chip coupling network 12.
  • the processor core 16 can communicate with the processor cores 16 in other multi-core chips 10 through the interchip coupling network 12.
  • the processor core 16 is connected to the centralized shared memory 14 via the chip-connected network 34.
  • the centralized shared memory 14 is connected to the chip-to-chip coupling network 12.
  • the network interface 3 2 can also be directly connected to the inter-chip coupling network 12 without going through the intra-chip connection network 3 4. Such a configuration enables all processor cores 16 in the system to access the centralized shared memory 28 and the distributed shared memory 2 2 distributed on each chip evenly. Also, by providing a directly connected path, the data transfer capability of the entire system can be increased even when the amount of data transferred between chips is large.
  • the power control register (FVR) 36 the power supply voltage and clock frequency supplied to the processor core 16 are set in order to control the operating frequency and operating voltage of the processor core 16.
  • the power control register is not only the processor core 16, but also the multi-core chip 10, the inter-chip coupling network 12, the centralized shared memory 14, the input / output chip 18, the centralized shared memory 2 8 and the on-chip coupling network 34, which store data for controlling the operating frequency and operating voltage of each of these components.
  • FIG. 2 is a diagram for explaining multigrain parallel processing according to the embodiment of the present invention.
  • Multigrain parallel processing is a parallel processing method that uses coarse grain parallelism, medium grain parallelism, and near fine grain parallelism hierarchically.
  • Coarse-grain parallelism is the parallelism between subroutines, loops, and basic blocks.
  • Medium-grain parallelism is the parallelism between iterations of loops.
  • Near-fine-grain parallelism is a statement.
  • Parallelism between instructions and between instructions. This multi-grain parallel processing is different from the conventional local and single-grain parallelism (such as loop parallelism and instruction-level parallelism). Parallel processing is possible.
  • a block is the outermost loop in each hierarchy.
  • a pseudo assignment statement block is a basic block that is combined and / or divided in consideration of scheduling overhead and parallelism.
  • the pseudo assignment statement block is basically an ordinary basic block, but a single basic block may be divided into a plurality of blocks for the purpose of parallelism extraction. If the processing time of one pseudo assignment statement block is short and the overhead during dynamic scheduling cannot be ignored, multiple pseudo assignment statement blocks are combined to generate one pseudo assignment statement block.
  • the loop index is divided into multiple partial D oa 1 1 loops, and the divided D oa 1 1 loop is newly created. It is defined as a repeating block. If the iteration block is n o n—D o a 1 1 loop, the hierarchical macro data flow processing should be applied to the parallelism within the iteration block.
  • Subroutine blocks should be expanded inline whenever possible. However, subroutines that cannot be inlined effectively as a result of code length consideration are left as subroutine blocks. In this case, hierarchical macro data flow processing should be applied to the parallelism of subroutine block IV.
  • the macro flow graph shows the control flow between macro tasks (MT).
  • MT macro tasks
  • a macrotask graph is a graph that expresses this earliest execution start condition.
  • the compiler then assigns the macrotasks on the macrotask graph to a processor cluster (a group of processors defined by the compiler or user).
  • This task assignment includes static scheduling assigned at compile time and dynamic scheduling assigned at run time.
  • dynamic scheduling a dynamic scheduling code is generated using a dynamic CP algorithm, and the generated dynamic scheduling code is embedded in the program.
  • dynamic scheduling it is not known which macrotask is executed by which processor until the execution time. Therefore, if the data shared between the macrotasks is allocated to the centralized shared memory 14 that is visible from all processors, Good.
  • a loop block that is assigned to a processor cluster by the Mac mouth data flow process, if the loop block is a Doa 1 1 loop or a Doacross loop, multiple processor cores in the processor cluster 1 6
  • the loop is split at the iteration level, and the loops are parallelized so that they are processed by.
  • Rebuilding loops includes changing the order of statement execution, loop distribution usage, node splitting scalar extension, loop interchange, loop unrolling, strip mining, array privateization, and unimodular transformation (loop Conventional techniques such as reversal, permutation, and scanning can be used as they are.
  • Near-fine-grain parallel processing in a multiprocessor system is efficient by scheduling near-fine-grain tasks to processors so that not only the load balance between processors but also the data transfer between processors is minimized. Realize parallel processing. Furthermore, in the scheduling required by this near-fine-grain parallel processing, the execution order of tasks becomes a problem because there is a data-dependent execution order constraint between near-fine-grain tasks.
  • the near-fine-grained task graph generated in this way is statically scheduled for each processor.
  • a scheduling algorithm in order to minimize the execution time in consideration of the data transfer overhead, a known heuristic algorithm (CP / DT ZM ISF method, CPZETF ZM ISF method, ETFZCP method, or Apply the DTZCP method) to determine the optimal schedule.
  • the compiler After scheduling ends, the compiler generates the machine code for each processor by arranging the sequence of tasks assigned to the processor core in order, and inserting data transfer instructions and synchronization instructions where necessary. .
  • the inserted data transfer instruction can determine the timing for storing data in the local memory 26 and sweeping out the data from the local memory 26 according to control dependence and data dependence between macro tasks.
  • the data transfer instruction and the synchronization flag are set with low overhead by the transmitting processor directly writing to the distributed shared memory 22 on the receiving processor core 16. It can be carried out.
  • FIG. 4 is a diagram illustrating an overview of local memory management according to the embodiment of this invention.
  • Programs are generally divided into multiple layers by subroutines and multiple loops. Therefore, it is important to consider at what timing the data necessary for program execution is transferred. For example, in a loop, data should be transferred before and after the loop. Specifically, data is transferred to local memory before the loop is executed, and data is transferred from local memory after the loop is executed. And in the loop, leave the data in local memory and place the data so that the loop can be executed. In this way, the unit of a program that can be executed while data is stored in local memory is called a “local memory management macro task”. In other words, the data handled by the local memory management macro task is always the size of data that can be loaded on the local memory. Data necessary for execution of the local memory management macrotask is transferred (loaded or stored) at an appropriate timing before or after execution of the local memory management macrotask. In addition, a local memory management macro task is determined so that data transfer does not occur within the task.
  • a loop that cannot place all necessary data in local memory defines the part of the loop where all used data is in local memory as a local memory management macrotask.
  • the program is divided so that all necessary data is stored in the local memory, and the local memory management macro task is determined.
  • the local memory management macrotask is determined.
  • the data required for executing the local memory management macrotask is transferred before and after the macrotask execution (loading to local memory, storing from local memory to centralized shared memory).
  • the loop has been described above, but the basic block and support in the program The same is true for pull-in. For subroutines, there are exceptions described later.
  • the present invention can be applied to any memory having a limited capacity (a memory capacity is smaller than that of data used).
  • the present invention can be applied to the distributed shared memory 22 in the processor core 16, the on-chip central shared memory 28, and the off-chip central shared memory 14 in addition to the local memory 26.
  • this program includes a double loop with variables i and j.
  • array variable A [1:30, 1:20] uses 600 elements
  • array variable B [1:30] uses 30 elements
  • array variable C [1:30, 1:20] ] Uses 600 elements.
  • this loop uses 1230 array elements. Therefore, it is not possible to execute this loop by loading all data in local memory.
  • the transfer (loading) of data to local memory may not be performed immediately before execution of the macro task, but may be performed at an earlier point in consideration of allocation of other data to the block. In this way, execution of macro tasks that use array variables (data) are executed. Loading an array variable used by the macro task into memory at any time before the beginning is called “preload”. This preload is performed even if other macrotasks are running, as long as the block into which the data is to be loaded is free.
  • Data can be transferred by DMA. In this way, data can be loaded even before execution of the macro task due to the free state of the block, and the data required before program execution can be prepared. For this reason, the waiting time of the processor due to the fact that the necessary data is not loaded in the memory can be reduced.
  • the transfer (store) of data from local memory may be performed at a later time in consideration of allocation of other data to the block, not immediately after the completion of the macro task execution.
  • poststore loading an array variable used in a macro task into memory at any time after the end of the macro task in which the array variable (data) is used is referred to as “poststore”.
  • This poststore can transfer data from local memory to centralized shared memory by DMA even while other macrotasks are running. In this way, by storing data at an arbitrary timing, it is possible to avoid concentrating the DMA load before and after execution of the macro task.
  • the array variable used by the subroutine caller is loaded. For example, saving, common and Data variables, C static variables, and global variables, these variables cannot be managed by the caller. Therefore, it is necessary to transfer the used variables to the shared memory after the subroutine processing in the macro task is completed. This is because data consistency cannot be achieved unless variables are read from local memory and written to shared memory at the end of the subroutine. Since the macro task is executed by one physical processor, the correct value is guaranteed even if data is loaded and stored in the macro task.
  • FIG. 5 is a diagram for explaining a state of division of the storage area of the memory according to the embodiment of the present invention.
  • the memory to be managed by the storage area is a local memory and a distributed shared memory.
  • the storage area of these managed memories is divided into a plurality of blocks (including sub-blocks) 10 1 to 10 4.
  • Figure 5 shows a block that divides the local memory storage area.
  • Block 1 0 1 is a fixed-length area in which the storage area of the local memory is divided into 1 powers of 2 (1/8 in the state shown).
  • the blocks 4 to 7 are divided into sub-blocks 8 to 15 (1 0 2) which are half of the block size.
  • the sub-blocks 1 2 to 15 are divided into sub-sub-blocks 2 4 to 3 1 (1 0 3) which are half the sub-block size.
  • the sub-subblocks 28 to 31 are divided into sub-sub-subblocks 5 6 to 6 3 (1 0 4) which are half of the sub-subblock size.
  • Block 1 0 1, sub block 1 0 2, sub sub block 1 0 3, sub sub block 1 0 4 are managed independently.
  • the compiler can set a block of any size between each address space in memory.
  • the compiler sets blocks of appropriate size according to the program to be compiled. That is, By preparing large blocks for programs that handle large data and small blocks for programs that handle small data, local memory can be used efficiently and efficiently.
  • sub-blocks, etc. are assigned serial numbers from the start address of the storage area. For this reason, the area indicated by one address is included in multiple blocks and sub-blocks. For example, block 0, sub-block 0 to 1, sub-sub block 0 to 3, and sub-sub sub block 0 to 7 indicate the same memory space (address 0 to 1 2 7). In this way, by setting multiple types of blocks to the same address in the memory space, it is possible to manage the memory so that appropriate types of blocks are used at any time.
  • the sub-block size set in this way is 1 2 of the block size
  • the sub-sub block size is 1/4 of the block size
  • the sub-sub sub-block size is 1 block of the block size.
  • the memory storage area is divided into blocks of multiple sizes that have a power-of-two size relationship (twice the size of adjacent blocks), and multiple divided blocks of size are stored. Offered as an area.
  • the block size is determined by the program information obtained when the compiler compiles the program, so it does not change from the start to the end of program execution.
  • the number and size of blocks differ to suit the characteristics of the program being compiled.
  • the block serving as the management unit of the storage area of the local memory according to the present invention is not a completely fixed size, but based on information obtained by the compiler analyzing the program, an optimum block size for the data size used in the program. You can decide the size.
  • the block size is fixed in the program, but the optimal block size is selected for each program. The block size may be changed during program execution.
  • the block size is determined so that all data used in one local memory management macrotask can be stored in one block.
  • the size of the block determines the size of the local memory management macro task. Note that the timing for putting data in and out of the specified block size is then determined by the scheduler based on the execution timing of the macro task.
  • the necessary data is loaded into the block of the optimum size for the data used in the local memory management macrotask.
  • the local memory storage area as a fixed-size area, it is possible to avoid the problem of fragmentation that occurs when managing it as a variable-size area.
  • the array variable A fits in one block of local memory.
  • Array variable B fits in one sub-subblock.
  • the block size is determined by the compiler according to the nature of the program. More specifically, the block size is determined so that the array variable A fits in one block of local memory, and the loop is divided. Normally, the block size does not change from the beginning to the end of the program to be compiled.
  • the memory used to divide the storage area is loaded with data used in the local memory management macro task.
  • the scheduler determines the memory power to load the data: local memory or distributed shared memory. At this time, data shared by multiple processor cores should be loaded into the distributed shared memory.
  • the scheduler uses the data loaded in that block as it is.
  • the necessary data is not loaded in any block, an empty block is allocated to the loaded data, and the data necessary for the allocated block is loaded.
  • the data with the highest sweep priority is read from local memory 26 and written to centralized shared memory 28 or 14 and the necessary data is loaded into the storage area that has become free blocks. To do.
  • FIG. 6 is a diagram for explaining the sweep priority of the memory according to the embodiment of the present invention, and the time is shown on the horizontal axis.
  • the sweep-out priority is determined in the following order.
  • Data that is not accessed thereafter is, for example, a variable that has been recalculated. You don't need to keep these already dead variables
  • the priority is the highest. Data that is accessed by other processors but not accessed by its own processor in the future can be transferred to the distributed shared memory 22 of the processor core 16 that needs the data, so that it has the next highest sweep priority. Data accessed by other processors can be transferred immediately to the distributed shared memory 22. However, if the data cannot be transferred immediately due to the memory status of the other processor core 16, the shared shared memory is shifted slightly before the data is transferred. Force to transfer to 22, transfer to centralized shared memory 28 or 14. In this way, in order to provide flexibility in the timing of data transfer from the local memory 26, the sweep priority is set lower than the data that is not accessed.
  • the priority for data accessed by its own processor is determined according to the time until it is next used. The earlier the time the data is used, the higher the sweep priority, and the data used in the immediate vicinity is lowered so that it remains in memory as much as possible.
  • processor core 0 (PC 0) defines array variable A (De f A) and uses array variable A (10 02).
  • array variable D When comparing array variable C and array variable D, array variable D is used before array variable C. Therefore, the sweep priority of array variable C is higher than the sweep priority of array variable D. Since array variables C and D are used later, they can be written back to the centralized shared memory CSM and loaded when needed next time.
  • the sweep priority is in the order of A, B, C, D.
  • FIG. 7 is a diagram for explaining the transition of variables loaded in the memory according to the embodiment of the present invention.
  • Figure 7 shows the memory of the program before the start of program execution when a program containing two low-power memory management macrotasks (MT 1, MT 2) is executed in one layer on one processor core.
  • the status of the memory at the end of execution of Macrotask 1 (MT1), the status of the memory at the start of execution of Macrotask2 (MT2), and the memory at the end of execution of Macrotask2 (MT2) Indicates the state.
  • the storage area of the local memory is divided as shown in FIG.
  • macrotask 1 Before the execution of macrotask 1 (MT 1), all memory storage areas (blocks) are empty (101 1).
  • blocks are allocated to the data (array variables A, B, C, D, E, and F) required by macrotask 1, and each array variable is loaded into memory. Thereafter, processing by macro task 1 starts.
  • the array variable A is assigned to block 0 by the declaration statement def A.
  • array variable B is assigned to block 1
  • array variable C is assigned to block 2
  • array variable D is assigned to block 3
  • array variable E is assigned to subblock 8
  • array variable F Is a sub-pro Is assigned to
  • each array variable is loaded into the block (1 0 1 2).
  • macro task 2 (MT 2) execution, all data used by macro task 2 must be loaded into memory.
  • array variables A, B, C, G, E, H, I and J are used, so 4 blocks and 4 sub-blocks are required.
  • array variables A, B, C, and E are already loaded into local memory, so the array variables to be newly loaded when executing macrotask 2 are array variables G, H, and I. And J.
  • array variable H is preloaded in sub-block 10 before the start of execution of macrotask 2.
  • Sub-block 1 1 is empty. Therefore, one block and one sub-block need to be freed at the start of macro task 2 execution.
  • array variable D is swept from block 3 according to the sweep priority, and array variable F is swept from sub-block 9.
  • one empty block and one empty sub-block are secured (1 0 1 4).
  • array variable G is assigned to block 3
  • array variable I is assigned to sub-block 9
  • array variable J is assigned to sub-block 1 1.
  • macrotask 2 is executed, and array variables G, I, and J are used in macrotask 2 (1 0 1 4).
  • data is stored from memory to distributed shared memory or centralized shared memory according to the priorities described above. It can be optimized and data transfer between memories can be reduced. In other words, according to the conventional LRU, data that has not been used recently but may be used soon is also transferred from the memory. However, according to the information acquired by the compiler as in the present invention, the timing when the data is used next can be known, and the memory can be used optimally.
  • the loop is divided by matching multiple loops.
  • the most widely accessed range in the multiplexed loop is analyzed to obtain the global index range. In other words, there is a range where the local memory needs to be accessed and a range where communication with the adjacent processor is required.
  • the data access range is analyzed and separated. Therefore, analyze the program structure and select the target loop group (T L G).
  • T L G target loop group
  • each loop is either a Doa 1 1 loop, a Reduction loop, or a Sequentia l loop depending on loop carrier data (recurrence).
  • all the unselected loops are also the target loop group. And allow loops that contain indirect references, allowing nesting of target loop groups. In other words, if a loop exists inside the loop selected as the target loop group, a target loop group is also generated for the inner loop. In addition, loops that cannot be matched with other loops form a target loop group only by that loop.
  • a target loop group is a set of repetitive blocks (RB) to which loop-consistent division can be applied on a macro task, and is a set of repetitive blocks that have direct data-dependent predecessor and successor relationships on the macrotask graph.
  • RB repetitive blocks
  • the same data is used between loops, the same area can be reused to prevent cache misses.
  • a TLG set is generated when the TLG satisfies all of the following generation conditions.
  • a split candidate TLG set is generated.
  • the TLG set with the highest cost is selected, and the selected TLG set is selected as a candidate for division.
  • GIR is calculated for each candidate TLG set for division. This way, you can cover all the code in the program.
  • TLG set 1 is a candidate partition TLG set 1
  • GIR is [1: 10].
  • the partition reference area is a storage area that must contain the data used in each TLG set. Specifically, the ratio of the data size used in the split candidate TLG set is calculated.
  • the data size used in set 1 is 300 k
  • the data size used in set 2 is 200 k
  • the data size used in set 3 is 100 k. If so, the ratio of data sizes is 3: 2: 1.
  • a minimum memory area (local memory or distributed shared memory with a smaller capacity) is assigned to each partition candidate TLG set.
  • the division candidate TLG set is divided so that the data used in the division candidate TLG set fits in an area smaller than the minimum memory area.
  • the data used in the division candidate T L G set can be placed in areas other than the area allocated at this time, but such processing is performed as a guide for division.
  • the partition candidate TLG set with the highest cost is used as a criterion for determining the block size.
  • the maximum number of divisions is adopted for the division candidate TLG set.
  • the maximum number of divisions is the maximum number of divisions in consideration of the configuration of the processor core (PC) in the allocated processor duplication (PG) and the overhead due to parallel processing. If the number of CPUs is one, the maximum number of divisions is the number of iterations of the loop. Since then, multiple divisions have become necessary T
  • the LG set is not selected as a candidate for splitting TLG. Then, again, a division candidate TLG set is generated.
  • TLG set 1 is divided by the maximum number of divisions, so the next TLG set 2 is selected as a division candidate TLG.
  • the TLG set 2 that is a candidate for splitting has a GIR of [1:20].
  • the block size determination pre-processing is executed. Calculate the number of partitions in which the data accessed in the reference partition candidate TLG set is smaller in size than the partition reference region. Here, only the size of the accessed data is considered, and access to indirectly referenced data is not considered. Select the number of divisions to be an integer multiple of the number of processor groups. Attempts to divide each loop in the TLG set with the number of divisions obtained.
  • the outermost loop (loop of i) is tried in 4 divisions.
  • templates for all local arrays in the TLG set are created, and the size of the created template is the temporary block size. Details of template creation will be described later. Again, access to indirectly referenced array data is not considered. If template creation fails, increase the number of divisions and start over from block size determination preprocessing.
  • the provisional block size determines whether it can be allocated to the division reference area. In this step, if the data is indirectly referenced, the dimension is determined using the declared size of the array. If an indirectly referenced array does not fit in the block, you may decide to place it in shared memory. If the data used in the TLG set can be allocated to the temporary block size, the number of divisions when the template is created is adopted (ie, no further division is performed). Then, the temporary block size is determined as the block size.
  • the data used in the TLG set cannot be allocated to the temporary block size, increase the number of divisions and start over from the block size determination pre-processing. Furthermore, if allocation is not possible even with the maximum number of partitions, the maximum number of partitions is adopted, and a TLG set that cannot be allocated thereafter is not selected as a partition candidate TLG set. Then, again, a division candidate T L G set is generated.
  • each partition candidate TLG set calculate how many blocks can be secured in the area determined by determining the partition reference area based on the block size determined earlier, and obtain the number of partitions that can be allocated. As a result, if any of the partition candidate TLG sets fails to be allocated, a split candidate TLG set is generated again.
  • the maximum number of partitions is adopted for the partition candidate TLG set that could not be assigned.
  • the TLG set that could not be assigned is not selected as the partition candidate TLG set, and the block size is not recalculated.
  • the data size of the partition candidate TLG set for which the number of partitions has already been determined is subtracted from the local memory size, and the TLG set is allocated again based on the ratio of the data size of the remaining partition candidate TLG sets.
  • Each loop in the candidate TLG set for which the number of divisions is determined.
  • Local memory management A macro task candidate.
  • TLG set 1 the data size used in TLG set 1 is 300 k
  • the data size used in TLG set 2 is 200 k
  • the data size used in TLG set 3 is 100 k.
  • the block size is determined based on TLG set 1. If TLG set 2 fails to allocate even with the maximum number of partitions, and TLG set 2 contains TLG set 4, TLG set 5, and TLG set 6, these Is added to the next candidate TLG set for partitioning.
  • the division is performed assuming that which data is used in what pattern and which data uses which block size This information is stored for assigning data to the low-power memory.
  • the processes performed here are macro task division, loop distribution, loop fusion, and loop reconstruction.
  • loop distribution is a process for reusing data when multiple division is performed, as will be described in detail in FIGS. 14 and 15.
  • Loop fusion is a process for reusing registers.
  • a macrotask with the number of divisions set in order from the outer layer loop is searched, and the found macrotask is set as a local memory management macrotask.
  • the macro task is not searched inside the macro task set as the local memory management macro task.
  • a template is a unit for assigning array variables to local memory.
  • the compiler prepares templates according to the pattern in which the program accesses the data.
  • the size of the provided template is the same as the size of the block or sub-block. Templates are prepared for each dimension (1D array, 2D array, 3D array, ...) and are larger than the size accessed by the program.
  • a template with the same size as the block size is used to manage local memory while maintaining program readability.
  • a template is a template in which array variables are stored. By storing the necessary data in the template, it is possible to place data in an arbitrary block on the oral memory.
  • the template is created by the following procedure.
  • For the third dimension select the larger number of rotations of the loop and set it to 3 rotations.
  • the size of the largest temporary template is taken as the block size. In the above example, the block size is 4 k elements.
  • division reference area size Z block size the number of available blocks (B 1 o c k _ n u m) is obtained by rounding down the decimal part of the quotient obtained by division. On the other hand, if the quotient obtained is less than 1, no block can be created with this template size, so it is determined that template creation failed.
  • the block size is divided by the size of each template (block size / size of each template), and the quotient is the number of sub-blocks.
  • three templates [1: 3 2, 1: 3 2, 1: 4, 0: 2] of 4 k element size are prepared. Since the template size and the number of templates have been determined, the number of loop divisions is fixed at 4.
  • the optimal block size is determined by looking at the entire program. For this reason, the number of program divisions for placing the data (working set) used in the macro task in the oral memory is determined. Then, select the number of divisions so that the block size is larger than the divided data size.
  • the data accessed in the loop To determine the block size, first, the data accessed in the loop To create a template with a power of 2.
  • the local memory size (excluding the flag area) is assumed to be 2 kB, the size of each array element is assumed to be 4 BZ elements, and the existence of distributed shared memory is not considered.
  • the outermost loop 1020 by the variable i, the inner loop 1021 by the variable j in the loop 1020, and the innermost loop 1022 by the variable k in the loop 1021 have a triple loop structure. ing.
  • a temporary template is created according to the procedure described above.
  • the outermost loop (variable i) 1020 is divided by the maximum number of divisions (10 divisions).
  • the maximum number of divisions is the number of iterations of the loop. Note that it is desirable to divide the inner loop when the outer loop is not able to secure the necessary number of blocks even if it is divided to the limit.
  • the created template is [1:16, 1: 8, 1: 1, 0: 3].
  • the loops 1030 and 1031 are divided in the same way.
  • the local memory management macro task suitable for the local memory size can be determined by dividing the inner (other dimensions) loop (multi-dimensional division). it can.
  • the local memory size (excluding the flag area) is assumed to be 2 kB, the size of each array element is 4 BZ elements, and the existence of distributed shared memory is not considered.
  • this program has a triple loop with variables j and k.
  • Loop 1051 is executed after loop 1041, and loop 1042 and loop 1052 have the same data (array variable A [1:30, 1:10, 1: 1: 1] and array variable B [1:30, 1 : 10, 1: 1]), loop 1043 and loop 1053 have the same data (array variable A [1: 30, 1 1: 20, 1: 1] and array variable B [1: 30, 1 1 : 20, 1: 1]).
  • the divided outermost loop 1041 B and outermost loop 1051 B can be executed in order (that is, the inner loop 1043 and the inner loop 1053 are executed in order). For this reason, the array data used in loop 1043 is not changed. It can also be used in loop 1 0 5 3. In other words, no data (array variable) is transferred between the end of execution of loop 1 0 4 1 B and the start of execution of loop 1 0 5 1 B.
  • the distribution of the loop is executed so that the loop that handles the same data is executed continuously. This prevents data transfer from occurring during the execution of the loop.
  • FIG. 16 shows an example of a procedure for creating a template bowl according to the embodiment of the present invention.
  • a template is a unit that allocates array variables to local memory in order to handle local memory on a macro task.
  • Templates are prepared as 1D arrays, 2D arrays, 3D arrays, etc., and their shapes vary depending on the array variables used in the macro task. For example, considering a two-dimensional array, squares with the same maximum value of each subscript of the array variable, or rectangles with different maximum values of subscripts (vertical and horizontal) Force to match the size of the array variable used in the macro task To be prepared.
  • the size of the template is larger than the size of data used by the local memory management macrotask.
  • the maximum number of subscripts in each dimension of the template is selected to be the smallest power of two that is greater than the maximum value of each dimension subscript in the array variable used by the local memory management macrotask. For this reason, the size of a template is the same as the size of either a block or a sub-block, even if its shape changes.
  • the size of the template is equal to the block size or one power of 2 of the block size.
  • a template with the smallest size that can fit the data is created, and the program is created so that the data fits in the created template. (Loop). And when allocating array variables to local memory, they can be allocated to blocks of the same size, and the storage capacity of local memory can be used without waste.
  • the template assigned to block 0 uses block 0 memory space and the template assigned to block 1 uses block 1 memory space.
  • the prepared template is the template in which a plurality of the same templates are arranged (dimension of array variable used by placing data + one dimension).
  • the newly created dimension is the dimension for specifying blocks, and the number of elements is the number of blocks.
  • the dimension of the template is one dimension larger than the dimension of the array variable. This is to change the block to be accessed by switching multiple array variables depending on the value of the added dimension of the template.
  • Each template is assigned to a different block (different address) in local memory. If the array variables have the same shape and size, the same template can be used. For example, evenly divided loops use array variables of the same shape and size, so it is effective to prepare such a template. For example, if the number of blocks is 8, and each size is [1: 2, 1, 1:16, 1: 4], t empA [l: 2, 1:16, 1: 4, 0: 7 ] Template in local memory.
  • Figure 17 shows the state of local memory to which the template is mapped.
  • FORTRAN uses the EQUIVALENCE statement for mapping the template.
  • EQUIVALENCE (LM (1), tem P A (l, 1, 1,0)) Te cowpea to declare that can be assigned to block 0 of the local memory, the template A.
  • Template A is a template for a 3D array where each dimension is t empA
  • t empA [1, 1, 1, 0] is assigned to block 0 (address 0 to 127), and t empA [1, 1, 1, 1] is assigned to block 1 (address 1 28 to 255). Assigned.
  • the outermost fourth dimension of the template is not the dimension of the template itself, but the block number to which the template is assigned.
  • the data of array variable G A is stored in block 2 of local memory.
  • Figure 18 shows the state of verbal memory to which another template is mapped. Unlike the example above, if the array size that appears in the program is [1: 2, 1,8, 1: 4], the template te mp_s ub A [1: 2, 1: 8, 1: 4, 0: 1 5] can be assigned to local memory. In this way, the sub-block to be accessed is variable depending on the value of the outermost element.
  • template (sub) A can be assigned to subblock 0 of local memory. .
  • Template A is a template for a three-dimensional array, and its size is t emp—sub A [1: 2, 2, 1: 8, 1: 4, 0:15]. Therefore, sub block 0 (address 0 to 63) is assigned t emp— su bA [l, 1, 1, 0], and sub block 1 (address 64 to: I 27) is assigned t emp — su bA [1 , 1, 1, 1] are assigned.
  • the data of array variable GA is stored in subblock 4 of local memory.
  • the compiler based on the information obtained by analyzing the program, the compiler identifies the shape of the array variable used in the program, creates a template, and decides which template to assign the variable to.
  • the one-dimensional address space of the memory can be made to appear multidimensional, and the multidimensional array used in the program can be allocated to the memory as it is.
  • the local memory size is 1024
  • the block size is 128
  • the local memory area is 4 blocks 101, 4 sub-blocks 102, 4 sub-sub-blocks 10 3, 8
  • the compiler When divided into sub-sub-sub-blocks 104, it shows how the compiler rewrites the code and the state of the local memory during program execution.
  • Figure 19 shows the state of the original code and local memory (state 1) before compilation.
  • This original code contains three loops and two subroutine calls, and these loops and subroutine calls are local memory management macrotasks.
  • Figure 20 shows the state (state 2) where the template is set to a block. LM region and template sequence are defined, and template template is transferred to low power / rememory by EQUIVALENCE statement.
  • Assign to address space With this allocation, the local / memory and the template point to the same area. And the corresponding area changes by changing the index (0-7) of the template. Although it is declared by the template array, after t emp i (1, 4), it is an area allocated to sub-blocks, so it is not used as a block.
  • Figure 21 shows the state (state 3) converted to the template array.
  • the array names a (i), b (i), c (i) in the original code are te mp i (i, 0), t emp i (i, 1), t emp i ( It can be rewritten as i and 2).
  • Figure 22 shows the situation (state 4) where data is being swept from the block.
  • the second macrotask uses four arrays b, c, d, and e, so four blocks are required.
  • the required number of blocks is released according to the sweep priority.
  • three arrays a, b, and c are stored in local memory, but arrays b and c are used continuously. So to load array e, array a is swept out.
  • the data stored in the block to be swept out is transferred to the central shared memory 28 or 14. Therefore, an instruction for transferring the data stored in the template array to the central shared memory 28 or 14 array is inserted into the original code. .
  • Figure 23 shows the state converted to the template array (state 5). Similar to the state shown in state 3 (Fig. 21), the array to be used in local memory is converted to the newly defined template array. Array a is swept from block 0 and array d is stored.
  • Figure 24 shows the situation where the subroutine is analyzed (state 6). Analyzes subroutine arguments and the number of blocks required for processing within the subroutine.
  • subroutine sub 1 uses argument array X and automatic variable array y. That is, one block for arguments and one block for internal processing. A total of two books are required.
  • Figure 25 shows the state (state 7) that is converted into a template array using block specification variables within the subroutine.
  • block_nol the block specification variable
  • Figure 26 shows the state (state 8) where a block for subroutine processing is reserved. Since the analysis in the subroutine has already been completed and the number of blocks required for the subroutine is already known, the necessary number of blocks are freed when the subroutine is called, and a block for subroutine processing is secured. If the required number of blocks is not available, sweep out the data already loaded. The data to be swept is determined according to the sweep priority.
  • this subroutine requires one argument block and one internal processing block.
  • arrays b, c, d, and e are used as an argument. Therefore, it is necessary to free one block for internal processing.
  • arrays c and d are used immediately, so array b is swept out.
  • Figure 27 shows the state (state 9) where the block specification variable is set.
  • the internal processing array used in the subroutine can be set to any block by the block specification variable block_nol.
  • the block number assigned to the array variable for internal processing is set in the specified variable.
  • Figure 28 shows the state in which the subroutine is executed (state 10).
  • subroutine The block specification variable set at the time of the call determines the block used. That is, block 1 is assigned to the array y for internal processing, and block 3 is assigned to the array X for arguments. In the subroutine, the subroutine is processed using the specified block.
  • Figure 29 shows the state at the end of subroutine execution (state 1 1).
  • the block for internal processing becomes NULL.
  • the argument prox returns to the original array received as an argument.
  • FIG. 30 shows a state (state 1 2) that is converted into a template array. Similar to the states shown in state 3 (Fig. 21) and state 5 (Fig. 23), the array to be used in the local memory is converted to a newly defined template array.
  • Figure 31 shows the state (state 13) in which a block for subroutine processing is secured. Since the analysis in the subroutine has already been completed and the number of blocks required for the subroutine is already known, the necessary number of blocks are freed when the subroutine is called, and blocks for subroutine processing are secured. If the required number of blocks is not free, the data already loaded is swept out. The data to be swept is determined according to the sweep priority.
  • next macro task (subroutine call) it is necessary to release one block for the internal processing of the subroutine.
  • the array a is used as an argument of the subroutine. Since the lj d, c, and e have the same sweep priority, the array d stored in block 0 with the smallest block number is swept out. Since it is known that the array a is required in the next macro task, the array a is transferred to an empty block 1 in the local memory by the data transfer unit.
  • Figure 32 shows the state (state 14) in which the block specification variable is set.
  • the internal processing array used in the subroutine is determined by the block specification variable block—nol. Any block
  • the block number assigned to the array variable for internal processing is set in the specified variable when the subroutine is called.
  • a block number different from the previous subroutine call (state 9 shown in Fig. 27) can be set.
  • Figure 33 shows the state in which the subroutine is executed (state 15).
  • the block used is determined by the block specification variable set when the subroutine is called. That is, block 0 is assigned to the array y for internal processing, and block 1 is assigned to the array X for arguments.
  • the subroutine is processed using the specified block. Processing is performed in a different area from the previous subroutine call (state 10 shown in Fig. 28).
  • Figure 34 shows the state when the subroutine is finished (state 16).
  • the code shown in Figure 34 is the code at the completion of compilation.
  • the block for internal processing becomes NU L L.
  • the argument block returns to the original array received as an argument.
  • the present invention can be applied to management of a storage area of a memory used by a processor, and is particularly suitable for management of a storage area of a memory used by a multitask processor.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Memory System (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

プロセッサによって使用されるメモリの記憶領域を管理する方法であって、前記プロセッサは、タスクの実行時に使用されるデータを格納するメモリに接続されており、前記メモリの記憶領域を複数の異なるサイズのブロックに分割し、前記タスクの実行時に使用されるデータに適合するサイズのブロックを選択し、前記選択されたブロックに、前記タスクの実行時に使用されるデータを格納することによって、メモリへデータを効率よく配置する。

Description

明 細 書 メモリ管理方法、 情報処理装置、 プログラムの作成方法及びプログラム 技術分野
本発明は、 複数のプロセッサコアで構成されるマルチプロセッサシステムにお けるメモリの管理方法に関し、 特に、 コンパイラが取得した情報に基づいて、 プ 口セッサによってアクセスされるデータをメモリの分割された領域に割り当てる 方法に関する。 背景技術
複数のプロセッサコアを一つのチップ上に集積したマルチコアプロセッサ （チ ップマルチプロセッサ） 力 各マイクロプロセッサメーカによって次々に発表さ れている。 ス一パーコンピュータ、 サーバ、 デスク トップコンピュータ及び P C サーバ分野の他、 情報家電及び装置組み込みの分野 （例えば、 携帯電話機、 ゲ ·. ム機、 カーナビゲーシヨンシステム、 デジタルテレビ受像機、 HD DZD V Dレ： コーダ ·プレーヤ等） においても、 マイクロプロセッサのマルチコア化の動きが -， 見られる。
このように、 現在情報家電からスーパーコンピュータに至るほとんどの情報機 器においてマルチコアプロセッサが使われるようになつており、 今後、 さらに多 くの情報機器にマルチコアプロセッサが組み込まれていくと考えられる。
マルチコアプロセッサは、 細粒度命令レベルの並列性だけでなく、 より並列性 の大きいループレベルの並列性、 さらに粒度の粗いループ間の並列性、 関数間の 粗粒度タスク並列性も利用することができる。 このように、 マルチコアプロセッ サは、 より大きな並列性の利用によって、 プロセッサの処理性能を向上させるこ とができる点で有利である。 また、 マルチコアプロセッサは、 n台のプロセッサ コアを用い同一性能を達成することができるので、 ク口ック周波数を n分の 1に し、 印加する電圧も下げることによって、 消費電力 （電圧の 2乗で増大する） を 低く抑えることができる点でも有利である。
また、 ソフトウェア面では、 マルチプロセッサ用の並列プログラミングは、 通 常、 チューニングに多大な時間を要することから、 アプリケーションソフ トゥェ ァの開発が大変である。 しかし、 比較的少数のプロセッサが集積されている現時 点では、 逐次プログラムを自動的に並列化する自動並列化コンパイラによって高 性能を得ることができる。 情報家電分野ではアプリケーションの質と数が市場で の競争力を決めることから、 コンパイラによって、 4コア、 8コア、 1 6コアの マルチプロセッサ用のプログラムの自動並列化が可能となれば、 マルチコアの優 位性が高まる。
また、 マルチグレイン並列化では、 文レベル、 ループレベル、 より粗いレベル (例えば、 ループ間、 サブルーチン間、 ベーシックブロック間） の全ての並列性 を組み合わせて最早実行可能条件解析によって並列性を抽出する技術が、 特開 2 0 0 1 - 1 7 5 6 1 9号公報に開示されている。 発明の開示
このような、 ローカルメモリの最適化は、 従来から行われていた。 し力 し、 従 来のローカルメモリの最適化は、 並列ループが連続する場合に、 並列可能なルー プを連続的に実行することによってメモリ上のデータを使い回すだけのものであ つた。
しかし、 一つのループで使用されるデータサイズはローカルメモリのサイズよ りも大きい場合が多く、 ループの中でデータのロード及びストァが発生していた c このとき、 プロセッサは、 次に使用するデータが準備されるまで処理を待つ必要 があり、 プロセッサによる処理のオーバーへッドが発生していた。
また、 ローカルメモリ上のデータを使いながらプログラムを実行していくデー タロー力ライゼーションによると、 ローカルメモリだけを使って処理をするため に、 逐次形のループ及びベーシックブロックで使用される大きなデータもロー力 ルメモリに格納しなければならない。 ローカルメモリに載せられないデータは共 有メモリに格納していた。 よって、 プログラム全域に渡ってデータをロー力ライ ゼーションを適用することが望まれている。
また、 スタティックスケジユーリング時及びダイナミックスケジユーリングコ 一ドの生成時には、 各プロセッサ上のローカルメモリ又は分散共有メモリを有効 に使用し、 プロセッサ間のデータ転送量を最小化するためのデータロー力ライゼ ーションも用いられる。
さらに、 プロセッサの集積度が高まり、 1チップに含まれるプロセッサコア数 が増えてくると、 プログラムを並列化してもそれほど処理性能が向上しない。 な ぜなら、 プロセッサの動作が早くなつても、 プロセッサによる処理速度とメモリ アクセス速度との差が拡大することによって、 プロセッサが使用するデータを適 切なタイミングでメモリへ供給できないという、 メモリウォールの問題が生じる からである。
そこで、 プロセッサに近接して設けられているメモリを上手に使う必要がある。 すなわち、 プロセッサに近接するメモリの記憶容量は小さいので、 大きなデータ が必要な場合は、 データを分割してメモリに載せることが必要となる。 さらに、 メモリ間のデータの転送は時間がかかるので、 メモリに載っているデータを使い 回せるように、 プログラムの処理の順序を工夫したスケジューリングをすること が求められる。 さらに、 メモリ間でデータを転送するときに DMAコントローラ を使って、 オーバヘッドを隠す必要がある。
コンパイラは、 プロセッサで実行されるプログラムの並列性を解析するときに、 プログラム内のタスクの実行順序の情報を取得し、 タスク間でのデータの依存関 係 （定義、 参照の関係） も解析する。 また、 分岐が決まると、 同じデータを使う プログラムが分かる。 このように、 コンパイラが取得した情報によって、 メモリ に格納されたデータが使用されるタイミングが分かり、 複数のタスク間でデータ を使い回すことができる。
すなわち、 本発明では、 プロセッサ近傍に配置された高速なメモリに格納され たデータを、 可能な限り連続して長期間置いたまま処理を続けられるようにする ために、 データを効率よく配置する。 具体的には、 必要なデータをプロセッサ近 傍の高速なメモリに格納し、 不必要となったデータを低速だが大容量のメモリへ 順次転送する。 さらに、 本発明では、 データを分割してローカルメモリに割り当 てる。 また、 ローカルメモリに格納されたデータを長期間使えるようにするため に、 コンパイラが持っている情報 （データが何時どこで使われるかの情報） に基 づいて、 どのデータを追い出すかを決める。 また、 必要となるデータを先にロー ドするように DMAをスケジユーリングする。
なお、 本発明は、 同一種類のプロセッサにおけるメモリ管理のみでなく、 異な る種類のヘテロジニアス ·マルチプロセッサにおけるメモリ管理にも適用するこ とができる。
本発明によれば、 メモリの記憶領域の管理が容易になることから、 ローカルメ モリ及び分散共有メモリへのデータの配置を最適化することができる。 これによ り、 メモリに載っているデータを使い回すことができ、 メモリ間でデータの転送 を減らすことができる。 図面の簡単な説明
図 1は、 本発明の実施の形態のシングルチップマルチコアプロセッサの構成図 である。 図 2は、 本発明の実施の形態のマルチグレイン並列処理の説明図である。
図 3は、 本発明の実施の形態のマクロフローグラフの説明図である。
図 4は、 本発明の実施の形態のローカルメモリ管理の概要の説明図である。 図 5は、 本発明の実施の形態のメモリの記憶領域の分割の状態の説明図である。 図 6は、 本発明の実施の形態のメモリの掃き出し優先度の説明図である。
図 7は、 本発明の実施の形態のメモリにロードされている変数の推移の説明図 である。
図 8は、 本発明の実施の形態のループの分割手順の具体例の説明図である。 図 9は、 本発明の実施の形態のループの分割手順の具体例の説明図である。 図 1 0は、 本発明の実施の形態のループの分割手順の具体例の説明図である。 図 1 1は、 本発明の実施の形態のループの分割手順の具体例の説明図である。 図 1 2は、 本発明の実施の形態のブロックサイズの決定手順の具体例の説明図 である。
図 1 3は、 本発明の実施の形態のブロックサイズの決定手順の具体例の説明図 である。
図 1 4は、 本発明の実施の形態のローカルメモリ管理マクロタスクの生成の具 体例 （デイストリビューシヨン前） の説明図である。
図 1 5は、 本発明の実施の形態のローカルメモリ管理マクロタスクの生成の具 体例 （デイストリビューシヨン後） の説明図である。
図 1 6は、 本発明の実施の形態のテンプレートの作成手順の例を示す。
図 1 7は、 本発明の実施の形態のテンプレートがマッピングされたローカルメ モリの状態の説明図である。
図 1 8は、 本発明の実施の形態のテンプレートがマッピングされたローカルメ モリの状態の説明図である
図 1 9 A及ぴ図 1 9 Bは、 本発明の実施の形態のコードイメージの作成例 （状 態 1) の説明図である。
図 2 OA及び図 20 Bは 本発明の実施の形態のコードイメージの作成例 （状 態 2) の説明図である。
図 21 A及び図 21 Bは 本発明の実施の形態のコードイメージの作成例 （状 態 3) の説明図である。
図 22 A及び図 22 Bは 本発明の実施の形態のコードイメージの作成例 （状 態 4) の説明図である。
図 23 A及び図 23 Bは 本発明の実施の形態のコードイメージの作成例 （状 態 5) の説明図である。
図 24 A及び図 24 Bは 本発明の実施の形態のコードイメージの作成例 （状 態 6) の説明図である。
図 25 A及び図 25 Bは 本発明の実施の形態のコードイメージの作成例 （状 態 7) の説明図である。
図 26 A及び図 26 Bは 本発明の実施の形態のコードイメージの作成例 （状 態 8) の説明図である。
図 27 A及び図 27 Bは 本発明の実施の形態のコードイメージの作成例 （状 態 9) の説明図である。
図 28 A及び図 28 Bは. 本発明の実施の形態のコードイメージの作成例 （状 態 10) の説明図である。
図 29 A及び図 29 Bは. 本発明の実施の形態のコードイメージの作成例 （状 態 1 1) の説明図である。
図 3 OA及び図 30 Bは. 本発明の実施の形態のコードイメージの作成例 （状 態 1 2) の説明図である。
図 31 A及び図 31 Bは. 本発明の実施の形態のコードイメージの作成例 （状 態 1 3) の説明図である。 図 3 2 A及び図 3 2 Bは、 本発明の実施の形態のコードイメージの作成例 （状 態 1 4 ) の説明図である。
図 3 3 A及び図 3 3 Bは、 本発明の実施の形態のコードイメージの作成例 （状 態 1 5 ) の説明図である。
図 3 4 A及び図 3 4 Bは、 本発明の実施の形態のコードイメージの作成例 （状 態 1 6 ) の説明図である。 発明を実施するための最良の形態
まず、 本発明の概要を説明する。
本発明は、 コンパイラがプログラムの解析によって取得した情報に基づいて、 メモリの記憶領域を管理する。 コンパイラはプログラムをコンパイルする際に、 プログラムの情報を取得する。 具体的には、 コンパイラは、 前記プログラムで使 用されるデータの情報、 前記データが次に使用されるタイミングの情報、 前記デ ータが使用されるプロセッサの情報を、 プログラムの解析によって取得できる。 すなわち、 プログラムによってデータが使用されるタイミングを取得できる。 本 発明の第 1の特徴は、 プログラムを解析して得られた情報に基づいて、 メモリの 記憶領域の割り当てを管理することである。 ，
具体的には、 コンパイラは、 プログラム （例えば、 ネストされた各階層の処 理） の実行スケジュールの情報を持っているので、 データがいつアクセスされる かの情報を取得できる。 よって、 プログラムの実行スケジュールに基づいてメモ リの記憶領域をデータに最適に割り当てることができるので、 データの転送を最 小化することができる。
さらに、 メモリに割り当てられたデータを、 どのプロセッサが、 いつ必要とす るかの情報を取得できる。 よって、 プロセッサによる処理に影響することなく D MAコントローラによって、 データをメモリに連続的に供給 （ロード） できる。 よって、 データがメモリに供給されるのを待っために、 プロセッサが止まらない, さらに、 コンパイラは、 データがプログラムによっていつアクセスされるかの 情報を取得できるので、 既に不要となったデータ又は直ぐにはアクセスされない データを特定することができ、 DMAコントローラによって不要となったデータ 又は直ぐにはアクセスされないデータをメモリの記憶領域から掃き出す （ス ト ァ） ことができる。 この将来の情報に基づいたデータの掃き出しは、 従来用いら れていた L R U (Least Recently Used) と異なり、 最近使われていないが直ぐ に使われるかもしれないデータが掃き出されることがなく、 メモリの利用を最適 ィ匕して、 メモリ間のデータ転送を減らすことができる。
すなわち、 本発明の第 2の特徴は、 プログラムを解析して得られた情報に基づ いて、 メモリへ、 及び 又は、 メモリからデータを転送するタイミングを決める ことである。 ，
このようにメモリの記憶領域を管理するために、 メモリの記憶領域を固定サイ ズのブロックに分割して、 ブロック毎にデータを割り当てる。 記憶領域が分割さ れるブロックのサイズは、 コンパイル時に取得したプログラムの 性 （プログラ ムで使用されている配列サイズ、 配列の形状、 プログラムの実行パターン等） に 応じて適切なサイズを決定する。 また、 ブロックのサイズは整数倍 （例えば、 2 の倍数） の関係にするとよい。
すなわち、 本発明の第 3の特徴は、 プログラムを解析して得られた情報に基づ いて、 メモリの記憶領域を適切なサイズのブロックに分割して、 データを割り当 てることである。 プログラムの特性に応じて記憶領域を固定サイズのプロックに 分割することは、 ハードウェアや O S (オペレーティングシステム） では成し得 ない。 これは、 ハードウェアや O Sによって記憶領域を分割すると、 いつも決ま つたサイズで分割されてしまうからである。
さらに、 アクセスするデータの種類や範囲によって、 プログラムに使用される データのサイズが異なる場合がある、 よって、 プログラム中で使用されるデータ のサイズに適合するように、 複数のサイズのブロックを用意する。 そして、 デー タのサイズに適合するように割り当てられるプロックのサイズを変える。
さらに、 プログラムの実行時に必要となるデータ （ある瞬間にメモリに載って いなければならないデータを 「ワーキングセット」 という） の分割にあわせて、 プログラムも分割する。 例えば、 ループを 2分の 1に分割すると、 使用されるデ ータも 2分の 1になる。 本発明の第 4の特徴は、 プログラムを解析して得られた 情報に基づいて、 メモリの記憶領域にワーキングセットが載るように、 プロダラ ムの分割数を決めることである。 例えば、 プログラムの分割は、 一つの大きなル ープを分割して、 細かい単位のループを繰り返し実行する。
さらに、 多重ループでは、 通常、 多次元配列変数が使用される。 1次元アドレ ス空間を有する固定サイズのプロックに多次元配列変数を割り当てる際に、 1次 元のブロックに多次元配列テンプレートを割り当てる。 この多次元配列テンプレ ートの形状及びサイズは、 プログラムで使用される配列変数の形状及びサイズに 基づいて決定される。 本発明の第 5の特徴は、 プログラムを解析して得られた情 報に基づいて、 プロックに割り当てられるテンプレートを決定することである。 これによつて、 配列変数の添字を変換する手間やプログラムの複雑化を避けなが ら、 任意の配列をメモリ上の任意のァドレスに割り当てることができる。
なお、 以下の本発明の実施の形態では、 データの使用について具体的に説明す るが、 プロセッサによるデータの使用 （参照） の他に、 データの定義 （データを 計算してメモリへ格納すること） におけるメモリ管理も本発明の範疇である。 す なわち、 本発明は、 データの使用及び定義の両方を含むデータのアクセスについ て適用可能されるものである。
次に、 本発明の実施の形態について、 図面を参照して説明する。
図 1は、 本発明の実施の形態のシングルチップマルチコアプロセッサの構成図 である。
本発明の実施形態のシングルチップマルチプロセッサ 1 0は、 複数のプロセッ サコア （PC 0、 PC 1、 "'、 PCn) 1 6を含む複数のマルチコアチップ （C MP 0、 ·■·、 CMPm) 1 0、 複数の集中共有メモリ （C SM0、 ·'·、 C SM j ) 1 4、 入出力制御を行う複数の入出力用チップ （I/O C S P 0、 ···、 I /Ό C S P k) 1 8、 及び、 チップ間結合網 （ I n t e r CCN) 1 2を備え る。
チップ間結合網 1 2は、 既存の接続技術 （クロスバースィッチ、 バス、 マルチ ステージネットワーク等） によって実現され、 複数のプロセッサコア 1 6、 複数 の集中共有メモリ 1 4及び入出力用チップ 1 8を接続する。 集中共有メモリ 14 は、 システム中の全プロセッサコア 1 6によって共有され、 各プロセッサコア 1 6からアクセス可能なメモリである。 集中共有メモリ 1 4は、 マルチコアチップ 1 0内に備わる集中共有メモリ 28を補完する。
各マルチコアチップ 1 0は、 複数のプロセッサコア （PC) 1 6、 集中共有メ モリ （C SMZL 2 C a c h e) 28及びチップ内結合網 （ I n t r a CC N) 34を備える。 各プロセッサコア 1 6は、 CPU 20、 分散共有メモリ （D SM： distributed shared memory) 2 2、 ロー力ノレプログラムメモリ (L PM I— C a c h e) 24、 ローカルデ
一タメモリ （LDMZD— c a c h e) 26、 データ転送コントローラ （DT C) 30、 ネットワークインターフェイス （N I ) 3 2及び電力制御レジスタ (F VR) 3 6を備える。
C PU 20は、 整数演算及び浮動小数点演算が可能なものであればよく、 特に 限定されない。 例えば、 データのロード及びス トアのアーキテクチャが単純なシ ングルイッシユー R I S Cアーキテクチャの CPUを用いることができる。 また、 スーパースカラプロセッサ、 VL IWプロセッサ等も用いることができる。 分散共有メモリ （D S M) 2 2は、 デュアルポートメモリで構成されており、 データ転送コントローラ 3 0を介して、 他のプロセッサコア 1 6からデータを直 接読み書きすることができ、 タスク間のデータ転送に使用される。
ローカルプログラムメモリ （L P M) 2 4は、 スケジューラによって定められ たタスクの実行順序に従って、 実行すべき命令を他のメモリから先読みしてキヤ ッシュする。 なお、 プログラムの特徴に応じ、 通常のデータキャッシュメモリと しても使用でき、 ヒットミスを少なくするためのキャッシュとしても使用される。 ローカルデータメモリ （L DM) 2 6は、 各プロセッサコア 1 6内だけでァク セスできるメモリであり、 各プロセッサコア 1 6に割り当てられたタスクで使用 されるデータ （例えば、 配列変数） を格納する。 また、 ローカルデータメモリ 2 6は、 L 1データキヤッシュに切り替えることができる。
データ転送コントローラ （D T C ) 3 0は、 公知の DMAコントローラによつ て構成され、 スケジューラによって定められたタイミングに従って、 実行すべき 命令や使用されるデータをメモリ間で転送する。 具体的には、 自又は他のプロセ ッサコア 1 6上のローカルメモリ 2 6、 自及び他のプロセッサコア 1 6上の分散 共有メモリ 2 2、 自及び他のマルチコアチップ 1 0上の集中共有メモリ 2 8、 及 び、 他のチップに設けられた集中共有メモリ 1 4間でデータを転送する。
なお、 ローカルデータメモリ 2 6とデータ転送コントローラ 3 0との間の破線 は、 シングルチップマルチプロセッサの用途に応じて、 データ転送 ントローラ 3 0がローカルデータメモリ 2 6にアクセスできるように構成してもよいことを 示している。 このような場合、 C P U 2 0力 転送指示を、 ローカルデータメモ リ 2 6を介して、 データ転送コントローラ 3 0に与えることができる。 また、 C P U 2 0が、 転送終了後に転送されたデータをチヱックすることができる。
C P U 2 0は、 ローカルデータメモリ 2 6、 分散共有メモリ 2 2又は専用のバ ッファ （図示省略） を介して、 データ転送コントローラ 3 0へデータ転送を指示 する。 また、 データ転送コントローラ 3 0は、 ローカルデータメモリ 2 6、 分散 共有メモリ 2 2又は専用のバッファ （図示省略） を介して、 C P U 2 0へデータ 転送の終了を報告する。 このとき、 どのメモリ又はバッファを使うかはプロセッ サの用途に応じて、 プロセッサの設計時に決められる。 又は、 複数のハードゥエ ァ的な方法を用意し、 プログラムの特性に応じて、 コンパイラ又はユーザがソフ トウエア的に使い分けられるようにしてもよい。
データ転送コントローラ 3 0へのデータ転送指示 （例えば、 何番地から何バイ トのデータを、 どこにストアし又はロードするか、 及び、 データ転送のモード (連続データ転送、 ストライド転送等） 等） は、 コンパイラが、 データ転送命令 をメモリ又は専用バッファに格納して、 プログラムの実行時にはどのデータ転送 命令を実行するかの指示のみを出すようにして、 データ転送コントローラ 3 0を 駆動するためのオーバへッドを削減することが望ましい。
ネットワークインタフェース （N I ) 3 2は、 各マルチコアチップ 1 0内のプ 口セッサコア 1 6の間を通信可能にするために、 チップ内結合網 3 4に接続され る。 チップ内結合網 3 4はチップ間結合網 1 2に接続されている。 プロセッサコ ァ 1 6は、 チップ間結合網 1 2によって、 他のマルチコアチップ 1 0内のプロセ ッサコア 1 6と通信することができる。
プロセッサコア 1 6は、 チップ內結合網 3 4を介して、 集中共有メモリ 1 4に 接続される。 集中共有メモリ 1 4は、 チップ間結合網 1 2に接続される。
なお、 ネットワークインタフェース 3 2は、 チップ内接続ネットワーク 3 4を 介さずに、 チップ間結合網 1 2とを直接接続することもできる。 このような構成 は、 システム中の全プロセッサコア 1 6が、 各チップ上に分散して配置された集 中共有メモリ 2 8及び分散共有メモリ 2 2に、 平等なアクセスを可能にする。 ま た、 直結されたパスを設けることによって、 チップ間のデータの転送量が多い場 合でも、 システム全体のデータ転送能力を高めることができる。 電力制御レジスタ （F V R) 3 6は、 プロセッサコア 1 6の動作周波数及び動 作電圧を制御するために、 プロセッサコア 1 6に供給される電源電圧やクロック 周波数が設定される。 なお、 図示したように、 電力制御レジスタは、 プロセッサ コア 1 6だけでなく、 マルチコアチップ 1 0、 チップ間結合網 1 2、 集中共有メ モリ 1 4、 入出力用チップ 1 8、 集中共有メモリ 2 8及びチップ内結合網 3 4に も設けられ、 これらの各構成の動作周波数及び動作電圧を制御するためのデータ が格納される。
図 2は、 本発明の実施の形態のマルチグレイン並列処理を説明する図である。 マルチグレイン並列処理とは、 粗粒度並列性、 中粒度並列性及び近細粒度並列 性を階層的に利用する並列処理方式である。 粗粒度並列性とは、 サブルーチン間、 ループ間及び基本ブロック間の並列性であり.、 中粒度並列性とは、 ループのイタ レーシヨン間の並列性であり、 近細粒度並列性とは、 ステートメント間及び命令 間の並列性である。 このマルチグレイン並列処理によって、 従来行われてきた局 所的かつ単一粒度の並列化 （ループの並列化及び命令レベルの並列化等） とは異 なり、 プログラム全域にわたるグローバルかつ複数粒度にわたるフレキシブルな 並列処理が可能となる。
マルチグレイン並列処理においては、 以下の手順で並列化処理が行われる。
1 ) ソースプログラムからマクロタスクを生成。
2 ) マクロタスク間の制御フロー及びデータ依存を解析しマクロフローグラフを 生成。
3 ) 最早実行可能条件解析によってマクロタスクグラフを生成。
以下、 この手順を具体的に説明する。
単一プログラム中のサブルーチン、 ループ、 基本ブロック間の並列性を利用す るマルチグレイン並列処理では、 ソースとなる、 例えばフォートランプログラム を、 粗粒度タスク （マクロタスク） として、 繰り返しブロック （R B ： repetition block) 、 サブノレ一チンブロック ( S B ： subroutine block) 、 及び 疑似代入文ブロック （B P A ： block of pseudo assignment statements) の 3 種類のマクロタスク （MT ) に分解する。 繰り返し
ブロックは、 各階層での最も外側のループである。
また、 疑似代入文プロックは、 スケジューリングオーバヘッド及び並列性を考 慮して、 結合及び/又は分割された基本ブロックである。 ここで、 疑似代入文ブ ロックは、 基本的には通常の基本プロックであるが、 並列性抽出のために単一の 基本ブロックを複数に分割してもよい。 また、 一つの疑似代入文ブロックの処理 時間が短く、 ダイナミックスケジューリング時のオーバへッドが無視できない場 合には、 複数の疑似代入文ブロックを結合して一つの疑似代入文ブロックを生成 する。
最外側ループである繰り返しブロックが D o a 1 1ループである場合は、 ルー ブインデクスを分割することによって、 複数の部分 D o a 1 1ループに分割し、 分割された D o a 1 1ループを新たに繰り返しブロックと定義する。 繰り返しブ ロックが n o n— D o a 1 1ループである場合は、 繰り返しブロック内の並列性 に、 階層的マクロデータフロー処理を適用するとよい。
サブルーチンブロックは、 可能な限りインライン展開するとよい。 しかし、 コ 一ド長を考慮した結果、 効果的にインライン展開ができないサブルーチンは、 そ のままサブルーチンプロックとする。 この場合、 サブルーチンブロック內の並列 性に、 階層的マクロデータフロー処理を適用するとよい。
次に、 マクロタスク間の制御フローとデータ依存を解析し、 図 3に示すような マクロタスクグラフ （MT G)
を作成する。 マクロフローグラフでは、 マクロタスク （M T ) 間の制御フローを 表している。 マクロタスクグラフを作成する際は、 マクロタスク間の制御依存及 びデータ依存を同時に解析し、 各マクロタスクが最も早く実行できる条件 （最早 実行可能条件） の形でマクロタスク間の並列性を検出する。 。 また、 この最早実 行開始条件をグラフで表現したものがマクロタスクグラフである。
そして、 コンパイラは、 マクロタスクグラフ上のマクロタスクを、 プロセッサ クラスタ （コンパイラ又はユーザによって定義されるプロセッサのグループ） へ 割り当てる。 このタスクの割り当てには、 コンパイル時に割り当てるスタティッ クスケジューリングと、 実行時に割り当てるダイナミックスケジューリングがあ る。 ダイナミックスケジューリングの場合、 ダイナミック C Pアルゴリズムを用 いてダイナミックスケジユーリングコ一ドを生成し、 生成されたダイナミックス ケジユーリングコードをプログラム中に埋め込む。 なお、 ダイナミックスケジュ 一リング時には、 実行時までどのマクロタスクがどのプロセッサで実行されるか 分からないので、 マクロタスク間で共有されるデータは全プロセッサから等距離 に見える集中共有メモリ 1 4に割り当てるとよい。
マルチグレイン並列化では、 マク口データフロー処理によってプロセッサクラ スタに割り当てられるループブロックは、 そのループブロックが D o a 1 1ルー プ又は D o a c r o s sループである場合、 プロセッサクラスタ内の複数のプロ セッサコア 1 6によって処理がされるように、 イタレーションレベルでループが 分割され、 ループが並列化される。
ループの再構築には、 ステートメントの実行順序の変更、 ループディス トリビ ユーシヨン、 ノードスプリツティングスカラ ェクスパンシヨン、 ループインタ —チェンジ、 ループアンローリング、 ストリップマイニング、 アレイプライベタ ィゼーシヨン、 及び、 ュニモジュラ一変換 （ループリバーサル、 パーミュテーシ ヨン、 スキュ一^ ング等） 等の従来の技術がそのまま利用できる。
また、 ループ並列処理が適用できないループには、 近細粒度並列処理、 又は、 ループのボディ部を階層的にマクロタスクに分割する粗粒度タスク並列処理を適 用する。 プロセッサクラスタに割り当てられるマクロタスクが疑似代入文プロックであ るか、 又は、 ループ並列化も階層的なマクロデータフロー処理も適用できないル 一プブロックの場合は、 疑似代入文ブロック内のステートメント又は命令を近細 粒度タスクとして、 プロセッサクラスタ内のプロセッサで並列処理する。
マルチプロセッサシステムでの近細粒度並列処理では、 プロセッサ間の負荷バ ランスだけでなくプロセッサ間のデータ転送を最少にするように、 近細粒度タス クをプロセッサにスケジユーリングすることによって、 効率よい並列処理を実現 する。 さらに、 この近細粒度並列処理で要求されるスケジューリングでは、 近細 粒度タスク間にはデータ依存による実行順序の制約があるため、 タスクの実行順 序が問題となる。
このようにして生成された近細粒度タスクグラフを各プロセッサにスタティッ クにスケジューリングする。 この際、 スケジューリングアルゴリズムとして、 デ ータ転送オーバへッドを考慮し実行時間を最小化するために、 公知のヒユーリス ティックアルゴリズム （C P /D T ZM I S F法、 C P Z E T F ZM I S F法、 E T F Z C P法、 又は、 D T Z C P法） を適用し最適なスケジュールを決定する。 スケジユーリングの終了後、 コンパイラはプロセッサコアに割り当てられたタ スクの命令列を順番に並べ、 データ転送命令や同期命令を必要な箇所に挿入する ことによって、 各プロセッサ用のマシンコードを生成する。 このとき、 挿入され るデータ転送命令は、 マクロタスク間の制御依存及びデータ依存よつて、 ロー力 ルメモリ 2 6にデータを格納する及びローカルメモリ 2 6からデータを掃き出す タイミングを決められる。
近細粒度タスク間の同期にはバージョンナンバー法を用い、 同期フラグの受信 は受信側プロセッサコアのビジーウェイトによって行うとよい。 ここで、 データ 転送指示及び同期フラグの設定は、 送信側のプロセッサが受信側のプロセッサコ ァ 1 6上の分散共有メモリ 2 2に直接書き込むことによって、 低オーバヘッドで 行うことができる。
<口一力/レメモリ管理〉
図 4は、 本発明の実施の形態のローカルメモリ管理の概要を説明する図である。 プログラムは、 一般に、 サブルーチン及び多重ループによって複数の階層に分 かれている。 よって、 プログラムの実行に必要なデータをどのタイミングで転送 するかを考えることが重要である。 例えば、 ループにおいては、 ループの前後で データを転送するとよい。 具体的には、 ループの実行前にデータをローカルメモ リに転送し、 ループの実行後にデータをローカルメモリから転送する。 そして、 ループ内ではデータをローカルメモリに載せたままで、 ループが実行できるよう にデータを配置するとよレ、。 このように、 データをローカルメモリに載せたまま で実行できるプログラムの単位を 「ローカルメモリ管理マクロタスク」 とレヽう。 すなわち、 ローカルメモリ管理マクロタスクで扱うデータは必ずローカルメモ リ上に載るサイズのデータである。 また、 ローカルメモリ管理マクロタスクの実 行に必要なデータは、 ローカルメモリ管理マクロタスクの実行前又は実行後の適 切なタイミングで転送 （ロード、 ストア） される。 さらに、 タスク内でデータの 転送が発生しないように、 ローカルメモリ管理マクロタスクを決定する。
そして、 必要な全てのデータをローカルメモリに載せることができないループ は、 そのループの中で、 使用される全てのデータがローカルメモリに載る部分を ローカルメモリ管理マクロタスクと定義する。 すなわち、 必要な全てのデータが ローカルメモリに載るようにプログラムを分割し、 ローカルメモリ管理マクロタ スクを決める。 このようにローカルメモリ管理マクロタスクを決めて、 ローカル メモリ管理マクロタスクの実行に必要なデータは、 マクロタスクの実行前後で転 送 （ローカルメモリへのロード、 ローカルメモリから集中共有メモリへのス ト ァ） する。 このため、 マクロタスク内において、 データの転送が発生しない。 以上、 ループについて説明したが、 プログラム中のベーシックブロック及びサ プル一チンでも同じである。 なお、 サブルーチンについては、 後述する例外があ る。
また、 本明細書では、 ローカルメモリの管理について説明するが、 容量に制限 のある （記憶容量が使用されるデータより少ない） メモリであれば、 本発明を適 用することができる。 例えば、 ローカルメモリ 26の他、 プロセッサコア 16内 の分散共有メモリ 22、 オンチップの集中共有メモリ 28及ぴオフチップの集中 共有メモリ 14にも、 本発明を適用することができる。
以上説明したプログラムを分割して、 ローカルメモリ管理マクロタスクを生成 する方法について、 図 4を参照して説明する。
ローカルメモリに配列変数の要素が 1000個載ると仮定する。 また、 図 4に 示すように、 このプログラムは変数 i、 jによる 2重ループが含まれている。 ル ープ中で配列変数 A [1 : 30, 1 : 20] は 600要素が使用され、 配列変数 B [1 ： 30] は 30要素が使用され、 配列変数 C [1 : 30， 1 : 20] は 6 00要素が使用される。 合計すると、 このループでは 1230個の配列要素が使 用される。 よって、 全てのデータをローカルメモリに載せて、 このループを実行 することができない。
そこで、 本発明の実施の形態のコンパイラは、 変数 iのループを、 i = l〜l 0及び、 i =l 1〜20の二つのループに分割する。 すると、 各ループでァクセ スされるデータは 630要素になるので、 全てのデータを,ローカルメモリに載せ たまま、 ループを最初から最後まで実行することができる。 この分割されたルー プが、 ローカルメモリ管理マクロタスクである。 そして、 このマクロタスクの実 行前後に必要なデータがロード及びストァされる。
データのローカルメモリへの転送 （ロード） はマクロタスクの実行直前でなく ても、 他のデータのブロックへの割り当てを考慮して、 もっと前の時点で実行し てもよレ、。 このように、 配列変数 （データ） が使用されるマクロタスクの実行開 始前までの任意のタイミングで、 そのマクロタスクで使われる配列変数をメモリ にロードすることを 「プレロード」 という。 このプレロードは、 他のマクロタス クの実行中であっても、 そのデータがロードされるべきブロックが空いていれば、
DMAによってデータの転送が可能である。 このように、 ブロックの空き状態に よって、 マクロタスクの実行前でもデータをロードすることができ、 プログラム 実行までに必要なデータを揃えることができる。 このため、 メモリに必要なデー タがロードされていないことによるプロセッサの待ち時間を削減することができ る。
また、 データのローカルメモリからの転送 （ストア） はマクロタスクの実行終 了直後でなくても、 他のデータのプロックへの割り当てを考慮して、 もっと後の 時点で実行してもよい。 このように、 配列変数 （データ） が使用されるマクロタ スクの終了後の任意のタイミングで、 そのマクロタスクで使われた配列変数をメ モリにロードすることを 「ポストストア」 とレヽう。 このポストストアは、 他のマ クロタスクの実行中であっても、 DMAによってローカルメモリから集中共有メ モリへのデータの転送が可能である。 このように、 任意のタイミングでデータを ストァすることによって、 DMAの負荷がマクロタスクの実行前後に集中するこ とを避けることができる。
次に、 前述したサブルーチンにおける例外について説明する。
前述したように、 一般的には、 口一カルメモリ管理マクロタスク内でデータの 転送が発生することはない。 しかし、 サブルーチンがローカルメモリ管理マクロ タスクとなった場合、 及び、 内部でサブルーチンを呼び出しているループがロー カルメモリ管理マクロタスクとなった場合の二つの場合には、 サブルーチン内に おいてデータを転送 （ロード及び Z又はストア） する必要がある。
具体的には、 サブルーチンの開始時に、 サブルーチン呼び出し元で使用してい た配列変数をロードする。 例えば、 フォートランにおけるセーブ、 コモン及びデ ータ変数、 C言語におけるスタティック変数及びグローバル変数を使用すると、 これらの変数は呼び出し元では管理することができない。 よって、 マクロタスク 内のサブルーチンの処理が終わったら使用された変数を共有メモリに転送する必 要がある。 サブルーチン終了時に変数をローカルメモリから読み出して共有メモ リに書き込まないと、 データの整合性がとれないからである。 なお、 マクロタス クは一つの物理プロセッサによって実行されるので、 マクロタスク内でデータを ロード及びストアしても正しい値が保証される。
<記憶領域の分割〉
図 5は、 本発明の実施の形態のメモリの記憶領域の分割の状態を説明する図で ある。
本発明で、 記憶領域の管理の対象となるメモリは、 ローカルメモリ及び分散共 有メモリである。 これらの管理対象のメモリの記憶領域は、 複数のブロック （サ ブブロック等も含む） 1 0 1〜1 0 4に分割されている。
図 5に、 ローカルメモリの記憶領域を分割したブロックを示す。 ブロック 1 0 1は、 ローカルメモリの記憶領域が 2のべき乗分の 1 (図示する状態では 8分の 1 ) に分割された固定長の領域である。 更に、 ブロック 4〜7は、 ブロックサイ ズの半分のサブブロック 8〜 1 5 ( 1 0 2 ) に分割されている。 さらに、 サブブ ロック 1 2〜 1 5は、 サブブロックサイズの半分のサブサブブロック 2 4〜 3 1 ( 1 0 3 ) に分割されている。 さらに、 サブサブブロック 2 8〜3 1は、 サブサ ブブロックサイズの半分のサブサブサブプロック 5 6〜6 3 ( 1 0 4 ) に分割さ れている。
ブロック 1 0 1、 サブプロック 1 0 2、 サブサブプロック 1 0 3、 サブサブサ ブブロック 1 0 4は独立して管理される。 コンパイラは、 メモリの各アドレス空 間に任意のサイズのプロックを設定することができる。 コンパイラは、 コンパィ ルされるプログラムに応じて適切なサイズのブロック等を設定する。 すなわち、 大きいデータを扱うプログラムでは大きなサイズのブロックを、 小さいデータを 扱うプログラムでは小さなサイズのプロックを用意することによって、 ローカル メモリを無駄なく、 かつ効率よく使用することができる。
なお、 ブロックの管理を容易にするため、 サブブロック等も、 記憶領域の先頭 アドレスから通し番号を付与する。 このため、 一つのアドレスによって示される 領域が、 複数のブロック、 サブブロックに含まれる。 例えば、 ブロック 0、 サブ ブロック 0〜 1、 サブサブプロック 0 ~ 3、 及びサブサブサブプロック 0〜 7は、 同じメモリ空間 （アドレス 0〜 1 2 7 ) を示す。 このように、 複数種類のブロッ クをメモリ空間の同じアドレスに設定することによって、 随時、 適切な種類のブ ロック等を使用するようにメモリを管理することができる。
このように設定された、 サブプロックのサイズはブ口ックのサイズの 1 2で あり、 サブサブブロックのサイズはブロックのサイズの 1 / 4であり、 サブサブ サブブロックのサイズはブロックのサイズの 1ノ 8となるように分割されている。 つまり、 メモリの記憶領域は、 サイズが 2のべき乗の関係 （隣接するサイズのブ ロックと 2倍の関係） にある複数のサイズのプロックに分割され、 分割された複 数のサイズのブロックが記憶領域として提供される。
なお、 ブロックサイズは、 コンパイラがプログラムをコンパイルする際に取得 したプログラムの情報によつて決定されるので、 プログラム実行開始から終了ま での間変更されない。 し力 し、 コンパイラが、 別のプログラムをコンパイルする と、 コンパイル対象のプログラムの特性に適合するように、 ブロックの数及びサ ィズは異なってくる。 すなわち、 本発明のローカルメモリの記憶領域の管理単位 となるブロックは、 完全に固定されたサイズではなく、 コンパイラがプログラム を解析した情報に基づいて、 プログラムで使用されるデータサイズに最適なブ口 ックサイズを決めることができる。 ブロックサイズはプログラム内では固定だが、 プログラム毎に最適なブロックサイズを選択する。 なお、 プログラム実行中にブロックサイズを変えてもよい。 具体的には、 プロ グラムのあるステップまでは大きな配列データを使ったが、 あるステツプ以後は 小さなスカラーデータ （1次元変数） を使うときは、 配列データの使用終了時に ブロックを分割してサブブロックにしてもよレ、。 また、 テンプレートの割り当て を変えることによって、 ブロックに載せられる配列変数のサイズを変更すること ができる。 テンプレートのブ口ックへの割り当ては後述する。
本発明では、 一つのローカルメモリ管理マクロタスクで使用される全てのデー タがーつのブロックに格納できるように、 ブロックサイズが決定される。 換言す ると、 プロックのサイズによって、 ローカルメモリ管理マクロタスクのサイズが 定まる。 なお、 定められたブロックサイズにデータを出し入れするタイミングは、 その後、 マクロタスクに実行タイミングに基づいて、 スケジューラによって決め られる。
このようにして、 口一カルメモリの記憶領域を複数のサイズのプロックに分割 することによって、 ローカルメモリ管理マクロタスクにおいて使用されるデータ に最適なサイズのブロックに、 必要なデータがロードされる。 また、 ローカルメ モリの記憶領域を固定サイズの領域で管理することによって、 可変サイズの領域 で管理する場合に生じる断片化 （フラグメンテーション） の問題を回避すること ができる。
図 4に示した分割したループの例では、 配列変数 Aはローカルメモリの一つの ブロックに収まる。 また、 配列変数 Bは一つのサブサブブロックに収まる。 換言 すれば、 ブロックのサイズは、 コンパイラによって、 プログラムの性質に応じて 決められる。 より具体的には、 配列変数 Aがローカルメモリの一つのブロックに 収まるようにブロックサイズが決められ、 ループが分割される。 そして、 通常は、 ブロックサイズはコンパイル対象のプログラムの開始時から終了時までは変更さ れない。 <データのロード及びストァ〉
次に、 ブロックへのデータの書き込み （ロード） 、 読み出し （ストア） 、 及び、 プロックの割り当てについて説明する。
図 5に示すように記憶領域が分割されたメモリには、 ローカルメモリ管理マク 口タスクにおいて使用されるデータがロードされる。 まず、 スケジューラは、 デ ータをロードするメモリ力 ローカルメモリか分散共有メモリかを決める。 この とき、 複数のプロセッサコアによって共有されるデータは分散共有メモリにロー ドするとよい。
次に、 スケジューラは、 必要なデータが既にロードされているブロックがある 場合、 そのブロックにロードされているデータをそのまま使用する。 一方、 必要 なデータがいずれのブロックにもロードされていない場合、 空いているブロック を当該ロードされるデータに割り当て、 割り当てられたプロックに必要なデータ をロードする。 さらに、 空いているブロックがなければ、 掃き出し優先度の最も 高いデータをローカルメモリ 2 6から読み出して、 集中共有メモリ 2 8又は 1 4 に書き込み、 空きブロックとなった記憶領域に必要なデータをロードする。
図 6は、 本発明の実施の形態のメモリの掃き出し優先度を説明する図であり、 横軸に時間の経過を示す。
本発明の実施の形態では、 掃き出し優先度は以下の順で決められる。
1 ) 以後アクセスされないデータ。
2 ) 他プロセッサでアクセスされるが、 自プロセッサではアクセスされないデー タ。
3 ) 再度自プロセッサで使用されるが、 先の時間で使用されるデータ。
4 ) 自プロセッサですぐに使用されるデータ。
以後アクセスされないデータは、 例えば、 新たに再計算されてしまっている変 数である。 このような既に死んでいる変数は残しておく必要がないため、 掃き出 し優先度は一番高くなる。 他のプロセッサでアクセスされるが、 今後自プロセッ サでアクセスされないデータは、 そのデータを必要とするプロセッサコア 16の 分散共有メモリ 22に転送するとよいので、 次に掃き出し優先度が高くなる。 他 プロセッサでアクセスされるデータは直ぐに分散共有メモリ 22へ転送すればよ いが、 他のプロセッサコア 16のメモリの状況によって、 すぐに転送できない場 合には、 少し時間をずらしてから分散共有メモリ 22へ転送する力、 集中共有メ モリ 28又は 14へ転送する。 このようにローカルメモリ 26からのデータの転 送タイミングに自由度を持たせるために、 アクセスされないデータより掃き出し 優先度を低く設定している。
最後に、 再び自プロセッサでアクセスされるデータについては、 次に使用され るまでの時間によつて優先度を決める。 そのデータが使用される時間が先である 程、 掃き出し優先度は高く、 すぐ近くで使用されるデータは掃き出し優先度を低 くし、 なるべくメモリに載ったまま残るようにする。
図 6を参照して、 時間の経過と共にメモリの掃き出し優先度について説明する。 図 6では、 現在、 プロセッサコア 0 (PC0) で実行されているローカルメモリ 管理マクロタスクにおいて、 配列変数 A、 B、 C及び Dがローカルメモリにロー ドされている状態を考える （1001) 。
このローカルメモリ管理マクロタスクでは、 始め、 プロセッサコア 0 (PC 0) で、 配列変数 Aを定義し （De f A) 、 配列変数 Aを使用している （10 02) 。
次に、 プロセッサコア 1 (PC 1) で、 別の配列変数 Aを定義した （100 3) 。 すると、 PC 0のローカルメモリにロードされている配列変数 Aは既に変 わっているので、 今後アクセスされることはない。 よって、 掃き出し優先度が最 高位になる。 キャッシュのコヒーレンス制御と同様に、 整合性がとれないデータ は、 不要なデータと判断すればよいからである。 次に、 後に実行されるべきマクロタスクを検討する。 配列変数 Bは、 他のプロ セッサ （PC 1) で使用される （1004) 。 配列変数 C及び Dは、 自プロセッ サ （P C 0) で使用される （1005、 1006) 。 よって、 配列変数 Bの掃き 出し優先度は、 配列変数 C及び Dの掃き出し優先度より高くなる。
配列変数 Cと配列変数 Dを比較すると、 配列変数 Dの方が配列変数 Cより先に 使用される。 よって、 配列変数 Cの掃き出し優先度は、 配列変数 Dの掃き出し優 先度より高くなる。 なお、 配列変数 C及び Dは、 後に利用されるので、 集中共有 メモリ CSMに一旦書き戻して、 次に必要になるときにロードすればよい。
このため、 掃き出し優先度は A、 B、 C、 Dの順となる。
図 7、 本発明の実施の形態のメモリにロードされている変数の推移を説明する 図である。
図 7は、 一つのプロセッサコア上で、 二つのロー力ノレメモリ管理マクロタスク (MT 1、 MT 2) が含まれるプログラムが一つの階層で実行される場合に、 プ ログラムの実行開始前のメモリの状態を、 マクロタスク 1 (MT 1) の実行終了 時のメモリの状態、 マクロタスク 2 (MT2) の実行開始時のメモリの状態、 及 び、 マクロタスク 2 (MT2) の実行終了時のメモリの状態を示す。 なお、 ロー カルメモリの記憶領域は、 図 5で示したように分割されている。
マクロタスク 1 (MT 1) の実行開始前には、 全てのメモリの記憶領域 （プロ ック） は、 空き状態である （101 1) 。 そして、 マクロタスク 1の開始時には、 マクロタスク 1で必要とされるデータ （配列変数 A、 B、 C、 D、 E、 F) にブ ロックが割り当てられ、 各配列変数がメモリにロードされる。 その後、 マクロタ スク 1による処理が開始する。 具体的には、 宣言文 d e f Aによって、 配列変 数 Aがブロック 0に割り当てられる。 同様に、 配列変数 Bがブロック 1に割り当 てられ、 配列変数 Cがブロック 2に割り当てられ、 配列変数 Dがブロック 3に割 り当てられ、 配列変数 Eサブブロック 8に割り当てられ、 配列変数 Fがサブプロ ック 9に割り当てられる。
マクロタスク 1の実行終了時には、 各配列変数がブロックにロードされている ( 1 0 1 2 ) 。
マクロタスク 2 (MT 2 ) の実行開始時には、 マクロタスク 2で使用される全 てのデータがメモリにロードされている必要がある。 マクロタスク 2では、 配列 変数 A、 B、 C、 G、 E、 H、 I及び Jが使用されるので、 4個のブロック及び 4個のサブブロックが必要である。 必要な配列変数のうち、 配列変数 A、 B、 C 及び Eは、 既にローカルメモリにロードされているので、 マクロタスク 2の実行 時に新たにロードすべき配列変数は、 配列変数 G、 H、 I及び Jである。 このう ち、 配列変数 Hは、 マクロタスク 2の実行開始前にサブブロック 1 0にプレロー ドされている。 また、 サブブロック 1 1は空いている。 よって、 マクロタスク 2 の実行開始の段階で 1個のブロック及び 1個のサブブロックを空ける必要がある。 そこで、 必要なデータをロードするブロックを確保するために、 掃き出し優先 度に従って配列変数 Dをプロック 3から掃き出し、 配列変数 Fをサブプロック 9 から掃き出す。 これによつて、 1個の空きブロック及び 1個の空きサブブロック を確保する （1 0 1 4 ) 。
このため、 マクロタスク 1の実行終了後、 マクロタスク 2の実行前には、 配列 変数 D及び Fの集中共有メモリへの転送、 配列変数 Hのローカルメモリへの転送 が必要となる （1 0 1 3 ) 。
マクロタスク 2の実行開始前に、 配列変数 Gがブロック 3に割り当てられ、 配 列変数 Iがサブプロック 9に割り当てられ、 配列変数 Jがサブプロック 1 1に割 り当てられる。 その後、 マクロタスク 2が実行され、 配列変数 G、 I及び Jがマ クロタスク 2で使用される （1 0 1 4 ) 。
このように、 前述した優先度によって、 メモリからデータを分散共有メモリ又 は集中共有メモリにストアするので、 従来の L R Uとは異なり、 メモリの利用を 最適化することができ、 メモリ間のデータ転送を減らすことができる。 すなわち、 従来の L R Uによると、 最近使われていないが直ぐに使われるかもしれないデー タもメモリから転送されてしまう。 しかし、 本発明のように、 コンパイラが取得 した情報によると、 そのデータが次に使用されるタイミングが分かり、 メモリを 最適に使用することができる。
<ループの分割〉
次に、 図 8から図 1 1を参照して、 ループの分割手順の具体例を説明する。 ループの分割は、 複数のループを見て整合分割を行う。 多重化されたループで 一番広くアクセスする範囲を解析して、 グロ一バルインデックスレンジとする。 すなわち、 ローカルメモリをアクセスすればよい範囲と、 隣のプロセッサと通信 をしなければいけない範囲とがあるので、 データのアクセス範囲を解析し、 これ を切り分ける。 このため、 プログラムの構造を解析し、 ターゲットループグルー プ （T L G) を選択する。 本実施形態では、 従来のコンパイラによる並列的なル ープを連続的に実行するための解析と異なり、 複数のループにわたってどのよう にメモリがアクセスされるかを解析する。
ここで、 二つのループが整合するとは、 以下の全ての条件を満たすことである。 1 ) 各ループが、 D o a 1 1ループ、 R e d u c t i o nループ、 ループキヤリ ッドデータ依存 （リカレンス） による S e q u e n t i a lループのいずれかで ある。
2 ) ループ間に配列変数のデータ依存が存在する。
3 ) 各ループのループ制御変数が同一配列の同じ次元の添字式で使用されており、 次元の配列添字がループ制御変数の一次式で表されている。
4 ) ループ間にデータ依存を導く各配列に対して、 配列添字中のループ制御変数 係数のループ間での比が一定である。
このとき、 選択されていない単一のループも全てターゲットループグループと し、 ターゲットループグループの入れ子を許容し、 間接参照を含むループも選択 する。 すなわち、 タ一ゲットループグループに選ばれたループの内側にもループ が存在していた場合、 内側のループに対してもターゲットループグループを生成 する。 また、 他のループと整合可能でないループは、 そのループのみでターゲッ トループグループを成す。
ターゲットループグループとは、 マクロタスク上でループ整合分割が適用可能 な繰り返しブロック （RB) の集合であり、 マクロタスクグラフ上で直接データ 依存先行、 後続関係を持つ繰り返しブロックの集合である。 これは、 実行時のコ ス ト （メモリ及びプロセッサ等のリソースの消費） が大きい繰り返しブロックと その繰り返しブロックに直接データ依存先行、 後続関係を持つ繰り返しブロック は大きなデータを扱うので、 分割の効果が高いためである。 これによつて、 ルー プ間で同じデータを使う場合に、 同じ領域を使い回して、 キャッシュミスを防止 することができる。
具体的に、 図 8に示すプログラムでは、 変数 iによる二つのループが TLG 1 となり、 各 TLG 1内の変数 j によるループが TLG 1 - 1及び TLG 1— 2と なる。 さらに、 TLG 1— 1内の変数 kによるループが TLG 1 _ 1— 1なり、 TLG 1— 2内の変数 kによるループが TLG 1— 2— 1なる。
次に、 図 9に示すように、 TLG集合を生成する。 TLGが以下の生成条件の 全てを満たす場合に、 TLG集合が生成される。
1) 少なくとも一つ以上共有配列を持つ （依存関係も考慮される） 。
2) 共有配列の整合次元が全て一致する。
3) サブルーチンを跨った場合は、 共有配列の形状が一致する。
次に、 図 10に示すように、 分割候補 TLG集合を生成する。 これは、 入れ子 になった TLGがある場合、 コストが最大の TLG集合を選択し、 選択された T LG集合を分割候補とする。 その後、 分割候補 TLG集合毎に G I Rを計算する。 このようにすると、 プログラム中の全てのコードをカバーすることができる。 具 体的には、 TLG集合 1が分割候補 TLG集合 1となり、 G I Rは [1 : 10] となる。
次に、 分割基準領域を決定する。 分割基準領域は、 各 TLG集合で使用される データを収めなければならない記憶領域である。 具体的には、 分割候補 TLG集 合で使用されるデータサイズの比を計算する。 ここで、 3個の分割候補 TLG集 合があり、 集合 1で使用されるデータサイズが 300 k、 集合 2で使用されるデ ータサイズが 200 k、 集合 3で使用されるデータサイズが 100 kであれば、 データサイズの比は 3 ： 2 ： 1になる。
この比に基づいて、 最小メモリ領域 （ローカルメモリと分散共有メモリとのう ち、 容量が小さいもの） を各分割候補 TLG集合に割り当てる。 具体的には、 分 割候補 TLG集合で使用されるデータが最小メモリ領域よりも小さいの領域に収 まるように、 分割候補 TLG集合を分割する。 なお、 実際には、 この時に割り当 てられた領域以外の領域にも分割候補 T L G集合で使用されるデータを載せるこ とができるが、 分割用の目安としてこのような処理をする。
これによつて、 分割後の各分割候補 T L G集合で使用されるデータを同時に口 一カルメモリに載せることが可能となる。 なお、 実際にデータをメモリに載せる かは、 スケジューリング及びメモリ管理ルーチンによって決まる。
次に、 ブロックサイズを決定する。
まず、 コス トが最も大きい分割候補 TLG集合を、 ブロックサイズを決定する 基準にする。 但し、 多重分割が必要となった場合、 分割候補 TLG集合には最大 分割数が採用される。 ここで、 最大分割数とは、 割り当てられるプロセッサダル ープ （PG) 内のプロセッサコア （PC) の構成と、 並列処理によるオーバーへ ッドを考慮した場合の最大の分割数である。 CPUの数が一つである場合、 最大 分割数は、 ループのイタレーシヨン数である。 以後、 多重分割が必要となった T LG集合は、 分割候補 TLG集合に選ばない。 そして、 再び、 分割候補 TLG集 合を生成する。
具体的には、 図 1 1に示すように、 TLG集合 1は最大分割数で分割されるの で、 次の TLG集合 2が分割候補 TLGに選択される。 分割候補となった TLG 集合 2は、 G I Rは [1 ： 20] である。
次に、 プロックサイズの決定手順について説明する。
まず、 ブロックサイズ決定前処理を実行する。 基準となる分割候補 TLG集合 でアクセスするデータが、 分割基準領域よりも小さいサイズになる分割数を計算 する。 ここではアクセスされるデータのサイズのみを考え、 間接的に参照される データのアクセスについては考慮しない。 分割数は、 プロセッサグループの数の 整数倍となるように選択する。 求められた分割数で T L G集合内の各ループの分 割を試行する。
具体的には、 最外ループ （ iのループ） で 4分割を試行する。 アクセスされる 配列変数 A及び Bのサイズは、 [k， j， i ] = [l : 30， 1 : 20， 1 ： 3] である。 総データサイズは、 30 X 20 X 3 X 2 = 3600になる。
次に、 ブロックサイズを決定する。
分割後の配列アクセス範囲に基づいて、 TLG集合中の全てのローカル配列の テンプレートを作成し、 作成されたテンプレートの大きさを仮プロックサイズと する。 テンプレートの作成の詳細は後述する。 ここでも、 間接参照される配列デ ータのアクセスについて考慮しない。 テンプレートの作成に失敗した場合、 分割 数を大きくして、 ブロックサイズ決定前処理からやり直す。
決定された仮プロックサイズを用いて、 分割基準領域に割り当てできるかを判 定する。 このステップでは、 データを間接的に参照している場合は、 その次元に ついては配列の宣言サイズを用いて判定する。 間接的に参照されている配列がブ ロックに収まらなかった場合、 共有メモリに置くことを決定してもよい。 TLG集合で使用されるデータが仮プロックサイズに割り当てできる場合、 テ ンプレートを作成したときの分割数を採用する （すなわち、 さらに分割はしな い） 。 そして、 仮ブロックサイズをブロックサイズと決定する。
一方、 TLG集合で使用されるデータが仮プロックサイズに割り当てできない 場合、 分割数を大きくして、 ブロックサイズ決定前処理からやり直す。 さらに、 最大分割数でも割り当てできなかった場合、 最大分割数を採用し、 以後、 割り当 てできなかった TLG集合は、 分割候補 TLG集合に選ばない。 そして、 再び、 分割候補 T L G集合を生成する。
次に、 分割数を決定する。
分割候補 TLG集合毎に、 先に決められたブロックサイズに基づいて、 分割基 準領域決定で決めた領域中にいくつのプロックが確保できるか計算し、 割り当て できる分割数を求める。 その結果、 いずれかの分割候補 TLG集合の割り当てに 失敗した場合、 再び、 分割候補 TLG集合を生成する。
その際、 割り当てできなかった分割候補 TLG集合は最大分割数を採用し、 以 後、 割り当てできなかった TLG集合は、 分割候補 TLG集合に選ばず、 プロッ クサイズは再計算しない。 既に、 分割数が決められた分割候補 TLG集合のデー タサイズをローカルメモリのサイズから減じて、 まだ残っている分割候補 TLG 集合のデータサイズの比に基づいて、 再度、 TLG集合を割り当てる。 そして、 分割数が決定した分割候補 TLG集合内にある各ループを。 ローカルメモリ管理 マクロタスク候補とする。
具体的には、 TLG集合 1で使用されるデータサイズが 300 k、 TLG集合 2で使用されるデータサイズが 200 k、 TLG集合 3で使用されるデータサイ ズが 100 kである例を考える。 TLG集合 1を基準にプロックサイズが決定で きたとする。 TLG集合 2を最大分割数でも割り当てに失敗した場合、 TLG集 合 2の中に TLG集合 4、 TLG集合 5及び TLG集合 6があった場合、 これら が次の分割候補 T L G集合に加わる。
全てのデータがローカルメモリに配置できるループの分割数が決まった場合、 どのデータがどのようなパターンでアクセスされる力 \ 及び、 どのデータがどの 大きさのプロック等を使用すると仮定して分割したかの情報を、 データをロー力 ルメモリに割り当てるときのために、 記憶しておく。
次に、 マクロタスクの分割、 ループの再構築を行う。 ここで行われる処理は、 マクロタスクの分割、 ループディス トリビューション、 ループフュージョン及び ループの再構築である。
ここで、 ループディストリビューション （Loop distribution) とは、 具体的 には図 1 4及び図 1 5で後述するが、 多重分割を行った際にデータを使い回すた めの処理である。 /レープフュージョン （Loop fusion) とは、 レジスタを使い回 すための処理である。
そして、 ループの再構築 （Loop restructuring) 後、 外側階層のループから順 に分割数が設定されているマクロタスクを探し、 見つかったマクロタスクをロー カルメモリ管理マクロタスクとする。 ローカルメモリ管理マクロタスクに設定さ れたマクロタスクの内側では、 マクロタスクの探索を行わない。
<テンプレー卜の作成 >
次に、 テンプレートの作成手順について説明する。
本実施の形態において、 テンプレートとは、 配列変数をローカルメモリに割り 当てる単位である。 コンパイラは、 プログラムがデータにアクセスするパタンに 応じてテンプレートを準備する。 提供されるテンプレートのサイズは、 ブロック 又はサブブロックのサイズと同じである。 また、 テンプレートは、 次元毎 （1次 元配列、 2次元配列、 3次元配列、 · · ·） に用意され、 プログラムによってァ クセスされるサイズ以上の大きさである。
ブロックを用いてローカルメモリを管理する場合に、 同一アドレス領域のブロ ックに様々なデータ （形状、 次元が異なる配列等） を載せる必要がある。 すなわ ち、 データのサイズがブロックに収まるものであっても、 1次元で宣言されてい るスカラー変数であったり、 2次元、 3次元の配列変数である場合がある。 また、 同じ次元のデータであっても各次元のサイズが異なるデータである場合もある。 これらを同じアドレス空間のブロックに載せるために、 すべてのデータを 1次元 のデータに変換してメモリアドレスと一致させることもできる。 しかし、 配列変 数の場合、 添字変換が必要となり、 ユーザーが書いたプログラムと異なるものと なってしまう。 このような添字変換をすると、 プログラムが分かりにくくなり、 デバッグも困難になり、 並列性の解析が分かりにくくなる。
そこで、 プログラムの可読性を保ったまま、 ローカルメモリを管理するために プロック等のサイズと同じサイズのテンプレートを利用する。 テンプレートとは、 配列変数が格納されるテンプレートである。 テンプレートに必要なデータを格納 することによって、 口一カルメモリ上の任意のブロックにデータを載せることを 実現する。
テンプレートは以下の手順によって作成される。
まず、 T L G集合内の全ての配列について、 各次元のアクセスサイズよりも大 きく、 かつ最も小さい 2のべき乗の数を求める。 そして、 各次元が求められた大 きさの仮テンプレートを作成する。
前述した例では、 最外の変数 iのループで 4分割を試行する。 例えば、 i = l 〜3、 4〜6、 7 ~ 8、 9〜： I 0の 4個のノレープに分割すれば、 3回転の 2個の ループ、 2回転の 2個のループができる。 分割されたループ内での配列変数 A及 び Bのアクセスサイズは、 共に、 [ k， j , i ] = [ 1 ： 3 0， 1 : 2 0， 1 ： 3 ] である。 なお、 3次元目はループの回転数のうち大きい方を選択し、 3回転 とする。
次に、 仮テンプレートの大きさを計算する。 テンプレートの各次元は配列変数 の各次元のサイズより大きな 2のべき乗の数としているので、 テンプレートサイ ズは、 3 2 X 3 2 X 4 = 4 k要素となる。 そして、 最も大きい仮テンプレートの サイズをブロックサイズとする。 前述した例では、 ブロックサイズは 4 k要素と なる。
その後、 分割基準領域サイズをブロックサイズで除算し商を求める （分割基準 領域サイズ Zブロックサイズ） 。 この求められた商が 1以上である場合は、 除算 に依って求められた商の小数点以下を切り捨てることによって、 用意できるプロ ックの数 （B 1 o c k _ n u m) を求める。 一方、 求められた商が 1未満である 場合は、 このテンプレートサイズでは一つもブロックが作成できないので、 テン プレートの作成が失敗したと判断する。
また、 ブロックサイズを各テンプレートのサイズで除算し （ブロックサイズ/ 各テンプレートのサイズ） 、 その商をサブブロックの数とする。
前述した例では、 分割されるローカルメモリの領域が 1 2 k要素分なので、 用 意できるプロック数は、 1 2 k Z 4 k = 3個と求まる。 最終的に、 4 k要素のサ ィズの 3個のテンプレート [ 1 : 3 2， 1 : 3 2， 1 : 4 , 0 : 2 ] が用意され る。 テンプレートサイズ及びテンプレート数が決まったので、 ループの分割数は 4で確定する。
すなわち、 この処理では、 プログラム全体を見て、 最適なブロックサイズを決 定する。 このため、 マクロタスクで使用されるデータ （ワーキングセット） を口 一カルメモリに載せるためのプログラムの分割数を定める。 そして、 分割された データサイズより大きなプロックサイズとなるように、 分割数を選択する。 く口一力ノレメモリ管理マクロタスクの決定の例 1〉
次に、 図 1 2〜図 1 3を参照して、 ブロックサイズの決定手順の別な具体例に ついて説明する。
ブロックサイズを決定するためには、 まず、 ループ内でアクセスされるデータ を解析して、 2のべき乗の大きさのテンプレートを作る。
この例では、 ローカルメモリのサイズ （フラグ領域除く） が 2 kB、 各配列要 素のサイズは 4 BZ要素と仮定し、 分散共有メモリの存在は考えない。
まず、 最外ループを最大分割数で分割した場合を考える。
図 12に示すように、 変数 iによる最外ループ 1020、 ループ 1020の中 に変数 jによる内側ループ 1021、 及び、 ループ 1021の中に変数 kによる 最内ループ 1022がある、 3重ループ構造となっている。
具体的には、 ループの分割を考えない場合、 最内ループ 1022で使用される 配列変数 A、 B及び Cのサイズは、 [k, j， i ] = [1 ： 10, 1 : 10， 1 : 10] である。 前述した手順によって仮テンプレートを作成する。 作成され る仮テンプレートのサイズは、 [k， j， i ] = [1 ： 16, 1 : 16， 1 : 1 6] となる。 この仮テンプレートに必要なブロックサイズは 16 X 16 X 16 X 4= 16 kBである。 ローカルメモリのサイズは 2 k Bなので、 一つもブロック を用意できない。 そこで、 最外ループ 1020を分割することを考える。
図 13に示すように、 最外ループ （変数 i ) 1020を最大分割数で分割 （ 1 0分割） する。 最大分割数は、 ループのイタレーシヨン数である。 なお、 外側の ループは限界まで分割しても必要なプロック数が確保できない場合に、 内側のル ープを分割することが望ましい。
この場合、 最内ループ 1022で使用される配列変数 A、 B及び Cのサイズは、 [k， j， i ] = [1 ： 10， 1 ： 10， 1 ： 1] である。 前述した手順によつ て作成される仮テンプレートのサイズは、 [k， j , i ] = [1 ： 16, 1 : 1 6, 1 : 1] となる。 この仮テンプレートに必要なブロックサイズは 16 X 16 X 1 X4 = l k Bである。 ローカルメモリのサイズは 2 k Bなので、 用意できる ブロック数は、 分割基準領域サイズ （2 kB) ブロックサイズ （I kB) =2 個となる。 このループでは 3個の配列変数を使用するので、 この状態では必要な ブロックが確保できない。 そこで、 次に、 内側ループ 1021を分割することを 考える。
内側ループ 1021を 2分割 （2等分） した場合、 最内ループ 1022で使用 される配列変数 A、 B及び Cのサイズは、 [k， j , i ] = [1 ： 10, 1 : 5 1 ： 1] である。 前述した手順によって作成される仮テンプレートのサイズは、 [k, j , i] = [l : 16， 1 : 8， 1 : 1] となる。 この仮テンプレートに 必要なブロックサイズは 16 X 8 X 1 X 4 = 512 Bである。 ローカルメモリの サイズは 2 k Bなので、 分割基準領域サイズ （ 2 k B ) Zブロックサイズ （51 2 B) によって用意できるブロック数を求めると、 用意できるブロックは 4個と なる。
よって、 このループで使用される 3個の配列変数が割り当てられるブロックが 確保できるので、 ブロックのサイズ及び個数が決定する。 作成されるテンプレー トは、 [1 : 16， 1 : 8， 1 : 1， 0 ： 3] となる。
そして、 内側ループ 1021を j =l : 5と、 j =6 : 10とに分けたループ 力 ローカルメモリ管理マクロタスクとなる。
ループ 1030、 1031も、 同様に分割する。
このように、 外側ループの分割に失敗した場合、 内側 （他の次元） のループで も分割 （多次元分割） することによって、 ローカルメモリのサイズに適したロー カルメモリ管理マクロタスクを決定することができる。
くローカルメモリ管理マクロタスクの決定の例 2 >
次に、 図 14から図 15を参照して、 ローカルメモリ管理マクロタスクの生成 の別な具体例を説明する。
この例でも、 前述の例と同様に、 ローカルメモリのサイズ （フラグ領域除く） が 2 kB、 各配列要素のサイズは 4 BZ要素と仮定し、 分散共有メモリの存在は 考えない。 このプログラムは、 図 14に示すように、 変数 j、 kによる 3重ループを 有する。 変数 iによる最外ループ 1041内に、 内側ループ 1042 ( j = 1 ： 10) 及び内側ループ 1043 ( j = 11 ： 20) が含まれている。 同様に、 変 数 iによる最外ループ 1051内に、 内側ループ 1052 ( j = 1 ： 10) 及び 内側ループ 1053 ( j = 1 1 ： 20) が含まれている。
ループ 1051は、 ループ 1041の後に実行される、 また、 ループ 1042 とループ 1052とは同じデータ （配列変数 A [1 : 30， 1 : 10， 1 : 1] 及び配列変数 B [1 : 30， 1 : 10， 1 : 1] ) を使用し、 ループ 1043と ループ 1053とは同じデータ （配列変数 A [1 : 30， 1 1 : 20， 1 : 1] 及び配列変数 B [1 : 30， 1 1 : 20， 1 : 1] ) を使用する。
し力 し、 このプログラムでは、 ループ 1042、 ループ 1043、 ループ 10 52、 ループ 1053の順に実行されるため、 同じデータをローカルメモリ上に 載せたまま使い回すことができない。 そこで、 図 15に示すように、 最外ループ 1041を、 内側ループ 1042 ( j = 1 ： 10) と内側ループ 1043 ( j = 11 : 20) とに分割する。 同様に、 最外ループ 1051を、 内側ループ 105 2 ( j = 1 ： 10) と内側ノレ一プ 1053 ( j = 1 1 ： 20 ) とに分割する。 この分割によって、 分割された最外ループ 1041 Aと最外ループ 1051 A とを順に実行することができる （すなわち、 内側ループ 1042と内側ループ 1 052とが順に実行される） 。 このため、 ループ 1042で使用した配列データ を、 そのまま、 ループ 1052で使用することができる。 つまり、 ループ 104 1 Aの実行終了時とループ 1051 Aの実行開始時との間でデータ （配列変数） の転送が発生しない。
同様に、 分割された最外ループ 1041 Bと最外ループ 1051 Bとを順に実 行することができる （すなわち、 内側ループ 1043と内側ループ 1053とが 順に実行される） 。 このため、 ループ 1043で使用した配列データを、 そのま ま、 ループ 1 0 5 3で使用することができる。 つまり、 ループ 1 0 4 1 Bの実行 終了時とループ 1 0 5 1 Bの実行開始時との間でデータ （配列変数） の転送が発 生しない。
このように、 プログラムの実行順序と、 そのプログラムで使用されるデータと が整合しない場合、 ループのデイストリビューションを実行して、 同じデータを 扱うループを連続的に実行するようにする。 これによつて、 ループの実行時にデ ータの転送が発生しないようにすることができる。
<テンプレートの作成手順の例 >
図 1 6は、 本発明の実施の形態のテンプレー卜の作成手順の例を示す。
テンプレートは、 ローカルメモリをマクロタスク上で扱うために、 ローカルメ モリに配列変数を割り当てる単位である。
テンプレートは、 1次元配列、 2次元配列、 3次元配列 · · ·等が用意され、 その形はマクロタスクで使用される配列変数によって様々である。 例えば、 2次 元配列を考えると、 配列変数の各添字の最大値が等しい正方形や、 添字の最大値 が異なる長方形 （縦長、 横長） 力 マクロタスクで使用される配列変数の大きさ に合うように用意される。
テンプレートのサイズは、 ローカルメモリ管理マクロタスクで使用されるデー タのサイズより大きくなる。 さらに、 テンプレートの各次元の添字の最大値は、 ローカルメモリ管理マクロタスクで使用される配列変数の各次元の添字の最大値 より大きく、 かつ最も小さい 2のべき乗の数が選択される。 このため、 テンプレ ートは、 その形が変わっても、 その大きさはブロック及びサブブロック等のいず れかのサイズと等しい。
よって、 テンプレートのサイズは、 ブロックサイズと等しい又はブロックサイ ズの 2のべき乗分の 1となる。 これによつて、 データが収まる最小の大きさのテ ンプレートを作り、 この作られたテンプレートにデータが収まるようにプログラ ム （ループ） を分割する。 そして、 配列変数をローカルメモリに割り当てる際に、 同じサイズのブロック等に割り当てることができ、 ローカルメモリの記憶容量を 無駄なく使用することができる。
割り当てられたテンプレートを使用することで、 プロック 0に割り当てられた テンプレートは、 ブロック 0のメモリ空間を使用し、 ブロック 1に割り当てられ たテンプレートは、 プロック 1のメモリ空間を使用する。
テンプレートは同じ形状のものをプロック数分用意する。 そしてブロック番号 によって使用するテンプレート配列を変える。 そのために、 用意されるテンプレ ートは同じテンプレートを複数個並べた形 （データを載せて使用する配列変数の 次元 + 1次元） が実際に作成されるテンプレートとなる。 新たに作られた次元は ブロック指定用の次元となり、 要素数はブロックの数となる。
すなわち、 テンプレートの次元は、 配列変数の次元より 1次元大きくなつてい る。 これは、 テンプレートの追加された次元の添字の値によって、 複数の配列変 数を切り替え、 アクセスするブロックを変えるためである。 なお、 各テンプレー トは、 ローカルメモリの異なるブロック （異なるアドレス） に割り当てられる。 配列変数の形状及び大きさが同じである場合、 同じテンプレートを使用すること ができる。 例えば、 均等に分割されたループは、 同じ形状及び大きさの配列変数 を使用することから、 このようなテンプレートを用意することが有効である。 例えば、 ブロック数が 8個であり、 その各々のサイズが [1 : 2， 1 : 16， 1 : 4] である場合、 t empA [l : 2， 1 : 16， 1 : 4， 0 : 7] のテン プレートをローカルメモリに割り当てる。 なお、 このとき、 プログラム中に表れ る配列変数が 5個であった場合は、 t em p A [1 : 2， 1 : 1 6， 1 : 4， 0 ： 4] として、 ブロック 0から 4のみにテンプレートを割り当てる。 他のプロ ックは、 更に分割してサブプロックとして利用してもよい。
図 1 7に、 テンプレートがマッピングされたローカルメモリの状態を示す。 テンプレートのマッピングには、 例えば FORTRANでは、 EQUIVALENCE文が用いら れる。 具体的には、 EQUIVALENCE (LM (1), temPA(l, 1， 1,0))と宣言することによつ て、 ローカルメモリのブロック 0に、 テンプレート Aを割り当てることができる。 テンプレート Aは、 3次元配列用のテンプレートで、 各次元は t empA
[1 : 2， 1 : 16， 1 : 4， 0 : 7] である。 よって、 プロック 0 (ァドレス 0〜127) には t empA [1, 1， 1， 0] が割り当てられ、 ブロック 1 (アドレス 1 28〜255) には t empA [1, 1， 1， 1] が割り当てられ る。
すなわち、 前述したように、 テンプレートの最外側の 4次元目はテンプレート 自体の次元ではなく、 テンプレートが割り当てられるブロック番号を示す。
さらに具体的に例示すると、
do dim3 = 1, 4
do dim2 = 1, 16
do diml - 1， 2
tempA(diml, dim2， dim3, 2) = GA(diml, dim2， dim3)
enddo
enddo
enddo
を実行することによって、 配列変数 G Aのデータが、 ローカルメモリのブロック 2に格納される。
図 18に、 別なテンプレートがマッピングされた口一カルメモリの状態を示す。 前述した例と異なり、 プログラム中に表れる配列サイズが [1 : 2， 1 : 8， 1 : 4] である場合、 サブブロックサイズに適合するテンプレート t e mp_s u b A [1 ： 2, 1 : 8， 1 : 4， 0 : 1 5] をローカルメモリに割り当てられ る。 このように最外側の要素の値によってアクセスするサブブロックが可変とな る。
前述と同様に EQUIVALENCE文を用いて、 EQUIVALENCE (LM(1),
temp_subA(l, 1， 1， 0) )と宣言することによって、 ローカルメモリのサブブロック 0に、 テンプレート （サブ） Aを割り当てることができる。 .
テンプレート Aは、 3次元配列用のテンプレートで、 その大きさは t emp— s u b A [1 ： 2, 1 : 8， 1 : 4， 0 : 15] である。 よって、 サブプロック 0 (アドレス 0〜 63) には t emp— s u bA [l， 1， 1， 0] が割り当て られ、 サブブロック 1 (アドレス 64〜： I 27) には t emp— s u bA [1， 1， 1， 1] が割り当てられる。
さらに具体的に例示すると、
do dim3 = 1, 4
do dim2 = 1, 8
do diml = 1， 2
temp_subA(diml, dim2, dim3， 4) = GA(diml, dim2, dim3)
enddo
enddo
enddo
を実行することによって、 配列変数 G Aのデータが、 ローカルメモリのサブブロ ック 4に格納される。
このように、 コンパイラがプログラムを解析して取得した情報に基づいて、 プ ログラム中で使用される配列変数の形を特定してテンプレートを作成し、 その変 数をどのテンプレートに割り当てるかを決める。 これによつて、 メモリの 1次元 のァドレス空間を多次元に見せることができ、 プログラム中で使用された多次元 配列をそのままの形でメモリに割り当てることができる。
くテンプレート配列を用いたコードイメージの作成〉 次に、 図 1 9から図 34を参照して、 テンプレート配列を用いたコードィメー ジの作成の具体例について説明する。 図 1 9から図 34の説明は、 ローカルメモ リサイズを 1024、 ブロックサイズは 1 28とし、 ローカルメモリの領域を 4 個のブロック 101、 4個のサブブロック 102、 4個のサブサブブロック 10 3、 8個のサブサブサブブロック 104に分割した場合に、 コンパイラがコード を書き換える様子及びプログラム実行時のローカルメモリの状態を示す。
図 1 9は、 コンパイル前のオリジナルコード及びローカルメモリの状態 （状態 1) を示す。 このオリジナルコード中には、 三つのループ及び二つのサブルーチ ン呼び出しが含まれており、 これらのループ及びサブルーチン呼び出しが、 ロー カルメモリ管理マクロタスクとなる。
図 20は、 テンプレートがブロック等に設定される状態 （状態 2) を示す。 L M領域及びテンプレート配列を定義し、 EQUIVALENCE文によってテンプレー卜を ロー力/レメモリの
アドレス空間に割り当てる。 この割り当てによって、 ローカ^/メモリとテンプレ 一トとは同じ領域を指す。 そして、 テンプレートの添字 （0〜7) を変えること によって対応する領域が変わる。 なお、 テンプレート配列によって宣言されるが t emp i (1， 4) 以後はサブブロック等に割り当てられた領域なので、 ブロ ックとしては使用されない。
具体的には、 以下の文がプログラムに挿入される。
Integer a (128), b(128)， c(128), d(128)， e(128)
Integer LM(1024)
Integer tempi (128, 0:7)
EQUIVALENCE (LM, tempi)
これによつて、 テンプレートがローカルメモリに割り当てられる。
図 21は、 テンプレート配列へ変換される状態 （状態 3) を示す。 ローカルメ モリに載せて使用したい配列を、 新しく定義したテンプレート配列へ変換する。 オリジナルコード中の配列をテンプレート配列にすることによって、 ローカルメ モリを使用していることになる。 ブロックを指定する次元の値 （添字） を変える ことによって、 使用されるブロック （ローカルメモリのアドレス） を変えること ができる。
具体的には、 オリジナルのコード中の配列名 a ( i ) 、 b ( i ) 、 c ( i ) は、 t e mp i ( i， 0) 、 t emp i ( i， 1) 、 t emp i ( i， 2) に書き換 えられる。
図 2 2は、 ブロックからデータが掃き出される状態 （状態 4) を示す。 二つ目 のマクロタスクでは、 四つの配列 b、 c、 d及び eを使用するため、 4個のプロ ックが必要である。 一つ目のマクロタスクが終了した時点で、 次に実行されるマ クロタスクで必要なブロック数が空いていない場合、 掃き出し優先度に従って必 要な数のブロックを空ける。 具体的には、 三つの配列 a、 b及び cが、 ローカル メモリ上に載っているが、 配列 b及び cは継続して使用される。 よって、 配列 e をロードするために、 配列 aが掃き出される。 掃き出されるブロックに格納され ていたデータは集中共有メモリ 28又は 1 4に転送される。 よって、 テンプレー ト配列に格納されたデータを集中共有メモリ 28又は 1 4の配列へ転送する命令 がオリジナルコードに挿入される。 .
図 2 3は、 テンプレート配列へ変換される状態 （状態 5) を示す。 状態 3 (図 2 1) に示した状態と同様に、 ローカルメモリに載せて使用したい配列を、 新し く定義したテンプレート配列へ変換する。 ブロック 0から配列 aが掃き出され、 配列 dが格納されている。
図 24は、 サブルーチンが解析される状態 （状態 6) を示す。 サブルーチンの 引数と、 サブルーチン内の処理に必要なブロック数を解析する。 図示する例では、 サブルーチン s u b 1では引数配列 X及び自動変数である配列 yを使用している。 つまり、 引数用に 1個のブロック、 内部処理用に 1個のブロック。 合計 2個のブ 口ックが必要である。
図 2 5は、 サブルーチン内でブロック指定変数を用いたテンプレート配列へ変 換される状態 （状態 7 ) を示す。 ここで、 前述したように、 サブルーチンは複数 箇所から呼ばれる可能性があるため、 テンプレート配列のブロック指定次元を定 数によって指定すると、 メモリ管理上の制限が強くなる。 そのため、 ブロック指 定変数 block_nol を用いて、 テン
プレートを任意の場所に置けるように、 テンプレート配列を変換をする。
図 2 6は、 サブルーチン処理用のブロックを確保する状態 （状態 8 ) を示す。 既に、 サブルーチン内の解析が終わり、 サブルーチンで必要なブロック数が分か つているので、 必要な数のブロックをサブルーチン呼び出し時に空けて、 サブル 一チン処理用のプロックを確保する。 必要な数のプロックが空いていない場合は、 既にロードされているデータを掃き出す。 掃き出されるデータは、 掃き出し優先 度に従って決められる。
具体的には、 このサブルーチンでは、 1個の引数ブロック及び 1個の内部処理 用ブロックが必要である。 メモリ上に配列 b、 c、 d及び eが載っているが、 配 列 eは引数として使用される。 よって、 1個のブロックを内部処理用に空ける必 要がある。 掃き出し優先度を考慮すると、 配列 c及び dは直ぐに使用されるため、 配列 bが掃き出される。
図 2 7は、 ブロック指定変数が設定される状態 （状態 9 ) を示す。 サブルーチ ン内で使用される内部処理用の配列は、 ブロック指定変数 block_nol によって 任意のブロックを
使用できる。 このため、 内部処理用の配列変数に割り当てられるブロック番号を 指定変数に設定する。
図 2 8は、 サブルーチンが実行される状態 （状態 1 0 ) を示す。 サブルーチン 呼び出し時に設定されたプロック指定変数によって、 使用されるプロックが決定 される。 すなわち、 ブロック 1は内部処理用の配列 yに割り当てられ、 ブロック 3は引数用の配列 Xに割り当てられる。 サブルーチンでは、 指定されたブロック を使用して、 サブルーチンの処理が行なわれる。
図 2 9は、 サブルーチンの実行終了時の状態 （状態 1 1 ) を示す。 サブルーチ ンの処理が終わると、 内部処理用のブロックは N U L Lとなる。 引数用のプロッ クは、 引数として受け取った元の配列に戻る。
図 3 0は、 テンプレート配列へ変換される状態 （状態 1 2 ) を示す。 状態 3 (図 2 1 ) 及び状態 5 (図 2 3 ) に示した状態と同様に、 ローカルメモリに載せ て使用したい配列を、 新しく定義したテンプレート配列へ変換する。
図 3 1は、 サブルーチン処理用のブロックを確保する状態 （状態 1 3 ) を示す。 既に、 サブルーチン内の解析が終わり、 サブルーチンで必要なブロック数が分か つているので、 サブルーチン呼び出し時に必要な数のブロックを空けて、 サブル 一チン処理用のブロックを確保する。 必要な数のブロックが空いていない場合は、 既にロードされているデータを掃き出す。 掃き出されるデータは、 掃き出し優先 度に従って決められる。
具体的には、 次のマクロタスク （サブルーチン呼び出し） で、 サブルーチンの 内部処理用に 1個のプロックを空ける必要がある。 ローカルメモリに載っている 配列 d、 a、 c及び eのうち、 配列 aはサブルーチンの引数として使用される。 配歹 lj d、 c及び eの掃き出し優先度は同じなので、 ブロック番号の最も小さいブ ロック 0に格納されている配列 dを掃き出す。 また、 次のマクロタスクで配列 a が必要なことが分かっているので、 データ転送ユニットによって、 ローカルメモ リの空いているブロック 1に配列 aを転送する。
図 3 2は、 ブロック指定変数が設定される状態 （状態 1 4 ) を示す。 サブルー チン内で使用される内部処理用の配列は、 ブロック指定変数 block— nol によつ て任意のブロック
を使用できる。 このため、 サブルーチン呼出時に、 内部処理用の配列変数に割り 当てられるブロック番号を指定変数に設定する。 前のサブルーチン呼出時 （図 2 7に示す状態 9 ) と異なるプロック番号を設定することができる。
図 3 3は、 サブルーチンが実行される状態 （状態 1 5 ) を示す。 サブルーチン 呼び出し時に設定されたプロック指定変数によって、 使用されるプロックが決定 される。 すなわち、 ブロック 0は内部処理用の配列 yに割り当てられ、 ブロック 1は引数用の配列 Xに割り当てられる。 サブルーチンでは、 指定されたブロック を使用して、 サブルーチンの処理が行なわれる。 前のサブルーチン呼出時 （図 2 8に示す状態 1 0 ) とは別の領域で処理を行っている。
図 3 4は、 サブルーチンの実行終了時の状態 （状態 1 6 ) を示す。 図 3 4に示 すコードがコンパイル完了時のコードである。 サブルーチンの処理が終わると、 内部処理用のブロックは NU L Lとなる。 引数用のブロックは、 引数として受け 取った元の配列に戻る。 産業上の利用可能性
本発明は、 プロセッサによって使用されるメモリの記憶領域の管理に適用でき、 特に、 マルチタスクプロセッサによって使用されるメモリの記憶領域の管理に適 している。

Claims

請求の範囲
1 . プロセッサによって使用されるメモリの記憶領域を管理する方法であって、 前記プロセッサは、 タスクの実行時にアクセスされるデータを格納するメ モリに接続されており、
前記メモリの記憶領域を複数の異なるサイズのブ口ックに分割し、 前記タスクの実行時にアクセスされるデータに適合するサイズのブロック を選択し、
前記選択されたプロックに、 前記タスクの実行時にアクセスされるデータ を格納することを特徵とするメモリ管理方法。
2 . 請求項 1に記載のメモリ管理方法であって、
前記タスクを含むプログラムの解析によって得られた情報に基づいて決定 されるサイズに、 前記プロックを分割することを特徴とするメモリ管理方法。 3 . 請求項 1に記載のメモリ管理方法であって、
前記ブロックは、 複数のサイズのブロックを含み、 前記ブロックの複数の サイズは整数倍の関係にあることを特徴とするメモリ管理方法。
4 . 請求項 1に記載のメモリ管理方法であって、
前記データに前記選択されたブロックへ割り当てることを決定した後、 デ ータ転送手段によって、 前記データを前記選択されたプロックに格納し、 前記ブロックの解放タイミングまでに、 前記データ転送手段によって、 前 記選択されたプロックに格納されたデータを読み出し、 他のメモリに格納す ることを特徴とするメモリ管理方法。 請求項 1に記載のメモリ管理方法であって、
前記タスクでアクセスされるデータに n次元の配列データが含まれる場合 に、 前記タスクでアクセスされる配列データに整合するように選択された n + 1次元のテンプレートを、 前記ブロックに割り当て、
データを格納するブロックを指定する場合に、 前記加えられた次元の値に よって、 アクセスされるブロックが異なるように、 次元の値の異なる前記テ ンプレートを前記各プロックに割り当てることを特徴とするメモリ管理方法。 プロセッサがメモリの記憶領域を管理する方法であって、
前記プロセッサは、 プログラムの実行時にアクセスされるデータを格納す るメモリに接続されており、
前記方法は、
前記メモリの記憶領域をブロックに分割し、
前記プログラムの解析によって得られた情報に基づいて定められた複数の 形状及びサイズのテンプレートを、 適合する大きさのブロックに割り当て、 前記割り当てられたテンプレートに適合する形状及び大きさのデータを、 前記テンプレートに格納することを特徴とするメモリ管理方法。 請求項 6に記載のプログラムの作成方法であって、
前記テンプレートを割り当てるステップでは、
各プロックに割り当て可能な複数種類のテンプレートから、 前記プロダラ ムでアクセスされる配列データの次元に 1を加えた次元を有し、 各次元の最 大値が前記プログラムでアクセスされる配列データの各次元の最大値より大 きいテンプレートを割り当て、
前記加えられた次元の値によって、 アクセスされるブロックが異なるよう に、 複数の前記テンプレートを複数の前記ブロックに割り当てることを特徴 とするプログラムの作成方法。
8 . プロセッサ及び前記プロセッサによってアクセスされるデータを格納する メモリを備える情報処理装置であって、
前記メモリの記憶領域は、 前記プロセッサで実行されるプログラムの解 祈によって得られた情報に基づいて決定される複数のサイズのプロックに分 割され、
前記プロックに割り当てられるテンプレートの形状及びサイズは、 前記プ 口グラムの解析によつて得られた情報に基づいて定められており、
前記プロセッサは、
前記プロセッサで実行されるプログラムの解析によって得られた情報に基 づいて決定される複数のサイズのプロックに、 前記メモリの記憶領域を分割 し、
前記プログラムの解析によって得られた情報に基づいて定められた形状及 びサイズのテンプレートを、 適合する大きさのブロックに割り当て、 前記割り当てられたテンプレートに適合する形状及び大きさのデータを、 前記テンプレートに格納することを特徴とする情報処理装置。 9 . 請求項 8に記載の情報処理装置であって、
前記プログラムでアクセスされる配列データの次元に 1を加えた次元を有 し、 加えられた次元以外の各次元の最大値が前記プログラムでアクセスされ る配列データの各次元の最大値以上のテンプレートが割り当てられ、 前記加えられた次元の値によって、 アクセスされるプロックが異なるよう に、 複数の前記テンプレートが複数の前記ブロックに割り当てられることを 特徴とする情報処理装置。 . プロセッサによって実行可能なプログラムの作成方法であって、
プログラムの情報をコンパイラによって解析し、
前記プログラムに含まれる各タスクの実行に必要なデータを特定し、 前記タスクの実行タイミングに従って、 必要なデータをメモリに読み書き するタイミングを決定し、
前記決定されたデータの書き込みタイミングまでに前記メモリの領域を割 り当てる命令を、 コンパイルされるプログラムに追加することを特徴とする プログラムの作成方法。 . 請求項 1 0に記載のプログラムの作成方法であって、
前記プログラムの解析によって得られた情報に基づいて、 解放する前記領 域及び前記領域を解放するタイミングを決定し、
前記割り当てられた領域を解放するために、 前記決定されたタイミングま でに前記メモリに書き込まれたデータを読み出す命令を、 前記コンパイルさ れるプログラムに追加することを特徴とするプログラムの作成方法。 . 請求項 1 1に記載のプログラムの作成方法であって、
前記メモリの領域を割り当てた後に、 データ転送手段によって、 前記デー タを前記メモリに格納する命令、 及び
前記メモリの領域の解放タイミングまでに、 前記データ転送手段によって、 前記メモリに格納されたデータを読み出し、 他のメモリに格納する命令を、 前記コンパイルされるプログラムに追加することを特徴とするプログラムの 作成方法。
1 3 . 請求項 1 0に記載のプログラムの作成方法であって、
前記プログラムの解析によって得られた情報は、 前記プログラムでァクセ スされるデータの情報、 前記データが次にアクセスされるタイミングの情報、 前記データをアクセスするプロセッサの情報の少なくとも一つを含むことを 特徴とするプログラムの作成方法。
1 4 . 請求項 1 0に記載のプログラムの作成方法であって、
前記プロセッサは複数のプロセッサコアを備えるマルチプロセッサであつ て、
前記方法は、 前記タスクをいつどのプロセッサに実行させるかを決定し、 前記決定されたプロセッサに前記タスクを割り当てる命令を、 前記コンパィ ルされるプログラムに追加することを特徴とするプログラムの作成方法。 1 5 . 請求項 1 0に記載のプログラムの作成方法であって、
前記メモリの領域は、 前記メモリの記憶領域が固定サイズのプロックに分 割された領域であることを特徴とするプログラムの作成方法。
1 6 . 請求項 1 5に記載のプログラムの作成方法であって、
前記メモリの領域は複数の異なるサイズのプロックに分割された領域であ つて、
前記複数のサイズは、 前記プロックの複数のサイズは整数倍の関係にある ことを特徴とするプログラムの作成方法。 1 7 . 請求項 1 5に記載のプログラムの作成方法であって、 前記プロックのサイズは、 前記コンパイラがプログラムを解析して得られ た情報に基づいて決定ざれることを特徴とするプログラムの作成方法。 . 請求項 1 5に記載のプログラムの作成方法
前記タスクでアクセスされるデータを前記一つのブロックに収まるように するために、 前記プログラムを分割することを特徴とするプログラムの作成 方法。 . 請求項 1 8に記載のプログラムの作成方法であって、
前記プログラムは多重ループを含み、
外側のループの分割によって生成されたタスクでアクセスされるデータが 前記ブロックに収まるか否かを判定し、
前記外側のループが分割によって生成されたタスクでアクセスされるデー タが前記プロックに収まらなければ、 更に内側のループを分割することによ つて、 前記データのサイズを変更することを特徴とするプロダラムの作成方 法。 . 請求項 1 0に記載のプログラムの作成方法
前記プログラムでアクセスされるデータに n次元の配列データが含まれる 場合に、 前記プログラムでアクセスされる配列データに整合するように選択 された n + 1次元のテンプレートを割り当て、
データを格納する領域を指定する場合に、 前記加えられた次元の値によつ て、 アクセスされる領域が指定されるように、 複数の前記テンプレートを複 数の領域に割り当てることを特徴とするプログラムの作成方法。
. プロセッサによって実行可能なプログラムであって、
前記プログラムは、 コンパイラによって、
プログラムの情報が解析され、
前記プログラムに含まれる各タスクの実行に必要なデータが特定され、 前記タスクの実行タイミングに従って、 必要なデータをメモリに読み書き するタイミングが決定され、
前記決定されたデータの書き込みタイミングまでに前記メモリの領域を割 り当てる命令が追加されることによって生成されるプログラム。
PCT/JP2008/053891 2007-02-28 2008-02-27 メモリ管理方法、情報処理装置、プログラムの作成方法及びプログラム WO2008105558A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US12/525,404 US8438359B2 (en) 2007-02-28 2008-02-27 Memory management method, information processing device, program creation method, and program
CN2008800037808A CN101601017B (zh) 2007-02-28 2008-02-27 存储器管理方法以及程序的生成方法
KR1020097017059A KR101186174B1 (ko) 2007-02-28 2008-02-27 메모리 관리방법, 정보처리장치, 프로그램의 작성방법 및 프로그램
GB0914592.1A GB2459802B (en) 2007-02-28 2008-02-27 Memory management method and information processing device implementing the method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2007-050269 2007-02-28
JP2007050269A JP5224498B2 (ja) 2007-02-28 2007-02-28 メモリ管理方法、情報処理装置、プログラムの作成方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2008105558A1 true WO2008105558A1 (ja) 2008-09-04

Family

ID=39721378

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/053891 WO2008105558A1 (ja) 2007-02-28 2008-02-27 メモリ管理方法、情報処理装置、プログラムの作成方法及びプログラム

Country Status (6)

Country Link
US (1) US8438359B2 (ja)
JP (1) JP5224498B2 (ja)
KR (1) KR101186174B1 (ja)
CN (1) CN101601017B (ja)
GB (2) GB2478874B (ja)
WO (1) WO2008105558A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013001614A1 (ja) * 2011-06-28 2013-01-03 富士通株式会社 データ処理方法およびデータ処理システム
JPWO2013001614A1 (ja) * 2011-06-28 2015-02-23 富士通株式会社 データ処理方法およびデータ処理システム

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8219740B2 (en) * 2008-06-25 2012-07-10 International Business Machines Corporation Flash sector seeding to reduce program times
CN101499034A (zh) * 2009-03-05 2009-08-05 北京中星微电子有限公司 内存管理方法
US8335897B2 (en) * 2009-12-15 2012-12-18 Seagate Technology Llc Data storage management in heterogeneous memory systems
WO2011078162A1 (ja) * 2009-12-24 2011-06-30 日本電気株式会社 スケジューリング装置、スケジューリング方法及びプログラム
US8723877B2 (en) 2010-05-20 2014-05-13 Apple Inc. Subbuffer objects
KR101754998B1 (ko) 2011-01-27 2017-07-06 삼성전자주식회사 멀티 코어 시스템 및 멀티 코어 시스템에서의 데이터 병렬 처리 방법
CN102622206A (zh) * 2011-01-28 2012-08-01 中兴通讯股份有限公司 一种处理器及其处理数据的方法
JP2012173870A (ja) * 2011-02-18 2012-09-10 Toshiba Corp 半導体装置及びメモリ保護方法
US9354988B2 (en) * 2011-03-28 2016-05-31 Sap Se Allocation strategies for data storage applications
JP5708216B2 (ja) * 2011-05-09 2015-04-30 ソニー株式会社 フラッシュメモリ装置、メモリ制御装置、メモリ制御方法、ストレージシステム
US9830133B1 (en) * 2011-12-12 2017-11-28 Significs And Elements, Llc Methods and apparatus for automatic communication optimizations in a compiler based on a polyhedral representation
WO2013095605A1 (en) * 2011-12-23 2013-06-27 Intel Corporation Apparatus and method for sliding window data gather
US10193927B2 (en) * 2012-02-27 2019-01-29 University Of Virginia Patent Foundation Method of instruction location randomization (ILR) and related system
US9323316B2 (en) 2012-03-13 2016-04-26 Intel Corporation Dynamically controlling interconnect frequency in a processor
CN104169832B (zh) 2012-03-13 2017-04-19 英特尔公司 提供处理器的能源高效的超频操作
US9436245B2 (en) 2012-03-13 2016-09-06 Intel Corporation Dynamically computing an electrical design point (EDP) for a multicore processor
US8984313B2 (en) 2012-08-31 2015-03-17 Intel Corporation Configuring power management functionality in a processor including a plurality of cores by utilizing a register to store a power domain indicator
US8510531B1 (en) * 2012-09-20 2013-08-13 Google Inc. Fast, dynamic cache packing
KR101537725B1 (ko) * 2013-01-18 2015-07-20 서울대학교산학협력단 워크 그룹 크기 결정 방법, 시스템 및 컴퓨터 판독가능 기록매체
JP6161396B2 (ja) * 2013-05-15 2017-07-12 オリンパス株式会社 演算装置
JP6161395B2 (ja) * 2013-05-15 2017-07-12 オリンパス株式会社 演算装置
JP6018022B2 (ja) 2013-06-14 2016-11-02 株式会社デンソー 並列化コンパイル方法、並列化コンパイラ、並列化コンパイル装置、及び、車載装置
JP5915624B2 (ja) * 2013-11-14 2016-05-11 株式会社デンソー 電子制御装置
JP6201788B2 (ja) * 2014-01-29 2017-09-27 富士通株式会社 ループ分割検出プログラム及びループ分割検出方法
JP6200824B2 (ja) * 2014-02-10 2017-09-20 ルネサスエレクトロニクス株式会社 演算制御装置及び演算制御方法並びにプログラム、ＯｐｅｎＣＬデバイス
KR101771289B1 (ko) * 2014-05-19 2017-08-24 엘에스산전 주식회사 Ｐｌｃ 프로그램 관리 장치
CN104168079B (zh) * 2014-09-03 2017-02-01 成都朗锐芯科技发展有限公司 一种多通道分组定时器
JP6488739B2 (ja) 2015-02-05 2019-03-27 株式会社デンソー 並列化コンパイル方法、及び、並列化コンパイラ
JP6488738B2 (ja) 2015-02-05 2019-03-27 株式会社デンソー 並列化コンパイル方法、及び、並列化コンパイラ
US10491667B1 (en) * 2015-03-16 2019-11-26 Amazon Technologies, Inc. Customized memory modules in multi-tenant service provider systems
JP6427053B2 (ja) 2015-03-31 2018-11-21 株式会社デンソー 並列化コンパイル方法、及び並列化コンパイラ
JP6427054B2 (ja) 2015-03-31 2018-11-21 株式会社デンソー 並列化コンパイル方法、及び並列化コンパイラ
EP3113026B1 (en) * 2015-06-29 2019-07-24 aicas GmbH Automatic memory management using a memory management unit
CN110874212B (zh) 2015-06-30 2021-08-20 华为技术有限公司 一种硬件加速方法、编译器以及设备
DE102017209697A1 (de) * 2016-06-13 2017-12-14 Denso Corporation Parallelisierungsverfahren, Parallelisierungswerkzeug und fahrzeuginterne Vorrichtung
DE102016211386A1 (de) * 2016-06-14 2017-12-14 Robert Bosch Gmbh Verfahren zum Betreiben einer Recheneinheit
JP2017228029A (ja) * 2016-06-21 2017-12-28 株式会社デンソー 並列化方法、並列化ツール、車載装置
US10289309B2 (en) 2016-09-12 2019-05-14 Toshiba Memory Corporation Automatic detection of multiple streams
US10073640B1 (en) 2017-03-10 2018-09-11 Toshiba Memory Corporation Large scale implementation of a plurality of open channel solid state drives
US10542089B2 (en) 2017-03-10 2020-01-21 Toshiba Memory Corporation Large scale implementation of a plurality of open channel solid state drives
US10339983B1 (en) * 2017-12-29 2019-07-02 Micron Technology, Inc. Temperature-based memory operations
US11461631B2 (en) * 2018-03-22 2022-10-04 Amazon Technologies, Inc. Scheduling neural network computations based on memory capacity
US11475306B2 (en) 2018-03-22 2022-10-18 Amazon Technologies, Inc. Processing for multiple input data sets
JP7060803B2 (ja) 2018-06-20 2022-04-27 富士通株式会社 情報処理装置、コンパイラプログラム及びコンパイル方法
CN109634518A (zh) * 2018-10-29 2019-04-16 成都华为技术有限公司 一种存储资源配置方法及装置
CN110704362B (zh) * 2019-09-12 2021-03-12 无锡江南计算技术研究所 一种处理器阵列局部存储混合管理方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003015883A (ja) * 2001-06-29 2003-01-17 Nec Corp プロセッサ間通信削減方法と並列化コンパイラ装置並びにプログラム
WO2005081113A2 (en) * 2004-02-13 2005-09-01 Jaluna Sa Memory allocation

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784699A (en) * 1996-05-24 1998-07-21 Oracle Corporation Dynamic memory allocation in a computer using a bit map index
US6088777A (en) 1997-11-12 2000-07-11 Ericsson Messaging Systems, Inc. Memory system and method for dynamically allocating a memory divided into plural classes with different block sizes to store variable length messages
JP4784792B2 (ja) 1999-12-22 2011-10-05 学校法人早稲田大学 マルチプロセッサ
DE10228103A1 (de) 2002-06-24 2004-01-15 Bayer Cropscience Ag Fungizide Wirkstoffkombinationen
CN1679005A (zh) * 2002-08-30 2005-10-05 皇家飞利浦电子股份有限公司 动态存储器管理
US7563748B2 (en) 2003-06-23 2009-07-21 Cognis Ip Management Gmbh Alcohol alkoxylate carriers for pesticide active ingredients

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003015883A (ja) * 2001-06-29 2003-01-17 Nec Corp プロセッサ間通信削減方法と並列化コンパイラ装置並びにプログラム
WO2005081113A2 (en) * 2004-02-13 2005-09-01 Jaluna Sa Memory allocation

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
YOSHIDA A.: "A Data-Localization Scheme among Doall/Sequential Loops for Fortran Coarse-Grain Parallel Processing", THE TRANSACTIONS OF THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS D-I, vol. J-78-D-I, no. 2, 25 February 1995 (1995-02-25), pages 162 - 169 *
YOSHIDA A.: "A Near-Fine-Grain Task Scheduling Scheme for Multi-Grain Data-Localization", IEICE TECHNICAL REPORT, vol. 96, 27 August 1996 (1996-08-27), pages 71 - 78 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013001614A1 (ja) * 2011-06-28 2013-01-03 富士通株式会社 データ処理方法およびデータ処理システム
JPWO2013001614A1 (ja) * 2011-06-28 2015-02-23 富士通株式会社 データ処理方法およびデータ処理システム

Also Published As

Publication number Publication date
GB0914592D0 (en) 2009-09-30
GB2478874A (en) 2011-09-21
GB2459802B (en) 2012-01-04
CN101601017A (zh) 2009-12-09
CN101601017B (zh) 2013-10-09
KR101186174B1 (ko) 2012-10-02
US8438359B2 (en) 2013-05-07
KR20090106613A (ko) 2009-10-09
JP5224498B2 (ja) 2013-07-03
GB2478874B (en) 2011-12-28
GB2459802A (en) 2009-11-11
GB201109237D0 (en) 2011-07-13
US20100174876A1 (en) 2010-07-08
JP2008217134A (ja) 2008-09-18

Similar Documents

Publication Publication Date Title
WO2008105558A1 (ja) メモリ管理方法、情報処理装置、プログラムの作成方法及びプログラム
JP4082706B2 (ja) マルチプロセッサシステム及びマルチグレイン並列化コンパイラ
EP1881405B1 (en) Global compiler for controlling heterogeneous multiprocessor
JP4936517B2 (ja) ヘテロジニアス・マルチプロセッサシステムの制御方法及びマルチグレイン並列化コンパイラ
US7926046B2 (en) Compiler method for extracting and accelerator template program
JP6018022B2 (ja) 並列化コンパイル方法、並列化コンパイラ、並列化コンパイル装置、及び、車載装置
US8528001B2 (en) Controlling and dynamically varying automatic parallelization
US20140137123A1 (en) Microcomputer for low power efficient baseband processing
JP2016192153A (ja) 並列化コンパイル方法、並列化コンパイラ、及び車載装置
JP2007305148A (ja) マルチプロセッサシステム
JP4784792B2 (ja) マルチプロセッサ
Owaida et al. Massively parallel programming models used as hardware description languages: The OpenCL case
JP2016192152A (ja) 並列化コンパイル方法、並列化コンパイラ、及び車載装置
JP4304347B2 (ja) マルチプロセッサ
JP4784842B2 (ja) マルチプロセッサ及びマルチプロセッサシステム
Ghadge Improving Code Overlay Performance by Pre-fetching in Scratch Pad Memory Systems
Lam et al. Hierarchical Reduction
JP2009230764A (ja) マルチプロセッサシステム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200880003780.8

Country of ref document: CN

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

Ref document number: 08721311

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 1020097017059

Country of ref document: KR

ENP Entry into the national phase

Ref document number: 0914592

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20080227

WWE Wipo information: entry into national phase

Ref document number: 0914592.1

Country of ref document: GB

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12525404

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 08721311

Country of ref document: EP

Kind code of ref document: A1