Setting-Experimente mit Stockfish 140106

By Hauke Lutz Date 2014-01-13 01:46

Die "stockfish_14011120_x64_modern_sse42"-Version führt im Bullet 10s+0,5" gegen Houdini 4 nach 156 von 1000 Partien mit +35 Elo.
Es wurde das Standardsetting ohne Pondern und ohne Idle Threads Sleep verwendet.

Hash = 1 GB
Kerne = 1 (Takt 4,5 GHz)

By Stefan Pohl Date 2014-01-13 04:47

Hauke Lutz schrieb:

Auf die Gefahr hin, dir auf den Keks zu gehen, merke ich dennoch an: Das geringe Verhältnis von Basiszeit zu Fischerbonus (nur Faktor 20) läßt den Engines kaum Spielraum ihren Zeiteinteilungsalgorithmus zu benutzen. Da dieser m.E. bei Stockfish noch immer verbesserungswürdig ist, könnte das Stockfish in diesem Test durchaus etwas bevorteilen (gegenüber Tests mit größerer Basiszeit (wie z. B. in der LS-Rangliste)).

Stefan

By Hauke Lutz Date 2014-01-13 05:36

Gegen konstruktive Kritik habe ich nichts einzuwenden

By Hauke Lutz Date 2014-01-13 05:42

Ich hab beim Endspiel beobachten können, dass Stockfish bei ausgeglichender Stellung Houdini gerne die Initative überlässt um am Ende von Houdini reingelegt zu werden oder Opfer seiner Selbst zu werden.

By Heinz Hagenstein Date 2014-01-14 14:01

ja im Endspiel da stimmt was nicht,

mein Gegner zeigte =.0 an mein Stockfisch über 4 im minus,und das über mehrere Züge.

By Stefan Pohl Date 2014-01-13 06:09

Hauke Lutz schrieb:

Gegen konstruktive Kritik habe ich nichts einzuwenden

Sehr löbliche Einstellung. Dann mache ich gleich weiter daimit und sage, daß 1 GB Hash bei diesen Testbedingungen völlig übertrieben viel ist. Selbst bei deinen schnellen Cores sind 256 MB mehr als ausreichend. Und überdimensionierte Hashtables können wegen des größeren Hashkeys ggf. etwas bremsen...Viel macht das aber nicht aus.

Stefan

By Hauke Lutz Date 2014-01-13 06:23

Das 256 MB ausreichen ist gut.
Das ein großer Hash sogar bremsen kann wusste ich noch nicht.
Hast du eine Vorstellung davon wie viel Hash bei welcher Anzahl von Knoten sinnvoll ist?

By Frank Quisinsky Date 2014-01-13 07:27

Hallo Lutz,

beim kleinen Permanent Brain (Hash) kommt es auf den Füllungsgrad an.
Suche Dir die gefräßigste Engine heraus und schaue, dass beim Turnier ca. 50% der Hash-Tabellen belegt werden.
Rechnet die Engine mal länger geht es an die 100%.

Siehe "Beeinflussungsfaktoren" unter "Conditions" ... Hilfe auf meinen Webseiten.
Spiele bei i7 4.3GHz bei 40 in 5 auch nur mit 256Mb. Überlegte lange ob ich auf 512Mb hochgehe aber ich sehe den Nutzen nicht bei ca. 7,5 Sekunden durchschnittliche Rechenzeit.
Von der Anzahl der Knoten würde ich das nicht abhängig machen (unterschiedliche Nutzung der Hashtabellen ist das Thema).

Würde ich mit 40/10 spielen ... 512Mb oder mit 40 in 20 ... 1.024Mb. Mehr als 2.048Mb würde ich eh nie geben.
Es sei denn bei einer Endspielanalyse.

Gruß
Frank

By Stefan Pohl Date 2014-01-13 07:29

Hauke Lutz schrieb:

Das 256 MB ausreichen ist gut.
Das ein großer Hash sogar bremsen kann wusste ich noch nicht.
Hast du eine Vorstellung davon wie viel Hash bei welcher Anzahl von Knoten sinnvoll ist?

Eine Stellung zu verhashen braucht wohl so ca. 10-12 Byte.
Ergo nimmst du die Zahl der Knoten pro Sekunde, die die Engine in deinem Test mit der höchsten Knotenzahl pro Sekunde, im Schnitt anzeigt.
Und das multiplizierst du dann mit dem ungefähren Bedenkzeitverbrauch pro Zug (in Sekunden), gemittelt über die ganze Partie (bei LS-Tempo ist das ca. 1 sekunde pro Zug).
Das verdreifachst du nun, weil ja am Anfang der Partie die Bedenkzeiten länger sind und es auch mal einen fail-low mit längerer Bedenkzeit geben kann.
Und nun noch das Ganze mal 12 (wegen 12 Byte pro Hash). Dann hast du die Hashgröße in Byte, die sinnvoll ist. Da aber eine Hashgröße immer eine 2er Potenz sein sollte, rundest du das dann hoch bis zur nächsten 2er Potenz.

Wenn Houdini bei dir so ca. 3 Millionen Knoten pro Sekunde macht (singlecore) und du würdest LS-Bedenkzeit nehmen, dann nimmst du 3 (Millionen Knoten pro Sekunde) * 3 (1 Sekunde Bedenkzeitverbrauch verdreifacht) * 12 = 108. Also sollten sogar 128 MB reichen. Alles natürlich für singlecore-Betrieb! Im Quadcore-Betrieb sind dann 128*4=512 MB sinnvoll. Bei noch mehr Kernen entsprechend noch mehr.
Bevor mir hier Leute vorrechnen, daß ich in meiner LS-Rangliste etwas zuwenig Hash benutze (128 MB wären besser als 64 MB) - das ist mir bewußt. Allerdings hatte ich zu Beginn der LS-Liste nur ein Notebook, auf dem dann 4 Partien (und somit 8 Engines) parallel liefen. Und das Notebook hat nur 4 GB RAM und mindestens 2 GB wollte ich für Windoofs freihalten. Und manche Engines haben noch separate PawnHash-Tabellen und/oder belegen noch TB-Cache, auch wenn ich ohne TBs teste. Das wäre mir deshalb zu knapp geworden...Und bei mir erreicht Houdini auch nur ca. 2.1-2.2 Millionen Knoten pro Sekunde.

Stefan

By Hauke Lutz Date 2014-01-13 07:54

Ok, danke für die Info

By Benno Hartwig Date 2014-01-13 08:59

> Bevor mir hier Leute vorrechnen, daß ich in meiner LS-Rangliste etwas zuwenig Hash benutze (128 MB wären besser als 64 MB) - das ist mir bewußt.

Das finde ich auch sehr OK. Der effektive Umgang mit dem Hash, wenn er nicht überdimensioniert ist, ist doch ggf. wichtig.
So soll eben gern auch die gute oder weniger gute Behandlung von Kollisionen (so es hier denn Unterschiede gibt) in den Vergleichstest eingehen.

Benno

By Horst Sikorsky Date 2014-01-13 09:25

ich analysiere im Moment mit ComStock +6 steiner 4096 Hash +4096 Triplehash -CPU-Auslastung 92-97%
Phy..Speicher 82%. Arbeitsspeicher Comstock gesamt 12.662.1
Ganz schön viel, oder?
Horst

By Michael Scheidl Date 2014-01-13 13:58

Es sollte genügen.

By Michael Scheidl Date 2014-01-13 13:57

Zitat:

Und das multiplizierst du dann mit dem ungefähren Bedenkzeitverbrauch pro Zug

Das halte ich zwar für einen weitverbreiteten Irrtum, die Hashgröße nur darauf abzustimmen was für einen einzigen Zug benötigt wird - denn ein nicht geringer Teil des Nutzens ist ja sicherlich, daß Einträge über mehrere Züge hinweg behalten werden. Aber falls

Zitat:

Das verdreifachst du nun,

...dann wird's schon passen, denn was in einem Partieverlauf vor mehr als drei Zügen war, ist sicher eher entbehrlich als das zeitnahe. Wobei man aber öfters sinngemäß lesen konnte, daß die Hash-Ersetzungslogik keine triviale ist (Stichwort Hashlernen/Rückwärtsanalyse).

Das mit dem Bremseffekt durch (sehr!) große Hashtables widerspricht an sich der grundsätzlichen Hashlogik, tritt aber ein weil bzw. falls der sog. TLB, ein Puffer der normalerweise RAM-Speicherzugriffe beschleunigt, an Performance verliert. Ich habe das ganze nur sehr oberflächlich verstanden, falls überhaupt. Jedenfalls würde ich mit diesem Effekt frühestens bei 512 MB rechnen, oder erst bei 1 GB.

By Thomas Plaschke Date 2014-01-14 20:23

Vielen Dank für diesen Beitrag, Michael Scheidl.

Ich denke, man kann praktische Erfahrungen mit den Tabellengrößen sammeln. Man kann auch Faustregeln aufstellen. Das erklärt aber weder wie Hashtabellen wirklich funktionieren noch die Erfahrungen oder Faustregeln. Dabei ist dazu nun wirklich viel und verständlich geschrieben worden.

Vielleicht liegt's auch an der Meinungstreue, mit der hier manche Meinung vertreten wird, dass sich hier kein (Schachprogrammier-)Praktiker zu solchen Themen äußert ...

Da ich selber von meinen - kleinen - Ausflügen in die Schachprogrammierung keine eigenen Erfahrungen mit der Erstellung von Hashtabellen beisteuern kann und nur in fremdem Code gestöbert habe, bitte ich meine Äußerungen natürlich mit einer Portion Vorsicht zu genießen (Ich bin auch nur Interpret). So viel vorweg.

- Ein Hashtabelleneintrag von Stockfish ist 16 Bytes groß. Was der Compiler daraus macht, wenn er möglicherweise die Speicherzugriffe des Programms optimiert ... Habe ich nicht kontrolliert. Könnte man prüfen. (x86 kommen Speichzugriffe auf 2-, 4- und 16-Bytegrenzen entgegen. Für die diversen Prozessorcaches spielen Cachelines auf 256 Byte-Grenzen eine Rolle. Pagegrenzen ebenfalls. Da sind überall ein paar Prozessortakte zu verlieren.).

- Programme, die mit mehreren Prozessen oder threads laufen, müssen für einen Informationsaustausch der Prozesse/threads untereinander sorgen. Hashtabellen sind dafür ein einfacher Weg. Je kleiner desto schlechter, oder? Ich weiß nicht, wie Stockfish das macht. Auch unter diesem Aspekt scheinbar ein Widerspruch: Je weniger Prozesse/threads desto besser möglicherweise.

- Es wäre neu für mich, dass die Hashtabellengröße gut bemessen ist, wenn das Programm sie auch "voll" bekommt. In volle oder fast volle Tabellen bekommt man keine Informationen hinein, ohne vorhandene Informationen zu überschreiben. Schlimm genug, worauf Michael Scheidl vermutlich völlig zu recht hinweist, dass die Tabellen nach mehreren Züge unweigerlich voll werden und dann die Hash-Ersetzungslogik das Beste aus der Situation machen muss.

- Hashtabelleneinträge veralten. Irgendwie müssen sie wieder recycelt werden.

- Ich habe mit einem i5 (4 threads) experimentiert und für Stockfish eine Tabellengröße von 1024 MByte als gute Größe für Kurzanalysen von ca. 10-120 Sekunden ermittelt. Vergleiche bis 8 GBytes zeigten etwas bessere Lösungszeiten. Höhere Knotenzahlen waren mit kleineren Hashgrößen 64-256 MBytes zu erreichen. Aber was bringt das schon?

Meine 5 Cents zu dem Thema

Viele Grüße
Th. Plaschke

By Stefan Pohl Date 2014-01-13 07:33

Stefan Pohl schrieb:

Hallo,

Nachdem nun alle 10 Settings, die ich so aufs Geradewohl entwickelt habe, je 300 Partien gegen Houdini 4 unter LS-Bedingungen gespielt haben, gab es 9 Enttäuschungen (Score war unter dem Endergebnis vom default-Stockfish 140106 gegen Houdini 4 (47.05%)). Einzige Ausnahme war ausgerechnet das Setting, bei dem nur der Contempt Factor auf +50 (also das maximale, was überhaupt geht) erhöht war und sonst alle Parameter default waren. Dieses Setting lag nach 300 Partien bei 51.5% gegen Houdini 4. Das ist natürlich nur ein sehr wackeliges Ergebnis und eigentlich zu schön, um wahr zu sein. Zudem würde man eigentlich gegen einen stärkeren Gegner (wie Houdini 4) ein eher schwächeres Ergebnis erwarten, wenn man den Remisfaktor so hoch ins Plus setzt.
Dennoch - oder gerade deswegen - habe ich nun mal einen echten LS-Testrun mit dieser Einstellung gestartet, da ja alle anderen 9 Gegner des LS-top10-tournaments mittlerweile schwächer als Stockfish sind, ergo sollte sich dort ein hoher Remisfaktor tendenziell positiv auswirken.
Zwischenergebnis morgen...Stay tuned!

Stefan

Den LS-Testrun mit Contempt Factor=50 habe ich abgebrochen. Nach 2500 Partien war das Ergebnis praktisch identisch mit den Endergebnis der default-Version. Auch die Remisquote war enttäuschenderweise nur 2% niedriger.
Ich teste jetzt Stockfish 140112. Mal sehen, wie das läuft. Ggf. breche ich das morgen ab, falls kein Plus zu Stockfish 140106 erkennbar ist...

Stefan

By Hauke Lutz Date 2014-01-13 07:50

Warum so pessimistisch? Es gab mehrere Verbesserungen. Ich bin mir sicher, dass H3 eingeholt werden wird.

By Benno Hartwig Date 2014-01-13 08:39

> Mal sehen, wie das läuft. Ggf. breche ich das morgen ab, falls kein Plus zu Stockfish 140106 erkennbar ist...

Natürlich habe ich Verständnis für dieses Vorgehen.
Der Start solch eines Tests ist aber auch zufallsbedingt. Und wenn du prinzipiell die Kandidaten rausnimmst, deren Start unglücklich aussieht, dann wirst du am Ende durchschnittlich schon Resultate erhalten, die etwas besser sind als es der Realität entspricht, oder?

Benno

By Hauke Lutz Date 2014-01-13 08:41

Ich würde mich ernsthaft wundern, wenn H3 nicht überholt wird.. Von daher kein Grund jetzt schon die Flinte ins Korn zu werfen.

By Stefan Pohl Date 2014-01-13 10:35

Benno Hartwig schrieb:

Kommt darauf an wie du "Start" definierst. Bei mir heißt 24 Stunden Testlauf ja ca. 3000 Partien - da sind die meisten anderen Testruns bereits zuende... Wenn ein Erfolgsscore dann nicht wenigstens gleich auf mit dem Endergebnis der Vorgängerversion ist, dann ist es einfach sehr unwahrscheinlich, daß da noch ein Plus am Ende rauskommt. Und da ja in sehr schneller Folge neue Versionen von Stocki released werden, kann ich so einen Test dann schon mal abbrechen, denke ich. Und eben lieber auf eine neue Version warten. Der jetzt laufende Testrun ist ja eine Version, die nur 6 Tage neuer als die zuletzt gelistete Version ist. Und der abgebrochene Testrun war eine Version, die nur 3 Tage neuer war.

Stefan

By Michael Scheidl Date 2014-01-13 14:02

Bei so einer beträchtlichen freiwilligen Leistung kann sich ohnehin keiner beschweren, und ich würde mich auch nicht beschweren wenn Du entschiedest: Max. ein Stockfishtest pro Monat. Stocki des Monats sozusagen.

By Stefan Pohl Date 2014-01-13 15:42

Michael Scheidl schrieb:

Ich habe mich für das System entschieden: Stockfish immer dann testen, wenn sonst im TopBereich nichts anderes zu testen ist. Wenn - wie im Moment - nichts anderes released wird, dann wird Stockfish intensiv getestet. Sobald aber irgendwas anderes im TopBereich kommt (selbst im erweitertem TopBereich (wie Saros oder auch ein neuer Hannibal oder so)), wird diese Engineversion getestet und Stockfish muß warten. Ein starrer Monatsrhythmus hat m.E. wenig Sinn. Außerdem: Was soll ich in der Zwischenzeit testen?

Stefan

By Stefan Pohl Date 2014-01-14 07:23

Stefan Pohl schrieb:

Erfreulicher Zwischenstand: Nach 3200 Partien liegt Stockfish 140112 bei +8 Elo zu Stockfish 140106. Dieses Mal könnte es also reichen, um als erste Engine Houdini 3 im Bullet zu überholen. Aber die Gesamt-Vergleichs-Errorbar ist z.Zt. noch ca. +/-13 Elo und selbst die Einzelerrorbar des Zwischenstandes ist noch +/-8 Elo. Es wäre also als worst-case Szenario denkbar, daß sich die +8 Elo noch komplett verflüchtigen oder sogar ein leichtes Minus rauskommt. Nur noch mal so als Anmerkung, da ja einige das Prinzip der Errorbar leider nicht begreifen können oder wollen. Also alles noch möglich. Auch natürlich, daß sich das Plus noch steigert. Zwei Drittel des Testruns fehlen ja noch. Ergebnis voraussichtlich Donnerstag.
Stay tuned!

Stefan

By Patrick Götz Date 2014-01-14 09:20

Zitat:

Erfreulicher Zwischenstand: Nach 3200 Partien liegt Stockfish 140112 bei +8 Elo zu Stockfish 140106.

Stefan

Also...
Stockfish 140106 liegt nach 10.000 Partien bei 3146 Elo.
Stockfish 140112 liegt nach 3.200 Partien bei 3154 Elo.
Da Stockfish ja dazu neigt mit zunehmender Partienzahl nachzulassen wäre es interessant zu wissen wo Stockfish 140106 nach ca. 3.200 Partien lag...

By Stefan Pohl Date 2014-01-14 12:41

Patrick Götz schrieb:

Zitat:

Erfreulicher Zwischenstand: Nach 3200 Partien liegt Stockfish 140112 bei +8 Elo zu Stockfish 140106.

Stefan

Das hatte ich hier gepostet. Zum Glück, daher konnte ich nachschlagen. Bei 3500 Partien lag Stockfish 140106 am höchsten, nämlich so bei 3152 . Danach ging es eben leicht abwärts bis zum Ende (3146).
Aber die Testverläufe sind ja nicht immer identisch bei allen Stockfishen - wär ja auch langweilig. Im Moment steigt nämlich der Score von Stockfish 140112 leicht und liegt momentan (knapp 4100 Partien) bei +10 Elo zu Stockfish 140106, hat also seit heute früh 2 Elo hinzugewonnen. Sieht also gut aus - ca. 3156 LS-Elo (im Moment! noch ist nicht mal Halbzeit). Sollte das so bleiben, wären das ca. +27 Elo zu Stockfish 131223 (also +27 Elo in nur knapp 3 Wochen...).

Stefan

By Stefan Pohl Date 2014-01-15 04:06

Stefan Pohl schrieb:

Patrick Götz schrieb:

Zitat:

Erfreulicher Zwischenstand: Nach 3200 Partien liegt Stockfish 140112 bei +8 Elo zu Stockfish 140106.

Stefan

Guten Morgen. Über Nacht ging der Score leider etwas runter. Nach 6200 Partien liegt Stockfish 140112 jetzt nur noch +6 Elo besser als 140106. Wird also doch knapp mit dem Ein- oder Überholen von Houdini 3. Naja, morgen wissen wir es genau. Wenns mit dieser Version noch nicht klappt, dann bestimmt bald mit einer der folgenden.

Stefan