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.