How can you calculate 5 math formula results if you only have 1 brain?

I think thread is being used in the same context, but running multiple threads on a core partially negates the benefits of having multiple cores in the first pace.

@wizzwizz4 If you had a single core than that core would have to switch between and work on all 96 threads at once. with multiple cores, divided evenly each core only has to run 24 threads. Further more, your OS can manage threads so that more important/demanding threads don't have to share as much cpu time on a core with so many other threads and less important/demanding threads can all be shared on a single core.

@BooleanCheese Hence "partially". If I understand your comment correctly, though, that is a tangent that's not really relevant to "asking for more information or suggesting improvements". Chat if you wish to continue this discussion, though I don't know that there's much to discuss.

@wizzwizz4 my point is that the benefit cannot be considered "partially" negated because the benefit of multiple cores is that it literally divides the amount of work a core has to do. To say the benefit is negated is just bad math.

@BooleanCheese It partially negates because, as mentioned in this answer, the switching between threads and fair resource allocation takes up processing power too. But, chat is the place for this.

Indeed. That you have four cores means you can have four threads actually running at a time. But that doesn't limit how many threads can exist. Most threads spend most of their time blocked - most of them waiitng for IO to complete before they can proceed.

'With almost nothing to do but check the status of the awaited resource, such threads are scheduled quite briefly.' - well, scheduled not at all usually. If a thread is waiting for I/O or a signal from another thread, then it is given no cycles at all - there is no point, it cannot do anything.

@MartinJames is right. The kernel would put such a thread into the IO wait queue associated with that IO device, and wouldn't schedule it at all until the CPU received an interrupt from the IO device, passed it to the kernel interrupt handler, which would then determine which process was waiting for that piece of information and put that process back in the "ready" queue so it would be available to be scheduled. There was an excellent presentation on system internals at LISA 2017; you can find the slides here: goo.gl/PFYsYy

Your description of hyperthreading is wrong. Hardware threads != software threads, they're execution contexts / logical cores. Both logical cores really do run their instructions at the same time. The front-end alternates between threads, but the out-of-order execution core can execute instructions/uops from both threads in the same cycle. This exposes the instruction-level parallelism from two threads to OoO execution to better keep the execution units fed with work (this is basically the point of SMT). It's nothing like "optimized context switching".

Also, nobody puts yield() system calls in their CPU intensive threads (unless it's legacy code from cooperative multi-tasking on Classic MacOS). Pre-emptive multi-tasking reschedules after a thread uses up its timeslice.

Threads can run simultaneously: the wording in the first sentence is kinda bogus. As many threads as you have logical cores can run simultaneously.

I don't really understand your answer. How am I have to have 1805 threads while I should only be able to have 4 (one for each of the virtual CPUs)?

@YellowPillow The operating system will decide which 4 threads should actually run, the rest will just wait until a processor is available.

@greg-449 Actually, with technologies such as multiple-issue processors (or just pipelines) it’s rather probable that frequently instructions from multiple threads are being executed simultaneously on a single core. This would mean more than 4 threads run at any given time.

@YellowPillow Forgive me - I've added some context and a link to timing so perhaps you can rephrase what's wrong with having lots of threads and few CPU. In practice - you're always constrained by something else delivering data to RAM or getting data to the storage - not the threads and the CPU scheduling. See this image for one "conversion" twitter.com/rzezeski/status/398306728263315456/photo/1

@11684, pipelining (and branch prediction) is rather a different thing from hyperthreading. Also, YellowPillow, you seem to be conflating CPUs with cores. Even without hyperthreading, you have one thread running per core — but you likely have multiple cores per CPU. CPU = physical chip on a single die (single piece of silicon) that fits into a socket on your motherboard; core = part of a CPU. (The CPU includes all sorts of other things besides just its cores; see goo.gl/PFYsYy for some idea.)

@11684: what you're describing (overlapping instructions from separate threads) is called Simultaneous MultiThreading (SMT). Intel's Hyperthreading (HT) is an implementation of SMT. It's very fine-grained (@Basil Bourque's description of it is completely wrong; it's not optimized context switching; the hardware does simultaneously execute both logical contexts).

← 6 messages moved from Discussion on answer by bmike: How can I have 1805 threads when I only have 4 virtual CPUs?

← 6 messages moved from Discussion on answer by Basil Bourque: How can I have 1805 threads when I only have 4 virtual CPUs?

@ThomasWeller great analogy