Pith. sign in

REVIEW 2 major objections 6 minor 35 references

Code Generation for Near-Roofline Finite Element Actions on GPUs from Symbolic Variational Forms

T0 review · 2 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read The paper shows that automatically scheduled GPU kernels for finite-element actions exceed 50% of the modeled roofline in 65% of a 56-case test suite, on two GPU generations.

desk verdict A competent, honest systems paper with a real contribution; the shared-memory-unit roofline concern is real but actually makes the reported 65% conservative, not inflated. read the letter →

arxiv 2506.17471 v1 pith:QGODFBLR submitted 2025-06-20 cs.DC cs.MScs.NAcs.PFmath.NA

Kaushik Kulkarni , Andreas Klöckner This is my paper · ORCID
classification cs.DCcs.MScs.NAcs.PFmath.NA MSC 65N3065Y0568N20
keywords GPUcodegenerationfiniteelementmethodvariationalformsrooflinemodelauto-tuninglooptilingmatrix-freeoperatorssymboliccompilation
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 claims that the central performance question for finite-element operators on GPUs — how to divide work across threads, how much state to keep per thread, and how much to stage through shared memory — can be answered by a compiler automatically, starting from nothing but the symbolic weak form. The approach generates a family of transformed kernels spanning two strategies, single-cell-per-work-item and parametric multi-level tiling, prunes the family with four structural constraints, and ranks the survivors with a heuristic cost model that estimates execution time from global and local memory traffic. Only the top nine ranked candidates are actually run and timed. On a suite of 56 operator scenarios in 2D and 3D covering mass, Laplace, Helmholtz, elasticity, and hyperelasticity, the chosen kernels reach more than 50% of a modeled roofline in 65% of cases on both an Nvidia Titan V and a Tesla K40c. The practical payoff is that a Firedrake user who writes a variational form in the UFL symbolic language gets a near-peak GPU kernel for most problems without hand tuning.

What carries the argument

The load-bearing object is the schedule space together with the cost model that ranks it. In the multi-level tiling strategy every kernel is parameterized by the quadrature tile $T_Q$, evaluation-phase tile rows and columns $T_r^e$, $T_c^e$, quadrature-phase tiles $T_r^q$, $T_c^q$, the number of cells per work group $N_c$, and work-items per cell $N_{WI}$. Reference derivative matrices $\Phi$ and $\Psi$ are prefetched into a single local-memory buffer whose size is the maximum of the per-stage tile products, made possible because the live ranges of the prefetched matrices are pairwise disjoint; a barrier-separated pipeline carries the evaluation-stage results into the quadrature stage. The cost model estimates time as $t_{\text{heur}} = \text{global accesses}/\beta^{\text{model}}_{\text{global}} + \text{local accesses}/\beta^{\text{model}}_{\text{local}}$, where both modeled bandwidths grow linearly with the number of resident subgroups and saturate at SHOC-measured peaks, and the effective resident-subgroup count is discounted by predication and SIMD efficiency. The roofline used as the performance target is the minimum of three ceilings — global bandwidth, local bandwidth, and peak FLOPS — assuming all latency is hidden.

What would settle it

A decisive check is to run a sample of the 56 kernels under hardware performance counters and compare the bottleneck the cost model predicts — global traffic, local traffic, or FLOPS — with the measured dominant stall. If many kernels the model calls bandwidth-bound are actually bound by barrier waits, register spills, or instruction issue, the modeled roofline overstates what the hardware can deliver and the 65% figure is inflated. A second check is whether the empirically best candidate ever falls outside the top nine kernels the cost model ranks first; if it does, the ranking premise fails even though the final kernels may still be fast.

Watch

Extended reading notes

Core claim

The paper's central claim is that near-roofline GPU performance for matrix-free finite-element action operators is reachable by transformation-based code generation plus a cheap search. The kernel for an operator is first produced from its UFL form by a form compiler, then rewritten through a constrained schedule space: a single-cell-per-work-item variant for low state-space loads, and a parametric multi-level tiling that separates evaluation from quadrature via array expansion and loop distribution, tiles the quadrature loop, prefetches the reference derivative matrices $\Phi$ and $\Psi$ into a shared local-memory buffer, and spreads a cell's inner products across a two-dimensional work group of $N_c \times N_{WI}$ work-items. Four constraints keep the space enumerable — tile sizes that allocate minimal local memory for a given synchronization count, $\eta_{\text{alias}} \ge 0.8$, $\eta_{\text{simd}} \ge 0.97$, and $N_c N_{WI} \le 256$ — and a cost model ranks candidates by modeled execution time, so only the top nine are timed. The measured outcome is that the selected kernels achieve more than 50% of the roofline $F_{\text{roofline}} = \min(AI_{\text{global}}\beta^{\text{peak}}_{\text{global}},\, AI_{\text{local}}\beta^{\text{peak}}_{\text{local}},\, F_{\text{peak}})$, where the $AI$ terms are global and local arithmetic intensities, in 65% of the 56 test cases, with the fraction essentially the same on Kepler and Volta microarchitectures.

Load-bearing premise

The headline 65% figure is measured against a roofline that assumes a kernel's throughput is simply the minimum of three ceilings — global memory bandwidth, local memory bandwidth, and raw arithmetic rate — with all memory latency completely hidden.

Editorial extensions

If this is right

  • A Firedrake user who supplies only the UFL weak form can expect a majority of operators to run within a factor of two of the modeled GPU peak, with no hand scheduling.
  • Preparation stays cheap: because only the top nine ranked candidates are timed, auto-tuning fits naturally into a normal compile-and-run workflow.
  • The same schedule space and cost model deliver a comparable 65% fraction on two different GPU microarchitectures, so the method transfers across hardware generations without re-derivation.
  • The two failure regimes are explicitly located: low-order $P_1$ kernels are limited by the global DOF layout's poor coalescing, and high-order kernels by local-memory state space and synchronization frequency, pointing to the next optimization targets.
  • The constraints $\eta_{\text{alias}} \ge 0.8$, $\eta_{\text{simd}} \ge 0.97$, and $N_c N_{WI} \le 256$ keep the transformation space small enough to enumerate while still containing near-roofline configurations.

Reading between the lines

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

  • The cost model's bandwidth-versus-residency curve is fitted once per device from microbenchmarks; recalibrating it online from hardware counters, or re-ranking candidates with measured stall data, would show how much of the 65% depends on that fit.
  • The schedule space is almost purely structural — tiling, prefetching, work division — so the same recipe could be applied to CPU vector units or other accelerators, where the three roofline ceilings would be cache bandwidth, DRAM bandwidth, and FLOPS.
  • The paper's own suggested kernel fusion (computing coupled actions, such as velocity and pressure, in one kernel) should interact favorably with the cost model: collapsing shared gather and scatter traffic raises arithmetic intensity, and fused operators may cross the 50% roofline even where each operator alone falls short.
  • Comparing generated kernels against the best hand-tuned implementation of each operator, rather than against the modeled roofline, would give a stricter measure of the method's value; the paper's archived configurations make that comparison directly runnable.
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

2 major / 6 minor

Summary. The paper presents an automatic schedule-search and code-generation approach for matrix-free finite element action kernels on GPUs, targeting variational forms expressed in UFL on simplex meshes. It defines two transformation strategies (single cell per work-item and parametric multi-level tiling with prefetching, loop tiling, and explicit grid mapping), a bounded search space with pruning constraints, and an analytic cost model that ranks candidates. The top nine ranked variants are then timed on the target device and the fastest is selected. The approach is implemented in the Firedrake framework via Loopy transformations and evaluated on an Nvidia Titan V (Volta) and a Tesla K40c (Kepler) across mass, Laplace, Helmholtz, elasticity, and hyperelasticity operators in 2D and 3D. The central empirical claim is that the generated kernels achieve more than 50% of a modeled roofline in 65% of the test cases on both devices.

Significance. If the central claim holds, this is a genuinely useful contribution: it defines a principled transformation space for an important class of FEM kernels, gives a cost model that drastically reduces the number of empirically timed configurations, and provides an implementation with archived software artifacts (Zenodo records) and measured timings. The final kernel selection is based on actual device timing of the top-ranked candidates, so the reported FLOP rates are measured rather than manufactured by the model; this is a strength that avoids the circularity that would arise from reporting purely modeled performance. The main risk is that the headline '65% of test cases' is measured against a roofline denominator that may not be a valid upper bound, as detailed below. If that denominator is corrected, the conclusion may be quantitatively different but the methodological contribution of the paper would remain intact.

