Hi Jürgen,

das hat eine Reihe von Gründen.

1) Wenn man mal eine Trefferrate von 100% unterstellt, würde das die Rechenzeit in Partien mit symmetrischer Zeitverteilung verdoppeln. Das wäre dasselbe wie eine Geschwindigkeitsverdoppelung, also ein Zuwachs um die 60 ELO.

Da das Programm anders als die allermeisten anderen Programme kein Verständnis für Eroberung des Raumes hat, sondern nur Mobilität erwägt, sind die Trefferraten typisch nur um die 25%, außer in erzwungenen Situationen. Damit wären dann noch etwa 19 ELO-Punkte gutzumachen, was bei ELO 2100 nicht mehr wirklich ins Gewicht fällt.

2) Der ganz große Haken wäre, daß der gesamte Kontrollfluß dafür umgeschrieben werden müßte. Derzeit geht Usermodus nicht parallel mit Berechnungen, weil der Kontrollfluß nahezu sequentiell ist (abgesehen halt von Interrupts).

Wollte man das ändern, dann wären die Mechanismen dafür auf der Entwicklungsplattform (x86) Multithreading, und auf der Zielplattform wäre es dann mal Zeit für ein kleines Echtzeit-Betriebssystem (es sind aber nur noch etwa 6 kB an freiem RAM verfügbar). Separate Stacks für die Threads wären auch noch ein Problem, weil sich Userthread und Computerthread dann vom Stackbedarf her addieren würden.

Die Codebasis würde auseinanderdriften, ebenso wie die vergleichbare Testbarkeit angesichts von Multithreading. Damit wäre aber eines der Hauptfeatures der Software verloren, nämlich daß man die eigentliche Applikation auch am PC weiterentwickeln und debuggen kann. Sogar Leute, die nichtmal eine Zielhardware haben, können derzeit Anregungen beitragen, weil sie das auf dem PC testen können. Und das auch noch auf jedem Betriebssystem, für das der Compiler GCC verfügbar ist (also alle).

Das vereinfacht außerdem eine mögliche Portierung auf Plattformen, die jetzt noch gar nicht existieren, weil die Unterschiede sich auf den Lowlevel-Treiber konzentrieren.

Es wird sogar PC-seitig noch schlimmer, weil das Thread-Handling unter Windows und Linux nicht identisch ist, so daß sich selbst die PC-Version dann noch in Linux und Windows zersplittern würde. Derzeit ist es egal, weil es eine singlethreaded Kommandozeilen-Anwendung ist. Das würde sogar unter DOS funktionieren.

Ich konnte heute übrigens erst wieder die PC-Version als Testplattform sehr angenehm nutzen. Bislang war der CT800 bei leicht schlechterer Stellung mit Remis durch Stellungswiederholung schnell zu einem Unentschieden zu bewegen. Das macht er jetzt nicht mehr unterhalb von 30 Zügen und wenn er nicht schlechter als -0.4 Bauerneinheiten steht, weil ich ihm die entsprechenden Züge einfach von seiner Zugliste eliminiere. Mit den Debugausgaben war auch schnell zu sehen, ob ich da auch das Richtige wegstreiche.

viele Grüße, Rasmus