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

171–176 of 176 posts

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

#171

Post by mort96 »

lmm wrote: post #170
mort96 wrote: post #169

Earlier quoted context omitted.

But you disagree with the other part of my comment, or..?

I agree that: - Human readers don't care about the details of everything you tried - Commits that both don't compile and have no useful message are of very little value But I don't think that's an argument against making small commits with uninformative messages, because making those commits without breaking compilation - or even explicitly checking that it compiles before committing - is much easier than coming up w…

But you don't agree that it's better if those 100 tiny commits with messages like "x" and which all just tweak the same piece of code are cleaned up with some squashing and rewording before making a PR?

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

#172

Post by lmm »

mort96 wrote: post #171
lmm wrote: post #170

Earlier quoted context omitted.

I agree that: - Human readers don't care about the details of everything you tried - Commits that both don't compile and have no useful message are of very little value But I don't think that's an argument against making small commits with uninformative messages, because making those commits without breaking compilation - or even explicitly checking that it compiles before committing - is much easier than coming up w…

But you don't agree that it's better if those 100 tiny commits with messages like "x" and which all just tweak the same piece of code are cleaned up with some squashing and rewording before making a PR?

> But you don't agree that it's better if those 100 tiny commits with messages like "x" and which all just tweak the same piece of code are cleaned up with some squashing and rewording before making a PR?

Not unless they're literally just e.g. making a change and undoing it. In general 100 tiny commits with messages like "x" don't make human PR review any harder and they make (automated) bisect to find a bug better.

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

#173

Post by high_na_euv »

wiz21c wrote: post #104
high_na_euv wrote: post #70

I work with compilers And despite it not being nice, some optimizations rely on type or function names schemas/substrings/etc It sucks, but thats how it works It doesnt have to be malicious just sometimes it is safer to deploy optimization only for your libs than risk breaking stuff Or your frontend is not giving you more data which you can rely on

On function types or schema, I can understand that. But names ?

Yes.

E.g "__nvidia_experimental_feature_xyz_v1"

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

#174

Post by high_na_euv »

colejohnson66 wrote: post #157
wiz21c wrote: post #104

Earlier quoted context omitted.

On function types or schema, I can understand that. But names ?

Not exactly the same, but intrinsics in some languages are purely name+signature matched.

Sure, but will anyone name a method like "__nvidia_experimental_feature_xyz_v1"?

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

#175

Post by account42 »

darkmighty wrote: post #132
Cthulhu_ wrote: post #64

Earlier quoted context omitted.

This is weirdly common; phone chipset manufacturers did it with phone benchmarks [0], VW with emissions [1], nVidia did it with 3DMark [2], Intel with the SPEC benchmark for its Xeon processors [3], etc. When it comes to computer graphics, iirc it's pretty normalized now - graphics drivers all seem to have tweaks, settings, optimizations and workarounds for every game. (As an aside, I hate that I have to link to arch…

> graphics drivers all seem to have tweaks, settings, optimizations and workarounds for every game. Maybe hyperbole, but I think obviously they can't do this for literally every game, that would require huge personnel resources. At least looking at mesa (linked elsewhere), only ~200 games are patched, out of what 100k PC games? So <1%.

Mesa is a lot more conservative about this than the proprietary drivers.

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

#176

Post by user3939382 »

imtringued wrote: post #96
user3939382 wrote: post #85

It 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 comp…

The problem is as follows: You have a fixed cost investment to produce a software code base, then you have fixed ongoing maintenance costs, at a minimum one developer who knows the codebase. Preferably two for a commercial product. On top of that you have small distribution costs over time. E.g. servers that host the software downloads. The marginal costs per user are very small or even zero for desktop applications.…

That’s a problem but it’s not the irreducible problem. Which is that the computing stack is constructed wrong (obvious and fixable) so you have these ridiculous requirements in the first place. The capital issue is a second order effect.
Post reply on HN