Pith. sign in

REVIEW 4 major objections 8 minor 78 references

PIMID: A Full-System Simulator with Intricacy and Diversity for Processing-in-Memory

T0 review · 4 major / 8 minor · reviewed 2026-07-31 · grok-4.5

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read One full-system simulator shows memory technology alone can move PIM runtime by more than 10×, and the best host memory is not the best PIM substrate.

desk verdict Solid infrastructure paper with a real dual-execution-model dataset; the 19× technology headline is partly an artifact of the DQ-reuse abstraction, which the authors flag but still lead with. read the letter →

arxiv 2607.24196 v1 pith:XKW2CTFD submitted 2026-07-27 cs.AR

Yuan He , Masaaki Kondo , Galen M. Shipman , Jered B. Dominguez-Trujillo , Shigeki Tomishima , Kazi Asifuzzaman This is my paper
classification cs.AR
keywords processing-in-memoryfull-systemsimulationmemorysystemssharedmessagepassinghost-deviceco-simulationarchitecturalexplorationin-memorynetwork
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Real processing-in-memory chips are still rare, so architects explore designs in simulation. Existing simulators each cover only a slice of that space: one memory type, one place to put compute, one programming style, and often no host system at all. This paper introduces PIMID, a single tool that runs the same annotated OpenMP and MPI kernels across eleven memory technologies, places processing elements from subarrays up to logic dies, scales their count and core fidelity, and co-simulates host and device in one process with explicit boundary costs. The resulting dual-execution-model dataset shows that memory technology alone can change runtime by more than an order of magnitude, that regular kernels scale superlinearly as in-memory bandwidth grows with compute, that graph traversal under message-passing hits a collective-communication wall that shared memory avoids, and that full-system offload saves energy only on HBM3 while a 16-core host still wins every end-to-end time comparison. The point is that incomplete simulators hide these asymmetries; a tool that spans the design space end to end makes them visible and comparable.

What carries the argument

PIMID: a single-process, execution- and trace-driven host–device co-simulator that runs both shared-memory (OpenMP) and message-passing (MPI) models on one device model, prices the in-memory network per technology from measured congestion, and places PEs from subarrays to logic dies across eleven memory technologies.

What would settle it

Build or measure a real multi-PE PIM device whose internal interconnect bandwidth or topology differs sharply from reusing the ordinary data bus; if PE-count superlinearity, the mid-hierarchy placement valley, or the message-passing BFS collective wall disappear or reverse under that hardware, the paper’s ranked design conclusions fail.

Watch

Extended reading notes

Core claim

Across a complete dual-execution-model dataset, memory technology alone moves PIM execution time by more than an order of magnitude (up to about 19× on histogram) and the best host main memory is not the best PIM substrate; regular kernels scale superlinearly with PE count because in-memory bandwidth co-scales with compute; graph traversal under message-passing hits a collective-communication wall absent under shared memory; and at full-system scope shared-memory offload saves energy only on HBM3 while a 16-core host keeps every end-to-end time win.

Load-bearing premise

In-memory communication is priced as bandwidth-limited reuse of each technology’s ordinary data bus and a modeled on-chip fabric, not as a dedicated PIM interconnect or the exact internal wiring of real chips.

Editorial extensions

If this is right

  • Architects should not pick a PIM substrate by host-main-memory ranking: low-latency bank-rich DRAM can beat premium high-bandwidth parts at bank-level PIM.
  • Message-passing graph codes on memory-resident PEs need communication-reducing partitions or stronger in-memory interconnects; shared-memory codes do not hit the same wall.
  • Adding PEs can be superlinearly worthwhile on regular bandwidth-bound kernels because compute and local bandwidth grow together.
  • Full-system energy wins from modest PIM offload appear only on cheap-array bandwidth-class memory (here HBM3); device-only tools will mis-rank offloads that hide host setup and boundary cost.
  • New engines and memory models can be swapped in through YAML plugins without rebuilding the whole stack as PIM hardware evolves.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If commercial PIM products keep shipping on GDDR-class substrates, the paper’s channel-starvation result implies those products may underperform bank-level PIM relative to mainstream DDR5-class parts on the same kernels.
  • The collective wall on BFS suggests MPI-style PIM runtimes will need first-class support for in-memory reductions and neighborhood exchange, not just point-to-point mailboxes.
  • Because host baselines stay faster end-to-end in every cell here, near-term PIM value may be energy and socket-offload under light host parallelism rather than raw wall-time replacement of a busy multi-core CPU.
  • A natural next measurement is whether dedicated PIM links (as in emerging inter-DIMM and PIM-network proposals) flatten the message-passing BFS blowup the tool quantifies.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 8 minor

Summary. The manuscript presents PIMID, an execution- and trace-driven full-system simulator for processing-in-memory that composes QEMU/ZSim (compute), Ramulator 2.0/CACTI/NVSim (eleven memory technologies), GARNET (in-memory network), and McPAT (power) behind YAML plugin interfaces. Its claimed advances over prior tools (MultiPIM, uPIMulator, PIMSim, etc.) are: (i) simultaneous support for shared-memory (OpenMP) and message-passing (MPI) execution models over one device model; (ii) PE placement from subarray to logic die with per-technology GARNET fabrics; (iii) single-process host–device co-simulation with explicit boundary charges and an end-to-end time/energy breakdown. The evaluation sweeps four device-side axes and one co-simulation study, reporting: memory technology alone moves execution time by >10× (up to 19.1× on histogram); the best host main memory is not the best PIM substrate; regular kernels scale superlinearly with PE count; message-passing BFS hits a collective-communication wall (24.6M → 2.42B cycles from 16 to 64 ranks); and full-system offload saves energy only on HBM3 while a 16-core host keeps all end-to-end time wins.

Significance. If the results hold, this is a useful infrastructure contribution: to my knowledge no prior open tool combines eleven memory technologies, both execution models, subarray-to-logic-die placement, and host–device co-simulation in one framework, and the dual-execution-model comparison under matched conditions is genuinely new. The paper ships concrete reproducibility assets (public GitHub source plus a container image, Table I), a documented defect ledger, hardware-anchored idle latencies (DDR5 ~110 ns, HBM2 ~130 ns, HBM3 ~235 ns from published measurements), JEDEC/datasheet-derived energy presets rather than tuned constants, an explicitly scoped co-simulation parity invariant (within 0.1% on regular shared-memory kernels), and an unusually candid limitations section (§V-G) that discloses the cross-host sensitivity (2–7%), the frozen-sample pricing, and the DQ-reuse abstraction boundary. The findings (technology-substrate inversion, placement valley, MPI collective wall on PIM) are stated as falsifiable, quantified claims that other tools and future silicon can check. The main risk is that the two most quotable headline numbers are co-produced by one modeling decision, as detailed in

major comments (4)
  1. [§IV-E, §V-B, Abstract] §IV-E and §V-B (Figs. 5): the headline result — GDDR6 at 14.2× and LPDDR5 at 19.1× DDR5 on histogram, and the derived abstract claim that 'the best host main memory is not the best PIM substrate' — follows mechanically from modeling intra-memory PE data exchange as bandwidth-limited reuse of the per-technology DQ datapath. Under that abstraction, a channel-centric part with few wide channels serializes 16 bank-level PEs onto the shared external bus by construction; the penalty is a property of the assumed interconnect, not of measured PIM behavior. The commercial silicon the paper itself cites, GDDR6-AiM [75], places a processing unit per bank(-pair) with dedicated internal datapaths precisely so bank-level compute does not contend on the channel DQ — i.e., real channel-centric PIM is architected to avoid exactly the starvation the model imposes. §V-G does disclose this boundary honestly
  2. [§V-G] Validation is almost entirely internal. The anchors offered are: host-attached idle latencies for three DRAM parts, datasheet-methodology energy presets, and the co-simulation/standalone parity invariant (which checks self-consistency, not accuracy). For a simulator paper whose findings will guide design choices, at least one external anchor against real PIM hardware is important: the UPMEM DPU has published characterization (PrIM [16], and uPIMulator [18] reports matching it), and HBM-PIM [15]/GDDR6-AiM [75] publish performance figures for kernels in the same class as GEMV. The paper states FPGA cross-validation is future work, but a software-only cross-check against one commercial DPU's measured kernel times appears within current scope and would substantially de-risk the tool's central promise. At minimum, please state explicitly which modeled quantities (per-bank PE throughput, in-me
  3. [§V-D, §V-G] §V-D (Fig. 7): the message-passing BFS 'collective wall' (24.6M cycles at 16 ranks → 278.6M at 32 → 2.42B at 64) is a ~100× blowup attributed to 'super-quadratic' growth of per-level frontier-exchange collectives, priced from an epoch-frozen GARNET congestion sample (§V-A, §V-G). Two things are missing for a claim of this magnitude: (1) a mechanism decomposition — how much of the blowup is modeled network contention versus the serialized per-rank rendezvous structure of the mailbox MPI runtime versus frontier replication; a 100× jump over one doubling step needs an accounting, not just a label. (2) Robustness to the pricing model: does the wall persist, and at what magnitude, under the closed-form analytical model and under live congestion feedback instead of the frozen sample? Since §V-G notes the shared-memory model uses live feedback while message-passing uses the frozen sample, part
  4. [§V-F, Table II] §V-F (Fig. 9): the energy verdict ('offload saves energy only on HBM3; the 16-core host keeps every end-to-end time win') depends on the power-gating assumption and on the host socket power figures in Table II (3.57/4.65/11.14 W for 1/4/16 cores at 22 nm). The gating contract — 'a component that is fully idle contributes no power,' including the host socket during the device window — is aggressive relative to real systems (an idle-but-coherent socket retains LLC, uncore, and PHY static power; the manuscript itself charges the host memory device, so why is the socket's static share zeroed?). The '12 of 20 cells' add-on comparison against a single busy OOO core and the 1.6× HBM3 energy win could both shift under a more conventional idle-power model. Please report the sensitivity of the Fig. 9 energy verdict to (a) nonzero idle socket power during the device window and (b) the assumed per-c
minor comments (8)
  1. [§V-G] §V-A/§V-G: the 2–7% cross-host sensitivity from OS thread-timing seeds amplified by the congestion feedback loop is disclosed but its direction is not; please state whether reported ratios (e.g., the 24.2M vs 24.6M BFS cells) bracket the true value or are biased, and consider pinning the seed for the figures.
  2. [Table II] Table II: the '0.5 row-hit fallback where command counts unavailable' is a consequential default buried in a dense cell; please state which technologies/figures actually use it and its effect on the reported per-command energies.
  3. [Fig. 2] Fig. 2(c): the DDR5 panel notes '2 sub-channels (not modeled)'. Since sub-channeling doubles the independent command paths on DDR5, please briefly justify that omitting it does not flatter DDR5's bank-level PIM ranking relative to HBM2/3 in Fig. 5.
  4. [§V-C, Fig. 6] §V-C: the claim that cycles are quoted 'because modeled device power co-varies with placement' is reasonable, but the energy panels are shown in Fig. 6 anyway; either discuss the placement-energy trend (it appears to favor coarse placement strongly) or omit the panel to avoid inviting an unargued reading.
  5. [Fig. 9] Fig. 9: with five kernel groups × five bar types × two execution models per panel, the figure is very dense; a hatch/legend explanation in the caption (beyond 'plain = shared-memory, hatched = message-passing') and consistent y-axis ranges across the DDR5/HBM3 pairs would help.
  6. [throughout] Typos/typesetting: 'Y AML' (multiple instances), 'Y . He' and 'T. V ogelsang' in the references/author block, and missing thin spaces before units throughout (e.g., '0.81/0.97nJ', '52.7mW', '16×the single-launcher').
  7. [§II, Table I] §II: Table I is a strong positioning artifact, but the 'In-memory network' column for PIMID ('Per-tech GARNET fabrics + analytical') presumes the DQ-reuse abstraction; a footnote cross-referencing §IV-E's boundary statement would make the comparison fairer to tools that model dedicated inter-bank paths (e.g., NoM [71] is cited but not tabulated).
  8. [§V-E] §V-E: the documented OoO-vs-in-order inversion on branch-heavy kernels at large working sets is plausible, but 'modeled physics, not a calibration error' asserts rather than shows; one sentence of evidence (mispredict counts or redirect-latency accounting) would suffice.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: headline rankings are simulation outputs of third-party engines under stated abstractions, not identities forced by fitted constants or self-citation.

full rationale

PIMID is an architectural simulator paper. Its load-bearing claims (technology ladder up to ~19×, host-vs-PIM substrate inversion, superlinear PE scaling, message-passing BFS collective wall, HBM3-only energy win under shared-memory offload) are empirical outputs of running annotated OpenMP/MPI kernels through integrated external engines (Ramulator 2.0, CACTI, NVSim, GARNET, McPAT, QEMU/ZSim), not algebraic derivations. Per-technology idle latencies are anchored to published hardware measurements; DRAM energy uses JEDEC-class IDD/VDD presets from vendor datasheet methodology rather than parameters tuned to produce the reported rankings. The co-simulation parity check (device-side cycles agree with standalone within 0.1% on regular shared-memory kernels) is a consistency validation, not a self-definitional loop. Related-work self-citations (e.g., MultiPIM lineage, author-overlapping surveys/accelerators) are background and non-load-bearing. The skeptic concern that DQ-datapath reuse (IV-E, V-G) co-produces channel-centric starvation is a modeling-fidelity limitation the paper itself states, not circular reasoning: an explicit abstraction that may be wrong is not Eq. X = Eq. Y by construction. No fitted-input-called-prediction, uniqueness-from-authors, or ansatz-smuggling chain is present. Score 0.

Assumptions & free parameters 5 free parameters · 6 assumptions · 1 invented entities

The central claims rest on standard simulation composition plus several domain modeling choices that are stated but not independently silicon-validated for PIM fabrics. No new physical entities are postulated; free parameters are calibration constants taken from datasheets or chosen as experimental defaults.

free parameters (5)
  • Per-technology IDD/VDD energy presets and 0.5 row-hit fallback = e.g. ~0.81/0.97 nJ per 64B DDR5 R/W; ~0.32/0.39 nJ HBM3; PCM RESET 51.9 nJ/64B
    Stock Ramulator 2 lacks usable energy constants; authors inject JEDEC-class current presets and a 0.5 row-hit fallback where command counts are unavailable. Rankings of energy depend on these values.
  • Default PE configuration (16 ALU PEs @ 500 MHz, bank placement) = 16 PEs, 500 MHz, bank level
    Device sweeps fix this default; absolute times and some relative gaps are configuration-dependent even though axes are swept one-at-a-time.
  • Host–device link latency/bandwidth/protocol overhead presets = From specs [64–66]; launch ~10.7K cycles
    PCIe/CXL/NVLink/interposer charges use published lane rates and characterization classes; user-overridable but fixed for the co-sim study.
  • Process node and McPAT power templates (22 nm) = 22 nm; PE ~54 mW; 16-PE H-tree fabric 7.3 mW
    Uniform 22 nm node and McPAT class templates set absolute watts (PE ~54 mW, host socket 3.57–11.14 W); energy verdicts scale with these.
  • Message-passing epoch-frozen GARNET congestion sample = Single-venue per figure family
    MP pricing freezes a measured congestion sample per epoch, introducing 2–7% cross-host sensitivity; absolute MP cycle counts are venue-dependent.
assumptions (6)
  • domain assumption Intra-memory PIM communication can be priced as bandwidth-limited reuse of the per-technology DQ datapath plus GARNET hierarchical fabric rather than a dedicated PIM NoC or exact TSV/dataline model.
    Stated in IV-E and bounded in V-G; load-bearing for PE-count superlinearity and placement results.
  • domain assumption Annotated OpenMP threads / MPI ranks map one-to-one onto device PEs and execute the same binary under device timing models.
    Programming-model section IV-G; enables dual-model comparison under matched conditions.
  • domain assumption Host and device are independent cycle-accounting domains in one process with explicit boundary charges; device model in co-sim is identical to standalone (parity invariant).
    Section IV-C; underpins end-to-end breakdown claims.
  • domain assumption Power gating: fully idle components (offloading host during device kernel; unused baseline cores) contribute zero power; active structures keep static power.
    Table II / IV-D; directly affects energy verdict that shared-memory offload energy is essentially all device.
  • domain assumption Integrated third-party tools (Ramulator 2, CACTI, NVSim, GARNET, McPAT, QEMU, ZSim) are adequate proxies for the modeled organizations at design-space fidelity.
    Throughout III–IV; standard in architecture simulation but unvalidated against real PIM silicon here.
  • standard math Standard computer-arithmetic and discrete-event simulation semantics.
    Background; no novel mathematics.
invented entities (1)
  • PIMID simulator (host/device engines + YAML plugin interfaces) independent evidence
    purpose: Provide the unified full-system PIM design-space vehicle and dual-execution-model dataset.
    Software artifact composed from existing engines; not a physical entity. independent_evidence is true insofar as source and container are released for external execution.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PIMID: A Full-System Simulator with Intricacy and Diversity for Processing-in-Memory." pith.science (2026). https://pith.science/paper/XKW2CTFD

@misc{pith2026260724196,
  author       = {Pith},
  title        = {Pith review of: PIMID: A Full-System Simulator with Intricacy and Diversity for Processing-in-Memory},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XKW2CTFD}},
  note         = {Machine review of arXiv:2607.24196}
}
read the original abstract

