Hallo Michael,
Das ist genau der Punkt. Grosse Hashtables nützen erst was, wenn sie gefüllt sind und das dauert bei den 16 bit Geräten sehr lang.

viele Grüße
Markus

Interessante Stellung Nr. 1. Dass 1. g4 gewinnt, hätte ich auf den ersten Blick nicht für möglich gehalten. Der Atlanta hat den auch gleich auf dem Schirm und löst die Aufgabe im 3-Min.-Modus sauber (Tiefe jeweils 14/15 Halbzüge). Schöne Abendübung.

Gruß!

Interessant . Ich hatte das letztens zufällig auch am Chess System Tal II bemerkt, dem ich aus Spaß 512 MB Hashspeicher gab. Er wurde langsamer.


Allerdings tatsächlich ungewöhnlich, das der Genius bei nur 3 MB zusätzlichem Hash langsamer wird, da sollte er eher spürbar schneller werden.

Nach meiner Erfahrung haben sich große Hashtables in der gesamten Historie der Brettcomputer und frühen PC-Programmen aus Anwendersicht noch nie wirklich gelohnt. Ich sage mal grob über den Daumen: Wenn 256K - 4096K einstellbar waren, dann war bei 1024K das Optimum erreicht. Bei langsameren PCs noch früher.
Einen wirklich drastischen Effekt gibt es ohnehin nur bei reinen Bauernendspielen, wenn Dinge wie (Fern-)Opposition, zugeordnete Felder o.ä. eine Rolle spielen.

Wenig HT nützen bereits sehr viel: Das nachfolgende Beispiel stammt aus der Micro-WM 1984.
1. c6-c7! wurde nicht gefunden.
Super Forte A hat die Lösung in ungefähr 8 Stunden gefunden. Einem Mephisto Phoenix Glasgow findet die Lösung nicht in dieser Zeit.

Und der kleine Plastikbomber Millennium ChessGenius, viel gescholten ob der nur 32KB HT. Der kann das in 5 Sekunden, inklusive hoher Bewertung.


Zurück zum Mephisto London:
Es gibt Situationen, da sind die 3MB etwas besser als die 512K. Das hatte ich heraus gefunden. Aber im ganz praktischen Spiel dürfte das Optimum zwischen 512K und 1024K liegen.

Gruß,
Wolfgang

Na, dann sind Atlanta und Magellan ja ganz ideal bestückt, und dabei war ich früher immer ein bisschen neidisch auf Geräte mit höheren Hash-Werten. ;-))

Gruß!

Mein Chess Genius Pro zieht schon nach 2 sek. 1 c6-c7 ! Auf der St.2 sek.Zug.

Das der Glasgow Phoenix das nicht in 8 Std. findet, ist schon heftig. Gerade bei ihm, bzw, auch den normal schnellen IIIern hatte ich übrigens genau bei diesem bekanntem Problem auch ohne Hashtables mehr erwartet.

Hallo,

da möchte ich widersprechen.

Werfen wir erneut einen Blick auf die Stellung 4 aus dem BT-Test.

BT-2630 - 4
T.D. Harding, 1978


Als Proband dient uns diesmal der Mephisto Phoenix mit der Tasc V2.5 Emulation. Auch bei der Tasc Emulation lässt sich die Hashgröße durch Mehrfachselektion auswählen. Dabei stehen die Größen 512, 1024, 2048, 4096 und 8192 KB zur Auswahl.

Dann schauen wir doch mal, wie sich der King V2.5 mit den verschiedenen Hashgrößen so anstellt:

Mephisto Phoenix Tasc King 2.50

Hash	1.Df7
512 KB	11:19 min (679 sek.)
1024 KB	09:37 min (577 sek.)
2048 KB	08:50 min (530 sek.)
4096 KB	07:52 min (472 sek.)
8192 KB	07:24 min (444 sek.)

Ich denke, der Unterschied ist erkennbar.

Gruß
Micha

Dann nimm mal die Stellung direkt daneben BT2630-5 (1. Ka6!).
Da liegen alle Zeiten für den Lösungszug bei knapp 10 Sekunden. Da muss man sich schon konzentrieren und reaktionsschnell sein, um die Zehntel-Sekunden Unterschied heraus zu messen.
512KB ist vielleicht 10 Prozent langsamer als 1024
1024 ist vielleicht 5 Prozent langsamer als 2048 und 4096.
Die 8192 ist einen Tick langsamer als letztere.

Und wohl gemerkt: Ich habe nicht lange nach einem Gegenbeweis gesucht, sondern einfach die nächste BT-Stellung genommen.

Gruß,
Wolfgang

OK, wie macht man das?

Gruß
Karl

Du gehst ins Menü zurück und wählst dieselbe Emulation nochmal.

Genauso, wie man die Milano-Emulationen durch das mehrmalige Auswählen der Nigel Short-Emulation auswählt.

Details:
https://www.schach-computer.info/wik...x#Emulationen: