Die idealen Vorgabestellungen für Eng-Eng Tests

By Kurt Utzinger Date 2009-11-22 19:14

[quote="Timo Klaustermeyer"]
[...]
- Es wird (vorerst) nur 1 Thread verwendet, MP-Tests sind zu aufwändig und nicht deterministisch
[...]
Viele Grüße
Timo
[/quote]

Hallo Thomas
Seit die MP-Euphorie (begreiflicherweise) um sich gegriffen hat, ist aus den von Dir genannten
Gründen alles viel komplizierter geworden. Alle Matches, die mit mehr als 1 Thread gelaufen sind,
müssten 3-4 Mal wiederholt werden, wollte man die grossen Unsicherheiten ein wenig eindämmen.
Das alles ist aber praktisch kaum mehr zu bewerkstelligen, weil der Aufwand ein Vielfaches zu gross
ist, um einen noch geringen Mehrnutzen für die Ranglisten zu erreichen.
Mfg
Kurt

By Ingo Bauer Date 2009-11-22 19:59

Hallo Timo,

Im Großen und Ganzen stimme ich dir zu und im Groben hast du meine Rangliste, die ich die letzten male Schachcafe "präsentiert" habe, erfunden

Ich gehe mal im Detail darauf ein:

a) Wieviele Vorgabestellungen?

Es gilt wie immer - je mehr je besser. Leider geht das nicht, also muß man einen Kompromiss finden. Ich habe mal mit den 50 Noomen angefangen und bin bei 50 geblieben. 50 Stellungen gibt Farbtausch gibt 100 Partien pro Enginepaar. (unter Punkt C dazu mehr)

b) Welche Vorgabestellungen?

Ausgewogen, d.h. bei 50 Stellungen nicht 50 Sizilianer. De Fakto habe ich nach einigen 1000 Spielen mir die mit den höchsten Weiß- und Schwarzgewinnraten rausgeworfen und ersetzt. Inzwischen habe ich "gleichmäßige" Gewinnverteilungen. (Nicht identisch, aber ähnlich!)

c) Wieviele Engines in der Rangliste?

Gute Frage! Ich habe etwas Probleme wenn zwei Engines zu weit auseinanderliegen. Wenn du die fünfhundertste Mittelklasse Engine testen willst ist es einfach 20/25 Gegner zu finden. Willst du die Topengnies testen wird es schwierig. Zusätzlich ist es noch schwer NICHT 5 Fruits im Testfeld zu haben (in Zukunft vielleicht Robbos). Da ich oberes Feld teste, bin ich bei 15 gelandet. gibt 1500 Spiele. Aus Erfahrung (~150000 Spiele die in de Rangliste galandet sind + mindestens 50000 die nicht reinflossen) behaupte ich, dass man damit ganz gut durchkommt.

d) Bedenkzeit?

"a volonte" - nur nicht zu kurz und, und das ist der Knackpunkt, wieviel Hardware steht zur Verfügung und in welcher Zeit soll ein Ergebniss vorliegen. Ob du 3 + 0 oder 90 + 30 testest ist egal, es wird sowieso genau eine Rangliste für 3 + 0 oder 90 + 30, die sind nicht vergleichbar. Am Ende läuft alles auf die Zeit und deinen akzeptierten Stromverbrauch raus. Ich selber habe eine spürbar erhöhte Stromrechnung wegen der Testerei! Alles Dinge die es zu beachten gibt.

- Ponder on

100% Zustimmung, auch meine Liste ist so erstellt.

- Jede Engine muss gegen jede andere die gleiche Anzahl an Partien mit gleichen Eröffnungen spielen

Idealzustand. Wenn deine Liste aber wächst bekommst du irgendwann zu viele Partien zu erledigen. Was hälst du von folgender Regelung: Jede Engine gegen die 15 (x) besten. Schwierig werden Autorendopplungen die man zwar Ausschließen könnte, aber was macht man wenn man z.B. eine x64 und x32 derselben Engine testen willst ... ohne Zweifel besteht da Diskussionsbedarf.

- 3-5 Steiner Tablebases, Bitbases und Shredderbases werden verwendet falls unterstützt (liegen wegen schnellerem Zugriff auf USB-Stick)

Ich spiele nur mit 4 Steinern weil ich mir nicht sicher bin wie sich engines "behindern" wenn sie gleichzeitg auf die Tbs zugreifen (egal ob Platte oder USB). Ich habe keineHhandicaps dadurch festgestellt, einige wenige Zugriffe und die 4 Steiner leigen sowieso im Windowscache. Ausserdem werden Enignes die Tbs "noch" nicht können, nicht zu sehr benachteiligt (sofern Tbs überhaupt ein Vorteil sind)

- 64bit Versionen werden verwendet, falls verfügbar und falls sinnvoll (bei Engines die spürbar von 64bit profitieren)

Zustimmung, allerdings ist die Entscheidung ob sie oder ob sie nicht profitieren nicht trivial und durchaus ein Streitpunkt. De Fakto müssen oft beide getestet werden.

- In der Regel nur eine Engine pro Autor / Autorenteam in der Rangliste (d.h. von open-source Engine Derivaten wird nur die stärkste Version verwendet bzw. bleibt in der Rangliste)

Nein, die ältere würde ich fix in der Liste stehen lassen, wird nur nicht mehr getestet. Bsp : S10, S11, S12. Ich selber teste immer noch mit S10, weil der ein Fixpunkt mit 12400 Spielen in meiner Liste ist. Das Rating ist auf 5 Elo +/- gesichert. (Auch Spike ist so ein Fixpunkt bei mir) Es gibt also für und wieder eine Enigne weiter drinzulassen. Ich sehe da beide Seiten!

- Es wird (vorerst) nur 1 Thread verwendet, MP-Tests sind zu aufwändig und nicht deterministisch

Yup! Was soll ich sagen, ich teste nur einen Thread und bin von der Wiederholbarkeit der Ergebnisse begeistert!

...Mit nur einem Thread schafft man auf einem Quadcore-Rechner immerhin 2 Partien gleichzeitig, bei zwei Threads nur noch eine (bei 4 Threads bräuchte man gar 2 Rechner oder 8core-PC).

Genau meine Denkweise! Lass uns beim Treffen doch mal darüber Quatschen, vielleicht könnnen wir ja gemeinsam was neues auf die Beine stellen. Allerdings gibt es da die 'gemeinsame' Hardware zu diskutieren. Ich jedenfalls hätte grundsätzliches Interesse!

Gruß
Ingo

By Timo Haupt Date 2009-11-22 20:39

Hi Ingo,

vielen Dank für dein Feedback! Da scheinen wir ja ziemlich dicht mit unseren Vorstellungen beieinander zu sein, was eine Rangliste angeht. Das sollten wir unbedingt beim Stammtisch nochmal durchsprechen. Ich hätte jedenfalls großes Interesse daran, mit einem zuverlässigen Tester wie dir ein gemeinsames Projekt wie hier umrissen auf die Beine zu stellen.

Viele Grüße
Timo

By Roland Rösler Date 2009-11-22 21:09

[quote="Ingo Bauer"]Ich selber teste immer noch mit S10, weil der ein Fixpunkt mit 12400 Spielen in meiner Liste ist. Das Rating ist auf 5 Elo +/- gesichert. [/quote]
Wow, 12.400 Spiele für eine Engine schlägt sogar CEGT 40/20. Da habe ich als Spitzenreiter Fruit 2.2.1 mit 10.198 Spielen und Shredder 9.1 mit 9.484 Spielen gefunden.
Anmerkung: Das Rating ist auf 8 Elo +/- zu 99,7% gesichert!

By Ingo Bauer Date 2009-11-22 21:13

Hallo

Das sind meine drei Engines mit mehr als 10000 Spielen.

Fruit 05/11/03                 : 2532    5   5 10400    36.0 %   2632   36.9 %
Deep Shredder 10 x64 1T        : 2506    5   5 12300    35.3 %   2611   33.9 %
Spike 1.2 Turin                : 2480    5   5 13800    32.1 %   2610   33.0 %

Die verwende ich wirklich gerne, weil das Rating praktisch wie festgemeißelt steht!

Gruß
Ingo

By Roland Rösler Date 2009-11-22 21:58

[quote="Timo Klaustermeyer"]zu den anderen folgenden Fragen:

a) Wieviele Vorgabestellungen?
b) Welche Vorgabestellungen?
c) Wieviele Engines in der Rangliste?
d) Bedenkzeit?[/quote]

zu b) Die Vorgabestellungen sollten ein repräsentativer Querschnitt sein zu den Eröffnungen der GM-Praxis der letzten 20 Jahre. Die Anzahl der Eröffnungszüge sollte 6 nicht unterschreiten und 14 nicht überschreiten (ist halt eröffnungsabhängig). Welche Eröffnungen bis zu welchem Zug man jetzt konkret auswählen sollte, kann ich Dir leider auch nicht sagen!

zu a,c,d) Die Punkte hängen alle von der Frage ab, wieviel Zeit man investieren will und auf welche Hardware (Anzahl cores) man zurückgreifen kann. Ist das erst mal festgelegt, muss man zwischen den 3 Punkten jonglieren und Prioritäten festlegen. Für mich z. B. hat Bedenkzeit (d) oberste Priorität, danach kommt Anzahl der Vorgabestellungen (a) und danach Anzahl der Engines (c). Mindestanforderungen sollten auch nicht unterschritten werden. So sollte die Anzahl der Engines nicht kleiner als 10 sein und Anzahl der Vorgabestellungen nicht kleiner als 25. So komme ich zu den Bandbreiten:
a) 25-100
c) 10-20
d) So lang wie möglich (30 - 60 Minuten pro Spiel)