major comments (2)
  1. [6.1, Eq. (47)] The roofline model F_roofline = min(AI_global·β_global, AI_local·β_local, F_peak) treats global bandwidth, local/L1 bandwidth, and FLOPS as independent ceilings. However, Section 6.1 states that 'local memory and the L1-cache are part of the same memory unit,' and on the tested Volta and Kepler architectures global memory traffic is also serviced through the L1/shared-memory unit. When global and local traffic compete for the same load-store path and on-chip bandwidth, the attainable throughput is bounded by the resource shared between them; a kernel with both a gather/scatter phase and a local-memory phase can take longer than the maximum of the two memory times. The min-of-ceilings expression is therefore an optimistic upper bound, and every percentage-of-roofline figure reported in Section 6.3, including the headline 65% claim, is computed against a denominator that can exceed the true maximum achievable throughput. This is load-bearing for the central claim. Please re-derive Eq. (47) with a model that accounts for the shared memory unit (for example, by combining the global and local transfer times through the L1/shared stage) and re-evaluate the reported percentages; if the corrected percentages are materially different, the abstract and Section 1 must be revised accordingly.
  2. [4.2.6, Eqs. (40)-(46)] The cost model t_heur in Eq. (40) consists only of global and local memory access times divided by modeled bandwidths; it contains no term for F_peak or instruction-issue time. For high-arithmetic-intensity configurations, two candidates with identical memory traffic but very different FLOP counts will receive the same score, and the top-b=9 pruning could exclude the best configuration in a compute-bound regime. Because the final selection is made by timing the top-b candidates, this omission may not invalidate the reported experiments, but it is a gap in the stated purpose of ranking the transformation space. Please either add a compute-time term to t_heur or provide a sensitivity analysis showing that the rank order and the final selected configuration are robust to this omission.
minor comments (6)
  1. [Section 1 vs. Section 6.2] The paper states '56 variational form evaluation scenarios' in Section 1, but Section 6.2 describes 5 operators × (8 degrees in 2D + 6 degrees in 3D) = 70 cases, and Figure 5 appears to show 70 bars per device. The counting should be reconciled, and the configuration tables (Tables 4-7) seem to omit rows for some cases (e.g., 3D Helmholtz P1 and 3D Mass P1 on Titan V) that nonetheless have bars in Figure 5.
  2. [Algorithm 4, lines 81-97] Line 82 uses the undefined variable 'j′' in the assignment 'j←N_WI j′ + local_id_1', and line 95 tests 'j≥T_r′_q' where the loop variable is 'iW' (or 'i′_W'). These appear to be typos that make the boundary checks incorrect as written; also line 67 contains an empty assignment 'ientry←'.
  3. [Figure 6 and Section 6.3] The caption of Figure 6 mentions 'V100' and 'Tesla K40m', but the experiments use a Titan V and a Tesla K40c; Section 6.3 similarly says 'V100 GPUs' once. Please correct the device names to match Section 6.2.
  4. [Equation (23)] The LaTeX in the definition of f(q) contains stray '&' and '’' tokens that make the formula difficult to parse; please typeset it cleanly.
  5. [Section 4.2.3, Eq. (22) area] The sentence before Eq. (22) reads 'by allocating by allocating' (a duplicated phrase), and the annotation after Eq. (22) contains 'N N derivw', which appears to be a typo for 'N_deriv^w'.
  6. [Throughout] The software is called both 'Loopy' and 'Loo.py' in different places; please make the spelling consistent with the canonical name used by the cited reference.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: cost-model ranking is pruned by measured timing, and the roofline figure is a measured ratio against an independent upper-bound model.

full rationale

