Neues Stockfish Feature in Vorbereitung: Stockfish-universal

By Lothar Jung Date 2026-04-18 12:55 Upvotes 1

Fortschritt bei AVX für optimierte Binaries.

By Olaf Jenkner Date 2026-04-19 14:01

Ich wüßte gerne, wie das funktioniert.
Mit BMI1 ersetzt das Programm x&(x-1) durch BLSR oder kann TZCNT (trailing zero count) nutzen.
Mit ABM kann das Programm z.B. POPCNT nutzen.
Wenn man vor jedem dieser Befehle auf das Vorhandensein der Opcodes prüft, dürfte die
Geschwindigkeit merklich leiden. Man könnte vor größeren Blöcken prüfen, wodurch der
Performanceverlust vernachlässigbar wird. Das widerspricht der Aussage, daß das Binary
kaum größer ist.
Irgendwie scheinen sie zu zaubern.

By Lothar Jung Date 2026-04-19 15:13

https://github.com/official-stockfish/Stockfish/pull/6740

By Andreas Matthies Date 2026-04-19 16:36 Edited 2026-04-19 16:56 Upvotes 2

Das Prinzip ist ganz einfach. Die Prüfung auf die Prozessorfunktionen erfolgt nur einmal direkt beim Start des Programms in der main Funktion. Dort wird dann je nach erkanntem Prozessor in eine "main_bmi2", "main_avx512", ... verzweigt und aus denen dann wiederum ausschließlich die Funktionen der erkannten Prozessorvariante aufgerufen.
Letztendlich hat man alle Binaries parallel in eine einzige verpackt, die Schwierigkeit bestand wohl größtenteils darin, diese Funktionen voneinander unterscheidbar zu machen, indem man beim Linken entsprechende eindeutige Symbole generiert. Ganz verstanden habe ich diesen Mechanismus allerdings noch nicht. Und scheinbar funktioniert das so auch nur mit gcc, für den Clang Compiler hat der Entwickler (noch) keine Idee, wie das umzusetzen wäre.

Die Aussage "kaum größer als ein spezialisiertes Binary" resultiert daraus, dass der Code ja nur einen Bruchteil der Größe der Netzwerkdaten hat, die ja in jedes Binary eingebunden sind. Somit sind selbst 8 Binaries in Summe immer noch ein (etwas größerer) Bruchteil der Netzwerkdaten und fallen dementsprechend kaum ins Gewicht. Hier https://github.com/official-stockfish/Stockfish/releases?q=prerelease%3Atrue kann man sehen, dass das Universal gezippt 67,5MB groß ist, während ein spezielles Binary 66,1MB umfasst.

Gruß, Andreas

By Olaf Jenkner Date 2026-04-19 19:07

Aha, danke.
Dann ist das Ganze nichts wirklich Besonderes.
Wenn der reine Programmcode vielleicht 1 MB in der Binary einnimmt, dann wären mit
den dazugelinkten überflüssigen Sachen eventuell 2 MB notwendig.
Die Innovation scheint mir darin zu bestehen, daß das aus Sicht der Entwickler nun viel
übersichtlcher geworden ist. Und der Anwender erwischt immer die optimale Version,
weil das Programm alles benutzt, was die CPU zu bieten hat.

By Andreas Matthies Date 2026-04-20 06:17

Olaf Jenkner schrieb:

Aha, danke.
Dann ist das Ganze nichts wirklich Besonderes.

Mir ist keine einzige andere Engine bekannt, die ein universal Binary in der beschriebenen Weise anbietet, insofern ist das im besten Wortsinn etwas Besonderes.

Olaf Jenkner schrieb:

Die Innovation scheint mir darin zu bestehen, daß das aus Sicht der Entwickler nun viel
übersichtlcher geworden ist. Und der Anwender erwischt immer die optimale Version,
weil das Programm alles benutzt, was die CPU zu bieten hat.

Den Entwicklern ist es komplett egal, für sie ändert sich gar nichts.
Entscheidend ist, dass der Benutzer automatisch die für seinen Prozessor optimale Version ausführt.
Und ein erfreulicher Nebeneffekt ist, dass sich der Ressourcenbedarf auf den Github-Servern reduziert, sobald die speziellen Versionen nicht mehr hochgeladen werden.
Was ich aus Sicht der Entwickler eigentlich sofort eingestellt hätte, um die Nutzer der Prereleases zur Nutzung und zum Test der Universal zu zwingen.

By Thomas Plaschke Date 2026-04-20 17:02

> Was ich aus Sicht der Entwickler eigentlich sofort eingestellt hätte, um die Nutzer der Prereleases zur Nutzung und zum Test der Universal zu zwingen.

Ich habe es gestern versucht x86-64-universal unter MSys2 zu compilieren - mit ucrt und mingw, nicht mit clang, bin aber gescheitert. Auf konventionelle Weise funktioniert es nach wie vor. Das Problem scheint im makefile zu liegen. Sowohl build als auch profile-build brechen mit Fehlern ab. Eigenartigerweise wird mit ucrt aber das für pgo instrumentierte File erzeugt und ausgeführt. Im Moment scheint es noch nicht ganz fertig.

