and then u must pass test regarding thinking, coherency, and tool calling

Comments URL: https://news.ycombinator.com/item?id=47783621

Points: 6

# Comments: 2

Wafer exists to make performance engineers more efficient. Most of the work perf engs do is extracting signal and turning it into the next experiment. You spend hours per kernel doing interpretation and bookkeeping: which counters matter, what changed, what hypothesis you’re testing, what to try next.

Wafer is building an environment where profiling, compiler analysis, and docs are first-class context in your workflow, so iteration is cheap. long-term, that same structured context becomes the interface for an automation layer that can read the evidence, propose a change, and rerun the loop.

NVIDIA has poured an insane amount of truth into their tooling. NCU, compiler output, SASS, the counters, the sections, the warnings, the “this is why you’re slow” breadcrumbs. Serious perf engineers already live in this stuff. The real problem is that it’s still not packaged as a tight loop. You run a profile, you get a giant report, then you spend a bunch of time translating it into a plan, mapping it back to the right lines of code, deciding what to ignore, deciding what to try next, and keeping track of what you’ve already tested. That translation step is where a ton of time goes, and it’s also the part that doesn’t scale.

We're just starting out and today, Wafer makes that translation step cheaper by keeping the evidence and the code in one place. You can run Nsight Compute profiling from your editor and view results where you’re editing, so you’re not flipping between terminals, report viewers, and screenshots. You can compile CUDA and inspect PTX and SASS mapped back to your source, so “what did the compiler actually do” is something you can answer in seconds and iterate on quickly. And you can query GPU documentation from inside the editor with the exact context you’re working in.

What we’re adding and moving towards is making that loop not just faster, but more automatic and more reproducible. We’re rolling out GPU Workspaces, where you keep a persistent CPU environment for your repo and dependencies, and only spin up GPU execution when you actually run something. A lot of GPU dev time is editing, debugging, and iterating on hypotheses, not burning GPU cycles - but today the workflow forces you to keep a GPU box alive just to preserve state. We want the “run the experiment” part to be on-demand and reliable, without killing your environment.

The bigger direction is the same theme: take the evidence perf engineers already use and make it machine-legible, so an automation layer can actually act on it. We're working on tool-driven loops: read the profile, identify the highest leverage bottleneck, propose a concrete code change, run the diff, re-profile, and keep a history of what worked and what didn’t.

If you’ve ever wished you could hand an agent your kernel plus the profiler and compiler evidence and have it do real work instead of vibes, that’s what we’re building towards.

You can see more about us here: https://wafer.ai

Or download directly from here: VS Code: https://marketplace.visualstudio.com/items?itemName=Wafer.wa... Cursor: https://open-vsx.org/extension/wafer/wafer

Would love feedback from anyone doing CUDA, CUTLASS/CuTe, Triton, training or inference perf. If you try it and something feels slow, confusing, or missing, email me at emilio@wafer.ai

Comments URL: https://news.ycombinator.com/item?id=46367310

Points: 3

# Comments: 1

The problem: Current ML profilers either dump too much data (torch.profiler) or abstract away the details you need. You can't see why your model is actually slow - is it memory bandwidth? Kernel launch overhead? Cache misses?

Our approach: We're reverse engineering GPU execution to trace from Python ops down to PTX instructions. One decorator gives you the full execution graph with actual bottlenecks highlighted.

Technical details: - Traces Python → CUDA kernels → PTX with timing breakdowns - Shows memory access patterns and bandwidth utilization - Kernel occupancy and scheduling analysis - Works with PyTorch/JAX, TensorFlow coming

We used this to optimize Llama inference and found bottlenecks we couldn't see before - got 50%+ speedup: https://www.herdora.com/blog/the-overlooked-gpu

Free beta with 10 hours of profiling: https://keysandcaches.com Github: https://github.com/Herdora/kandc Docs: https://www.keysandcaches.com/docs

Curious what inference bottlenecks others are hitting that current tools can't diagnose. What's your experience with existing profilers? Would be very useful to hear thoughts from the community :)

Comments URL: https://news.ycombinator.com/item?id=44850506

Points: 1

# Comments: 0

We're building Chisel to solve this. Instead of wrestling with nvtx events and complex CUDA interfaces, you just add decorators to the functions you want to profile. As simple as:

app = ChiselApp("my-app", gpu=GPUType.A100_80GB_1)

@app.capture_trace(trace_name="gpu_task")

These 2 lines will get you the profiling trace for your code on an A100.

Run your code normally, then view results in a clean dashboard or locally.

Documentation: https://herdora.mintlify.app/

If you sign up this week, there's $50 in free credits to try it out (our profiling runs are billed by the second, so this is a ton of free profiling runs!)

We'd love feedback from anyone who gives it a shot. We're also currently developing a C++ SDK for teams that need to profile lower-level code. Let us know if this would be of interest to you. We want to learn what profiling pain points have you run into with ML codebases. Please reach out if you have any fun stories to tell :). We very much welcome contributions!

The github repo is: https://github.com/Herdora/chisel

Comments URL: https://news.ycombinator.com/item?id=44779115

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44613348

Points: 1

# Comments: 0

We're actively welcoming contributions, new hardware support, and benchmark requests.

Repo here: https://github.com/Herdora/chip-benchmark Dashboard: https://herdora.com/benchmark

Feedback and contributions welcome! We made it super easy to add other architectures by including the script we used for benchmarking.

Comments URL: https://news.ycombinator.com/item?id=44567454

Points: 3

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=44544923

Points: 8

# Comments: 0

So we built Chisel: one command to run profiling commands on any kernel. Zero local GPU hardware required.

Next up we're planning to build a web dashboard for visualizing results, simultaneous profiling across multiple GPU types, and automatic resource cleanup. But please let us know what you would like to see in this project.

Available via PyPI: pip install chisel-cli

Github: https://github.com/Herdora/chisel

We're actively developing and would love community feedback. Feature requests and contributions always welcome!

Comments URL: https://news.ycombinator.com/item?id=44463017

Points: 3

# Comments: 1

So we built Chisel: one command spins up a cloud instance, syncs your GPU code, runs profiling (supports Python/PyTorch/TensorFlow and AMD rocprofv3), and automatically pulls results back. Zero local GPU hardware required.

Next up: Web dashboard for visualizing results, simultaneous profiling across multiple GPU types, and automatic resource cleanup.

Available via PyPI: pip install chisel-cli

Github: https://github.com/Herdora/chisel

We're actively developing and would love community feedback, especially from GPU devs exploring AMD alternatives to NVIDIA. Feature requests and contributions welcome!

Comments URL: https://news.ycombinator.com/item?id=44416042

Points: 2

# Comments: 0

It spins up remote H100, L40S, or MI300X machines (via DigitalOcean for now, but gonna expand backends soon), runs your code, and gives you back detailed traces (kernel timings, memory transfers, API calls, etc). Everything is CLI-based and designed for iterative dev—profiling takes \~1–2 minutes per run.

For example:

# Profile a PyTorch training script on H100 with Nsight Systems chisel profile --nsys train.py

# Profile a HIP kernel on MI300X with system trace chisel profile --rocprofv3="--sys-trace" matrix_add.cpp

Repo: https://github.com/Herdora/chisel PyPI: pip install chisel-cli

Would love feedback! especially from anyone building custom kernels, ML layers, or low-level GPU ops.

Comments URL: https://news.ycombinator.com/item?id=44391255

Points: 3

# Comments: 0