Created engine_cccl_patterns.py — NOT parameter tuning, but architecture
design patterns extracted from reading CCCL source code as model input:
6 patterns from 4 CCCL source files (read as complete files, not grep):
1. dispatch_reduce.cuh → GridEvenShare work distribution
Maps to paged_attention_v2 partition planning.
BI-V100: max_blocks = 2×16×5 = 160 CTAs.
2. agent_reduce.cuh → Reduce tile config (register-limited, NOT SMEM)
KEY FINDING: reduce loads to REGISTERS via striped access, not SMEM.
This means tile = tpb×ipt×type_size ≤ 48KB is WRONG for reduce.
BI-V100 can use items=32 for float32 (CCCL SM100: items=16).
3. agent_scan.cuh → Scan tile config (SMEM-limited via BlockLoad staging)
KEY FINDING: scan DOES use SMEM staging (BlockLoad → BlockScan → BlockStore).
Strict constraint: tpb×ipt×type_size ≤ 48KB.
4. single_pass_scan_operators.cuh → Delay is DEAD on BI-V100
KEY FINDING: line 130: if (gridDim.x < 500) → threadfence_block
BI-V100 max grid = ~32 << 500 → ALL delay strategies are identical.
dcid/ns/l2w parameters have ZERO effect. Focus on ipt/tpb/load_algo.
5. summary_statistics.cu → Compound reduce (Welford) merge
Maps to V2 cross-partition log-sum-exp merge.
Structurally identical to Welford parallel variance merge.
6. cc_dispatch.cuh → Policy precomputation (lowest_cc_resolver)
Pre-compute all Qwen3.6 configs at import time, not runtime.