Processing-in-Memory addresses the memory wall by co-locating computation with memory, but because real PIM hardware remains scarce, simulation is the primary way to explore the PIM design space. Yet existing PIM simulators each cover only part of that space: they typically model a single memory technology, fix processing elements at one level of the memory hierarchy, support a single execution model, and stop at the device boundary. We therefore present PIMID, an execution- and trace-driven full-system simulator that closes these gaps in one tool. PIMID supports both the shared-memory and message-passing execution models, running annotated parallel code in OpenMP and MPI side by side across eleven memory technologies (seven DRAM standards, SRAM, and three non-volatile memories); it places PEs anywhere from subarrays to logic dies, sweeps PE count and core-model fidelity, and prices the in-memory network per technology from measured congestion. Its single-process host-device co-simulation resolves an end-to-end time and energy breakdown (host preparation, device compute, and explicit boundary charges) that device-only tools cannot produce. Across the resulting dual-execution-model dataset, PIMID shows that the memory technology alone moves execution time by more than an order of magnitude and that the best host main memory is not the best PIM substrate; that regular kernels scale superlinearly with PE count as in-memory bandwidth co-scales with compute; that graph traversal under message-passing hits a collective-communication wall absent under shared memory; and that at full-system scope the offload trades time for energy only on the bandwidth-class memory: shared-memory offload saves energy on HBM3 while a 16-core host keeps every end-to-end time win. PIMID's plugin interfaces let new engines and models be added through standardized YAML specifications as PIM technology evolves.

Figures

Figures reproduced from arXiv: 2607.24196 by the authors.

Figure 1
Figure 1. PIMID system architecture: two simulation engines (host and device) coupled at the offload boundary, over a shared modeling infrastructure. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Per-technology memory hierarchies and PE attach points. Panels (a)–(e): the seven DRAM standards’ physical organizations with per-level fan-outs; [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Simulation components exercised by the evaluation studies, drawn as the architecture of Fig. 1 with the active components highlighted, the rest [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Emerging-memory sweep. Execution time (left panel) and device-scope energy (right panel), both as bars on log scales, for five kernels on 16 in [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: DRAM technology sweep. The same five kernels, PE configuration, and panel layout as Fig. 4 (execution time left, device-scope energy right; 16 [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: PE placement sweep on HBM3 at 16 PEs. Execution time (left panel) and device-scope energy (right panel) for the five kernels with PEs placed at [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: PE-count scaling on HBM3 at bank placement. Execution time (left panel) and device-scope energy (right panel) for the five kernels as the in-memory [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 8
Figure 8. Figure 8: PE core-model fidelity sweep on HBM3 (16 PEs, bank placement). Execution time (left panel) and device-scope energy (right panel) for the five [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: Whole-application host-device co-simulation (device PEs at 500 MHz, host at 2 GHz): PIM offload versus the host-only baselines on the 16-core [PITH_FULL_IMAGE:figures/full_fig_p012_9.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

78 extracted references · 1 linked inside Pith

  1. [75]

    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,

    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, H. Choi, J. Lee, D. Ko, Y . Jun, K. Cho, I. Kim, C. Song, C. Jeong, D. Kwon, J. Jang, I. Park, J. Chun, and J. Cho, “A 1ynm 1.25V 8Gb 16Gb/s/pin GDDR6-based Accelerator-in-Memory Supporting 1TFLOPS MA...

    2022

  2. [16]

    Benchmarking a New Paradigm: Experimental Analysis and Characterization of a Real Processing-in-Memory System,

    J. G ´omez-Luna, I. El Hajj, I. Fernandez, C. Giannoula, G. F. Oliveira, and O. Mutlu, “Benchmarking a New Paradigm: Experimental Analysis and Characterization of a Real Processing-in-Memory System,”IEEE Access, vol. 10, pp. 52 565–52 608, 2022

    2022

  3. [18]

    Pathfinding Future PIM Architectures by Demystifying a Commercial PIM Technology,

    B. Hyun, T. Kim, D. Lee, and M. Rhu, “Pathfinding Future PIM Architectures by Demystifying a Commercial PIM Technology,” inProc. IEEE Int. Symp. High-Performance Computer Architecture (HPCA), March 2024, pp. 263–279

    2024

  4. [15]

    Hardware Architecture and Software Stack for PIM Based on Commercial DRAM Technology,

    S. Lee, S. Kang, J. Lee, H. Kim, E. Lee, S. Seo, H. Yoon, S. Lee, K. Lim, H. Shin, J. Kim, S. O, A. Iyer, D. Wang, K. Sohn, and N. S. Kim, “Hardware Architecture and Software Stack for PIM Based on Commercial DRAM Technology,” inProc. 48th Annual Int. Symp. Computer Architecture (ISCA), 2021, pp. 43–56

    2021

  5. [1]

    Pro- cessing data where it makes sense: Enabling in-memory computation,

    O. Mutlu, S. Ghose, J. G ´omez-Luna, and R. Ausavarungnirun, “Pro- cessing data where it makes sense: Enabling in-memory computation,” Microprocessors and Microsystems, vol. 67, pp. 28–41, June 2019

    2019

  6. [2]

    A Survey on the Expanding Scope and Interdisciplinary Opportunities for Processing-in-Memory Techniques,

    K. Asifuzzaman, Y . He, T. Zhang, E. Tang, N. R. Miniskar, K. Teranishi, and J. S. Vetter, “A Survey on the Expanding Scope and Interdisciplinary Opportunities for Processing-in-Memory Techniques,”IEEE Access, vol. 14, pp. 18 408–18 430, 2026

    2026

  7. [3]

    A Modern Primer on Processing in Memory,

    O. Mutlu, S. Ghose, J. G ´omez-Luna, and R. Ausavarungnirun, “A Modern Primer on Processing in Memory,” inEmerging Computing: From Devices to Systems. Springer, 2023, pp. 171–243

    2023

  8. [4]

    Cellular Logic-in-Memory Arrays,

    W. H. Kautz, “Cellular Logic-in-Memory Arrays,”IEEE Transactions on Computers, vol. C-18, no. 8, pp. 719–727, 1969

    1969

Show all 78 references
  1. [5]

    A Logic-in-Memory Computer,

    H. S. Stone, “A Logic-in-Memory Computer,”IEEE Transactions on Computers, vol. C-19, no. 1, pp. 73–78, 1970

    1970

  2. [6]

    A Case for Intelligent RAM,

    D. Patterson, T. Anderson, N. Cardwell, R. Fromm, K. Keeton, C. Kozyrakis, R. Thomas, and K. Yelick, “A Case for Intelligent RAM,” IEEE Micro, vol. 17, no. 2, pp. 34–44, 1997

    1997

  3. [7]

    Active Pages: A Computa- tion Model for Intelligent Memory,

    M. Oskin, F. T. Chong, and T. Sherwood, “Active Pages: A Computa- tion Model for Intelligent Memory,” inProc. 25th Annual Int. Symp. Computer Architecture (ISCA), 1998, pp. 192–203

    1998

  4. [8]

    FlexRAM: Toward an Advanced Intelligent Memory System,

    Y . Kang, W. Huang, S.-M. Yoo, D. Keen, Z. Ge, V . Lam, P. Pattnaik, and J. Torrellas, “FlexRAM: Toward an Advanced Intelligent Memory System,” inProc. IEEE Int. Conf. Computer Design (ICCD), 1999, pp. 192–201

    1999

  5. [9]

    A Scalable Processing- in-Memory Accelerator for Parallel Graph Processing,

    J. Ahn, S. Hong, S. Yoo, O. Mutlu, and K. Choi, “A Scalable Processing- in-Memory Accelerator for Parallel Graph Processing,” inProc. 42nd Annual Int. Symp. Computer Architecture (ISCA), 2015, pp. 105–117

    2015

  6. [10]

    PIM-Enabled Instructions: A Low-Overhead, Locality-Aware Processing-in-Memory Architecture,

    J. Ahn, S. Yoo, O. Mutlu, and K. Choi, “PIM-Enabled Instructions: A Low-Overhead, Locality-Aware Processing-in-Memory Architecture,” in Proc. 42nd Annual Int. Symp. Computer Architecture (ISCA), 2015, pp. 336–348

    2015

  7. [11]

    RowClone: Fast and Energy-Efficient In-DRAM Bulk Data Copy and Initialization,

    V . Seshadri, Y . Kim, C. Fallin, D. Lee, R. Ausavarungnirun, G. Pekhi- menko, Y . Luo, O. Mutlu, P. B. Gibbons, M. A. Kozuch, and T. C. Mowry, “RowClone: Fast and Energy-Efficient In-DRAM Bulk Data Copy and Initialization,” inProc. 46th Annual IEEE/ACM Int. Symp. Microarchite...

    2013

  8. [12]

    Ambit: In-Memory Accelerator for Bulk Bitwise Operations Using Commodity DRAM Technology,

    V . Seshadri, D. Lee, T. Mullins, H. Hassan, A. Boroumand, J. S. Kim, M. A. Kozuch, O. Mutlu, P. B. Gibbons, and T. C. Mowry, “Ambit: In-Memory Accelerator for Bulk Bitwise Operations Using Commodity DRAM Technology,” inProc. 50th Annual IEEE/ACM Int. Symp. Microarchitecture (...

    2017

  9. [13]

    ISAAC: A Con- volutional Neural Network Accelerator with In-Situ Analog Arithmetic in Crossbars,

    A. Shafiee, A. Nag, N. Muralimanohar, R. Balasubramonian, J. P. Strachan, M. Hu, R. S. Williams, and V . Srikumar, “ISAAC: A Con- volutional Neural Network Accelerator with In-Situ Analog Arithmetic in Crossbars,” inProc. 43rd Annual Int. Symp. Computer Architecture (ISCA), 20...

    2016

  10. [14]

    PRIME: A Novel Processing-in-Memory Architecture for Neural Net- work Computation in ReRAM-Based Main Memory,

    P. Chi, S. Li, C. Xu, T. Zhang, J. Zhao, Y . Liu, Y . Wang, and Y . Xie, “PRIME: A Novel Processing-in-Memory Architecture for Neural Net- work Computation in ReRAM-Based Main Memory,” inProc. 43rd Annual Int. Symp. Computer Architecture (ISCA), 2016, pp. 27–39

    2016

  11. [17]

    UPMEM,UPMEM SDK, available at https://sdk.upmem.com

  12. [19]

    PIMSys: A Virtual Prototype for Processing in Memory,

    D. Christ, L. Steiner, M. Jung, and N. Wehn, “PIMSys: A Virtual Prototype for Processing in Memory,” inProc. International Symposium on Memory Systems, 2024, pp. 26–33

    2024

  13. [20]

    PIMCoSim: Hardware/Software Co-Simulator for Exploring Processing-in-Memory Architectures,

    J. Shin, S. An, S. Lee, and S. E. Lee, “PIMCoSim: Hardware/Software Co-Simulator for Exploring Processing-in-Memory Architectures,”Elec- tronics, vol. 13, no. 23, p. 4795, 2024

    2024

  14. [21]

    PiMulator: a Fast and Flexible Processing-in-Memory Emulation Platform,

    S. Mosanu, M. N. Sakib, T. Tracy, E. Cukurtas, A. Ahmed, P. Ivanov, S. Khan, K. Skadron, and M. Stan, “PiMulator: a Fast and Flexible Processing-in-Memory Emulation Platform,” inProc. Design, Automa- tion and Test in Europe Conf. (DATE), March 2022, pp. 1473–1478

    2022

  15. [22]

    MultiPIM: A Detailed and Configurable Multi-Stack Processing-In-Memory Simulator,

    C. Yu, S. Liu, and S. Khan, “MultiPIM: A Detailed and Configurable Multi-Stack Processing-In-Memory Simulator,”IEEE Computer Archi- tecture Letters, vol. 20, no. 1, pp. 54–57, 2021

    2021

  16. [23]

    QEMU, a Fast and Portable Dynamic Translator,

    F. Bellard, “QEMU, a Fast and Portable Dynamic Translator,” inProc. USENIX Annual Technical Conference, FREENIX Track, 2005, pp. 41– 46

    2005

  17. [24]

    ZSim: Fast and Accurate Microarchitec- tural Simulation of Thousand-Core Systems,

    D. Sanchez and C. Kozyrakis, “ZSim: Fast and Accurate Microarchitec- tural Simulation of Thousand-Core Systems,” inProc. 40th Int. Symp. Computer Architecture (ISCA), 2013, pp. 475–486

    2013

  18. [25]

    Ramulator: A Fast and Extensible DRAM Simulator,

    Y . Kim, W. Yang, and O. Mutlu, “Ramulator: A Fast and Extensible DRAM Simulator,”IEEE Computer Architecture Letters, vol. 15, no. 1, pp. 45–49, 2016. 14

    2016

  19. [26]

    Ramulator 2.0: A Modern, Modular, and Extensible DRAM Simulator,

    H. Luo, Y . C. Tugrul, F. N. Bostanci, A. Olgun, A. G. Yaglikci, and O. Mutlu, “Ramulator 2.0: A Modern, Modular, and Extensible DRAM Simulator,”IEEE Computer Architecture Letters, vol. 23, no. 1, pp. 112– 116, 2024

    2024

  20. [27]

    CACTI 7: New Tools for Interconnect Exploration in Innovative Off-Chip Memories,

    R. Balasubramonian, A. B. Kahng, N. Muralimanohar, A. Shafiee, and V . Srinivas, “CACTI 7: New Tools for Interconnect Exploration in Innovative Off-Chip Memories,”ACM Transactions on Architecture and Code Optimization, vol. 14, no. 2, pp. 14:1–14:25, 2017

    2017

  21. [28]

    NVSim: A Circuit- Level Performance, Energy, and Area Model for Emerging Nonvolatile Memory,

    X. Dong, C. Xu, Y . Xie, and N. P. Jouppi, “NVSim: A Circuit- Level Performance, Energy, and Area Model for Emerging Nonvolatile Memory,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 31, no. 7, pp. 994–1007, 2012

    2012

  22. [29]

    GARNET: A Detailed On-Chip Network Model inside a Full-System Simulator,

    N. Agarwal, T. Krishna, L.-S. Peh, and N. K. Jha, “GARNET: A Detailed On-Chip Network Model inside a Full-System Simulator,” inProc. IEEE Int. Symp. Performance Analysis of Systems and Software (ISPASS), April 2009, pp. 33–42

    2009

  23. [30]

    McPAT: An Integrated Power, Area, and Timing Modeling Framework for Multicore and Manycore Architectures,

    S. Li, J. H. Ahn, R. D. Strong, J. B. Brockman, D. M. Tullsen, and N. P. Jouppi, “McPAT: An Integrated Power, Area, and Timing Modeling Framework for Multicore and Manycore Architectures,” inProc. 42nd Annual IEEE/ACM Int. Symp. Microarchitecture (MICRO), December 2009, pp. 469–480

    2009

  24. [31]

    PIMSim: A Flexible and Detailed Processing-in-Memory Simulator,

    S. Xu, X. Chen, Y . Wang, Y . Han, X. Qian, and X. Li, “PIMSim: A Flexible and Detailed Processing-in-Memory Simulator,”IEEE Com- puter Architecture Letters, vol. 18, no. 1, pp. 6–9, 2019

    2019

  25. [32]

    Sim2PIM: A Complete Simulation Framework for Processing-in- Memory,

    B. E. Forlin, P. C. Santos, A. E. Becker, M. A. Z. Alves, and L. Carro, “Sim2PIM: A Complete Simulation Framework for Processing-in- Memory,”Journal of Systems Architecture, vol. 128, p. 102528, 2022

    2022

  26. [33]

    Architectural modeling and benchmarking for digital DRAM PIM,

    F. A. Siddique, D. Guo, Z. Fan, M. Gholamrezaei, M. Baradaran, A. Ahmed, H. Abbot, K. Durrer, K. Nandagopal, E. Ermovick, K. Kiyawat, B. Gul, A. T. Mughrabi, A. Venkat, and K. Skadron, “Architectural modeling and benchmarking for digital DRAM PIM,” in Proc. IEEE Int. Symp. Wor...

    2024

  27. [34]

    UniNDP: A Unified Compilation and Simulation Tool for Near DRAM Processing Architectures,

    T. Xie, Z. Zhu, B. Li, Y . He, C. Li, G. Sun, H. Yang, Y . Xie, and Y . Wang, “UniNDP: A Unified Compilation and Simulation Tool for Near DRAM Processing Architectures,” inProc. IEEE Int. Symp. High-Performance Computer Architecture (HPCA), 2025, pp. 624–640

    2025

  28. [35]

    SimpleScalar: An Infrastructure for Computer System Modeling,

    T. Austin, E. Larson, and D. Ernst, “SimpleScalar: An Infrastructure for Computer System Modeling,”Computer, vol. 35, no. 2, pp. 59–67, 2002

    2002

  29. [36]

    The gem5 Simulator,

    N. Binkert, B. Beckmann, G. Black, S. K. Reinhardt, A. Saidi, A. Basu, J. Hestness, D. R. Hower, T. Krishna, S. Sardashti, R. Sen, K. Sewell, M. Shoaib, N. Vaish, M. D. Hill, and D. A. Wood, “The gem5 Simulator,”ACM SIGARCH Computer Architecture News, vol. 39, no. 2, pp. 1–7, 2011

    2011

  30. [37]

    Sniper: Exploring the Level of Abstraction for Scalable and Accurate Parallel Multi- Core Simulation,

    T. E. Carlson, W. Heirman, and L. Eeckhout, “Sniper: Exploring the Level of Abstraction for Scalable and Accurate Parallel Multi- Core Simulation,” inProc. Int. Conf. High Performance Computing, Networking, Storage and Analysis (SC), 2011

    2011

  31. [38]

    The Championship Simulator: Architectural Simulation for Education and Competition,

    N. Gober, G. Chacon, L. Wang, P. V . Gratz, D. A. Jimenez, E. Teran, S. Pugsley, and J. Kim, “The Championship Simulator: Architectural Simulation for Education and Competition,”arXiv preprint arXiv:2210.14324, 2022

    2022 arXiv

  32. [39]

    The Structural Simulation Toolkit,

    A. F. Rodrigues, K. S. Hemmert, B. W. Barrett, C. Kersey, R. Oldfield, M. Weston, R. Risen, J. Cook, P. Rosenfeld, E. Cooper-Balis, and B. Jacob, “The Structural Simulation Toolkit,”ACM SIGMETRICS Performance Evaluation Review, vol. 38, no. 4, pp. 37–42, 2011

    2011

  33. [40]

    DRAMsim3: A Cycle-Accurate, Thermal-Capable DRAM Simulator,

    S. Li, Z. Yang, D. Reddy, A. Srivastava, and B. Jacob, “DRAMsim3: A Cycle-Accurate, Thermal-Capable DRAM Simulator,”IEEE Computer Architecture Letters, vol. 19, no. 2, pp. 106–109, 2020

    2020

  34. [41]

    DRAM- Sys4.0: A Fast and Cycle-Accurate SystemC/TLM-Based DRAM Sim- ulator,

    L. Steiner, M. Jung, F. S. Prado, K. Bykov, and N. Wehn, “DRAM- Sys4.0: A Fast and Cycle-Accurate SystemC/TLM-Based DRAM Sim- ulator,” inProc. Int. Conf. Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS), 2020, pp. 110–126

    2020

  35. [42]

    NVMain 2.0: A User-Friendly Memory Simulator to Model (Non-)V olatile Memory Systems,

    M. Poremba, T. Zhang, and Y . Xie, “NVMain 2.0: A User-Friendly Memory Simulator to Model (Non-)V olatile Memory Systems,”IEEE Computer Architecture Letters, vol. 14, no. 2, pp. 140–143, 2015

    2015

  36. [43]

    DAMOV: A New Methodology and Benchmark Suite for Evaluating Data Movement Bottlenecks,

    G. F. Oliveira, J. G ´omez-Luna, L. Orosa, S. Ghose, N. Vijayku- mar, I. Fernandez, M. Sadrosadati, and O. Mutlu, “DAMOV: A New Methodology and Benchmark Suite for Evaluating Data Movement Bottlenecks,”IEEE Access, vol. 9, pp. 134 457–134 502, 2021

    2021

  37. [44]

    DX100: Programmable Data Access Accelerator for Indirec- tion,

    A. Khadem, K. Kamalakkannan, Z. Zhu, A. Poptani, Y . Gu, J. B. Dominguez-Trujillo, N. Talati, D. Fujiki, S. Mahlke, G. Shipman, and R. Das, “DX100: Programmable Data Access Accelerator for Indirec- tion,” inProc. 52nd Annual Int. Symp. Computer Architecture (ISCA), 2025, pp. 1641–1658

    2025

  38. [45]

    An edge re-ordering based acceleration architecture for improving data locality in graph analytics applications,

    S. Hu, M. Kondo, Y . He, R. Sakamoto, H. Zhang, J. Zhou, and H. Nakamura, “An edge re-ordering based acceleration architecture for improving data locality in graph analytics applications,”Microprocessors and Microsystems, vol. 102, p. 104895, 2023

    2023

  39. [46]

    Compute Caches,

    S. Aga, S. Jeloka, A. Subramaniyan, S. Narayanasamy, D. Blaauw, and R. Das, “Compute Caches,” inProc. IEEE Int. Symp. High Performance Computer Architecture (HPCA), 2017, pp. 481–492

    2017

  40. [47]

    DAISM: Digital approximate in-SRAM multiplier-based accelerator for DNN training and inference,

    L. Sonnino, S. Shresthamali, Y . He, and M. Kondo, “DAISM: Digital approximate in-SRAM multiplier-based accelerator for DNN training and inference,” inProc. Design, Automation and Test in Europe Conf. (DATE), 2024

    2024

  41. [48]

    DRISA: A DRAM-based Reconfigurable In-Situ Accelerator,

    S. Li, D. Niu, K. T. Malladi, H. Zheng, B. Brennan, and Y . Xie, “DRISA: A DRAM-based Reconfigurable In-Situ Accelerator,” inProc. 50th Annual IEEE/ACM Int. Symp. Microarchitecture (MICRO), 2017, pp. 288–301

    2017

  42. [49]

    SIMDRAM: A Framework for Bit-Serial SIMD Processing Using DRAM,

    N. Hajinazar, G. F. Oliveira, S. Gregorio, J. D. Ferreira, N. Man- souri Ghiasi, M. Patel, M. Alser, S. Ghose, J. G ´omez-Luna, and O. Mutlu, “SIMDRAM: A Framework for Bit-Serial SIMD Processing Using DRAM,” inProc. 26th Int. Conf. Architectural Support for Programming Languag...

    2021

  43. [50]

    FloatPIM: In-Memory Acceleration of Deep Neural Network Training with High Precision,

    M. Imani, S. Gupta, Y . Kim, and T. Rosing, “FloatPIM: In-Memory Acceleration of Deep Neural Network Training with High Precision,” in Proc. 46th Annual Int. Symp. Computer Architecture (ISCA), 2019, pp. 802–815

    2019

  44. [51]

    Neurocube: A Programmable Digital Neuromorphic Architecture with High-Density 3D Memory,

    D. Kim, J. Kung, S. Chai, S. Yalamanchili, and S. Mukhopadhyay, “Neurocube: A Programmable Digital Neuromorphic Architecture with High-Density 3D Memory,” inProc. 43rd Annual Int. Symp. Computer Architecture (ISCA), 2016, pp. 380–392

    2016

  45. [52]

    TETRIS: Scalable and Efficient Neural Network Acceleration with 3D Memory,

    M. Gao, J. Pu, X. Yang, M. Horowitz, and C. Kozyrakis, “TETRIS: Scalable and Efficient Neural Network Acceleration with 3D Memory,” inProc. 22nd Int. Conf. Architectural Support for Programming Lan- guages and Operating Systems (ASPLOS), 2017, pp. 751–764

    2017

  46. [53]

    TensorDIMM: A Practical Near-Memory Processing Architecture for Embeddings and Tensor Operations in Deep Learning,

    Y . Kwon, Y . Lee, and M. Rhu, “TensorDIMM: A Practical Near-Memory Processing Architecture for Embeddings and Tensor Operations in Deep Learning,” inProc. 52nd Annual IEEE/ACM Int. Symp. Microarchitec- ture (MICRO), 2019, pp. 740–753

    2019

  47. [54]

    RecNMP: Accel- erating Personalized Recommendation with Near-Memory Processing,

    L. Ke, U. Gupta, B. Y . Cho, D. Brooks, V . Chandra, U. Diril, A. Firoozshahian, K. Hazelwood, B. Jia, H.-H. S. Lee, M. Li, B. Maher, D. Mudigere, M. Naumov, M. Schatz, M. Smelyanskiy, X. Wang, B. Reagen, C.-J. Wu, M. Hempstead, and X. Zhang, “RecNMP: Accel- erating Personaliz...

    2020

  48. [55]

    Newton: A DRAM-maker’s Accelerator-in- Memory (AiM) Architecture for Machine Learning,

    M. He, C. Song, I. Kim, C. Jeong, S. Kim, I. Park, M. Thottethodi, and T. N. Vijaykumar, “Newton: A DRAM-maker’s Accelerator-in- Memory (AiM) Architecture for Machine Learning,” inProc. 53rd Annual IEEE/ACM Int. Symp. Microarchitecture (MICRO), 2020, pp. 372–385

    2020

  49. [56]

    NeuPIMs: NPU-PIM Heterogeneous Acceleration for Batched LLM Inferencing,

    G. Heo, S. Lee, J. Cho, H. Choi, S. Lee, H. Ham, G. Kim, D. Ma- hajan, and J. Park, “NeuPIMs: NPU-PIM Heterogeneous Acceleration for Batched LLM Inferencing,” inProc. 29th Int. Conf. Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2024

    2024

  50. [57]

    GraphP: Reducing Communication for PIM-based Graph Processing with Efficient Data Partition,

    M. Zhang, Y . Zhuo, C. Wang, M. Gao, Y . Wu, K. Chen, C. Kozyrakis, and X. Qian, “GraphP: Reducing Communication for PIM-based Graph Processing with Efficient Data Partition,” inProc. IEEE Int. Symp. High- Performance Computer Architecture (HPCA), 2018, pp. 544–557

    2018

  51. [58]

    GraphQ: Scalable PIM-based Graph Processing,

    Y . Zhuo, C. Wang, M. Zhang, R. Wang, D. Niu, Y . Wang, and X. Qian, “GraphQ: Scalable PIM-based Graph Processing,” inProc. 52nd Annual IEEE/ACM Int. Symp. Microarchitecture (MICRO), 2019, pp. 712–725

    2019

  52. [59]

    JEDEC,JESD79-5: DDR5 SDRAM Standard, JEDEC Solid State Tech- nology Association, 2020

    2020

  53. [60]

    ——,JESD209-5: LPDDR5 SDRAM Standard, JEDEC Solid State Technology Association, 2019

    2019

  54. [61]

    ——,JESD250: GDDR6 SGRAM Standard, JEDEC Solid State Tech- nology Association, 2017

    2017

  55. [62]

    ——,JESD235: High Bandwidth Memory (HBM) DRAM Standard, JEDEC Solid State Technology Association, 2013

    2013

  56. [63]

    ——,JESD238: HBM3 DRAM Standard, JEDEC Solid State Technol- ogy Association, 2022

    2022

  57. [64]

    PCI-SIG,PCI Express Base Specification, Revision 5.0, PCI-SIG, 2019

    2019

  58. [65]

    Compute Express Link (CXL): Enabling Heteroge- neous Data-Centric Computing with Heterogeneous Memory Hierarchy,

    D. Das Sharma, “Compute Express Link (CXL): Enabling Heteroge- neous Data-Centric Computing with Heterogeneous Memory Hierarchy,” IEEE Micro, vol. 43, no. 2, pp. 99–109, 2023

    2023

  59. [66]

    Ultra-Performance Pascal GPU and NVLink Interconnect,

    D. Foley and J. Danskin, “Ultra-Performance Pascal GPU and NVLink Interconnect,”IEEE Micro, vol. 37, no. 2, pp. 7–17, 2017. 15

    2017

  60. [67]

    TN-41-01: Calculating Memory System Power for DDR3,

    Micron Technology, “TN-41-01: Calculating Memory System Power for DDR3,” Micron Technology, Inc., Technical Note, 2007

    2007

  61. [68]

    Understanding the Energy Consumption of Dynamic Random Access Memories,

    T. V ogelsang, “Understanding the Energy Consumption of Dynamic Random Access Memories,” inProc. 43rd Annual IEEE/ACM Int. Symp. Microarchitecture (MICRO), 2010, pp. 363–374

    2010

  62. [69]

    Towards Energy-Proportional Datacenter Memory with Mobile DRAM,

    K. T. Malladi, F. A. Nothaft, K. Periyathambi, B. C. Lee, C. Kozyrakis, and M. Horowitz, “Towards Energy-Proportional Datacenter Memory with Mobile DRAM,” inProc. 39th Annual Int. Symp. Computer Architecture (ISCA), 2012, pp. 37–48

    2012

  63. [70]

    Fine-Grained DRAM: Energy-Efficient DRAM for Extreme Bandwidth Systems,

    M. O’Connor, N. Chatterjee, D. Lee, J. Wilson, A. Agrawal, S. W. Keck- ler, and W. J. Dally, “Fine-Grained DRAM: Energy-Efficient DRAM for Extreme Bandwidth Systems,” inProc. 50th Annual IEEE/ACM Int. Symp. Microarchitecture (MICRO), 2017, pp. 41–54

    2017

  64. [71]

    NoM: Network-on- Memory for Inter-Bank Data Transfer in Highly-Banked Memories,

    S. H. SeyyedAghaei Rezaei, M. Modarressi, R. Ausavarungnirun, M. Sadrosadati, O. Mutlu, and M. Daneshtalab, “NoM: Network-on- Memory for Inter-Bank Data Transfer in Highly-Banked Memories,” IEEE Computer Architecture Letters, vol. 19, no. 1, 2020

    2020

  65. [72]

    OpenMP Architecture Review Board,OpenMP Application Program- ming Interface, Version 5.2, 2021

    2021

  66. [73]

    Message Passing Interface Forum,MPI: A Message-Passing Interface Standard, Version 4.1, 2023

    2023

  67. [74]

    SimplePIM: A Software Framework for Productive and Efficient Processing-in- Memory,

    J. Chen, J. G ´omez-Luna, I. El Hajj, Y . Guo, and O. Mutlu, “SimplePIM: A Software Framework for Productive and Efficient Processing-in- Memory,” inProc. 32nd Int. Conf. Parallel Architectures and Compila- tion Techniques (PACT), 2023

    2023

  68. [76]

    Memory Bandwidth and Machine Balance in Cur- rent High Performance Computers,

    J. D. McCalpin, “Memory Bandwidth and Machine Balance in Cur- rent High Performance Computers,”IEEE Computer Society Technical Committee on Computer Architecture (TCCA) Newsletter, pp. 19–25, December 1995

    1995

  69. [77]

    DIMM-Link: Enabling Efficient Inter-DIMM Communication for Near-Memory Processing,

    Z. Zhou, C. Li, F. Yang, and G. Sun, “DIMM-Link: Enabling Efficient Inter-DIMM Communication for Near-Memory Processing,” inProc. IEEE Int. Symp. High-Performance Computer Architecture (HPCA), 2023

    2023

  70. [78]

    PIMnet: A Domain-Specific Network for Efficient Collective Communication in Scalable PIM,

    H. Son, G. Jonatan, X. Wu, H. Cho, K. Shivdikar, J. L. Abellan, A. Joshi, D. Kaeli, and J. Kim, “PIMnet: A Domain-Specific Network for Efficient Collective Communication in Scalable PIM,” inProc. IEEE Int. Symp. High-Performance Computer Architecture (HPCA), 2025

    2025

Pith tools

Reviewed July 31, 2026 · model on record in the stance chip above.