4 ms·

Just a note that it seems many people think the main problem isn't the context switch. Rather, Linux by default allocates a very large stack to every thread, an

Just a note that it seems many people think the main problem isn't the context switch. Rather, Linux by default allocates a very large stack to every thread, and thus many threads lead to high memory usage. Async makes this better. See e.g. this recent clip from one of the engineers on Project Loom in which they argue that the context switch is relatively low overhead: https://youtu.be/07V08SB1l8c?si=i0v9w90Kb_M0I4gP&t=966 https://youtu.be/07V08SB1l8c?si=i0v9w90Kb_M0I4gP&t=966

gwbas1c 3y ago
At least on Windows I've reconfigured the stack space. (I had to run an experiment that required a lot of threads.) Is this something that's hard to do on Linux?
- steveklabnik 3y ago
  It's the same, but this issue gets to one of the hearts here: Both of these APIs are set by you, the user. You can choose how big to set your stack size, it's true. However, what value do you actually set? Too high, and you're still using too much memory, though admittedly less. Too low, and you either need to accept death by stack overflow, or runtime detect this case and fix things up. With async/await in Rust, the compiler can statically see how large the stack size needs to be. Each "thread" will have a perfectly sized stack. No user intervention required, no fiddling with settings.
  - 10000truths 3y ago
    > Both of these APIs are set by you, the user. You can choose how big to set your stack size, it's true. However, what value do you actually set? Too high, and you're still using too much memory, though admittedly less. Too low, and you either need to accept death by stack overflow, or runtime detect this case and fix things up. This is a solved problem - it's "just" the longest path in a call graph where each node is weighted by its function's stack frame size. > With async/await in Rust, the compiler can statically see how large the stack size needs to be. Each "thread" will have a perfectly sized stack. No user intervention required, no fiddling with settings. There is nothing stopping a compiler from doing the exact same analysis for a sync function at compile time (barring exceptions like varargs or deliberate recursion). They just... haven't, for some reason. It's a shame that it took until Zig for it to be addressed.
MrBuddyCasino 3y ago
The stack memory won’t actually be physically allocated upfront - like all user space memory it is virtual.

gwbas1c 3y ago

At least on Windows I've reconfigured the stack space. (I had to run an experiment that required a lot of threads.) Is this something that's hard to do on Linux?

steveklabnik 3y ago
It's the same, but this issue gets to one of the hearts here: Both of these APIs are set by you, the user. You can choose how big to set your stack size, it's true. However, what value do you actually set? Too high, and you're still using too much memory, though admittedly less. Too low, and you either need to accept death by stack overflow, or runtime detect this case and fix things up. With async/await in Rust, the compiler can statically see how large the stack size needs to be. Each "thread" will have a perfectly sized stack. No user intervention required, no fiddling with settings.
- 10000truths 3y ago
  > Both of these APIs are set by you, the user. You can choose how big to set your stack size, it's true. However, what value do you actually set? Too high, and you're still using too much memory, though admittedly less. Too low, and you either need to accept death by stack overflow, or runtime detect this case and fix things up. This is a solved problem - it's "just" the longest path in a call graph where each node is weighted by its function's stack frame size. > With async/await in Rust, the compiler can statically see how large the stack size needs to be. Each "thread" will have a perfectly sized stack. No user intervention required, no fiddling with settings. There is nothing stopping a compiler from doing the exact same analysis for a sync function at compile time (barring exceptions like varargs or deliberate recursion). They just... haven't, for some reason. It's a shame that it took until Zig for it to be addressed.

MrBuddyCasino 3y ago

The stack memory won’t actually be physically allocated upfront - like all user space memory it is virtual.