[ News-Ticker ]   [ SWCR Engines TOP 20 ]   [ Interviews ]   [ Buch-Rezensionen ]   [ Downloads ]   [ Begriffserklärungen, Links ]   [ ToDo ]

[ zurück zur Software-Berichte Startseite ]   [ zurück zu SWCR *Aktuell* ]

Gehe zu weiteren SWCR Unterseiten:
[ Hinweise ]   [ Spielbedingungen ]   [ Updates ]   [ Engines ]

Beeinflussungsfaktoren

Seit nunmehr ca. 12 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 jetzt 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. 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 (Doch wird z. B. stärker bei längeren Bedenkzeiten, Hiarcs 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. 8 Jahren heute nur ein Blitzlevel (Vergleich: 486er 33 MHz zu einem Intel Core 2 Duo 8400 mit 3.0Ghz).

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. 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 SWCR spielen die 20 weltbesten Engines. Jede Engine hat 40 Partien gegen jede andere Engine zu spielen. Als Bedenkzeit setze ich 40 Züge in 10 Minuten. Diese Bedenkzeit liegt in einem zeitlichen Rahmen und ich produziere damit auf Dauer logisch aussagekräftige Ergebnisse. Als Hardware setze ich gleich schnelle Intel Systeme sein. 40 Züge in 10 Minuten bedeutet auch, dass es nicht zu unnötigen Zeitnotsituationen kommt.

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. 40 Minuten dauert, fällt es mir beim Zusehen sehr schwer, aufregende Wendungen zu verfolgen und. zu verstehen. Die durchschnittliche Spielstärke der 20 weltbesten Engines liegt ca. 900 ELO über die eines starken Vereinsspielers, der vielleicht auf eine Leistung von 1.800 ELO kommt.

2. Verwendete Benutzeroberfläche (GUI)
Es gibt eine Reihe von Benutzeroberflächen die sich für Engine-Engine Turniere oder Ratinglisten sehr gut eignen. Meist wird die Shredder, Fritz oder Arena GUI hierfür eingesetzt. Natürlich gibt es Vor- und Nachteile zwischen den genannten GUIs 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 20 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 lzur 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 die franz. 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.

Bei der SWCR benutze ich unterschiedliche Bücher. Unter der Shredder 12 GUI ein Buch von Sedat Canbaz als auch das sehr gute Shredder 12 Eröffnungsbuch von Sandro Necchi. Diese Bücher gehen nicht sehr tief in die Eröffnungstheorie. Bei der Erstellung einer Ratingliste wird die Spielstärke einer Engine ermittelt und nicht wie gut oder schlecht Datenbankabfragen sind. Bei der Fritz GUI verwende ich das Strong 2010 Buch. Dieses Buch ist Bestandteil vom ChessBase Power Book 2010.

4. Endspieldatenbanken (Nalimov Table-Bases, Shredderbases, egbb - BitBases)
Bei den Nalimov Table-Bases (Endspieldatenbanken) handelt es sich um einfache Datenbankabfragen, zu möglichen Endspielstellungen, bei wenigen Figuren (4-6 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.

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 85 Zügen (bis zur Endstellung Matt / Remis) 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 die Nalimov Table-Bases. 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 85 Zügen ca. 50 Züge, die von einer Engine berechnet werden. Von diesen 50 Zügen sind sicherlich ca. 15 klare Züge (Schlagzüge, erzwungene Züge etc..). Verbleiben 35 Züge, die verschiedene Engines natürlich auch verschieden bewerten. Wenn 35 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-50 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 egbb-BitBases oder Nalimov Table-Bases auch auf einen USB Stick kopieren. Das ist sehr sinnvoll um die vielen unnötigen Festplattenzugriffe zu vermeiden.

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.

Shredderbases / egbb - Bitbases
Sofern Engines eigene Entwicklungen von Endspieldatenbanken anbieten, setzte ich diese natürlich auch ein (wie bei den Table-Bases max. 4-Steiner).

5. Hash-Tables / Permanent Brain (ponder)

Grundsätzlich gilt bei Hash-Tables:
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.

Dieses Dokument habe ich vor ca. 3 1/2 Jahren zur ATL-4 (Arena Tourney League) erstellt.
Die Datei wurde komplett überarbeitet, neue Erkenntnisse sind eingeflossen.

® Copyright: Frank Quisinsky / SCHACHWELT
zuletzt aktualisiert am 16.05.2010, 12:45