Beeinflussungsfaktoren
back to Frank's Chess Page

Copyright: © by Frank Quisinsky
Last changes: June 28th, 2020

Seit nunmehr ca. 24 Jahren nutze ich Engines für so genannte "Engine-Engine" Turniere / Ratinglisten. Es gibt einen Hauptgrund, warum ich ausgerechnet diesen Bereich des Computerschachs zu einen meiner Lieblingsthemen erkoren habe.

Lernen durch Zusehen:
Strittig ist, ob die eigene Spielstärke durch diesen Zuseh-Effekt gesteigert werden könnte. Ich vermute schon, allerdings ohne praktische Erfahrungen verbleibt lediglich die Theorie. Spiele ich nach einer längeren Zeit selbst gegen einen menschlichen Gegner oder einer Engine, merke ich schnell, dass sich viele unnötige Flüchtigkeitsfehler einschleichen. Auch spiele ich gegen "Menschen" sehr aggressiv. Vermutlich habe ich mir diese Spielweise durch das Zusehen von Engine-Engine Partien angewöhnt.

Meist ist es so, dass ich verzaubert zusehe und erst später oder auch oftmals "leider" gar nicht, in einer späteren Analyse, verstehe, was von der künstlichen Intelligenz so alles aufs Brett kombiniert wurde. Aufgrund meiner ganzen Experimente bzw. der Beschäftigung mit Schachprogrammen vermute ich dennoch, dass ich insbesondere meine taktische Schlagkraft deutlich verbessern konnte.

Untersuchen wir nun die vielen unsicheren Beeinflussungsfaktoren, die bei der Erstellung einer Ratingliste auftreten, scheint es ein schier unmögliches Unterfangen zu sein, eine Ratingliste zu erstellen. Erforderlich ist eine gute Organisation, denn wer wirft im Verlauf schon gerne ein paar tausend gespielte Partien wieder in den Papierkorb? Aufgrund der vielen Beeinflussungsfaktoren als auch Veränderungen bei den Engines selbst, stellt eine Ratingliste immer nur eine Momentaufnahme dar. Die als _ultimativ_ zu wertenden Elo-Zahlen können durch eine Ratingliste nur bedingt ermittelt werden, später mehr!

Die erste Frage für ein solches Unterfangen sollte sein:
WAS WILL ICH ERREICHEN?

Möchte ich möglichst viele Engines unter möglichst gleichen Voraussetzungen und mit möglichst aussagekräftigen Ergebnissen? Meine Überlegungen zu diesem Themenkomplex versuche ich nachfolgend näher auszuführen.

Direkt ein eingeschobener Hinweis:
Meine Sichtweise auf Ratinglisten hat sich im Verlauf der letzten Jahre deutlich verändert! Ein bekanntlich sehr zeit- und kostenintensives Thema (Strom, Hardware). Eine frisch erstellte Ratingliste ist aufgrund der vielen Engine Updates in kurzer Zeit wieder veraltet. Heute gibt es sicherlich mehr als 1.000 Engine Entwicklungen. Immer weniger Programmierer schauen sich Partien zwecks möglicher Verbesserungen der eigenen Programmentwicklung genauer an. So steht doch heute vielmehr die verwendete Suchtechnik und oder automatisiertes Parametertuning im Vordergrund. Um mehr über Engines mittels Statistik herauszufinden, ist die Engine-Forschung wie eh und je interessant. Gerade beim Mittelspiel gibt es noch viel zu erforschen. Ratinglisten sind eher als ABM-Maßnahmen zu werten, wenn es darum geht, _lediglich_ die reine Spielstärke in Elo zu messen. Warum? Der Durchschnitt der TOP-40 Engines dieser Welt liegt _wahrscheinlich_ um 200 Elo über der derzeit maximal erreichten menschlichen Spielstärke vom Weltmeister Magnus Carlsen. Dies bei der Nutzung von nur einem Core auf einem handelsüblichen Intel oder AMD-System. Der Aufwand solcher Spielstärkemessungen erscheint aus menschlicher Sicht zunächst sinnentfremdet. Was wir unter der Zuhilfenahme von einfachen Statistiken herausfinden werden, nehmen wir dennoch gerne zur Kenntnis.

Persönlich empfinde ich heute Themen wie:
Die logische Herabsetzung der Engine Spielstärke unter Beibehaltung menschlich interessanter Eigenschaften / Spielstile für erhellender. Es wäre z. B. interessant, den Spielstil von Weltmeister Michail Tal zu klonen und dafür modernes KI einzusetzen. Es wäre ferner interessant, die heute erreichte Engine Spielstärke besser zu nutzen. Hierbei könnte die für "Menschen" interessante Mittelspielphase sehr aufregend gestaltet werden.

Für die Programmentwicklung von Wasp nutze ich die Möglichkeit Engine-Turniere zu organisieren oder Spießroutenläufe durchzuführen. Schon allein um herauszufinden, gegen welche Gegner ich zum Zwecke der Weiterentwicklung testen sollte. Es gibt nach wie vor Gründe sich mit der Engine-Forschung zu beschäftigen.

Eine Ratingliste kann heute jeder mit ein wenig Fleißarbeit erstellen und stellt im Grunde nichts Besonderes mehr dar! Wer in Kombination seinen Forscherdrang befriedigen möchte wird immer Gefallen an dem Themenkomplex Ratingliste / Engine-Turnier finden.

Unsichere Beeinflussungsfaktoren:
Eine ganze Reihe unterschiedlicher Faktoren bereitet uns Kopfzerbrechen? Stimmen die eigenen Resultate und warum kommt es oftmals zu gravierenden Abweichungen zu Testergebnisse anderer Computerschächler? Das Auge des Betrachters sollte ein wenig geschult werden, nicht zuletzt, um die Erwartungshaltung bei Engines, meist favorisierten Engines, einzugrenzen. Aufgrund vieler Diskussionen in Computerschachforen vermute ich, dass viele Schachfreunde zu sehr an ihren eigenen Ergebnissen glauben. Ein Blick nach links, rechts wird meist nur deshalb durchgeführt, um Engine Updates nicht zu verpassen. Sinnvoller wäre es vielleicht die Gründe für abweichende Testergebnisse zu hinterfragen, um selbst einen Nutzen aus den Informationen zu ziehen. Auch war es noch nie möglich interessierte Computerschächler, in Fragen der Engine-Forschung, unter einen Hut zu bringen. Jeder kocht nur zu gerne sein eigenes Süppchen. Das ist schade, aber grundsätzlich gilt natürlich, dass der eigene Spaßfaktor _immer_ im Vordergrund stehen sollte, aus einem Unterfangen eine Ratingliste zu erstellen kein Stressfaktor werden sollte und ruhig auch die Erfahrungswerte anderer Schachfreunde studiert werden können. Wer das berücksichtigt, wird noch mehr Gefallen an diesem Themenkomplex finden ohne sich direkt in die Welt der Stiere in "www-Zeiten" wie heute zu beamen.

1. Spielstufe / Bedenkzeit, Hardware / Prozessoren

Die Spielstufe / Bedenkzeit steht in Abhängigkeit zum gewünschten zeitlichen Rahmen und auch der zur Verfügung stehenden Hardware. Wie viel Zeit möchten Sie ihrer Ratingliste oder einem Engine-Turnier gönnen? Möchten Sie möglichst viele Engines ein picken, sollte die Zeit "vielleicht" heruntergefahren werden, wenn aussagekräftige Ergebnisse Ihre Zielsetzung sind. Schon dieser Punkt sorgte in der Vergangenheit für heftige Diskussionen. Verfechter "längerer Bedenkzeit" verurteilen die Bemühungen der Verfechter "kürzerer Bedenkzeit". Diese ganze Fechterei erinnert an die drei Musketiere (lange, mittlere und kürzere Bedenkzeit). Aber auch die drei Musketiere waren nur zusammen stark und mithin sollten wir uns zunächst mal genau das in unser Hirn brennen. Eine Wahrheit bei der Beantwortung der Frage zu der gewählten Bedenkzeit gibt es nicht, zumal nur sehr wenige Engines bei mehr oder weniger Bedenkzeit im direkten Vergleich zu anderen Engines auch unterschiedliche Ergebnisse produzieren.

