futhark - Githubissues

calebwin / emu

The write-once-run-anywhere GPGPU library for Rust

https://calebwin.github.io/emu

MIT License

1.59k stars 53 forks source link

futhark #22

Open nestordemeure opened 5 years ago

nestordemeure commented 5 years ago

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

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

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

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

@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 commented 4 years ago

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

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

calebwin commented 4 years ago

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