[flagged]
Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
81–90 of 176 posts
Re: Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
#82Heh. 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...
Are there any archives of that techreport article with images intact?
Ah yes they changed the site and URL system after some years, here is the OG one with screenshots
Page 1 https://web.archive.org/web/20071028172853/http://techreport...
Page 2 https://web.archive.org/web/20111130162817/http://techreport...
Page 3 https://web.archive.org/web/20080213212637/http://techreport...
Page 4 https://web.archive.org/web/20101110031431/http://techreport...
Page 5 https://web.archive.org/web/20101108144857/http://techreport...
Re: Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
#83Earlier 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.
God I can't stand it when I get this kind of output from Claude, they really need to train it out for Claude 5.
"[Tangentially related emoji] I have completed this fully functional addition to the project that is now working perfectly! There are now zero bugs and the system is ready for deployment to production! [Rocketship emoji]"
Then of course you test it out and it doesn't work at all! It's very grating. It would be more bearable if it hedged its claims a bit more (maybe that will negatively affect the quality of the results though - if training a model to output insecure code also makes it a murderous Hitler admirer then, since when humans hedge their output is less likely to be perfect, it may mean it pushes the model to output code that is less than perfect).
Re: Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
#84Reminds me of when ~10 years ago with a particular version of Webpack the build would fail if I had one SVG called add.svg so I had to rename it plus.svg
or breaking numpy by importing your api key from a little file you wrote called "secret.py" :P
Re: Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
#85It would be nice if we could find economics that allowed us to share code instead of all the bullshit with the binary blob drivers. Same for basebands and everything else. How many collective hours and months of our society’s finest minds has been wasted reverse engineering binary blobs, controllers through IO pins, trying to reverse engineer circuit schematics —- when all of this is already sitting on someone’s computer somewhere and they could just GIVE you the docs. CUDA and NVIDIA can go to hell.
Re: Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
#86Earlier quoted context omitted.
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
[deleted]
Re: Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
#87Earlier 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…
I've followed your same approach but switched to having just "most of the commits work" after I found out about git bisect --skip.
Re: Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
#88Someone 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.
> that's gonna be squashed
Isn't your interpretation backwards in some cases? What I mean, is that _because_ you see the intermediate commits are garbage, you _then_ decide not to review the individual commits (because you are interested in the contribution anyway).
I certainly do care for the hobby FOSS projects I maintain, and bad commit messages + mega-commits won't fly at my day job.
Squash-merging has the advantages of making 1 PR == one commit with the PR ID in the commit message, sure, but it's unfortunately promotes bad Git hygiene (and works around it)
Re: Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
#89Sometimes you write some heavily tuned code in a high level language like C++ that you know could be translated into very specific GPU assembly, then find that the compiler isn't producing the exact assembly that you had in mind.
When you talk to the computer team about it they may offer a range of solutions, some of which may not be applicable to open source code. Picture proprietary #pragmas, intrinsics, or whatnot. What do you do? You can't ship a high performance library that doesn't deliver high performance. It is then when you rely on things like function names to enable specific code transformations that can't be used in general because they would sometimes break third party code.
I never worked on Cutlass, but this is the sort of thing that is done in the real world.
There is nothing nefarious about this sort of optimizatkon. People comparing this to cheating on benchmarks by rendering lower quality images are not on the right track.
Re: Fp8 runs ~100 tflops faster when the kernel name has "cutlass" in it
#90Reminds me of when I was working on NVIDIA Jetson systems, and learning how to use them, that you can run 1 command to make everything go faster... (https://jetsonhacks.com/2019/04/10/jetson-nano-use-more-powe...)