Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / Leistungsabfall von Stockfish 14.1
1 2 Previous Next  
- - By Thomas Plaschke Date 2021-11-18 10:23
In dieser bekannten Stellung zeigt Stockfish 14.1 ein eklatantes Abfallen der Leistung (Knoten pro Sekunde). Zum Zeitpunkt des Abbruchs der Berechnung waren nur noch 5 von 36 Threads mit 100% Auslastung aktiv.


Engine:
FEN: 3B4/1r2p3/r2p1p2/bkp1P1p1/1p1P1PPp/p1P4P/PPB1K3/8 w - - 0 1

Stockfish 14.1:
8/14  00:00   776k  38.784k  -7,92  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.bxa3 Txa6 6.Lxf6 Ta8 7.axb4 Lxb4
...
19/27  00:01   49.365k  47.330k  -8,83  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.bxa3 Txa6 6.Lxf6 gxf4 7.dxc5 dxc5 8.Lxh4 c4 9.Kd1 bxa3 10.Lg5 f3 11.Le3 Ta8
...
23/43  00:16   818.381k  50.664k  -11,07  1.exf6 exf6 2.Lxf6 axb2 3.c4+ Kxc4 4.Ld3+ Kd5 5.Lxa6 Tc7 6.Ld3 c4 7.Lb1 c3 8.Kd1 gxf4 9.Lxh4 f3 10.Lc2 Tc4 11.Lf2 Lb6 12.Lg6 Tc7 13.Kc2 Te7 14.Kb3 Lxd4 15.g5 Te2 16.h4 b1D+ 17.Lxb1 Tb2+ 18.Ka4
24/45+  00:37   1.911.749k  51.546k  -9,43  1.c4+
24/45  00:37   1.912.414k  51.543k  -10,67  1.c4+ Kxc4 2.exf6 exf6 3.Lxf6 axb2 4.dxc5 Kxc5 5.Kd3 b3 6.Ld4+ Kc6 7.axb3 Txb3+ 8.Ke4 b1L 9.Lxb1
...
31/34  00:40   2.076.231k  51.385k  -11,34  1.c4+ Kxc4 2.exf6 exf6 3.Ld3+ Kd5 4.Ke3 cxd4+ 5.Kf3 b3 6.Lxa6 Tb8 7.bxa3 bxa2 8.Lxa5 a1D 9.Lb4 Dh1+ 10.Kf2 Dh2+ 11.Kf1
32/27  00:43   2.244.037k  51.195k  -11,34  1.fxg5 Lxd8 2.g6 e6 3.b3 cxd4 4.Ld3+ Kb6 5.exf6 Lxf6 6.cxb4 d5 7.g5 Lxg5 8.b5 Ta8 9.Kf3 e5 10.Kg4
33/25  00:59   3.047.289k  50.986k  -11,34  1.exf6 exf6 2.Lxf6 axb2 3.cxb4 d5 4.bxa5 Txf6 5.a6 Te7+ 6.Kd3 Txf4 7.Kc3 Txd4 8.Kxb2 Kxa6 9.Kc3 Te3+ 10.Kb2
34/22  01:01   3.138.615k  50.995k  -11,34  1.c4+ Kxc4 2.exf6 exf6 3.Lxf6 axb2 4.Ld3+ Kd5 5.Kf3 b3 6.a4 c4 7.Le4+ Ke6 8.Lxg5 d5 9.Lb1 c3 10.Lxh4 c2
...
38/16  01:07   3.435.609k  51.040k  -11,28  1.c4+ Kxc4 2.exf6 exf6 3.Ld3+ Kd5 4.Lxa6 Ta7 5.Lxf6 Txa6 6.bxa3 gxf4 7.g5 c4 8.g6 bxa3
39/19  01:08   3.511.114k  51.037k  -10,96  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.Ld3+ Kd5 5.dxc5 b3 6.a4 dxc5 7.Lxa6 Te7+ 8.Lxe7 b1D 9.Lb7+ Ke6 10.Lc8+ Kxe7
...
43/20  01:15   3.840.656k  51.027k  -10,96  1.exf6 exf6 2.Lxf6 axb2 3.c4+ Kxc4 4.Ld3+ Kd5 5.dxc5 b3 6.axb3 Txb3 7.Lc2 b1D 8.Lxb1 Txb1 9.Lxg5 Tb2+ 10.Kf3
44/33  01:32   4.714.237k  50.874k  -10,96  1.exf6 exf6 2.Lxf6 axb2 3.c4+ Kxc4 4.Ld3+ Kd5 5.dxc5 b3 6.a3 dxc5 7.Lxb2 Te6+ 8.Kf2 c4 9.Lf5 Lb6+ 10.Kf1
45/32  02:42   8.242.456k  50.840k  -11,38  1.exf6 exf6 2.Lxf6 axb2 3.c4+ Kxc4 4.dxc5 Kxc5 5.Lb1 gxf4 6.Lxh4 d5 7.Lf2+ Kc4 8.h4 Te7+ 9.Kf1
46/41  16:10   11.554.728k  11.909k  -11,42  1.exf6 exf6 2.Lxf6 d5 3.Lxg5 b3 4.Lxb3 Te6+ 5.Kd3 c4+ 6.Lxc4+ dxc4+ 7.Kc2 Te2+ 8.Kc1 axb2+ 9.Kb1 Lxc3 10.Lxh4
47/31  1:57:27   30.946.271k  4.391k  -11,58  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.b3 Lxd8 6.Lb5 Kxd4 7.fxg5 Te7+ 8.Kf2 fxg5 9.Kg1 Te1+ 10.Kg2
48/17  1:57:29   30.952.215k  4.391k  -11,58  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.b3 Lxd8 6.Lb5 Kxd4 7.fxg5 Te7+ 8.Kf2 fxg5 9.Kg1
49/29  2:15:07   33.505.383k  4.133k  -11,59  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.b3 Lxd8 6.Lb5 Kxd4 7.Kd2 Te7 8.Lc4 d5 9.La6 gxf4 10.Lb5
50/35  9:30:00   49.201.383k  1.439k  -11,96  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.b3 Txa6 6.Le7 c4 7.fxg5 cxb3 8.gxf6 b2 9.f7 b1D
50/41  9:30:00   49.201.383k  1.439k  -11,58  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.Lxf6 Txa6 6.b3 c4 7.bxc4+ Kxc4 8.Lxg5 b3 9.axb3+ Kxb3
Bester Zug: exf6, Wert: -11,58, Tiefe: 50/41, Dauer: 9:30:00,979, 49.201.382.605 Knoten, 1.439 kK/sek

Die Analyse erfolgte unter Windows 10 mit  Arena 3.51 bei 16 GB für Hashtabellen und Endspieltabellen für 3-6 Steiner.

Kann dieses Verhalten nachvollzogen werden? Kennt jemand die Ursache?

Rätselnd grüßt
Th. Plaschke
Parent - - By Peter Martan Date 2021-11-18 10:41 Edited 2021-11-18 10:45
Ich kann's mit 30 Threads nicht nachvollziehen mit SF 14.1 und auch 16G Hash, es bleiben bei mir, nachdem der Hash voll ist gute 5 Minuten darüber hinaus weiter laufend, die Knoten auf ca. 54000 kn/s stabil, und die CPU- Auslaustung bleibt nahe 100%.
Mein erster Verdacht wäre, dass dein Rechner zu swappen anfängt, kann das sein?

Diese Studie von William Rudolph hat's übrigens sogar ins Wikipedia geschafft:

https://de.wikipedia.org/wiki/Positionelles_Remis
Parent - - By Klaus S. Date 2021-11-18 14:12
Hmm,

Bei Thomas sind es nach 2:40  auch noch 50.840k

nach  16:10   noch  11.909k,  nach  1:57:27  nur noch  4.391k

und zum Schluss  9:30:00   1.439k
Parent - By Peter Martan Date 2021-11-18 14:19 Edited 2021-11-18 14:22
Eben. Natürlich kann auch ein anderer CPU- konsumierender Prozess im Hintergrund laufen, aber das wäre ja wohl erst recht aufgefallen, den Stapelüberlauf vom Arbeitsspeicher merkt man manchmal erst, wenn's so weit ist, dass er mehr und mehr bremst. Bei Windows 10 sind's z.B. oft die vielen svchost- Prozesse, die Speicher fressen und manchmal auch CPU- Leistung, liest da und dort und beobachtet zeitweise auch selbst
Parent - - By Thomas Plaschke Date 2021-11-18 15:43
Nein, es ist keine Hintergrundaktivität für diese "Erscheinung" verantwortlich. Wenn ich längere Analyse laufen lasse, beende ich vorher alle Ressourcen verbrauchenden Anwendungen. Am Ende liefen tatsächlich nur noch 5 Threads mit 100 %. Jeder auf einem anderen Kern. Aber alle anderen logischen CPUs zeigten kein nennenswerte Aktivität. Auch waren keine besonderen Festplattenaktivitäten festzustellen. Nachdem ich Stockfish gestoppt hatte, lief der Rechner im Leerlauf.

>Ich kann's mit 30 Threads nicht nachvollziehen mit SF 14.1 und auch 16G Hash, es bleiben bei mir, nachdem der Hash voll ist gute 5 Minuten darüber hinaus weiter laufend, die Knoten auf ca. 54000 kn/s stabil, und die CPU- Auslaustung bleibt nahe 100%.


Ich habe es auf meinem Rechner mit identischem Ergebnis (erhebliches Abfallen der Knotenleistung) mehrmals probiert. Mit 54 Mn/s sollte nach einer 1/2 Stunde die Tendenz erkennbar sein und nach 2 1/2 Stunden das Ergebnis eindeutig. - So war's auf meinem PC.

Viele Grüße
Th. Plaschke
Parent - - By Peter Martan Date 2021-11-18 20:52 Edited 2021-11-18 21:09
Wieviel RAM hat denn der Rechner insgesamt?
Hast du mal geschaut, wieviele svchost- Prozesse sich im Lauf des Rechnens anhäufen und wieviel Speicher die fressen?
Weiß sonst auch nichts außer Stapelüberlauf,
Parent - - By Thomas Plaschke Date 2021-11-18 22:04
Der Rechner hat 32 GB RAM.

Die svchost-Prozesse sind ein lästiges Übel, mit dem das BS Speicher spart (man mag's nicht glauben). Mit dem Programm werden Dienste gestartet, die als DLL-vorliegen. Die meisten verabschieden sich nach ihrem Start wieder oder dösen im ausgelagerten wie im physischen RAM bis zu ihrer Erweckung. Übrig bleibt nach ihrem Start ihr Starthilfeprogramm, das noch zur Kommunikation mit ihnen gebraucht wird. An den Diensten sollte man sich nur vergreifen, wenn man weiß, was man tut. Ich lasse meistens die Finger davon.
Wenn svchost.exe-Einträge im Taskmanager mal eine hohe CPU-Last zeigen, gibt es dafür einen Grund - den man unmittelbar oder mittelbar selbst verursacht hat (bspw. Einrichtung regelmäßiger Windows-Updates, Drucker-Spooling). Also normalerweise tut svchost nichts und will nur manchmal spielen. Übrigens findet man im Ressourcenmonitor Hinweise zu den Diensten, die zur jeweiligen Instanz von svchost gehört. Der Speicher, den diese Dateien benötigen, kann in die Gigabytes gehen, aber nicht in einer Weise, dass ein 32 GB-System dadurch in die Knie geht. Jedenfalls laufen auf meinem PC keine solchen Dienste. In dem von mir - wiederholt - beobachteten Verhalten von Stockfish würde ich schlicht von keiner Verursachung durch Systemdienste ausgehen.

Ein Stapelüberlauf müsste zum Programmabsturz führen. Aber Stockfish lief ja noch.

Ich lasse die Engine gerade mit 18 Kernen bei 16 MB für Hashtabellen laufen. Nach 16 Minuten keine Schwächen

Viele Grüße
Th. Plaschke
Parent - By Max Siegfried Date 2021-11-18 23:44
Bei mir lastet allein der Chrome Browser manchmal über 32 GB RAM aus.
Parent - - By Peter Martan Date 2021-11-18 23:48 Edited 2021-11-19 00:08
Thomas Plaschke schrieb:

Ein Stapelüberlauf müsste zum Programmabsturz führen. Aber Stockfish lief ja noch.

Also bei mir nicht (Programmabsturz durch Swappen, je nachdem, was man unter Absturz versteht, bis der Bildschirm einfriert, das ist dann schon ein letztes Einknicken der Bedienbarkeit).
Es wird hingegen, was im RAM nicht mehr Platz hat, z.B. Hashtables, auf Speichermedien geschaufelt, man spricht eben von swappen, mit den Festplatten mit Motor hat man das noch gehört, mit den SSDs nicht mehr, aber je mehr RAM ausgelagert wird, desto langsamer wird das System. Man merkt's zuerst bei anderen Programmen an der verzögerten Reaktion auf Maus- und Menübefehle, nachdem man die aber beim Rechnen des Schachprogramms nicht gibt, merkt man's bei dem an der verringerten Knotenzahl. SF nimmt sich ja auch an large pages, was er kriegt, das führt noch früher zu Auslagerungen, soviel ich weiß.

Mehr kann ich dazu aus eigener Erfahrung nicht sagen, Thomas, du hast gefragt, ich hab' einen Vorschlag gemacht, den ich mir als Erklärung vorstellen könnte, 32 G Gesamtspeicher mit 16 G zugewiesenem Hash, die aber mit längerem Rechnen auch mehr werden können, (was bekommst du denn an Arbeitsspeicher- Auslastung angezeigt?) besonders mit avx2-NNUE- Unterstützung, und wenn viel auf die tbs zugegriffen wird, die ja auch als erfolgte Berechnungen abgelegt werden, damit sie nicht immer wieder neu angerechnet bzw. aufgesucht werden müssen, da kann ich mir schon vorstellen, dass mit ein paar Systemprozessen gemeinsam (und gegen die svchost- Prozesse kann man sich eben ohne Eingriffe in die Sicherheit des Betriebssystems nicht wehren) schon swapping passieren könnte.
Was hast du für einen Vorschlag?
Passiert das wirklich nur bei der einen Stellung und nur bei der einen SF 14.1- Installation? Dann würde ich diese Engine in diesem GUI neu installieren, weil wenn's kein systematischer Fehler ist, muss die eine .exe von dem einen GUI aufgerufen die Ursache sein, oder?

Edit: Malware kann's natürlich auch sein und alle möglichen Hardware- Probleme, (besonders thermische Überlastung) aber all das würde sich wohl auch anders als nur beim SF14.1- Arena- Rechnen auf der einen Stellung zeigen, und ich gehe ja davon aus, dass du, ob z.B. die Temperatur zu hoch wird, bereits als Erstes wirst geprüft haben, bedauert jedwede naseweise Einmischung in das, was du selbst am besten über dein System wissen wirst,
Parent - By Thomas Plaschke Date 2021-11-19 01:31
Zurecht sprichst Du die Problematik einer Ferndiagnose an, bei der man das Objekt/Subjekt nicht selbst in Augenschein nehmen kann. Du gehst aber richtig davon aus, dass der PC selbst "unauffällig" seinen Dienst verrichtet (nicht übertaktet, gut gekühlt aktueller Verbrauch für 18 Stockfish-Threads 260 W bei 56° C CPU-Temperatur, 38° C am Mainboard, und 47° C bei den Spannungswandlern, alle Ventilatoren trieseln mit weniger als 600 U/min). Das Gerät läuft unter Last stets stabil.

Swappen mit der Folge eines "unansprechbaren" Systems habe ich seit Windows XP-Zeiten und Single-Core-CPUs nicht erinnerlich. Im Zusammenhang mit Schachprogrammen überhaupt nur bei fehlerhafter Konfiguration. Das soll nicht heißen, dass das nicht aus anderen Gründen vorkommen kann. Auf meinen Windows 7- und Windows 10-PCs jedoch nicht. Bei anderer Gelegenheit habe ich jedoch mal wahrgenommen, dass bei Nutzung der Syzygy-Tabellen freier Speicher der Schach-Engine zugeordnet wird (technisch werden die Tabellen "gemapped" und wie Speicher behandelt - man möge mich eines Besseren belehren, wenn das nicht stimmt). Das ist kein Speicherloch und führt auch nicht zum Swapping, wie Ronald de Man versichert hat.

Leider ist der Zeitaufwand für den Nachvollzug der verschiedenen Erklärungsversuche schwer abzuschätzen und eher als groß zu bezeichnen, wenn man nicht zu früh abgebrochen haben will.

Nachdem ein Leistungsabfall mit 16 MB + Syzygy-Tabellen nach gut 2 Stunden nicht eingetreten ist, aber der Ressourcen-Monitor Stockfish 8 GB Speicher zugeordnet fand, lasse ich gerade SF mit 16 GB für Hashtabellen, aber ohne Syzygy-Tabellen auf die Stellung los. Nach einer halben Stunde ist jetzt kein zusätzlicher Speicherverbrauch festzustellen, jedoch ein geringer Leistungsabfall von knapp 39 Mnps auf 37,5 Mnps bei 18 Threads. Dieser muss nicht an den zu 100 % genutzten Hashtabellen liegen, da bei 16 MB die Mnps-Werte stets stiegen. Bereits nach 20 Minuten, im 50. Halbzug zeigte Stockfish übrigens 1. La4+ an. Nach einer halben Stunde aber immer noch mit einer Bewertung < -8.

Ich lasse das Programm über Nacht laufen und habe Morgen früh hoffentlich neue Erkenntnisse.

Viele Grüße
Th. Plaschke

P.S.: Den Begriff des Stapelüberlaufs kenne ich vom Programmieren. Das Betriebssystem gibt jedem Programm beim Start einen zusätzlichen Speicherbereich: Den Stack, zu deutsch Stapelspeicher. Auf den Beginn dieses Speicherbereichs wird ein Prozessorregister (der Stackpointer) gesetzt. Lokaler Speicher der Programmroutinen bzw. Unterprogramme wird hier abgezwackt, Parameter übergeben und vom Prozessor Rücksprungadressen abgelegt (letzteres ist sehr interessant für Malware). Also ein sehr sensibler Speicherbereich. Wenn das Programm diesen Bereich durch lokalen Speicherbedarf oder rekursive Unterprogrammaufrufe (wie in Schachprogrammen) überbeansprucht hat, kann es zum Stapelüberlauf kommen, der regelmäßig zum Programmabsturz führt. Das zur Erklärung meiner zitierten Bemerkung.
Parent - - By Klaus S. Date 2021-11-19 00:18 Edited 2021-11-19 00:23
Hallo Thomas:

Analysis by Stockfish 14.1:
...
1.exf6 d5 2.Bxe7 b3 3.Bxb3 Re6+ 4.Kf3 axb2 5.Bc2 Bxc3 6.f5 Re1 7.f7 Rbxe7 8.f8Q R7e3+ 9.Kg2
  Schwarz steht klar auf Gewinn: -+ (-10.24)  Tiefe: 31/17   00:01:54  558MN, tb=9065
1.exf6 d5 2.f7 Re6+ 3.Kd1 Rf6 4.Bxa5 Kxa5 5.fxg5 Rxf7 6.g6 Rg7 7.cxb4+ Rxb4 8.bxa3 Rxd4+ 9.Kc1 Rf4 10.Bf5
  Schwarz steht klar auf Gewinn: -+ (-10.25)  Tiefe: 32/19   00:02:06  624MN, tb=9364
1.exf6 d5 2.f7 Re6+ 3.Kd1 Rf6 4.Bxa5 Kxa5 5.fxg5 Rxf7 6.g6 Rg7 7.cxb4+ Rxb4 8.bxa3 Rxd4+ 9.Kc1 Rf4 10.Bf5
  Schwarz steht klar auf Gewinn: -+ (-10.25)  Tiefe: 33/19   00:02:14  660MN, tb=10074
1.exf6 d5 2.f7 Re6+ 3.Kd1 Rf6 4.Bxa5 Kxa5 5.fxg5 Rxf7 6.g6 Rg7 7.cxb4+ Rxb4 8.bxa3 Rxd4+ 9.Kc1 Rf4 10.Bf5
  Schwarz steht klar auf Gewinn: -+ (-10.25)  Tiefe: 34/18   00:02:19  690MN, tb=10283
1.exf6 d5 2.f7 Re6+ 3.Kd1 Rf6 4.Bxa5 Kxa5 5.fxg5 Rxf7 6.g6 Rg7 7.cxb4+ Rxb4 8.bxa3 Rxd4+ 9.Kc1 Rf4 10.Bf5 Rf3
  Schwarz steht klar auf Gewinn: -+ (-10.30)  Tiefe: 35/30   00:03:29  1058MN, tb=26700
1.exf6 d5 2.f7 Re6+ 3.Kd1 Rf6 4.Bxa5 Kxa5 5.fxg5 Rxf7 6.g6 Rg7 7.cxb4+ Rxb4 8.bxa3 Rxd4+ 9.Kc1 Rf4 10.Bf5 Rf3
  Schwarz steht klar auf Gewinn: -+ (-10.38 --)  Tiefe: 36/24   00:04:58  1495MN, tb=48523
1.c4+ Kxc4 2.exf6 e5 3.dxe5 Bxd8 4.fxg5 axb2 5.g6 Bxf6 6.exf6 d5 7.g5 Kc3 8.Bb1 Ra8 9.g7 d4 10.g6
  Schwarz steht klar auf Gewinn: -+ (-10.42)  Tiefe: 36/24   00:06:41  2028MN, tb=77164
1.c4+ Kxc4 2.exf6 e5 3.dxe5 Bxd8 4.fxg5 axb2 5.g6 Bxf6 6.exf6 d5 7.g5 Kc3 8.Bb1 Ra8 9.g7 d4 10.g6
  Schwarz steht klar auf Gewinn: -+ (-10.50 --)  Tiefe: 37/35   00:08:14  2551MN, tb=97650
1.c4+ Kxc4 2.exf6 e5 3.dxe5 Bxd8 4.fxg5 axb2 5.g6 Bxf6 6.exf6 d5 7.g5 Kc3 8.Bb1 Ra8 9.g7 d4 10.g6
  Schwarz steht klar auf Gewinn: -+ (-10.59 --)  Tiefe: 37/42   00:09:30  2979MN, tb=115030
1.exf6
  Schwarz steht klar auf Gewinn: -+ (-10.50 ++)  Tiefe: 37/42   00:10:55  3450MN, tb=135793
1.exf6 d5 2.fxe7 Re6+ 3.Kf3 b3 4.Bb1 bxa2 5.Bxa2 axb2 6.fxg5 Bxc3 7.Bb1 Bxd4 8.g6 Re1 9.Bd3+ c4 10.e8Q+ Rxe8
  Schwarz steht klar auf Gewinn: -+ (-10.38)  Tiefe: 37/42   00:10:55  3452MN, tb=135887
1.exf6 d5 2.fxe7 Re6+ 3.Kf3 b3 4.Bb1 bxa2 5.Bxa2 axb2 6.fxg5 Bxc3 7.Bb1 Bxd4 8.g6 Re1 9.Bd3+ c4 10.e8Q+ Rxe8
  Schwarz steht klar auf Gewinn: -+ (-10.30 ++)  Tiefe: 38/16   00:10:58  3472MN, tb=136691
1.exf6 d5 2.fxe7 Re6+ 3.Kf3 b3 4.Bb1 bxa2 5.Bxa2 axb2 6.fxg5 Bxc3 7.Bb1 Bxd4 8.g6 Re1 9.Bd3+ c4 10.e8Q+ Rxe8
  Schwarz steht klar auf Gewinn: -+ (-10.47 --)  Tiefe: 38/18   00:10:58  3472MN, tb=136691
1.exf6 d5 2.fxe7 Re6+ 3.Kf3 b3 4.Bb1 bxa2 5.Bxa2 axb2 6.fxg5 Bxc3 7.Bb1 Bxd4 8.g6 Ra7 9.Kf4 Ra1
  Schwarz steht klar auf Gewinn: -+ (-10.59)  Tiefe: 38/18   00:10:59  3474MN, tb=136747
1.exf6 d5 2.fxe7 Re6+ 3.Kf3 b3 4.Bb1 bxa2 5.Bxa2 axb2 6.f5 Rbxe7 7.Bxe7 Re1 8.c4+ dxc4 9.f6 Rf1+ 10.Ke3 c3 11.Kd3 Ra1 12.f7
  Schwarz steht klar auf Gewinn: -+ (-10.59)  Tiefe: 39/27   00:11:09  3538MN, tb=138769
1.exf6 d5 2.fxe7 Re6+ 3.Kf3 b3 4.Bb1 bxa2 5.Bxa2 axb2 6.f5 Rbxe7 7.Bxe7 Re1 8.c4+ dxc4 9.f6 Rf1+ 10.Ke3 c3 11.Kd3 Ra1 12.f7
  Schwarz steht klar auf Gewinn: -+ (-10.67 --)  Tiefe: 40/43   00:12:46  4110MN, tb=159543
1.exf6 d5 2.fxe7 Re6+ 3.Kf1 b3 4.Bb1 gxf4 5.axb3 axb2 6.Kg2 Bxc3 7.Kf3 Bxd4 8.Kxf4 Kb4 9.g5 Kxb3 10.Kg4 Re1
  Schwarz steht klar auf Gewinn: -+ (-10.67)  Tiefe: 40/44   00:13:08  4227MN, tb=168366
1.exf6 d5 2.fxe7 Re6+ 3.Kf1 b3 4.Bb1 gxf4 5.axb3 axb2 6.Kg2 Bxc3 7.Kf3 Bxd4 8.Kxf4 Kb4 9.g5 Kxb3 10.Kg4 Re1
  Schwarz steht klar auf Gewinn: -+ (-10.75 --)  Tiefe: 41/44   00:16:57  5560MN, tb=284885
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kd3 Kd7 7.Bc8+ Ke8 8.Bf5 Bxd8 9.exd8Q+ Kxd8 10.fxg5 a1Q 11.g6
  Schwarz steht klar auf Gewinn: -+ (-10.79)  Tiefe: 41/44   00:21:12  7060MN, tb=373243
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kd3 Kd7 7.Bc8+ Ke8 8.Bf5 Bxd8 9.exd8Q+ Kxd8 10.fxg5 a1Q 11.g6
  Schwarz steht klar auf Gewinn: -+ (-10.87 --)  Tiefe: 42/33   00:24:38  8306MN, tb=458740
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kd3 Kd7 7.Bc8+ Ke8 8.Bf5 Bxd8 9.exd8Q+ Kxd8 10.fxg5 a1Q 11.g6
  Schwarz steht klar auf Gewinn: -+ (-10.96 --)  Tiefe: 42/53   00:27:31  9363MN, tb=531345
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kf3 Kd7 7.Bb5+ Rxb5 8.Bxa5 a1Q 9.e8B+ Kxe8 10.fxg5
  Schwarz steht klar auf Gewinn: -+ (-10.96)  Tiefe: 42/53   00:27:33  9372MN, tb=531791
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kf3 Kd7 7.Bb5+ Rxb5 8.Bxa5 a1Q 9.e8B+ Kxe8 10.fxg5
  Schwarz steht klar auf Gewinn: -+ (-10.96)  Tiefe: 43/16   00:27:35  9390MN, tb=533364
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kf3 Kd7 7.Bc4 a1Q 8.Bb5+ Rxb5 9.Bxa5
  Schwarz steht klar auf Gewinn: -+ (-10.96)  Tiefe: 44/17   00:29:19  10020MN, tb=583711
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kf3 Kd7 7.Bc4 a1Q 8.Bb5+ Rxb5 9.Bxa5
  Schwarz steht klar auf Gewinn: -+ (-11.04 --)  Tiefe: 45/34   00:31:54  10991MN, tb=748826
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.fxe7 Rxe7+ 5.Bxe7 Ra8 6.Kd2 a1Q 7.Kc2 Qh1 8.dxc5 Qh2+ 9.Kb1
  Schwarz steht klar auf Gewinn: -+ (-11.04)  Tiefe: 45/34   00:35:52  12437MN, tb=931998
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kd3 Kd7 7.Ke4 Bxd8 8.exd8Q+ Kxd8 9.Bc4 a1Q 10.Bd3
  Schwarz steht klar auf Gewinn: -+ (-11.04)  Tiefe: 46/19   00:38:55  13536MN, tb=1030840
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kd3 Kd7 7.Ke4 Bxd8 8.exd8Q+ Kxd8 9.Bc4 a1Q 10.Bd3
  Schwarz steht klar auf Gewinn: -+ (-11.04)  Tiefe: 47/19   00:42:17  14672MN, tb=1101604
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Kd3 Kd7 7.Ke4 Bxd8 8.exd8Q+ Kxd8 9.Bc4 a1Q 10.Bd3
  Schwarz steht klar auf Gewinn: -+ (-11.12 --)  Tiefe: 48/39   00:48:47  17032MN, tb=1340043
1.exf6 b3 2.axb3 a2 3.Bd3+ Kc6 4.Bxa6 Rxb3 5.fxe7 Rxb2+ 6.Ke3 Kd7 7.Bc8+ Ke8 8.Bf5 Bxd8 9.exd8Q+ Kxd8
  Schwarz steht klar auf Gewinn: -+ (-11.12)  Tiefe: 48/39   00:49:11  17175MN, tb=1361609
1.exf6 d5
  Schwarz steht klar auf Gewinn: -+ (-11.21 --)  Tiefe: 49/39   01:03:26  22320MN, tb=1868383
1.c4+ Kxc4 2.exf6 exf6 3.Bxf6 axb2 4.Bd3+ Kd5 5.Bxa6 Re7+ 6.Bxe7 b1Q 7.Bxg5 Qc2+ 8.Kf3 Qd1+ 9.Kg2
  Schwarz steht klar auf Gewinn: -+ (-11.21)  Tiefe: 49/39   01:19:26  28091MN, tb=2501141
1.c4+ Kxc4 2.exf6 exf6 3.Bxf6 axb2 4.Bd3+ Kd5 5.Bxa6 Re7+ 6.Bxe7 b1Q 7.Bxg5 Qc2+ 8.Kf3 Qd1+ 9.Kg2
  Schwarz steht klar auf Gewinn: -+ (-11.29 --)  Tiefe: 50/41   01:27:40  31049MN, tb=3049106
1.c4+ Kxc4 2.exf6 exf6 3.Bxf6 axb2 4.Bd3+ Kd5 5.Bxa6 Re7+ 6.Bxe7 b1Q 7.Bxg5 Qc2+ 8.Kf3 Qd1+ 9.Kg2
  Schwarz steht klar auf Gewinn: -+ (-11.37 --)  Tiefe: 50/41   01:36:27  34266MN, tb=3793120
1.exf6 exf6 2.c4+ Kxc4 3.Bxf6 axb2 4.Bd3+ Kd5 5.Bxa6 b3 6.Bxb7+ Ke6 7.fxg5 b1Q 8.d5+ Kd7 9.g6
  Schwarz steht klar auf Gewinn: -+ (-11.37)  Tiefe: 50/41   01:45:30  37444MN, tb=4342957
1.exf6 exf6 2.c4+ Kxc4 3.Bxf6 axb2 4.Bd3+ Kd5 5.Bxa6 b3 6.Bxb7+ Ke6 7.fxg5 b1Q 8.d5+ Kd7 9.g6
  Schwarz steht klar auf Gewinn: -+ (-11.37)  Tiefe: 51/17   01:45:31  37451MN, tb=4344490
1.exf6 exf6 2.c4+ Kxc4 3.Bxf6 axb2 4.Bd3+ Kd5 5.Bxa6 b3 6.Bxb7+ Ke6 7.fxg5 b1Q 8.d5+ Kd7 9.g6
  Schwarz steht klar auf Gewinn: -+ (-11.37)  Tiefe: 52/17   01:45:38  37492MN, tb=4350726
1.exf6 exf6 2.c4+ Kxc4 3.Bxf6 axb2 4.Bd3+ Kd5 5.Bxa6 b3 6.Bxb7+ Ke6 7.fxg5 b1Q 8.d5+ Kd7 9.g6
  Schwarz steht klar auf Gewinn: -+ (-11.37)  Tiefe: 53/17   01:46:14  37718MN, tb=4384034
1.exf6 exf6 2.c4+ Kxc4 3.Bxf6 axb2 4.Bd3+ Kd5 5.Bxa6 b3 6.Bxb7+ Ke6 7.dxc5 Kxf6 8.axb3 b1Q 9.fxg5+ Kxg5
  Schwarz steht klar auf Gewinn: -+ (-11.37)  Tiefe: 54/18   02:00:18  42892MN, tb=5698980
1.exf6 exf6 2.c4+ Kxc4 3.Bxf6 axb2 4.Bd3+ Kd5 5.Bxa6 b3 6.Bxb7+ Ke6 7.dxc5 Kxf6 8.axb3 b1Q 9.fxg5+ Kxg5
  Schwarz steht klar auf Gewinn: -+ (-11.45 --)  Tiefe: 55/48   02:01:46  43429MN, tb=5802413
1.exf6 exf6 2.c4+ Kxc4 3.Bd3+ Kd5 4.Bxa6 Ra7 5.Bc4+ Kxc4 6.b3+ Kc3 7.Bxf6 c4 8.Bxg5 cxb3 9.axb3 Kxb3 10.Bxh4
  Schwarz steht klar auf Gewinn: -+ (-11.45)  Tiefe: 55/48   02:03:55  44186MN, tb=6013507
1.exf6 exf6 2.c4+ Kxc4 3.Bd3+ Kd5 4.Bxa6 Ra7 5.Bxf6 Rxa6 6.bxa3 cxd4 7.Bxg5 Ke4 8.axb4 Bxb4 9.Bxh4 Rxa2+ 10.Kd1
  Schwarz steht klar auf Gewinn: -+ (-11.47)  Tiefe: 56/40   02:13:10  47615MN, tb=7015899
1.exf6 d5
  Schwarz steht klar auf Gewinn: -+ (-11.55 --)  Tiefe: 57/50   05:16:46 109920MN, tb=19752197

(,  19.11.2021)

Gesamt: 32GB, 16GB Hash, 3core @3.7GHz    Im Schnitt zw. 5.200 und 5.900 kN/s  also ca. 10x langsamer als dein Testlauf.

Nach Abbruch (letzter Wert  5:16:46)  immer noch 5.750 kN/s, aber Tiefe 57/50 !! (bei dir nach 9:30:00 nur Tiefe 50/41)

Nach 02:13:10 ein kleiner Hänger bis 05:16:46, aber sonst alles klar ...
Parent - By Peter Martan Date 2021-11-19 00:39 Edited 2021-11-19 00:56
Klaus S. schrieb:

Gesamt: 32GB, 16GB Hash, 3core @3.7GHz    Im Schnitt zw. 5.200 und 5.900 kN/s  also ca. 10x langsamer als dein Testlauf.

Naja, und damit dauert's natürlich (vielleicht nicht 10x aber doch direkt proportional) länger, bis der 16G-Hash die 32G RAM überfordern könnte, ist das wirklich unmöglich, dass das passiert, besonders mit viel Prozessorleistung relativ zum RAM?

Daneben ist außer noch unwahrscheinlicheren (weil noch auffälligeren) Hardware- Malware- Problemen eigentlich nur noch die thermische Instabilität etwas Rechenleistung- Abhängiges. Einzelne Kerne fangen halt schon bei 60° an, weniger zu leisten, das macht dann die Gesamt- Temperatur wieder weniger hoch und es schaut im Schnitt ok aus, aber zum Schluss schafft es die Kühlung nur mehr bei relativ wenigen Cores zu gewährleisten, dass sie ihre volle Leistung erreichen. Man müsste sich die Temperaturen der einzelnen Kerne und deren einzelnen GHz- Output anschauen bei genau der einen Engine im einen Anlassfall. Dass sich all das allerdings nicht auch mit anderen NNUE- Engines, anderen GUIs und anderen Stellungen zeigen sollte, das kann ich mir irgendwie nach wie vor nicht vorstellen.
Just my two cents regards
Parent - - By Thomas Plaschke Date 2021-11-19 01:47
Das ist ja interessant! Peter hat ja schon richtigerweise auf die unterschiedlichen Leistungen der beiden Rechner hingewiesen, aber so fällt die unterschiedliche Rechentiefe erst recht auf. Vielleicht ein Parallelisierungsproblem? Andererseits konnte Peter auf seinem Rechner nichts Ungewöhnliches feststellen.

Gerade arbeitet sich mein Rechner wieder an dem Problem ab. Diesmal mit 16 GB aber ohne Endspieltabellen. Nach 50 Hz und fast 47 Mrd. Knoten fand er (bei "falscher" Bewertung) den Lösungszug. Dass nur 18 Threads eingesetzt sind, sollte keine Rolle spielen. Aber nach 30 Minuten rechnet die Stockfish zwar noch (68 Hz) bleibt aber seit über einer Stunde stumm - wie bei dem Hänger auf Deinem Rechner. In meinem ersten Versuch trat das Verstummen nach 2h 15min ein und dauerte bis zum Abbruch über 7 Stunden. Hmm...

Viele Grüße
Th. Plaschke
Parent - - By Peter Martan Date 2021-11-19 08:14 Edited 2021-11-19 08:21
Der Ausdruck Stapelüberlauf war falsch, was ich meine, ist das hier:

https://de.wikipedia.org/wiki/Swapping

Und ich sage dir, dass das bei Langzeit- Rechnen von Hightech- SMP- Anwendungen, die eine hohe Anzahl von Kernen voll auslasten, im Bereich, in dem du zwar freien RAM haben solltest, aber nicht wirklich hast, weil ihn das Betriebssystem anders verwaltet, als das die eine Anwendung gerne hätte, auch schon vorkommt, wenn der Arbeitsspeicher mehr als zur Hälfte voll wird. Ich bemerke bei meinen 128G RAM sowas, wenn ich länger mit 98G standrechnen lasse, drum stelle ich praktisch nie mehr als 65536 Mb Hash für eine einzelne Engine ein und drehe die Syzygys ab, wenn sie nicht wirklich helfen können, (so z.B. auch prinzipiell bei Stellungen, von denen ich schon weiß, dass es Festungen sind, also die tbs- Stellungen zwar angerechnet, aber gar nicht wirklich erreicht werden können, jedenfalls nicht sinnvoller Weise im Sinn des Lösungsweges) trägt ein letztes Mal eigene Beobachtungen zum dem an sich nicht uninteressanten aber nur bedingt Stellungs- und Engine- abhängigen Phänomen bei,
Parent - - By Lothar Jung Date 2021-11-19 08:29
Auf Discord wird das gleiche Problem beschrieben:

„ <@312566876775383051>, I've noticed something else that may or may not help identify the issue with TB use on Windows.  When I run Stockfish or Komodo and if I remember correctly 0.27 and earlier LC0's, and 7 piece TBs,  I can be massively hitting the TB files and my drives containing the windows page file remain inactive.  Windows never paged a memory mapped file to disk which made sense to me since the file is already on disk.  Running Leela 0.28 as I convert training data, I noticed once the TBs start getting accessed, the page file is getting hammered.  Since the machine becomes unstable fairly quickly due to a lack of memory despite showing 80GB free RAM or more, I decided to experiment by increasing my page file size on one drive to 128GB.  That resulted in my machine not becoming unusable within less than an hour, but that drive has massive access during the conversion process.  Not sure if that helps you or not, but other engines like SF do not use the pagefile regardless of how hard they hit the TB.  In fact, until I changed settings a month or two back, those hard drives would power off and go to sleep during analysis with TB hits.  FYI“

Lothar
Parent - - By Peter Martan Date 2021-11-19 08:36 Edited 2021-11-19 08:48
Ja, früher kam das klassische Swappen einerseits öfter vor, man wusste, wenn die Festplatte dauenrd zu rattern anfing, ohne dass man aktiv einen Speicherauftrag gab, dass es Zeit war, die Anwendung zu beenden, manchmal musste man dann schon Minuten- lang warten, bis der Rechner auf den Menübefehl reagierte, wenn man's rechtzeitig machte, blieb er aber in aller Regel immer noch bedienbar, sowas passiert den modernen Rechnern seltener, es kommt aber auch immer noch vor.
Andererseits ist es heutzutage vielleicht wieder häufiger geworden, es ist nur weniger schnell erkenntlich, und es mag etwas damit zu tun haben, dass das Paging und das Swapping von Windows automatisch mehr eingesetzt werden (zwei an sich nützliche Prozesse der Speicherverwaltung, die laut Wiki-Link auch durchaus zusammenarbeiten, vielleicht ist das "Problem" mittlerweile auch mehr das Paging als das Swapping beim Schach, keine Ahnung, aber dass Windows sich gegen zu große Hashtables beim Langzeit- Rechnen "wehrt", sehe ich einfach schon auch.

Edit: Und dass die GPU- gestützten hingegen über ihren NN- Cache, wenn er groß eingestellt ist und lange damit gerechnet wird, den RAM auch ganz schön überfüllen können, das Phänomen kennt man sowieso auch gut mittlerweile. Vielleicht gibt's für NNUE ja auch ein ähnliches Problem? Die tbs haben dabei Relevanz, auch wenn Roland de Man mal gesagt haben soll, das sei nicht so (wann war das?) bei komodo muss man darauf achten, dass man den eigenen MCTS- Hash Rechenzeit- entsprechend richtig limitiert, weil der sonst auch ausufern kann und zum "normalen" Hash zusätzliches draufpackt, wenn man im MCTS- Mode rechnen lässt, alles Phänomene, die's früher so nicht gab, und die automatische Speicherverwaltung von Windows wird (ich wiederhole auch das nochmal, weil ich's selber erst beobachtet habe, als ich mehr drauf geachtet habe) spätestens seit den ausufernden svchost- Prozessen immer "eigener", repetiert
Parent - - By Lothar Jung Date 2021-11-19 08:40
Ich glaube, daß das bei Windows 11 besser ist.
Parent - - By Peter Martan Date 2021-11-19 08:44
Das glaube ich erst, wenn's genug Andere ausprobiert haben.
Parent - By Lothar Jung Date 2021-11-19 10:44
Peter, heißt Du Thomas, Du Ungläubiger.
Parent - - By Volker Göbel Date 2021-11-19 09:45
Wer schnell nach Erscheinen eines neuen Betriebssystems, das auch auf seinem Rechner haben muss, der sollte damit rechnen, erst mal eine Zeit lang ein Betatester zu sein.

Man kann doch wenigstens ein halbes bis ganzes Jahr noch warten, dann hat das neue BS meistens seine Kinderkrankheiten abgelegt, durch erfolgt Updates.

MfG
Parent - By Lothar Jung Date 2021-11-19 10:42
Stimmt schon.

Aber man kann Windows 11 parallel installieren und dann testen.
Aber entsprechende Testveröffentlichungen sind leicht im Internet auffindbar.
Es gibt aber immer noch das AMD Problem.
Für Lc0 spielt Windows keine große Rolle.
Möchte man mehr Performance sollte man Linux ausprobieren.

Grüße

Lothar
Parent - - By Jörg Oster Date 2021-11-19 11:12 Upvotes 1
Sollte das dann aber nicht alle Threads gleichermaßen beeinträchtigen?

Ein Test wäre, nur die 4er oder evtl. auch 5er TBs einzusetzen und zu beobachten, ob dann das gleiche Phänomen auftritt.
Ich glaube aber nicht, dass Ronald de Man sich eventueller Risiken dieser Art nicht bewusst gewesen wäre ...

Ich vermute hier was anderes, was aber wirklich nur Spekulation ist.
Die Stackgröße wurde auf 8 MB erhöht. Bei 32 Threads sind das schon mal 256 MB.
Desweiteren, double extensions. Meiner Meinung nach extremst riskant heutzutage, wo die Engines
ziemlich schnell sowieso zum Teil sehr große Suchtiefen erreichen. Vor allem im Endspiel.
Und die Anhebung der maximal erlaubten Suchtiefe auf 246 Halbzüge.
Das alles im Zusammenspiel verursacht vielleicht Probleme.
Ich denke, es hatte durchaus seinen Grund, dass ein M. Costalba in der Hinsicht immer sehr konservativ war.
Es wäre durchaus mal interessant zu sehen, welche selektive Suchtiefen generell hier erreicht werden.
Zur Zeit gibt es im Code ja die Einschränkung, dies nur für PV nodes zu tun.

Aber ich kenne mich nicht wirklich aus im Thema Speichermanagement der Betriebssysteme.
Ein erfahrener Programmierer könnte hier vielleicht mehr dazu sagen.
Parent - - By Lothar Jung Date 2021-11-19 11:19 Edited 2021-11-19 11:36
Ich würde erstmal das versuchen:

https://www.makeuseof.com/tag/windows-stop-code-memory-management-bsod/

Vor allem aber: Alle unnötigen laufende Programme schließen, auch die im Auto-Start. Wenn nicht nötig, keine 7-Steiner aktivieren. Nebenläufige Tasks, die nicht nötig sind, im Taskmanager deaktivieren. Hash reduzieren.

Lothar
Parent - By Max Siegfried Date 2021-11-19 13:22
Lothar Jung schrieb:

Ich würde erstmal das versuchen:

<a class='ura' href='https://www.makeuseof.com/tag/windows-stop-code-memory-management-bsod/'>https://www.makeuseof.com/tag/windows-stop-code-memory-management-bsod/</a>

Vor allem aber: Alle unnötigen laufende Programme schließen, auch die im Auto-Start. Wenn nicht nötig, keine 7-Steiner aktivieren. Nebenläufige Tasks, die nicht nötig sind, im Taskmanager deaktivieren. Hash reduzieren.

Lothar

Ja am besten er schließt alles jedes mal, auch die Auto-Start Programme und am besten er aktiviert auch nicht die 6- und 5-Steiner Syzygy Tablebases und natürlich auch den Hash reduzieren der wer braucht schon Hash, wenn der Mensch selbst alles besser weiß usw.
Am besten man hört ganz mit Schach auf PCs auf, spätestens dann wenn der Rechner nicht mehr anspringt.

Wenn er der einzige mit solchen Problemen ist und diese bei niemand anderem auftreten, dann liegt es an dem Zusammenspiel der Hardware oder er weiß nicht wirklich wie man mit dem PC richtig umgehen, ihn sauber und ordentlich, halten sollte oder er hat etwas verstellt.
Parent - - By Max Siegfried Date 2021-11-19 13:14
Jörg Oster schrieb:

Sollte das dann aber nicht alle Threads gleichermaßen beeinträchtigen?

Ein Test wäre, nur die 4er oder evtl. auch 5er TBs einzusetzen und zu beobachten, ob dann das gleiche Phänomen auftritt.
Ich glaube aber nicht, dass Ronald de Man sich eventueller Risiken dieser Art nicht bewusst gewesen wäre ...

Ich vermute hier was anderes, was aber wirklich nur Spekulation ist.
Die Stackgröße wurde auf 8 MB erhöht. Bei 32 Threads sind das schon mal 256 MB.
Desweiteren, double extensions. Meiner Meinung nach extremst riskant heutzutage, wo die Engines
ziemlich schnell sowieso zum Teil sehr große Suchtiefen erreichen. Vor allem im Endspiel.
Und die Anhebung der maximal erlaubten Suchtiefe auf 246 Halbzüge.
Das alles im Zusammenspiel verursacht vielleicht Probleme.
Ich denke, es hatte durchaus seinen Grund, dass ein M. Costalba in der Hinsicht immer sehr konservativ war.
Es wäre durchaus mal interessant zu sehen, welche selektive Suchtiefen generell hier erreicht werden.
Zur Zeit gibt es im Code ja die Einschränkung, dies nur für PV nodes zu tun.

Aber ich kenne mich nicht wirklich aus im Thema Speichermanagement der Betriebssysteme.
Ein erfahrener Programmierer könnte hier vielleicht mehr dazu sagen.

Dann muss er sich halt 64 oder 128 oder 256 GB RAM gönnen, wenn er eine Stellung bei voller Power stundenlang analysieren lassen möchte.
Am besten auch eine extrem schnelle und 8 TB große SSD verwenden.
Eine schnelle CPU führt nur schneller zum wahrscheinlich dem selben Ergebnis wie eine langsame CPU. Aber wenn man stundenlang eine Stellung analysieren lassen möchte, dann muss man die anderen Komponenten auch anpassen.
Man verbaut schließlich auch keine Flugzeugturbine in einem Smart Fortwo ohne diesen vorher entsprechend anzupassen mit den jeweiligen Komponenten.
Vor allem wenn die nächste CPU noch schneller wird.
Und ob konservativ wirklich besser wäre ist fraglich, zumal sich Stockfish super schnell weiterentwickelt.
Parent - - By Jörg Oster Date 2021-11-19 14:02 Upvotes 1
Max Siegfried schrieb:

Jörg Oster schrieb:

Sollte das dann aber nicht alle Threads gleichermaßen beeinträchtigen?

Ein Test wäre, nur die 4er oder evtl. auch 5er TBs einzusetzen und zu beobachten, ob dann das gleiche Phänomen auftritt.
Ich glaube aber nicht, dass Ronald de Man sich eventueller Risiken dieser Art nicht bewusst gewesen wäre ...

Ich vermute hier was anderes, was aber wirklich nur Spekulation ist.
Die Stackgröße wurde auf 8 MB erhöht. Bei 32 Threads sind das schon mal 256 MB.
Desweiteren, double extensions. Meiner Meinung nach extremst riskant heutzutage, wo die Engines
ziemlich schnell sowieso zum Teil sehr große Suchtiefen erreichen. Vor allem im Endspiel.
Und die Anhebung der maximal erlaubten Suchtiefe auf 246 Halbzüge.
Das alles im Zusammenspiel verursacht vielleicht Probleme.
Ich denke, es hatte durchaus seinen Grund, dass ein M. Costalba in der Hinsicht immer sehr konservativ war.
Es wäre durchaus mal interessant zu sehen, welche selektive Suchtiefen generell hier erreicht werden.
Zur Zeit gibt es im Code ja die Einschränkung, dies nur für PV nodes zu tun.

Aber ich kenne mich nicht wirklich aus im Thema Speichermanagement der Betriebssysteme.
Ein erfahrener Programmierer könnte hier vielleicht mehr dazu sagen.

Dann muss er sich halt 64 oder 128 oder 256 GB RAM gönnen, wenn er eine Stellung bei voller Power stundenlang analysieren lassen möchte.
Am besten auch eine extrem schnelle und 8 TB große SSD verwenden.
Eine schnelle CPU führt nur schneller zum wahrscheinlich dem selben Ergebnis wie eine langsame CPU. Aber wenn man stundenlang eine Stellung analysieren lassen möchte, dann muss man die anderen Komponenten auch anpassen.
Man verbaut schließlich auch keine Flugzeugturbine in einem Smart Fortwo ohne diesen vorher entsprechend anzupassen mit den jeweiligen Komponenten.
Vor allem wenn die nächste CPU noch schneller wird.
Und ob konservativ wirklich besser wäre ist fraglich, zumal sich Stockfish super schnell weiterentwickelt.


Ach Max, oder lieber Magnum, oder doch Tom?
Wie gut, dass du dich auskennst und für alles eine super Lösung parat hast. 
Parent - By Max Siegfried Date 2021-11-19 14:44
Jörg Oster schrieb:

Max Siegfried schrieb:

Jörg Oster schrieb:

Sollte das dann aber nicht alle Threads gleichermaßen beeinträchtigen?

Ein Test wäre, nur die 4er oder evtl. auch 5er TBs einzusetzen und zu beobachten, ob dann das gleiche Phänomen auftritt.
Ich glaube aber nicht, dass Ronald de Man sich eventueller Risiken dieser Art nicht bewusst gewesen wäre ...

Ich vermute hier was anderes, was aber wirklich nur Spekulation ist.
Die Stackgröße wurde auf 8 MB erhöht. Bei 32 Threads sind das schon mal 256 MB.
Desweiteren, double extensions. Meiner Meinung nach extremst riskant heutzutage, wo die Engines
ziemlich schnell sowieso zum Teil sehr große Suchtiefen erreichen. Vor allem im Endspiel.
Und die Anhebung der maximal erlaubten Suchtiefe auf 246 Halbzüge.
Das alles im Zusammenspiel verursacht vielleicht Probleme.
Ich denke, es hatte durchaus seinen Grund, dass ein M. Costalba in der Hinsicht immer sehr konservativ war.
Es wäre durchaus mal interessant zu sehen, welche selektive Suchtiefen generell hier erreicht werden.
Zur Zeit gibt es im Code ja die Einschränkung, dies nur für PV nodes zu tun.

Aber ich kenne mich nicht wirklich aus im Thema Speichermanagement der Betriebssysteme.
Ein erfahrener Programmierer könnte hier vielleicht mehr dazu sagen.

Dann muss er sich halt 64 oder 128 oder 256 GB RAM gönnen, wenn er eine Stellung bei voller Power stundenlang analysieren lassen möchte.
Am besten auch eine extrem schnelle und 8 TB große SSD verwenden.
Eine schnelle CPU führt nur schneller zum wahrscheinlich dem selben Ergebnis wie eine langsame CPU. Aber wenn man stundenlang eine Stellung analysieren lassen möchte, dann muss man die anderen Komponenten auch anpassen.
Man verbaut schließlich auch keine Flugzeugturbine in einem Smart Fortwo ohne diesen vorher entsprechend anzupassen mit den jeweiligen Komponenten.
Vor allem wenn die nächste CPU noch schneller wird.
Und ob konservativ wirklich besser wäre ist fraglich, zumal sich Stockfish super schnell weiterentwickelt.


Ach Max, oder lieber Magnum, oder doch Tom?
Wie gut, dass du dich auskennst und für alles eine super Lösung parat hast. 

Ah fühlst du dich auch verfolgt Jörg oder Ernie oder doch lieber Bernd?
Parent - By Thomas Plaschke Date 2021-11-19 17:02
Hallo Jörg,
der "Nachtlauf" ist beendet: Stockfish 14.1 lief mit 18 Threads und 16 GB Hashtabellen, aber ohne Endspieltabellen.
Engine:
FEN: 3B4/1r2p3/r2p1p2/bkp1P1p1/1p1P1PPp/p1P4P/PPB1K3/8 w - - 0 1

Stockfish 14.1:
8/9  00:00   115k  16.468k  -6,40  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6
9/17  00:00   507k  24.156k  -7,75  1.exf6 e5 2.dxc5 axb2 3.Ld3+ Kxc5 4.Lxa6 Lxd8 5.cxb4+ Kxb4 6.Lxb7
...
34/18  00:31   1.171.612k  36.914k  -11,15  1.exf6 exf6 2.Lxf6 axb2 3.Lxg5 bxc3 4.Lxh4 c4 5.Lb1 Ta8 6.Lf6 Te8+ 7.Le5 dxe5 8.dxe5 Td7 9.Le4 Td2+ 10.Ke3
35/21  00:33   1.229.964k  36.980k  -10,65  1.exf6 exf6 2.Lxf6 axb2 3.Lxg5 bxc3 4.Lxh4 c4 5.Lb1 d5 6.Kf3 Lb6 7.g5 Lxd4 8.g6 Kc5 9.f5 Ta3 10.Kg4
36/60  01:43   3.842.752k  37.033k  -11,19  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.fxg5 Lb6 6.g6 Txa2 7.Kf3 Kc4 8.Lxh4 b3 9.Lf5 Ta1 10.Ke2 b1D 11.Lxb1
37/16  01:43   3.842.785k  37.033k  -11,19  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.fxg5 Lb6 6.g6 Txa2 7.Kf3 Kc4 8.Lxh4 b3
38/16  01:43   3.842.860k  37.033k  -11,19  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.fxg5 Lb6 6.g6 Txa2 7.Kf3 Kc4 8.Lxh4 b3
39/16  01:43   3.843.652k  37.033k  -11,19  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.fxg5 Lb6 6.g6 Txa2 7.Kf3 Kc4 8.Lxh4 b3
40/16  01:43   3.845.958k  37.033k  -11,19  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.fxg5 Lb6 6.g6 Txa2 7.Kf3 Kc4 8.Lxh4 b3
41/16  01:44   3.871.246k  37.034k  -11,19  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.fxg5 Lb6 6.g6 Txa2 7.Kf3 Kc4 8.Lxh4 b3
42/35  01:46   3.935.857k  37.033k  -11,19  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.fxg5 Lb6 6.g6 Txa2 7.Kf3 Kc4 8.g7 Tb8 9.Lxh4 Ta1 10.Lh7 b1D 11.Lxb1 Txb1
43/16  01:48   4.018.710k  37.058k  -11,19  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.fxg5 Lb6 6.g6 Txa2 7.Kf3 Kc4 8.g7 Tb8
44/52  01:54   4.256.327k  37.121k  -11,19  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.Lb1 gxf4 6.Lxh4 b3 7.g5 bxa2 8.Lxa2 Tb3 9.Lf2+ Kc4 10.Lb1 Txh3 11.g6
45/38  03:16   7.361.443k  37.518k  -11,56  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 Kxc5 5.Lb1 gxf4 6.Ld3 Ld8 7.Lxd8 Ta3 8.Lxh4 f3+ 9.Kd1 Txd3+ 10.Kc2
46/39  05:20   12.134.377k  37.879k  -11,68  1.exf6 exf6 2.c4+ Kxc4 3.Lxf6 axb2 4.dxc5 b3 5.Lxb3+ Txb3 6.axb3+ Kxb3 7.Lxb2 Kxb2 8.cxd6 gxf4 9.Kf3 Txd6 10.g5
47/41  10:10   23.541.936k  38.580k  -12,38  1.exf6 exf6 2.Lxf6 axb2 3.cxb4 d5 4.fxg5 Te6+ 5.Kf3 cxb4 6.Le5 Tc6 7.Ld3+ Ka4 8.Kf4 b3 9.axb3+ Txb3 10.Lb1
48/40  12:51   30.007.882k  38.882k  -12,58  1.exf6 exf6 2.Lxf6 axb2 3.fxg5 d5 4.dxc5 bxc3 5.Kd3 Te6 6.Lxc3 Lxc3 7.c6 Kxc6 8.Kxc3 Kc5 9.Lb1
49/17  13:18   31.089.705k  38.923k  -12,58  1.exf6 exf6 2.Lxf6 axb2 3.dxc5 bxc3 4.Kd3 gxf4 5.c6 Txc6 6.Lxh4 Ka6 7.Lg5 b1D 8.Lxb1 Txb1 9.Lxf4
50/37+  20:02   46.784.996k  38.920k  -10,49  1.La4+
50/37+  20:02   46.798.732k  38.920k  -8,40  1.La4+
50/62  20:04   46.867.755k  38.917k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Ke1 Ta8 8.Kd2 Kf8 9.Ke2 Taa7 10.Kd2 Kg7 11.Kc1 Tb6 12.Kd1
51/18  20:04   46.870.141k  38.916k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Ke1 Ta8 8.Kd2 Kf8 9.Ke2 Taa7
52/20  20:04   46.871.640k  38.916k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Kd2 Ta8 8.Ke3 Kf8 9.Kd3 Taa7
53/18  20:04   46.878.355k  38.916k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Kd2 Ta8 8.Ke3 Kf8 9.Kd3 Taa7
54/18  20:09   47.074.320k  38.907k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Kd2 Ta8 8.Ke3 Kf8 9.Kd3 Taa7
55/66  20:12   47.162.917k  38.906k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Kd2 Ta8 8.Ke3 Kf8 9.Kd3 Taa7 10.Kd2 Kg7 11.Kc1 Ta6 12.Kb1 Ta8 13.Kc1 Taa7 14.Kc2 Tb8 15.Kd1 Tc8 16.Kd2
56/19  20:14   47.256.044k  38.904k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Kd2 Ta8 8.Ke3 Kf8 9.Kd3 Taa7 10.Kd2
57/19  20:15   47.289.851k  38.905k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Kd2 Ta8 8.Ke3 Kf8 9.Kd3 Taa7 10.Kd2
58/19  20:50   48.559.010k  38.843k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Kd2 Ta8 8.Ke3 Kf8 9.Kd3 Taa7 10.Kd2
59/60  20:56   48.780.258k  38.834k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lc7 7.Kf3 Taa7 8.Kf2 Kf8 9.Kf1 Ta6 10.Kf2 Ta8 11.Kg2 Tbb8 12.Kf2 Lxd8 13.Ke2 Ta6 14.Kd3 Tbb6 15.Ke2 Kg7 16.Kf1 Tb7 17.Kg1
...
68/27  30:06   68.011.506k  37.650k  -8,39  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Kd2 Ke8 8.Kd3 Ta8 9.Kc2 Taa7 10.Kb1 Lb6 11.Kc1 Ta6 12.Kc2 Lc7 13.Kb1 Ta8 14.Kc2
69/54  1:57:08  228.844.112k  32.557k  -7,70  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Tbb6 7.Lxb6 Txb6 8.Kd1 Kf8 9.Kc1 Ta6 10.Kd2 Lc7 11.Ke1 Ke8 12.Kd2
70/65  2:35:49  298.015.804k  31.875k  -8,46  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Ke3 Kxd8 8.Kd2 Taa7 9.Ke3 Ke8 10.Kd2 Ta8 11.Ke1 Ta6 12.Kf1 Taa7 13.Kg2 Kd8 14.Kg1
71/62  2:35:51  298.093.582k  31.875k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tc7 9.Ke2 Td7 10.Kf1 Ta7 11.Kf2 Taa6 12.Ke3 Kb7 13.Kf2 Ta5 14.Kg1
72/17  2:35:51  298.093.602k  31.875k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tc7 9.Ke2
73/17  2:35:51  298.093.620k  31.875k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tc7 9.Ke2
74/17  2:35:51  298.094.143k  31.875k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tc7 9.Ke2
75/17  2:35:51  298.094.159k  31.875k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tc7 9.Ke2
76/17  2:35:51  298.095.497k  31.875k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tc7 9.Ke2
77/17  2:35:52  298.100.679k  31.875k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tc7 9.Ke2
78/17  2:35:53  298.154.866k  31.875k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tc7 9.Ke2
79/17  2:37:55  301.887.232k  31.859k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tc7 9.Ke2
80/32  2:44:42  314.230.882k  31.797k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kf3 Tb5 9.Kf2 Td7 10.Kg2 Ta7 11.Kf3 Kc7 12.Ke2 Ta8 13.Kf2 Tg8
81/46  2:45:49  316.210.685k  31.782k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kd2 Tc6 9.Kc2 Ta7 10.Kc1 Taa6 11.Kc2 Tc7 12.Kd2 Taa7 13.Ke2 Ta5 14.Kf2 Ta6
82/38  2:51:29  326.626.047k  31.742k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Lxb6 Taxb6 8.Kd2 Tc6 9.Kc2 Ta7 10.Kc1 Tb6 11.Kb1 Ta5 12.Ka1 Tb8 13.Kb1 Tb7 14.Ka1 Taa7 15.Kb1
83/54  4:05:08  463.980.886k  31.545k  -8,46  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kxd8 6.f5 Ta8 7.Ke3 Lb6 8.Kf3 Tab8 9.Kg2 La5 10.Kh1 Ke8 11.Kg1 Ta8
84/76  4:05:21  464.371.740k  31.545k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kxd8 6.f5 Td7 7.Ke3 Tc7 8.Kd2 Lb6 9.Ke2 Ke8 10.Kd2 Tca7 11.Ke3 Ta8 12.Kf3 Lc7 13.Kg2 Ta5
85/18  4:05:34  464.798.798k  31.544k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kxd8 6.f5 Td7 7.Ke3 Tc7 8.Kd2 Lb6 9.Ke2 Ke8
86/73  4:05:47  465.197.679k  31.544k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kxd8 6.f5 Td7 7.Ke3 Tc7 8.Kd2 Lb6 9.Ke2 Ke8 10.Kd2 Td7 11.Ke1 Taa7 12.Kd1 Tdb7 13.Kd2 Ta8 14.Ke3
87/18  4:58:55  562.986.102k  31.390k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kxd8 6.f5 Td7 7.Ke3 Tc7 8.Kd2 Lb6 9.Ke2 Ke8
88/72  4:59:40  564.368.973k  31.388k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kxd8 6.f5 Td7 7.Ke3 Kc7 8.Kd2 Lb6 9.Ke2 Kc8 10.Kd1 Ta8 11.Kd2 Kb8 12.Kc1 Tc7 13.Kd1 Ka7 14.Ke1 Tac8 15.Kf1 Td8
89/82  5:18:30  599.413.589k  31.366k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kxd8 6.f5 Td7 7.Ke3 Kc7 8.Kd2 Ta8 9.Ke2 Kc8 10.Kd3 Lb6 11.Kd2 Tb7 12.Kc1 Kc7 13.Kd1
90/42  5:51:02  659.156.727k  31.295k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kxd8 6.f5 Ta8 7.Kd2 Tab8 8.Kc2 Lb6 9.Kb1 Ta8 10.Kc1 Ta4 11.Kc2 Tc7 12.Kb1 Taa7 13.Kc2 Tab7
91/72  5:57:22  670.868.860k  31.287k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kxd8 6.f5 Tb8 7.Kf1 Tba8 8.Kg1 Ke8 9.Kf2 T8a7 10.Ke2 Kf8 11.Kf2 Tb7 12.Ke2 Ld8
92/21-  9:39:51  1.086.542.172k  31.230k  -8,46  1.La4+ Kxa4
92/53+  9:39:53  1.086.614.513k  31.230k  -7,64  1.La4+
92/53  9:39:53  1.086.614.536k  31.230k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lxd8 7.Kd2 Lc7 8.Ke2 Lb6 9.Kd2 Ld8 10.Kd3
93/42  9:40:21  1.087.466.030k  31.229k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lxd8 7.Kd2 Lc7 8.Ke2 La5 9.Kf2 Ld8 10.Kf1 Kb8 11.Ke1 Tba7 12.Kd1 La5 13.Ke2
94/18  10:17:54  1.156.280.834k  31.188k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lxd8 7.Kd2 Lc7 8.Ke2 La5 9.Kf2 Ld8
95/30  10:29:49  1.178.469.161k  31.185k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Ke3 La7 8.Lb6 Lb8 9.Ke2 Td7 10.Kf2 Txb6 11.Ke1 Lc7 12.Kf1 Ta6 13.Kg1 Kb7 14.Kf1 Ta5
96/66  13:48:52  1.534.572.201k  30.856k  -7,64  1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Lb6 7.Ke3 La7 8.Lb6 Lb8 9.Ke2 Td7 10.Kf2 Txb6 11.Ke1 Lc7 12.Kd2 Tb8 13.Kd3 Tb7 14.Kc2 Ta7 15.Kd1 Ta8 16.Kc2 Ta5 17.Kd1 Td8 18.Kd2 Te8
Bester Zug: La4, Wert: -7,64, Tiefe: 96/66, Dauer: 11:15:52,620, 1.534.572.200.775 Knoten, 30.856 kK/sek
Schließlich wurde der Lösungszug gefunden! Die Knotenleistung ist dabei um rund 20 % von ca. 39 Mnps auf kaum 31 Mnps gefallen, blieb dann aber für Stunden auf diesem Niveau stabil. Hintergrundprozesse - von Dauer - liefen meines Wissens nicht. Stockfish hat laut Ressourcenmonitor auch keinen zusätzlichen Hauptspeicher abgefordert und das System noch ca. 12 GB zur freien Verfügung. Bemerkenswert sind noch die "Tiefenschübe" ab 20:02 und 2:35:49. Da "raste" Stockfish plötzlich in die Tiefe.

Im letzten Versuch habe ich SF 14.1 mit 36 Threads, 3-6 Steinern und 16 GB Hashtabellen erneut ausprobiert. Aber vorher hatte ich die Auslagerungsdatei "abgeschaltet", die sonst 4-5 GB groß war.
Engine:
FEN: 3B4/1r2p3/r2p1p2/bkp1P1p1/1p1P1PPp/p1P4P/PPB1K3/8 w - - 0 1

Stockfish 14.1:
8/11  00:00   698k  41.050k  -8,07  1.exf6 e6 2.dxc5 Lxd8 3.Ld3+ Ka5 4.cxd6 axb2
...
38/20  00:43   2.251.580k  51.887k  -11,61  1.exf6 exf6 2.Lxf6 d5 3.fxg5 Te6+ 4.Le5 axb2 5.cxb4 Kxb4 6.Kd3 c4+ 7.Ke2 Ka3 8.g6 Kxa2
39/16  00:45   2.342.347k  51.901k  -11,53  1.exf6 exf6 2.Lxf6 d5 3.Lxg5 b3 4.Lxb3 axb2 5.Lc2 c4 6.Kd2 Kc6 7.Le7 Txe7 8.La4+ Kd6
40/38  00:51   2.650.619k  51.759k  -10,88  1.exf6 exf6 2.Lxf6 d5 3.Lxg5 b3 4.Lxb3 axb2 5.Lc2 c4 6.a4+ Kc6 7.Lxh4 Tb3 8.g5 Txc3 9.Lg6 Td3 10.Le8+ Kd6
...
43/17  01:45   5.415.848k  51.307k  -11,53  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.bxa3 Txa6 6.Le7 c4 7.a4 b3 8.axb3 cxb3 9.fxg5
44/30  02:48   8.572.982k  51.022k  -11,61  1.c4+ Kxc4 2.exf6 exf6 3.Lxf6 axb2 4.dxc5 Kxc5 5.Kf2 d5 6.Lxg5 Lb6 7.Lf6 Txa2 8.Kf3 Ta3+ 9.Ke2 Kc4 10.Lxb2
...
48/19  14:19   44.945.099k  52.270k  -12,69  1.c4+ Kxc4 2.Ld3+ Kxd4 3.exf6 c4 4.Lb1 e5 5.f7 Txf7 6.Lxg5 axb2 7.Lxh4 exf4 8.g5 f3+ 9.Kf2 Lb6 10.g6
49/76  34:07  108.605.591k  53.037k  -13,15  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.bxa3 Txa6 6.fxg5 Lxd8 7.g6 Ta7 8.dxc5 dxc5 9.g5
50/19  34:20  109.268.674k  53.041k  -13,15  1.exf6 exf6 2.Lxf6 axb2 3.fxg5 d5 4.c4+ Kxc4 5.Ld3+ Kc3 6.Lxa6 b1D 7.Lxb7 cxd4 8.g6 Dxg6 9.Lxd4+ Kxd4 10.Kf2
51/17  34:24  109.519.765k  53.042k  -13,15  1.exf6 exf6 2.Lxf6 axb2 3.fxg5 d5 4.c4+ Kxc4 5.Ld3+ Kc3 6.Lxa6 b1D 7.Lxb7 cxd4 8.g6 Dxg6 9.Lxd4+ Kxd4
52/41  40:27  128.668.538k  52.996k  -13,17  1.c4+ Kxc4 2.exf6 exf6 3.Ld3+ Kd5 4.Lxa6 Ta7 5.bxa3 Txa6 6.Lxf6 c4 7.axb4 Lxb4 8.Lxg5 Txa2+ 9.Kf3 Le1 10.Lf6 c3
...
58/38  1:35:38  301.423.132k  52.529k  -13,42  1.c4+ Kxc4 2.exf6 exf6 3.Ld3+ Kd5 4.Lxa6 Ta7 5.Ld3 Lxd8 6.Kd2 Kxd4 7.bxa3 Txa3 8.Lh7 gxf4 9.Kc2 Txa2+ 10.Kb3 Ta3+ 11.Kc2
57/28  1:35:38  301.423.132k  52.529k  -13,25  1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5 4.Lxa6 Ta7 5.fxg5 axb2 6.Ld3 Lxd8 7.g6 c4 8.Lb1 Kxd4 9.Kf3 Te7 10.Kg2 c3 11.Kf2 Tc7 12.a4 bxa3 13.g7 Txg7 14.Lc2 Te7
Bester Zug: exf6, Wert: -13,25, Tiefe: 57/28, Dauer: 1:35:38,964, 301.423.131.716 Knoten, 52.529 kK/sek
Stockfish hat den Lösungszug zwar nicht gefunden, aber mit Endspieltabellen keinen Einbruch der Knotenleistung hinnehmen müssen. Liegt's an der Auslagerungsdatei und Swapping? Um aber so starke Geschwindigkeitseinbußen zu erklären, müsste schon massiv "geswappt" werden. Der Ressourcenmonitor zeigte aber nur sehr geringe Datenmengen im Transfer zur SSD mit der Auslagerungsdatei. Swapping wäre aber eine einfache Erklärung. Mich befriedigt sie aber nicht, weil Windows keinen Speicher auslagert, auf den (häufig) zugegriffen wird. Noch am ehesten wären davon die Hashtabellen betroffen, die den Speicheranforderungen für die gecachten/gemappten Endspieltabellen weichen müssten. Nur vermute ich, dass auf die Speicherbereiche der Hashtabellen viel häufiger zugegriffen wird. Damit wären sie keine Kandidaten für die Auslagerung. Außerdem weiß ich nicht, wie Swapping erklären könnte, dass am Ende des ersten langen Tests von 36 nur noch 5 aktive Threads liefen.

Zu Deinen Überlegungen kann ich leider nichts Fundiertes beitragen. Wenn ich Dich recht verstehe, können tiefe Suchen, wenn sie mit vielen Threads einhergehen, sehr viel Speicher im Zugriff haben, was bspw. Gift für die Prozessor-Caches wäre. In meinem Fall bei 18 oder 36 Threads wäre die Cache-Bank gesprengt.

Meine Weisheit ist hier am Ende. Ich lasse das "Phänomen" mal so (ungelöst) stehen.

Viele Grüße
Th. Plaschke
Parent - - By Thomas Plaschke Date 2021-11-20 17:40
Wie's der Zufall will, wenn man mal Muse hat: Ich habe Stockfish 14.1 mit MS Visual Studio 2019 kompiliert.

Beim Vergleich mit dem Kompilat von mingw 11.2 fiel mir auf, dass das mit dem MS-Compiler erstellt Programm mit einem Thread nach etwas über einer Minute keinen Mucks mehr tat. Wie sich herausstellte, war das Programm abgestürzt. Wenn das Programm mit mehreren Threads lief, stürzte es nur noch schneller ab. Nachdem das Manipulieren an den #defines für die diversen CPUs nicht brachte (die zich Warungen, die der MS-Compiler zudem noch auswarf, verunsicherten zusätzlich), habe ich in den Linker-Einstellungen - eingedenk Deiner Bermerkung an dieser Stelle - die Stackgröße auf 64 MB herauf gesetzt (default 1 MB). - Und siehe da: es läuft!

Ich werde den Wert irgendwann probehalber auf 8 MB heruntersetzen. Fälschlicherweise hatte ich Dich aus diesem Thread mit der Erwähnung von 64 MB als neuer SF-Stackgröße in Erinnerung. Aber ich wäre nie auf die Idee gekommen, dass ein Stapelüberlauf die Ursache sein könnte, hättest Du es hier nicht erwähnt.

Viele Grüße
Th. Plaschke
Parent - - By Jörg Oster Date 2021-11-20 19:23
Interessant.
Selber benutze ich Visual Studio gar nicht.
8 MB sollten reichen, siehe https://github.com/official-stockfish/Stockfish/commit/a858defd332bddd828c9280a9e326a0b750b3dda

Gruß, Jörg.
Parent - By Thomas Plaschke Date 2021-11-20 19:59
Also mit dem 64 MB Stack hat es keinen Absturz gegeben. Ich werde ihn bei Gelegenheit auf 8 MB setzen.
Im SF-Quellcode ist für den MS Compiler auch keine Lösung kodiert worden. Vielleicht ist das auch gar nicht möglich und muss generell über den Linker festgelegt werden. Ich kenne mich damit nicht aus. Aber es läuft ja auch so.

Viele Grüße
Th. Plaschke
Parent - - By Kurt Utzinger Date 2021-11-18 14:30
Thomas Plaschke schrieb:

In dieser bekannten Stellung zeigt Stockfish 14.1 ein eklatantes Abfallen der Leistung (Knoten pro Sekunde). Zum Zeitpunkt des Abbruchs der Berechnung waren nur noch 5 von 36 Threads mit 100% Auslastung aktiv.

Kann dieses Verhalten nachvollzogen werden? Kennt jemand die Ursache?

Rätselnd grüßt
Th. Plaschke


Hallo Thomas
Bei mir - allerdings unter ChessBase 16 - null Abfall der Leistung.
BTW: Kann es sein, dass dieses Problem einzig Critter 1.6a 64-bit
und Crystal 240621 zu lösen imstande sind?
Gruss
Kurt
Parent - - By Peter Martan Date 2021-11-18 14:49
Kurt Utzinger schrieb:

BTW: Kann es sein, dass dieses Problem einzig Critter 1.6a 64-bit
und Crystal 240621 zu lösen imstande sind?

Nein, SugaR AI ICCF 2.50 z.B. kann's auch praktisch sofort, probierte gerade
Parent - - By Kurt Utzinger Date 2021-11-18 15:21
Peter Martan schrieb:

Kurt Utzinger schrieb:

BTW: Kann es sein, dass dieses Problem einzig Critter 1.6a 64-bit
und Crystal 240621 zu lösen imstande sind?

Nein, SugaR AI ICCF 2.50 z.B. kann's auch praktisch sofort, probierte gerade


Danke Peter
Nun habe ich noch Fire 8.NN x64 avx2 gefunden, der die Lösung bis 6.f5= ausspielen würde, allerdings noch immer mit einer viel zu hohen Gewinnbewertung für Schwarz, kurzum richtige Zugfolge aus dem falschen Grund, wobei es ein Rätsel bleibt, dass ein Programm richtig agiert, alles noch opfert und trotz Remis ein Plus von über 7 Bauerneinheiten anzeigt.
Gruss
Kurt
Parent - By Roland Riener Date 2021-11-18 16:46
Hallo Kurt!

Sting 27 zeigt sofort La4+ mit Bewertung - 0,57, kann man gelten lassen.
Texel 1.07 zeigt ebenfalls sofort La4+, allerdings mit Bewertung -5,84. Also ähnlich wie Fire 8 bei dir.

Gruß, Roland
Parent - By Thomas Plaschke Date 2021-11-18 15:31
Vielen Dank, Kurt!

Ich wusste nicht, dass die gute alte Critter-Engine diese Studie löst. Crystal habe ich zu den üblichen Verdächtigen gerechnet, die noch am ehesten mit der Stellung klar kommen. - Auch SugaR AI ICCF. Und natürlich wollte ich wissen, ob Stockfish inzwischen weiß, worum es in der Stellung geht.

Hier geht es mir aber um das eigenartige Suchverhalten von Stockfish. Die Engine scheint inmitten des Suchvorgangs Suchthreads "abzustellen" und kommt irgendwann gar nicht mehr nennenswert "vom Fleck".
Interessant wäre jetzt zu wissen, ob Stockfish 14.1 dieses Verhalten auf anderen Rechnern (speziell anderen Prozessoren) auch zeigt.

Viele Grüße
Th. Plaschke
Parent - - By Markus Pillen Date 2021-11-18 21:21 Upvotes 1
Hallo alle miteinander,
Deep Shredder 12x64 löst die Stellung sofort mit einer Bewertung von -0.30. Er weiß also, dass es remis ist.

viele Grüße
Markus

Line 0.0
3B4/1r2p3/r2p1p2/bkp1P1p1/1p1P1PPp/p1P4P/PPB1K3/8 w - - 0 1

CPU: AMD Ryzen 3750X 12 Core
Analysis by Deep Shredder 12 x64:

1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Kxd8 7.Kf3 Lb6 8.Kg2 Ta5 9.Kf2
  Schwarz hat minimalen Vorteil: = (-0.29)  Tiefe: 10/31   00:00:00
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lxd8 7.Kf3 Tba7 8.Ke4 Ta5 9.Ke3 Kf8 10.Ke2
  Schwarz hat minimalen Vorteil: = (-0.29)  Tiefe: 11/22   00:00:00
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke4 Ta8 9.Ke3 Kc7 10.Ke4 Tg8
  Schwarz hat minimalen Vorteil: = (-0.29)  Tiefe: 12/27   00:00:00
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke4 Ta8 9.Ke3 Kc7 10.Ke4 Tg8 11.Kf3
  Schwarz hat minimalen Vorteil: = (-0.29)  Tiefe: 13/30   00:00:00  2050kN
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke4 Ta8 9.Ke3 Kc7 10.Ke4 Tg8 11.Kf3 Ta7 12.Ke4
  Schwarz hat minimalen Vorteil: = (-0.29)  Tiefe: 14/24   00:00:00  2310kN
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Kf8 7.Kf3 Lxd8 8.Kg2 Ta8 9.Kf2 Lc7 10.Kf3 Tbb8 11.Ke2 Te8 12.Ke3 Kg8
  Schwarz hat minimalen Vorteil: = (-0.29)  Tiefe: 15/30   00:00:00  2868kN
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lxd8 7.Kf3 Tb8 8.Ke4 Ta5 9.Ke3 Lc7 10.Ke2 Kf8 11.Kf3 Tc8 12.Ke4 Kg8 13.Ke3
  Schwarz hat minimalen Vorteil: = (-0.29)  Tiefe: 16/37   00:00:00  3776kN
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Ke8 6.f5 Lxd8 7.Kf3 Tb8 8.Ke4 Ta5 9.Ke3 Lc7 10.Ke2 Kf8 11.Kf3 Tc8 12.Ke4 Kg8 13.Ke3 Lb6 14.Kd3
  Schwarz hat minimalen Vorteil: = (-0.29)  Tiefe: 17/38   00:00:00  5127kN, bb=188
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Tb8 7.Kf2 Lxd8 8.Ke3 Kb7 9.Ke2 Taa8 10.Kf3 Lc7 11.Ke3 Ka6 12.Ke4 Ka5 13.Ke3 Kb6
  Schwarz hat minimalen Vorteil: = (-0.30)  Tiefe: 18/39   00:00:01  8804kN, bb=188
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke2 Tb8 9.Kf3 Taa8 10.Ke4 Kc7
  Schwarz hat minimalen Vorteil: = (-0.30)  Tiefe: 19/44   00:00:01  14884kN, bb=197
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke2 Tb8 9.Kf3 Taa8 10.Ke4 Kc7 11.Ke3 La5
  Schwarz hat minimalen Vorteil: = (-0.30)  Tiefe: 20/46   00:00:02  21663kN, bb=220
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke2 Tb8 9.Kf3 Taa8 10.Ke4 Kc7 11.Ke3 La5 12.Ke4 Kb6 13.Ke3 Ka7 14.Kd3 Lc7
  Schwarz hat minimalen Vorteil: = (-0.30)  Tiefe: 21/46   00:00:03  34803kN, bb=225
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke2 Tb8 9.Kf3 Taa8 10.Ke4 Kc7 11.Ke3 La5 12.Ke4 Kb6 13.Ke3 Ka7 14.Kd3 Lc7
  Schwarz hat minimalen Vorteil: = (-0.30)  Tiefe: 22/53   00:00:08  77956kN, bb=701
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke2 Tb8 9.Kf3 Taa8 10.Ke4 Kc7 11.Ke3 La5 12.Ke4 Kb6 13.Ke3 Ka7 14.Kd3 Lc7
  Schwarz hat minimalen Vorteil: = (-0.30)  Tiefe: 23/47   00:00:12  127MN, bb=793
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke2 Tb8 9.Kf3 Taa8 10.Ke4 Kc7 11.Ke3 La5 12.Ke4 Kb6 13.Ke3 Ka7 14.Kd3 Lc7
  Schwarz hat minimalen Vorteil: = (-0.30)  Tiefe: 24/54   00:00:20  205MN, bb=1114
1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e6+ Kc8 6.f5 Kxd8 7.Ke3 Lb6 8.Ke2 Tb8 9.Kf3 Taa8 10.Ke4 Kc7 11.Ke3 La5 12.Ke4 Kb6 13.Ke3 Ka7 14.Kd3 Lc7
  Schwarz hat minimalen Vorteil: = (-0.30)  Tiefe: 25/51   00:00:49  489MN, bb=2174

(Pillen,  18.11.2021)
Parent - - By Kurt Utzinger Date 2021-11-18 21:47
Markus Pillen schrieb:

Hallo alle miteinander,
Deep Shredder 12x64 löst die Stellung sofort mit einer Bewertung von -0.30. Er weiß also, dass es remis ist.

viele Grüße
Markus

(Pillen,  18.11.2021)




Hallo Markus
Interessant, denn Deep Shredder 13 hat nicht einmal in der Schlussstellung den Durchblick.
Gruss
Kurt

Analysis by Deep Shredder 13 x64:

1. -+ (-14.83): 6...Rb8 7.Ke3 Kc7 8.Ke4 Rf8 9.Kd3 Bb6 10.Ke3 Raa8 11.Ke4 Kd8 12.Kf3 Rc8 13.Ke3 Kc7 14.Kd2 Ra8 15.Ke3 Rab8 16.Ke4 Rfc8 17.Kf3 Ra8 18.Ke3 Rd8 19.Ke4 Rh8 20.Kd3 Kd8 21.Kc2 Ke8 22.Kd2 Kf8 23.Ke2 Rd8 24.Kd3 Ke8 25.Ke3 Rc8 26.Kd3 Kd8 27.Kd2 Kc7 28.Kd3 Ra8 29.Ke3 Kd8 30.Kd3 Rf8 31.Ke3

2. -+ (-14.83): 6...Kc7 7.Kd3 Kb6 8.Ke4 Ra8 9.Ke3 Rh8 10.Kd3 Rbb8 11.Ke3 Rhg8 12.Kd2 Kc7 13.Ke3 Bb6 14.Kf3 Kc8 15.Ke3 Ra8 16.Kf3 Ra5 17.Ke3 Kc7 18.Kd3 Ra7 19.Ke3 Rh8 20.Kf3 Rf8 21.Ke3 Rb8 22.Kd3 Kb7 23.Ke2 Rg8 24.Ke3 Kc7 25.Kd3 Rd8 26.Ke3 Kb7 27.Kf3 Raa8 28.Ke4 Kc7 29.Ke3 Re8 30.Ke4 Rh8 31.Kf3
Black is clearly winning
Parent - By Markus Pillen Date 2021-11-18 21:53
Hallo Kurt,
Da ist bei der 13er Version wohl einiges an Wissen zugunsten der Geschwindigkeit bzw größerer Selektiver Cuts geopfert worden.

Viele Grüße
Markus
Parent - By Max Siegfried Date 2021-11-18 17:52
Eines ist sicher und zwar das 64GB RAM das Problem deutlich hinausgezögert hätten, auch wenn es durch mehr RAM nicht unbedingt dauerhaft beseitigt worden wäre.
Parent - - By Andreas Mader Date 2021-11-19 16:23 Edited 2021-11-19 16:27
Thomas Plaschke schrieb:

Kann dieses Verhalten nachvollzogen werden? Kennt jemand die Ursache?

Rätselnd grüßt
Th. Plaschke


Kannst du es denn selbst nachvollziehen - soll heißen: Lässt sich dieses Verhalten zu hundert Prozent auf deinem Rechner reproduzieren?

Schöne Grüße
Andreas
Parent - - By Thomas Plaschke Date 2021-11-19 17:13
Den Test vom Threadanfang habe ich 3 mal gestartet. Der Leistungsabfall bei den Knoten pro Sekunde zeigte sich jedes Mal.
Die Reduzierung von 36 auf 5 Threads habe ich nur bei einem dieser Tests gesehen, weil ich nur den die Nacht durch laufen ließ - und am Morgen auch nach den aktiven Threads geguckt habe.

Viele Grüße
Th. Plaschke
Parent - - By Andreas Mader Date 2021-11-19 17:48
Thomas Plaschke schrieb:

Den Test vom Threadanfang habe ich 3 mal gestartet. Der Leistungsabfall bei den Knoten pro Sekunde zeigte sich jedes Mal.
Die Reduzierung von 36 auf 5 Threads habe ich nur bei einem dieser Tests gesehen, weil ich nur den die Nacht durch laufen ließ - und am Morgen auch nach den aktiven Threads geguckt habe.

Viele Grüße
Th. Plaschke


Da wir hier ja fleißig am Spekulieren sind, kann ich noch einen Fehler bei den Hash-Tabellen anbieten. Durch das Erzeugen des Hash-Codes geht Information verloren und daher kann es vorkommen, dass ein Hash-Code nicht eindeutig einer Stellung zuordenbar ist - zwei Stellungen haben dann den selben Hash-Code. Das passiert zwar äußerst selten, aber es kann nicht vollkommen ausgeschlossen werden. Da so ein Ereignis nicht vorhersehbare Reaktionen produziert, kann das beobachtete Phänomen eine mögliche Reaktion davon sein. Ich weiß nicht, wie genau der Hash-Schlüssel im konkreten Fall erzeugt wird, aber wenn da auch irgendetwas mit der Konfiguration des Rechners enthalten ist, dann würde das erklären, warum Andere das nicht reproduzieren können.

Schöne Grüße
Andreas
Parent - By Jörg Oster Date 2021-11-19 19:02
Andreas Mader schrieb:

Thomas Plaschke schrieb:

Den Test vom Threadanfang habe ich 3 mal gestartet. Der Leistungsabfall bei den Knoten pro Sekunde zeigte sich jedes Mal.
Die Reduzierung von 36 auf 5 Threads habe ich nur bei einem dieser Tests gesehen, weil ich nur den die Nacht durch laufen ließ - und am Morgen auch nach den aktiven Threads geguckt habe.

Viele Grüße
Th. Plaschke


Da wir hier ja fleißig am Spekulieren sind, kann ich noch einen Fehler bei den Hash-Tabellen anbieten. Durch das Erzeugen des Hash-Codes geht Information verloren und daher kann es vorkommen, dass ein Hash-Code nicht eindeutig einer Stellung zuordenbar ist - zwei Stellungen haben dann den selben Hash-Code. Das passiert zwar äußerst selten, aber es kann nicht vollkommen ausgeschlossen werden. Da so ein Ereignis nicht vorhersehbare Reaktionen produziert, kann das beobachtete Phänomen eine mögliche Reaktion davon sein. Ich weiß nicht, wie genau der Hash-Schlüssel im konkreten Fall erzeugt wird, aber wenn da auch irgendetwas mit der Konfiguration des Rechners enthalten ist, dann würde das erklären, warum Andere das nicht reproduzieren können.

Schöne Grüße
Andreas


Zum Erzeugen des Hashkeys werden keine hardwarebezogenen Daten verwendet,
sondern nur Eigenschaften der jeweiligen Schachstellung.

Sogenannte Hashkollisionen werden ja gerne als Erklärung für alle möglichen Sachen hergenommen,
haben aber eher so gut wie keine Auswirkung in den meisten Programmen.
Züge aus den Hashtabellen werden vor Ausführung auf (Pseudo-)Legalität geprüft.

Gruß, Jörg.
Parent - - By Benno Hartwig Date 2021-11-20 06:46 Edited 2021-11-20 07:06

> Durch das Erzeugen des Hash-Codes geht Information verloren und daher kann es vorkommen, dass ein Hash-Code nicht eindeutig einer Stellung zuordenbar ist - zwei Stellungen haben dann den selben Hash-Code.


Wie ist das an solchen Stellen eigentlich realisiert?
Ich hatte geglaubt, es würde über den Hashwert in die Hashtabelle gegriffen, und dort wäre aber neben der Bewertung auch Information hinterlegt, die  verlässlich dokumentiert, ob die Stellung passt. Es wäre ausgeschlossen, dass mit einem falschen Wert gearbeitet wird.
Ist dies nicht so? Wird einfach frech mit dem Wert gerechnet und wir tun so, als ob es Hashkollisionen gar nicht gäbe?
Gemeinhin widmet man sich, wenn man in anderen Zusammenhängen Hashtabellen nutzt, doch sehr eingehend der Behandlung von Hashkollisionen. Bei Engines nicht???
Parent - - By Olaf Jenkner Date 2021-11-20 10:14 Edited 2021-11-20 10:26 Upvotes 1
Hier ist es erklärt:
https://en.wikipedia.org/wiki/Zobrist_hashing

"assuming that hash collisions will not occur, or will not greatly influence the results of the table if they do. "
Bei einer 64 Bit-Tabelle gibt es 2^64, also 1,8*10^19 verschiedene Möglichkeiten. Da ist es sehr unwahrscheinlich, daß zwei verschiedene Positionen kollidieren.
Falls das doch irgendwo tief im Suchbaum passiert, dann dürfte die Auswirkung kaum bemerkbar sein. Daß es weiter oben passiert, ist noch viel unwahrscheinlicher.
Parent - - By Benno Hartwig Date 2021-11-20 13:42

> Bei einer 64 Bit-Tabelle gibt es 2^64, also 1,8*10^19 verschiedene Möglichkeiten. Da ist es sehr unwahrscheinlich, daß zwei verschiedene Positionen kollidieren.


2^64 Bit sind 2^56 Byte, also mehr als 70000 Tera-Byte.
Da mögen Kollisionen selten sein , aber bei solchen Hashtabellen sind wir bei unseren Engines ja nun doch noch lange nicht!
Parent - - By Olaf Jenkner Date 2021-11-20 14:50
Sind selten, wenn alle 64 Bit gespeichert werden. Ein Teil ist der Index, der Rest muß aber gespeichert und bei einem Treffer auf dem Index verglichen werden. Wenn das nicht passiert, dann gibt es häufig Kollisionen.
Parent - By Benno Hartwig Date 2021-11-20 14:58
Möglicherweise hatte ich dich missverstanden:

Die Hashtable selbst ist sicherlich so klein, dass es in kleineren Installationen und bei längeren Zeiten sicherlich zu ausgesprochen vielen Kollisionen kommen wird.
Daran dachte ich bei meiner Antwort.

Aber man könnte solch einem Eintrag in der Hashtabelle einen größeren Hashwert mitgeben, über den man identifiziert, ob die aktuelle Stellung wirklich hier steht.
An dieser Stelle kann man Fehlinterpretationen natürlich sehr, sehr unwahrscheinlich machen, wenn man beispielsweise 64-Bit-Hashwerte nimmt.
Ich glaube jetzt, das meintest du, und dann hättest du natürlich Recht.
Up Topic Hauptforen / CSS-Forum / Leistungsabfall von Stockfish 14.1
1 2 Previous Next  

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill