arXiv:2606.22812v1 [cs.AR] 22 Jun 2026
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding Daichi Tokuda
Tatsuya Kubo
Ismail Emir Yuksel
The University of Tokyo Tokyo, Japan [email protected]
The University of Tokyo / RIKEN Tokyo, Japan [email protected]
ETH Zurich Zurich, Switzerland [email protected]
Ataberk Olgun
Haocong Luo
Tomoya Nagatani
ETH Zurich Zurich, Switzerland [email protected]
ETH Zurich Zurich, Switzerland [email protected]
The University of Tokyo Tokyo, Japan [email protected]
Geraldo F. Oliveira
Abdullah Giray Yağlıkçı
Mohammad Sadrosadati
ETH Zurich Zurich, Switzerland [email protected]
CISPA Saarbrücken, Germany [email protected]
ETH Zurich Zurich, Switzerland [email protected]
Onur Mutlu
Shinya Takamaeda-Yamazaki
ETH Zurich Zurich, Switzerland [email protected]
The University of Tokyo / RIKEN Tokyo, Japan [email protected]
Abstract Vector–scalar comparison is a fundamental computation primitive that compares each element in a vector against a single scalar value. It is widely used in a broad range of data-intensive workloads from databases to machine learning. Due to its low computational intensity, the execution of this operation tends to be memory-bound, especially for large vectors, thereby limiting the utilization of compute resources. Processing-using-DRAM (PuD) is an emerging computing paradigm that performs massively parallel bitwise operations directly within the DRAM array, alleviating off-chip data movement. Unfortunately, no prior work proposes an efficient PuD-based solution tailored to vector–scalar comparisons. Existing PuD-based approaches require many DRAM commands because the comparison’s algorithmic complexity grows with operand bit-width in the bit-serial execution model, which is inherently induced by current PuD architectures. As a result, this command overhead becomes the dominant performance bottleneck, limiting application-level speedup. We propose Clutch, a novel data representation and comparison algorithm for accelerating vector–scalar comparisons in PuD systems with high efficiency and scalability. Our key idea is twofold. First, to reduce the number of DRAM commands required for comparison, Clutch adopts temporal coding for vectors, where each value is encoded as a sequence of leading ones. This enables lookupbased comparisons, where comparing against a scalar input simply
involves accessing the corresponding DRAM row. Second, Clutch leverages our key insight that a divide-and-conquer approach enables scalable lookup-based comparisons without incurring a prohibitive memory footprint at high bit-precision. Specifically, Clutch partitions the operand into multiple multi-bit chunks which can be compared independently using compact lookup tables, and merges per-chunk results through a procedure designed to execute efficiently on PuD. Clutch provides a flexible tradeoff between throughput and memory usage by adjusting chunk count. Experimental results on two applications, predicate evaluation and decision tree inference, demonstrate that Clutch improves endto-end application throughput (and energy efficiency) by an average of 12× (69×) over highly optimized CPU and GPU execution and 2.9× (3.0×) over the state-of-the-art bit-serial PuD implementation. Notably, we present, to our knowledge, the first mapping of decision tree inference to PuD execution, extending PuD to a new application domain. Our results demonstrate that DRAM can serve as a high-performance and energy-efficient computing substrate for comparison-intensive workloads.
CCS Concepts • Computer systems organization → Other architectures; • Hardware → Memory and dense storage.
Keywords processing-in-memory, memory systems, DRAM
This work is licensed under a Creative Commons Attribution 4.0 International License. ICS ’26, Belfast, United Kingdom © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2522-7/2026/07 https://doi.org/10.1145/3797905.3800550
ACM Reference Format: Daichi Tokuda, Tatsuya Kubo, Ismail Emir Yuksel, Ataberk Olgun, Haocong Luo, Tomoya Nagatani, Geraldo F. Oliveira, Abdullah Giray Yağlıkçı, Mohammad Sadrosadati, Onur Mutlu, and Shinya Takamaeda-Yamazaki. 2026. Clutch: High Performance Vector-Scalar Comparison using DRAM
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
via Chunked Temporal Coding. In 2026 International Conference on Supercomputing (ICS ’26), July 06–09, 2026, Belfast, United Kingdom. ACM, New York, NY, USA, 19 pages. https://doi.org/10.1145/3797905.3800550
1
Introduction
Vector-scalar comparison, which compares every element in a vector with a single scalar value, is a fundamental primitive in dataintensive workloads. It is widely used in predicate evaluation for in-memory database query processing [54, 72, 73, 91, 100, 113, 121, 186], thresholding and masking operations in scientific computing and image processing [1, 53, 154, 193, 205], and decision tree ensemble inference in machine learning [39, 83, 98, 149]. Efficient vector–scalar comparison is critical in many of these data-intensive applications because the performance of this step often dominates overall execution [103, 121, 186]. Our profiling results on real CPU systems show that comparisons account for up to 1) 96% of execution time in query processing workloads [54, 72, 73, 91, 100, 113, 121, 186] and 2) 81% of execution time in Gradient Boosting Decision Tree (GBDT) inference [83, 149] (see §3.1 for the detailed methodology and configuration). However, due to its very low computational intensity, the performance of vector–scalar comparison is typically bottlenecked by main-memory bandwidth, leaving compute resources underutilized on large-scale data. Processing-using-Memory (PuM) [3, 9, 14, 24, 36, 40, 45, 51, 58, 59, 61–63, 85, 92, 106, 107, 118–120, 132, 133, 138, 140, 145, 146, 151, 157–166, 173–175, 181, 182, 192, 199] has emerged as a promising approach to alleviate the processor-memory data movement bottleneck by performing computation directly within memory arrays using the intrinsic operational principles of memory cells. Among various PuM technologies, Processing-using-DRAM (PuD) [2, 38, 43, 45– 47, 59, 63, 64, 67, 81, 95, 109–111, 119, 124, 132, 133, 143, 157, 158, 160, 162, 164, 168, 185, 188, 192, 197] leverages the analog operational principles of DRAM circuitry and the massive internal parallelism of each DRAM bank, enabling massively parallel computations within DRAM. A key design principle in conventional PuD architectures [63, 81, 110, 111, 142, 143, 161] is to perform arithmetic in a bit-serial manner within each column through repeated PuD operations (i.e., bulk data copy and bitwise operation), each implemented using dedicated DRAM command sequences. Our PuD performance analysis reveals that PuD is particularly effective for vector–scalar comparison in terms of data movement efficiency (see §3.2). In a processor-centric system, the entire input vector must be read from memory and transferred to the processor, where each element of the vector is compared against the same scalar value. In contrast, PuD performs the comparison directly within DRAM, reducing data movement to only a 1-bit-per-element result bitmap. PuD also enables high-throughput subsequent processing with reduced data movement. In real-world workloads, comparison results often need to be combined with other bitmaps via reduction operations such as AND/OR (see §6). PuD can perform such reductions directly in DRAM at high throughput using bulk bitwise operations, eliminating the need to transfer intermediate bitmaps back to the processor. However, PuD-based execution sometimes shows limited performance improvements at the application level, and can even underperform processor-based execution under certain configurations (see Figure 14 and Figure 24). This occurs because conventional PuD
Daichi Tokuda et al.
approaches [63, 81, 110, 111, 124, 142, 143, 161] rely on bit-serial execution, in which the comparison’s algorithmic complexity grows with the operand bit-width, leading to a large number of PuD operations. Despite reduced data movement, the performance bottleneck shifts from off-chip data movement to the latency of PuD operations required for in-DRAM comparisons, limiting application-level performance. As such, reducing the number of PuD operations is a key challenge for unlocking the full potential of PuD for accelerating comparison-intensive applications. We present Clutch (Comparison Algorithm using Lookup Table with Chunked Temporal Coding), a new data representation and algorithm designed for PuD execution to enable efficient and scalable vector–scalar comparisons. Our key idea is twofold. First, to reduce the number of PuD operations required for comparison, Clutch operates on vectors encoded with temporal coding [126, 187] instead of the binary representation. In this scheme, a value 𝑣 is represented as a sequence of 𝑣 leading ones followed by zeros (e.g., a 3-bit value of 3 is encoded as 1110000). A key property of temporal coding is that the 𝑖-th bit of the encoded value 𝑣 equals the truth value of 𝑖 < 𝑣. As a result, when vector elements are stored in temporal coding across the columns of a DRAM subarray, each row directly contains the output bitmap of a vector–scalar comparison for the corresponding scalar value. The host processor can therefore execute a vector–scalar comparison with a single RowCopy, producing the result within DRAM and significantly reducing the number of PuD operations compared to the bit-serial approach. Second, to support high bit-precision (e.g., 16-bit and 32-bit) in a scalable and memory-efficient manner, Clutch introduces a divideand-conquer approach based on our key insight that full-width comparisons can be decomposed into comparisons on smaller bit chunks. Specifically, Clutch partitions the representation of each operand into multiple multi-bit chunks. Each chunk is independently compared to the corresponding portion of the scalar value by referencing a compact lookup table encoded with temporal coding. These per-chunk results are then merged through a procedure that propagates carry information across chunks, optimized for PuD execution. This chunk-wise design significantly reduces the number of DRAM rows used compared to encoding the full bitwidth as a single lookup table. By adjusting the number of chunks, Clutch provides a flexible tradeoff between comparison throughput and memory footprint. We demonstrate Clutch’s effectiveness on two comparison- intensive applications: predicate evaluation for in-memory databases [54, 72, 73, 91, 100, 113, 121, 186] and Gradient Boosting Decision Tree (GBDT) inference [39, 83, 98, 149]. For GBDT, we propose a novel mapping of the inference process onto PuD, based on our observation that tree traversal can be reformulated as a sequence of vector–scalar comparisons followed by mask operations, which Clutch can directly accelerate. We conduct detailed end-to-end performance evaluations on both applications using two PuD architectures: one requiring no DRAM modifications [67, 95, 110, 111] and SIMDRAM [43, 81, 124, 161], which modifies DRAM circuitry to natively support bulk bitwise NOT operations. The main contributions of this work are as follows: • Our application profiling and Processing-using-DRAM (PuD) performance analysis reveal that reducing the number of
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding
PuD operations required for comparisons is critical to accelerating comparison-intensive applications. • We present Clutch, a new PuD-oriented comparison algorithm and data representation, which uses a lookup-tablebased method with temporal coding to significantly reduce the number of PuD operations required for comparison. Clutch adopts a divide-and-conquer approach that enables a flexible tradeoff between throughput and memory footprint by adjusting the number of chunks. • We apply Clutch to two applications: predicate evaluation and Gradient Boosting Decision Tree (GBDT) inference. To our knowledge, this is the first work that applies PuD-based acceleration to GBDT. On average, Clutch improves throughput (and energy efficiency) by 12× (69×) over optimized processor execution and by 2.9× (3.0×) over the state-of-the-art bit-serial PuD approach. • Our results demonstrate that PuD can provide substantial application-level speedup when paired with an algorithm and data representation that together minimize PuD operation count, highlighting DRAM’s viability as a highperformance and energy-efficient computing substrate.
2 Background 2.1 Vector-Scalar Comparison Vector-scalar comparison is a fundamental and widely used operation across various data processing pipelines. It typically involves comparing each element in a vector against a single scalar value, followed by filtering, masking, or other conditional processing based on the results. Such vector-scalar comparisons are central to predicate evaluation workloads, such as query processing in in-memory databases and thresholding in scientific and image processing [1, 53, 154, 193, 205]. In the machine learning domain, this operation also plays a dominant role in the inference of Gradient Boosting Decision Tree (GBDT) [39, 83, 98, 149]. These applications play a foundational role in modern datacentric systems that support real-world infrastructure. Optimizing predicate evaluation boosts query performance in in-memory databases [54, 72, 73, 91, 100, 113, 121, 186]. GBDT, with its low computational cost and state-of-the-art accuracy on tabular data, enables fast, low-overhead decision-making in edge AI systems with limited resources. More detailed descriptions of these applications are provided in §6.1 and §6.2.
2.2
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
64K columns per bank in DDR4), and multiple operations can be performed concurrently across different banks (e.g., 16 banks). Chip
Processor Memory Controller
DRAM Cell
Bank
wordline
Subarray
Memory Channel
Sense Amplifier
Capacitor bitline
Sense Amplifier
DRAM Module
Subarray
Chip Chip Chip Chip
Sense Amplifier
Sense Amplifier
Figure 1: DRAM Organization.
2.3
Processing-using-DRAM
Processing-using-DRAM (PuD) [2, 38, 43, 45–47, 59, 63, 64, 67, 81, 95, 109–111, 119, 124, 132, 133, 143, 157, 158, 160, 162, 164, 168, 185, 188, 192, 197] is a new computing paradigm that leverages the analog properties of DRAM to enable massively parallel in-DRAM computation. This work targets two representative PuD architectures. The first is SIMDRAM [81], one of the most well-established PuD architectures, which supports bulk bitwise NOT operations through the use of dual-contact cells (originally introduced by Ambit [161]). The second is Unmodified PuD [64, 67, 95, 110, 111, 138, 196–198], which avoids modifications to the DRAM chips and is modeled after computation capabilities that are demonstrated to be present in commercial off-the-shelf (COTS) DRAM PIM [63, 64, 110, 111, 132, 133, 138, 140, 194–198]. We note that we do not aim to claim an execution model that can be immediately adopted in existing systems with COTS DRAM chips. Instead, we choose this Unmodified PuD architecture as a candidate for future PuD systems that can offer the lowest manufacturing cost and minimal changes to DRAM circuitry. We experimentally confirm the practical feasibility of Unmodified PuD and obtain precise operation latencies through experiments on off-the-shelf DDR4 DRAM modules using DRAM Bender [139, 153], an FPGA-based custom memory control infrastructure [84, 139, 152, 153] (Figure 2).
DDR4 DRAM Module Temperature Controller PCI-e to Host Machine
Memory Controller on FPGA
DRAM Organization and Operation
Dynamic Random Access Memory (DRAM) is organized in a hierarchical structure consisting of channels, ranks, chips, banks, and subarrays of memory cells (Figure 1). Each cell consists of a single transistor paired with a capacitor. Each cell stores one bit of data, based on the charge level held in the capacitor. Within each subarray, cells form a two-dimensional grid of rows (wordlines) and columns (bitlines). The memory controller integrated in the CPU die generates a sequence of DRAM commands to access data in DRAM. The ACT command opens a specific row and copies its data into the row buffer. The PRE command closes the active row. These commands operate on all columns in a row (e.g.,
Figure 2: Our FPGA-based PuD testing infrastructure (DRAM Bender [139]) with DDR4 modules. PuD computation consists of repeated invocations of two primitive PuD operations: RowCopy and MAJ3. Each PuD operation is realized by issuing a dedicated sequence of DRAM commands such as ACT and PRE [63, 81, 161, 197]. RowCopy transfers data between rows within the same subarray, enabling efficient bulk data movement inside DRAM via two consecutive activations within the same subarray in quick succession. The MAJ3 operation activates multiple rows to compute a three-input bulk bitwise majority function. By
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
Daichi Tokuda et al.
using one of the constant rows (rows filled entirely with 0s or 1s) as a fixed input, MAJ3 realizes AND and OR operations, serving as a fundamental logic primitive for PuD. Different PuD architectures support MAJ3 in different ways. SIMDRAM (and Ambit) enables the simultaneous activation of three rows within a designated row group in each subarray. In contrast, Unmodified DRAM cannot simultaneously activate exactly three rows. Prior work [111, 140, 194–197] observes that COTS DRAM chips support simultaneous activation of four rows but not three, and attributes this limitation to the hierarchical row decoder design. To perform MAJ3, Unmodified DRAM instead activates four rows through a sequence of ACT and PRE commands. Before the four-row activation, one of the four rows is set to an intermediate voltage level using the Frac operation [64, 111], effectively neutralizing its contribution to the majority vote and making the result equivalent to a three-input majority. Because Unmodified DRAM does not support logical NOT natively, prior work maintains both a value and its logical complement throughout the computation, achieving functional completeness without a dedicated NOT operation [63, 110]. Prior PuD performs arithmetic by vertically aligning the binary representations of operands within a column and executing a sequence of PuD operations in a bit-serial manner [81, 124, 142, 143, 161]. Figure 3 illustrates the first step of a multiplication between two operands, operand 1 and operand 2, whose bits are stored vertically in the same column. To compute the AND of their LSBs, the PuD first uses RowCopy operations to copy the two LSB bits ( 1y and 2y ) along with a constant row filled with zeros ( 3y ) into a set of designated rows called compute rows, where MAJ3 can be performed. Executing MAJ3 over these three bits produces the AND of the two LSB bits ( 4y ). By processing each bit from the LSB to the MSB in this bit-serial manner, PuD performs full arithmetic operations such as multiplication. Because DRAM applies the same command sequence across all columns within a bank, PuD performs the same arithmetic operation concurrently on every column, enabling massive parallelism. Massive Parallelism
1 0 1
Computation Rows Binary in Vertical Layout
Operand 2 Operand 1
0 1 LSB 1 MSB 0 1 LSB 0 0 Constant Rows 1 MSB
0 1 0 1 0 0 0 1
Row
1Copy 0 1 1 1 1 0 0 0 1 1 0 0 0 1 1 1
0 1 0 1 0 0 0 1
1 0 1 0 1 1 Row 1 Copy 1 0 0 0 1 1 0 0 0 1 1
RowCopy the LSB of Operand 1 to a computation row
2
0 0 0 1 0 1 0 0 0 1
0 1 1 1 0 1 0 1 1 Row 1 Copy 1 0 0 0 1 1 0 0 0 1 1
RowCopy the LSB of Operand 2 to a computation row
3
0 0 0 0 1 0 1 0 0 0 1
0 0 1 0 1 0 1MAJ3 0 1 1 1 1 0 0 0 1 1 0 0 0 1 1
RowCopy the constant zero row to a computation row
4
0 0 0 0 1 0 1 0 0 0 1
1 0 1 1 1 0 1 0 Row 1 Copy 1 1 1 0 0 0 1 1 0 0 0 1 1
Execute MAJ3 to produce the AND of two LSBs
0 0 0 0 1 0 1 0 0 0 1
1 0 1 1 1 1 0 0 1 0 1
Process bits from LSB to MSB in a bit serial manner
Figure 3: Bit-serial-based PuD arithmetic.
3 Motivation 3.1 Bottleneck Profiling of Vector-Scalar Comparisons Vector-scalar comparisons are widely used across a broad range of applications that support the foundation of modern society, from query processing in in-memory databases to inference in decision
tree ensembles for machine learning. In many of these workloads, accelerating the comparison step is particularly effective, as it has a substantial impact on overall performance [103, 121, 186]. Our profiling results on real CPU systems (e.g., Intel Core i7-9700K [93]) show that comparison operations account for up to 96% of the total execution time in query processing and up to 81% in GBDT inference1 (see §6 for the system configuration and workload details). Figure 4 illustrates the fraction of execution time spent on comparison operations for a subset of workloads evaluated in §6. WG1–WG3 correspond to GBDT inference: WG1 uses depth 12 with a batch size 1024, WG2 uses depth 8 with a batch size 1024, and WG3 uses depth 10 with a batch size 64. WQ1–WQ3 correspond to predicate evaluation queries Q2–Q4 in §6.2.
Figure 4: Fraction of execution time spent on comparison. Due to the very low computational intensity of the comparison operation, its performance is bottlenecked by off-chip data movement for large datasets [121]. We confirm this by profiling an optimized comparison kernel [121], which employs a transposed layout for vector–scalar comparison: loading the vector data from DRAM alone accounts for the vast majority of the total execution time. This shows that further improving comparison performance requires alleviating the memory-bandwidth bottleneck.
3.2
Data Movement Reduction via PuD Execution
Figure 5 illustrates that PuD explicitly reduces off-chip data movement compared to the processor-centric approach, leveraging the arithmetic nature of vector–scalar comparisons. We consider a scenario where a vector 𝐵 of 𝑛-bit elements is stored in DRAM, and the host processor holds a scalar value 𝑎. The goal is to compute a comparison 𝑎 < 𝐵𝑖 for each 𝑛-bit element 𝐵𝑖 and obtain the resulting 1-bit output vector 𝑌 . We begin by describing the execution on the processor. Assuming that the vector 𝐵 is much larger than the processor’s cache, the processor must first load 𝐵 from DRAM ( 1i ). Then, the comparison is performed, and the processor obtains the output vector 𝑌 ( 2i ). Depending on the size of 𝐵 and the structure of the subsequent processing stages, 𝑌 may also not fit in the cache. The lower bound on DRAM accesses is at least reading the 𝑛-bit vector 𝐵. In contrast, in PuD execution, the vector 𝐵 is stored in DRAM in a vertical layout. To perform the comparison, each bit of the scalar 𝑎 must be initialized across all columns so that PuD operations can process it against the corresponding bits of 𝐵. A naive approach would be to WRITE the scalar value into every column, but this would incur the same off-chip data movement that PuD aims to eliminate. 1 For GBDT inference, the comparison step includes producing leaf addresses based on
comparisons between feature values and node thresholds.
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
1) Processor-centric Execution 1
Vector-Scalar Comparison
1 2
Comparisons
1-bit
2) Processing-using-DRAM
Processor
Read n-bit vec. B
DRAM
DRAM
Issue PuD Ops: Broadcast-Compare(
)
2 Comparisons
Processor
n-bit n-bit
Large Data Movement
3
Small Data Movement
3
Read 1-bit vec. Y
in-DRAM Reuse of Y for Subsequent PuD Ops
Figure 5: PuD execution effectively reduces data movement for vector-scalar comparison. Instead, following prior approaches [43, 110], PuD can prepare constant rows filled entirely with 0s or 1s in advance across all columns, and then initialize each bit of 𝑎 by selecting the appropriate constant row and copying it using RowCopy [63, 138, 158, 161, 197]. For example, if 𝑎 = 3 (𝑎 2𝑎 1𝑎 0 = 011 in binary), it copies the all-1s row for 𝑎 0 and 𝑎 1 and the all-0s row for 𝑎 2 . In this way, PuD dynamically issues PuD operations according to the value of 𝑎 ( 1y ), and the comparison is executed entirely inside DRAM without any off-chip data movement of 𝑎 ( 2y ). The output vector 𝑌 with 1-bit elements is produced directly within DRAM, and the host processor reads 𝑌 ). only when it is needed for subsequent processing ( 3y Crucially, the output bitmap 𝑌 is often combined with other comparison-result bitmaps (e.g., via AND/OR operations) in real workloads (see also §6). PuD can execute these bitwise operations directly in DRAM at high throughput, avoiding transfers of 𝑌 to the processor until the final result is needed (described as the yellow arrow in Figure 5). In summary, processor-side execution involves transferring at least the full 𝑛-bit vector 𝐵, assuming that 𝐵 is much larger than the processor cache. In contrast, PuD execution only requires transferring the 1-bit vector 𝑌 of the same length, or potentially no transfer of 𝑌 at all if the subsequent bitwise reduction is handled by PuD. Therefore, for large vectors, PuD can reduce the data transfer volume by a factor of at least 𝑛. This advantage comes from three key properties of vector–scalar comparison: (i) the scalar value is shared across all elements, (ii) the output is a vector with 1-bit elements (i.e., a bitmap), and (iii) the output bitmap is often combined with other bitmaps in downstream processing.
3.3
Limitations of Bit-Serial Comparison in PuD
While PuD can explicitly reduce data transfer for vector–scalar comparisons, the bit-serial comparison [81, 143, 161] still limits the end-to-end application-level speedup over processor-centric execution. This limitation arises mainly because, as illustrated in Figure 6, the bit-serial approach requires ∼ 6𝑛 PuD operations for an unsigned 𝑛-bit comparison per DRAM bank in Unmodified PuD, and ∼ 4𝑛 in SIMDRAM [81, 110, 161]. 2 This overhead makes it difficult to outperform the processor-based approach when parallelism is limited or when additional overhead from non-comparison operations arises in real-world applications (see Figures 17 and 24). 2 The ∼4𝑛 operations on SIMDRAM include RowCopy operations to initialize the scalar value 𝑎 within the subarray from constant rows. The ∼6𝑛 operations on Unmodified PuD additionally include RowCopy to a neutral row and a Frac operation per step.
Bottleneck Bit-serial-based PuD
~
Clutch-based PuD
ReadY
ReadY
PuD Ops
~
PuD Ops
Normalized Execution Time (Bit-serial-based PuD = 1)
Figure 6: Execution time breakdown of vector–scalar comparison at 32-bit precision on PuD. Our analysis further reveals that the latency of comparisons is dominated by the number of PuD operations. While PuD eliminates the need to move the vector 𝐵 from DRAM to the processor, the large number of PuD operations required for bit-serial comparison becomes the performance bottleneck. For example, as shown in Figure 6, PuD operations account for 76% of the total latency in 32-bit comparisons on a system configuration summarized in Table 1, clearly indicating that PuD operations, not data movement, are the primary limiter. Therefore, reducing the number of PuD operations is a key challenge, and addressing it is critical to unlocking the full performance potential of PuD for comparison-intensive applications.
4
Clutch
To reduce the large number of PuD operations incurred by bit-serial execution, we present Clutch, a novel comparison algorithm and data representation for PuD.
4.1
Lookup Table-based Approach
Instead of representing each element of 𝐵 in binary, Clutch uses temporal coding [126, 187], where a value 𝑣 is represented as a bitstream of 𝑣 leading ones followed by zeros. A key property of this encoding is that the 𝑖-th bit equals the truth value of 𝑖 < 𝑣. As illustrated in Figure 7, when vector elements are stored in this format across the columns of a DRAM subarray, each column stores one vector element, and row 𝑎 directly contains the output bitmap of the vector–scalar comparison 𝑎 < 𝐵𝑖 for all elements 𝐵𝑖 . The data encoded with temporal coding is either converted offline and loaded into DRAM, or converted from binary by the host processor and stored in DRAM prior to execution (we discuss the cost of this conversion in §6). At runtime, the host processor dynamically issues PuD operations based on the scalar value 𝑎, executing
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
Daichi Tokuda et al.
the vector–scalar comparison within the DRAM subarray (we discuss the system design for dynamically issuing PuD operations in §7.3). While this lookup table-based approach offers extremely high throughput, it requires a large number of rows (2𝑛 −1 rows) for 𝑛-bit values, which poses practical challenges when mapped to DRAM rows. Since typical PuD architectures have DRAM subarrays with e.g., 1024 rows [81, 142, 143, 161], supporting 𝑛 = 16 or 𝑛 = 32 far exceeds the available row budget. Moreover, as described in §6.2, some applications benefit from placing multiple vectors in the same subarray columns to enable in-DRAM reductions over multiple result bitmaps. In such cases, even for 𝑛 ≤ 8, a more compact design is required. Therefore, we need a new approach that preserves the high throughput of lookup-based comparisons while significantly reducing the required number of rows.
Vector-Scalar Comparison
1 1 1 3 1 4 1 5 1 6 0 0
Look up 1 th Row 2
Binary Temporal
1 1 0 1 1 1 1 1 1 0
1 1 0 0 0 0 0
1 1 1 1 0 0 0
6 The j-th bit of the Temporal Coding represents the truth value of
Divide-and-Conquer for Comparison on PuD
Pre-stored Table in DRAM Array Row Idx
Coding for the Table
Two steps justify this transformation. First, relaxing 𝑎 1 == 𝑏 1 to 𝑎 1 ≤ 𝑏 1 only introduces the case 𝑎 1 < 𝑏 1 , which is already covered by the first term, so the overall expression remains equivalent. Second, for integer comparisons, 𝑎 1 ≤ 𝑏 1 can be rewritten as (𝑎 1 − 1) < 𝑏 1 . With this form, the comparison (𝑎 1 − 1) < 𝑏 1 can be evaluated using the same lookup table as 𝑎 1 < 𝑏 1 , simply by using (𝑎 1 − 1) as the index instead of 𝑎 1 . As shown in Figure 8, Clutch evaluates three sub-comparisons: 𝑎 1 < 𝑏 1 ( 1y ), (𝑎 1 − 1) < 𝑏 1 ( 2y ), and 𝑎 0 < 𝑏 0 ( 3y ), each via a single lookup-table access, and then combines them into the final result using a single MAJ3 operation ( 4y ). The Boolean expression can be simplified to a single MAJ3 because if 𝑎 1 < 𝑏 1 holds then (𝑎 1 − 1) < 𝑏 1 also holds.
1 0 0
4
2 MSB
3
Binary
0 1 1 0 Chunked Temporal
Row Idx 0
1 1 0 1 2 0 0 1 Table for 1 1 2 0
Table for
Divide-and-Conquer Approach for Comparisons
To support scalable and memory-efficient lookup table-based comparisons, Clutch adopts a divide-and-conquer approach. Our key idea is that a full-width comparison can be decomposed into smaller sub-comparisons over bit chunks. Specifically, Clutch partitions each binary operand into multiple multi-bit chunks, compares each chunk independently using a compact lookup table encoded with temporal coding, and then merges the partial results through a procedure that propagates carry information across chunks, optimized for PuD execution. Figure 8 illustrates Clutch’s divide-andconquer approach for a 4-bit binary number split into two chunks: an MSB chunk and an LSB chunk. For each chunk, a straightforward lookup-table comparison under temporal coding produces a per-chunk result. To merge the per-chunk results efficiently on PuD, we rewrite the comparison expression 𝑎 < 𝑏. Let 𝑎 1 and 𝑏 1 denote the MSB chunks and 𝑎 0 and 𝑏 0 denote the LSB chunks. A direct reformulation yields: 𝑎 < 𝑏 ⇔ 𝑎 1 < 𝑏 1 or (𝑎 1 == 𝑏 1 ) and 𝑎 0 < 𝑏 0 Because the equality term (𝑎 1 == 𝑏 1 ) is not directly available from the chunk-level comparisons, we substitute it as follows: 𝑎 < 𝑏 ⇔ 𝑎 1 < 𝑏 1 or (𝑎 1 − 1) < 𝑏 1 and 𝑎 0 < 𝑏 0
LSB
0 1 0 1
Row Copy Result Bitmap for
Figure 7: Lookup table-based comparison via temporal coding.
4.2
1
Coding for the Table
3
2
1 0 0
1 0 0 1 1 0 1 0 1
1 1 0
1 0 0 1 1 0 4 1 MAJ3 0 Result 1 Bitmap for 1
Figure 8: Clutch encoding and algorithm example. Although Figure 8 shows the two-chunk case, this divideand-conquer algorithm can be applied recursively from the LSB side when the number of chunks exceeds two, producing a PuDoptimized comparison algorithm. Algorithm 1 shows the general algorithm of Clutch to compute vector–scalar comparisons. The algorithm processes chunks from the LSB chunk to the MSB chunk (lines 2–13), progressively merging per-chunk comparison results using a single MAJ3 operation per chunk (line 12). The array 𝑐𝑝 stores the starting row index of the lookup table for each chunk, so that row[𝑎 𝑗 + 𝑐𝑝 [ 𝑗]] retrieves the result of comparing chunk
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding
value 𝑎 𝑗 against the corresponding chunk of each vector element 𝐵𝑖 . The host processor retains 𝑐𝑝 and the chunk values 𝑎 0, . . . , 𝑎𝐶 −1 (𝐶 denotes the number of chunks), and dynamically issues PuD operations based on these values. Algorithm 1 PuD-Optimized Clutch Algorithm Require: 𝐶: the number of chunks Require: 𝑎 0 , . . . , 𝑎𝐶 −1 : individual chunks of scalar 𝑎 (from LSB to MSB) Require: 𝑘 0 , . . . , 𝑘𝐶 −1 : bit-width of each chunk Require: 𝑐𝑝 [0 . . . 𝐶 − 1]: starting row index of the table for each chunk Ensure: comparison result 𝐿 (𝐿 = 1 if 𝑎 < 𝐵𝑖 for each column 𝑖) 1: if 𝑎 0 = 2𝑘0 − 1 then 2: 𝐿 ← 0 // 𝑎 0 < 𝑏 0 is always false when 𝑎 0 = 2𝑘0 − 1 3: else 4: 𝐿 ← row[ 𝑎 0 + 𝑐𝑝 [0] ] // 𝐿 ← (𝑎 0 < 𝑏 0 ) 5: end if 6: for 𝑗 = 1 to 𝐶 − 1 do 7: if 𝑎 𝑗 = 2𝑘 𝑗 − 1 then 8: 𝑙𝑡 ← 0 // 𝑎 𝑗 < 𝑏 𝑗 is always false when 𝑎 𝑗 = 2𝑘 𝑗 − 1 9: else 10: 𝑙𝑡 ← row[ 𝑎 𝑗 + 𝑐𝑝 [ 𝑗 ] ] // 𝑙𝑡 ← (𝑎 𝑗 < 𝑏 𝑗 ) 11: end if 12: if 𝑎 𝑗 = 0 then 13: 𝑙𝑒 ← 1 // 𝑎 𝑗 ≤ 𝑏 𝑗 is always true when 𝑎 𝑗 = 0 14: else 15: 𝑙𝑒 ← row[ 𝑎 𝑗 − 1 + 𝑐𝑝 [ 𝑗 ] ] // 𝑙𝑒 ← (𝑎 𝑗 − 1 < 𝑏 𝑗 ) = (𝑎 𝑗 ≤ 𝑏 𝑗 ) 16: end if 17: 𝐿 ← MAJ3(𝐿, 𝑙𝑡, 𝑙𝑒 ) // Combine chunks: 𝑙𝑡 or (𝑙𝑒 and 𝐿) 18: end for 19: return 𝐿
The algorithm first initializes 𝐿 with the LSB chunk comparison result (lines 1–5). When 𝑎 0 = 2𝑘0 − 1, the lookup table access would exceed the table boundary, but since 𝑎 0 < 𝑏 0 is always false for the maximum chunk value, the algorithm sets 𝐿 = 0 using a constantzero row (line 2). For each subsequent chunk 𝑗 ≥ 1 (lines 6–18), the algorithm computes two values: 𝑙𝑡 = (𝑎 𝑗 < 𝑏 𝑗 ) (lines 7–11) and 𝑙𝑒 = (𝑎 𝑗 ≤ 𝑏 𝑗 ) (lines 12–16). The value 𝑙𝑡 is obtained by looking up 𝑎 𝑗 in the lookup table (line 10), with the same maximum-value boundary case handled by setting 𝑙𝑡 = 0 (line 8). The value 𝑙𝑒 is obtained by looking up (𝑎 𝑗 − 1) in the same table (line 15). When 𝑎 𝑗 = 0, this access would underflow, but since 𝑎 𝑗 ≤ 𝑏 𝑗 is always true, the algorithm sets 𝑙𝑒 = 1 using a constant-one row (line 13). Finally, the algorithm combines 𝐿, 𝑙𝑡, and 𝑙𝑒 via MAJ3 to propagate the comparison result from lower chunks to the current chunk (line 17). This operation computes 𝑙𝑡 or (𝑙𝑒 and 𝐿), matching the reformulated comparison expression described above. Notably, Clutch does not require a logical NOT operation for any step. As a result, even on Unmodified DRAM, Clutch does not need to maintain the logical complement of a value. The number of PuD operations in Clutch depends only on the number of chunks 𝐶, not the operand bit-precision 𝑛. Clutch enables a flexible tradeoff between throughput and memory footprint by adjusting the number of chunks. Since each chunk’s lookup table has 2𝑘 − 1 rows for a 𝑘-bit chunk and this grows exponentially with 𝑘, the total number of rows is minimized when the 𝑛 bits are distributed as evenly as possible across the 𝐶 chunks. Figure 9 illustrates this tradeoff space across different operand bit-precisions
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
(𝑛 = 4, 8, 16, 32) and chunk counts for Unmodified DRAM, where each point represents a different chunk count annotated with the number of chunks used. For example, for 32-bit values with five chunks (chunk sizes of 6, 6, 6, 7, 7 bits, requiring 63 + 63 + 63 + 127 + 127 = 443 rows), Clutch executes vector–scalar comparison in only 17 PuD operations on Unmodified DRAM. This yields over an order-of-magnitude reduction in PuD operations compared to the state-of-the-art bit-serial approach [81, 143, 161]. Bit-Precision (n)
Figure 9: Tradeoff between DRAM row usage and the number of PuD operations in Clutch. Each point represents a different chunk count on Unmodified DRAM, annotated with the number of chunks used.
5
Evaluation
In §5 and §6, we compare processor-centric execution and PuDbased execution under the same processor and DRAM configuration to ensure a fair comparison. In §5, we focus on the end-to-end performance of a vector–scalar comparison kernel, where a scalar value resides on the processor and the vector is resident in DRAM. We quantitatively evaluate the performance of two comparison methods, the state-of-the-art bit-serial execution (SIMDRAM and Ambit) [81, 161] and Clutch. Table 1 summarizes the processor and DRAM system configurations used in §5.3 These configurations are shared across all evaluated execution methods and algorithms. We evaluate two representative PuD architectures, which we also use in §6. 1) Unmodified PuD: A COTS DRAM based PuD architecture that does not require modifications to the DRAM circuitry [64, 67, 95, 110, 111, 138, 196–198]. This architecture is modeled after COTSDRAM chips [63, 64, 110, 111, 140, 194–198] and realizes the MAJ3 operation using the Frac operation [64] and fixed four-row activation [110, 197]. We note that we do not aim to claim an execution model that can be immediately adopted in existing systems with COTS DRAM chips. Instead, we choose this Unmodified PuD architecture as a candidate for future PuD systems that can offer the lowest manufacturing cost and minimal changes to DRAM circuitry. We validate its practicality and obtain precise, hardware-verified latencies of PuD operations on off-the-shelf DDR4 DRAM modules using DRAM Bender [139, 153] (which is based on SoftMC [84, 152]), an FPGA-based custom memory control infrastructure (see Figure 2). 3 The workloads evaluated in §5 and §6.2 are memory-bandwidth bound [121], so the
processor generation has little impact on the throughput. We use DDR4-2666 [97] because it enables us to obtain hardware-verified PuD operation latencies using our FPGA platform (see Figure 2).
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
2) Modified PuD (SIMDRAM): A PuD architecture that adopts the same subarray structure as SIMDRAM [81], also used in several subsequent works [43, 124]. The DRAM cell array is equipped with dual-contact cells (originally introduced by Ambit [161]) to support in-DRAM bulk bitwise NOT operations. This Modified PuD architecture implements the MAJ3 operation via triple-row activations among a set of reserved rows (i.e., compute rows) within each subarray. Following prior work [81, 124, 161], we assume each DRAM module contains 16 banks, and PuD is enabled in one subarray per bank, with each subarray containing 1024 rows. Under the configuration shown in Table 1, this yields a column-level parallelism of 64K columns × 16 banks × 2 DIMMs per channel × 2 channels. For precise evaluation, we do not simply scale single-bank performance by a factor of 16. Instead, we derive a cycle-accurate latency from DRAM command sequences that explicitly model DRAM banklevel parallelism (BLP). Note that our evaluation does not exploit subarray-level parallelism (SALP) [109]. If SALP is further exploited for PuD computation, PuD parallelism would be much higher, as demonstrated in prior work [132, 142]. Our evaluation follows prevailing methodology in PuD evaluation [81, 110, 124, 141–143]. We first run applications on real machines and profile their execution at kernel granularity. For kernels that are accelerated by PuD, we subtract the measured CPU execution time of the kernel and replace it with the analytically derived PuD-based computation time inside DRAM. We then add the execution time of all other processing, without overlapping it with the PuD computation time. Since Clutch’s comparison results remain in DRAM rather than being cached in the CPU, we explicitly add the time to transfer the output bitmaps from DRAM back to the processor, yielding a conservative (i.e., favoring baseline processor-centric systems) end-to-end performance estimate. The execution time on the processor is measured on real hardware (see Table 1 for the evaluation in §5.1), and CPU power consumption is obtained using Intel RAPL [102]. For PuD-based computation inside DRAM, we analytically derive the execution time based on the sequence of DRAM commands required. The power consumption of PuD is estimated using data from CACTI 6.5 [130]. For the energy cost of the PuD operations, we follow prior work [110, 197] and assume that each additional simultaneously activated row increases the activation energy by 22% relative to the single-row case, as reported using real DRAM chips in [197]. For a fair comparison, we also account for the energy consumption of the host-side processor execution during PuD execution, assuming single-threaded processor power consumption.
Table 1: Evaluated system configurations. Main Memory 64 GB DDR4-2666 (4 × 16 GB) [97], dual-channel; (COTS DRAM) Peak bandwidth: 42.6 GB/s; 2 ranks per DIMM, 16 banks per rank; Processor (Real CPU)
Intel Core i7-9700K [93], 8 cores, up to 4.9 GHz; 32 kB L1, 256 kB L2 per core; 12 MB shared L3;
Daichi Tokuda et al.
5.1
Performance of Vector-Scalar Comparison
Figure 10 shows the performance comparison for vector–scalar comparisons with 256M elements. We evaluate six implementations: 1) CPU (scan), 2) CPU (tree), 3) Bit-Serial (U) (the state-of-the-art bitserial approach [81, 161] on Unmodified PuD), 4) Clutch (U) (Clutch on Unmodified PuD), 5) Bit-Serial (M) (the bit-serial approach on Modified PuD), and 6) Clutch (M) (Clutch on Modified PuD). For the main CPU baseline, labeled CPU (scan) in the figure, we use an optimized kernel based on BitWeaving-V [121], a state-ofthe-art technique designed to accelerate predicate evaluation in column scans for databases. BitWeaving-V addresses inefficiencies in conventional data layouts by storing data in a transposed, bitsliced layout, where bits at the same position across many values are packed together, enabling parallel bitwise evaluation using SIMD instructions. In our implementation, BitWeaving-V outperforms other conventional scan layouts for all tested bit-precisions (8-bit, 16-bit, and 32-bit), and we therefore use CPU (scan) as our primary processor-centric baseline. In addition, we evaluate a tree-based CPU implementation, labeled CPU (tree), which reduces the number of comparison operations by organizing predicate thresholds in a search tree rather than scanning all predicate ranges sequentially. Our evaluation explicitly includes the time required to transfer the final comparison result row back to the host CPU for PuD. For each bit-precision, Clutch uses the minimum number of chunks required to store a single value entirely within a single subarray (i.e., one chunk for 8-bit, two chunks for 16-bit, and five chunks for 32-bit), as shown in Figure 9. Figure 10 presents the throughput of vector-scalar comparison on six systems, for three bit-precisions (8-bit, 16-bit, 32-bit). Across all bit-precisions, CPU (scan) is consistently faster than CPU (tree) because the tree-based approach incurs irregular memory accesses when traversing the index structure and still requires linear-time memory accesses to build the bitmap. Consequently, we use CPU (scan) as the CPU reference for the speedup numbers reported.
(a)
(b)
(c)
Figure 10: Throughput of vector-scalar comparisons at (a) 8-bit precision, (b) 16-bit precision, and (c) 32-bit precision. Clutch provides higher throughput as bit-precision increases, realizing up to 36× (20× on average) speedup over the CPU and up to 4.1× (3.1× on average) over bit-serial PuD. This trend is explained in Figure 5: CPU execution reads full-width operands from memory and is constrained by memory bandwidth, whereas PuD reads back only a result 1-bit-per-element bitmap. Consequently, PuD’s relative data-movement savings grow with the operand bitprecision. In addition, Clutch substantially reduces the number of PuD operations compared to bit-serial PuD, directly alleviating the dominant performance bottleneck of bit-serial PuD (see Figure 6). Figure 11 presents the energy efficiency, defined as the number of comparisons completed per unit of energy consumption, relative to CPU (scan). Clutch improves energy efficiency by up to 96× (54× on average) compared to the CPU and up to 4.2× (3.1× on average) compared to bit-serial PuD.
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
threshold and (ii) a one-hot feature mask indicating which feature the node uses. Nodes are grouped by tree, and within each tree, columns are arranged in order of increasing depth so that nodes at the next depth are logically adjacent. (c)
6.1
Gradient Boosting Decision Tree Inference
GBDT models [39, 83, 98, 149] are powerful ensemble models composed of multiple decision trees, demonstrating excellent performance in both classification and regression tasks on tabular data. GBDT has become a standard method in a wide range of industrial applications that involve tabular data [26, 170]. Compared to deep neural networks (DNNs), many comparative studies have shown that GBDT offers advantages in terms of accuracy, computational cost, and interpretability [169, 170]. A recent large-scale benchmark study [169] that compared 14 tree-based and deep learning models on 111 tabular datasets reported that GBDT-based models occupied the top three positions. Due to its lower computational cost in the inference phase compared to DNNs, GBDT is particularly widely used in resourceconstrained edge devices [103, 180, 202]. Practical applications include remote sensing, anomaly detection, and predictive analytics on IoT sensor devices [8, 88, 176, 202–204]. As a result, GBDT has become an essential component in edge AI systems, and further improvements in inference efficiency are actively pursued. Among various implementations of GBDT, CatBoost [83, 149] is known as one of the most powerful models. In the aforementioned benchmark study [169], CatBoost ranked first on 19 individual datasets and achieved the best average rank of 4.9. CatBoost adopts a regular branching structure known as oblivious trees [83, 149], where all nodes at the same depth share the same feature index and threshold, as illustrated in Figure 12. This property enables parallel execution of all 𝑛𝑢𝑚_𝑡𝑟𝑒𝑒𝑠 × 𝑛𝑢𝑚_𝑑𝑒𝑝𝑡ℎ comparisons regardless of previous branching results. The final prediction is obtained by summing the leaf values reached in all trees.
Input
Depth2
Tree1 Depth0
Depth0
1 F1 < 38 F < 38 node node1 node node node node 1 38 F1 < 19Depth Depth 38 F < 19 FF1<<19 2 FF01<<19 0 0 0 thresh1: 38 node node node node
Depth1
Tree0 Depth0 Depth1
0: FFalse F < 46 1: True F1 < 38 thresh0: 46 1 < 380 node node 1: True 0: False
F0 = 42 F1 = 34
1
F < 19 F0 < 19 F0 < 19 F0 0 < 19 node0 node node node Depth2 Leaf F0 < 19 Leaf F0 <Leaf 19 Leaf F0 <Leaf 19 Leaf F0 <Leaf 19 Leaf Value Value Value Value Value Value0 Value thresh Value 2: 19 Leaf 0Leaf 1 Leaf 2Leaf 3 Leaf 4Leaf 50Leaf 6Leaf 7 Value Value Value Value Value Value Value Value Leaf0 Leaf1 Leaf2 Leaf3 Leaf Leaf6 = Leaf Leaf 110 4 Leaf5Addr 7 Value Value Value Value Value Value Value Value 0 1 2 3 4 5 6= 110 7 Leaf Addr
Mask F0 1 Mask F1 0
Leaf Addr = 110
0 1
1 0
Figure 12: Mapping of GBDT trees to DRAM. Execution flow. Figure 13 shows the proposed execution flow for CatBoost inference on PuD. The algorithm processes one feature at a time using a two-stage process. In the first stage of processing a feature, the host processor issues PuD operations based on the current feature value to perform a vector–scalar comparison against all node thresholds across all columns. This comparison is applied uniformly to all columns, regardless of which feature each node actually uses, yielding a 1-bit result for "(feature value) < (node threshold)" in each column. In the second stage of processing a feature, the one-hot mask for the current feature is applied via a bitwise AND, so that only columns whose nodes use the current feature retain their comparison result; all others are cleared to zero. The masked result is then merged into the accumulated leaf address bitmap using a bitwise OR. The algorithm repeats this twostage process for every feature used by the model. Each DRAM bank processes one input instance, and multiple banks operate concurrently. Tree0
Mask for F0 1 Mask for F1 0
0 1
Stage 2 for
Stage 1 for
1 0
1 0 1
Comparison Results
0 1 0
Stage 1 for
Stage 2 for
Compare against
Compare against 1 0 0
1 0
0 1
1 0
AND
Leaf Addresses
1 1
6.1.1 Implementation with Clutch. Our contributions include a novel method for accelerating CatBoost inference under the PuD architecture. To our knowledge, this is the first demonstration of accelerating GBDT inference on PuM. Our mapping of CatBoost to PuD execution is based on our key insight that tree traversal can be reformulated as a sequence of vector–scalar comparisons followed by mask operations. Furthermore, in this mapping, the per-node bitmaps directly correspond to leaf addresses, minimizing the cost of reading out inference results. Layout. We map each decision-tree node to a single DRAM column, as illustrated in Figure 12. Each column stores (i) the node’s
Mapping to DRAM
thresh0 thresh1 thresh2
We demonstrate the applicability of Clutch to real-world workloads by evaluating it on two representative cases that benefit from the acceleration of comparisons: inference on Gradient Boosting Decision Tree (GBDT), which is widely used in finance, healthcare, and web services, and predicate evaluation, which is commonly used in query processing for databases, scientific computing, and image processing.
Instance0
Depth0
Accelerating Applications
thresh0 thresh1 thresh2
6
GBDT Model Treen_tree-1 node F0 < 46 Tree1 node 1: True 0: False F0 < 46 Tree0 node node node
Depth2
(b)
Depth1
(a)
Figure 11: Energy efficiency of vector-scalar comparisons at (a) 8-bit precision, (b) 16-bit precision, and (c) 32-bit precision.
Perform vector–scalar comparison of F0 against all thresholds
0
0
2 Apply the one-hot mask for F0
3
1 0 1
0 1 1
1 0 0
AND
1
0
0
OR
Perform vector–scalar comparison of F1 against all thresholds
1 0
0 1
1 0
1
1
0 Leaf Addr
4
Apply the one-hot mask for F1 Merge the results
Figure 13: Proposed GBDT inference flow on PuD. Figure 13 illustrates this flow for a model with two features, 𝐹 0 and 𝐹 1 , showing the four steps that result from applying the twostage process to each feature. First, a vector–scalar comparison of 𝐹 0 is performed against all node thresholds ( 1y ). The one-hot mask for 𝐹 0 is then applied via bitwise AND, retaining comparison results only for nodes that use 𝐹 0 ( 2y ). Next, a vector–scalar comparison
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
Table 2: Evaluated system configurations for GBDT Main Memory 4 GB DDR4-2400 [97], single-channel, 64-bit, single rank; (COTS DRAM) 16 banks per rank, 8 KB row buffer per bank; Peak bandwidth: 19.2 GB/s Processor (Real CPU)
Quad-core ARM Cortex-A53 [15], up to 1.5 GHz; L1 Cache: 32 kB D-cache, 32 kB I-cache; L2 Cache: 1 MB shared, 64 B line size
Since Clutch repeats vector–scalar comparisons for each feature, the performance of CatBoost inference on Clutch depends on the number of features. We therefore evaluate performance across datasets with varying feature counts. We use large-scale, real-world tabular datasets listed in Table 3, following prior work on GBDT benchmarking [149]. We evaluate a multi-task inference composed of four independent tasks, each predicted by a GBDT model, following the standard multi-task scenario [94, 129]. We vary the number
Table 3: Datasets for GBDT Inference. Dataset
# of Features
Size
airline [13] higgs [23] covtype [25]
13 28 54
115M 28M 581K
We first focus on the large model configuration with depth 10. Figure 14 shows the throughput results for different datasets and bit-precisions. Clutch provides up to 4.5× (3.5× on average) speedup over CPU-based execution and up to 3.8× (2.2× on average) speedup over bit-serial PuD. As the number of features increases, the execution time of both the bit-serial PuD and Clutch degrades due to the linear increase in the number of comparisons required to determine leaf addresses. Under such conditions, the advantage of Clutch becomes more pronounced compared to the bit-serial PuD approach. For example, for the 32-bit inference with the covtype dataset, the bit-serial PuD method performs worse than the CPU baseline, whereas Clutch (M) provides a 3.1× speedup over the CPU.
(a)
(b)
(c)
Figure 14: Normalized throughput of GBDT inference at (a) 8-bit precision, (b) 16-bit precision, and (c) 32-bit precision. Figure 15 presents the breakdown of execution time and energy consumption for the 32-bit higgs dataset. For the PuD implementations, the breakdown consists of three components: 1) PuD execution that performs in-DRAM leaf-address retrieval (PuD-side), 2) transfer of the leaf addresses from DRAM to the host (DRAMtoHost), and 3) CPU-side summation of leaf values (CPU-side).
Normalized Energy Consumption (CPU=1)
6.1.2 Performance and Energy Evaluation. GBDT models are commonly deployed on resource-constrained environments such as edge devices or embedded systems [103, 180, 202]. To evaluate the performance under typical scenarios, we use a real, relatively low-power CPU system described in Table 2. We employ an optimized CPU implementation of CatBoost [83, 149] by leveraging Arm NEON SIMD instructions [16] along with multithreading to maximize performance on the baseline system. We estimate the CPU power consumption using the Xilinx Power Estimator [190]. For a fair comparison, we evaluate the advantages of CatBoost inference using Clutch when PuD is integrated into this system. We evaluate PuD under this system configuration by assuming a parallelism of 64K columns × 16 banks, corresponding to a single DDR4 rank as described in Table 2. The number of chunks used for each bit-precision follows the configuration described in §5.1.
of trees of the model across 512, 1024, and 2048, which we refer to as small, medium, and large configurations, respectively. We also vary the depth of each tree across 8, 10, and 12. Feature comparisons are evaluated at three different bit-precisions: 8-bit, 16-bit, and 32-bit. All leaf values are fixed at 16-bit precision. The default batch size is set to 1024.
Normalized Execution Time (CPU=1)
of 𝐹 1 is performed against all node thresholds ( 3y ). Finally, the one-hot mask for 𝐹 1 is applied via bitwise AND, and the result is merged with the 𝐹 0 bitmap produced in 2yvia bitwise OR to update the leaf address bitmap ( 4y ). Leaf addresses in DRAM. After sweeping all features, each column holds the final comparison result for its node. Because nodes are laid out by depth, the comparison results across depths naturally form a binary encoding of the leaf address. For example, in Figure 12 and Figure 13, a tree of depth 3 has leaf addresses ranging from 0 to 7. If the comparison results at depths 0, 1, and 2 are 1, 1, and 0, respectively, the resulting bitmap encodes the binary value 110, which corresponds to leaf address 6. In this way, the bitmap remaining in DRAM after all comparisons directly encodes, for each tree, the leaf address determined by the comparison results at each depth. Minimal CPU involvement. The CPU reads a single DRAM row to obtain all trees’ leaf addresses, fetches the corresponding leaf values from DRAM, and sums them to produce the final inference output (i.e., the predicted value). Both the comparisons at each node and the tree traversal based on the comparison results are performed entirely inside DRAM, with no intermediate data transferred offchip. The CPU is only involved in the final step of aggregating leaf values and producing the predicted value.
Daichi Tokuda et al.
(a)
(b)
Figure 15: Breakdown of (a) execution time and (b) energy consumption of GBDT inference. In Bit-Serial (M), the PuD-side component is responsible for 70.2% of the total execution time, while CPU-side component accounts for 29.2% and DRAMtoHost for 0.6% of the total execution
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding
(CPU, 64 Batch Size = 1)
Normalized Throughput
3.7×
(a)
3.2×
Figure 16: Sensitivity of GBDT inference throughput to batch size. To evaluate the generality of Clutch across various model configurations, we use the higgs dataset and test various combinations of tree sizes and depths. Figure 17 demonstrates that Clutch (M) consistently outperforms other methods across different model settings, providing up to 5.1× (3.9× on average) speedup over the CPU and up to 3.6× (2.5× on average) over Bit-Serial (M). In particular, when the tree size is small, bit-serial PuD suffers significant throughput loss due to insufficient utilization of parallelism. In contrast, Clutch maintains high performance even in such cases thanks to its faster execution of in-DRAM comparison, providing 2.9× higher throughput than the CPU on average across Clutch (U) and Clutch (M).
Depth = 10
Depth = 12
(b)
Figure 18b compares the memory footprint when the tree size is large and using 32-bit precision. Since the memory footprint is identical for Bit-Serial (U) and Bit-Serial (M), and likewise for Clutch (U) and Clutch (M), Figure 18b shows one entry each for Bit-Serial and Clutch. In Figure 18b, Feature Idx refers to the memory footprint of the feature index stored for each node, which corresponds to the one-hot feature masks in Clutch’s layout. For deeper trees (depth = 12), leaf values dominate the total memory footprint, and Clutch introduces an additional encoding overhead of about 85 MB compared to the baseline model. For shallow trees (depth = 8), the relative overhead of Clutch becomes larger because the baseline model itself is smaller; however, the absolute footprint of the Clutchencoded model remains modest at around 60 MB in total, which is within 1–2% of the 4–8 GB DRAM capacity typically available on embedded devices.
6.2
(b)
Depth = 8
Figure 18: Clutch overhead analyses. (a) Effective GBDT inference throughput including the data conversion overhead. (b) Memory footprint.
4.3×
2.8×
(a)
Memory Footprint [MB]
6.1.3 Data Conversion and Memory Footprint Overheads. We quantitatively evaluate the overhead introduced by the Clutch encoding scheme in terms of data conversion time and memory footprint during CatBoost inference. Clutch requires a one-time conversion of the vector data from binary to chunked temporal coding before inference starts. One way to eliminate this overhead is to pre-convert the static vector data offline and store the converted representation in DRAM before execution. Another approach is to perform the conversion once at runtime and amortize its cost over subsequent inference instances (i.e., input data points). As more instances are processed, the per-instance overhead decreases. Figure 18a shows the effective throughput (i.e., the throughput measured from the start of conversion through inference), including the initial conversion overhead, as a function of the number of inference instances processed. The point at which Clutch’s effective throughput curve crosses the CPU baseline is approximately 5K inference instances, demonstrating that the conversion overhead is quickly amortized in practical workloads.
Normalized Throughput (CPU=1)
time. In Clutch (M), the PuD-side component reduces to 23.9% and DRAMtoHost accounts for 1.5%, shifting the dominant bottleneck to the CPU-side at 74.6%. This is because Clutch reduces the PuD-side operation cost by 7.0× on average compared to bit-serial PuD. A similar trend is observed in energy consumption. In Bit-Serial (M), the PuD-side accounts for 54.2% of total system energy, while CPU-side accounts for 45.6% and DRAMtoHost accounts for 0.3%. In Clutch (M), the PuD-side share reduces to 18.0%, while DRAMtoHost accounts for 0.7%, with the CPU-side becoming the dominant contributor at 81.3%. Overall, Clutch provides a 2.9× energy efficiency improvement over the CPU and 2.8× over bit-serial PuD on average. Figure 16 shows the sensitivity to batch size for the 32-bit higgs dataset. Throughput is normalized to the CPU baseline with a batch size of 64. The numbers annotated next to each Clutch (M) data point indicate the throughput improvement of Clutch (M) over the CPU at the corresponding batch size. As batch size increases, CPU L1 and L2 data cache hit rate improves during the CPU-based accumulation of leaf values, resulting in faster execution. Consequently, the comparison operations become more dominant in overall execution time, making the throughput advantage of Clutch over both the CPU and bit-serial PuD more pronounced. At a batch size of 4096, Clutch (M) provides 4.3× speedup over the CPU and 3.3× over Bit-Serial (M).
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
(c)
Figure 17: Sensitivity of GBDT inference throughput to model size at (a) 8-bit precision, (b) 16-bit precision, and (c) 32-bit precision.
Predicate Evaluation
Predicate evaluation is a fundamental operation in data-centric applications, appearing in database queries [54, 72, 73, 91, 100, 113, 121, 186], scientific computing, and image processing [1, 53, 154, 193, 205]. It applies numerical or categorical predicates (e.g., inequalities or category-membership tests) and produces the bitmap indicating whether each element satisfies the predicate. This bitmap enables efficient filtering and reduces the workload for subsequent computations. In in-memory databases, predicate evaluation is typically implemented via column scans in the WHERE clause, playing a key role in early-stage query processing and lowering the cost of operations such as aggregation [54, 72, 73, 91, 100, 113, 121, 186]. We
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
evaluate Clutch on predicate evaluations from in-memory database workloads. In the PuD implementation, each DRAM column corresponds to one record, and all feature values of that record are placed vertically within the same column in the same subarray [161]. In Clutch’s implementation, each feature vector is encoded using chunked temporal coding. Because the Clutch algorithm described in Algorithm 1 supports only the < comparison, other comparison operators are derived as follows. The ≤ operator is realized by decrementing the scalar value by one, since 𝑎 ≤ 𝑏 is equivalent to (𝑎 − 1) < 𝑏 for integers. The > and ≥ operators are obtained by negating the results of ≤ and <, respectively. On Modified PuD, this negation is performed using bulk bitwise NOT operations, while on Unmodified PuD, which lacks the native NOT, the complement of each feature value is additionally stored to obtain the negated result; this is analogous to how the bit-serial PuD on Unmodified DRAM also maintains complemented values to support all comparison operators [63, 110]. Finally, the == operator is computed as the bitwise AND of ≤ and ≥. In this way, Clutch-based PuD supports all five comparison operators (<, ≤, >, ≥, and ==). For each predicate, PuD produces a bitmap directly in DRAM, and bitwise AND or OR operations are then performed within the same subarray to produce the final bitmap corresponding to the WHERE clause. This resulting bitmap is then loaded by the processor, which performs subsequent operations such as COUNT or AVERAGE. 6.2.1 Evaluation. We evaluate the effect of Clutch-based acceleration of predicate evaluation. Since Clutch’s performance is sensitive to the bit-precision of feature values, and existing general-purpose query evaluation benchmarks do not allow flexible control over bit-precision, we develop our own benchmark, as done in prior work [60, 121, 161, 184, 191]. Our benchmark captures a broad range of query patterns, from common to more intricate cases, as summarized in Table 4. Each dataset consists of eight features sampled from a uniform distribution. We use three levels of bitprecision (8-bit, 16-bit, and 32-bit) and three different data sizes measured in the total number of feature values (small table: 64M, medium table: 256M, and large table: 1G), corresponding to 8M, 32M, and 128M records, respectively. Table 4: Benchmark queries Q1
WHERE 𝑥 0 < 𝑓𝑖 < 𝑥 1
Q2
WHERE (𝑥 0 < 𝑓𝑖 < 𝑥 1 AND 𝑦0 < 𝑓 𝑗 < 𝑦1 )
Q3
COUNT (WHERE (𝑥 0 < 𝑓𝑖 < 𝑥 1 OR 𝑦0 < 𝑓 𝑗 < 𝑦1 ))
Q4
AVERAGE(𝑓𝑘 ) FROM (WHERE 𝑥 0 < 𝑓𝑖 < 𝑥 1 AND 𝑦0 < 𝑓 𝑗 < 𝑦1 )
Q5
WITH avg_val = AVERAGE(𝑓𝑘 ) WHERE (𝑥 0 < 𝑓𝑖 < 𝑥 1 OR 𝑦0 < 𝑓 𝑗 < 𝑦1 ) COUNT (WHERE avg_val < 𝑓ℓ < 2· avg_val )
We evaluate Clutch’s performance on 1) a desktop-class CPU system as described in Table 1 and 2) a server-class GPU system as summarized in Table 5. Following prior work [124], we project the throughput of PuD when integrated into the A100’s HBM2 memory, assuming that the HBM2 subarray structure can support PuD operations as in DDR4. In this analysis, we assume a per-stack parallelism of 2KB columns × 16 banks × 8 channels.
Daichi Tokuda et al.
Table 5: Evaluated system configurations for predicate evaluation on GPU Main Memory (COTS DRAM)
5 stacks of HBM2, total 40 GB; Peak bandwidth: 1555 GB/s;
Processor (Real GPU)
NVIDIA A100 Tensor Core GPU (PCIe), up to 1.59 GHz; SMs: 108, CUDA Cores: 6912;
We compare the PuD approach against BitWeaving-V [121], a state-of-the-art implementation for predicate evaluation on CPU. BitWeaving-V stores data in a transposed, bit-sliced layout optimized for predicate evaluation, and we confirm that it provides higher performance than conventional layouts for all tested bitprecisions on both CPU and GPU. Since both the CPU baseline using BitWeaving-V and PuD operate on transposed layouts that are not suited for value retrieval, all platforms (CPU, GPU, and PuD) also maintain a copy of the database in a conventional layout to efficiently perform post-processing operations such as AVERAGE. Clutch uses the following number of chunks: 8-bit: 2 chunks, 16-bit: 4 chunks, 32-bit (Modified PuD): 8 chunks, and 32-bit (Unmodified PuD): 12 chunks, so that all feature vectors fit within a subarray. 4 We first focus on the evaluation of Q2 on the CPU-based system. Figure 19 shows the normalized throughput relative to CPU for three table sizes and three bit-precisions. Clutch provides up to 83× (50× on average) speedup over the CPU. This improvement is due to the ability of PuD to reduce data transfers for both comparison operations and bitmap reductions. Compared to bit-serial PuD, Clutch provides up to 4.0× (3.1× on average) speedup.
(a)
(b)
(c)
Figure 19: Normalized throughput of Q2 at (a) small table, (b) medium table, and (c) large table. Figure 20 presents the energy efficiency normalized to CPU for the large table configuration. Clutch provides up to 218× (135× on average) energy efficiency improvement over the CPU and up to 4.2× (3.1× on average) over bit-serial PuD.
(a)
(b)
(c)
Figure 20: Normalized energy efficiency of Q2 at (a) 8-bit precision, (b) 16-bit precision, and (c) 32-bit precision. We quantitatively evaluate the overhead of data format conversion for predicate evaluation at 32-bit precision, following the 4 On Unmodified PuD, each feature value and its complement must both be stored to
support all comparison operators. Depending on the configuration, a larger number of chunks can be required to fit all features within the row budget of a single subarray.
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding
same methodology as the GBDT evaluation (Figure 18a). As with GBDT inference, Clutch requires a conversion of the vector data from binary to chunked temporal coding before execution begins. Figure 21 shows the effective throughput, including this initial conversion overhead, as a function of the number of queries processed. Since the conversion cost is fixed, it is amortized over subsequent queries (i.e., the per-query overhead decreases as more queries are processed). Clutch surpasses the CPU throughput after processing approximately 1.5K–1.9K queries, and outperforms the bit-serial PuD after processing approximately 48K–61K queries. If this amortization is insufficient, the runtime conversion overhead can be eliminated entirely by pre-converting the data offline and storing it in DRAM before execution. Normalized Throughput (CPU=1)
CPU
Bit-Serial (U)
Bit-Serial (M)
Clutch (U)
Clutch (M)
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
respectively. On the CPU-based system, in the Bit-Serial (M) implementation, post-bitmap processing on the processor side accounts for 96% of the total execution time for Q4 and 92% for Q5. Since Clutch accelerates only the PuD-side execution, the overall throughput improvement is inherently limited for these queries. 34× 43×
31× 37× 43× 57× 42× 56×
33× 42×
2.3× 2.5×
1.7× 1.8×
(a)
46× 59× 43× 81× 43× 81×
2.2× 2.7×
(b)
(c)
Figure 23: Normalized throughput on CPU-based system at (a) 8-bit precision, (b) 16-bit precision, and (c) 32-bit precision.
40 40 60 30 30 45 20 20 30 10 10 15 0 100K 200K 300K 400K 500K 600K 0 100K 200K 300K 400K 500K 600K 0 100K 200K 300K 400K 500K 600K
# of Queries
# of Queries
# of Queries
Figure 21: Effective throughput of Q2 including the data conversion overhead at (a) 8-bit precision, (b) 16-bit precision, and (c) 32-bit precision. Clutch provides a flexible tradeoff between throughput and memory footprint by adjusting the chunk count. Figure 22 illustrates this tradeoff space between memory footprint and the throughput of Q2. Within 1.5× the memory footprint of the CPU execution, Clutch (M) provides up to 58× (44× on average) higher throughput compared to the CPU, and within 2.0×, up to 70× (53× on average). Compared to Bit-Serial (M), Clutch (M) provides up to 2.9× (2.4× on average) higher throughput within 1.5× the memory footprint of the bit-serial PuD, and up to 3.5× (2.9× on average) within 2.0×.
(a)
(b)
(c)
Figure 24: Normalized throughput on GPU-based system at (a) 8-bit precision, (b) 16-bit precision, and (c) 32-bit precision.
(a)
(b)
Figure 25: Breakdown of execution time on CPU-based system at (a) Q4 and (b) Q5.
(a)
(b)
(c)
Figure 22: Tradeoff between throughput and memory footprint of Q2 at (a) 8-bit precision, (b) 16-bit precision, and (c) 32-bit precision. Figure 23 5 and Figure 24 show the throughput for all five queries listed in Table 4 executed on the medium table using the CPU system (Table 1) and the GPU system (Table 5), respectively. On the CPU system, Clutch provides up to 81× (28× on average) higher throughput than the CPU and up to 4.0× (2.2× on average) over the bit-serial PuD implementation for Q1 through Q5. For Q4 and Q5, where post-processing operations dominate, Clutch provides up to 2.7× (2.1× on average) speedup over the CPU baseline; however, its additional speedup over the bit-serial PuD implementation is limited to up to 1.08× (1.05× on average). To understand this trend, Figure 25 and Figure 26 show the breakdown of execution time at 8-bit precision on the CPU-based and GPU-based systems, 5 In Figure 23, the numbers annotated near each bar indicate the speedup over the CPU
baseline. For Q4 and Q5, the annotated numbers correspond to Clutch (M).
(a)
(b)
Figure 26: Breakdown of execution time on GPU-based system at (a) Q4 and (b) Q5. In contrast, on the GPU system, the bit-serial PuD implementation fails to outperform processor execution in most cases, whereas Clutch provides up to 5.7× (3.3× on average) speedup over GPUbased execution and up to 6.6× (4.3× on average) over bit-serial PuD. This is because, in HBM2, the ratio of column-level parallelism to memory bandwidth is smaller than that on DDR4, making the bit-serial in-DRAM comparisons a more prominent bottleneck. As a result, even for Q4 and Q5, the PuD-side comparison accounts for 63% and 61% of the total execution time on average in the BitSerial (M) implementation, as shown in Figure 26. By accelerating this dominant component, Clutch provides end-to-end throughput gains on the GPU system. This highlights Clutch’s advantage in efficiently handling comparison-intensive workloads even under
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
limited column-level parallelism, helping to unlock the full performance potential of future PuD architectures integrated with HBM.
7 Discussion 7.1 Limitations of Clutch Clutch does not always deliver significant throughput improvements compared to CPU-based execution or bit-serial PuD implementations. This section discusses the primary scenarios where Clutch can be less effective. 7.1.1 Comparison is Not the Dominant Bottleneck. Clutch can fail to provide high throughput when comparison operations are not the dominant performance bottleneck. For instance, on CPU-based systems, the execution of Q3, Q4, and Q5 with bit-serial PuD shows limited improvement due to the dominant cost of post-comparison processing (see Figure 25). To address this limitation, even in such cases, offloading non-comparison operations to dedicated hardware integrated within the memory controller can enable applications to benefit from Clutch’s high-speed comparison operations. Clutch has the potential to be effectively combined with other specialized processing units including Processing-near-Memory techniques [4– 7, 10–12, 17–22, 24, 27–35, 37, 41, 42, 44, 48–50, 52, 55–57, 65, 66, 68– 71, 74–80, 82, 86, 87, 89, 90, 96, 99, 101, 104, 105, 108, 112, 114– 117, 122, 123, 125, 128, 134, 135, 137, 144, 147, 148, 150, 155, 156, 167, 171, 172, 177, 183, 189, 200, 201, 208, 209] to enhance overall system performance. 7.1.2 Limited Benefit with Small Working Sets. As discussed in §3, one key source of PuD’s performance gain is its ability to reduce off-chip data movement. When the vector working set fits entirely within the processor’s cache hierarchy, however, this benefit largely disappears: data can be reused from the cache, and a sufficiently powerful processor can, in principle, outperform PuD. In such small–working set scenarios (e.g., inference with small GBDT models or predicate evaluation over small tables on server-class processors) conventional processor-centric execution can be the more appropriate choice. Even when the working set fits in the CPU cache, Clutch can still exceed the processor’s throughput in some cases. Clutch offers very high comparison throughput inside DRAM (e.g., providing 4.9 TOPS for 16-bit comparison under the configuration of Table 1). Moreover, it produces 1-bit-per-element bitmaps, reducing off-chip data movement, and these bitmaps can be combined using highthroughput in-DRAM bitwise operations. 7.1.3 Limited Benefit with Non-Static Vector Data. Although we quantitatively showed that the overhead of data conversion for Clutch can be amortized when the converted vector data is reused repeatedly during application execution (see Figure 18a and Figure 21), this amortization benefit diminishes when the vector data is not static. If the vector is frequently updated throughout the application, Clutch cannot deliver as high performance. This is because its specialized encoding scheme incurs a high cost during vector updates. This motivates future work on extending Clutch to efficiently support frequently updated vectors.
Daichi Tokuda et al.
7.1.4 When Memory Capacity Headroom Is Absent. Clutch’s specialized encoding incurs memory capacity overhead. When sufficient headroom is unavailable, this overhead can cause some data to be paged out, undermining overall performance gains. In such cases, the system should fall back to the bit-serial PuD. However, Clutch can adjust its chunk count to operate within a given capacity budget and still deliver substantial speedups (e.g., within 1.5× the baseline memory footprint, Clutch provides up to 58× higher throughput over the CPU for Q2).
7.2
Synergy Between Clutch Algorithm and PuD Execution
Clutch’s temporal-coding algorithm is designed to be general and can, in principle, be executed on a conventional processor. However, PuD execution uniquely amplifies its benefit. In a processor-based execution, the processor must read every per-chunk bitmap from DRAM to combine them into the final comparison result, generating data transfer proportional to the number of chunks. PuD eliminates this overhead by performing all per-chunk lookups and their combination entirely within DRAM, so that only the final result bitmap needs to be transferred to the processor. Consequently, Clutch-PuD reduces data transfer by 5× for 32-bit kernel-level comparisons, and by up to 140× (Figure 14) and 17× (Figure 19) at the application level compared to executing the same Clutch algorithm on the CPU. These results show the strong affinity between the Clutch algorithm and the PuD paradigm.
7.3
System Integration
Clutch requires the host processor to dynamically issue PuD operations based on the scalar value the host processor holds. Clutch follows the host-driven system integration model introduced by prior work [43, 110], where the host processor dynamically constructs a 𝜇Program based on the scalar value and dispatches it to the memory-controller-side control unit for execution. From the PuD execution framework originally introduced by SIMDRAM [81], Clutch adopts a subset of its mechanisms: (i) a small ISA extension that provides an invocation surface to trigger PuD operations on selected memory regions, (ii) OS support to manage PIM objects, and (iii) a lightweight control unit associated with the memory controller that executes the 𝜇Program and issues the corresponding DRAM commands with the timing parameters required for PuD operations such as RowCopy and MAJ3. Unlike SIMDRAM, Clutch does not require a hardware datatransposition unit that converts data between horizontal and vertical layouts at runtime. In Clutch, the scalar value is initialized within DRAM through RowCopy from constant rows, eliminating the need for runtime layout conversion and its associated hardware complexity. As a result, Clutch can be realized with modest extensions to the memory controller and small ISA/OS modifications.
7.4
Outlook for Future DRAM and PuD’s Potential
PuD’s advantage can be understood by a balance: (i) how much internal column-level parallelism a DRAM module can expose per ACT, versus (ii) the off-chip bandwidth available to processor-based execution. As newer DRAM technologies increase off-chip bandwidth,
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding
holding internal parallelism fixed would shrink PuD’s relative edge. However, PuD-oriented optimizations (e.g., increasing column-level parallelism and aggressively exploiting subarray-level parallelism (SALP) [109, 142]) can increase PuD computation throughput. With these enhancements, PuD’s advantage can be preserved and even amplified across DRAM generations.
8
Related Work
Other PuD architectures. Although various PuD architectures have been proposed [2, 45–47, 59, 81, 109, 118, 119, 142, 143, 157, 158, 160, 162, 164, 168, 179, 185, 188, 192], Clutch differs from these proposals in two key aspects. First, by introducing a data representation tailored to comparisons, Clutch provides the highest throughput among PuD approaches for vector–scalar comparisons. Second, Clutch takes an algorithmic approach rather than an architectural one, and therefore can be applied to modern density-optimized DRAM chips [127, 131, 136] without requiring modifications to DRAM circuitry. Among bit-serial PuD systems, recent successors to SIMDRAM, such as MIMDRAM [143] and Proteus [142], add modifications to DRAM circuitry or its peripheral logic to support MIMD execution and dynamic bit-precision, respectively. Clutch is orthogonal to these architectural enhancements and compatible with such PuD architectures. Several non-bit-serial PuD techniques have also been explored, including designs that support inter-column data movement [47, 118, 119], stochastic computing [2, 118, 168, 179], and LUT-based execution [46, 59, 178, 206, 207]. These techniques differ from Clutch in two important ways. First, they require modifications to the DRAM cell array or its peripheral circuitry, increasing manufacturing cost and complexity, whereas Clutch takes an algorithmic approach that can operate on Unmodified DRAM [64, 67, 95, 110, 111, 138, 196–198]. Second, their designs primarily target multiplication and vector inner products rather than comparison operations. Among these, pLUTo [59] is the most closely related to Clutch as it enables general-purpose LUT-based function evaluation in DRAM. However, in pLUTo’s scheme, the memory footprint grows exponentially with operand bit-width when applied to vector–scalar comparison. Clutch addresses this limitation through its divideand-conquer chunking strategy, which enables memory-efficient scaling to high bit-precisions (e.g., 16-bit and 32-bit). Processing-near-Memory (PnM). Processing-near-memory (PnM) adds custom logic near the memory array [4–7, 10–12, 17–22, 24, 27– 35, 37, 41, 42, 44, 48–50, 52, 55–57, 65, 66, 68–71, 74–80, 82, 86, 87, 89, 90, 96, 99, 101, 104, 105, 108, 112, 114–117, 122, 123, 125, 128, 134, 135, 137, 144, 147, 148, 150, 155, 156, 167, 171, 172, 177, 183, 189, 200, 201, 208, 209]. PnM exploits the high internal memory bandwidth inside a DRAM chip. While PnM accelerates computation by providing higher memory bandwidth and lower latency to dedicated processing units, the full input vector must still be transferred from the memory array to those units. In contrast, PuD performs comparisons directly within the memory array, avoiding the transfer of the input vector to logic units. Furthermore, PuD requires no additional processing logic and directly exploits the massive column-level parallelism of the existing DRAM arrays.
9
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
Conclusion
We present Clutch, a PuD-oriented algorithm and data representation for accelerating vector–scalar comparison. Clutch provides a flexible tradeoff between memory footprint and throughput by combining a lookup-table-based comparison using temporal coding with a divide-and-conquer approach. Across two applications, GBDT inference and predicate evaluation, Clutch improves endto-end throughput (and energy efficiency) by an average of 12× (69×) over optimized processor execution and 2.9× (3.0×) over the state-of-the-art bit-serial PuD approach. These results demonstrate that DRAM can serve as a high-performance and energy-efficient computing substrate for comparison-intensive workloads.
Acknowledgments We thank the anonymous reviewers of MICRO 2025, HPCA 2026, and ICS 2026 for their valuable feedback. We also thank the members of CASYS at UTokyo and the SAFARI Research Group at ETH Zurich for providing a stimulating intellectual environment. We acknowledge the generous gifts from our industrial partners, including Google, Huawei, Intel, and Microsoft. This work is supported in part by JST CREST (JPMJCR21D2), JSPS KAKENHI (23H00467), JST ACT-X (JPMJAX25CC), the Semiconductor Research Corporation (SRC), the ETH Future Computing Laboratory (EFCL), and the AI Chip Center for Emerging Smart Systems (ACCESS).
References [1] Akmalbek Abdusalomov, Mukhriddin Mukhiddinov, Oybek Djuraev, Utkir Khamdamov, and Taeg Keun Whangbo. 2020. Automatic salient object extraction based on locally adaptive thresholding to generate tactile graphics. Applied Sciences (2020). [2] Salma Afifi, Ishan Thakkar, and Sudeep Pasricha. 2024. ARTEMIS: A Mixed Analog-Stochastic In-DRAM Accelerator for Transformer Neural Networks. IEEE TCAD (2024). [3] Shaizeen Aga, Supreet Jeloka, Arun Subramaniyan, Satish Narayanasamy, David Blaauw, and Reetuparna Das. 2017. Compute Caches. In HPCA. [4] Junwhan Ahn, Sungpack Hong, Sungjoo Yoo, Onur Mutlu, and Kiyoung Choi. 2015. A Scalable Processing-in-Memory Accelerator for Parallel Graph Processing. In ISCA. [5] Junwhan Ahn, Sungjoo Yoo, Onur Mutlu, and Kiyoung Choi. 2015. PIM-Enabled Instructions: A Low-Overhead, Locality-Aware Processing-in-Memory Architecture. In ISCA. [6] Berkin Akin, Franz Franchetti, and James C. Hoe. 2015. Data Reorganization in Memory Using 3D-Stacked DRAM. In ISCA. [7] Berkin Akın, James C. Hoe, and Franz Franchetti. 2014. HAMLeT: Hardware Accelerated Memory Layout Transform within 3D-Stacked DRAM. In HPEC. [8] Adrián Alcolea, Mercedes E Paoletti, Juan M Haut, Javier Resano, and Antonio Plaza. 2020. Inference in supervised spectral classifiers for on-board hyperspectral imaging: An overview. Remote Sensing (2020). [9] Mustafa F Ali, Akhilesh Jaiswal, and Kaushik Roy. 2019. In-Memory Low-Cost Bit-Serial Addition Using Commodity DRAM Technology. TCAS-I (2019). [10] M. A. Z. Alves, M. Diener, P. C. Santos, and L. Carro. 2016. Large Vector Extensions Inside the HMC. In DATE. [11] Marco A. Z. Alves, Paulo C. Santos, Matthias Diener, and Luigi Carro. 2015. Opportunities and Challenges of Performing Vector Operations Inside the DRAM. In MEMSYS. [12] M. A. Z. Alves, P. C. Santos, F. B. Moreira, et al. 2015. Saving Memory Movements Through Vector Processing in the DRAM. In CASES. [13] American Statistical Association. 2009. Data Expo 2009: Airline OnTime Performance. https://community.amstat.org/jointscsg-section/dataexpo/ dataexpo2009. [14] Shaahin Angizi and Deliang Fan. 2019. GraphiDe: A Graph Processing Accelerator Leveraging In-DRAM-Computing. In GLSVLSI. [15] Arm Ltd. 2016. Arm Cortex-A53 MPCore Processor Technical Reference Manual. [16] Arm Ltd. 2024. Arm Neon Intrinsics Reference. https://developer.arm.com/ architectures/instruction-sets/simd-isas/neon. [17] H. Asghari-Moghaddam, A. Farmahini-Farahani, K. Morrow, et al. 2016. NearDRAM Acceleration with Single-ISA Heterogeneous Processing in Standard
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
Memory Modules. IEEE Micro (2016). [18] Hadi Asghari-Moghaddam, Young Hoon Son, Jung Ho Ahn, and Nam Sung Kim. 2016. Chameleon: Versatile and Practical Near-DRAM Acceleration Architecture for Large Memory Systems. In MICRO. [19] Erfan Azarkhish, Christoph Pfister, Davide Rossi, Igor Loi, and Luca Benini. 2016. Logic-Base Interconnect Design for Near Memory Computing in the Smart Memory Cube. IEEE VLSI (2016). [20] Erfan Azarkhish, Davide Rossi, Igor Loi, and Luca Benini. 2016. A Case for Near Memory Computation Inside the Smart Memory Cube. In EMS. [21] Erfan Azarkhish, Davide Rossi, Igor Loi, and Luca Benini. 2018. Neurostream: Scalable and Energy Efficient Deep Learning with Smart Memory Cubes. TPDS (2018). [22] Oreoluwatomiwa O. Babarinsa and Stratos Idreos. 2015. JAFAR: Near-Data Processing for Databases. In SIGMOD. [23] Pierre Baldi, Peter Sadowski, and Daniel Whiteson. 2014. HIGGS Dataset. UCI Machine Learning Repository. https://archive.ics.uci.edu/dataset/280/higgs [24] Maciej Besta, Raghavendra Kanakagiri, Grzegorz Kwasniewski, Rachata Ausavarungnirun, Jakub Beránek, Konstantinos Kanellopoulos, Kacper Janda, Zur Vonarburg-Shmaria, Lukas Gianinazzi, Ioana Stefan, et al. 2021. SISA: SetCentric Instruction Set Architecture for Graph Mining on Processing-in-Memory Systems. In MICRO. [25] Jock A. Blackard and Denis J. Dean. 1999. Covertype. https://doi.org/10.24432/ C50K5N https://archive.ics.uci.edu/dataset/31/covertype. [26] Casper Solheim Bojer and Jens Peder Meldgaard. 2021. Kaggle forecasting competitions: An overlooked learning opportunity. International Journal of Forecasting (2021). [27] Amirali Boroumand. 2020. Practical Mechanisms for Reducing Processor-Memory Data Movement in Modern Workloads. Ph. D. Dissertation. Carnegie Mellon University. [28] Amirali Boroumand, Saugata Ghose, Berkin Akin, Ravi Narayanaswami, Geraldo F. Oliveira, Xiaoyu Ma, Eric Shiu, and Onur Mutlu. 2021. Google Neural Network Models for Edge Devices: Analyzing and Mitigating Machine Learning Inference Bottlenecks. In PACT. [29] Amirali Boroumand, Saugata Ghose, Berkin Akin, Ravi Narayanaswami, Geraldo F. Oliveira, Xiaoyu Ma, Eric Shiu, and Onur Mutlu. 2021. Mitigating Edge Machine Learning Inference Bottlenecks: An Empirical Study on Accelerating Google Edge Models. arXiv preprint arXiv:2103.00768 (2021). [30] Amirali Boroumand, Saugata Ghose, Youngsok Kim, Rachata Ausavarungnirun, Eric Shiu, Rahul Thakur, Daehyun Kim, Aki Kuusela, Allan Knies, Parthasarathy Ranganathan, et al. 2018. Google Workloads for Consumer Devices: Mitigating Data Movement Bottlenecks. In ASPLOS. [31] Amirali Boroumand, Saugata Ghose, Brandon Lucia, Kevin Hsieh, Krishna Malladi, Hongzhong Zheng, and Onur Mutlu. 2017. LazyPIM: An Efficient Cache Coherence Mechanism for Processing-in-Memory. CAL (2017). [32] Amirali Boroumand, Saugata Ghose, Geraldo F. Oliveira, and Onur Mutlu. 2021. Polynesia: Enabling Effective Hybrid Transactional/Analytical Databases with Specialized Hardware/Software Co-Design. arXiv preprint arXiv:2103.00798 (2021). [33] Amirali Boroumand, Saugata Ghose, Geraldo F. Oliveira, and Onur Mutlu. 2022. Polynesia: Enabling High-Performance and Energy-Efficient Hybrid Transactional/Analytical Databases with Hardware/Software Co-Design. In ICDE. [34] Amirali Boroumand, Saugata Ghose, Minesh Patel, Hasan Hassan, Brandon Lucia, Rachata Ausavarungnirun, Kevin Hsieh, Nastaran Hajinazar, Krishna T. Malladi, Hongzhong Zheng, et al. 2019. CoNDA: Efficient Cache Coherence Support for Near-Data Accelerators. In ISCA. [35] Amirali Boroumand, Saugata Ghose, Minesh Patel, Hasan Hassan, Brandon Lucia, Nastaran Hajinazar, Kevin Hsieh, Krishna T. Malladi, Hongzhong Zheng, and Onur Mutlu. 2017. LazyPIM: Efficient Support for Cache Coherence in Processing-in-Memory Architectures. arXiv preprint arXiv:1706.03162 (2017). [36] F Nisa Bostancı, Ataberk Olgun, Lois Orosa, A Giray Yağlıkçı, Jeremie S Kim, Hasan Hassan, Oğuz Ergin, and Onur Mutlu. 2022. DR-STRaNGe: End-to-End System Design for DRAM-Based True Random Number Generators. In HPCA. [37] Damla Senol Cali, Gurpreet S. Kalsi, Zülal Bingöl, Can Firtina, Lavanya Subramanian, Jeremie S. Kim, Rachata Ausavarungnirun, Mohammed Alser, Juan Gomez-Luna, Amirali Boroumand, et al. 2020. GenASM: A High-Performance, Low-Power Approximate String Matching Acceleration Framework for Genome Sequence Analysis. In MICRO. [38] Kevin K Chang, Prashant J Nair, Donghyuk Lee, Saugata Ghose, Moinuddin K Qureshi, and Onur Mutlu. 2016. Low-cost inter-linked subarrays (LISA): Enabling fast inter-subarray data movement in DRAM. In HPCA. [39] Tianqi Chen and Carlos Guestrin. 2016. Xgboost: A scalable tree boosting system. In Proceedings of the 22nd acm sigkdd international conference on knowledge discovery and data mining. [40] Ping Chi, Shuangchen Li, Cong Xu, Tao Zhang, Jishen Zhao, Yongpan Liu, Yu Wang, and Yuan Xie. 2016. PRIME: A Novel Processing-in-Memory Architecture for Neural Network Computation in ReRAM-Based Main Memory. In ISCA. [41] Seunghwan Cho, Haerang Choi, Eunhyeok Park, Hyunsung Shin, and Sungjoo Yoo. 2020. McDRAM v2: In-Dynamic Random Access Memory Systolic Array
Daichi Tokuda et al.
Accelerator to Address the Large Model Problem in Deep Neural Networks on the Edge. IEEE Access (2020). [42] Guohao Dai, Tianhao Huang, Yuze Chi, Jishen Zhao, Guangyu Sun, Yongpan Liu, Yu Wang, Yuan Xie, and Huazhong Yang. 2018. GraphH: A Processing-inMemory Architecture for Large-Scale Graph Processing. TCAD (2018). [43] Joao Paulo C de Lima, Ben Morris, Asif Ali Khan, Jeronimo Castrillon, and Alex K Jones. 2026. Count2multiply: Reliable in-memory high-radix counting. In HPCA. [44] João Paulo C. de Lima, Paulo Cesar Santos, Marco A. Z. Alves, Antonio Beck, and Luigi Carro. 2018. Design Space Exploration for PIM Architectures in 3D-Stacked Memories. In CF. [45] Quan Deng, Lei Jiang, Youtao Zhang, Minxuan Zhang, and Jun Yang. 2018. DrAcc: A DRAM Based Accelerator for Accurate CNN Inference. In DAC. [46] Quan Deng, Youtao Zhang, Minxuan Zhang, and Jun Yang. 2019. Lacc: Exploiting lookup table-based fast and accurate vector multiplication in dram-based cnn accelerator. In DAC. [47] Wenya Deng, Zhi Wang, Yang Guo, Jian Zhang, Zhenyu Wu, and Yaohua Wang. 2023. DAS: A DRAM-Based Annealing System for Solving Large-Scale Combinatorial Optimization Problems. In ICA3P. [48] Alain Denzler, Rahul Bera, Nastaran Hajinazar, Gagandeep Singh, Geraldo F. Oliveira, Juan Gómez-Luna, and Onur Mutlu. 2021. Casper: Accelerating Stencil Computation using Near-Cache Processing. arXiv preprint arXiv:2112.14216 (2021). [49] Fabrice Devaux. 2019. The True Processing in Memory Accelerator. In Hot Chips. [50] Mario Drumond, Alexandros Daglis, Nooshin Mirzadeh, Dmitrii Ustiugov, Javier Picorel, Babak Falsafi, Boris Grot, and Dionisios Pnevmatikatos. 2017. The Mondrian Data Engine. In ISCA. [51] Charles Eckert, Xiaowei Wang, Jingcheng Wang, Arun Subramaniyan, Ravi Iyer, Dennis Sylvester, David Blaauw, and Reetuparna Das. 2018. Neural Cache: Bit-Serial In-Cache Acceleration of Deep Neural Networks. In ISCA. [52] D. G. Elliott, M. Stumm, W. M. Snelgrove, et al. 1999. Computational RAM: Implementing Processors in Memory. D&T (1999). [53] F Gökhan Ergin. 2017. Dynamic masking techniques for particle image velocimetry. Isı Bilimi ve Tekniği Dergisi (2017). [54] Franz Färber, Norman May, Wolfgang Lehner, Philipp Große, Ingo Müller, Hannes Rauhe, and Jonathan Dees. 2012. The SAP HANA Database–An Architecture Overview. IEEE Data Eng. Bull. (2012). [55] A. Farmahini-Farahani, J. H. Ahn, K. Compton, and N. S. Kim. 2014. DRAMA: An Architecture for Accelerated Processing Near Memory. CAL (2014). [56] Amin Farmahini-Farahani, Jung Ho Ahn, Katherine Morrow, and Nam Sung Kim. 2015. NDA: Near-DRAM Acceleration Architecture Leveraging Commodity DRAM Devices and Standard Memory Modules. In HPCA. [57] Ivan Fernandez, Ricardo Quislant, Eladio Gutiérrez, Oscar Plata, Christina Giannoula, Mohammed Alser, Juan Gómez-Luna, and Onur Mutlu. 2020. NATSA: A Near-Data Processing Accelerator for Time Series Analysis. In ICCD. [58] João Dinis Ferreira, Gabriel Falcao, Juan Gómez-Luna, Mohammed Alser, Lois Orosa, Mohammad Sadrosadati, Jeremie S Kim, Geraldo F Oliveira, Taha Shahroodi, Anant Nori, et al. 2021. pLUTo: In-DRAM Lookup Tables to Enable Massively Parallel General-Purpose Computation. arXiv preprint arXiv:2104.07699 (2021). [59] João Dinis Ferreira, Gabriel Falcao, Juan Gómez-Luna, Mohammed Alser, Lois Orosa, Mohammad Sadrosadati, Jeremie S Kim, Geraldo F Oliveira, Taha Shahroodi, Anant Nori, et al. 2022. pLUTo: Enabling Massively Parallel Computation in DRAM via Lookup Tables. In MICRO. [60] Daichi Fujiki. 2023. MVC: Enabling fully coherent multi-data-views through the memory hierarchy with processing in memory. In MICRO. [61] Daichi Fujiki, Scott Mahlke, and Reetuparna Das. 2018. In-Memory Data Parallel Processor. In ASPLOS. [62] Daichi Fujiki, Scott Mahlke, and Reetuparna Das. 2019. Duality Cache for Data Parallel Acceleration. In ISCA. [63] Fei Gao, Georgios Tziantzioulis, and David Wentzlaff. 2019. ComputeDRAM: In-Memory Compute Using Off-the-Shelf DRAMs. In MICRO. [64] Fei Gao, Georgios Tziantzioulis, and David Wentzlaff. 2022. FracDRAM: Fractional values in off-the-shelf DRAM. In MICRO. [65] Mingyu Gao and Christos Kozyrakis. 2016. HRL: Efficient and Flexible Reconfigurable Logic for Near-Data Processing. In HPCA. [66] Mingyu Gao, Jing Pu, Xuan Yang, Mark Horowitz, and Christos Kozyrakis. 2017. TETRIS: Scalable and Efficient Neural Network Acceleration with 3D Memory. In ASPLOS. [67] Esteban Garzón, Alexander Fish, and Leonid Yavits. 2026. CADM: Content addressable commodity off-the-shelf DRAM-based genome classifier. Journal of Systems Architecture (2026). [68] Nika Mansouri Ghiasi, Jisung Park, Harun Mustafa, Jeremie Kim, Ataberk Olgun, Arvid Gollwitzer, Damla Senol Cali, Can Firtina, Haiyu Mao, Nour Almadhoun Alserr, et al. 2022. GenStore: A High-Performance and Energy-Efficient InStorage Computing System for Genome Sequence Analysis. In ASPLOS.
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding
[69] Christina Giannoula, Ivan Fernandez, Juan Gómez Luna, Nectarios Koziris, Georgios Goumas, and Onur Mutlu. 2022. SparseP: Towards Efficient Sparse Matrix Vector Multiplication on Real Processing-in-Memory Architectures. In SIGMETRICS. [70] Christina Giannoula, Nandita Vijaykumar, Nikela Papadopoulou, Vasileios Karakostas, Ivan Fernandez, Juan Gómez-Luna, Lois Orosa, Nectarios Koziris, Georgios Goumas, and Onur Mutlu. 2021. SynCron: Efficient Synchronization Support for Near-Data-Processing Architectures. In HPCA. [71] Maya Gokhale, Bill Holmes, and Ken Iobst. 1995. Processing in Memory: The Terasys Massively Parallel PIM Array. Computer (1995). [72] Goetz Graefe et al. 2011. Modern B-tree techniques. Foundations and Trends in Databases (2011). [73] Martin Grund, Jens Krüger, Hasso Plattner, Alexander Zeier, Philippe CudreMauroux, and Samuel Madden. 2010. Hyrise: a main memory hybrid storage engine. Proceedings of the VLDB Endowment (2010). [74] Peng Gu, Shuangchen Li, Dylan Stow, Russell Barnes, Liu Liu, Yuan Xie, and Eren Kursun. 2016. Leveraging 3D Technologies for Hardware Security: Opportunities and Challenges. In GLSVLSI. [75] Peng Gu, Xinfeng Xie, Yufei Ding, Guoyang Chen, Weifeng Zhang, Dimin Niu, and Yuan Xie. 2020. iPIM: Programmable In-Memory Image Processing Accelerator using Near-Bank Architecture. In ISCA. [76] Qi Guo, Nikolaos Alachiotis, Berkin Akin, Fazle Sadi, Guanglin Xu, Tze Meng Low, Larry Pileggi, James C. Hoe, and Franz Franchetti. 2014. 3D-Stacked Memory-Side Acceleration: Accelerator and System Design. In WoNDP. [77] Juan Gómez-Luna, Izzat El Hajj, Ivan Fernandez, Christina Giannoula, Geraldo F. Oliveira, and Onur Mutlu. 2021. Benchmarking Memory-Centric Computing Systems: Analysis of Real Processing-in-Memory Hardware. In CUT. [78] Juan Gómez-Luna, Izzat El Hajj, Ivan Fernandez, Christina Giannoula, Geraldo F. Oliveira, and Onur Mutlu. 2022. Benchmarking a New Paradigm: Experimental Analysis and Characterization of a Real Processing-in-Memory System. IEEE Access (2022). [79] Juan Gómez-Luna, Izzat El Hajj, Ivan Fernández, Christina Giannoula, Geraldo F. Oliveira, and Onur Mutlu. 2021. Benchmarking a New Paradigm: An Experimental Analysis of a Real Processing-in-Memory Architecture. arXiv preprint arXiv:2105.03814 (2021). [80] Ramyad Hadidi, Lifeng Nai, Hyojong Kim, and Hyesoon Kim. 2017. CAIRO: A Compiler-Assisted Technique for Enabling Instruction-Level Offloading of Processing-in-Memory. TACO (2017). [81] Nastaran Hajinazar, Geraldo F Oliveira, Sven Gregorio, João Dinis Ferreira, Nika Mansouri Ghiasi, Minesh Patel, Mohammed Alser, Saugata Ghose, Juan Gómez-Luna, and Onur Mutlu. 2021. SIMDRAM: A framework for bit-serial SIMD processing using DRAM. In ASPLOS. [82] Mary Hall, Peter Kogge, Jeff Koller, Pedro Diniz, Jacqueline Chame, Jeff Draper, Jeff LaCoss, John Granacki, Jay Brockman, Apoorv Srivastava, et al. 1999. Mapping Irregular Applications to DIVA, a PIM-Based Data-Intensive Architecture. In SC. [83] John T Hancock and Taghi M Khoshgoftaar. 2020. CatBoost for big data: an interdisciplinary review. Journal of big data (2020). [84] Hasan Hassan, Nandita Vijaykumar, Samira Khan, Saugata Ghose, Kevin Chang, Gennady Pekhimenko, Donghyuk Lee, Oguz Ergin, and Onur Mutlu. 2017. SoftMC: A flexible and practical open-source infrastructure for enabling experimental DRAM studies. In HPCA. [85] Zhezhi He, Li Yang, Shaahin Angizi, Adnan Siraj Rakin, and Deliang Fan. 2020. Sparse BD-Net: A Multiplication-Less DNN with Sparse Binarized Depth-Wise Separable Convolution. JETC (2020). [86] Kevin Hsieh, Eiman Ebrahimi, Gwangsun Kim, Niladrish Chatterjee, Mike O’Connor, Nandita Vijaykumar, Onur Mutlu, and Stephen W. Keckler. 2016. Transparent Offloading and Mapping (TOM) Enabling Programmer-Transparent Near-Data Processing in GPU Systems. In ISCA. [87] Kevin Hsieh, Samira Khan, Nandita Vijaykumar, Kevin K. Chang, Amirali Boroumand, Saugata Ghose, and Onur Mutlu. 2016. Accelerating Pointer Chasing in 3D-Stacked Memory: Challenges, Mechanisms, Evaluation. In ICCD. [88] Jianfeng Hu and Jianliang Min. 2018. Automated detection of driver fatigue based on EEG signals using gradient boosting decision tree model. Cognitive neurodynamics (2018). [89] Jiayi Huang, Ramprakash Reddy Puli, Pritam Majumder, Sungkeun Kim, Rahul Boyapati, Ki Hwan Yum, and Eun Jung Kim. 2019. Active-Routing: Compute on the Way for Near-Data Processing. In HPCA. [90] Yu Huang, Long Zheng, Pengcheng Yao, Jieshan Zhao, Xiaofei Liao, Hai Jin, and Jingling Xue. 2020. A Heterogeneous PIM Hardware-Software Co-Design for Energy-Efficient Graph Processing. In IPDPS. [91] Stratos Idreos, Fabian Groffen, Niels Nes, Stefan Manegold, K Sjoerd Mullender, Martin L Kersten, et al. 2012. MonetDB: Two decades of research in columnoriented database architectures. IEEE Data Eng. Bull. (2012). [92] Mohsen Imani, Saransh Gupta, Yeseong Kim, and Tajana Rosing. 2019. FloatPIM: In-Memory Acceleration of Deep Neural Network Training with High Precision. In ISCA.
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
[93] Intel Corporation. 2018. Intel Core i7-9700K Processor Datasheet. https://ark.intel.com/content/www/us/en/ark/products/186604/intel-core-i79700k-processor-12m-cache-up-to-4-90-ghz.html. [94] Leonid Iosipoi and Anton Vakhrushev. 2022. Sketchboost: Fast gradient boosted decision tree for multioutput problems. NeurIPS (2022). [95] Zuher Jahshan and Leonid Yavits. 2024. MajorK: Majority based kmer matching in commodity DRAM. CAL (2024). [96] Jaeyoung Jang, Jun Heo, Yejin Lee, Jaeyeon Won, Seonghak Kim, Sung Jun Jung, Hakbeom Jang, Tae Jun Ham, and Jae W. Lee. 2019. Charon: Specialized Near-Memory Processing Architecture for Clearing Dead Objects in Memory. In MICRO. [97] JEDEC Solid State Technology Association. 2012. DDR4 SDRAM Standard. https://www.jedec.org/standards-documents/docs/jesd79-4a. [98] Guolin Ke, Qi Meng, Thomas Finley, Taifeng Wang, Wei Chen, Weidong Ma, Qiwei Ye, and Tie-Yan Liu. 2017. Lightgbm: A highly efficient gradient boosting decision tree. NeurIPS (2017). [99] Liu Ke, Xuan Zhang, Jinin So, Jong-Geon Lee, Shin-Haeng Kang, Sukhan Lee, Songyi Han, Yeongon Cho, Jin Hyun Kim, Yongsuk Kwon, et al. 2021. NearMemory Processing in Action: Accelerating Personalized Recommendation with AxDIMM. IEEE Micro (2021). [100] Alfons Kemper, Thomas Neumann, Florian Funke, Viktor Leis, and Henrik Mühe. 2012. HyPer: Adapting Columnar Main-Memory Data Management for Transactional AND Query Processing. IEEE Data Eng. Bull. (2012). [101] Chad D. Kersey, Hyesoon Kim, and Sudhakar Yalamanchili. 2017. Lightweight SIMT Core Designs for Intelligent 3D Stacked DRAM. In MEMSYS. [102] Kashif Nizam Khan, Mikael Hirki, Tapio Niemi, Jukka K Nurminen, and Zhonghong Ou. 2018. Rapl in action: Experiences in using rapl for power measurements. TOMPECS (2018). [103] Alireza Khataei and Kia Bazargan. 2025. TreeLUT: An Efficient Alternative to Deep Neural Networks for Inference Acceleration Using Gradient Boosted Decision Trees. In FPGA. [104] Duckhwan Kim, Jaeha Kung, Sek Chai, Sudhakar Yalamanchili, and Saibal Mukhopadhyay. 2016. Neurocube: A Programmable Digital Neuromorphic Architecture with High-Density 3D Memory. In ISCA. [105] Jeremie S. Kim, Damla Senol Cali, Hongyi Xin, Donghyuk Lee, Saugata Ghose, Mohammed Alser, Hasan Hassan, Oguz Ergin, Can Alkan, and Onur Mutlu. 2018. GRIM-Filter: Fast Seed Location Filtering in DNA Read Mapping Using Processing-in-Memory Technologies. BMC Genomics (2018). [106] Jeremie S Kim, Minesh Patel, Hasan Hassan, and Onur Mutlu. 2018. The DRAM Latency PUF: Quickly Evaluating Physical Unclonable Functions by Exploiting the Latency-Reliability Tradeoff in Modern Commodity DRAM Devices. In HPCA. [107] Jeremie S Kim, Minesh Patel, Hasan Hassan, Lois Orosa, and Onur Mutlu. 2019. DRaNGe: Using Commodity DRAM Devices to Generate True Random Numbers With Low Latency and High Throughput. In HPCA. [108] Jeremie S. Kim, Damla Senol, Hongyi Xin, Donghyuk Lee, Saugata Ghose, Mohammed Alser, Hasan Hassan, Oguz Ergin, Can Alkan, and Onur Mutlu. 2017. GRIM-Filter: Fast Seed Filtering in Read Mapping using Emerging Memory Technologies. arXiv preprint arXiv:1708.04329 (2017). [109] Yoongu Kim, Vivek Seshadri, Donghyuk Lee, Jamie Liu, and Onur Mutlu. 2012. A case for exploiting subarray-level parallelism (SALP) in DRAM. ISCA (2012). [110] Tatsuya Kubo, Daichi Tokuda, Tomoya Nagatani, Masayuki Usui, Lei Qu, Ting Cao, and Shinya Takamaeda-Yamazaki. 2025. MVDRAM: Enabling GeMV Execution in Unmodified DRAM for Low-Bit LLM Acceleration. arXiv preprint arXiv:2503.23817 (2025). [111] Tatsuya Kubo, Daichi Tokuda, Lei Qu, Ting Cao, and Shinya TakamaedaYamazaki. 2025. PUDTune: Multi-Level Charging for High-Precision Calibration in Processing-Using-DRAM. CAL (2025). [112] Young-Cheon Kwon, Suk Han Lee, Jaehoon Lee, Sang-Hyuk Kwon, Je Min Ryu, Jong-Pil Son, Seongil O, Hak-Soo Yu, Haesuk Lee, Soo Young Kim, et al. 2021. A 20nm 6GB Function-in-Memory DRAM, Based on HBM2 with a 1.2 TFLOPS Programmable Computing Unit using Bank-Level Parallelism, for Machine Learning Applications. In ISSCC. [113] Tirthankar Lahiri, Shasank Chavan, Maria Colgan, Dinesh Das, Amit Ganesh, Mike Gleeson, Sanket Hase, Allison Holloway, Jesse Kamp, Teck-Hua Lee, et al. 2015. Oracle database in-memory: A dual format in-memory database. In ICDE. [114] Joo Hwan Lee, Jaewoong Sim, and Hyesoon Kim. 2015. BSSync: Processing Near Memory for Machine Learning Workloads with Bounded Staleness Consistency Models. In PACT. [115] Sukhan Lee, Shin-haeng Kang, Jaehoon Lee, Hyeonsu Kim, Eojin Lee, Seungwoo Seo, Hosang Yoon, Seungwon Lee, Kyounghwan Lim, Hyunsung Shin, et al. 2021. Hardware Architecture and Software Stack for PIM Based on Commercial DRAM Technology: Industrial Product. In ISCA. [116] S. Lee, K. Kim, S. Oh, J. Park, G. Hong, D. Ka, K. Hwang, J. Park, K. Kang, J. Kim, J. Jeon, N. Kim, Y. Kwon, K. Vladimir, W. Shin, J. Won, M. Lee, H. Joo, et al. 2022. A 1ynm 1.25V 8Gb, 16Gb/s/pin GDDR6-based Accelerator-in-Memory Supporting 1TFLOPS MAC Operation and Various Activation Functions for Deep-Learning Applications. In ISSCC.
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
[117] Jie Li, Xi Wang, Antonino Tumeo, Brody Williams, John D. Leidel, and Yong Chen. 2019. PIMS: A Lightweight Processing-in-Memory Accelerator for Stencil Computations. In MEMSYS. [118] Shuangchen Li, Alvin Oliver Glova, Xing Hu, Peng Gu, Dimin Niu, Krishna T Malladi, Hongzhong Zheng, Bob Brennan, and Yuan Xie. 2018. SCOPE: A Stochastic Computing Engine for DRAM-Based In-Situ Accelerator. In MICRO. [119] Shuangchen Li, Dimin Niu, Krishna T Malladi, Hongzhong Zheng, Bob Brennan, and Yuan Xie. 2017. DRISA: A DRAM-Based Reconfigurable In-Situ Accelerator. In MICRO. [120] Shuangchen Li, Cong Xu, Qiaosha Zou, Jishen Zhao, Yu Lu, and Yuan Xie. 2016. Pinatubo: A Processing-in-Memory Architecture for Bulk Bitwise Operations in Emerging Non-Volatile Memories. In DAC. [121] Yinan Li and Jignesh M Patel. 2013. Bitweaving: Fast scans for main memory data processing. In SIGMOD. [122] Hongyeol Lim and Giho Park. 2017. Triple Engine Processor (TEP): A Heterogeneous Near-Memory Processor for Diverse Kernel Operations. TACO (2017). [123] Jiawen Liu, Hengyu Zhao, Matheus A. Ogleari, Dong Li, and Jishen Zhao. 2018. Processing-in-Memory for Energy-Efficient Neural Network Training: A Heterogeneous Approach. In MICRO. [124] Jiantao Liu, Minxuan Zhou, Yue Pan, Chien-Yi Yang, Lana Josipović, and Tajana Rosing. 2025. OptiPIM: Optimizing Processing-in-Memory Acceleration Using Integer Linear Programming. In ISCA. [125] Elliot Lockerman, Axel Feldmann, Mohammad Bakhshalipour, Alexandru Stanescu, Shashwat Gupta, Daniel Sanchez, and Nathan Beckmann. 2020. Livia: Data-Centric Computing Throughout the Memory Hierarchy. In ASPLOS. [126] Advait Madhavan, Timothy Sherwood, and Dmitri Strukov. 2014. Race logic: A hardware acceleration for dynamic programming algorithms. ISCA (2014). [127] Michele Marazzi, Tristan Sachsenweger, Flavien Solt, Peng Zeng, Kubo Takashi, Maksym Yarema, and Kaveh Razavi. 2024. Hifi-dram: Enabling high-fidelity dram research by uncovering sense amplifiers with ic imaging. In ISCA. [128] Kiran Kumar Matam, Gunjae Koo, Haipeng Zha, Hung-Wei Tseng, and Murali Annavaram. 2019. GraphSSD: Graph Semantics Aware SSD. In ISCA. [129] Morten Moshagen. 2010. multiTree: A computer program for the analysis of multinomial processing tree models. Behavior Research Methods (2010). [130] Naveen Muralimanohar, Rajeev Balasubramonian, and Norman P Jouppi. 2009. CACTI 6.0: A tool to model large caches. HP laboratories (2009). [131] Onur Mutlu. 2013. Memory scaling: A systems architecture perspective. In IMW. [132] Onur Mutlu, Ataberk Olgun, Geraldo F Oliveira, and Ismail E Yuksel. 2024. Memory-Centric Computing: Recent Advances in Processing-in-DRAM. In IEDM. [133] Onur Mutlu, Ataberk Olgun, and Ismail E Yuksel. 2025. Memory-centric computing: solving computing’s memory problem. In IMW. [134] Lifeng Nai, Ramyad Hadidi, Jaewoong Sim, Hyojong Kim, Pranith Kumar, and Hyesoon Kim. 2017. GraphPIM: Enabling Instruction-Level PIM Offloading in Graph Computing Frameworks. In HPCA. [135] R. Nair, S. F. Antao, C. Bertolli, P. Bose, et al. 2015. Active Memory Cube: A Processing-in-Memory Architecture for Exascale Systems. IBM JRD (2015). [136] Hwayong Nam, Seungmin Baek, Minbok Wi, Michael Jaemin Kim, Jaehyun Park, Chihun Song, Nam Sung Kim, and Jung Ho Ahn. 2024. DRAMScope: Uncovering dram microarchitecture and characteristics by issuing memory commands. In ISCA. [137] Dimin Niu, Shuangchen Li, Yuhao Wang, Wei Han, Zhe Zhang, Yijin Guan, Tianchan Guan, Fei Sun, Fei Xue, Lide Duan, et al. 2022. 184QPS/W 64Mb/mm2 3D Logic-to-DRAM Hybrid Bonding with Process-Near-Memory Engine for Recommendation System. In ISSCC. [138] Ataberk Olgun, Juan Gomez Luna, Konstantinos Kanellopoulos, Behzad Salami, Hasan Hassan, Oguz Ergin, and Onur Mutlu. 2022. PiDRAM: A Holistic End-toEnd FPGA-Based Framework for Processing-in-DRAM. TACO (2022). [139] Ataberk Olgun, Hasan Hassan, A Giray Yağlıkçı, Yahya Can Tuğrul, Lois Orosa, Haocong Luo, Minesh Patel, Oğuz Ergin, and Onur Mutlu. 2023. DRAM Bender: An extensible and versatile FPGA-based infrastructure to easily test state-ofthe-art DRAM chips. TCAD (2023). [140] Ataberk Olgun, Minesh Patel, A Giray Yağlıkçı, Haocong Luo, Jeremie S Kim, F Nisa Bostancı, Nandita Vijaykumar, Oğuz Ergin, and Onur Mutlu. 2021. QUACTRNG: High-throughput true random number generation using quadruple row activation in commodity DRAM chips. In ISCA. [141] Geraldo F Oliveira, Juan Gómez-Luna, Saugata Ghose, Amirali Boroumand, and Onur Mutlu. 2022. Accelerating neural network inference with processing-indram: From the edge to the cloud. IEEE Micro (2022). [142] Geraldo Francisco Oliveira, Mayank Kabra, Yuxin Guo, Kangqi Chen, Abdullah Giray Yaglikci, Melina Soysal, Mohammad Sadrosadati, Joaquin Olivares Bueno, Saugata Ghose, Juan Gómez-Luna, et al. 2025. Proteus: Achieving High-Performance Processing-Using-DRAM with Dynamic Bit-Precision, Adaptive Data Representation, and Flexible Arithmetic. In ICS.
Daichi Tokuda et al.
[143] Geraldo F Oliveira, Ataberk Olgun, Abdullah Giray Yağlıkçı, F Nisa Bostancı, Juan Gómez-Luna, Saugata Ghose, and Onur Mutlu. 2024. MIMDRAM: An Endto-End Processing-Using-DRAM System for High-Throughput, Energy-Efficient and Programmer-Transparent Multiple-Instruction Multiple-Data Computing. In HPCA. [144] Geraldo F. Oliveira, Paulo C. Santos, Marco A. Z. Alves, and Luigi Carro. 2017. NIM: An HMC-Based Machine for Neuron Computation. In ARC. [145] Lois Orosa, Yaohua Wang, Mohammad Sadrosadati, Jeremie Kim, Minesh Patel, Ivan Puddu, Haocong Luo, Kaveh Razavi, Juan Gómez-Luna, Hasan Hassan, Nika Mansouri Ghiasi, Saugata Ghose, and Onur Mutlu. 2021. CODIC: A LowCost Substrate for Enabling Custom In-DRAM Functionalities and Optimizations. In ISCA. [146] Jisung Park, Roknoddin Azizi, Geraldo F Oliveira, Mohammad Sadrosadati, Rakesh Nadig, David Novo, Juan Gómez-Luna, Myung-suk Kim, and Onur Mutlu. 2022. Flash-Cosmos: In-Flash Bulk Bitwise Operations Using Inherent Computation Capability of NAND Flash Memory. In MICRO. [147] D. Patterson, T. Anderson, N. Cardwell, et al. 1997. A Case for Intelligent RAM. IEEE Micro (1997). [148] Ashutosh Pattnaik, Xulong Tang, Adwait Jog, Onur Kayiran, Asit K. Mishra, Mahmut T. Kandemir, Onur Mutlu, and Chita R. Das. 2016. Scheduling Techniques for GPU Architectures with Processing-in-Memory Capabilities. In PACT. [149] Liudmila Prokhorenkova, Gleb Gusev, Aleksandr Vorobev, Anna Veronika Dorogush, and Andrey Gulin. 2018. CatBoost: unbiased boosting with categorical features. NeurIPS (2018). [150] S. H. Pugsley, J. Jestes, H. Zhang, R. Balasubramonian, et al. 2014. NDC: Analyzing the Impact of 3D-Stacked Memory+Logic Devices on MapReduce Workloads. In ISPASS. [151] Seyyed Hossein SeyyedAghaei Rezaei, Mehdi Modarressi, Rachata Ausavarungnirun, Mohammad Sadrosadati, Onur Mutlu, and Masoud Daneshtalab. 2020. NoM: Network-on-Memory for Inter-Bank Data Transfer in Highly-Banked Memories. CAL (2020). [152] SAFARI Research Group. 2017. SoftMC — GitHub Repository. https://github. com/CMU-SAFARI/softmc. [153] SAFARI Research Group. 2022. DRAM Bender — GitHub Repository. https: //github.com/CMU-SAFARI/DRAM-Bender. [154] Naratip Santitissadeekorn, David JB Lloyd, Martin B Short, and Sylvain Delahaies. 2020. Approximate filtering of conditional intensity process for Poisson count data: Application to urban crime. Computational Statistics & Data Analysis (2020). [155] Paulo C. Santos, Geraldo F. Oliveira, João P. Lima, Marco A. Z. Alves, Luigi Carro, and Antonio C. S. Beck. 2018. Processing in 3D Memories to Speed Up Operations on Complex Data Structures. In DATE. [156] P. C. Santos, G. F. Oliveira, D. G. Tomé, M. A. Z. Alves, E. C. Almeida, and L. Carro. 2017. Operand Size Reconfiguration for Big Data Processing in Memory. In DATE. [157] Vivek Seshadri, Kevin Hsieh, Amirali Boroumand, Donghyuk Lee, Michael A Kozuch, Onur Mutlu, Phillip B Gibbons, and Todd C Mowry. 2015. Fast Bulk Bitwise AND and OR in DRAM. CAL (2015). [158] Vivek Seshadri, Yoongu Kim, Chris Fallin, Donghyuk Lee, Rachata Ausavarungnirun, Gennady Pekhimenko, Yixin Luo, Onur Mutlu, Phillip B Gibbons, Michael A Kozuch, et al. 2013. RowClone: Fast and Energy-Efficient In-DRAM Bulk Data Copy and Initialization. In MICRO. [159] Vivek Seshadri, Yoongu Kim, Chris Fallin, Donghyuk Lee, Rachata Ausavarungnirun, Gennady Pekhimenko, Yixin Luo, Onur Mutlu, Phillip B Gibbons, Michael A Kozuch, et al. 2018. RowClone: Accelerating Data Movement and Initialization Using DRAM. arXiv preprint arXiv:1805.03502 (2018). [160] Vivek Seshadri, Donghyuk Lee, Thomas Mullins, Hasan Hassan, Amirali Boroumand, Jeremie Kim, Michael A Kozuch, Onur Mutlu, Phillip B Gibbons, and Todd C Mowry. 2016. Buddy-RAM: Improving the performance and efficiency of bulk bitwise operations using DRAM. arXiv preprint arXiv:1611.09988 (2016). [161] Vivek Seshadri, Donghyuk Lee, Thomas Mullins, Hasan Hassan, Amirali Boroumand, Jeremie Kim, Michael A Kozuch, Onur Mutlu, Phillip B Gibbons, and Todd C Mowry. 2017. Ambit: In-Memory Accelerator for Bulk Bitwise Operations Using Commodity DRAM Technology. In MICRO. [162] Vivek Seshadri and Onur Mutlu. 2016. The processing using memory paradigm: In-DRAM bulk copy, initialization, bitwise AND and OR. arXiv preprint arXiv:1610.09603 (2016). [163] Vivek Seshadri and Onur Mutlu. 2017. Simple Operations in Memory to Reduce Data Movement. In Advances in Computers, Volume 106. [164] Vivek Seshadri and Onur Mutlu. 2019. In-DRAM bulk bitwise execution engine. arXiv preprint arXiv:1905.09822 (2019). [165] Ali Shafiee, Anirban Nag, Naveen Muralimanohar, Rajeev Balasubramonian, John Paul Strachan, Miao Hu, R. Stanley Williams, and Vivek Srikumar. 2016. ISAAC: A Convolutional Neural Network Accelerator with In-Situ Analog Arithmetic in Crossbars. In ISCA. [166] Mrigank Sharad, Deliang Fan, and Kaushik Roy. 2013. Ultra Low Power Associative Computing with Spin Neurons and Resistive Crossbar Memory. In
Clutch: High Performance Vector-Scalar Comparison using DRAM via Chunked Temporal Coding
DAC. [167] Hyunsung Shin, Dongyoung Kim, Eunhyeok Park, Sungho Park, Yongsik Park, and Sungjoo Yoo. 2018. McDRAM: Low Latency and Energy-Efficient Matrix Computations in DRAM. IEEE TCADICS (2018). [168] Supreeth Mysore Shivanandamurthy, Ishan G Thakkar, and Sayed Ahmad Salehi. 2021. Atria: A bit-parallel stochastic arithmetic based accelerator for in-dram cnn processing. In ISVLSI. [169] Assaf Shmuel, Oren Glickman, and Teddy Lazebnik. 2024. A Comprehensive Benchmark of Machine and Deep Learning Across Diverse Tabular Datasets. arXiv preprint arXiv:2408.14817 (2024). [170] Ravid Shwartz-Ziv and Amitai Armon. 2022. Tabular data: Deep learning is not all you need. Information Fusion (2022). [171] Gagandeep Singh, Dionysios Diamantopoulos, Christoph Hagleitner, Juan Gomez-Luna, Sander Stuijk, Onur Mutlu, and Henk Corporaal. 2020. NERO: A Near High-Bandwidth Memory Stencil Accelerator for Weather Prediction Modeling. In FPL. [172] Gagandeep Singh, Giovanni, Geraldo F. Oliveira, Stefano Corda, Sander Stuijk, Onur Mutlu, and Henk Corporaal. 2019. NAPEL: Near-Memory Computing Application Performance Prediction via Ensemble Learning. In DAC. [173] Linghao Song, Xuehai Qian, Hai Li, and Yiran Chen. 2017. PipeLayer: A Pipelined ReRAM-Based Accelerator for Deep Learning. In HPCA. [174] Linghao Song, Youwei Zhuo, Xuehai Qian, Hai Li, and Yiran Chen. 2018. GraphR: Accelerating Graph Processing Using ReRAM. In HPCA. [175] Arun Subramaniyan and Reetuparna Das. 2017. Parallel Automata Processor. In ISCA. [176] Rui Sun, Guanyu Wang, Wenyu Zhang, Li-Ta Hsu, and Washington Y Ochieng. 2020. A gradient boosting decision tree based GPS signal reception classification algorithm. Applied Soft Computing (2020). [177] Weiyi Sun, Zhaoshi Li, Shouyi Yin, Shaojun Wei, and Leibo Liu. 2021. ABCDIMM: Alleviating the Bottleneck of Communication in DIMM-Based NearMemory Processing with Inter-DIMM Broadcast. In ISCA. [178] Purab Ranjan Sutradhar, Mark Connolly, Sathwika Bavikadi, Sai Manoj Pudukotai Dinakarrao, Mark A Indovina, and Amlan Ganguly. 2020. pPIM: A programmable processor-in-memory architecture with precision-scaling for deep learning. CAL (2020). [179] Ishan G Thakkar, Supreeth M Shivanandamurthy, and Sayed Ahmad Salehi. 2023. Low-Latency, Energy-Efficient In-DRAM CNN Acceleration with Bit-Parallel Unary Computing. In Embedded Machine Learning for Cyber-Physical, IoT, and Edge Computing: Hardware Architectures. [180] Daichi Tokuda and Shinya Takamaeda-Yamazaki. 2025. DF-BETA: An FPGAbased Memory Locality Aware Decision Forest Accelerator via Bit-Level Early Termination. ACM TRETS (2025). [181] Minh SQ Truong, Eric Chen, Deanyone Su, Liting Shen, Alexander Glass, L Richard Carley, James A Bain, and Saugata Ghose. 2021. RACER: Bit-Pipelined Processing Using Resistive Memory. In MICRO. [182] Minh SQ Truong, Liting Shen, Alexander Glass, Alison Hoffmann, L Richard Carley, James A Bain, and Saugata Ghose. 2022. Adapting the RACER Architecture to Integrate Improved In-ReRAM Logic Primitives. JETCAS (2022). [183] Po-An Tsai, Changping Chen, and Daniel Sanchez. 2018. Adaptive Scheduling for Systems with Asymmetric Memory Hierarchies. In MICRO. [184] Peng Wang, Shuo Li, Guangyu Sun, Xiaoyang Wang, Yiran Chen, Hai Li, Jason Cong, Nong Xiao, and Tao Zhang. 2018. Rc-nvm: Enabling symmetric row and column memory accesses for in-memory databases. In HPCA. [185] Yaohua Wang, Lois Orosa, Xiangjun Peng, Yang Guo, Saugata Ghose, Minesh Patel, Jeremie S Kim, Juan Gómez Luna, Mohammad Sadrosadati, Nika Mansouri Ghiasi, et al. 2020. Figaro: Improving system performance via fine-grained indram data relocation and caching. In MICRO. [186] Thomas Willhalm, Nicolae Popovici, Yazan Boshmaf, Hasso Plattner, Alexander Zeier, and Jan Schaffner. 2009. SIMD-scan: ultra fast in-memory table scan using on-chip vector processing units. Proceedings of the VLDB Endowment (2009). [187] Di Wu, Jingjie Li, Ruokai Yin, Hsuan Hsiao, Younghyun Kim, and Joshua San Miguel. 2020. UGEMM: Unary computing architecture for GEMM applications. In ISCA. [188] Lingxi Wu, Rasool Sharifi, Ashish Venkat, and Kevin Skadron. 2022. DRAMCAM: General-purpose bit-serial exact pattern matching. CAL (2022). [189] S. L. Xi, O. Babarinsa, M. Athanassoulis, and S. Idreos. 2015. Beyond the Wall: Near-Data Processing for Databases. In DaMoN. [190] Xilinx, Inc. 2022. Xilinx Power Estimator User Guide. v2022.1. [191] Xin Xin, Yanan Guo, Youtao Zhang, and Jun Yang. 2021. SAM: accelerating strided memory accesses. In MICRO. [192] Xin Xin, Youtao Zhang, and Jun Yang. 2020. ELP2IM: Efficient and Low Power Bitwise Operation Processing in DRAM. In HPCA. [193] Li Y., Xu W., Chen H., Jiang J., and Li X. 2021. A Novel Framework Based on Mask R-CNN and Histogram Thresholding for Scalable Segmentation of New and Old Rural Buildings. Remote Sensing (2021). [194] Ismail Emir Yüksel, Ataberk Olgun, F Nisa Bostanci, Oğuzhan Canpolat, Geraldo F Oliveira, Mohammad Sadrosadati, A Giray Yağlikçi, Onur Mutlu, et al.
ICS ’26, July 06–09, 2026, Belfast, United Kingdom
2025. In-DRAM True Random Number Generation Using Simultaneous MultipleRow Activation: An Experimental Study of Real DRAM Chips. In ICCD. [195] Ismail Emir Yuksel, Akash Sood, Ataberk Olgun, Oğuzhan Canpolat, Haocong Luo, Nisa Bostanci, Mohammad Sadrosadati, Giray Yaglikci, and Onur Mutlu. 2025. PuDHammer: Experimental Analysis of Read Disturbance Effects of Processing-using-DRAM in Real DRAM Chips. In ISCA. [196] Ismail Emir Yuksel, Yahya Can Tugrul, F Bostanci, Abdullah Giray Yaglikci, Ataberk Olgun, Geraldo F Oliveira, Melina Soysal, Haocong Luo, Juan Gomez Luna, Mohammad Sadrosadati, et al. 2023. PULSAR: Simultaneous many-row activation for reliable and high-performance computing in off-the-shelf DRAM chips. arXiv preprint arXiv:2312.02880 (2023). [197] Ismail Emir Yüksel, Yahya Can Tuğrul, F Nisa Bostancı, Geraldo F Oliveira, A Giray Yağlıkçı, Ataberk Olgun, Melina Soysal, Haocong Luo, Juan GómezLuna, Mohammad Sadrosadati, et al. 2024. Simultaneous Many-Row Activation in Off-the-Shelf DRAM Chips: Experimental Characterization and Analysis. In DSN. [198] İsmail Emir Yüksel, Yahya Can Tuğrul, Ataberk Olgun, F Nisa Bostancı, A Giray Yağlıkçı, Geraldo F Oliveira, Haocong Luo, Juan Gómez-Luna, Mohammad Sadrosadati, and Onur Mutlu. 2024. Functionally-Complete Boolean Logic in Real DRAM Chips: Experimental Characterization and Analysis. In HPCA. [199] Yue Zha and Jing Li. 2020. Hyper-AP: Enhancing Associative Processing Through A Full-Stack Optimization. In ISCA. [200] Dongping Zhang, Nuwan Jayasena, Alexander Lyashevsky, Joseph L Greathouse, Lifan Xu, and Michael Ignatowski. 2014. TOP-PIM: Throughput-oriented programmable processing in memory. In HPDC. [201] Mingxing Zhang, Youwei Zhuo, Chao Wang, Mingyu Gao, Yongwei Wu, Kang Chen, Christos Kozyrakis, and Xuehai Qian. 2018. GraphP: Reducing Communication for PIM-Based Graph Processing with Efficient Data Partition. In HPCA. [202] Tianning Zhang, Weihuan He, Hui Zheng, Yaoping Cui, Hongquan Song, and Shenglei Fu. 2021. Satellite-based ground PM2. 5 estimation using a gradient boosting decision tree. Chemosphere (2021). [203] Wanhu Zhang, Junqi Yu, Anjun Zhao, and Xinwei Zhou. 2021. Predictive model of cooling load for ice storage air-conditioning system by using GBDT. Energy reports (2021). [204] YD Zhang, L Liao, Q Yu, WG Ma, and KH Li. 2021. Using the gradient boosting decision tree (GBDT) algorithm for a train delay prediction model considering the delay propagation feature. Advances in Production Engineering & Management (2021). [205] Dong Zhong, Qinglei Cao, George Bosilca, and Jack Dongarra. 2022. Using long vector extensions for MPI reductions. Parallel Comput. (2022). [206] Ranyang Zhou, Arman Roohi, Durga Misra, and Shaahin Angizi. 2022. ReDLUT: Reconfigurable in-DRAM LUTs enabling massive parallel computation. In ICCAD. [207] Ranyang Zhou, Sepehr Tabrizchi, Arman Roohi, and Shaahin Angizi. 2022. Lt-pim: An lut-based processing-in-dram architecture with rowhammer selftracking. CAL (2022). [208] Q. Zhu, T. Graf, H. E. Sumbul, L. Pileggi, and F. Franchetti. 2013. Accelerating Sparse Matrix-Matrix Multiplication with 3D-Stacked Logic-in-Memory Hardware. In HPEC. [209] Youwei Zhuo, Chao Wang, Mingxing Zhang, Rui Wang, Dimin Niu, Yanzhi Wang, and Xuehai Qian. 2019. GraphQ: Scalable PIM-Based Graph Processing. In MICRO.