Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 176 posts

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

#31

Post by stpedgwdgfhgdd »

WildGreenLeave wrote: post #27
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…

It is missing the (to me) most important part. The reason why these changes are made.

True, you need to instruct the AI agents to include this.

In our case the agent has access to Jira and has wider knowledge. For commit messages i don’t bother that much anymore (i realise typing this), but for the MRs I do. Here i have to instruct it to remove implementation details.

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

#32

Post by lmm »

gorgoiler wrote: post #30
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.

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 any broken commit is likely to have a neighbour that works - isolated bad commits aren't a problem (that's what skip is for, and it's easy enough to include that in your script - you do automate your bisects, right?), long chains of bad commits are). Squashing means your bisect will land on a squashed commit, when it's only really done half the job. (In particular, the very worst case, where every single one of your intermediate commits was broken, is the same as the case you get when you squash)

> When it’s ready for the attention of your peers then you absolutely ought to dress it up as smartly as possible. It’s at that point that you write a cover letter for your change: what was the situation before, why that was bad, what this patch does instead, and how you proved in practice that it made things better (tests!)

And that's what the PR description is for! You don't have to destroy all your history to make one.

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

#33

Post by lloeki »

kristopolous wrote: post #18
lemonlearnings wrote: post #16

Earlier quoted context omitted.

Claude, look at this git history, analyse diffs and create an intelligent commit message to replace each commit message. Do a rebase to fix it all up.

Would you actually do that? It's information destruction. You can machine generate at any time, but you can only delete the human input once

> you can only delete the human input once

    git branch "backup/$(git branch --show-current)/$(date +%s)"
    # do whatever you fancy
    git reset --hard "backup/$(git branch --show-current)/${thattimestampabove}"
You can't lose anything as long as you have a pointer to it (which doubles as making it easy to find)

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

#34

Post by a-french-anon »

haunter wrote: post #17

Heh. Does anyone remember when almost 25 years ago ATI (AMD) caught manipulating the Quake III benchmarks by renaming the executables to ‘quack’? https://web.archive.org/web/20230929180112/https://techrepor... https://web.archive.org/web/20011108190056/https://hardocp.c... https://web.archive.org/web/20011118183932/www.3dcenter.de/a...

Or Intel checking for "GenuineIntel" in ICC's output: https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Support...

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

#35

Post by jjcob »

WildGreenLeave wrote: post #27
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…

It is missing the (to me) most important part. The reason why these changes are made.

I hate it when I look at some code, wondering why I added a refresh call at that point, I do a git blame to find the commit message, and it says "add refresh call".

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

#36

Post by fancyfredbot »

fooker wrote: post #5

When intel did it, the pitchforks came out. Nvidia seems to get a pass. Whys that?

Intel disabled optimisations when they detected they were running on their competitors hardware. The motivation was to make competitors compare badly in benchmarks.

Nvidia are disabling optimisations on their own hardware. The motivation appears to be related to these optimisations being unsafe to apply to general code.

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

#37

Post by gorgoiler »

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…

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 represents the approved change and its description. For me, the commit is created the moment a review is requested, instead of from the moment it is approved and landed. One reason this is particularly useful is that you can now treat the commit as if it had already landed on the main branch. (It is easier to share, cherry-pick, rebase, etc. — easier than doing so with a branch of many commits, in my experience.)

Prospective changes do not change type (from branch to squashed commit or merge commit) either, when they are approved, which simplifies these workflows.

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

#38

Post by DaiPlusPlus »

stpedgwdgfhgdd wrote: post #31
WildGreenLeave wrote: post #27

Earlier quoted context omitted.

It is missing the (to me) most important part. The reason why these changes are made.

True, you need to instruct the AI agents to include this. In our case the agent has access to Jira and has wider knowledge. For commit messages i don’t bother that much anymore (i realise typing this), but for the MRs I do. Here i have to instruct it to remove implementation details.

> you need to instruct the AI agents to include this.

The agent can't do that if you told Claudepilotemini directly to make some change without telling it why you were prompting it to make such a change. LLMs might appear magic, but they aren't (yet) psychic.

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

#39

Post by xnorswap »

spullara wrote: post #21
RestartKernel wrote: post #9

Earlier quoted context omitted.

I much prefer this over those AI generated commit messages that just say "refactored X" every single commit.

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.

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

#40

Post by globular-toast »

lmm wrote: post #22
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...

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.

The only sane thing a maintainer can do with something like this is squash it into one commit. So if you care about `git bisect` then you don't want this.

Why do I care? Interesting question. I'm generally a person who cares, I guess. In this specific case it seems analogous to a mechanic having a tidy workshop. Would you leave your bicycle with someone head to toe in grease and tools strewn all over the place? I wouldn't.

Post reply on HN