Author: Vincent Diepeveen
Date: 12:27:15 09/03/03
Go up one level in this thread
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. 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.