Blitzranglisten haben wir schon genug! Schnellschachranglisten für sp Engine sind gefragt (z.B. 25'+5" oder 15'+3")! Hier würde ich auch am ehesten Überraschungen zu den etablierten Ranglisten 40/40 bzw. 40/20 mit poder=off erwarten!

Letzte Anmerkung: Ingo hat schon einen ganz wichtigen Punkt angesprochen! Die Hardware, auf der die Spiele ausgetragen werden, muß möglichst gleich sein bzw. gut justiert sein.

By Timo Haupt Date 2009-11-22 22:41

Hallo Roland,

klingt gut, danke für die Kommentare. Ich sympathisiere auch eher mit längeren Bedenkzeiten. Auch hier wieder mein Argument: Für mich sind längere Zeiten näher an der Spielpraxis. Natürlich werden auf Schachservern auch massenweise Blitzpartien gespielt, aber die interessieren mich persönlich nicht besonders. Bei Turnieren herrscht nun einmal längere Bedenkzeit vor und auch bei Analysen verwendet man in der Regel mehr Zeit. Ein weiterer Pluspunkt ist, dass es beim Live-Beobachten der Partien interessanter ist, wenn die Engines mehr Zeit haben. So kommt man als Mensch noch einigermaßen mit, während eine Blitzpartie mir viel zu schnell ist, um noch dem Spielfluss folgen zu können. Es ist einfach spannender zu beobachten, wenn sich eine Engine bei einem Fail-High / -Low auch mal ein paar Minuten nehmen kann, um denselbigen aufzulösen. Das zählt für mich ebenso dazu wie das Beobachten des Ponderns, Kai und Ingo geht es offenbar ähnlich (siehe Ponder on / off Thread).

Einzig und allein die Tatsache, dass man einerseits viele Partien spielen will, andererseits aber auch in absehbarer Zeit mit dem Test einer Engine fertig werden möchte, spricht gegen längere Bedenkzeiten. Letztendlich ist es eine Frage der Kapazitäten, wie Roland auch schon sagte. Hätte man 10 Rechner im Test-Pool und können auf jedem Rechner zwei Partien gleichzeitig laufen (bei Quadcore und Test der SP-Version möglich), dann sähe die Sache schon gar nicht mehr so schlecht aus...

Viele Grüße
Timo

By Gerhard Sonnabend Date 2009-11-23 09:16

[quote="Timo Klaustermeyer"]
[...snip...]
- Es wird (vorerst) nur 1 Thread verwendet, MP-Tests sind zu aufwändig und nicht deterministisch
[...snip...]
[/quote]

Hi Timo !

Das bekommt man hier ja oftmals zu lesen.
Wo und wann jedoch hast Du selbst (falls überhaupt) diese Erfahrung gemacht ?

Evtl. ist ja folgendes für Dich interessant:
http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?pid=15164#pid15164

Viele Grüsse,
G.S.

By Timo Haupt Date 2009-11-23 22:15

Zitat:

[...snip...]
Wo und wann jedoch hast Du selbst (falls überhaupt) diese Erfahrung gemacht ?
[...snip...]

Hallo Gerhard,

ehrlich gesagt habe ich dazu keine Daten. Dein Posting zu diesem Thema kannte ich auch nicht, danke dafür! Dass es eine gewisse Streuung gibt, ist wegen der nicht-deterministischen Suche von MP-Engines unstrittig, darüber sind wir uns sicher einig. Das bedeutet allerdings zunächst nur, dass sich die Partien nicht immer reproduzieren lassen - die Ergebnisse müssen nicht unbedingt davon betroffen sein. Natürlich ist es schon auffällig, dass sich bei deinen Versuchen nur eine Abweichung um +/- 0.5 Punkte ergab. Aber du wirst mir wahrscheinlich zustimmen, dass man mehr Tests mit verschiedenen Engines bräuchte, um die These zu festigen. Allerdings bin ich davon überzeugt, dass es keine gravierenden Unterschiede geben wird (je mehr Partien, desto weniger stark wird prozentual die Schwankung sein). Außerdem muss man bedenken, dass auch SP-Engines nicht immer 100% identische Partien abliefern. Christophe Theron hatte dazu mal einen interessanten Artikel geschrieben (ich glaube seinerzeit in CSS veröffentlicht) - wenn ich mich richtig erinnere, liegt es daran, dass im Betriebssystem mehrere Prozesse im Hintergrund laufen, die ebenfalls geringfügig CPU-Zeit einfordern, das aber chaotisch (d.h. nicht vorhersehbar, wann und wieviel). Somit kommt es früher oder später dazu, dass eine Engine mal eine Iteration früher abbricht oder gerade noch schafft, je nachdem wieviel CPU-Zeit von anderen Prozessen abgezwackt wurde. Nun muss ein früher oder später beendeter Suchvorgang nicht jedes Mal zu einem anderen Zug und ein anderer Zug nicht jedes Mal zu einem anderen Ergebnis führen - aber es könnte trotzdem passieren! Allerdings passiert so etwas bei MP-Engines viel häufiger (je mehr Threads, desto schlimmer) als bei SP-Engines (leider kann ich auch das nicht mit Daten belegen).

Fazit: Für mich ist der Hauptgrund, nur mit einem Thread spielen zu lassen, dass es weniger Ressourcen kostet bzw. man mehr Partien zur gleichen Zeit schafft. Die Problematik mit der Reproduzierbarkeit spielt für mich eine untergeordnete Rolle. Erst Recht jetzt, wo ich deine Vermutung (unterstützt durch wenige, aber zumindest ein paar Testreihen) gelesen habe.

Viele Grüße
Timo

P.S.: Ich freue mich darüber, dass CEGT und CCRL mit SP- und MP-Engines testen. Ich schaue regelmäßig in die Listen und habe mir schon häufig die Partien heruntergeladen. Ich würde an eurer Stelle nichts ändern - der Erfolg (im Sinne von allgemein anerkanntes Maß der Dinge in der Computerschachszene was verlässliche Ranglisten angeht) gibt euch Recht! In diesem Thread habe ich lediglich laut gedacht, wie ich eine Rangliste angehen würde, wenn ich denn eine neue ins Leben rufen würde. Es wäre doch auch von Vorteil, wenn dieser Ansatz einer neuen Liste von dem der existierenden Listen abweicht. Denn erstens wäre so für Abwechslung gesorgt bzgl. der Testbedingungen, zweitens würde dies eventuell die Bedürfnisse der wenigen Leute befriedigen, die die Bedingungen der etablierten Listen nicht ganz optimal finden und drittens würde am Ende möglicherweise (oder sollte ich gar sagen wahrscheinlich) gezeigt werden, dass alle Listen ungefähr die gleichen Ergebnisse produzieren. Dann hätte man immerhin bewiesen, dass systematisches Testen ein Garant für verlässliche Ergebnisse ist - d.h. es kommt nur darauf an, seine Testbedingungen durchzuhalten, aber nicht unbedingt darauf, wie diese Bedingungen genau aussehen...

By Frank Quisinsky Date 2009-11-23 14:31

Hallo Timo,

3 Jahre alt aber meine Standpunkte haben sich nicht groß geändert.
Das waren die Bedingungen zur ATL-4

http://www.amateurschach.de/atl4/_about-atl4.htm

Du schreibst:
a) Wieviele Vorgabestellungen?
b) Welche Vorgabestellungen?
c) Wieviele Engines in der Rangliste?
d) Bedenkzeit?

Die für mich "festen" Parameter wären (auch wenn andere das anders sehen, hier überwiegen einfach meine persönlichen Vorlieben):
- Ponder on
- Jede Engine muss gegen jede andere die gleiche Anzahl an Partien mit gleichen Eröffnungen spielen
- 3-5 Steiner Tablebases, Bitbases und Shredderbases werden verwendet falls unterstützt (liegen wegen schnellerem Zugriff auf USB-Stick)
- 64bit Versionen werden verwendet, falls verfügbar und falls sinnvoll (bei Engines die spürbar von 64bit profitieren)
- In der Regel nur eine Engine pro Autor / Autorenteam in der Rangliste (d.h. von open-source Engine Derivaten wird nur die stärkste Version verwendet bzw. bleibt in der Rangliste)
- Es wird (vorerst) nur 1 Thread verwendet, MP-Tests sind zu aufwändig und nicht deterministisch

---

Vorgabestellungen:
Haben den großen Nachteil, dass Du stetig die gleichen Eröffnungen siehst. Dann ist die Komponente Spannung weg.
Selbst bin ich nach wie vor davon überzeugt das PGN-Random am Interessantesten ist.
Geht aber leider nicht unter der Shredder GUI.

Zur Zeit setze ich bei meiner Ratingliste unter der Shredder 12 GUI das 12.2a Buch von Sedat Canbaz ein.
Nun ja, so ganz zufrieden bin ich nicht und im Grunde ist das wirklich mein Hauptproblem unter der Shredder GUI.
Lieber wäre mir wenn PGN-Random auch unter Shredder funktionieren würde

Engines in einer Ratingliste:
Das Thema habe ich durch

Die Engines sollten idealerweise nicht mehr als 250 ELO auseinander liegen.
Sonst hast Du das Problem, dass die Engines oben (zu hoch) oder unten (zu niedrig) bewertet werden. Eher der letzte zu niedrig bewertet wird. Wohl gemerkt bei einer Berechnung mit ELOstat 1.3. Besser und logischer verhält sich Bayes ELO. Der letzte in einer Ratingliste wird angehoben und das entspricht auch der Realität.

Beispiel:
Smarthink 1.20 ist letzter in einer Ratinglsite. Nehme ich jetzt z. B. 4 weitere Engines die schwächer spielen als Smarthink wird sich bei einer ELOstat Berechnung mit 90% Wahrscheinlichkeit der Wert von SmarThink 1.20 um ca. 20 ELO verbessern. Brauchst Du bei Bayes ELO nicht, denn dort stimmt der Wert auch wenn keine 4 schwächeren Engines eingepickt werden.

