Robert Bauer schrieb:
Zitat:
Wer ein altes Netz spielen will, nimmt einfach einen alten dazu passenden Stockfish.
Du kannst mir sicher die Liste der passenden Stockfishe zu einem Netz geben, z.B. den letzten Stockfish, bevor auf ein neues Netz umgestellt wurde, denn dieser ist ja dann der Beste für das jeweilige Netz. :->
Mit ein wenig Suchen in den Commits von Stockfish nach "New Architecture" findet man die beiden folgenden Commits:
https://github.com/official-stockfish/Stockfish/commit/e8d64af1230fdac65bb0da246df3e7abe82e0838 (Wechsel von half_kp auf half_ka_v2)
https://github.com/official-stockfish/Stockfish/commit/d61d38586ee35fd4d93445eb547e4af27cc86e6b (Wechsel von halfka_v2 auf half_ka_v2_hm)
Und das sind auch schon alle Architekturwechsel, die es in den Master geschafft haben.
Der letzte/beste Stockfish mit halfka_v2 müsste also der vom 5.8.21 sein:
https://github.com/official-stockfish/Stockfish/commit/dabaf2220fe0c77400a5f71a91952f510e6a126bDer letzte/beste Stockfish mit der Originalarchitektur half_kp ist vom 17.5.21:
https://github.com/official-stockfish/Stockfish/commit/f90274d8ce1aad4ad0595aacbceb74b6cbe306a8Robert Bauer schrieb:
Das ist das Problem. Es gibt keine solche Liste. Alles andere ist unnötiger Aufwand, da diese Information vorliegen sollte bzw. gepflegt werden könnte, z.B. einerseits als Spalte bei der bekannten NNUE-Netz-Seite und andrerseits als Spalte bei den Stockfish-Dev-Builds.
Diese NNUE-Netz-Seite ist ja primär dazu da, dass die Entwickler dort Netze hochladen und innerhalb von Fishtest verwenden können. Aber ich gebe dir Recht, eine Spalte, aus der man auf einen Blick erkennen könnte, was für ein Netz das ist, würde nicht weh tun. Selbst die Dateigröße wäre ja derzeit ausreichend, um daraus die Architektur ableiten zu können.
Ich vermute mal, dass die Entwickler dieses "wilde Testen von Netzen" eher vermeiden wollen, weil es die Supportanfragen erhöht.
Robert Bauer schrieb:
Zitat:
...da auch in den Low-Level-Routinen immer Optimierungen eingebaut sind, die mit Architektur A funktionieren, mit Architektur B aber nicht.
Ist dies eine Annahme oder hast Du dies dem Code oder der Aussage eines SF-Programmierers entnommen?
Das habe ich zum einen daraus geschlossen, dass die Commits mit den Architekturänderungen immer auch viel entsprechenden Code der Art
https://github.com/official-stockfish/Stockfish/commit/d61d38586ee35fd4d93445eb547e4af27cc86e6b#diff-da313937d54e9247a2c2c12116ca5fc89998f01ac846f5f9be0b499725286dc1R139 enthalten.
Zum anderen lese ich das auch hier
https://github.com/syzygy1/Cfish/issues/204#issue-944790893 heraus, wo der Haupt-NNUE-Entwickler von möglichen Optimierungen in einem dünn besetzten Featurelayer spricht. Wie dünn der besetzt ist, unterscheidet sich aber wiederum von Architektur zu Architektur.
Robert Bauer schrieb:
In den Stockfish Sourcen gibt es ein Unterverzeichnis NNUE. Darin müssen alle NNUE-Architektur-Änderungen enthalten sein, ansonsten wäre es ein klarer Bruch gegen Coding Conventionen.
Diese Sourcen sind überschaubar. Zugegebenermaßen fehlt mir z.Zt. das nötige Know How, um dies zu implementieren. Mein Versuch mit CFish, wo die Parameter wahrscheinlich nur in einer Datei nnue.c drinstecken, ist leider gescheitert.
Ist ja auch so. Allerdings fliegt der alte Code halt raus, wenn der neue Code kommt, um das ganze übersichtlich zu halten.
Wenn du dir die Commits oben genauer anschaust, ist es eben nicht nur eine schnöde Anpassung der Netzgröße, die man mit der Anpassung eines Parameters z.B. von 512 auf 1024 erledigen könnte. Insbesondere die Featuresets haben es halt in sich, was die Komplexität angeht. Und solche Änderungen
https://github.com/official-stockfish/Stockfish/commit/e8d64af1230fdac65bb0da246df3e7abe82e0838#diff-e5df0d0a5fec73d66bcc2267e22b11a188c09b1b239dbb076633447e4f2b2570L41 parallel zu pflegen, das geht wahrscheinlich früher oder später schief. Immerhin ist einer der Maintainer schon ausgestiegen, weil ihm der aktuelle NNUE-Code schon zu komplex war.
Robert Bauer schrieb:
Die Entwickler einer Engine sollten und werden universeller denken. Es kommen immer wieder neue Ansätze. Diesmal sind es "größere" Netze. Wie Andreas Matthies korrekt schrieb, ging die Verdopplung mit einer Vereinfachung einher. Ich sehe Potential darin, wenn man die Parameter in der nnue_architecture.h und nnue_feature_transformer.h flexibel gestalten würde, nämlich entweder aus der NNUE auslesen würde oder als Engine Parameter über die Oberfläche steuerbar machen würde, dann wäre nochmal ein Tor zu weiterer Variation und somit weiterem Fortschritt geöffnet.
Die Variablen existieren ja auf Ebene der Entwickler. Die müssen aber neben der Anpassung im Stockfish auch immer den Trainer, mit dem die Netze trainiert werden, entsprechend anpassen und dann auch tatsächlich Netze trainieren, die diesen Parametern entsprechen. Das passiert ja in den entsprechenden Branches von Sopel und co. Aber was hast du als Endanwender davon, wenn diese Parameter variabel sind bzw. du beliebige Netze laden könntest? Du kannst doch nur bestehende Netze testen, die a. im Fishtest durchgefallen sind, b. zwar mal gut waren aber inzwischen übertroffen sind oder c. aktuell und so gut sind, dass sie demnächst im Master enthalten sein werden. Da an Fortschritt zu glauben, heisst ja, die Methoden von Fishtest in Zweifel zu ziehen. Und da würde ich widersprechen.
Insgesamt aber endlich mal eine erstaunlich konstruktive Diskussion