Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it

Post by amelius » Fri, Oct 03, 2025, 9:02 AM UTC

lmm wrote: post #32

gorgoiler wrote: post #30

Earlier quoted context omitted.

You have the right idea but, I believe, the wrong reasoning with your first two arguments. git-bisect works best when every commit works , contains a single idea, and stacks in a linear history. These features are of most use in a publicly visible branch, and is why it is helpful to squash an entire pull-request into a single, atomic commit — one which clearly defines the change from before- to after-this-feature. Yo…

> git-bisect works best when every commit works, contains a single idea, and stacks in a linear history. That works best in a publicly visible branch, and is why it is helpful to squash an entire pull-request into a single, atomic commit — one which clearly defines the change from before- to after-this-feature. Disagree; git-bisect works best when every commit is small and most commits work (in particular, as long as…

Post by 1313ed01 » Fri, Oct 03, 2025, 9:06 AM UTC

gorgoiler wrote: post #37

lmm wrote: post #32

Earlier quoted context omitted.

> git-bisect works best when every commit works, contains a single idea, and stacks in a linear history. That works best in a publicly visible branch, and is why it is helpful to squash an entire pull-request into a single, atomic commit — one which clearly defines the change from before- to after-this-feature. Disagree; git-bisect works best when every commit is small and most commits work (in particular, as long as…

Thanks for responding. Everything you say I agree with. I think our differences lie in the scope of how much of my private activity do I want to share in public. You’re right that GitHub, GitLab et al let you use their tooling to write the final commit message (for the merge commit or squash commit). My preference has always been to do that in git itself. In both cases you end up with a single atomic commit that repr…

Post by [deleted] » Fri, Oct 03, 2025, 9:09 AM UTC

mort96 wrote: post #48

lmm wrote: post #22

Earlier quoted context omitted.

Why do you care? Small commits are great for git bisect, and having to come up with a fancy message can break your flow. Code reviewers generally review a whole PR diff, not the individual commits. Fussing about commit messages smacks of prioritising aesthetics over functionality.

Small commits where each commit represents nothing of value and doesn't compile are terrible for git bisect. And for code review. A code reviewer doesn't care that you spent 10 days across 100 commits tweaking some small piece of code, the code reviewer cares about what you ended up with. The bisecter probably wants to compile the code at every commit to try and see if they can reproduce a bug. Commits which don't co…

Post by [deleted] » Fri, Oct 03, 2025, 9:13 AM UTC

almostgotcaught wrote: post #24

globular-toast wrote: post #12

Someone really needs to learn to use `git commit --amend`. Almost 100 commits with pointless commit messages like "wip" or "x"? Be kinder to your reviewers...

Literally no one looks through the individual commits in a PR that's gonna be squashed. I don't care if it's 10 or 10,000 - I'm always gonna review the full thing.

Post by lambdaone » Fri, Oct 03, 2025, 9:16 AM UTC

xnorswap wrote: post #39

spullara wrote: post #21

Earlier quoted context omitted.

what kind of AI are you using that generates shitty commit messages? This a common kind of message from Claude / Augment: Fix dynamic channel list by passing auth via metadata - Pass userId and userEmail in metadata when calling HTTP transport - AuthenticatedToolsProviderFactory now reads from context.metadata - Each tools/list request creates a fresh ToolsProvider with authentication - Execute command description no…

> - Tested locally and working correctly This is completely meaningless and just pollutes the log.