Pith. sign in

REVIEW 4 major objections 4 minor 60 references

High-Level Big Integer Arithmetic in Futhark for GPUs

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

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

Pith's one-line read High-level code can bring GPU big-integer arithmetic to within about 1.35x of hand-tuned CUDA.

desk verdict Solid systems paper; the real result is Futhark at ~1.35x the speed of hand CUDA, while the 'within 95%' headline is an optimistic estimate that ignores compiler overheads the paper itself documents. read the letter →

arxiv 2607.28897 v1 pith:6AXROVFR submitted 2026-07-30 cs.SC cs.DCcs.PL

Cosmin E. Oancea , Stephen M. Watt This is my paper · ORCID
classification cs.SCcs.DCcs.PL
keywords bigintegerarithmeticGPUFutharkfunctionalarraylanguageregisterallocationcarrypropagationquadraticmultiplicationexactdivision
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

This paper tries to establish that big-integer arithmetic for midsize operands of 2^15 to 2^19 bits can be written in the high-level functional GPU language Futhark and still run close to the speed of hand-tuned CUDA. The authors implement addition, multiplication, and division by composing map, scan, and other data-parallel operators, and they rely on a compiler pass that automatically places arrays in GPU registers. Across the benchmarks, Futhark addition runs at about the same speed or faster than the CUDA version, while multiplication and division typically take about 1.35x as long. The paper argues that most of that gap comes from a missing 128-bit multiplication primitive in Futhark, not from the high-level style itself. The broader claim is that a functional array language, with the right compiler support, can express exact integer arithmetic compactly and still be competitive with low-level GPU code.

What carries the argument

Three algorithmic decompositions carry the argument: the scan-based carry propagation for addition, where per-digit overflow flags are combined by an associative operator so an exclusive prefix sum yields every carry; the quadratic convolution for multiplication, split into balanced forward and reversed work per thread and accumulated in registers; and Watt's exact-arithmetic quotient algorithm for division, adapted to variable precision. The compiler-side mechanism is the register-placement pass (the `#[toregmem]` annotation), which checks that the defining sub-kernel and the reading sub-kernel have matching parallel dimensions and identical outer indexing before allocating an array in regi

What would settle it

Compile a Futhark version that uses a native 128-bit multiply (or an exact emulation that is already accounted for) on a GPU that supports it, and measure the actual ratio to the hand-coded CUDA implementation. If the ratio stays above about 1.3x instead of dropping toward 1.05x, the paper's correction is wrong.

Watch

Extended reading notes

Core claim

The paper's central claim is that the performance cost of using a high-level functional language for GPU big-integer arithmetic is small: for addition, the Futhark version matches or beats a hand-coded CUDA implementation, and for multiplication and quotient it trails by about 1.35x once the missing 128-bit multiply is accounted for. The key enabler is a compiler pass that places arrays in register memory when it can verify that the array is produced and consumed thread-locally; without this pass, shared-memory allocation runs out of fast memory on the largest datasets and is 1.3 to 2.4x slower. With the pass, the Futhark code scales as expected, running 2^13 instances of 2^19-bit multiplica

Load-bearing premise

The headline comparison assumes that replacing Futhark's four-multiplication emulation with a single 128-bit multiply would slow the CUDA baseline by the same 1.33x factor, and that no other Futhark-specific inefficiency remains; if that transfer fails, the 'within 95%' conclusion weakens.

Editorial extensions

If this is right

  • If the claims hold, functional array languages can serve as productive front-ends for GPU libraries of exact arithmetic, since the compiler absorbs memory placement decisions.
  • The register-placement pass is a general compiler utility: any Futhark program whose intermediate arrays are accessed thread-locally should see similar gains, not just big-integer code.
  • Adding a 128-bit multiplication primitive to Futhark would close nearly all of the remaining performance gap for multiplication and division.
  • The scaling results indicate the approach can extend beyond 2^19 bits as long as operands and key intermediates fit in fast memory.
  • A high-level portable implementation could reduce the cost of porting big-integer kernels between GPU vendors.

Reading between the lines

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

  • The paper's 1.33x correction for the missing 128-bit multiply is an estimate transferred from a single microbenchmark; if a native 128-bit multiply were added, the real overhead could differ because the Futhark version also pays for suboptimal barrier elimination and 64-bit index arithmetic.
  • The register-placement idea plausibly extends to other thread-private working-set algorithms, such as NTT-based multiplication or dense polynomial arithmetic, which face the same fast-memory bottleneck.
  • A natural test is to compile the same Futhark code for a non-CUDA GPU and check whether the register-placement path preserves its performance edge over shared-memory allocation on different hardware.
  • The variable-precision multiplication inside the division loop suggests the same framework could be reused for modular arithmetic or exact polynomial division, where m-precision specialisation is also central.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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 reports GPU implementations of block-level addition, multiplication, and division (and, according to the abstract, subtraction) for mid-size integers of 2^15 to 2^19 bits, written in the high-level functional language Futhark. It also introduces a compiler pass, guided by user annotations, that places arrays in register memory. The implementations are benchmarked on an NVIDIA A100 against hand-written CUDA versions from the authors' earlier work (CudaP) and against NVIDIA's CGBN library. The main claim is that high-level Futhark code can approach hand-written CUDA performance: multiplication and division are typically about 1.35x slower, and after applying a 1.33x correction for Futhark's lack of native 128-bit multiplication, the authors infer that Futhark is within about 95% of CudaP on most datasets.

Significance. If the measured claims hold, the paper is a useful contribution to high-level GPU programming: it demonstrates that a functional array language can express non-trivial big-integer arithmetic kernels compactly and reach within a modest factor of hand-written CUDA, and it provides evidence that compiler-directed register placement can yield substantial speedups. The independent comparison against CGBN and the explicit discussion of the 128-bit multiplication gap are strengths. However, the headline 'within 95% of CudaP' claim is an extrapolation rather than a direct measurement, and the paper advertises subtraction without presenting or benchmarking a standalone subtraction implementation. These issues need to be addressed before the central claim is fully credible.

