Pith. sign in

REVIEW 4 major objections 4 minor 32 references

MAP-UOT: A Memory-Efficient Approach to Unbalanced Optimal Transport Implementation

T0 review · 4 major / 4 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read Unbalanced optimal transport is memory-bound, and a single fused rescaling pass that reads and writes the matrix once per iteration delivers average 1.9x-2.2x speedups over prior CPU solvers and up to 3.5x on a GPU.

desk verdict A useful cache-blocked Sinkhorn implementation, but the claimed memory-traffic advantage does not survive a close look at POT's vector-scaling baseline. read the letter →

arxiv 2412.11079 v1 pith:JFX7377X submitted 2024-12-15 cs.DC

Chengyu Sun , Jinyu Hu , Hong Jiang This is my paper · ORCID
classification cs.DC
keywords unbalancedoptimaltransportSinkhornalgorithmmemory-boundoptimizationRooflinemodelcachelocalityGPUtilingdistributedmemoryscalabilityrowandcolumnrescaling
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

The paper argues that the Sinkhorn solver for unbalanced optimal transport (UOT) is limited by memory bandwidth, not arithmetic, and that a memory-aware implementation can remove that limit. It establishes this with a Roofline analysis showing an operational intensity near 1/4, far below the break-even point of modern CPUs and GPUs, and with cache-miss and throughput measurements. On that basis it proposes MAP-UOT, which interleaves the alternating row and column rescaling steps into a single cache-friendly double-loop, so one iteration reads and writes the matrix once instead of making two separate passes. The payoff, if the claim holds, is a roughly 2x average speedup over state-of-the-art CPU implementations and even larger gains on GPUs, plus better scalability on distributed-memory systems.

What carries the argument

The load-bearing mechanism is an interleaved double-loop that merges the two rescaling passes of a Sinkhorn iteration. While walking a row, the loop applies the precomputed column factor to each element and accumulates the row sum; once the row sum is known, the same row is visited again to apply the row factor while accumulating partial column sums into a per-thread scratch array. This makes every matrix access row-contiguous and cuts the per-iteration memory flow to the theoretical minimum of one read and one write of the matrix (when the row or matrix stays cached), replacing the baseline's two separate passes over the data. On GPUs the same principle appears as tiled kernels that load blocks into shared memory, accumulate column sums with atomic adds, and perform row reductions with warp shuffles and 128-bit vector accesses.

What would settle it

Measure DRAM traffic during one Sinkhorn iteration of each implementation on the same matrix using hardware performance counters; if the baseline moves fewer bytes than MAP-UOT or less than about double its traffic, the memory-traffic explanation and the predicted speedup ceiling both need revision.

Watch

Extended reading notes

Core claim

The central discovery is that the bottleneck in Sinkhorn-style UOT iterations is memory traffic: each element of the cost matrix is touched several times per iteration, in patterns that defeat cache locality. MAP-UOT restructures the iteration so that the column rescaling for a row is done at the same time as accumulating that row's sum, and the row rescaling is done at the same time as accumulating partial column sums. This condenses the work into one traversal per iteration, makes all accesses row-contiguous, and brings DRAM traffic to the theoretical minimum of one read and one write of the matrix per iteration when the matrix fits in cache. The implementation then specializes this idea for CPU (loop unrolling, AVX2 vectorization) and GPU (tiled blocks, shared memory, 128-bit loads/stores, warp-shuffle reductions) platforms.

Load-bearing premise

The claimed speedups rest on the premise that the baseline implementations move roughly twice as much memory per iteration as MAP-UOT's single fused pass, a premise that fails if a baseline already applies rescaling factors without rewriting the matrix in place, in which case the comparison no longer isolates the memory-traffic reduction.

Editorial extensions

If this is right

  • In the four representative applications profiled, where UOT consumes 62-99% of end-to-end time, solving the solver bottleneck transfers directly to application-level speedups.
  • The single-pass iteration approaches the Roofline ceiling for memory-bound UOT, so further large gains must come from reducing iteration count or raising memory bandwidth rather than from arithmetic tuning.
  • The row-partitioned parallelization is free from false sharing and scales to many threads and to distributed-memory nodes with an all-reduce replacing the per-thread column-sum accumulation.
  • The relative benefit is largest for matrices whose rows stay resident in cache, and the gains persist for rectangular matrix shapes.

Reading between the lines

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

  • If the memory-traffic premise is right, the same fused rescaling pattern should transfer to balanced entropic optimal transport and other alternating scaling algorithms; the gain would shrink for implementations that already apply scaling factors without rewriting the kernel matrix.
  • A definitive test of the mechanism is to count DRAM bytes moved per iteration with hardware performance counters; if a baseline with fused vector scaling already approaches the one-read one-write minimum, the reported speedups would be attributed to implementation details rather than to the traffic reduction.
  • The paper's future direction of sparse matrices is not automatic: fusing the rescaling passes requires the row and column sums of the scaled matrix, which, depending on the sparsity pattern, may force dense scratch arrays or extra traversals unless a specialized sparse traversal is designed.
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 / 4 minor

Summary. The paper proposes MAP-UOT, a memory-oriented implementation of the entropic unbalanced optimal transport (UOT) Sinkhorn solver. The authors argue that UOT is memory-bound, model a naive in-place row/column rescaling implementation with a Roofline analysis, and then introduce a fused 'interweaved' traversal that, in their account, reduces each iteration to one read and one write of the cost matrix. They report single-threaded, multithreaded, GPU, and supercomputer speedups against POT and COFFEE, together with cache-miss, throughput, and memory-consumption measurements. The empirical evaluation is broad, covering CPU, GPU, MPI, and an end-to-end application.

Significance. If the central traffic-reduction claim were correct, this would be a useful systems contribution: a clear architectural rationale for a 2-3x improvement over a widely used library. The paper also contains a substantial engineering effort: CPU vectorization and thread partitioning, GPU tiling and shared-memory reductions, MPI scaling, and a real domain-adaptation application. The cache-miss and throughput measurements are useful evidence that access-pattern optimization matters for this kernel. However, the paper's theoretical framework is not matched to the actual baseline used in the experiments, and the algorithmic description contradicts the 'single read and single write' claim in an important way. The empirical speedups may well be real, but the paper's stated mechanism does not currently establish that MAP-UOT reduces memory traffic relative to POT's vector-scaling Sinkhorn. The contribution is therefore defensible after a major revision that re-derives the memory-traffic argument and aligns the pseudocode with the implementation.

major comments (4)
  1. [Section 3.1, Eq. (1); Section 5.2.1] The Roofline model counts Q = 6*M*N per iteration for the pedagogical in-place implementation shown in Figure 1. The experimental SOTA baseline, however, is POT's sinkhorn_unbalanced, which uses vector scaling factors and computes matrix-vector products without rewriting the kernel matrix in place. Its per-iteration DRAM traffic is approximately two reads of the matrix (for the forward and transpose matrix-vector products), not 6*M*N of read-plus-write traffic. Consequently, the claimed 'theoretical minimum of 2*M*N is a 2-3x reduction over SOTA' does not follow from the Roofline analysis for the POT baseline. The measured speedups should be attributed to cache locality and access-pattern improvements, or the comparison should be made against a baseline that actually rescales the matrix in place.
  2. [Section 4.1.1, Algorithm 1; Section 3.1] Algorithm 1 traverses each row twice per iteration: Lines 7-8 apply the column factor and accumulate the row sum, and Lines 11-13 apply the row factor and accumulate the next column sum. Each element is therefore read and written twice per iteration at the cache-line level. The one-read-one-write claim holds only when the row remains cache-resident between the two passes; the paper states this condition for the CPU design but presents the claim unconditionally in the abstract and in Section 3.1. The GPU implementation in Section 4.2 describes part 2 and part 4 as separate kernels, so it appears to incur 4*M*N DRAM traffic per iteration, not 2*M*N. Please specify precisely which traffic quantity is being counted, for which implementation, and under which cache assumptions.
  3. [Section 4.1.1, Algorithm 1, Lines 1-3 and 16-20] The update of the column rescaling factors is inconsistent with the prose. The text says Factorcol is precomputed as pow(CPD[j]/colsum_j, fi), but Line 2 overwrites Factorcol[j] with pow(CPD[j]/Factorcol[j], fi), and Lines 16-20 accumulate NextSumcol entries into Factorcol[j]. Neither operation yields the next iteration's factor, which should be pow(CPD[j]/new_colsum_j, fi) computed from the accumulated column sums. As written, this pseudocode cannot be the algorithm that produced the reported results. Please correct the notation or the update rule.
  4. [Section 5.2.1 and Section 5.3.1] The comparison with POT mixes implementation layers: MAP-UOT is a C/CUDA library while POT's CPU and GPU paths are Python/Numpy and Python/CuPy. For small matrices, Python call overhead and per-operation dispatch can be a significant fraction of runtime, and the paper reports that improvements are largest for small matrices. Please report either isolated kernel times (excluding Python overhead) or clearly state that the numbers are end-to-end times, and confirm that the same convergence criterion and number of iterations are used in all implementations. The COFFEE comparison mitigates this on CPU, but the GPU comparison remains affected.
minor comments (4)
  1. [Figures 2-5 and 9-17] Several figures have axis labels, legends, and annotations that render as '/uni...' placeholder strings, making them unreadable in the submitted PDF; these must be regenerated with embedded fonts.
  2. [Section 2.1] The coefficients er and ep are used in the definition of fi in Figure 1 but are not defined in the text; please define them in Section 2.1.
  3. [Section 4.2.2, Algorithm 2] The loading of SmemFactorrow and the exact mapping of the (Ty*Ny) x Tx submatrix to threads are not fully specified; please make the indexing explicit so the kernel is reproducible.
  4. [Section 5] The paper does not provide a link to the source code or an artifact; given the dependence of the results on implementation details such as tiling parameters and vectorization, please include a code availability statement.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the Roofline analysis is a hardware-based bound and the speedups are direct measurements; the only self-reference is a non-load-bearing comparison with the authors' earlier COFFEE baseline.

full rationale

The paper's central claim is an empirical implementation result: MAP-UOT is measured to run faster than POT and COFFEE on specific CPUs, GPUs and a supercomputer. The Roofline analysis in Section 3.1 is a standard bound computed from measured peak performance and bandwidth, not a fitted model used to generate the speedups. The theoretical minimum Q = 2MN is explicitly conditional on an in-place formulation in which the matrix must be read and written once per iteration; it is a lower bound for that formulation, not a derived prediction validated by the measurements. No parameter is fitted to a subset of data and then renamed as a prediction. The only self-citation is to COFFEE [25], the first author's prior work, used as a comparison baseline and as a source of application profiling figures; this is legitimate independent, externally measured support and is not load-bearing for the algorithmic claim. A reviewer concern that POT's actual sinkhorn_unbalanced keeps vector scaling factors and does not rewrite the kernel would, if correct, weaken the paper's memory-traffic explanation, but it is a baseline-validity and correctness issue, not a circular-derivation issue, and cannot be established from the paper text alone. Therefore no circular step meeting the quotation-and-reduction standard is present.

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

The central speedup claim depends on the assumption that the in-place matrix rescaling formulation is the appropriate baseline and that one read plus one write per element per iteration is the memory traffic lower bound. This is natural for the authors' own framework but not for POT's vector-scaling Sinkhorn. The only free parameters are the GPU tiling choices, selected by grid search. No new physical or mathematical entities are introduced.

free parameters (2)
  • GPU tiling parameters (Tx, Ny) for part 2 = Tx=32, Ny=8 (part 2); Tx=128, Ny=8 (part 4), Ty=2
    Selected experimentally in Figure 8 as the best performing configuration on RTX 3090 Ti for a 10240x10240 matrix; no sensitivity analysis across sizes or platforms is reported.
  • AVX2 loop unroll factor on CPU = not reported
    The text says loops are unrolled and AVX2 is used, but the unroll factor and scheduling details are not specified.
assumptions (4)
  • domain assumption The UOT algorithm is correctly represented by in-place row and column rescaling of the matrix A.
    Section 2.1 defines the baseline as iterating row and column rescaling of A. POT's actual sinkhorn_unbalanced uses vector scaling factors and does not modify A; this representation may not match the SOTA baseline.
  • domain assumption A single Sinkhorn iteration requires at least one read and one write of the full matrix (Q_min = 2*M*N).
    Section 3.1 states the theoretical minimum Q is 2*M*N because one read and one write of A are required. This ignores vector-scaling Sinkhorn implementations that never write the matrix.
  • ad hoc to paper Fusing column and row rescaling does not change the convergence or final solution of the UOT algorithm.
    The paper asserts the order of rescaling does not affect the theoretical limit (Section 2.1 citing [17]) but provides no numerical validation that MAP-UOT's interleaved order converges to the same transport plan with the same number of iterations.
  • standard math The Roofline model operation counts (ADD, DIV, MUL, CALL each count as one) are representative of actual work.
    Section 3.1 uses this simplification to derive I = (M*N+M+N)/(4*M*N), which is a modeling assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MAP-UOT: A Memory-Efficient Approach to Unbalanced Optimal Transport Implementation." pith.science (2026). https://pith.science/paper/JFX7377X

@misc{pith2026241211079,
  author       = {Pith},
  title        = {Pith review of: MAP-UOT: A Memory-Efficient Approach to Unbalanced Optimal Transport Implementation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JFX7377X}},
  note         = {Machine review of arXiv:2412.11079}
}
read the original abstract

Unbalanced optimal transport (UOT) has been widely used as a fundamental tool in many application domains, where it often dominates the application running time. While many researchers have proposed various optimizations for UOT, few have attempted to optimize it from a computer architecture's perspective. In this paper, we first study the performance bottlenecks of UOT through a series of experiments, which reveals that UOT is heavily memory-bound. Guided by these findings, we propose MAP-UOT, a Memory-efficient APproach to the implementation and optimization of UOT on CPU and GPU platforms. Our experimental evaluations show that the proposed strategy consistently and significantly outperforms the state-of-the-art (SOTA) implementations. Specifically, it provides single-threaded performance improvement over POT/COFFEE by up to 2.9X/2.4X, with an average of 1.9X/1.6X. At the same time, it provides parallelized performance improvement over POT/COFFEE by up to 2.4X/1.9X, with an average of 2.2X/1.8X, on Intel Core i9-12900K; and over POT by up to 3.5X, with an average of 1.6X, on Nvidia GeForce RTX 3090 Ti. MAP-UOT also shows great performance improvement on the Tianhe-1 supercomputer.

Figures

Figures reproduced from arXiv: 2412.11079 by the authors.

Figure 1
Figure 1. Implementation of the UOT algorithm with C language and Python language implementation demos. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The proportion of time occupied by the UOT algorithm among four applications (top) [25] and the proportion [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Global memory Roofline model of UOT on 12900K and RTX 3090 Ti, respectively. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (14 more)
Figure 4
Figure 4. Figure 4: L1 and L2 cache miss rate of UOT on 12900K with Numpy implementation. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Global load/store throughput of UOT on RTX 3090 Ti with Cupy implementation. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Schematic of MAP-UOT on multi/many-cores CPU. [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Schematic of MAP-UOT on GPU. 4.2.3 Implementation Details of Part ⃝4 The design of part ⃝4 and part ⃝2 have similarities, we will focus on the differences. In terms of tiling strategy, we have arranged 1-D blocks and each block consists of T x threads. Then for each bl…
Figure 8
Figure 8. Figure 8: Running time (ms) of MAP-UOT over different parameters on RTX 3090 Ti. [PITH_FULL_IMAGE:figures/full_fig_p012_8.png]
Figure 9
Figure 9. Figure 9: Single-threaded performance of UOT on 12900K. [PITH_FULL_IMAGE:figures/full_fig_p012_9.png]
Figure 10
Figure 10. Figure 10: Scalability of multiple threads for UOT. The legend ’T’ refers to the number of threads, ’M’ refers to [PITH_FULL_IMAGE:figures/full_fig_p013_10.png]
Figure 11
Figure 11. Figure 11: Reduction of cache misses over POT and COFFEE for UOT. [PITH_FULL_IMAGE:figures/full_fig_p013_11.png]
Figure 12
Figure 12. Figure 12: L1 cache miss rate on different number of threads of MAP-UOT. The legend ’T’ refers to the number of [PITH_FULL_IMAGE:figures/full_fig_p014_12.png]
Figure 13
Figure 13. Figure 13: Performance of UOT on RTX 3090 Ti. of size M = N = 20480. We set two different cluster configurations, 8 processors per node and 12 processors per node, to demonstrate applicability. The results are normalized by the performance of single-threaded POT execution. The e…
Figure 14
Figure 14. Figure 14: Increment of global throughput over POT for UOT. [PITH_FULL_IMAGE:figures/full_fig_p016_14.png]
Figure 15
Figure 15. Figure 15: Peak memory consumption during computation for UOT. [PITH_FULL_IMAGE:figures/full_fig_p016_15.png]
Figure 16
Figure 16. Figure 16: Scalability of UOT on Tianhe-1 supercomputer. [PITH_FULL_IMAGE:figures/full_fig_p016_16.png]
Figure 17
Figure 17. Figure 17: Performance of UOT on the domain adaptation application. [PITH_FULL_IMAGE:figures/full_fig_p017_17.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

32 extracted references · 28 canonical work pages

  1. [1]

    Altschuler, F

    J. Altschuler, F. Bach, A. Rudi, and J. Niles-Weed. Massively scalable sinkhorn distances via the nyström method. Advances in neural information processing systems, 32, 2019

    work page 2019

  2. [2]

    Arjovsky, S

    M. Arjovsky, S. Chintala, and L. Bottou. Wasserstein generative adversarial networks. In International conference on machine learning, pages 214–223. PMLR, 2017

    work page 2017

  3. [3]

    Bonneel and D

    N. Bonneel and D. Coeurjolly. Spot: sliced partial optimal transport. ACM Transactions on Graphics (TOG), 38(4):1–13, 2019. /uni00000014/uni00000019/uni00000016/uni00000015/uni00000019/uni00000017/uni00000014/uni00000015/uni0000001b/uni00000015/uni00000018/uni00000019/uni00000018/uni00000014/uni00000015 /uni00000031/uni00000058/uni00000050/uni00000045/uni...

    work page 2019

  4. [4]

    Cheng, M

    J. Cheng, M. Grossman, and T. McKercher. Professional CUDA c programming. John Wiley & Sons, 2014

    work page 2014

  5. [5]

    Chizat, G

    L. Chizat, G. Peyré, B. Schmitzer, and F.-X. Vialard. Scaling algorithms for unbalanced optimal transport problems. Mathematics of Computation, 87(314):2563–2609, 2018

    work page 2018

  6. [6]

    Chizat, G

    L. Chizat, G. Peyré, B. Schmitzer, and F.-X. Vialard. Unbalanced optimal transport: Dynamic and kantorovich formulations. Journal of Functional Analysis, 274(11):3090–3123, 2018

    work page 2018

  7. [7]

    Courty, R

    N. Courty, R. Flamary, and D. Tuia. Domain adaptation with regularized optimal transport. In Joint European Conference on Machine Learning and Knowledge Discovery in Databases, pages 274–289. Springer, 2014

    work page 2014

  8. [8]

    M. Cuturi. Sinkhorn distances: Lightspeed computation of optimal transport. Advances in neural information processing systems, 26, 2013

    2013

Show all 32 references
  1. [9]

    Ding and S

    N. Ding and S. Williams. An instruction roofline model for gpus. IEEE, 2019

    2019

  2. [10]

    Ferradans, N

    S. Ferradans, N. Papadakis, G. Peyré, and J.-F. Aujol. Regularized discrete optimal transport. SIAM Journal on Imaging Sciences, 7(3):1853–1882, 2014

    2014

  3. [11]

    Flamary, N

    R. Flamary, N. Courty, A. Gramfort, M. Z. Alaya, A. Boisbunon, S. Chambon, L. Chapel, A. Corenflos, K. Fatras, N. Fournier, L. Gautheron, N. T. Gayraud, H. Janati, A. Rakotomamonjy, I. Redko, A. Rolet, A. Schutz, V . Seguy, D. J. Sutherland, R. Tavenard, A. Tong, and T. Vayer....

    2021

  4. [12]

    Flamary, N

    R. Flamary, N. Courty, D. Tuia, and A. Rakotomamonjy. Optimal transport for domain adaptation. IEEE Trans. Pattern Anal. Mach. Intell, 1, 2016

    2016

  5. [13]

    Frogner, C

    C. Frogner, C. Zhang, H. Mobahi, M. Araya, and T. A. Poggio. Learning with a wasserstein loss. Advances in neural information processing systems, 28, 2015

    2015

  6. [14]

    Genevay, M

    A. Genevay, M. Cuturi, G. Peyré, and F. Bach. Stochastic optimization for large-scale optimal transport.Advances in neural information processing systems, 29, 2016

    2016

  7. [15]

    Gramfort, G

    A. Gramfort, G. Peyré, and M. Cuturi. Fast optimal transport averaging of neuroimaging data. In International Conference on Information Processing in Medical Imaging, pages 261–272. Springer, 2015

    2015

  8. [16]

    Gulrajani, F

    I. Gulrajani, F. Ahmed, M. Arjovsky, V . Dumoulin, and A. C. Courville. Improved training of wasserstein gans. Advances in neural information processing systems, 30, 2017

    2017

  9. [17]

    P. A. Knight. The sinkhorn–knopp algorithm: convergence and applications. SIAM Journal on Matrix Analysis and Applications, 30(1):261–275, 2008

    2008

  10. [18]

    Kusner, Y

    M. Kusner, Y . Sun, N. Kolkin, and K. Weinberger. From word embeddings to document distances. InInternational conference on machine learning, pages 957–966. PMLR, 2015

    2015

  11. [19]

    J. Lee, N. P. Bertrand, and C. J. Rozell. Parallel unbalanced optimal transport regularization for large scale imaging problems. arXiv preprint arXiv:1909.00149, 2019

    1909 arXiv

  12. [20]

    G. Pai, J. Ren, S. Melzi, P. Wonka, and M. Ovsjanikov. Fast sinkhorn filters: Using matrix scaling for non-rigid shape correspondence with functional maps. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, pages 384–393, 2021

    2021

  13. [21]

    K. Pham, K. Le, N. Ho, T. Pham, and H. Bui. On unbalanced optimal transport: An analysis of sinkhorn algorithm. In International Conference on Machine Learning, pages 7673–7682. PMLR, 2020

    2020

  14. [22]

    R. Sato, M. Yamada, and H. Kashima. Fast unbalanced optimal transport on a tree.Advances in neural information processing systems, 33:19039–19051, 2020

    2020

  15. [23]

    Schiebinger, J

    G. Schiebinger, J. Shu, M. Tabaka, B. Cleary, V . Subramanian, A. Solomon, J. Gould, S. Liu, S. Lin, P. Berube, et al. Optimal-transport analysis of single-cell gene expression identifies developmental trajectories in reprogramming. Cell, 176(4):928–943, 2019. 17 A PREPRINT - ...

    2019

  16. [24]

    R. Smith. Performance of mpi codes written in python with numpy and mpi4py. In 2016 6th Workshop on Python for High-Performance and Scientific Computing (PyHPC), pages 45–51. IEEE, 2016

    2016

  17. [25]

    C. Sun, H. Luo, H. Jiang, J. Zhang, and K. Li. Coffee: Cross-layer optimization for fast and efficient executions of sinkhorn-knopp algorithm on hpc systems. IEEE Transactions on Parallel and Distributed Systems, 2023

    2023

  18. [26]

    Thakur, R

    R. Thakur, R. Rabenseifner, and W. Gropp. Optimization of collective communication operations in mpich. The International Journal of High Performance Computing Applications, 19(1):49–66, 2005

    2005

  19. [27]

    J. J. Tithi and F. Petrini. A new parallel algorithm for sinkhorn word-movers distance and its performance on piuma and xeon cpu. arXiv preprint arXiv:2107.06433, 2021

    2021 arXiv

  20. [28]

    F. Wang, H. Jiang, K. Zuo, X. Su, J. Xue, and C. Yang. Design and implementation of a highly efficient dgemm for 64-bit armv8 multi-core processors. In 2015 44th International Conference on Parallel Processing, pages 200–209. IEEE, 2015

    2015

  21. [29]

    J. Wang, P. Wang, and P. Shafto. Sequential cooperative bayesian inference. In International Conference on Machine Learning, pages 10039–10049. PMLR, 2020

    2020

  22. [30]

    Williams, A

    S. Williams, A. Waterman, and D. Patterson. Roofline: an insightful visual performance model for multicore architectures. Communications of the ACM, 52(4):65–76, 2009

    2009

  23. [31]

    K. D. Yang and C. Uhler. Scalable unbalanced optimal transport using generative adversarial networks. arXiv preprint arXiv:1810.11447, 2018

    2018 arXiv

  24. [32]

    X. Yang, X. Liao, W. Xu, J. Song, Q. Hu, J. Su, L. Xiao, K. Lu, Q. Dou, J. Jiang, et al. Th-1: China’s first petaflop supercomputer. Frontiers of Computer Science in China, 4:445–455, 2010. 18

    2010

Pith tools

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