[Skinney]

For a CPU bound workload you’ll be better off using one «full» thread per cpu in a pool and submitting tasks to said pool.

Then again, the same would be true in Go. Loom simply brings goroutines to the JVM.

Go might perform better, but that can be due to many other things not specific to the concurrency implementation (like better memory utilization because not every struct is stored on the heap in Go)

[omazurov]

I thought the promise was we'd use Threads for everything and forget to worry about blocking calls. I can't run one OS thread per CPU in my proposed benchmark: I want to run millions of threads. Reimplementing it in a different concurrency model would mean Loom is hopeless for such workloads. Go may perform better but I don't think it would perform well (I see, I now have to implement my benchmark in go as well). I just don't believe their scheduler is so good.

[Skinney]

> I thought the promise was we'd use Threads for everything and forget to worry about blocking calls.

That is the promise, yes, but you specifically mentioned a CPU-bound task. A CPU-bound workload cannot hope to do much better than doing a concurrent task spread equally among the available CPU's, spawning more threads will just add coordination overhead.

If you're spawning one million threads, each of which will perform a blocking operation, then you're likely not CPU bound (unless you're doing a System.sleep(1) or the equivalent).

> I just don't believe their scheduler is so good.

I believe you pick your own scheduler. By default it uses ForkJoin, which is supposed to be pretty good, uses the same conceptual implementation as Go (work stealing), but you're free to use something else.

[omazurov]

> If you're spawning one million threads, each of which will perform a blocking operation, then you're likely not CPU bound

Imagine a DAG with million nodes. Each node takes data from all its input edges, processes it and sends to all its output edges. Now that I have light threads I want to use them to implement all nodes. Edges are naturally implemented as blocking queues. If I feed enough data into this structure I get a CPU-bound workload with a lot of concurrency (and scalability). Yet the nodes will have to block on their input queues because data will not be ready in most cases.

Now, to complicate the design, I want to have I/O tasks that read data from a file/network and feed it into the DAG and send its resulting output to the UI thread. Should I use different "threads" for different parts of the design? I'd hate to, especially given the fact that all those parts are dynamic in nature.

So, of course, I'm not currently spawning a million threads to execute all those tasks but Loom says I could do that for all my tasks and my concern is that to get decent performance I'd have to explicitly separate my "CPU-bound" tasks from my "I/O-bound" tasks and use different kinds of threads for each (which I'm kind of doing right now but again the promise was...).

[Skinney]

In that case you should be fine. It should work as well as goroutines and async/await in other languages.

As long as you do IO or other blocking operations which block for a significant amount of time (ms instead of ns), Loom will be beneficial. Otherwise, you'd do better with regular threads in a pool, but even then I'd imagine the performance difference to be tiny.

[lmm]

It's not answering your question (indeed what you've described is actually very similar to my entity simulation example), but it sounds like the actor model might be a good fit, FWIW.