Kernel code and hardware constraints are difficult to reason about when memory movement, tiling, and generated representations remain disconnected.
The implementation
What I built
Built an interactive source-and-inspector workbench with kernel presets, hardware choices, parameter controls, and explicit separation between static estimates and measured GPU behavior.
Python
PyTorch
Triton
TypeScript
React
CUDA
Features
Inspect and edit kernel presets
Explore hardware and tile parameter choices
Compare illustrative IR and roofline estimates
Architecture
Next.js and React workbench with an editable source pane.
TypeScript static analyzer derives illustrative compiler representations and hardware estimates.
Separate Python/Triton kernel implementations and hardware-specific correctness/benchmark paths.
Engineering decisions
Expose hardware assumptions beside the estimates.
Keep frontend analysis distinct from actual Triton compilation and GPU execution.
Validation and measured results
The current frontend source has four kernel presets and four hardware specification profiles. These are implementation counts, not measured hardware runs.
The local browser workbench renders source, parameter controls, and analysis output. No GPU benchmark was executed for the portfolio.
Historical T4 speedup tables require independently inspectable hardware receipts; those values are not used as portfolio performance claims.
Limits and unfinished work
The browser analyzer does not invoke a real Triton GPU compiler.
Illustrative IR, occupancy, and roofline output do not prove device execution or speedup.
Kernel correctness and performance depend on hardware, shapes, layouts, and numerical tolerances.
