4 ms·

I'm not sure I understand. Are you saying that a 1:1 threading model without preemption will be more performant than an M:N threading model without preemption?

I'm not sure I understand. Are you saying that a 1:1 threading model without preemption will be more performant than an M:N threading model without preemption? How would this affect the performance of applications that spin up thousands of tasks?

limsup 13y ago
If you restrict yourself to 64 bit systems, you can essentially go back to using OS threads with blocking I/O because the address space is so large. You can fit thousands of 2MB call stacks into the processes address space and rely on the OS and MMU to manage the memory. The problem that created the whole non-blocking, async domain was the memory needed for the thread's call stacks. You don't have enough address space to place a bunch of 2MB call stacks for each thread, if you're handling tens of thousands of connections.
- masklinn 13y ago
  > The problem that created the whole non-blocking, async domain was the memory needed for the thread's call stacks. You don't have enough address space to place a bunch of 2MB call stacks for each thread, if you're handling tens of thousands of connections. c10k is (almost) 15 years old, updating it for today are the OS and MMU going to manage 10 million threads and stacks for that many connections?
- rdtsc 13y ago
  2MB call stacks? Mine are 10MB: $ ulimit -s $ 10240 I can only spawn 200 threads in the worst case and keep them active before system starts swapping. Yes memory space is large by anytime those have to run they'd have to be brought up into the working set. EDIT: nevermind, _wmd pointed out that stack memory is still virtual and it only be brought into the physical memory as needed.
  - MrBuddyCasino 13y ago
    Now I'm confused. This comment says that the stack memory is not allocated by the OS unless actually needed: https://news.ycombinator.com/item?id=6728030 https://news.ycombinator.com/item?id=6728030 Is this not true?
    - rdtsc 13y ago
      That is right, the full 8MB or 10MB or whatever of max is not being paged in. I am stupid. I'll correct the initial comment. Thanks
klodolph 13y ago
No, they're saying the performance will be slightly degraded. But you can already spin up thousands of threads on Linux without performance problems. The M:N model is notoriously difficult, making your threading system 10x as complicated usually isn't worth the 10% performance increase. Haskell is, again, the exception that proves the rule. In Haskell there is no stack and no need for TLS, so the complexity of M:N threading is much lower. Additionally, on Haskell there is a provision for pinning green threads to OS threads if you need interoperability with foreign code that can't get moved across threads as easily, and the assumption is that you usually don't need to pin threads. I'd also like to point out that for some applications, using native threads instead of green threads will reduce the number of context switches, it's when threads are CPU bound that green threads give you the biggest performance boost.
- pcwalton 13y ago
  > Additionally, on Haskell there is a provision for pinning green threads to OS threads if you need interoperability with foreign code that can't get moved across threads as easily, and the assumption is that you usually don't need to pin threads. You can do that in Rust too (and we do it a lot).

limsup 13y ago

If you restrict yourself to 64 bit systems, you can essentially go back to using OS threads with blocking I/O because the address space is so large. You can fit thousands of 2MB call stacks into the processes address space and rely on the OS and MMU to manage the memory. The problem that created the whole non-blocking, async domain was the memory needed for the thread's call stacks. You don't have enough address space to place a bunch of 2MB call stacks for each thread, if you're handling tens of thousands of connections.

masklinn 13y ago
> The problem that created the whole non-blocking, async domain was the memory needed for the thread's call stacks. You don't have enough address space to place a bunch of 2MB call stacks for each thread, if you're handling tens of thousands of connections. c10k is (almost) 15 years old, updating it for today are the OS and MMU going to manage 10 million threads and stacks for that many connections?
rdtsc 13y ago
2MB call stacks? Mine are 10MB: $ ulimit -s $ 10240 I can only spawn 200 threads in the worst case and keep them active before system starts swapping. Yes memory space is large by anytime those have to run they'd have to be brought up into the working set. EDIT: nevermind, _wmd pointed out that stack memory is still virtual and it only be brought into the physical memory as needed.
- MrBuddyCasino 13y ago
  Now I'm confused. This comment says that the stack memory is not allocated by the OS unless actually needed: https://news.ycombinator.com/item?id=6728030 https://news.ycombinator.com/item?id=6728030 Is this not true?
  - rdtsc 13y ago
    That is right, the full 8MB or 10MB or whatever of max is not being paged in. I am stupid. I'll correct the initial comment. Thanks

klodolph 13y ago

No, they're saying the performance will be slightly degraded. But you can already spin up thousands of threads on Linux without performance problems. The M:N model is notoriously difficult, making your threading system 10x as complicated usually isn't worth the 10% performance increase. Haskell is, again, the exception that proves the rule. In Haskell there is no stack and no need for TLS, so the complexity of M:N threading is much lower. Additionally, on Haskell there is a provision for pinning green threads to OS threads if you need interoperability with foreign code that can't get moved across threads as easily, and the assumption is that you usually don't need to pin threads. I'd also like to point out that for some applications, using native threads instead of green threads will reduce the number of context switches, it's when threads are CPU bound that green threads give you the biggest performance boost.

pcwalton 13y ago
> Additionally, on Haskell there is a provision for pinning green threads to OS threads if you need interoperability with foreign code that can't get moved across threads as easily, and the assumption is that you usually don't need to pin threads. You can do that in Rust too (and we do it a lot).