1. Liste ist updated
2. @matthias80
Sehr gute Frage und ich habe jetzt einige Stunden damit zugebracht eine sinnvolle Antwort zu finden mit dem Ergebnis: Ich kann es nicht genau sagen, vermute aber stark ja! Warum ist das so?
Ich habe das ganze in C#, einer Compiler/Interpreter geschrieben. Der hier durch den Compiler erzeugte Code ist lediglich eine Framework Spezifischer Code, welcher erst auf dem Zielsystem durch den sogenannten JIT (Just in Time) Compiler in echte Maschinenbefehle umgesetzt wird. Anders als bei bspw einem C++ Projekt kann ich dem Compiler daher nicht sagen, welche Befehlssatzerweiterungen/SIMD Instruktionen er explizit nutzen soll, da ich nicht für eine bestimmte Zielplattform kompiliere. In dem von mir genutzten Framework (.net Core 3.1) werden grundsätzlich seit Version 3 alle Hardware Intrinsics bis hin zum AVX2 unterstützt. Man kann diese auch über einen Abstraktionslayer direkt ansprechen (Eleganterweise bietet die Abstraktionsschicht auch Fallback Optionen, falls die Hardware den Befehlssatz nicht unterstützt) und direkt implementieren, was ich aber nicht getan habe. Für die finale Code Optimierung ist der JIT Compiler zuständig. Ich gehe stark davon aus, dass dieser zu einem gewissen Grad Vektor basierte Optimierungen vornimmt, aber in welchem Ausmaß und welchen Befehlssatz er dann wirklich anwendet kann ich nicht sagen. De Facto ist das OpenSource Framework .net Core gegenüber dem proprietären .net (4.x) bei diesen Compiler basierten Optimierungen deutlich voraus. Habe das Projekt auch mal spaßeshalber 1:1 auf klassisches .net 4.8 portiert und die Performance war unterirdisch (unter 30% vom .net core pendant).
Habe versucht über Intel VTune eine disassembly zu erstellen (im Bereich Freeware disassembly ist der support von .net core noch nicht so prall), konnte hier allerdings keine spezfischen Hardware Instructions finden, welche auf SIMD Instruktionen hinwiesen. Netter weise konnte das Tool aber auch ein Profiling durchführen, mit einem durchaus positiven Ergebnis:
Gab noch deutlich mehr Output, ein Profiler wird verwendet um sogenannte "Hot-Spots" im Code zu identifizieren. Quasi die Programmteile, welche am meisten CPU Zeit fressen und auch zu einem gewissen Grad beurteilen, ob es sich dabei um Wartezyklen etc handelt.
Zu guter letzt muss ich auch ehrlich sagen: Das Gebiet ist für mich auch Neuland
3. CPU Goup Support
Habe noch viel Zeit drauf verwendet zu dem Thema mehr Input zu finden. (Noch) nicht wirklich vorhandene Dokumentation unter .net core ist eine Herausforderung dabei. Über die Laufzeitumgebung welche die Managed Threads verwaltet wäre es die eleganteste Lösung, dazu habe ich aber leider nichts sinnvolles gefunden in .net core, nur für klassisches .net. Es gäbe die Möglichkeit über System DLL Importe und dem Arbeiten mit ProcessThreadAffinitys hier evtl eine Lösung zu schaffen, allerdings wäre hier eine gute Portion Trial and Error involviert. Hier besteht die wesentliche Herausforderung darin, dass ich das ganze selbst nicht testen kann. Daher werde ich weitere Implementierungsversuche bezüglich CPU Groups zunächst erstmal aussetzen, sorry!
@Kullberg
ein 64 Core run ohne HT wäre dennoch mal interessant
______________________________________________________________________
Edit: Nicht schlecht. in der 0.1 ist der 8600k mit 4,8Ghz schneller als der 8700k mit 5Ghz in der alten Version
Edit²: v0.11
Nur die CPU Erkennung geändert, sonst alles gleich
263,729 statt nur 257,203
)
