PaperlayerView exact revision on arXiv

Source-linked AI summary

KernelOPT: Dispatch-Aware Agentic Search for GPU Kernel Optimization

Aheli Poddar, Sanskar Prasad, Arindam Samanta, Subha Chakraborty, Vishal Goyal, Rohit Singh Rathaur

arXiv:2609.30059v2cs.DCcs.AIcs.LG

TL;DR

Compiled-model kernel optimizers often treat models as black boxes and do not verify re-stitched models end to end. KernelOPT preserves vendor-library dispatch, optimizes Triton sub-kernels with profiling-guided agents, and applies four verification gates. Across 250 KernelBench problems, it improves geomean speedup over torch.compile at all three levels, including fallback cases.

  • Problem

    LLM kernel optimizers can improve standalone kernels but generally do not respect compiled-model structure or verify re-stitched models end to end.

    Source: §1 · p. 2

  • Method

    KernelOPT preserves vendor-library calls, targets Triton sub-kernels with profiling-guided agents, and uses four gates to verify candidates and re-stitched models.

    Source: §1 · p. 2, §3 · p. 3

  • Results

    Across 250 KernelBench problems, all-problems geomean speedups over torch.compile improve at L1, L2, and L3; the L1 result is 1.40×.

    Source: §6.1 · p. 7, §7 · p. 9

  • Takeaways & Limitations

    Of 250 problems, 70 are optimized, 95 are matched, and 85 fall back, with the compiler baseline preserved when candidates fail verification.

    Source: §7 · p. 9

    Search ranks candidates by latency without enforcing early correctness flags and tests only the fastest candidate at final selection, limiting search efficiency and completeness.

    Source: §4.3 · p. 5

Abstract

from arXiv · show

Deep learning inference and training performance depends critically on GPU kernel efficiency. Modern compilers such as PyTorch Inductor automatically generate GPU kernels from high-level model code, but frequently underperform expert-written implementations by wide margins. Recent LLM-assisted kernel optimizers can close this gap for standalone kernels, yet treat compiled models as black boxes, generally optimizing individual standalone kernels without respecting the compiler's structural decisions or verifying the model end-to-end. We present KernelOPT, a multi-agent system that treats compiled models as structured artifacts. It preserves vendor library calls (cuBLAS, cuDNN) and exclusively targets generated Triton sub-kernels using five profiling-guided LLM agents. A four-gate verification cascade applies static validation, multi-seed correctness checking, model-level float64-fallback verification, and performance gating ($\gamma{=}1.03$) to filter candidates and verify the re-stitched model end-to-end. When candidates fail verification, the system preserves the compiler baseline. The system accepts PyTorch nn Modules, standalone Triton kernels, and Helion kernels. Evaluated on 250 KernelBench problems (100 Level 1, 100 Level 2 and 50 Level 3) on NVIDIA H200, KernelOPT achieves geometric mean speedups over torch compile of 1.40$\times$ (L1), 1.15$\times$ (L2), and 1.07$\times$ (L3) across all kernels, including fallback cases. Optimized-only geomeans (excluding cases where verification gates preserve the compiler baseline) are substantially higher: 2.54$\times$ (L1: 36/100), 1.84$\times$ (L2: 23/100), and 1.37$\times$ (L3: 11/50), reflecting where the optimizer achieves meaningful leverage.

1 INTRODUCTION

Inductor-generated kernels leave optimization opportunities, while prior LLM optimizers do not verify re-stitched models end to end. KernelOPT preserves compiler dispatch choices and targets Triton sub-kernels with model-level verification.

1 INTRODUCTION

  • Inductor’s limited tile-size search, conservative fusion, and fixed pattern rewrites leave performance opportunities despite its 2.27× inference speedup over eager mode.Expert-written kernels demonstrate near-order-of-magnitude speedups on the same hardware but require extensive engineering effort.Source: §1 · p. 1
  • Prior LLM kernel optimizers lack end-to-end verification of re-stitched models against the original PyTorch model with weight-extracted correctness and performance gating.Some support multi-kernel decomposition, but none provides the specified verification approach.Source: §1 · p. 2
  • KernelOPT preserves cuBLAS/cuDNN calls, targets Triton sub-kernels, and verifies optimized results at the model level because replacing vendor calls introduces more failures than gains.Removing dispatch preservation drops L2 optimization success to 0%, and 75% of fallbacks are library-dominated.Source: §1 · p. 2
  • The system combines compiled-model-aware decomposition, four-gate verification, and profiling-guided search by five agents, including diversity enforcement against search stagnation.It also accepts standalone Triton and Helion kernels.Source: §1 · p. 2

2 RELATED WORK

Kernel optimization spans compiler scheduling, hand-written kernels, and LLM-driven search, but approaches differ in their target and verification scope. KernelOPT combines compiled-model decomposition, NCU-guided planning, and end-to-end verification.

2 RELATED WORK

  • Compiler methods such as Halide and TVM separate algorithm from schedule, while Inductor uses fixed tile sizes and fusion patterns and ThunderKittens offers tile-level CUDA abstractions.Mirage applies multi-level superoptimization with formal equivalence verification.Source: §2 · p. 2
  • On KernelBench Level 1, KernelOPT reaches 1.649× geomean vs. torch.compile, compared with KernelAgent’s 0.966×, and wins 40/68 head-to-head problems.The comparison used identical H200 hardware and Claude Sonnet 4.6; KernelAgent had 71/100 working kernels, with 22/71 regressed, versus KernelOPT’s 89/100 working.Source: §2 · p. 2
  • KernelOPT combines Inductor-aware decomposition, NCU-guided multi-agent planning, float64-fallback verification, and compiler-baseline fallback when no candidate passes all four gates.AutoKernel also provides model-level profiling and end-to-end correctness verification, but does not use NCU hardware profiling to guide optimization.Source: §2 · pp. 2–3
  • KernelBench provides 250 problems across three difficulty levels and standardized evaluation using torch.allclose(rtol=10−4, atol=10−4).The evaluation also includes 20 tutorial kernels.Source: §2 · p. 3

3 PROBLEM FORMULATION

KernelOPT formulates compiled-model optimization as searching Triton sub-kernels while holding external library calls fixed. It seeks low-latency candidates that pass verification, using profiling-derived plans to explore the search space.

3 PROBLEM FORMULATION

  • The formulation represents a compiled model as Triton-generated sub-kernels plus fixed extern library calls, then defines kernel latency, model re-stitching, and verification.The optimization objective is introduced after defining these components.Source: §3 · p. 3
  • Because the syntactically valid Triton search space is intractable to enumerate, an LLM transformation operator maps a kernel and profiling-derived plan to a candidate.The plan belongs to the optimization-plan space P.Source: §3 · p. 3
  • The verification function is a sequential conjunction of four gates, with static validation and correctness applied per candidate and model-level and performance checks applied to the re-stitched model afterward.If no candidate passes all gates, the system returns the original kernel unchanged.Source: §3 · p. 3

4 METHOD

KernelOPT traces compiled models, profiles and optimizes Triton sub-kernels with collaborating agents, and verifies the re-stitched model through sequential gates. Its beam search preserves chain diversity, while experience memory curates selected outcomes for future planning.

4.1 SYSTEM OVERVIEW

  • In multi-kernel mode, KernelOPT traces a PyTorch model, preserves extern kernels, profiles with NCU, iteratively optimizes sub-kernels, then re-stitches and verifies the model.Inductor-aware synthesis merges adjacent fusible Triton groups; this alone can yield large gains, including 33× on L2 018.Source: §4.1 · p. 3

4.2 AGENT ARCHITECTURE

  • Five agents collaborate in a LangGraph state machine; profiling and strategy analysis inform plans, execution receives error feedback, and a meltdown detector enforces diversity when directions collapse.The analyst classifies bottlenecks using SOLmem versus SOLcomp against an 80% threshold.Source: §4.2 · pp. 3–4, Figure 1 · p. 4

4.3 PROFILING-GUIDED BEAM SEARCH

  • Profiling-guided beam search ranks candidates by latency while preserving a representative per active chain, balancing exploration with exploitation under a fixed plan budget.The released implementation ranks without enforcing the per-candidate correctness flag and tests only the single fastest candidate at final selection, affecting search efficiency and completeness.Source: §4.3 · pp. 4–5

4.4 VERIFICATION CASCADE

  • The cascade applies static validation and multi-seed correctness checks during optimization, then checks re-stitched model correctness and performance end to end.When strict comparison fails, a float64 reference disambiguates numerical noise; the accepted-side error-ratio distribution is not yet instrumented.Source: §4.4 · pp. 5–6

4.5 EXPERIENCE MEMORY

  • Experience memory stores items using asymmetric speedup thresholds, while a cross-run tracker flags strategies with under 30% success after at least three attempts as AVOID.Benchmark-derived guidelines provide cold-start planner context but do not affect Table 1.Source: §4.5 · p. 6

5 EXPERIMENTAL SETUP

The evaluation uses fixed search settings across 250 KernelBench problems on an H200, with torch.compile as the primary baseline. Candidates are searched under a bounded budget and reported only after correctness and end-to-end performance checks.

Experimental platform and settings

  • Experiments ran on one NVIDIA H200 using Claude Sonnet 4.6 via Vertex AI, with hyperparameters fixed across all 250 problems.Settings included T=5 iterations, N=4 plans per iteration, K=4 retries, beam width B=4, and a 3% performance-gate margin.Source: §5 · p. 6

Baseline selection

  • The primary baseline was torch.compile with Inductor max autotune; direct comparisons with other tools were omitted because hardware and optimization scope differ.The evaluation follows KernelBench’s protocol and measures gains over the deterministic compiler.Source: §5 · p. 7

Benchmark coverage

  • The evaluation covered KernelBench Levels 1–3 (250 problems) and 10 tutorial kernels each for Triton and Helion, totaling 270 problems.The levels comprise 100 single-op kernels, 100 composite operators, and 50 model architectures.Source: §5 · p. 7

Measurement and verification

  • Benchmarks used do bench with 25 ms warmup and 100 ms repetition; search correctness used allclose(10^-3), while final verification used 10^-4.The total compute budget was approximately 1,100 H200 GPU-hours.Source: §5 · p. 7

Search and reporting protocol

  • Each problem received up to 20 LLM-driven candidates, and the highest end-to-end speedup passing all four gates was reported; fallbacks preserved the compiler baseline.Matched kernels within the 3% noise margin were deployed as-is, so reported outcomes were non-regressing by construction; results reflect the search budget, not a theoretical ceiling.Source: §5 · p. 7

6 RESULTS AND DISCUSSION

KernelOPT improves on torch.compile across all three KernelBench levels, though successful optimizations are concentrated in a minority of problems. Results also show that end-to-end checks matter: isolated kernel gains may not survive model re-stitching, and leverage depends on the workload’s optimizable Triton share.

6.1 MAIN RESULTS

  • Of 250 problems, 70 passed all gates with speedup above 1.03×, 95 were matched or unattempted, and 85 fell back to the compiler baseline.The optimized-kernel speedup distribution is heavy-tailed: a minority achieved order-of-magnitude gains, while most gains were 1.03–1.5×.Source: §6.1 · p. 7
  • The largest gains came from algorithmic rewrites and fusion: diagonal-matmul rewriting reached 88.63×, while cited L2 fusion cases reached 33.11× and 8.30×.KernelOPT also improved 4/10 official Triton tutorials (best 1.70×) and 5/10 Helion tutorials (best 1.08×).Source: §6.1 · pp. 7–8
  • Against torch.compile, all-problem geomeans were 1.40× (L1), 1.15× (L2), and 1.07× (L3); optimized-only geomeans were 2.54×, 1.84×, and 1.37×.The all-problem values include fallback cases; optimized-only values cover the 70 problems that passed all gates.Source: §6.1 · p. 7, Table 1 · p. 8

6.2 SPEEDUP BASELINES: VS. COMPILE AND VS. EAGER

  • On these KernelBench workloads, compile’s margin over eager was roughly 1.23–1.56×, below the 2.27× literature figure for full macroarchitectures.The paper attributes the difference to the benchmark’s individual operators or short fusion chains, where dispatch and launch overhead consume more runtime.Source: §6.2 · p. 8

6.3 FALLBACK ANALYSIS

  • Library-dominated cases accounted for 64/85 fallbacks (75%); Gate 4 also rejected 15 L1 kernels whose isolated NCU gains did not survive dispatch overhead end-to-end.Seven L3 models generated no Triton kernels, and five fallbacks were terminal correctness failures.Source: Table 1 · p. 8, §6.3 · p. 9

6.4 THE MULTI-KERNEL COMPOSITION GAP

  • Among 126 multi-kernel problems, 37 (29%) had at least one individually optimized sub-kernel whose gain did not survive re-stitching; Gate 4 avoided shipping 16 end-to-end regressions.The paper attributes this composition gap to dispatch/re-stitching overhead, implicit contiguous copies, and Amdahl’s law.Source: §6.4 · p. 9

