search

diku-dk / futhark

:boom::computer::boom: A data-parallel functional programming language
http://futhark-lang.org
ISC License
2.41k stars 166 forks source link

User-defined tuning parameters #2154

Open athas opened 5 months ago

athas commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 4 months ago

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

athas commented 4 months ago

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

athas commented 3 months ago

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