> Ahh! Yes, that would be the case. Reduce would run only once all > input-futures have become ready. > > We don't have any way to work around that at this point short of > re-implementing reduce to start working on the input elements as they become > available.
I went ahead and implemented a few versions of reduce with futures as input here: https://gist.github.com/dcbdan/7946ed38b088fbcb62aa12b40435c794 The versions I tried out are reduce_when_each - each time a future is ready, locks the mutex and then accumulates the stored value. reduce_algorithm - once all the futures are ready, call parallel reduce reduce_queue - reduces vector of futures that are ready and appends to the back of a new vector of futures. Then it recurses until the set of futures is one element and returns that. reduce_safe_object - same as when each except with no mutex and each os thread adds to its own accumulator value. Then reduces the accumulated values stored by each thread I was hoping that reduce_queue would perform the best under the right circumstances, but I'm not sure my test works quite right (or that reduce_queue works quite right). My test is intended to make a vector of futures that are ready after a prescribed length of time--i.e. following some distribution. However, every time reduce_queue is called, all of the input futures return true to is_ready. An example: suppose reduce_queue is given half input futures that are ready immediately and half input futures that take a long time to be ready. Then reduce_queue should reduce the ready half and then reduce the rest as they become ready. With my test, it seems that reduce_queue doesn't start until all of the futures are ready. Any suggestions to how I can modify the test? Or modify reduce_queue? Thanks, Daniel Bourgeois
_______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
