Ausführen einer Simulation auf reinem Ubuntu im Vergleich zu Ubuntu in Windows (WSL)

15

Ich möchte eine Frage zum Testen einer großen CAE- Simulation auf demselben Computer in den folgenden beiden Situationen stellen.

Reines Ubuntu-System
Ubuntu-System in Windows 10 (WSL)

Sind die Rechengeschwindigkeiten in beiden Fällen nahezu gleich oder unterschiedlich?

windows windows-subsystem-for-linux benchmarks

— ABCDEMMM
quelle

4

Ohne die Art der Simulation zu kennen, ist dies unmöglich zu beantworten.

— muru

1

@muru: Es ist nicht so vage. Eine "Simulation" ist vermutlich ein rechenintensiver Hintergrundjob, der entweder die CPU oder den Speicher bindet. (Festplatten- oder Netzwerk-E / A-Vorgänge stellen möglicherweise auch einen Engpass dar, aber dies wird von Entwicklern solcher Programme tendenziell vermieden, und einige moderne Simulationscodes verwenden möglicherweise sogar die GPU für parallele Berechnungen.) Sie können problemlos einen Benchmark schreiben (oder herunterladen) Das testet alle diese 2 bis 5 möglichen Engpässe und prüft, ob es einen signifikanten Unterschied zwischen WSL und nativem Ubuntu für einen von ihnen gibt. Ich würde es tun, aber ich habe keine WSL (oder Windows 10) verfügbar.

— Ilmari Karonen

3

@IlmariKaronen "vermutlich". Abhängig von den Daten, die komprimiert werden, kann es genauso gut zu einer I / O-Belastung kommen, selbst wenn die CPU gebunden ist. Der Rest Ihres Kommentars ist ein guter Grund, dies zu schließen - wir haben keine Ahnung, welche mögliche Kombination von Engpässen hier von Bedeutung ist.

— muru

1

Nun, ich habe eine Antwort gepostet, da sich herausstellt, dass geeignete Benchmarks bereits online sind . Natürlich kann ich nicht sicher sagen, ob der spezifische Simulationscode des OP auf der WSL langsamer abläuft oder nicht. Eine Antwort auf diese Frage nützt aber auf jeden Fall niemandem außer dem OP. Was ich anhand der Benchmarks beantworten kann, ist, bei welchen Arten von Simulationscode vernünftigerweise Leistungsunterschiede zwischen WSL und nativem Linux zu erwarten sind.

— Ilmari Karonen

@muru, es ist eine CAE-Simulation (Abaqus CAE).

— ABCDEMMM

18

Ihre Simulationssoftware ist höchstwahrscheinlich entweder an die CPU oder an den Speicher gebunden . Bei solchen Workloads würde man keinen signifikanten Unterschied zwischen der Ausführung des Codes auf "Bare Metal" oder innerhalb der WSL (oder einer anderen Kompatibilitätsebene oder VM, die native Ausführung verwendet) feststellen, da in beiden Fällen das Betriebssystem meist nur bereitsteht Der Simulationscode läuft dabei direkt auf der CPU.

Es ist jedoch auch möglich, dass Ihre Simulation zumindest teilweise an die E / A gebunden ist, und hier können sich Unterschiede ergeben. Anscheinend hat WSL (derzeit) eine ziemlich langsame Dateisystemschnittstellenschicht, die die Datenträger-E / A erheblich verlangsamen kann. * Allerdings kann die Datenträger-E / A der Hauptengpass für viele Arten von Massendatenverarbeitungsaufgaben sein, eine "Simulation". Normalerweise sollte er nicht die meiste Zeit damit verbringen, Dateien zu lesen und zu schreiben. Wenn dies der Fall ist, können Sie die Ausführung von einer RAM-Festplatte (z. B. tmpfs unter nativem ** Linux) in Betracht ziehen, um unnötigen physischen Festplattenzugriff zu vermeiden.

In jedem Fall besteht die einzige Möglichkeit, sicher zu sein, darin, Ihre Simulation in beiden Umgebungen und in der Zeit zu testen, die für die Ausführung erforderlich ist. Zuvor sollten Sie jedoch einen Blick auf vorhandene Benchmarks werfen, z. B. auf diesen Performance-Benchmark von WSL vs. Docker vs. VirtualBox vs. Native Linux von Phoronix aus dem Februar 2018 , und die Ergebnisse auf Tests untersuchen, bei denen dieselben Komponenten beansprucht werden des Systems wie Ihre Simulation.

(FWIW, die Phoronix-Ergebnisse stimmen anscheinend größtenteils mit den oben beschriebenen allgemeinen Grundsätzen überein, obwohl es einige bemerkenswerte Besonderheiten gibt, wie VirtualBox, das anscheinend in einigen I / O-gebundenen Benchmarks besser abschneidet als natives Linux, da die Daten auf der virtuellen Festplatte nicht immer sofort synchronisiert werden Ein potenziell relevantes Problem, das ich oben nicht erwähnt habe, ist, dass die Benchmarks signifikante Unterschiede in der Multi-Threaded-OpenMP-Leistung sowohl zwischen den verschiedenen Host-Umgebungen als auch zwischen verschiedenen Linux-Distributionen aufweisen, selbst wenn sie auf nackter Hardware ausgeführt werden. Das ist nicht verwunderlich, da Threading und IPC vom Kernel verwaltet werden. Ich schätze, dass ein großer Teil des Unterschieds zwischen den Distributionen auf unterschiedliche Laufzeit- und / oder Kompilierzeit-Kernel-Optimierungsparameter zurückzuführen ist.)

^{*) Nach dieser MSDN Blog - Post von 2016, gibt es eigentlich zwei Dateisystem - Interface - Komponenten in WSL: volfs, die nativen Dateisystem Linux emuliert eng Semantik über NTFS und wird verwendet , zB zu montieren /und /home, und DrvFs, die meist Windows-ähnliche Semantik bieten und wird für den Zugriff auf die Windows-Host-Laufwerke über /mnt/cusw. verwendet. Wenn für Ihre Software keine nativen Linux-Dateisystemfunktionen wie mehrere feste Verknüpfungen zu derselben Datei erforderlich sind, kann die Dateizugriffsleistung verbessert werden, wenn sie so konfiguriert wird, dass ihre Datendateien in einem DrvFs-Ordner gespeichert werden WSL.}

^{**) Laut diesem Reddit-Thread aus dem Mai 2017 wird "tmpfs zurzeit mit disk" in der WSL emuliert. Sofern sich im letzten Jahr nichts geändert hat, bedeutet dies vermutlich, dass die Verwendung von tmpfs in der WSL keinen Leistungsvorteil gegenüber einem normalen Dateisystem auf der Festplatte bietet.}

— Ilmari Karonen
quelle

Vielleicht nicht nur Parameter -O3 -march=haswelloptimieren , sondern auch Compileroptionen (z . B. oder so). Ich weiß nicht, was Clear Linux tatsächlich zum Erstellen seiner Kernel verwendet, aber vielleicht kann BMI2 / popcnt/ einen messbaren Unterschied zwischen glibc und dem Kernel bewirken . (Der Kernel hat gewonnen 't profitieren von AVX jedoch, weil der Kernel es vermeidet, FPU-Register zu berühren, außer in einem bestimmten Code wie den Software-RAID5 / 6-Fehlerkorrekturdaten.)

— Peter Cordes

12

Ubuntu in Windows (WSL - 2017 Fall Creators Update) ist definitiv langsamer als "Pure" Ubuntu in Linux-Umgebungen.

Beispielsweise dauert das Malen von Bildschirmen in Windows 10 um ein Vielfaches länger als in Ubuntu 16.04, dh Sie können tatsächlich sehen, wie sich der Cursor in Windows 10 bewegt:

Es dauert ungefähr 5 Sekunden, bis der Begrüßungsbildschirm von WSL Bash angezeigt wird. Im Vergleich dazu sind es ungefähr 1 1/2 Sekunden für den gleichen Begrüßungsbildschirm in Ubuntu 16.04:

CPU-Benchmarking

Der erste Abschnitt zeigt, wie langsam Bildschirm-E / A ist, aber was ist mit CPU-Benchmarking?

Von diesem Dienstprogramm Ask Ubuntu Q & A: CPU Benchmarking für Linux aus habe ich Tests auf Ubuntu 16.04 unter Linux und Windows durchgeführt. Unter Linux ca. 24 Sekunden, unter Windows 10 Version 1709 ca. 31 Sekunden. Linux ist 6 Sekunden schneller oder ungefähr 25% schneller. Allerdings habe ich gerade Windows 10 auf Version 1803 aktualisiert (Redstone 4 aka Spring Creators April 2018 Update) und es hat 24 Sekunden gedauert, was dem von Linux entspricht.

Ubuntu 16.04 unter Linux

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          23.5065s
    total number of events:              10000
    total time taken by event execution: 23.5049
    per-request statistics:
         min:                                  2.13ms
         avg:                                  2.35ms
         max:                                  8.52ms
         approx.  95 percentile:               2.76ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   23.5049/0.00

Ubuntu 16.04 unter Windows 10 Build 1709

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          30.5350s
    total number of events:              10000
    total time taken by event execution: 30.5231
    per-request statistics:
         min:                                  2.37ms
         avg:                                  3.05ms
         max:                                  6.21ms
         approx.  95 percentile:               4.01ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   30.5231/0.00

Ubuntu 16.04 unter Windows 10 Build 1803

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          23.7223s
    total number of events:              10000
    total time taken by event execution: 23.7155
    per-request statistics:
         min:                                  2.21ms
         avg:                                  2.37ms
         max:                                  4.53ms
         approx.  95 percentile:               2.73ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   23.7155/0.00

HINWEIS: Das Windows 10-Frühjahrsupdate für 2018 (genannt Redstone 4 ) wurde am 9. Mai (vor 4 Tagen) veröffentlicht. Ich werde es bald installieren, um die Verbesserungen zu überprüfen. Zweifellos gibt es viele. Eines, von dem ich weiß, dass es mich interessiert, ist die Möglichkeit, cronJobs beim Start auszuführen . Ich benötige das für automatische tägliche Backups auf gmail.com.

HINWEIS 2: Ich habe gerade Windows 10 Build 1803 (Spring Creators Update AKA Redstone 4 vom April 2018) installiert und das Malen auf dem Bildschirm ist viel schneller. Es sind nur noch 3 anstatt 5 Sekunden, um den Bash-Begrüßungsbildschirm anzuzeigen. Der CPU-Benchmark ist jetzt mit Linux vergleichbar.

— WinEunuuchs2Unix
quelle

8

Beachten Sie, dass dies irreführend ist - dies unterscheidet nicht zwischen E / A-Leistung und anderer Rechenleistung. Es ist bekannt, dass die WSL für E / A langsam ist (siehe z. B. Phoronix-Benchmarks). Das sagt nichts darüber aus, ob die Berechnungen von OP in der WSL genauso schnell durchgeführt werden können.

— muru

6

Ich bin ehrlich überrascht, dass das Zeichnen des Begrüßungsbildschirms in beiden Fällen nicht sofort wirksam ist. Ihr Computer ist (vermutlich) froh, in wenigen Millisekunden weitaus komplexere Bildschirmaktualisierungen durchführen zu können, z. B. bei der Wiedergabe von Videos. Und das letzte Mal, als ich ein Terminal sah, das so langsam war wie bei Ihrer ersten Aufnahme, war es Anfang der 90er Jahre, als ich mit meinem 2400-Bit / s-Modem eine BBS anwählte.

— Ilmari Karonen

Was meinst du mit "Ubuntu in Linux"?

— Jon Bentley

3

Ehrlich gesagt, ist diese Art von Benchmark für jede Art von realistischem Programm völlig unbrauchbar, da jeder Benchmark im Wesentlichen die Geschwindigkeit der Konsolenlackierung misst. Entweder ist Ihr Programmengpass die Konsolen-E / A (die selbst unter Linux mit den meisten Terminalemulatoren notorisch langsam ist), oder dies ist keine verlässliche Maßnahme für irgendetwas Nützliches.

— Matteo Italia

2

@ WinEunuuchs2Unix Soweit ich sehen kann, gibt es wenig Berechnung. Aber viele E / A-Vorgänge: Abrufen des Wetters, Lesen von Datum und Uhrzeit, Drucken in einem Format, Lesen von Systeminformationen usw. Haben Sie Abaqus jemals verwendet? Simulationssoftware wie Ansys oder Simulink sind bei der Ausführung der eigentlichen Simulation nicht an die Bildschirm-E / A gebunden, es sei denn, Sie erzwingen dies. Abhängig von der durchgeführten Simulation ist es durchaus möglich, dass diese die richtigen Endergebnisse anzeigen.

— muru

7

Denken Sie darüber nach - in der WSL läuft auf Ihrem Computer das vollständige grafische Windows-System (was in erster Linie eine schreckliche Ressource ist) sowie das Ubuntu-Subsystem. In nativem Ubuntu läuft nur Ubuntu.

— JimDeadlock
quelle

1

@ JimDeadlock Ich glaube wirklich nicht, dass es den Desktop tötet, es zeigt es einfach nicht an. Jede GUI-App läuft immer noch im Hintergrund, nicht wahr?

— Eric Duminil

2

Die Windows-GUI verbraucht etwas Speicher, benötigt aber nicht viel CPU, wenn Sie nichts tun. Ich verstehe nicht, warum dies erhebliche Auswirkungen hätte.

— Vidarlo

1

Wenn Sie die Konsole auf ein anderes VT umschalten, werden keine Prozesse abgebrochen. @EricDuminil ist richtig. Möglicherweise werden Dinge angehalten, die CPU-Zeit für Grafikaktualisierungen beanspruchten, da der X-Server weiß, dass diese nicht mehr angezeigt werden (und daher möglicherweise keine Zeit für die OpenGL-Verarbeitung oder sonstwas verschwenden). Aber wenn Sie pstreeoder ausführen ps auxw, ist es offensichtlich, dass alle Prozesse noch am Leben sind. (Oder topdrücken Sie M, um nach Speicherverbrauch zu sortieren.)

— Peter Cordes

2

@MichaelEricOberlin: Der Wechsel zu einem anderen VT hat keinen Einfluss auf den Runlevel! Es ist nur so, dass Textkonsolen immer noch in einem Runlevel verfügbar sind , mit dem GDM gestartet wird. (Und übrigens, Runlevel gehören im Grunde genommen der Vergangenheit an; systemdfunktionieren nicht wie SysV init. Der frühere Teil dieses Kommentars gibt vor, dass Sie eine 5- oder 10-jährige Linux-Distribution mit einem Old-School- initSetup ausgeführt haben.) Aber ja Wenn Sie sich von Ihrer X-Sitzung abmelden und X11 / GDM stoppen, werden Ressourcen freigesetzt, insbesondere wenn Sie keinen Auslagerungsspeicher haben oder Ihr Desktop einen Fehler aufweist, der häufig auftritt, selbst wenn Sie sich im Leerlauf befinden.

— Peter Cordes

1

@MichaelEricOberlin: Dein Kommentar ist ganz einfach falsch. Würden Sie es bitte löschen?

— Eric Duminil

1

Ich weiß nicht, ob dies insbesondere Ihre Simulation beeinflusst, aber es könnte:

WSL benutzt KEIN RAM für Shared Memory! Es nutzt die Festplatte!

Das bedeutet, wenn Ihre Simulation Shared Memory verwendet (think /dev/shm), kann dies langsam sein und / oder Ihr Speichergerät verschleißen! Und die Leistungsminderung kommt aus mehreren Schichten:

Der Dateisystemtreiber
Der Speichertreiber
Das Speichermedium

Wenn dies nicht der Fall ist, sollte die Leistung derjenigen von Bare-Metal-Ubuntu ähnlich sein (vorausgesetzt, es werden keine anderen E / A-Vorgänge ausgeführt, wie andere bereits erwähnt haben).

— Mehrdad
quelle

Wirklich gut zu wissen!

— ABCDEMMM