optimize 1366x768

 

Beeinflussungsfaktoren
back to Frank's Chess Page

® Copyright: Frank Quisinsky
Last changes: February 15th, 2016, 12:00

 

Seit nunmehr ca. 19 Jahren nutze ich Engines für so genannte "Engine-Engine" Turniere / Ratinglisten. Es gibt einen Hauptgrund, warum ich ausgerechnet diesen Bereich des Computerschachs zu meinem Lieblingsthema 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, das 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 Turnieren 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 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?

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.

 

Unsichere Beeinflussungsfaktoren:
Eine ganze Reihe unterschiedlicher Faktoren bereitet uns Kopfzerbrechen? Stimmen überhaupt die eigenen Resultate und warum kommt es oftmals zu gravierenden Abweichungen zu anderen verfügbaren Ratinglisten? 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 letztendlich, 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. Grundsätzlich gilt, dass der eigene Spaßfaktor 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.

 

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 gönnen? Möchten Sie möglichst viele Engines einpicken, sollte die Zeit heruntergefahren werden wenn aussagekräftige Ergebnisse Ihre Zielsetzung sind. Schon dieser Punkt sorgte in der Vergangenheit für heftige Diskussionen. Verfechter "längerer Bedenkzeiten" verurteilen die Bemühungen der Verfechter "kürzerer Bedenkzeiten". Diese ganze Fechterei erinnert an die drei Musketiere (lange, mittlere und kürzere Bedenkzeiten). 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 an Bedenkzeit auch unterschiedliche Ergebnisse, im direkten Vergleich zu anderen Engines, produzieren (Stockfish wird z. B. stärker bei längeren Bedenkzeiten, Houdini bei kürzeren Bedenkzeiten).

Allerdings vertrete ich die Auffassung, dass die Turnierbedenkzeiten (40 Züge in 120 Minuten, 40 Züge in 150 Minuten) im Computerschach nicht die Königsdisziplin stellen. "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. 17 Jahren heute nur ein Blitzlevel (Vergleich: 486er 33 MHz zu einem Intel i7 mit 3.5Ghz).

Zu bedenken ist auch, dass aufgrund der Kompilierungen von Schachprogrammen, auch 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.

Vorteile: Bei der SWCR2 spielen derzeit 21 der weltbesten Engines. Jede Engine hat 50 Partien gegen jede andere Engine zu spielen. Als Bedenkzeit setze ich 40 Züge in 5 Minuten. Diese Bedenkzeit liegt in einem zeitlichen Rahmen und ich produziere damit auf Dauer logisch aussagekräftige Ergebnisse. Als Hardware setze ich zur Zeit einen meiner i7 Systeme ein. Ferner versuche ich möglichst viele unterschiedliche Engines einzusetzen. Das ist heute aufgrund der "Clone-Problematik" schon eine echte Aufgabe herauszufinden, ob sich Engines wirklich unterscheiden.

Nachteile: Der Lerneffekt durch die schnellen Bedenkzeiten bei dem hohen Level der Engines lässt nach. Auch wenn eine Partie, bei der von mir verwendeten Bedenkzeit, durchschnittlich ca. 20 1/2 Minuten dauert, fällt es mir beim Zusehen sehr schwer, aufregende Wendungen zu verfolgen und zu verstehen. Die durchschnittliche Spielstärke der 21 weltbesten Engines liegt ca. 1.000 Elo über die eines starken Vereinsspielers, der vielleicht auf eine Leistung von 1.800 Elo kommt. Je weniger Zeit desto mehr sich bildende Fragezeichen beim Zusehen von Engine-Engine Matches.

 

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 von Einst praktisch verschwunden sind.

 

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ücher müssen wir zunächst den Sinn des Einsatzes hinterfragen. Steht z. B. ein großes Turnier an, wird fast jeder Programmierer oder Eröffnungsbuch-Autor versuchen, Elo-Pünktchen mittels Manipulation durch Tuning herauszukitzeln. Auf diesen 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 überhaupt 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, z. B. das Eröffnungsbuch von Sedat Canbaz. Viele Anhänger der immer beliebteren Chess960 Variante spielen nur deswegen gerne Chess960, weil sie der Eröffnungstheorie überdrüssig sind. 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 bis hin zum Tuning durch Book-Learning.
d. Viele Engines spielen stur die nach eigener Ausspielwahrscheinlichkeit besten Varianten. Dies führt zu doppelten oder zumindest weitläufig doppelten Partien!
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. Eröffnung wird immer gerne als Paradebeispiel herangezogen. Computerschachprogramme sollten z. B. die französiche Eröffnung oder viele Varianten der holländischen Eröffnung mit Schwarz meiden!
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.

Letztendlich steht zu Recht 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 weit unterlegen sind.

Bei der SWCR2 benutze ich ein in der Zeit vom 09.07.2010 - 16.01.2012 entwickeltes eigenes "Random Buch.
Siehe hierzu:
SWCR1 opening book

 

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 ineinander greifende Datenbanken abgefragt. Die 4-Steiner oder 5-Steiner Table-Bases sollten demnach stets komplett sein, schon alleine 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.

 

Table-Bases sind speicherhungrig!

Beispiel zu den 5-Steinern:

 21 MB für die Entkompremierung der 5-Steiner Table-Bases für Engine A
 21 MB für die Entkompremierung der 5-Steiner Table-Bases für Engine B
 32 MB Cash für die Table-Bases für Engine A
 32 MB Cash für die Table-Bases für Engine B
------
106 MB notwendiger RAM

 

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 90 Zügen bei ca. 2.875 durchschnittlicher Elo (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 dauert die Partien) entschieden. Meines Erachtens liegt der große Schwachpunkt bei Schachprogrammen im frühen Übergang zum Endspiel. Endspielwissen ist schwierig zu implementieren und nur sehr wenige Schachprogramme warten mit enormes Endspielwissen auf, Paradebeispiel ist Ktulu von Rahman Paidar (IRAN). Ktulu verzichtet daher komplett auf Endspieldatenbanken. Aufgrund einer effizienten Suche kann das Problem (wenig Endspielwissen) zumindest eingeschränkt werden. Endspielschwächere Programme können mit der einfachen rohen Rechengewalt dennoch 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, weil 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 ja 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. 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 90 Zügen = ca. 55-60 Züge, die von einer Engine berechnet werden. Von diesen 50-60 Zügen sind sicherlich ca. 15 klare Züge (Schlagzüge, erzwungene Züge etc..). Verbleiben 35-45 Züge, die verschiedene Engines natürlich auch verschieden bewerten. Wenn 35-45 Züge durch eine Verdoppelung der Hardware für 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 runde 45-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, aber dieser Effekt wird dann auch von den 4-Steinern erreicht!

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 kostspielig sein. 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.

SWCR:
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. 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. 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.

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 der SWCR2 mithin zum Einsatz (Nalimov Table-Bases oder die neueren Gavitobases oder Syzygybases.

Zusatz, erstellt am 13.09.2010:
Aufgrund schneller Speichermedien (z. B. USB-Sticks) kommt es nicht mehr zu dieser beschriebenen Prozessorbremse. Mein Ausführungen zu diesem Thema basieren noch auf ältere Berichte, die vor teilweise mehr als 10 Jahren fertigte. Schachfreund Stefan Pohl wies mich im CSS Forum darauf hin. Selbst benutze ich heute eher schnelle SSD HDs.

Lektüre zum Thema (Bericht von Lars Bremer und Gerhard Sonnabend):
http://www.computerschach.de/index.php?option=com_content&task=view&id=510&Itemid=272

http://www.computerschach.de/index.php?option=com_content&task=view&id=255&Itemid=274

 

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 Permament 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 etc.. Auf einem Einprozessor-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 Einprozessor-System machen kaum 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 Dual und Quad Core 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.

Ponder=Off Partien sind meines Erachtens realitätsfremd, denn der Mensch schaltet auch nicht sein Gehirn ab wenn der Gegner am Zug ist.

 


Zusammenfassend:

Die Auswirkungen bewerte ich mit 1-5 Sternen.
Je mehr Sterne, desto höher der Beeinflussungsfaktor.

01. Bedenkzeit
Bei der heutigen Hardware ist es fast egal ob Sie kurze oder mittlere Bedenkzeiten einsetzen. Die Ergebnisse werden nur geringfügig (+-25 Elo) voneinander abweichen (Annahme bei gleicher Anzahl der Gegner und sonstigen gleichen Voraussetzungen). Wählen Sie eine Bedenkzeit, bei der Sie noch folgen können. Bei Partie in x Minuten oder den Fischer Zeitkontrollen wird teilweise das Zeitmanagement diverser Engines nicht optimal genutzt. Das kann Auswirkungen haben allerdings fallen diese eher sehr gering aus. Mittlerweile sind die Engines so weit entwickelt, dass bei keinen der verwendeten Zeitkontrollen Engines die Zeit überziehen und mithin die Partie verlieren.
Auswirkung: **

02. Eröffnungsbücher / Vorgabestellungen
Setzen Sie vernünftige Eröffnungsbücher für Engine-Engine Turniere oder Ratinglisten ein. Es reicht aus, wenn die Tiefe nicht über 14 -20 Züge geht. Nutzen Sie für alle Engines das gleiche Buch, denn Sie wollen ja etwas vergleichen. Es kann nur das verglichen werden was auch gleich ist. Ich glaube nicht, dass der ganze Buchkomplex wirklich Vorteile bringt. Mit verwendeten Vorgabestellungen werden Sie vergleichbare Ergebnisse erzielen. Allerdings ist es deutlich spannender, ein breites nicht zu tiefes Eröffnungsbuch einsetzen.
Auswirkung: *

03. Endspieldatenbanken
Eine Alternative wäre es überhaupt keine Endspieldatenbanken einzusetzen und die GUI Option "GUI nutzt Endspieldatenbanken" einzuschalten.
Auswirkung: **

04. Hash-Tables
Stellen Sie die Hash-Tables auf keinem Fall zu niedrig ein. Bei 40 Züge in 5 Minuten reichen 256Mb, bei 40 Züge in 10 Minuten reichen 5126Mb, bei 40 Züge in 20 Minuten reichen 1.024Mb (auf aktueller 3.5 GHz Intel i7 / i5 / i3 Hardware). Sofern die Hash-Tables nicht zu niedrig eingestellt werden (darauf sollten Sie wirklich achten) ist im Grunde nur das Endspiel betroffen. Die "vermutlich" besseren Züge werden schneller gefunden.
Auswirkung: *

05. Permanent Brain (Ponder) on/off
Sie werden völlig andere Partien sehen, allerdings wirkt sich das nicht auf Statistiken aus. Dennoch vermute ich, dass viele Engines zumindest minimal von Ponder = On profitieren. Logischerweise die Engines, die in der Lage sind mit mehr Zeit an Spielstärke deutlicher zu gewinnen. Nach meinen heutigen Erkenntnissen vermute ich, dass Engines mit weniger Schachwissen mehr vom Pondern bzw. auch längeren Bedenkzeiten profitieren.
Auswirkung: **

06. Gleiche Anzahl von Partien / viele unterschiedlichen Gegner
Um ein genaues Rating zu ermitteln, benötigen Sie viele unterschiedlich spielende Engines. Diese sollten möglichst die gleiche Anzahl von Partien gegeneinander spielen. Interessant ist folgender Umstand:

Eine Ratingliste basiert auf 10 Engines. Jede Engine spielte 100 Partien gegen jede andere Engine, also 900 Partien pro Engine. Ist für eine Engine ein Angstgegner dabei wird trotz der vielen Partien ein Rating um einen größeren Elo-Wert abweichen, als bei einer anderen Ratingliste, in der z. B. 20 Engines 50 Partien gegeneinander spielen. Die Ratingliste mit 20 Teilnehmern produziert mithin die genaueren Ergebnisse. Selbst eine Ratingliste, in der wenige Engines dann z. B. 2.000 oder mehr Partien gespielt haben, bleibt ungenauer im Vergleich zu einer Ratingliste, die mehr Gegner aufweist. Je mehr Gegner desto höher die Aussagekraft des Ratings und desto weniger Partien werden notwendig sein.
Auswirkung: ****

07. Aufgabefaktor
Sofern sie Aufgabefaktoren (GUI oder Engine) nutzen, werden die Partien natürlich früher enden. Letztendlich sparen Sie Zeit und können mehr Partien produzieren. Allerdings werden Partien selten zu Unrecht abgebrochen. Wenn z. B. zwei Engines gegeneinander spielen, und sich bei der Konstellation KLB - K (falscher Läufer und Randbauer) bei +6 im Vorteil fühlen, die GUI mit Gewinn abbricht, ist das natürlich dumm. Es gibt weitere mögliche Konstellationen. Dennoch kommen solche Fallgestaltungen im Verhältnis eher selten vor. Wird ohne Aufgabefaktor gespielt sind wesentlich bessere Auswertungen der Ergebnisse möglich (Thema Endspielstatistiken).
Auswirkung: *

08. w32 (32-Bit) oder x64 (64-Bit)
Es ist bekannt, welche Engines von 64-Bit profitieren. Ferner sind viele 32-Bit Engines nicht 64-Bit kompatibel. Für die Erstellung einer Ratingliste sollten Sie gleiche Voraussetzungen wählen. Selbst bevorzuge ich es, 32-Bit / 64-Bit Engines getrennt zu testen. Ein Vergleich der Spielstärke zwischen w32 und x64 ist dennoch schwierig. Durch 64-Bit kommen Engines schneller auf Tiefe und gerade Engines, die mit mehr Zeit besser werden profitieren von 64-Bit. So die Vorgehensweise bei der SWCR1. Bei der SWCR2 nutze ich wenn verfügbar immer die x64 und wenn verfügbar natürlich die SSE42 oder AVX Variante auf dem verwendeten i7 System.
Auswirkung: **

Sehr schöne Äußerungen zu dem Thema gab Tord Romstad in einem Interview:
http://www.schach-welt.de/spezial/computerschach-/interviews-/tord-romstad-und-team-dt.html (deutsche Version)
http://www.schach-welt.de/spezial/computerschach-/interviews-/tord-romstad-and-team.html (englische Version)

09. 1-Core, 2-Cores, 4-Cores
Es ist bekannt, wie groß der Elo-Zuwachs durch 2 oder 4 Cores im Vergleich zu einem Core ist. Es kann interessant sein festzustellen, ob eine Engine im Vergleich zu einer anderen Engine besonders von der Mehrprozessorprogrammierung profitiert oder eher nicht. Allerdings kann das auch sehr einfach mit einer einzigen Stellung getestet werden. Es ist nicht notwendig die Engines hierfür tausende von Partien spielen zu lassen. 4 Cores sind natürlich für Analysezwecke interessant, genau wie x64 bzw. alle Spielstärke steigernden Faktoren, allerdings nicht für eine Ratingliste. Eine Ratingliste hat die Aufgabe Engines zu vergleichen und hierfür sollten möglichst alle Engines unter den gleichen Voraussetzungen gegeneinander antreten. Siehe auch der letzte Satz zu Punkt 08 (trifft auch hier zu).
Auswirkung: **

10. Benutzeroberflächen
Die Wahl der Benutzeroberfläche ist heute kein Thema mehr. Zumindest glaube ich nicht, dass hierdurch andere Ergebnisse bei Engine-Engine Turniere / Ratinglisten produziert werden.
Auswirkung: NICHT WICHTIG

11. Anzahl der Partien
Die Anzahl der Partien ist natürlich sehr wichtig. Grundsätzlich gilt, je mehr Partien, desto höher die Aussagekraft einer ermittelten Elo. Es stellt sich nur die Frage, wie viele Partien maximal notwendig sind, um ein gesichertes Rating einer Engine zu bewirken. Meines Erachtens wird ein Rating nach 400 Partien interessant, bei ca. 600 Partien aussagekräftig und bei ca. 800 Partien stabil. Zwischen 400 und 600 Partien verändern sich Ratings um maximal 10-20 Elo nach unten oder nach oben. Treffen Sie keine Aussage zu einer Spielstärke wenn nicht mindestens ca. 400 Partien gegen möglich viele Gegner vorliegen. Die Computerschächler sind sich über diesem Tatbestand, meist aufgrund eigener Erfahrungen, bewusst. Sehr wichtig hierbei ist auch der Umstand: Je mehr Engines eingesetzt werden und je höher die Spielstärke bzw. der Zeitfaktor ist, desto weniger Partien werden für aussagekräftige Ratings notwendig.
Auswirkung:
*****

12. Verlorene Partien auf Zeit
Solche Partien werden immer seltener. Dennoch werden Sie solche Partien in Ihren Datenbanken immer wieder finden. Wiederholen Sie die Partien einfach. Für eine Ratingliste sind die Auswirkungen eher gering. Es sei denn das eine Engine unter einer Benutzeroberfläche wirklich Probleme hat und z. B. ständig auf Zeit verliert oder die Table-Bases nicht richtig nutzt. Das sollten Sie natürlich beobachten. Siehe auch Punkt 01.
Auswirkung: *

13. Sonstige Software die im Hintergrund aktiv ist
Sie sollten Ihr System schon vernünftig konfigurieren. Vermeiden Sie zu viele aktive Programme / Prozesse. Sofern Sie sich mit Betriebssystemen ein wenig auskennen, sollten Sie alle unnötigen Prozesse (Start / Systemsteuerung / Verwaltung / Dienste) deaktivieren.

Vorsicht:
Deaktivieren Sie notwendige Prozesse wird Ihr Betriebssystem unter Umständen nicht mehr hochfahren! Vergewissern Sie sich, welche Prozesse deaktivert werden. Zu dem Thema gibt es sehr gute Webseiten, einfach googlen.

Ein Virenscanner muss nicht aktiv sein wenn Engine-Engine Partien laufen. Ein laufender Kaspersky verursacht während eines Aktualisierungsprozesses "Zeitüberschreitungen bei laufenden Eng-Eng Matches. Achten Sie darauf, dass ausreichend Arbeitsspeicher zur Verfügung steht. Überprüfen Sie bei Eng-Eng Vergleichen, ob noch Arbeitsspeicher frei ist. Ein guter TIPP: Halten Sie ca. 20% Arbeitsspeicher bei laufenden Engine-Engine Matches frei.
Auswirkung: * - ***** (unbestimmt)

14. Betriebssysteme
Setzen Sie 32-Bit oder 64-Bit Betriebssysteme ein. Optimal wäre ein 64-Bit Betriebssystem, so können Sie mit 32-Bit als auch 64-Bit kompatiblen Engines spielen. Auf einem 64-Bit Betriebssystem laufen 32-Bit Engines ca. 0.6% langsamer. Für Computerschach bevorzuge ich selbst Windows 7 Professional x64.
Auswirkung: NICHT WICHTIG

15. Elo-Berechnungssysteme
Mit Bayesian, Elostat oder Ordo stehen drei Programme für Elo-Berechnungen zur Verfügung. Persönlich befinde ich aufgrund zahlreicher Auswertungen alle für geeignet. Darstellungen zu Spielstärke der künstlichen Intelligenz gehen meines Erachtens besser aber dafür müsste das Elo-System selbst kräftig überarbeitet werden. Ferner fehlen wirklich gute Tools um Statistiken zu erstellen. Festzuhalten bleibt, dass eine Ratingliste auch leicht unterschiedliche Ergebnisse ausgibt, wenn unterschiedliche Berechnungsprogramme benutzt werden. Auch viele Benutzeroberflächen berechnen Ausgaben in Elo. Auch diese Berechnungen weichen geringfügig voneinander ab. Sie sollten sich informieren wenn Sie Elo-Listen vergleichen. Bei der SWCR2 wird mit Elostat berechnet. Bei den Partie Downloads finden Sie die Berechnungen aller drei Berechnungsprogramme.

 

Dieses Dokument habe ich vor ca. 10 Jahren zur ATL-4 (Arena Tourney League) erstellt.
Die Datei wurde komplett zum Zweck der SWCR2 überarbeitet, neue Erkenntnisse sind eingeflossen.