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

21–30 of 176 posts

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

#21

Post by spullara »

RestartKernel wrote: post #9
kilpikaarna wrote: post #7

Keeping it real with the commit msgs

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 now correctly shows currently online machines
    - Tested locally and working correctly

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

#22

Post by lmm »

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.

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

#23

Post by RestartKernel »

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…

GitHub Copilot for one, and I'm pretty sure JetBrains' offering does the same.

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

#24

Post by almostgotcaught »

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.

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

#25

Post by almostgotcaught »

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.

When I was a kid and my family first moved to the US my dad used to take me for walks. He didn't know anything about the country (couldn't speak English yet) so the only thing he could comment on was what he imagined the prices of all the houses were. Some people just feel the need to comment on something even when they don't understand anything.

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

#26

Post by lloydatkinson »

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…

Every time I’ve tried to use AI for commit messages its designers couldn’t be bothered to get it to take into account previous commit messages.

I use conventional commit formats for a reason, and the AI can’t even attempt it. I’m not even sure I’d trust it to get the right designation, like “fix(foo)!: increase container size”.

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

#27

Post by WildGreenLeave »

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…

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

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

#28

Post by rbanffy »

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.

> having to come up with a fancy message

Message doesn’t need to be fancy, but it should describe what you did. Being unable to articulate your actions is a thought smell. It’s often seen when the developer is trying stuff until it sticks and needs a commit because the only way to test the fix is in a testing environment, two bad practices.

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

#30

Post by gorgoiler »

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.

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.

You’re welcome to do whatever you like in your private branch of course, but once you are presenting work for someone else to review then it’s consistent with “I believe this is now complete, correct, working, and ready for review” to squash everything into a single commit. (The fact that code review tools show the sum of all the minor commits is a workaround for people that don’t do this, not a feature to support them!)

In terms of ‘git commit -m wip’: no one is saying you should wear a suit and tie around the house, but when you show up for your senate hearing, presenting yourself formally is as necessary as it is to leave the slides, sweat pants, and tee shirt at home.

Yes, commit early and often while in the flow of putting together a new idea or piece of work. 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!)

Or to use a different analogy: they don’t want every draft of your master’s thesis from start to finish and they’ll be annoyed if they have to fix basic typos for you that should’ve been caught before the final draft. They don’t care about the typos you already found either, nor how you fixed them. They just want the final draft and to discuss the ideas of the final draft!

Conversely if your master’s thesis or git branch contains multiple semantically meaningful changes — invent calculus then invent gravity / add foo-interface to lib_bar then add foo-login to homepage — then it probably ought to be two code reviews.

Post reply on HN