Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / @Info: Wieso läuft Houndini bei Dir durch?
1 2 Previous Next  
- - By Frank Quisinsky Date 2010-09-11 09:58 Edited 2010-09-11 10:03
Ingo,

habe Deine eMail derzeit nicht zur Hand ...

Houdini hat das gleiche Problem wie Twisted und Komodo.
Hänger bei klaren Endstellungen (z. Kb falscher Läufer vs. K).

Nur mit dem Unterschied das alles komplett crasht, im Speicher hängen bleibt.
Mittlerweile nach 230 Partien 8 Crashes!

Hinzu kommt ein weiteres Problem im Mittelspiel (Hänger vor der 3fachen Zeitüberschreitung, bei Beteiligung diverser Figurenkombinationen - Vermutung, keine Lust weiter im Detail zu testen).

Kann mir nicht vorstellen, dass Houdini bei Dir rund läuft, kann nicht sein!
Diese Engine kann im Grunde mit automatischen Turnieren nicht getestet werden.

Werde dennoch versuchen meinen Test zu Ende zu bringen.

Die meisten Abstürze aber im Endspiel bei klarer Remisstellung. Dies fällt wahrscheinlich auch nur deswegen auf, weil ich in der SWCR ohne Aufgabefaktor spielen lasse.

Umso tragischer, da die Partien wiederholt werden müssen (Shredder GUI kommt nicht dazu zu speichern). 6 Remis Partien gegen andere Engines mussten also wiederholt werden und bei den Wiederholungen gewinnt Houdini dann meist, weil die Grundspielstärke sehr hoch ist. Das alles macht ca. 5 ELO aus, die Houdini bei mir mehr hat, bzw. weniger haben müsste.

Gruß
Frank
Parent - - By Clemens Keck Date 2010-09-11 12:34
Hallo Frank

zu Houdini kann ich nix sagen, aber Komodo1.2 ist ja auch eine meiner "Sparringsengines". Diese engine lief in der Fritz GUI im engine match auch nicht rund bei mir. Ich weis nicht mehr genau was es für Fehler waren aber Komodo1.2 im engine match, das klappte nicht.
Aber siehe da in der Arena GUI hat Komodo 1.2 bei mir schon weit über 1000 Partien 10+5 (allerdings ponderOFF) ohne einen Fehler gespielt.

Gruß Clemens
Parent - - By Frank Quisinsky Date 2010-09-11 13:05 Edited 2010-09-11 13:14
Hi Clemens,

hängt wohl daran, dass ich ohne Aufgabefaktor spielen lasse. Dann fällt es öfters auf.

Komodo erreicht bei Endspielspielen, die klar Remis sind,  z. B. Kb falscher Läufer - K die maximale Suchtiefe und friert ein, überzieht dann auf Zeit. Houdini macht das auch, aber lässt die ganze GUI direkt mit abstürzen.

Verfolge Computerschach nun schon ein paar Jahrhunderte aber solche Fehler sind mir neu. Heute scheinen direkt mehrere Engines damit ein Problem zu haben.

Twisted überzieht auch die Zeit wenn offenbar die maximale Suchtiefe erreicht wurde (lässt die GUI aber nicht abstürzen).

Wirklich dumm ... bin jetzt nicht zu Hause und kann nicht auf die Abstürze reagieren.
Offenbar laufen gerade nur noch 7 von 8 Matches. Loop scheint gegen Junior hängen geblieben zu sein.

Loop M1-T macht das gerne wenn - Matt ermittelt wurde, reagiert dann oftmals nicht gar nicht und stürzt ab, menschlich .
Hin und wieder liegt dann auch die GUI lahm.

Heute morgen sind direkt 4 Houdini Matches hängen geblieben.
Wahrscheinlich läuft bis Montag früh keines der jetzt noch 7 laufenden Matches mehr.
Dafür wird Houdini schon sorgen.

Also, Houdini fliegt nach dem laufenden Turnier raus (keine Lust und Zeit laufend die Turniere zu korrigieren, entweder es läuft automatisch oder es passiert gar nichts). Ist ja total buggy. Bei Loop M1-T kommt das selten vor aber ich werde nach dem Turnier wieder zurückgehen auf Version 2007. Bei Komodo sind die Abstürze nicht tragisch, weil die GUI nicht zu Absturz gebracht wird. Muss dann lediglich das Ergebnis auf Remis geändert werden (passiert bei Komodo nur in klaren Remis Stellungen). Vielleicht hast Du auch diesen Komodo Fall.

Starte ChessBase GUI und gebe in der Suchmaske ein ... time oder Zeit (Zeit bei Fritz und time bei Shredder) und Du siehst die Zeitüberschreitungen.

Gruß
Frank
Parent - - By Peter Behringer Date 2010-09-11 13:36
"funktioniert nicht",...; "crasht"

---->is not a valid bug report!

Mein Tipp, Herr Experte:

1. Xboard/WinBoard benutzen+ "log" an (Ich kann mir schon vorstellen, daß $Engine gefährlichen Unsinn an das GUI sendet; halte aber einen Absturz Winboards für unwahrscheinlich).

2. Logdaten ansehen

3. Fehlerbericht verfassen und absenden
Parent - - By Frank Quisinsky Date 2010-09-11 15:12 Edited 2010-09-11 15:16
Hallo,

ich habe im letzten Jahr mehr als 20 solcher Fehlerberichte zu den Programmieren gesendet. Im Fall von Houdini verzichte ich dankend. Diese ganzen IPP Familie Programme haben ja ein ganzen Heer an Fans. Ich frage mich nur was die testen oder ob irgend jemand von denen sich die Engine eigentlich schon mal genauer angesehen hat.

Bin mal gespannt was Ingo schreibt. Bin mir sicher er hat die gleichen Probleme. Allerdings spielt er mit Aufgabefaktor und von daher werden sich die Abstürze in Grenzen halten.

Houdini muss in den Sourcen eine Beschränkung bei der maximale Suchtiefe haben. Diese ist viel zu niedrig gesetzt. Das ist für einen Programmierer einfach zu ändern. Aber im Grunde fällt dieser Fehler schon nach wenigen Partien auf und insofern verstehe ich nicht, dass der Fehler noch im Programm ist.

Derzeit checke ich eine Rykba Blunder Datenbank (habe ich mir zu fast jeder der Engines die in der SWCR spielt aus meinen SWCR Datenbanken erstellt). Die schwerwiegenden Fehler von Houdini spielt meist auch Rybka 4 (mit Rybka 2, 3 noch nicht überprüft). Witzig, denn andere Engines spielen diese Fehler nicht.

Aber egal ...
Muss das Thema jetzt nicht wieder aufwühlen.

Wird jetzt getestet, nach 920 Partien wieder herausgenommen und fertig.
Sollen sich andere mit diesem Zeug näher beschäftigen.

Gruß
Frank
Parent - - By Peter Behringer Date 2010-09-12 01:06
Informationsgehalt Deines Beitrags hier? NULL!

Wein Dich woanders aus; bzw. lerne ordentliche Fehlerberichte zu erstellen.

ps
Weiter unten las ich:
Zitat:
Auf meinen SWCR Systemen sind 8 Dienste Aktiv,


Toll. Ganz alleine hinbekommen? $Tunefoo angeworfen+Registry händisch verwurstelt?

Zitat:
ich werde sicherlich nicht hingehen und das Remote Zeug aktivieren damit ein Schachturnier läuft, mit notwendigen Sicherheitsmechanismen die Rechner schützen weil der Remote Zugriff offen ist.


Du hast es nicht im Griff, Dein System, bzw. zu wenig Vertrauen.

Zitat:
Habe hunderte Stunden in Zeiten damit verbracht Sergei Abramov (Convekta GUIs) oder Martin Blume etc, etc. mit solchen Fehlermeldungen zu helfen.


Sehr unterhaltsame Schnurren: "solche Fehlermeldungen"? Etwa wie die aus Deinem ersten Beitrag? L0L!
Parent - By Frank Quisinsky Date 2010-09-12 09:41
Hallo Peter,

na wenigstens mal etwas zum Lachen im Thread.

$Tunefoo

Sofern ich mich erinnere gab es wirklich mal ein Programm mit dem Namen Tunefoo.
Ca. 1985 in DOS 4 Zeiten auf dem Trödelmarkt in der PD Kiste für 5 DM.

Viele Grüße
Frank
Parent - - By Günther Höhne Date 2010-09-11 14:23 Edited 2010-09-11 14:25
[quote="Frank Quisinsky"]
Bei Komodo sind die Abstürze nicht tragisch, weil die GUI nicht zu Absturz gebracht wird. Muss dann lediglich das Ergebnis auf Remis geändert werden (passiert bei Komodo nur in klaren Remis Stellungen). Vielleicht hast Du auch diesen Komodo Fall.
[/quote]

Hallo Frank,

hier ein solches Beispiel. Die Partie habe ich dann Remis gegeben, trotz Zeitüberschreitung.

[Event "20 Minuten/Partie + 5 Sekunden/Zug"]
[Site "Engine Match"]
[Date "2010.08.30"]
[Round "1"]
[White "Komodo64 1.2 JA"]
[Black "Zappa Mexico II x64"]
[Result "1/2-1/2"]
[PlyCount "176"]
[EventDate "2010.??.??"]

