Address mapping-recognition type task processing mechanism

Abstract

The Address Mapping Aware Tasking (AMAT) mechanism manages computational task data and issues computational tasks on behalf of the threads that created the computational task data. The AMAT mechanism stores computational task data generated by host threads in a set of partitions, with each partition designated for a particular memory module. The AMAT mechanism maintains address mapping data that maps address information to partitions. A thread pushes computational task data to the AMAT mechanism instead of generating and issuing its own computational tasks. The AMAT mechanism uses the computational task data and the address information contained in the address mapping data to determine the partition in which to store the computational task data. The AMAT mechanism then issues computational tasks to be executed near the corresponding memory module (i.e., in a PIM execution unit or a NUMA compute node) based on the computational task data stored in the partitions.

Description

Background Art

[0001] The approaches described in this section are approaches that can be carried out, but are not necessarily approaches that have been previously conceived or carried out. Thus, unless otherwise indicated, none of the approaches described in this section should be assumed to be eligible as prior art merely by virtue of being included in this section. Further, none of the approaches described in this section should be assumed to be well-understood, routine, or conventional merely by virtue of being included in this section.

[0002] Since computing throughput scales faster than memory bandwidth, various techniques have been developed to continue to supply data to increasing computing capacity. Processing In Memory (PIM) incorporates processing capabilities within a memory module so that tasks can be directly processed within the memory module. In the context of Dynamic Random-Access Memory (DRAM), an exemplary PIM configuration includes vector calculation elements and local registers. This enables the memory controller to trigger calculations in parallel across multiple memory modules without the need for data movement across the memory module interface, thereby significantly improving performance, particularly for data-limited workloads.

[0003] To effectively utilize PIM, software development must be aware of hardware details, specifically the mapping from memory addresses to memory modules. This is necessary because, in order to operate on multiple elements of memory data within a single-bank local PIM execution unit, for example, to perform element reduction in an array, all memory addresses of the target operand must be mapped to the same physical memory bank. Furthermore, PIM commands from separate host threads using the same bank and PIM registers cannot be processed simultaneously by the PIM execution unit because doing so would cause a so-called "PIM collision," potentially corrupting intermediate data. Therefore, software must prevent multiple PIM commands from being issued simultaneously from different cores targeting the same bank and PIM registers, thereby reducing the bandwidth benefits provided by PIM.

[0004] Even without PIM, software awareness of memory addresses relative to memory module mappings is beneficial for the efficient execution of parallel applications in non-uniform memory access (NUMA) systems. As systems scale to include multiple compute and memory modules, the relative positions of compute modules to the memory modules they access can significantly impact performance. While software awareness of mapping information may not be necessary for application accuracy in this scenario, performance can be greatly improved if compute tasks are scheduled on compute modules close to the memory modules they access.

[0005] Requiring software to be aware of the mapping from memory addresses to memory modules is undesirable for several reasons. Mapping functions often differ across architectures, reducing code portability. Furthermore, mapping functions may differ for different implementations even on the same architecture, adding additional complexity to any mapping-aware software. For example, mapping functions may be dynamically programmed to optimize data interleaving strategies for different workloads. Moreover, exposing hardware-level memory address mappings to user software can create security vulnerabilities that malicious software can exploit. Finally, many software developers find it undesirable to consider underlying hardware details when developing software, as this negatively impacts productivity.

[0006] Existing approaches to address these problems include using partitioned global address spaces, distributed task queuing structures, first-touch page allocation, and page movement. These mechanisms are primarily designed to share highly regular patterns or coarse, i.e., page-level, data mappings. They do not adequately address the aforementioned problems with fine-grained, configurable mapping strategies and irregular access patterns, which may require frequent dynamic address translations and consideration of fine-grained address stride patterns. In the case of regular code patterns, if access patterns and dependencies are statically known and scheduling can be optimized for data mapping in the underlying hardware, it may be possible to automate accurate and efficient task scheduling in some cases. However, this is not possible with algorithms exhibiting irregularity or any kind of runtime data dependency. Therefore, a solution is needed for using PIM-enabled or NUMA systems in an effective way in applications with irregular data access patterns, without requiring knowledge of the mapping from memory addresses to memory modules.