Allerdings vertrete ich die Auffassung, dass die Turnierbedenkzeit (40 Züge in 120 Minuten oder 40 Züge in 150 Minuten) im Computerschach nicht die Königsdisziplin stellt. "Computerschach", die künstliche Intelligenz, kommt mit ganz anderen Bewertungsmaßstäben daher als im direkten Vergleich "menschliches" Schach. In Abhängigkeit zur Hardware, stellt die Turnierbedenkzeit vor ca. 25 Jahren heute nur ein Blitzlevel (Vergleich: Intel 80486 Prozessor aus den Jahren 1989 - 1995 zu einem heutigen 10th Generation Intel® Core™ i9-10900K) dar.

Zu bedenken ist auch, dass aufgrund der Kompilierungen von Schachprogrammen, unterschiedliche Prozessortypen für abweichende Ergebnisse sorgen könnten. Es gibt Engines, wo diese Vermutungen zumindest nahe liegen. Als Beispiel bietet sich Zappa an. Wie groß diese Unterschiede sind, ist natürlich auch wieder abhängig von den sonstigen Beeinflussungsfaktoren. Eine endgültige Klärung, bei den vielen unterschiedlichen Test-Methoden, ist daher so gut wie ausgeschlossen. "Unsere Programmierer" werden schon wissen, wie ihre Babys kompiliert werden, bzw. sollte dieser Umstand als gegeben und mithin kaum als diskussionsreif dargestellt werden. Die Prozessor Befehlssätze (BMI2, AVX, POPCMT, SSE etc..) sind in letzten Jahren zu einem ergänzenden Thema geworden.

Vorteile: Bei meinen ehemaligen SWCR-2 oder FCP Ratingliste spielten die besten zur Verfügung stehenden Programmen gegeneinander. Jede Engine absolvierte 50 Partien gegen jede andere Engine. Ferner versuchte ich möglichst viele unterschiedliche Engines einzusetzen. Das ist aufgrund der "Clone-Problematik" schon eine echte Aufgabe herauszufinden, ob sich Engines wirklich unterscheiden. Bei 40 Züge in 10 Minuten konnte ich zuletzt bei der FCP Ratingliste den Partien schön folgen. Verzweifeln Sie nicht, wenn viele interessante Zugfolgen nicht verstanden werden. Es macht Spaß diese im Anschluss an einer Partie oder bei Zeitbedarf unklare Zugfolgen näher zu analysieren.

Nachteile: Der Lerneffekt durch zu schnelle Bedenkzeit bei dem erreichten sehr hohen Level der Engines lässt nach. Die durchschnittliche Spielstärke der 41 weltbesten Engines liegt ca. 1250 Elo über die eines starken Vereinsspielers, der vielleicht auf eine Leistung von 1800 Elo kommt. Je weniger Zeit desto mehr sich bildende Fragezeichen beim Zusehen von Engine-Engine Matches. Bei vielen Ratinglisten geht es gar nicht mehr um das Partiematerial selbst, eher um möglich schnell eine Elo zu fabrizieren. Der Sinn einer solchen Testserie liegt meist verborgen in der Kombination der eigentlichen Hobby-Ausübung, denn viele Interessen prallen aufeinander. Wie z. B. sich generell mit Computer, Statistik und gleichzeitig Schach zu beschäftigen!

2. Verwendete Benutzeroberfläche (GUI)

Es gibt eine Reihe von Benutzeroberflächen, die sich für Engine-Engine Turniere oder Ratinglisten sehr gut eignen. Natürlich gibt es Vor- und Nachteile zwischen den Benutzeroberflächen, aber daraus wird heute keine Glaubensfrage mehr konstruiert. Im Laufe der Jahre wurden die Benutzeroberflächen kontinuierlich verbessert, so dass viele Kinderkrankheiten praktisch verschwunden sind. Ich habe selbst viele Jahre zusammen mit Martin Blume in die Entwicklung der Arena GUI gesteckt oder auch Tim Mann (Winboard) mit Informationen versorgt.

3. Eröffnungsbücher