6.5 L3 ARCHITECTURE ANALYSIS AND ABLATION STUDY

  • Level 3 success occurred when optimizable Triton kernels made up a meaningful share of execution time, including in MLPs, attention epilogues, and U-Net skip connections.In a 50-problem distribution-preserving ablation sample, disabling any component bundle reduced optimized rate from 38% to at most 10%; disabling Inductor-aware synthesis eliminated L2 optimization.Source: §6.5 · p. 9

7 CONCLUSION

KernelOPT preserves compiler structure and vendor-library dispatch while directing optimization toward Triton sub-kernels, then verifies the re-stitched model. Its conclusion reports gains across KernelBench alongside practical scope and implementation limits.

7 CONCLUSION

  • Of 250 problems, 70 were optimized, 95 matched, and 85 fell back; gains were largest on algorithmic rewrites, matmul/reduction operations, and cross-boundary fusion.The system preserves the compiler baseline when candidates fail verification.Source: §7 · p. 9

A AGENT PROMPT TEMPLATES

  • Six fixed agent prompts structure the pipeline, with five LLM-driven agents and one deterministic profiler.The prompts were fixed across the 250 KernelBench experiments.Source: A AGENT PROMPT TEMPLATES · p. 11

A.1 PLANNER AGENT

  • The Planner uses Nsight Compute profiling and kernel source to diagnose bottlenecks, consult optimization memory, and propose one actionable change.It targets Triton kernels and launch parameters rather than vendor-library calls, which the prompt describes as hardware-optimized and difficult to beat.Source: §A.1 · p. 12

A.2 EXECUTOR AGENT

  • The Executor implements the plan with minimal source edits and uses compile errors or correctness failures as feedback for up to K retries.Its prompt requires preserving the function signature and checking syntax, Triton calls, masks, and numerical stability.Source: §A.2 · p. 13

A.3 SUMMARIZER AGENT

  • The Summarizer compares kernel diffs and profiling metrics to attribute effects, then generalizes successful or failed attempts into reusable experience.It is instructed not to attribute effects absent from profiling data.Source: §A.3 · pp. 13–14

A.4 PROFILER AGENT

  • The Profiler selects an Nsight Compute configuration by analyzing source markers, tensor initialization, and benchmark-loop structure.For multi-kernel files, its prompt directs profiling all kernels so the pipeline can discover the bottleneck.Source: §A.4 · p. 14

A.5 CODEGEN (SYNTHESIS) AGENT

  • The synthesis agent generates standalone Triton kernels from ATen operation specifications, including a wrapper and input generator.Its prompt says to retain matmul or convolution as standard PyTorch calls and fuse only epilogue operations.Source: §A.5 · pp. 14–15

A.6 FUSION AGENT

  • The Fusion Agent combines adjacent Triton kernels connected by intermediate buffers into one kernel that keeps intermediate values in registers.The fused kernel must preserve external inputs and outputs and eliminate the specified intermediate buffers.Source: §A.6 · p. 15

B VERIFICATION CASCADE DETAILS

The verification specification separates checks on each candidate from checks on the re-stitched model, including a float64 fallback for numerical discrepancies. The section also describes search-selection limitations and the scope of shipped optimization guidelines.

B VERIFICATION CASCADE DETAILS

  • Gates 1–2 run on every candidate during optimization, while Gates 3–4 run once on the re-stitched model after optimization.Table 3 provides the complete gate specification, including synthesis-stage validation.Source: Table 3 · p. 16, B VERIFICATION CASCADE DETAILS · p. 16
  • When strict comparison fails, Gate 3 uses a float64 reference to distinguish numerical noise from algorithmic errors, with separate checks for normal and degenerate cases.For the normal case, the error ratio ρ passes if ρ ≤ 10; the degenerate case uses scale-relative and absolute error bounds.Source: B VERIFICATION CASCADE DETAILS · p. 16
  • Search may carry fast-but-incorrect candidates between iterations, and final selection tests only kfast, so a slower correct candidate is not guaranteed to be tried.The authors describe these behaviors as limits on search efficiency and completeness, not on the returned model’s correctness guarantee.Source: B VERIFICATION CASCADE DETAILS · p. 16