[0007] Embodiments are shown in the accompanying drawings as examples, not as limitations, and similar reference numerals refer to similar elements. [Brief explanation of the drawing]

[0008] [Figure 1] This is a block diagram showing the microprocessor configuration. [Figure 2A] This flowchart shows the threads that push computation task data to the task processing mechanism. [Figure 2B] This is a flowchart illustrating the task processing mechanism that generates and issues computation tasks. [Figure 3A] This block diagram shows a traditional baseline task processing approach for managing PIM commands in a multithreaded environment. [Figure 3B]This block diagram shows how to manage PIM commands in a multithreaded environment using a task processing mechanism. [Modes for carrying out the invention]

[0009] The following description includes many specific details to provide a thorough understanding of the embodiments for illustrative purposes. However, it will be apparent to those skilled in the art that the embodiments can be carried out without these specific details. In other examples, well-known structures and devices are shown in block diagrams to avoid unnecessarily obscuring the embodiments. I. Overview II. Architecture III. Management of computational task data using a task processing mechanism

[0010] I. Overview The Address Mapping-Aware Tasking (AMAT) mechanism provides a technical solution to problems associated with using PIM-enabled or NUMA systems in a multithreaded environment by organizing computation tasks and task data and facilitating the correct / efficient placement of computation task execution. As used herein, the term “computation task” refers to one or more PIM or non-PIM instructions executed together in a single location, i.e., on a single PIM module or NUMA compute node. The term “computation task data” refers to data specifying one or more input parameters for such computation task, which may include, for example, one or more operations to be performed, one or more address or index values, one or more data values, dependency information, priority information, etc.

[0011] The AMAT mechanism stores computation task data generated by host threads in a set of logical partitions in memory, each partition designated for a specific memory module or memory submodule. The AMAT mechanism maintains address mapping data that maps address information to partitions, enabling computation task data to be stored in specific partitions. The partition selected for computation task data may be based on address information contained in the computation task data itself, e.g., the AMAT partition corresponding to the memory module containing data processed by the task according to input index parameters, or, for example, which partition occupies the least to reduce load imbalance between computation modules and memory modules when the computation task data contains all the data accessed by the task.

[0012] During computation, threads push computation task data to the AMAT mechanism before the computation task is executed. The AMAT mechanism determines the task partitions as described herein and stores the computation task data in those partitions. After being stored in the AMAT partitions, the computation tasks within each partition can then be processed independently so as to be executed near the memory module containing the computation task data.

[0013] In PIM-enabled systems, the AMAT mechanism ensures that all data accessed during the processing of a PIM task resides in the same memory element. The AMAT mechanism also ensures that PIM commands from different threads cannot be issued simultaneously to the same PIM-enabled memory element, thus avoiding PIM collisions. In NUMA systems, the AMAT mechanism ensures that some or all data accessed during the processing of a computation task is mapped to a memory element close to the computation module executing that task. The AMAT mechanism also ensures that concurrently running tasks access data in different memory elements, reducing contention and imbalance. In PIM-enabled use cases, throughput and parallelism are improved by allowing PIM commands to be issued simultaneously to different PIM execution units. This performance advantage is particularly important in memory bandwidth-sensitive applications such as machine learning, which involves sparse or irregular memory access and minimal data reuse. All of these advantages are achieved by the AMAT mechanism, as address mapping is handled by the AMAT mechanism, eliminating the need for threads to be aware of how memory addresses are mapped to specific memory elements or PIM execution units. For illustrative purposes, the embodiments are described below in a PIM-enabled memory context, but the embodiments are not limited to this context and are applicable to other contexts such as NUMA systems.

[0014] II. Architecture Figure 1 is a block diagram of a microprocessor configuration 100. The microprocessor configuration 100 includes a microprocessor 110 and a memory module 120. The microprocessor configuration 100 may include additional elements that are not shown or described herein for illustrative purposes.

