Guter SF aus Sourcen vom 3.8.2015 und ein irrer Patch

By Benno Hartwig Date 2015-08-18 21:57 Edited 2015-08-18 22:05

Man muss auch mal eine Gelegenheit nutzen, sich lächerlich zu machen.
Also erzähle ich mal eine wahre Geschichte (und Ungeduldige mögen bitte gleich ans Ende springen):

Vor ein paar Wochen hatte ich hier ja mal meine Idee erwähnt, z.B. in qsearch solche Positionen mit einem Bonus zu belohnen, in denen der zweitbeste Zug nur wenig schlechter als der beste Zug ist. und dann...

Vorspiel:

Ich lud mir am 3.8. die offiziellen Stockfish-Sourcen frisch herunter und bastelte etwas Logik in qsearch ein, kompilierte zunächst mit Visual Studio 2015. Gegen das Kompilat aus unveränderten Sourcen erreichte ich dann auch durchschnittlich ca. 52% Quote.
"Nett!" dachte ich. Aber das VS-Kompilat war immer schnarchig langsam. (OK, das könnte man vermutlich besser hinbekommen)

Mit etwas Hilfe hier im Forum installierte ich dann MinGW und bekam nun so auch Kompilate, die allenfalls ganz wenig langsamer sind als die offiziellen Dev-Stockfishe waren.

Die verschiedenen Versionen, die ich nun bastelte, erreichten in Durchläufen von jeweils gut 1000 Partien gegen das Kompilat aus den Originalsourcen und den letzten
Dev-Stockfish vom 3.8. (stockfish_15073009_x64_modern.exe) immer so zwischen 51% und 54% (also jeweils aus gut 2000 Partien)
OK: ultrakurze 5sec + 0,2s auf einem noch nicht mal fixen i3.

1. Akt:

Nun bekam ich Lust, das doch mal im Fishtest zu sehen.

Zunächst bot mir Hauke an, einen Testlauf zu machen. Bei 16000 Partien gegen diverse Gegner kam aber nur ein verdammt kleiner Fortschritt heraus.
(Thanx noch mal dafür, Hauke)

Aber nun wollte ich mal lernen, wie Github und Fishtest funktioniert, und mit der Hife von Jörg kam das dann schließlich auch ins laufen.
(Natürlich auch dir ein dickes Danke, Jörg)
Zu sehen ist dieser kurz-Test hier
http://tests.stockfishchess.org/tests
mit dem Namen "qsearch_bonus" von "Quapsel" (Qu)
Mühsam erfolgreich war er:

Code:

LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 82097 W: 15678 L: 15355 D: 51064

Aber immerhin.

Ein anderer SF-Bastler, der mich nach meiner Idee fragte, machte mich dann aber auf einen dicken Logikfehler aufmerksam. Dicker, dummer Hund, das. Das Programm machte an dieser Stelle dadurch tatsächlich was ganz anderes als beabsichtigt.

Und: Was hatte ich denn nun eigentlich getestet?...

Zwischenspiel:

Ich korrigierte meine Sourcen und bekam dann ein Programm, welches in meinem häuslichen Test eigentlich ziemlich versagte.

Aber warum waren da vorher Erfolge gewesen?

2. Akt

Nun wollte ich wissen, was meine Fehlentwicklung denn so gut machen konnte, dass doch fast immer eine Quote über 50% herauskommen konnte.
Und so kam ich zu zwei zusätzlich Zeilen, die eigentlich einfach nur irre sind!
Zeilen, die keinen Sinn ergeben, die aus meiner Sicht sogar von die SF gepflegte Erkenntnisse kaputt machen.
Aber dieser SF erspielte immerhin sowas wie (hier nur 1000 Partien):

1 SF_qs_immer1_inv          : 3020  1002 (+266,=532,-204), 53.1 %
    SF_x64m_ori_pb                : 501 (+132,=272,- 97), 53.5 %
    SF_15073009_x64m              : 501 (+134,=260,-107), 52.7 %

Dieses Executable und die Sourcen könnt ihr bei Interesse hier herunterladen:
http://quapsel.bplaced.net/extra/SF_MinGW/Stockfish_20150803-irrerPatch.zip
Eingefügt habe ich nur 3 Zeilen in search.cpp, eingeleitet mit "// irrer Patch"
Enthalten ist ein 64bit-modern.Kompilat mit dem Namen SF_20150803_irrerPatch_x64m.exe

"Entweder ist das alles nur ein Irrtum, zu wenig Partien, oder da muss woanders im SF ein Bug sein, der diesem 'irren Patch' seine Wirkung ermöglicht!" dachte ich mir.

3. Akt

Ich wollte mit aktuellen Sourcen weitermachen.
In den Sourcen, die ich mir am 17.8. herunterlud, schadetet dieser 'irre Patch' dann aber nur.

oder

wie man's nimmt:
"OK, der SF-Fehler wurde wohl behoben, Spuk vorbei!" dachte ich mir. Auch gut!

Aber ich wollte dann doch mal sehen, wie sich meine alte 'irre' SF-Version nun gegen die aktualisierten Sourcen und den aktuellen Dev-Stockfish stockfish_15081513_x64_modern.exe macht.
Heraus kam erstaunlicherweise:

SF_qs_immer1_inv          : 3017  1565 (+432,=812,-321), 53.5 %
    SF-dev_15081513               : 782 (+221,=406,-155), 54.2 %
    SF20150817_ori_pb             : 783 (+211,=406,-166), 52.9 %

Hier sah ich dann, dass mein Virenscanner durchdrehte und allmählich fest auf 25% CPU stand, daher auch einige Verluste auf Zeit.
Ich habe den Rechner dann durchgestartet und LittleBlitzer neu gestartet.
Es ging dann aber lustig weiter mit:

SF_qs_immer1_inv_b        : 3026  2039 (+771,=697,-571), 54.9 %
    SF-dev_15081513               : 1019 (+376,=331,-312), 53.1 %
    SF20150817_ori_pb             : 1020 (+395,=366,-259), 56.7 %

Vorhin setzte ich mal etwas längere Zeiten auf: 30s + 0,3s
Und auch da hat der irre-SF ziemlich gut gestartet:

1 SF_qs_immer1_inv_c        : 3062  741 (+191,=506,- 44), 59.9 %
    SF-dev_15081513               : 370 (+ 94,=256,- 20), 60.0 %
    SF20150817_ori_pb             : 371 (+ 97,=250,- 24), 59.8 %

Der irre-SF bleibt erst mal seiner erfolgreichen Linie treu.
aktuell, bei noch wenigen Partien immerhin annähernd 60%! Und das gegen den aktuellen Dev-Stockfish!
SF_qs_immer1_inv, SF_qs_immer1_inv_b und SF_qs_immer1_inv_c sind dieselben Programme, nur im LittleBlitzer anders benannt.

Gedanken auf nach diesem Opernabend:

Keine Ahnung, warum der "irre Stockfish" (die SF-Sourcen vom 3.8.2015 mit dem irren Patch) erfolgreich ist.

Alles ein Hirngespinst?
Zufall?
Nur ein SF-vs.-SF-Phänomen?
Lächerlich gemacht?

Oper kann Spaß machen!
Zumindest kam mir dieser Ablauf vor wie eine Oper mit einer ziemlich bunten Palette von Effekten und Aha-Erlebnissen.

Vielleicht hat ja jemand von euch Lust, dieses Executable "irrer-Stockfish" mal ein paar Tests zu unterwerfen.
Ist er gegen "eure Gegner" auch erfolgreich? Wie sehr erfolgreich ggf.?
Oder auch gar nicht??
Ich wäre für jede Rückmeldung dankbar!
Hier darum noch mal der Link zu Sourcen und Executable: http://quapsel.bplaced.net/extra/SF_MinGW/Stockfish_20150803-irrerPatch.zip

Grüße an alle Verwunderten
Neugierigen
und Opernfreunde
Benno

By Jörg Oster Date 2015-08-18 22:51

Hallo Benno,

testest du mit PGO-Builds wie im Framework? Für mich ein klares No-Go!
Ich teste lokal nur mit normalen Builds.

Warum sich Lucas Braesch damit (und nicht nur in dieser Sache) durchsetzen konnte,
wird mir auf ewig ein Rätsel bleiben.
Für mich ist der Framework damit ein gutes Stück unzuverlässiger geworden ...

Ich hatte mal den Fall, dass nach einem Patch auf einmal der perft 5% schneller war als vorher!
Obwohl der Patch überhaupt nichts in der Hinsicht geändert haben konnte. Nach dem darauffolgenden Patch
war dann alles wieder normal.

Vielleicht kann der Compiler bei deinem "irren Patch" irgendwas optimieren, was vorher nicht ging.
Hast du mal die Kompilate vom Speed her miteinander verglichen?

Just my 2 cents.

Gruß, Jörg.

By Benno Hartwig Date 2015-08-18 23:08 Edited 2015-08-18 23:19

Im Moment läuft mein wiederaufgesetzer LittleBlitzer und zeigt:

1. SF_qs_immer1_inv_c  239.5/400 102-23-275 (L: m=5 t=0 i=0 a=18)  (D: r=211 i=36 f=13 s=1 a=14) (tpm=656.0 d=17.63 nps=589175)
2. SF20150817_ori_pb    76.0/200 11-59-130  (L: m=15 t=4 i=0 a=40) (D: r=100 i=19 f=5 s=0 a=6)   (tpm=662.4 d=17.06 nps=562771)
3. SF-dev_15081513      84.5/200 12-43-145  (L: m=12 t=1 i=0 a=30) (D: r=111 i=17 f=8 s=1 a=8)   (tpm=664.9 d=17.22 nps=558878)

Meistens sehe ich übrigens, dass der dev-SF etwas höhtete nps-Werte hat als der Compile der Originalsourcen.
Die Bonus-Versionen haben aber stets etwas höhere Werte.

Diese Begegnungen (1 Thread, kein Pondern, 30s + 0,3s) werden die Nacht jetzt auch durchlaufen.
Mal gucken was dort morgen früh steht.

SF-dev_15081513 ist tatsächlich: stockfish_15081513_x64_modern.exe
SF20150817_ori_pb ist der Profile-build der unveränderten Sourcen vom 3.8.2015
SF_qs_immer1_inv_c entstand aus diesen Sourcen ergänzt eben durch den "irren Patch", ebenfalls als profile-build.

Dass jede bonus-Variante, die ich schrieb, etwas höhere nps-Werte zeigte, schiebe ich übrigens nicht auf die Optimierung sondern darauf, dass eine Erhöhung von value hin und wieder auch zu zusätzlichen beta-cuts führt. Frühere und häufigere beta-Cuts bedeuten aber auch, dass eben diese Knoten schneller bearbeitet sind.

Ich wäre nicht auf die Idee gekommen, dass die Nutzung des profile-build in irgendeiner Hinsicht schädlich wäre.
Nur so habe ich EXEs, die nicht den Dev-Kompilaten prinzipiell tempomäßig hinterherlaufen.
Und so bin ich dichter dran an den SFs, die ja am Ende entstehen sollen.

Aber ich könnte natürlich auch mal normale Builds aus den unveränderten und den gepatchten Sourcen erzeugen.

Benno

By Benno Hartwig Date 2015-08-19 09:22 Edited 2015-08-19 09:25

Heute steht es in diesem 30s+0,3s-Spießrutenlauf:

SF_qs_immer1_inv_c        : 3060  2431 (+652,=1639,-140), 60.5 %
    SF-dev_15081513               : 1214 (+324,=816,- 74), 60.3 %
    SF20150817_ori_pb             : 1217 (+328,=823,- 66), 60.8 %

Gut 60% holte der irre-SF (hier heißt er noch "SF_qs_immer1_inv_c" ) sowohl gegen den aktuellen Dev-Stockfish ("SF-dev_15081513" ) als auch gegen das Kompilat aus originalen Sourcen ("SF20150817_ori_pb" ).

Benno

By Thomas Plaschke Date 2015-08-19 10:37

Mein spontaner Übernacht-Test bringt aktuell dieses Ergebnis:

Code:

Games Completed = 915 of 2000 (Avg game length = 126.029 sec)
Settings = RR/256MB/45000ms+400ms/M 500cp for 12 moves, D 150 moves/PGN:10moves_SALC_500.pgn(500)
Time = 29540 sec elapsed, 35029 sec remaining
 1.  SF-BHs-ip                  244.5/459  110-80-269    (L: m=3 t=0 i=0 a=77)  (D: r=186 i=51 f=18 s=5 a=9)  (tpm=983.9 d=23.11 nps=2867602)
 2.  SF150815Dev                237.5/457  104-86-267    (L: m=2 t=0 i=0 a=84)  (D: r=177 i=59 f=15 s=1 a=15)  (tpm=963.3 d=23.16 nps=2883485)
 3.  Komodo 9.1                 204.0/457  90-139-228    (L: m=8 t=0 i=0 a=131)  (D: r=91 i=88 f=21 s=2 a=26)  (tpm=965.9 d=20.79 nps=2824641)
 4.  SF150817-VS                229.0/457  97-96-264    (L: m=5 t=0 i=0 a=91)  (D: r=176 i=42 f=24 s=4 a=18)  (tpm=968.1 d=22.82 nps=2681446)

SF-BHs-ip .....: B enno H artwigs i rrer p atch
SF150815Dev ...: Developement-Version vom 15.08. von abrok.de
Komodo 9.1 ....: Läuft zum Vergleich mit
SF150817-VS ...: Der SF-Code vom 17.08. Compiliert mit Visual Studio 2015 Community. Dürfte etwas langsamer als das VS 2013-Compilat sein und deutlich langsamer als minGW-Versionen.

Verwendet werden außerdem 6-Steiner auf einer SSD.

Laut Elostat sieht die Reihenfolge so aus:

Code:

    Program                          Elo    +   -   Games   Score   Av.Op.  Draws
  1 SF-BHs-ip                      : 3317   20  20   459    53.3 %   3294   58.6 %
  2 SF150815Dev                    : 3310   21  21   457    52.0 %   3297   58.4 %
  3 SF150817-VS                    : 3301   21  21   457    50.1 %   3300   57.8 %
  4 Komodo 9.1                     : 3272   23  23   457    44.6 %   3309   49.9 %

Mit welchem Compiler hats Du Deine SF-BHs-ip-EXE erzeugt? Mit PGO?

Viele Grüße
Th. Plaschke

By Benno Hartwig Date 2015-08-19 12:14

Ja, ich habe das make mit dem profile-build aufgerufen (das ist mit PGO gemeint, richtig?).
Benno

By Benno Hartwig Date 2015-08-19 13:34

Thanx für deinen Test.
Der Erfolg war vielleicht nicht ganz so groß, wie ich es "ankündigte",
aber dass diese eigentlich unsinnige Sourcenänderung überhaupt spürbar erfolgreich sein kann, war wohl nicht zu erwarten gewesen.

Benno

By Jörg Oster Date 2015-08-19 13:59

Benno Hartwig schrieb:

Kann ich so nicht bestätigen.
Zwar nur 300 Partien, 18"+0.08", aber immerhin ...

Code:

Finished game 300 (SF-Master vs SF-Irrer1): 1/2-1/2 {Draw by adjudication}
Score of SF-Irrer1 vs SF-Master: 51 - 49 - 200  [0.503] 300
ELO difference: 2
Finished match

Wie von mir nicht anders erwartet, vermute ich ganz stark,
dass der pgo-build von deinem irren Patch spürbar schneller ist als der andere.
Ich teste wie gesagt nur mit normalen builds.

Hier der Link zu einem Thread im Fishcooking-Forum, wo es genau darum ging.
https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/Ta_lPaKg1oc

By Benno Hartwig Date 2015-08-19 15:42

Ich werde mal einen normalen 64bit-modern-build machen und den wieder bei 30s+0,3s gegen den aktuellen Dev-Stockfish schicken.
Da war der profile-build halt besonders erfolgreich.
Dass der Vorsprung da soo groß war, ist wohl zumindest zum Teil auch dem Zufall geschuldet gewesen.
Allerdings befürchte ich, dass dieser normale build dann gegen den ungebremsten Dev nur mit angezogener Handbremse läuft.
Aber mal gucken...

Vermute ich richtig: Die Devs sind sämtlich und mit wenig Aufwand als profile-build erstellt worden?

Ich bin mir inzwischen übrigens doch nicht mehr sicher, ob dieser Patch nicht doch auch bei den aktuellen Sourcen greift.
Ggf. ließ ich mich da zu schnell entmutigen.
Auch da mal gucken...

Viele Grüße
Benno

By Thomas Plaschke Date 2015-08-19 20:06

Dass pgo-builds eine weitere Ursache für beobachtbares nichtdeterministisches Verhalten von Engines ist, ist mir neu.
Für kurze Bedenkzeiten, um die es bei den Fishtests und "Benno's irren Patch" geht, müsste das ja schnell überprüfbar sein.

Ich schildere zuerst, wie immer, recht ausführlich, wie ich getestet habe.
Ich habe die Bedenkzeiten verschiedener builds genommen. Der Quellcode ist der vom 17.8. Die in der folgenden Tabelle notierten Namen sprechen im Allgemeinen für sich. Allein SF150817 ist das mit VS2015 erzeugte Programm und bei stockfish_15081720-Dev handelt es sich um den build "stockfish_15081720_x64_modern" von abrok.de.
Ich habe mit 4 Versionen des minGW-Compilers vom Stockfish-Quellcode builds mit und ohne profile-guided-optimization erzeugt. Die das makefile und damit die Compiler-flags blieben natürlich jeweils für beide builds unverändert. Getestet wurde mit dem eingebauten Benchmark (Aufruf von der Kommandozeile mit Parameter bench).
Dieser Benchmark wurde von jedem build 100 Mal durchlaufen. Alle builds liefen singlethreaded mit Priorität Realtime auf core 1 meines i5-3970K. Der Prozessor läuft mit ca. 4,4 GHz. Fragen zum Turbo-Modus stellen sich daher nicht.

Code:

                            Mittelwert  rel. Abw.  abs Abw.
SF150817 .................:   3092       103,2%       99

SF150817[473p] ...........:   2797       101,6%       44
SF150817[473p-noPGO] .....:   3005       102,4%       73

SF150817[484p] ...........:   2828       102,2%       63
SF150817[484p-noPGO] .....:   3008       103,8%      113

SF150817[492p] ...........:   2811       101,6%       45
SF150817[492p-noPGO] .....:   3063       102,1%       63

SF150817[510p] ...........:   2845       101,6%       44
SF150817[510p-noPGO] .....:   3041       101,7%       52

stockfish_15081720-Dev ...:   2857       101,5%       42

Wenn übehaupt könnte man festzustellen geneigt sein, dass die Werte von nicht-PGO-builds stärker streuen. Interessant, dass der VS2015-build vergleichweise weit streut. - Und schön zu sehen, dass die pgo-builds von minGW 4.9.2 (stockfish_15081720-Dev und SF150817[492p]) recht nah beieinander liegen.
Allerdings habe ich nicht berechnet, wie stark die Werte streuen. Dazu fehlt mir der statistische Background. Mit genauen Anweisungen ander Foristen lässt sich das ja vielleicht noch bewerkstelligen.

Den Forums-Thread, in dem das nichtdeterministisches Verhalten der pgo-builds erörtert wurde, muss ich noch lesen.
Das zunächst von mir dazu.

Viele Grüße
Th. Plaschke

By Thomas Plaschke Date 2015-08-20 12:28

Zur Ergänzung die Werte für "bench 16 1 17 default depth" - also mit 17 statt der standardmäßigen 13 Hz Rechentiefe:

Code:

                           Mittelwert (ms)  rel. Abw.  abs. Abw.
SF150817.EXE                         21050  100,4%      78
SF150817[473p].EXE                   18920  100,7%     133
SF150817[473p-noPGO].EXE             20266  100,4%      85
SF150817[484p].EXE                   19139  100,7%     139
SF150817[484p-noPGO].EXE             20335  100,6%     131
SF150817[492p].EXE                   19025  100,4%      79
SF150817[492p-noPGO].EXE             20741  100,6%     122
SF150817[510p].EXE                   19224  101,2%     224
SF150817[510p-noPGO].EXE             20571  101,3%     267
stockfish_15081720_x64_modern.EXE    19363  100,5%     101

Der Test mit 9 Hz bringt Ergebnisse in der Größenordnung von einer Drittelsekunde. Die Extremwerte liegen im einstelligen Bereich entfernt von den Mittelwerten. Das ergibt im Durchschnitt auch nur sehr niedrige Abweichungen vom Mittelwert. Ich lasse diesen Test aber hier aus.

Den Test mit 17 Hz finde ich bezogen auf nichtdeterministische Verhaltensweise durch verschieden Arten von builds auch nicht alarmierend.

Viele Grüße
Th. Plaschke

By Frank Brenner Date 2015-08-19 14:00

>1 SF-BHs-ip : 3317 20 20 459 53.3 % 3294 58.6 %
>2 SF150815Dev : 3310 21 21 457 52.0 % 3297 58.4 %

SF-BHs-ip wurde von Benno zuhause compiliert

SF150815Dev wurde von abrok.de compiliert

Um die Versionen besser vergleichen zu können sollte Benno SF150815Dev ebenfalls selber compilieren und zwar mit der gleichen methode mit den gleichen Optionen und alles gleich wie die Version wo seine Änderungen drin sind.
Hierbei ist es nicht empfehlenswert durch lange profiler Läufer jeweils individuell für jeden Sourceode den schnellsten code zu erzeugen (nichtdeterministische compilation), sondern es ist wichtig, dass beide Sourcen gleichwertig d.h. deterministisch compiliert werden.

Es ist durchaus denkbar, dasss der Compiler durch hinzufügen von wenigen zeilen zufällig einen schnelleren Code erzeugt oder dass die cpu den code schneller abarbeitet, weil zb die Branch-Prediction in der Cpu zufällig dann eine größerer Trefferquote produziert. Dies kann man ja durch die nps hinterher feststellen.

By Jörg Oster Date 2015-08-19 10:45

Profile-builds sind nicht schädlich in dem Sinne.
Aber sie sind nun mal nicht deterministisch. D. h. du bekommst jedes Mal
ein unterschiedlich schnelles Kompilat!

By Benno Hartwig Date 2015-08-19 12:27

In welchem Maße schwanken die Kompilatgeschwindigkeiten deiner Erfahrung nach?
Ich hatte das eher als marginal vermutet, kann da natürlich auch daneben liegen.
Ich hatte den Eindruck
normaler build: ca 93% der Geschwindigkeit der dev-SFs
profile-build: ca 98% der Geschwindigkeit der dev-SFs

Außerdem ist es ja schon sinnvoll, schon bei der Entwicklung einen Eindruck zu bekommen, wie schnell die Ausführung am Ende sein wird.
Die Begutachtung der Optimierungsmöglichkeiten erst ganz am Ende käme mir reichlich spät vor.
Ausnahme: Ich tune gerade wirklich an der Geschwindigkeit, feilsche um Prozentbruchteile. Dann mag es anders sein.

Benno