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

41–50 of 176 posts

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

#41

Post by mattlondon »

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...

Just in case anyone else parsed that sentence the same way as me, ati detected "quake" as the executable and changed things like texture quality etc to increase benchmark performance. Some people discovered this after they renamed the executable to "quack" and the image quality improved but the benchmarks were lower, proving that the ati drivers "optimised" by reducing quality.

Ati did not rename quake to quack as I originally thought from this! :)

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

#42

Post by globular-toast »

lloeki wrote: post #33
kristopolous wrote: post #18

Earlier quoted context omitted.

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)

No need to make a "backup" branch. Learn to trust the reflog.

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

#43

Post by stahorn »

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...

The proper way to work with git: Commit like a madman on your private branch. Short messages, written in seconds, just to be able to remember what you were doing if you are interrupted and have to get back into your work later. If you have a CI pipeline, often you have to make small changes until it works, so no reason to bother with smart commit messages.

At some point, you will have something working that makes sense that clean up. Then use interactive rebase to create one or a few commits that "makes sense". What makes sense is one of these topics that could create a whole bike garage, but you and your team will have some agreement on it. One thing that I like is to keep pure refactorings by themselves. No one cares to review that you've changed typos in old variables names and things like that. If it's a separate commit, you can just skip over it.

Depending on if you are completely done or not, the resulting branch can be sent as a PR/MR. Make sure that all commits have a reason why the change was made. No reason to repeat what the code says or generate some AI slop message. Your knowledge of why a change was done in a certain way is the most valuable part.

Of course, this way of working fits my work, that is not cloud based in any way and with lots of legacy code. It creates git history that I would like to have if I have to take over old projects or if I have to run git bisect on an unfamiliar code base and figure out some obscure bug. You might have a completely different technology stack and business, where it makes sense to work in some other way with git.

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

#44

Post by a_wild_dandan »

mattlondon wrote: post #41
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...

Just in case anyone else parsed that sentence the same way as me, ati detected "quake" as the executable and changed things like texture quality etc to increase benchmark performance. Some people discovered this after they renamed the executable to "quack" and the image quality improved but the benchmarks were lower, proving that the ati drivers "optimised" by reducing quality. Ati did not rename quake to quack as I…

Thank you for explaining. I was so confused at how AMD was improving Quake performance with duck-like monikers.

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

#45

Post by toolslive »

nil novi sub soli.

- Intel faced a "cheating compiler" controversy when SPEC, the benchmark standard-setter, invalidated over 2,600 benchmark results for Intel Xeon processors in early 2024. ( https://www.tomshardware.com/pc-components/cpus/spec-invalid... )

- microsoft doing similar things (java benchmarks, C compiler benchmarks)

- and everybody cheating on AI benchmarks (https://www.thestack.technology/ai-benchmarking-scandal-were...)

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

#46

Post by ffsm8 »

DaiPlusPlus wrote: post #38
stpedgwdgfhgdd wrote: post #31

Earlier quoted context omitted.

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.

I think you're missing context.

He's saying that he likely has an MCP connected to jira on the LLM he's developing with.

Hence the prompt will have already referenced the jira ticket, which will include the why - and if not, you've got a different issue. Now the LLM will only need something like "before committing, check the jira ticket we're working on and create a commit message ...

But whether you actually want that is a different story. You're off the opinion it's useful, I'd say it's rarely doing to be valuable, because requirements change, making this point in time rational mostly interesting in an academic sense, but not actually valuable for the development you're doing

It depends on a ton of factors, and at least I'd put very little stock in the validity of the commit message that it might as well not exist. (And this is from the perspective of human written ones, not AI)

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

#47

Post by darrenf »

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.

Isn't "Fix dynamic channel list" the reason?

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

#48

Post by mort96 »

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.

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 compile force the bisecter to step through commits one by one until they find one which compiles, linearizing a process which should be logarithmic.

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

#49

Post by rkomorn »

jjcob wrote: post #35
WildGreenLeave wrote: post #27

Earlier quoted context omitted.

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".

But... I keep being told that commit messages are useless because the code is the documentation, so code diffs are self-explanatory...

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

#50

Post by tylerchr »

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.

You might be surprised. Yours sounds like the attitude of someone who has not had the luxury of reviewing well-constructed commits. PRs with intentional commits permit both faster and deeper reviews—but alas, not everyone is so respectful of their reviewers’ time and energy.
Post reply on HN