Include rayon?

[vitiral]

@killercup I think you have better opinions on this than I. I would just like to express my experiences integrating rayon directly into ergo_sync and see whether it is actually a dependency we want/need. @llogiq you might be interested too.

First off, rayon is a fantastic library. ergo_sync mentions it as a crate you probably want to use for parallel processing at the top of its docs.

However, I am still unclear what the cost of rayon is. A couple of questions I would like answered before we assume rayon should be included:

• What are the runtime costs of including rayon if rayon is never used? It has a zero-configuration global thread pool -- does that always exist, or is it only created when needed?
• What are the actual use cases of rayon? It seems that "trivially parallel processing of collections" is the only answer. It is generally not considered best practice to use rayon for:
  • "normal" thread pool that might be IO bound -- rayon is for performing real work, not as a general thread pool.
  • message passing / channels, as rayon does not guarantee more than one thread is running at a time (which could cause deadlock)
• What is the story of TLS (i.e. thread local variables) with rayon? I swear I found a doc saying their use was "undefined behavior" but I cannot find it again.

When I tried to use rayon for the examples in ergo_sync I found that I couldn't because of the above issues, which concerned me when including it as a core part of the parallel processing story. I found that spawn with channels accomplished pretty much everything needed, and did it very expressively with few surprises and probably very performantly as well. The way I see it, the main use of rayon is to do parking_lots of data that can be split into chunks and processed in paralel.

I would like to include rayon because it really is useful for parallel processing. Honestly par_sort() alone probably makes it a worthwhile library. However I would like to understand the pros/cons/usecases before we include it.

[cuviper]

What are the runtime costs of including rayon if rayon is never used? It has a zero-configuration global thread pool -- does that always exist, or is it only created when needed?

It is only created when needed, then exists for the rest of the process life. This is sort of natural from Rust's philosophy to avoid "life before main", so automatic init isn't really a thing. Also, if you did something like using Rayon once and never again, then the cost of the global thread pool will only be the basic presence of those sleeping threads -- no cpu time, just a little memory and OS bookkeeping.

What are the actual use cases of rayon? It seems that "trivially parallel processing of collections" is the only answer.

It's a data-parallelism library, best for CPU-bound work. But it doesn't have to be trivial -- for instance parallel sorting has partition data at each step before splitting into further parallel work.

It is generally not considered best practice to use rayon for: [IO bound / message passing / channels]

Yeah, I agree with this. Channels might be OK if the receiver is outside the pool, but generally you only want functional tree-like dependencies in rayon -- join being the main primitive for this.

What is the story of TLS (i.e. thread local variables) with rayon? I swear I found a doc saying their use was "undefined behavior" but I cannot find it again.

You're probably thinking of this note, "Because op is executing within the Rayon thread-pool, thread-local data from the current thread will not be accessible." Or maybe this one. There's no undefined behavior here. It's just more of a reminder that these really are crossing thread boundaries, so TLS will access different memory.

[vitiral]

@cuviper thanks for the clarifications!

I think with these claritfications we should probably include rayon in ergo_sync with some clear docs on how/when to use it. From the linked issue in rayon it looks like there is an effort to broaden the scope of when rayon is useful as well.

I am particularily happy that rayon does not require resources if never used. That makes me significantly happier in including it by default.