Parallel for

[pfeatherstone]

What's the best way to implement a parallel_for() function using this library. Use stlab::async, store all the futures in a std::vector then call stlab::when_all() ? Or is there a better way?

[FelixPetriconi]

It depends a bit on your use case. You can do it this way. Be aware that it cancels all outstanding tasks as soon as the first exception is thrown, because the assumption of this function is that the results of all tasks are needed.
If you have more the use case that a stream of tasks shall be processed then you could setup a channel with sender + receiver and push all values through it.

[pfeatherstone]

I had a look at channel, but I think I want a fork/join mechanism for parallel_for(). I gave it a go with the following steps:

• Partition the for-loop range into blocks
• Call stlab::async with default_executor on each block, where each block performs a for loop on its own subrange, and store the futures in a vector
• Then call await() on each future

This worked but it added a huge amount of overhead. I then tried a very simple thread pool (no task stealing) which supports std::future, then implemented parallel_for() on top of that and the overhead was barely noticeable.

So, I'm either misusing stlab's concurrency library somehow, or the threadpool is spinning like crazy wasting resources.

[FelixPetriconi]

I think creating inner loops is not necessary. Just create a std::vectorstlab::future, pass this to a when_all and have an evaluation of the result in the associated task. In the end just create one await on the resulting future or even better add an .then() and continue there your operation. Using an await is always a blocking operation and one should avoid blocking at all costs.

E.g. like here: https://github.com/stlab/libraries/blob/main/test/future_when_all_range_tests.cpp#L119
Waiting here is just necessary for the UnitTest.

[pfeatherstone]

OK cool thank you. I'll give that a go at some point. However my super dumb implementation seems to be working fine with little or at least acceptable overhead. So I might stick to that for now. It's a bit overkill bringing in all of stlab libraries just for a parallel for. I don't need a full blown tasking system right now.