futhark

[nestordemeure]

Are you aware of Futhark ?

They let the user write GPU code with highlevel functions (in a dedicated language) that are then optimized and compiled down to openCL or Cuda.

As a long term goal, using a similar approach (or integrating with their optimizer), you could let the user use an iterator (gpu_iter() ?) and optimize the code at compile time.

[calebwin]

Yes.

Multiple people have suggested to me letting the user use an iterator. But I can't produce OpenCL code without seeing the code inside the body of the for loop. The user would be limited in what code they can have inside the body of the for loop.

[nestordemeure]

If I understand the problem clearly (unability to see code outside of a macro), I see two solutions :

• incorporating iterators into the emu language (inside the emu! macro and thus perfectly visible)
• using an attribute (#[emu]) on the rust functions that use the iterator (you can then extract the iterator and rewrite it).

(As an aside, excuse me for jumping in and offering suggestions about improvement on a project to which I am not contributing. You have done a great job with emu.)

[calebwin]

These are good ideas. This is actually kind of along the lines of some of the stuff I have been thinking about recently.

And no, please don't stop - I really appreciate all input. Discussion is contribution IMO.

[timClicks]

@nestordemeure how would an iterator (with unknown length) know how to batch the data? e.g. generating the correct shape of CUDA blocks/grids

[calebwin]

Not related to your question @timClicks but the approach I ultimately went with for v0.3.0 is similar to what @nestordemeure described. I don't try to determine the length of the iterator. Rather, I inspect the structure of the for loop and match on one of several pre-defined patterns.

For example, for i in start..end where start and end are float literals is a pattern I handle. for x in &data where data is some expression is a pattern I don't yet handle but plan to. for x in data.enumerate().some_other_method() is not a pattern that I will try to handle.

Basically, at compile-time, I try to come up with expressions that evaluate to a dimensions of the grid.

• for i in 0..1000 - 1000
• for i in 0..(count * 100) - (count * 100)
• for x in &data - data.len()

[timClicks]

Really interesting @calebwin. Will take a look into the implementation.

[calebwin]

Please do!

I have a 3:1 code-to-comment ratio according to loc and I would be happy to further explain the architecture. Also, this "table of contents" may be helpful..