But if an application uses multiple threads, then the application can take advantage of multiple processors, by scheduling different threads on different processors, so it's not true that:
- "regular" applications do one thing at once
- adding processors won't make them run faster
1. Applications have to be written to schedule multiple threads to different processors. There are specific calls to create this behavior. Multi threaded DOES NOT mean .. by default that it can use multiple processors. There are also specific changes depending upon the OS you're writing it for. This is especially true for the hardware. What good does it do you to write a bunch of routines.. all sharing variables.. spawning threads.. Then half your threads end up sitting in a queue waiting for the slowest one to finish. Assuming you even made the correct calls in the first place.
2. Processors have multiple pipelines.. multiple threads can be sent to different pipelines on a processor..(the processor can only start one instruction at a time.. but it can have different instrctuons in each pipeline) so processors can in effect do "more than one thing at a time".. there are limits but it has been this way since the Pentium 1. Win 9X is a multi threaded app.. but it cannot take advantage of multiple processors.. but it CAN send multiple threads to different pipelines.
So in effect .. the processor will start an instruction (A) on clock cycle one .. but that instruction takes 5 clocks to finish... it will start the NEXT (B) instruction on clock cycle two in a different pipeline.. but B only takes three clock cycles.. it comes out one ahead.. but what if it depends on a result of A? then you wasted something didnt you.. well it ALSO works this way for multi procs but WAY MORE convoluted..
3. Multi processor computers require an completely different kind of bus hardware (referred to as APIC) vs. the older single proc limited PIC. To upgrade generally requires you upgrade you motherboard, proc and usually your RAM. (This is specific to Intel hardware types.. or AMD.. I don't know much about RISC hardware or its limitations)
4. Its is a REALLY BAD idea to "add" a processor.. even if you can. You really have to trash your old one.. or use it in another computer. Multiple procs work best if they are from the same "stepping" model.. I am not positive... but I "think" when you buy sets. they are actually from the same "die" or at least same production run. When you are talking about something that small.. with that many components (we are talking tens of millions of transistors) even the most minute of differences can throw them off. Not enough for you to detectt... but a proc running at 4GHz will know the difference.. you will get errors and more likely blue screens.. A LOT.
ya I am sure someone will say how they did this and it worked fine.. that's okay if you are playing World of Warcraft (a multi threaded, multi proc enabled game)..but NOT if you are running a production server controlling your line.
5. Two processors with a WELL WRITTEN app might yield a 40% improvement.. but there is overhead.. Windows XP/Linux/Unix for example are multi proc enabled OS's (unlike 9X). Overhead comes form management of the processors.. and memory. 4 procs will not make your computer 4 times faster. It really depends on the app and how its used. Look up Amdahl's Law.. will give you an idea..
6. From what I understand.. writing multi proc apps .. is as much an art as a science.. many times.. if poorly done it can result in even poorer performance. A good programmer will know when to use them and when not to. Making a bunch of text calls.. which rely more on the bus and memory.. don't really require any CPU horsepower.. but a complicated floating point subroutine.. hell throw as many procs as you got at it. You can't just throw threads out there and expect results.
7. There is only ONE OS ever written that ignores these rules.. that was the BeOS. Apparently it could forced any multi threaded application to use every processor available. As to how efficient it was. I have no idea.. It must have ran the app through some crazy API that redirected multiple threads to a "pseudo pool".. I cannot imagine this was efficient the overhead must have been tremendous. Things like thread pool and queue length have to be considered before an app is written.. sloppy managment of these will reult in piss poor performance of your app on pulti procs.
I'll give you some gaming examples.. and you can test them for yourself.
Half Life is a multi threaded app... but it WILL NOT take advantage of multiple processors.. if you watch your task manager.. you will see massive activity on Proc 0 but only a alight increase on proc 1... (proc 1 is from the OS processing I/O and backgoround commands).
World of Warcraft.. multi proc enabled.. and VERY well written.. you will see anywhere from a 20-40% perf gain depending on the routines running. You can look at task man and both procs are screaming.
CAD is a great example.. every proc you have will be screaming.. that prog as a hog.
NOw that multi core procs are about as common as a liberal commie on a college campus.. you will see most modern apps written to use multi procs to some degree. but don't assume that because someone says multi threaded.. that you will se any diff.
I hope that helps..