Stockfish 1.7.1 update available

Discussion of anything and everything relating to chess playing software and machines.

Moderators: Harvey Williamson, Dann Corbit, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Stockfish 1.7.1 update available

Post by mcostalba » Sun Apr 11, 2010 10:40 pm

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.

User avatar
Eelco de Groot
Posts: 4277
Joined: Sun Mar 12, 2006 1:40 am
Location: Groningen

Re: Stockfish 1.7.1 update available

Post by Eelco de Groot » Sun Apr 11, 2010 10:44 pm

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
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan

User avatar
Eelco de Groot
Posts: 4277
Joined: Sun Mar 12, 2006 1:40 am
Location: Groningen

Re: Stockfish 1.7.1 update available

Post by Eelco de Groot » Sun Apr 11, 2010 11:23 pm

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 :P

Regards, Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan

PauloSoare
Posts: 1335
Joined: Thu Mar 09, 2006 4:30 am
Location: Cabo Frio, Brasil

Re: Stockfish 1.7.1 update available

Post by PauloSoare » Mon Apr 12, 2010 4:56 am

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

User avatar
beachknight
Posts: 3533
Joined: Tue Jan 09, 2007 7:33 pm
Location: Antalya, Turkey
Contact:

Re: Stockfish 1.7.1 update available

Post by beachknight » Mon Apr 12, 2010 6:58 am

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,
hi, merhaba, hallo HT

frcha
Posts: 191
Joined: Thu Jan 28, 2010 4:47 pm
Contact:

Re: Stockfish 1.7.1 update available

Post by frcha » Mon Apr 12, 2010 3:12 pm

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! :twisted:


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

User avatar
Daniel Mehrmann
Posts: 857
Joined: Wed Mar 08, 2006 8:24 pm
Location: Germany
Full name: Daniel Mehrmann

Re: Stockfish 1.7.1 update available

Post by Daniel Mehrmann » Mon Apr 12, 2010 3:31 pm

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

Dann Corbit
Posts: 11702
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: Stockfish 1.7.1 update available

Post by Dann Corbit » Mon Apr 12, 2010 7:03 pm

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

User avatar
michiguel
Posts: 6401
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: Stockfish 1.7.1 update available

Post by michiguel » Mon Apr 12, 2010 7:15 pm

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

Ralph Stoesser
Posts: 408
Joined: Sat Mar 06, 2010 8:28 am

Re: Stockfish 1.7.1 update available

Post by Ralph Stoesser » Mon Apr 12, 2010 8:31 pm

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

Post Reply