Viele Grüße
Th. Plaschke

By Andreas Matthies Date 2026-04-20 18:36 Edited 2026-04-20 19:15

Mit msys2/mingw64 funktioniert es bei mir ohne Probleme.
Mit der ucrt64 Umgebung habe ich es noch nicht probiert... edit: auch das build in ucrt64 war jetzt erfolgreich.
Für das profile-build muss man den sde Emulator per RUN_PREFIX= bekannt machen, wie es "make help" auch anzeigt, das normale build sollte aber auch ohne funktionieren.

Vielleicht schreibst du mal, welche Fehler das genau sind, die bei dir auftreten.

Gruß, Andreas

By Thomas Plaschke Date 2026-04-20 21:12

Vielen Dank für die Hinweise und das Angebot!
sde und RUN_PREFIX hatte ich nicht auf dem Plan. Aber sde ist ja schnell heruntergeladen.
Gestartet mit

make clean -j profile-build ARCH=x86-64-universal COMP=mingw RUN_PREFIX="/c/tools/sde/sde -future --"

gibt's lustige Ergebnisse. Beim 2 Lauf werden im Verzeichnis temp_builds die CPU-spezifischen Unterverzeichnisse angelegt. Nur an deren Existenz konnte ich ablesen, ob in RUN_PREFIX der Pfad zur Datei oder der Dateipfad verlangt wurde ("/path/to/sde" ist diesbezüglich nicht eindeutig - unter Windows könnte man sicher identifizieren, wenn mit sde.exe der Dateipfad gemeint ist).

Sowohl mit mingw64 als auch ucrt64 gab es kein gutes Ende:

*** No rule to make target 'universal-object-pgo'.  Stop.

*** [Makefile:1317: C:/Tools/msys64/home/Nutzer/sf260419/src/temp_builds/x86-64-sse41-popcnt/stockfish.o] Error 2

waren die Fehlermeldungen mit denen der Build abbrach. Die Fehlermeldungen wechseln auch von Lauf zu Lauf. make -j scheint dafür ursächlich zu sein. Im Verzeichnis temp_builds werden die CPU-spezifischen Unterverzeichnisse nur mit make -j angelegt, wenn auch nur bei jedem 2. Lauf. Ich habe übrigens keine Änderungen am makefile vorgenommen. Es ist das, was gestern herunterzuladen war.

Vielen Dank!
Th. Plaschke

By Andreas Matthies Date 2026-04-21 06:51 Edited 2026-04-21 06:54

Drei Anmerkungen:
clean und profile-build im selben Aufruf sieht wild aus, ich würde das immer in zwei make Aufrufe aufteilen.
COMP=... lasse ich weg und lasse die gestartete Shell (mingw64.exe oder ucrt64.exe) über den korrekten/Default-Kompiler entscheiden.
-j funktioniert zumindest auf meinem Windows Notebook nicht, weil er dabei regelmäßig in Speicherprobleme gerät. Vermutlich weil der Rechner mit 8 Hyper-threading Kernen, also 16 Threads bei nur 16GB Hauptspeicher etwas knapp an RAM ist. Ich nutze deshalb üblicherweise -j 4

Gruß, Andreas

By Thomas Plaschke Date 2026-04-21 14:34

Also genau Dein Rezept, aber ohne -j, was ich normalerweise nicht im Aufruf einsetze, sondern im makefile in den konkreten Build-Aufrufen von build und profile-build (und damit noch nie Probleme hatte. Das geht dann eins fix drei! - 18 Kerne+HT und 32 GB oder 16 Kerne+SMT und 64 GB, aber auch im alten 4 Kerne+HT und 16 GB Notebook):

1. make clean /* Weil mingw bei erfolgreichem profile-build nicht nur die Objekt-Dateien, sondern eine Unzahl andere Temporärdateien hinterlässt */
2. make profile-build ARCH=x86-64-universal RUN_PREFIX="/c/tools/sde/sde -future --"

Es bleiben dieselben Fehlermeldungen:

Code:

            mingw32-make[1]: *** No rule to make target 'universal-object-pgo'.  Stop.
mingw32-make[1]: Leaving directory 'C:/Tools/msys64/home/Nutzer/sf260419/src/temp_builds/x86
           mingw32-make: *** [Makefile:1317: C:/Tools/msys64/home/Nutzer/sf260419/src/temp_b                                                                    builds/x86-64/stockfish.o] Err

Die eigenartige Formatierung der Ausgaben und Fehlermeldungen (mit Einrückungen) ist auch eine "Neuerung" der aktuellen Stockfish-Version.
Wie schon erwähnt, lässt sich Stockfish auf die "konventionelle" Art problemlos weiterhin kompilieren.

[Nachtrag]
Mit der heute eingestellten Dev-Version (20.04.2026) funktioniert's auch bei mir

(ausprobiert mit mingw - ucrt64 versuche ich gleich).

Viele Grüße
Th. Plaschke