futhark about emu HOT 7 OPEN

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.

from emu.

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.)

from emu.

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()

from emu.

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.

from emu.

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

from emu.

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

from emu.

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..

from emu.