C SHIPPED OPTIMIZATION GUIDELINES

  • Shipped guidelines were extracted post hoc from the 250 KernelBench runs and did not affect reported results.Table 4 reports binary success/failure counts rather than speedup magnitudes; only strategies with zero failures and at least two successes enter the default cold-start context.Source: C SHIPPED OPTIMIZATION GUIDELINES · p. 16, Table 4 · p. 17

D ABLATION RESULTS

The ablation study tests degraded configurations on a stratified 50-problem sample and reports that removing any single component reduces optimization success. Its observations identify effects associated with search breadth, memory, performance gating, profiling, iterations, and Inductor-aware filtering.

D ABLATION RESULTS

  • The 50-problem sample preserves outcome-category distributions within each level, and Table 7 reports optimized, matched, and fallback counts for the full-system subset and ablations.The full-system C0 configuration uses beam width 4, 5 iterations, NCU profiling, optimization memory, and an end-to-end performance gate.Source: D ABLATION RESULTS · p. 17, Table 6 · p. 18, Table 7 · p. 18
  • Removing any single component reduces optimization success by 74–84% in the combined ablation study.The study covers 50 problems; the no-Inductor-aware configuration uses L2 only, with n=20.Source: Table 5 · p. 17, D ABLATION RESULTS · p. 17
  • A single search chain reduced optimized kernels from 19 to 5; without experience memory, L1 optimizations fell from 10 to 4 and all L2/L3 optimizations were lost.Without the performance gate, only 3 L1 kernels optimized.Source: D ABLATION RESULTS · p. 18
  • Without profiling, 5 kernels still optimized; a single iteration yielded 4, while removing Inductor-aware filtering caused all 20 L2 kernels to fall back.The no-profiling configuration included 2 L2 cases with algorithmic improvements rather than profiling guidance.Source: D ABLATION RESULTS · p. 18

E NCU PROFILING CASE STUDIES

The case studies show that isolated kernel speedups and re-stitched model speedups can diverge because of dispatch overhead, unoptimized kernels, and synthesis steps outside the NCU-guided loop. Profiling-guided changes range from register and occupancy tuning to algorithmic rewrites and operator simplification.

Speedup measurement scope

  • Sub-kernel and E2E speedups differ because E2E includes the re-stitched model, preserved library calls, other kernels, and Python dispatch, while Sub-k measures isolated kernel-loop improvement.Amdahl’s law can dilute kernel gains; for L3-002, E2E also includes an earlier synthesis/fusion gain absent from the NCU trace.Source: E NCU PROFILING CASE STUDIES · pp. 18–19, Table 8 · p. 20

L1-007 matmul

  • 2.89× E2E speedup follows a 3.27× sub-kernel gain for L1-007 after FP16 dot-product accumulation reduces registers from 184 to 125 and doubles occupancy.The baseline is compute-bound; the optimized kernel becomes memory-bound as higher occupancy saturates memory bandwidth.Source: E NCU PROFILING CASE STUDIES · p. 19

L1-012 diagonal matrix multiply

  • 88.63× E2E speedup for L1-012 comes primarily from replacing an O(N^3) diagonal-matrix GEMM with O(N^2) row scaling.The original GEMM wastes more than 99.99% of multiply-accumulate operations on zeros; the optimization pass adds a further improvement through memory-access changes.Source: E NCU PROFILING CASE STUDIES · pp. 19–20

L2-018 algebraic simplification

  • 33.11× speedup for L2-018 follows algebraic simplification of a six-operation chain into a dot product using precomputed weight-column and bias sums.This reduces arithmetic from O(MNK) to O(MK) and eliminates singleton reductions and intermediate memory traffic.Source: E NCU PROFILING CASE STUDIES · p. 20

F COMPLETE KERNELBENCH RESULTS

Across all KernelBench levels, KernelOPT improves or preserves the torch.compile baseline, with larger geomean gains on L1 than on L2 or L3. Results also show that model-level fallbacks, composition effects, and architecture family influence where optimization succeeds.

F COMPLETE KERNELBENCH RESULTS

G.2 L2 KERNEL 018: ALGEBRAIC SIMPLIFICATION (33.11×)

  • 33.11× speedup for L2-018 follows simplifying a six-operation chain into a single dot product using precomputed weight-column sums and bias sum.The change reduces arithmetic from O(MNK) to O(MK), eliminates singleton reductions, and replaces six separate launches with one fused Triton kernel.Source: F COMPLETE KERNELBENCH RESULTS · p. 22, §G.2 · p. 26

F.1 FALLBACK ANALYSIS

  • 35 GEMM-dominant and 26 Conv-dominant cases account for most of the 73 performance-regression fallbacks, while 7 cases generated no Triton kernels and 5 had E2E correctness failures.The fallback classification uses kernel-name keyword matching, not profiling-derived runtime attribution; Gate 4 preserves the baseline when E2E performance regresses.Source: §F.1 · p. 23, Figure 4 · p. 23

F.2 MULTI-KERNEL COMPOSITION GAP: FULL CASE LISTING

  • 37 of 126 multi-kernel problems show a composition gap, where isolated sub-kernel gains do not translate into whole-model gains.In the most extreme case, four of six sub-kernels improve by 10.02×, 2.36×, 1.16×, and 3.77×, yet the model reaches only 0.93× E2E versus torch.compile.Source: §F.2 · p. 23

F.3 L3 ARCHITECTURE BREAKDOWN

  • Conv-dominant architectures account for most L3 fallbacks, while MLP- and attention-based models show higher optimization rates when non-library kernels contribute meaningful runtime.The architecture breakdown covers all 50 L3 models and reports sub-kernel ranges, optimized counts, and dominant fallback causes by family.Source: §F.3 · p. 24, Table 11 · p. 24, Figure 5 · p. 24

G.1 L1 KERNEL 012: DIAGONAL MATRIX MULTIPLY (88.63×)

  • For C = diag(A) · B with a 4096-element A and 4096 × 4096 B, KernelOPT reports an 88.63× speedup over torch.diag(A) @ B by replacing the O(N^3) GEMM with O(N^2) row scaling.The optimization pass further improves memory access patterns.Source: §G.1 · pp. 25–26

G.3 L1 KERNEL 007: MATMUL AUTOTUNE OPTIMIZATION (2.89×)

For L1-007, KernelOPT combines lower register pressure with expanded autotuning to improve matmul performance. In tutorial-kernel tests, it also finds gains on some expert-written Triton and Helion kernels, using only the first two verification gates.

G.3 L1 KERNEL 007: MATMUL AUTOTUNE OPTIMIZATION (2.89×)

  • 2.89× speedup for L1-007 combines approximately 2× from occupancy improvement with 1.4× from tile-size optimization.Casting operands to FP16 before tl.dot reduces register use from 184 to 125 per thread and doubles theoretical occupancy; the winning smaller output tiles improve L2 cache utilization.Source: §G.3 · pp. 26–27, Figure 6 · p. 27

H TUTORIAL KERNELS

  • 4/10 Triton tutorial kernels and 5/10 Helion tutorial kernels improve, with best gains of 1.70× and 1.08×, respectively.These expert-written starting points are evaluated in single-kernel mode, so model-level verification Gates 3–4 do not apply.Source: H TUTORIAL KERNELS · p. 27

I GATE 3 CORRECTNESS VERIFICATION: ρ DISTRIBUTION ANALYSIS

The reported Gate-3 error-ratio statistics cover rejected candidates, not accepted ones. Rejections were far from the threshold and usually recovered on retry, but the missing accepted-side logging leaves decision-boundary behavior unmeasured.

I.1 QUANTITATIVE SUMMARY (REJECTED CANDIDATES ONLY)

I.2 KEY OBSERVATIONS •

  • Every logged true-ratio rejection was at least 1,569, more than 150× above ρmax = 10, so none was borderline.The threshold is therefore not observed near a decision boundary among these rejected candidates.Source: §I.2 · p. 28
  • 160 of 161 true-ratio rejections were transient and passed on a subsequent retry; only one problem reached terminal E2E correctness failure via a ρ rejection.Four other terminal correctness failures arose from crashes, timeouts, or output-shape mismatches, not ρ rejection.Source: §I.2 · p. 28, Table 12 · p. 28
  • Because accepted-candidate ρ values are not logged, the study cannot establish false-positive or false-negative rates or how close accepted values come to ρmax.The appendix identifies logging the accept branch as future work.Source: I GATE 3 CORRECTNESS VERIFICATION: ρ… · p. 27, §I.2 · p. 28

J HARDWARE AND SOFTWARE CONFIGURATION

  • Table 13 summarizes the hardware, software, and hyperparameter configuration used across the experiments.Source: Table 13 · p. 29

Related papers

Loading 2609.30059v2…