Skew resistance PID device and processing method

The skew-resistant PID device and method address load imbalance in PID-Join algorithms by replicating join keys in banks and ranks, optimizing data distribution, and performing specific operations to enhance parallel processing performance and reduce latency.

JP7803601B1Active Publication Date: 2026-01-21IND ACADEMIC COOP FOUND YONSEI UNIV
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2025025217
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2024-10-30
Filing Date
2025-02-19
Publication Date
2026-01-21
Estimated Expiration
2045-02-19

AI Technical Summary

Technical Problem

Existing PID-Join algorithms experience performance and scalability issues due to load imbalance caused by skewed input tables, leading to some IDPs being idle while others are overloaded.

Method used

A skew-resistant PID device and processing method that replicates join keys in units of banks and ranks, determines an optimal replication ratio through a cost model, and performs Bank and Rank Set-aware Partitioning to distribute data evenly among IDPs, using a Host-to-DIMM scatter operation, All-to-All Inter-IDP Shuffle, and Single-IDP Join operations.

Benefits of technology

Improves parallel processing performance by evenly distributing data across IDPs, reducing load imbalance and latency, and maintaining efficient join operations even with skewed data distributions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007803601000001_ABST
    Figure 0007803601000001_ABST
Patent Text Reader

Abstract

The present invention provides a skew resistance PID device and processing method that improves the parallel processing performance of an IDP (In-DIMM Processor). [Solution] The skew resistance PID device according to the present invention is composed of multiple ranks each containing multiple banks, and includes DIMMs (Dual In-line Memory Modules) including an IDP that processes internal memory operations, a memory controller, and a host CPU that is connected to the DIMM via the memory controller and replicates join keys on a bank and rank basis to improve the parallel processing performance of the IDP.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to PID technology, and more particularly to a skew-resistant PID device and processing method that can improve the parallel processing performance of an IDP (In-DIMM Processor) by replicating a join key in units of a bank and a rank via a memory controller. [Background technology]

[0002] Recently, the development of dual inline memory modules (DIMMs) has enabled DIMMs to support in-DIMM processing (PID) by placing in-DIMM processors (IDPs) near the memory banks. PID can accelerate applications experiencing memory wall issues by offloading memory-intensive work to the IDP. Offloading work to the IDP allows applications to take advantage of the DIMM's high internal memory bandwidth and minimizes data movement between the host central processing unit (CPU) and the DIMM. Until recently, no commercial DIMMs supporting PID were available, but with the introduction of UPMEM DIMMs and Samsung AxDIMMs, interest in PID has grown in various fields, including bioinformatics, machine learning, and security.

[0003] In-memory databases often experience memory wall issues, but PID has proven to significantly improve this. In particular, previous research has proposed the PID-Join algorithm to accelerate in-memory join operations. Given two tables, R and S, the join operation begins with the CPU evenly distributing the tuples of R and S to each IDP, after which the IDP independently performs global partitioning. The CPU then remixes the tuples between the IDPs, allowing each IDP to process its own partition, and the IDPs then perform a single IDPJoin. The CPU then collects the output tuples from all IDPs and quickly executes the in-memory join operation.

[0004] However, existing PID-Join algorithms have the problem that performance and scalability decrease when the input table is skewed. Although such algorithms use global partitioning per IDP to balance the computational load among IDPs, the presence of skewed input tables causes serious load imbalance, resulting in some IDPs processing while others are idle. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Korean Patent Publication No. 2022-0062399 Summary of the Invention [Problem to be solved by the invention]

[0006] The present invention has been made in consideration of the above-mentioned problems of the prior art, and an object of the present invention is to provide a skew-resistant PID device and processing method that can improve the parallel processing performance of IDP by duplicating join keys in units of bank and rank.

[0007] It is also an object of the present invention to provide a skew-resistant PID device and processing method that can determine a cost model for determining the replication ratio based on the configuration of the PID device.

[0008] Another object of the present invention is to provide a skew-resistant PID device and processing method that can determine the number of bank sets and rank sets by calculating the optimal join key replication ratio (RRoptimal) through a cost model. [Means for solving the problem]

[0009] In order to achieve the above object, one aspect of the present invention provides a skew resistance PID device that includes a DIMM (Dual In-line Memory Module) that is composed of a plurality of ranks, each of which includes a plurality of banks, and that includes an IDP (In-DIMM Processor) that processes internal memory operations; a memory controller; and a host CPU that is connected to the DIMM via the memory controller and that replicates join keys on a bank and rank basis to improve the parallel processing performance of the IDP.

[0010] The host CPU can analyze the configuration of the R and S tables and determine a cost model that determines the replication ratio based on the configuration of the skew resistance PID device.

[0011] The host CPU can determine the number of bank sets and the number of rank sets by calculating an optimal join key replication ratio (RRoptimal) through the cost model.

[0012] The host CPU can execute a Host-to-DIMM scatter operation that distributes and transfers the R table and the S table to the DIMM.

[0013] The IDP can perform a Bank and Rank Set-aware Partitioning operation that replicates the R table to the bank set and the rank set, and distributes the S table to the bank set and the rank set based on the replication of the R table.

[0014] The host CPU can perform an All-to-All Inter-IDP Shuffle operation by transferring the data of the R table and the S table to each IDP, allowing each IDP to exchange and process the data of the R table and the S table.

