Schachcomputer.info Community - Info: Millennium ChessGenius Pro

Schachcomputer.info Community (https://www.schachcomputer.info/forum/index.php)

- Die ganze Welt der Schachcomputer / World of chess computers (https://www.schachcomputer.info/forum/forumdisplay.php?f=2)

- - Info: Millennium ChessGenius Pro (https://www.schachcomputer.info/forum/showthread.php?t=5201)

Re: AW: Re: AW: Millennium ChessGenius Pro

Zitieren:

Zitat von Rasmus (Beitrag 60824)

Ach, Experte ist übertrieben - Hyatt, den sehe ich als Experten. Donninger allerdings auch. Ich habe nur etwas Erfahrung durch "learning by doing".

Man muß hierbei zwei Aspekte unterscheiden, erstens Performance und zweitens Sicherheit. Die Sicherheit kriegt man mit 64bit-keys in den Griff, die man zusammen mit der Position abspeichert.

Denn reine Indexkollisionen sind unbedenklich, sofern man beim konkreten Auswerten noch mitbekommt, daß zwar der Index, nicht aber der volle Schlüssel übereinstimmen. Das wirkt sich "nur" auf die Performance aus.

Ich nehme an, bei 160kB Hashtables wird Richard Lang auf ähnliche Probleme gestoßen sein wie ich. Sein Sourcecode ist nicht verfügbar, so daß ich nur mutmaßen kann, ob er womöglich eine ähnliche Lösung gewählt haben könnte. Grundsätzlich speichert der CT800 nicht den vollen 64bit-key einer Position, weil das eben ganze 8 Byte pro Position sind. Stattdessen werden nur die oberen 32bit eines 64bit-Keys gespeichert, und die unteren 12bit sind implizit schon im Index enthalten. Dadurch kommt man auf 48bit, was Hyatts Untersuchungen zufolge locker ausreicht.

Zusätzlich ist manchmal ja auch der beste Zug gespeichert, und ebenso wie Hyatt habe ich es bei tausenden Testspielen nie erlebt, daß das Debug-OOOPS erschienen wäre. Das käme, wenn der gespeicherte Zug in der Position nicht pseudolegal wäre, was bei einer Hashkollision höchstwahrscheinlich geschähe.

Das andere Problem ist die Performance, denn die Frage ist, wie geht man damit um, daß man viel weniger Hash-Einträge hat, als man gerne hätte? Klar wirken sich da 160kB negativ aus gegenüber mehreren MB. Da gibt's auch verschiedene Strategien, die man wählen kann.

Man kann "depth preferred" wählen, mit der Logik, daß das ja einen ganzen Suchbaum repräsentiert und deswegen sehr viel wert ist. Man kann aber auch das genaue Gegenteil machen, "leaf preferred", mit der Logik, daß dann die Treffer viel häufiger sein werden.

Entschuldige das Denglisch, aber in dem Bereich denke ich auf englisch, und ich muß erst übersetzen.

Mal ein konkretes Beispiel aus meinem Projekt, was mich übrigens ein komplettes Wochenende Vollzeit gekostet hat, das war echt übel. In einem Testspiel warf der CT800 ohne erkennbaren Anlaß seine Dame weg und verlor dann natürlich. Wie sich am Ende (vereinfacht) rausstellte, lag das aber nicht an Hashkollisionen, sondern im Suchbaum war die Stellung als mies erkannt worden, so daß jeder Antwortzug aufgrund der Suchbaum-Beschneidung letztlich als Unfug klassifiziert wurde. Mit dem Resultat, daß es keine brauchbaren Züge gab.

Da fehlerhafterweise nur die brauchbaren und nicht die vorhandenen Züge für die Patterkennung herangezogen wurden, erkannte der Suchalgorithmus fehlerhaft auf Patt, so daß das Wegwerfen der Dame als Remis fehlerkannt wurde. Da der CT800 ohnehin gerade etwas schlechter stand, war das eine attraktive Wahl. Ein Fehler, der übrigens bereits in der vor mir existierenden Codebasis vorhanden war, was das Debugging in einem nur halb verstandenen Algorithmus nicht gerade vereinfacht hat.

Aber solche krassen Fehler sind es, die zu total irrationalen Zügen führen können, und die dann gerne mal Hashkollisionen zugeschrieben werden. Ist halt eine bequeme Ausrede.

Dem kann ich mich anschließen; es ist nur so, daß ich von Hyatt ein quantitatives Paper erinnere, von Donninger nicht.

Hier übrigens der Link via wayback archive:

https://web.archive.org/web/20120614...ollisions.html

Nein, bislang nicht. Allerdings hatte ich vor einem Jahr auch noch keine Erfahrungen mit Schachprogrammierung.

Vielen Dank Rasmus, für die umfangreichen Erläuterungen und auch Darlegung Deiner eigenen Erfahrungen :top:

Gruß
Egbert

AW: Millennium ChessGenius Pro

Ts Ts Egbert, um diese Zeit noch Postings schreiben. Kannst Du nicht Schlafen oder was? :D

Re: AW: Millennium ChessGenius Pro

Zitieren:

Zitat von MaximinusThrax (Beitrag 60829)

Ts Ts Egbert, um diese Zeit noch Postings schreiben. Kannst Du nicht Schlafen oder was? :D

:D War gerade einmal aufgewacht und das Thema ist halt spannend, obgleich... um diese Zeit noch mehr "Verrückte" unterwegs zu sein scheinen ;)

Gruß
Egbert

AW: Millennium ChessGenius Pro

Hallo zusammen,
auf der Suche nach dem Ursprung der CGP-Engine habe ich, wie von Dirk (Supergrobi) vorgeschlagen, meinen alten Palm T/X reaktiviert, auf dem der Chess Genius in der Version 2.30 installiert ist. Ich bin gerade dabei, den BT-Test 2630 durchlaufen zu lassen, habe aber im Vorfeld die beiden Teststellungen von Wolfgang 2 (https://www.schachcomputer.info/foru...&postcount=231) und Sascha (Mythbuster) (https://www.schachcomputer.info/foru...&postcount=376) eingegeben. Ergebnis: CG Palm T/X hat auch nach 15 min Rechenzeit keinen blassen Schimmer. Er spielt die Fehlzüge Dxb7 bzw. Kh4. Es scheint ihm also schon damals einiges an Schachwissen verloren gegangen zu sein.
Sobald ich die BT-Ergebnisse habe, poste ich sie. Ein direkter Vergleich mit denen des CGP (den ich noch nicht habe) ist sicherlich sehr aufschlussreich. Vielleicht hier schon der Hinweis: Die BT-Teststellung 4 (Dxf7) löst Genius Palm T/X in 15 Sekunden: Die Versionen London, Vancouver, Berlin (auch Pro) und alle WM-Vorgänger schaffen es nicht in 15 min.
Grüße
Roberto

AW: Millennium ChessGenius Pro

Ihr Lieben,

wenn man sich in der SSDF-Liste anschaut, wie Programme auf "mobilen" CPUs so performen (ein paar Brett-Klassiker sind als Benchmark mit dabei):

Code:

38 Revelation II Hiarcs 14.1                2941   59   -54   158   63%  2851

69 Revelation Hiarcs 13.3 XScale 500 MHz    2771   57   -52   177   66%  2660

91 Revelation Shredder 12  XScale 500 MHz   2706   60   -58   140   56%  2665

107 Hiarcs Palm Chess 13.1 T5 XScale 416Mhz 2650   58   -57   143   52%  2636

116 Revelation Rybka 2.2  XScale 500 MHz    2629   47   -44   240   62%  2546

124 Revelation Deep Sjeng 3.0               2599   68   -76   100   37%  2692

151 Resurrection Rybka 2.2 StrongARM 203 MH 2485   43   -42   260   51%  2478

171 Resurrection Fruit '05 StrongARM 203 MH 2394   67   -62   120   60%  2321

172 Hiarcs 9.5a/9.6 Palm TungstenE OMAP 126 2392   34   -35   400   45%  2426

174 CEBoard Crafty 2004 HP RX4240  400 MHz  2373   48   -50   200   43%  2423

200 Chess Genius 3 Iphone 4 ARM A8 800MHz   2260   82   -69   100   69%  2122

205 Palm Tiger 2009 Tung C  400 MHz         2238   48   -51   200   41%  2304

206 Mephisto Genius 2.0  486/50-66 MHz      2236   23   -23   917   58%  2177

213 Chess Machine 30-32 MHz Schr?der 3.1    2209   28   -27   646   63%  2120

218 Meph Genius 68 030 33 MHz               2194   41   -40   287   53%  2174

229 Chess Genius 1.4 SX1  OMAP 310 120 MHz  2149   50   -47   210   60%  2081

231 Chess Genius 1.0  486/33 MHz            2140   31   -31   483   50%  2143

238 Chess Tiger 14.9 Palm m515 16MB 42MHz   2105   68   -75   100   39%  2183

256 Mephisto Berlin  68 000 12 MHz          2015   22   -22   986   57%  1968

267 Mephisto Portorose 68000 12 MHz         1947   24   -23   867   60%  1873

268 Mephisto Nigel Short 6502 5 MHz         1945   64   -60   128   58%  1890

287 Chess Genius 1.5 Palm m515 16MB 42MHz   1873   69   -81   100   32%  2004

290 Mephisto Roma  68000 12 MHz             1871   18   -18  1519   56%  1830

.
.
.
Dann sieht man, dass Chess Genius sowohl auf den 68er Palms

Code:

238 Chess Tiger 14.9 Palm m515 16MB 42MHz   2105   68   -75   100   39%  2183

287 Chess Genius 1.5 Palm m515 16MB 42MHz   1873   69   -81   100   32%  2004

.
.
.
.. als auch auf ARM 120 Mhz Prozessoren

Code:

172 Hiarcs 9.5a/9.6 Palm TungstenE OMAP 126 2392   34   -35   400   45%  2426

229 Chess Genius 1.4 SX1  OMAP 310 120 MHz  2149   50   -47   210   60%  2081

.
.
.
... sehr viel schlechter als die Konkurrenz performt. Jetzt wäre es noch spannend zu erfahren, ob insbesondere das C-Programm, das hier 240 ELO unter Hiarcs bei gleicher Rechenleistung gelistet wird, mit der Zeit irgendwie weiterverbessert wurde. Oder, ob es 1:1 im CGP drin steckt.

Sonnige Grüße
Theo

(der jetzt einen Dell Axim X51 ausgepackt hat :))

AW: Millennium ChessGenius Pro

Noch bemerkenswerter finde ich ja das hier:

Code:

200 Chess Genius 3 Iphone 4 ARM A8 800MHz   2260   82   -69   100   69%  2122

206 Mephisto Genius 2.0  486/50-66 MHz      2236   23   -23   917   58%  2177

Der Unterschied in der Spielstärke ist nicht viel über statistischem Rauschen. Ich habe mir mal die Mühe gemacht, die Coremark-Daten der CPUs rauszusuchen. Ein 486-DX2 hatte einen Coremark von 67. Ein Cortex-A8 hat bei 800MHz einen Coremark von 1900. Da der Cortex-A8 ein Singlecore ist, sind hier keine Verluste durch Parallelisierung zu bedenken.

Damit haben wir einen Faktor von 28 in der Rechenkraft. Bei 60 Elo pro Verdoppelung sollte man also eine Differenz von knapp 300 ELO zugunsten des iPhones erwarten.

Nun ist die Genius-Version auf dem PC höchstwahrscheinlich in Assembler geschrieben, das hat Lang ja seinerzeit von 68k-Assembler nach x86 portiert, während die ARM-Version (mangels ARM-Assembler-Version) wohl in C ist.

Aber: C ist nicht um einen Faktor von knapp 30 langsamer als Assembler. Typisch bringt C 80% der Geschwindigkeit, und einzelne Hotspots kann man immer noch mit Inline-Assembler lösen.

Um einen Faktor von 30 hinzukriegen, müßte man C schon so wie Basic in einem Interpreter laufen lassen.

AW: Millennium ChessGenius Pro

Zitieren:

Zitat von Theo (Beitrag 60835)

Ihr Lieben,

wenn man sich in der SSDF-Liste anschaut, wie Programme auf "mobilen" CPUs so performen (ein paar Brett-Klassiker sind als Benchmark mit dabei):

Code:

38 Revelation II Hiarcs 14.1                2941   59   -54   158   63%  2851

69 Revelation Hiarcs 13.3 XScale 500 MHz    2771   57   -52   177   66%  2660

91 Revelation Shredder 12  XScale 500 MHz   2706   60   -58   140   56%  2665

107 Hiarcs Palm Chess 13.1 T5 XScale 416Mhz 2650   58   -57   143   52%  2636

116 Revelation Rybka 2.2  XScale 500 MHz    2629   47   -44   240   62%  2546

124 Revelation Deep Sjeng 3.0               2599   68   -76   100   37%  2692

151 Resurrection Rybka 2.2 StrongARM 203 MH 2485   43   -42   260   51%  2478

171 Resurrection Fruit '05 StrongARM 203 MH 2394   67   -62   120   60%  2321

172 Hiarcs 9.5a/9.6 Palm TungstenE OMAP 126 2392   34   -35   400   45%  2426

174 CEBoard Crafty 2004 HP RX4240  400 MHz  2373   48   -50   200   43%  2423

200 Chess Genius 3 Iphone 4 ARM A8 800MHz   2260   82   -69   100   69%  2122

205 Palm Tiger 2009 Tung C  400 MHz         2238   48   -51   200   41%  2304

206 Mephisto Genius 2.0  486/50-66 MHz      2236   23   -23   917   58%  2177

213 Chess Machine 30-32 MHz Schr?der 3.1    2209   28   -27   646   63%  2120

218 Meph Genius 68 030 33 MHz               2194   41   -40   287   53%  2174

229 Chess Genius 1.4 SX1  OMAP 310 120 MHz  2149   50   -47   210   60%  2081

231 Chess Genius 1.0  486/33 MHz            2140   31   -31   483   50%  2143

238 Chess Tiger 14.9 Palm m515 16MB 42MHz   2105   68   -75   100   39%  2183

256 Mephisto Berlin  68 000 12 MHz          2015   22   -22   986   57%  1968

267 Mephisto Portorose 68000 12 MHz         1947   24   -23   867   60%  1873

268 Mephisto Nigel Short 6502 5 MHz         1945   64   -60   128   58%  1890

287 Chess Genius 1.5 Palm m515 16MB 42MHz   1873   69   -81   100   32%  2004

290 Mephisto Roma  68000 12 MHz             1871   18   -18  1519   56%  1830

.
.
.
Dann sieht man, dass Chess Genius sowohl auf den 68er Palms

Code:

238 Chess Tiger 14.9 Palm m515 16MB 42MHz   2105   68   -75   100   39%  2183

287 Chess Genius 1.5 Palm m515 16MB 42MHz   1873   69   -81   100   32%  2004

.
.
.
.. als auch auf ARM 120 Mhz Prozessoren

Code:

172 Hiarcs 9.5a/9.6 Palm TungstenE OMAP 126 2392   34   -35   400   45%  2426

229 Chess Genius 1.4 SX1  OMAP 310 120 MHz  2149   50   -47   210   60%  2081

Naja. Das Richard Langs Programm gegen Fritz, hiarcs oder shredder verliert ist ja eigentlich ganz normal. Das war ein anderes Paradigma.
Deswegen hat Richard ja auch nicht mehr viel gemacht im computerschach als die Handy/Tablet iOS/Android Adaptionen für kleines Geld im Internet zu verkaufen.

Shredder / hiarcs und Fritz sind Programme aus der PC Zeit.

Ich denke für die zukünftigen Schachcomputer Produktion müsste Ossi Weiner auf Programme dieser Art zurückgreifen. Programme die MP fähig sind und die sehr viel tiefer im SUCHBAUM vordringen.
Denn die Konkurrenz schläft ja nicht und bietet starke Stockfish Gegner mit hoher Elozahl.
Das sollte der Weg für Millennium sein um gegen Phönix , Pewatronic und DGT anzukommen.

AW: Millennium ChessGenius Pro

Zitieren:

Zitat von Rasmus (Beitrag 60838)

...
Um einen Faktor von 30 hinzukriegen, müßte man C schon so wie Basic in einem Interpreter laufen lassen.

Das trifft es ziemlich gut. Vor zwei Jahren führte ich eine Simulation im Zusammenhang mit einer mathematischen Formel durch. In C (mit G++ Compiler übersetzt) brauchten 1000.000 Durchgänge 15.5 Sekunden, während die Sache in BASIC 256 fast vier Minuten in Anspruch nahm. Das BASIC-Programm lief auf einem schnelleren Rechner.

Es ist wirklich erstaunlich, wie langsam die Millennium-Rechner geworden sind. An den Hashtables kann es nicht liegen. Denn wenn die 160 KB für den MCP zu wenig sein sollen, dann müsste der alte MCG mit seinen 25 KB ja noch viel schlechter sein - ist er aber nicht!. Es sieht ja derzeit (Partien von Micha, Egbert) eher so aus, als dass der theoretische Geschwindigkeitsvorteil von Faktor 2.5 nicht einmal vollends zur Geltung kommt.
Die Millennium-Rechner sind per se sicher keine schwachen Computer. Aber es wäre natürlich schon interessanter gewesen, wenn sie wirklich ernsthaft um die Leistungsspitze im Turnier mit den alten "Brettis" mitspielen könnten. Und da fehlt wohl ein Stück.

Gruß
Wolfgang

AW: Millennium ChessGenius Pro

Zitieren:

Zitat von Theo (Beitrag 60835)

Jetzt wäre es noch spannend zu erfahren, ob insbesondere das C-Programm, das hier 240 ELO unter Hiarcs bei gleicher Rechenleistung gelistet wird, mit der Zeit irgendwie weiterverbessert wurde. Oder, ob es 1:1 im CGP drin steckt.

Hallo Theo,

große Unterschiede wird es da nicht geben. Ich habe meine Vergleichstests (nachzulesen hier: https://www.schachcomputer.info/foru...&postcount=462), in denen nahezu identische Hauptvarianten und Bewertungen herauskamen, ja zwischen MCG und Chess Genius Palm 2.20 gemacht, was ja eine der frühesten C-Programm-Versionen überhaupt ist (die ARM-Engine wurde mit ChessGenius Palm 2.0 eingeführt).

Viele Grüße,
Dirk

AW: Millennium ChessGenius Pro

Zitieren:

Zitat von mclane (Beitrag 60839)

Ich denke für die zukünftigen Schachcomputer Produktion müsste Ossi Weiner auf Programme dieser Art zurückgreifen. Programme die MP fähig sind und die sehr viel tiefer im SUCHBAUM vordringen.
Denn die Konkurrenz schläft ja nicht und bietet starke Stockfish Gegner mit hoher Elozahl.

Die Frage ist aber - will man das wirklich? So starke Programme braucht man eigentlich nur zur Analyse, weil das Spielen dagegen keinen Spaß macht. Analyse kann man aber besser auf dem PC machen, dann auch gleich mit netter graphischer Auswertung als Balkendiagramm, wodurch man auf den ersten Blick sieht, ob die Partie strategisch oder durch einen einzelnen Patzer entschieden wurde.

Zum eigentlichen Spielen kann man diese Programme nur mit ELO-Bremse gebrauchen. Shredder hat so einen Regler, Stockfish AFAIK nicht. Es hat sich gezeigt, daß es viel schwieriger ist, Programme "realistisch" zu drosseln, als sie zu verbessern. Niemand will eine Drosselung, wo das Programm 40 Züge lang spielt wie ein Carlsen, der mit dem noch zu erfindenden Chessium gedopt ist, um dann die Dame einzustellen.

Möglicherweise ist das auch ein Grund, wieso die iPhone-Version von CG nicht von der schnellen Hardware profitiert. Vielleicht war das ja auch Absicht, um dem Benutzer nicht eine letztlich nur frustrierende Software hinzustellen.

Dann wäre die nächste Frage, ob man wirklich den Hardware-Aufwand treiben will, nur um dann im Normalfall mit angezogener Handbremse zu fahren. Auf jeden Fall könnte Millennium so ein Gerät dann nicht mehr mit handelsüblichen NiMH-Akkus betreiben, sondern dann wäre man wie bei Tablets auf die dort üblichen Akkus angewiesen. Mit der Konsequenz, daß die nach ein paar Jahren hin sind, und passender Ersatz schwierig zu bekommen wäre. Oder man müßte auf Akkubetrieb ganz verzichten, was auch nicht so toll wäre.

Wenn ich mir die Spielstärke des CG ansehe, liegt er in einem starken, aber noch nicht übermenschlichen Bereich. Und die lediglich 15mA Stromaufnahme (CG, nicht pro, aus dem Parallelthread) im Rechnermodus sind schon sehr bemerkenswert.

Wieviel Strom zieht der CGP eigentlich?