6 ms·
Threads are bad for high concurrency. Specifically when you need to call out to another service that has some latency. Say you have 1000 threads. To handle a r
by nullwasamistake 7y ago
Threads are bad for high concurrency. Specifically when you need to call out to another service that has some latency.
Say you have 1000 threads. To handle a request each one needs to make 50ms of external or DB calls. In one second, each thread can handle 20 calls. So you can handle 20k requests/second with 1000 threads. But Rust is so fast it can serve 500k requests a second. So with regular threads, you need ~25,000 threads. The OS isn't going to like that.
With async you can run a single thread per core, with no concurrency limits. So you get your 500k requests without overhead. With fibers you just run 20k fibers which is a little bit of overhead but easy to do.
This is the core reason everyone is pushing async and fibers in fast languages. When you can push a ton of requests/second but each one has latency you can't control, regular threads will kneecap performance.
In "slow" languages like Python, Ruby, etc, async/fibers don't really matter because you can't handle enough requests to saturate a huge thread pool anyways.
- staticassertion 7y agoJava services have managed for a long time to do just fine. Usually you just have dedicated threadpools for those db/ whatever calls. But yes, eventually, for very heavy cases (more than what I would call "high") you will want async/await.
- pjmlp 7y agoWhich can still be done via java.util.concurrent (Callable, Futures, Promises, Flow) until Project Loom arrives.
- j88439h84 7y agoIn Python I use async instead of threads for reasons unrelated to performance. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html
- noncoml 7y agoWhy only 1000 threads? Why not 10k or 100k? With 8k stack for each, you can easy have 10k-100k threads in a low-end system
- MrBuddyCasino 7y agoLet's be real here, its not just the memory requirements, because context switching and the associated nuking of cpu caches are not free. You can go very far with it nowadays, but you can go much farther with async code, if you really need to.
- noncoml 7y agoNobody is denying that async code is faster. But it’s not as dramatic as presented in the grand parent post. And IMHO the added code complexity is not worth the trouble.
- MrBuddyCasino 7y ago> And IMHO the added code complexity is not worth the trouble. The thing is, this is just that - your opinion, generalized as The Truth. But engineering is about making the right trade-offs. Often threading will be fine, you'll win simplicity, and all is good. But sometimes you really need the performance, or your field is crowded and its a competitive advantage. Think large-scale infrastructure at AWS, central load-balancers, or high-freq-trading.
- zzzcpan 7y agoIt goes deeper than that. There is plenty of research showing that shared memory multithreading is not even a viable concurrency model. The premise that threads are fine and simple is just false.
- pcwalton 7y agoI'm not sure what you mean. One of Rust's major research contributions is to show that shared memory multithreading is a perfectly viable concurrency model, as long as you enforce ownership discipline to statically eliminate data races.
- noncoml 7y ago
- pcwalton 7y ago25,000 threads are perfectly fine on Linux.
- je42 7y agoit is the memory associated with a posix thread that becomes the limit.