Optimale Spielstärke auf hyperthreadfähigem Prozessor

By Wolfgang Battig Date 2015-01-16 16:51

Benno Hartwig schrieb:

Wird eigentlich folgende Frage von der 'Gemeinde' einhellig beantwortet, oder gibt es da verschiedene Sichten?

Wie sollte man auf einer hyperthreadfähigen Maschine mit 2 realen Kernen (einem i3) eine Engine einsetzen, wenn man maximale Spielstärke erreichen will?
Mit 2 Threads (weniger Parallelisierungsverluste) oder mit 4 Threads (voller Prozessorausnutzung)?

Analog könnte man natürlich auch zu den 4 realen Kernen eines i7 fragen:
Sollte man dann lieber 4 Threads oder 8 Threads einstellen?

Benno

Wenn es dir um eine (bestimmte) Engine geht, die du z.B. zur Analyse nutzt: einfach beide Varianten ausprobieren und die nehmen, die mehr Knoten macht. Die nps eignen sich zwar nicht zum Vergleich unterschiedlicher Engines weil jede anders zählt/darstellt, aber wenn du nur wissen willst, ob Engine A auf 2 oder 2+2 Threads schneller ist...

By Benno Hartwig Date 2015-01-16 17:01 Edited 2015-01-16 17:03

Ich habe so eine Vermutung, und ich habe mit Stockfish nun gerade einen Test gestartet: 2 Threads gegen 4 Threads
Da kann natürlich nur 1 Partie zur Zeit laufen, und so wird das etwas dauern...
Andere Engines (z.B. Komodo) mit einer besseren oder schlechteren Qualität der Parallelisierung mögen sich da auch noch etwas anders darstellen.

Mich würde interessieren, ob die Erwartungen der Computerschachinteressierten hier übereinstimmen, oder ob die Meinungen da auch auseinander gehen.

Die nps-Werte taugen vermutlich nicht zum Vergleich, da mit steigender Thread-Zahl ein immer größer werdenden Anteil von Knoten analysiert wird, der bei kleinerer Thread-Zahl bereits früher per Cut rausgeflogen wäre. Also überflüssigerweise analysierte Knoten, die aber beim nps-Wert mitberechnet werden.

Benno

By Hauke Lutz Date 2015-01-16 17:11

Das Problem ist, dass man sowas nur mit 2 PCs über eine Netzwerkverbindung testen kann.

By Benno Hartwig Date 2015-01-16 17:15

Was spricht dagegen, auf einem einzigen PC jeweils eine Partie ohne Pondern zu spielen:

Stockfish 2 Threads vs. Stockfish 4 Threads

Welche Befürchtung hast du, was da passieren könnte, was das Ergebnis verfälscht?

Benno

By Hauke Lutz Date 2015-01-16 17:17

Das Problem ist das du bei HT on wirklich nur 2 viertel Kerne bei der einen und 4 viertel Kerne bei der anderen Engine hast.

By Benno Hartwig Date 2015-01-16 17:26 Edited 2015-01-16 17:42

... wobei aber bei Nutzung von nur 2 Kernen diese sehr deutlich schneller rechnen als wenn du 4 aktive Threads hast.
Ich beschrieb meine Beobachtung mal in
http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?pid=90257#pid90257
Bei 4 aktiven Threads rechnet der einzelne Thread demnach mit 59,5% der Leistung, die ein Thread bei nur 2 aktiven Threads hat.
(Das heißt: Der Prozessor macht nicht viele kleine Extrapausen, nur weil seine HT-Threads nicht ausgelastet sind. Die Anzeige des Taskmanagers 50% ist dann irreführend, der Prozessor macht schon so schnell wie er kann, kann nur die spezielle HT-Lückenfüllerei nicht betreiben, darum eben 59,5% statt 50,0%)

Benno

By Hauke Lutz Date 2015-01-16 17:46

Ich lese die CPU/RAM-Auslastung über die Logitech Gaming Software mit Darstellung auf einer Tastatur mit Bildschirm aus, weil der Taskmanager schon alleine bei übertakteter CPU nicht genau ist.
Das diese Experiment genau ist kann ich mir zwar immernoch nicht wirklich vorstellen, aber nun gut. Ich lasse mich gerne eines besseren belehren.

By Benno Hartwig Date 2015-01-16 21:12

Wie ich es sehe, kann ich auf meinem Notebook Hyperthreading nicht deaktivieren. Hier stellt sich nur die Frage: 2 oder 4 Threads. Meine Beobachtung beschrieb ich ja.
Ob sich bei 2 Threads ohne Hyperthreading noch was ändern würde, wenn man denn HT deaktivieren kann, wäre schon auch interessant. Und für solch einen Test bräuchte man dann doch 2 verbundene Rechner, da hast du recht.

Benno

By Thomas Plaschke Date 2015-01-16 21:33

Wir hatten im letzten Jahr schon einen längeren Austausch zu HT. Für mich war danach klar, "HT aus" bzw. "HT nicht nutzen" ist für Schachprogramme am besten. Punkt. Kein aber.

Bei einem Test muss man darauf achten, dass die Engine, die ohne HT arbeiten soll, auch wirklich auf verschiedenen physischen Kernen läuft (Ich hatte Resultate beschrieben, die aus der Nichtbeachtung dieser Bedingung folgen.). Die nicht verwendeten Ausführungspfade der von einer engine genutzten physischen Kerne dürfen auch nicht von einer anderen engine genutzt werden.

Für mich bleibt weiter nicht die nps-Leistung entscheidend. Time to depth und Lösungsgeschwindigkeit geben den Ausschlag - bei multithreaded engines aber leider nicht deterministisch. Meine Beobachtungen lassen mich letztlich auf die simultane Nutzung beider Ausführungspfade eines Kerns (so heißen die logischen (HT-)cores bei Intel wohl technisch) verzichten. Ganz klar: Daumen runter für HT! Ehrliches Multitasking für ehrliche Programme! Nur ein Thread pro physischen Kern!

Viele Grüße
Th. Plaschke

By Benno Hartwig Date 2015-01-17 07:19

> Bei einem Test muss man darauf achten, dass die Engine, die ohne HT arbeiten soll, auch wirklich auf verschiedenen physischen Kernen läuft?

Hast du denn tatsächlich beobachtet, dass auf eine 2-Kerne-Maschine bei nur 2 aktiven logischen Kernen diese beiden auf einem(!) realen Kern abgearbeitet wurden, während der andere reale Kern mit seinen beiden logischen Kernen gemütlich Pause macht? (wenn das nicht ausdrücklich so konfiguriert wurde, versteht sich)
Ich beobachtete so was bislang nie.

Ich hatte bislang immer schön angezeigt bekommen, dass zwei aktive Threads tatsächlich zusammen annähernd die Knotenleistung bieten wie 4 aktive Threads.
Ich interpretierte dass dann: Auch bei nur 2 aktiven Threads sind beide realen Kerne voll ausgelastet.
Dass sie nicht ganz die Knotenleistung der 4 aktiven Threads erreichen ist zu erwarten und liegt nur daran, dass die geschickte Befehlsausführungsoptimierung, die HT ja realisiert, so nicht greifen kann.

Benno

By Thomas Plaschke Date 2015-01-17 12:10

Benno Hartwig schrieb:

Ja, welchem Ausführungspfad (im weiteren spreche ich nur von Pfaden) das Betriebssystem einen Prozess/Thread zuweist, bestimmt es selbst (Das Windows 8.1, auf dem dieser Text entsteht, verwaltet in diesem Augenblick mehr als 1100 Threads! Auf welchem Kern/Pfad ein Thread ohne explizite Zuweisung ausgeführt wird, ist kaum vorhersagbar.). Bei einem 2-Kerne-mit-4-Pfaden-Prozessor laufen die erwähnten beiden Threads einer engine dann auch mal nur auf den beiden Pfaden eines Kerns. - Der andere Kern ist dann zeitweise unbenutzt. Nachweis: Die Auslastungsanzeige des Taskmangers. Alle logische Prozessoren sind gleichmäßig ausgelastet. Ich habe definitiv nicht den Eindruck, dass Windows zwischen Kernen und Ausführungspfaden unterscheidet. Man kann natürlich auch der Auffassung sein, dass bei zwei Threads jeweils ein Thread nur von den Pfaden des gleichen Kerns ausgeführt werden - die Auslastungsanzeige würde dasselbe Bild liefern. Aber wenn ich zwei Instanzen eines single-threaded laufendes Programmes explizit auf verschiedenen Kernen (nicht Pfade! Ich weise der jeweiligen Instanz beide Pfade des einen Kerns zu.) starte, zeigen beide Instanzen eine erkennbar höhere Knotenleistung als ohne explizite Zuweisung der Kerne.

Aber möglicherweise habe ich die Frage nicht richtig verstanden ("2-Kerne-Maschine bei nur 2 aktiven logischen Kernen "? - mit HT hat sie 4 (aktive) logische Prozessoren. In der üblichen Nomenklatur sind Kerne=cores=physische Prozessoren. Der i3 hat 2 Kerne und 4 logische Prozessoren (=4 Ausführungspfade). Können wir uns darauf einigen?).

Benno Hartwig schrieb:

...
Ich hatte bislang immer schön angezeigt bekommen, dass zwei aktive Threads tatsächlich zusammen annähernd die Knotenleistung bieten wie 4 aktive Threads.
Ich interpretierte dass dann: Auch bei nur 2 aktiven Threads sind beide realen Kerne voll ausgelastet.
...

Wenn mit Threads Software-Threads der engines gemeint sind, verstehe ich das Ergebnis nicht. Knotenleistung pro thread lag nach meiner Erinnerung bei meinem i3 mit HT bei etwa 60% eines - und jetzt aufgepasst - auf einem Kern, mit nur auf einem Ausführungspfad laufenden Thread. Vereinfacht sollte die Knotenleistung der mit 2 Threads auf verschiedenen Kernen laufenden engine etwa 80% der mit 4 Threads auf allen verfügbaren Pfaden laufenden Engine betragen.

Benno Hartwig schrieb:

...
Dass sie nicht ganz die Knotenleistung der 4 aktiven Threads erreichen ist zu erwarten und liegt nur daran, dass die geschickte Befehlsausführungsoptimierung, die HT ja realisiert, so nicht greifen kann.

Benno

"... geschickte Befehlsausführungsoptimierung ..."? Ein bisschen mehr ist HT schon. Im Geiste verwende ich für die Hardware das Bild einer Straße, die sich von einer auf zwei Richtungsfahrbahnen erweitert und dann wieder auf eine Richtungsfahrbahn verengt. Auf der doppelspurigen Strecke entspricht die geringere Verkehrsdichte und der bessere Verkehrsfluss dem höheren Codedurchsatz, und damit verbunden, der höheren Leistungsfähigkeit des HT-Konstrukts.

Aber nichtsdestotrotz finde ich das Thema zur Genüge erörtert. Auf meinem i3 würde ich grundsätzlich nur 2 Engine-Threads auf verschiedenen Kernen laufen lassen. Wie man das bewerkstelligt, wenn man HT nicht abschalten kann, habe ich an anderer Stelle beschrieben.
3 single-threaded laufende Engines (warum nur 3 und nicht 4? Das BS, dass dafür immer als Grund vorgeschoben wird, braucht nur selten Rechenpower!) hätten auf meinem Notebook ein in der niedrigen Knotenleistung erkennbares Handicap.

Viele Grüße
Th. Plaschke

By Benno Hartwig Date 2015-01-17 20:49 Edited 2015-01-17 20:54

> Aber möglicherweise habe ich die Frage nicht richtig verstanden ("2-Kerne-Maschine bei nur 2 aktiven logischen Kernen "?

Gemeint ist: CPU mit 2 "Kernen" und 4 "logischen Prozessoren" und nur 2 Threads, die massiv Last verursachen.
Hast du tatsächlich schon mal selbst beobachtet, dass diese Threads nicht(!) so verteilt wurden, dass sie auf den logischen Prozessoren zweier Kerne ausgeführt wurden?
Ich hatte gedacht, dass sowas schon lange nicht mehr passiert. Passiert es deiner Meinung nach wirklich immer noch auf heutigen Rechnern?

> Knotenleistung pro thread lag nach meiner Erinnerung bei meinem i3 mit HT bei etwa 60% eines - und jetzt aufgepasst - auf einem Kern, mit nur auf einem Ausführungspfad laufenden Thread.

So hatte ich es ja auch geschrieben. Bei SF knapp 60%, bei Gull etwas mehr.
In meinem Posting heute 8:25 stellte ich fest, dass 4 aktive Threads (nach meiner Einschätzung: verteilt auf die 4 logischen Prozessoren) um 15% mehr Knoten analysieren (in der Summe schneller rechnen) als nur 2 aktive Threads (für mich nur erklärlich, wenn diese tatsächlich auch auf logischen Prozessoren gefahren werden, die auf verschiedenen Kernen laufen. Oder siehst du das anders)

> Aber nichtsdestotrotz finde ich das Thema zur Genüge erörtert

Erstaunlich!
- Die Frage "Wie konfiguriere ich die Engine, damit ihr Schach möglichst stark wird?" ist sehr naheliegend für dieses Forum
- die Erwartungen der Teilnehmer sind sehr unterschiedlich, die Unklarheit ist also tatsächlich groß
- Die praktischen Ergebnisse sind nicht eindeutig. Im Moment führt bei mir die 4-Thread-Version recht knapp mit: 537,0 zu 519,0
und wie es bei anderen Engines, bei mehr Kernen und bei längeren Zeiten aussieht, wissen wir noch nicht wirklich.
Die größere Knotenleistung bei 4 Kernen und die Verluste wegen der stärkeren Parallelisierung wirken halt entgegengesetzt. Was wirkt wann mehr?

Ich denke im Gegensatz zu dir: hier ist noch Raum für einige Diskussion und auch für praktische Untersuchungen. denn wie gesagt:

"Wie konfiguriere ich die Engine auf meinem PC, damit ihr Schach möglichst stark wird?"

sollte unter Computerschachinteressierten gern geklärt werden können.

Benno

By Thomas Plaschke Date 2015-01-18 00:46

Natürlich freut es mich, wenn ein Interesse an meinen Erfahrungen besteht. Ich bin ja (auch) nur ein Laie, der sich zwar seit über 30 Jahren mit Computerhardware beschäftigt und ebenso lang dem Programmieren als Hobby frönt, aber eben kein Fachmann im Prozessorschmieden oder verwandten Berufen. Immerhin decken sich meine Erwartungen im Wesentlichen hinsichtlich des Verhaltens von Hard- und Software mit meinen Beobachtungen. Wo das nicht der Fall ist mache ich neue Erfahrungen und gucke noch mal genauer hin.

Du fragtest nach der Auslastung bzw. der Verteilung von 2 Threads. Taskmanager und Resourcenmonitor zeigen alle 4 Pfade gleichmäßig etwa zur Hälfte beschäftigt. Gesamtauslastung der CPU 50%. Offensichlich sind die Threads nicht Kernen oder Pfaden fix zugeordnet. Das kann man zwar programmieren (Stichwort: Affinität). Wird aber anscheinend nicht gemacht - warum sollte man das auch? Alle Programme und Dienste (gerade ca. 100 Prozesse und 1200 Threads) müssen sich die CPU teilen und da geht es nach Verfügbarkeit! Die beiden Threads werden also auf allen 4 Pfaden, aber immer nur auf 2 Pfaden gleichzeitig und nicht zwangsläufig zeitgleich ausgeführt. Dabei laufen sie hin und wieder auch nur auf den beiden Pfaden eines Kerns.

Nicht überzeugt? Welche Verteilung der CPU-Auslastung ist zu erwarten (bei 2 Kerne mit 4 Ausführungspfaden) mit drei Engine-Threads?
Alle 4 Pfade mit 75%? Meine Beobachtung: 3 Pfade (davon 2 zwangsläufig auf einem Kern, nicht wahr?) mit ca. 90% Auslastung und ein Pfad mit etwa 40%. Warum nicht 3 Pfade mit 100%? Oder warum nicht 4 Pfade mit 75%?

Nimmt man 3 singlethreaded Engines ist die Systemauslastung ebenfalls 75%. Aber auch bei diesem Szenario sind die 4 Pfade nicht gleichmäßig ausgelastet, sondern ähnlich wie bei der multithreaded Engine. Trotzdem ist die Knotenleistung der 3 Engines identisch. Windows sorgt also für eine den Bedingungen angepasste, gleichmäßige Leistungsverteilung. Die Lastverteilung auf die Pfade führt dabei in die Irre. Logisch wird das Ergebnis nur, wenn man unterstellt, dass Threads/Programme von Windows nicht an bestimmte Pfade gebunden werden, sondern, nachdem sie von irgendeinem anderen Thread abgelöst wurden, zu einem anderen, gerade freien Pfad wechseln.

Aus weiteren Beobachtungen ergibt sich folgendes Leistungsranking:
1 Engine mit freier Pfadwahl: höchste Knotenleistung.
2 Engines mit freier Pfadwahl eines Kerns: knapp darunter.
2 Engines ohne konkrete Pfadzuweisung: deutlich darunter.
2 Engines kreuzweise auf die Pfade der Kerne verteilt (a) Pfad 0 u. 3, (b) Pfad 1 u. 2: noch schlechter.
3 Engines auf 4 Pfaden: ca. 20% unter dem ersten.
4 Engines: nicht getestet.

Ich hatte das schon mal im letzten Jahr geschildert. Experimentiert habe ich natürlich einiges mehr. Aber alles nur mit meinem i3 und Atom (den ich nicht mehr habe). Für andere Prozessorgenerationen kann es anders aussehen. Für mich ist aber die Tendenz klar. Deswegen: Kein Hyperthreading. Auch, weil es beim nächsten Prozessor eine andere Effektivität haben kann. Außerdem hängt eine Menge von der jeweiligen Implementierung des Parallelisierungsalgorithmus ab.

Im übrigen bin ich diese Diskussionen nicht nur wegen der Wiederholungen überdrüssig, sondern auch, weil sie sehr zeitaufwändig sind. Für diesen Beitrag brauchte ich mit all dem Testen und verifizieren und formulieren über 2 Stunden. Und habe selber keine neuen Erkenntnisse gewonnen und erwarte nicht, dass sie irgendjemanden helfen.
Natürlich kannst Du vom Ergebnis her argumentieren: 537 : 519. Dann ist doch alles klar, nicht wahr?

Viele Grüße
Th. Plaschke

By Benno Hartwig Date 2015-01-18 22:14

Ja, dass die Threads nicht mehr starr den logischen Prozessoren zugeordnet sind, denke ich auch.
Gerade daher vermute ich aber, dass ein aktuelles Windows sehr schnell lastproduzierende Threads so auf die logischen Prozessoren verteilt, dass sie die Kerne möglichst gleichmäßig belasten. Wie gut ihnen das gelingt, weiß ich nicht.

Deine Ergebnisse sind schon sehr interessant, und man mag über die Hintergründe grübeln wollen.
Das ändert aber nicht an der profanen Ausgangssituation:
Ich habe einen HT-fähigen Rechner, und ich will, dass meine Engine auf ihm ein möglichst starkes Schach produziert.
Und ich habe den Thread-Parameter und überlege, welcher Wert hier ggf. optimal ist.
Ein praktischer Test ist dann wohl durchaus ein adäquater Weg für die Informationsgewinnung.
Darum mein Ansatz, den ich immer noch ganz vernünftig finde,
zu einem Thema was nach meiner Ansicht noch längst nicht geklärt ist.
(Muss ja nicht jeden interessieren.)

> Im übrigen bin ich diese Diskussionen nicht nur wegen der Wiederholungen überdrüssig...

Thanx für deine Ausführungen, aber niemand zwingt dich dazu, wenn du denn keine Lust hast.
Zumal wir doch eigentlich auch gar keine besonders konkrete Meinungsverschiedenheit haben.

Benno

By Benno Hartwig Date 2015-01-17 07:25 Edited 2015-01-17 07:53

Die Erwartungen sind also durchaus verschieden.
Stand nach der ersten Nacht (i3 2377M, 1,5HGz, 2 reale Kerne, HT, kein Pondern, 30s+0,3s):

1. SF64_15010523_4T  288.5/575 116-114-345  (L: m=21 t=0 i=0 a=93) (D: r=262 i=42 f=19 s=5 a=17)(tpm=663.7 d=20.22 nps=2083545)
2. SF64_15010523_2T  286.5/575 114-116-345  (L: m=14 t=0 i=0 a=102)(D: r=262 i=42 f=19 s=5 a=17)(tpm=664.7 d=20.07 nps=1821813)

Die Vertreter des "egal" könnten also Recht behalten. Ich lasse es aber noch weiterlaufen.
Erwartungsgemäß ist die Knotenleistung bei 4 Kernen ein wenig größer, ca. 15%.
Dafür bedingt die Nutzung von 4 Kernen vermutlich aber einen größeren Anteil an überflüssigen Analysen.
Aus meinem Bauch heraus: bei längeren Zeiten könnte der Nutzen von mehr Threads aber auch noch steigen. Ich rechne schon arg kurz

Benno

By Timo Haupt Date 2015-01-19 13:28

Hallo Benno,

Prof. Hyatt hat am 29.10.2014 im Talkchess-Forum dazu etwas geschrieben, das sich mit meinen Erfahrungen deckt (Hyperthreading-Thread bei Talkchess):

Robert Hyatt schrieb:

[...]
For chess it is a combination of two issues only.

(1) how much of the time is one thread blocked so that the other thread offers useful work to keep the processor core busy; (2) what is the cost (in chess the answer is search overhead caused by searching extra nodes since move ordering is not perfect). If you gain more with (1) than you lose with (2), it is a good idea. Otherwise it is not.

Unfortunately this is not consistent across all chess engines. If an author spends a LOT of time trying to optimize cache accesses, and tries to minimize the use of spin locks (xchg instruction and such) then hyper threading is usually a losing proposition since the two threads interfere rather than overlap when both are not blocked a lot of the time. If the engine is not highly tuned/optimized, hyper threading will generally offer enough of a gain that it might actually gain more than it loses via the search overhead issue.

I have yet to find a case where my program runs better with SMT enabled, however, nor any other program we regularly run on our cluster nodes, we therefore have this disabled in all of our machines.

Ich habe auch schon einige Tests mit HT durchgeführt und festgestellt, dass es sehr stark von der Engine abhängt, ob es sich vorteilhaft, nachteilig oder praktisch gar nicht auswirkt, wenn man die zusätzlichen Ausführungspfade einer HT-fähigen CPU nutzt. Weiterhin hängt es natürlich davon ab, ob man von 2 auf 4 Threads "erweitert" (hier ist der Speedup bei den meisten Engines immer noch recht gut), oder ob es von 4 auf 8, 6 auf 12 oder sogar von 8 auf 16 Threads geht. Mit letzterer Konfig (also 16 Threads auf einem i7-5960x) hat Hannibal im Leidener Turnier gespielt - hier hatten wir vorab längere Testreihen absolviert (time-to-depth gemessen anhand verschiedener Stellungen und Tiefen, mit diversen Wiederholungen) und festgestellt, dass sich durch Parameteranpassungen (Split-Depth) immer noch leichte Steigerungen ergeben, wenn man alle Ausführungspfade der CPU nutzt.

Für Testreihen im Singlecore-Modus würde ich hingegen nur so viele Threads verteilen wie physische Cores auf der CPU vorhanden sind - die Gefahr, dass sonst eine Engine irgendwo benachteiligt wird, sehe ich ansonsten als zu groß an. Spielt man hingegen mit nur einer Engine auf der CPU (z.B. auf playchess) und kommen somit die zusätzlichen Threads alle dieser Engine zugute, hängt es wie oben beschrieben von der Engine selbst ab, ob es sich lohnt, die HT-Ausführungspfade zu nutzen oder nicht. Hier hilft nur: Testen, bis man sich sicher ist. Eventuell kann man so tatsächlich noch ein paar Elo rauskitzeln und das ist ja oft bei Turnierteilnahmen gerade der Reiz, dass man seine Hard- und Software bis zum Machbaren tuned, um ein möglichst starkes Gesamtpaket zu haben. Meiner Erfahrung nach wird aber eine CPU, bei der alle (also auch die Hyperthreading-)Ausführungspfade genutzt werden, heißer als bei Nicht-Nutzung von HT. Insofern ist es fraglich, ob man wenn möglich die CPU lieber ein bisschen mehr übertaktet und auf HT verzichtet - das könnte eventuell vorteilhafter sein. Hängt aber auch wieder davon ab, wieviele Threads man ohnehin schon nutzen kann und wieviel Overclocking-Potenzial (zusätzlich) vorhanden ist.

Viele Grüße
Timo

By Ingo B. Date 2015-01-18 09:01

Moin,

Benno Hartwig schrieb:

...
<code>1. SF64_15010523_4T 725.5/1408 296-253-859 (L: m=41 t=0 i=0 a=212)(D: r=661 i=112 f=37 s=10 a=39)(tpm=664.7 d=20.30 nps=2069514)
2. SF64_15010523_2T 682.5/1408 253-296-859 (L: m=46 t=0 i=0 a=250)(D: r=661 i=112 f=37 s=10 a=39)(tpm=664.3 d=20.11 nps=1822174)</code>

...

<code> Program Score    % Av.Op. Elo +   - Draws
1 SF64_15010523_4T    : 725.5/1408 51.5    -5 5   11 11   61.0 %
2 SF64_15010523_2T    : 682.5/1408 48.5 5    -5   11 11   61.0 %</code>

Demnach würde man mit 4 statt 2 Threads ungefähr 5 ELO gewinnen.
...
Die Knotenleistung ist bei 4 Threads übrigens um 13,6% höher.
...

Nachdem ich obige Frage gelesen habe, und klarstellen möchte, dass es nicht um 2 oder 4 SINGLE Enginetest geht, sondern darum ob man mit 2 oder 4 Threads das stärkere Gesamtpaket bekommt, hätte ich geantwortet, dass es, bei einer modernen Intel CPU inzwischen ungefähr egal ist.
Wenn ich deine Zahlen sehe und (wie du schon schriebst) die Errorbar mal lausser acht lasse, hätte ich bei 5 Elo auch gesagt, das es egal ist (5 Elo, phhh).

Interessant ist noch deine angezeigte durchschnittliche Tiefe. 4T-SF kommt 0.19 Ply tiefer. Also fast 1/5 Ply während deine Knotenleistung nur um rund 1/7 gestiegen ist !? Das passt in der Erwartung nicht bei mir zusammen. (Und wie viel Elo sind ein Ply? Passt 0.19 zu 5 Elo? 1/5 Ply sollte auch konservativ geschätzt doch mehr als 5 Elo sein?)
... und das ganze gilt für SF, wie es bei anderen Engines aussieht ist noch eine andere Frage ...

Ansonsten kann ich nur sagen, das ich mal eine Zeitlang mit einer deutlich älteren ATOM-CPU (die da technisch schlechter war) mit 4 Threads und Shredder (der das vielleicht nicht so gut kann wie SF) auf Playchess gespielt habe und ohne jede statistische Relevanz, gefühlt in jedem zweiten Spiel kam ein sehr seltsamer Zug vor. Wenn sich also deine obige Tabelle mit den vielen Fragezeichen sehe würde ICH, um mein Bauchgefühl zu beruhigen, auf die einstellige Elosteigerung verzichten und mit 2T spielen. (Und besser für die Umwelt ist es auch noch

!)

Gruß
Ingo

By Benno Hartwig Date 2015-01-18 12:30 Edited 2015-01-18 12:41

> dass es, bei einer modernen Intel CPU inzwischen ungefähr egal ist.

Dass die CPU ihren Teil gut macht, glaube ich ja. Sie muss bei HT-Einsatz aber so viel Mehrleistung bringen, dass sie die logischen Verluste (unnötige Berechnungen) wegen der stärkeren Parallelisierung ausgleichen kann. Dass ihr das wirklich ausreichend gelingt, war mir zumindest nicht klar.

> hätte ich bei 5 Elo auch gesagt, das es egal ist (5 Elo, phhh).

Klar.
Es geht mir aber auch nicht so sehr um eine Empfehlung "Ey, spielt mal lieber mit 4 Threads!" als mehr um die Erkenntnis, wie es sich eigentlich verhält.
Und vor meinem Test war zumindest mir sehr unklar, ob nicht doch eine der beiden Varianten einen recht deutlichen Vorsprung herausspielen kann, und ich hatte sogar eher auf die 2 Threads getippt.
Benno

By Benno Hartwig Date 2015-01-18 12:55

> Interessant ist noch deine angezeigte durchschnittliche Tiefe. 4T-SF kommt 0.19 Ply tiefer. Also fast 1/5 Ply während deine Knotenleistung nur um rund 1/7 gestiegen ist !? Das passt in der Erwartung nicht bei mir zusammen.

Ich denke, das passt sogar überraschend gut zusammen.

Gehe ich davon aus, dass heute 1 Ply mehr ungefähr die doppelte Knotenzahl bedeutet, ergibt sich doch Folgendes:

log2(8/2*Knoten) = log2(8/7) + log2(Knoten) = log2(Knoten) + 1/5,2
Eine Geschwindigkeitssteigerung um Faktor 8/7 sollte also tatsächlich im Mittel ca. 1/5,2 Mehr-Plys erwarten lassen.

Ich denke, noch passender sollte man es nicht erwarten bei diesem kleinen Ansatz.
Benno

By Ingo B. Date 2015-01-18 14:35

Benno Hartwig schrieb:

Ich denke, das passt sogar überraschend gut zusammen.

(Oje, ewig nicht gemacht, jetzt mu0te ich ersteinmal wieder rausfinden wie ich den 2er Log auf dem Windowstaschenrechner tippe

)
OK, Knoten Ply passt im Rahmen der Daten halbwegs, war nur so ein morgendliches Bauchgefühlt. Was ich mit eher meinte war die konservative Annahme von 50 Elo pro Ply. Dann sollte das erste Fünftel an Plyzuwachs mehr als 20% der Elo Leistung bringen. Also 10 Elo und mehr.
Und es stimmt auch ziemlich gut. 10 Elo Abstand, passt zur 50 Elo Annahme. Indirekt hast du die 50 Elo gleich (in deinem Tiefenbereich, das flacht vielleicht irgendwann ab) "mitbewiesen"

Alles gut mit deinem Experiment!

Bleibt die Frage ob 10 Elo für die Engine die 'gerüchteweise' am besten mit HT klarkommt, für eine allgemeingültige Aussage wie "mit HT ist besser" reichen? Das muß jeder für sich entscheiden - ich fürchte die meisten halten 10 Elo für wichtig.

Gruß
Ingo

By Benno Hartwig Date 2015-01-18 17:09

> allgemeingültige Aussage...

Ne, mache ich bestimmt nicht. Eine Engine habe ich angesehen, und das auch nur bei sehr kurzen Zeiten.

Manch einer tummelt sich mit seinem Rechner z.B. im Maschinenraum oder bei Infinity. Und ich denke, da sind solche Überlegungen "Wie viele Threads" schon auch interessant, auch wenn dies nicht viele Extra-ELO bedeutet.
Und: 2 oder 4 oder 8 einzustellen, kostet halt keine Mühe und keinen Extrastrom.

Benno

By ? Date 2015-01-18 17:24

Benno Hartwig schrieb:

...
Und: 2 oder 4 oder 8 einzustellen, kostet halt keine Mühe und keinen Extrastrom.
...

Das stimmt nicht! Zumindest nicht bei einem alten i7 (Prä-Sandy, 1333 Sockel, mein letze CPU mit HT - ausser Geschäftsnotebooks). Mit 8 Threads ist das Ding DEUTLICH wärmer geworden und konnte WEIT wenige übertaktet werden als mit 4 Threads. Bei nicht kompletter Nutzung aller Threads liegen einzelne "Pipelines" (mangels besseren Wissens wie das nochmal hieß) brach. Ich sehe nicht, dass sich das Prinzip geändert haben sollte.

Gruß
Ingo

By Benno Hartwig Date 2015-01-18 21:45

Aha.
Ich habe hier gesehen (mittlerweile auch auf i7), dass 4 Threads ca 85% des nps-Wertes erreichen wie 8 Threads.
OK, maximal in diesem Verhältnis 85/100 mögen auch die Unterschiede beim Stromverbrauch und bei der Hitze liegen.

Benno

By Ingo B. Date 2015-01-19 06:50

Benno Hartwig schrieb:

Ich meine mich zu erinnern:

Mein 1366-i7 lief offiziel auf 2.66 Ghz. Mit HT kam ich maximal auf 3.2 oder 3.4 GHz, ohne HT auf glatte 4GHz (das weiß ich noch). Wenn dein obiges Verhältniss stimmen würde (was ich für den alten Sockel nicht mehr weiß) hätte ich den Knotenverlust ungefähr ausgeglichen und die Probleme alle umschifft.
Das das bei Notebooks nicht geht und wir den Stromverbrauch (aua) dann mal aussen vor lassen ist klar.

Gruß
Ingo

By Ernest Bonnem Date 2015-01-18 22:00

Benno Hartwig schrieb:

Demnach würde man mit 4 statt 2 Threads ungefähr 5 ELO gewinnen.
Du meinst (5 ± 11) ELO, wenn ich Dich richtig lese...

By Benno Hartwig Date 2015-01-19 06:47

Ich meine den Schätzwert +5 ELO.

Die +-11 für die 95%-Wahrscheinlichkeit bedeuten übrigens auch:
mit ca. 65% liegt die echte Differenz im Bereich +0 ELO bis + 10 ELO.
Und damit ist die Wahrscheinlichkeit für eine (sehr kleine oder auch etwas größere) Steigerung immerhin (65+35/2)% = 82,5%.
So was in etwa meinte ich dabei auch mit.

Benno

By Benno Hartwig Date 2015-01-19 10:09

> Ich habe den Test jetzt noch mal mit 60sec+0,6sec (also doppelte Zeit) gestartet.

Hier führt die 4-Thread-Variante im Moment immerhin mit 286,0 zu 247,0 (das wären +13 ELO bei +-18).
Ich lasse mal weiterlaufen...
Benno

By Ingo B. Date 2015-01-19 10:25

Benno Hartwig schrieb:

Hier führt die 4-Thread-Variante im Moment immerhin mit 286,0 zu 247,0 (das wären +13 ELO bei +-18).
Ich lasse mal weiterlaufen...
Benno

Da geht mir noch ein anderer Schwachpunkt deines Test auf (der vielleicht schon erwähnt wurde, sorry): Selbsttest! Ob das mit der Tatsache übereinstimmt das man doch eher gegen andere spielt? Einen Test von 4 und 2 Threads z.B. gegen K8 wäre zwar aufwändiger aber interessanter. Mann könnte das sogar als Kreuztabelle realisieren mit K8 bei 2 und 4 Threads ...

Ansonsten, solltest du jetzt 13 Elo erhalten bin ich auf die weiteren Daten, wie Knoten, Tiefe ... gespannt.

Gruß
Ingo

By Benno Hartwig Date 2015-01-19 12:43 Edited 2015-01-19 13:00

Natürlich hast du recht. Bloß beim Selbsttest bekommt man halt am schnellsten einen Vergleich hin.
Der Selbsttest liefert dir eine "Genauigkeit", die du bei einem Gountlet erst mit der 4-fachen(?) Partienzahl hinbekommst.
Dafür liefert dein Vorschlag aber eben auch Aussagen zu Komodo und Stockfish.

Im Moment (ein wenig länger soll es aber schon noch laufen) sieht es so aus bei 60s+0,6s:

LittleBlitzer:

1. SF64_15010523_4T  315.5/582  134-85-363 (L: m=11 t=0 i=0 a=74) (D: r=289 i=47 f=13 s=3 a=11)(tpm=1321.8 d=22.29 nps=2183389)
2. SF64_15010523_2T  266.5/582  85-134-363 (L: m=12 t=0 i=0 a=122)(D: r=289 i=47 f=13 s=3 a=11)(tpm=1321.7 d=21.95 nps=1853476)

ELOstat:

  Program               Score     %    Av.Op.  Elo    +   -    Draws
1 SF64_15010523_4T : 315.5/582  54.2    -15     15   17  17   62.4 %
2 SF64_15010523_2T : 266.5/582  45.8     15    -15   17  17   62.4 %

Die 4-Thread-Version hat die Quote also sogar noch etwas verbessern können.
Benno

By Benno Hartwig Date 2015-01-20 11:19

1000 Partien wollte ich gern erreichen. Und so steht es jetzt:

LittleBlitzer:

1. SF64_15010523_4T  535.0/1005  214-149-642 (L: m=15 t=0 i=0 a=134)(D: r=509 i=81 f=27 s=3 a=22)(tpm=1320.5 d=22.52 nps=2178499)
2. SF64_15010523_2T  470.0/1005  149-214-642 (L: m=26 t=0 i=0 a=188)(D: r=509 i=81 f=27 s=3 a=22)(tpm=1320.2 d=22.18 nps=1853891)

Elostat:

    Program              Score     %    Av.Op.  Elo    +   -    Draws
1 SF64_15010523_4T : 535.0/1005  53.2    -11     11   13  13   63.9 %
2 SF64_15010523_2T : 470.0/1005  46.8     11    -11   13  13   63.9 %

Dass der ELO-Vorsprung wieder von 15 auf 11 schrumpfte, lässt ahnen, wie wackelig solch eine Schätzung nach 1000 Partien noch ist.
Trotzdem neige ich dazu, den Thread-Wert auf die Anzahl der logischen Prozessoren zu setzen, wenn die Spielstärke maximal sein soll.
Es kostet halt nichts, und wahrscheinlich kommen dadurch eben doch wenigsten ein paar einzelne ELO hinzu.

Benno

By 2phil4u Date 2015-01-20 20:17

Ich denke, dass viel daran liegt, wie gut das Hyperthreading ist.
AMD hat ja z.B. Module, die mehr davon profitieren dürften.
Ausserdem kann ich mir vorstellen, dass viel auch mit Speicherlatenzen zusammenhängt und zu guter Letzt spielt natürlich die Programmierung eine riesige Rolle.
Ich denke kaum, dass auch nur eine engine speziell auf HT optimiert ist, viel Geld steckt ja nicht gerade in den Schachprogrammen, umso erstaunlicher die starken Leistungszuwächse.
Es gibt afaik keinen einzigen wirklichen Großcomputer, der genutzt wird, das war noch anders, als das Duell Mensch gegen Maschine noch nicht entschieden war.
Schach ist sowieso ein bischen out habe ich den Eindruck, gibt kaum wissenschaftliches Interesse an dem Spiel, kein Kapital fliesst, wäre das der Fall hätten wir schon längst Schachcluster.
Die Spitzenspieler haben ja auch Schwierigkeiten noch wirklich hohe Siegprämien zu bekommen, weil das Spiel einfach kaum öffentliches Interesse hat, das war sicher mal anders.

By Benno Hartwig Date 2015-01-20 20:46

> ...weil das Spiel einfach kaum öffentliches Interesse hat, das war sicher mal anders.

Damit hat du wohl Recht.
Und auch der Respekt vor der Leistung der Elite ist sicher oft durch die Allgegenwart der Engines weniger geworden.
Und mancher Ärger wirkt dann durchaus verständlich
(siehe auch http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?tid=8127)

Benno

By Ingo B. Date 2015-01-21 09:10

Benno Hartwig schrieb:

Und auch der Respekt vor der Leistung der Elite ist sicher oft durch die Allgegenwart der Engines weniger geworden.
Und mancher Ärger wirkt dann durchaus verständlich
(siehe auch <a class='urs' href='http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?tid=8127'>http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?tid=8127</a>)

Na ja, ob der Ärger auf eine neue Technik so verständlich ist? Würde er sich auch über den Buchdruck ärgern weil jetzt jeder Hinz und Kunz sich Eröffnungen aneingen kann? So ist der Lauf der Dinge ...

Gruß
Ingo

By Benno Hartwig Date 2015-01-21 11:14

Engines ermöglichen und ermutigen Schnackern und Nichtskönnern, sich überheblich gegenüber GMs aufzuspielen.
Das war nach der Erfindung der Buchdrucks wohl nur bedingt möglich.

Es ist der Lauf der Dinge, aber es laufen eben auch nicht alle Dinge schön.

Benno

By Ludwig Buergin Date 2015-01-21 12:19

Hallo Benno u. Ingo

Es gibt den alten spruch: wer nicht mit der zeit geht,der geht mit der zeit.

Gruß Ludwig

Computerschächer

By Benno Hartwig Date 2015-01-21 13:02

> Es gibt den alten spruch: wer nicht mit der zeit geht,der geht mit der zeit.

Gestern hat's geregnet, heute scheint die Sonne - das sind Umstellungen, die muss man erst mal verkraften. (Jürgen Kohler)
Benno

By Thomas Plaschke Date 2015-01-21 19:29

Ich will das Thema auf keinen Fall noch mal aufkochen,

aber nach meinen Erfahrungen sind die 2T-Engines bei diesem Test klar benachteiligt worden, indem ihre Threads nicht explizit verschiedenen Kernen zugewiesen wurden

. Dann wäre auf meinem i3 eine ca. 15% höhere Rechengeschwindigkeit für die T2-Versionen zu erwarten (Siehe unter http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?pid=82975#pid82975 die Messwerte zu den Punkten 1 und 2.).

Viele Grüße
Th. Plaschke

By Benno Hartwig Date 2015-01-22 06:58

> Ich will das Thema auf keinen Fall noch mal aufkochen,

Warum nicht, ist dieser eine Thread denn so schlimm?

Nimm meine Frage Stellung doch so naiv, wie ich sie stellte:
Da hat jemand seinen HT-fähigen Prozessor, will die Engine drauf laufen lassen und fragt nach der besten Thread-Einstellung.
Ob Windows damit gut oder weniger gut umgeht ist wohl interessant.
Die Frage nach einem derart naiv eingestellten optimalen Thread-Wert bleibt ja trotzdem interessant (finde zumindest ich).

Dass sich mit etwas Knowhow und gezielter, manueller Zuweisung bestimmter logischer Prozessoren eventuell mehr erreichen lassen könnte, will ich ja gar nicht abstreiten.
Ich muss mir dein Posting vom 29.7. noch mal genauer ansehen.
Auch mit Blick darauf, was das praktisch bedeutet.

Benno

By Thomas Plaschke Date 2015-01-22 20:00

Als Mann laufe ich ja angeblich ohnehin nur als single-task-fähig herum.

Was kümmert mich da ein anderer Thread? So frustriert bin ich ja nicht, dass ich nicht noch an der Diskussion Anteil nehmen möchte.

Ich will noch bemerken, dass Du gar keine Chance hast, den Test für die 2T-Teilnehmer fair(er) zu machen. Dafür zu sorgen, dass die 2T-Programme ihre Threads optimal auf den beiden cores ausführen können, ließe sich von fähigen Entwicklern oder Programmierer vielleicht noch bewerkstelligen. Aber was soll man mit closed-source-software machen. Komodo, Houdini und Co. kannst Du nicht helfen.

Also kannst Du Dir bestenfalls mit einer Abschätzung behelfen, indem Du die 15% Leistungsnachteil in Elo umrechnest. Das dürfte den aktuellen Abstand noch nicht ganz aufheben.

Wie dem auch sei: Aus Deinem Test kann man für diese Testbedingungen jedenfalls keinen Nachteil für HT ableiten.

Viele Grüße
Th. Plaschke

By Benno Hartwig Date 2015-01-23 10:19 Edited 2015-01-23 10:36

Mit meinem Test geht es auch nicht um Vorteile oder Nachteile des HT an sich.
Es ging, wie ich bereits im ersten Posting schrieb, um:

"Wie sollte man auf einer hyperthreadfähigen Maschine mit 2 realen Kernen (einem i3)
eine Engine einsetzen, wenn man maximale Spielstärke erreichen will?"

Mein kleines SF-K-Turnier zeigt jetzt übrigens:

Elostat:

  Program                Score     %    Av.Op.  Elo    +   -    Draws
1 SF64_15011815_4T : 748.5/1237  60.5   2981   3056   14  14   47.5 %
2 SF64_15011815_2T : 692.0/1238  55.9   2990   3031   14  14   45.9 %
3 Komodo8_4T       : 530.0/1233  43.0   3012   2963   14  14   46.2 %
4 Komodo8_2T       : 500.5/1234  40.6   3017   2950   14  14   45.6 %

Littleblitzer: (musste ich zwischendurch mal neu starten, darum etwas kleinere Partienanzahl)

1. SF64_15011815_2T  682.5/1222  403-260-559 (L: m=70 t=0 i=0 a=190) (D: r=333 i=113 f=38 s=8 a=67)(tpm=642.8 d=21.07 nps=1849611)
2. SF64_15011815_4T  738.0/1220  448-192-580 (L: m=66 t=0 i=0 a=126) (D: r=346 i=112 f=56 s=7 a=59)(tpm=642.9 d=21.16 nps=2095752)
3. Komodo8_2T        496.5/1219  217-443-559 (L: m=294 t=0 i=0 a=149)(D: r=254 i=176 f=57 s=9 a=63)(tpm=634.9 d=15.55 nps=1898202)
4. Komodo8_4T        523.0/1219  240-413-566 (L: m=251 t=0 i=0 a=162)(D: r=255 i=177 f=53 s=10 a=71)(tpm=632.9 d=15.20 nps=2526137)

Ich habe daher den Eindruck, wenn man mit aktiviertem HT arbeitet, und zumindest wenn man nicht gezielt mit der Prozessorzuweisung hantiert, dann ist es sinnvoll, für "Threads" wirklich die Anzahl der logischen Prozessoren zu konfigurieren. Die Unterschiede sind natürlich nicht groß, aber auch für 25 oder auch 13 Mehr-ELO müsste ein Programmierer schon einige Mühe investieren, denke ich.
(Es wäre natürlich interessant zu sehen, ob sich dies auf einem i7 mit 8 logischen Prozessoren so bestätigen lässt.)

Benno

PS:
Und ob sich der unerwartet deutliche Unterschied beim nps-Wert bei Komodo im einfachen Betrieb unter Arena irgendwie bestätigen lässte, will ich mir nun auch noch mal ansehen.

2 Threads	3	21%
egal (die Spielstärke ist ungefähr gleich groß)	3	21%
4 Threads	8	57%