Bedenkzeit:
Ich h alte von Fischer bei der Erstellung einer Ratingliste rein gar nichts. Thema ist das Zeitmanagement ... gerade noch etwas in einem anderen Thread dazu geschrieben. Will mich jetzt nicht wiederholen.
Gut ist 40 in 5, 40 in 10, 40 in 20, 40 in 40 ... bei diesen Bedenkzeiten stelle ich zumindest bei den von mir verwendeten Engines keine Unstimmigkeiten mit dem Zeitmanagement fest.

Ponder = on
Ohne Ponder = On würde ich niemals spielen.
Nehme mir doch keine Spannungskomponente weg.

Jede Engine gegen jede Engine gleiche Zahl von Partien.
Das wäre natürlich optimal aber schwierig durchführbar wenn Du updaten musst.

Derzeit gehe ich so vor.
Habe meine Basis mit 12 Engines aufgebaut. Nun gab es zwei wichtige Updates und 4 kommen derzeit hinzu. Ich habe die Partien der zwei upgedaten engines nicht mehr in meiner Hauptratingliste. So dann nur die 16 die ich derzeit teste. Jeder gegen Jeden 40 Partien = 600 Partien pro Engine. Ab ca. 350 Partien erhältst Du aussagekräftige Ergebnisse, siehst kaum noch eine Engine die dann mal bei weiteren 100 oder 200 Partien sich noch um mehr als 15 ELO verändert.

Tablebases:
Am Besten ganz ohne und spielen lassen bis zum Matt. So erkennst Du leicht welche Engines dann im Endspiel abfallen.
So hätten auch alle die gleichen Bedingungen aber das funktioniert nicht. Der Capture Programmierer schrieb mir mal sehr verständlich, dass seine Engine die TBs benötigt weil weitere Sourcen auf die TBs abgestimmt sind. Spiele also immer mit 4-Steinern (egbbs, nalimov und shredderbases). 5-Steiner sorgen eher dafür das die ELO sich eher verschlechtert als verbessert (glaube ich habe das erklärt in dem Text zur ATL-4). Rainer Serfling wollte das einst nicht wahr haben, glaube er ließ sich aber dann doch überzeugen

4-Steiner reichen !!

64bit:
Spiele immer mit einem Hauptziel ... alle Engines spielen unter den gleichen Bedingungen zumal es von jeder Engine eine 32Bit gibt. Halte nichts davon zu mischen, würde dann eher eine 32Bit und eine gesonderte 64Bit Ratingliste erstellen und dann vergleichen !!

Eine Engine von einem Autor
Sehe ich auch so.

1 Thread
Richtig, ein Ergebnis kannst Du Dir dann je nach Faktor der Engine selbst hochrechnen. Auch schon mehrfach diskutiert und die Meinungen gehen ein wenig auseinander. Hochrechnen nach Faktor funktioniert aber wenn ich so in die Ratinglisten schaue. Wenn Bright (hat glaube ich den besten SMP Faktor) z. B. 1.8 (2 Cores) erreicht dann kann ich ein Ergebnis leicht zum Faktor 1.0 (1 Core) hochrechnen. Dafür muss ich nicht ausgiebig testen, finde gar das ist Verschwendung der Test-Zeit.

Lese mal die vielen Kommentare zu PGN-Random in der Datei zur ATL-4 !!
Selbst für die Nachanalyse einfach geil ... weil ich weiß woher die Eröffnungstellung kommt und ich die GM Partie zum Vergleich für die Analyse habe.

Wenn Du möchtest sende ich Dir mal Ergebnisse von meinem Ratinglistenaufbau !!
Du kannst leicht viele Dinge sehen, z. B. wie sich ELO-Werte mit mehr Partien wirklich verändern !!

Gruß
Frank

By Timo Haupt Date 2009-11-23 22:38

Hi Frank,

du bist ja wieder richtig mit Herzblut bei der Sache! Soviele Postings hast du heute rausgehauen, nicht schlecht Herr Specht! Nehme mal an, dass du Urlaub hast oder selbständig bist - als Angestellter kann ich unter der Woche leider nicht so prompt tagsüber posten. Deshalb erst jetzt, um 22:30 Uhr, meine Antwort...

Danke für deine vielen Hinweise und Anregungen zu dem Thema. Ich weiß das wirklich zu schätzen, vor allem den Hinweis auf PGN Random, ein Feature, das ich ehrlich gesagt vorher nicht kannte. Deshalb werde ich mir deine ATL-4 Seite mal ganz genau anschauen.

Trotzdem werde ich von einigen Bedingungen nicht abrücken:
- 5-Steiner Tablebases, Bitbases, Shredderbases. Einfach deshalb, weil es heutzutage Standard ist. Vom USB-Stick ist der Bremseffekt außerdem viel geringer als früher von Festplatte. Wenn man genug RAM hat, könnte man sie sogar komplett in eine RAM-Disk schieben (bei Shredder- und Bitbases schon jetzt problemlos möglich, für Nalimovs sollten es dann 10 GB RAM sein, wenn man die kompletten 5-Steiner nimmt).
- 64bit Version einer Engine wird genommen, falls verfügbar und sinnvoll (sprich: bringt Geschwindigkeitssteigerung).

Das Argument, dass man dadurch ja keine einheitlichen Bedingungen mehr für alle Engines hat, ist zwar auf den ersten Blick korrekt, da ja nicht alle Engines Tablebases bzw. 64bit unterstützen. Aber meine Entgegnung darauf ist, dass es ja jedem Autor freisteht, Tablebase-Zugriff bzw. 64bit Unterstützung zu implementieren. Warum sollte man die Engines, die diesen Technologievorsprung haben, künstlich beschneiden, nur weil andere so etwas noch nicht unterstützen? Dann müsste man auch z.B. History Pruning bei allen Engines abschalten, die es beherrschen, wenn man andere Engines mittestet, die es nicht beherrschen. 64bit und Tablebase-Support sind für mich lediglich Softwaretechniken, die eingesetzt werden oder eben nicht. Aber wenn diese Techniken verfügbar sind, setze ich sie auch ein, da ich möchte, dass eine Engine mit voller Stärke spielt, wenn ich sie teste. Die einzige Ausnahme hier ist der Einsatz von mehr als einem Thread. Das beherrschen auch nicht alle, aber ich würde diejenigen, die es unterstützen, bei meiner Rangliste künstlich beschneiden. Aber nur deshalb, weil ich nicht genügend Ressourcen habe. Wenn ich genügend Rechenkapazität hätte, würde ich sowohl SP als auch MP testen und mehrere Ranglisten daraus erstellen, um zu sehen, wieviel Zuwachs es bei Verwendung von mehreren Threads gibt. In der MP-Liste (z.B. maximal 4 Threads) wären dann die jeweils stärksten Versionen der Engines enthalten (wie bei CEGT und CCRL "best versions").

Viele Grüße
Timo

By Frank Quisinsky Date 2009-11-23 23:03

Hi Timo,

nee, stecke beruflich in einer sich verändernden positiven Position und habe daher zumindest im Moment mehr Zeit für Computerschach.
Und da ich einiges aufzuholen habe erfreue ich mich mal wieder am Hobby und nutze die Zeit.
Dafür hatte ich in den letzten Jahren eigentlich überhaupt keine Zeit für Computerschach, selbst wenn ich die Lust gehabt hätte.

Zukünftig wirds bei mir aber auch wieder weniger an Zeit für Computerschach.

5-Steiner:
Da gab es schon so viele Experimente aber die Prozessorbremse der Engines ist nicht unerheblich.
Schaue es Dir im Task-Manager an wenn Engines beim Zugriff im Übergang zum Endspiel plötzlich auf 30% Prozessorleistung bei Nutzung der 5-Steiner abfallen.
Das für 99,9% unnötiger Datenbanktreffer aus Table-Bases. Und selbst die 0,1% Treffer garantieren keinen Gewinn weil im nächsten Zug schon wieder alles anders aussehen kann.

Die Frage die sich hier stellt ist ...
Bringen die TBs wirklich so viel um langfristig den Verlust an Prozessorleistung aufzuheben.
Meine Antwort : Nein, bringt zumindest für Eng-Eng nichts.
Erst Recht beim Blitz nichts, bei längeren Bedenkzeiten wohl eher kein Vorteil oder Nachteil.

Für Analysen klar ... Bestens geeignet aber nicht für Eng-Eng.

Nun was macht das aus:
Unterschiedliche Ergebnisse die ich hatte ...
Bei Fruit z. B. seinerzeit nach 600 Partien - 15 ELO bei der Verwendung von 5-Steinern.

Es gab glaube ich mal eine Loop Version die TBs konnte.
Da waren es auch ca. - 10 ELO.
Bei Shredder konnte ich nichts feststellen ... keinen Gewinn oder Zuwachs.

Kaum messbar.
Aber wenn jetzt noch die Festplatte rattert und rattert und dies zu einem erheblichen Verschleiß führt nehme ich eher Abstand.

Vielleicht bei den neuen schnellen Festplatten.
Dann würde ich das nochmals testen aber die Frage ist wie lange die neuen Festplatten halten. Dazu gibt es noch keine Erfahrungswerte.

Nun gut, spielst Du mit den 5-Steinern solltest Du darauf achten das die Daten komplett sind.

4-Steiner oder 5-Steiner ... das ist diskutierbar

Persönlich wäre es am Besten ganz auf die ganzen Datenbankeinflüsse zu verzichten.
Eröffnungsbücher, Table-Bases ... meine ich will ja keine Datenbank spielen sehen sondern wissen wie stark die Engine ist.
Datenbankabfragen haben dabei weniger verloren ... aber das ist meine persönliche Meinung.

Hardcoretesten nenne ich das.
Ich weiß ich kann höhere Spielstärken erzielen (x64 oder mehr Cores, 5-Steiner mit tollen Mattanzeigen).
Aber ich verzichte darauf weil ich absolute gleiche Bedingungen erzeugen möchte, weil ich vergleichen möchte.

Ja klar x64 bringt eine Geschwindigkeitssteigerung aber dann hapert es wieder an der Vergleichbarkeit.
Thema: Gleiches mit Gleichem vergleichen.
Habe ich ja ausführlich drüber geschrieben.

Beispiel:
Der Betrachter einer Ratingliste wundert sich das Hiarcs 12.1 plötzlich nicht auf Platz 8 sondern in einer anderen Liste auf Platz 13 steht.
Warum, in einer Liste sind die x64 Engines drin und in der anderen nicht.

Welches Ergebnis ist nun für den Betrachter interesssanter ?
Doch das wo ich alles miteinander vergleichen kann, oder ?
Denn der Betrachter muss eigentlich nur wissen ... Hiarcs 32Bit hat ELO ?, kann aber eine höhere ELO erreichen wenn es eine x64 Version geben würde.

Für mich persönlich ist dann Hiarcs auf Platz 8 !

Würde ich das in zwei Ratinglisten w32 und x64 sehen würde ich sagen ... OK bei 32Bit ist Hiarcs auf Platz 8 und bei 64Bit ist überhaupt kein Hiarcs vorhanden ... weil es keine 64Bit gibt. Insofern würde mich persönlich das Ergebnis von Hiarcs 32Bit in einer 64Bit Ratingliste überhaupt gar nicht interessieren.

Aber wie gesagt, alles Geschmackssache und Meinungen gehen auseinander.

Deine Entgegnung ist richtig.
Wenn ein Programmierer kein x64 anbietet kann ich nur das testen was da ist.
Technologievorsprung ... auch richtig.
Alles richtig ...

Aber wenn doch von allen eine 32Bit vorliegt warum sollte ich dann 64Bit testen wenn das nicht von allen vorliegt.

Also wie gesagt, ich verstehe die Ansichten zu x64 ja.
Dennoch würde ich so nicht testen ...

Verurteile aber auch niemanden der anders testet

Du hast ja Argumente für x64 und insofern ist das für Dich dann auch OK, klar !!

--

Ja, schaue Dir mal die Erläuterungen zu PGN-Random an.

Gruß
Frank