[0015] The memory module 120 may be implemented with any type of computer memory, and the embodiments are not limited to any particular type of memory. According to one embodiment, the memory module 120 includes N PIM-enabled memory elements, each PIM-enabled memory element including one or more banks and a corresponding PIM execution unit configured to execute PIM commands, but the embodiments are not limited to dynamic random access memory (DRAM) or memory elements in the form of banks. Each PIM execution unit includes processing logic circuits such as an arithmetic logic unit (ALU), a lightweight central processing unit (CPU), a graphics processing unit (GPU), a microcontroller, and local storage such as one or more registers.

[0016] The microprocessor 110 may be any type of CPU, GPU, microcontroller, or logic circuit. Depending on the particular embodiment, the microprocessor 110 may have a single core or multiple cores, and the embodiment is not limited to a microprocessor having any particular number of cores or a particular type of core. Although only one microprocessor is shown, the embodiment may be distributed across multiple microprocessors, each having one or more threads, using well-studied prior art for distributed synchronization. The microprocessor 110 includes threads 130 and a task processing mechanism 140. Threads 130 are microprocessor threads and may include any number of threads and threads of any type. In the example shown in Figure 1, the threads include four threads identified as T1 to T4 for illustrative purposes. The microprocessor 110 may include other elements not shown and not described herein for illustrative purposes, such as one or more memory controllers, caches, buses, interfaces, etc. The microprocessor 110 and the memory module 120 are communicably coupled, for example, via one or more command buses and data buses.

[0017] The task processing mechanism 140 manages computation task data and facilitates the accurate and efficient execution of concurrent computation tasks. The task processing mechanism 140 includes partitions 142, address mapping data 144, management data 146, and a task processing manager 148. The task processing mechanism 140 may be implemented by computer hardware, computer software, or any combination of computer hardware and software, and may include additional components and data that may vary depending on the particular embodiment.

[0018] Partition 142 represents a conceptual division of computation task data, and the data contained in each partition is physically located in the corresponding memory element within the memory module 120. Thus, in the context of PIM-enabled memory, each of the N partitions contains computation task data for a particular PIM-enabled memory module and the corresponding PIM execution unit. Partition 142 can be implemented in any type of memory capable of storing computation task data, such as one or more registers, one or more caches or scratchpads, a portion of main memory, PIM local registers, etc. Although partition 142 is shown in Figure 1 as being located on the microprocessor 110 for illustrative purposes, embodiments are not limited to this example, and partition 142 may be located within the microprocessor 110, within the memory module 120, or elsewhere, depending on the particular embodiment. The size of partition 142 may be specified, for example, based on the size of the computation task data and the maximum number of partition inputs required for a particular embodiment. The portion of memory designated to store partition 142 may be contiguous or discontinuous, and may differ from partition to partition. For example, some partitions may be implemented in contiguous portions of memory, while others may be implemented in discontinuous portions of memory. The address range and other data of partition 142 may be stored in management data 146, as will be described in more detail below.

[0019] Address mapping data 144 is data used by the task processing manager 148 to determine which partition 142 to store the computation task data received from thread 130 in. Address mapping data 144 maps memory address information to partitions and / or memory elements, enabling a specific partition and / or memory element to be determined from predetermined memory address information. According to one embodiment, address mapping data 144 maps memory address information to partition identification data (ID) and memory element IDs. As will be described in more detail below, the task processing manager 148 stores the computation task data in the appropriate partition and then issues a computation task using the computation task data. The partition ID for a given computation task may be determined by several functions of a subset of address bits in the computation task data, specified by the address mapping data. Address mapping data 144 may be stored in any location accessible to the task processing mechanism 140, such as a dedicated memory location containing one or more registers, an area of ​​main memory, etc. In some embodiments, user-level code may be prevented from directly accessing or manipulating the address mapping data 144, so that user software cannot directly infer the details of the underlying address mapping, and partitioning can be performed completely transparently to the user software.