[0015] Each IDP can perform a Single-IDP Join operation to perform a Join operation based on the data in the R table and the S table and generate a corresponding Join result.

[0016] Each IDP can perform a hash join or an order-merge join in the join operation.

[0017] Each IDP may transfer the corresponding join results to the host CPU, which may then aggregate the corresponding join results to generate a final result.

[0018] In order to achieve the above object, one aspect of the present invention provides a skew-resistant PID processing method executed in a skew-resistant PID (Processing in DIMM) device including a DIMM (Dual In-line Memory Modules) composed of a plurality of ranks each including a plurality of banks, the DIMM including an IDP (In-DIMM Processor) for processing internal memory operations, a memory controller, and a host CPU connected to the memory module via the memory controller, the method comprising: determining a duplication ratio based on a configuration of the PID device; and duplicating a Join key in units of banks and ranks of the DIMM based on the duplication ratio to improve parallel processing performance of the IDP. [Effects of the Invention]

[0019] The disclosed technology according to the present invention has the following advantages. However, it does not mean that a particular embodiment should include all or only the following advantages, and the technical scope of the present invention is not limited thereby.

[0020] The skew-resistant PID device and processing method of the present invention can improve the parallel processing performance of the IDP by replicating the join key in units of banks and ranks.

[0021] The skew resistant PID device and processing method of the present invention can determine a cost model that determines the replication ratio based on the configuration of the PID device.

[0022] The skew-resistant PID device and processing method of the present invention can determine the number of bank sets and the number of rank sets by calculating the optimal Join key replication ratio (RRoptimal) through a cost model. [Brief explanation of the drawings]

[0023] [Figure 1] 1A and 1B are diagrams illustrating the characteristics of a conventional PID-Join algorithm and SPID-Join; [Figure 2] FIG. 2 is a diagram illustrating the functional configuration of a skew-resistance PID device according to an embodiment of the present invention. [Figure 3] FIG. 2 is a diagram illustrating a PID-Join algorithm according to an embodiment of the present invention. [Figure 4] 3 illustrates an example of a cost model according to one embodiment of the skew resistance PID device of FIG. 2. [Figure 5] 1 is a flowchart illustrating a skew resistance PID processing method according to the present invention. [Figure 6] FIG. 1 is a diagram illustrating the bankset-based Join key replication process of the SPID-Join algorithm. [Figure 7] FIG. 1 is a diagram illustrating the rank set-based Join key replication process of the SPID-Join algorithm. [Figure 8] This is a diagram explaining the partitioning of SPID-Join banks and rank sets for IDPs and input tuples. [Figure 9] FIG. 2 is a diagram illustrating variables for constructing a cost model according to one embodiment of the present invention. [Figure 10] FIG. 10 is a diagram illustrating the Join operation delay time of the PID-Join algorithm according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0024] The description of the present invention is merely an embodiment for structural or functional explanation, and therefore the technical scope of the present invention should not be construed as being limited by the embodiment described in the specification. In other words, since the embodiments can be variously modified and can have various forms, the technical scope of the present invention should be understood to include equivalents that can realize the technical idea. Furthermore, the objectives or effects presented in the present invention do not mean that a particular embodiment should include all of them or should include only such effects, and therefore the technical scope of the present invention should not be understood as being limited thereby.

[0025] Meanwhile, the meanings of the terms used in this specification should be understood as follows.

[0026] Terms such as "first" and "second" are used to distinguish one component from another and should not be used to limit the scope of the technology. For example, a first component may be named a second component, and similarly, a second component may be named a first component.

[0027] When a component is said to be "connected" to another component, it should be understood that it may be directly connected to the other component, but there may also be other components in between. Conversely, when a component is said to be "directly connected" to another component, it should be understood that there are no other components in between. Meanwhile, other expressions describing the relationship between components, such as "between" and "immediately between," or "adjacent to" and "directly adjacent to," should be interpreted similarly.

[0028] Singular expressions should be understood to include plural expressions unless the context clearly dictates otherwise, and terms such as "comprise" or "have" are intended to specify the presence of embodied features, numbers, steps, operations, components, parts, or combinations thereof, but do not preclude the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0029] The use of identifiers (e.g., a, b, c, etc.) in each step is for convenience of description, and the identifiers do not dictate the order of the steps, and the steps may occur in a different order than specified unless the context clearly dictates a specific order. That is, the steps may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

[0030] The present invention is embodied as computer-readable code on a computer-readable recording medium, which includes any type of recording device that stores data readable by a computer system. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. The computer-readable recording media may also be distributed among computer systems connected to a network, allowing the computer-readable code to be stored and executed in a distributed manner.

[0031] Unless otherwise defined, all terms used herein have the same meaning as commonly understood by a person of ordinary skill in the art to which the present invention pertains. Terms commonly used and defined in advance are interpreted to be consistent with the meaning they have in the context of the relevant art, and are not interpreted as having an ideal or overly formal meaning unless explicitly defined herein.

[0032] FIG. 1 is a diagram illustrating the characteristics of a conventional PID-Join algorithm and SPID-Join.

[0033] Referring to Figure 1, we compare the main characteristics of three Processing-in-DIMM (PID) Join algorithms.

[0034] UPMEM-Join and PID-Join are equivalent to the conventional PID-Join algorithm, and perform joins through IDP-wise Global Partitioning. Here, IDP-wise Global Partitioning corresponds to a method in which a processor built into the DIMM 110 (see Figure 2) distributes data processing. For example, it corresponds to a method in which tuples (rows) of input tables R and S are evenly divided among each IDP 111. In IDP-wise Global Partitioning, if a specific join key is biased and concentrated on a specific IDP 111, the load on that IDP 111 becomes excessive, resulting in load imbalance. In other words, even if other IDPs 111 have finished their work, they must wait until the work of the IDP 111 with the heaviest load is completed.

[0035] Meanwhile, SPID-Join performs Replication-aware Global Partitioning using Bank-&Rank-wise Replication+Partitioning. Here, Bank-&Rank-wise Replication+Partitioning is a method that utilizes the parallelism of banks 113 and ranks 112 in memory, and Replication-aware Global Partitioning is a technology that introduces data replication to solve the load imbalance problem of existing IDP-wise Global Partitioning. In other words, SPID-Join can distribute the load to multiple IDPs through replication even if the join key is biased, thereby effectively resolving load imbalance.

[0036] Additionally, both UPMEM-Join and PID-Join distribute data equally across the IDP111 by dividing the R and S tables using the IDP-wise Global Partitioning method, but biased input data can cause load imbalances. On the other hand, SPID-Join uses the Bank-&Rank-wise Replication+Partitioning method to finely adjust data division and distribute load through replication. Comparing the R and S table size ratios of UPMEM-Join, PID-Join, and SPID-Join, UPMEM-Join is optimized for a 1:1 ratio, while PID-Join and SPID-Join have no restrictions on the R:S ratio, allowing for flexible operation at various ratios.

[0037] FIG. 2 is a diagram illustrating a skew-resistant PID device according to one embodiment of the present invention.

[0038] Referring to FIG. 2, the skew-resistant PID device 100 includes a DIMM 110, an IDP 111, a rank 112, a bank 113, a memory controller 120, and a host CPU .

[0039] The DIMM 110 includes multiple ranks 112, each including multiple banks 113, and an IDP 111 that processes internal memory operations. The DIMM 110 corresponds to a module that stores and transfers memory data in a computer system implementing host memory. The DIMM 110 includes multiple banks 113 to provide high memory bandwidth and capacity. The DIMM 110 also has a hierarchical structure consisting of banks 113 and ranks 112, with each rank 112 consisting of multiple banks 113. The DIMM 110 can distribute consecutive bytes of a burst across multiple banks 113 using a byte-interleaving technique. For example, in the case of a Double Data Rate 4 (DDR4) DIMM configured for 64-bit bursts, 8 bytes of a burst are distributed and processed across multiple memory banks. A burst corresponds to the smallest data access unit supported by the DIMM 110.

[0040] In one embodiment, the DIMM 110 provides bank-level parallelism and rank-level parallelism. Here, the DIMM 110 processes memory requests through bank-level parallelism by accessing multiple banks 113 in parallel. Furthermore, the DIMM 110 can provide inter-rank parallelism, which processes different memory requests in parallel, by independently operating multiple ranks 112 through a control signal dedicated to each rank 112.

[0041] The memory controller 120 manages and coordinates data transfer between the host CPU 130 and the DIMM 110. For example, the memory controller 120 manages the operation of reading and writing data from the DIMM 110 in response to a request from the host CPU 130. Furthermore, when the host CPU 130 accesses the DIMM 110, the memory controller 120 translates a logical memory address into a physical memory address, thereby transmitting the request generated by the host CPU 130 to the correct memory location. The memory controller 120 performs a memory bandwidth management operation to coordinate data transfer between multiple memory channels and banks 113, but is not necessarily limited to this operation. The memory controller 120 may also perform an operation of distributing or aggregating data to multiple banks 113 when transferring data from the DIMM 110 in burst mode.

[0042] The host CPU 130 is connected to the memory module via the memory controller 120 and replicates the join key in units of banks 113 and ranks 112 to improve the parallel processing performance of the IDP 111. Here, the join key corresponds to a key value used in a database join operation, and is used, for example, when performing a join between two different tables based on a common attribute value between the database tables. The host CPU 130 replicates the join key in units of banks 113 and ranks 112 and performs inter-table data matching based on the replicated join key to perform the parallel processing work of the IDP 111.

[0043] In one embodiment, the host CPU 130 analyzes the configurations of the R table and the S table and determines a cost model for determining a replication ratio based on the configuration of the PID device 100. Here, the R table and the S table correspond to input tables used in the process of performing a join operation in a database and distributed computing. The R table acts as the first input table in the join operation, and the S table acts as the second input table. The host CPU 130 analyzes the sizes of the R table and the S table and the distribution of join keys included in each table based on the cost model and determines the replication ratio of each join key based on the analysis result. For example, the host CPU 130 determines the join key replication ratio of the R table and the S table based on the cost model, taking into account the time required for the join operation, memory bandwidth usage, and data imbalance.

[0044] In one embodiment, the host CPU 130 calculates an optimal join key replication ratio (RRoptimal) through a cost model to determine the number of sets of banks 113 and the number of sets of ranks 112. Here, the optimal join key replication ratio corresponds to a ratio indicating how many times a join key should be replicated across multiple IDPs 111 to solve a data skew problem. The host CPU 130 determines the optimal join key replication ratio for distributing data that can be processed by the IDPs 111 according to the number of sets of banks 113 and ranks 112 of the PID device 100 through the cost model. For example, the host CPU 130 analyzes the size and distribution of the R table and the S table to determine the optimal join key replication ratio according to memory cost, processing cost, and communication cost, and then distributes data according to the join key replication ratio.

[0045] In one embodiment, the host CPU 130 performs a Host-to-DIMM scatter operation to distribute and transfer the R table and the S table to the DIMM 110. Here, the Host-to-DIMM scatter operation corresponds to an operation in which the host CPU 130 distributes and efficiently allocates data to multiple memory banks 113 and ranks 112 while transferring data of the R table and the S table to the DIMM 110. The host CPU 130 distributes and transfers the data of the R table and the S table to multiple banks 113 and ranks 112 through the Host-to-DIMM scatter operation. For example, the host CPU 130 performs parallel processing by distributing data of a specific join key according to the number of banks 113 and ranks 112 of a specific IDP 111 based on the Host-to-DIMM scatter operation.

[0046] In one embodiment, the IDP 111 performs a bank and rank set-aware partitioning operation to replicate the R table to a set of banks 113 and a set of ranks 112, and distribute the S table to the set of banks 113 and a set of ranks 112 based on the replication of the R table. Here, the bank and rank set-aware partitioning operation corresponds to an operation in which the IDP 111 appropriately replicates and divides data of the R table and the S table to each bank 113 and rank 112, stores the data in the DIMM 110, and enables each IDP 111 to process the data in parallel. The IDP 111 performs replication of the R table according to each bank 113 and rank 112, and distributes the S table to the banks 113 and ranks 112 based on the replicated R table.

[0047] In one embodiment, the host CPU 130 transfers data in the R table and the S table to each IDP 111 and performs an All-to-All Inter-IDP Shuffle operation to enable each IDP 111 to exchange and process the data in the R table and the S table. The All-to-All Inter-IDP Shuffle operation corresponds to a process of rearranging and exchanging data so that data matching the Join key is properly distributed before each IDP 111 independently performs a Join operation. The host CPU 130 exchanges data in the R table and the S table of each IDP 111 through the All-to-All Shuffle operation, allowing each IDP 111 to independently perform a Join operation. In this way, the host CPU 130 exchanges data evenly between each IDP 111 to prevent data from concentrating on a specific IDP 111.

[0048] In one embodiment, each IDP 111 performs a Single-IDP Join operation, which performs a Join operation based on the data in the R table and the S table to generate a corresponding Join result. Here, the Single-IDP Join operation corresponds to an operation that performs a Join operation using only the data assigned to each IDP 111 without additional data exchange with other external processors by performing local processing based on the data in the R table and the S table corresponding to the Join key held by each IDP 111, and this operation is performed after the All-to-All Inter-IDP Shuffle operation. Each IDP 111 performs a Join operation based on the data in the R table and the S table received from the host CPU 130 to join the R table and the S table and generate a Join result.

[0049] In one embodiment, each IDP 111 performs a hash join or a sort-merge join in a join operation. Here, a hash join corresponds to a method of converting a join key into a hash function and then joining data between tables based on the hash function. A sort-merge join corresponds to a join method used when two tables are pre-sorted on the join key. For example, a sort-merge join corresponds to a method of sorting data in the R table and the S table, and merging and joining the data based on the same join key. Each IDP 111 generates a hash table by performing a hash join, converts the join key into a hash function, and stores it in a hash slot. Each IDP 111 also performs a sort-merge join on the sorted R table and S table to merge data when the join keys of the tables match.

[0050] In one embodiment, each IDP 111 transfers the corresponding join result to the host CPU 130, which then collects the corresponding join results to generate a final result. Here, each IDP 111 transfers the join result generated by performing a join operation between the R table and the S table to the host CPU 130. Thereafter, the host CPU 130 merges the results distributed according to the processing scope of each IDP 111 to generate a final join result. For example, the host CPU 130 collects the join results received from each IDP 111 and merges data corresponding to duplicate join keys or the same ID to generate a final join table.

[0051] FIG. 3 is a diagram illustrating the PID-Join algorithm according to one embodiment of the present invention.

[0052] Referring to Figure 3, the PID-Join algorithm PID-Join uses two input tables R and S stored in the host memory. The process of executing JPEG0007803601000002.jpg3060 will be explained. Here, we assume that |R|≦|S|.

[0053] First, the host CPU 130 evenly distributes and transfers R and S tuples from host memory to all IDPs 111. Here, a tuple corresponds to a data unit that means a row or record in a relational database. Second, the IDP 111 performs IDP-wise Global Partitioning on the R and S tuples assigned to it. Third, the host CPU 130 causes all IDPs 111 to transfer their own tuples and move them to IDP 111 locations that conform to IDP-wise Global Partitioning. Fourth, each IDP 111 performs a Single-IDP Join operation on the R and S partitions assigned to it to generate a partition join result. For example, each IDP 111 performs a hash join to further partition the given R and S partitions to fit the WRAM (Working RAM) size, and then uses 24 hardware threads to build a hash table that fits the WRAM size and process the partitions in parallel. Finally, the host CPU 130 collects the join results generated for each IDP 111 from all the IDPs 111, and finally completes the join operation.

[0054] FIG. 4 is a diagram illustrating an example of a SPID-Join algorithm according to an embodiment of the present invention.

[0055] 4, the SPID-Join algorithm supports various Join key duplication ratios by leveraging the parallelism of the banks 113 and ranks 112 of the DIMM 110. The SPID-Join algorithm groups the IDPs 111 of the PID-supported DIMM 110 into rank 112 sets and bank 113 sets, duplicates R in each set, and evenly distributes the S tuples. Here, at least one IDP 111 forms at least one bank 113 set, and a rank 112 set is composed of at least one rank 112. Then, for each bank 113 and rank 112 set, the SPID-Join algorithm partitions the R and S tuples of each set into IDPs 111, shuffles the tuples between the IDPs 111, and has each IDP 111 perform a Single-IDP Join operation on its own tuple partition.

[0056] Here, replicating the R table increases the number of IDPs 111 assigned to each R tuple, increasing internal memory bandwidth and computational processing. Evenly distributing the tuples of the S table to each bank 113 and rank 112 set reduces load imbalance among IDPs 111 caused by S skew. Because each set receives one R table replica, the total number of sets is the SPID-Join join key replication ratio. SPID-Join then adjusts the count of banks 113 and ranks 112 to match the total number of bank 113 and rank 112 sets to match a given join key replication ratio. For example, if eight UPMEM DIMMs 110 jointly provide 16 ranks 112 and 64 banks 113 per rank, SPID-Join supports join key replication ratios from 1 to 1,024.

[0057] The SPID-Join algorithm first identifies an optimal Join key replication ratio using a cost model. Then, the SPID-Join algorithm determines the number of rank 112 sets and bank 113 sets according to the selected Join key replication ratio. The SPID-Join algorithm then performs a Host-to-DIMM scatter operation to evenly distribute tuples from the host CPU 130 to the DIMM 110, thereby evenly distributing all tuples of the R table and S table to all IDPs 111. Each IDP 111 then performs a Bank and Rank Set-aware Partitioning operation on the R table and S table tuples based on the number of rank 112 sets and bank 113 sets to evenly distribute the S partitions among the rank 112 sets and bank 113 sets and equally replicate the R partitions across all rank 112 sets and bank 113 sets. Then, the SPID-Join algorithm performs an All-to-All Inter-IDP Shuffle operation to transfer the R table and S table tuples from the source IDP 111 to the destination IDP 111. The IDP 111 performs a Single-IDP Join operation for each R table and S table partition. Finally, the host CPU 130 collects the Join results from the DIMM 110 to the host CPU 130.

[0058] FIG. 5 is a flow chart illustrating the skew resistance PID processing method according to the present invention.

[0059] 5, the skew-resistant PID device 100 determines a replication ratio based on the configuration of the PID device (step S510). Here, the skew-resistant PID device 100 calculates an optimal Join key replication ratio (RRoptimal) through a cost model to determine the number of sets in the banks 113 and the number of sets in the ranks 112. The skew-resistant PID device 100 also analyzes the sizes and distributions of the R table and the S table to determine the optimal Join key replication ratio based on memory cost, processing cost, and communication cost, and performs data distribution according to the Join key replication ratio.

[0060] The skew-resistant PID device 100 replicates the join key in units of banks 113 and ranks 112 of the DIMM 110 based on the replication ratio (step S530), thereby improving the parallel processing performance of the IDP 111. Here, the skew-resistant PID device 100 replicates the join key in units of banks 113 and ranks 112 by performing a host-to-DIMM scatter operation, a bank and rank set-aware partitioning operation, an all-to-all inter-IDP shuffle operation, and a single-IDP join operation, thereby improving the parallel processing performance of the IDP 111.

[0061] FIG. 6 is a diagram illustrating the bankset-based Join key replication process of the SPID-Join algorithm.

[0062] 6, the SPID-Join algorithm begins by having the host CPU 130 issue a single burst-length memory request to load eight Join Keys from eight memory banks 113 into the 64-byte vector register of the host CPU 130. The SPID-Join algorithm then repeats the Join Key duplication and vector register rotation eight times to duplicate the Join Keys in all eight sets of banks 113. In each iteration, the eight Join Keys stored in the vector register are distributed to eight memory banks 113 belonging to different sets of banks 113 using the burst-length memory request. Because each set of banks must obtain all eight Join Keys according to byte interleaving, the SPID-Join algorithm rotates the vector register by eight bytes (i.e., the tuple size including the 4-byte Join Key and the 4-byte tuple index) before moving on to the next iteration.

[0063] In the next iteration, the SPID-Join algorithm again distributes the Join keys using burst length memory requests, and each bank 113 set obtains the Join key that appears later among the eight Join keys stored in the vector register. After all iterations are performed, eight Join keys are replicated to each of the eight bank 113 sets, completing the task of replicating the eight Join keys to the eight bank 113 sets. This allows the SPID-Join algorithm to complete the Join key replication using only nine burst length memory requests and seven vector register rotations. The SPID-Join algorithm can increase the number of iterations and adjust the target bank 113 to replicate a larger number of Join keys to more bank 113 sets.

[0064] FIG. 7 is a diagram illustrating the rank set-based Join key replication process of the SPID-Join algorithm.

[0065] 7, the SPID-Join algorithm illustrates how it accelerates Join key replication in a rank 112 set configuration with two rank 112 sets and eight ranks 112 per rank 112 set. Similar to replicating Join keys between bank 113 sets, SPID-Join first loads the Join key into a vector register. The SPID-Join algorithm then distributes the Join key to the two rank 112 sets in parallel. Here, one host CPU 130 thread distributes the Join key to the bank 113 sets of one rank 112 set, while the other host CPU 130 thread performs the same task for the other rank 112 set.

[0066] The host CPU 130 then rotates the vector register one Join key at a time and repeatedly distributes the Join keys to the banks 113 of two Rank 112 sets at a time. This allows the SPID-Join algorithm to increase the Join key replication bandwidth by the number of Rank 112 sets (rank set count). If the number of Rank 112 sets is set to the number of PID support Ranks 112, the total memory bandwidth provided by the entire memory channel of the PID device 100 can be maximized.

[0067] FIG. 8 is a diagram illustrating the bank and rank set-based partitioning of SPID-Join for IDPs and input tuples.

[0068] FIG. 8 shows a method for performing a Bank and Rank Set-aware Partitioning operation on tuples in the R table and the S table when the IDP 111 has eight bank sets and two rank sets. First, the IDP 111 performs Radix partitioning to divide the R table and the S table into "numIDPsPerSet" partitions. Here, "numIDPsPerSet" is set to a value obtained by dividing the number of all IDPs 111 available in the PID device 100 by the number of bank 113 sets (bank set count) and the number of rank 112 sets (rank set count). For example, in a PID device 100 having 1,024 IDPs 111, "numIDPsPerSet" is set to 64 (=1024 / (2×8)). Here, "rankSetCount" = 2 and "bankSetCount" = 8.

[0069] The IDP 111 then performs R table replication and S table distribution. Here, R table replication replicates the tuples of each R partition to the corresponding (bankSetCount x rankSetCount) IDP-wise partitions, and S distribution distributes the tuples of each S partition to the IDP-wise partitions. The IDPs 111 associated with an IDP-wise partitioning belong to different bank 113 and rank 112 sets. When the IDP 111 processes all numIDPsPerSet partitions of R and S, the Bank and Rank Set-aware Partitioning operation is completed, and the tuples stored in the IDP-wise partitions are transferred to the corresponding destination IDP 111 by performing the next stage of the Join operation (i.e., inter-IDP shuffle).

[0070] FIG. 9 is a diagram illustrating variables for constructing a cost model according to an embodiment of the present invention.

[0071] JPEG0007803601000003.jpg51170

[0072] JPEG0007803601000004.jpg31170

[0073]

number

[0074] JPEG0007803601000006.jpg14170

[0075] JPEG0007803601000007.jpg9170

[0076]

number

[0077] To find the lowest join execution latency, we evaluate the join execution latency (i.e., Latency) of the SPID-Join algorithm. SPID-Join ) is modeled as the sum of the delay times of the five Join execution stages. Here, the five Join execution stages are grouped into two: PID execution and inter-IDP communication. Here, when the SPID-Join algorithm utilizes hash join in the Single-IDP Join operation, the following Equation 3 is obtained.

[0078]

number

[0079] Here, "SP" stands for Bank and Rank Set-aware Partitioning operation, "LP", "Build", and "Probe" correspond to the three internal stages of Single-IDP Join operation (i.e., local partitioning, hash table generation, and hash table probe), "HtoD" corresponds to Host-to-DIMM scatter operation, "Shuffle" corresponds to All-to-All Inter-IDP Shuffle operation, and "DtoH" corresponds to Join result gathering from DIMM 110 to host CPU 130.

[0080] Five stages of delay time and the required memory capacity in a single bank (i.e., "Capacity SPID-Join To model the "SPID-Join" algorithm, the cost model must calculate the total number of R and S tuples involved in each step and the number of tuples per IDP 111. Since the Join key duplication in the SPID-Join algorithm increases the number of R tuples, the number of tuples per IDP 111 and the total number of tuples are calculated as follows:

[0081]

number

[0082] Here, #IDPs corresponds to the total number of IDPs available in a PID-supported system, while S-tuples are distributed to banks and rank sets. Since all IDPs 111 must wait until the IDP with the highest load completes execution in each Join execution stage, the cost model is modeled by taking advantage of the fact that the IDP 111 with the highest load has a dominant influence on the execution delay time of each stage, rather than accurately calculating the total size of S-tuples and the size of each IDP. Therefore, the number of S-tuples per IDP and the total number of S-tuples is modeled as shown in Equation 5 below.

[0083]

number

[0084] JPEG0007803601000012.jpg54170

[0085]

number

[0086] Here, to model the number of S-tuples in the IDP 111 with the highest load, we gained an important insight: the S-tuple distribution of the SPID-Join algorithm distributes not only the most popular join key, but also the load of all other join keys. Therefore, the most popular join key of S remains the most popular join key even after the S-tuples are distributed to the IDP 111. Based on this important insight, we assume that all join keys, excluding the most popular join key, have little impact on the IDP 111 with the highest load, regardless of the replication ratio. Therefore, the cost model calculates the number of S-tuples in the IDP with the highest load as shown in Equation 7.

[0087]

number

[0088] JPEG0007803601000015.jpg15170

[0089] JPEG0007803601000016.jpg72170

[0090]

number

[0091] where the Zipf factor characterizes the nth most popular value, JPEG0007803601000018.jpg16149. Here, multiplying |S| by the probability of the most popular join key (i.e., n=1) yields the number of S-tuples that have the most popular join key.

[0092] Using the formula mentioned above, the cost model can estimate the execution delay time for each stage of the join operation. Here, the first two stages, the Host-to-DIMM scatter operation and the Bank and Rank Set-aware Partitioning operation, are not affected by the Join key replication ratio of the SPID-Join algorithm, so these delay times can be modeled as follows:

[0093]

number

[0094] All remaining steps occur after the Bank and Rank Set-aware Partitioning operation, so the number of Bank 113 and Rank 112 sets in the SPID-Join algorithm must be taken into account. Based on Equation 9, the remaining steps of the Join operation are modeled as follows:

[0095]

number

[0096] FIG. 10 is a diagram illustrating the join operation delay time of the PID-JOIN algorithm according to an embodiment of the present invention.

[0097] Referring to Figure 10, we compare the join execution delay time of SPID-Join with that of PID-Join. Here, we conducted an experiment to compare the join execution delay time between each algorithm. The experiment was carried out as follows:

[0098] 1.1 Experimental Setup

[0099] Experiments were conducted to compare the performance of SPID-Join with PID-Join and UPMEM-Join. The data used were a synthetic dataset and the TPC-H dataset, with table sizes varying from 0.5M to 32M and table ratios ranging from 1:1 to 1:8. A Zipf distribution was used to model non-normal distributions of the data, with Zipf factors ranging from 0.0 (uniform distribution) to 2.0 (skewed distribution). The PID-Join algorithm was compiled with g++-11, and comparisons were conducted in various environments.

[0100] 1.2 Fast Join Executions with Skewed Tables

[0101] SPID-Join performed significantly better than PID-Join when data distribution was irregular. When the Zipf factor was 1.0, 1.5, and 2.0, SPID-Join was up to 10.38 times faster than PID-Join. In particular, when data was biased, PID-Join's performance deteriorated due to uneven load distribution among IDPs, but SPID-Join solved this problem through dynamic load balancing. In addition, while PID-Join's performance deteriorated due to memory shortage issues, SPID-Join experienced relatively fewer memory shortages.

[0102] 1.3 Scalability Analysis

[0103] Even on a uniform data set with a Zipf factor of 0.0, SPID-Join performed better than PID-Join. While the performance difference with PID-Join decreased with uniform distribution, SPID-Join still ran up to 3.07 times faster than PID-Join. This indicates that SPID-Join can perform efficient joins regardless of data distribution. While PID-Join also experienced memory shortages in this case, SPID-Join experienced fewer such memory shortages.

[0104] 1.4 Mitigation of Inter-IDP Load Imbalance

[0105] To evaluate the efficiency of SPID-Join, we varied the Zipf factor of S from 0.0 to 2.0 using 0.5M tuples and a 1.8 ratio, and compared the tuple distribution between IDP111s for PID-Join and SPID-Join. SPID-Join successfully alleviated load imbalance between IDP111s at all Zipf factors. At a Zipf factor of 2.0, the standard deviation of the tuple distribution for PID-Join was 78,974, while that for SPID-Join was 6,223. Furthermore, we measured the join execution latency, showing that SPID-Join recorded a significantly lower latency of 165 ms compared to 1,909 ms for PID-Join. SPID-Join also had significantly lower unused time for rank 112 and IDP111. These results demonstrate that SPID-Join's rank 112- and bank 113-based join key replication effectively manages load imbalances.

[0106] 1.5 Validation of Cost-Driven Replication Ratio

[0107] To validate the cost-based replication ratio selection for SPID-Join, we varied the Zipf factor from 0.0 to 2.0, predicted join latencies, and evaluated the accuracy of the cost model. The results showed that SPID-Join join latencies using the optimal replication ratio were only 0.85% higher than the Oracle latencies. The cost model correctly selected the optimal replication ratio for three of the five benchmarks, effectively capturing the tradeoff between the benefits of join key replication and the overhead of R replication. However, at low replication ratios, the actual latencies tended to be slightly higher than the predicted latencies. This was due to a slight error in the cost model's communication modeling.

[0108] 1.6 Fast Join Executions with TPC-H Dataset

[0109] To evaluate the performance of SPID-Join, we compared the execution latency of joins between multiple tables using the TPC-H dataset. Using a scale factor of 10 for the TPC-H dataset, we ran a join simulation involving the Lineitem, Part, Supplier, and Orders tables. SPID-Join performed up to 4.88 times faster than PID-Join as the Zipf factor increased, with a mean absolute percentage error of only 0.72%, highlighting the efficiency of cost-based replication ratio selection. However, due to the size of the Orders table, SPID-Join's performance on biased data was somewhat limited.

[0110] 1.7 System Cost

[0111] To compare the system costs of SPID-Join and PID-Join, the recommended retail price of the PID device 100 was calculated. As the Zipf factor increased, SPID-Join's cost-to-performance ratio remained relatively constant, while PID-Join's cost-to-performance ratio decreased significantly. At a Zipf factor of 2.0, SPID-Join achieved a performance of 5,938 tuples / second / $, 8.37 times higher than PID-Join. As a result, it was shown that SPID-Join effectively resolved load imbalances between IDPs 111 and further utilized the PID device 100.

[0112] 1.8 Impact of the Zipf Factor Mismatch

[0113] To study the effect of an incorrectly estimated Zipf factor on cost-based replication ratio selection, we introduced an error of -20% to +20% in the Zipf factor. Despite this error, the cost model was able to select the optimal replication ratio in 13 of 20 cases. The predicted delay times showed a consistent pattern of increasing at low replication ratios, decreasing as the ratio increased, and then increasing again at higher rates. Even when non-optimal ratios were selected, the execution delay times did not differ significantly from the optimal delay times, with an average absolute percentage error of only about 0.51%.

[0114] 1.9 Comparison with CPU Join Algorithms

[0115] A comparison of latency between SPID-Join, PID-Join, and CPUJoin algorithms revealed that SPID-Join outperformed M-PASS at all Zipf factors. SPID-Join recorded lower latency than PRO and PRHO up to Zipf factor 1.0, but showed higher latency than PRO and PRHO at high skew. This highlights the importance of skew mitigation when utilizing PID-assisted DIMM110, and SPID-Join showed higher latency than PRO and PRHO at high Zipf factors.

[0116] Although the present invention has been described above with reference to preferred embodiments, it will be understood that those skilled in the art can make various modifications and changes to the present invention without departing from the spirit and technical scope of the present invention.

[0117] [National Research and Development Project of the Republic of Korea that supported this invention] [Project unique number] 2710006677 [Project Number] RS-2020-II201361 [Ministry name] Ministry of Science, ICT and Communication [Name of issue management (specialized) organization] Information and Communications Planning and Evaluation Agency [Research Project Name] Information, Communications and Broadcasting Innovation Human Resources Development (R&D) [Research title] Artificial Intelligence Graduate School Support (Yonsei University) [Project Implementation Organization Name] Yonsei University Industry-Academia Cooperation Group [Research Period] 2024.01.01 ~ 2024.12.31 [National Research and Development Project of the Republic of Korea that supported this invention] [Project unique number] 2710007386 [Project Number] RS-2024-00395134 [Ministry name] Ministry of Science, ICT and Communication [Name of issue management (specialized) organization] Information and Communications Planning and Evaluation Agency [Research Project Name] AI Semiconductor-Based Data Center Advanced Leading Technology Development [Research title] DPU-centric data center architecture for next-generation AI semiconductors [Project Implementation Organization Name] Yonsei University Industry-Academia Cooperation Group [Research Period] 2024.04.01 ~ 2024.12.31 [Explanation of symbols]

[0118] 100: Skew resistance PID device 110:DIMM 111:IDP 112: Rank 113: Bank 120: Memory controller 130: Host CPU

Claims

1. a DIMM (Dual In-line Memory Module) including an IDP (In-DIMM Processor) that processes internal memory operations and is configured with a plurality of ranks each including a plurality of banks; A memory controller; A skew-resistant PID (Processing in DIMM) device comprising: a host CPU connected to the DIMM via the memory controller, and duplicating a join key in units of a bank and a rank to improve parallel processing performance of the IDP.

2. The host CPU 2. The skew-resistant PID (Processing in DIMM) device of claim 1, further comprising: analyzing the configuration of an R table and an S table; and determining a cost model for determining a replication ratio based on the configuration of the skew-resistant PID device.

3. The host CPU 3. The skew-resistant PID (Processing in DIMM) device of claim 2, wherein the number of sets of banks and the number of sets of ranks are determined by calculating an optimal join key replication ratio (RRoptimal) through the cost model.

4. The host CPU 3. The skew-resistant PID (Processing in DIMM) device according to claim 2, wherein a Host-to-DIMM scatter operation is performed to transfer the R table and the S table to the DIMM in a distributed manner.

5. The IDP is The skew-resistant PID (Processing in DIMM) device of claim 2, further comprising: a bank and rank set-aware partitioning operation that duplicates the R table according to the bank set and the rank set; and distributes the S table to the bank set and the rank set based on the duplicated R table.

6. The host CPU 6. The skew-resistant PID (Processing in DIMM) device of claim 5, further comprising: an All-to-All Inter-IDP Shuffle operation that transfers the data of the R table and the S table to each IDP and enables each IDP to exchange and process the data of the R table and the S table.

7. Each IDP is:

7. The skew-resistant PID (Processing in DIMM) device of claim 6, further comprising: a Single-IDP Join operation that performs a Join operation based on data in the R table and the S table to generate a corresponding Join result.

8. Each IDP is: The skew-resistant PID (Processing in DIMM) device according to claim 7, wherein the Join operation performs Hash Join or Align Merge.

9. Each IDP is:

8. The skew resistant PID (Processing in DIMM) device of claim 7, further comprising: transferring the corresponding join results to the host CPU; and the host CPU collecting the corresponding join results to generate a final result.

10. A skew-resistant PID (Processing in DIMM) processing method performed in a skew-resistant PID (Processing in DIMM) device including a DIMM (Dual In-line Memory Modules) including an IDP (In-DIMM Processor) that processes internal memory operations and is configured with a plurality of ranks each including a plurality of banks, a memory controller, and a host CPU connected to the DIMM via the memory controller, determining a replication ratio based on the configuration of the skew resistance PID device; and replicating a join key in units of banks and ranks of the DIMM based on the replication ratio to improve parallel processing performance of the IDP.

Citation Information

Patent Citations

  • Method and system for supplier-based memory speculation in memory subsystem of data processing system

    JP2005174342A

  • Memory circuit system and method

    JP2009526323A

  • Electronic device

    JP2024175604A

  • KR2022-0062399