Incremental Async Computation and Reporting Progress

[BGR360]

Background: Fractal Visualizer Project

My pet project to get more acquainted with the Rust ecosystem is to implement an interactive fractal visualizer in Rust.

I have two simultaneous goals:

• 100% interactivity / responsiveness

  • Leverage the iterative nature of fractal computation to incrementally render the computed fractal images to the screen, gradually getting more and more detailed and accurate.
  • Do not block the main event loop on any computation.
  • Quickly pivot the async computation when the user changes parameters.

• Speeeeeeeed

  • Leverage as much CPU (and eventually GPU) power as I can in between frames.
  • Avoid as much overhead as possible (e.g., passing large pixel buffers between threads).
  • Try to leverage compute shaders with double precision and/or a parallel computation library like ArrayFire to crunch the intense floating point math.

I wrote the initial prototype using SDL2 and rayon, with a simple message-passing scheme between the main render thread and a driver thread. However, I'm realizing that all the features I eventually want to add will probably outgrow this approach. After reading more deeply into Bevy, it seems that the ECS architecture could work quite nicely for me.

Main Question: Incremental Async Computation

In short, what is the most "Bevitious" way to report progress and/or yield a series of intermediate results from an async computation?

Currently the only async example in the Bevy repo spawns tasks whose results are not available until they are computed in their entirety. Fractals, by contrast, are computed iteratively, and can produce usable results after every iteration.

I will admit that I'm not well-versed in futures-like programming. I do have a pretty solid grasp of traditional shared-memory multithreading and message-passing, but not so much futures. So if this is something common that has already been discussed ad nauseam, then I'll happily be shooed away to other resources.

If and when I figure this out, I'd be happy to contribute another example to the Bevy repo illustrating how to report progress from async tasks (seems like that would be a common thing to do).

[morgul77]

I don't know bevy, and I don't know rust (reading and learning both). But my thoughts after reading this:

1. Start a task that generate a fractal
2. Start a task to receive a result
3. If result received, start a task for the next result
4. When generation is finished, pass a message to the receiving task that it should not restart.

[Ratysz]

You could use a library like async-channel to send back intermediate results as they become available. The receiving system can then read them synchronously using Receiver::<FractalResult>::try_recv().

The "pivoting" can also be arranged using an async channel. You can send inputs to your compute task synchronously from your Bevy app, and on the other end you'll need to select!() between computation future and the Receiver::<FractalInput>::recv() future.

[djeedai]

@Ratysz or anyone familiar with Bevy internals, can you confirm my suspicion that Bevy's Events and its EventReader and EventWriter cannot be used in this case, because one side (consumer or producer, depending on the direction of the messages) is not a Bevy system? Would it be possible to modify events to work here? Or is it too clunky, and coupling a Bevy system with a non-Bevy "processor" running in a separate thread really call for a third-party Bevy-independent solution?

One extra use case I can think of in the same vein as @BGR360's own use case above, and which I think is fairly common nowadays in games, is an HTTP request to communicate with an online service. Note also that you can do that with a blocking thread but it's not as nice as using proper async. So there's the extra complication of having an async runtime run in parallel of Bevy (and potential CPU resource starvation issues).

More generally, the docs would benefit of guidance to implement any scenario where a blocking task requires a separate thread, and how to communicate between that thread and a Bevy system. Ping @alice-i-cecile in case that's already under your radar. I also have a use case that might come soon, so happy to take that one and go investigate.

[alice-i-cecile]

More generally, the docs would benefit of guidance to implement any scenario where a blocking task requires a separate thread, and how to communicate between that thread and a Bevy system. Ping @alice-i-cecile in case that's already under your radar. I also have a use case that might come soon, so happy to take that one and go investigate.

This would be helpful! My direct experience with async is minimal, so I'll mostly be of use on the project management / technical writing side.

For now, doing some digging and turning it into a Bevy example would be incredibly useful and should be able to be done largely independently. That will serve both as an alternate form of documentation and as a basis to write up a page in the Book.

[Ratysz]

[...] can you confirm my suspicion that Bevy's Events and its EventReader and EventWriter cannot be used in this case [...]

Events are not a channel, so, correct, you cannot use them for this purpose.

[...] async runtime run in parallel of Bevy [...]

Bevy already has an async runtime built into it, bevy_tasks. A Bevy-powered project I work on uses it to drive its futures just fine.

[djeedai]

• executor_parallel has an example use of async_channel
• asset_server has some examples of async use, but not all of them are relevant