|
|
|
|
|
by lmm
1771 days ago
|
|
What's the use case for that kind of behaviour? AIUI the main point of Loom is so that we can go back to writing in (logical) thread-per-request style for IO-bound network servers. If you've got a CPU-bound workload then it's presumably not interactive so writing it in high-throughput high-latency batch style would be more natural, so it's hard to think why you'd want millions of threads for a CPU-bound workload. (I guess maybe some kind of entity simulation thing where you want to write one thread per entity? But I'm not sure you'd expect a huge speedup from that versus just doing the whole thing single-threaded). |
|