Quote from aphexcoil:
A dual-processor system is much more efficient, even if the program isn't multi-threaded. SOme programs, which clog up certain pipes in a one processor system will not be able to clog up the whole computer with two processors. Conceivably, you could have a 5x-10x improvement under certain conditions.
One that comes to mind is running a virus scan that clogs up the CPU while trying to do a spreedsheet that would normally take 10 seconds that would now take 100 seconds because it sits at a lower priority level to the anti-virus program. With two processors, the spread-sheet can do its thing without having to wait for the anti-virus program to get finished its job.

Quote from nitro:
This is slightly innacurate. While it is true that if the program is not multi-threaded, the "only" software that would benefit from the multiple CPU is the OS, assuming it too is multi-threaded, and that does make some difference.
As far as Hyperthreading, it is an interesting technolgy. I do not have a Hyperthread enabled MB yet so I cannot run tests. However, 5 - 10 times speed improvements would be astonishing to me under all but the most superficial of circumstances.
All of the P4 already have advanced pipelining etc. How much _could_ hyperthreading add in the absence of another CPU? Probably less than a 20% improvement, if that...
nitro
BINGO! It is the OS that truly benefits from a dual processor. The benefits can then be truly passed on to other softwares but again, the OS has to be benefitting first.
I have ordered a Hyperthread MB and I look forward to playing with it after the first of the year. Still, I think you'll need an OS tweaked for it for any real benefits. But I'll soon know. As far as noticing any real differences for now, anybody with a P4 between 1.7 and 2.5 should be hard pressed to see it in any meaningful software improvement factors.![]()
Quote from canyonman00:
And no, you really wouldn't have a 5x-10x increase in processing speeds with a dual processor setup in Windows. XP or otherwise. And it would not split the processor load between the two programs that way unless the software was written to instruct it to. And even then both software products would have to be written in that special way. You know, that (seemingly) impossible task of working together.
Quote from canyonman00:
...And it would not split the processor load between the two programs that way unless the software was written to instruct it to. And even then both software products would have to be written in that special way...
Quote from ArchAngel:
You must have missed that Multiprocessor Operating Systems 101 class.
That's EXACTLY what any MP-enabled operating system (like Windows 2K/XP) does - and the software apps don't have to be written in any "special way" either. In fact, the whole process is completely transparent to the programs. It's simply the extension of the standard multiprogramming scheduling environment to use multiple processors if available.
Now if a single program is to take advantage of internal parallelism and benefit from the additional CPUs of a multiprocessor environment, it needs to be multi-threaded (of course a multi-threaded program will still run on a single CPU box without change or being aware of how many CPUs are actually in the box).
But if you had an 8-CPU box and started eight compute intensive programs, they'd ALL run simultaneously without anything special and without the programs even being aware of it or having to be coded any particular way.
----------------------------------------
Nope, didn't miss the class. And got the theory down pat. It's the reality issue where the trouble sets in. Based upon that, I'd ask you to put the meter on the motherboard and watch what happens in actual MIPS and their direction of flow using TODAY'S version of XP. The nanoseconds of difference are not viable to ANY off-the-shelf software operations. Unless you are running some major heavy duty processing needs, you won't be able to detect any plausible differences.
It is this factor that negates the need for a user of MOST "OFF-THE-SHELF" software from needing multi-processor setups. While I don't dispute the gate flipping between the processors being viable, it is not a real help for the standard users.
So yes, your 8-CPU box example would be accurate in an intensive computing environ. But look at the other examples that are being used to show me the possibilities. None of them "truly" meet that need of employing the multiple processors. In most instances the processor would spend more time laughing at its project request than it would doing it.
None of the proposed explanations so far would rise to the level of a competent tech declaring the user buy a second or third processor. That is, unless you just absolutely positively need that CD burned in seven minutes instead of about eight and a half while the other operations run.![]()
Quote from aphexcoil:
If I wanted to convert a DVD to MPEG4 format in real-time, I would definately need another processor for other functions or else my system would just become unresponsive.
---------------------------------
This is the explanation that you would use to try to convince me as your tech for employing a second processor? If you're using a P4 and XP Pro, your system would not become non-responsive. There is some overwhelming need to convert this DVD in real-time? This conversion to MPEG4 format would not be possible before or after you watching this DVD?
This is not a quality use, need, or explaination, for a multi-processor machine NOR THE $$ NEEDED TO PUT IT TOGETHER. Especially of the P4, 1+ gig of RAM flavor. You've got to do much better than that! Stick with everyday user reality as I can develop a NASA level scenario also.![]()