Threads-Test

By Thomas Müller Date 2014-03-17 20:59

Hi Andreas,

wie geil ist das denn !!!

Hast du selbst diese Kiste?
Den opteron wollte ich mir nächste jahr vielleicht auch gönnen je nachdem was bis dahin neu auf dem markt ist?!
Danke für die testerei....muss ich nachher noch detaillierter anschauen!

gruß
thomas

By Andreas Strangmüller Date 2014-03-17 21:48

Hallo Thomas,

ja, die Kiste ist mein.
Wollte mir schon lange den Traum eines Rechners mit möglichst vielen Kernen erfüllen. Nun war er bezahlbar.
Hauptsächlich zum Experimentieren, Ranglisten erstellen, Engine-Matches durchführen, etc.

Außer den neuen AMD "Warsaw" hab ich keine Neuigkeiten zu den Server-Prozessoren gefunden.
Diese bassieren aber nach wie vor auf Sockel G34, SR5690 Chipsatz. Also kein USB 3.0, PCI Express 3.0 oder SATA 6Gb/s.

Viele Grüße,
Andreas

By Thomas Müller Date 2014-03-17 22:21

das passt.....gratuliere dazu und viel spaß damit

Mal sehen was es bei nächstes jahr wird ?!

By Joachim Rang Date 2014-03-17 21:02

Sehr spannend!
Und was sagt uns das?
a) die Effizienz nimmt mit zunehmenden Kernen ab
b) Geschwindigkeitsvorteile nehmen mit zunehmender Bedenkzeit ab

Sonst noch was?

By ? Date 2014-03-17 21:11

Joachim Rang schrieb:

Sehr spannend!
Und was sagt uns das?
a) die Effizienz nimmt mit zunehmenden Kernen ab
b) Geschwindigkeitsvorteile nehmen mit zunehmender Bedenkzeit ab

Sonst noch was?

Ja, die elend lange Bedenkzeit bei TCEC ist "für die Katz", insbesondere mit so vielen Kernen. Von 4 auf 8 kommt kaum noch was rum (~20 Elo), was soll denn von 8 auf 16 noch passieren?
Natürlich kann eine andere Enigne da etwas besser oder schlechter sein, Welten werden nicht mehr bewegt. Besser (und natürlicher) wäre es bei TCEC 2 x 8 Kerne mit Ponder ON spielen zu lassen. (Da würde aber die ein oder andere Engine noch Probleme machen

)

Gruß
Ingo

By Benno Hartwig Date 2014-04-03 09:54

Das TCEC-Turnier ist aber eben eines, bei dem die kritische Frage "Hey, aber wie wäre es bei mehr Ressourcen?" nicht mehr kommt.
Das finde ich dann doch wieder sehr schön. Ein Event, bei dem jeder wohl anerkennt, dass die Zeiten lang und die Ressourcen reichlich sind.

BTW: was bringt denn der eine Prozessor noch etwas schneller ist als der andere?
Was bringt denn für das Computerschach noch etwas mehr Speicheraufrüstung? jeweils wenige ELO wohl nur.
Und trotzdem wird es Spaß an der Freude gemacht. Oder es wird einfach genutzt, weil die Kiste unter dem Schreibtisch ja eh halt so mächtig ist.

Deinen Vorschlag mit Ponder on, finde ich aber auch gut.
Aber welche Probleme erwartest denn da "bei der einen oder anderen Engine"?
Ponder-on-Turniere könnten helfen, die Entwickler zu motivieren, sich hier schlaue Gedanken zu machen.
Und für das Ziel "ein Computersystem als ein möglichst guter Schachspieler" wäre eben auch ein effizientes Pondern notwendig.

Benno

By Ingo B. Date 2014-04-03 12:52

Oh je, zwei Wochen nach dem schreiben noch ein Komentar ...

Benno Hartwig schrieb:

Das mit dem "... wie wäre es mit mehr Ressourcen?" ist ja durchaus berechtigt. Die Art wie sie hier eingesetzt werden ist aber verschwendet bzw, die meisten, die es nicht besser wissen bleiben im Glauben das 16 Kerne POFF der "heilige Gral" wären (oder so was ähnliches).

Benno Hartwig schrieb:

BTW: was bringt denn der eine Prozessor noch etwas schneller ist als der andere?

En ELo? Fast nichts. Habe ich vor Jahren schon vorgerechnet - interessiert nur keinen. Die Leute wollen Geld ausgeben weil sie meinen der neue Haswell wäre besser als der Ivy ... "Rubbish".

Benno Hartwig schrieb:

Was bringt denn für das Computerschach noch etwas mehr Speicheraufrüstung? jeweils wenige ELO wohl nur.

Na das wäre noch interessanter. Bei "schneller" hat man immerhin so einen Korridor von 50-70 Elo je Verdopplung, bei doppeltem Hash habe ich Zweifel das man das irgendwie sinvoll in Elo ausdrücken kann (immer vorrausgesetzt ist habe einen vernünftigen Grundwert). Ich jedenfalls kenne keine belastbaren Zahlen zw. 32,64,128 ... 4069, 8192 ... MB mit denen man etwas anfagen könnte. Bei einem WM Turnier mit 120+0 wird es auch wenig asumachen ob man mit 2GB, 4GB oder 8GB spielt. Man nimmt halt viel weil es im Zweifel nicht schadet. (Noch lächerlicher ist es für Schach die superteuren schellen Riegel zu kaufen. Die warten sowieso meistens darauf das das PRogramm etwas neues in den Hash einträgt ...)

Benno Hartwig schrieb:

Und trotzdem wird es Spaß an der Freude gemacht. Oder es wird einfach genutzt, weil die Kiste unter dem Schreibtisch ja eh halt so mächtig ist.

Der letzte Teil ja, der erste macht aber nur FReude so lange man es nciht besser weiß ...

Benno Hartwig schrieb:

Deinen Vorschlag mit Ponder on, finde ich aber auch gut.

Da würden die erwähnten Ressourcen beim Sprung von 8 auf 16 definitiv besser genutzt.

Benno Hartwig schrieb:

Aber welche Probleme erwartest denn da "bei der einen oder anderen Engine"?

Es ist ein zusätzliches Feature das zusätzlich zum "viele Kerne" Problem auch zuverlässig laufen muß. Konkret kenne ich ein paar Engines die nach längerem Pondern ihren Ponder Hit (oder eben Miss) bekommen und dann stur weiter pondern ... bis die Zeit um ist - meistens geht es ja gut "aber ab und zu". Völlig mieses Zeitmanagement weil der PRogrammierer sich keine Gedanken über die gewonnen Zeit bei einem PTreffer gemacht hat ...

Kurz: Ich lasse mir 2 Kerne noch gefallen, auch 4 sind gerade noch OK, danach würde ich lieber PON oder mehrere Spiele gleichzeitig laufen lassen wenn man die zur Verfügung stehenden Mittel optimal nutzen will.

Gruß
Ingo

By Patrick Götz Date 2014-03-18 01:14

Joachim Rang schrieb:

Sehr spannend!
Und was sagt uns das?
a) die Effizienz nimmt mit zunehmenden Kernen ab
b) Geschwindigkeitsvorteile nehmen mit zunehmender Bedenkzeit ab

Die Feststellungen a) und b) ohne konkrete Zahlen sind genauso langweilig, wie die Feststellung dass jemand mit 10 Jahren Schach Erfahrung besser spielt als jemand mit 10 Tagen Erfahrung.
Interessant wird es wenn man konkrete Zahlen hat, so wie sie durch diesem Test in bisher unbekannter Güte vorliegen.
Beispielsweise hatte bisher keiner eine Vorstellung davon, wie drastisch der Zugewinn von 4 auf 8 Kernen abfällt.

Gruß
Patrick

By Joachim Rang Date 2014-03-18 08:41 Edited 2014-03-18 08:44

Mein Post war nicht sarkastisch gemeint. Er klingt vielleicht so, aber das sehr spannend war nicht ironisch gemeint.

Schlussfolgerung b) ist z.B meines Erachtens nicht belegt - es könnte auch einfach sein, dass Spielstärkeunterschiede mit höherer Bedenkzeit weniger stark sichtbar werden.

By Andreas Strangmüller Date 2014-03-17 22:02

Beabsichtigt sind aktuell noch folgende Tests:

2 gegen 4 Threads und 4 gegen 8 Threads

Evtl. noch ein Test mit 960+0.05 Sekunden.
Mal sehen, ob ich die Geduld dafür aufbringe.

By Patrick Götz Date 2014-03-18 01:24

Andreas Strangmüller schrieb:

2 gegen 4 Threads und 4 gegen 8 Threads

Ja, die beiden Begegnungen würden den Test auf schöner Weise abrunden.
Besonders den 4 gegen 8 Threads würde ich sehr spannend finden.
Wenn 4 gegen 8 Threads läuft sind noch 20 Kerne frei, da würde noch ziemlich gut (gleichzeitig) ein 1 (oder 2) gegen 16 Threads Test rein passen, den ich extrem spannend finden würde, denn vergleichbares Material existiert meines Wissens noch nicht auf diesen Planeten.

Grüße
Patrick

By Andreas Strangmüller Date 2014-04-02 20:14

Ergänzend die Ergebnisse des Vergleichs 2 gegen 4 und 4 gegen 8 Threads.

Detaillierte Informationen zu diesem Test stehen in folgendem PDF-Dokument:
http://www.fastgm.de/schach/Threads-Test-2-4-8.pdf

Die PDF als Grafik:

By Andreas Strangmüller Date 2014-04-04 23:55

Hier noch die aktuellen Ergebnisse der Threads-Verdoppelung als Graph:

By Patrick Götz Date 2014-03-18 01:07

Lieber Andreas,

diese Statistik ist ein echter Leckerbissen. Danke!

Gruß
Patrick

By Frank Quisinsky Date 2014-03-18 03:38

Hallo Andreas,

Glückwunsch zur Power-Maschine

Machst echt richtig gute Sachen, darüber freuen sich hier ganz bestimmt sehr viele Leser.

Erinnere mich noch an das Review für Gambit-Soft zu Deep Fritz (erste Deep Fritz Version). Da ging es auch darum wie die Steigerungen bei mehreren Cores waren. Seinerzeit war der eine oder andere froh dann mal ein System mit zwei echten Prozessoren zu haben. Glaube es war Mathias Feist der mir die Info sendete ... schon mehr als 16 Jahre her.

x 1.7 - 1.8 bei 2 Cores
x 3.2 bei 4 Cores
x 5.1 war es glaube ich bei 8 Cores

Rechnen wir das hoch kann der Vorteil bei 8 Cores nur gering ausfallen. Von 4 auf 8 ist ja keine Verdoppelung der Geschwindigkeit, sondern nur eine Verdoppelung der Cores und die 20 Elo mehr sind sehr realistisch aber irgendwie auch logisch.

Das bei Verdoppelung der Bedenkzeit der Zuwachs von ca. 70 Elo (das vermuteten wir in den Diskussionen vor ca. 15 Jahren) mit immer schnellerer Hardware abnimmt war immer umstritten. Es kommt hier auch ein wenig auf die Engine selbst an. Es gibt Engines bei denen sich deutlich weniger regt bei tieferen Analysen als bei anderen. Meist finden diese Engines sehr schnell einen guten Zug und übersehen viel bei tieferen Analysen, weil einfach zu viel weggeschnitten wurde.

Finde wir können generell nicht sagen, dass die Spielstärke bei Verdoppelung der Bedenkzeit weniger bringt. Das kann nicht korrekt sein, vielmehr kommt es hier wirklich auf die Programmierung an. Ein Junior der mit mehr Zeit immer mehr aufdreht und eine sehr gute Suche hat wird mit mehr Zeit deutlicher profitieren als eine Engine die sehr schnell eine gute Variante findet und an dieser krampfhaft festhält.

Für Analysen können viele Cores sehr hilfreich sein aber ich denke nach wie vor nur um vorher ausgewählte Züge dann mal über Nacht zu analysieren. Ich halte wenn überhaupt maximal eine 4-Core Analyse für sinnvoll. War es doch der Chef der derzeit schnellen Android Handy Prozessoren der sagte, was sollen denn mehr als 4 Cores überhaupt noch bringen. So ganz Unrecht hat er nicht mit der Aussage.

Aber die Maschine ist bestimmt richtig gut, habe mir den Prozessor letzte Woche auch im Detail ansehen können.
Damit hast Du ausgezeichnete Testmöglichkeiten, überlege schon wie ich testen würde wenn ich das Teil hätte.

Wahrscheinlich weiter mit einem Core und höheren Bedenkzeiten aber mehr Partien gleichzeitig. Aber ich würde mich auch dazu verleiten lassen 4-Core - 4 Core bei Ponder = on spielen zu lassen und das dann 2x gleichzeitig. Keine Ahnung ...

Wünsche Dir viel Spaß damit und hoffe auf weitere schöne Beiträge von Dir!

Viele Grüße
Frank

By Stefan Pohl Date 2014-03-18 12:03

Alles so, wie ich es auch erwartet hätte, wenn ich vorher hätte einen Tipp abgeben müssen.
Aber einmal richtig durchtesten, noch dazu mit so vielen Partien, ist besser als zehn mal aufgrund logischer Überlegungen etwas zu erwarten...

In diesem Sinne: Sehr, sehr toll gemacht!!!

Stefan

By Robert Bauer Date 2014-04-04 09:01

Hallo Andreas,

ich würde gerne deine Maschine einschätzen können im Vergleich zu anderen AMD oder INTEL.
Findest Du dazu Benchmark-Ergebnisse oder kannst Du z.B. "Passmark" selber laufen lassen? Ich wäre auch sehr daran interessiert, was der gute alte Fritzmark sagt.
Natürlich ist letztendlich die ELO das Maß aller Dinge. Aber ein Benchmark bei 1,2,4,8.. Cores zeigt die direktere Abhängigkeit in der Geschwindigkeit, während bei ELO diverse Faktoren (Engine-Multicore-Ausnutzung, Speicherausnutzung, CPU-Architektur,...) bis hin zur ELO-Berechnung selbst eine Rolle spielen.
Mach bitte einen Benchmark über 1,2,4,8,16...CPUs mit "Passmark" und Fritzmark. (Ich weiß nicht ob das technisch möglich ist, aber es wäre wirklich super. Ich glaube man kann ein Programm "irgendwie" einstellen auf die Ausnutzung von N Cores.)

Wäre deine Statistik nicht auf 16 Cores oder gar 24 Cores (gegen 1) erweiterbar?

Viele Grüße,
Robert

By Andreas Strangmüller Date 2014-04-05 00:34

Hallo Robert,

der Test 1 gegen 16 Cores läuft aktuell schon einige Zeit und dauert etwa noch 5 Tage.

Wenn Du eine hohe Schachperformance meines Rechners erwartest wirst Du sicherlich enttäuscht sein.
Meine Erfahrungen und Messungen bestätigen, dass es aktuell ab 8 Cores keine große Steigerung mehr gibt.
Von 4 auf 8 Cores sind es um die 20 Elo, von 8 auf 16 tippe ich nur noch auf ~ 10 Elo. Die Effektivität der Parallelisierung stößt hier aktuell an seine Grenzen.
Evtl. führe ich den Test 8-16 Cores noch mit der längeren Bedenkzeit 240+0.05 Sek. durch. Dauert allerdings auch fast 10 Tage bei 3000 Partien.

6-12 Kerne bei hohen Taktraten bieten m. E. derzeit die optimale Schachperformance.

Mein Rechner ist eher dafür geeignet mehrere Engines mit vier oder acht Cores an einer oder verschiedenen Stellungen gleichzeitig rechnen zu lassen.
Ebenso der Einsatz als Test-/Ranglistenrechner um viele Partien mit 1 oder 2 Cores absolvieren zu können.

Der Fritzmark kann aktuell nur bis 8 Cores, die Werte zu 1, 2, 4 und 8 kann ich aber gerne hier posten. Passmark hab ich noch nie probiert, schaue ich mir mal an.

Viele Grüße,
Andreas

By Robert Bauer Date 2014-04-07 12:56

Hallo Andreas,

herzlichen Dank für deine Antwort.

Dann bin ich mal gespannt auf deine weiteren Ergebnisse...

Viele Grüße,
Robert

By Andreas Strangmüller Date 2014-04-10 18:49

Hallo Robert,

anbei die Ergebnisse des Tests 1 gegen 16 Cores.

Bei kurzen Bedenkzeiten wirken sich die 16 Cores sogar negativ aus. Erst bei 240+0.05 gibt es eine Steigerung (immerhin + 17 Elo) im Vergleich zu 8 Cores.
Viele Cores brauchen scheinbar mehr Zeit um in Schwung zu kommen.

Hier die Ergebnisse des Fritzmarks (kann bis 16 Cores):

   1 =  2,78 /  1336
   2 =  5,48 /  2628
   4 = 10,83 /  5198
   8 = 18,44 /  8850
  16 = 22,77 / 10931

und von Passmark:

  Integer Test     CPU-Mark
 
   1 =  1724       1 =   980
   2 =  3447       2 =  1886
   4 =  6894       4 =  3496
   8 = 13791       8 =  6086
  16 = 27591      16 =  9040
  32 = 54799      32 = 10226

Viele Grüße,
Andreas

By Tom Paul Date 2014-04-11 05:43

Deshalb wäre ein TCEC mit 60 + 15 Bedenkzeit und ein Vielfaches mehr an Partien wesentlich interessanter.

By Thomas Plaschke Date 2014-04-07 14:14

Das ist ja ein sehr ernüchterndes Ergebnis.

Lässt sich auch sagen, welche Parallelisierungsalgorithmen (relativ) besser performen (Einen Überblick gibt es unter http://chessprogramming.wikispaces.com/Parallel+Search)?
Insbesondere von Programmen, die den DTS-Algorithmus verwenden müsste man etwas erwarten können. Zu denen gehören Crafty und von Zappa meine ich es in einem Forum gelesen zu haben.
Für andere Parallel-Algorithmen scheinen mehr threads zum Handicap werden zu können. So würde ich bspw. die niedrige Knotenleistung von Toga und einigen anderen Engines beim TCEC interpretieren (algorithmusbedingt viele memory locks?) und eine negative Auswirkung auf die Spielstärke als Folge davon.
- Aber welcher Entwickler hat schon einen Rechner mit zweistelliger Core-Anzahl?

Lässt sich also aus den Einzelergebnissen etwas zur Effizienz der Parallelisierungsalgorithmen ablesen?

Viele Grüße
Th. Plaschke

By Jörg Oster Date 2014-04-07 14:55

Thomas Plaschke schrieb:

Das ist ja ein sehr ernüchterndes Ergebnis.

Lässt sich auch sagen, welche Parallelisierungsalgorithmen (relativ) besser performen (Einen Überblick gibt es unter <a class='urs' href='http://chessprogramming.wikispaces.com/Parallel+Search'>http://chessprogramming.wikispaces.com/Parallel+Search</a>)?
Insbesondere von Programmen, die den DTS-Algorithmus verwenden müsste man etwas erwarten können. Zu denen gehören Crafty und von Zappa meine ich es in einem Forum gelesen zu haben.

Hallo Thomas,

wie kommst du darauf?
Crafty verwendet auch YBWC. Hier der passende Comment aus Crafty's search.c:

Code:

/*
 ************************************************************
 *                                                          *
 *   If this is an SMP search, and we have idle processors, *
 *   now is the time to get them involved.  We have now     *
 *   satisfied the "young brothers wait" condition since we *
 *   have searched one move.  All that is left is to check  *
 *   the size of the tree we have searched so far, so that  *
 *   we do not split too near the tips and drive up the     *
 *   overhead unacceptably.  This has the additional effect *
 *   that we might split after 2-3 moves have been searched *
 *   which might sound like an issue, but the overhead is   *
 *   not so critical if we are more certain that we need to *
 *   actually search every move.  The more moves we have    *
 *   searched, the greater the probability that we are      *
 *   going to search them all.                              *
 *                                                          *
 ************************************************************
 */

Zu Zappa kann ich nichts sagen.

Gruß, Jörg.

By Thomas Plaschke Date 2014-04-07 16:50

Ich fürchte, ich habe aus diesem Aufsatz http://www.cis.uab.edu/hyatt/search.html geschlossen, dass er DTS nicht nur mit Cray Blitz getestet hatte, sondern auch in Crafty implementiert haben würde. Trugschluss meinerseits.

Aber auf ZCT bin ich gestoßen. Zach Wegner erklärt (2008) mit ZCT die einzige open-source-Implementation von DTS gemacht zu haben. Siehe: http://zct.sourceforge.net/.
Gian-Carlo Pascutto hat es in (späten) Deep Sjeng Versionen eingesetzt. Hier erwähnt: https://chessprogramming.wikispaces.com/deep+sjeng.

Infos zur Parallelsuche von Zappa habe ich nicht finden können.

Gruß und tschüss
Th. Plaschke

By Thomas Plaschke Date 2014-04-07 18:33

Statt Edit:

Jetzt habe ich's gefunden.
In der Readme zu ZCT hat Zach Wegner die ihm bekannten Implementationen von DTS aufgezählt: https://github.com/zwegner/zct/blob/master/README.txt (Abschnitt 'CODE').

Viele Grüße
Th. Plaschke

By Jörg Oster Date 2014-04-07 20:12

Sehr interessant. Danke!

By Frank Brenner Date 2014-04-07 19:13

Hallo Andreas,

ich finde es gut was du für Experimente durchführst.

Bevor man jedoch Rückschlüsse aus deinen Ergebnissen zieht müssten eigentlich folgende Punkte noch geklärt werden.

1. Besitzt die CPU dynamisches Takten ?
Es gibt CPUS die Takten einen Core deutlich höher wenn im wesentlichen nur ein Core benutzt wird, bei 2 Cores wird die Frequenz ebenfalls erhöht aber nicht so stark usw...
Hier kann es durchaus ein großes Spektrum von 2,3 - 3,6 GHZ geben.
Fürs Schach wäre es natürlich nur aussagekräftig wenn zb bei 2 vs 8 Cores alle Cores mit der gleichen Frequenz betrieben werden.

2. Qualität der Multicorearchitektur.

Hier kannst du einmal einen einfachen tests machen, der muss deterministisch sein, also zb stockfish einmal im singlecore betrieb in der console starten und zb eine bestimmte Tiefe durchrechnen lassen und die Zeit dann stoppen.
Das ganze kannst du 16 mal machen, einmal mit einem Stockfish, dann mit zwei, dann mit drei usw....
Idealerweise Rechnet ein einziger Stockfish (100 % CPU last auf einen Core) genauso schnell wie ein einzelner Stockfish wenn 16 Stück davon simultan laufen ...

Ohne dass diese beiden Fragen beantwortet sind, sind deine Ergebnisse alle nur schwebend ....

Wie schauts eigentlich mit Permanent Brain aus, ist das ausgeschaltet ?

Grüße
Frank

By Andreas Strangmüller Date 2014-04-08 18:48

Hallo Frank,

danke für Dein Interesse und Deine interessanten Gedanken zum Threads-Test!

Die CPU, der AMD Opteron 6376 besitzt dynamisches Takten, Base 2.3 GHz, Full Load turbo 2.6 GHz und Half Load turbo 3.2 GHz.
Diesen "Turbo Core", im BIOS heißt die Option "Core Performance Boost (CPB Mode)" habe ich aus den von Dir genannten Gründen deaktiviert. "PowerNow" ist ebenfalls deaktiviert.
Somit laufen alle 32 Cores immer exakt mit 2.3 GHz (200 x 11,5).

Ponder oder Permanent Brain ist bei allen meinen Tests deaktiviert.

Zur Qualität der Multicorearchitektur:
Die kann ich nicht beeinflussen. Bei Mehrkernsystemen ist 1 Core alleine immer (etwas) schneller als 1 Core wenn die restlichen ausgelastet sind. Das ist nach meinen Tests und Erfahrungen bei Intel und AMD so, oder liege ich da falsch?
Gibt es überhaupt deterministische Mehrkern-CPUs?

Kann aber gerne mal Stockfish mit einem Kern alleine rechnen lassen und dann diesen Test wiederholen, wenn zugleich ein Stockfish mit z. B. 16 oder 31 Kernen läuft.

Viele Grüße,
Andreas

By Frank Brenner Date 2014-04-08 20:19

Hallo Andreas,

Stockfish läuft im singlecore betrieb deterministisch.

Du kannst also zb 16-32 dos fenster öffnen und jedesmal ein bestimmtes stockfish.exe ausführen (also eine bestimmte version, jedesmal die gleiche) und dann zb das kommando "go depth 22" eingeben.

22 hab ich willkürlich ausgesucht, du kannst es auch mit kleineren tiefen probieren und dann wirst du feststellen dass nach jedem neustart das stockfish exe bei go depth x stets deterministisch rechnet.

mit "setoption name Clear Hash" musst du danach die hashtabellen löschen und danach kannst du dann erneut "go depth xx" eingeben. Alternativ auch einfach das exe unterbrechen (mit Strg/C) und in der console neustarten.

Du kannst jetzt einmal damit spielen und die zeit dann notieren für die ein einziger stockfish core für eine bestimmte tiefe benötigt. Am besten mehrmals probieren und gucken damit die Streuung gering ist, so dass die Ergebnisse auf 0,1% genau werden.

mit "go infinite" kannst du einen singelcore stockfish für immer rechnen lassen und dann kannst du bequem in einem anderen fenster wieder einzeln die zeit für geringe tiefen stoppen.

So kann man dann einmal für speziell dein system : Dual AMD Opteron 6376 (2x 16 Kerne) - Also 2x Opteron 6376
testen um wieviel Prozent die Geschwindigkeit geringer wird wenn zb 3 oder 7 oder 8 oder 9 oder 15 oder 16 oder 32 cores gleichzeitig den single-stockfish ausführen.

Ich bin mir nicht sicher ob zb der 6376 wirklich 16 cores hat oder ob es nur 8 sind und jeder core ist virtuell in 2 cores aufgesplittet, d.h. die beiden ausführungsstränge teilen sich dann die in dem core enthaltenen resourcen.

Es ist bei allen Mutlicore- und Multicpusystemen so, dass die Performance pro single-core abnimmt, umso mehr cores belastet sind, weil sich die ganzen cores die Busleitungen in der Cpu zu den (mehrstufigen) Caches und zum Arbeitsspeicher mehr oder weniger teilen müssen (durch ausgeklügelte strategien)

Die UCI Befehle stehen hier beschrieben:
http://wbec-ridderkerk.nl/html/UCIProtocol.html

Hier kann man auch mal probieren ob ein Stockfish der mit 16 fäden läuft eine gleichgroße last auf einen siebzehnten single-core Stockfish ausübt wie 16 einzelne singlecore Stockfische.

Meiner meinung nach sind diese Ergebnisse schon wichtig, wenn man später die ELO performance von 4 cores vs 8 cores ; oder n cores vs m cores ausspielen lässt.

Grüße
Frank