When someone said "MP-enabled operating system", he meant "multi-tasking", not multi-processing. Basically, if you want dual CPU, then you probably will derive some benefit (or you better hope so). Basically, its good for CPU-intensive tasks. Even XP will get unresponsive at normal settings with single CPU and something CPU intensive. By the way, in XP, I can assign processes to one or both CPU's. When playing games or backtesting, I point the process at one of the CPU's, to reduce the overhead of dual CPU. Sometimes both, one process per CPU However, my IO subsystem sucks. You may need to consider this.
Since I'm the one who used the "MP-enabled operating system" term, let me clarify. The term DOES mean multi-processor. Multi-tasking is simply a rudimentary function of any operating system's scheduler and can be done on boxes with only one processor. MP-enabled operating systems have multi-processor aware schedulers that can direct processes/threads to available processors to execution. As far as whether a dual processor box is "needed", it obviously depends on the mix of jobs running. The key point I was making was in response to canyonman's comment that special programming was necessary to make use of more than one processor in a box. In his example he concluded that you could only run two programs on a machine and make use of both processors if the programs were specially written to do so. The point was that in fact you both programs would run AND use both processors WITHOUT special programming. Whether someone needs the incremental processing power a second (or more) processors provides is a different issue. If your 2+ GHz P4 is consistently pegging 85%+ CPU utilization while running whatever mix of programs a person is running, then looking at adding a second processor makes sense. What "real world" situation might need this? Taking in a realtime datafeed streaming in quotes on a thousand or more symbols simultaneously feeding a variety of scanners, signal generators, and technical analyzers and displays. If doing that seriously pushes the CPU utilization on your box, then a second processor would help resolve it - because at the very least, you've got twice as much processor to divvy up between the datafeed handling thread and the analysis/display thread(s). Other "realworld" examples - people using rendering software, non-linear digital video software, etc. Usually multiple processor boxes are more important for servers, but there are definitely workstation-based uses for them.
Quick additional thoughts for clarification: 1. There's still a misunderstanding - a SINGLE program that wants to benefit from dual processors does need to be multi-threaded. More than one program running in the job mix do NOT have to be "tweaked" to benefit from multiple processors. Indeed, there are many programs that would themselves individually benefit little (or not at all) from multi-threading, but two or more such programs running simultaneously would realize significant performance improvement (without tweaking). 2. For clarification, "pegging" does not mean "spiking". In the sentence context, if the CPU utilization meter is pegging (i.e., consistently stuck at or above) 85% or more when running a particular user's normal job mix (whatever that may be), then there can be more than a marginal performance benefit produced by adding an additional processor. It has to do with overhead of process context switching, lost CPU cycles, main memory to processor cache transfers, etc. 3. The example of Bryce, etc. - is interesting, but not specifically meaningful. Don't know if Bryce's renderer is multi-threaded like more sophisticated CGI software. If it is multi-threaded, then additional processors would likely reduce your rendering time (assuming there aren't other resource bottlenecks inherent in it's design) - commercial rendering tools do definitely benefit from multi-processors. The other items you mentioned are interesting uses but are insignificant since they're I/O bound processes - wherein the processor is waiting for the I/O channel (i.e., disk, network, etc.) most of the time and so there are a lot of free cycles during such processing. Windows will simply steal the cycles needed for those things from other processes (e.g., your Bryce process). And depending on how the Bryce software is designed, it may itself be experiencing resource blocking from the disk (either directly as a function of how the program works or indirectly as a result of virtual memory paging) and thus not making maximum use of the CPU. The example is interesting and you're clearly happy with what you have, but it's not an indication of whether your job mix (or any other mix) could run faster on a multi-processor. What it does say though is that YOU are satisfied with your configuration and if it's fast enough to keep the owner satisfied, that's all that really matters when it comes to a computer config. Others might not be satisfied of course and would therefore look for ways of speeding things up (such as wanting to cut down that 15 minute render time). Capacity evaluation and planning of course requires much more detailed investigation and information about the job mix, hardware particulars, resource utilization dynamics, etc.
If you are running at 85%, not at idle, and it doesn't consistently go above that point, then you are not CPU-bound. Adding a second processor is not the right thing to do in that situation.
... and notice that I've been running my second processor idle for too long. The most simplist point is -- when I click it, I don't want to wait!
In the most simplistic situation of one single threaded program running, that would be true. But with complex job mixes, it only may or may not be true. That's why I said that looking into a second processor makes sense - not that it was the ONLY thing to look at doing. Operating dynamics play a big role in determining overall throughput. The idea of "CPU-bound" is too simple and isn't always relavent (especially to use as a blanket determination of whether a second processor is or isn't the "right" thing to do). A box can be at 85-90% consistent CPU utilization (theoretically not fully "CPU-bound") but still be "processing constrained" (i.e., unable to do any more work without degrading overall job mix performance). Such systems can see an incremental job mix performance improvement (i.e., reduction in overall execution time) by adding a second processor because of reduced context switching overhead, reduced main memory cycle times, etc. In the worst case situation, analysis might even show that streamlining part of the I/O subsystem would remove a bottleneck that's introducing additional throughput inefficiency (thus keeping the CPU utilization from increasing where it would otherwise go and keeping overall execution times longer than necessary) - in which case you'd want to look at both making an I/O improvement and a second processor (since the I/O streamlining will remove the block preventing CPU utilization from increasing further). So, as originally stated, if a machine is running at 85%+ consistently, then it's time to look into various options - including whether a second processor makes sense. Is it always the right choice - of course not, no one said it was. Is it sometimes the right choice - of course it is, that's why you look at it to see if it makes sense in the particular situation. Do most people need dual 2 Ghz P4s? Nope. Do some people? Yep.
The answer's pretty simple, Bryce is a pig. With very little reduction in rendering time, the renderer is (1) not multi-threaded (or if it is, then it has excessive inherent thread contention that effectively makes it single threaded) and therefore can't benefit from dual processors and/or (2) is hitting the disk drive a lot and most of the time is in I/O wait (and thus can't benefit from the more than double processor speed that even an ordinary single threaded non-I/O bound process would receive). Bryce isn't commercial grade rendering software, so I guess it's not too surprising. If CPU utilization is fairly low on both systems during the rendering, then I/O bounding is pretty likely. However, if your machine is pushing high CPU during rendering, then the better test would be to fire up two renderings on your machine and see how long it takes to complete both jobs and then do the same on the faster machine. If Bryce is not I/O bound, then you'd expect your machine to take twice as long as the other machine to complete the two simultaneous renderings. However, it's probably a good guess that the Bryce render is I/O bound.