PaperlayerView exact revision on arXiv

Source-linked AI summary

A Modern Primer on Processing in Memory

Onur Mutlu, Saugata Ghose, Juan Gómez-Luna, Rachata Ausavarungnirun, Mohammad Sadrosadati, Geraldo F. Oliveira

arXiv:2012.03112v5cs.ARcs.DC

TL;DR

Modern data-intensive workloads and memory-scaling limits make processor-centric data movement costly in performance and energy. The paper surveys processing-in-memory through processing-using-memory and processing-near-memory, along with cross-layer adoption challenges. It concludes that real PIM prototypes are emerging, while a shift toward data-centric computing remains central to practical adoption.

  • Problem

    Growing data working sets and costly processor–memory data movement make main memory a significant performance and energy bottleneck in modern systems.

  • Method

    The paper surveys PIM designs that compute in memory circuitry or near memory through processing-using-memory and processing-near-memory.

  • Results

    Real PIM hardware is emerging through processing-using-memory and processing-near-memory prototypes and solutions.

  • Takeaways & Limitations

    A data-centric design paradigm performs computation where data resides or is generated, with minimal data movement.

  • Takeaways & Limitations

    PIM adoption requires addressing system security, reliability, endurance, and error-correction challenges.

Abstract

from arXiv · show

This paper discusses recent research that aims to enable computation close to data, an approach we broadly call processing-in-memory (PIM). PIM places computation mechanisms in or near where the data is stored (i.e., inside memory chips or modules, in the logic layer of 3D-stacked memory, in the memory controllers, in storage devices or chips), so that data movement between the computation units and memory/storage units is reduced or eliminated. While the general idea of PIM is not new, we discuss motivating trends in applications as well as memory circuits and technology that greatly exacerbate the need for enabling it in modern computing systems. We examine at least two promising new approaches to designing PIM systems to accelerate important data-intensive applications: (1) processing-using-memory, which exploits fundamental analog operational principles of memory chips to perform massively-parallel operations in-situ in memory, (2) processing-near-memory, which exploits different logic and memory integration technologies (e.g., 3D-stacked memory technology) to place computation logic close to memory circuitry, and thereby enable high-bandwidth, low-energy, and low-latency access to data. In both approaches, we describe and tackle relevant cross-layer research, design, and adoption challenges in devices, architecture, systems, compilers, programming models, and applications. Our focus is on the development of PIM designs that can be adopted in real computing platforms at low cost. We conclude by discussing work on solving key challenges to the practical adoption of PIM. We believe that the shift from a processor-centric to a memory-centric mindset (and infrastructure) remains the largest adoption challenge for PIM, which, once overcome, can unleash a fundamentally energy-efficient, high-performance, and sustainable new way of designing, using, and programming computing systems.

1. Introduction

Modern workloads are making main-memory data movement an increasingly severe bottleneck, while memory scaling and integration advances motivate computation closer to stored data. The paper surveys two PIM approaches—processing-using-memory and processing-near-memory—and the practical challenges to adopting them.

  • Growing application working sets and faster data-analysis demands make main memory an increasingly significant bottleneck across computing systems and domains.
  • Processor-centric systems incur high energy and latency costs by moving data from memory across the memory channel into caches and registers before computation.
  • PIM places computation in or near storage locations to reduce or eliminate movement between computation units and memory or storage.
  • Processing-using-memory: Processing-using-memory exploits analog memory-circuit operations for simple, massively parallel in-situ computation with potentially large gains and minimal circuit changes.
  • Processing-near-memory: Processing-near-memory adds computation to controllers, memory chips, modules, or 3D-stacked memory logic layers for more general-purpose and flexible PIM.
  • Adoption challenges: Practical adoption requires programming, runtime, coherence, virtual-memory, data-structure, benchmarking, and simulation support for host–PIM systems.

2. Major Trends Affecting Main Memory

DRAM scaling increasingly struggles to provide capacity, bandwidth, latency, energy efficiency, cost, and reliability together. These trends create performance, energy, robustness, security, and safety pressures across modern computing systems.

  • Capacity, bandwidth, and latency: DRAM capacity, bandwidth, and latency are difficult to scale simultaneously, worsening memory bottlenecks as workload demands grow.
  • Capacity, bandwidth, and latency: More than 1 million times of DRAM storage-capacity improvement over five decades contrasts with approximately 8 times lower latency.
  • Reliability: DRAM scaling to smaller nodes reduces cell reliability by increasing leakage, electrical-noise sensitivity, and vulnerability to disturbance.
  • Reliability: Higher-density DRAM chips correlate with higher server failure rates, linking newer technology nodes with increased reliability concerns.
  • Reliability and security: RowHammer and RowPress can predictably induce bit flips in modern DRAM, undermining physical memory isolation and creating security and safety risks.
  • Energy: Main-memory energy consumption rises with increasing capacity, bandwidth, parallelism, complexity, off-chip placement, and scaling-related reliability mechanisms.

3. The Need for Intelligent Memory Controllers to Enhance Memory Technology Scaling

Intelligent memory controllers can mitigate DRAM scaling challenges by exploiting variation in retention, latency, reliability, temperature, and access behavior. However, sophisticated DRAM-controller intelligence is harder to implement than in flash controllers because DRAM access is faster and has higher bandwidth.

  • Intelligent memory controllers can mitigate RowHammer and RowPress through programmable mechanisms that manage memory robustness.The paper identifies intelligent controllers as a promising approach for overcoming multiple DRAM scaling challenges.
  • More than 75% of DRAM refreshes can be eliminated by profiling per-row retention and adjusting refresh rates or decommissioning weak rows.Conventional refresh uses worst-case retention assumptions, causing unnecessary energy and performance costs.
  • 33% lower read latency and 55% lower write latency are achieved at 55 °C versus 85 °C across 115 real DRAM modules.Temperature-aware controller policies exploit the greater charge available in cooler DRAM cells.
  • 57% access-latency reductions are possible by profiling manufacturing variation and using cells that reliably operate faster than specification timings.The approach exploits heterogeneity among DRAM cells rather than applying worst-case timings universally.
  • Subarray-level parallelism, refresh-access parallelization, and charge-aware timing can reduce bank conflicts, refresh impact, and access latency.These techniques require coordinated changes in DRAM organization and controller behavior.
  • DRAM-controller intelligence remains more challenging than flash-controller intelligence because modern DRAM has much lower access latency and much higher access bandwidth.This difference constrains the practical complexity and response time of intelligent DRAM-controller designs.

4. Perils of Processor-Centric Design

Processor-centric systems move data between computation units and memory through costly buses, caches, and interconnects. Because data movement can dominate computation energy and hinder irregular workloads, the paper argues for a data-centric architectural shift.

  • Processor-centric execution requires data to travel from DRAM through the memory controller and bus into caches and registers before computation.The resulting separation between computation and storage creates repeated movement between system components.
  • More than 62% of energy in four mobile workloads and more than 90% in large commercial edge neural-network models is spent on memory access and data movement.These measurements illustrate the system-wide energy imbalance created by processor-only computation.
  • Narrow off-chip buses limit bandwidth and parallel requests, making higher concurrency and lower latency increasingly expensive.Pin-count and cost constraints restrict the memory channel’s ability to hide long memory latency.
  • The paper identifies a processor-centric vicious cycle in which data movement motivates complex latency-hiding mechanisms that add further energy and latency overheads.It proposes breaking this cycle by changing toward a data-centric execution paradigm.
  • Caches are often ineffective for random, strided, and some streaming accesses because fetched data is not reused by the processor.PageRank exemplifies a workload with frequent random accesses and little computation.
  • A main-memory access consumes two to three orders of magnitude more energy than an addition, with one cited example reporting approximately 115× higher energy.Communication and data movement therefore dominate computation costs in energy terms.

5. Processing-in-Memory (PIM): Technology Enablers and Two Approaches

Processing-in-memory equips the memory subsystem to compute where data resides, addressing the costs of processor-centric data movement. The paper presents 3D-stacked memory and byte-addressable NVM as enablers, and distinguishes processing-using-memory from processing-near-memory.

  • Processing-in-memory places computation in or near storage so that data movement between computation and memory is reduced or eliminated.PIM is presented as part of a broader data-centric approach that enables computation across system components.
  • PUM reduces movement and exploits internal array bandwidth, whereas PNM offers more general logic but can be bottlenecked by internal or external memory buses.The two approaches therefore present different tradeoffs and are both important to PIM’s potential.
  • 3D-stacked memories use TSV-connected layers and can provide a logic layer with space for PIM functionality near DRAM arrays.The logic layer can interact with both the processor and DRAM cells, while TSVs provide high internal bandwidth.
  • Byte-addressable resistive NVMs offer potentially higher density, near-DRAM latency and energy, nonvolatility, and opportunities to redesign memory subsystems for PIM.The paper discusses PCM, MRAM, RRAM or memristors, and FeRAM as emerging NVM types.
  • Processing-using-memory exploits memory-cell and array operating principles to perform computation in situ, usually with small architectural changes.Examples include bulk copy or initialization, Boolean operations, and simple arithmetic across SRAM, DRAM, NVM, FeRAM, and NAND flash.
  • Processing-near-memory integrates accelerators, processing cores, functional units, or reconfigurable logic close to memory arrays or in memory controllers.PNM supports more general computation but still moves data between nearby computation logic and memory arrays.

6. Processing-Using-Memory (PUM)

Processing-using-memory exploits memory circuits and internal parallelism to perform data movement and computation in place, reducing bottlenecks and enabling substantial performance and energy gains. The section presents RowClone, Ambit, SIMDRAM, MIMDRAM, and pLUTo as progressively broader or more flexible PUM mechanisms, while highlighting programmability and granularity challenges.

  • Existing DRAM substrates: Some PUM operations can run on unmodified commercial DRAM by violating recommended timing parameters, including copy, initialization, Boolean operations, random-number generation, and physical unclonable functions.ComputeDRAM demonstrates such behavior for RowClone-like copying and Ambit-like bitwise operations in tested off-the-shelf chips.
  • RowClone: RowClone accelerates bulk copy and initialization, reducing 4kB page-copy latency by 11.6× and energy by 74.4× with 0.01% DRAM chip area overhead.Across six copy- and initialization-intensive benchmarks, performance improves 4%–66% and DRAM energy consumption falls 15%–69%.
  • MIMDRAM: PUD executes very-wide SIMD operations inside DRAM, but rigid row granularity can cause underutilization, restrict operations, and create a programmability barrier.MIMDRAM addresses these issues through hardware/software co-design that allocates and controls only the resources required for each operation, adding 1.11% DRAM-chip and 0.6% CPU-die area cost.

D-RaNGe Key Idea

The paper presents memory-centric mechanisms that generate randomness, unique keys, and security operations directly in memory while reducing data movement. It also surveys in-memory acceleration techniques for data-intensive workloads, alongside reliability, programmability, and integration challenges.

  • DRAM cell latency failure probabilities arise from manufacturing variation and can be observed to extract random values.
  • D-RaNGe generates true random numbers in 282 LPDDR4 devices, passes all NIST statistical tests, and achieves over two orders of magnitude higher throughput than the state-of-the-art DRAM-based TRNG.
  • The CODIC-based PUF achieves 1.8× higher throughput than the best state-of-the-art DRAM PUF, with similar temperature resilience and more repeatable responses.
  • CODIC overwrites DRAM at power-on to counter cold boot attacks, with no runtime latency or power overhead and lower power-on latency and energy than LISA and RowClone.It reports 2.0× lower latency and 1.7× lower energy during DRAM power-on than those mechanisms.
  • Emerging NVM and MRAM designs perform in-situ operations to reduce data movement, including MVM, bitwise computation, genome-analysis acceleration, and sDTW execution.MATSA improves performance by 7.35×/6.15×/6.31× and energy efficiency by 11.29×/4.21×/2.65× over CPU, GPU, and processing-near-memory platforms, respectively.
  • Flash-Cosmos improves bulk bitwise processing through multi-operand sensing and enhanced SLC-mode programming, achieving completely reliable computation on the tested NAND chips.Processing-using-flash remains limited by the need for more complex computations, programmability, and system-integration work.

7. Processing-Near-Memory (PNM)

