Wenn man die batterien einlegt ist default ECO eingeschaltet. Danach sollte er die zuletzt gemachte einstellungen behalten bis die batterien wieder raus gehen.
Ich habe noch nicht versucht wie das ist mit netzteil. Dann sollte ECO default ausgeschaltet sein dachte ich.

Edit: habe es gerade versucht, und Egbert hat (natürlich ) recht, mit netzteil ist auch default ECO eingeschaltet.

Grüsse, Paul

__________________
Wenn ich mich irre, sollte es ein Horizont Wirkung sein

Hallo Leute,

wenngleich ich in dem leider geschlossenen Nachbarthread (https://www.schachcomputer.info/foru...ead.php?t=5201) nicht gepostet hatte, habe ich doch interessiert mitgelesen und fand, es waren einige interessante Hinweise auf den Ursprung der ChessGenius(Pro)-Engine dabei. Schade, daß ein paar Leute ihre Emotionen nicht im Griff hatten. Damit das nicht dazu führt, daß wir nun den Ursprung der Engine nicht mehr weiter untersuchen, versuche ich hier, an den konstruktiven Teil jener Diskussion anzuknüpfen.

Dieser Thread ist eigentlich nicht der richtige Ort - falls Interesse besteht, kann man vielleicht wieder einen neuen Thread erstellen „Millennium ChessGenius Pro - hier geht es weiter“ oder so ähnlich

Daß die MCG/CGP-Engine wenig Verwandtschaft mit dem London-Programm aufweist, hat ja eigentlich schon der BT-Test des MCG mit wenig Korrelation zum London gezeigt, und daher soll es in diesem Beitrag auch nicht um das Thema „London“ gehen.

Neben den London-Werbeaussagen war in erster Linie immer die Aussage seitens Millennium und wohl auch Richard Lang, daß in dem Gerät ein C-Programm werkelt, das der Android-Engine des ChessGenius entspricht, die wiederum eng verwandt/identisch mit iOS und Palm sein soll.

Da der Palm die älteste dieser Plattformen ist und es laut Äußerungen des geschlossenen Threads in den Changelogs der iOS/Android-Versionen keinen Hinweis auf eine Änderung an der Engine gibt, untersuche ich hier die Palm-Historie.

Als Palm in den 90er Jahren die ersten Handhelds herausbrachte, lief darauf ein Motorola Dragonball-Controller mit 68000er-Kern. Die schnellsten Derivate, die 2000/2001 herauskamen, waren immerhin mit 32MHz getaktet, der Rest war langsamer. Speicher war auch immer knapp und nicht mit heutigen Systemen vergleichbar.

Im Jahr 2002 kam dann der erste Palm mit ARM-CPU (Intel XScale) heraus (s. auch https://de.wikipedia.org/wiki/HP_Palm), und damit die alten Programme darauf noch liefen, konnte PalmOS 5 diese auf dem neuen Prozessor emulieren - mit Geschwindigkeitseinbußen, aber immerhin… Und nach und nach kamen dann native ARM-Applikationen heraus, die die Geschwindigkeit des Prozessors voll nutzen konnten.

Chess Genius war bereits zu 68000er-Zeiten auf dem Palm verfügbar. Aus dieser Zeit (späte 1990er/frühe 2000er Jahre) stammt die Aussage, daß aufgrund des geringeren Speicherbedarfs, und weil die Palms damals ja noch ziemlich langsam waren, nicht eine aktuelle Version der 68000er-Engine, sondern eine Roma-Version als Basis für ChessGenius auf dem Palm genommen wurde. (s. auch http://chessgenius.com/palm/faq.htm unter „Is ChessGenius for the Palm Computing® platform an actual World Champion Chess program?“ - das wurde auch bereits im geschlossenen Thread geschrieben.)

Der interessante Punkt ist, was danach geschah. Nach Einführung des ARM mußte Lang sein Programm umschreiben. Zum besseren Verständnis sei noch einmal darauf hingewiesen, daß ein Assembler-Programm nicht einfach wie ein in einer Hochsprache vorliegendes Programm für einen anderen Prozessor neu kompiliert werden kann; stattdessen muß man das Programm Befehl für Befehl neu schreiben.

Richard Lang konnte für diese Übersetzung wieder den Roma als Basis nehmen, aber es standen ihm auch zahlreiche andere Möglichkeiten zur Verfügung, um eine „Vorlage“ auszuwählen. Es gab auf dem PC nicht nur das „London“-Programm (Chess Genius 3.0 DOS), sondern auch noch einige modernere Versionen, die angeblich auch einen deutlich aggressiveren Spielstil hatten (zumindest Chess Genius 4 und 6.5 sagte man das nach). Und die Geschwindigkeits- und Speicherplatz-Limitierung der frühen Palms war ja nun auch nicht mehr gegeben.

Lang selbst schreibt auf der oben verlinkten Palm-FAQ-Seite „The new ARM engine is a modern chess engine which supports hash tables and is much stronger.“ (Und nichts mehr von Roma wie bei der 68000-Engine, allerdings auch nichts von London.)

Bei der Beschäftigung mit diesen Themen habe ich mich daran erinnert, daß ich von früher auch noch einen Palm habe (Palm T|X), auf dem allerdings nur eine Demo-Version von ChessGenius (Version 2.20) installiert ist. Das Tolle für uns ist, daß man zwischen den beiden erwähnten Engines (68000 emuliert und ARM) umstellen kann und sogar im Programm einen kleinen Beschreibungstext erhält:

Zur 68000-Version steht da: „Die Standardmaschine verwendet den derzeitigen Code des 1987 Weltmeisterprogramms.“
Und zur ARM-Engine: „Die ARM Engine läuft nativ auf dem ARM Prozessor. Sie ist Hunderte von ELO Punkten stärker als die Standard Engine.“

Scheinbar hat das „C-Programm“ (ARM-Engine) und die alte 68000er-Version (egal ob nun Roma/Amsterdam/Psion) nicht viel miteinander zu tun?!

Zur Überprüfung habe ich mal einen einfachen Test gemacht.
Nach 1.f3 e5 2.g3 ist sowohl ChessGenius Palm als auch Millennium ChessGenius aus dem Buch und muß rechnen.

Da bei meiner Demo-Version in größeren Rechentiefen auf der ARM-Engine nichts mehr angezeigt wird, habe ich die Analyse auf eine Rechentiefe von 7 Halbzügen bezogen, nur die 68000-Engine habe ich noch ein bißchen länger rechnen lassen.

Hier die Ergebnisse:

Sowohl MCG als auch die ARM-Engine zeigen die gleiche zweifelhafte Hauptvariante mit Le6 statt Lxd3 mit Figurengewinn, bei nur minimal abweichender Bewertung. Das 68000er-Programm zeigt hingegen auch nach längerer Rechenzeit ganz andere Varianten und eine abweichende Bewertung.

Hier ein zweiter Test: 1.h4 e5 2.h5

Auch hier sind die ARM-Engine des Palm-Genius 2.20 und der MCG zwar nicht komplett identisch, aber doch sehr ähnlich, während die 68000er-Engine ganz andere Bewertungen und Varianten zeigt.

Da meine Demo-Version nicht so lange rechnen kann, werde ich wohl kaum weiterführende Untersuchungen anstellen können und hoffe darauf, daß es im Forum noch Leute gibt, die einen ARM-basierten Palm mit lizensiertem ChessGenius besitzen.

Die bislang durchgeführten, flüchtigen Untersuchungen scheinen zwei Dinge zu belegen:

1. Die Engine des MCG/MCGPro ist tatsächlich zumindest sehr nah verwandt mit der ARM-Engine für Palm.
2. Die ARM-Engine für Palm (und somit auch die des MCG/CGP) basiert wohl nicht auf der ursprünglich verwendeten 68000-Engine, die auf dem Roma-Programm basieren sollte.

Womit noch immer nicht klar ist, woher dieses „C-Programm“ (ARM-Engine) denn nun kommt…

Ich möchte noch kurz auf Postings im geschlossenen Nachbarthread eingehen, die eine Verwandtschaft des MCG/Pro mit Amsterdam/Roma/Psion belegen sollten und somit im Widerspruch zum eben Gesehenen zu stehen scheinen:

Michas Testposition (https://www.schachcomputer.info/foru...&postcount=167) fand ich sehr interessant, aber letztlich nicht beweiskräftig, da die späteren Lang-Programme den Fehlzug auch aufgrund anderer Erwägungen mit nur wenig schlechterer Bewertung verwerfen können, wie Wolfgang gezeigt hat (s. https://www.schachcomputer.info/foru...&postcount=231). Eine kleine Änderung der allgemeinen Bewertungskriterien könnte unter solchen Umständen dazu führen, daß der Fehlzug doch wieder ausgeführt wird.

Saschas Erwähnung der Greco-Stellung (s. https://www.schachcomputer.info/foru...&postcount=376) fand ich wirklich bemerkenswert - man hätte wohl kaum gedacht, daß ein neuerer Lang-Computer statisches „Wissen“ dieser Art verlieren könnte. Andererseits ist das Herausstreichen von statischem „Wissen“ zugunsten der möglichen Erreichung größerer Rechentiefen ja ein moderner Ansatz, der auch zur Zeit der Entstehung der ARM-Engine schon modern wurde. Ich halte es jedenfalls nicht für unmöglich, daß Lang dieses Wissen in der ARM-Version gestrichen haben könnte.

Womit soll man die ARM-Engine also vergleichen? Vielleicht mit einem späteren Lang-DOS-Programm? Ich besitze leider keine späten PC-Genius-Versionen, um in diesem Bereich Vergleiche anzustellen. Möglicherweise ist die ARM-Engine auch etwas komplett Neues (Stand 2002) bzw. Eigenes und versucht, das Schachwissen durch Suchtiefe zu ersetzen, was ja auch 2002 schon „in“ war. Damit ließen sich evtl. manche Aussetzer der neuen Geräte erklären, denn die Engine ist (wenn die Annahme stimmt) für viel schnellere Geräte und somit größere Suchtiefen ausgelegt.

Vielleicht werden wir niemals die Herkunft zweifelsfrei beweisen können, und müssen uns damit abfinden, hier etwas „eigenes“ zu haben.

Viele Grüße,
Dirk

Das es ein eigenes Produkt ist , muss ja nicht erst mal was negatives sein.
Vielleicht ja ganz praktisch wenn wir die Geräte untereinander spielen lassen. So hat man Abwechslung und auch wieder was zum testen.

__________________
Die ganze Welt des Computerschachs

Hallo Dirk,
danke für deine Ausführungen, die mich dazu verleitet haben, mal tief in meinen Schränken zu suchen und siehe da, mein Karton mit Palm und Pocket pc Geräten ist noch vorhanden.
Ich werde die Dinger mal wieder mit Energie versorgen und versuchen den Chessgenius da wieder drauf ans laufen zu bekommen. Den Lizenzkey habe ich noch.
Ich melde mich dann mal, wenn die Dinger reaktiviert sind.

viele Grüße
Markus

Ok, letzte Chance. Ich mache den Thread wieder auf.

Bei der nächste Verfehlung, ist/sind Thread und Personen ohne Begründung draußen.

Ich bin gerne bereit, meine Entscheidung im persönlichen Gespräch zu begründen, warum dieser Thread geschlossen wurde.

Gruß
Micha

Dirk

Wie lang ist die Steuerzeit?

Zunächst mal, danke an Chessguru für die Wiedereröffnung! Und in der Hoffnung, daß die Wiederschließung sich nicht als notwendig erweist.

Das wird zwar gerne als Ausrede benutzt, wenn ein Programm patzt, ist aber praktisch bedeutungslos. Zwar sind Indexkollisionen häufig, aber es wird an der Position ja auch noch der eigentliche Hashkey gespeichert. Das Paper ist leider nicht mehr online verfügbar, aber Robert Hyatt (Crafty) hat das untersucht. Ergebnis: Ab 48bit Schlüssellänge spielen Hashkollisionen keine Rolle mehr.

Wenn man einen besten Zug in der Tabelle mit gespeichert hat, kann man auch untersuchen, ob der denn pseudolegal ist. Hyatt hatte lange Jahre in Crafty dieses Überprüfungs-Feature, welches ihm zufolge auch nie angeschlagen hat.

Man muß hierbei erstens sehen, daß die 68k-Versionen direkt in Assembler waren, die ARM-Versionen nicht. Zweitens ist 68k eine CISC-Architektur, während ARM RISC ist. Das bedeutet u.a., daß man bei ARM eine load/store-Architektur hat, anders als bei 68k. Speziell der 030 hatte einen anständigen Cache, durch den das ansonsten damals langsame Speicher-Interface drastisch beschleunigt wurde, was bei den Befehlen zur direkten Speichermanipulation (erhöhe den Inhalt von Adresse sowieso um eins) wichtig war - und solche Befehle gibt es auf ARM gar nicht erst.

Ich entsinne das nicht mehr auf 68k, wohl aber auf Motorola 56k-DSPs, die ich noch in Assembler bearbeitet habe. Da gab's schon eine Pipeline, daß also Befehl Sowieso auf Register Bla erst im Takt DANACH Auswirkungen hatte. Wenn man das geschickt gemacht hat, mit Interleaving der Befehle, dann konnte man die Befehlszahl pro Takt drastisch erhöhen. Richard Lang ist definitiv einer von der Klasse, die sowas draufhatten. Und dann relativierte es sich auch, daß die CISC-Befehle mehr Takte brauchten.

Quintessenz: Man kann die Taktfrequenzen nicht so direkt vergleichen.

Nicht zu vergessen ist auch, daß man in C deutlich anders als in Assembler programmiert und dabei auch in etwa seinen Compiler kennen muß. Ich weiß nicht, wie es bei Lang ist, aber ich halte es auch für denkbar, daß er mit C nicht so richtig warmgeworden sein könnte. Ich habe bei Talkchess C-Code von Ed Schroeder gesehen, und dem merkt man an, daß er in Assembler denkt. Wenn man das mit C macht, geht das zwar, nur ergibt das C-Idiome, für deren Optimierung der Compiler nicht ausgelegt ist.


Übrigens, zu der Anregung, man könnte ja auch mal mehr Speicher für die Hashtables verbauen: Ja, das geht. Ich weiß das im Details nur von STM32, der hat einen "flexible memory controller", mit dem er auch externen Speicher ansprechen kann (auf Kosten von IO-Pins).

ABER: Erstens läuft der dann ohnehin nur mit der halben Geschwindigkeit wie das interne RAM, und zweitens muß man auf dem Bus Daten und Adressen kommunizieren, während das interne RAM sowas wie einen eigenen Datenbus kennt. Drittens wird externes RAM oft genug nur mit 16bit angebunden, besonders, wenn das Marketing dieses Detail verschweigen kann. Dadurch wird es dann noch langsamer.

Daß das externe RAM um (mindestens) einen Faktor 6-9 langsamer als das interne ist, das ist absolut realistisch. Dadurch würde die Spielstärke nicht so stark steigen, wie man es rein der Tabellengröße nach erwarten könnte.

viele Grüße, Rasmus

>> Hallo Rasmus,

erfreut nehme ich zur Kenntnis, dass wir nun einen weiteren Experten im Forum haben

Dem Thema Hashtable-Kollisionen hatte auch der Nizmo-Autor sehr intensiv gewidmet.

Einen sehr interessanten, wenn auch fast schon wissenschaftlichen Beitrag gab es zu dem Thema in Computerschach & Spiele, Heft 4/94 ab Seite 38. Der Artikel "Der Fleischwolf im Schachprogramm" von Dr. Christian Donninger) beschreibt dort die Funktionsweise von Hashtabellen und auch das Problem der Hashtables-Kollisionen. Die 160 KB des CGP sind bei einem so schnellen Prozessor einfach nicht ausreichend. Hier bedarf es sicher 2 MB und mehr um diese Effekte ausreichend zu minimieren.

Mir fehlen hier ganz einfach die Detailkenntnisse ob Rober Hyatt oder Dr. Christian Donninger falsch liegen.

Ich zitiere einen kurzen Auszug aus seinen Analysen:

"...eine Stellung wird unter Umständen gänzlich falsch bewertet, mysteriöse, oft nicht reproduzierbare Züge erscheinen am Brett. Das Schachprogramm erhält "menschliche Eigenschaften..."

Im weiteren Verlauf räumt der Autor jedoch ein, dass das Problem eher selten auftaucht.

Gruß
Egbert

PS: Eine Frage habe ich noch Rasmus, hast Du auch Erfahrungen mit der Programmierung von Emulatoren?

Gruß
Egbert

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.

Hallo Bryan,

die Rechenzeit war variabel, weil es mir auf den Vergleich der Software und nicht der Hardware ankam, d.h. ich wollte wissen, was die Engines bei einer bestimmten Tiefe anzeigen, aber nicht, wie lange sie dafür brauchen, da die Hardwarebasis ja bekanntermaßen unterschiedlich ist (Palm T|X hat 312MHz). Mit der ARM-Engine auf dem Palm kam ich am schnellsten (ca. 15-20s) auf die angegebenen Rechentiefen, bei den anderen dauerte es ein wenig länger.

Viele Grüße,
Dirk