Skip to content

Commit 5cdbbfa

Browse files
LessUpCopilot
andcommitted
docs: consolidate public entry pages
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
1 parent dcac6e7 commit 5cdbbfa

12 files changed

Lines changed: 84 additions & 252 deletions

File tree

README.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ A CUDA SGEMM engineering notebook designed for both deep learning and interview
1515
- **Progressive kernel ladder**: naive -> tiled -> bank-conflict-free -> double-buffer -> Tensor Core.
1616
- **Evidence-first reporting**: performance claims are paired with correctness policy and scope labels.
1717
- **Comparable interfaces**: FP32 kernels share a unified `(A, B, C, M, K, N, stream)` launcher contract.
18-
- **Interview-ready narrative**: dedicated pages for project highlights, interview walkthrough, and references.
18+
- **Interview-ready narrative**: architecture, methodology, validation, and references reinforce one public story.
1919
- **Bilingual mirrored docs**: English and Chinese public pages stay aligned.
2020

2121
## Quick start
@@ -39,8 +39,9 @@ Runtime tests and benchmarks require a CUDA-capable local machine. Hosted CI is
3939
| Open English home | [Docs Home](https://lessup.github.io/sgemm-optimization/en/) |
4040
| Open Chinese home | [中文首页](https://lessup.github.io/sgemm-optimization/zh/) |
4141
| Build and run once | [Getting Started](https://lessup.github.io/sgemm-optimization/en/getting-started) |
42-
| Understand differentiation | [Project Highlights](https://lessup.github.io/sgemm-optimization/en/project-highlights) |
43-
| Prepare interview explanation | [Interview Playbook](https://lessup.github.io/sgemm-optimization/en/interview-playbook) |
42+
| Understand differentiation | [Architecture Overview](https://lessup.github.io/sgemm-optimization/en/architecture/) |
43+
| Prepare interview explanation | [Methodology](https://lessup.github.io/sgemm-optimization/en/methodology/) |
44+
| Check trust boundaries | [Validation Overview](https://lessup.github.io/sgemm-optimization/en/validation/) |
4445
| Trace technical lineage | [References](https://lessup.github.io/sgemm-optimization/en/references) |
4546
| Read normative specs | [OpenSpec Specs](openspec/specs/) |
4647

README.zh-CN.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@
1515
- **优化链条完整**:naive -> tiled -> bank-conflict-free -> double-buffer -> Tensor Core。
1616
- **证据优先表达**:性能结论与正确性策略、测量范围一起呈现。
1717
- **接口保持一致**:FP32 kernel 使用统一 `(A, B, C, M, K, N, stream)` launcher 契约。
18-
- **面试友好叙事**提供项目亮点、面试手册、参考文献三类高价值入口
18+
- **面试友好叙事**架构、方法论、验证与参考资料共同支撑同一条公共叙事
1919
- **中英文镜像文档**:公开页面结构保持一致,便于传播与复用。
2020

2121
## 快速开始
@@ -39,8 +39,9 @@ ctest --test-dir build
3939
| 打开中文首页 | [中文首页](https://lessup.github.io/sgemm-optimization/zh/) |
4040
| 打开英文首页 | [Docs Home](https://lessup.github.io/sgemm-optimization/en/) |
4141
| 编译运行一次 | [快速上手](https://lessup.github.io/sgemm-optimization/zh/getting-started) |
42-
| 了解项目差异化 | [项目亮点](https://lessup.github.io/sgemm-optimization/zh/project-highlights) |
43-
| 准备面试表达 | [面试手册](https://lessup.github.io/sgemm-optimization/zh/interview-playbook) |
42+
| 了解项目差异化 | [架构概述](https://lessup.github.io/sgemm-optimization/zh/architecture/) |
43+
| 准备面试表达 | [方法论](https://lessup.github.io/sgemm-optimization/zh/methodology/) |
44+
| 查看可信边界 | [验证概览](https://lessup.github.io/sgemm-optimization/zh/validation/) |
4445
| 追溯技术来源 | [参考文献](https://lessup.github.io/sgemm-optimization/zh/references) |
4546
| 阅读规范源 | [OpenSpec 规范](openspec/specs/) |
4647

docs/en/architecture/index.md

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -18,6 +18,12 @@ This repository is not organized as “one fast kernel plus a benchmark screensh
1818

1919
That structure makes the project useful for learning, review, and interviews: readers can explain **why** a kernel exists before they talk about how fast it is.
2020

21+
## What this repository is trying to prove
22+
23+
- SGEMM optimization should read as a reasoning chain, not a bag of isolated tricks.
24+
- Performance claims only count when they stay attached to correctness policy and benchmark scope.
25+
- Tensor Core acceleration is only persuasive when constraints and fallback behavior are explicit.
26+
2127
## System map
2228

2329
| Layer | Responsibility | Where to go next |
@@ -83,6 +89,14 @@ This is not just process documentation. It affects how the architecture is narra
8389
4. Read [Tensor Core Path](/en/architecture/tensor-core-path) before interpreting WMMA benchmark numbers.
8490
5. Use the existing kernel deep dives when you want implementation detail instead of system rationale.
8591

92+
## Fast reviewer path
93+
94+
1. Read this page for the system claim.
95+
2. Read [Kernel Ladder](/en/architecture/kernel-ladder) for the optimization order.
96+
3. Read [Validation Overview](/en/validation/) before trusting any benchmark claim.
97+
4. Read [Methodology](/en/methodology/) when you need the concise explanation path used in reviews or interviews.
98+
5. Use [Resources Hub](/en/resources/) to trace external sources and comparison points.
99+
86100
## Related resources
87101

88102
- [Resources Hub](/en/resources/)

docs/en/interview-playbook.md

Lines changed: 0 additions & 92 deletions
This file was deleted.

docs/en/methodology/index.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,23 @@ flowchart TD
3737
3. **Use local GPU evidence early.** Diagnosis without runtime evidence usually misclassifies the bottleneck.
3838
4. **Hand every speedup to Validation.** A gain only counts after correctness, scope, and reproducibility are re-checked.
3939

40+
## Interview-ready framing
41+
42+
Use this structure when you need to explain the project concisely in a review or interview:
43+
44+
1. **Problem framing** — SGEMM is a useful proxy for memory hierarchy, parallel mapping, and mixed-precision trade-offs.
45+
2. **Optimization ladder** — each kernel changes one bottleneck class at a time.
46+
3. **Correctness and trust model** — cuBLAS is the oracle, tolerances differ between FP32 and WMMA, and unsupported WMMA shapes fall back explicitly.
47+
4. **Measurement discipline** — end-to-end and compute-only numbers are separated, and hosted CI is kept separate from local GPU proof.
48+
5. **Engineering maturity** — unified launcher interfaces, RAII/error handling, mirrored docs, and OpenSpec governance show the work is maintained deliberately.
49+
50+
### High-value deep-dive questions
51+
52+
- **Why not just use cuBLAS?** Production code should, but this repository exists to demonstrate bottleneck diagnosis and defensible optimization reasoning.
53+
- **Why is the Tensor Core path still behind cuBLAS?** The WMMA path here is educational and intentionally exposes staging, alignment, and fallback costs instead of hiding them behind a production-tuned stack.
54+
- **How do you know the performance claims are trustworthy?** The project checks correctness first, labels benchmark scope explicitly, and separates CI-safe checks from local GPU runtime evidence.
55+
- **What would you improve next for production work?** Architecture-specific launch tuning, deeper WMMA overlap, stronger profiler evidence, and CUTLASS-style maintainable kernels.
56+
4057
## Read this section in order
4158

4259
1. [Learning Path](/en/learning-path)

docs/en/project-highlights.md

Lines changed: 0 additions & 31 deletions
This file was deleted.

docs/en/validation/index.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -50,3 +50,10 @@ Treat every number in this repository as **scoped evidence**, not a universal pr
5050
- Only then compare the number to another result.
5151

5252
If any of those fields are missing, the number is a hint, not a claim.
53+
54+
## Common presentation mistakes
55+
56+
- Claiming “Tensor Core is always faster” without shape, conversion, and fallback caveats.
57+
- Quoting one GFLOPS number without its benchmark label or workload scope.
58+
- Ignoring the numerical-tolerance difference between FP32 and mixed precision.
59+
- Treating hosted CI success as proof of CUDA runtime correctness or performance.

docs/zh/architecture/index.md

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -18,6 +18,12 @@ title: 架构概述
1818

1919
这样的结构让项目同时适合学习、评审和面试:读者可以先解释 **为什么** 某个 kernel 存在,再讨论它快了多少。
2020

21+
## 这个仓库真正想证明什么
22+
23+
- SGEMM 优化应该被讲成一条推理链,而不是零散技巧合集。
24+
- 性能结论只有和正确性策略、benchmark 范围一起出现时才可信。
25+
- Tensor Core 加速只有在约束条件和 fallback 行为都说清楚时才有说服力。
26+
2127
## 系统地图
2228

2329
| 层次 | 责任 | 下一步阅读 |
@@ -83,6 +89,14 @@ title: 架构概述
8389
4. 在解释 WMMA benchmark 前,先阅读 [Tensor Core 路径](/zh/architecture/tensor-core-path)
8490
5. 当你需要实现细节而不是系统原因时,再跳转到各个 kernel 深入页。
8591

92+
## 给评审者的快速路径
93+
94+
1. 先看本页,确认系统主张。
95+
2. 再看 [Kernel 阶梯](/zh/architecture/kernel-ladder),理解优化顺序。
96+
3. 在相信 benchmark 之前,先看 [验证概览](/zh/validation/)
97+
4. 需要简洁的复述与答辩框架时,转到 [方法论](/zh/methodology/)
98+
5. 需要技术来源与对照材料时,转到 [资源中心](/zh/resources/)
99+
86100
## 相关资源
87101

88102
- [资源中心](/zh/resources/)

docs/zh/interview-playbook.md

Lines changed: 0 additions & 92 deletions
This file was deleted.

docs/zh/methodology/index.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,23 @@ flowchart TD
3737
3. **尽早使用本地 GPU 证据。** 没有运行时证据的诊断,通常会误判瓶颈。
3838
4. **所有提速都必须交给验证章节。** 只有重新通过正确性、范围与可复现性审查后,速度提升才算成立。
3939

40+
## 面试与评审时的讲述框架
41+
42+
当你需要在评审或面试里快速说明这个项目时,建议按下面的顺序组织:
43+
44+
1. **问题定义** —— SGEMM 是理解内存层级、并行映射和混合精度权衡的高价值代理问题。
45+
2. **优化阶梯** —— 每一级 kernel 只针对一种瓶颈类别做改变。
46+
3. **正确性与可信度模型** —— 以 cuBLAS 为 oracle,FP32 与 WMMA 使用不同容差,WMMA 不满足条件时显式回退。
47+
4. **测量纪律** —— 区分端到端与 compute-only,并把托管 CI 与本地 GPU 证据严格分开。
48+
5. **工程成熟度** —— 统一 launcher 接口、RAII/异常处理、双语镜像文档和 OpenSpec 治理共同说明这是被认真维护的工程案例。
49+
50+
### 高价值追问与回答框架
51+
52+
- **既然有 cuBLAS,为什么还做这个?** 生产场景当然优先用 cuBLAS,但这个仓库的目标是展示如何定位瓶颈、验证结论,并把优化讲清楚。
53+
- **为什么 Tensor Core 路径仍然落后于 cuBLAS?** 这里的 WMMA 实现是教学型路径,刻意保留 staging、对齐与 fallback 成本,而不是把它们隐藏在生产级调优栈里。
54+
- **你怎么证明性能结论可信?** 先过正确性,再标清 benchmark 范围,并把 CI 可验证内容与本地 GPU 运行时证据分开。
55+
- **如果要继续做成生产项目,下一步会是什么?** 架构特化 launch 调优、更深的 WMMA overlap、更完整的 profiler 证据,以及更可维护的 CUTLASS 风格内核方案。
56+
4057
## 建议阅读顺序
4158

4259
1. [学习路径](/zh/learning-path)

0 commit comments

Comments
 (0)