Pith. sign in

REVIEW 6 major objections 5 minor 38 references

AMPED: Accelerating MTTKRP for Billion-Scale Sparse Tensor Decomposition on Multiple GPUs

T0 review · 6 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Pith's one-line read AMPED shows that sharding a sparse tensor by output-mode index, keeping every update to a factor-matrix row on one GPU, lets MTTKRP run on billion-scale tensors with a 5.1x geometric mean speedup over single-GPU baselines.

desk verdict Solid scaling results, but the 5.1x headline is BLCO-only and the missing HPSPTM comparison weakens the SOTA claim. read the letter →

arxiv 2507.15121 v2 pith:FBF3MTBH submitted 2025-07-20 cs.DC

classification cs.DC
keywords MTTKRPsparsetensordecompositionCPmulti-GPUloadbalancingpartitioningbillion-scaletensorsGPUcommunication
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

AMPED is a multi-GPU algorithm for the Matricized Tensor Times Khatri-Rao Product (MTTKRP), the compute bottleneck in sparse tensor decomposition. The paper claims that sharding a sparse tensor by output-mode index, so all nonzeros that update the same factor-matrix row are assigned to the same GPU, removes cross-GPU race conditions and synchronization during computation. On four real-world billion-scale tensors, AMPED reports a 5.1x geometric mean speedup in total execution time over state-of-the-art single-GPU baselines using 4 GPUs on one node, and near-linear scaling (1.9x, 2.3x, 3.3x) as the GPU count grows from 1 to 4. This matters because MTTKRP is the repeated inner loop of canonical polyadic decomposition, and the tensors that arise in applications now exceed the memory of a single GPU.

What carries the argument

The carrying mechanism is output-mode-index sharding: choose a mode $d$, split its index range $\mathcal{I}_d$ into equal-size contiguous partitions, and collect every nonzero tensor element incident on an index in a partition into one tensor shard. Each shard updates only its own rows of the output factor matrix, so shards are independent and can be assigned to different GPUs with no cross-GPU atomics or synchronization during computation. Inside a GPU, each shard is split into equal-sized inter-shard partitions assigned to streaming multiprocessors, where atomic operations are used only within the device. The paper stores one copy of the tensor per output mode in host CPU memory, streams shards to GPUs, and exchanges the updated factor-matrix rows between GPUs with a ring all-gather after each mode.

What would settle it

Run AMPED on a synthetic billion-scale tensor with a deliberately skewed output-mode distribution, e.g., 50% of nonzeros under one output index and the rest uniform; if the slowest shard's compute time dominates total time and the 4-GPU speedup over 1 GPU falls toward 1x, then the equal-index-size sharding assumption is falsified.

Watch

Extended reading notes

Core claim

The central claim is that the task-dependency-free partitioning of FLYCOO-GPU extends to multiple GPUs if the tensor is split by output-mode index instead of by nonzero count. Equal-size index partitions of the output mode are collected into tensor shards, each shard is assigned to one GPU, and each shard is further divided into equal inter-shard partitions for the GPU's streaming multiprocessors. Because all nonzeros that update a given row of the output factor matrix live in the same shard, GPUs never race during elementwise computation; after a mode finishes, the updated factor-matrix rows are exchanged with a ring all-gather. The result is that total execution time on billion-scale tensors is reported as 5.1x faster (geometric mean) than BLCO, MM-CSF, HiCOO-GPU, and FLYCOO-GPU, while the partitioning scheme alone is 8.2x better than an equal-nonzero-count distribution.

Load-bearing premise

The speedup depends on equal-size output-mode index partitions producing roughly equal work per GPU; a highly skewed tensor, such as the paper's Twitch dataset where popular streamers and games concentrate nonzeros, breaks that balance and makes one shard's GPU the bottleneck.

Editorial extensions

If this is right

  • Total MTTKRP time falls by a geometric mean of 5.1x on the four tested billion-scale tensors when moving from the strongest single-GPU baselines to 4 GPUs on one node.
  • Using 2, 3, and 4 GPUs gives 1.9x, 2.3x, and 3.3x geometric mean speedups over the same algorithm on one GPU, so the approach scales nearly linearly on these datasets.
  • The sharding scheme alone is worth a geometric mean 8.2x speedup over simply dividing the nonzeros equally among GPUs, because equal-nonzero splits force host-side merges and cross-GPU dependencies.
  • On the smallest test tensor, Twitch, the single-GPU FLYCOO-GPU baseline remains 3.9x faster, and the paper attributes this to GPU-GPU communication overhead; the result is therefore strongest for tensors that do not fit in one GPU's memory.

Reading between the lines

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

  • Because shards are independent by construction, a natural extension is to size shards to each device's memory and bandwidth rather than to an equal share of indices; a heterogeneous CPU+GPU+FPGA version would inherit the same correctness argument.
  • The Twitch slowdown points to a specific testable fix: replace equal-size index partitions with partitions balanced by estimated nonzero counts per output index while keeping each index in one partition, which would preserve task independence and reduce skew.
  • The paper's execution-time breakdown shows host-to-GPU streaming of tensor shards as a major cost on large tensors, so prefetching the next shard during compute of the current one is a direct way to attack the largest remaining bottleneck.
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

6 major / 5 minor

Summary. The paper presents AMPED, a multi-GPU parallel algorithm for the Matricized Tensor Times Khatri-Rao Product (MTTKRP) kernel in sparse tensor decomposition. AMPED extends the single-GPU FLYCOO-GPU partitioning scheme to multiple GPUs: for each output mode, output-mode indices are partitioned into shards that are assigned to GPUs, and each shard is further divided into inter-shard partitions assigned to threadblocks. The design avoids inter-GPU data dependencies by keeping all updates to a given output row in the same shard, and uses an all-gather ring to exchange factor-matrix rows between modes. Experiments on a 4-GPU node (NVIDIA RTX 6000 Ada) with four FROSTT/RecSys tensors report a 5.1x geometric mean speedup in total execution time over GPU baselines, a 8.2x speedup over equal nonzero-element distribution, and scalability of 1.9x/2.3x/3.3x with 2/3/4 GPUs versus one GPU.

Significance. If the reported results hold, the work addresses a real bottleneck: MTTKRP is the dominant cost in sparse CPD, and billion-scale tensors exceed single-GPU memory. The internal scalability results (1.9x/2.3x/3.3x on 2/3/4 GPUs) and the partitioning-scheme comparison (8.2x vs equal distribution) are useful empirical contributions, and the paper explicitly extends a known single-GPU scheme to a multi-GPU setting with a dependency-free sharding property. However, the headline 5.1x claim needs clarification and the evaluation omits the closest prior multi-GPU work, HPSPTM. The paper provides no code artifact or data-availability statement, which limits reproducibility. The central idea is plausible and the system appears to work, but the current presentation does not fully substantiate the 'state-of-the-art' claim.

major comments (6)
  1. [Section 5.2 / Abstract] The 5.1x geometric mean speedup is not precisely defined. The text first says 'Our work demonstrates a geometric mean speedup of 5.1x compared with the state-of-the-art baselines' and then, three sentences later, says 'Our work shows a geometric speedup of 5.1x using 4 GPUs compared to BLCO.' Because FLYCOO-GPU outperforms AMPED on Twitch by 3.9x (i.e., an AMPED/FLYCOO speedup of about 0.26x), a geometric mean over all baseline-dataset pairs that includes FLYCOO cannot equal 5.1x. The paper must specify exactly over which baselines and datasets the geometric mean is computed, and report per-baseline per-dataset speedups so the number is checkable.
  2. [Section 5.2 / Related Work] The evaluation omits HPSPTM [4], the only prior multi-GPU MTTKRP implementation cited in Section 2. Since AMPED uses 4 GPUs, comparing against single-GPU baselines (BLCO, MM-CSF, ParTI-GPU, FLYCOO-GPU) does not establish superiority over the multi-GPU state of the art. The authors should either benchmark HPSPTM on the same tensors, demonstrate that it is infeasible on billion-scale inputs (with concrete memory/time evidence), or rephrase the claim to 'speedup over single-GPU baselines.' This is load-bearing for the abstract's unqualified 'state-of-the-art GPU baselines' statement.
  3. [Section 5.2 / Figure 5] No error bars or multiple-run statistics are reported. All speedups appear to be based on single executions. For a systems paper whose central claim is a speedup factor, at least a few repetitions with mean and variance should be provided for the main comparison, especially on tensors where the margins may be small.
  4. [Abstract vs Section 3.1] The abstract claims that AMPED introduces 'a partitioning strategy combined with a dynamic load balancing scheme,' but Section 3.1 explicitly describes 'a static partitioning scheme.' If the dynamic element is the runtime assignment of shards to GPUs described in Section 4.2, this should be stated explicitly; otherwise the inconsistency between the abstract and the technical description confuses the contribution.
  5. [Section 3.2] The definition of k_d = |I_d|/m appears dimensionally inconsistent with the notion of equal-sized index partitions. If |I_d| is the number of output-mode indices and the indices are divided into k_d equal-sized partitions, then each partition contains |I_d|/k_d = m indices, which is an unusual formulation. The intended relationship between the number of shards, the number of GPUs, and the index partition size should be clarified, as this is the foundation of the partitioning scheme.
  6. [Section 5.5] The computation-time overhead among GPUs is measured by executing each GPU grid separately, which isolates computation from communication and scheduling. This measurement may not reflect actual end-to-end load imbalance, where PCIe transfers, all-gather, and barrier effects interact with varying shard sizes. The paper should report end-to-end per-GPU busy/idle time, or justify why isolated grid execution is representative of the full execution.
minor comments (5)
  1. [Section 2.2] FLYCOO-GPU is referenced as both '[36]' and '[37]' in the same paragraph; the second citation should be checked and corrected.
  2. [Section 5.1.1] The statement that the NVIDIA RTX 6000 Ada 'has more computing power and global memory than the NVIDIA A100 GPU' is inaccurate for memory: the A100 80GB variant has more memory than the 48GB RTX 6000 Ada. Please verify or remove this comparison.
  3. [Algorithm 2] The variable 'nnz' is used in the loop condition (line 8) but is never initialized in the pseudocode, and 'P' is first defined in the comment on line 20 after it is used. Move the definitions and initialization before the loop for readability.
  4. [Section 5.7] The text notes that preprocessing time is not the focus, but the main speedup claims in Section 5.2 do not explicitly state whether preprocessing is excluded from the reported total execution times; this should be stated in the main evaluation section.
  5. [General] No source-code availability or artifact statement is provided for AMPED, despite the baselines being linked to open-source repositories. Adding a link or an explicit availability statement would improve reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: AMPED's speedups are measured against external baselines on public datasets; self-citations to FLYCOO-GPU are disclosed design foundations, not load-bearing derivations.

full rationale

This is an empirical systems paper. The central claims are measured execution times on public FROSTT and recommender datasets against external open-source baselines (BLCO, MM-CSF, ParTI, FLYCOO-GPU). The speedup numbers are not derived from a fitted model and are not defined in terms of the paper's own outputs. The partitioning scheme is adopted from the authors' prior FLYCOO-GPU work via explicit citation; however, this self-citation is not load-bearing for the performance claim. AMPED's correctness and speed are established by the experiments reported in this paper, and the citation supplies an algorithmic design choice, not a predicted result. The scalability numbers (1.9x, 2.3x, 3.3x) are computed by dividing measured single-GPU time by measured multi-GPU time. The partitioning-scheme comparison (5.3x-10.3x speedups) is a controlled ablation against an equal-distribution partitioner, not a self-referential metric. No equation in the paper reduces to its own inputs, and no fitted parameter is relabeled as a prediction. The skeptic's concerns about the exact composition of the 'state-of-the-art baselines', the absence of HPSPTM in the benchmarks, and FLYCOO-GPU outperforming AMPED on Twitch pertain to the completeness and interpretation of the SOTA comparison, not to circularity. The core measured results stand independently of the paper's own prior claims. Therefore the circularity score is 0.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The algorithm depends on two user-chosen parameters (θ=32, R=32) and on the empirical regularity of real-world tensor index distributions. No new physical or mathematical entities are postulated, and no fitted constants enter the performance model.

free parameters (2)
  • Threadblock width θ = 32
    Number of nonzero tensor elements processed per threadblock column. Chosen by hand, not tuned per dataset; affects occupancy and load balance.
  • Rank R = 32
    Rank of factor matrices, set to 32 similar to related work. Determines factor matrix size and all-gather communication volume.
assumptions (3)
  • domain assumption Real-world billion-scale tensors have sufficiently uniform index distributions that equal-sized shards of output indices yield balanced GPU workloads
    The static sharding divides output mode indices into equal-sized partitions and assigns all nonzeros sharing an index to the same GPU. The paper's load-balance measurements (Section 5.5) show <1% overhead for most tensors but higher for Twitch, confirming this is an empirical assumption, not a guarantee.
  • domain assumption Host CPU memory is large enough to store one tensor copy per mode
    AMPED maintains N copies of the input tensor in host memory (Section 4.8). This is required for the mode-by-mode execution. For the four datasets the 1.5 TB host memory suffices, but the method's scalability is bounded by this storage multiplier.
  • standard math CUDA atomic operations and GPUDirect P2P communication behave as documented
    Correctness of the parallel updates within a GPU relies on atomicAdd semantics, and the all-gather relies on P2P transfers between GPUs (Sections 4.7, 4.9). Standard hardware/software behavior is assumed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AMPED: Accelerating MTTKRP for Billion-Scale Sparse Tensor Decomposition on Multiple GPUs." pith.science (2026). https://pith.science/paper/FBF3MTBH

@misc{pith2026250715121,
  author       = {Pith},
  title        = {Pith review of: AMPED: Accelerating MTTKRP for Billion-Scale Sparse Tensor Decomposition on Multiple GPUs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FBF3MTBH}},
  note         = {Machine review of arXiv:2507.15121}
}
read the original abstract

Matricized Tensor Times Khatri-Rao Product (MTTKRP) is the computational bottleneck in sparse tensor decomposition. As real-world sparse tensors grow to billions of nonzeros, they increasingly demand higher memory capacity and compute throughput from hardware accelerators. In this work, we present AMPED, a multi-GPU parallel algorithm designed to accelerate MTTKRP on billion-scale sparse tensors. AMPED scales beyond the limits of a single GPU, meeting both the memory and performance requirements of large-scale workloads. We introduce a partitioning strategy combined with a dynamic load balancing scheme to distribute computation and minimize GPU idle time. On real-world billion-scale tensors, AMPED achieves a 5.1x geometric mean speedup in total execution time over state-of-the-art GPU baselines using 4 GPUs on a single CPU node.

Figures

Figures reproduced from arXiv: 2507.15121 by the authors.

Figure 1
Figure 1. summarizes the elementwise computation of a nonzero tensor element in mode 2 of a 3-mode tensor. In [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2 uses the same notation introduced in Section 3.1. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Target platform We consider a single node multi-GPU platform where the GPUs are connected to a single CPU, as illustrated in [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Overview of threadblock The basic computing unit of a GPU is a thread. According to the GPU programming model [1, 38], a multi-threaded program is Algorithm 2: Parallel Algorithm Executed on a Shard 1 GPU Grid(𝑇𝑆𝑑,𝑧 , Y, 𝑇𝑜𝑢𝑡): 2 Input: Input tensor shard, 𝑇𝑆𝑑,𝑧 3 Fact…
Figure 5
Figure 5. Figure 5: Total execution time (speedup of our work compared to each baseline is shown at the top of each bar) [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Impact of proposed partitioning scheme Section 3 describes the partitioning scheme used in this work to distribute the tensor shards among GPUs. An alternative approach is to distribute the non-zero tensor elements equally among all GPUs. It introduces additional com￾p…
Figure 7
Figure 7. Figure 7: Execution time breakdown of the input tensors [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 9
Figure 9. Figure 9: shows the speedup of each input tensor as the number of GPUs increases from 1 to 4. The speedup is calculated by dividing the total execution time of the input tensor on a single GPU by its total execution time in each case. Our proposed parallel algorithm achieves geo…
Figure 10
Figure 10. Figure 10: Preprocessing time 6 Conclusion and Future Work In this paper, we proposed AMPED, a novel parallel algorithm designed to accelerate MTTKRP on billion-scale tensors using mul￾tiple GPUs. Our approach introduced a partitioning scheme that allowed each tensor partition t…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 23 canonical work pages

  1. [4]

    Tamer Özsu, Zhuo Tang, Albert Y

    Yuedan Chen, Guoqing Xiao, M. Tamer Özsu, Zhuo Tang, Albert Y. Zomaya, and Kenli Li. 2022. Exploiting Hierarchical Parallelism and Reusability in Tensor Kernel Processing on Heterogeneous HPC Systems. In2022 IEEE 38th International Conference on Data Engineering (ICDE) . 2522–2535. doi:10.1109/ICDE53745.2022. 00234

  2. [1]

    Richard Ansorge. 2022. Programming in parallel with CUDA: a practical guide . Cambridge University Press

  3. [2]

    Vivek Bharadwaj, Osman Asif Malik, Riley Murray, Aydın Buluç, and James Dem- mel. 2024. Distributed-Memory Randomized Algorithms for Sparse Tensor CP Decomposition. In Proceedings of the 36th ACM Symposium on Parallelism in Algo- rithms and Architectures (Nantes, France) (SPAA ’24). Association for Computing Machinery, New York, NY, USA, 155–168. doi:10.1...

  4. [5]

    Andrzej Cichocki. 2014. Era of big data processing: A new approach via tensor networks and tensor decompositions. arXiv preprint arXiv:1403.2048 (2014)

  5. [6]

    Andrzej Cichocki, Danilo Mandic, Lieven De Lathauwer, Guoxu Zhou, Qibin Zhao, Cesar Caiafa, and Huy Anh Phan. 2015. Tensor decompositions for signal processing applications: From two-way to multiway component analysis. IEEE signal processing magazine 32, 2 (2015), 145–163

  6. [7]

    Massimiliano Fatica. 2008. CUDA toolkit and libraries. In 2008 IEEE hot chips 20 symposium (HCS). IEEE, 1–22

  7. [8]

    Gérard Favier and André LF de Almeida. 2014. Overview of constrained PARAFAC models. EURASIP Journal on Advances in Signal Processing 2014, 1 (2014), 1–25

  8. [9]

    Sofia Fernandes, Hadi Fanaee-T, and João Gama. 2021. Tensor decomposition for analysing time-evolving social networks: An overview. Artificial Intelligence Review 54, 4 (2021), 2891–2916

Show all 38 references
  1. [10]

    Helal, Jan Laukemann, Fabio Checconi, Jesmin Jahan Tithi, Teresa Ranadive, Fabrizio Petrini, and Jeewhan Choi

    Ahmed E. Helal, Jan Laukemann, Fabio Checconi, Jesmin Jahan Tithi, Teresa Ranadive, Fabrizio Petrini, and Jeewhan Choi. 2021. ALTO: Adaptive Linearized Storage of Sparse Tensors. In Proceedings of the ACM International Conference on Supercomputing (Virtual Event, USA) (ICS ’21...

  2. [11]

    Pieter Hijma, Stijn Heldens, Alessio Sclocco, Ben van Werkhoven, and Henri E. Bal. 2023. Optimization Techniques for GPU Programming. ACM Comput. Surv. 55, 11, Article 239 (March 2023), 81 pages. doi:10.1145/3570638

  3. [12]

    David Hong, Tamara G Kolda, and Jed A Duersch. 2020. Generalized canonical polyadic tensor decomposition. SIAM Rev. 62, 1 (2020), 133–163

  4. [13]

    Yuwang Ji, Qiang Wang, Xuan Li, and Jie Liu. 2019. A Survey on Tensor Tech- niques and Applications in Machine Learning. IEEE Access 7 (2019), 162950– 162990. doi:10.1109/ACCESS.2019.2949814

  5. [14]

    Robin Kobus, Daniel Jünger, Christian Hundt, and Bertil Schmidt. 2019. Gossip: Efficient communication primitives for multi-gpu systems. In Proceedings of the 48th International Conference on Parallel Processing . 1–10

  6. [15]

    Tamara G Kolda and Brett W Bader. 2009. Tensor decompositions and applications. SIAM review 51, 3 (2009), 455–500

  7. [16]

    Sadayappan

    Süreyya Emre Kurt, Saurabh Raje, Aravind Sukumaran-Rajam, and P. Sadayappan

  8. [17]

    Jan Laukemann, Ahmed E Helal, S Anderson, Fabio Checconi, Yongseok Soh, Jesmin Jahan Tithi, Teresa Ranadive, Brian J Gravelle, Fabrizio Petrini, and Jee Choi. 2024. Accelerating Sparse Tensor Decomposition Using Adaptive Linearized Representation. arXiv preprint arXiv:2403.063...

  9. [18]

    Ang Li, Shuaiwen Leon Song, Jieyang Chen, Xu Liu, Nathan Tallent, and Kevin Barker. 2018. Tartan: Evaluating Modern GPU Interconnect via a Multi-GPU Benchmark Suite. In 2018 IEEE International Symposium on Workload Characteri- zation (IISWC). 191–202. doi:10.1109/IISWC.2018.8573483

  10. [19]

    Jiajia Li, Yuchen Ma, and Richard Vuduc. 2018. ParTI!: A parallel tensor infrastruc- ture for multicore CPUs and GPUs. A parallel tensor infrastructure for multicore CPUs and GPUs (2018)

  11. [20]

    Çatalyürek, Jimeng Sun, Kevin Barker, and Richard Vuduc

    Jiajia Li, Bora Uçar, Ümit V. Çatalyürek, Jimeng Sun, Kevin Barker, and Richard Vuduc. 2019. Efficient and Effective Sparse Tensor Reordering. https://github. com/hpcgarage/ParTI

  12. [21]

    Wenqing Lin, Hemeng Wang, Haodong Deng, and Qingxiao Sun. 2024. ScalFrag: Efficient Tiled-MTTKRP with Adaptive Launching on GPUs. In 2024 IEEE In- ternational Conference on Cluster Computing (CLUSTER) . 335–345. doi:10.1109/ CLUSTER59578.2024.00036

  13. [22]

    Julian McAuley. 2021. Recommender Systems and Personalization Datasets. https://cseweb.ucsd.edu/~jmcauley/datasets.html#

  14. [23]

    Helal, Fabio Checconi, Jan Laukemann, Jesmin Jahan Tithi, Yongseok Soh, Teresa Ranadive, Fabrizio Petrini, and Jee W

    Andy Nguyen, Ahmed E. Helal, Fabio Checconi, Jan Laukemann, Jesmin Jahan Tithi, Yongseok Soh, Teresa Ranadive, Fabrizio Petrini, and Jee W. Choi. 2022. Efficient, out-of-Memory Sparse MTTKRP on Massively Parallel Architectures. In Proceedings of the 36th ACM International Conf...

  15. [24]

    Andy Nguyen, Ahmed E Helal, Fabio Checconi, Jan Laukemann, Jesmin Jahan Tithi, Yongseok Soh, Teresa Ranadive, Fabrizio Petrini, and Jee W Choi. 2022. Efficient, out-of-memory sparse MTTKRP on massively parallel architectures. https://github.com/jeewhanchoi/blocked-linearized-c...

  16. [25]

    Sadayappan

    Israt Nisa, Jiajia Li, Aravind Sukumaran-Rajam, Prasant Singh Rawat, Sriram Krishnamoorthy, and P. Sadayappan. 2019. An Efficient Mixed-Mode Represen- tation of Sparse Tensors. In Proceedings of the International Conference for High Performance Computing, Networking, Storage a...

  17. [26]

    Israt Nisa, Jiajia Li, Aravind Sukumaran-Rajam, Prasant Singh Rawat, Sriram Krishnamoorthy, and Ponnuswamy Sadayappan. 2019. An Efficient Mixed-Mode Representation of Sparse Tensors. https://github.com/isratnisa/MM-CSF

  18. [27]

    Sa- dayappan

    Israt Nisa, Jiajia Li, Aravind Sukumaran-Rajam, Richard Vuduc, and P. Sa- dayappan. 2019. Load-Balanced Sparse MTTKRP on GPUs. In 2019 IEEE In- ternational Parallel and Distributed Processing Symposium (IPDPS) . 123–133. doi:10.1109/IPDPS.2019.00023

  19. [28]

    NVIDIA Corporation. 2024. GPUDirect. https://developer.nvidia.com/gpudirect Accessed: 2025-04-30

  20. [29]

    NVIDIA Corporation. 2024. NVIDIA NVLink. https://www.nvidia.com/en- us/design-visualization/nvlink-bridges/ Accessed: 2025-04-30

  21. [30]

    Owens, Mike Houston, David Luebke, Simon Green, John E

    John D. Owens, Mike Houston, David Luebke, Simon Green, John E. Stone, and James C. Phillips. 2008. GPU Computing. Proc. IEEE 96, 5 (2008), 879–899. doi:10.1109/JPROC.2008.917757

  22. [31]

    Jérémie Rappaz, Julian McAuley, and Karl Aberer. 2021. Recommendation on Live-Streaming Platforms: Dynamic Availability and Repeat Consumption. In Proceedings of the 15th ACM Conference on Recommender Systems (Amsterdam, ICPP ’25, September 08–11, 2025, San Diego, CA, USA Sasi...

  23. [32]

    Choi, Jiajia Li, Richard Vuduc, Jongsoo Park, Xing Liu, and George Karypis

    Shaden Smith, Jee W. Choi, Jiajia Li, Richard Vuduc, Jongsoo Park, Xing Liu, and George Karypis. 2017. FROSTT: The Formidable Repository of Open Sparse Tensors and Tools. http://frostt.io/

  24. [33]

    Nitish Srivastava, Hanchen Jin, Shaden Smith, Hongbo Rong, David Albonesi, and Zhiru Zhang. 2020. Tensaurus: A Versatile Accelerator for Mixed Sparse-Dense Tensor Computations. In 2020 IEEE International Symposium on High Performance Computer Architecture (HPCA). 689–702. doi:...

  25. [34]

    Sasindu Wijeratne, Rajgopal Kannan, and Viktor Prasanna. 2021. Reconfigurable Low-latency Memory System for Sparse Matricized Tensor Times Khatri-Rao Product on FPGA. In 2021 IEEE High Performance Extreme Computing Conference (HPEC). 1–7. doi:10.1109/HPEC49654.2021.9622851

  26. [35]

    Sasindu Wijeratne, Rajgopal Kannan, and Viktor Prasanna. 2023. Dynasor: A Dynamic Memory Layout for Accelerating Sparse MTTKRP for Tensor Decompo- sition on Multi-core CPU. In2023 IEEE 35th International Symposium on Computer Architecture and High Performance Computing (SBAC-P...

  27. [36]

    Sasindu Wijeratne, Rajgopal Kannan, and Viktor Prasanna. 2024. Sparse MTTKRP Acceleration for Tensor Decomposition on GPU. In Proceedings of the 21st ACM International Conference on Computing Frontiers . 88–96

  28. [37]

    Sasindu Wijeratne, Ta-Yang Wang, Rajgopal Kannan, and Viktor Prasanna. 2023. Accelerating Sparse MTTKRP for Tensor Decomposition on FPGA. InProceedings of the 2023 ACM/SIGDA International Symposium on Field Programmable Gate Arrays (Monterey, CA, USA) (FPGA ’23). Association f...

  29. [38]

    Cyril Zeller. 2011. CUDA C/C++ Basics. (2011)

  30. [2022]

    In 2022 IEEE International Parallel and Distributed Processing Symposium (IPDPS)

    Sparsity-Aware Tensor Decomposition. In 2022 IEEE International Parallel and Distributed Processing Symposium (IPDPS) . 952–962. doi:10.1109/IPDPS53621. 2022.00097

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.