Omar SobhandClaude Opus 4.7
7b23f61632
Hand-authored skill catalog anchored to real 2026-07 versions:
- Rust 1.97.1 (stable), edition 2024
- React 19.2.7, Server Components + Actions
- TailwindCSS 4.3.3 (CSS-first config, Oxide engine)
- three.js r185 (WebGPURenderer stable, BatchedMesh matured)
- React Native 0.86 / Expo SDK 54+ (New Architecture default)
- cargo-nextest 0.9.140, gitleaks 8.20+, cargo-audit 0.21+
- Postgres 17 (18 in beta, don't rely on)
- CUDA Blackwell, Metal Apple7+, ROCm CDNA3
Ships 15 skills across the categories:
foundation/ workspace-repo-commit-protocol
small-focused-commits
tdd-red-green-refactor
code-review-checklist
int-xx-marker-protocol
decompose-int-items
rust/ write-rust-current-edition
rust-error-handling
cargo-test-driven-development
rust-async-tokio-idioms
backend/ postgres-migrations-forward-only
postgres-index-selection
api-pagination-day-1
frontend/ react-19-server-components
tailwind-v4-idioms
component-4-state-model
mobile/ expo-managed-vs-bare
rn-flashlist-perf
gpu/ gpu-coalescing-and-occupancy
roofline-model
threejs/ threejs-perf-and-teardown
security/ cargo-audit-workflow
secret-scanning-gitleaks
skills_loader.rs walks skills/**/*.md, parses YAML frontmatter
(name, description, when_to_use, tags), upserts via
skills_catalog::upsert_builtin. Idempotent per boot — bumps version
+ appends skill_versions row ONLY when body changes. Deterministic
sha256-derived ids so builtins are stable across boots.
Dockerfile copies skills/ to /etc/clawmates/skills. Server boot
task spawns loader alongside team_template_loader.
Follow-ups (Slice 3.5c continuation, future PRs):
- 20-30 more skills (duckdb, shadcn composition, a11y, WebGPU
migration, metal frame capture, rocprof, deep gitea forge
integration, semgrep rulepacks)
- Bind skills to team template roles (add [role.skills] refs to
templates/teams/*.toml + wire template_role_skills population
in team_template_loader)
Co-Authored-By: Claude Opus 4.7 <[email protected]>
75 lines
2.9 KiB
Markdown
75 lines
2.9 KiB
Markdown
---
|
|
name: roofline-model
|
|
description: The roofline model — is your kernel compute-bound or memory-bound? Estimate arithmetic intensity before optimizing.
|
|
when_to_use: You're the arch_analyst or bench_engineer role sizing up a GPU kernel before or after implementation.
|
|
tags: [gpu, performance, analysis]
|
|
---
|
|
|
|
# The roofline model
|
|
|
|
Before you optimize anything, know which wall you're hitting.
|
|
|
|
## The two rooflines
|
|
|
|
- **Peak memory bandwidth** — how many bytes/sec your GPU can pull from HBM.
|
|
- **Peak compute** — how many FLOPs/sec your GPU can execute.
|
|
|
|
Where they meet defines the **ridge point** (in FLOPs / byte). Kernels to the left of the ridge are memory-bound; to the right, compute-bound.
|
|
|
|
## Reference numbers (2026)
|
|
|
|
| Device | Peak BW (TB/s) | Peak FP32 (TFLOP/s) | FP16/BF16 tensor | Ridge (FLOP/B, FP32) |
|
|
|---|---|---|---|---|
|
|
| NVIDIA B200 (Blackwell) | 8.0 | 80 | ~2200 tensor | ~10 |
|
|
| NVIDIA H100 | 3.35 | 67 | 989 tensor | ~20 |
|
|
| AMD MI300X (CDNA3) | 5.3 | 163 | ~2600 tensor | ~31 |
|
|
| Apple M3 Max | 0.4 | 14 | — | ~35 |
|
|
|
|
*Rough figures — verify against the actual SKU. Ratios matter more than absolutes.*
|
|
|
|
## Arithmetic intensity
|
|
|
|
FLOPs performed per byte read from HBM. Compute it BEFORE writing the kernel:
|
|
|
|
```
|
|
GEMM (A: MxK, B: KxN, C: MxN, all FP32):
|
|
FLOPs = 2*M*N*K
|
|
Bytes = 4*(M*K + K*N + M*N) (naive, no tiling)
|
|
AI = 2*M*N*K / (4*(M*K + K*N + M*N))
|
|
For M=N=K=1024: AI ≈ 170 FLOP/B → compute-bound on H100
|
|
For M=N=1024, K=32: AI ≈ 15 FLOP/B → memory-bound on H100
|
|
```
|
|
|
|
## What the diagnosis tells you
|
|
|
|
**Memory-bound** — DON'T optimize the math. Reduce bytes:
|
|
- Fuse kernels to keep data in registers/shared.
|
|
- Use lower precision (FP16/BF16/INT8) if numerics allow.
|
|
- Better tiling to reuse loaded data.
|
|
- Coalesce (see [[gpu-coalescing-and-occupancy]]).
|
|
|
|
**Compute-bound** — DON'T optimize the loads. Feed the ALU:
|
|
- Use tensor cores (Nvidia) / matrix cores (AMD) / AMX / metal Simd matrix ops.
|
|
- Instruction-level parallelism (multiple independent FMAs per thread).
|
|
- Higher occupancy is often COUNTERPRODUCTIVE — you want registers, not more threads.
|
|
|
|
**Balanced (near the ridge)** — hardest. Small changes tip you into one regime or the other. Profile OFTEN.
|
|
|
|
## Reporting
|
|
|
|
Every kernel benchmark report includes:
|
|
```
|
|
Kernel: gemm_fp32_tiled
|
|
Achieved throughput: 52 TFLOP/s (78% of 67 TFLOP/s peak)
|
|
Achieved bandwidth: 280 GB/s (8% of 3.35 TB/s peak)
|
|
Arithmetic intensity: 180 FLOP/B
|
|
Regime: compute-bound
|
|
Bottleneck to attack: tensor core underutilization — WMMA fragment misaligned
|
|
```
|
|
|
|
## Anti-patterns
|
|
|
|
- **Optimizing math on a memory-bound kernel.** Doubling FLOPs while DRAM saturates changes nothing.
|
|
- **Micro-benchmarking without measuring HBM traffic.** Wall clock alone can't tell you which regime you're in.
|
|
- **Skipping roofline "because we already know it's slow".** You don't know the CEILING until you plot it.
|