pypto-optimization

PyPTO 性能优化（持续补充）

规则 1：连续搬运先达阈值，再在归约轴找甜点

对包含归约的算子（softmax、logsoftmax、sum/amax/amin，以及 mean=sum/count 语义）按以下优先级：

• 对固定题型 shape=(16,256,256), dim=1，默认模板直接用 set_vec_tile_shapes(1, 16, 256)。
• 先满足硬约束：prod(tile_shape) <= 16384 且 auto_tiles <= 2048。
• 若 auto_tiles > 2048，优先引入 loop + view/assemble 分块，再做 tile 微调。
• 若编译/验证出现 UB 或 OoOSchedule 相关报错，优先降 prod(tile_shape)（常见从 16384 -> 8192 -> 4096）。
• 先让连续搬运达经验阈值：contiguous_bytes(tile) >= 1KB（经验值，第一性能门槛）。
• 在同等可编译约束下，未达 1KB 的候选默认淘汰，不能仅因“规约轴不分段”直接入选。
• 只有当可编译候选都达不到 1KB 时，才在 <1KB 候选中比较规约轴分段与实测。
• 达到阈值后，不要默认“规约轴越大越快”；对规约轴 tile 做候选实测（默认顺序 16 -> 32 -> 64），按实测选甜点。
• tile 不浪费：优先让每一维 tile[i] <= shape[i]。tile[i] 远大于对应维度通常不会增加有效并行，反而会浪费 tile 预算并抬高 auto-tiling 开销。
• 禁止误读：不是“越连续越好”也不是“归约轴不切分”。连续搬运达标后，目标转为减少规约分段，而不是继续放大非规约轴 tile。

其中（关键，禁止误算）：

• contiguous_bytes(tile) = contiguous_tile_elems * dtype_bytes
• contiguous_tile_elems 指一次连续搬运段里的 tile 元素数，不是原始 shape 元素数。
• Vec 场景默认按最后一维估算：contiguous_tile_elems = tile[last_axis]（不做转置/置换时）。
• 连续搬运阈值判定前，优先满足 tile[last_axis] <= shape[last_axis]；不要通过 tile > shape 做“折算达标”。
• FP32 常用阈值：contiguous_tile_elems >= 256（约 1KB）
• FP16/BF16 常用阈值：contiguous_tile_elems >= 512（约 1KB）
• 反例：shape=(16,256,256), dim=1, tile=(1,256,64) 时，连续搬运按 tile[2]=64 算，仅 64*4=256B，未达到 1KB。

原因

• 连续搬运不足时，访存碎片和跨步开销会先成为瓶颈。
• 连续搬运达到高效区后，进一步放大通常边际收益很低。
• 归约轴 tile 过大时，单 task 可能过胖（局部归约树更重、寄存器/流水压力更高）。
• 归约轴 tile 过小时，分段与合并开销会上升。
• 因此常见是非单调关系（U 型），需要在达标候选中找甜点，而不是单调追大。

示例 A：Softmax (16, 16384), dim=1

• set_vec_tile_shapes(1, 8192)：每行 2 段（优先）
• set_vec_tile_shapes(2, 4096)：每行 4 段
• set_vec_tile_shapes(4, 4096)：每行 4 段，且更多预算给了非归约轴

经验上，(1, 8192) 通常优于 (2, 4096) 和 (4, 4096)。

示例 B：Reduction (16, 64, 256, 256), dim=1

• set_vec_tile_shapes(1, 16, 1, 256) / (1, 32, 1, 256) / (1, 64, 1, 256)：均满足连续搬运达标，需做甜点比较。
• set_vec_tile_shapes(1, 1, 16, 256)：虽然连续搬运达标，但归约轴未被有效利用，通常是劣候选。

这个例子体现了层级规则：连续搬运先达标，达标后做归约轴甜点搜索。

示例 C：TripletMarginLoss Phase-1 (128, 4096), dim=1