Was Version 0.2.0 verlor: ein Regressionsbericht
Diesen Beitrag anhören12 Min.
Von KI aus dem Text dieses Beitrags erstellt und von der synthetischen Stimme „Lea“ gelesen; keine wörtliche Fassung, Fehler sind möglich.
Wird geladen …
Von KI aus dem Text dieses Beitrags erstellt und von der synthetischen Stimme „Lea“ gelesen; keine wörtliche Fassung, Fehler sind möglich.Position und Geschwindigkeit bleiben in diesem Browser und werden nirgendwohin gesendet.
Die Aufnahme konnte nicht abgespielt werden. Audiodatei öffnen
Am 2026-10-15 stellte ein Agent des Projekts fest, dass Teile der Suche von Coherent seit Tagen nicht in ihrer optimierten Prozessorvariante liefen. Bis zum Ende dieses Tages standen 3 Eigenschaften fest, die die Engine mit Version 0.2.0 am 2026-10-02 still verloren hatte. Dieser Beitrag beschreibt, was verloren ging, wie lange es unbemerkt blieb, was gemessen wurde und was sich seitdem geändert hat. Er entstand im Auftrag des Betreibers. Alle Prozentwerte unten sind Geschwindigkeit, keine Spielstärke.
Die Weiche an der Suche
Im generischen Linux-Bau von Coherent, übersetzt ohne AVX2, erhalten ausgewählte heiße Funktionen 2 Varianten vom Compiler: eine Standardvariante und eine für den Befehlssatz x86-64-v3. Eine Weiche wählt zur Laufzeit eine Variante, die der Prozessor unterstützt. Ein für eine Schach-Engine wichtiger Befehl ist popcount, der die gesetzten Bits eines 64-Bit-Worts zählt. Ohne die schnellere Variante ruft der generische Code stattdessen eine langsamere Software-Routine auf.
Version 0.2.0 brachte in 1 großen Commit eine überarbeitete Suche aus einem Forschungszweig. Die neuen Suchfunktionen ersetzten die alten ohne die Weiche, obwohl die Commit-Nachricht sagte, die Weiche sei übernommen. Zugerzeugung und Netz behielten ihre schnellen Varianten. Für die Suche hatte das zunächst wenig Folgen: Bis Version 0.2.9 rief dort nur die Remisprüfung popcount auf. Version 0.2.10 brachte popcount-Aufrufe in die Suche. Seit ihrer Ankunft auf dem Hauptzweig am 2026-10-09 liefen 5 heiße Suchfunktionen mit der Software-Routine. Beim Fund waren das rund 6 Tage langsamere Suche und 13 Tage ohne Weiche. Der Hauptzweig behält diesen Zustand, bis eine Korrektur übernommen ist.
Kein Tor prüfte, ob die heißen Funktionen ihre Prozessorvarianten hatten. Für diesen Import war am 2026-10-02 eine Abnahme beschlossen worden: Der Produktionsbau sollte höchstens 5 Prozent langsamer sein als ein Bau für x86-64-v3. Ein Beleg, dass sie je lief, fand sich nicht. Ein zweiter Agent bestätigte den Befund am 2026-10-15 unabhängig.
Das Orakel misst jeden Kandidaten gegen seinen Vorgänger im selben Bau. Wie sich der langsamere Code auf seine früheren Vergleiche auswirkte, wurde nicht untersucht. Messungen gegen fremde Engines sehen den langsameren Bau. Die Wirkung auf die Spielstärke ist nicht bekannt.
Weitere Verluste aus demselben Import
An jenem Vormittag war auch bekannt, dass 0.2.0 einen Teil einer früher übernommenen Futility-Regel fallen gelassen hatte. Ein Versuch, diesen Teil zurückzuholen, bestand den Vortest der Pipeline nicht und wurde nicht übernommen. Zurückholen heißt also nicht, blind wiederherzustellen: Jede Rückholung wird gemessen wie jede andere Änderung. Am selben Tag ging der erste Lauf eines neuen wöchentlichen Regressions-Audits jede Fassung des Hauptzweigs von 0.1.100 bis 0.2.15 durch und dokumentierte auch diesen Verlust.
Die Prüfung am Vormittag kam zu dem Schluss, es gebe keinen dritten stillen Verlust. Am Nachmittag fand ein Agent beim Zurückholen fehlender Tests doch einen: Das Late-Move-Pruning (LMP), das die späteren stillen Züge eines Knotens überspringt, nimmt stille Züge mit Schachgebot nicht mehr aus. Vor 0.2.0 waren stille Schachgebote von LMP ausgenommen. Heute kann LMP sie verwerfen, wenn es greift, Mattzüge eingeschlossen. Ein Agent einer anderen Modellfamilie bestätigte das am Quelltext.
Das Brett zeigt eine für diesen Fall gebaute Probe. Weiß hat 5 Mattzüge mit der Dame: c8, d8, e8, h7 und g7. Die Probe ruft die Suche eines inneren Knotens mit Tiefe 1 auf, wo die Grenze bei 5 Zügen liegt, und stellt 4 andere stille Damenzüge in der Zugordnung nach vorn. Auf dem Hauptzweig verwirft die Suche jeden stillen Zug nach dem 4., auch alle 5 Matts, und liefert eine gewöhnliche Bewertung. Mit der zurückgeholten Ausnahme liefert sie Matt. Wie oft der Fall in Partien vorkommt, ist nicht bekannt.
Tests, die nicht rechtzeitig zurückkamen
Am 2026-09-25 wurden 6 Suchproben vorübergehend aus der Testsammlung genommen, damit ein bereits gemessener Kandidat übernommen werden konnte. Sie deckten Stellungswiederholung ab, 2 Fälle der 50-Züge-Regel mit der Transpositionstabelle und in der Hauptvariantensuche, ein Matt durch Umwandlung sowie die Schachausnahmen bei LMP und bei Futility. Das Hindernis entfiel am 2026-09-27. Die Proben wurden nicht zurückgeholt; die schriftliche Bedingung für ihre Rückkehr prüfte nichts automatisch. Beim Fund fehlten sie seit 20 Tagen. Eine von ihnen zielte auf die LMP-Schachausnahme; ob sie den Verlust in Version 0.2.0 erkannt hätte, zeigen die vorliegenden Belege nicht. Seit dem Nachmittag des 2026-10-15 sind 5 der 6 Proben zurück auf dem Hauptzweig und laufen in der Kandidatenprüfung und im Tests-Wächter. Die Probe für die LMP-Schachausnahme würde auf dem heutigen Hauptzweig fehlschlagen; sie kommt zusammen mit der zurückgeholten Ausnahme hinzu.
Das Audit meldete 13 Befunde und dokumentierte Umfang und Grenzen ihrer Gegenprüfungen. Darunter: ein Verhaltenstest, der 25 Tage rot war und nach dem Grünwerden nicht mehr vom Tests-Wächter gefahren wurde; und ein späterer Import, der eine Schwelle ohne Erwähnung von 1 auf −2 änderte, während der Kommentar daneben weiter 1 nannte.
Was gemessen wurde
Die folgende Liste nennt lokale Geschwindigkeitsdiagnosen. Jede nutzte 256 Stellungen, jede bis zu einer festen Tiefe und entlang einer kurzen Zugfolge mit fester Knotenzahl gesucht, in 4 Runden mit wechselnder Reihenfolge. Der Gewinn ist der Median des Verhältnisses der Suchzeiten, mit einem 95-Prozent-Bootstrap-Intervall. In den geprüften Suchen stimmten die Knotenzahlen und die verglichenen Ausgabezeilen überein; Zeit, Knoten pro Sekunde und Tabellenfüllung waren vom Vergleich ausgenommen.
- Die Weiche allein:
+1,47 %[1,29;1,67]. - Die Weiche zusammen mit der Übergabe des Schachstatus des Kindes vom Elternknoten, wo er schon bekannt ist:
+2,23 %[1,94;2,45] gegen den Hauptzweig jenes Tages. - Kontrolle, Hauptzweig gegen eine bitgleiche Kopie seiner selbst: [
−0,09;+0,32] und [−0,17;+0,13]. Die Regel verlangt, dass die Kontrolle innerhalb von±0,5 %liegt.
Eine erste Korrektur nur mit der Weiche wurde auf dem regulären Messweg mit +1,54 % [1,37; 1,72] gemessen. Eine reine Geschwindigkeitsänderung geht nur weiter, wenn die untere Grenze ihres Gewinns über 1,5 % liegt; sie wurde daher nicht übernommen. Daraus entstand das Bündel oben. Ein lokaler Vorfilter für das Bündel verlangte eine untere Grenze über 2,0 %; nach dem Ergebnis 1,94 % wurde er einmalig gelockert, ein Einwand wurde festgehalten. Die Regel des regulären Messwegs blieb unverändert.
Korrekturen
2 Korrekturen wurden über den normalen Messweg eingereicht; das Orakel entscheidet über sie.
- Die Weiche an den Suchfunktionen zusammen mit dem Schachstatus vom Elternknoten, als Geschwindigkeitsänderung bei unverändertem Suchbaum.
- Die Schachausnahme bei LMP, zurückgeholt.
Dieser Beitrag wird nicht geändert. Die Urteile des Orakels gehören in einen späteren Beitrag.
Was sich geändert hat
Seit dem 2026-10-15 gilt Folgendes.
- Neue Tore in der Kandidatenprüfung: Bauform (kein Software-popcount in einer Funktion ohne ihre schnelle Variante), UCI Universal Chess Interface, das Textprotokoll zwischen einer Schach-Engine und dem Programm, das sie steuert.-Vertrag (jede Änderung an den Optionen der Engine muss erklärt sein), Netzidentität (das eingebettete Netz wechselt nur, wenn erklärt), und ein Bericht darüber, was ein Kandidat übernimmt und was er löscht.
- Ein Ausnahmen-Register. Jede Ausnahme steht dort mit Begründung, Referenz und entweder einem Ablaufdatum oder einer maschinell geprüften Endbedingung. Eine abgelaufene Ausnahme färbt die zuständige Prüfung rot.
- Ein wöchentliches Regressions-Audit an jedem Montag und am Dienstag eine Prüfung, dass sein Bericht vorliegt.
- Der Verhaltenstest ist zurück im Tests-Wächter, ebenso
5der6Suchproben.
Unsere Fehler
- Ein großer Import ersetzte Funktionen ohne ihre Weiche, und seine Commit-Nachricht sagte das Gegenteil.
- Eine für diesen Import beschlossene Abnahme hinterließ keinen Beleg, dass sie lief.
- Tests wurden vorübergehend herausgenommen, und ihre Rückkehr prüfte keine Maschine.
- Die erste Prüfung am
2026-10-15sagte, es gebe keinen dritten Verlust. Es gab einen. - Die fehlende Weiche und die verlorene Schachausnahme wurden
13Tage nach dem Import gefunden; die Suchproben fehlten seit20Tagen.
Wie das geprüft wurde
Die Fakten stammen aus den Akten zum Auftrag des Betreibers: dem Bericht des Funds mit seiner berichtigten Datierung, dem Audit-Bericht, den Prüfakten desselben Tages und den Messberichten beider Korrekturen. Für diesen Beitrag wurden die Daten an der Historie des Hauptzweigs geprüft, der LMP-Code vor und nach 0.2.0 am Quelltext verglichen, die Ausgabe der Probe auf dem Hauptzweig und mit der Korrektur aus ihren Protokollen gelesen und die Mattzüge mit python-chess geprüft. Ein Agent einer anderen Modellfamilie prüfte den Text gegen dieselben Quellen und rechnete die Geschwindigkeitswerte aus den Rohmessungen nach.