Processing-near-memory (PNM) places computation close to memory to address data-movement bottlenecks across graph processing, databases, time-series analysis, consumer workloads, neural networks, and genome analysis. The surveyed systems use heterogeneous, workload-tailored hardware and report substantial performance and energy benefits, while exposing trade-offs in offloading granularity, complexity, cost, and adoption requirements.

  • Design Trade-offs and Adoption: PNM offloading granularity ranges from application-level to function-level and instruction-level, creating trade-offs among performance gains, complexity, and cost.The section also identifies programming models, runtime scheduling, coherence, and virtual-memory support as practical adoption challenges.
  • PNM in DRAM-Based Main Memory: PNM exploits high-bandwidth memory integration to reduce costly data movement, especially for workloads with irregular accesses and low computation per fetched item.The section highlights 3D-stacked DRAM and custom logic as a basis for placing computation near data.
  • Tesseract: Graph Processing: 13.8× average system performance improvement and 87% average energy reduction were achieved by Tesseract across five large-graph processing workloads.Tesseract is a programmable PNM accelerator that exploits computation capability in the logic layer of 3D-stacked memory.
  • Polynesia: HTAP Databases: Polynesia improved transactional throughput by 1.70× on average, analytical throughput by 3.74×, and energy consumption by 48% versus prior HTAP systems.Its design partitions resources into isolated transactional and analytical processing islands, each with workload-specific data replicas, execution engines, and hardware.
  • NATSA: Time-Series Analysis: NATSA improved matrix-profile performance by 9.9× on average and reduced energy by 19.4× on average over a state-of-the-art multicore implementation.It performs complete time-series analysis near 3D-stacked HBM using specialized floating-point processing units.
  • Mobile Consumer Workloads and Edge Neural Networks: Mensa-G reduced inference energy by 66.0%, while improving energy efficiency by 3.0× and throughput by 3.1× across 24 Google edge neural-network models.Mensa-G executes neural-network layers heterogeneously across small processor-centric and memory-centric accelerators tailored to layer families.

8. Enabling the Adoption of PIM

PIM adoption requires programming, compiler, runtime, and architectural mechanisms that reduce programmer burden while accounting for offloading trade-offs. The paper highlights high-level frameworks and automated optimization as promising support, but identifies programming interfaces and compiler/library support as open challenges.

  • Adoption challenges: PIM adoption depends on addressing system and programming challenges without placing a heavy burden on most programmers.These challenges include compiler support, runtime mechanisms, coherence, and virtual memory.
  • Offloading granularity: Offloading granularity affects PIM performance, energy, system complexity, and programming and code-generation complexity.Instruction-level approaches can ease adoption, whereas larger tasks may require methods that limit CPU–PIM information exchange.
  • Programming support: High-level frameworks such as SimplePIM and DaPPA abstract hardware characteristics to simplify PIM programming.SimplePIM uses management, communication, and processing interfaces, while DaPPA automates data distribution, output gathering, memory management, and DPU parallelization.
  • Programming support: SimplePIM enables map, reduce, and zip iterators on PIM arrays for workloads ranging from vector addition to machine-learning model training.Its interfaces draw on abstractions and communication patterns used by distributed programming frameworks.
  • Programming support: 5.43× fewer lines of code are required by SimplePIM than by hand-optimized UPMEM SDK histogram code.The figure caption also states that the SimplePIM version is easier to read and understand.
  • Programming support: DaPPA improves end-to-end performance by 2.1× on average across six hand-optimized PrIM benchmarks and reduces programming complexity by 94.4% on average.The performance gains are attributed to data-transfer parallelization and improved workload partitioning between CPU and PIM cores.
  • Future work: Effective programming interfaces and compiler/library support remain central open research and development issues despite recent progress in PIM tools and frameworks.Open questions include mapping high-level abstractions onto diverse PIM hardware while minimizing data movement and synchronization overhead.

8.2. PIM Runtime: Scheduling and Data Mapping

PIM runtime systems must identify suitable code, decide when to offload it, map data effectively, and share PIM resources. The paper surveys compiler, profiling, scheduling, and mapping approaches while emphasizing that robust runtime support across conditions remains unfinished.

  • Runtime responsibilities: PIM runtimes must determine what code to execute near data, when to offload it, how to map data, and how to share PIM mechanisms.These decisions affect whether PIM execution is viable and effective across memory granularities and concurrent users.
  • Offloading candidates: Manually identifying PIM offloading candidates requires substantial programmer effort and detailed knowledge of CPU–PIM hardware trade-offs.The paper develops a systematic toolflow to reduce this burden for custom PIM logic.
  • Offloading candidates: Candidate selection can use hardware-aware criteria such as energy intensity, data-movement energy, and memory intensity.Illustrative thresholds include more than 30% of workload energy, more than 30% of data-movement energy, and MPKI greater than 10.
  • Scheduling: Runtime and compiler mechanisms can identify and dynamically schedule PIM offloading candidates using profiling, locality, and platform-specific analysis.Examples include ALP’s online cache-miss profiling and GPU mechanisms combining compile-time and runtime decisions.
  • Data mapping: Effective data and code mapping depends on the application, system configuration, and PIM type.For PUM operations on two source arrays, practical mapping must guarantee their alignment within the same DRAM subarray.
  • Future work: Developing data/code mapping and scheduling methods for diverse applications and core–memory configurations remains necessary.The paper describes existing approaches but states that robust runtime systems effective under many conditions still require research.

