When teaching async Rust, there is often an emphasis on concurrency vs parallelism.
-
When teaching async Rust, there is often an emphasis on concurrency vs parallelism. Why? Why is it considered more important here than when programming in threads? IMO it applies equally in both systems, it's just apparent in different ways
-
@nrc I can only speak to my experience but: I was already used to having parallelism in other programming languages, by spawning a thread per CPU core and processing data in parallel. Or by running a process per core.
When I first used Rust I relied on this model, requiring many CPU cores to get parallelism. This proved expensive! But then I discovered Tokio and concurrent IO on one thread. This felt really different and saved a lot of money on buying VM cores.
-
@nrc Sure, I could scale Tokio across many CPU cores or threads, but my really simple end-to-end probe (for Cloudflare) didn't need many CPU cores, they were all sitting idly waiting for IO. Discovering concurrency without parallelism was a really big deal for me at that point.
-
@adam_chal would that be meaningfully different to running multiple OS threads on one core?
-
@nrc @adam_chal
Regular threads will eat num threads x stack size mem. You have min scheduling latency of ≈1ms. So in worst case each thread will wait num threads * 1ms. (in case with file io Tokio will give you the same results :)) -
@deafbeef @adam_chal yeah, this is the well-known benefit of async over threads. My question is more whether there is a fundamental change in the programming logic or if there is a real-life performance improvement or capacity improvement of the implemented system
-
@nrc @deafbeef @adam_chal there can be significant performance differences due to context switching
