Stockfish "use sleeping threads" - Redux

[michiguel]

BTW I have given a quick look at Crafty code but the "pause" solution does not seem portable to me becuase is coded in an asm{} gcc-ism statement that does not work under Windows....

In Windows there's the function YieldProcessor() - maybe this only works in Visual Studio.

Robert

From
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Code: Select all

YieldProcessor Macro

Signals to the processor to give resources to threads that are waiting for them. This macro is only effective on processors that support technology allowing multiple threads running on a single processor, such as Intel's Hyperthreading technology.

I am not sure is an equivalent solution, becuase it seems if HT is off then threads keep spinning....at least reading the docs it seems like this to me.

Can't you use semaphores to make it portable? maybe I do not understand the problem.

Miguel

[bob]

BTW, is this a bit of perhaps broken English? Does it mean "threads sleep when waiting rather than spinning"? for example?

yes, that's the meaning. I am not native speaker so probably I choose a not best name, but for me a thread blocked on a condition variable "does sleep".

BTW I have given a quick look at Crafty code but the "pause" solution does not seem portable to me becuase is coded in an asm{} gcc-ism statement that does not work under Windows....

There was a windows version of the #include. I will look around to see if I can find it. That was the intel-recommended solution for spin locks on a HT-enabled CPU...

[bob]

BTW I have given a quick look at Crafty code but the "pause" solution does not seem portable to me becuase is coded in an asm{} gcc-ism statement that does not work under Windows....

In Windows there's the function YieldProcessor() - maybe this only works in Visual Studio.

Robert

That's software. Just tells the process scheduler "put me back in the ready state and choose another ready process to execute, if there is one." Same sort of idea, but not related to hyper-threading. Related to one process spinning while waiting on another that is not running as often as desired to clear the condition causing the other process to spin.

[bob]

BTW I have given a quick look at Crafty code but the "pause" solution does not seem portable to me becuase is coded in an asm{} gcc-ism statement that does not work under Windows....

In Windows there's the function YieldProcessor() - maybe this only works in Visual Studio.

Robert

From
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Code: Select all

YieldProcessor Macro

Signals to the processor to give resources to threads that are waiting for them. This macro is only effective on processors that support technology allowing multiple threads running on a single processor, such as Intel's Hyperthreading technology.

I am not sure is an equivalent solution, becuase it seems if HT is off then threads keep spinning....at least reading the docs it seems like this to me.

Can't you use semaphores to make it portable? maybe I do not understand the problem.

Miguel

Semaphores/mutexes have a significant latency. It takes thousands of instructions to block a process, and then unblock it and get it back into the CPU. Not even considering cache loss and such... This is only an issue when you have more threads than real processors, as it is impossible to recognize who is spinning and who is doing useful work. I make it a practice to always run with #threads == #cpus... then a spinning process doesn't hurt a thing if all that machine does is play chess...

[bob]

I posted a reply to Robert but that vanished somehow, probably I goofed. Anyway, most of what I wrote was rendered irrelevant by the subsequent exchange.

So Marco: this option it uses thread synchronization mechanisms to start and stop threads? Contrary to what? Terminating and creating new threads? Or using variable polling? Have I understood anything?

And maybe something like "Use thread-waiting" or "Use thread synchronization objects" will make me (and others) shut up about terminology?

I am guessing as opposed to spinning in a busy wait (spin loop)...

[bob]

I strongly suspect this test is meaningless. The idea "use sleeping threads" is not something that "parses" in my terminology.

Sorry but I fail to see a link between the two sentences.

P.S: Regrading terminology, in case you may want to give a not so quick look at the code, perhaps then is gonna parse better

I did, and it still didn't parse. It appeared that you meant "threads block (sleep) as opposed to spinning?" That "use sleeping threads" did not carry that idea very well. I would suggest, as alternatives, "waiting threads block|spin" or "threads block|spin when waiting" or something similar. "use sleeping threads" translates to "use a thread that is sleeping" which is what I was having trouble understanding, and that is obviously not what you meant.

[adamh]

Semaphores/mutexes have a significant latency. It takes thousands of instructions to block a process, and then unblock it and get it back into the CPU. Not even considering cache loss and such...

With all respect Robert, I do not think that a thousand instructions are a lot. Assuming that a thread runs a chunk of work for at least one second, then the mutex stuff would be one millionth of that second. (Assuming 3 clock cycles per instruction). Or did I get something wrong?

On the other hand I fail to see any performance gains too. But synchronisation objects could produce neater code (matter of taste yes), thus making it easier to focus on the real task at hand...[/quote]

[mcostalba]

On the other hand I fail to see any performance gains too.

Modern CPUs have a dynamic clock policy. Speed is throttled back when CPU heats up, so keeping a cooler machine it means to give the opportuninty to the CPU to increase the clock. This could be difficult to prove testing on a single machine where the "other" engine heats up the CPU while thinking and we know thermal behaviour has an inertia longer then the time to move especially at fast TC, but when playing say on a chess server keeping a cooler machine could help. And is proved (at least I see this on my QUAD) that "sleeping/blocking threads" help in this regard, simply looking at task manager's activity it is possible to see that CPU is less loaded than with full threads running.

[adamh]

So Marco,

you seem to say: the only effect of "use sleeping threads" is the thread synch mechanism, nothing else???

And on my machine with my tests above , (with megaloads of cooling), the performance difference would be caused by CPU frequency variations (due to temperature)? Temperature would have to vary very very quickly to have such an effect I'd say...

Is this what you are saying?
* * *
BTW: Could you please take a look at my Visual Studio troubles, under "Programming" THX

[bob]

Semaphores/mutexes have a significant latency. It takes thousands of instructions to block a process, and then unblock it and get it back into the CPU. Not even considering cache loss and such...

With all respect Robert, I do not think that a thousand instructions are a lot. Assuming that a thread runs a chunk of work for at least one second, then the mutex stuff would be one millionth of that second. (Assuming 3 clock cycles per instruction). Or did I get something wrong?

thousandS. Notice the S. If you do lots of locks and unlocks within the search, as some do with the hash table, then thousands of instructions per node, where you can normally search a node with a few thousand instructions, total, is a _big_ deal.

In endgames, splitting near the tips, the same thing happens. You should never ignore "thousands" of instructions. If you do those enough times, it becomes millions and then billions...

On the other hand I fail to see any performance gains too. But synchronisation objects could produce neater code (matter of taste yes), thus making it easier to focus on the real task at hand...

[/quote]

Problem is, there are no standards that work across platforms, where my spin locks work everywhere. Windows doesn't do things in a POSIX compliant way, obviously, so the code is not necessarily neater, it ends up with duplicate code surrounded by #ifdef(xxx) which is messier.