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

User-defined tuning parameters #2154

Open
athas opened this issue Jun 6, 2024 · 5 comments
Open

User-defined tuning parameters #2154

athas opened this issue Jun 6, 2024 · 5 comments

Comments

@athas
Copy link
Member

athas commented Jun 6, 2024

It would be nice to have a language facility that can allow a user to add their own tuning parameters. A tuning parameter is essentially a hidden argument of type i64 that you configure through the context. The idea is not that they are used for changing the result of the program (although there is no way to check for that), but for configuring chunk sizes and such.

We already have runtime support for tuning parameters constructed by the compiler itself, so we just need a syntax and semantics for it at the source level. One approach would be a builtin function tuning_param used like this:

tuning_param "my_important_parameter" 100

The string is used for the external name of the tuning parameter, and the 100 is the default value. It's a slightly magical function, because the string (which is just a literal of type []u8 as far as Futhark is concerned) must be a literal so the compiler can fish it out. Alternatively we could do it with an attribute:

#[tuning_param(my_important_parameter)] 100

This also requires some thinking about what happens if that 100 is not a constant.

@athas
Copy link
Member Author

athas commented Jun 26, 2024

I have come to prefer this notation:

#[tuning_param(my_important_parameter)] 100

It will require an extension to the IR, as we need to make GetSize a BasicOp, but that is no big deal. We will also require the ability to pass a default expression to GetSize, rather than deriving it exclusively from the size class. The code generation for GetSize will also have to be a bit different, as the default may depend on run-time values, which is not the case for our current tuning parameters.

@athas
Copy link
Member Author

athas commented Jun 26, 2024

Another question is how/when to type check the default value. Maybe we need an actual language feature, instead of faking it via attributes.

@athas
Copy link
Member Author

athas commented Jul 20, 2024

Chapel's config declarations are very interesting, but perhaps overkill for our needs.

@athas
Copy link
Member Author

athas commented Jul 20, 2024

Requiring the attribute to be on a value definition might be a good idea, however.

@athas
Copy link
Member Author

athas commented Aug 18, 2024

@coancea we should talk about this one, since I remember you've wanted it before.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant