-2

I recently read in a post that I can run 96 threads. However, when I look at my PC's performance, and posts like this, I see thousands of threads being able to run.

I assume the word thread is being used for two different things here (correct me if I'm wrong and explain). I want to know what the difference between the two "thread"s are. Why is one post saying 92 but another saying 6500?

Ian Kirkpatrick
  • 1,861
  • 14
  • 33
  • 5
    The difference is exactly 6404 threads – Hovercraft Full Of Eels Apr 08 '18 at 17:49
  • 5
    You can start as many threads as your memory allows. But they won't be all executed concurrently. If you have 4 cores, only 4 threads can run at a time. The other ones are waiting until the scheduler decides to execute them, .i.e. allocate them a time slice of execution. – JB Nizet Apr 08 '18 at 17:51
  • @camickr the main question was what's the difference between the terminology. If you wanna get snooty then don't answer the second part. What's the difference between the threads that each post is talking about? – Ian Kirkpatrick Apr 08 '18 at 17:54
  • @JBNizet 4 cores = 4 threads? Maybe we should start collecting some money for you, so you can afford reasonable hardware ;-) ... seriously: depending on your the exact kind of core, you might be able to run 2 or even 4 threads per core. – GhostCat Apr 08 '18 at 17:58
  • @GhostCat Do you need my bank account number? :-) – JB Nizet Apr 08 '18 at 17:59
  • 1
    The first post says there are 96 cores in his system, and that means 96 threads can run in parallel. The other post talks about thread objects. You can of course start a lot more threads, but only a handful will actually run simultaneously, and you will lose efficiency due to frequent context switching. – rustyx Apr 08 '18 at 18:00
  • @JB Nizet, Does this mean the others are run along side those 4? like it runs a part of the first 4, then a part of the next 4, then a part of the next 4, then goes back and runs the next part of the first 4, then the next part of the next 4 and so on? Is that correct? – Ian Kirkpatrick Apr 08 '18 at 18:01
  • @rustyx it depends on what the threads are doing. If the task is CPU-bound, yes. If it's IO-bound, not necessarily. – JB Nizet Apr 08 '18 at 18:01
  • 1
    @IanKirkpatrick yes, that's it basically. – JB Nizet Apr 08 '18 at 18:02
  • I'm taking out the second part of the question since you all crucified me for asking it. It wasn't even the main question. – Ian Kirkpatrick Apr 08 '18 at 18:02
  • @rustyx 48 hperthreaded cores – Martin Smith Apr 08 '18 at 18:05
  • I appreciate the quick accept ;-) – GhostCat Apr 08 '18 at 18:06

1 Answers1

0

The answer is: both links "talk" about the same thread.

The major difference is: the first is effectively asking about the number of threads that a given CPU can really execute in parallel.

The other link talks about the fact how many threads you can coexist within a certain scope (for example one JVM).

In other words: the major "idea" behind threads is that ... most of the time, they are idle! So having 6400 threads can work out - assuming that your workload is such, that 99.9% of the time, each thread is just doing nothing (like: waiting for something to happen). But of course: such a high number is probably not a good idea, unless we are talking about a really huge server that has zillions of cores to work with. One has to keep in mind that threads are also a resource, owned by the operating system, and many problems that you did solve using "more threads" in the past have no different answers (like using nio packages and non-blocking io instead of having zillions of threads waiting for responses for example).

Meaning: when you write example code where each thread just computes something (so, if run alone, that thread would consume 100% of the available CPU cycles) - then adding more threads just creates more load on the system.

Typically, a modern day CPU has c cores. And each cores can run t threads in parallel. So, you got often like 4 x 2 threads that can occupy the CPU in parallel. But as soon as your threads spent more time doing nothing (waiting for a disk read or network request to come back), you can easily create, manage, and utilize hundreds or even thousands of threads.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • Don't start thousands of threads. Oversubscribing due to "IO bound" is a sure way to lose efficiency. Have a look at NIO instead. – rustyx Apr 08 '18 at 18:08
  • @rustyx I didn't say it is a good idea though. I will add your thought to my answer. – GhostCat Apr 09 '18 at 07:03