4 ms·

> due all machinery necessary to setup and start OS thread The machinery to start an OS thread is on the order of magnitude of nanoseconds. Starting an OS thre

> due all machinery necessary to setup and start OS thread The machinery to start an OS thread is on the order of magnitude of nanoseconds. Starting an OS thread far cheaper than printing a line to stdout, for example. OS threads are only a problem in interpreted languages, because all of them have a global interpreter lock of some sort. For compiled native languages OS threads are more efficient than green threads.

ahartmetz 7y ago
It takes about ten microseconds to start a thread on Linux, not nanoseconds. https://stackoverflow.com/questions/3929774/how-much-overhead-is-there-when-creating-a-thread https://stackoverflow.com/questions/3929774/how-much-overhea...
- otabdeveloper4 7y ago
  That microbenchmark is old and quite imperfect; I'm pretty sure it's not actually measuring what it claims to measure. The point still stands. Creating threads (at least in a normal OS like a modern Linux) is really fast. E.g., when processing a huge logfile it's faster to create one short-lived thread per each line than it is to use a thread pool with the producer-consumer routine and conditional variables.
CraigJPerry 7y ago
OS threads means context switching which means relinquishing the cpu from user space to kernel space for a time. Green threads is pure user-space. No expensive context switch.
- fulafel 7y ago
  Context switch is switching between processes or threads that a CPU core runs. In parallel computation it's well known how to avoid that: keep the thread count equal to hardware core/thread count. Green threads enable concurrency but not parallelism, so they are not applicable to accelerating computation. (core.async isn't actually green threads, except in ClojureScript, but its thread pool is more for working around blocking calls than exloiting parallelism).
- otabdeveloper4 7y ago
  > OS threads means context switching which means relinquishing the cpu from user space to kernel space for a time. No. The OS will switch contexts regardless of how many threads you have. Even with zero threads the OS will be context switching between processes anyways. That's just how pre-emptive multitasking works. What you're trying to say is that threads might get starved due to imperfect scheduling; but even that is wrong - you're never going to write a better scheduler than the one in the Linux kernel. I mean that seriously. If you want a deterministic scheduling routine without unpredictable delays, then just use one of the realtime schedulers provided to you by the kernel. That's what they're there for.
  - CraigJPerry 7y ago
    > The OS will switch contexts regardless of how many threads you have With IRQs pinned (via CPU mask given to the kernel at boot time) and application process pinning, there will be no preemption of the application process. > Even with zero threads the OS will be context switching between processes anyways No, this is what pinning is explicitly for. > What you're trying to say is that threads might get starved due to imperfect scheduling No, you've misunderstood

ahartmetz 7y ago

It takes about ten microseconds to start a thread on Linux, not nanoseconds. https://stackoverflow.com/questions/3929774/how-much-overhead-is-there-when-creating-a-thread https://stackoverflow.com/questions/3929774/how-much-overhea...

otabdeveloper4 7y ago
That microbenchmark is old and quite imperfect; I'm pretty sure it's not actually measuring what it claims to measure. The point still stands. Creating threads (at least in a normal OS like a modern Linux) is really fast. E.g., when processing a huge logfile it's faster to create one short-lived thread per each line than it is to use a thread pool with the producer-consumer routine and conditional variables.

CraigJPerry 7y ago

OS threads means context switching which means relinquishing the cpu from user space to kernel space for a time. Green threads is pure user-space. No expensive context switch.

fulafel 7y ago
Context switch is switching between processes or threads that a CPU core runs. In parallel computation it's well known how to avoid that: keep the thread count equal to hardware core/thread count. Green threads enable concurrency but not parallelism, so they are not applicable to accelerating computation. (core.async isn't actually green threads, except in ClojureScript, but its thread pool is more for working around blocking calls than exloiting parallelism).
otabdeveloper4 7y ago
> OS threads means context switching which means relinquishing the cpu from user space to kernel space for a time. No. The OS will switch contexts regardless of how many threads you have. Even with zero threads the OS will be context switching between processes anyways. That's just how pre-emptive multitasking works. What you're trying to say is that threads might get starved due to imperfect scheduling; but even that is wrong - you're never going to write a better scheduler than the one in the Linux kernel. I mean that seriously. If you want a deterministic scheduling routine without unpredictable delays, then just use one of the realtime schedulers provided to you by the kernel. That's what they're there for.
- CraigJPerry 7y ago
  > The OS will switch contexts regardless of how many threads you have With IRQs pinned (via CPU mask given to the kernel at boot time) and application process pinning, there will be no preemption of the application process. > Even with zero threads the OS will be context switching between processes anyways No, this is what pinning is explicitly for. > What you're trying to say is that threads might get starved due to imperfect scheduling No, you've misunderstood