[0020] The task processing manager 148 manages the computation task data stored in partition 142, which includes storing computation task data in partition 142 and issuing computation tasks using the computation task data stored in partition 142. According to one embodiment, the task processing manager 148 is implemented by a microprocessor primitive, instruction, or memory-mapped target address, also referred to herein as "push," which provides the task processing mechanism 140 with the ability to store computation task data in one of the partitions 142. The task processing mechanism 140 is also provided with a primitive or instruction, also referred to herein as "pop," which causes it to execute the next computation task based on the computation task data stored in partition 142. In another embodiment, the hardware primitive is an instruction that translates a computation task data address to a partition ID, which can use a thread to push the computation task data to the appropriate partition of the computation task data software structure. In another embodiment, the hardware primitive simply represents an interface (e.g., a memory-mapped address or register) for extracting address mapping data (e.g., a bitmask indicating which address bits specify a partition ID), which can then be used by a thread to generate a partition ID from the compute task data address and push the compute task data to the correct partition in software.

[0021] The management data 146 is data used by the task processing manager 148 to manage the partition 142. This may include, for example, for each of the partitions 142, the address range of the partition, the next push address where the next calculation task data is stored in the partition, and the next pop address where the next calculation task data is retrieved from the partition and used to issue a calculation task. Depending on a particular embodiment, the management data 146 may include other data (e.g., instead of the next push / next pop address, the addresses of one or more head / tail / root / leaf nodes in a linked list or graph).

[0022] III. Management of Calculation Task Data Using a Task Processing Mechanism FIGS. 2A and 2B are flowcharts 200, 250 respectively showing the management of calculation task data using a task processing mechanism. The flowchart 200 of FIG. 2A shows a single thread that pushes calculation task data to the task processing mechanism 140 for illustration purposes, but is applicable to processing calculation task data from any number of threads.

[0023] In step 202, the thread generates calculation task data. This may be done at any time during thread execution. For example, while performing operations on data, the thread determines one or more next operations to be performed on the data stored at a particular memory address and generates calculation task data specifying the operation, memory address, and value. One non-limiting example of an operation is an arithmetic operation such as addition, subtraction, etc. performed on the data stored at a particular memory address. The thread may store the calculation task data in, for example, one or more registers, cache, main memory, etc.

[0024] In step 204, the thread that generated the computation task data calls a push primitive or instruction to push the computation task data generated by the thread to the task processing mechanism 140. More specifically, the computation task data is stored in one of the partitions 142. The thread may provide the address information within the computation task data or the target virtual address as an argument when calling the primitive or instruction. The thread may call the push primitive or instruction when the thread generates the computation task data or afterwards. According to one embodiment, instead of issuing a computation task as normally done, the thread uses a primitive or instruction to push the computation task data to the task processing mechanism 140.

[0025] In step 206, the address information within the computation task data is processed to determine the partition that stores the computation task data, i.e., the destination partition. Various techniques may be used to determine the destination partition based on the address information. According to one embodiment, a bit mask supplied by the address mapping data 144 is applied to the memory address bits within the computation task data to generate the resulting bits. The bit mask may include any number of bits that can vary according to a particular embodiment and address mapping pattern. Next, the resulting bits are used to determine the partition in which the computation task data is stored, and the computation task data corresponds to the memory element to which the original address is mapped in the underlying address mapping strategy.

[0026] In another embodiment, partitions are selected based on resource usage information present in the management data, either in conjunction with or instead of address information associated with computation tasks. For example, when the data required for a computation task is minimal, or when data locality is not particularly important in the system, it may be preferable to consider the amount of available memory space in available memory elements, or the load imbalance resulting from varying the number of pending tasks in each memory element, when selecting a target partition. Considering this data, which can be queried from the management data 146, can help reduce load imbalance or memory space imbalance across different memory elements.

[0027] According to one embodiment, for example, the determination of a target partition based on address information by applying a bitmask is performed based on the physical address bits of the specified address information. In some embodiments, generating a physical address from the supplied address information requires computation and / or translation. Rather than a complete address, only a base address and index offset may be supplied in the address information, and the target address is calculated based on the base address and index offset. This calculation may be implemented in software or hardware along the execution path (by routing the relevant data to existing arithmetic units, or by duplicating all or some of these arithmetic units for this execution path).

[0028] In some embodiments, address information is specified in a virtual address space, and the virtual address information is translated to a physical address space. However, in some embodiments, some or all of the target partition calculation may be performed before the translation. In systems with page-based virtual-to-physical address translation, in the case of a bitmask, any bits that fall into the page offset area of ​​the virtual address can be applied without translation. According to one embodiment, before performing the translation, the page size of the target virtual address is checked (in hardware or software) to determine whether it encompasses all bitmask bits (or, if this can be determined beforehand, the target virtual address is stored in a register or hardwired). If no translation is required, the partition determination can be calculated immediately based on the virtual address. If a translation is required, the virtual address is sent to the translation mechanism to generate the corresponding physical address.

[0029] According to one embodiment, the memory address bit value is processed using a hash function to generate a hash value for determining the memory mapping. The hash function may be of any type, and the embodiment is not limited to any particular type of hash function. The hash value is then used to determine the corresponding partition and memory element. In this example, the address mapping data 144 maps the hash value to the partition ID and memory element ID.

[0030] After the destination partition is determined in step 206, step 208 determines the next push address in the destination partition. The next push address is the next available address in the partition for storing the compute task data. According to one embodiment, the partition ID of the destination partition is used to look up the next push address in management data 146. Management data 146 includes data that maps the partition ID to the next push address. For example, the task processing manager 148 uses the partition ID of the destination partition and management data 146 to determine the next push address of the destination partition. According to one embodiment, the next push address for each partition is maintained in address mapping data 144 instead of management data 146. The next push address of a partition may or may not be contiguous with the address where the last compute task data was stored in the partition, depending on how the partition is stored in memory. Memory allocation may also be required, and the push primitive or instruction handles any allocation and memory stride necessary to store the compute task data in a location in memory that maps it to the appropriate memory element. In one embodiment, the push primitive is implemented as a hardware mechanism that takes a target partition ID and compute task data as input, allocates space for the compute task data within the target partition as needed (by initiating a system call and then performing any necessary copies or pointer updates for the underlying data structure), updates the "next push" information for the next caller (for example, in the case of contiguous partition allocation, this may include incrementing the "next push" pointer by the size of the compute task data), and returns a pointer to the allocated space.

[0031] In step 210, the computation task data is stored in the destination partition. For example, the task processing manager 148 stores the computation task data at the next push address in the destination partition determined in step 208. This can be achieved by the task processing manager 148 generating and issuing one or more store commands. Depending on the size of the computation task data and address mapping data, it may be necessary to issue multiple store commands to non-contiguous strides of memory to ensure that they map to the same memory element. The task processing manager processes this stride and also increments the next push address to the next available memory address in the partition, and updates either the management data 146 or the address mapping data 144 with the new next push address, depending on where the next push address in the partition is stored.

[0032] According to one embodiment, computation task data is ordered within a partition based on the time the computation task data was stored in the partition. The order may be time-series (first-in, first-out), reverse time-series (first-in, last-out), or partial ordering via a tree or graph structure based on specified or inferred dependencies. Thus, computation task data received from multiple threads is stored together in partition 142 based on when the computation task data was pushed to the task processing mechanism 140 by each thread.

[0033] According to one embodiment, when a push primitive or command is invoked, instead of storing the compute task data in the destination partition, the address of the destination partition is returned to the thread. The thread then uses the received address to store the compute task data in the partition. For example, suppose thread T1 invokes a push primitive or instruction for a particular compute task data. The destination partition is determined based on the address information contained in the compute task data, for example, using a bitmask or hash function as described above, to determine the destination partition corresponding to the compute task data. The next push address in the destination partition, for example, the memory address in the destination partition where the next compute task data will be stored, is determined using management data 146 and returned to thread T1. Thread T1 then issues a command to store the compute task data at the next available address in the particular partition.

[0034] According to one embodiment, when a push primitive or command is invoked, instead of storing the compute task data in the destination partition, an index (e.g., a numerical identifier) ​​of the destination partition is returned to the thread. The thread then stores the compute task data in the identified partition. In some such embodiments, each application may maintain a set of next push addresses for each partition in its own virtual address space. For example, suppose thread T1 invokes a push primitive or instruction for a particular compute task data. The destination partition is determined using, for example, a bitmask or hash function as described above, based on the address information contained in the compute task data to determine the destination partition corresponding to the compute task data. The indication of the destination partition is returned to thread T1, and then thread T1 refers to the next push address that thread T1 maintains for the destination partition, for example, the memory address where the next compute task data in the destination partition is stored, and then issues a command to store the compute task data at the next available address in the particular partition. Steps 202-210 are repeated for any number of threads and any number of pushes, thereby grouping the compute task data together by the PIM execution unit.

[0035] Flowchart 250 in Figure 2B illustrates how the task processing mechanism 140 generates and issues computation tasks using computation task data stored in partition 142. In step 252, a thread invokes a pop primitive or instruction to cause the task processing manager 148 to generate and issue computation tasks based on the computation task data stored in the partition. The thread invoking the pop primitive or instruction may be any thread, such as a management thread or background thread, running on the task processing mechanism 140 including the task processing manager 148, or a thread performing work, such as thread T1 within thread 130. The thread invoking the pop primitive or instruction may be the same or a different thread that generated the computation task data. The thread invoking the pop primitive or instruction may specify the source partition from which the computation task is issued, for example, by specifying a partition ID. Alternatively, the pop primitive or instruction may cause the task to generate and issue computation tasks from each partition containing computation task data, where the corresponding command execution unit is ready to execute the next computation task.

[0036] In step 254, the task processing mechanism 140 determines the next pop address in the source partition. For example, the task processing manager 148 looks up the next pop address in the specified source partition in the management data 146 when a pop primitive or instruction is invoked. It may also perform additional checks, such as examining the computation task data, to find the highest-priority computation task or the next "ready" computation task to be issued.

[0037] In step 256, the computation task data is retrieved from the source partition. For example, the task processing manager 148 loads the computation task data from the next pop address determined in step 254. According to one embodiment, the task processing manager 148 updates the next pop address, such as a pointer to the source partition, and updates the management data 146 with the updated pop address.

[0038] In step 258, a computation task is issued based on the retrieved computation task data. For example, in the context of PIM, the task processing manager 148 uses the computation task data to construct a fully valid PIM command, for example, using the address, operation, and value specified by the computation task data, and the ID of the PIM execution unit corresponding to the source partition. In step 260, the computation task is issued. For example, the task processing manager 148 causes the PIM command generated in step 258 to be issued to the memory system of the microprocessor configuration 100.

[0039] Steps 252-260 can be repeated any number of times and in parallel for any number of partitions. Since PIM commands are issued to different PIM execution units, PIM commands for different partitions may be generated and issued in parallel to their respective PIM execution units.

[0040] Using the approach described above, the task processing mechanism 140 ensures that all target operands of a PIM command are mapped to the same memory element, while avoiding PIM collisions or memory contentions from individual threads, without requiring the thread to be aware of the specific hardware embodiment of the memory module, more specifically, how the addresses are mapped to physical memory elements such as PIM execution units.

[0041] Figure 3A is a block diagram illustrating a conventional baseline task processing approach for managing PIM commands in a multithreaded environment running irregular applications. In Figures 3A and 3B, the term "module" refers to a memory element. A host thread loads computation task data from memory and generates PIM commands. For example, a thread loads computation task data specifying addresses, arithmetic operations, and values. The thread generates PIM commands using the computation task data loaded from memory. PIM commands from multiple host threads are serialized to avoid PIM collisions and issued to the memory system one at a time. This is necessary because it is not possible to safely assume where the data is stored and which destination PIM execution unit will process the PIM command. This can lead to performance degradation if PIM commands to different destination PIM execution units are not sufficiently interleaved, as some PIM execution units may remain idle while waiting for the next PIM command.

[0042] Figure 3B is a block diagram illustrating the management of PIM commands in a multithreaded environment using a task processing mechanism. As described herein, instead of generating and issuing its own PIM commands, threads push computation task data to the task processing mechanism. This can be executed as soon as the computation task data is generated, eliminating the traditional step of storing the computation task data in memory. The task processing mechanism stores the computation task data in partitions based on address information within the computation task data, so that all computation task data for each destination PIM execution unit is grouped together. As shown in Figure 3B, in response to one or more pop commands, the task processing mechanism generates and issues PIM commands to the memory system that can be executed in parallel for multiple PIM execution units and memory modules. By using the task processing mechanism in this way, parallelism is improved, PIM collisions are eliminated, and it is ensured that all operands of a PIM command are mapped to the same memory element without the host thread needing to know how memory addresses are mapped to physical memory elements, more specifically to PIM execution units and memory modules. All of these advantages, except for avoiding PIM collisions, are also realized in NUMA embodiments.

