[MTHREADS] document Conv1D padding benchmark optimization investigation

[gao0624]

Description

This is an investigation-only PR documenting the Conv1D padding benchmark optimization investigation. No production code change is included.

conv1d_padding is a benchmark/pytest scope (benchmark/test_conv1d.py -m conv1d_padding), not a separate FlagGems operator. The underlying operator is flag_gems.conv1d, whose canonical implementation reuses Conv2D via unsqueeze/squeeze.

A dedicated FP16 true-1D implicit-GEMM Triton prototype (historical reference: PR #6027) was evaluated against the canonical Conv2D-via-unsqueeze path on MTT S5000 to determine whether the Conv1D padding benchmark workload distribution justified a production MTHREADS Conv1D override.

The prototype showed a strong local win on the representative K7g2 dispatch-hit case (1.87x vs canonical), but no sufficiently broad, regression-free production dispatch region was established across the evaluated padding benchmark shapes. The dedicated prototype was therefore not landed; the canonical Conv1D path remains the production default.

Performance

IMPORTANT: The dedicated measurements below are investigation/prototype results. They do not represent production FlagGems performance because the dedicated Conv1D kernel was not landed. Canonical Gems Speedup represents the current production path.

FP16 investigation results

Status	Mode	Shape	Torch Latency (us)	Canonical Gems Latency (us)	Prototype Latency (us)	Canonical Gems Speedup	Prototype Gems Speedup	Prototype vs Canonical
SUCCESS	forced	K3 32×64×512, 64×64×3, g=1, fp16 p=1	30.700	70.400	70.100	0.436x	0.438x	1.004x
SUCCESS	forced	K5 64×48×1024, 128×48×5, g=1, s=2, fp16 p=2	47.000	245.800	290.000	0.191x	0.162x	0.848x
SUCCESS	dispatch-hit	K7g2 16×24×2048, 96×12×7, g=2, fp16 p=3	73.000	148.500	79.400	0.492x	0.919x	1.870x
SUCCESS	fallback	K11 8×8×8192, 16×8×11, g=1, fp16 p=5 (same)	80.000	140.000	140.000	0.571x	0.571x	1.000x

Definitions:

• Canonical Gems Speedup = Torch Latency / Canonical Gems Latency
• Prototype Gems Speedup = Torch Latency / Prototype Latency
• Prototype vs Canonical = Canonical Gems Latency / Prototype Latency (>1 = prototype faster)

Mode explanation:

• forced: prototype manually forced for investigation; not production routing
• dispatch-hit: candidate structural dispatch selects dedicated prototype
• fallback: candidate routing selects canonical implementation

Key Findings

• K7g2: Dispatch-hit case; prototype wins 1.87x vs canonical (148.5 us → 79.4 us). Isolated result in a single benchmark configuration.
• K3: Forced measurement; near parity (1.004x). Does not satisfy dispatch condition (in_c/g=64 > 32).
• K5: Forced measurement; material regression (0.848x, ~15% slower). Does not satisfy dispatch condition (in_c/g=48 > 32, kernel=5 < 7).
• K11: Fallback; same-padding routes to canonical by design (symmetric padding limitation).
• No sufficiently broad regression-free production dispatch region was established.

Decision

Prototype not landed. Canonical Conv2D-via-unsqueeze path remains production default. Future optimization should examine the underlying Conv2D execution path.

Validation

• 28/28 relevant tests/test_conv1d.py cases passed during the final investigation run.
• Benchmark methodology: triton.testing.do_bench, warmup=200, iter=500, fresh process + fresh cache.
• All numbers auto-computed from raw latencies.

CI

• rule-check: pass
• linter: pass
• unit-test: pass
• backend jobs: skipped (docs-only change)

Detailed analysis, architecture, methodology, environment, and benchmark provenance are in docs/notes/mthreads-conv1d-investigation.md.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}