Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / Rybka 3 - seltsamer Einfluss der Hash-Größe
- - By Gerd Lahnstein Date 2008-10-27 05:20 Edited 2008-10-27 07:05
Ich habe leider einen ziemlich langsamen Rechner (2GHz P4, 1 GB RAM), daher versuche ich bei meinen Programmen so gut es geht immer die optimalsten Einstellungen zu finden. So habe ich auch bei Rybka 3 mit der Hash-Größe experimentiert und bin dabei auf einen recht seltsamen Einfluß auf die Analyseleistung gestoßen.

Normalerweise sollte man ja eigentlich annehmen, daß sich bei zunehmend größerem Hash-Speicher die Analyseleistung entsprechend verbessert, allerdings konnte ich dies bei Rybka 3 nicht feststellen. Im Gegenteil, es wurde mit größerem Hash sogar meist schlechter, teilweise dauerte es bis zu 36 Mal länger, bis der beste Zug gefunden wurde, bzw. manchmal konnte der Zug auch nach Stunden nicht gefunden werden.

Für mich ist dieser seltsame Einfluß der Hash-Größe auch eine Erklärung, warum sich manchmal einige hier im Forum wundern, warum sie tw. erheblich längere Suchzeiten haben (z.B. bei den wunderschönen Brillianten von Walter Eigenmann) als andere. Der Brilli #9 kommt übrigens auch in meinen Tests vor.

Wer mehr dazu lesen möchte, siehe hier:
http://www.schachfeld.de/f202/rybka-3-seltsamer-einfluss-hash-speichergroesse-rechenleistung-7874/

Anm. Mod: Link anklickbar gemacht
Parent - - By Micha Wehrmann Date 2008-10-27 08:54
Auch ich nutze einen Pentium 4, meiner hat 3 GHz und 1,5 GB RAM.

Welche Hashgrößen sollte ich nach Deiner Erfahrung am besten wählen?

a) Für die flotte Durchsicht einer Partie, sagen wir 5 bis 10 sec pro Halbzug.
b) Für die tiefe nächtliche Auto-Analyse einer Partie, mit 6 min pro Halbzug im Mittel.

Mit Dank für Deine Meinung,
Micha
Parent - - By Gerd Lahnstein Date 2008-10-27 13:49
Tja, nach diesen Tests macht eigentlich nur 32 MB Hash Sinn, so abenteuerlich es klingen mag, dabei ist es auch egal wie lange man Rybka rechnen läßt. Das ist schon verwunderlich, aber es sind nunmal meine Beobachtungen. Dabei kann es aber Ausnahmefälle geben, wo bestimmte Hash-Größen dennoch besser abschneiden, in den Tests gab es allerdings nur zwei davon:

Testposition #1:
64 MB: 9 +0.49 1.Sxd6 ( 9.69) Sek.
32 MB: 10 +0.69 1.Sxd6 (27.34)

Allerdings verfing sich Rybka bei dieser Testposition und 64 MB Hash bei seiner Denkstufe 10 offensichtlich in einer Endlosscheife und brachte auch nach einer Stunde keinen weiteren Analyse-Output.

(Das könnte neben der Tatsache, daß der beste Zug bei dieser Testposition und bei 64 MB deutlich schneller gefunden wird, ein Hinweis sein, daß Rykba intern je nach Hash-Größe vielleicht auch etwas anders arbeitet und sich in den "64-MB-Algorithmen" vielleicht ein Fehler bemerkbar macht, der bei anderen Hash-Größen nicht zum Tragen kommt. Aber das ist reine Spekulation.)

Testposition #2:
256 MB: 13+  0:06:35   5.672.204  14.723  +1,51  18.Lxg7
032 MB: 14+  0:08:46   7.716.014  15.012  +1,38  18.Lxg7

Auch da war 256 MB Hash schneller als 32 MB.

Aber... von diesen Einzelfällen weiß man allerdings erst hinterher (sofern man dies überhaupt aufwendig testet) und das Risiko scheint eher deutlich größer, daß sich Rybka bei größerem Hash mehr oder weniger elegant zunächst oder sogar dauerhaft an der Lösung vorbeirechnet.

Nun mag man natürlich anmerken, daß 3 Testpositionen viel zu wenig seinen, um allgemeine Aussagen zu machen, vielleicht habe ich ja tatsächlich ausgerechnet so dusselige Testpositionen erwischt, mag sein mag nicht sein. Wäre daher nicht verkehrt, wenn andere Leute weitere Tests vornehmen, um mehr über diesen seltsamen Einfluß der Hash-Größe herauszufinden. Andererseits reicht eigentlich aber schon eine Testposition, um festzustellen, daß da etwas nicht stimmen kann.

Ob die Testergebnisse sich auch mit anderes CPUs verifizieren lassen, müßte jemand anderes mal ausprobieren.

Nun, die Testpositionen haben sich darauf beschränkt einen Zug zu finden, der Gewinn verspricht. Rybka mag vielleicht auch eher so gestrickt sein, daß es sich damit völlig zufrieden gibt, einen Zug zu finden, der zwar möglicherweise nicht der aller-aller beste ist, aber dafür nach Rybkas Ansicht mit großer Sicherheit ausreichend gut genug ist, um damit zu gewinnen. Motto, mehr als gewinnen kann man ja nicht, etwa so wie bei der WM 2008, wo Anand in der 3. Partie 33...Lxd3 mit Matt in 11 Zügen ausgelassen hat. Und auch bei anderen Stellungen wird ja immer wieder beobachtet, daß Rybka 3 nicht immer und in jedem Fall zu den besten Lösungsfindern zählt.

Wäre daher ganz interessant auch mal Positionen zu untersuchen, wo Rybka versuchen muß, eine schlechtere Stellung zu minimieren. Vielleicht versucht Rybka dann eher in jedem Fall den allerbesten Zug zu finden, um den drohenden Untergang doch noch abzuwenden.
Parent - By Ernest Bonnem Date 2008-10-29 15:23
BS2830 p19 bm Be1


GUI: CB-F11-R3
Analysis by Rybka 3 32-bit (xxx MB):   1cpu   (with sampled search)
1024MB
1.Be1   +-  (1.49 !)   Depth: 14   00:03:06  7796kN
512MB
1.Be1  +/-  (1.26 !)   Depth: 12   00:00:38  1577kN
256MB
1.Be1  +/-  (1.29 !)   Depth: 12   00:00:21  930kN
128MB
1.Be1  +/-  (1.27 !)   Depth: 12   00:00:19  840kN
64MB
1.Be1  +-  (1.50 !)   Depth: 13   00:00:37  1530kN
32MB
1.Be1  +/-  (1.28 !)   Depth: 12   00:00:21  944kN
16MB
1.Be1  +/-  (1.30 !)   Depth: 13   00:01:23  3537kN
8MB
1.Be1  +-  (1.55 !)   Depth: 14   00:05:09  12266kN
4MB
1.Be1  +/-  (1.18 !)   Depth: 12   00:00:40  1748kN

Hier bekommt man die besten Lösungszeiten mit 128, 256 und 32 MB Hash 

... und mit ShredderClassic GUI (also: ohne sampled search)

Engine: Rybka 3 32-bit (xxx MB) by Vasik Rajlich, Larry Kaufman    1cpu
1024MB
12.34   0:19   +1.30++  1.Be1 (836.779) 43
512MB
11.34   0:08   +1.27++  1.Be1 (376.278) 43
256MB
16.34  11:02   +1.94++  1.Be1 (25.983.538) 40
128MB
14.34   1:52   +1.58++  1.Be1 (4.734.020) 43
64MB
13.34   1:17   +1.30++  1.Be1 (3.367.721) 44
32MB
13.34   0:32   +1.43++  1.Be1 (1.380.144) 43
16MB
13.34   0:37   +1.36++  1.Be1 (1.611.165) 44
8MB
12.34   0:27   +1.36++  1.Be1 (1.198.201) 45
4MB
11.34   0:11   +1.18++  1.Be1 (532.803) 46

Also hier bekommt man die besten Lösungszeiten mit 512, 4 und 256 MB Hash 
Parent - - By Kurt Utzinger Date 2008-10-27 11:46
Halllo Gerd
Das mit den Hashtables (unter Rybka) ist halt so eine Sache. So ist in
der folgenden von Dir getesteten Stellung



mein Intel Quad Q6600 2.4 GHz schon längstens über die Suchtiefe 20 hinaus, ohne
dass jedoch der brillante Zug Txf6 gefunden worden wäre. Mit MP-Systemen ist
eine vergleichbare Testarbeit schlicht unmöglich geworden. Deine Tests laufen ja
wohl noch mit einer CPU, wo es eigentlich solche Differenzen nicht geben sollte.
Aber Rybka scheint da in jeder Hinsicht ein spezieller Fall zu sein. Ich habe es
aufgegeben, mich darüber noch zu wundern.
Mfg
Kurt
Parent - By Kay Schoenberger Date 2008-10-27 12:11
>Deine Tests laufen ja
>wohl noch mit einer CPU, wo es eigentlich solche Differenzen nicht geben sollte.
>Aber Rybka scheint da in jeder Hinsicht ein spezieller Fall zu sein. Ich habe es
>aufgegeben, mich darüber noch zu wundern.

Das kann einfach daran liegen, dass beim Hashing von Spielpositionen der Zufall im Spiel ist. Dahinter stecken ja XOR-Verknüpfungen mit Zufallswerten, die bei den meisten Engines wohl fest gesetzt sind. Das muss man aber nicht machen, sodass sich bei einer erneuten Analyse mit anderen werten andere Ergebnisse ergeben können.

MfG,
Kay
Parent - By Peter Unger Date 2008-10-27 14:01
dass dies so ist, musste ich im "Computer Bild Spiele - advanced chess" Finale leidvoll erfahren. Bin zum Schluss auf meinen Dual-Core zurückgegangen und habe im Quad nur einen Core laufen lassen. Für Freestyle + Quad 6600 ist die Rybka 3 engine m. E. absolut ungeeignet.
Dies habe ich (und nicht nur ich) im Rybka Forum moniert. Man kann nur hoffen, dass in diesem Jahr noch ein Update gibt.

Gruß

Peter Unger
Parent - By Gerd Lahnstein Date 2008-10-27 15:03
Ja, Kurt, diesen höchsten Grad des User-Daseins (das Wundern aufgeben) werde ich vielleicht auch noch dereinst erreichen, wenn ich mich in ferner Zukunft mal genauso lange mit Schach-Engines beschäftigt haben werde wie ihr hier. Tja mei...ich bin halt leider noch in der "sich-wundern-Phase".

Aber vielleicht erlaubst du dir dennoch mal den Spaß den 9. Brillianten mit 32 MB Hash anzugehen, wäre ziemlich gepannt auf das Ergebnis.

In der Tat waren es die gerade euere z.T. erheblich voneinander abweichenden Analyse-Outputs bzgl. der Brillis von Walter Eigenmann, die neben bis dahin gemachten eigenen Beobachtungen mich veranlaßt haben diese Hash-Größen Tests durchzuführen. Und ich war schon nicht wenig verblüfft zu sehen, daß meine oller P4 nur doppelt so langsam war wie z.B. der Rechner von Peter Martan, dessen Quad 4x2,5Ghz mit 1536 MB Hash mindestens 20 Mal schneller (wenn nicht mehr) als meine Kiste sein sollte.

Über die von dir angesprochenen Schwierigkeiten der Reproduzierbarkeit bei MP-Systemen habe ich mangels eigener Hardware bisher leider nur lesen können, aber das scheint ja nicht unbedingt eine spezielle Rybka Problematik zu sein.

Was die Implementierung des Hash-Speichers bei Rubka betrifft, so tun sich doch einige Ungereimtheiten auf, sie scheint - freundlich formuliert - "nicht gerade gelungen", denn besonders bei einem langsamen Rechner wie meinem sollte man schon erwarten, daß ein größerer Hash-Speicher sich entsprechend vorteilhafter bemerkbar machen sollte, da es ja Sinn und Zweck eines Hash ist, durch schnellen Zugriff auf bereits ermittelte Zwischenergebnisse ein zeitaufwendiges erneutes Berechnen zu vermeiden. Zumindest sollte ein größerer Hash nicht zu teilweise erheblichen Einbußen der Analyseleistung führen.

Gruß
Gerd
Parent - - By Joachim Krzyzanowski Date 2008-10-29 11:14
[quote="Kurt Utzinger"]
Halllo Gerd
Das mit den Hashtables (unter Rybka) ist halt so eine Sache. So ist in
der folgenden von Dir getesteten Stellung



mein Intel Quad Q6600 2.4 GHz schon längstens über die Suchtiefe 20 hinaus, ohne
dass jedoch der brillante Zug Txf6 gefunden worden wäre. Mit MP-Systemen ist
eine vergleichbare Testarbeit schlicht unmöglich geworden. Deine Tests laufen ja
wohl noch mit einer CPU, wo es eigentlich solche Differenzen nicht geben sollte.
Aber Rybka scheint da in jeder Hinsicht ein spezieller Fall zu sein. Ich habe es
aufgegeben, mich darüber noch zu wundern.
Mfg
Kurt
[/quote]

Auch vor R3 habe ich solche Feststellungen machen können:
hash     tiefe         zeit
016      13            0:00:38
032      15            0:02:35
064      16            0:05:08
128      16            0:05:24
256      14            0:01:18
512      14            0:01:18
Parent - - By Kurt Wagner Date 2008-12-31 13:15
Kann mir bitte jemand ganz kurz erklären, was die Engine in so eine Hashtable reinschreibt? Warum muss/soll der hash so groß sein?
Parent - - By Benno Hartwig Date 2008-12-31 14:35
Bewertungen zu Stellungen, die innerhalb der Suche durchlaufen werden.
- Manche Stellungen werden dank Zugumstellung innerhalb der Suche noch einmal durchlaufen und brauchen dann nicht neu bewertet zu werden.
- Teile der Suche müssen mit veränderten alpha-beta-Werten erneut durchsucht werden, und manche Werte sind dann ggf. auch in dieser Suche nutzbar.
- Mglw. können manche Positionenbewertungen in der Suche mit der um 1 vergrößerten Suchtiefe erneut verwendet werden.
-...

So wird in die Hashtabelle jede Menge hineingeschrieben.
Und wenn die Tabelle voll ist, muss klug überschrieben werden, damit möglichst wenig wertvolle Informationen überschrieben werden.

Benno
Parent - - By Kurt Wagner Date 2008-12-31 16:20
Acho, vielen Dank!. Das heißt also, dass bei kleinerer Hash-Size das Programm im schlimmsten Fall "nur" langsamer rechnet weil es evtl. Stellungen doppelt berechnet; die Ergebnisse sind aber genauso präzise wie bei großen Hash-Sizes? Kann ich dass so verstehen?
Parent - - By Benno Hartwig Date 2009-01-01 15:22
Zitat:
dass bei kleinerer Hash-Size das Programm im schlimmsten Fall "nur" langsamer rechnet weil es evtl. Stellungen doppelt berechnet
Richtig.
Ich vermute, dass die Threads der Multi-Core-Engines mit Hilfe der Hashtables kommunizieren (bin da unsicher),
Ansonsten könnten Hashtables auch komplett weggelassen werden, die Engine müsste dann nur etwas länger rechnen, um dann zu denselben Ergebnissen zu kommen.
Wie groß dieser Faktor sein mag, weiß ich aber nicht.
Aus dem Bauch: der Faktor ist (deutlich?) kleiner als 2.

Benno
Parent - By Kay Schoenberger Date 2009-01-01 19:09
Ich habe das kurz anhand des "20. Brillianten" überprüft:
Mit 1 MB Hash braucht Fritz 9 insgesamt 2:45 min, um Tiefe 15 zu erreichen, bei 512 MB sind es nur 1:29 min. Macht einen Faktor von 1,85. Leider kann man in der Fritz-GUI nicht 0 MB einstellen; könnte durchaus noch einen deutlichen Unterschied machen (das erste MB ist sicher das wichtigste).

Kay
Up Topic Hauptforen / CSS-Forum / Rybka 3 - seltsamer Einfluss der Hash-Größe

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill