Leistungseinschätzung Dual-CPU System (Schach)

[Schachwurze]

laut div testergebnissen erzielt man ohne HT die besten ergebnisse. und von den entwicklern empfiehlt niemand HT. sch... auf die knoten oder tiefe. was zählt ist die gesamtanalyse, und die leidet unter HT.
bei den FAQ auf der komodo hp. wird empfohlen die physical cores zu nehmen. threads machen nur sinn, wenn jeder stellung ein thread zugewiesen wird (macht keiner)

HT cloud engines werde ich selber deshalb nicht benutzen. lg

 

[Hellstaff]

Ich kenne diese Diskussionen, doch die Ergebnisse sind (für mich) nicht eindeutig.

Auf dieser Seite http://www.top-5000.nl/testsets.htm habe ich schon einmal ein paar Teststellungen (nightmare) herausgepickt und mit meinen 4930K jeweils mit 6C/6T und 6C/12T getestet.

Es ging um typische "Suche den richtigen Zug"-Aufgaben und die Lösungszeiten lagen zwischen 30s und 5min. Ergebnis: Mal war 6C/6T schneller, dann wieder 6/12T. Auch mit dem Dual-Xeon 20C/40T sehen die Resultate ähnlich aus.

Im CCC Forum ist man auch geteilter Meinung Hyper Threading für Rechnerschach deaktivieren oder nicht ?

 

[Kullberg]

Ich hab das Thema HT im Schach ausgiebig getestet. Bei neueren Intel CPUs bis 4 Cores (6 hab ich nicht getestet) ist es besser, HT anzulassen bzw. alle Cores (reale + virtuelle) zu nutzen. Bei 2-Sockel PCs (ich hab ab 16 Cores getestet), ist es besser HT nicht zu nutzen bzw. nur die realen Cores zu verwenden. Ich mache das durch Setzen von Affinities bei Rechnern bis 32 Cores. Bei Rechnern über 32 Cores muss man HT ausschalten, weil sonst Windows die Cores in groups anordnet, womit kein Schach Programm umgehen kann. Aus diesem Grund machen auch Rechner mit mehr als 64 Cores keinen Sinn.

 

[Hellstaff]

Könntest du vl noch erklären, warum ich in (bestimmten) komplexen Taktikstellungen mit dem Dual-Xeon manchmal die Variante 20C/20T schneller ist als 20C/40T und dann wieder umgekehrt? Spielt die Reproduzierbarkeit des Ergebnisses eine Rolle, denn manchmal habe ich den Eindruck, dass die Engine für den richtigen Zug länger braucht, bzw. bei einer Suchtiefe hängen bleibt. Welche Probleme könnten noch auftauchen?

Apropos Suchtiefe: Ist dieser Wert bei Standardeinstellungen einer Engine ein (relativ) zuverlässiges Maß für die Leistungsfähigkeit eines Programms (in Kombination) mit der Hardware? Vorausgesetzt, der Variantenbaum wird nicht zu stark gestutzt

EDIT: Zum 6-core kann ich relativ sicher sagen, dass 6C/12T schneller den richtigen Zug findet.

 

[Kullberg]

Bei mp-Schachprogrammen ist das Ergebnis non-deterministisch, dh., der Suchbaum ist jedesmal anders. Und jedesmal ist der Weg zum Ergebnis ein Anderer. Du erkennst das daran, dass jedesmal eine andere Anzahl von nodes bis zur gegebenen Suchtiefe angezeigt wird. Oft ist auch das Ergebnis unterschiedlich. Und die PV (principal variation) ist anders. Wenn Du nur 1 Core verwendest kriegst Du normalerweise immer das gleiche Ergebnis nach der gleichen Anzahl von Knoten. Vasik Rajlich (der Programmierer von Rybka / mein Geschäftspartner) hat das Verhalten bei mp als "search luck" beschrieben.
Meine Tests hab ich auf 2 Arten gemacht:
Die gleiche Engine spielt in 2 Versionen: einmal mit allen Threads, einmal nur mit den realen Kernen.
Test 1: die Spielstärke wird verglichen. Dafür braucht man sehr viele Spiele (über 1000) und die Differenzen sind gering
Test 2: die durchschnittliche Suchtiefe wird verglichen. Dafür habe ich ein Programm geschrieben, was pgn Dateien auswertet. Diesen Test kann man recht empfindlich gestalten. Dazu muss die jeweilige Eröffnung jeweils 2x (1x mit Weiß, 1x mit Schwarz) gespielt werden. Es werden nur Ergebnise genommen, wo das Ergebnis gleich ist. Die Differenzen in den jeweiligen Spiel-Paaren werden ausgewertet. Es werden nur Ergebnisse genommen, die innerhalb 1 Standardabweichung liegen. Mit dieser Methode kriegt man deutlich bessere und reproduzierbarere Ergebnisse, es genügen einige Hundert Spiele.

p.s. zur Suchtiefe: sie ist bei einigen Engines ein zuverlässiges Maß für die Leistungsfähigkeit. Bei manchen Engines ist es allerdings so, dass ein Ergebnis mit mehr Threads bei gleicher Suchtiefe besser ist, da hat sozusagen der Baum mehr Äste, es ist nicht soviel durch Reduktiosnalgorithmen weggeschnitten. Ein Test um das rauszukriegen ist einfach: man lässt die Engine 1 Thread gegen maximale Threads spielen bei festgelegter Suchtiefe.

 

[jdl]

Es ging um typische "Suche den richtigen Zug"-Aufgaben und die Lösungszeiten lagen zwischen 30s und 5min. Ergebnis: Mal war 6C/6T schneller, dann wieder 6/12T. Auch mit dem Dual-Xeon 20C/40T sehen die Resultate ähnlich aus.

Für HPC gilt allgemein, daß SMT nichts bringt. SMT korrigiert nur etwas die Problematik des Context Switchings. D.h. man sollte unbedingt die Threads fest an physikalische Cores binden. Es reicht nicht aus, die Threads eines Programms an einen Satz von Cores zu binden es muß unbedingt eine 1:1 Relation sein. Desweiteren sollten die Zahl der Context Switches reduziert werden. Ich habe keine Ahnung ob man das unter Windows beeinflußen kann, unter Linux gibt es spezielle Kernel Builds mit Server Parametrisierung.

 

[Hellstaff]

Danke Kullberg für deine schöne Ausführung


Hier ist noch ein Zitat von Stockfish Programmierer Tord Romstad bezüglich der Reproduzierbarkeit: Romstad Kiiski Costalba


Frage 19

Frank Quisinsky:

"Bei Analysen mit mehreren Cores kommen unterschiedliche Resultate dabei heraus. Dann, wenn versucht wird, die Analyse zu wiederholen. Könntest Du uns diese Umstände näher erklären? Vielleicht tritt dieser Fall auch nur bei einer der möglichen Techniken bei der Implementierung von Multiprozessor-Code auf?"

Tord Romstad:

"Wenn ein Schachprogramm eine Position, irgendwo tief innerhalb des Suchbaums, untersucht, macht es Gebrauch bzw. erinnert sich an frühere bereits untersuchte Positionen der gleichen Suche. Die Zugbeschneidung, Verkürzung oder Verlängerung hängen davon ab, welche Positionen vorher überprüft wurden und wie die Ergebnisse der Untersuchung dieser Positionen waren. Der Großteil der Informationen, der für eine Entscheidung verwendet wird, liegt im Arbeitsspeicher. Der Arbeitsspeicher steht allen Prozessoren zur Verfügung.

Solange es nur einen Thread gibt, ist alles zu 100% reproduzierbar. Aber bei mehreren Threads, beginnen seltsame Dinge zu geschehen, weil diese Threads nie synchron mit gleicher Geschwindigkeit aktiv sein können. Immer wieder wird eine CPU für ein paar Millisekunden eine Pause einlegen müssen und das Betriebssystem weist dann sofort eine andere Aufgabe zu. Das geschieht zufällig und ist nicht vorhersehbar, eine Kontrolle gibt es hierfür nicht. Als Konsequenz erreicht jeder Prozessor eine bestimmte Position eher zufällig und das wirkt sich dann auf die Suche nach Entscheidungen zur aktuellen Position aus."

 

[Kullberg]

Bei den ersten CPUs mit HT hat es tatsächlich nichts gebracht, HT zu nutzen, zumindest nicht für smp. Heute ist das etwas anders. Programme, wo Ergebnisse der einzelnen Threads/Tasks völlig unabhängig sind, profitieren von HT indem sie die Recheneinheiten stärker auslasten. Ein typisches Beispiel ist Cinebench 15, da kann man das licht testen. Tatsächlich steigt auch der Energieverbrauch an - so um ca. 20% bei Rechnern, wo die CPU der hauptsächliche Verbraucher ist. Das Problem beim Schach ist, dass die Mehrleistung an Rechenleistung vermindert wird durch die Tatsache, dass die Ergebnisse teilweise voneinander abhängig sind. Bei weing Cores scheint die Mehrleistung zu überwiegen, bei vielen Cores die Verluste. Und dann gibt es noch den Effekt, dass bei einigen CPUs bei Nutzung aller Threads die TDP überschritten wird und deshalb der Turbo nicht komplett ausgeschöpft werden kann. Dies ist aber bei neueren CPUs eher nicht mehr der Fall - allerdings nur beim Schach, weil da viele sehr einfache instruktionen verwendet werden.

@jdl
Bei Windows kann ein Programm selbst seine eigenen Threads definierten Cores zuordnen - der Befehl ist in C++ setthreadaffinitymask. Von extern kann man das nicht - da kann man nur dem ganzen Programm eine Maske zuordnen, was auch sehr gut funktioniert. Falls ein Programm allerdings keine Threads, sondern Tasks verwendet (einziges mir bekanntes Beispiel beim Schach ist Rybka), kann man von extern jeden Task einem Core zuordnen, was tatsächlich eine gewisse Steigerung der Performance (lt. meinen Messungen 1-2%) bringt.

 

[Knogle]

Also ich nutze Deep Fritz 14 vorallem mit Stockfisch und Texel, und mir hat der Sprung von nem 6 Kerner auf nen 12 Kerner extremst viel gebracht, obwohl die niedriger getaktet sind

Habe dann mal mit 24C/48T probiert und dann mit 24C/24T, und dabei mit letzterem bessere Ergebnisse erzielt