Hallo Micha,

ich finde das auch enttäuschend, aber es ist erklärbar. Ich glaube auch nicht, dass das an den Emulationen liegt, denn nach der Erklärung von Markus sollte sich der Original London 68000 genauso verhalten, wenn man ihm 3 MB spendieren würde. Die größeren Hashtabellen helfen wahrscheinlich eher auf echten 32 Bit-Systemen.

Und der Tasc R30 ist ja auch schon ein 32-Bit-System, da sind die Verhältnisse ja auch schon ganz anders.

Es gibt für jedes System eine ideale Größe für Hash-Tabellen, wenn wie gesagt die Verwaltung länger dauert als eine Stellungsanalyse, dann bringt die Tabelle sogar nur Nachteile.

Ruud könnte es möglicherweise verbessern, wenn tatsächlich ein 68020 oder 68030 emuliert wird und nicht ein 68000.

Viele Grüße
Michael

Hallo Michael,

nein, ich bin nicht enttäuscht. Das wäre auch etwas unfair gegenüber Ruud, da ich seinerzeit (Revelation II AE Update) Ruud, neben anderen Personen, gebeten hatte, den größeren Hash Speicher zu implementieren.

Was mich viel mehr ärgert, ist die Tatsache, dass es mir erst jetzt aufgefallen ist. Daher ja auch der Hinweis auf andere Phoenix Geräte, die das Problem betrifft. Hat das denn nie irgendjemand zuvor getestet?

Gut, ich bin nicht der große Stellungstester, sondern mehr der Spieler. War jetzt auch mehr ein Zufall, der mich zum Testen animiert hatte.

Letztendlich ist es kein Weltuntergang, da ich mit den Phoenix Geräten nach wie vor sehr zufrieden bin, aber aus meiner Sicht sollte es einfach Erwähnung finden.

Und das war es auch schon.

Gruß
Micha

Ein Gedanke der mir gefällt. Geht halt bei Geräten die nur als 68000 er erschienen sind nicht wie zB. Glasgow 68000, Amsterdam 68000 oder die Sphinx 40/50, aber ab Dallas gab es ja den 68020 und ab Portorose den 68030!

__________________
Schach ist das Spiel, das die Verrückten gesund hält. (Albert Einstein)

Hallo Schachcomputer Freunde,

mir gefallen solche respektvollen und fundierten Diskussionen wie die aktuelle zum Thema Hashtables außerordentlich gut. Dies dient zu einem besseren Verständnis, gerade bei diesem sehr komplexen Thema und ich habe einiges an neuen Aspekte auch für mich entdecken können, herzlichen Dank dafür! Einfluss auf den Nutzen von Hashtables haben also unter anderem:

- Die Busbreite des Systems 16 Bit, 32 Bit, 64 Bit...

- Falls eine Emulation vorliegt, auf welchen Prozessor wurde emuliert (16 Bit, 32 Bit,…)

- Der Stellungstyp (Mittelspiel, Endspiel) Auch innerhalb dieser Spielabschnitte gibt es Stellungstypen, wo sich die Vorteile von Hashtables ganz unterschiedlich auswirken können

- Die generelle Effizienz von Hashtables ist abhängig davon, ob die Größe der Hashtables auf die Geschwindigkeit des Prozessors abgestimmt ist

- Die Effizienz von Hashtables steht im Zusammenhang mit der Bedenkzeit. Beim Blitzen und Schnellschach dürften Hashtables eher Nach- als Vorteile bringen. Im Turnierschach und vor allem bei langen Analysen sieht die Sache bereits ganz anders aus

- Natürlich ist es auch von großer Bedeutung, ob die Hashtables gut programmiert worden sind (mein subjektiver Eindruck ist beispielsweise, dass Dave Kittinger beim Novag Diablo hier noch einige Luft nach oben hatte)

- Auch die Programmstruktur hat Einfluss, wie förderlich Hashtables sein können (Fritz mag hier als positives Beispiel dienen)

- Hashtables in Stellungstests können den Praxisnutzen nicht von Partien spiegeln, da bei Stellungstests immer erst das zeitfressende Füllen der Hashtabellen ansteht

- Dann kommt noch erschwerend hinzu, dass es offenbar Programm wie den King gibt, die nach jedem ausgeführten Zug die Hashtables löschen, d.h. der Ram steht nach jedem Zug wieder komplett für neue Berechnungen zur Verfügung.

Garantiert habe ich noch weitere Aspekte unwissentlich unterschlagen.

Gruß
Egbert

Hallo zusammen,

ich hab mal mit den CB_Emulationen Tests durchgeführt und London 68030 36MHz-2MB verglichen mit 36MHz-8MB.


Fazit: Die 8MB sind gleich schnell (Grundstellung) oder schneller (Endspiel, Mattstufe)!


2MB: Grundstellung Tiefe 08: 3m24s
8MB: Grundstellung Tiefe 08: 3m23s


2MB: Endspiel g4: Tiefe 17: 11m32s
8MB: Endspiel g4: Tiefe 17: 9m58s


Matt in 9 (siehe https://glarean-magazin.ch/2021/01/1...knights-chess/)
8/5p2/1p2p3/kP2P3/P1K1PP1p/1P6/2P5/8
2MB: Matt Kc3: 2m48s

8MB: Matt Kc3: 2m26s


Kann es sein, dass auf dem Phoenix die Speicherzugriffe ins Hash langsamer sind?


LG
Frank

Hallo Frank,

Danke für das Teilen Deines Tests. Ich bin jetz wirklich kein Experte in Sachen CB_Emulationen, aber ich glaube dort wird der tatsächliche Prozessor, also 68000, 68020, oder 68030 emuliert, beim Phoenix basiert hingegen die Emulation per se auf dem 68000.

Gruß
Egbert

Yep, das stimmt!

(bis auf den London 68040, der glaube ich auf 68030 basiert.)
Übrigens gab es den A'dam auch als 68020, aber wer weiß wo die EPROMS liegen
https://www.schach-computer.info/wik...Amsterdam_1985


LG
Frank

Wenn ich mich noch recht erinnere, es war erst 1985 war zu lesen bei der WM'85 das der Amsterdam 1 auf einem Motorola PC (Entwicklungssystem) lief für schlappe 50.000 US-Dollar was damals ein Heidengeld war.
Ein Brettgerät 68020 dagegen kam erst mit dem Dallas wobei der "Cologne" der bei der Compu-WM Köln lief nie so erschien .

__________________
Schach ist das Spiel, das die Verrückten gesund hält. (Albert Einstein)

Ich komme mal wieder zum schachlichen Aspekt. Der Sinn von Hash-Tables, bzw. der größte Nutzen besteht dann, wenn viele Varianten (durch Zugumstellung) zum gleichen Ziel führen (und wenige Figuren auf dem Brett stehen). Denn diese identischen Zielknoten müssen nicht mehrmals untersucht werden.

Ein Beispiel hierfür sei nachfolgende Stellung: Um diese zu begreifen, sei auf die Theorie der "zugeordneten Felder" verwiesen.



Weiß gewinnt nur mit 1. Ka1! oder 1. Kc1!

Zwei Mephisto Phoenix London wurden nun darauf angesetzt.

Verlauf der Rechentiefen / Viele "Überholvorgänge"
Die 3M- Version legte in den ersten Minuten los wie die Feuerwehr, lag in der Mindestsuchtiefe 2 Halbzüge voraus. Bis etwa zur zehnten Minute drehte sich binnen einer Minute das Bild, denn der 512K-London legte einen Zwischenspurt hin:
512K Tiefe 21/33
3M: Tiefe 19/31. Dann stellte diese 3M-Version binnen weniger Minuten auf 23/34, lag also um +2 voraus.

Danach übernahm wieder die 512K-Variante durch einen "Zwischenspurt" die Führung. Tendenziell war die 512K in der Anfangszeit meist schneller bzw. aktueller mit einer neuen Bewertung.

Nach etwa 3 Stunden stand es gleich, sowohl in Tiefe, als auch Bewertung (+1,21). Danach waren die beiden Mephistos länger unbeobachtet.

Nach exakt 6 Stunden dann folgendes Bild:
512K-Version: Tiefe 25/34, Ast 01, Bewertung 1,21
3M -Version: Tiefe 26/34, Ast 01, Bewertung 1,72

34 Minuten änderte die 512K-Version die Bewertung auf +1,81, ohne dass sich and der Tiefe und Ast (01) etwas geändert hätte.

5 Minuten später änderte die 512K-Version die Bewertung erneut, jetzt auf die 1,72, welche die 3M-Version vorher schon hatte:
Beide: Tiefe: 26/34, Variante 01/06.

Fazit: Dieses letzte Ergebnis hatte die 3M-Version knapp 40 Minuten eher als der 512K. Das ist zu vernachlässigen bei der Zeitstrecke von fast 7 Stunden. Es ist also auf längere Sicht ein Kopf-an-Kopf Rennen.

Und was machte Task King 2.50 ?
512K Zwischen 2h 55min und 3h 00 min.
8192K 2h 48 Minuten

Jeweils mit der Bewertung von +2,08 und sonst identischen Zahlen.

Gruß,
Wolfgang

Guten Morgen Wolfgang,

vielen Dank für das Teilen Deiner Erkenntnisse zum Thema Hashtables unter Mephisto Phoenix, nun auch zum Task King 2.50. Es wäre jedoch ein fataler Irrtum daraus schließen zu wollen, dass die Hashtables keine signifikanten Vorteile im Bereich der Schachcomputer gebracht hätten.

Zur Beweisführung verweise ich auf Computerschach & Spiele, Ausgabe 1/94, Seite 13 bis 16, in welcher sich unter anderem nachstehende Grafik für den Risc 2500 befindet:



Also hier ist schon ein dramatischer Geschwindigkeitsvoteil, gerade von 0 KB auf 128 KB zu verzeichnen. Wie verhält sich der Risc 2500 unter Mephisto Phoenix mit den dort erwähnten Teststellungen? Ggf. gibt es dann hier ein Problem bei der Umsetzung im Mephisto Phoenix und Ruud müsste sich des Themas annehmen, denn mit der Busbreite 16 Bit >32 Bit (Emulations-Basis) könnte dann das Verhalten nicht zu erklären sein.


Gruß
Egbert