major comments (4)
  1. [Section VI(c), Table II, and Section VI(d), Table III] The conclusion that F-Reg is 'within 95% of CudaP on all datasets' is not a direct measurement. It is obtained by dividing every F-Reg/CudaP slowdown ratio by ~1.33, a factor measured only by porting Futhark's oneConvMul to CudaP on the larger datasets. Two problems: (1) the factor is applied uniformly to all precisions although it was measured only at the largest sizes; (2) the correction removes only the 128-bit multiplication gap, while Section VI(b) itself identifies additional Futhark-specific overheads (sub-optimal barrier elimination and 64-bit index arithmetic) causing 1.04-1.27x slowdowns on 6-Add; these are not corrected in the multiplication/division inference. The 216-bit division row (Table III) is a concrete counterexample: F-Reg/CudaP = 1.53, which after the 1.33 correction is still >1.15, yet the paper excludes this row without justification. I recommend either providing
  2. [Abstract and Sections V-VII] The abstract promises 'addition, subtraction, multiplication and division', and the introduction mentions subtraction from earlier work, but the paper contains no standalone subtraction implementation, evaluation, or table entry. Subtraction appears only as a helper (bsubReg') inside the division step (Figure 6, line 50). This is an inconsistency between the advertised contribution and the actual content. Please either add a subtraction section with benchmarks or revise the abstract and conclusions to list only addition, multiplication, and division.
  3. [Section IV and abstract] The abstract says 'automated placement of arrays in GPU register memory is critical for performance', but the placement is directed by explicit user annotations (#[toregmem(1)], #[glb2reg_only(1)]) and then verified by a compiler pass. This is not fully automatic placement; it is annotation-directed, compiler-checked placement. The distinction matters for the 'high-level and memory-agnostic' narrative, and the paper should qualify the claim accordingly.
  4. [Section VI(a)-(d), Tables I-III] The evaluation is entirely based on runtime ratios, but no experimental methodology is reported: no number of runs, no statement of whether times are medians or means, no variance or standard deviation, and no mention of clock throttling or warmup. GPU benchmarks are noisy, and several key comparisons are close to 1.0 (e.g., 0.98 and 1.05 in Table III). A short methodology paragraph is needed to establish that the reported ratios are reproducible.
minor comments (4)
  1. [Section III] Typo: 'sized-dependent types' should be 'size-dependent types'.
  2. [Table II, 2^19 row] The F-Shm column at precision 2^19 shows '—' for both 1-Mul and Poly, but the text says F-Shm cannot run Poly at 2^18 and higher. Clarify whether 1-Mul at 2^19 was also infeasible or simply not run.
  3. [Section V] In the multiplication formula, the index bounds '0≤i,j,k<m' are written together; it should be clear that k ranges up to 2m-2. This is a small notation issue but may confuse readers.
  4. [References] The paper relies heavily on the authors' earlier work [35] and [48], one of which is 'to appear'. Please state explicitly in the introduction or a contributions subsection what is new in this paper relative to those works: the Futhark port, the compiler pass, and the new measurements.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central performance claims rest on measured comparisons against independent and hand-written baselines, not on fitted inputs or self-referential definitions.

full rationale

The paper is an implementation-and-benchmark study rather than a derivation chain. The central claims — that Futhark versions of multiplication/division run about 1.35x slower than hand-coded CUDA and that addition runs at comparable speed — are supported by directly measured runtimes reported in Tables I-III. The comparisons involve two independent baselines: the authors' earlier CudaP code and NVIDIA's CGBN library, the latter being external. The register-placement compiler pass is evaluated by comparing F-Reg against F-Shm, which is again a direct measurement. The paper does cite its own earlier algorithms ([48] for addition/multiplication, [35] for division) and its own compiler work, but those citations supply algorithm provenance and compiler background, not an unverified premise that forces the conclusion. The 'within 95% of CudaP' statements are extrapolations based on the separately measured ~1.33x slowdown caused by porting Futhark's oneConvMul into CudaP; this is an inference about a missing 128-bit multiply, and one may dispute its generality — the paper itself notes additional Futhark overheads such as sub-optimal barrier elimination and 64-bit index arithmetic, and the 216-bit division row is excluded — but it is not circular. No fitted parameter is renamed as a prediction, no quantity is defined in terms of the result it is used to derive, and no load-bearing uniqueness theorem is imported from the authors' own work. The main risks are correctness/optimism risks about the 1.33x correction factor, not circularity.

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

No free parameters are fitted to data; the performance claims are measurements rather than derived predictions. The axioms are standard mathematical properties of carry propagation, the soundness assumption behind the new compiler pass, and the correctness of a prior published division algorithm. No new physical or mathematical entities are introduced.

assumptions (3)
  • standard math The carry-propagation operator carryBop (encoding overflow and high-bit information) is associative and has a neutral element, so an exclusive scan correctly propagates carries across threads.
    Section V-A and Figure 4 line 24 use scan carryBop 2; correctness depends on associativity of the bit-encoded operation, which is not proven in the paper.
  • domain assumption The Futhark compiler's new register-placement analysis is sound: arrays mapped to registers are only accessed with affine thread-index patterns satisfying the backward-pass checks.
    Section IV describes a forward/backward safety analysis but provides no formal proof or machine-checked implementation, so correctness rests on compiler correctness.
  • domain assumption Watt's quotient algorithm [58] computes the quotient and remainder and has the stated cost of at least five full-precision multiplications.
    Section V-C states the algorithm requires at least five multiplications; correctness is taken from the referenced ISSAC paper rather than re-derived here.

how reviews work

0 comments
Cite this review

Pith. "Pith review of High-Level Big Integer Arithmetic in Futhark for GPUs." pith.science (2026). https://pith.science/paper/6AXROVFR

@misc{pith2026260728897,
  author       = {Pith},
  title        = {Pith review of: High-Level Big Integer Arithmetic in Futhark for GPUs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6AXROVFR}},
  note         = {Machine review of arXiv:2607.28897}
}
abstract

We report on GPU implementations of block-level addition, subtraction, multiplication and division for midsize integers, with operands of $2^{15}$ to $2^{19}$ bits using the high-level functional language Futhark. Comparing with hand-written C++/CUDA versions and CGBN, we identify which functional constructs compile well, where memory placement and sequentialization are effective, and what compiler support is needed. The results show that high-level code can express the algorithms compactly while approaching competitive performance after certain compiler improvements. In particular, we find that automated placement of arrays in GPU register memory is critical for performance.

Figures

Figures reproduced from arXiv: 2607.28897 by the authors.

Figure 1
Figure 1. Futhark constructs & demonstration on shifting a 2D array an elegant expression that is close to the algorithm, while still offering good performance. We refer the reader to [54] for a comparative study of some of these languages. The types and semantics of the constructs used in this paper are illustrated in [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Register Demo: reg is mapped to registers, shm is not. IV. Futhark Compiler Improvements The intragroup kernels created by incremental flattening allocate all intermediates in shared memory because this is always safe, i.e., accessible by any thread. However, this is inefficient for several reasons: (1) registers have better bandwidth and latency than shared memory, and allow graceful degradation by memory spilling,… view at source ↗
Figure 3
Figure 3. In essence, map2 ⊖1 x y computes whether the per-digit addition overflows or results in the maximal uint value. The result (an array of boolean tuples) is passed to an exclusive prefix sum (scanexc ⊙ (false,true)) that propagates the carry for each digit, and the last map applies the corresponding carry to the per-digit addition [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: shows the optimized code for addition. Func￾tion badd is intended to compute ipb instances of n · q digit additions within a cuda block of ipb · n threads, i.e., q is the sequentialization factor. This is hinted by the dependently-sized type [ipb ∗ n][q]uint for the ar…
Figure 5
Figure 5. Figure 5: highlights the code structure of multiplication in Futhark, which follows the strategy proposed in [48]: Function bmulReg (line 43) is intended to receive two register-allocated arguments and also produce their mul￾tiplication result in register memory. The implementa￾…
Figure 6
Figure 6. Figure 6: is intended to give the gist of the Futhark im￾plementation by presenting incomplete code corresponding to the step function that is run in a loop and consists of operations on integers whose precision varies through the loop. Since the algorithm cost is dominated by m…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

60 extracted references · 1 canonical work pages

  1. [1]

    Shape- constrained array programming with size-dependent types

    Lubin Bailly, Troels Henriksen, and Martin Elsman. Shape- constrained array programming with size-dependent types. In Proceedings of the 11th ACM SIGPLAN International Work- shop on Functional High-Performance and Numerical Comput- ing, FHPNC 2023, page 29–41. ACM, 2023

    2023

  2. [2]

    Big integer multiplication with CUDA FFT (cuFFT) library

    Hovhannes Bantikyan. Big integer multiplication with CUDA FFT (cuFFT) library. International Journal of Innovative Re- search in Computer and Communication Engineering , 2:6317– 6325, 2014

    2014

  3. [3]

    Ziogas, Timo Schneider, and Torsten Hoefler

    Tal Ben-Nun, Johannes de Fine Licht, Alexandros N. Ziogas, Timo Schneider, and Torsten Hoefler. Stateful dataflow multi- graphs: A data-centric model for performance portability on heterogeneous architectures. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis , SC ’19. ACM, 2019

    2019

  4. [4]

    Elbert, Rhea George, Jeremy McGibbon, Lukas Trümper, Elynn Wu, Oliver Fuhrer, Thomas Schulthess, and Torsten Hoefler

    Tal Ben-Nun, Linus Groner, Florian Deconinck, Tobias Wicky, Eddie Davis, Johann Dahm, Oliver D. Elbert, Rhea George, Jeremy McGibbon, Lukas Trümper, Elynn Wu, Oliver Fuhrer, Thomas Schulthess, and Torsten Hoefler. Productive per- formance engineering for weather and climate modeling with python. In Proceedings of the International Conference for High Perf...

    2022

  5. [5]

    Blelloch

    Guy E. Blelloch. Scans as primitive parallel operations. In Inter- national Conference on Parallel Processing, ICPP’87, Univer- sity Park, PA, USA, August 1987 , pages 355–362. Pennsylvania State University Press, 1987

    1987

  6. [6]

    Ramanujam, and P

    Uday Bondhugula, Albert Hartono, J. Ramanujam, and P. Sa- dayappan. A practical automatic polyhedral parallelizer and locality optimizer. In Proceedings of the 29th ACM SIGPLAN Conference on Programming Language Design and Implemen- tation, PLDI ’08, pages 101–113. ACM, 2008

    2008

  7. [7]

    Jax: composable transformations of python+ numpy programs, 2018

    James Bradbury, Roy Frostig, Peter Hawkins, Matthew James Johnson, Chris Leary, Dougal Maclaurin, George Necula, Adam Paszke, Jake VanderPlas, Skye Wanderman-Milne, et al. Jax: composable transformations of python+ numpy programs, 2018

    2018

  8. [8]

    CCCL: CUDA C++ Core Libraries,

    CCCL Development Team. CCCL: CUDA C++ Core Libraries,

Show all 60 references
  1. [9]

    Chakravarty, Gabriele Keller, Sean Lee, Trevor L

    Manuel M.T. Chakravarty, Gabriele Keller, Sean Lee, Trevor L. McDonell, and Vinod Grover. Accelerating haskell array codes with multicore gpus. In Procs. Workshop on Declarative Aspects of Multicore Programming, DAMP ’11, page 3–14. ACM, 2011

    2011

  2. [10]

    Big prime field FFT on the GPU

    Liangyu Chen, Svyatoslav Covanov, Davood Mohajerani, and Marc Moreno Maza. Big prime field FFT on the GPU. In Proceedings of the 2017 ACM International Symposium on Symbolic and Algebraic Computation , ISSAC 2017, pages 85–

    2017

  3. [11]

    Chicha, M

    Y. Chicha, M. Lloyd, C. Oancea, and S. M. Watt. Parametric Polymorphism for Computer Algebra Software Components. In Procs. 6th Int. Symposium on Symbolic and Numeric Algo- rithms for Scientific Comput. , pages 119–130. Mirton Publish- ing House, 2004

    2004

  4. [12]

    OpenMP: an industry standard api for shared-memory programming

    Leonardo Dagum and Ramesh Menon. OpenMP: an industry standard api for shared-memory programming. Computational Science & Engineering, IEEE , 5(1):46–55, 1998

    1998

  5. [13]

    The R- LRPD Test: Speculative Parallelization of Partially Parallel Loops

    Francis Dang, Hao Yu, and Lawrence Rauchwerger. The R- LRPD Test: Speculative Parallelization of Partially Parallel Loops. In Int. Par. and Distr. Processing Symp. (PDPS) , pages 20–29, 2002

    2002

  6. [14]

    FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness

    Tri Dao, Dan Fu, Stefano Ermon, Atri Rudra, and Christo- pher Ré. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. In S. Koyejo, S. Mohamed, A. Agarwal, D. Belgrave, K. Cho, and A. Oh, editors, Advances in Neural Information Processing Systems , volu...

    2022

  7. [15]

    van Balen, Gabriele K

    Ivo Gabe de Wolff, David P. van Balen, Gabriele K. Keller, and Trevor L. McDonell. Zero-overhead parallel scans for multi- core cpus. In Proceedings of the 15th International Workshop on Programming Models and Applications for Multicores and Manycores, PMAM ’24, page 52–61. ACM, 2024

    2024

  8. [16]

    Dieguez, Margarita Amor, Ramon Doallo, Akira Nukada, and Satoshi Matsuoka

    Adrian P. Dieguez, Margarita Amor, Ramon Doallo, Akira Nukada, and Satoshi Matsuoka. Efficient high-precision integer multiplication on the GPU. The International Journal of High Performance Computing Applications , 36(3):356–369, 2022

    2022

  9. [17]

    High precision integer addi- tion, subtraction and multiplication with a graphics processing unit

    Niall Emmart and Charles Weems. High precision integer addi- tion, subtraction and multiplication with a graphics processing unit. Parallel Processing Letters , 20(4):293–306, 2010

    2010

  10. [18]

    Com- piling machine learning programs via high-level tracing

    Roy Frostig, Matthew James Johnson, and Chris Leary. Com- piling machine learning programs via high-level tracing. Systems for Machine Learning , pages 23–24, 2018

    2018

  11. [19]

    Grelck and K

    C. Grelck and K. Trojahner. Implicit Memory Management for SaC. In C. Grelck and F. Huch, editors, Implementation and Ap- plication of Functional Languages, 16th Int. Workshop, IFL’04 , pages 335–348. University of Kiel, Institute of Computer Science and Applied Mathematics, 2...

    2004

  12. [20]

    Merging compositions of array skeletons in SAC

    Clemens Grelck and Sven-Bodo Scholz. Merging compositions of array skeletons in SAC. Journal of Parallel Computing , 32(7+8):507–522, 2006

    2006

  13. [21]

    SAC - A functional array language for efficient multi-threaded execution

    Clemens Grelck and Sven-Bodo Scholz. SAC - A functional array language for efficient multi-threaded execution. Int. J. Parallel Program., 34(4):383–427, 2006

    2006

  14. [22]

    High performance stencil code generation with lift

    Bastian Hagedorn, Larisa Stoltzfus, Michel Steuwer, Sergei Gor- latch, and Christophe Dubach. High performance stencil code generation with lift. In Int. Symposium on Code Generation and Optimization (CGO) , CGO 2018, page 100–112. ACM, 2018

    2018

  15. [23]

    Oancea, Anne C

    Mary Hall, Cosmin E. Oancea, Anne C. Elster, Ari Rasch, Sameeran Joshi, Amir Mohammad Tavakkoli, and Richard Schulze. Scheduling language chronology: Past, present, and future. ACM Trans. Archit. Code Optim. , 22(3), 2025

    2025

  16. [24]

    Dense arithmetic over finite fields with the CUMODP library

    Sardar Anisul Haque, Xin Li, Farnam Mansouri, Marc Moreno Maza, Wei Pan, and Ning Xie. Dense arithmetic over finite fields with the CUMODP library. In Mathematical Software – ICMS 2014 , volume 8592 of LNCS, pages 725–732. Springer, 2014

    2014

  17. [25]

    Plain polynomial arithmetic on GPU

    Sardar Anisul Haque and Marc Moreno Maza. Plain polynomial arithmetic on GPU. Journal of Physics: Conference Series , 385:012014, 2012

    2012

  18. [26]

    Apl on gpus: a tail from the past, scribbled in futhark

    Troels Henriksen, Martin Dybdal, Henrik Urms, Anna Sofie Kiehn, Daniel Gavin, Hjalte Abelskov, Martin Elsman, and Cosmin Oancea. Apl on gpus: a tail from the past, scribbled in futhark. In Procs. of Int. Workshop on Functional High- Performance Computing, FHPC 2016, page 38–43...

    2016

  19. [27]

    Troels Henriksen, Ken Friis Larsen, and Cosmin E. Oancea. De- sign and gpgpu performance of futhark’s redomap construct. In Proceedings of the 3rd ACM SIGPLAN International Workshop on Libraries, Languages, and Compilers for Array Program- ming, ARRAY 2016, page 17–24, New Yor...

    2016

  20. [28]

    Troels Henriksen and Cosmin E. Oancea. Bounds checking: An instance of hybrid analysis. In Proceedings of ACM SIGPLAN International Workshop on Libraries, Languages, and Compil- ers for Array Programming, ARRAY’14, page 88–94, New York, NY, USA, 2014. Association for Computing...

    2014

  21. [29]

    Incremental flattening for nested data parallelism

    Troels Henriksen, Frederik Thorøe, Martin Elsman, and Cosmin Oancea. Incremental flattening for nested data parallelism. In Proceedings of the 24th Symposium on Principles and Practice of Parallel Programming, PPoPP ’19, pages 53–67. ACM, 2019

    2019

  22. [30]

    Verifying array properties in pure data-parallel programs

    Nikolaj Hey Hinnerskov, Robert Schenck, and Cosmin Oancea. Verifying array properties in pure data-parallel programs. Proc. ACM Program. Lang., 10(PLDI), June 2026

    2026

  23. [31]

    Hsu and Rodrigo Girão Serrão

    Aaron W. Hsu and Rodrigo Girão Serrão. U-net CNN in APL: exploring zero-framework, zero-library machine learning. In Proc. ARRAY’23, Orlando, USA, 18 June 2023 , pages 22–35. ACM, 2023

    2023

  24. [32]

    A data parallel compiler hosted on the GPU

    Aaron Wen-yao Hsu. A data parallel compiler hosted on the GPU. PhD thesis, Indiana University, 2019

    2019

  25. [33]

    CAMPARY: CUDA multiple precision arith- metic library and applications

    Mioara Joldes, Jean-Michel Muller, Valentina Popescu, and Warwick Tucker. CAMPARY: CUDA multiple precision arith- metic library and applications. In Mathematical Software – ICMS 2016, volume 9725 of LNCS, pages 232–240, Cham, 2016. Springer

    2016

  26. [34]

    Seyong Lee and Jeffrey S. Vetter. Openarc: open accelerator research compiler for directive-based, efficient heterogeneous computing. In Proceedings of the 23rd International Sympo- sium on High-Performance Parallel and Distributed Computing , pages 115–120, 2014

    2014

  27. [35]

    Marchioro, Aske N

    Martin B. Marchioro, Aske N. Raahauge, Marc I. Lovenskjold, Cosmin E. Oancea, and Stephen M. Watt. On GPU imple- mentation for multi-precision integer division. In Proc. 2026 Computer Algebra in Scientific Computing (CASC 2026) , LNCS to appear. Springer-Verlag, 2026

    2026

  28. [36]

    Fast polynomial arithmetic on a GPU

    Marc Moreno Maza and Wei Pan. Fast polynomial arithmetic on a GPU. Journal of Physics: Conference Series , 256:012009, 2010

    2010

  29. [37]

    Static and Dynamic Analyses for Efficient GPU Execution

    Philip Munksgaard. Static and Dynamic Analyses for Efficient GPU Execution. PhD thesis, Department of Computer Science, Faculty of Science, University of Copenhagen, 2023

    2023

  30. [38]

    Dataset sensitive autotuning of multi-versioned code based on monotonic prop- erties

    Philip Munksgaard, Svend Lund Breddam, Troels Henriksen, Fabian Cristian Gieseke, and Cosmin Oancea. Dataset sensitive autotuning of multi-versioned code based on monotonic prop- erties. In Viktória Zsók and John Hughes, editors, Trends in Functional Programming. TFP 2021. Lec...

    2021 doi

  31. [39]

    Memory optimizations in an array language

    Philip Munksgaard, Troels Henriksen, Ponnuswamy Sadayap- pan, and Cosmin Oancea. Memory optimizations in an array language. In Proceedings of the International Conference on High Performance Computing, Networking, Storage and Anal- ysis, SC ’22. IEEE Press, 2022

    2022

  32. [40]

    Implementation of multiple-precision floating-point arithmetic for GPU comput- ing

    Takatoshi Nakayama and Daisuke Takahashi. Implementation of multiple-precision floating-point arithmetic for GPU comput- ing. In Proceedings of the 23rd IASTED International Confer- ence on Parallel and Distributed Computing and Systems , PDCS 2011, pages 343–349. IASTED, 2011

    2011

  33. [41]

    Cooperative groups big numbers (CGBN) library

    NVlabs. Cooperative groups big numbers (CGBN) library. https://github.com/NVlabs/CGBN, 2018

    2018

  34. [42]

    Oancea, Christian Andreetta, Jost Berthold, Alain Frisch, and Fritz Henglein

    Cosmin E. Oancea, Christian Andreetta, Jost Berthold, Alain Frisch, and Fritz Henglein. Financial software on gpus: between haskell and fortran. In Proceedings of the 1st ACM SIGPLAN Workshop on Functional High-Performance Computing , FHPC ’12, page 61–72. Association for Comp...

    2012

  35. [43]

    Oancea and Lawrence Rauchwerger

    Cosmin E. Oancea and Lawrence Rauchwerger. Logical infer- ence techniques for loop parallelization. In Proceedings of the 33rd ACM SIGPLAN Conference on Programming Language Design and Implementation , PLDI ’12, page 509–520, New York, NY, USA, 2012. Association for Computing ...

    2012

  36. [44]

    Oancea and Lawrence Rauchwerger

    Cosmin E. Oancea and Lawrence Rauchwerger. Scalable con- ditional induction variables (civ) analysis. In 2015 IEEE/ACM International Symposium on Code Generation and Optimiza- tion (CGO) , pages 213–224, 2015

    2015

  37. [45]

    Oancea, Jason W

    Cosmin E. Oancea, Jason W. A. Selby, Mark Giesbrecht, and Stephen M. Watt. Distributed models of thread-level specula- tion. In International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA) , pages 920– 927, 2005

    2005

  38. [46]

    Oancea and Stephen M

    Cosmin E. Oancea and Stephen M. Watt. Midsize in- teger arithmetic repository. https://github.com/coancea/ midint-arithmetic/futhark-reg

  39. [47]

    Oancea and Stephen M

    Cosmin E. Oancea and Stephen M. Watt. Domains and ex- pressions: an interface between two approaches to computer algebra. In Proceedings of the 2005 International Symposium on Symbolic and Algebraic Computation , ISSAC ’05, page 261–

    2005

  40. [48]

    Oancea and Stephen M

    Cosmin E. Oancea and Stephen M. Watt. GPU implementations for midsize integer addition and multiplication. In Languages, Compilers, Analysis – From Beautiful Theory to Useful Practice: Essays Dedicated to Alan Mycroft on the Occasion of His Retirement, LNCS 15500, pages 51–79....

    2025

  41. [49]

    Approximate nearest-neighbour fields via massively-parallel propagation-assisted k-d trees

    Cosmin Eugen Oancea, Ties Robroek, and Fabian Gieseke. Approximate nearest-neighbour fields via massively-parallel propagation-assisted k-d trees. In 2020 IEEE International Conference on Big Data (Big Data) , pages 5172–5181, 2020

    2020

  42. [50]

    Robert Schenck, Ola Rønning, Troels Henriksen, and Cosmin E. Oancea. Ad for an array language with nested parallelism. In SC22: International Conference for High Performance Com- puting, Networking, Storage and Analysis , pages 1–15, 2022

    2022

  43. [51]

    Seasonal-trend time series decomposition on graphics processing units

    Dmitry Serykh, Stefan Oehmcke, Cosmin Oancea, Dainius Masiliūnas, Jan Verbesselt, Yan Cheng, Stéphanie Horion, Fabian Gieseke, and Nikolaj Hinnerskov. Seasonal-trend time series decomposition on graphics processing units. In IEEE Int. Conference on Big Data (BigData) , pages 5...

    2023

  44. [52]

    Steuwer, T

    M. Steuwer, T. Koehler, B. Köpcke, and F. Pizzuti. Rise & shine: Language-oriented compiler design, 2022. arXiv:2201.03611 [cs.PL]. https://arxiv.org/abs/2201.03611

    2022 arXiv

  45. [53]

    Towards automatic openmp-aware utilization of fast GPU memory

    Delaram Talaashrafi, Marc Moreno Maza, and Johannes Doer- fert. Towards automatic openmp-aware utilization of fast GPU memory. In Michael Klemm, Bronis R. de Supinski, Jannis Klinkenberg, and Brandon Neth, editors, OpenMP in a Mod- ern World: From Multi-device Support to Meta ...

    2022

  46. [54]

    Hsu, Gabriele K

    David van Balen, Tiziano De Matteis, Clemens Grelck, Troels Henriksen, Aaron W. Hsu, Gabriele K. Keller, Thomas Koop- man, Trevor L. McDonell, Cosmin Oancea, Sven-Bodo Scholz, Artjoms Sinkarovs, Tom Smeding, Phil Trinder, Ivo Gabe de Wolff, and Alexandros N. Ziogas. Comparing ...

    2025 arXiv

  47. [55]

    van den Haak, Trevor L

    Lars B. van den Haak, Trevor L. McDonell, Gabriele K. Keller, and Ivo Gabe de Wolff. Accelerating nested data parallelism: Preserving regularity. In Maciej Malawski and Krzysztof Rzadca, editors, Euro-Par 2020: Parallel Processing , pages 426–442, Cham, 2020. Springer Internat...

    2020

  48. [56]

    Graph rewriting semantics for functional programming lan- guages

    Marko van Eekelen, Sjaak Smetsers, and Rinus Plasmeijer. Graph rewriting semantics for functional programming lan- guages. In Dirk van Dalen and Marc Bezem, editors, Computer Science Logic, pages 106–128, Berlin, Heidelberg, 1997. Springer Berlin Heidelberg

    1997

  49. [57]

    Loop and data transformations for sparse matrix code

    Anand Venkat, Mary Hall, and Michelle Strout. Loop and data transformations for sparse matrix code. In ACM SIGPLAN Conf. on Prog. Lang. Design and Impl. (PLDI) , PLDI ’15, page 521–532. ACM, 2015

    2015

  50. [58]

    Stephen M. Watt. Efficient generic quotients using exact arith- metic. In ISSAC ’23, pages 535–544. ACM, 2023

    2023

  51. [59]

    A data-centric approach to extreme-scale ab initio dissipative quantum transport simulations

    Alexandros Nikolaos Ziogas, Tal Ben-Nun, Guillermo Indale- cio Fernández, Timo Schneider, Mathieu Luisier, and Torsten Hoefler. A data-centric approach to extreme-scale ab initio dissipative quantum transport simulations. In Proceedings of the International Conference for High...

    2019

  52. [2023]

    https://github.com/NVIDIA/cccl

Pith tools

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