Hallo Frank,

genau diese Aussage/Einschätzung gilt es zu überprüfen... und genau dazu werde ich meinen Beitrag leisten.

Gruß
Egbert

20% sollten für in etwa 16 ELO-Punkte sorgen. Damit lassen sich drastisch andere Ergebnisse nicht erklären. Es ergibt im Grunde auch nicht wirklich Sinn, den Takt erst danach zu erhöhen, weil das alles chip-intern ist. Die Takterhöhung besteht softwareseitig aus leicht abgewandelten Konstanten für die Programmierung der Taktstufe der CPU, das ist alles. Da ist auch keine Verdrahtung oder Layout beteiligt, durch die zunächst einmal nicht der volle Takt erreichbar ist.

Außer man nimmt zunächst eine andere CPU, aber wieso sollte man sich den zusätzlichen Aufwand überhaupt machen, statt gleich die richtige zu verbauen?

Eine Möglichkeit wäre, daß man bewußt nicht die volle Taktgeschwindigkeit in der Betaversion programmiert hat, um nicht die ganze (menschliche, nicht elektrische ^^) Spannung aufs Seriengerät zu ruinieren.

Ein anderer Grund können Compiler-Optimierungen sein, die man für die Beta nicht vorgenommen hat, so daß die Software tatsächlich deutlich langsamer lief. Das würde ich auch so machen, um im Falle eines Absturzes bessere Infos zu haben, wo genau der Crash passiert ist. Speziell Inlining sollte man dem Compiler dafür gezielt untersagen, aber auch einen ganzen Zoo an weiteren Optimierungen.

Oder daß Debug-Checks in der Software drin sind, sog. Asserts, mit denen die Software selber prüft, ob immer alle Parameter beim Rumrechnen korrekt sind, um Instabilitäten zu verhindern. Das ergäbe dann eine Fehlermeldung statt eines Absturzes. In der Finalversion blendet man die aus, wenn sie reifgetestet wurde und diese Checks nicht angeschlagen haben.

Und natürlich, daß softwareseitig noch tatsächliche Verbesserungen stattgefunden haben können von der Beta zur Serie, u.a. nämlich anhand der Ergebnisse des Beta-Tests. Dafür macht man den ja.

Den braucht man aber auch nicht für den Code, sondern das bekommt man eigentlich nur mit Daten voll. Konkret wäre hier ein größeres und womöglich auch besser abgestimmtes Eröffnungsbuch zu nennen. Ein Programm kann ganz beachtlich damit patzen, daß es formal gesehen korrekte Eröffnungen wählt, mit denen es danach aber nichts anfangen kann. Oder ein fehlerbereinigtes Buch, denn heutzutage kann man ja mit einem entsprechenden Test-Framework das gesamte Eröffnungsbuch auch automatisiert durchtesten.

Außerdem wären auch noch zusätzlich Endspieltabellen möglich, wobei da aber auch nur "König+Bauer gegen König" sinnvoll wäre. Die Mattführung gegen den alleinstehenden König braucht keine Tabelle, und die nächste wirklich relevante "König+Turm+Bauer gegen König+Turm" läge dann bei um die 30MB, paßt also eh nicht mehr rein.

Hallo,

ich glaube meine vorherige Antwort ist etwas untergegangen.
Meines Erachtens wurde nicht nur die Taktfrequenz vom Prototypen erhöht von 100 auf 120Mhz, sondern auch der Arbeitsspeicher von 80KB auf 160KB verdoppelt, was den Speicher für HT fast verdreifacht im Vergleich zum Prototypen.

Viele Grüße
Jürgen

Richtig der Hash wurde verdoppelt.

Gegen welches Gerät soll ich denn nun das nächste Match beginnen? keine Wünsche ?

__________________
Die ganze Welt des Computerschachs

Hallo Thorsten,

hast Du den Saitek Risc 2500, bzw. Mephisto Montreux?

Gruß
Egbert

Am Aussage kräftigsten wäre, wenn Du und Egbert mal gegen den gleichen Gegner spielt, bei:

1.) gleicher Eröffnungswahl und
2.) ausgeschaltetem Zufallsgenerator
3.) deaktiviertem Permanentbrain von allen Geräten, damit Bedienzeiten bzw. Bedienverzögerungen keine Rolle spielen.

Dann hätte man mit einer einzigen Partie zumindest weitgehende Klarheit, ob die Geräte nun identisch sind - oder nicht.

Ich kann da nur die chessmachine 512 anbieten mit 16 MHz oder so.
Dann würde ich The King 2.54 nehmen.

Der 100 MHz mit 80 KB Hash hat gegen die chessmachine mit The King 3 Partien gewonnen und 2 remisiert. D.h. 4-1 gespielt !!

So richtig Sinn macht das nicht. Wenn schon der lahme Kasten 4-1 gespielt hat...

__________________
Die ganze Welt des Computerschachs

Hallo Thorsten,

Also damals beim MCG hat Millenium mitgeteilt, dass von den 64KB 32KB für HT zur Verfügung stehen.
Wenn das Programm nun identisch geblieben ist, würde das für den Prototypen mit 80KB bedeuten, dass dieser dann 48KB für HT hat und für den nun herausgekommenen MCGPro mit 160KB, stehen also 128KB für HT zu Verfügung.
Das heisst also, der Prototyp hat 1,5x soviel HT und der MCGPro hat 4x soviel HT wie der erste MCG. Oder im Vergleich Protoyp und MCGPro ein Faktor von 2,7.

Viele Grüße
Jürgen

Hi Thor, mich interessieren die Spielstärkeunterschiede zwischen dem MCG und MCGPro im praktischen Spiel, deshalb wäre es schön die Matches von Lars Sundin mit dem MCGPro nachzuspielen. Da hätte man einen direkten Vergleich, wie sich die Geschwindigkeit bemerkbar macht.

MCG - Atlanta 10:10 http://www.hiarcs.net/forums/viewtopic.php?t=7767
MCG - Star Diamond/Sapphire 13:7 http://www.hiarcs.net/forums/viewtopic.php?t=7672
MCG - Nigel Short 12:8 http://www.hiarcs.net/forums/viewtopic.php?t=7500

__________________
http://chess-computer.blogspot.com/

Hallo Thorsten,,

Wolfgang hat ja einen sinnvollen Vorschlag gemacht, ich denke wir können es allerdings noch leichter und genauer (keine weiteren Abhängigkeiten zwischen den Gegnern) feststellen, ob es Unterschiede zwischen den Geräten/Engines beim CGP gibt. Micha hat bereits in diesem Thread die Ergebnisse des CGP zum BT-2630 Test gepostet, s. Beitrag #143

Ich denke wir sollten einfach diesen Test auch noch durchführen, ich komme allerdings erst ab dem Wochenende dazu, damit zu beginnen. Andere CGP-Besitzer sind natürlich auch herzlich eingeladen, den Test durchzuführen und die Ergebnisse zu posten

Ist das für Dich Ok Thorsten?

Gruß
Egbert