Implementation of irregular flattening

[athas]

This highly WIP PR contains an implementation of full flattening as a transformation that goes from the SOACS representation to GPU. It is the result of a few hours of hacking and can handle the following program:

def main = map (\n -> #[unsafe] i64.sum (iota n))

Flattened versions of all core Futhark constructs must be defined, and so far I have only done Iota and Reduce. The main design challenge was the representation of irregular arrays in the compiler, as well as the overall structure of the algorithm. It is currently based on (irregular) distribution, much like the moderate flattening algorithm. I think that is the best way to do it.

The ultimate goals are:

1. Replace the current implementation of flattening with one that is more principled (the old one is really dirty in places because I had no idea what I was doing).
2. Maintain incremental flattening, just in a more principled framework. The "fully flattened" code version will only be used as a last resort.
3. Experiment with whether (possibly virtualised) full flattening may perhaps have acceptable performance in the intra-group case.
4. Support compiling any Futhark program to GPU code; not just the subset that uses only regular nested parallelism.
5. Bring back recursive functions.

An explicit non-goal is adding support for irregular arrays in the source language.

[Munksgaard]

Wow, this is exciting stuff! What are the prospects for success?

[athas]

There is no real risk of this not succeeding. Flattening a first-order monomorphic language is not particularly difficult, although implementing all the cases will be tedious. The main challenge is writing the code in a clean and maintainable way. Time is the main constraint.

That's only for naive flattening, though, which is notoriously inefficient in practice. It's a more open question how efficient we can make it subsequently. I'm fairly confident we can do a good job, though.

The only somewhat bothersome wrinkle is that we allow arbitrary (potentially irregular) parallelism in reduce/scan/histogram operators. Flattening doesn't have a solution for that. However, nontrivial parallelism in those operators is exceedingly rare, and in all cases these constructs can be turned into maps without any asymptotic overhead, so we can always do that for the really nasty cases. (Although so can the original programmer who writes the source code.)

[melsman]

I like it!! Also the return of recursion... man. 17. okt. 2022 kl. 13.57 skrev Troels Henriksen < ***@***.***>:

…

There is no real risk of this not succeeding. Flattening a first-order monomorphic language is not particularly difficult, although implementing all the cases will be tedious. The main challenge is writing the code in a clean and maintainable way. Time is the main constraint. That's only for *naive* flattening, though, which is notoriously inefficient in practice. It's a more open question how efficient we can make it subsequently. I'm fairly confident we can do a good job, though. The only somewhat bothersome wrinkle is that we allow arbitrary (potentially irregular) parallelism in reduce/scan/histogram operators. Flattening doesn't have a solution for that. However, nontrivial parallelism in those operators is exceedingly rare, and in all cases these constructs can be turned into maps without any asymptotic overhead, so we can always do that for the really nasty cases. (Although so can the original programmer who writes the source code.) — Reply to this email directly, view it on GitHub <#1740 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI5DO5II43RN2VHMXJCTLDWDU5JDANCNFSM6AAAAAARGPEMCI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[FluxusMagna]

What does the type of a irregular nested array look like? [n][?]a or similar? I guess existentials come in handy here somehow?

Will there be any limitations on recursion? For example, I'd assume we still wouldn't have recursive data types.

[athas]

This is not a source language extension, so there will be no (source) irregular arrays. in the core language, they are represented as flag arrays with flag vectors.

There will be no restrictions on recursive functions, but still no recursive data types (these would require a more substantial change to the internal value representation).