Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: The need to unmake move

Author: Robert Hyatt

Date: 08:04:00 09/04/03

Go up one level in this thread


On September 03, 2003 at 20:20:05, Vincent Diepeveen wrote:

>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.



Ask them the following question:  (I already know the answer)

I have a process running on a CPU with no other processes.  My process
blocks to do an I/O.  When that I/O interrupt comes in, how long does it
take before my process is back running on that processor again?

Answer is _not_ 10ms.

It is not 1ms.

it is _immediately_.

If you are running more than one process on a single CPU, yes it will be
10ms.  But if you only have one process running, and it blocks, when it
unblocks later it is scheduled _immediately_.

Once you get that, you will know a bit more than you know now, and you'll
stop making stupid statements.  The very idea of a process unblocking, but
having to sit 10ms on an idle processor before it begins is so far beyond
stupid, it takes light 6 months to get from stupid to there...

>
>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.