Claims

1. It is a microprocessor, Equipped with a task processing mechanism, The task processing mechanism described above is: Receiving first computation task data pushed to the task processing mechanism by a first thread that calls a push instruction, The first computation task data is stored in a first partition associated with a first memory element of the memory system, To generate a first calculation task based on the stored first calculation task data, To issue the first calculation task to the first memory element of the memory system, It is configured to do the following: Microprocessor.

2. The task processing mechanism is configured to determine the first memory element corresponding to the first computation task data based on the amount of available memory space of a plurality of memory elements including the first memory element. The microprocessor according to claim 1.

3. The task processing mechanism described above is: The process involves processing the address information in the first calculation task data to generate a processing result, Using the processing results, the first memory element corresponding to the first computation task data is determined, It is configured to do the following: The microprocessor according to claim 1.

4. The task processing mechanism, based on the first computation task data, determines the first memory element corresponding to the first computation task data. Applying a mask to at least a portion of the address information in the first calculation task data, or Using a hash function to process at least a portion of the address information in the first computation task data, It is configured to be determined by one or more of the following: The microprocessor according to claim 1.

5. The task processing mechanism described above is: Receiving a second calculation task data that is different from the first calculation task data, The second calculation task data is stored in the first partition, To generate a second computation task based on the stored second computation task data, The second calculation task is issued to the first memory element of the memory system, It is configured to do the following: The microprocessor according to claim 1.

6. The task processing mechanism generates the first computation task and issues the first computation task to the first memory element in response to the first thread or another thread calling a pop instruction that specifies the first partition. The microprocessor according to claim 1.

7. The task processing mechanism described above is: Receiving a second calculation task data that is different from the first calculation task data, The second computation task data is stored in a second partition associated with a second memory element different from the first memory element, To generate a second computation task based on the stored second computation task data, To issue the second calculation task to the second memory element of the memory system, It is configured to do the following: The microprocessor according to claim 1.

8. The second calculation task is issued to the second memory element in parallel with the first calculation task issued to the first memory element, The microprocessor according to claim 7.

9. The first memory element is a PIM-compatible memory element, The first calculation task data includes an address, an operation, and one or more values ​​within the first calculation task data. Generating the first calculation task includes generating a PIM command for the PIM-enabled memory element based on the address, the operation, and one or more values ​​in the first calculation task data. Issuing the first calculation task to the first memory element includes issuing the PIM command to the PIM execution unit associated with the PIM-enabled memory element. The microprocessor according to claim 1.

10. A computer execution method, The task processing mechanism within the microprocessor Receiving first computation task data pushed to the task processing mechanism by a first thread that calls a push instruction, The first computation task data is stored in a first partition associated with a first memory element of the memory system, To generate a first calculation task based on the stored first calculation task data, This includes issuing the first computation task to the first memory element of the memory system, Computer execution method.

11. The task processing mechanism includes determining the first memory element corresponding to the first computation task data based on the amount of available memory space of a plurality of memory elements including the first memory element. The computer execution method according to claim 10.

12. It is a system, A memory system including multiple memory elements, A microprocessor including a task processing mechanism, The task processing mechanism described above is: Receiving first computation task data pushed to the task processing mechanism by a first thread that calls a push instruction, The first computation task data is stored in a first partition associated with a first memory element of the memory system, To generate a first calculation task based on the stored first calculation task data, To issue the first calculation task to the first memory element of the memory system, It is configured to do the following: system.

13. The first memory element is a PIM-compatible memory element, The first calculation task data includes an address, an operation, and one or more values ​​within the first calculation task data. Generating the first calculation task includes generating a PIM command for the PIM-enabled memory element based on the address, the operation, and one or more values ​​in the first calculation task data. Issuing the first calculation task to the first memory element includes issuing the PIM command to the PIM execution unit associated with the PIM-enabled memory element. The system according to claim 12.

Images