> Als Nicht-Fachmann ist mir bspw. aufgefallen, dass die Threads untereinander über Datenstrukturen kommunizieren, die zeitweise für andere Threads gegen lesen oder schreiben gesperrt werden. Dadurch scheint mancher Engine eine Menge Sand ins Getriebe zu geraten. Im TCEC ist mir aufgefallen, dass Togas Knotenleistung und Tiefe bei 16 Cores kaum besser waren als auf meinem 4 Core-PC.

Mag sein, dass deine Idee in die richtig Richtung führt.

Ich hatte gedacht gehabt, dass eine schlechte Parallelisierung dazu führt, dass viele Knoten berechnet werden, die für die Entscheidung letztlich irrelevant sind, oder dass trotz Hashtable Berechnungen mehrfach erfolgen. Beides hätte dann aber wohl zu hohen nps-Werten führen müssen, auch wenn die Geschwindigkeit des in-die-Tiefe-Gehens und damit die Spielstärke davon nur wenig profitieren könnte.

Und nun steigt bei Houdini bei der Rechenpowerverdopplung 16->32 kerne der nps-Wert nur um schlappe 20 Prozent.
(und bei diesen 20% können immer noch unsinnigerweise und doppelt berechnete Knoten dabei sein)
Sand im Getriebe, Sperrungen, Warteschlangen. Mag sein.

Geschwindigkeitssteigerungen durch Schnellermachen einzelner Kerne werden zunehmend schwierig, denke ich.
Da ist die Flucht in viele-Kerne dann schon ein Weg, weiterhin kräftig Leistungssteigerungen zu produzieren.
Wird ein anständiger Arbeitsplatzrechner in 20 Jahren ggf. 16 Kerne haben?
Und wieviele Kerne wird eine Maschine haben, die man sich hinstellt, um eine Super-(schach-)Maschine zu besitzen?

Entwicklungsarbeit in eine sehr gute Parallelisierung erscheint mir sehr wichtig, wenn man auchin paar Jahren noch eine Top-Engine anbieten will.
Komodo(?) wurde doch auch lange nicht wirklich ernst genommen, eben weil es da nur eine 1-Kern-Version gab.
Ähnlich wird es in ein paar Jahren den Engines ergehen, die nur bis zu 4 Kernen gut skalieren.

Benno

Nachdem dein posting an mich auch genau so geendet hat, und ich dir in genau dem Punkt auch recht gebe (), probier ich's auch nochmal, obwohl es Roland eigentlich schon gut genug auf den Punkt gebracht hat.
Du sagst, wir hätten einfach nicht genug Teststellungen und kannst damit eigentlich auch wieder nur meinen, "um damit Ranglisten unnötig zu machen".
Stimmt, die haben wir aber auch nicht, wenn wir meinen, wir könnten die engines den Großteil dieser Teststellungen selbst erfinden lassen, indem wir sie einfach nur eine entsprechend große Zahl von Partien aus sehr viel weniger Teststellungen, die wir aber auch rein willkürlich aussuchen, ausspielen lassen.
Ich gehe mal auf diesen Denkfehler gar nicht wieder näher ein, aus dem aber das einfach falsche Dogma entsteht: "Elo aus gut erstellten Ranglisten sind das einzig aussagekräftige Spielstärkekriterium und geben perfekt etwas wieder, was man als overall playing strength bezeichnen könnte und müsste, und dadurch und nur dadurch braucht einen  an engines und deren Entwicklung sonst nichts zu interessieren".
Obwohl es einem mit der Flut an >3000-Elo-engines längst rein praktisch vor Augen geführt wird, dass dieses Dogma sich selbst widerlegt hat, und die Speerspitze der engine- Entwicklung, das Stockfish- framework, längst die Elo, die hinten rauskommen sollen, nur mehr mit gezielt für bestimmte Stellungstypen programmierten patches füttert, (merke: autoplay als Fortschrittskontrolle ist nicht gleich autotuning, es kommt einfach nicht nur darauf an, wie, sondern auch darauf, was genau du testest), obwohl das alles so ist und hinlänglich bekannt, hältst du eisern daran fest, ich bin mir nach dem, was du in diesem thread hier wieder so schreibst, ziemlich sicher, aus genau einem Grund:
Du lässt einfach als "Teststellungen", wie du sie dir vorstellst, nur solche gelten, bei denen es deiner persönlichen Ansicht nach nur einen einzigen best move gibt, der noch dazu mit einem Riesenevalabstand gegen alle anderen Kandidatenzüge beweisbar ist.
Das ist einfach Scheuklappendenken, Ingo, deine Teststellungen deines Ranglistentestsets sind auch Teststellungen, egal wie du sie nennst, und du legst besonderen Wert darauf, dass sie keinen best move als "Lösung" haben, in Wirklichkeit ist genau das der pure Selbstbetrug, es sind Teststellungen und deshalb, weil du die best moves, die es in jeder Stellung gibt, einfach nicht kennst, und ihn dir die engines auch nicht anhand ihrer einzelnen numerischen Evals beweisen können, ist das noch lange nicht anders.
Du sagst, es gäbe einfach nicht genug Teststellungen und im selben Satz sagst du dazu, wenn sie die engines nicht in Unmengen von Partien selbst erfinden.
Das ist interdictio in se, Ingo, nicht mehr und nicht weniger, da denke nicht ich ums Eck, sondern du, um dir selbst nicht die logisch sonst sofort anstehende Frage beantworten zu müssen, wo ist denn der Unterschied zwischen Stellungen, die der Mensch und solchen, die die engines "erfinden"?
Es gibt keinen in Wirklichkeit, buddhistisch betrachtet genauer gesagt in Wahrheit, nämlich im Wesentlichen:
Schachstellungen sind praktisch unendlich zahlreich, aber alle sind "lösbar", die einen leichter, die anderen schwerer, auch das liegt im Auge des Betrachters, wenn sie dir schwer oder unlösbar vorkommen, liegt das nur daran, dass du nur ganze und halbe Punkte als Ergebnis gelten lässt.
Der einzig wirkliche Unterschied ist, wie ähnlich sie einander in Hinblick auf bestimmte verschiedenste schachliche und programmiertechnische Kriterien sind, wenn du nur 0, 1 und 1/2 zählst, entgeht dir der Großteil dieser Unterschiede ziemlich sicher und du beschränkst dich auf ein kleines Teilgebiet, von dem du meinst, ah, eh unlösbar, kann man an die engines delegieren.

Nimm einfach, wenn du nicht nur die taktischen hot shots als Teststellungen gelten lassen willst und kannst, irgendwelche aus der Fernschachpraxis und der allgemeinen Eröffnungstheorie hinlänglich als ausanalysiert bekannte Stellungen in beliebiger Anzahl, befreie dich von dem Zwangsgedanken, es dürfe nur einen einzelnen Lösungszug geben, lass ein paar verschiedene gelten, die nach gründlicher Analyse in den Evalverläufen in den relevanten Abspielen innert einer definierten Range liegen, was den Quotienten der Evaländerungen über diese relevanten Varianten angeht, nimm von mir aus ruhig auch den STS (hast du dir den überhaupt schon einmal etwas näher angeschaut, ist doch für TDS völlig wurscht, wie du das krampfhaft in diesbezüglich völlig irrelevante Elos umrechnen könntest) und wirf das mit allen möglichen taktischen Testsets zusammen, wenn es dir nur um Quantität geht, um die geht's aber außer dir hier niemandem in dem Zusammenhang.
Bestimmte technische Fähigkeiten in bestimmten Stellungen zu beurteilen, braucht kein Riesenkollektiv, es braucht ein klare Fragestellung, was genau man testen will, und dann muss man sich halt mit der Antwort auf nur genau die eine Frage zufrieden geben und für die nächste Antwort die nächste klare Frage mit der nächsten Teststellung stellen.
Das alles sagt dir nix, ist ok, schade, wenn du es selbst schade findest, aber wenn's dir eh egal ist, nicht einmal das, dann nicht einmal schade, Ingo.
Wissen ist Macht, du weißt nix, macht auch nix, wenn du's eh nicht wissen willst.

> Kn/s sind ungeeignet um die Qualität der Implementierung der parallelen Suche zu bewerten.

Im Prinzip teile ich deine Bedenken.
Aber was da so im Einzelnen passiert, wenn eine Engine bei Kernverdopplung nur 20% nps gewinnt, würde mich doch interessieren.
Und ich vermute einfach mal frech, da läuft irgendwas verdammt schlecht, ist unglücklich programmiert.
Insofern sind zumindest einige Bewertungen wohl schon möglich.

Benno

Irgendwie verstehe ich die Argumentation nicht. Beim Schach sagst du, spiele für dich nur die Zielgröße ELO eine Rolle.
Für die Vermessung der für die Erreichung des ELO-Ergebnisses verantwortlichen Komponenten wie Stellungsbwertung, (paralleler) Suchalgorithmus, technissche SMP-Implementierung (z.B. semaphoren, spinlocks, process- oder thread-basierend), Bedenkzeitmanagement, ...  interessierst du dich nicht.
In der Formel 1 ist es aber nicht das Rennergebnis was einzig interessieren soll, sondern hier spielen nun die Berachtung der einzelnen Komponenten eine wichtig Rolle?

Aber ok, ich versuche es mal ohne Autos.



"Qualität der Implementierung der parallelen Suche", bin mir nicht genau sicher, wie du das meinst und bevor ich das
falsch interpretiere, will ich lieber mal etwas weiter ausholen, damit wir auch vom Gleichen sprechen.
In der Landschaft der heute etablierten parallelen Suchalgorithmen befinden sich neben weiterentwickelten Konzepten wie parallel Alpha-Beta-Suche,
Algorithmen wie YBWC (heute in vermutlich vielen Schach-Engines verwendet) und brute-force Ansätzen wie Shared-Hash-Table
(vermutlich das was du als "dumm programmierte Engine" bezeichnen würdest, so sie ihn benutzen würde).
Parallele Suchalgorithmen haben als Kenngrößen die Merkmale "Speedup" und "Skalierung".
Mal auf Schach übertragen könnte man sagen das Speedup in TTD und Skalierung in NPS gemessen werden kann.
Da die traversierende Baumsuche nunmal inhärente serielle Merkmale aufweist, ist deren Parallelisierung niemals trivial
und auf Schach bezogen heißt das, dass man versuchen muss a) möglichst wenig Arbeit doppelt zu machen und b)
Ergebnisse möglichst unmittelbar in die Suche einfließen zu lassen, um nicht an schon "veralteten" Stellungen herumzurechnen.
Für a) gibt es Hash-Tables und b) versucht z.B. YBWC zu adressieren. Charakteristikum von Algortithmen wie YBW ist aber
deren begrenzte Skalierbarkeit bei aber gutem Speedup. So einfach wie du das mit der "dummen und cleveren Threadverwaltung"
einer Engine beschreibst ist das dann aber nicht, denn natürlich wird das niemand so programmieren, wie du es in dem "dummen Fall"
beschreibst. Das Problem entsteht an der Stelle, wo deine "clevere Engine" nicht genau weiß, was in dem Moment an der Stelle im Baum
clever ist. Sie könnte sich vermeintlich clever verhalten und als clever annehmen, was bis eben noch clever erschien, aber genau
das macht der YBW eben nicht, sondern er rückversichert sich in einem nicht parallelisierten Schritt an vermeintlich optimaler Stelle,
ob sich die  nicht vielleicht der ganze Zweig des Baumes erledigt hat, bevor er mit der Gewalt von vielen Threads in dessen Analyse
einsteigt. Übrigens eines der Beispiele an denen man sieht, dass Algorithmen aus menschenhand stammen  
So, und was machen wir nun in solchen Momenten des "Wartens vom kleinen Bruder", CPU-Resourcen idlen lassen oder vermeintlich
"dumme" Aufgaben verteilen?
Als Engineentwickler ist es sicherlich schwer vorhersehbar, inwieweit die eigene Engine mit ihrem Suchalgorithmus später mal auf
bestimmter Hardware skaliert, also sich die Kurve der Knotenleistung/sec pro weiteren Prozessor/Core/Thread darstellt.
Insoweit sind Messungen wie die von Andreas hier von sehr großem Wert für sie (insbesondere, wenn sie nicht selbst solche Maschinen
zur Verfügung haben). Und ich könnte mir gut vorstellen, dass Engines wie Junior oder Komodo hieraus ihre Konsequenzen gezogen haben
und versuchen auf Systemen in denen ihre Programme mit vielen Threads ins Rennen geschickt werden, dem Problem der abflachenden
Skalierungskurve des mit zunehmender Anzahl von Threads, mit zunehmender Verbreiterung des Suchbaums zu begegnen, die ein besseres
Skalierungsverhalten hat.
In gewisser Weise also aus SMP-Sicht ein Shift zu besserer Skalierbarkeit auf Kosten schlechteren Speedups mit dem Ergebnis einer besseren ELO.
Das die Komodo/Junior-Teams hier festgestellt haben, dass eine breitere Baumstruktur generell Vorteile bringt, kann ich mir nicht vorstellen,
dass müsste dann für single-thread genauso gelten. Die Fragestellung, inwieweit sich die Struktur des Baumes
auf die Spielstärke des Programms, sagen wir mal gemessen in den beliebten ELO, auswirkt, sehe ich als eine sehr komplexe Funktion mit
vielen Variablen. Ob es besser ist in Tiefe X lieber nach X+1, oder breiter in Tiefen <X zu rechnen, hängt sicher ausser von der aktuellen Tiefe X
auch ganz wesentlich von der jeweiligen Stellung ab. Hinzu kommen, wenns um ELO geht, Fragestellungen inwieweit sich Weiterrechnen in
Anbetracht der zu investierenden Bedenkzeit und sich der vielleicht seit mehreren Plys kaum noch ändernden Wurzelknotenbewertung
überhaupt noch lohnt.

Nur nochmal zur Sicherheit:

- nps ist kein gutes Maß um den Spielstärkezuwachs in ELO-Zahlen auszudrücken, sondern ein Maß der Skalierung einer Engine
- TTD ist auch kein gutes Maß um Spielstärkezuwachs in ELO-Zahlen auszudrücken, sondern ein Maß des Speedups einer Engine
- ELO ist vermutlich das einzig gute Maß um Spielstärkezuwachs in ELO-Zahlen auszudrücken.

Ansonsten kann ich jedem (des englischen mächtigen) nur empfehlen bei talkchess vorbeizuschauen, da gibt es viele sachkundige
Diskussionen hierzu.

so, mittagspause um
gruß
roland