Author: Tom Kerrigan
Date: 14:59:22 05/23/00
Go up one level in this thread
On May 23, 2000 at 14:40:52, Robert Hyatt wrote: >On May 23, 2000 at 13:12:05, Tom Kerrigan wrote: > >>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 > > >Only conceptually... On-die multiprocessing is splatting two processors on the same chip. All of the processors. Including various buffers, caches, etc. Proc-level multithreading is adding a few register files and scheduling logic. All the other processor stuff is shared. So, extremely different concept _and_ design approach... -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.