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

71–80 of 176 posts

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

#71

Post by s_gourichon »

lambdaone wrote: post #60
amelius wrote: post #51

Earlier quoted context omitted.

Can't git-bisect simply ignore commits with a commit message smaller than N characters?

That might sound facile, but it's actually a great idea. Being able to ignore commits based on regexes would be even more powerful.

Not sure it really has huge benefits, but I guess something like this should work:

``` #!/bin/sh N=20 msg_len=$(git log -1 --pretty=%B | wc -c) if [ "$msg_len" -lt "$N" ]; then exit 125 fi # Here you would run your actual test and report 0 (good), 1 (bad) as needed exit 0 ```

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

#72

Post by chedabob »

Cthulhu_ wrote: post #65
fooker wrote: post #5

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

nVidia got their pitchforks back in 2003: https://web.archive.org/web/20051218120547/http://techreport...

And again in 2010, although as far as I'm aware this was just based on speculation and it was never proved that it was intentional, or that the optimisation would have netted the gains the author said: https://web.archive.org/web/20250325144612/https://www.realw...

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

#73

Post by davedx »

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…

> 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!)

This is an extremely opinionated and time consuming way of working. Maybe in this context it makes sense (nvidia driver kernel somethings), but I don't think it's universally the best way to write code together.

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

#74

Post by davedx »

kilpikaarna wrote: post #7

Keeping it real with the commit msgs

Some criticism of the author here regarding how they structure their diffs.

They "made something ~100 tflops faster" and peoples' comments are "their commit messages are bad"? You guys would hate how John Carmack worked, too

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

#75

Post by gorgoiler »

davedx wrote: post #73
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…

> 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!) This is an extremely opinionated and time consuming way of working. Maybe in this context it…

I agree that it’s time consuming but the complexity is constant, in my personal experience and with helping others, in that once you start writing long form commit messages (a) you only ever get faster at it, as a skill; and (b) it’s hard to stop!

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

#77

Post by reitanuki »

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.

Plenty of people do. At least at my work (and yes we squash PRs too). For some changes it's an easy way to make review way more sane.

For an illustration of the scale of this, search GitHub for 'commit by commit': https://github.com/search?q=%22commit+by+commit%22&type=pull... (2M results)

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

#78

Post by kilpikaarna »

davedx wrote: post #74
kilpikaarna wrote: post #7

Keeping it real with the commit msgs

Some criticism of the author here regarding how they structure their diffs. They "made something ~100 tflops faster" and peoples' comments are "their commit messages are bad"? You guys would hate how John Carmack worked, too

I was appreciative/shitposting.

Would love to see Carmack's commit messages. Just the other day I unsuccessfully tried to look for pictures of his office newer than QuakeIII era. Want ti figure out his ergonomics for working (presumed) 10h days well into middle age.

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

#79

Post by benji-york »

kilpikaarna wrote: post #78
davedx wrote: post #74

Earlier quoted context omitted.

Some criticism of the author here regarding how they structure their diffs. They "made something ~100 tflops faster" and peoples' comments are "their commit messages are bad"? You guys would hate how John Carmack worked, too

I was appreciative/shitposting. Would love to see Carmack's commit messages. Just the other day I unsuccessfully tried to look for pictures of his office newer than QuakeIII era. Want ti figure out his ergonomics for working (presumed) 10h days well into middle age.

Looks pretty normal: https://playcanv.as/p/apIKHp7a
Post reply on HN