Die Gefahr ist groß, andere Personen bei diesem Themenkomplex auf die Füße zu treten. Insofern versuche ich vorsichtig meine Überlegungen niederzuschreiben. Bei Eröffnungsbüchern müssen wir zunächst den Sinn des Einsatzes hinterfragen. Steht z. B. ein wichtiges offizielles Turnier an, wird fast jeder Programmierer oder Eröffnungsbuch-Autor versuchen, Elo-Pünktchen mittels Manipulation durch Tuning heraus zu kitzeln. Auf diesem Gebiet haben sich einige Experten in der Szene herauskristallisiert. Auch bei einem längeren Engine Match, spielt ein gutes Buch und auch Book-Learning eine wesentliche Rolle. Insofern wird einem getunten Eröffnungsbuch und auch Book-Learning zu Recht und ohne Frage eine besondere Bedeutung zugewiesen. Wie schaut es bei Engine-Turnieren oder bei der Erstellung einer Ratingliste aus? Dürfen Bücher Einflüsse im direkten Vergleich zu sämtlicher Engine-Konkurrenz ausüben? Dürfen wir bei einer Bewertung einer Engine den Datenbankeinflüssen überhaupt eine so große Aufmerksamkeit widmen? Wirkt sich Book-Learning positiv aus, wenn direkt 21 Programme gegeneinander spielen? Eine Eröffnung, die gegen Engine A buchstäblich in die Hose gegangen ist, kann gegen Engine B zu einem Erfolg führen! Durch Book-Learning wird diese Eröffnungsvariante aber oftmals gar nicht mehr ausgespielt. Es gibt Engine Programmierer, die sich sehr viel Arbeit bei der Erstellung eines Eröffnungsbuch machen, andere bedienen sich einfacher Datenbanksammlungen aus Großmeisterpartien. Viele User setzen auch speziell ausgesuchte Stellungen (Nunn Test) ein, um weitestgehend Bucheinflüsse bei Turnieren oder Ratinglisten zu vermeiden. Beliebt sind auch sehr kleine breite Bücher, die nicht in die Tiefe der Eröffnungstheorie gehen. Viele Anhänger der immer beliebteren Chess960 Variante spielen nur deswegen gerne Chess960, weil sie der Eröffnungstheorie überdrüssig sind. Es gibt Anwender, die versuchen gar die komplette Eröffnungstheorie zu umgehen. Schon nach diesen wenigen Worten werden Sie bemerken, dass dieses Thema wirklich sehr komplex ist und zunächst eine Lösung für einen gesunden Mittelweg, gerade für Ratinglisten-Ersteller, zumindest schwierig erscheint. Versuchen wir dieses ganze Durcheinander im Hinblick auf die Erstellung einer Ratingliste zusammenzufassen:

a. Book-Learning kann sowohl negativ als auch positiv manipulierend wirken!
b. Eröffnungsbücher könnten getunt sein und gegen nicht getunte Engines negative Auswirkungen haben.
c. immer wieder kehrende Positionen, wie z. B. der Nunn-Test, führen zur Langeweile und Einseitigkeit.
d. Viele Engines spielen stur die nach eigener Ausspielwahrscheinlichkeit besten Varianten. Dies führt zu doppelten oder zumindest weitläufig doppelten Partien sofern verwendete Bücher nicht über ausreichend Varianten verfügen.
e. Bücher, durch die Eröffnungssysteme nur angespielt werden, lassen Engines oftmals merkwürdige Fortsetzungen spielen. Eröffnungssysteme werden nicht verstanden und unnötige Kurzpartien sind die Folge. Die französische. Eröffnung wird immer gerne als Paradebeispiel herangezogen. Viele Buchautoren vermieden für Computerschachprogramme z. B. die französische Eröffnung oder viele Varianten der holländischen Eröffnung. Vorteilhaft ist allerdings immer, wenn solche Schwächen erkannt werden und Programmierer sich auf die Suche nach Verbesserungen begeben könnte.
f. GUI-Einheitsbücher werden unter Umständen gesteuert von Ausspielpräferenzen. Jeder von uns könnte aber zu Ausspielpräferenzen eine stark unterschiedliche Meinung haben.
g. Ein getuntes Buch für Version 1.0 von Engine X könnte bei Version 2.0 der gleichen Engine einen negativen Effekt zeigen und erst recht bei Verwendung von Turnieren oder Ratinglisten an dem mehrere Engines beteiligt sind.

Letztendlich stand zu Recht immer die Vermutung im Raum, dass selbst die besten verfügbaren Engines, bei der Eröffnungswahl und den eigentlichen Ideen, die dahinter verborgen sind, Großmeistern unterlegen sind. Es gilt heute im Jahr 2020 als eher wahrscheinlich, dass aufgrund der stark angestiegenen Spielstärken unserer Engines, diese vielleicht letzte Dominanz unserer geliebten Großmeister nun auch "teilweise" umgestoßen wurde. Bei Gesprächen mit Großmeistern hörte ich immer wieder den Kommentar: Wenn durch gut bekannte Eröffnungsideen kein leichter Vorteil errungen werden kann, ist die Chance auf ein Remis nicht mehr wahrscheinlich.

4. Endspieldatenbanken (Nalimov Table-Bases, Shredderbases, Gaviotabases, Syzygybases)

Bei den Nalimov Table-Bases (Endspieldatenbanken) handelt es sich um einfache Datenbankabfragen, zu möglichen Endspielstellungen, bei wenigen Figuren (3-7 Steiner). Bereits in der Suche erreichen Schachprogramme durch Schlagzugkombinationen die 5-Steiner Table-Bases, sogar wenn 15 oder leicht mehr Figuren auf dem Brett verbleiben. Engines greifen mal mehr oder weniger aggressiv auf diese Datenbanken zu. Je aggressiver die Datenbankabfragen, desto eher erfolgen die ersten Zugriffe. Bei den Table-Bases werden oftmals mehrere ineinandergreifende Datenbanken abgefragt. Die 4-Steiner oder 5-Steiner Table-Bases sollten demnach stets komplett sein, schon allein um nicht reproduzierbare Partien zu vermeiden.

Die kompletten 4-Steiner Nalimov Table-Bases nehmen ca. 30 MB Festplattenspeicher in Anspruch (70 Dateien).
Die kompletten 5-Steiner Nalimov Table-Bases nehmen ca. 7.402 MB Festplattenspeicher in Anspruch (292 Dateien).
Auch die 6-Steiner liegen schon komplett vor, etliche 7-Steiner werden auch schon angeboten.

Insbesondere eignen sich die Table-Bases für Analysen, aber eignen sich die Datenbanken auch für Engine-Engine Turniere oder zur Erstellung einer Engine Ratingliste? Diese Frage löste in Computerschachforen schon öfters heftigste Diskussionen aus. Die verbreitete Annahme, dass sich die 5-Steiner positiv auf die Spielstärke einer unterstützenden Engine auswirken ist äußerst fragwürdig und meines Erachtens FALSCH. Wir sehen oftmals durch Table-Bases enorm hohe Mattankündigungen, sind daher schier begeistert. Die Nachteile ruhen in einer für uns kaum sichtbaren Dimension?!

Ein Versuch den Umstand zu erläutern:
Computerschachpartien werden durchschnittlich nach 86 Zügen bei ca. 3000 durchschnittlicher Elo entschieden (bis zur Endstellung Matt / Remis; Je nach durchschnittlicher Spielstärke der verwendeten Engines und unter Beachtung das je höher der Elo-Durchschnitt, desto länger dauern die Partien). Meines Erachtens lag der große Schwachpunkt bei Schachprogrammen in der Vergangenheit im frühen Übergang zum Endspiel. Gerade in dieser Partiephase wurde in den letzten Jahren die größten Fortschritte erzielt. Endspielwissen wird heute im Jahr 2020 brutal errechnet. Mittelspielwissen stellt nach wie vor die wirkliche Herausforderung dar! Seinerzeit war das Paradebeispiel Ktulu von Rahman Paidar (Iran). Ktulu verzichtet komplett auf Endspieldatenbanken. Aufgrund einer effizienten Suche kann das Problem (wenig Endspielwissen) zumindest eingeschränkt werden. Der Programmierer von Ktulu konzentrierte sich dann bei seiner Entwicklung immer mehr auf spezielles Endspielwissen (Turmendspiele) und hatte sehr viel Spaß daran. Endspielschwächere Programme können mit der einfachen rohen Rechengewalt Gewinn- bzw. Remis bringende Wendungen selbst errechnen. Schon nach den ersten Zugriffen, auf 5-Steiner Endspieldatenbanken, nimmt die Prozessorleistung einer Engine um runde 70% ab. Die ersten Zugriffe sind je nach Aggressivität, früher oder später, im Grunde "leider" überwiegend zu früh sichtbar. Dem Vorteil einer gesicherten Datenbankabfrage steht die Prozessorbremse als Nachteil gegenüber. Bei genauer Betrachtungsweise erst recht, denn wir wissen das Programme im Übergang zum Endspiel an Spielstärke verlieren. Eine aggressive Table-Base nutzende Engine kann durch die beschriebene Prozessorbremse, bei in der Regel begrenztem Endspielwissen, Leistung verlieren. Erst recht dann, wenn eine effiziente Suche, also die rohe Rechengewalt, stark gemindert wird. Dieser Nachteil überwiegt dem doch _so sicher_ vermuteten Vorteil. Auch dürfen wir nicht vergessen, dass in ca. 95% aller Fälle eine Engine durch Table-Bases nicht zwingend besser punktet. Die erspielten Vorteile sind in der Partiephase meist schon längst vorhanden und durch Table-Bases wird uns lediglich ein schnelleres und vor allem saubereres Ergebnis präsentiert. In vielleicht 5% aller Fälle wirken sich die Table-Base Ergebnis steigernd aus, wenn die andere Engines nicht auch auf Table-Bases zugreifen kann.

Eine Verdoppelung der Geschwindigkeit auf heutiger Standard-Hardware bringt ca. 40-60 Elo. Ziehen wir Eröffnungsbuchzüge und klare Endspielzüge bei 6 oder weniger Figuren auf dem Brett ab (4-Steiner reichen aus, später mehr), haben wir bei einer durchschnittlichen Partielänge von 86 Zügen = ca. 50-55 Züge, die von einer Engine berechnet werden. Von diesen 50-55 Zügen sind sicherlich ca. 15 klare Züge (Schlagzüge, erzwungene Züge etc..). Verbleiben 35-40 Züge, die verschiedene Engines natürlich auch verschieden bewerten. Wenn 35-40 Züge durch eine Verdoppelung der Hardware für 40-60 Elo sorgt, wie groß wäre der Einfluss bei der Prozessorbremse von 100 auf 30% für vielleicht 5-8 Züge aufgrund ins Nirwana laufenden Table-Base Zugriffen, bei in etwa 15 Figuren auf dem Brett? Immer mit dem Hintergedanken, dass die meisten Partien erst nach ca. 50-60 Zügen entschieden werden und Table-Base Zugriffe vermeldet werden. Die Prozessorbremse kann ca. für 15 Elo sorgen. Und das alles für ca. 10 Elo mehr, durch Punkte, die durch Table-Bases eingefahren werden? Bei dem endspielschwächeren Programm AnMon kam ich bei einem Experiment gar zu dem Ergebnis, dass runde 25 Elo durch 5-Steiner Table-Bases verloren wurden. Je nach Aggressivität bei Table-Base Zugriffen, kann sich dann doch alles noch die Waage halten. Fruit greift z. B. erst in der Grundeinstellung auf die 5-Steiner zu, wenn noch 8 Steine auf dem Brett sind (sehr vernünftig). In diesem Fall könnten die Table-Bases minimal etwas bringen!

Ein anderer Tatbestand der nicht zu unterschätzen ist:
Unsere Rechner laufen bei der Erstellung einer Ratingliste meist 24 Stunden täglich. Bei 5-Steiner Table-Base Zugriffen können wir uns sicher sein, dass es zu durchschnittlich 500 - 4.000 Festplattenzugriffen in der Sekunde kommt. Festplatten sind zwar nicht mehr so kostspielig aber mit Gewalt sollten wir keinen Verschleiß provozieren. Eine Neu-Installation kann ferner sehr zeitaufwendig und vor allem teuer werden. Sie können die Nalimov Table-Bases etc. auch auf einen USB-Stick kopieren. Das ist sehr sinnvoll, um die vielen unnötigen Festplattenzugriffe zu vermeiden. Heute behelfen wir uns mit schnellen SSD Festplatten und grenzen dieses Problem ein.

