Blog Post: Careful what data you send or how to tank your performance with Task.async

Using the term parallel in this context is incorrect, the correct term would be concurrently and this has some very important implications:

1. You are not guaranteed that the spawned tasks will be running on a separate physical core, as this is decided by the scheduler, there are ways to configure this manually, however you will be breaking the abstraction level of concurrency used in elixir and potentially introduce locks;
2. As the scheduler switches context between running processes, every process will get a slice of execution time, naturally having more processes on the same thread will make them run slower.

@D4no0 I disagree, parallel is the correct term here or why wouldn’t it be? Yes there is no guarantee that they will all run at the same time - but with 24 available cores and the schedulers otherwise unoccupied I’m pretty certain they will. Unless you intend to make the argument that nothing on the BEAM ever runs in parallel or what am I missing?

There is definitely nothing that absolutely stops them from running at the same time, making it concurrent.

If you are not certain 100%, then you cannot claim that your tasks are running in parallel. IMO a setup where this is enforced in all cases is in order to validate parallel claims and benchmarks.

To be fair, that wasn’t very surprising. Parallelizing in such a manner only saves time when (1) there’s lots of it (not just 3 tasks) and (2) the data is not being carried around but is crunched into much smaller pieces and/or sent off to other systems (Kafka, Postgres et. al.).

But the article was informative and interesting, and I thank you for it.

Come on now. Unless you have a strict one-thread-pinned-per-core runtime then you can’t claim it for any runtime, Golang’s and Rust’s tokio’s included.

Fact is that most parallel runtimes do parallelization on a best-effort basis and they do a damn good job at it. There was a rather hilarious article a while ago reposted on HN how the Linux kernel never used more than 4 (or 8?) cores for a while, some years ago. What can a runtime do if the kernel is lying to it? But that’s a separate topic.

So… 100% guarantee? No, but it’s at least 90%.

It still doesn’t feel right to me using this term so freely, there is a reason parallel programming (for example cuda development) is an entire different paradigm with completely different concepts.

Maybe, but my goal is not a strictly academic discussion.

Unbounded parallelism is generally not a good tactic. Your workload and underlying hardware capabilities should be well understood to help determine how concurrent you want a set of tasks to go.

@D4no0 Technically it executed in parallel if at any point in time during that time 2 bits of code ran at the same time. If you think that for almost 4 minutes of run time with 24 schedulers available to erlang (and 12 physical cores) this didn’t happen then that’s some next level. Of course, it happened more than that and you could look at CPU utilization. You can always make an argument that “maybe it didn’t actually execute in parallel” even with the OS scheduler.

Most of that is beside the point though, what’s important is showing how the runtime, by default not some weird configuration, handles these work loads and what to do accordingly.

@warmwaffles The parallelism here wasn’t unbounded though right - I mean the first example explicitly has 3 tasks.

That said, of course you’re right - which is why I always advocate to benchmark things instead of assuming what’s faster/better as there are many surprises on the way

Totally! It was just a stupid example I made up to try and easily illustrate in a benchmark the problem I ran into with benchee to show-case it without all the context and overload of benchee.

edit: sorry for multi reply, tried to fold it into one again but couldn’t see how to delete this one