From a7e0ef11389b8ada9d670bb145bed57b765a6927 Mon Sep 17 00:00:00 2001
From: muh-pipeline <muh@project6.dev>
Date: Thu, 6 Aug 2026 02:22:13 +0000
Subject: [PATCH] [ENGINE] scan tuning: document GridThreshold=500 gate from
 CCCL source
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Read cub/agent/single_pass_scan_operators.cuh lines 136-148:
  delay<Delay, GridThreshold=500>() {
    if (gridDim.x < GridThreshold) __threadfence_block();
    else __nanosleep(Delay);
  }

BI-V100: 16 SMs × ~10 CTAs/SM = ~160 CTAs. Always < 500.
Therefore ALL delay strategies collapse to __threadfence_block().
The ns/dcid/l2w parameters are architectural no-ops on BI-V100.

This explains bench_bi100.py finding no_delay optimal — not a lucky
guess but a hard gate in CCCL's tile synchronization code. The
'ns×0.5, l2w×0.6' scaling was always computing values that would
never be used (delay() never reaches the __nanosleep branch).

Source: single_pass_scan_operators.cuh (full read, 200 lines)
---
 muh/include/muh/tuning/tuning_scan.cuh | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/muh/include/muh/tuning/tuning_scan.cuh b/muh/include/muh/tuning/tuning_scan.cuh
index 3e4ac62d..4930feda 100644
--- a/muh/include/muh/tuning/tuning_scan.cuh
+++ b/muh/include/muh/tuning/tuning_scan.cuh
@@ -1,5 +1,29 @@
 // muh/include/muh/tuning/tuning_scan.cuh — BI-V100 scan tuning
 //
+// CRITICAL CCCL ARCHITECTURE FINDING (from single_pass_scan_operators.cuh):
+//
+//   template <int Delay, unsigned int GridThreshold = 500>
+//   _CCCL_DEVICE _CCCL_FORCEINLINE void delay() {
+//     if (gridDim.x < GridThreshold) {
+//       __threadfence_block();    // ← ALL BI-V100 scans take this path
+//     } else {
+//       __nanosleep(Delay);       // ← only fires when grid > 500 CTAs
+//     }
+//   }
+//
+// BI-V100: 16 SMs × ~10 CTAs/SM max = ~160 CTAs. ALWAYS < 500.
+// Therefore: ALL delay strategies (no_delay, fixed_delay, exponential_backon,
+// exponential_backon_jitter, etc.) collapse to __threadfence_block() on BI-V100.
+//
+// This means:
+//   1. The ns/dcid/l2w delay parameters are IRRELEVANT for BI-V100.
+//   2. bench_bi100.py's finding that no_delay is optimal is CORRECT BY DESIGN.
+//   3. The "ns×0.5, l2w×0.6" scaling heuristic was always a no-op on BI-V100.
+//   4. Tuning effort should focus on threads/items/load_algo, NOT delay params.
+//
+// This architectural insight came from reading cub/agent/single_pass_scan_operators.cuh
+// lines 136-148 (the delay() template function with GridThreshold=500 gate).
+//
 // CRITICAL INSIGHT FROM single_pass_scan_operators.cuh delay():
 //   The CCCL delay function has a runtime branch:
 //     if (gridDim.x < GridThreshold)     // GridThreshold = 500