Frage Ansys Mechanical mit MKL-Trick auf AMD Prozessoren erheblich beschleunigen

marvinatorVC

Neuling
Mitglied seit
Jan 27, 2021
Beiträge
4
Bewertungspunkte
0
Punkte
1
Hallo zusammen,

ich habe eine ziemliche Odyssee hinter mir, um zu erreichen, dass ANSYS Mechanical meinen 3800X voll auslastet.
Die Problematik, dass die bei ANSYS Mechanical (und auch MATLAB) verwendete Intel Math Kernel Library (MKL) AMD Hardware stark benachteiligt, ist seit einiger Zeit ein bekanntes Problem. Der Fix hierfür war bisher, dass eine System-Umgebungsvariable gesetzt wurde, welche die MKL in einen Debug-Modus versetzt und somit unabhängig von der Vendor-ID der CPU den bestmöglichen Befehlssatz (AVX2 im Falle von Matisse) benutzt.
Nun war der bisherige Konsens, dass dieser Trick bis zur MKL Version 2020.0.0 funktionieren sollte. Das stimmt aber zumindest im Falle von Ansys Mechanical scheinbar nicht!
Ich habe lange herumprobiert und recherchiert, aber alle Versuche die Rechenleistung meines Prozessors zu steigern blieben erfolglos.
Letztendlich habe ich eine ältere Version heruntergeladen (2019R1). Nun funktioniert der Trick mit der Umgebungsvariable zwar, jedoch nur, wenn das Projekt auch in R2019 erstellt wurde. Startet man Mechanical APDL 2019 im Batch-Modus und lädt ein mit 2020R2 erstelltes Input-file, ist man wieder bei der gähnend langsamen Rechenleistung unterwegs!
Merkwürdig ist das, was passiert, wenn man nun das in 2019R1 erstellte Projekt in 2020R2 öffnet und berechnet; nun ist auch in 2020R2 eine erhebliche Steigerung der Rechenleistung feststellbar! Das finde ich hochgradig eigenartig...
Weiß einer vielleicht woran das genau liegt, dass der Trick nur dann in 2020R2 funktioniert, wenn man ein in R2019 erstelltes Projekt lädt?
Laut Solver-output File wurde dabei die "neue" Version der MKL 2020.0.0 genutzt.

Die Umgebungsvariable, die gesetzt werden muss und ihr Wert lautet: MKL_DEBUG_CPU_TYPE=5

Vielleicht helfen meine Erkenntnisse ja jemandem, der das gleiche Problem hat!

Schönen Abend noch,
Marvin
 
Hi, ich hoffe du hast Benachrichtigungen im Forum eingeschlatet, und das hier siehst
Weiß einer vielleicht woran das genau liegt, dass der Trick nur dann in 2020R2 funktioniert, wenn man ein in R2019 erstelltes Projekt lädt?
Meine einzige Vermutung: 2020-er Projekte verwenden einen komplett neuen Satz an Bilbiotheken, die mit dem "anti-fix" ausgestattet sind. Die 2019-er Reihe würde dann mit alten laufen und nicht betroffen sein.

Ich weiß nicht, wie dieser Anti-Consumer Check bei neuen Versionen funktioniert (und ich meine auch den MKL-Trick). Die ganz alte Vorgehensweise ist hier bei Agner Fog nachzulesen: https://www.agner.org/optimize/blog/read.php?i=49

Nämlich wurde der Text in CPUID verglichen (siehe CPU-Z Output):
- AuthenticAMD
- GenuineIntel
Und dazu noch die "Family number" - (siehe diese Antwort)

Die Textauschnitte sollten jeweils separat zu 4 Buchstaben abgespeichert sein in den Bibliotheken (.so, .dll) und Executables (.exe). Wenn du also das selbst versuchen möchtest: Nimm z.B. Notepad++ in die Hand und suche nach "ntel", "Genu", "ineI" in den Dateien des Programms. Nach einem Backup der Dateien kannst du versuchen diese Textausschnitte durch die der AMD zu ersetzen. Falls aber wirklich nach Family Number/was anderem gecheckt wird, wird's nichts bringen.

Soweit ich weiß funktionieren die alten "Patcher" nicht mehr und vor der MKL-Debatte hab ich keine neueren im Netz finden können. Vielleicht wird's mal wieder Zeit... ;)
 
Moin,

vielen Dank für deine Antwort!
Ich muss mal schauen, ob ich mir den Aufwand mache die entsprechenden Bibliotheken herauszusuchen und dann manuell zu patchen. Da ANSYS ja ein kommerzielles Programm ist, ist der Code ja schon kompiliert und dann ist meines Wissens nach ein ziemliches Gebastel, um das wieder lesbar zu machen. Ich bin aber was die Modifikation von kompilierten Programmen angeht auch absolut unerfahren...vlt. verstehe ich da was falsch.

Ich hab übrigens zusätzlich herausgefunden, dass ANSYS das Problem in 2020R1 angeblich verbessert haben soll. Das konnte ich jetzt aber nicht so direkt feststellen.
Ich hab auch mal den Support angehauen, die wissen zwar von dem Problem aber planen nicht das in Zukunft mal anständig zu fixen...wirklich schade!
Ich arbeite jetzt einfach mit der 2019er Version. Die ist nicht so intuitiv in der Bedienung, aber das ist ja nur Gewöhnungssache.
 
"Eigentlich" ist es die richtige Vorgehensweise den Support zu nerven, bloß meistens sind es 1st Level Schulpraktikanten (vom Niveau her) und geben an die Entwickler selten was weiter, damit sie es wirklich mal fixen.

Zu Bilbiotheken: Wenn es hilft alleine den Vendor String zu ersetzen, kannst du da mit Notepad++ ran und nur diese Zeichenketten ersetzen (nichts hinzufügen oder sonst ändern)! Mit N++ könntest du einfach in allen Installationsdateien des Programs nach Text suchen (vermutlich ergibt "ineI" bei case-sensitive (Groß-/Kleinschreibung) die wenigsten falsch-positive Ergebnisse) - sollte zum vorsichtigen Ersetzen nicht mehr als eine Viertelstunde dauern. Sofern das Programm die eigenen Dateien beim Start nicht überprüft, sollten die Änderungen nicht zurückgesetzt werden.
Wenn das nichts bringt, versuch's nicht weiter, da müssten schwerere Geschütze ausgefahren werden :)

Trotzdem ist es ein spannendes Thema, halte uns auf dem Laufenden
 
Bei den ganzen Datei bist Du da gut beschäftigt. Bei den wenigen hundert Euro würde ich da sowie eine andere CPU einsetzen. Epyc gibt es gebraucht ziemlich günstig und die haben das Problem nicht.
 
Oben Unten