1. d4 {Buch 0s} Nf6 {Buch 0s} 2. c4 {Buch 0s} e6 {Buch 0s} 3. Nc3 {Buch 0s} Bb4
{Buch 0s} 4. e3 {Buch 0s} b6 {Buch 0s} 5. Nge2 {Buch 0s} Bb7 {Buch 0s} 6. a3 {
Buch 0s} Be7 {Buch 0s} 7. d5 {Buch 0s} O-O {Buch 0s} 8. g3 {Buch 0s} b5 {Buch
0s} 9. Nf4 {0.00/20 56s} bxc4 {-0.03/16 1:34m} 10. Bxc4 {-0.01/23 1:21m} exd5 {
-0.11/16 2s} 11. Ncxd5 {0.00/20 43s (Sfxd5)} Nc6 {-0.07/15 47s} 12. O-O {+0.13/
18 6s} Ne5 {+0.03/15 1:00m} 13. Be2 {+0.12/19 43s} Re8 {+0.02/15 18s (Ld6)} 14.
Nxf6+ {+0.08/19 2:30m (f3)} Bxf6 {+0.07/16 59s} 15. Nd5 {+0.11/20 2s (Ld2)} Rb8
{-0.04/14 41s (d6)} 16. f4 {+0.26/20 32s (Tb1)} Bxd5 {-0.10/15 28s} 17. Qxd5 {
+0.31/21 4s} c6 {-0.09/15 28s} 18. Qc5 {+0.21/21 18s (Dd2)} d6 {+0.01/15 56s}
19. Qc2 {+0.24/22 28s} Nd7 {0.00/15 0s} 20. Ra2 {+0.03/19 27s} Rc8 {0.00/14 5s
(Db6)} 21. Bd2 {+0.14/17 22s (Lg4)} Qe7 {-0.05/14 29s (d5)} 22. Ba6 {+0.17/21
1:36m (b4)} Rc7 {-0.19/15 19s} 23. Ba5 {+0.16/18 2s (b4)} Nb6 {+0.02/15 34s}
24. Re1 {+0.26/19 25s} Qe6 {0.00/15 0s} 25. b3 {+0.18/18 19s} Qd5 {+0.04/14
21s (Tce7)} 26. Bd2 {+0.25/17 24s} c5 {+0.03/14 0s} 27. Bb5 {+0.26/18 26s} Rb8
{+0.21/13 11s (Tee7)} 28. e4 {+0.45/20 1:08m} Qe6 {+0.22/14 3s} 29. e5 {+0.39/
19 13s} dxe5 {+0.29/14 0s} 30. fxe5 {+0.10/19 26s} Bxe5 {+0.17/14 0s} 31. Bf4 {
+0.05/20 26s} f6 {+0.27/14 0s} 32. Bxe5 {+0.38/18 15s} fxe5 {+0.36/14 0s} 33.
Qc3 {+0.34/19 14s} Rf8 {+0.51/14 18s} 34. Rae2 {+0.60/18 2s} c4 {+0.40/14 18s
(Df5)} 35. Rxe5 {+0.36/18 22s} Qf7 {+0.48/15 40s} 36. Re8 {+0.60/22 19s} Qf2+ {
+0.59/15 5s} 37. Kh1 {+0.68/22 22s} Rxe8 {+0.41/15 19s} 38. Rxe8+ {+0.71/21 3s}
Kf7 {+0.41/15 0s} 39. Re1 {+0.69/21 31s} Kg8 {+0.58/15 15s (Sd5)} 40. Rc1 {+0.
60/19 44s (Db4)} h6 {+0.44/14 21s} 41. bxc4 {+0.71/22 46s} Rc5 {+0.44/15 0s}
42. a4 {+0.81/21 17s (Te1)} a6 {+0.67/14 45s} 43. Bxa6 {+0.84/23 15s} Rh5 {+0.
70/14 8s} 44. h4 {+0.88/22 32s} Nxa4 {+0.70/15 0s} 45. Qe1 {+0.93/21 21s} Qf3+
{+0.85/15 8s} 46. Kh2 {+0.94/21 21s} Nc5 {+0.73/15 10s} 47. Rc3 {+0.92/20 0s
(Lc8)} Qf8 {+0.81/15 30s} 48. Bb5 {+0.82/22 21s} Kh7 {+0.91/15 0s (Tf5)} 49.
Re3 {+1.06/18 11s} Rf5 {+0.91/15 7s} 50. Qb1 {+1.13/19 8s} g6 {+0.96/15 11s}
51. Bc6 {+1.18/19 11s (De1)} Rf1 {+1.15/14 1:01m} 52. Re7+ {+1.17/23 0s} Qxe7 {
+1.18/16 24s} 53. Qxf1 {+1.17/22 4s} Kg8 {+1.18/17 28s (Sd7)} 54. Bd5+ {+1.30/
18 10s} Kg7 {+1.18/17 6s} 55. Qf2 {+1.18/22 5s} h5 {+1.23/16 42s} 56. Kg2 {+1.
21/27 5s} Kh7 {+1.27/16 15s} 57. Qf4 {+1.21/23 3s (Kf3)} Kg7 {+1.27/17 28s} 58.
Qd4+ {+1.17/23 3s} Kh7 {+1.27/16 0s} 59. Bf3 {+1.17/22 11s (Kf3)} Kg8 {+1.32/
16 17s} 60. Kf2 {+1.22/22 8s (Ld5+)} Qf8 {+1.27/16 20s} 61. Ke2 {+1.27/25 1s
(Kg2)} Qe7+ {+1.27/16 21s} 62. Qe3 {+1.22/23 5s} Qd6 {+1.32/15 11s} 63. Kf2 {
+1.20/20 0s (Ld5+)} Kg7 {+1.27/14 14s} 64. Kg2 {+1.26/23 33s (Ld5)} Kh7 {+1.33/
15 15s} 65. Bd5 {+1.30/23 9s} Qf8 {+1.34/16 5s} 66. Qe5 {+1.45/24 5s} Nd3 {+1.
34/17 31s} 67. Qc7+ {+1.45/26 4s (De2)} Kh6 {+1.38/16 18s} 68. Qf7 {+1.72/24
22s} Qxf7 {+1.57/17 0s} 69. Bxf7 {+1.78/20 0s} Ne5 {+1.07/18 12s (Sc5)} 70. Bd5
{+2.33/25 8s (Lg8)} g5 {+1.02/10 0s} 71. Kf2 {+2.30/26 9s (Kh3)} gxh4 {+0.01/
20 16s (Kg6)} 72. gxh4 {+2.93/26 8s} Nxc4 {+0.01/25 2s (Kg7)} 73. Bxc4 {+3.99/
28 0s} Kg7 {+0.01/30 10s (Kg6)} 74. Be2 {+4.02/45 40s (Ke2)} Kf6 {+0.01/32 30s
(Kg6)} 75. Bxh5 {+4.02/29 35s (Kg1)} Kg7 {0.00/63 0s (Kf5)} 76. Kf3 {+4.01/32
31s (Lg6)} Kf6 {0.00/63 0s (Kh6)} 77. Kg4 {+4.07/48 28s (Ke4)} Kg7 {0.00/63 0s}
78. Kg5 {+4.06/26 24s} Kh8 {0.00/63 0s (Kg8)} 79. Bg6 {+3.99/33 22s (Lf7)} Kg8
{0.00/63 0s} 80. h5 {+4.12/60 2s (Kh6)} Kh8 {0.00/63 0s (Kg7)} 81. h6 {+3.99/
66 3s (Kh6)} Kg8 {+0.01/6 0s} 82. Be4 {+4.06/71 3s (Kf6)} Kh8 {0.00/63 0s} 83.
Kg6 {+4.02/55 6s} Kg8 {0.00/63 0s} 84. Kh5 {+4.12/28 20s (Ld5+)} Kh8 {0.00/59
0s} 85. Kg5 {+4.09/55 8s} Kg8 {0.00/63 0s} 86. Kg6 {+4.04/44 0s (h7+)} Kh8 {0.
00/63 0s} 87. Bf5 {+4.03/62 1s} Kg8 {0.00/63 0s} 88. Bg4 {+3.99/70 1s (h7+)}
Kh8 {0.00/63 0s time} 1/2-1/2



Gruß
Günther
Parent - - By Günther Höhne Date 2010-09-11 14:32
Hier noch ein weiteres Besipiel, auch hier hätte Komodo auf Zeit verloren.



[Event "20 Minuten/Partie + 5 Sekunden/Zug"]
[Site "Engine Match"]
[Date "2010.09.03"]
[Round "1"]
[White "Thinker 5.4Di x64"]
[Black "Komodo64 1.2 JA"]
[Result "1/2-1/2"]
[PlyCount "285"]
[EventDate "2010.??.??"]

1. d4 {Buch 0s} d5 {Buch 0s} 2. c4 {Buch 0s} c6 {Buch 0s} 3. Nf3 {Buch 0s} e6 {
Buch 0s} 4. e3 {Buch 0s} Bd6 {Buch 0s} 5. Nc3 {+0.01/1 41s} f5 {Buch 0s} 6. Ne5
{Buch 0s} Nf6 {Buch 0s} 7. Be2 {Buch 0s} O-O {Buch 0s} 8. O-O {Buch 0s} Nbd7 {
Buch 0s} 9. f4 {+0.01/1 35s} Be7 {+0.25/19 42s} 10. a3 {+0.01/1 27s (Db3)} Ne4
{+0.15/19 31s} 11. cxd5 {+0.01/1 26s (Sxe4)} cxd5 {+0.09/21 28s} 12. Nxe4 {+0.
01/1 25s (Db3)} Nxe5 {+0.12/23 36s} 13. dxe5 {+0.01/1 16s (fxe5)} fxe4 {+0.07/
22 40s} 14. Qd4 {+0.01/1 34s} Qb6 {+0.13/24 3s} 15. Qxb6 {+0.01/1 45s} axb6 {
+0.11/24 8s} 16. Bd2 {+0.01/1 41s} Bd7 {+0.21/24 11s} 17. Rfc1 {+0.01/1 49s}
Rac8 {+0.21/25 13s} 18. Rxc8 {+0.01/1 1:19m} Rxc8 {+0.20/27 1:20m} 19. Rc1 {+0.
01/1 33s} Rc6 {+0.20/23 4s} 20. Kf1 {+0.01/1 22s (b4)} g5 {+0.19/21 1:20m} 21.
g3 {+0.01/1 0s} gxf4 {+0.19/21 40s} 22. gxf4 {+0.01/1 29s} Rxc1+ {+0.29/20 5s}
23. Bxc1 {+0.01/1 8s} Kg7 {+0.21/26 13s} 24. Bd2 {+0.01/1 36s (Lg4)} Kg6 {+0.
26/25 28s} 25. Bc3 {+0.01/1 3s (Lg4)} h5 {+0.26/26 54s} 26. Ke1 {+0.01/1 31s}
b5 {+0.27/27 4s} 27. Kd2 {+0.01/1 21s (Kf2)} Bd8 {+0.28/27 26s} 28. Bf1 {+0.01/
1 35s} Bc7 {+0.28/28 33s} 29. Bh3 {+0.01/1 34s} Bb6 {+0.27/30 6s} 30. Ke2 {+0.
01/1 17s} Bc7 {+0.27/30 4s} 31. Bd4 {+0.01/1 31s} Ba5 {+0.26/31 28s} 32. Bc5 {
+0.01/1 27s} Kf7 {+0.27/27 1s} 33. Kd1 {+0.01/1 32s (Lf1)} Kg6 {+0.27/26 23s}
34. Kc2 {+0.01/1 26s} Be1 {+0.27/28 26s} 35. Bg2 {+0.01/1 26s} Kf5 {+0.27/28 4s
} 36. Bf1 {+0.01/1 36s} Kg6 {+0.28/28 6s} 37. Kb3 {+0.01/1 13s (Kd1)} Ba5 {+0.
26/27 23s} 38. Bh3 {+0.01/1 7s} Be1 {+0.30/23 17s} 39. Bb6 {+0.01/1 3s (Kc2)}
Kh6 {+0.22/25 34s} 40. Bf1 {+0.01/1 17s (Lg2)} Kg6 {+0.24/28 24s} 41. Bg2 {+0.
01/1 34s} Bc6 {+0.27/27 35s} 42. Ba7 {+0.01/1 17s (Ld4)} Bd7 {+0.27/25 18s} 43.
Bc5 {+0.01/1 6s} Be8 {+0.20/26 10s} 44. Bf1 {+0.01/1 15s (Kc2)} Bc6 {+0.21/28
25s} 45. Ba7 {+0.01/1 24s (Ld4)} Be8 {+0.15/26 20s} 46. Bh3 {+0.01/1 21s (Ld4)}
Bd7 {+0.19/26 15s} 47. Bd4 {+0.01/1 1s (Lc5)} Ba5 {+0.26/25 22s} 48. Bf1 {+0.
01/1 19s (Ka2)} Kf5 {+0.08/26 18s} 49. Be2 {+0.01/1 2s} Be8 {+0.11/27 13s} 50.
Bc5 {+0.01/1 22s} Be1 {+0.05/27 5s} 51. Kc2 {+0.01/1 22s (Lb6)} Kg6 {+0.11/25
14s} 52. Kd1 {+0.01/1 9s (Ld4)} Bf2 {0.00/28 15s} 53. Kd2 {+0.01/1 18s} Bg1 {
0.00/28 0s} 54. h3 {+0.01/1 19s} Bf2 {0.00/28 0s} 55. Bd1 {+0.01/1 16s (Kc3)}
Kf5 {0.00/31 17s} 56. Bb6 {+0.01/1 13s (Le2)} Kg6 {0.00/25 13s} 57. Ke2 {+0.01/
1 12s} Bg3 {0.00/33 1:03m} 58. Bc2 {+0.01/1 13s (Kd2)} Kf5 {0.00/26 20s} 59.
Kd2 {+0.01/1 12s} Bf2 {0.00/30 4s} 60. Bb3 {+0.01/1 16s (Kc3)} Bg3 {0.00/27 12s
} 61. Ke2 {+0.01/1 17s (Kc3)} Bg6 {0.00/32 11s} 62. a4 {+0.01/1 10s (Lc2)} Be8
{+0.03/27 1:05m} 63. a5 {+0.01/1 0s} Bh4 {0.00/27 10s} 64. Kd2 {+0.01/1 6s} Be7
{0.00/27 8s} 65. Kc3 {+0.01/1 7s} Bh4 {0.00/27 3s} 66. Kd4 {+0.01/1 11s (Lc2)}
Bf2 {0.00/26 14s} 67. Bc2 {+0.01/1 14s (Ld1)} b4 {0.00/25 14s} 68. Bd1 {+0.01/
1 13s} Bh4 {0.00/29 0s} 69. Bb3 {+0.01/1 17s (Lc2)} Bf2 {0.00/28 10s} 70. Bc2 {
+0.01/1 15s} Bb5 {0.00/28 37s} 71. Bd1 {+0.01/1 13s (Lc5)} Be8 {0.00/25 8s} 72.
Ba7 {+0.01/1 16s (Le2)} Kg6 {0.00/27 39s} 73. Be2 {+0.01/1 0s (Lc5)} Kf5 {0.00/
25 23s} 74. Bb6 {+0.01/1 26s (Lc5)} Bh4 {0.00/27 7s} 75. Bf1 {+0.01/1 13s (b3)}
Bd7 {0.00/24 11s} 76. Ba7 {+0.01/1 8s (Lc5)} Bf2 {0.00/27 6s} 77. a6 {+0.01/1
2s (Le2)} bxa6 {0.00/28 7s} 78. Bxa6 {+0.01/1 1s} Be8 {0.00/30 22s} 79. Be2 {
+0.01/1 0s (Lc5)} Bh4 {0.00/27 6s} 80. Bb6 {+0.01/1 5s (Lc5)} Bf2 {0.00/29 6s}
81. Bf1 {+0.01/1 8s (Lc5)} Ba4 {0.00/25 7s} 82. Bc5 {+0.01/1 3s (Le2)} Be1 {0.
00/30 7s} 83. Be2 {+0.01/1 6s} Be8 {0.00/32 2s} 84. Be7 {+0.01/1 6s (Ld1)} Bd2
{0.00/26 36s} 85. h4 {+0.01/1 0s} Bf7 {-0.48/24 8s} 86. Bd1 {+0.01/1 12s (Lc5)}
b3 {-0.09/25 16s} 87. Bc5 {+0.01/1 0s (Lxb3)} Ba5 {-0.66/27 5s} 88. Bxb3 {+0.
01/1 4s} Bd8 {-0.62/26 0s} 89. Bd1 {+0.01/1 14s} Bxh4 {-0.53/28 9s} 90. Be2 {
+0.01/1 1s} Bf2 {-0.68/25 3s} 91. b4 {+0.01/1 8s} h4 {-0.52/26 0s} 92. b5 {+0.
01/1 11s} h3 {-0.80/26 2s} 93. Bf1 {+0.01/1 9s} h2 {-0.80/25 0s} 94. Bh3+ {+0.
01/1 11s} Kg6 {-0.80/26 12s} 95. Bg2 {+0.01/1 5s} Be8 {-0.87/24 1s} 96. b6 {+0.
01/1 10s} Bc6 {-0.80/25 21s} 97. Bb4 {+0.01/1 1s (Lh1)} Bb7 {-0.89/24 6s} 98.
Be7 {+0.01/1 5s (La3)} Be1 {-1.01/20 7s} 99. Bd8 {+0.01/1 9s} Kf7 {-0.97/23 0s}
100. Bh1 {+0.01/1 12s (Lc7)} Ba5 {-1.51/23 5s} 101. Kc5 {+0.01/1 3s (Lc7)} Bd2
{-1.44/25 6s} 102. Kd4 {+0.01/1 1s} Ke8 {-1.43/22 6s} 103. Bg5 {+0.01/1 4s
(Lh4)} Kd7 {-1.42/25 6s} 104. f5 {+0.01/1 4s} exf5 {-1.46/26 2s} 105. Bf4 {+0.
01/1 8s} Bc1 {-1.47/27 1s} 106. e6+ {+0.01/1 9s} Kxe6 {-1.45/27 1s} 107. Bxh2 {
+0.01/1 9s} Kd7 {-1.57/27 13s} 108. Bf4 {+0.01/1 0s} Kc6 {-1.51/26 9s} 109. Ke5
{+0.01/1 1s} Bc8 {-1.49/25 3s} 110. Bh6 {+0.01/1 7s (Lg5)} Bb2+ {-1.69/24 5s}
111. Kf4 {+0.01/1 0s} Kxb6 {-1.63/25 4s} 112. Bf8 {+0.01/1 10s} Kb5 {-1.63/28
6s} 113. Bg2 {+0.01/1 4s} Kc4 {-1.63/27 2s} 114. Bf1+ {+0.01/1 7s} Kb3 {-1.68/
26 19s} 115. Bh3 {+0.01/1 0s} Kc2 {-1.75/27 22s} 116. Bc5 {+0.01/1 6s (Lxf5)}
Bg7 {-1.70/25 5s} 117. Kg5 {+0.01/1 4s} Kc3 {-1.70/24 2s} 118. Bb6 {+0.01/1
12s (Ld6)} d4 {-1.69/27 4s} 119. exd4 {+0.01/1 6s (La5+)} Bxd4 {-1.70/26 4s}
120. Bxf5 {+0.01/1 5s} Bxf5 {-1.73/35 2s} 121. Kxf5 {+0.01/1 7s} e3 {-1.72/34
17s} 122. Ba5+ {+0.01/1 14s (Ld8)} Kd3 {-1.69/38 23s} 123. Kf4 {+0.01/1 5s} Bb2
{-1.70/36 14s} 124. Kf3 {+0.01/1 9s (Le1)} Bc1 {-1.70/36 2s} 125. Bb4 {+0.01/1
5s (Lb6)} Bd2 {-1.70/38 2s} 126. Bd6 {+0.01/1 4s} e2 {-1.69/40 5s} 127. Bg3 {
+0.01/1 3s} Bc3 {-1.70/33 0s} 128. Bf2 {+0.01/1 7s} Bb4 {-1.69/40 13s} 129. Bg3
{+0.01/1 10s} Kd2 {-1.69/37 3s} 130. Bf2 {+0.01/1 6s} Bd6 {-1.70/43 0s} 131.
Ke4 {+0.01/1 10s (Lh4)} Bc5 {-1.68/33 18s} 132. Bh4 {+0.01/1 0s (Lg3)} Be3 {-1.
68/30 1s} 133. Be7 {+0.01/1 9s (Lg3)} Kd1 {-1.66/27 1s} 134. Bh4 {+0.01/1 7s}
Bg5 {-1.63/34 4s} 135. Bf2 {+0.01/1 3s (Lg3)} Kd2 {-1.69/34 2s} 136. Bg3 {+0.
01/1 6s (Kf3)} Bf6 {-1.64/34 2s} 137. Bf4+ {+0.01/1 9s (Lf2)} Ke1 {-1.60/38 4s}
138. Bg3+ {+0.01/1 9s} Kf1 {-1.75/54 0s} 139. Kd3 {+0.01/1 7s (Ke3)} Be5 {-1.
67/49 10s} 140. Bh4 {+0.01/1 0s} Bd6 {-0.02/43 16s} 141. Ke3 {+0.01/1 0s (Ke4)}
Bb4 {-0.02/50 1s} 142. Kf3 {+0.01/1 5s} Bc3 {-0.02/74 0s} 143. Bf2 {+0.01/1 9s
time} 1/2-1/2

Gruß
Günther
Parent - - By Frank Quisinsky Date 2010-09-11 14:55
Hi,

ja, das sind diese schrecklichen Dinger.
48x in der SWCR-64 und mehr als 100x in der SWCR-32.

Aber ... die GUI stürzt nicht ab.
Alles schon von Ingo und meiner Wenigkeit zu Don gesendet.

Don sieht das ganz cool.
Unter uns, liest ja keiner mit ...

Da kommt kein Update mehr.
Der programmiert etwas neues.

Gruß
Frank
Parent - - By Günther Höhne Date 2010-09-11 15:07
[quote="Frank Quisinsky"]
Da kommt kein Update mehr.
Der programmiert etwas neues.
[/quote]

Hallo Frank,

etwas neues, das kann ja vieles sein... Bleibt zu hoffen, dass er der Schachprogrammierung treu bleibt.

Gruß
Günther
Parent - By Frank Quisinsky Date 2010-09-11 15:20
Hi Günther,

das es im Computerschach derzeit ruhig ist täuscht.
Es ist alles andere als ruhig.

Er programmiert sicherlich an etwas was wir uns alle wünschen

Gruß
Frank
Parent - - By Ingo Bauer Date 2010-09-11 15:49
Hallo Frank,

Warum fragst du mich, wenn du schon lange eine Antowort auf alles hast:

[quote="Frank Quisinsky"]
Kann mir nicht vorstellen, dass Houdini bei Dir rund läuft, kann nicht sein!
[/quote]

Auch dein weiteren Einlassungen in diesem Thread scheinen mir nicht auf eine Frage hinauszulaufen sondern auf Meinungmache

Aber trotzdem kurz zu Houdini 1.03a.

Ja, Houdini stürtzt ab und zu, so wie von dir beschrieben, ab, aber die schlimmste Engine ist es bei weitem nicht. Andere sind da viel schlimmer bei mir (inklusive einer kommerziellen), wieder andere verursachen 0 Probleme. Mit Kommodo müßtest du mit obiger Kritik sofort das spielen einstellen, machst du aber nicht weil die die eine Engine sympathiser ist als die andere. Twisted logic lief bei mir als eine der besten (ich kann mich nicht an einen einzigen Crash erinnern).

Was deine "Ich komme nicht an meine Rechner ran" betrifft: Deswegen habe ich schon ewig auf ALLES einen Remotezugriff. solange der Rechner noch läuft komme ich ran, habe ich einen Bluescreen stehen die Rechenr auf Neustart und ich kann von Remote das Turnier fortführen.
Vonwoaus auch immer ich in einem Forum posten kann (so wie du gerade), kann ich an meine Rechner - sogar von meinem Android Handy aus!

[quote="Frank Quisinsky"]
... 6 Remis Partien gegen andere Engines mussten also wiederholt werden und bei den Wiederholungen gewinnt Houdini dann meist ....
[/quote]

Sorry, aber das ist statistisch natürlich unhaltbar. Natürlich gewinnt er mal eine Remispartie bei der Wiederholung, aber er kann auch wieder Remisspielen und sogar. Wenn du genug Remispartien nochmal spielst, sollte sich ein ausgeglichenes Punkteverhältniss einstellen, nur hat Houdini nicht so viele Remispartien.

Gruß
Ingo
Parent - - By Frank Quisinsky Date 2010-09-11 16:23 Edited 2010-09-11 16:27
Hi Ingo,

ich wollte nur wissen ob Du die Abstürze auch hat!
Wollte nicht wissen ob Du am WE durch die Gegend läufst und mittels Handy prüfst ob Houdini noch läuft.

Sag mal ... also die Kirche im Dorf lassen und nicht mitschleppen

...

Nicht ob Du mit Remote die Buggy Engines über Dein Handy steuerst. Auf meinen SWCR Systemen sind 8 Dienste Aktiv, ich werde sicherlich nicht hingehen und das Remote Zeug aktivieren damit ein Schachturnier läuft, mit notwendigen Sicherheitsmechanismen die Rechner schützen weil der Remote Zugriff offen ist. Auch wenn ich darüber auch schon nachgedacht habe, aber es sollte doch möglich sein dass in heutigen Zeiten ein Schachprogramm nicht mehr mit solchen primitiven Hängern eine GUI lahm legt. Erinnert mich eher an Winboard Zeiten als einige wenige bemüht waren sämtliche Engines auf solche und andere Fehler zu prüfen. Habe hunderte Stunden in Zeiten damit verbracht Sergei Abramov (Convekta GUIs) oder Martin Blume etc, etc. mit solchen Fehlermeldungen zu helfen.

Sag mal ...
Also irgend wann sollte es auch mal gut sein

Also nach 230 Partien 8 Hänger ... 4.0 : 4.0 Punkte da in Remis Positionen.
Die Wahrscheinlichkeit das die Engine bei einer Erfolgsquote von 80% wieder ein 4.0 : 4.0 produziert ist sehr gering. Bleibt es bei dem Schnitt 8 von 230 sind das 5 ELO die durch Partie Wiederholungen manipuliert wird.

Da Du ohne Aufgabefaktor spielst, werden die Partien bei Dir früher mit Remis beendet und von daher wirst Du nicht so viele Hänger haben. Werde die Abstürze zählen und Punkte beim Endergebnis unter Heranziehung der Erfolgsquote abziehen.

Houdini macht nach 920 Partien 80%
stürzt 32x ab.

16:16 Punkte wäre das tatsächliche Ergebnis!

Diese 32 Partien werden dann wiederholt ... 80% von 32 möglichen Punkten = 25,5 : 6,5 ... hatte aber tatsächlich 16 : 16 und insofern werden 9,5 Punkte abgezogen wenn es wirklich zu 32 Abstürzen nach 920 Partien kommt ... FERTIG ... mit einem dicken Hinweis in der Ratingliste das die Engine derart buggy ist das ein Test eigentlich fast unmöglich ist. Wir wollen doch informieren ... gelle!

Sonst ist ja die ELO komplett manipuliert.

Bei Twisted oder Komodo ist das einfach zu ändern, GUI stürzt auch nicht ab. Shredder speichert die Partie und setzt ein "time".

Also, keine Meinungsmache ... eher ... hier wird eine Engine bewertet die aufgrund der Fehler eigentlich gar nicht bewertet werden kann.

Gruß
Frank
Parent - - By Frank Quisinsky Date 2010-09-11 16:43 Edited 2010-09-11 16:46
Hallo zusammen,

muss mal schauen, zunächst wird Houdini normal durchspielen. Die Abstürze werden korrigiert und wie beschrieben gezählt. Die Partien werden normal wiederholt.

Bislang gab es nicht 8 sondern 7 (sorry).

1x gegen Rybka
1x gegen Stockfish
1x gegen Loop
1x gegen Junior
1x gegen Spark
1x gegen Fruit
1x gegen muss nachsehen (war Crafty NP)

Die Frage ist nach der Korrektur:
Wie gehe ich überhaupt vor?
Ich meine für diese genannten Engines.

Ich könnte Houdini 9.5 Punkte abziehen und 0 Züge Partien mit Ergebnissen in die Datenbanken setzen.
Ich weiß ja dummerweise nicht wie die Nachholpartien endeten (nicht verfolgt).

Macht auch keinen Sinn, ob nun eine Engine bei so vielen Partien einen halben Punkt mehr oder weniger hat.

Also, bei dem Beispiel:
Houdini stürzt 32x in Remis Positionen nach 920 Partien ab und erhält nach der Berechnung im letzten Beitrag 9.5 Punkte weniger.
Könnte ich eine Liste erstellen und 18 Gewinnpartien von Houdini auf Remis setzen. Nehme dann je eine Partien von der 18 Engines hinter Houdini. Errechne die neue ELO und ermittle wie viel ELO es genau sind. Ziehe diesen Wert dann mit einen Hinweis in der Ratingliste ab, lasse aber alle Partien so wie sie sind drin. So bleiben alle Original Partien in der Liste (die 0 Züge Partien dienen lediglich zur Ermittlung der genauen ELO) und ich kenne den genauen Wert. Es sind nicht 5 sondern zwischen 3-4 ELO wenn es wirklich nach 920 Partien zu 32 Abstürzen kommt.

Irgendwie so ...

Gruß
Frank
Parent - - By Frank Quisinsky Date 2010-09-11 16:58
Hallo zusammen,

die andere Alternative wäre ... den Test von Houdini zu stoppen und die Engine im laufenden Turnier durch eine andere IPP Familie Engine zu ersetzen. Wäre aber schade da der Test läuft, allerdings wird die komplette Datenbank auch noch manipuliert. Oder einfach die Partien stillschweigend wiederholen und so tun als ob nichts wäre, wie es Ingo macht.

Fire 1.31 läuft ja auch nicht sonderlich rund aber stürzt zumindest nicht ab (schlechtes Zeitmanagement in Ponder Partien, bei Ponder Treffer zu schnelle Antworten ... die Zeit wird offenbar den anderen Zügen aber nicht mehr gegeben ... was für ein blöder Parameter hierzu in der Konfigurationsdatei ... unsinnig!

Bin mal gespannt mit welchen Überraschungen IvanHoe um die Ecke kommt. Kann es kaum noch erwarten ...

Gruß
Frank
Parent - By Ingo Bauer Date 2010-09-11 19:56
[quote="Frank Quisinsky"]
... Oder einfach die Partien stillschweigend wiederholen und so tun als ob nichts wäre, wie es Ingo macht...
[/quote]

Nur damit hier kein falscher Eindruck entsteht:

1. Ich wiederhole nichts "stillschweigend"! Als generelle Regel wiederhole ich ALLE Spiele, von JEDER Engine die nicht beendet wurden. Zeitüberschreitung IST nach den Schachregeln ein ordentliches Ende - Diese Spiele werden selbstverständlich NICHT anders gewertet oder gar wiederholt (Das wäre ja ein  Verstoß gegen die Regeln!). Ich wiederhole nur Spiele bei denen die GUI abgestürzt ist. Welchen "Status" das Spiel davor hatte, interessiert mich dabei nicht, da es für die Anwendung meiner Regel irrelevant ist (und ich schon so manche Remisstellung gesehen habe die eine Engine noch "vergeigt" hat).

2. Die Anzahl an Spielen die ich wiederholen muß liegt, auch für Houdini, unter 1%.

3. Ehe ich mich so über Houdini ereifern würde, müßte ich mir hier Luft wegen dreier anderer größerer und bekannterer, zum Teil sogar kostenpflichtiger, Engines verschaffen - lohnt aber nicht.

4. ALLE abgestürtzen GUIs und Engines, egal welche und auch Houdini, konnte ich bisher IMMER mit dem XP64 Taksmanager beenden.

Gruß
Ingo
Parent - By Frank Quisinsky Date 2010-09-12 10:33 Edited 2010-09-12 10:38
Hi Ingo,

nochmals kurz gelesen ...

Twisted crash nicht sondern überzieht in klaren Remisstellungen die Zeit.
Auch fast 50 Partien vorhanden, die von mir auf Remis korrigiert wurden.

Da Du das nicht prüfst (anderer Beitrag im Thread) fällt Dir das natürlich nicht auf.
Wenn eine Partie schon zu 100% remis ist, sollte die Partie auch Remis bleiben.

Solche Zeitüberschreitungen, wie auch diese von Twisted die auch Komodo produziert, werden von mir korrigiert, denn mich interessiert das tatsächliche Partie Ergebnis und nicht ein Ergebnis welches durch einen offensichtlichen Fehler (bei Twisted gar immer einen Zug vor dem tatsächlichen Remis) zu Stande kommt. Ich will doch eine genaue ELO messen!

Bei Hannibal 1.0a sah ich diesen Fehler in nun über weit über 1.500 Partien erst 1x.
Also offensichtlich behoben.

Wie gesagt, fällt auch eher auf wenn bis zum Ende gespielt wird und nicht durch irgend einen Aufgabefaktor die laufende Partie abgebrochen wird.

Gruß
Frank
Parent - - By Wolfgang Battig Date 2010-09-11 17:56
[quote="Frank Quisinsky"]
....

Kann mir nicht vorstellen, dass Houdini bei Dir rund läuft, kann nicht sein!


Hallo Frank,

ist ja interessant - wie Ingo schon schrieb - was Du so alles weißt, was auf ander Leuts Rechnern abgeht, Respekt!

Ich weiß nicht, was bei Dir oder Ingo passiert, aber meinen Test kann ich beurteilen. Nach bisher ca. 450 Partien mit Houdini 1.03a hat
es genau EINE ZÜ gegeben, die ich als Remis gewertet habe weil es einen Zug vor einer erzwungenen Pattstellung passierte. Aber: Houdini ist nicht im Speicher geblieben! Dieses Phänomen konnte ich bisher nicht beobachten. Ich spiele übrigens auch ohne Aufgeben/Remis anbieten, lediglich das Häkchen bei "ZÜ beachten" ist gesetzt.

Wenn ich jetzt wie Du argumentieren würde, müsste ich Dir leider sagen: "Kann mir nicht vorstellen, dass Houdini bei Dir Probleme macht, kann nicht sein!" Tu ich aber nicht. Dafür sind die Konfigurationen bei den Testern einfach zu unterschiedlich als dass man von sich auf andere schließen sollte!

Zitat:
Diese Engine kann im Grunde mit automatischen Turnieren nicht getestet werden.


Das ist - bei allem Respekt - totaler Quatsch! Es gibt deutlich schlimmere Engines als Houdini (Komodo 1.2, teilweise ältere Rybkas, Loop selten aber auch häufiger als Houdini, Zappa Mexico II, Jonny 3.08 usw.).

Ich habe den Eindruck, Frank, dass Du keine Lust mehr auf Houdini hast und irgendwie versuchst aus der Nummer rauszukommen. Erst hast Du die IPPs "verdammt", dann doch aufgenommen und jetzt willst Du wieder nicht mehr. Warum sagst Du es dann nicht einfach? Du bist doch sonst auch ein Freund klarer Worte. So erinnert es an das Rumgeeiere von Politikern, sorry.

Wie gesagt, ist aber nur eine Vermutung

Gruß
Wolfgang

PS: Bei Houdini 1.02 hatte ich in bisher 1400 Partien übrigens GAR KEINEN Hänger/ZÜ, nur so nebenbei...

Parent - By Frank Quisinsky Date 2010-09-11 18:23 Edited 2010-09-11 18:29
Hallo Wolfgang,

übrigens, es steht das nächste Match ... LIVE Tabelle ... gegen Shredder!
Damit Absturz Nummer 8 und von den 8 laufenden Matches sind jetzt noch 6 aktiv.

Es kommt natürlich auf die Testbedingungen an, wie Du sicherlich weist.
Um was für einen Fehler es sich handelt habe ich beschrieben.

Das dieser dann auch mit Ponder zu tun hat ... maximale Zugtiefe erreicht, Engine rechnet, andere Engine rechnet auch und beim Wechsel kommt der Hänger. Ich gehe davon aus, dass Du ohne Ponder spielst, mithin siehst Du den Fehler nicht und zu Zeitüberschreitungen sollte es dann auch nicht kommen. Also die NON-Ponderer bleiben verschont.

Aus der Nummer heraus komme, warum, aus welcher?
Aus der das dies die erste Engine ist die gnadenlos eine GUI zum Absturz bringt ... OK macht Ktulu auch aber aus anderen Gründen.

Teste die IPP Familie jetzt mal durch aber wenn die Matches hängen bleiben, die GUI abstürzt dann liegt ein Problem vor!
Denn ich habe natürlich keine Lust 24 Stunden am Tag daneben zu sitzen um mittels Task-Manager auf die Abstürze zu reagieren.

Und zu Deinem ersten Satz.
Auch Ingo spielt mit Ponder, wir setzen die Netzwerkfunktion von Shredder ein. Ein Turnier oder Spießrountenlauf und alle greifen auf diese *.sto Turnierdatei zu. Da der Fehler absolut offensichtlich ist, muss Ingo diese Abstürze auch haben, was er ja auch gerade bestätigte. Allerdings halten sich diese in Grenzen weil meist im klaren Remis Stellungen im Endspiel die Abstürze erfolgen und da Ingo nicht bis zum Ende spielen lässt, kommen die Abstürze bei Ingo sicherlich seltener vor.

Also ich habe jetzt nach 252 Ponder = ON Partien genau 8 Abstürze der GUI, aggressiverster Art. Selbst der Task Manager konnte 2x den Prozess nicht töten. Unlocker 1.9.0 musste einspringen ... was für ein Schrott! Was macht die Engine da?

Übrigens, dass so viele das Problem nicht erkennen ist klar.
Um mehr Partien zu generieren wird meist ohne Ponder gespielt.
Um weitere Partien mehr zu generieren wird der Aufgabemodus eingeschaltet.

Mit Zappa hatte ich noch nie ein Problem.
Die Komodo Probleme bringen die GUI nicht zum Absturz.

Aber ...
Es ist bei allen IPP Familie Programmen ein ganz dickes Problem drin.
Kein mir bekanntes produziert einen korrekten Ponder Mode.

Fire spielt zu schnell auf Ponder Treffer und das Zeitmanagement ist schlecht.
Houdini stürzt bei max. Suchtiefe im Ponder Mode ab.

Und ich bin wirklich schon richtig neugierig auf IvanHoe.
Die ganzen ersten Versionen dieser ganzen IPP Familie Programme hatten alle ein Ponder Problem.
Heute etwas versteckter aber noch vorhanden.

Scheint das die Truppe von Hobbyprogrammierern bei dem Ponder Mode vor einer echten Herausforderung steht.
Löst im Grunde jeder Programmierer in wenigen Stunden.

Nun gut ...

Houdini hat erst mal wieder eine 23er Runde gespielt. Mit den nächsten Abstürzen ist in ca. 7 Stunden zu rechnen wenn die Houdini wieder spielt. Mal schauen wie viele von den noch 6 von 8 laufenden Matches dann hängen bleiben. Bis Montag wird sich das wahrscheinlich auf 0 laufende Matches reduzieren

Was für eine Murks Programmierung!
Und was für eine grandiose Truppe welche Houdini bislang getestet hat.

BRAVO

Gruß
Frank
Parent - - By Ingo Bauer Date 2010-09-11 19:39
Hallo Wolfgang,

[quote="Wolfgang Battig"]
... Es gibt deutlich schlimmere Engines als Houdini (Komodo 1.2, teilweise ältere Rybkas, Loop selten aber auch häufiger als Houdini, Zappa Mexico II, Jonny 3.08 usw.)...
[/quote]

Das kann ich so nur unterschreiben. Ehe ich mich über Houdini errege, müßte ich aus dem Kopf sofort 3 andere aus meinem Turnier werfen, zwei davon hast du oben genannt. Houdini ist bei weitem nicht die schlimmste Enigne auch wenn ich mir sie stabiler wünschen würde. Wenn ich mich über eine Engine ärgere setze ich ein Posting. Vielleicht ließt es der Programmierer, vielleicht nicht, mir egal. Wenn er etwas ändert gut, wenn nicht überlege ich mir im stillen ob ich die Engine weiterlaufen lasse oder nicht.
Um so einen Wind hier zu machen wie Frank (ob deine open genannten Gründe stimmen soll jeder selbst entscheiden), langt es aber lange nicht.

Um nochmal meinen Gesammteindruck in wenige Worte zu fasssen: Von den Engines die Probleme machen ist Houdini ein ganz gewöhnlich durchschnittliche. Der User der nicht tausende von Partien spielt, wird davon aller Wahrscheinlichkeit nach nichts mitbekommen.

Gruß
Ingo

PS: Loop ist übrigend eine der 100% Engines. Ich kann mich nicht an einen Crash erinnern - so verschieden können Konfigurationen sein!
Parent - - By Frank Quisinsky Date 2010-09-11 20:13
Hallo Ingo,

Loop stürzt ab in Situation Matt gegen sich, reagiert nicht mehr überzieht die Zeit, selten mit Crash.

GUI crasht derzeit bei 4 Engines:

01. Loop 13.6 sehr sehr selten
01a. Loop M1-T, bislang 3x ... siehe Kommentar oben
02. Junior 11.2 (nur x64) unregelmäßig, kann Fehler nicht orten ... aber in mehr als 1.000 Partien
03. Houdini
04. Ktulu (schon öfters beschrieben).

Zurück zu Houdini:
8 x bei jetzt 250 Partien ... mal schauen wie oft denn noch.

3,2% ... nach jeder 33igsten Partie und nicht nach tausenden.
Und das hat auch nichts mit unterschiedlichen Konfigurationen zu tun.

Gruß
Frank ... sehr windig heute
Parent - - By Günther Höhne Date 2010-09-11 20:49 Edited 2010-09-11 20:52
[quote="Frank Quisinsky"]
3,2% ... nach jeder 33igsten Partie und nicht nach tausenden.
Und das hat auch nichts mit unterschiedlichen Konfigurationen zu tun.

Gruß
Frank ... sehr windig heute
[/quote]

Hallo Frank,

naja, wie das im Computerschach nun mal so ist,
Wenn zwei Experten einer Meinung sind, ist einer von ihnen kein echter Experte...
Insofern auch heute alles in bester Ordnung!

Gruß
Günther
Parent - - By Frank Quisinsky Date 2010-09-12 09:45
Hallo Günther,

mit dem Handy Remote steuern um auf Houdini Abstürze zu reagieren.
Da hat Ingo gestern echt den Brüller abgeliefert.

Oder der gute Wolfgang Battig ...
Aus einer Nummer nicht mehr herauskommen!

Mein Gott, was so alles in den Köpfen der Leute ist.
Immer wieder unglaublich solche Dinge zu lesen.

Gruß
Frank
Parent - - By Ingo Bauer Date 2010-09-12 09:48
Hallo Frank

[quote="Frank Quisinsky"]
...
mit dem Handy Remote steuern um auf Houdini Abstürze zu reagieren.
Da hat Ingo gestern echt den Brüller abgeliefert.
...
[/quote]

... und du schaffst es Dinge mal wieder völlig aus dem Zusammenhang zu reißen. Und das ist kein Brüller, sondern nur traurig!

Gruß
Ingo
Parent - By Frank Quisinsky Date 2010-09-12 10:12 Edited 2010-09-12 10:17
Hi Ingo,

das war wirklich witzig, alleine die Vorstellung.

Sitzt gerade bei "Salt" im Kino in der linken Dein Handy in der rechten ...

Um ein Houdini Hänger zu managen.

Sein mir nicht böse, aber das war mein erster Gedanke als ich das las.
Mein Gott, ich bin ja zugegeben schon ein wenig verrückt ... wenn ich denn mal etwas in Angriff genommen habe.

Aber Remote mittels Handy um Abstürze zu händeln.
Jetzt weiß ich auch endlich warum Remote eingeführt wurde

Kein Software Programmierer muss mehr einen Fehler korrigieren, er weist einfach auf die Remote Funktion hin.
Das heutige Zeitalter in Kombination ... mit ... mit den geliebten Handys

Gruß
Frank

Gerade mal nachgeschaut, bei den letzten 23 Houdini Partien kein weiterer Absturz.
6 der 8 Matches laufen noch. Mal schauen wie viele heute Nachmittag bei der nächsten Runde hängen bleiben.
Parent - - By Stefan Pohl Date 2010-09-12 07:23
Also Leute ich weiß nicht, wo das Problem liegt. Ich stelle beim Testen die Nalimov 5-Steiner (und die Triplebases für IvanHoe, aber das ist hier ohne Belang) zur Verfügung, die ja nicht nur Rybka, Naum, Hiarcs und Co nutzen, sondern auch meine Testumgebung die Fritz12-GUI. Und letztere stoppt die Engines, sobald weniger als 6 Steine auf dem Brett sind und spielt die Partie dann selbstständig aus den Tablebases optimal zu Ende. Und die Engineautoren gehen anscheinend davon aus, daß alle Computerschachenthusiasten die Nalimovs heutzutage selbstverständlich haben und benutzen - warum auch nicht?!? Es werden ja auch Eröffnungsbücher oder vorher erstellte Eröffnungsvorgabestellungen benutzt - warum also keine TableBases??? Die gut 7 Gig Speicherplatz kriegt man ja selbst als USB-Stick heutzutage schon aus dem Kaugummiautomaten...
Wenn man die Nalimovs benutzt, gibts solche Probleme nicht. Houdini 1.03a hat bei mir hunderte von Partien OHNE Crash oder Zeitüberschreitung oder sonstige Probleme absolviert. Die einzigen Zeitüberschreitungen produzieren (aber auch nur alle paar hundert Partien) die div. IvanHoes. Und ich spiele auch alle Partien bis zum bitteren Ende, habe also das Remis-geben und Aufgeben durch die GUI beides auf "niemals" gestellt... No Problem.
Die Argumentation, daß eine Engine alles selbstständig spielen muß zieht doch m.E. gar nicht, sonst dürfte man ja weder Bücher noch Vorgabestellungen (die ja aus Büchern bzw. direkt von Menschen stammen) zulassen. Dann hätte man also nur noch eine einzige Ausgangsstellung zum Testen, das wär wohl ziemlich langweilig, oder? Die TableBases nicht zuzulassen ist ergo einfach nicht mehr zeitgemäß und reiner Dogmatismus. Für mich gehören die 5-Steiner TBs genauso zur Testumgebung wie GUI, Hashspeicher und Hardware.

Lange Rede kurzer Sinn: Hat die GUI TableBases, freut sich der Tester !

Gruß - Stefan
Parent - - By Frank Quisinsky Date 2010-09-12 10:03 Edited 2010-09-12 10:06
Hallo Stefan,

Bei 5-Steinern kommt es in der Suche dazu, dass der Prozessor noch ca. 30% der Engine zur Verfügung stellt.
70% Prozessorkraft gehen dabei ins Nirgendwo.

Bei 1+1 also schon sehr früh (z. B. wenn noch 14 Figuren auf dem Brett) dann 0,3 Sekunden pro Zug.
Ganz unabhängig davon, das auch noch Zeit bei der Zugübertragung verloren geht.

GUI gibt den Engines die 5-Steiner:
Eine GUI darf eine Engine nicht beim Spiel beeinflussen. Wir wollen doch die Leistung der Engine messen, und nicht die Leistung von Datenbanken oder einer GUI. Wenn eine Engine die Endspieldatenbanken nicht unterstützt dann sollte das nicht durch Funktion der GUI belohnt werden.

Daher haben wir das bei der Arena Entwicklung natürlich auch nicht umgesetzt.

5-Steiner bei Eng-Eng Matches führen zu einer Benachteiligung von ca. 15-20 ELO. Das wurde schon x mal ausgetestet. Daran ändert auch die Zeitkontrolle nichts, denn es bleibt bei einer Nutzung der Prozessorkraft von ca. 30% in der für Engines schwierigsten Partiephase.

Und die beschriebenen Houdini Probleme treten beim Spielen mit Ponder = on auf.
Zugegeben mit "GUI nutzt TableBases" könnten auch bei Ponder = on die Abstürze minimiert werden.
Bei Ponder = off gibt es solche Probleme nicht, aber Ponder = off ist wie FRC / Chess 960 ... eine Abart vom Schach.
Es ist unnatürlich ohne Ponder spielen zu lassen, wirklichkeitsfremd ... gibt es beim Schach nicht.

Wenn Du also mit Gewalt eine Engine lähmen willst, setzte die 5-Steiner ein.
Das ist ein gutes Mittel ein Handicap einzubauen, wie z. B. auch die Spielstärke zu minimieren.

5 oder 6-Steiner sind gut für Analysen aber für Engine-Engine Matches ist diese Prozessorbremse ein Handicap für jede Engine.
Offenbar hast Du Dich damit noch nicht beschäftigt, lese mal "Beeinflussungsfaktoren auf meiner Webseite".
Dort steht es etwas detailierter ... und vielleicht möchtest Du das ja gar auch selbst mal rausfinden.

Beobachte den TaskManager wenn Engines mit 5-Steiner laufen!

Viele Grüße
Frank
Parent - - By Stefan Pohl Date 2010-09-12 13:49
Also ich habe die TBs auf einem USB-Stick und cache sie doppelt mit 256 MB für die GUI und 256 MB je Engine und von nennenswerten Leistungsverlusten kann keine Rede sein, schon gar nicht nur noch 30% Prozessorleistung...
Die Knotenzahlen, die Rybka, Fritz und auch Hiarcs anzeigen, sind mit und ohne TBs unter der Fritz 12 GUI (mit den obigen Settings) bei halbwegs vollem Brett (>=10-12 Steine) sehr ähnlich. Erst wenn die Trefferzahlen stark zunehmen (so 8 Steine auf dem Brett und weniger), gehen die Knotenzahlen so auf (nicht um!) ca. 70% runter (Deep Fritz 11 z.b. von ca. 10 Millionen auf ca. 7 Millionen Knoten/s), was aber vollkommen logisch ist, da ja viele TB-Abfragen (aber eben auch Treffer!) dazukommen. Zudem macht ein TB-Treffer eine sofortiges Ende der Suche in diesem Ast des Alpha-Beta-Algorithmus-Suchbaums möglich, sodaß viele weitere Knotenberechnungen eingespart werden, was die investierte Zeit zum Nachschauen im Cache/auf dem USB-Stick mehr als wettmacht, was man (bzw. ich) auch daran erkenne, daß die angzeigte Rechentiefe in solchen Stellungen ca. 1-3 (!) Halbzüge höher ist, als ohne TB-Zugriff. Außerdem macht jeder TB-Treffer mit Mattwertung (nicht Remis) viele Knoteneinsparungen in den Nachbarästen der Alpha-Beta-Suche möglich, weil eine solch extreme Bewertung viele Abschneidungen möglich macht (was ja bekanntermaßen das Grundprinzip des Alpha-Beta-Algorithmus ist).
Wenn Du auf deinem System wirklich nur noch 30% Leistung übrig hast, müßte auch die angezeigte Knotenleistung der jeweiligen Engine entsprechend fallen. Nur diese Anzeige ist für die Schachleistung maßgeblich, nicht irgendwelche Anzeigen des Task-Managers. Der zeigt viel an, wenn der Tag lang ist. Und falls auch die angezeigten Knotenzahlen auf 30% fallen sollten (was ich mir kaum vorstellen kann), dann hat Dein Rechner ein ernstes Problem, aber das sind nicht die Tablebases...

Gruß - Stefan
Parent - - By Frank Quisinsky Date 2010-09-12 13:59
Hi Stefan,

aufmerksam gelesen.
Zugegeben, ich habe mich seit dem letzten Test der 5-Steiner nicht mehr intensiv für Eng-Eng Matches damit beschäftigt.

Es gab im alten ChessBits Forum (ca. 1997, Diskussion lief auch im alten Gambit-Soft Forum) mal eine ellenlange Diskussion zu dem Thema. Viele werden Uli Türke oder Dieter Bürssner noch kennen. Die beiden beteiligten sich auch rege an den Diskussionen. Sofern ich mich erinnere verstand Uli das Problem seinerzeit auch nicht so richtig. Der gute Markus Kästner wollte seine eigenen TBs CDs verkaufen und war auch komplett gegen diese Thesen.

Im Laufe der Jahre entwickelten dann diverse Programmierer wirkliche Settings um die Zugriffe auf die 5-Steiner wegen der Prozessorbremse nicht zu früh zu starten. Diese Parameter gab es dann in Yace aber auch in Fruit.

Wieder Jahre später testete ich das mit Fruit und Loop. Bei Fruit war der Test zweifelhaft, weil eingestellt wurde dass Fruit nicht auf die 5-Steiner zugreifen sollte, bevor weniger als 9 Steine auf dem Brett. Fruit spielte mit dieser Einstellung nur 3 ELO schwächer ... also in einem nicht messbaren Bereich. Bei Loop (glaube es war Loop, muss zu Hause nachsehen) waren es 15 ELO und bei einem weiteren Test mit AnMon waren es 22 ELO weniger.

Insofern wäre ein weiterer Test gar nicht mal so uninteressant, ohne jetzt mittels Parameter die Zugriffe auf die 5-Steiner einzuschränken.

Das eine Engine ca. 70% Prozessorleistung verliert sollte aber klar sein.
Das nur wenige TB Treffer wirklich Sinn machen, sollte auch klar sein.

Der Nutzen der TBs wird bei noch vielen Steinen auf dem Brett überschätzt.
Nutzen - Prozessorbremse ...

Habe gerade mal eine Umfrage gestartet.
Vielleicht hat ja nach so vielen Jahren wieder mal jemand ein Interesse an solchen Ergebnisse.
Da es in der SWCR-64 eh sehr experimentell zugeht ... würde ich dort gerne solche Testläufe durchführen.

Viele Grüße
Frank

PS: Werde mich mit Deinen Hinweisen mal ein wenig beschäftigen.
Wie gesagt, schon lange her als ich das Thema zuletzt hatte, möchte dazu jetzt auch zunächst nichts weiteres mehr schreiben.
Parent - - By Stefan Pohl Date 2010-09-12 14:41
Habe jetzt auch mal meinen Taskmanager angeschaut (Vista x64 Home Premium, Quadcore-Prozessor 2.8GHz, 8GB Ram).

Ohne TBs auf USB-Stick (Stick aus dem Rechner ausgestöpselt!) in einer Stellung mit 8 Steinen (Könige, je ein Turm, je 2 Bauern) (Rechner vorher frisch gebootet), Engine 1024 MB Hash:

- Hiarcs 13.1 99% der Leistung, Chessprogram.exe 0% (das ist die Fritz 12 GUI)
- Deep Rybka 4 25%, 25%, 24%, 24% der Leistung (je Core) (Rybka ist da anders gestrickt und zeigt jeden Core im Taskmanager einzeln an, daher eben 4x knapp 25%, da Quadcore-Prozessor, s.o.). Chessprogram.exe 0%

Mit 5-Steiner TBs auf USB Stick und 256 MB Cache GUI und 256 MB Cache Engine in derselben 8Steiner-Stellung (Rechner vorher frisch gebootet):
- Hiarcs 13.1 98% der Leistung. Chessprogram.exe 1%
- Deep Rybka 4 25%, 24%, 23%, 24% (=96% gesamt), Chessprogram.exe 1%

Also nur 1% Leistungsabfall für die Engine gegenüber der GUI. Das war aber in einer 8-Steiner Stellung auch zu erwarten, da ja 99% der untersuchten Stellungen mehr als 5 Steine haben dürften, und ja bei 5 Steinen nach einmal nachschauen in den TBs die Suche dort auf jeden Fall abgebrochen wird und außerdem schaut ja auch die Engine in den TBs nach, nicht die GUI!
Dazu müß ich noch anfügen, daß mein Schach-PC keine Antivirensoftware o.ä. aufgespielt hat (gehe damit nur auf schach.de) und auch bis auf die Schachsoftware keinerlei sonstige Programme nach dem Kauf aufgespielt wurden (=jungfräuliches maximal-Power-System !)...

Und man muß bedenken, daß das Nachschauen in den TBs auf dem USB-Stick zwar flott ist, aber natürlich trotzdem langsam im Vergleich zum Nachschauen im Hauptspeicher. Aber dank des großen Caches und der Tatsache, daß gefundene TB-Stellungen ja auch in die Hashtables wandern, wird ja meist nur einmal nach einer Stellung pro Partie und Engine wirklich auf dem USB-Stick nachgeschlagen. Der insgesamt 512 MB große Cache und die 1GB großen Hashtables speichern bald den gesamten 5-Steiner, der sich auf dem Brett entwickeln könnte (fast) komplett ab. Ein anderer 5-Steiner kann ja dann nur noch durch Bauernumwandlung entstehen (=selten). Ergo: Sobald sich die TB-Zugriffe der Engine in einer Partie "warmgelaufen" haben, wird praktisch nur noch im Hauptspeicher auf TBs zugegriffen. Das bremst dann praktisch nicht mehr ab. Und das macht ja dann auch die Engine, nicht die GUI, daher auch kein nennenswerter Leistungsabfall im Taskmanager, sehr wohl aber bei der Knotenzahl. Die FritzGUI greift selbst erst auf die TBs zu, wenn nur noch 5 Steine AUF DEM BRETT sind und dann wird die Engine sowieso von der GUI gestoppt.

Gruß - Stefan
Parent - - By Frank Quisinsky Date 2010-09-12 14:51
Hi Stefan,

hm, baue mal eine einfache Stellung mit 12 Steinern auf.
Lasse nur eine Engine die einen Core nutzt laufen.

Schaue in den Task-Manager ...
Ich sehe nach wie vor einen Leistungsabfall von 70%.
Gerade mal auf meinem Notebook mit der Shredder GUI getestet.

Nehme mal eine andere GUI oder schalte in der Fritz GUI "GUI nutzt Tablebases aus, wobei das eigentlich egal sein sollte, denn durch diese Einstellung wird auf die Datenbank zugriffen ... seitens der GUI ... wenn wirklich 5-Steine auf dem Brett sind (nicht in der Suche).

Und zu Deinen Einstellungen:
TBs über USB-Stick mit großen Cache ...
Das muss ich noch testen, habe ich bei den 5-Steinern noch nicht getestet.

Bei mir liegen die 5-Steiner auf der Platte, habe hier derzeit keinen 8GB Stick zur Hand.
Schaue ich mir aber an, kann mir nur nicht vorstellen das dies hinsichtlich der Prozessorbremse einen Unterschied ausmachen sollte (wenn ja, dann habe ich etwas dazugelernt). Ich meine bei der Nutzung der 5-Steiner in der Suche sollte es egal sein ob die TBs auf der Platte oder einem USB-Stick liegen. Die Prozessor Leistung sollte in beiden Fällen um a. 70% nach unten gehen.

Viele Grüße
Frank
Parent - - By Stefan Pohl Date 2010-09-12 15:03
Hab ich gemacht. Hiarcs 13.1 auf einem Core: 25%  (logisch bei nur einem Core) mit und auch 25% ohne TBs. Chessprogram.exe 0%. Knotenzahl ca.1 Million/s bei einem Core (mit 4 Cores knapp 3,7 Mio/s)

(Alle Einstellungen siehe letztes Posting, nur ohne frisch booten, 12 Steiner-Stellung (König, Turm, Läufer, 3 Bauern je Seite).

Ergo: Entweder taugt die ShredderGUI nix, oder in deinem Rechner ist der Wurm drin. Ich habe nur die FritzGUI und nutze auch nur diese, daher kann ich es mit der Shredder GUI nicht testen. Wichtig ist aber auf jeden Fall ein großer Cachespeicher. Doppeltes Caching, wie es die FritzGUI ermöglicht, ist natürlich noch besser...

Gruß - Stefan
Parent - - By Frank Quisinsky Date 2010-09-12 15:17
Hi Stefan,

bist Du Dir denn sicher, dass unter der Fritz GUI die 5-Steiner in der Suche auch genutzt werden?
Könnte auch eine Erklärung sein, gerade mit der Arena GUI geprüft, gleiches Ergebnis ... Prozessorleistung geht um 70% nach unten.

Schaue mir das nächste Woche mit dem USB-Stick an.
Vielleicht liegt es daran, kann ich mir aber nicht vorstellen.

Gruß
Frank
Parent - - By Stefan Pohl Date 2010-09-12 16:43
Was soll denn diese Frage??? Natürlich bin ich sicher. Ich weiß ja nicht, was deine merkwürdigen GUIs und Rechenr da so treiben oder anzeigen, aber unter der FritzGUI zeigen alle UCI-Engines (und die Natives wie Deep Fritz logischerweise erst recht) an, wieviele TB-Zugriffe sie machen (neben der Anzahl der insgesamt berechneten Knoten). Darüberhinaus blinkt die LED an meinem TB-USB-Stick heftig los, sobald TB-Zugriffe erfolgen.
Vieleicht suchst Du die Anfängerfehler mal lieber bei Dir selber?!?
Parent - - By Frank Quisinsky Date 2010-09-12 18:50 Edited 2010-09-12 18:54
Hallo Stefan,

warum so aggressiv?

Leider kann ich das nicht nachvollziehen was Du schreibst!
Gebe mir ja wirklich die größte Mühe.

Werde das aber nächste Woche mal unter der Fritz GUI ausprobieren bzw. auch mit dem USB-Stick.

Berichte dann nochmals ...
Würde auch alles was bekannt ist komplett auf dem Kopf stellen bzw. wäre ja fast sensationell !!
Oder, Du musst einen SUPER Computer haben

Mal schauen, vielleicht liege ich ja wirklich falsch.
Anfängerfehler mache ich natürlich auch ... bekanntlich lernt man nie aus!

Viele Grüße
Frank
Parent - - By Stefan Pohl Date 2010-09-13 08:47
"...Mal schauen, vielleicht liege ich ja wirklich falsch.
Anfängerfehler mache ich natürlich auch ... bekanntlich lernt man nie aus!"

Was meinst Du mit auch? Ich hab keinen gemacht. Das Thema warum man TBs unbedingt auf einem USB-Stick mit schneller Access-Time lagern und gut cachen sollte, wurde hier schon vor längerer Zeit und mehrfach ausführlich behandelt. Inkl. Links zu Testberichten und auch ein Testprogramm für die Access-Time von USB-Sticks.

Ich kanns nun mal nicht so toll finden, wenn jemand, an dem dieses wichtige Thema für Engine-Tests offensichtlich völlig vorbeigelaufen ist, den großen Tester inkl. eigener Rangliste gibt und mir unterstellt, meine TB-Zugriffe wären nur eine Fata Morgana und nur deshalb träte bei mir keine 70%-Ausbremsung der Engines auf. Das wird man ja dann wohl auch mal anmerken dürfen?!?

Zum Thema nie auslernen würde ich das CSS-Forums-Archiv empfehlen, Gerhard Sonnabend hat sich vor längerer Zeit hier sehr ausführlich und lesenswert zu dem Thema geäußert und auch div. Links bereitgestellt (s.o.).

Gruß - Stefan
Parent - - By Frank Quisinsky Date 2010-09-13 10:07 Edited 2010-09-13 10:16
Hallo Stefan,

das Wort Anfängerfehler hast Du in die Diskussion gebracht.
Ich antwortete, dass mir das natürlich "auch" passieren kann.

Das "Auch" bezieht sich darauf, dass mir nicht bekannt ist bzw. das ich jemals erlebt habe, dass jemand fehlerfrei arbeitet.
Das gibt es nicht und ich schon mal gar nicht !!

Aber ich möchte Dich nicht belehren und beleidigen schon mal gar nicht bzw. Dir überhaupt gar nichts unterstellen.
Warum sollte ich das tun?

Das liegt nicht in meiner Absicht!
Es ist vielmehr so, dass es interessant ist was Du schreibst.

Ich erinnere mich ...
Das erste kommerzielle Programm, welches Nalimov nutzen konnte war nach meinem Wissen "MChess". Dennoch konnten die Datenbanken schon sehr lange vorher von einigen Amateuren genutzt werden, z. B. Crafty. Seinerzeit gab es noch komprimierte und nicht komprierte TableBases. Die ersten Berichte hierzu schreib ich 1997, also lange bevor ein Fritz, ein Shredder etc. die Daten nutzen konnte oder ein Helmut Conrady sich dem Thema annahm. Helmut fragte mich hierzu Löcher in den Bauch und auch viele andere in den diversen Schachforen. Im weiteren Verlauf erstelle Helmut Conrady die mir als "Besten Berichte" zum Thema in Erinnerung gebliebenen Abhandlungen. Selbst setzte ich die Nalimov Datenbanken schon bei den ersten publizierten WB Engine Turnieren ein, seinerzeit gab es nur 4-5 kompatible WinBoard Programme.

Den Bericht von Gerhard Sonnabend kenne ich nicht. Werde mir das ansehen!
Bin immer ganz froh wenn ich mal Berichte von anderen Lesen kann.

In den letzten Jahren habe ich wie beschrieben dem Thema keine große Aufmerksamkeit mehr geschenkt, zumal ich eine Computerschachpause von 3 Jahren eingelegt hatte.

Das es nicht mehr zu einer Prozessorbremse kommen soll ist mir absolut neu. Wahrscheinlich gibt es Änderungen in der Fritz GUI, die ich nicht verfolgt habe, also ich Zweifel nicht an was Du schreibst, warum sollte ich. Ich schrieb, dass ich mir das nicht vorstellen kann, allerdings nicht das Du Anfängerfehler begehst etc..

Wie gesagt, werde mir das noch in Ruhe ansehen.

Es geht mir auch nicht um die Zugriffszeit der TBs, sondern darum das Engines diese ja nutzen und mithin weiterverarbeiten. Dabei kommt es zu einer Prozessorbreme. Das wurde über die ganzen Jahre seit 1997 festgestellt und ist kein Geheimnis.

Also, Du musst mich nicht belehren, auch wenn das sicherlich "nett" gemeint ist
Diese Links habe ich zu diesem Thema viele Jahre selbst prodziert.

Alleine auf das Gambit-Soft Review zu den 5-Steinern gab es mehr als 100.000 Zugriffe.
Und viele Personen waren sehr dankbar diese Informationen schön sortiert lesen zu können.

Ich kann diesen Bericht von 1999 gerne für Dich erneut hochladen, oder einen anderen den ich 1997 schrieb.

Wie gesagt, ist nicht besserwisserisch gemeint aber ich denke Du bist mit einigen Deiner Kommentaren schlicht an die falsche Person geraten.
Macht aber nichts!

Wie gesagt, wenn ich mir die Sache mal näher angesehen habe melde ich mich ...
Bin mit Schulschachklamotten beschäftigt und muss das verschieben, wollte das eigentlich heute machen.

Viele Grüße
und nochmals ...

Vielen Dank für die vielen Hinweise von Deiner Seite !!

Gruß
Frank

PS:
Dennoch, ich halte persönlich nichts von beeinflussende Datenbankfaktoren beim Messen von Ratings.
Schlicht sollte die Spielstärke der Engine gemessen werden und nicht wie gut die Zugriffe auf Datenbanken sind.
Das mag eine sehr eigenwillige Meinung sein, aber jegliches + an Beeinflussungsfaktoren kann jeder selbst ermitteln, finde das ist nicht Aufgabe einer Ratingliste, maximal als Test um ein paar Denkanstösse zu geben.
Parent - - By Klaus S. Date 2010-09-13 13:10
Hi Frank,

Stefan meint wohl diesen 5-seitigen Artikel:

http://www.computerschach.de/index.php?option=com_content&task=view&id=510&Itemid=272

Gruß
WL
Parent - By Stefan Pohl Date 2010-09-13 13:17
[quote="Wilfried Lübkemann"]
Hi Frank,

Stefan meint wohl diesen 5-seitigen Artikel:

http://www.computerschach.de/index.php?option=com_content&task=view&id=510&Itemid=272

Gruß
WL
[/quote]

Ganz genau, danke für den Link. Ich hab auch langsam keine Lust das hier alles noch mal lang und breit auseinanderzusetzen. Da dieser brillante Artikel bereits 2006 erschien und für großen Aufruhr in der Szene sorgte und auch hier im Forum das Thema vor Jahren ausführlich diskutiert und beleuchtet wurde, dachte ich, jeder ernsthafte Computerschächer hätte dieses Thema schon vor Jahren zur Kenntnis genommen. Es gehört für Engine-Freaks und Tester m.E. zum elementaren Grundwissen. Naja, das dachte ich jedenfalls.

Beste Grüße - Stefan
Parent - - By Frank Quisinsky Date 2010-09-13 13:56
Hi Wilfried,

ja, diesen Bericht kannte ich nicht.
Sehr guter Bericht !!

Also da habe ich etwas dazugelernt, wie gesagt habe mich viele Jahre nicht mehr mit dem Thema beschäftigt, da ich die Daten eh nicht für eine Ratingliste nutzen würde.

Danke für den Link-Hinweis!

Viele Grüße
Frank

PS: Werde meinen Bericht zu den Beeinflussungsfaktoren bzw. den Hinweisen zu den Endspieldatenbanken ändern und darauf hinweisen.
Parent - - By Klaus S. Date 2010-09-13 14:33
Hier noch ein Nachschlag zum Thema:

Mit H2benchw Zugriffszeit messen

http://www.computerschach.de/index.php?option=com_content&task=view&id=255&Itemid=274

Viele Grüße - Wilfried
Parent - By Frank Quisinsky Date 2010-09-13 15:28
Hi Wilfried,

den Test (H2benchw) wiederrum kenne ich.
Hatte ja bei dem neuen Corsair GTR berichtet und ich glaube auch diesen Test eingesetzt.

Jemand fragte nach den Zugriffszeiten bei den 5TBs.
Jetzt weiß ich auch was er gemeint hatte (Name vergessen).
Konnte damit erst gar nichts anfangen.

Gut, habe ich wirklich etwas dazu gelernt.
Muss das unter "Beeinflussungsfaktoren" auf meinen Webseiten noch ändern. Das meiste was dort unter TBs steht stammt aus einem älteren Bericht, den ich wie beschrieben, vor vielen Jahren schrieb.

Viele Grüße
Frank
Parent - - By Stefan Pohl Date 2010-09-13 13:10
"Es geht mir auch nicht um die Zugriffszeit der TBs, sondern darum das Engines diese ja nutzen und mithin weiterverarbeiten. Dabei kommt es zu einer Prozessorbreme. Das wurde über die ganzen Jahre seit 1997 festgestellt und ist kein Geheimnis."

Das ist leider -  ich muß es so sagen - schlicht und einfach komplett falsch. Es geht nur um die Zugriffszeiten. Eine wie auch immer geartete "Verarbeitung" findet nicht statt. Was sollte auch verarbeitet werden? Es wird bei der passenden Stellung im TB-Cache nachgesehen. Falls die Stellung dort nicht auftaucht, wird in den TBs auf dem USB-Stick nachgesehen, falls 5 oder weniger Steine auf dem Brett während der Alpha-Beta-Suche auftauchen (Zugriffszeit!, Cache!!!), und dort steht nur ein einziger Zahlenwert pro Stellung, nämlich entweder Remis oder Matt für Weiß/Schwarz in x Zügen. Dieser Wert wird wie eine Stellungsbewertung bei einem Hashtablezugriff (völlig gleiches Grundprinzip - da wird auch nix "verarbeitet") benutzt, anstatt die Bewertungsfunktion (Zeit gespart!) aufzurufen und die Suche in diesem Ast der Alpha-Beta-Suche wird sofort beendet, weil ja dank TB-Zugriff feststeht, wie die Partie ab dort ausgeht. Daher weitere Suche ab dort überflüssig (viele, viele Knotenuntersuchungen und damit  Zeit gespart!)(weshalb ja TBs die Suche auch so extrem beschleunigen! 1-3 HZ tiefer im Endspiel sind normal!!!), selbst wenn die angezeigten Knotenzahlen um 20-30% sinken (bei 8 und weniger Steinen auf dem realen Brett). War die Stellung im Cache noch nicht gefunden worden, wird sie nun noch in selbigen geschrieben (auch wie bei den normalen, persistenten Hashtables). Und fertig ist der TB-Zugriff.

Ein Tablebase-Zugriff funktioniert also im Prinzip wie die Hashtables, nur daß man auf dem USB-Stick gewissermaßen schon vorgefüllte Hahstables vorliegen hat. Daher guckt die Engine/GUI in den Cache (=TB-Hashtables, wenn man so will), und wird dort fündig oder nicht. Falls nicht, guckt sie in die vorgefüllten "read-only-USB-HashTableBases" auch Nalimovs genannt, holt sich dort den numerischen Wert (=Stellungsbewertung) und schreibt diesen dann noch in den Cache. Es ist zwar so, daß in den Nalimov-TableBases die Stellungen an 1 (mit Bauern) oder 2 Achsen (keine Bauern) gespiegelt werden, um Platz zu sparen, aber das im Zugriff auf die TBs zu berücksichtigen ist keine Verarbeitung, da so oder so eine bestimmte Adresse in den TableBases erstellt werden muß (aus dem Figurenmuster der aktuellen Stellung), genauso wie das auch beim Nachsehen in normalen Hashtables der Fall ist (Errechnen des Hashwerts = Adresse im Speicher). Diese Spiegelungen verändern nur die Art der Adressenberechnung, erhöhen aber nicht nennenswert deren Rechenzeit-Aufwand !

Also nochmal zusammengefasst: Nur die Zugriffszeiten auf die TBs sind von Bedeutung, denn es sind nix weiter als externe, schreibgeschützte, unveränderliche Hashtables, bei denen sehr oft eine winzig kleine Datenmenge (eine Integer-Zahl (Remis,Matt in x)) ausgelesen wird. Deshalb der USB-Stick mit einer schnellen Access-Time (weil viel schnellere Zugriffszeit als jede Festplatte) und ein großer Cache, weil dort der Zugriff wiederum viel schneller ist, als beim schnellen USB-Stick, da der Cache im schnellen Hauptspeicher-RAM liegt.

Punkt, Ende, aus - Nix Verarbeitung, nix Prozessorbremse. So wie mein Taskmanager das auch anzeigt, ganz egal ob 1 oder 4 Cores, ob 8 oder 12 Steine auf dem Brett usw. usw. eben weil nix verarbeitet, sondern nur nachgeschlagen wird. Und der geringe Zeitaufwand des Nachschlagens wird (sofern man einen USB-Stick mit schneller Access-Time benutzt, s.o.) tausendfach durch die eingesparten Knoten, die in der Suche jenseits der 5-Steiner-Stellung sonst noch zu berechnen wären, überwogen. Zusätzlich ermöglicht eine so extreme Bewertung wie Matt in x Zügen auch in den Nachbarästen der Suche viele zusätzliche Abschneidungen (=Knoteneinsparungen), weil ja das das Grundprinzip des Alpha-Beta-Algorithmus ist: Er schneidet umso mehr weg, je extremer der Alpha und/oder der Beta-Wert ist.
Daher eben die leicht sinkendende Knotenzahl-Anzeige und die parallel dazu stark steigenden Rechentiefen (1-3 Halbzüge tiefer in gleicher Zeit sind viel!), beides umso stärker ausgeprägt, je weniger Steine noch auf dem realen Brett sind, da umso mehr TB-Zugriffe statt Stellungsbewertungen erfolgen.

Doch eigentlich alles ganz einfach und einleuchtend, sofern man erst mal das Grundprinzip und seine Parallelelen zu den Hashtables verstanden hat.

Gruß - Stefan
Parent - - By Frank Quisinsky Date 2010-09-13 13:54
Hallo Stefan,

OK, habe den Bericht von Gerhard gelesen (kannte ich nicht).
Verstehe jetzt auch was Du genau meinst.

Wie gesagt, habe mich Jahre mit dem Thema nicht mehr beschäftigt, nutze 4-Steiner die auf der Platte liegen.
Ob diese über einen USB-Stick oder der Platte genutzt werden, ist bei den 4-Steiner von sehr geringer Bedeutung, anders bei den 5-Steinern (lt. dem Bericht).

Unter Arena und Shredder hatte ich am Wochende den Zugriff auf die 5-Steiner mittels Plattenzugriffe getestet. Nach wie vor die Prozessorbremse, ich hatte Dir ja geschrieben das ich keinen USB Stick zur Hand zum Prüfen hatte und mir das noch ansehen wollte.

Nun, dann habe ich wieder etwas dazugelernt und werde auch mal ein wenig experimentieren.
Der Bericht von Gerhard ist klar und gut erklärt auch Deine Ausführungen!

Dir für die vielen Hinweise ein Dank, wie gesagt ... ich wusste das nicht, weil ich eh diese Datenbanken (5-Steiner) niemals einsetzen würde weil ich beschrieben die Leistungen der Engine messe und hierbei frei von Datenbankeinflüssen sein möchte. Würde ich heute die SWCR erneut starten würde auch auch die 4-Steiner nicht mehr aktivieren (hatte ich schon öfters geschrieben). Diese dienen eher dazu um die Endlosschleifen der Endspiele zu minimieren, da ich auch ohne Aufgabefaktor spielen lasse.

Auch Gerhard Sonnabend ein Dank für den sehr guten Bericht.

Viele Grüße
Frank
Parent - - By Gerhard Sonnabend Date 2010-09-13 14:10
Nur um es klarzustellen, der Bericht ist von Lars Bremer,
von mir stammen lediglich die Messungen und ein paar ganz
wenige Details.

Viele Grüsse,
G.S.
Parent - - By Frank Quisinsky Date 2010-09-13 15:33
Hi Gerhard,

OK, tja so kommen die Wissenlücken zu Stande.
Viele Jahre habe ich gar nichts getan und bin ja erst seit ca. einem Jahr wieder aktiv.
Wäre mir sonst sicherlich nicht durchgegangen.

Diese Möglichkeit die 5-Steiner mit einem schnellen Stick zu nutzen und die Prozessorbremse zu umgehen ist natürlich hochinteressant für Analysen.

Fragte mich eh schon (Interview mit Stefan Meyer-Kahlen, TB Frage) wie bei der Erweiterung der Shredder-Bases auf 6-Steiner alles schnell geladen werden sollte.
Stefan schrieb es wären ca. 40GB RAM notwendig.

OK, OK ...

Dann wären diese 6-Steiner ShredderBases natürlich auch sehr interessant für Analysen!

Viele Grüße
Frank
Parent - - By Gerhard Sonnabend Date 2010-09-13 16:11
Ja Frank, die Zeit vergeht sehr schnell.
Heutzutage braucht es auch keine USB-Sticks
oder anderen externen Speicher mehr.
Einfach eine SSD im PC verbauen, thats it.
Zudem sind die Teile z.B. zu "Backupzwecken"
unschlagbar schnell.

Viele Grüsse,
G.S.
Parent - - By Frank Quisinsky Date 2010-09-13 16:21
Hi Gerhard,

ja das stimmt.
Habe auch eine SSD im Einsatz und alles kurz überprüft.
Auch mit meinen beiden Corsair GTR.

Mir ist nun auch alles klar was Stefan schrieb.
Habe auch schon meinen Bericht "Beeinflussungsfaktoren abgeändert, bzw. einen Zusatz erstellt".

Sofern Stefan mitliest:
Stefan, ich wollte das von Beginn an nicht in Frage stellen was Du geschrieben hast (mache ich grundsätzlich nicht, sondern prüfe) aber ...
Ich konnte mir das in der Tat nicht vorstellen! Schon allein weil ich mich wirklich x Stunden mit dem Thema beschäftigt hatte aber das alles schon ein paar Jahre zurück liegt.

Bin Dir wirklich auch sehr dankbar, gerade weil ich auf meinem Arbeitsrechner auch die 5-Steiner für Analysen einsetze und das jetzt natürlich geändert habe.

Viele Grüße
Frank
Parent - By Thomas Müller Date 2010-09-13 16:59
ja aber frank....jahre in der IT sind welten...da ist soviel passiert, aber das weisst du ja auch!
Ich weiß jetzt grad nicht aus dem kopf seit wann es USB 2.0 gibt.
Womöglich sind deine damaligen erfahrungen sogar noch mit usb 1.x ?
Und jetzt gibt es ja auch schon USB 3 sticks/platten und eben die SSD.
Ob die USB 3 in den zugriffszeiten nochmals schneller sind müsste ich auch erst nachschauen.
Egal....auch du hast was gelernt und weiter gehts

grüße thomas
Up Topic Hauptforen / CSS-Forum / @Info: Wieso läuft Houndini bei Dir durch?
1 2 Previous Next  

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill