Now that we have concurrent_maplist/2, concurrent_forall/2, concurrent_and/2, does it make sense to have a concurrent_setof/3? (and concurrent_aggregate/3, etc.)? My experience with concurrent_maplist/2 is that its speed-up varies a lot: sometimes the speedup matches the number of cores; sometimes I get a slowdown (this is what I would expect).
Related: a version of setof/3 that doesn’t use sort/2 but instead uses a hash (or assoc) to guarantee unique results.
PS: It’d also be nice if concurrent_maplist/2 allowed specifying the number of threads, the way the other concurrent predicates do. Or I suppose I could use setup_call_cleanup/3 to wrap the call with a save
cpu_count, change its value, then restore (does it make sense to add such a predicate to library(thread)?) … the use case is when I have a number of predicates I want to run in parallel with a wide variation of run times and it’s impossible to predict which ones will be long running, so it’s nice to get as many as possible into the queue.
PPS: In trying to understand the implementation of setof/3, I found that it uses
$new_findall_bag, which doesn’t seem to be defined anywhere in the sources …