Multi-Threading

[Twister]

Would there be any negative impacts to my program if I were to call 1,000 threads to one, single procedure? They would be continuously going until they are stopped at different times. But these threads would be going for at the least of a few hours each, maybe.

Maybe there could be a more efficient way instead, maybe quicker?

Please do note that I haven't done much with multi-threading, so advice would be nice also.  :toothy


EDIT: Could anyone recommend a book for me on multi-threading in Windows? I would very much appreciate it!

Thank you.

[Geryon]

Would there be any negative impacts to my program if I were to call 1,000 threads to one, single procedure?

Yes, unless you have 1000 core.

[Rockoon]

1 GUI thread + 1 worker thread for each core.

The assumption here being that the GUI thread is idle most of the time, sitting in a typical cpu-yielding pump waiting for messages to arrive.

[Farabi]

No, just make sure they dont access the same memory at the same time.

[Farabi]

Would there be any negative impacts to my program if I were to call 1,000 threads to one, single procedure?

Yes, unless you have 1000 core.

No, a single core processor can have many thread running.

[oex]

If the CPU is maxed you have the 'weight' of the thread code (Startup, OS juggling, Shutdown) which will ultimately slow down your code but otherwise no

[Rockoon]

Would there be any negative impacts to my program if I were to call 1,000 threads to one, single procedure?

Yes, unless you have 1000 core.

No, a single core processor can have many thread running.

Can, and Should are two different things.

[hutch--]

You need a good reason to run a high thread count, a lot of modern programming does not properly comprehend what is involved and you get slow laggy applications due to the thread overhead. Exceptions are threads that are mainly idle and things like internet connections qualify here as their data transfer rate is very slow alongside what can be processed by a single core in a computer.

If performance matters then Rockoons advice is sound, 1 thread per core and if the processor supports hyperthreading an extra helper thread per core.

[Geryon]

Would there be any negative impacts to my program if I were to call 1,000 threads to one, single procedure?

Yes, unless you have 1000 core.

No, a single core processor can have many thread running.

Well, not exatcly. A CPU can execute one thing at a time. So, the OS make the cpu to switch between threads (this is called "task switching")
For example, let's say you have a cpu with 10 MIPS(million instruction per second) and 2 threads is active. Then each thread can have less than 5 MIPS calculation "power".
Why less ? Because task switching takes time too.

[ecube]

The one thread per core is silly, you can easily do 30-50 threads for a single core and you'll see a nice speed boost depending on what you're using them for. Windows has a limit on the total number of threads that can be created, I think it's a around a few thousand. Anyway if you want to see some examples of programs using high threads look at firefox or apache. I've personally used 30 or so for thread polling in my que system and it drastically sped up what I was doing. Anything that blocks or holds up the show you should consider putting it in a thread.To give a practical example say you wanted to compress a 7 gig file. What I recommend you do is have 1 thread read the data, and put it in a que, then other threads actually process the data, that way you have nice parallelism. :U

[dioxin]

Radio Ga Ga ,
1000 threads is probably too much. Is there really a task that would need so many?

If you have low-cpu use tasks that are blocking other tasks then maybe use a thread to free up resources but 1000 of them sounds over the top.

The rest of what follows assumes high cpu usage threads such as those doing long, intensive calculations.
If the threads are CPU intensive then each thread will be given its timeslice in turn. Typical timeslice is 16ms so each thread will get some CPU time every 16ms x 1000 threads / n cores = 16/n seconds (n=number of cores you have) which means your GUI threads, the stuff you try to type at the keyboard or click on with a mouse, will become unbearably slow and unusable. You'd need to run your calculation threads at a low priority so the GUI threads get some time to run.


To limit the number of threads to the number of cores is not a good idea.
Suppose you have 5 threads and 4 cores and each thread needs 3 hours to process then you'll spend 3 hours on the first 4 threads with 1 thread waiting for a core to become available. As soon as the first thread finishes you can schedule the 5th thread and it will take another 3 hours but during this time the other 3 threads will all finish and the cpu cores running them will sit idle. The total time to finish will be 6 hours.
On the other hand, if you scheduled 5 threads on 4 cores then each thread would be given timeslices and the total task would complete in around 3h45m with all 4 cores running all of the time. A saving of 37% in time to completion.

If you can follow that explanation you'll see that the best number of threads to use is dependent on the task you're doing.

Paul.

[Twister]

When I look on the Performance tab in Task Manager (taskmgr.exe), I find that I have ~890 threads running under normal circumstances. But If I were to increase that to ~1,890—it wreak havoc on my machine?

[BogdanOntanu]

When I look on the Performance tab in Task Manager (taskmgr.exe), I find that I have ~890 threads running under normal circumstances. But If I were to increase that to ~1,890—it wreak havoc on my machine?

The threads that you see there are NOT performing CPU intensive operations.

Most of the time they just "sit" there performing nothing, just waiting for an event or signal or message to wake them up.

An relatively small number of threads that are actually performing CPU intensive calculations can put down the most advanced CPU.

In my experience it  was not uncommon for the whole OS/system to become very sluggish and non responsive when I was running intensive multi-threading testing.

This number is variable depending on how many cores your CPU has but I observed it to be in the range of 8-32 very intensive threads for one core.

[redskull]

"One running thread per core" is the optimum, most efficient way; any more, and you gain no more speed, and lose a little bit of task switching overhead for each additional one.  Generally, the logical benefits and "perceived responsiveness" of splitting up your program outweighs the fractions of time you lose, but 1000 is far too many (assuming they all run all the time).  There's no way to escape the fact that if you have 'x' operations to do, and 'y' CPU's to do them on, you'll never get them done any faster than x/y.

-r

[Twister]

When I look on the Performance tab in Task Manager (taskmgr.exe), I find that I have ~890 threads running under normal circumstances. But If I were to increase that to ~1,890—it wreak havoc on my machine?

The threads that you see there are NOT performing CPU intensive operations.

Most of the time they just "sit" there performing nothing, just waiting for an event or signal or message to wake them up.

That is exactly what I am using those threads for!  :clap:

So, referring to my previous question: Will there be anything negative?

I could probably right it in C++ using a class; it would be slow, but at least thousands of threads won't be hitting the same procedure.