4 ms·

The comments here remind me of MongoDB is web scale. You can have thousands of idle threads on a machine with one or a few CPU cores. Sure if you have several o

The comments here remind me of MongoDB is web scale. You can have thousands of idle threads on a machine with one or a few CPU cores. Sure if you have several of them competing for CPU time you will lose efficiency. But at the point where the total duty cycle is less than capacity - context switch overhead you will not see any I’ll effects. I know because I have tried this. 4096 threads on a dual core $5/month VPS did beautifully for IO-bound tasks. Also the author is examining a desktop machine. Of course it will have a bunch of idle processes. In fact I would argue that if the machine was running 100% CPU usage by a few threads all day long the author would be quite upset at the electric bill, fan noise, and the heat generated. Desktop applications are not throughput bound. They are latency bound and having a bunch of threads on standby is normal.

asdfasgasdgasdg 5y ago
In the modern era, threads are more of a memory problem than a compute problem. If you spawn a thread per request (or several) it can be an issue by maintaining too much stack space. But I don't know of any reliable benchmark showing that threads or events outperform in real systems, except in cases of extremely high numbers of simultaneous contexts (i.e. very high number of ongoing requests/very low cost per request of operation).
- staticassertion 5y ago
  You could just spawn threads with smaller stacks. Also afaik that memory won't ever get paged in if it isn't used? So I don't know if it matters much. Also, idle threads aren't a problem, even on a system under load. Especially on a desktop. Also also, there's no global threadpool, which means if you have K programs on N codes and K > N it's a moot point trying to save threads. Any desktop has K > N. So reducing thread usage in all of your processes is unlikely to help.
  - IgorPartola 5y ago
    You said what I would have. Stack size of 100k is plenty for lightweight threads. 100MB for 1000 threads isn’t much for a modern system.
    - asdfasgasdgasdg 5y ago
      More to the point, only allocated pages matter from the perspective of resident memory. As long as the thread stacks are not actually too deep, it doesn't really matter very much the nominal depth.

asdfasgasdgasdg 5y ago

In the modern era, threads are more of a memory problem than a compute problem. If you spawn a thread per request (or several) it can be an issue by maintaining too much stack space. But I don't know of any reliable benchmark showing that threads or events outperform in real systems, except in cases of extremely high numbers of simultaneous contexts (i.e. very high number of ongoing requests/very low cost per request of operation).

staticassertion 5y ago
You could just spawn threads with smaller stacks. Also afaik that memory won't ever get paged in if it isn't used? So I don't know if it matters much. Also, idle threads aren't a problem, even on a system under load. Especially on a desktop. Also also, there's no global threadpool, which means if you have K programs on N codes and K > N it's a moot point trying to save threads. Any desktop has K > N. So reducing thread usage in all of your processes is unlikely to help.
- IgorPartola 5y ago
  You said what I would have. Stack size of 100k is plenty for lightweight threads. 100MB for 1000 threads isn’t much for a modern system.
  - asdfasgasdgasdg 5y ago
    More to the point, only allocated pages matter from the perspective of resident memory. As long as the thread stacks are not actually too deep, it doesn't really matter very much the nominal depth.