TalkChess.com

michiguel wrote:I would not be surprised if SF is ~10 elo points stronger if it does not save in HT the results of null searches.

Instead I would be surprised a lot because, also this change, as _all_ the changes that went in SF are tested with at least thousand games and in this case saving the null search value proved to be slightly better then do not.

Thanks Jim!

I actually did not have a copy yet either of Stockfish 1.7.1. With a little bit of luck, Mediafire will also not be capable of handling the download-traffic

Eelco

michiguel wrote:

mcostalba wrote:

IWB wrote: The biggest problem was that Zugzwang detection is weakening the engine, that was something I did not consider - when I read then about the Minimum Split point I was totaly confused ... but all turned out to be ok.

You are right. I will try to explein why zug detection _could_ (because is still not proven 100% but our internal tests say so) weaken the engine.

When SF evaluates a position it stores the position score in a big table in memory called transposition table or hash.

If SF founds again the same position it does not search again through that, but simply uses the already saved position score. This saves a lot of searching effort. It is very common practice and almost all teh engines do the same.

In SF we save the position score _also_ when doing what is techncially called a null move search that is a kind of quick search to see if position deserves to be searched deeper or, being uninteresting, can be skipped.

This null move search is very powerful but has a weak point: it can fail when the position is zugzwang for the side to move. In this case the null search can give a wrong result and reports that the side to move is winning while it is not. Normally is not so dangerous, but if you save the wrong result in the hash table (as we do starting from 1.7), next time you find the same position you think you are still winning yielding to a completely wrongly evaluated position (I am not very precise here because otherwise the things would be a little bit messy, but the concept is this).

So, how zug detection works ?

With zug detection SF simply does _not_ saves in hash table the score for the positions found by null search, in this way you cannot mislead a zug position but at the same time you lose the benefit of having the position score already saved in the hash table and so your search effort is bigger: that's the reason why zug detection could weaken your engine (also in this case the description is not 100% accurate but gives the idea, actually SF saves the same the score but does not use it in certain cases)

I think it will be the opposite. As it was discussed in another thread, saving the results of null searches in the hashtable do not help much, and as a consequence, they actually pollute the hash table. I would not be surprised if SF is ~10 elo points stronger if it does not save in HT the results of null searches.

Miguel

Because real zug position happens very seldom in real games you end up with a bigger searching effort for no real benefit when you enable the zug detection.

I hope it is clear enough.

I always have the impression -just that- that deep null move searches are a bit nonsensical. The effect of a nullmove should be immediate and maybe the detection of Zugzwang-like effects is a main reason deeper nulmove searches are necessary. But they are essentialy used to prove that a node is not important. If you have little hash available -this will never be an issue with short timecontrol testing- I would rather not store a null move search if this displaces other entries. But I have never tried anything like like not storing null window search results if they are after a null move. That is probably very drastic.

After a certain depth though, most of these null move fail high nodes should stay high indefinitely unless alpha fails low. After reaching enough depth maybe you could experiment with just doing the verification each time, which at least detects Zugzwang immediately. Still I have never tried anything that drastic and nullmove remains a very usefull technique and hard to do without so maybe it is just prejudice that there should be a real difference in how nullmove acts with big searchdepths.

I know how much the search is slowed down if the hashtable is getting "full", you can just look at some of the search-results from Louis Zulli who uses I think somewhere around 1024 Mb -not sure- with those of Rainbow Serpent using 256 MB, the programs are different but the main reason for not reaching higher depths is I think the transposition table entries going missing. The same thing probably applies to storing q-search results, storing those will help most at timecontrols that do not need the full hashtable. They are different in the respect that on deeper iterations you will just generate different q-searches of hopefully short lenghts for new endnodes, but null move searches just keep growing because they start right from the root. And after a certain depth I think they contain/generate nonsense

Regards, Eelco

mcostalba wrote:

PauloSoare wrote:Thanks to all Stockfish team. I like computer chess for 31 years ago, as I recall, is the first time I see a free program between the two best in the world.

Actually it is the first time that the _officially_ best in the world is between two free (and open sourced, that is far more sensible then being free) programs

You're right. 31 years following computer chess and I do not
know to express myself properly.

Jim Ablett wrote:

beachknight wrote:Hi Jim,

Could you please provide another d/l links for SF171?

Best,

Massive download traffic for Stockfish has put an end
to my public Dropbox downloads temporarily.
Mirror links are now available on my homepage (Mediafire)

Jim.

Thank you!

Best,

Tord Romstad wrote:

mhalstern wrote:I have HT off on my pc as this option is better for other engines that I use. Fot The latest Stockfish Version, would 8 cores be better than 4?

I am not sure whether I understand your question. Did you mean to ask "...would 8 threads be better than 4"?

For optimal strength, the number of threads should always equal the number of physical CPU cores (for Stockfish, and probably also for all other chess engines). If you have a quad-core machine (with or without hyperthreading), use four threads. Also remember to set "Minimum Split Depth" to 4 if you have a quad-core.

Stupid slit depth I wish I had read this before!


change -- actually i have it on 4 but in task manager i still get 8 threads running


max #split threads per split point=5
minimum split depth =4
threads=4
Intel core 2 quad cpu Q6600 2.4 ghz 3 gb ram
WIn xp.


I guess thats the way it works!

With ivanhoe sometimes i get 8 even 16 threads running ...

Tord Romstad wrote: If Stockfish doesn't detect the correct number of CPU cores on your machine, it is important not only to adjust the number of search threads, but also the "Minimum Split Depth" parameter. On a CPU with 4 or fewer cores, this parameter should be set to 4. On an eight-core machine, it should be set to 7.

I think it would be no violation of the UCI protocol if you would change the "split depth" parameter internal if the engine is getting a thread command.

So, if threads are setup in a external file you could setup the split depth directly and set a new default value. The default value will display if the uci command comes.

Thats what i do in Homer if , just for example, the egtb path has been changed in my external ini file, a new default egtb string will be printed if the uci command comes.

Yes, in know some gui's might be handle uci option staticly at the first install, but that's wrong. uci can be changed every time.

However, it just would it make easier for the users out there.

Best,
Daniel

The new stockfish is really excellent against closed and semi-closed positions. It's very nice to have another option to analyze these positions.

mcostalba wrote:

michiguel wrote:I would not be surprised if SF is ~10 elo points stronger if it does not save in HT the results of null searches.

Instead I would be surprised a lot because, also this change, as _all_ the changes that went in SF are tested with at least thousand games and in this case saving the null search value proved to be slightly better then do not.

Then again, at fast pace when HT replacement is not critical.

Miguel

From 1.6 to 1.7 we have seen a new search approach.
I wonder what comes next. A totally new eval?

This is great piece oft software. It plays already very strong. On the other hand there seem to be much potiential for further improvements. From reading the sources and the comments within the sources, I get the impression of a rough diamant here and there. Also it's eval output is a little tipsy some times. All in all to me it's still mysterious why it plays so strong???