Each thread is runned by one CPU core?
I am currently learning to use C++11 threads.
I wanted to see how many threads my hardware can support without causing worse performance in my program.
I simply called:
it returns 4. Since I have a quad core CPU, I thought that it makes perfect sense.
So let's say that I run 4 simple C++11 threads in my program, is each thread running on it's own core then in parallell? Or is it much harder and more complicated to make program threads to utilize several CPU cores, or is it this simple?
So even if I have a really simple program, can I always improve the performance by dividing the work in the prorgam over those 4 threads?
I wanted to see how many threads my hardware can support without causing worse performance in my program.
I simply called:
|
|
it returns 4. Since I have a quad core CPU, I thought that it makes perfect sense.
So let's say that I run 4 simple C++11 threads in my program, is each thread running on it's own core then in parallell? Or is it much harder and more complicated to make program threads to utilize several CPU cores, or is it this simple?
So even if I have a really simple program, can I always improve the performance by dividing the work in the prorgam over those 4 threads?
Last edited on
| So let's say that I run 4 simple C++11 threads in my program, is each thread running on it's own core then in parallell? Or is it much harder and more complicated to make program threads to utilize several CPU cores, or is it this simple? |
Its out of your hands. Determining which thread gets how much CPU time and when is the job of the scheduler (part of the OS).
Schedulers are pretty smart these days, so if you have 2 threads that are needing a lot of CPU time, it's likely they'll run concurrently... provided nothing else on the system is also demanding a lot of CPU time.
So the short answer is... "don't worry about it... the OS takes care of it. There's nothing you can do".
Whether or not that's TECHNICALLY true is another matter... there might be a way to communicate with the scheduler to specifically place your threads on different cores... however it certainly wouldn't exactly be simple... and it definitely would not be portable... nor would it be part of the C++11 threading lib.
| So even if I have a really simple program, can I always improve the performance by dividing the work in the prorgam over those 4 threads? |
More threads does not mean better performance. In fact, in simple programs, the opposite is often true. If there's not a lot of work that NEEDS to be done in parallel, forcing it to be done in parallel often slows things down.
Thread synchronization is very expensive. To get good performance out of multiple threads, threads should be doing a decent amount of work with minimal synchronization. It's like a tradeoff.
If the tasks you're doing are very simple... then the tradeoff may not be worth it.
Remember, your OS also needs to run. It has to update the clock, notify you of other alarms, accept ethernet packets, etc. Any other programs on your PC also need to run.
What it CAN do is find the optimal core for your thread to run on at that particular moment. However, in terms of how OSs work with interrupts, you are not garunteed to have two threads running on different cores. What you can do is set an affinity for each thread (ok, well you can do with this processes, not sure about threads). This will tell your OS which core you'd prefer your thread to run on. If you have 2 threads and set different threads, they may have more chance of running concurrently, but it's still not guaranteed.
The benefits to mutlthreading are best when you have a task which you know will take a significant amount of time. Perhaps you want to load picture A into memory, apply an effect onto picture B, and allocate memory for picture C. If none of those depend on each other, you can make them as 3 parallel threads. Therefore all three will be done quicker than each one in serial.
What it CAN do is find the optimal core for your thread to run on at that particular moment. However, in terms of how OSs work with interrupts, you are not garunteed to have two threads running on different cores. What you can do is set an affinity for each thread (ok, well you can do with this processes, not sure about threads). This will tell your OS which core you'd prefer your thread to run on. If you have 2 threads and set different threads, they may have more chance of running concurrently, but it's still not guaranteed.
The benefits to mutlthreading are best when you have a task which you know will take a significant amount of time. Perhaps you want to load picture A into memory, apply an effect onto picture B, and allocate memory for picture C. If none of those depend on each other, you can make them as 3 parallel threads. Therefore all three will be done quicker than each one in serial.
Last edited on
Ok, I see. Thanks for explaining :).
I will make sure to only use threads when it helps.
I will make sure to only use threads when it helps.
Not sure if you've heard of CUDA by Nvidia. It's not something you'd probably implement for a normal application, but for massive numerical calculations where we can utilize parallel processing (in not 4, but 400 threads), we can take advantage of this GPU-accelerated library and use the video card to accelerate your calculations. it's actually pretty cool. If you're interested, check it out.
Topic archived. No new replies allowed.