8.3. Memory Coherence

Memory coherence is difficult in PIM because PIM logic and processor cores may concurrently access shared data, while fine-grained coherence can consume the communication benefits PIM seeks. CoNDA addresses this tension through speculative, batched coherence checking but does not close the broader research problem.

  • Coherence challenge: PIM coherence must coordinate updates between PIM logic and processor cores without negating PIM’s bandwidth and latency benefits.Fine-grained MESI coherence can force many messages across the narrow processor–memory bus.
  • CoNDA: CoNDA maintains CPU–PIM cache coherence without sending coherence requests for every memory access.It uses speculative permissions, compressed coherence signatures, and CPU-side validation of possible violations.
  • CoNDA: CoNDA’s performance and energy are within 10.4% and 4.4%, respectively, of a zero-latency, zero-energy coherence system.These figures describe its approach to near-ideal coherence behavior.
  • Future work: Further coherence solutions are needed for all workloads, offloading granularities, and PIM approaches.The paper specifically points to broader interfaces supporting coherence across devices and memory.

8.4. Virtual Memory Support

Unified virtual memory is important for flexible host–PIM programming but requires distributed translation and protection mechanisms. CPU-dependent translation can erase PIM gains, while IMPICA demonstrates an in-memory approach for pointer chasing rather than a general solution.

  • Virtual memory challenge: A unified host–PIM virtual address space supports flexible programming through shared address semantics but requires distributed translation and access protection.All system components must translate addresses while guaranteeing protection for every memory access.
  • Translation overhead: Relying on CPU-side address translation can nullify in-memory and near-memory performance gains through long-latency requests and additional memory traffic.Page-table walks may issue multiple requests to main memory over the memory channels.
  • Translation mechanisms: Duplicating TLBs and moving page walkers into PIM logic introduces coherence, storage, complexity, and cross-architecture compatibility challenges.These constraints make a general in-memory translation mechanism difficult or expensive.
  • IMPICA: IMPICA traverses virtual-memory pointer chains within 3D-stacked DRAM without CPU virtual-to-physical translation lookups.It exploits the high internal bandwidth of 3D-stacked memory for pointer chasing.
  • IMPICA: IMPICA reduces overall system energy consumption by 41%, 23%, and 10% for three commonly used data structures, and by 6% for DBx1000.These reported reductions apply to the pointer-chasing workloads evaluated by the paper.
  • Scope boundary: Efficient PIM virtual-to-physical translation and access protection remain challenging for general applications, especially those accessing large virtual-memory regions.IMPICA addresses pointer chasing, but the paper identifies broader support as an open challenge.

8.5. Data Structures for PIM

PIM requires data structures tailored to its execution model, especially for many-core, pointer-chasing, contended, and graph workloads. SISA combines in-DRAM bulk bitwise processing with near-memory logic for different graph data representations.

  • Concurrent data structures tailored to PIM are necessary to support high-performance, scalable many-core applications.
  • Pointer-chasing and contended structures require careful analysis and partitioning to exploit 3D-stacked memory bandwidth and latency.
  • SISA uses in-DRAM bulk bitwise processing for high-degree-vertex bitvectors and near-memory logic for low-degree-vertex integer arrays.
  • SISA-enhanced algorithms outperform hand-tuned baselines, including more than 10× speedup over Bron-Kerbosch for maximal-clique listing.
  • Future work should extend PIM-aware designs to hash tables, search trees, priority queues, and irregular or sparse data structures.

8.6. Benchmarks and Simulation Infrastructures

PIM adoption depends on representative benchmarks, systematic kernel identification, and accurate evaluation infrastructure. DAMOV supplies a methodology and open benchmark suite, while NAPEL applies machine learning to estimate PNM performance and energy.

  • Accurate PIM assessment requires real-world memory-intensive applications, a methodology for identifying offloading candidates, and reliable simulation infrastructures.
  • DAMOV methodology: DAMOV identifies memory-bound functions, clusters locality independently of architecture, and classifies bottlenecks through scalability analysis across CPU and PNM configurations.
  • DAMOV methodology: DAMOV analyzed 345 applications and 77K functions, then examined 144 memory-bound functions from 74 applications to identify six bottleneck classes.
  • Benchmarks: The resulting 144 functions form the open-source DAMOV Benchmark Suite for studying PIM architecture research questions.
  • Adoption infrastructure: DAMOV motivates future profilers, compilers, and runtime systems that identify kernels, generate optimized PIM code, and coordinate offloading.
  • Prediction: NAPEL uses ensemble learning with microarchitecture parameters and application characteristics to predict PNM performance, energy, and offloading suitability for unseen applications.

