Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / SF6-Ply15: 1Thread vs. 2 Threads vs. 4 Threads
- - By Benno Hartwig Date 2015-05-05 08:38 Edited 2015-05-05 08:51
In http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?pid=92657#pid92657 schrieb ich ja schon, dass möglicherweise die Züge, die bei Nutzung mehrer Threads gewählt werden, zufallsbedingt auch manchmal schlechter sein könnten, als es des Suchtiefe entspricht.

Um hier etwas Einblick zu bekommen, habe ich mal ein Turnier aufgesetzt
Stockfish 6 spielt gegen sich selbst in den Varianten 1 Thread, 2 Threads und 4 Threads, fest eingestellte Suchtiefe 15 Plys
Vor kurzem noch hatte ich erwartet, dass alle dann ca. gleich erfolgreich sein sollten, inzwischen hatte ich Zweifel.

Und so ging es aus:
1: Stockfish-6-64 T1 1088,5/2109   51,61%
2: Stockfish-6-64 T4 1042,5/2108   49,45%
3: Stockfish-6-64 T2 1032,0/2109   48,33%

und im Detail:
Stockfish-6-64 T1 - Stockfish-6-64 T2 : 544,5/1055 158-124-773    51,61%
Stockfish-6-64 T1 - Stockfish-6-64 T4 : 544,0/1054 168-134-752    51,61%
Stockfish-6-64 T2 - Stockfish-6-64 T4 : 521,5/1054 145-156-753    49,48%


Und ich bin unsicher:
Ist dieser Vorsprung der 1-Thread-Variante dem Zufall geschuldet, oder sollte ich das schon als kleine Bestätigung meiner These werten?
51,6% sind ja nur ein kleiner Vorsprung, der ca. 15 ELO entspricht.
Eben habe ich dasselbe für Komodo 8 noch mal gestartet.

Benno
Parent - By GS Date 2015-05-05 09:19
Zu den Daten:
Code:

T1 vs T2 544.5 out of 1055 perf= +11 [+11 -11]
T1 vs T4 544.0 out of 1054 perf= +11 [+11 -11]
T2 vs T4 521.5 out of 1054 perf= - 4 [+11 -11]


Alles also im Lot resp. innerhalb der Error-Margins.
Um so etwas ähnliches wie "Bestätigung" zu erhalten
müsste man diesen Test wohl 10x (oder noch mehr ?)
wiederholen und eine noch deutlich grössere Anzahl
an Spielen durchführen.
Parent - - By Peter Martan Date 2015-05-05 09:49
Benno Hartwig schrieb:

Und ich bin unsicher:
Ist dieser Vorsprung der 1-Thread-Variante dem Zufall geschuldet, oder sollte ich das schon als kleine Bestätigung meiner These werten?


Keine Ahnung, Benno, weil statistisch wird dir das sowieso sofort um die Ohren geklatscht werden, ah ist eh schon passiert.

Aber rein kausal würde ich sagen, kein Wunder, wenn die Tiefe konstant ist, sollte die single core- Suche die effektivste sein, bei SMP müsstest du rein theoretisch, wie du ja, was ich so gelesen habe, eh auch vermutest, einfach eine zusätzliche Fehlerquelle drin haben, wie groß die im jeweiligen Fall ist, wird sich aber vermutlich wirklich nur mit sehr vielen Partien untersuchen lassen, und dann weißt du's erst wieder nur für die eine engine, das eine Testset (buchlos allein würde dafür aber durchaus auch reichen, find ich, wieviele Dubletten produziert werden, spielt hier ja überhaupt keine Rolle, jedes andere Eröffnungsset gibt auch nur über das eine allein Aufschluss, buchlos sollte wenigstens am ehesten reprodzierbar sein) und die eine Suchtiefe.
Parent - - By Frank Brenner Date 2015-05-06 21:39
Mach das Experiment doch auch mal mit tiefe 1-14 und vlt 16

bei den kleineren tiefen sollte das doch auch viel schneller sein.
Parent - - By Benno Hartwig Date 2015-05-06 22:22
Ich habe es gerade noch mal aufgesetzt mit Stockfish und Tiefe 14.
Mal gucken...
Benno
Parent - - By Benno Hartwig Date 2015-05-09 20:39
Bei Stockfish (jetzt fest 14 Plys) ist es wirklich nicht so klar. Hier stand es schließlich:

1: Stockfish-6-64 T2     1657,5/3222    51,44%
2: Stockfish-6-64 T1     1636,0/3222    50,78%
3: Stockfish-6-64 T4     1539,5/3222    47,78%

1 Thread und 2 Threads annähernd gleich auf, 4 Threads ein wenig abgeschlagen.

Die Begegnungen im Einzelnen:

Stockfish-6-64 T1 - Stockfish-6-64 T2    : 806,5/1611 231-229-1151
Stockfish-6-64 T1 - Stockfish-6-64 T4    : 829,5/1611 277-229-1105
Stockfish-6-64 T2 - Stockfish-6-64 T4    : 853,0/1611 296-201-1114

Interessanterweise hat also immer die Engine mit weniger Threads die Begegnung gewonnen.
Nur hatte T2 gegen T4 besonders deutlich gewonnen, wodurch T2 in der Gesamtwertung schließlich vor T1 lag.

Ich fasse mal frech die 14Plys- und 15Plys-Ergebnisse zusammen:

Stockfish-6-64 T1      2724,5   5331    51,11%
Stockfish-6-64 T2      2700,0   5330    50,66%
Stockfish-6-64 T4      2571,5   5331    48,24%

Deutlich ist es nicht, aber ich vermute immer noch, dass SF mit steigender Threadanzahl bei gleicher Suchtiefe ggf. leicht an Qualität verliert.
Das wäre schon ein sehr deutlich anderes Verhalten als das von Komodo.

Benno
Parent - - By Kurt Utzinger Date 2015-05-09 22:11
Benno Hartwig schrieb:

[...]
Deutlich ist es nicht, aber ich vermute immer noch, dass SF mit steigender Threadanzahl bei gleicher Suchtiefe ggf. leicht an Qualität verliert.
Das wäre schon ein sehr deutlich anderes Verhalten als das von Komodo.

Benno


Soll das heissen, dass man SF am besten auf einem Thread laufen lassen sollte???
Kurt
Parent - - By Benno Hartwig Date 2015-05-10 06:39
Nein.
Dass SF bei mehr Threads stärker wird, wurde ja vielfach gezeigt.
Aber die Spielstärkesteigerung geschieht aus meiner Sicht ein wenig langsame,r als man es mit Blick auf die Plys erwarten sollte.
Im Gegensatz zu Komodo, wo die Spielstärke (auf die Plys bezogen) schneller steigt.

Geht SF deshalb nun weniger gut mit vielen Kernen um?
Vielleicht, weiß nicht.
Vielleicht(!) schafft SF es dafür ja besser als K, bei mehr Kernen besonders schnell auf Tiefe zu kommen, OK. Das könnte obigen Effekt ausgleichen
Ich begann das zu untersuchen. Die Ergebnisse waren dann aber so wenig reproduzierbar, sodass wohl nur eine längere Versuchsreihe hier ein eigenes Bild verschaffen kann.
Das habe ich dann abgebrochen.

Benno
Parent - - By Frank Brenner Date 2015-05-10 14:08

> Geht SF deshalb nun weniger gut mit vielen Kernen um? Vielleicht, weiß nicht.


Dein Experiment ist prinzipiell ungeeignet um bei der Beantwortung dieser Frage behilflich zu sein.

Selbst wenn dein Experiment in beliebige extreme weise ausgegangen wäre, so wäre dies noch gar nicht mal ein Indiz dafür, dass SF mit mehr Kernen weniger gut umgeht als K oder umegekehrt.

Du kannst die Merhkernqualität nur mit einem einzigen Test ermitteln: Viele Spiele austragen mit vielen Kernen!
Parent - By Benno Hartwig Date 2015-05-10 19:45

> Du kannst die Merhkernqualität nur mit einem einzigen Test ermitteln: Viele Spiele austragen mit vielen Kernen!


Zustimmung!
Trotzdem hat mich auch die andere Fragestellung interessiert.
Und im Falle Komodo ist ja auch was rausgekommen, was zumindest mich sehr überrascht hat.
Benno
Parent - By Jörg Oster Date 2015-05-05 11:34
Jede SMP-Suche weitet den Suchbaum etwas, sprich, es werden mehr Knoten durchsucht als bei einer entsprechenden Single-Suche der Fall ist => search overhead
Siehe hierzu auch diesen interessanten Beitrag von Kai Laskos auf Talkchess:
http://talkchess.com/forum/viewtopic.php?t=56019

Das sogenannte "Lazy SMP" weitet also den Suchbaum wesentlich mehr als z. B. YBW ...

Für deinen Test mit Stockfish ist also fraglich, ob sich da überhaupt ein Unterschied feststellen lässt.
Wenn, dann aber wohl eher zu Gunsten des SMP-Mode, weil auch hier einfach mehr Knoten bei gleicher Suchtiefe durchsucht werden und die Chance, etwas zu übersehen, leicht geringer ist.

Bei Komodo solltest du aber schon ein wesentlich eindeutigeres Ergebnis erhalten.
Parent - - By Benno Hartwig Date 2015-05-06 21:12
Bei Komodo 8 mit konstanter Tiefe 13 steht es nun

1: Komodo-8-64bit 4T 675,0/1202
2: Komodo-8-64bit 2T 601,5/1202
3: Komodo-8-64bit 1T 526,5/1202

Komodo-8-64bit 1T - Komodo-8-64bit 2T : 275,0/601 86-137-378
Komodo-8-64bit 1T - Komodo-8-64bit 4T : 251,5/601 74-172-355
Komodo-8-64bit 2T - Komodo-8-64bit 4T : 275,5/601 83-133-385

Bei gleicher Tiefe zeigt sich hier, dass Komodo recht deutlich(!) stärker spielt, wenn er mehr Threads hat.
Finde ich erstaunlich!

Benno
Parent - - By Frank Brenner Date 2015-05-07 00:52 Edited 2015-05-07 00:55 Upvotes 1
da gab es vor geraumer zeit einmal ein streitgespräch zwischen Hyatt und Komodo Team , ich glaub DD.

Komodo realisiert die Nutzung von mehreren cpu's auf eine besondere weise und zwar wird der Suchbaum dabei unter anderem auch dichter durchforstet (daher bei gleicher Tiefe die höhere Spielstärke) zusätzlich gelangt Komodo mit mehreren cpu's auch etwas schneller in die tiefe. Komodo realisiert also eine Kombination dieser beiden Elemente.

Es ging hierbei um das Thema wie man die Nutzung von mehreren Cores bewertet, also zb Time-To-Depth.
Bei Komodo ist Time-To-Depth also nicht die richtige Messmethode.

Hyatts Standpunkt war,dass Time-To-Depth die richtige Bewertung sein sollte bzw könnte.
Laut ihm sollten mehrere Cores nur zur Beschleunigung der suche der single-cpu-version hergenommen werden. Wenn - so wie bei Komodo- zusätzlich andere dinge gemacht werden mit den zusätzlichen CPU's so stellt dies laut Hyatt eher ein Designfehler dar, denn die zusätzlichen elemente die nicht zur Beschleunigung der Suche eingesetzt werden könnten ebenfalls in der Single-CPU-Version integriert werden.

Sollte (so Hyatt) die zusätzlichen Cores - so wie bei Komodo - den Suchbaum verdicken, so führt dies also  entweder zu einer suboptimalen  Gesamtlösung oder man könnte also  alternativ auch die single-cpu-version hernehmen und auch dort den Suchbaum verdicken und die single-cpu-version  auf diese Weise ebenso verbessern.

Letzlich ist das eine ähnliche Diskussion wie einmal vor 14 Jahren in der CSS Sprechstunde von Christophe Théron.
Théron vertrat den Standpunkt dass eine gut designte Engine auf jeder Bedenkzeitstufe relativ gesehen gleich stark spielen sollte.

Falls dies - so Théron - nicht der fall sein sollte, so liegt ein designfehler im Programm vor. (bzw suboptimalität)
Kurz: Laut Théron sollten sich die Reihenfolge der Spielstärke der Engines bei  verschiedenen listen die jeweils mit verschiedenen Bedenkzeitstufen ermittelt werden immer gleich sein.
Wir sehen dass dies bei heutigen engines nicht der fall ist, die Verletzung der Regel ist aber nur klein, Komodo ist im Bullet vielleicht 10-15 Elo schwächer als SF, aber bei 5+3 etwa 10 ELo stärker.
Für Prognosen bei deutlich längeren Bedenkzeiten muss aber der Elo-Unterschied nicht immer größer werden, tatsächlich kann die Kurve durchaus wellenförmig sein, d.h. bei 30+5 könnte wieder SF6 besser sein, bei 150+30 wieder Komodo und bei 3 Tage /Zug wieder SF....
Parent - By Peter Martan Date 2015-05-07 06:46
Ich kann mich an die Diskussion mit Hyatt im CCC erinnern, dachte allerdings eigentlich, das sei mit Larry Kaufman gegangen.
Ich kann als Nichtprogrammierer natürlich eigentlich gar nicht mitreden, fand aber damals Hyatts Argumente auch irgendwie nachvollziehbar, vor allem dachte ich halt, bei den angegebenen Suchtiefen der Programme sei die erste Zahl diejenige, die mehr oder weniger "komplett" durchsucht würde.
Ich weiß schon, dass das blauäugig ist, und dass es natürlich gut wäre, würden die Mehrknoten nicht nur für die time to depth so wie bei single core genutzt, sondern auch in mehr "Breite" investiert, es sei denn, dass diese Breite mehr Fehlerquelle als Vorteil wäre, ich hatte halt irgendwie angenommen, kompletter als komplett (was sie ja bei single core in einer bestimmten Tiefe auch schon sein könnte) sei vielleicht eher schlecht als gut.
Eigentlich eine ziemlich pessimistische Sicht von mir, und je mehr ich's mir überlege, desto eher würde ich hoffen, Benno hat sich bei Stockfish von der Statistik täuschen lassen und es bringt bei Komodo wirklich nachweisbar was.
Es könnte ja vor allem die zweite Tiefenangabe der Extensions und der selektiveren Suche bei Mehrkern wesentlich anders sein als bei single core, das müsste sich dann allerdings, würden diese Zahlen überhaupt was sagen, schon im Output allein auch zeigen.
Muss ich mir mal näher anschauen.
Parent - - By Benno Hartwig Date 2015-05-07 08:19 Edited 2015-05-07 08:50
Thanx für die Erklärungen,
insbesondere weil die Komodo-Ergebnisse dadurch verständlich werden.

> Wenn - so wie bei Komodo- zusätzlich andere dinge gemacht werden mit den zusätzlichen CPU's so stellt dies laut Hyatt eher ein Designfehler dar, denn die zusätzlichen elemente die nicht zur Beschleunigung der Suche eingesetzt werden könnten ebenfalls in der Single-CPU-Version integriert werden.


Im ersten Moment wollte ich zustimmen.
Als Einwand fiel mir aber ein: Engine-Parallelberechnung führt immer auch Rechnungen durch, die sich letztlich nicht als hilfreich erweisen (die Diskrepanz zwischen den Faktoren 1,7 und 2,0 eben). Insofern sind die Bedingungen für eine Teilberechnung bei 1 Thread und mehreren Threads etwas unterschiedlich. In dem einen Rahmen könnte eine Berechnung sinnvoll sein (weil andere ja nur vielleicht relevant wären), im anderen Rahmen wären sie aber zweitrangig (weil andere auf jeden Fall hilfreich sind). Nur so eine Idee.
Ggf. hat Hyatt hier doch ein wenig vorschnell geurteilt, ohne Kenntniss dessen halt, wie andere ihre konkreten Lösungen implementieren.

Man ist ja gern mal bereit, gefangen in eigenen Idee darüber zu urteilen, was anderen generell möglich ist.
Andererseits ist Hyatt ja kein Dummer, und er hat gerade in diesem Bereich besonders große Erfahrungen.

Benno

PS:
Bei meinem neu aufgesetzen 14ply-Stockfish-Turnier beginnt es weniger klar, eine erste Tendenz ist hier aber wieder: "Weniger Threads sind bei gleicher Tiefe besser!"
1T: 259,0    2T: 255,0    4T: 237,0           bei jeweils gut 500 Partien
Parent - - By Frank Brenner Date 2015-05-12 18:37

> Ggf. hat Hyatt hier doch ein wenig vorschnell geurteilt ....


Wieso ?
Parent - - By Benno Hartwig Date 2015-05-12 19:16
Soweit ich es verstehe, meinte er, dass die Designentscheidung, wie sie die Komodo-Leute trafen, unvorteilhaft ist.

Abgesehen davon, dass das eine sehr mutig-selbstbewusste These ist, machte ich darauf aufmerksam, dass die Situation in 1-Thread- und mehr-Thread-Logik zumindest darin unterschiedlich ist, dass eine konkrete Detailüberprüfung bei 1-Thread ggf. als entscheidungsrelevant erkannt werden kann, während sie bei einer mehr-Thread-Lösung nur mit einer Wahrscheinlichkeit <1 überhaupt eine Rolle spielt. Das könnte für die Entscheidung, ob der Prüfungsaufwand betrieben werden sollte, eine Rolle spielen.
Und dann würde Hyatt in diesem Punkte ggf. irren.

Benno
Parent - - By Frank Brenner Date 2015-05-13 00:09 Edited 2015-05-13 00:20

> Soweit ich es verstehe, meinte er, dass die Designentscheidung, wie sie die Komodo-Leute trafen, unvorteilhaft ist.


das hat er nicht gesagt.

Es war eine theoretische Aussage:

Wenn ein Schachprogramm  für 1 CPU optimiert ist  und wenn dann noch n CPu's dazukommen, dann ist es theoretisch möglich den Algorithmus so zu erweitern dass er mit den n Cpu's einem maximal großen Speedup erfährt der zu einer maximal möglichen Spielstärke führt.

Bei einem Schachprogramm  sollte dann dieses schachprogramm mit dem maximal größten Speedup Spielstärkemäßig keiner anderen Lösung unterlegen sein.

Sollte es andere Lösungen geben die zusätzlich zu einem nicht_maximalen Speedup noch zb noch den Suchalgorithmus verändern (zb K), so ist gelten folgende Aussagen
(i) - K kann auch für 1 CPU verbessert werden.
ODER
(ii) K kann so umgeschrieben werden, dass die zusätzlichen CPU's lediglich für einen Speedup eingesetzt werden und das so entstehende Programm ist mindestens so spielstark wie K (ggf sogar stärker)

Komodo ist also kein Beleg - und noch nicht mal ein Indiz - dafür dass die Annahme falsch ist.

Selbst wenn Lefler - und jeder andere mensch - sagt er sei nicht in der Lage Komodo so umzuschreiben dass (i) oder (ii) gilt, so ist das kein Gegenbeweis.
Parent - - By Benno Hartwig Date 2015-05-13 08:45 Edited 2015-05-13 09:19
Hyatts "Annahme" (These, mehr ist es nicht, oder?) steht aber doch im direkten Widerspruch zu Idee bei der Komodo-Entwicklung.
Diese verstehe ich so (vielleicht irre ich ja auch):
   Sie implementieren Logik, die so nur bei Verwendung mehrerer Kerne wirksam ist.
   Das tun sie dann doch, weil sie nicht glauben, dass ihnen (i) gelingt
   und weil sie keinen Weg zur Realisierung von (ii) erkannten.

Das ist kein Beweis. Da hast du natürlich Recht.
Aber immerhin gelang ihnen damit ein absolutes Spitzenprogramm, welches insb. auf vielen Kernen überzeugt.
Ich erkenne das schon als Indiz an.

Zumindest müsste Hyatt sich jetzt aufgefordert fühlen, eine wirklich gute Begründung für seine These zu geben.
Bauchgefühl und "ich habe viel Erfahrung, und mir gelang nie was anderes" wären nur schwache Argumente.
Anderen Engineentwickler sind halt auch nicht unbedingt Dummies!

Benno
Parent - - By Frank Brenner Date 2015-05-13 12:45 Edited 2015-05-13 12:47
Ich denke es ergibt keinen Sinn hier weiter zu vertiefen, da ich den Link zu dem Thread nach talkchess nicht finde.

> Sie implementieren Logik, die so nur bei Verwendung mehrerer Kerne wirksam ist.


Grundsätzlich lässt sich jeder Algorithmus der auf n CPUs läuft auch mit 1 CPU berechnen, von daher ist die Berechnungskraft identisch.

Der einzige Vorteil von n CPU's ist eine potentiell höhere Geschwindigkeit. Sämtliche Logik lässt sich auch ebenso auf einer CPU realisieren.
Parent - - By Benno Hartwig Date 2015-05-13 13:00

> Grundsätzlich lässt sich jeder Algorithmus der auf n CPUs läuft auch mit 1 CPU berechnen, von daher ist die Berechnungskraft identisch.


Ja, aber:
auf 1 CPU kann es wegen der hier ja anderen (besseren!) Informationslage ggf. wirkungsvoller sein, lieber etwas anderes zu berechnen als bei mehreren CPUs.
Ein Argument, weswegen dies tatsächlich nicht (nie) sein kann, hörte ich bislang nicht.
Aber ob das auch wirklich stattfindet, kann ich andererseits natürlich auch nicht sagen. Bei Komodo versucht man es halt so.

Benno
Parent - - By Frank Brenner Date 2015-05-13 15:36

> auf 1 CPU kann es wegen der hier ja anderen (besseren!) Informationslage ggf. wirkungsvoller sein, lieber etwas anderes zu berechnen als bei mehreren CPUs.


Wie bitte ?

Nebenbei bemerkt, ich weiß nicht ob du das weißt: Bei einer parallelen Suche im Schachbaum, kann das Programm vorher nicht entscheiden ob es für bestimmte Äste sinnvoll ist diese zu durchsuchen. Aus diesem Grund kann man die vergeudete CPU Performance (Faktor ~1,7 statt 2 bei 2 CPUs) nicht für andere dinge abzweigen.

Zweigt man dennoch CPU leistung der anderen cpus für andere Dinge ab anstatt die zusätzlichen CPUs zur Beschleunigung einzusetzen( so wie bei Komodo) so könnte diese verdickte Suche auch in der 1-CPU Version zur Verbesserung des Spiels führen.
Parent - - By Benno Hartwig Date 2015-05-13 16:21
Wieso dein "Wie bitte".
Dein folgender Satz erklärt doch sehr zutreffend, warum eben bei 1 CPU eine "bessere Informationslage" besteht.
Und unterschiedliche Informationslagen machen in der Folge dann ggf. auch unterschiedliche Logik empfehlenswert.

Dein letzter Satz ist ja für sich genommen richtig, er ignoriert aber:
Es gibt ggf. Logik für 1-CPU-Betrieb, die für die Beschleunigung besonders wirkungsvoll ist, die bei mehr CPUs aber schlechter wirkt (wg. schlechtere Informationsbasis). Und stattdessen  macht man vielleicht dann etwas anderes, etwas was weniger beschleunigt aber besser wertet.
"Stattdessen" ist ein wichtiges Wort. Darum ließe sich diese Logik ggf. nicht einfach für 1-CPU-Betrieb dazubauen.

Ich halte sowas zumindest nicht für ausgeschlossen, und ggf. steckt bei Komodo solch eine Überlegung hinter der Realisierung.

Benno
Parent - - By Frank Brenner Date 2015-05-13 16:31

> Es gibt ggf. Logik für 1-CPU-Betrieb, die für die Beschleunigung besonders wirkungsvoll ist, die bei mehr CPUs aber schlechter wirkt (wg. schlechtere Informationsbasis).


Kannst du Programmieren ? Dann zeig mir mal ein Beispiel. Ich verstehe deinen Satz jedenfalls nicht.
Parent - - By Benno Hartwig Date 2015-05-13 17:07

> Kannst du Programmieren ? Dann zeig mir mal ein Beispiel. Ich verstehe deinen Satz jedenfalls nicht.


Ja, ich kann programmieren.

Beispiel:
Analyse eines Zuges mitten im Suchbaum.
Wenn die bisherige Analyse einen wirkungsvollen beta-Wert bietet (z.B. bei 1-CPU-Betrieb oft der Fall), wird diese Zuganalyse schnell sein (schnelle Widerlegung).
Wenn noch kein gut nutzbarer beta-Wert bereit steht (bei mehr-CPU-Betrieb immer wieder mal der Fall), würde die Analyse desselben Zuges an dieser Stelle sehr deutlich (um ein Vielfaches?) länger dauern.
Dann könnte entschieden werden, diese Analyse jetzt noch nicht zu machen, zwischendurch etwas anderes zu bewerten, vielleicht ein Kriterium, welches man sonst gar nicht beachtet hätte.

Wohlgemerkt:
Ich behaupte nicht(!), dass tatsächlich so Vorteile entstehen.
Ich sage nur, dass ich kein Argument erkenne für die These, dass dies nie so eintreten kann.
("Nicht das, was wir nicht wissen, bringt uns zu Fall, sondern das, was wir fälschlicherweise zu wissen glauben." Tom DeMarco)

Benno
Parent - - By Frank Brenner Date 2015-05-14 00:22

>Dann könnte entschieden werden, diese Analyse jetzt noch nicht zu machen, zwischendurch etwas anderes zu bewerten, vielleicht ein Kriterium, welches man sonst gar nicht beachtet hätte.  Ich behaupte nicht(!), dass tatsächlich so Vorteile entstehen. Ich sage nur, dass ich kein Argument erkenne für die These, dass dies nie so eintreten kann.


Und diese schwache argumentation lässt Dich dann behaupten: Zitat "Ggf. hat Hyatt hier doch ein wenig vorschnell geurteilt, ohne Kenntniss dessen halt, wie andere ihre konkreten Lösungen implementieren."
Parent - - By Benno Hartwig Date 2015-05-14 07:08 Edited 2015-05-14 08:01

> Und diese schwache argumentation lässt Dich dann behaupten: Zitat "Ggf. hat Hyatt hier doch ein wenig vorschnell geurteilt, ohne Kenntniss dessen halt, wie andere ihre konkreten Lösungen implementieren."


Ja,
sie lässt mich erklären, dass Hyatt hier gegebenenfalls ein wenig vorschnell geurteilt hat.
(und dicker hatte ich es ja nicht formuliert)


Solche eine allgemeingültige  Aussage zu Entwicklungen, die man nicht kennt, sind prinzipiell zwar manchmal möglich.
Sie brauchen aber eine sehr gute Argumentation.
Und dies um so mehr, wenn andere Fachleute mit ebenfalls viel Erfahrung und herausragenden Ergebnissen ihre Arbeit erkennbar daran ausrichten, dass diese Aussage so nicht gilt.

Ja, ich halte daher meine ggf-Bemerkung , die du zitierst, auf jeden Fall für gerechtfertigt.
Zu oft habe ich gerade in meinem Studium Leute kennen gelernt, die mit großer Überzeugt etwas fälschlicherweise für unmöglich gehalten haben!
Und später stellte sich dann heraus, dass (nur) sie die ggf. recht versteckte Lösung mit ihren Ansätzen nicht finden konnten. Gefangen in eigenen Denkweisen.

Und wenigstens 2 mal sind mir ähnliche Fehleinschätzungen auch passiert (beide Male übrigens hinsichtlich des Zeitaufwandes denkbarer Algorithmen für bestimmte Problemlösungen).
Und ich war dann jeweils richtig verblüfft, als mir später Lösungen präsentiert wurden, die ich doch für unmöglich gehalten hatte.

Benno
Parent - - By Frank Brenner Date 2015-06-24 01:33

> Ja, sie lässt mich erklären, dass Hyatt hier gegebenenfalls ein wenig vorschnell geurteilt hat.


Benno, du kannst das Experiment jetzt auch mal mit Komodo 9.1 machen, also ob eine 4 Core Suche bis zu Tiefe n einen deutlich dichteren Baum berechnet als eine 1-Core Suche bis Tiefe n.

Hyatt fühlt sich jedenfalls bezugnehmend auf sein früheres Posting mit K9.1 plötzlich im Recht:

http://talkchess.com/forum/viewtopic.php?topic_view=threads&p=629326&t=56762
Parent - By Benno Hartwig Date 2015-06-24 06:28
Sorry. ich habe K9.1 nicht. (noch nicht ?)
Bei K8 hatte ich halt gesehen, dass bei gleicher Rechentiefe die Version mit mehreren Kernen deutlich erfolgreicher war. Was ich hier sicher nicht erwartet hatte.
Benno
Parent - By Daniel Mehrmann (Homer) Date 2015-05-07 14:38 Edited 2015-05-07 14:42
Die unterschiedliche Größe der Suchbäume während einer SMP-Suche,
welche bei jeder neuen Suche jedes mal anders ausfallen, lassen sich
dadurch erklären, das bei modernen Engines die Bedingungen für
z.B für LMR oder LMP durch die Parallelisierung der Zugverarbeitung
nicht mehr genau eingehalten werden können oder zumindest ein hoher
Verlust an Performance hingenommen werden muss.

In der Regel führt dies dazu das die Suchbäume anwachsen und sich
das Problem pro zusätzlichem Thread per Node (Splitpoint) potenziell erhöht.

Gruß
Daniel
Up Topic Hauptforen / CSS-Forum / SF6-Ply15: 1Thread vs. 2 Threads vs. 4 Threads

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill