Microsoft Visual Studio 2015

By Thomas Plaschke Date 2015-07-24 21:01

Benno Hartwig schrieb:

...
Damit sind nun auch standardmäßig in der Gratis-Version 64-bit-Kompilate möglich.

...

Mit der freien Version von VS2013 geht es auch. Die Kompilate sind 10-15% langsamer (deutliche Tendenz auch zu 15%).

Viele Grüße
Th. Plaschke

By Benno Hartwig Date 2015-07-31 10:16

PS:
umfangreichere Testläufe haben inzwischen gezeigt, dass meine VS-Kompilate nur 75%-80% der Geschwindigkeit der heruntergeladenen Dev-Stockfishe haben. Das ist schon eine recht ärgerliche Verlangsamung und Schwächung.

Andererseits liefert mir das bunkbail-1.2.1-Stockfish-Kompilierpaket von Nabil Danial keine Kompilate mehr.

Es arbeitet einige Zeit fleißig, sagt dann noch, dass das Kompilat im bin-Ordner liegt, da liegt dann aber nichts.
Das ist seit ein paar Monaten so, kam mit irgendeiner SF-Sourcenänderung.
Kennt ihr dies auch? Weiß jemand, wie man dieses Paket wieder in Gang bringt mit aktuellen SF-Sourcen?

Benno

By Jörg Oster Date 2015-07-31 12:48

Benno Hartwig schrieb:

Hast du schon mal MinGW ausprobiert?
Hier http://support.stockfishchess.org/kb/advanced-topics/compiling-stockfish-on-windows ist eine sehr gute Anleitung.
Die gleiche Geschwindigkeit wie die Kompilate der abrok.eu Seite erreichst du damit allerdings auch nicht.

P. S.: Das, und viele weitere nervige "Eigenarten" von Windows, haben mich seinerzeit veranlasst, zu Linux zu wechseln.
Da ist so vieles so viel einfacher ...

By Thomas Plaschke Date 2015-07-31 23:07 Upvotes 1

> umfangreichere Testläufe haben inzwischen gezeigt, dass meine VS-Kompilate nur 75%-80% der Geschwindigkeit der heruntergeladenen Dev-Stockfishe haben.

Da würde ich noch einige Optimierungsmöglichkeiten bei den Compileroptionen vermuten. Wirklich.

> Andererseits liefert mir das bunkbail-1.2.1-Stockfish-Kompilierpaket von Nabil Danial keine Kompilate mehr.

Das kam mit der Umstellung auf c++11, glaube ich. Das Rockwood-Paket wartet wohl auch noch auf die Umstellung. Was das Problem ist, weiß ich nicht.

Ich habe inzwischen auf meinem Rechner inzwischen diverse minGW-Versionen, die ich unter der msys-shell laufen lasse. Im Moment sind das die Posix-Versionen 4.73, 4.84, 4.92 und 5.10. Die 4.84 lasse ich meistens aus. Die ist relativ nah an der 4.92.
Mit dem Original Stockfish-makefile bringt die 4.73 die schnellste Version zustande, die meistens eine Winzigkeit schneller ist als die abrok-Version.
Mit etwas Parameter-tuning bringt bei mir jede Compiler-Version eine schnellere Version zustande.

Dazu habe ich eine Testumgebung gebaut, die ich gerne vorstellen will:

Die "Giftküche" meines SF-makefiles sieht in Abschnitt 3.5 zurzeit so aus (Zeilen mit # sind auskommentiert):

Code:


### 3.5 Optimization
ifeq ($(optimize),yes)

...

  ifeq ($(comp),mingw)
    CXXFLAGS += -mtune=native
#    CXXFLAGS += -march=core2 -mtune=native

## EXPerimental
    ifeq ($(comp_version),$(filter $(comp_version),vEXP))
      CXXFLAGS += -O3
##
      CXXFLAGS += -fira-algorithm=CB
      CXXFLAGS += -fira-region=all
      CXXFLAGS += -finline-functions
      CXXFLAGS += -funswitch-loops
#      CXXFLAGS += -fgcse -fgcse-lm -fgcse-sm -fgcse-las -fgcse-after-reload
#      CXXFLAGS += --param allow-store-data-races=1
#      CXXFLAGS += --param omega-eliminate-redundant-constraints=1
      CXXFLAGS += --param predictable-branch-outcome=16
      CXXFLAGS += -ftree-loop-ivcanon -ftree-loop-im
      CXXFLAGS += -funroll-all-loops
      CXXFLAGS += -funsafe-loop-optimizations
#      CXXFLAGS += -Wunsafe-loop-optimizations

###########
#      CXXFLAGS += -fno-early-inlining
#      CXXFLAGS += -funroll-loops
#      CXXFLAGS += -fipa-pta -fivopts
#      CXXFLAGS += --param l1-cache-size=256 --param l2-cache-size=3072 --param l1-cache-line-size=64
#      CXXFLAGS += -fvariable-expansion-in-unroller
#      CXXFLAGS += -fbranch-target-load-optimize
#      CXXFLAGS += -freschedule-modulo-scheduled-loops -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
#      CXXFLAGS += -floop-interchange -floop-strip-mine
    endif
## >4.7
    ifeq ($(comp_version),$(filter $(comp_version),v473 v473p v474))
      CXXFLAGS += -O3
      CXXFLAGS += -funroll-all-loops
      CXXFLAGS += -funswitch-loops
      CXXFLAGS += -ftree-loop-im
      CXXFLAGS += --param ipcp-unit-growth=75 --param inline-unit-growth=67 -finline-limit=256
      CXXFLAGS += --param predictable-branch-outcome=17
      CXXFLAGS += -fgcse-sm -fgcse-las
      CXXFLAGS += -fgcse-after-reload

      CXXFLAGS += -fira-algorithm=CB
      CXXFLAGS += -fira-region=all
    endif

## >4.8
    ifeq ($(comp_version),$(filter $(comp_version),v483 v484p v484 v485))
      CXXFLAGS += -O3
      CXXFLAGS += --param predictable-branch-outcome=15
      CXXFLAGS += --param ipcp-unit-growth=75 --param inline-unit-growth=67 -finline-limit=256
      CXXFLAGS += -finline-functions
      CXXFLAGS += -fno-early-inlining
      CXXFLAGS += -fgcse-sm -fgcse-las -fgcse-after-reload
    endif

## >4.9
    ifeq ($(comp_version),$(filter $(comp_version),v490 v491 v491p v492 v492p v493))
      CXXFLAGS += -O3
      CXXFLAGS += -finline-functions
      CXXFLAGS += --param predictable-branch-outcome=15
      CXXFLAGS += -funsafe-loop-optimizations
      CXXFLAGS += -Wunsafe-loop-optimizations
      CXXFLAGS += --param ipcp-unit-growth=50 --param inline-unit-growth=34 -finline-limit=256
      CXXFLAGS += -funswitch-loops
      CXXFLAGS += -ftree-loop-im
      CXXFLAGS += -fprefetch-loop-arrays
      CXXFLAGS += -fvect-cost-model=unlimited
      CXXFLAGS += -fno-tree-slp-vectorize
      CXXFLAGS += -fno-tree-loop-vectorize
      CXXFLAGS += -fgcse-sm -fgcse-las
      CXXFLAGS += -fgcse-after-reload
      CXXFLAGS += -funroll-all-loops
      CXXFLAGS += -maccumulate-outgoing-args -minline-all-stringops
    endif

## >=5.0
    ifeq ($(comp_version),$(filter $(comp_version),v500 v510p))
      CXXFLAGS += -Ofast
      CXXFLAGS += -finline-functions
      CXXFLAGS += -fdevirtualize-at-ltrans
      CXXFLAGS += -fdevirtualize-speculatively
      CXXFLAGS += -fgcse-sm -fgcse-las
      CXXFLAGS += -fgcse-after-reload
      CXXFLAGS += -funsafe-loop-optimizations
      CXXFLAGS += -Wunsafe-loop-optimizations

      CXXFLAGS += --param predictable-branch-outcome=17
      CXXFLAGS += --param ipcp-unit-growth=50 --param inline-unit-growth=34 -finline-limit=256
      CXXFLAGS += -funswitch-loops
      CXXFLAGS += -funroll-all-loops
      CXXFLAGS += -ftree-loop-ivcanon -ftree-loop-im

      CXXFLAGS += -fprefetch-loop-arrays
      CXXFLAGS += -maccumulate-outgoing-args -minline-all-stringops
    endif

  endif
...

Ich behaupte nicht, dass ich wüsste, was hinter jeder einzelnen Option steckt. Ich habe zuerst nach Optimierungsoptionen gesucht, die nicht von -O2, -O3 oder -Ofast gesetzt werden. Dann hat das lustige Ausprobieren begonnen - und ist noch nicht zu Ende.
Man kann mit den Compiler-Parametern eine Menge experimentieren. Statt -O3 z.B. -O2 plus einiger weiterer Parameter ist bei 4.73 schneller. Bringt aber bei 4.92 und 5.10 nichts. 5.10 ist mit -Ofast meistens ganz gut. Dummerweise ändert sich das von einer Stockfish-Version zur nächsten. Für Stockfish-Matefinder sind wieder ganz andere Parameter besser und die 4.92-Version ist etwa genauso schnell wie die 4.73er.
Manchmal bringt auch das Abschalten von Optionen, die durch die -O[23fast] gesetzt werden. Bei der 4.92 brachten diese beiden Optionen etwas: -fno-tree-slp-vectorize und -fno-tree-loop-vectorize.
Manche Optionen gibt es auch nur für gcc, aber nicht für minGW.

Der Aufruf von make erfolgt aus einem (DOS-)Batch-File. Dabei werden mittels der übergebenen Variable comp_version die gewünschten Optimierungen ausgewählt.

Code:

@echo off
Setlocal EnableDelayedExpansion

SET PTH_BAK=%PATH%

CLS
ECHO ~~~~~~~~~~~~~~~~~~~~~
ECHO -- Es geht los ... --
ECHO ~~~~~~~~~~~~~~~~~~~~~

FOR %%I IN ( 473p 492p 510p ) DO (
  SET VSN=%%I
  SET PRG_NAME=Stockfish150729

  IF EXIST C:\mingw64\!VSN!\mingw64\bin\. (
    SET PATH=C:\mingw64\!VSN!\mingw64\bin;C:\MinGW\msys\1.0\bin;C:\WINDOWS;C:\WINDOWS\SYSTEM32;C:\WINDOWS\SysWOW64

    SET PRG=!PRG_NAME![!VSN!].exe

    REM del !PRG!
    del *.o
    del *.gcda
    del syzygy\*.o
    del syzygy\*.gcda

    ECHO.
    ECHO        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ECHO        make clean profile-build ARCH=x86-64-modern comp_version=v!VSN! COMP=mingw EXE=!PRG! strip
    ECHO        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ECHO.
    ECHO.

    make clean profile-build ARCH=x86-64-modern comp_version=v!VSN! COMP=mingw EXE=!PRG! strip

    SET PRG=!PRG_NAME![!VSN!EXP].exe
    make clean profile-build ARCH=x86-64-modern comp_version=vEXP COMP=mingw EXE=!PRG! strip
    )
  )

SET PATH=!PTH_BAK!
SET PTH_BAK=

CLS
ECHO ... .  Nun zum Benchmark-Test ...

call benchmark.bat

Die MSYS-Shell befindet sich im Pfad C:\MinGW\msys\1.0\bin.
Die minGW-Versionen sind im Verzeichnis C:\mingw64\!VSN!\mingw64\bin in den von der Variablen !VSN! gesetzten Unterverzeichnissen (473p, 492p und 510p) untergebracht. Deren Namensschema (Version ohne Punkt + 'p' für Posix-Bibliothek) dürfte einleuchten.
Da die PATH-Variable neu gesetzt wird, dürfen die Standard-Pfade nicht fehlen (C:\WINDOWS etc.).
Die FOR-Schleife klappert die Verzeichnisse ab, setzt die Umgebungsvariablen und ruft make auf.
Will man nur den Stockfish für eine Compilerversion erzeugen, kann man die nicht gewünschten abschalten, indem man in der FOR-Schleife die Verzeichnisnamen auf nicht existente Verzeichnisse ändert (bspw. 492-p).

Der vollständige Durchlauf der Batch-Datei erzeugt 6 Programmversionen und dauert auf meinem Rechner etwa 8 Minuten. Jede Änderung im makefile will daher gut überlegt sein. Will man auf die "Experimental"-Versionen verzichten, lässt man den zweiten Aufruf von make weg.
Disziplin und ein gutes Gedächtnis schaden auch hier nicht. Man sollte die Beschreibung der gcc-Compiler-Optionen bereit halten.

Wenn die Batch-Datei abgearbeitet ist, wird benchmark.bat aufgerufen.

Code:

@ECHO off
PAUSE
SET SF=Stockfish150729
SET P1=stockfish_15072918_x64_modern.EXE
SET P2=SF150725.EXE
SET P3=%SF%[473p].EXE
SET P4=%SF%[492p].EXE
SET P5=%SF%[510p].EXE
SET P6=%SF%[473pEXP].EXE
SET P7=%SF%[492pEXP].EXE
SET P8=%SF%[510pEXP].EXE

FOR %%I IN ( %P1% %P2% %P3% %P4% %P5% %P6% %P7% %P8% ) DO (
  cls
  IF EXIST %%I (
    start /B /WAIT /REALTIME /AFFINITY 0xF %%I bench >nul
    ECHO Ergebnis für: %%I
    PAUSE
  )
)
pause

Man könnte die Variable SF auch übergeben. Dann lässt sich die Batchdatei aber nicht mehr standalone aufrufen.
Nacheinander werden die frischen Stockfish (Plural von fish ist im englischen fish

) ausgeführt. Zum Vergleich ist in P1 der Stockfish von der abrok-Seite referenziert. P2 ist in diesem File die VS2013 Version. Fehlende Dateien führen nicht zu Fehlermeldungen.

Die beschriebenen Batch-Dateien sind übrigens zur Verwendung im Source-Verzeichnis ("\src") konzipiert.

Außerdem sollte in der Quelldatei misc.cpp die Variable Version mit dem Datumsstring initialisiert werden. Sonst wird das Datum des Compilierens gesetzt. Da ich keine (anderen) Änderungen am Stockfish-Code vornehme, möchte ich das nicht.

Ich hoffe, das hilft Dir über den bunkbail-Verlust hinweg.

Viele Grüße
Th. Plaschke

By Benno Hartwig Date 2015-08-01 07:21

Wow!
Thanx für die vielen Infos!
Die werde ich mir mal reinziehen.

Inzwischen habe ich mir auch MinGW installiert.
Interessanterweise klappt der SF-Build auf einem meiner Windows7-64bit-Rechner
und auf dem anderen nicht (mal gucken, was ich da nun wieder falsch machte...)

Benno

By Benno Hartwig Date 2015-08-03 13:16

Inzwischen klappen die MinGW-Kompilate prima.
Normale builds sind bereits recht fix. Ich komme immerhin auf ca. 92% der Geschwindigkeit der Dev-Version.

Aber auch der profile-build klappt prima und ohne jedes eigene Zutun. Ungefähr satte 98% der Dev-Geschwindigkeit sehe ich dann in der nps-Anzeige.

Thanx an das SF-Team auch für die prima Vorbereitung für den Build, die man mit der Stockfish-Sourcenanlieferung erhält!

Benno

By Thomas Plaschke Date 2015-08-04 10:26

> Thanx an das SF-Team auch für die prima Vorbereitung für den Build, die man mit der Stockfish-Sourcenanlieferung erhält!

Ja, die Jungs haben sich echt Mühe gegeben. Und das makefile von Stockfish ist an sich recht lehrreich, wenn man mit make keine Erfahrungen hat.

> Aber auch der profile-build klappt prima und ohne jedes eigene Zutun. Ungefähr satte 98% der Dev-Geschwindigkeit sehe ich dann in der nps-Anzeige.

Da sollte mehr gehen. Welchen Prozessor und welche Compilerversion hast Du genutzt?
Ich werde nachher einige Vergleichswert hier einstellen. Bis dann.

Viele Grüße
Th. Plaschke

By Thomas Plaschke Date 2015-08-04 12:53

Ich habe von meinem Desktop-Rechner und meinem Notebook die Benchmark-Ergebnisse für verschiedene Compilerversionen ausgewertet.

Zuerst das Notebook. Ein i3-3227U @1,9 GHz:

Code:

SF150730     Lauf 1   Lauf 2   Lauf 3      Ø    Diff.   in %     rel. zu abrok 
abrok        6896     6875     6897     6889,33     22    0,3%       ./.      
473 -O3      6814     6747     6765     6775,33     67    1,0%       101,7%     
484 -O3      6769     6720     6696     6728,33     73    1,1%       102,4%     
492 -O3      6799     6840     6765     6801,33     75    1,1%       101,3%     
510 -O3      6902     6970     6903     6925,00     68    1,0%        99,5%      
473 -O2      6835     6760     6747     6780,67     88    1,3%       101,6%     
484 -O2      6771     6777     6727     6758,33     50    0,7%       101,9%     
492 -O2      6795     6732     6738     6755,00     63    0,9%       102,0%     
510 -O2      6841     6842     6832     6838,33     10    0,1%       100,7%     
gest. Mittel                            6805,74     57    0,8%

Dazu die Werte vom i5-3570K @4,4 GHz:

Code:

SF150730     Lauf 1   Lauf 2   Lauf 3      Ø     Diff.    in %   rel. zu abrok 
abrok        3006     3015     3009     3010,00    9      0,3%      ./.           
473 -O3      2955     2947     2950     2950,67    8      0,3%     102,0%          
484 -O3      2944     2945     2946     2945,00    2      0,1%     102,2%          
492 -O3      2976     2979     2975     2976,67    4      0,1%     101,1%          
510 -O3      2998     3001     3002     3000,33    4      0,1%     100,3%          
473 -O2      2935     2921     2927     2927,67   14      0,5%     102,8%          
484 -O2      2961     2961     2975     2965,67   14      0,5%     101,5%          
492 -O2      2937     2936     2934     2935,67    3      0,1%     102,5%          
510 -O2      2988     2985     3009     2994,00   24      0,8%     100,5%          
gest. Mittel                            2967,30    9      0,3%

Es fällt auf, dass die Werte (Dauer des Benchmarktests in Millisekunden) des i5 weniger "schwankend" sind. Die Programme sind die PGO-Versionen - also nicht vergleichbar mit Deinen "normalen" builds.
Es wurden nur die Optimierungsstufen -O2 und -O3 verwendet und -mtune=native gewählt. Im Übrigen blieben die Einstellungen wie im Original-makefile.
Relativ zum automatischen Build von Roman Korba's Webseite (abrok-Version) liegen meine builds eigenwilliger Weise fast immer vorn. Keine Ahnung warum.

Viele Grüße
Th. Plaschke

By Thomas Plaschke Date 2015-08-06 16:52

Einen hab' ich noch.

Zur Thematik 'Was bringt Hyperthreading?' habe ich die Benchmark-Batchdatei etwas modifiziert (war eigentlich ein Neuschreiben).

Ich gehe, wie viele andere, davon aus, dass Time to Depth bezogen auf die Spielstärke die richtige Einschätzung ermöglicht. Für die vermutlich zumindest nicht schlechtere Alternative 'Lösung einer Sammlung von Teststellungen' scheue ich den Aufwand sowohl für die Durchführung als auch für die vorherige Identifizierung geeigneter Teststellungen.

Getestet wurde mit der abrok-Dev-Version vom 30.7.15. Je 10mal wurde der Test für Rechentiefen von 9 bis 17 plies durchgeführt.
Gemessen wurde für single-threaded, 2 Threads und 4 Threads. Mein i3 hat 2 cores und durch Hyperthreading 4 logische Prozessoren. Stockfish lief für die Tests mit 1 und 2 Threads auf je 1 Ausführungspfad beider cores - also nie simultan auf den Ausführungspfaden eines cores. Das hatte sich bereits früher als optimal auf dem Testrechner erwiesen.

Ich zeige hier die Minimalwerte und die Werte des gestutzten Mittels (das arithmetrische Mittel ohne die 'Extremwerte' - der schlechteste und der beste Wert).

Die Auswertung der Minima (Werte sind Zeiten in Millisekunden):

Code:

Ply        1 Thread 2 Threads 4 Threads
9             619         399       530       
10          1.096         774       822       
11          2.119       1.317     1.414     
12          4.002       2.154     2.291     
13          6.712       3.619     3.929     
14         10.275       5.357     6.121     
15         16.528       8.946     9.386     
16         30.243      13.615    14.898
17         44.137      21.859    21.795

Die Maxima lagen im Schnitt für 1 Thread um 3%, 2 Threads um 27,7% und für 4 Threads um 28,0% über den Minima.

Und hier die Mittelwerte:

Code:


Ply        1 Thread 2 Threads 4 Threads
9               622      456       600
10            1.102      850       976
11            2.130    1.501     1.642
12            4.037    2.520     2.729
13            6.765    3.849     4.225
14           10.316    6.236     6.708
15           16.587    9.591    10.392
16           30.358   15.231    16.371
17           44.562   24.130    24.432

Obwohl die nps-Leistung bei 4 Threads erwartungsgemäß höher war, entschied das Rennen wieder Mal nicht der schnelle Hase, sondern der scheinbar langsame Igel mit Haaresbreite für sich. Das ist aber nicht die Überraschung, sondern, dass die zusätzlichen Threads des Hyperthreadings nur eine höhere Knotenleistung produzieren, die auf diesem Rechner aber verpufft.

Bei anderen Rechnern, insbesondere mit (viel) mehr Ausführungspfaden als mein Notebook mag das anders aussehen. Ich warte auf Ergebnisse

.

Viele Grüße
Th. Plaschke

By Benno Hartwig Date 2015-08-06 17:50

Als "Gegenprobe" könntest du einen Zweikampf ohne Pondern 2 Kerne gegen 4 Kerne laufen lassen.
Seinerzeit hatte ich vermutet, dass die 4 Kerne eher schlechter abschneiden (zwar nps-Tempogewinn, aber Effizienzverluste wegen der doppelt so großen Parallelisierung)

Die Ergebnisse waren für mich dann aber nicht eindeutig, und sie schienen recht Engine-abhängig.
Mehrheitlich deuteten sie aber durchaus auf ein "Mit Nutzung des Hyperthreading ist die Engine stärker!" hin.
Welche Erfahrung machten hier ggf. andere?

Groß sind die Unterschiede nicht. Es bedarf schon einer etwas größeren Partienanzahl.

Benno

By Thomas Plaschke Date 2015-08-07 18:19

Aus verschiedenen Gründen würde ich einen "Zwei-"kampf einer identischen Engine nicht durchführen.
1. Ich habe nur ein relativ "rechenschwaches" Notebook, dem ich das nicht zumuten möchte (ich bin im Moment in einer Ferienwohnung in der Vulkaneifel, wo drinnen wie draußen 30° und mehr - so genau will ich das gar nicht wissen - herrschen).
2. Habe ich den Test mit 100 Testläufen pro ply wiederholt. Dieses Mal hat bei 17 plies Rechentiefe (der letzte Lauf) die 4-Threads-Engine gerade so eben die Nase vorn. Es könnte also erst bei den höheren Rechentiefen zu einer Differenzierung kommen. Zu dumm, dass die am aufwändigsten zu testen sind.
3. Die relative Spannbreite der Werte (=MAX/MIN) ist wesentlich höher, als in dem ersten Test. Lässt man Ausreißer weg, liegen die 2- und 4-Threads-Engines bei 47% bzw. 43%.

Code:

Ply  1T   2T   4T
9   18% 145%  38%
10  15% 112%  52%
11  12%  52%  43%
12   8%  47%  36%
13   8%  49%  37%
14   4%  34%  57%
15   3%  36%  33%
16   4%  37%  51%
17   2%  73%  42%

Dass die Zahl der Extremwerte (nach unten wie nach oben) steigen würde, war zu erwarten. Da nicht bekannt ist, wo ihre obere Grenze ist, können die hohen Werte nicht überraschen. Geht man aber von 47% bzw. 43% aus hat man schon ein ziemlich lautes Rauschen (das bekannte nichtdeterministische Verhalten multithreaded arbeitender Engines), obwohl die Mittelwerte annähernd identisch sind. Das bedeutet aber wiederum, dass andere Faktoren, angefangen bei der Eröffnungswahl, größere und den Test entscheiden könnende Einflüsse haben können. Parallel zu 2T vs. 4T müsste man ja dann bspw. auch noch 2T vs. 2T und 4T vs. 4T durchführen, um die Auswirkungen der Testbedingungen zu ermitteln. Diese Faktoren lassen sich m.E. aber nicht völlig herausfiltern.

Aus diesen Gründen halte ich nichts von einem Zweikampf einer identischen Engine 2T vs. 4T.

Viele Grüße
Th. Plaschke

By Thomas Plaschke Date 2015-08-08 13:54

> Mehrheitlich deuteten sie aber durchaus auf ein "Mit Nutzung des Hyperthreading ist die Engine stärker!" hin.

Dazu habe ich noch einen weiteren Testlauf durchgeführt. Ich wollte den Einfluss der Testumgebung auf das Ergebnis für die 2 Threads-Engine herausfinden.
Einerseits lief der Test mit 2 Threads auf den logischen Prozessoren 1 und 3 ("start" mit AFFINITY 0x5) und damit jeder Thread auf einem eigenen core. Im anderen Test wurde die Engine auf allen 4 logischen Prozessoren ausgeführt ("start" mit AFFINITY 0xF). (Die Funktion/Wirksamkeit der AFFINITY-Einstellung habe ich überprüft

)

Code:

Ply  2T-2cores   2T-4HT  rel.
9         459       586  128%
10        898     1.046  116%
11      1.499     1.730  115%
12      2.539     2.865  113%
13      4.126     4.546  110%
14      6.549     7.339  112%
15     10.179    11.438  112%
16     15.793    17.544  111%
17     24.222    26.826  111%

Man büßt auf meinem i3 demnach ca. 11% an Leistung ein, wenn man nicht dafür sorgt, dass die Threads immer nur auf "physischen" Prozessoren laufen und niemals parallel auf den Ausführungspfaden eines cores. Für andere HT-Prozessoren sind andere Ergebnisse zu erwarten. Bei einem Engine-Vergleich wird man aber diese Problematik (grundsätzlich) berücksichtigen müsssen. 11% sind immerhin wesentlich mehr als man durch unterschiedliche minGW-Compilerversionen gewinnt oder verliert.

Viele Grüße
Th. Plaschke