Author: Vincent Diepeveen
Date: 17:20:05 09/03/03
Go up one level in this thread
On September 03, 2003 at 16:28:18, Robert Hyatt wrote: >On September 03, 2003 at 15:27:15, Vincent Diepeveen wrote: > >>On September 03, 2003 at 13:15:48, Robert Hyatt wrote: >> >>>On September 03, 2003 at 12:23:08, Vincent Diepeveen wrote: >>> >>>>On September 03, 2003 at 10:54:37, Sune Fischer wrote: >>>> >>>>>On September 03, 2003 at 10:48:31, Vincent Diepeveen wrote: >>>>> >>>>>>>I only see the need for communication when there is *somthing* to communicate. >>>>>> >>>>>>You answer your own question already. There continuesly is something to >>>>>>communicate. >>>>> >>>>>Such as? >>>>> >>>>>Whatever it is maybe it can be redesigned by using a smarter message system. >>>>> >>>>>The parent thread doesn't need to know *what* the child thread is doing, it only >>>>>needs to know what the child threads finds, if anything at all, right? >>>>> >>>>>-S. >>>> >>>>The only one who you are confusing is yourself. >>>> >>>>DIEP runs fine at any latency, but the speedup simply gets a lot less when the >>>>latency goes up. >>>> >>>>There are many practical problems. >>>> >>>>You speak about shipping messages. >>>> >>>>When are you going to receive them. Check each millisecond? >>>> >>>>Or let the OS decide? >>>> >>>>The OS fires at 100Hz, so things like processes that are sleeping because of the >>>>OS putting them to sleep (when locking and for 600 times they can't get the >>>>lock) then you have a latency of 10 ms before the process is awake. >>>> >>>>You are aware of such problems? >>>> >>> >>>No, because there is no such problem. If you are running something else on >>>the same CPU, then you will see that 10ms latency. If that CPU is idle, then >>>the instant the process is unblocked it will begin execution. >> >>Wrong, the 10ms latency is there to put something in the RUN queue of the >>kernel. Though there is no technical reason to remove that 10ms for the OS >>programmers, they are not allowed to do that, because that is violating >>agreements with important software manufacturers which have written software >>that assumes 10ms latency here and this crucial software will crash and cause >>severe problems if it is no longer there. >> >>The OS helpdesk. > >It absolutely does _not_ work like that. What happens is this: > >Processes are blocked. As an interrupt comes in, a process gets moved from >blocked to ready. The temptation is to move that process from ready to run >if it is higher in priority than the process already in run. But that causes >excessive context switching. So, the process gets moved to ready and there >it sits until the next 10ms timer interrupt fires, and _then_ the scheduler >is called to move the currently running process back to ready, and the newly >ready process (of a higher priority) into running. > >That is _all_ there is to it. > >If the CPU is idle, and the interrupt comes in, the process is scheduled >_right now_, it goes from blocked to ready to run _instantly_. No 10ms >delay. > >There is no doubt about how that works. And your explanation is simply >garbage. Ask some of the linux kernel guys. Ingo Molnar is a good one to >ask although Alan Cox will also answer. The double origin3800 has 1024 cpu's. One partition (P7) is sized 512 processors from which 500 can get used simultaneously to run a single program cc-NUMA. So sorry to inform you that Linux doesn't run on any partition cc-NUMA > 64 cpu's. IRIX does though. With 10 braincells one could have known though that the SGI-Origin3800 is running IRIX. I did at least, that's why i asked SGI instead and got back this answer. In fact way more was answerred than just this. Best regards, Vincent > >> >>Thank you, >>Vincent >> >>>I have explained this before. You can read about it in any good O/S book >>>that discusses this approach. Your "conception" of the algorithm is flawed. >>> >>>>DIEP only can run well parallel at a shitload of cpu's thanks to statistical >>>>chances that a scenario X doesn't happen much. >>>> >>>>That took 1.2 years fulltime work. Still tuning some details. >>>> >>>>There is a lot of communication. It is very easy to test this yourself. >>>> >>>>Just get a cheap network card. Say 100mbit and connect 2 pc's. Now let them do a >>>>parallel search. >>>> >>>>Please report back to me when you have a speedup > 1.0, because initially you'll >>>>be slower than 1.0 i bet. >>>> >>>>Best regards, >>>>Vincent
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.