The paper's actual selection procedure breaks any circular link between the cost model and the reported performance. Section 4.3 states: 'In order to obtain the final transformed kernel we execute the b-best ranked variants of the Multi-level tiling and the Single-cell per work-item variant with dummy data, time them and choose the fastest timed kernel variant.' Thus the cost model only limits which kernel variants are timed; the final kernel and its FLOP rate come from wall-clock measurement, not from the model. The headline claim, that at least 50% of the Eq. (47) roofline is reached in about 65% of test cases, is a measured ratio against an upper-bound model whose parameters (F_peak, beta_peak_global, beta_peak_local) are device specifications measured with the SHOC benchmark; they are not fitted to the FEM kernels and are not derived from the paper's own predictions. The same SHOC measurements are used to calibrate the cost model's SGsat and bandwidth curves, but this is a shared external calibration source, not an equation-level reduction: no fitted parameter is renamed as a predicted outcome. Self-citations (Loopy [29], vectorization study [24], related DG work [17]) are implementation or background dependencies, not load-bearing uniqueness or derivation claims, so they do not make the argument circular. The paper's own limitations are explicit: Section 2.3 excludes surface integrals and sum factorization, Section 6.3.1 attributes low-order shortfalls to DOF layout, and Section 6.3.2 attributes high-order shortfalls to state-space pressure. Section 6.1 also notes that 'local memory and the L1-cache are part of the same memory unit' while Eq. (47) takes a min over separate global and local ceilings; that is an internal modeling tension and a correctness risk for the roofline denominator, but it is not a circularity, because the measured kernel time is not constructed to equal the roofline. No step in the derivation reduces a claimed prediction to its own inputs, so no circularity is found.

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

The central claim rests on two fitted saturation parameters in the cost model, on the roofline modeling assumption, and on the scoped input class. No new physical entities are postulated.

free parameters (2)
  • SGsat,global = 8 (K40), 1 (Titan V)
    Saturation point for the modeled global memory bandwidth in Eq. 41; fitted to SHOC benchmark measurements.
  • SGsat,local = 10 (K40), 12 (Titan V)
    Saturation point for the modeled local memory bandwidth in Eq. 42; fitted to SHOC readLocalMemory measurements.
assumptions (4)
  • domain assumption The bilinear forms considered are expressible in the restricted UFL subset of Eq. 15, excluding surface integrals and sum factorization.
    Section 2.3 defines the input space and states which forms are out of scope.
  • domain assumption The GPU execution model follows OpenCL nomenclature with SIMD width 32, unified L1/shared memory, and the register and local memory limits in Table 3.
    Section 2.5 and Table 3 set the hardware model for the transformations and cost model.
  • domain assumption The roofline model of Eq. 47 upper-bounds achievable performance with three independent ceilings and perfect latency hiding.
    Section 6.1 states this assumption; it defines the denominator of the headline roofline fraction.
  • standard math Quadrature-based finite element assembly faithfully discretizes the variational form, and TSFC, Loopy, and the Ciarlet formalism are correct.
    Sections 2.1 and 2.2 rely on standard FEM and DSL compiler machinery without proving it.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Code Generation for Near-Roofline Finite Element Actions on GPUs from Symbolic Variational Forms." pith.science (2026). https://pith.science/paper/QGODFBLR

@misc{pith2026250617471,
  author       = {Pith},
  title        = {Pith review of: Code Generation for Near-Roofline Finite Element Actions on GPUs from Symbolic Variational Forms},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QGODFBLR}},
  note         = {Machine review of arXiv:2506.17471}
}
abstract

We present a novel parallelization strategy for evaluating Finite Element Method (FEM) variational forms on GPUs, focusing on those that are expressible through the Unified Form Language (UFL) on simplex meshes. We base our approach on code transformations, wherein we construct a space of scheduling candidates and rank them via a heuristic cost model to effectively handle the large diversity of computational workloads that can be expressed in this way. We present a design of a search space to which the cost model is applied, along with an associated pruning strategy to limit the number of configurations that need to be empirically evaluated. The goal of our design is to strike a balance between the device's latency-hiding capabilities and the amount of state space, a key factor in attaining near-roofline performance. To make our work widely available, we have prototyped our parallelization strategy within the \textsc{Firedrake} framework, a UFL-based FEM solver. We evaluate the performance of our parallelization scheme on two generations of Nvidia GPUs, specifically the Titan V (Volta architecture) and Tesla K40c (Kepler architecture), across a range of operators commonly used in applications, including fluid dynamics, wave propagation, and structural mechanics, in 2D and 3D geometries. Our results demonstrate that our proposed algorithm achieves more than $50\%$ roofline performance in $65\%$ of the test cases on both devices.

Figures

Figures reproduced from arXiv: 2506.17471 by the authors.

Figure 1
Figure 1. Work-group used in the parametric multi-level tiling. The smallest squares represent one work [PITH_FULL_IMAGE:figures/full_fig_p016_1.png] view at source ↗
Figure 2
Figure 2. Cardinality of search space as per bounds chosen in Section 4.2.5. [PITH_FULL_IMAGE:figures/full_fig_p023_2.png] view at source ↗
Figure 3
Figure 3. Both (a) and (b) are ways of tiling an 8 × 8 matrix with a tile shape T r × T c . Both variants incur Nsync = 2, but variant (a) will use more local memory than (b). Configurations like (a) are not considered in our parameter space as (b) has lower L with the same Nsync which generally would correspond to superior performance. 23 [PITH_FULL_IMAGE:figures/full_fig_p023_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Modeled bandwidth 4.2.6. Cost Model In Section 4.2.5, we defined a bounded transformation space which we enumerate. How￾ever, we see from [PITH_FULL_IMAGE:figures/full_fig_p024_4.png]
Figure 6
Figure 6. Figure 6: Comparison of % of cases achieving a % roofline on the Tesla K40 and V100 GPUs [PITH_FULL_IMAGE:figures/full_fig_p028_6.png]
Figure 5
Figure 5. Figure 5: Evaluated performance versus the roofline for Nvidia Titan V (left) and Nvidia Tesla K40c (right). [PITH_FULL_IMAGE:figures/full_fig_p029_5.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

35 extracted references · 22 canonical work pages

  1. [1]

    M. S. Alnæs, UFL: A Finite Element Form Language, Lecture Notes in Computational Science and Engineering (2012) 303–338doi:10.1007/978-3-642-23099-8_17

    work page doi:10.1007/978-3-642-23099-8_17 2012

  2. [2]

    T. H. Gibson, A. T. T. McRae, C. J. Cotter, L. Mitchell, D. A. Ham, Firedrake, Compatible Finite Element Methods for Geophysical Flows (2019) 39–54doi:10.1007/ 978-3-030-23957-2_3

    work page 2019

  3. [3]

    Dupont, J

    T. Dupont, J. Hoffman, C. Johnson, R. C. Kirby, M. G. Larson, A. Logg, L. R. Scott, The FEniCS Project, Chalmers Finite Element Centre, Chalmers University of Tech- nology, 2003. URLhttps://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-235786

    work page 2003

  4. [4]

    Blatt, A

    M. Blatt, A. Burchardt, A. Dedner, C. Engwer, J. Fahlke, B. Flemisch, C. Gersbacher, C. Gräser, F. Gruber, C. Grüninger, et al., The Distributed and Unified Numerics Environment, version 2.4, Archive of Numerical Software 4 (100) (2016) 13–29.doi: 10.11588/ans.2016.100.26526

    doi:10.11588/ans.2016.100.26526 2016

  5. [5]

    R. C. Kirby, L. Mitchell, Solver Composition across the PDE/Linear Algebra Bar- rier, SIAM Journal on Scientific Computing 40 (1) (2018) C76–C98.doi:10.1137/ 17M1133208. 35

    work page 2018

  6. [6]

    Helenbrook, D

    B. Helenbrook, D. Mavriplis, H. Atkins, Analysis of “p”-Multigrid for Continuous and Discontinuous Finite Element Discretizations, in: 16th AIAA Computational Fluid Dynamics Conference, 2003, p. 3989.doi:10.2514/6.2003-3989

    doi:10.2514/6.2003-3989 2003

  7. [7]

    Phillips, S

    M. Phillips, S. Kerkemeier, P. Fischer, Tuning Spectral Element Preconditioners for Parallel Scalability on GPUs, pp. 37–48.doi:10.1137/1.9781611977141.4

    work page doi:10.1137/1.9781611977141.4

  8. [8]

    Brezzi, M

    F. Brezzi, M. Fortin, Mixed and Hybrid Finite Element Methods, Vol. 15, Springer Science & Business Media, 1991.doi:10.1007/978-1-4612-3172-1

    doi:10.1007/978-1-4612-3172-1 1991

Show all 35 references
  1. [9]

    NVIDIA, V100 GPU Architecture (2017)

    T. NVIDIA, V100 GPU Architecture (2017)

    2017

  2. [10]

    Logg, K.-A

    A. Logg, K.-A. Mardal, G. Wells, Automated Solution of Differential Equations by the Finite Element Method: The FEniCS book, Vol. 84, Springer Science & Business Media, 2012.doi:10.5555/2331176

    2012 doi

  3. [11]

    P. G. Ciarlet, Numerical Analysis of the Finite Element Method, (No Title) (1976)

    1976

  4. [12]

    Saad, Krylov Subspace Methods on Supercomputers, SIAM Journal on Scientific and Statistical Computing 10 (6) (1989) 1200–1232.doi:10.5555/3037518.3037519

    Y. Saad, Krylov Subspace Methods on Supercomputers, SIAM Journal on Scientific and Statistical Computing 10 (6) (1989) 1200–1232.doi:10.5555/3037518.3037519

    1989

  5. [13]

    Homolya, L

    M. Homolya, L. Mitchell, F. Luporini, D. A. Ham, TSFC: A Structure-Preserving Form Compiler, SIAM Journal on Scientific Computing 40 (3) (2018) C401–C428. doi:10.1137/17M1130642

    2018 doi

  6. [14]

    R. C. Kirby, A. Logg, A Compiler for Variational Forms, ACM Transactions on Math- ematical Software (TOMS) 32 (3) (2006) 417–444.doi:10.1145/1163641.1163644

    2006

  7. [15]

    Munshi, The OpenCL Specification, in: 2009 IEEE Hot Chips 21 Symposium (HCS), IEEE, 2009, pp

    A. Munshi, The OpenCL Specification, in: 2009 IEEE Hot Chips 21 Symposium (HCS), IEEE, 2009, pp. 1–314.doi:10.1109/HOTCHIPS.2009.7478342

    2009

  8. [16]

    Danalis, G

    A. Danalis, G. Marin, C. McCurdy, J. S. Meredith, P. C. Roth, K. Spafford, V. Tippa- raju, J. S. Vetter, The Scalable Heterogeneous Computing (SHOC) Benchmark suite, in: Proceedings of the 3rd Workshop on General-Purpose Computation on Graphics Processing Units, 2010, pp. 63–7...

    2010

  9. [17]

    Klöckner, T

    A. Klöckner, T. Warburton, J. Bridge, J. S. Hesthaven, Nodal Discontinuous Galerkin Methods on Graphics Processors, Journal of Computational Physics 228 (21) (2009) 7863–7882.doi:10.1016/j.jcp.2009.06.041

    2009 doi

  10. [18]

    Komatitsch, G

    D. Komatitsch, G. Erlebacher, D. Göddeke, D. Michéa, High-order Finite-Element Seismic Wave Propagation Modeling with MPI on a large GPU cluster, Journal of computational physics 229 (20) (2010) 7692–7714.doi:10.1016/j.jcp.2010.06.024

    2010 doi

  11. [19]

    Ljungkvist, Matrix-free Finite-Element Computations on Graphics Processors with Adaptively Refined Unstructured Meshes., in: SpringSim (HPC), 2017, pp

    K. Ljungkvist, Matrix-free Finite-Element Computations on Graphics Processors with Adaptively Refined Unstructured Meshes., in: SpringSim (HPC), 2017, pp. 1–1.doi: 10.5555/3108096.3108097

    2017

  12. [20]

    I. Kiss, S. Gyimothy, Z. Badics, J. Pavo, Parallel Realization of the Element-by-Element FEM Technique by CUDA, IEEE Transactions on magnetics 48 (2) (2012) 507–510. doi:10.1109/TMAG.2011.2175905. 36

    2012

  13. [21]

    Banaś, F

    K. Banaś, F. Krużel, J. Bielański, Optimal Kernel Design for Finite Element Numerical Integration on GPUs, Computing in Science & Engineering PP (2019) 1–1.doi:10. 1109/MCSE.2019.2940656

    2019

  14. [22]

    Markall, A

    G. Markall, A. Slemmer, D. Ham, P. Kelly, C. Cantwell, S. Sherwin, Finite Element Assembly Strategies on Multi-core and Many-core Architectures, International Journal for Numerical Methods in Fluids 71 (1) (2013) 80–97.doi:10.1002/fld.3648

    2013 doi

  15. [23]

    Kronbichler, K

    M. Kronbichler, K. Kormann, I. Pasichnyk, M. Allalen, Fast Matrix-free Discontinuous Galerkin Kernels on Modern Computer Architectures, in: International Supercomput- ing Conference, Springer, 2017, pp. 237–255.doi:10.1007/978-3-319-58667-0_13

    2017 doi

  16. [24]

    T. Sun, L. Mitchell, K. Kulkarni, A. Klöckner, D. A. Ham, P. H. Kelly, A Study of Vectorization for Matrix-free Finite Element Methods, arXiv preprint arXiv:1903.08243 (2019).doi:10.1177/1094342020945005

    2019 arXiv

  17. [25]

    M. G. Knepley, K. Rupp, A. R. Terrel, Finite Element Integration with Quadrature on the GPU, arXiv (2016).doi:10.48550/arXiv.1607.04245

    2016 doi arXiv

  18. [26]

    Brezzi, J

    F. Brezzi, J. Douglas, Two Families of Mixed Finite Elements for Second order Elliptic Problems, Numerische Mathematik 47 (1985) 217–235.doi:10.1007/BF01389710

    1985 doi

  19. [27]

    Feautrier, Array Expansion, in: ACM International Conference on Supercomputing 25th Anniversary Volume, 1988, pp

    P. Feautrier, Array Expansion, in: ACM International Conference on Supercomputing 25th Anniversary Volume, 1988, pp. 99–111.doi:10.1145/2591635.2667159

    1988

  20. [28]

    Rathgeber, G

    F. Rathgeber, G. R. Markall, L. Mitchell, N. Loriant, D. A. Ham, C. Bertolli, P. H. Kelly, PyOP2: A High-level Framework for Performance-Portable Simulations on Un- structuredMeshes, in: 2012SCCompanion: HighPerformanceComputing, Networking Storage and Analysis, IEEE, 2012, pp...

    2012 doi

  21. [29]

    A. Klöckner, Loo.py: Transformation-based Code Generation for GPUs and CPUs, in: Proceedings of ACM SIGPLAN International Workshop on Libraries, Languages, and Compilers for Array Programming, 2014, pp. 82–87.doi:10.1145/2627373.2627387

    2014

  22. [30]

    Verdoolaege, isl: An Integer Set Library for the Polyhedral Model, in: Inter- national Congress on Mathematical Software, Springer, 2010, pp

    S. Verdoolaege, isl: An Integer Set Library for the Polyhedral Model, in: Inter- national Congress on Mathematical Software, Springer, 2010, pp. 299–302.doi: 10.1007/978-3-642-15582-6_49

    2010 doi

  23. [31]

    Z. Jia, M. Maggioni, B. Staiger, D. P. Scarpazza, Dissecting the Nvidia Volta GPU Architecture via microbenchmarking, arXiv preprint arXiv:1804.06826 (2018).doi: 10.48550/arXiv.1804.06826

    2018 doi arXiv

  24. [32]

    URLhttps://en.wikipedia.org/w/index.php?title=List_of_Nvidia_graphics_ processing_units&oldid=988270783

    Wikipedia contributors, List of Nvidia Graphics Processing Units — Wikipedia, the free encyclopedia, [Online; accessed 16-November-2020] (2020). URLhttps://en.wikipedia.org/w/index.php?title=List_of_Nvidia_graphics_ processing_units&oldid=988270783

    2020

  25. [33]

    14029412

    Software used in ‘UFL to GPU: Near the Roofline’ (nov 2024).doi:10.5281/zenodo. 14029412

    2024 doi

  26. [34]

    UFL to GPU: Near the Roofline

    K. Kulkarni, Reproducer Software for “UFL to GPU: Near the Roofline”. (Nov. 2024). doi:10.5281/zenodo.14032650. 37

    2024 doi

  27. [35]

    C. D. Cantwell, S. J. Sherwin, R. M. Kirby, P. H. Kelly, FromhtopEfficiently: Strategy Selection for Operator Evaluation on Hexahedral and Tetrahedral Elements, Computers & Fluids 43 (1) (2011) 23–28.doi:10.1051/mmnp/20116304. Appendix A. V ariational forms of FEM operators He...

    2011

Pith tools

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