8.7. Real PIM Hardware Systems and Prototypes

Real PIM prototypes are emerging across UPMEM and industry systems, enabling evaluation on actual workloads and hardware. Results show strong benefits for workloads aligned with PIM’s bandwidth, simplicity, and communication characteristics, while hardware limitations remain important.

  • Real PIM hardware and prototypes enable evaluations on real workloads and accelerate software, algorithm, and adoption research.
  • Processing-using-memory: COTS DRAM supports processing operations at success rates above 94%, demonstrating computation capability in chips not designed for that purpose.
  • UPMEM systems: UPMEM characterization and the 16-workload PrIM suite provide workload insights, programming recommendations, and hardware-design guidance.
  • UPMEM systems: UPMEM favors processor-centric memory-bound workloads with simple operations and little or no communication across DPUs.
  • UPMEM applications: SpMV reaches 51.7% of peak performance on a 2528-core UPMEM system, compared with less than 1% on processor-centric CPU and GPU systems.
  • UPMEM applications: PIM application studies span sequence alignment, machine-learning training, graph neural networks, homomorphic operations, and reinforcement learning.
  • UPMEM applications: The first-generation UPMEM system accelerates homomorphic addition by 50–100× over a CPU and 2–15× over a GPU, but trails GPUs on homomorphic multiplication by 10–15×.
  • Industry prototypes: Industry systems include SK Hynix AiM and CXL-PNM solutions that place processing engines near or within memory-related components.

8.8. Security Considerations

PIM changes the security and reliability surface of memory-centric systems. Direct memory access can enable high-throughput attacks, while isolation, access control, ECC, and other robustness mechanisms remain necessary.

  • Security requirements: PIM introduces security requirements for securely executing offloaded code and preventing information leakage between concurrently executing applications.
  • Security requirements: PIM computation units need process isolation and secure access control for both data storage and computation resources.
  • Reliability: PIM may exacerbate RowHammer, while NVM endurance limits can constrain reliability and effectiveness of processing-using-memory approaches.
  • Reliability: Future PIM systems likely need in-memory ECC and other robustness techniques to preserve data reliability under computation and technology-scaling noise.
  • Attack surface: IMPACT exploits direct main-memory access, shared DRAM row buffers, and PIM parallelism to create high-throughput covert and side channels.
  • Potential benefits: PIM can potentially reduce exposure by keeping data and computation within one chip and eliminating processor–memory data movement.

9. Other Resources on PIM

PIM is being disseminated through courses, talks, interviews, and open-source infrastructures that support education, experimentation, and further innovation.

  • PIM is increasingly covered in advanced computer architecture courses and dedicated PIM courses emphasizing research and practical aspects.
  • Special sessions, talks, and interviews provide additional forums for sharing progress in PIM and memory-centric computing.
  • Open-source simulators, prototyping platforms, benchmark suites, and application implementations can disseminate PIM knowledge and foster further developments.

10. Conclusion and Future Outlook

The paper frames PIM as a data-centric response to processor-centric data-movement costs, combining computation with memory or storage. It presents PUM and PNM as promising approaches while emphasizing that adoption still depends on solving substantial programming, runtime, infrastructure, and mindset challenges.

  • Processor-centric systems create major performance and energy bottlenecks because computation occurs away from data and requires extensive movement across the memory hierarchy.
  • PIM advances a data-centric paradigm by enabling computation where data resides or is generated, thereby minimizing data movement.
  • Processing-using-memory: Processing-using-memory exploits memory circuitry for operations such as copying, initialization, bulk-bitwise processing, reorganization, and random-number generation.
  • Processing-near-memory: Processing-near-memory places computation beside memory banks, within modules or controllers, or in 3D-stacked logic layers to improve performance and reduce energy.
  • Widespread PIM adoption still requires easy-to-use programming models, compilers, libraries, and runtime support that abstract architectural details.
  • A broader data-centric architecture could produce orders-of-magnitude energy and performance improvements and potentially enable new applications and platforms.
  • The largest adoption challenge is shifting the mindset and infrastructure from treating memory as storage alone to treating it as a combined computation-and-storage substrate.
Loading 2012.03112v5…