Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BLAS dot product kernel #413

Merged
merged 14 commits into from
Feb 28, 2024
Merged

BLAS dot product kernel #413

merged 14 commits into from
Feb 28, 2024

Conversation

gabizon103
Copy link
Collaborator

@gabizon103 gabizon103 commented Feb 19, 2024

Implements a dot product kernel that is parameterized over multiplier reuse, from #411

apps/blas/dot/dot.fil Outdated Show resolved Hide resolved

// needed for typechecking
assume RA::L == log2(N);
assume M::II <= reuses;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This assumption is a little sketchy. What is the reason this would be safe?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it is sketchy because it wouldn't always be safe. But otherwise, the compiler throws errors that the invocation of M triggers too often since we want Dot's delay to be reuses

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think one way to think about assume is that we should only use it if we know an algebraic fact is true but the compiler cannot prove it (log(2*n) = 1 + log(n)). Everything else is out of bounds for usage of assume and this doesn't quite seem like an algebraic property but more a "thing we want to be true but isn't".

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally makes sense. What should I do here, then? Because if we abstract over multiplier implementation, we need some way to reason about the multiplier's II in comparison to the entire module's II, and I'm not sure how else to do that

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you look again, I was able to get rid of this assume; I was using <'G: II> in the signature of Multipliers. Now I changed that just to <G: 1> but kept II as an output parameter (so it can be accessed elsewhere)

{

M := new Multipliers[W, N];
RA := new RAdd[W, N];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use the instance borrow syntax to specify how long both of these components are reused for.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't the time over which I reuse them depend on the output parameters of the instances? For the multiplier specifically, I would imagine that the interval would look like ['G, 'G + reuses*M::II + M::L], which we can't express.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't we express that? Can't we write:

M := new Multipliers[W, N] in ['G, 'G + reuses*M::II + M::L];

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

This is something that should be supported, right? As in we should be able to figure out what M:II and M::L are just from the instantiation, and then use them in the borrow interval.

apps/blas/dot/dot.fil Outdated Show resolved Hide resolved
@rachitnigam
Copy link
Member

@gabizon103 don't get blocked on my reviews for merging this. Push ahead and maybe add links to the tracker for things that need my review!

@rachitnigam rachitnigam mentioned this pull request Feb 25, 2024
4 tasks
@gabizon103 gabizon103 merged commit 0656bae into main Feb 28, 2024
4 checks passed
@gabizon103 gabizon103 deleted the blas branch February 28, 2024 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants