If the app is single threaded, yes the other chip will be idle from that apps point of view. But you do have lots of other processes (os components, device drivers etc) running on your computer at any given time , so the other cpu is not wasted. How delegating programs (processes, threads) is done is down to the operating system itself. Not owning a multicpu box myself I don't know what controls (if any) your operating system gives you in this regard. If the app is multi threaded it should be running on all cpus if the operating system just permits it properly.
Let me add that the above is true if the app is written to indeed ASSIGN threads to different processors. Many apps are multithreaded for reason of the internal organization of the software itself WITHOUT GOING THROUGH THE TROUBLE OF ASSIGNING DIFFERENT PROCESSORS TO DIFFERENT THREADS. So, answer: maybe.
It is two different CPU in the same box. The Windows OS has to be configured for Multiple CPU, and then the task manager will assign the Loads accordingly, if you have diiferent programs running at the same time. Say diiferent trading programs processing data concurrently, at the same time ,you let a movie running with WinDVD, and a fish tycoon game generating virual money for you, and your System Mechanic is cleaning/tuning up your system, and perhaps that AntiVirus program is scanning in the background, firewall, Antispyware, then a TV tuner, then your browser windows busy downloading graphics, the DVD burner also working in the background to copy and cool movie etc. Of course, if you have only one single program running, then it must have been written using a multi-threaded scheme in order for it to take advantage of Dual CPU.
I didn't realize that - I was always under the impression that the OS took care of assigning the thread to a processor and that it would happen in a non-deterministic fashion depending on system resources. Good to know.
The little I think I know of Windows programming is that if the threads are created properly it should be upto Windows to delegate threads to all available cpus. The hardware side, chipset etc, has no say in this. It's all about how to operating system software decides/chooses to use the hardware. If somebody has a multicpu Win box I'd be happy to hear what kind of job delegation possibilities there are; is it possible to bind a single app to a known cpu exclusively, how much control is given on which cpus the threads run etc or if there are any capabilities of this kind at all. Adobian, please note that in modern operating systems there are practically never situations where only 1 program is running, as the os components and device drivers are always running in addition to the user programs. When you receive data from network it goes through the network card driver, network protocol layers etc before ending up as usable data in your program, and all these steps are separate programs themselves. Many users think that if they have started one program only then they have only one program running, this is not the case. All of the os is just a program, or more properly several programs, to the computer hardware. Check your task manager process list and please remember that many device drivers are not listed in this process list at all yet are run all the time. So more cpu's always helps performance.
Ok, I've got several multiprocessor boxes running. If only Windows was truly that efficient. Yes, you can assign duties to a dedicated processor, but the software programmer/coder has his work cut out for himself/herself. Windows tends to poll for available resources. Working from a, "What's available, who's next, what's next, which processor is in line with available resources?" framework. When you get into the server versions of Windows it is more controllable. IMHO
Depends, the chipset or the OS can do this. It can be a function taken on by the software. This requires the software developer to really be on the game in resource management though. It's part of the problem in coming up with universal hardware/software standards using Windows as there seem to be three or four ways to attack the issue. If it's not directed though, the chipset can handle it (somewhat).