Author: Vincent Diepeveen
Date: 06:05:38 02/26/03
Go up one level in this thread
On February 25, 2003 at 21:27:13, Matt Taylor wrote: >On February 25, 2003 at 18:53:53, Vincent Diepeveen wrote: > >>On February 25, 2003 at 13:28:43, Matt Taylor wrote: >> >>hello are you trying to measure the quantum of a thread in your code? >> >>how does this measure how fast a thread gets signalled *anyhow* with >>WaitForSingleObject? ><snip> > >Yes, I am measuring a thread quantum. WaitForSingleObject can potentially switch >faster (on the order of nanoseconds possibly, definitely a few microseconds at >worst), but that's not the issue -- Crafty isn't using WaitForSingleObject. >Crafty is using its own custom spin lock. > >You asserted that Crafty would spin on the locked data until its timeslice (or >quantum) was up. That just isn't true unless someone is dumb enough to run mt=2 >with 1 processor in their system. I think Crafty even has code to prevent that, >but I'm not sure. With 1 thread, it is not possible to block on your own locks >unless you have a bug. The spin lock is very fast, faster than making a function >call (neglecting the fact that the function is going to do the same thing). This >equates to a few nanoseconds. now you're bragging a lot of nonsense. Bob is saying he wants to do without spinning. and that i am kind of idiot to not have optimized for it, where i did measure it already for 32 processors in fact as at NUMA systems you cannot waste bandwidth at all. Crafty keeps the locks longer than DIEP. It locks for all processors which it is searching with for a long period of time. DIEP locks only the processor which is busy getting a new job and for a short period of time, then it runs on. The common problem all programs have is what to do at startup when 1 processor starts the YBW search, so the others are idling for a very short while. The more processors you got the bigger this problem is (as you start the YBW+ search with just 500Mhz processor or so). It is here where bob says you should not spin. My argument is that it is impossible to do without spinning under linux because the latency is too high. Bob didn't even measure it yet of course. Under windows the WaitForSingleObject is faster than what you got under linux. Try the 'select' for example under LINUX which is the 'default' solution for everything under *nix. It is a horrible thing to use. It even does do a malloc() or something in the kernel. Under IRIX you can try to use spin_lock() which is trying for 600 tries busywait to get a lock and after that idles a process. For all these systems after those few tries, which of course usually will fail as you do not have a job for at least another few bunch of nodes, then a process gets put to idle, after which the only way to wake it up is by means of the runqueue. This one fires at 100Hz. So minimum latency is 10ms under all the *nix systems. Your measurements of the quantum of a bunch of threads put at HighPriority is therefore complete useless. The alternative for windows is WaitForSingleObject(). Note that in DIEP i do without a single system call there. Got too much scared after the measurements done. >-Matt
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.