Author: Robert Hyatt
Date: 13:28:18 09/03/03
Go up one level in this thread
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. > >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.01 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.