Meine Ratinglisten / Turniere:
Ich mache es mir sehr einfach und verzichte auf 5-Steiner Table-Bases. Die 4-Steiner reichen allein deswegen aus, um Partien zu verkürzen (Zeitersparnis durch klare Remis- oder gewinnbringende Fortsetzungen) und fehlendes Endspielwissen nur in klaren Fällen zu kompensieren. Zum Beispiel das Endspiel: König / Dame gegen König / Turm. Ich vermute, nach meinen heutigen Erkenntnissen, dass zumindest die 4-Steiner für maximal 10 Elo mehr sorgen. Die 5-Steiner für eine Verringerung der Spielstärke um ca. 5-10 Elo zur Verantwortung gezogen werden können. Allerdings lasse ich bis zum Matt spielen und deaktiviere die Aufgabefaktoren der Engines bzw. auch mögliche Einstellungen der jeweiligen Benutzeroberflächen (GUIs). Die Endspieldatenbanken, das Betriebssystem und die Engines selbst liegen auf einer schnellen SSD HD. Dies verringert wie gesagt die Zugriffszeiten deutlich bzw. werden auf fast Faktor 0 heruntergefahren.

Heute sind schnelle SSD Festplatten nicht mehr wegzudenken.

Nalimov Table-Bases / Shredderbases / Gaviotabases / Syzygybases
Sofern Engines eigene Entwicklungen von Endspieldatenbanken anbieten, setzte ich diese natürlich auch ein (Shredderbases). Was unterstützt wird, kommt bei meinen Ratinglisten mithin zum Einsatz (Nalimov Table-Bases oder die neueren Gaviotabases oder syzygybases). Die syzygybases haben sich heute als Standard herauskristallisiert.

Zusatz, erstellt am 13.09.2010:
Aufgrund schneller Speichermedien (z. B. USB-Sticks) kommt es nicht mehr zu dieser beschriebenen Prozessorbremse. Meine Ausführungen zu diesem Thema basieren noch auf ältere Berichte, die vor teilweise vor 20 Jahren fertigte. Selbst benutze ich heute auch schnelle SSD Festplatten. Dennoch werden Systeme immer noch ohne SSD Festplatten angeboten und von daher möchte ich die Hinweise aus dieser Datei nicht löschen.

Zusatz, erstellt am 26.06.2020:
Nach wie vor nutze ich 4-Steiner Endspieldatenbanken, um wie beschrieben, Partien zu verkürzen bzw. lange Endspielschleifen zu vermeiden. Dies allein um den Züge Durchschnitt der Partien ohne Aufgabefaktor geringer zu halten. Datenbankabfragen von 5-Steinern oder 6-Steinern greifen mir für die Messung einer Engine-Spielstärke zu sehr in die eigentlich maßgebliche programmiertechnische Leistung des Programmierers ein. Jegliche unnötige Datenbankabfragen (Eröffnungsbücher mit zu langen Varianten, Endspieldatenbanken größer als 4-Steiner) beeinflussen die tatsächliche Messung der Spielstärke einer Engine. Mein Ziel ist es immer gewesen die "Nackte" Spielstärke einer Engine zu messen. Zwecks Chancengleichheit sollten Einflüsse von Datenbankabfragen für Messungen bei direkten Vergleichen vermieden werden.

5. Hash-Tables / Permanent Brain (ponder)

Grundsätzlich gilt zum Thema Hash-Tables die folgende These:
Der Hash-Füllungsgrad, bei der durchschnittlich verwendeten Bedenkzeit, sollte bei der gefräßigsten Engine in einem Turnier 50% betragen. Beträgt die durchschnittliche Bedenkzeit 30 Sekunden, sollte nach 30 Sekunden, in einer Endspielstellung, der Füllungsgrad bei 50% liegen. Schachprogramme nehmen sich mal mehr mal weniger Zeit und es könnte sein, dass bei der durchschnittlichen Bedenkzeit von 30 Sekunden für einen Zug 60 oder mehr Sekunden verwendet wird. Hashtabellen wirken sich erst im Endspiel Elo steigernd aus. Es ist immer besser eher zu viel als zu wenig Hashtabellen zu geben. Das Engines durch zu große Hashtabellen benachteiligt werden, konnte ich nie feststellen (allerdings sollte das nicht übertrieben werden)! Diese Aussage mag vielleicht in sehr wenigen Ausnahmefällen zutreffen aber selbst dann kaum zu relevanten Abweichungen ermittelter Elo-Zahlen führen. Sehr gerne bezeichnen wir Hashtabellen auch als "kleines Permanent Brain".

Hinweis:
Durch Hashtabellen werden berechnete Züge im zur Verfügung gestellten RAM gehalten. Engines können beim nächsten Zug auf diese Berechnungen zurückgreifen und ersparen sich unnötige Rechenzeit.

Berechnet eine Engine den nächsten Zug, während der Gegner selbst am Zug ist (in der Annahme das der Gegner, die selbst berechnete beste Zugfolge wirklich ausspielt), sprechen wir von Permanent Brain oder einfach "Ponder". Ponder=on ist der Regelfall in einem Engine-Engine Match auf zwei Systemen, z. B. bei einem offiziellen Wettkampf, wie einer Computerschach-Weltmeisterschaft, Autoplayer Partien. Auf einem Ein Prozessor-System führt Ponder=on zu einer Teilung des Prozessors. Ponder-Treffer gibt es in durchschnittlich ca. 25-35% der Züge einer Schachpartie zweier in etwa gleichstarker Engines, sofern Züge durch Datenbankeinflüsse (Eröffnungsbuch) bei dieser Betrachtung außen vor bleiben. Bei durchschnittlich "nur" 25-35% Ponder-Treffer führt die Teilung des Prozessors (50%-50%) zunächst mal zu einer Verlangsamung der Engine-Leistung. Eine einfache Aussage, wenn es bei 50%-50% nur zu 25-35% Ponder-Treffern kommt. Turniere mit Ponder=on auf einem Ein Prozessor-System machen keinen Sinn. Die meisten User von Schachprogrammen spielen ihre Engine-Engine Partien / Turniere ohne Ponder, offenbar mit dem Hintergedanken mehr Partien zu produzieren. Notwendig ist das in Zeiten von Mehrprozessor-Systemen allerdings nicht mehr. Ob heute Engines wirklich und wesentlich vom Pondern beeinflusst werden bleibt fraglich. Auf Anhieb fällt mir die Engine King of Kings ein. Der wesentliche Vorteil für den Beobachter von Eng-Eng Partien bei Ponder=on ist unzweifelhaft, dass die GUI zwei laufende Analysen gleichzeitig anzeigt (1 eigener Prozessor / Core für jede Engine). Das Beobachten von solchen Ponder=on Partien ist nicht nur viel spannender, sondern wir können in zwei stetig mitlaufenden Analyseprozessen Einblick nehmen. Es macht also Sinn Engines bei Ponder = on gegeneinander antreten zu lassen aber in diesem Fall sollte die Bedenkzeit höher eingestellt werden. Für solche Partien nutze ich z. B. gerne die Zeitkontrollen 40 Züge in 20 oder 40 Züge in 40 Minuten. Andernfalls habe ich Probleme zwei mitlaufende Engines-Analysen zu folgen.

Ponder=Off Partien erscheinen zunächst realitätsfremd, denn der Mensch schaltet auch nicht sein Gehirn ab, wenn der Gegner am Zug ist. Bei überschaubaren Pondertreffern gilt Ponder=on heute eher als Ressourcenverschwendung. Computerschach und menschliches Schach war von je her nie vergleichbar. Für die Messung der Spielstärke sind Ponder=Off Partien besser geeignet um wie beschrieben nicht unnötige Ressourcen im Raum verpuffen zu lassen. Strom ist teuer geworden!!

Dieses Dokument habe ich vor ca. 20 Jahren zur ATL-4 (Arena Tourney League) erstellt und wurde
in den letzten Jahren mehrfach überarbeitet, neue Erkenntnisse sind eingeflossen.