Hi,
Anyone knows that if you create a multithread application and execute it into a multicore CPU, can the threads be executed into different CPUs?
I think yes because of the use of the shared cache memory.
What do you think?
Printable View
Hi,
Anyone knows that if you create a multithread application and execute it into a multicore CPU, can the threads be executed into different CPUs?
I think yes because of the use of the shared cache memory.
What do you think?
Thats the idea behind multi threaded applications.
And using threads is the only way to make your application scalable on multi core systems.
Have a look at Intel's Threading Building Blocks and QtConcurrent
for higher level parallel computing mechanisms.
Different processors (cores) may be used. But it doesn't mean they are used. You might need to change the process policy of your operating systems to allow scheduling different threads of the same process to different processing units.
Hi,
Do you think that is not done by OS itself? I know that using GNU/Linux is possible to change process scheduling policy but I don't know if it's possible using Windows.Quote:
Originally Posted by wysota
Thanks,
Well, no, it doesn't have to be. I don't have a multicpu system myself, so I'm only guessing here... but first of all you need a system that supports multiple cores and second of all, the default scheduling policy could be to schedule threads of the same process to the same cpu. From what I observed on this forum this tends to be the default setting on Windows (I'm not sure of that though).Quote:
Originally Posted by ^NyAw^
Here is something to read to get you started: http://msdn2.microsoft.com/en-us/library/ms684251.aspx
I have a dual-core system running Linux and windows dual-boot.
On both OSs two cores are represented as two processors.
Meaning to the OS two cores appear to be the same as two cpus.
From my experience on both OSs I can tell that you don't need to perform any
special magic to make parallel computing work.
Good luck
Linux is certainly not a good example here. By changing a single option in the kernel configuration I can disable one of your cores. And there are kernel builds that have it turned on and there are builds that have it turned off. So if you installed a kernel with SMP support, you can use multiple cores straight away (provided that the scheduler is told to schedule threads to different processors). The same applies to Windows - a build without SMP capabilities won't handle multiple cores. And even if you do have SMP support, the scheduler configuration might be different. I guess it's less "shaky" when it comes to Windows, because it's practically delivered completely preconfigured, but you can't say the same for Linux. That I'm sure of.Quote:
Originally Posted by DeepDiver
I didn't say this is a problem here (if there is a problem at all), but I say that system configuration can influence thread affinity.
Yeah - you are right. Using an non-SMP-kernel will result in a non-multi core supported platform .... (But why would you do that????)
But yes - you are again right - miss configuration of the system will cause trouble ...
Windows NT had different product version: Single CPU, 2-4 CPU and .... (what ever)
Since Windows 2000 I never saw a Windows without SMP support..
I never had to touch scheduling policies neither on Windows nor on Linux (with SMP-kernel)
Based on the fact that Windows is (was?) licenced per CPU, I'm sure there are versions for different numbers of CPUs.Quote:
Originally Posted by DeepDiver
Again, I don't say the problem is caused by the lack of SMP support, I just point out the reason for having a constant 50% load might be that threads are scheduled to a single processing unit. Reasons for such behaviour are unknown to me - I don't have a multicore machine, hence I have no experience with it.
Hi,
So, the OS is not schduling some threads to different CPUs. So if I wrote an application that creates some threads, all of them will be executed on the same CPU. The speedup of the system will be grater than a single CPU system because some processes will be executed on the other CPU, but what I really want to know is if my application that have 2 threads that uses a lot of CPU, could spawn one thread to one CPU and the other thread to the other CPU sharing data throught cache memory(or any other way).Quote:
I just point out the reason for having a constant 50% load might be that threads are scheduled to a single processing unit.
Thanks,
@wysota:
I totally agree with you - all I'm saying is: usually it works without trouble.
In the past years I did a lot of threading stuff and I like the approach of Intel and Qt to bring threading to a high level.
Both concepts/implementations allow runtime detection of number of cores/cpus available and distribute the work load.
This makes an application scale on various platforms.
And if you have a closer look at the implementations: they don't touch cpu affinity at all.
These implementations assume that the OS does it right. (and they do from my experience)
take care
With the coming QConcurrent , see presentation here, the thread scaling on CPU's is done automatically (one thread per CPU) but it offers an easy API to scale it manually as you wish.