Stockfish verliert auf Zeit gegen Gull

By Tom Paul Date 2015-10-09 21:55

Da hoffst du vergeblich.

By Dithyrambus Date 2015-10-09 22:02

Schnacker!

By Ralf Mueller Date 2015-10-09 23:37

Wie kann es denn überhaupt passieren, dass Engines ohne Extrembedenkzeiten auf Zeit verlieren? Da muss doch schon ein größerer Bug vorliegen!?

By Michael Scheidl Date 2015-10-09 23:50

Man spielt mit 150m+30s, da ist klar daß eine Zeitüberschreitung auf einem Programmfehler beruhen muß. Pech für Stockfish, zumal Updates nur zwischen Stages erlaubt sind. Kann passieren, in dieser brutalen Enginekonkurrenz. Daß man in so einem wichtigen Bewerb eine bewährte, verläßliche Version einsetzt statt einer riskanten neuen, ist ein Gedankengang dem sich die zuständigen leider nicht angeschlossen haben.

Gull 3 hat dieses Problem nicht.

By Frank Brenner Date 2015-10-10 01:35

Hier ein Log für den letzten Zug bei dem Stockfish die Zeit um 10ms überschritten hat (Die eingestellte Bedenkzeit war 150min + 30 Sek/Zug)

---------------------------------------

full cutechess log for SF's last move:

At timestamp 117141515 SF receives info that it has 35186 milliseconds on the clock.
At timestamp 117176709 Stockfish makes its move and prints out the time for the move, which is 35196 ms.

SF steps over time by 10 ms (35186 - 35196 = -10)

Best,
Martin (Operator)
--------------------------------------------------------

Mir fallen zwei mögliche Erklärungen ein:

Für alle Erklärungen gilt aber die Tatsache dass SF wohl wirklich nahezu alle zur Verfügung stehenden millisekunden für seinen Zug konsumieren wollte.

Wenn das ganze System unter Windows läuft so kann es sein, dass das Betriebssystem mal eben die Prozesse alle für ein paar ms angehalten hat um auf der SSD aufzuräumen oder um daten vom Cache nachzuladen oder zu speichern.

Die zweite Erklärung: der Windows timer hat nur eine Granularität von 15 ms (auf meinem PC). D.h. wenn ich in einer Schleife den timer messe so messe ich zig tausend mal zb 456ms und plötzlich im nächsten schleifendurchlauf 471ms, obwohl der schleifendurchlauf weniger als ein tausendstel einer ms dauert.

Ich glaube es ist kein Fehler vom letzten Lazy Patch.

By Tom Paul Date 2015-10-10 01:39

Sondern von Windows.

By Dithyrambus Date 2015-10-10 02:13 Upvotes 1

Halt doch mal den mund!
Oder bleibe zumindest bei einer meinung.

http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?pid=95742#pid95742

By Dithyrambus Date 2015-10-10 02:12

Eine sehr plausible deutung!
Danke!

By Benno Hartwig Date 2015-10-10 06:23

Und ich dachte immer, dass die Engines sich eh einen Zeitpuffer einräumen, der verhindert, dass so knappe Überschreitungen passieren.
Hier also so was wie: 0,5 sec für den Zug, der ja immer mind. 30 sec hat.
Lag ich da denn daneben? Passiert das nicht (generell)?

Benno

By Benno Hartwig Date 2015-10-10 06:34 Edited 2015-10-10 06:37

Selbst bei sehr kurzen Zeiten fand ich SF immer sehr stabil.
Für erste Tests mit littleBlitzer gönnte ich den SF-Kompilaten auch mal nur 1s+0,1s
(OK, Sinnhaftigkeit fragwürdig. Es ging aber nur um eine allererste Betrachtung der Auswirkung einer Änderung an den Sourcen: Original vs. kleine Änderung).

Zu Zeitüberschreitungen kam es dann auch bei mehreren Tausend Partien nur sehr vereinzelt.
(wobei: Partienanzahl = Anzahl phys. Kerne)

Benno

By Dirk Triebel Date 2015-10-10 11:01

Es könnte auch mit dem hohen Hash zutun haben. Ich habe auf dem Server festgestellt, dass sich engines vermehrt bei hohem Hash "aufhängen". Es scheint ja hier kein direktes Zeitmanagement Problem vorgelegen haben, bei der Bedenkzeit. Ich denke das Programm hat an einer Stelle overloaded oder was auch immer. Warum das passiert ist, wissen wohl nur die Programmierer und kann man glaube ich nur durch viel testen herausfinden. Wenn es ein größeres Problem ist, werden wir das in den nächsten Partien sehen. Meiner Meinung nach war es auch sehr riskant, eine solche Sonder Version im TCEC einzusetzen. Aber so bleibt es wenigstens spannend:-).

By Frank Brenner Date 2015-10-10 11:33

Das kann durchaus sein.

Wenn zb Windows (warum auch immer) ein Teil vom großen Cache der ja im DDR4 Arbeitsspeicher sich befindet auf die Festplatte auslagert, dann passiert folgendes:
Wenn die Engine auf diesen Bereich zugreift, so bleibt die Engine so lange Eingefroren bis dass Betriebssystem die entsprechende Page (so heissen die Bereiche die auf Platte ausgelagert werden) vollständig von der Festplatte in den DDR4 Arbeitsspeicher zurück kopiert hat. Danach wacht die Engine aus dem Dornröschenschlaf auf und wundert sich dass zb 40ms vergangen sind obwohl scheinbar nur ein DDR4-Speicherzugriff stattgefunden hat der normalerweise vielleicht 10ns = (0,01ms) dauert. (Sehr häufig liegen die daten auch im 1st oder 2nd Level Cache der CPU, dann vergehen nur 0,0001 ms)

Mit Bennos Zeitpuffer kann man so was verhindern. So ein Zeitpuffer stört aber dann im Testframework wo pro Zug 50ms addiert werden. Hier kann man dann schwer einen Zeitpuffer von 500ms ansetzen, vielleicht 15ms. Aber auch dann ist das schon ein schönes stück wenn fast 1/3 der Bedenkzeit reduziert wird. Das Testframework wird diesen patch sicherlich verwerfen ....

Eine Lösung könnte sein, dass der Schiedsrichter bei der Zeitmessung nur zehntelesekunden misst, anstatt tausendstel.

By Benno Hartwig Date 2015-10-11 00:16 Edited 2015-10-11 00:25

Und nun verlor Stockfish bei TCEC schon das 2. Mal auf Zeit!
Beim ersten Mal ging ein halber Punkt verloren!
Und diesmal sogar ein bis dahin sehr tapfer erkämpfter ganzer Punkt!!

Wer wird jetzt der Finale-Gegner von Komodo? Houdini oder Gull?
Oder sollte Stockfish doch noch eine Chance haben? Ich zweifle.
Schon irgendwie Mist so.

Immerhin war die Partie gegen Protector jetzt so spannend wie kaum eine andere.
Zu sehen, wie SF diese Partie recht spät und ganz allmählich zum Sieg hinwendet, ständig mit einer Uhr, die bis dicht an die "0" heranzählt.
Dabei ständig hoffen und bangen. "Wenn SF diese Stage überlebt gibt's bestimmt eine gute Korrektur!"
Und dann so dicht vor dem Sieg doch die Katastrophe (für SF, und möglicherweise auch für diese TCEC-Season-8).

Benno

By Frank Brenner Date 2015-10-11 00:21

Ja, so wie es aussieht hat Martin den Stick selber um seinen Hals gelegt indem er ein riesiges Regelwerk geschrieben hat und jetzt selber über seine eigenen Regeln stolpert.

Denn nun muss sein TCEC darunter leiden, dass Komodo nachher im Finale unglücklich gegen Houdiini oder Gull spielt. Wen interessiert das den noch ?

By Dithyrambus Date 2015-10-11 01:49 Upvotes 1

Frank Brenner schrieb:

Ja, so wie es aussieht hat Martin den Stick (sic!) selber um seinen Hals gelegt [...]

Geht's dir gut? Oder müssen wir uns sorgen machen?
Leute, lest euren auswurf doch nochmal, bevor ihr auf "Schreiben" klickt.

By Wolfgang Battig Date 2015-10-11 02:21 Edited 2015-10-11 02:25 Upvotes 2

Kann Dir nur zustimmen, Horst! So einen Unsinn habe ich selten gelesen. Ein Turnier ist nach Meinung von F.B. offenbar nur etwas wert, wenn das erwartete Finale dabei herauskommt.

Martin, bzw. seine Turnierregeln sind jetzt also "schuld", dass Stockfish vielleicht nicht weiterkommt?? Lächerlich!
Auf die Idee, dass das SF-Team Mist gebaut hat kommt Dein geneigter Vorposter offenbar nicht. Warum schicken sie eine Version, deren Zeitmanagement scheinbar sehr "offensiv" ist? Martin spricht in einer Videobotschaft (https://vid.me/zK5X) selbst von "gambling" des Stockfish-Teams (ca. bei Minute 1:45 des Videos).

In anderen Sportarten sind auch nicht immer Nr.1+2 im Finale. Bestes Beispiel, gerade zu Ende, Darts World Grand-Prix. Im Finale Nr.1 gegen Nr.7 (2-6 waren dabei, alle ausgeschieden). Und dann erdreistet sich die Nr.7 auch noch zu gewinnen. Wirklich unerhört!! Daran sind natürlich der Ausrichter oder die Regeln schuld, nicht die Spieler, die die Felder nicht treffen...

(Wer in diesem Beitrag Ironie findet darf sie behalten)

By Frank Brenner Date 2015-10-11 10:48

Du regst dich ja auf, das war eine art Redewendung.

Das TCEC ist mit der sehr hohen Anzahl an Spielen nicht vergleichbar mit zb einer früheren WM mit nur 6 Runden.

Hier sollten sich die besten zwei Engines qualifizieren.

Jetzt tuts das aber nicht.

Es scheiden sich jetzt die Meinungen darin, zwischen denjenigen die stets und selbstverständlich buchstabengetreu jeden Buchstaben des Regelwerks umsetzen und zwischen denjenigen die möglicherweise das Regelwerk während des Turniers ändern und eine Änderung zugunsten eines einzelnen Teilnehmers zulassen.

Martin gehört nach meinem Wissen zur ersten Gruppe.

Ich selber würde stets das Regelwerk so schreiben, dass der menschliche Turnierdirektor jederzeit jede beliebige Entscheidung treffen darf.

By Dithyrambus Date 2015-10-11 13:12

Siehst du, geht doch!

Gleiche aussage, aber viel freundlicher zu lesen.

By Benno Hartwig Date 2015-10-11 05:54 Edited 2015-10-11 06:33

PS: ("Verwaltungskunst")
Wenn Engines wegen Programmierfehlern abstürzen, dann wird ihnen bei TCEC in den folgenden Partien die Möglichkeit eingeräumt, es mit weniger Threads und mit weniger Hash zu versuchen.
Könnte diese Regel jetzt auch erweitert so ausgelegt werden, dass SF es fortan mit einer etwas kürzeren inneren Zeitvorgabe versuchen darf? "SF: 140 min + 25 sec" oder so?
Dann würde SF wohl wirklich auch in den regulären 150 min + 30 sec fertig werden können.
Ich glaube, auch damit würde SF noch recht sicher das Finale erreichen können.

Oder bliebe dabei zu viel Geschmäckle? "Lex-Stockfish"
Oder lässt sich eventuell auch das System so einfach nicht betreiben?

Benno

By Thomas Plaschke Date 2015-10-11 09:42

>Könnte diese Regel jetzt auch erweitert so ausgelegt werden, dass SF es fortan mit einer etwas kürzeren inneren Zeitvorgabe versuchen darf?

Das könnte ein gangbarer Weg sein. Aber alles, was auf eine neue (korrigierte) Programmdatei hinausläuft, wäre wohl sicher nicht regelkonform und damit Wettbewerbsverzerrung. Andererseits ist die Zeitsteuerung kein Bug im eigentlichen Sinne. Sie funktioniert ja. Es kommt nur leider zu Zeitüberschreitungen, weil das Zeitpolster zu knapp berechnet wird. Richtig rechnen, aber das falsche Ergebnis bringen könnte man aber auch von jeder Bewertungsfunktion sagen, weil sie nicht in jeder Stellung die richtige Bewertung liefert. Wo ist die Grenze?

Viele Grüße
Th. Plaschke

P.S.: Ob die Stockfish-Fanboys aus dem TCEC-Chatwing, die eine neue Stockfish-Binary, die Annullierung oder Remiswertung der auf Zeit verlorenen Partien und wer weiß nicht was sonst noch alles fordern, das genauso laut für jede andere Engine fordern würden? Als sich in Stage 1 einige Programmabstürze ereigneten, war von ihrer Seite oft gefordert, die betroffenen Engines rauszuschmeißen. Wie heißt es: Gerechtigkeit ist gleiches gleich zu behandeln. Aber manche sind eben gleicher.

By Peter Martan Date 2015-10-11 10:11 Edited 2015-10-11 10:14

Hab die Regeln selbst nicht gelesen, aber hier schreibt jemand
http://www.talkchess.com/forum/viewtopic.php?topic_view=threads&p=644611&t=57899&sid=fed81c12a555857a5d60d8b81a16b61c
es dürfe einmal pro Stage bei einem "serious, play limiting bug" nachgebessert werden, wenn's nur den entsprechenden Bug allein betrifft.