Multicores
|
From: Benny Amorsen on 3 Sep 2005 07:25 >>>>> "rv" == robertwessel2(a)yahoo com <robertwessel2(a)yahoo.com> writes: rv> In any event, time slice triggered context switches are *very* rv> rare. At best a few tens to a few hundred per second. IIRC, in the original AmigaOS -- I think up to 2.0 -- time slice triggered context switching was actually broken -- but no one noticed, since enough events were usually generated to keep contexts switching back and forth. (These days a scheduler would probably give control back to a low-priority process interrupted by a high-priority process as quickly as possible, and so the bug would not be hidden.) /Benny
From: Joe Seigh on 3 Sep 2005 07:53 robertwessel2(a)yahoo.com wrote: > > The number of context switches is not typically reduced in any > significant way by going to a dual (or multi-) CPU system. The vast > majority of context switches occur because a thread blocks or calls on > another thread or context for a service (really the same thing), and > those are *not* impacted by the number of CPUs in the system. Context > switches due to time slice expirations *can* be reduced by a multiple > CPU configuration, but only if the number of threads tends to be close > to the number of CPUs. If there are many runnable thread, and the time > slice interval does not change, even that can be slower on the dual > processor system, since slices will occur after only half the number of > instructions. In any event, time slice triggered context switches are > *very* rare. At best a few tens to a few hundred per second. > Except for systems like Linux which preempt signaling threads (at least on single processor systems). You can significantly speed up a Linux multi-threaded application by adding a sched_yield() after a blocked wait. One of the rare instances where two wrongs make a right. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.
From: Nick Maclaren on 3 Sep 2005 08:10 In article <7oydnZ2dnZ0UikTrnZ2dnRkThN6dnZ2dRVn-052dnZ0(a)comcast.com>, Joe Seigh <jseigh_01(a)xemaps.com> wrote: >robertwessel2(a)yahoo.com wrote: >> >> The number of context switches is not typically reduced in any >> significant way by going to a dual (or multi-) CPU system. The vast >> majority of context switches occur because a thread blocks or calls on >> another thread or context for a service (really the same thing), and >> those are *not* impacted by the number of CPUs in the system. Context >> switches due to time slice expirations *can* be reduced by a multiple >> CPU configuration, but only if the number of threads tends to be close >> to the number of CPUs. If there are many runnable thread, and the time >> slice interval does not change, even that can be slower on the dual >> processor system, since slices will occur after only half the number of >> instructions. In any event, time slice triggered context switches are >> *very* rare. At best a few tens to a few hundred per second. > >Except for systems like Linux which preempt signaling threads (at least >on single processor systems). You can significantly speed up a Linux >multi-threaded application by adding a sched_yield() after a blocked >wait. One of the rare instances where two wrongs make a right. And seriously parallel applications that do not spin wait. It is very common (and reasonable) to test a memory-based lock for the other end of a channel having responded, and to enter a wait if it doesn't after a short period. If you have enough cores to keep every thread going, the number of such waits can be much smaller than if you do not. Regards, Nick Maclaren.
From: Skybuck Flying on 3 Sep 2005 19:15 <robertwessel2(a)yahoo.com> wrote in message news:1125731066.086811.73210(a)z14g2000cwz.googlegroups.com... > > Skybuck Flying wrote: > > An interesting question is the following question: > > > > Suppose there are two processors one single core and one dual core. Both are > > rated at the same speed for example: > > > > Single Core Processor 5000+ > > Dual Core Processor 5000+ > > > > The question is how the rating is done. > > > > The disadventage of a single core processor is that the software/operating > > system/applications will have to do many "context switches". Only one > > thread/process can run on a single core processor at a time, so multiple > > concurrent threads/processess will have to be swapped on and off the > > processor as to create the illusion of parallel processing. This switching > > is called a "context switch" and can be considered "overhead" <- which is > > loss of performance/speed. > > > > Software/operating systems/applications which use many threads will cause > > lot's of overhead on a single core processor. > > > > Here is an example: > > (much silliness snipped) > > Except for a few special cases, nobody would want two 1x processors > instead of a single 2x processor. In short, the single faster > processor will run almost everything fast, the dual processor will run > fast only if there is consistently more than one thread ready to > execute, and at best will match the performance of the single > processor. I would want a dual core processor, I would even want a 1000 core processor. The reason is simply because then I as a programmer can start writing *serious* multi threaded software which can take adventage of multi core processors. Assuming that single core processors hit a certain limit than a simple way to get more speed is to do things in parallel. The hardware folks think that their cpu's might not be able to go any faster by increasing the clock speeds so the hardware folks will have to find other ways to speed it up and one fine way of doing that is multiple cores and everything else in parallel too ;) So as more and more software becomes multi threaded these dual/multi cores cpu will work much better because they will be much more responsive and the software can take advantage of the multiple cores thus increasing in speed too, best of both worlds really ;) > The number of context switches is not typically reduced in any > significant way by going to a dual (or multi-) CPU system. The vast > majority of context switches occur because a thread blocks or calls on > another thread or context for a service (really the same thing), and > those are *not* impacted by the number of CPUs in the system. Context > switches due to time slice expirations *can* be reduced by a multiple > CPU configuration, but only if the number of threads tends to be close > to the number of CPUs. If there are many runnable thread, and the time > slice interval does not change, even that can be slower on the dual > processor system, since slices will occur after only half the number of > instructions. In any event, time slice triggered context switches are > *very* rare. At best a few tens to a few hundred per second. As far as I can tell windows xp doesn't care how many threads are running, it will simply give each thread the same ammount of time slice thereby lagging the whole system. That's why the number of contex switches doesn't increase as the number of threads increase. Windows xp makes absolutely no attempt to keep the system responsive. To keep the system responsive windows xp would need to shorten each time slice and thereby creating more contex switches thus leaving less processing power to do anything usefull. Bye, Skybuck.
From: Ken Hagan on 6 Sep 2005 05:31
Skybuck Flying wrote: > > I would want a dual core processor, I would even want a 1000 core processor. > > The reason is simply because then I as a programmer can start writing > *serious* multi threaded software which can take adventage of multi core > processors. A nit pick... You can write such software now. Your customers will need to wait until they have such a processor before they will benefit from it. Until then, there is no advantage to parallel software, only overheads and cost. That's why we aren't all doing it already. |