Author: Tom Kerrigan
Date: 10:12:05 05/23/00
Go up one level in this thread
On May 23, 2000 at 09:21:31, Robert Hyatt wrote: >On May 23, 2000 at 04:08:16, Tom Kerrigan wrote: > >>On May 23, 2000 at 03:08:52, Bruce Moreland wrote: >> >>>On May 23, 2000 at 02:39:30, Tom Kerrigan wrote: >>> >>>>For some reason, people seem to believe that unless you're using 100% of your >>>>processor all the time, you could make do with a slower processor. >>>> >>>>Okay, maybe your processor spends the VAST majority of its time waiting on you. >>>>But that's not what matters. What matters is how much time you spend waiting on >>>>the processor. >>>> >>>>I have an 800MHz Pentium III at work. It is very noticably faster than my 400MHz >>>>Celeron at home. Even if I'm just browsing the web, I definitely prefer using my >>>>work computer because I have to wait on it half as long. >>> >>>I'm all for faster computers, I just don't see what the benefit is of having two >>>processors in a computer that's used by the typical home or business user. I >>>may have to add "yet" to the previous sentence, but maybe not. >>> >>>People need more processors if: >>> >>>1) They do two CPU-intensive things at once. The typical user doesn't do this >>>very much. >>> >>> or >>> >>>2) The application they are using can divide work. The typical application does >>>not divide work. There are lots of reasons for this. We have a chicken and egg >>>problem due to most computers being single processor. Another reason is that >>>many tasks are inherently sequential. Another reason is that many tasks take >>>very little time to execute, so multiprocessor overhead doesn't make a lot of >>>sense. Another reason is that many tasks that take a lot of time take a lot of >>>time due to bottlenecks other than the processor. And finally, if you have a >>>task that is significant enough that you could notice time saved due to an >>>additional processor, and it is able to be broken down into parts that can be >>>done concurrently, multiprocessor code is often difficult to design, build, >>>debug, document, and maintain. Adding multiprocessor features to most programs >>>is a poor design decision. >>> >>>I am not a Luddite. If you have your normal single-threaded compute-bound app, >>>and you double processor speed, the improvement is immediate, and I approve of >>>this kind of improvement, most definitely. But take one of the many commercial >>>chess apps and put it on a quad processor machine and see what happens -- >>>nothing. This is also true of essentially *any* current app you can buy that >>>does anything. >>> >>>Chess is actually a great case for multiprocessor computers, so for us, they are >>>cool. >>> >>>But it will be a while until the typical user sees much advantage to adding >>>another processor, I think. >>> >>>I see that multiple processor machines are becoming more common, but I can't >>>understand why, and I can't understand why this trend would continue. >>> >>>bruce >> >>Sorry, I didn't read your post carefully and didn't realize you were talking >>specifically about multiple processors. >> >>"Multiprocessing" will hopefully become widespread soon thanks to >>multi-threading processors. This is an idea that [mainly] Compaq/Alpha has been >>promoting. The idea is that if you have a processor with 2 execution units, you >>can do one of two things: >> >>1) Use both units to execute a single thread; unfortunately, one of the units >>will probably be idle a lot of the time. This is what most chips do now. >> >>2) Use one unit per thread, in the case that two threads are running. That way, >>neither unit spins. >> >>The chip real-estate overhead for multithreading is evidently pretty small. >>Hopefully it will be incorperated in mainstream chips soon. >> >>-Tom > > >That is the main case we were discussing. I pointed out that within the next >3-5 years, most microprocessors will probably follow this path, so that each >single processor chip will have 2 (or even 4) cpus internally. Multi-threading >CPUS are a bit different, but not much. Some designs don't really have multiple >cpu cores, but they are able to contain multiple processor states, so that >context-switching is essentially free. On-die multiprocessing and processor-level multithreading are two very different things. -Tom
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.