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.