Ich möchte mal ein Gedanken zum Thema Verdoppelung der Rechenleistung und der damit verbundenen Spielstärke vorstellen. Angeregt dazu wurde ich durch folgende Bemerkung:

Rückblick: Ganz zu Anfang rechneten Schachprogramme einfach an einer Stellung und gaben nach einiger (meist zu langer) Zeit einen Zug als Antwort zurück. Die ersten Programme rechneten bis zu einer bestimmten Tiefe und ab und zu verschätzten sie sich bei der benötigten Rechenzeit ganz kräftig und übertraten die erlaubte Bedenkzeit.
In den 1970ern setzte sich dann das "Iterative deepening" durch, es wird also erst bis Tiefe 1 gerechnet, dann folgt Tiefe 2, dann Tiefe 3 usw. (manche Programme fangen auch erst bei Tiefe 2 an). Dieses Vorgehen hat zwei Vorteile, zum einen können interne Heuristiken so den Suchbaum besser einschätzen und die Suche beschleunigen (die Berechnung der Tiefen 1, 2, 3, 4 und 5 ist schneller als wenn gleich Tiefe 5 angegangen würde) und zum anderen hat das Programm jederzeit einen besten Zug und kann auf Benutzereingaben oder Zeitrestriktionen reagieren. Es wird also nicht mehr eine feste Tiefe vorgegeben sondern Rahmenbedingungen geben vor "wie tief man kommt".

Eine grundsätzliche Aussage beim Computerschach ist nun, dass mehr Rechenleistung zu besserem Spiel führt. 1981 und 1983 hat das Belle-Team dies erstmals quantitativ untersucht. Dazu spielte Belle gegen sich selbst, immer dieselbe Bewertungsfunktion und eine fixe Tiefe. Daraus ergab sich für die geringeren Tiefen ein Unterschied von etwa 200-250 Elo pro Halbzug, der sich aber bei den größeren Tiefen abschwächte. Da ein Halbzug mehr ungefähr einen Faktor 6 in der benötigten Rechenleistung bedeutete kamen Zahlen von 60-100 Elo pro Verdopplung der Rechenleistung zustande.
Lange Zeit waren Brettcomputer in dieser gut untersuchten Region zu Hause und unveränderte Programme auf unterschiedlicher Hardware bestätigten den Effekt. Die Zahlen änderten sich wenig von Programm zu Programm und erst mit den Programmen auf immer schnelleren PC kamen in Region mit "Diminishing Return". So hat Darkthouht-Autor Ernst. A. Heinz Zahlen für die Tiefen 10-12 vorgelegt. Dabei darf man aber nicht vergessen, dass die Suchbäume schlanker geworden sind, eine neue Tiefe brauchte also nicht mehr das fünf- bis sechsfache an Zeit der vorherigen sondern nur noch den Faktor 2-3. Dennoch war zu sehen, dass mehr Rechenleistung alleine kein guter Weg sein wird.

Was bedeutet das für uns heute, wenn wir altbekannte Programme auf immer schnellerer Hardware laufen lassen (egal ob als Emulation oder "in echt")?

Zum einen verlassen wir schnell den Bereich der gesicherten Erkenntnisse. Der oben erwähnte Fritz1 wurde auf Pentiumrechnern und danach nicht mehr richtig getestet. Eine Extrapolation der 60-80 Elo pro Verdopplung auf einen Athlon2400 ist statistisch nicht gerechtfertigt, der Fehler ist sehr, sehr groß.

Zum anderen muss man sich überlegen, was bei einem schneller laufenden Programm anders ist als bei seinen langsameren Geschwistern. Wie beim Belle-Experiment angemerkt bleibt die Bewertungsfunktion ja gleich. Mehr als die darin erfassten Stellungsmerkmale werden nur allmählich durch taktische Erkenntnisse erweitert. Findet ein Programm ein bestimmtes Merkmal gut, dann bleibt es auch nach der Beschleunigung so, nutzt aber eventuell nicht mehr so viel. Zwei Beispiele:

Aufgrund geringer Suchtiefe versucht das Programm mögliche Gabeln statisch zu berechnen. Eine drohende Gabel braucht mindestens vier Halbzüge bzw. drei mit Ruhesuche (ich, Gabelzug, ich, Schlagzug) um entdeckt zu werden. Gelingt dies statisch entdeckt zu werden braucht es nur noch zwei Halbzüge (ich, Gabelzug). Ein Programm mit statischer Entdeckung von Gabelzügen kann also weiter schauen. Allerdings sind solch statische Merkmale nur begrenzt erkennbar. Zwischenschachs, Überlastung von Figuren, Ablenkung von Figuren und ähnliche Tricks sorgen dafür, dass eigentlich nur eine ausreichend tiefe Suche solche Fälle abdecken kann. Und selbst da gibt es noch den Horizonteffekt, Kombinationen sind tiefer als die Berechnung und werden daher zu spät erkannt.

Viele Programme brauchen für die Eröffnung spezielle Bewertungselemente um Dummheiten zu vermeiden. So vergeben viele Programme einen Malus, wenn sich eine Leichtfigur auf d3/e3 für Weiß bzw. d6/e6 für Schwarz vor einen eigenen Bauern stellt. Kann die Suche nur wenige Halbzüge erfassen, dann hilft das meistens gut. Die wenigen Ausnahmen werden halt nicht erfasst und das Programm fühlt sich unwohl, wenn taktische Erwägungen den Zug dennoch als besten sehen (z.B. wenn sonst Material verloren geht). Sucht das Programm aber tiefer, dann werden Blockaden in den ersten Zügen der Hauptvariante nicht mehr erkannt wenn die Figur noch ein zweites Mal zieht. Wichtigeres Merkmal wäre also zu erkennen wann ein Tempoverlust vorliegt, etwas was bei wenigen Halbzügen Suchtiefe nicht sinnvoll ist.

Bei wachsender Suchtiefe werden also andere Merkmale wichtig, Dynamik muss stärker bewertet werden und statische Merkmale unterliegen verstärkt einer möglichen Falschbewertung.

Darf jetzt ein altes Programm mit einer für geringen Suchtiefe optimierten Bewertungsfunktion (optimiert natürlich unter den Bedingungen der Entwicklung des Programms wie verfügbare Tester, Konkurrenz, sonstige Nebenbedingungen) deutlich tiefer rechnen, dann besteht die Gefahr, dass die Bewertungsbaum immer wieder in eine bestimmte Richtung zieht und die Suche dynamisch in die andere. Dabei wird sich auf Dauer die Suche durchsetzen, aber jede Optimierung bei der Beschneidung des Suchbaums leidet darunter. Besonders ausgeprägt ist dies bei Selektivität im Suchbaum. Entscheidungen für eine Vertiefung oder flachere Suche eines Teilbaums beruhen teilweise auf der Bewertungsfunktion. Wenn diese aber gegen die Suche arbeitet, dann werden die falschen Teile des Suchbaums vertieft (und kosten Rechenzeit) und weg geschnitten (und damit was wichtiges übersehen).

Einige Programme zeigen dies sehr schön indem z.B. in der Eröffnung immer als ein hinterer Zug der Hauptvariante die Rochade auftaucht. Die Bewertungsfunktion will also rochieren, aber die Suche verschiebt es immer und immer wieder. Irgendwann steht der König immer noch in der Mitte und es ist zu spät, der Gegner konnte einen Angriff starten.

Langer Rede kurzer Sinn: Ein Programm kann leider nicht so einfach auf deutlich anderer Hardware eingeschätzt werden. Egberts Tests mit dem Revelation II zeigen deutlich die Grenzen von Glasgow und Dallas.

Vielen Dank für den ausführlichen Bericht. Deine Ausführungen zu Belle kenne ich wohl auch aus "Schach dem Computer". 200-250 Punkte pro Halbzug erschienen mir damals schon suspekt. Immerhin war man seinerzeit bereits bei etwa 8 Halbzügen auf Turnierstufe.

Ich möchte noch kurz etwas zu den Geschwindigkeiten ergänzen. "cpubenchmark.net" gibt beispielsweise Leistungswerte an für:

AMD Athlon II X4 630: 3169 Punkte
AMD Athlon 2400+: 462 Punkte

Diese Relation von Faktor 7 bestätigt - sehr genau - der Fritz_Chess_Benchmark_12.
ABER: Nur wenn mit vier logischen Prozessorkernen gerechnet wird. Lasse ich nur einen Prozessorkern ran, dann wird das Ergebnis etwa geviertelt.

Und genau so siehts dann auch unter MS-DOS aus. Das unterstützt nur einen Kern. Ist also so zusagen ein "Flaschenhals". Ein praktischer Test mit Ftitz 1 bestätigte das.
Um nach a2-a4 in den 12. Halbzug zu kommen, benötigt

AMD Athlon II X4 630: 12 Sekunden

Hallo Wolfgang,

eigentlich wollte ich hier nicht spezifische Hardware sprechen.
Nur so viel: Bei irgendwelchen Benchmarks dürfen nicht Äpfel mit Birnen verglichen werden. Also Mehrkernprozessoren sind ungünstig (außer man nimmt Werte für nur einen Kern), genauso aber unterschiedlich schnelle Speicher usw.

Dosbox wäre auch noch so ein gutes Werkzeug, das läuft auch ohne spezielles Geboote. Ich habe damit unter Win7 das gute alte "Pirates" aus DOS-Zeiten ans Laufen gekriegt. Läuft in nem DOS-Fenster, oder wahlweise als Vollbild.

Allerdings emuliert das gleich das gesamte System in Software, also auch die CPU. Man braucht also einen flotten Prozessor, wenn man emulierte 486er oder Pentium-Geschwindigkeit erreichen will.

Über die DOSBOX hat Theo in einem Parallelthread etwas geschrieben. Damit muss ich mich erst noch befassen.
Ich wählte, auch aus anderen Gründen, einen anderen Ansatz:
Auf einem Windows 7 - Rechner installierte ich die Software "Oracle VM VirtualBox". Und darin Win XP, Windows 98. Jetzt komme ich wieder über Windows 98 zu MS-DOS.
Aber die Geschwindigkeit darin ist mehr als schlecht.
Was oben der Rechner (12 Halbzüge nach a2-a4) in 12 Sekunden bewerkstelligte, dauert jetzt etwas weniger als 7 Minuten. Also 34 mal länger.
Nachtrag: Der PII/266MHz benötigt unter MS-DOS 01:56, also sechs mal so lang wie der AMD Athlon XP 2400+. Im Endeffekt liegen diese knapp 7 Minuten auf dem Niveau einen 486DX2/66 bzw. knapp darüber Richtung Pentium 60.

Gruß
Wolfgang

Hallo Wolfgang

Das kommt mir aber sehr langsam vor. Gerade VM sollte schneller als Dosbox sein.

Hab die gleiche Rechnerkonfiguration.
Meine Werte bei Fritz 1 9 sec und Gideon 1.0 rechnet bei a2-a4 zirka
1400000 pos/sec .

Mein System i7 CPU970 3,2GHz

Gruß Mark 1

Genau so ist es. Aber mein Ansatz war eigentlich, dass ich einen möglichst schnellen DOS-Rechner wollte, um die Schachprogramme zu testen.

Kleiner Schwenk in die Vergangenheit
Die "langsame" Seite von Fritz und Psion kennen ich auch. Angefangen mit einem Commodore PC 10-III, ein XT-Computer mit 8088-Prozessor (8 bit), der mit 4,77x2, also rund 9,5 MHZ lief.

Lösezeiten für dieses Studie (1. b4-b5!)

XT-8088, Commodore PC10-III (9.5 MHz): 12:40
intel 80286-16: 3:28
intel 80386-SX16: 3:15
intel 80386-SX25: 2:07
intel 80386-DX40: 1:11
Cyrix 486-DX40: 0:29
intel 80486-DX2/66: 0:20
intel Pentium 60: 0:17
Cyrix 486-DX2/100: 0:14
intel Pentium 90: 0:10

Die kursiv dargestellten Zeiten (für Psion Chess 1.1) ermittelte ich auf meinen eigenen PCs, die anderen auf Rechnern von Kollegen. Davon gab es genug im Studentenwohnheim. Erfreulicherweise auch viel Schach interessierte.
Also: Eine neue "Spielwiese" für Geschwindigkeitstests ist eröffnet.

Wie ist denn das eigentlich mit der VM von Win7-Professional? Das Hauptproblem von Win7 ist ja, daß es auf nennenswert gescheiten Rechnern notwendig 64bit ist und deswegen keine 16bit-Programme ausführen kann, wohingegen DOS-Programme (soweit ich erinnere) 16bittig sind.

Die VM von Win7 stellt einem ein XP-32 zur Verfügung, und dieses sollte ja dann DOS-Programme ausführen können. Ist ja auch speziell für Legacy-Anwendungen gedacht.

Alternativ, funktioniert vielleicht auch FreeDOS ( http://www.freedos.org/ )?

P.S.: Bei der Studie konnte ich nicht widerstehen und habe die eben in den CT800 eingehackt; dessen Cortex-M4 bei 168 MHz spuckt trotz natürlich anderer Software die Lösung nach 6 Sekunden aus. Das liegt in dem Bereich, den ich anhand der Coremark-Werte des 486-DX2 und des M4 auch erwarten würde.

Ich belebe diesen Strang mal wieder:

Solche Aussagen finden sich ja immer mal wieder. Aber woher kommen sie? Gibt es dazu Untersuchungen, z.B. durch statistisch aussagekräftige Turniere?

Ich habe zum Vergleich mal für 8 Programme die Zahlen der SSDF genommen und für unterschiedliche CPUs die Faktoren 3 (K6-2 450 -> Athlon 1200 und 486 50/66 -> Pentium 90) und 2,5 (Pentium 90 -> Pentium MMX 200) angenommen. Damit komme ich auf folgende Verbesserungen bei Verdopplung:

Rebel Century 4 66
Rebel 9 62
Rebel 8 56
Rebel 7 44
Chess Machine 117
Rebel 6 69
Polgar 71
MM IV 113

Damit kommt auf etwa 75+-25 mit Rebel 7, Chess Machine und MM IV außerhalb dieses Fehlerintervalls.

Vielleicht kann ja jemand anderes mal Vergleichswerte liefern, ich finde die Zahlen für Programme aus den 90ern jedenfalls nicht besonders.

MM IV und MM V haben mit den Schaetzle+Bsteh-Turbokits in der SSDF-Liste überdurchschnittlich zugelegt (was Dein Ergebnis für den MM IV ja zeigt)

Auch der Polgar 10 MHz legt gegenüber der 5 MHz-Version um >100 Punkte in unserer Aktivliste zu. Kann natürlich Zufall oder statistische Ungenauigkeit sein...

viele Grüße
Robert