Esecuzione di una simulazione su Ubuntu puro vs su Ubuntu in Windows (WSL)

15

Vorrei porre una domanda sul test di una simulazione CAE di grandi dimensioni sullo stesso computer nelle seguenti due situazioni.

Sistema Ubuntu puro
Sistema Ubuntu in Windows 10 (WSL)

Le velocità di calcolo in entrambi i casi sono quasi le stesse o sono diverse?

windows windows-subsystem-for-linux benchmarks

— ABCDEMMM
fonte

4

Senza conoscere la natura della simulazione, è impossibile rispondere.

— muru,

1

@muru: non è così vago. Una "simulazione" è presumibilmente un lavoro in background intensivo dal punto di vista computazionale, che lo rende associato alla CPU o alla memoria. (Anche l'I / O del disco o della rete potrebbe essere un collo di bottiglia, ma è qualcosa che le persone che scrivono tali programmi tendono ad evitare, e alcuni moderni codici di simulazione potrebbero persino usare la GPU per il calcolo parallelo.) Si potrebbe facilmente scrivere (o scaricare) un benchmark che verifica tutti questi 2-5 possibili colli di bottiglia e controlla se esiste una differenza significativa tra WSL e Ubuntu nativo per ognuno di essi. Lo farei, ma non ho WSL (o Windows 10) disponibile.

— Ilmari Karonen,

3

@IlmariKaronen "presumibilmente". A seconda dei dati portati, potrebbe anche essere intensivo di I / O anche se associato alla CPU. E il resto del tuo commento è una buona ragione per chiudere questo: non abbiamo idea di quale possibile combinazione di strozzature sia importante qui.

— muru,

1

Bene, ho pubblicato una risposta, dal momento che risulta che i benchmark adeguati sono già online . Ovviamente, non posso dire con certezza se il codice di simulazione specifico del PO funzionerà più lentamente su WSL o no; ma in ogni caso, una risposta a questa domanda non è di alcuna utilità per nessuno tranne che per l'OP. Ciò a cui posso rispondere, in base ai parametri di riferimento, è quali tipi di codice di simulazione potrebbero ragionevolmente prevedere differenze di prestazioni tra WSL e Linux nativo.

— Ilmari Karonen,

@muru, è una simulazione CAE (Abaqus CAE).

— ABCDEMMM,

18

Il software di simulazione è probabilmente associato alla CPU o alla memoria . Per tali carichi di lavoro, non si farebbe eccezione per vedere alcuna differenza significativa tra l'esecuzione del codice su "bare metal" o all'interno di WSL (o qualsiasi altro livello di compatibilità o VM che utilizza l'esecuzione nativa), poiché in entrambi i casi il sistema operativo è principalmente in attesa mentre il codice di simulazione viene eseguito direttamente sulla CPU.

Tuttavia, è anche possibile che la simulazione sia almeno in parte legata all'I / O, ed è qui che possono emergere differenze. Apparentemente, WSL (attualmente) ha un livello di interfaccia del filesystem piuttosto lento che può rallentare significativamente l'I / O del disco. * Detto questo, mentre l'I / O del disco può essere il principale collo di bottiglia per molti tipi di attività di elaborazione di dati in blocco, una "simulazione" di solito non dovrebbe passare la maggior parte del tempo a leggere e scrivere file. Se il tuo è, potresti prendere in considerazione la possibilità di eseguirlo da un disco RAM (ad esempio tmpfs su ** Linux nativo) per evitare l'accesso al disco fisico inutile.

In ogni caso, l'unico modo per essere sicuri è testare la simulazione in entrambi gli ambienti e il tempo necessario per l'esecuzione. Prima di farlo, tuttavia, potresti voler dare un'occhiata ai benchmark esistenti, come questo benchmark delle prestazioni WSL vs. Docker vs. VirtualBox vs. Linux nativo di Phoronix da febbraio 2018 , ed esaminare i risultati di eventuali test che sottolineano gli stessi componenti del sistema come fa la tua simulazione.

(FWIW, i risultati di Phoronix sembrano corrispondere per lo più ai principi generali che ho delineato sopra, anche se ci sono alcune stranezze notevoli come VirtualBox che apparentemente ha sovraperformato Linux nativo in alcuni benchmark legati all'I / O, apparentemente a causa del suo disco virtuale che non sincronizza sempre immediatamente i dati al disco fisico. Un problema potenzialmente rilevante che non ho notato sopra è che i benchmark mostrano differenze significative nelle prestazioni OpenMP multi-thread sia tra i diversi ambienti host sia anche tra diverse distribuzioni Linux anche quando si esegue su hardware nudo. non è troppo sorprendente, dal momento che il threading e IPC sono gestiti dal kernel. Immagino che gran parte della differenza tra le distro potrebbe dipendere da diversi parametri di ottimizzazione del kernel di runtime e / o tempo di compilazione.)

^{*) Secondo questo post del blog MSDN del 2016, in realtà ci sono due componenti dell'interfaccia del filesystem in WSL: VolFs, che emula da vicino la semantica del filesystem Linux nativo su NTFS e viene utilizzato per montare eg /e /home, e DrvFs, che fornisce principalmente semantica simile a Windows e viene utilizzato per accedere alle unità Windows host tramite /mnt/cecc. Se il software in uso non richiede specificatamente funzionalità di filesystem Linux native come più collegamenti fissi allo stesso file, la configurazione per archiviare i propri file di dati in una cartella DrvFs può migliorare le prestazioni di accesso ai file su WSL.}

^{**) Secondo questo thread Reddit di maggio 2017, "tmpfs è attualmente emulato usando il disco" su WSL. A meno che qualcosa non sia cambiato nell'ultimo anno, ciò significa presumibilmente che l'uso di tmpfs su WSL non offre alcun vantaggio in termini di prestazioni rispetto all'utilizzo di un normale filesystem su disco.}

— Ilmari Karonen
fonte

Forse non solo sintonizzare i parametri, ma le opzioni del compilatore (ad es. -O3 -march=haswellO qualcosa del genere. Non so che Clear Linux effettivamente utilizza per costruire i loro kernel, ma forse BMI2 / popcnt/ qualunque cosa possa fare una differenza misurabile in glibc e nel kernel. (Il kernel ha vinto trarrà vantaggio da AVX, tuttavia, perché il kernel evita di toccare i registri FPU tranne in codici specifici come i dati di correzione degli errori software-RAID5 / 6.)

— Peter Cordes

12

Ubuntu in Windows (WSL - 2017 Fall Creators Update) è decisamente più lento di Ubuntu "puro" in ambiente Linux.

Ad esempio, la pittura dello schermo impiega molte volte più tempo in Windows 10 rispetto a Ubuntu 16.04, cioè puoi effettivamente vedere lo spostamento del cursore in Windows 10:

Ci vogliono circa 5 secondi per dipingere la schermata di avvio di WSL Bash. In confronto sono circa 1 1/2 secondi per la stessa schermata iniziale in Ubuntu 16.04:

Benchmarking della CPU

La prima sezione mostra quanto sia lento l'I / O sullo schermo, ma per quanto riguarda il benchmarking della CPU?

Da questo Ask Ubuntu Q&A: utility di benchmarking della CPU per Linux , ho eseguito test su Ubuntu 16.04 su Linux e Windows. Su Linux circa 24 secondi su Windows 10 versione 1709 circa 31 secondi. Linux è 6 secondi più veloce o circa il 25% più veloce. Tuttavia ho appena aggiornato Windows 10 alla versione 1803 (aggiornamento di Redstone 4 aka Spring Creators di aprile 2018) e ci sono voluti 24 secondi, che è lo stesso di Linux.

Ubuntu 16.04 su 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 su 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 su 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

NOTA: l' aggiornamento della primavera di Windows 10 per il 2018 (soprannominato Redstone 4 ) è uscito il 9 maggio (4 giorni fa) e lo installerò presto per verificare i miglioramenti. Senza dubbio ce ne sono molti. Quello che so di ciò che mi interessa è la capacità di eseguire cronlavori all'avvio. Ne ho bisogno per i backup giornalieri automatici su gmail.com.

NOTA 2: Ho appena installato Windows 10 Build 1803 (aprile 2018, Spring Creators Update AKA Redstone 4) e la pittura dello schermo è molto più veloce. Ora sono solo 3 secondi anziché 5 secondi per visualizzare la schermata iniziale di Bash. Il benchmark della CPU è alla pari con Linux ora.

— WinEunuuchs2Unix
fonte

8

Si noti che questo è fuorviante, ciò non distingue le prestazioni di I / O e altre prestazioni di calcolo. WSL è noto per essere lento per l'I / O (vedere ad esempio i benchmark Phoronix). Ciò non dice nulla sul fatto che i calcoli di OP possano essere eseguiti altrettanto velocemente in WSL.

— muru,

6

Sono sinceramente sorpreso che il disegno della schermata iniziale non sia efficace in entrambi i casi. Il tuo computer è (presumibilmente) felice di fare aggiornamenti dello schermo molto più complessi in pochi millisecondi, ad esempio durante la riproduzione di video. E l'ultima volta che ho visto un terminale lento come nella tua prima registrazione è stato nei primi anni '90, quando componevo un BBS sul mio modem a 2400 bps.

— Ilmari Karonen,

Cosa intendi con "Ubuntu in Linux"?

— Jon Bentley,

3

Onestamente, questo tipo di benchmark è completamente inutile per qualsiasi tipo di programma realistico, come qualsiasi benchmark che essenzialmente misura la velocità di verniciatura della console. O il collo di bottiglia del programma è l'I / O della console (che è notoriamente lento anche su Linux con la maggior parte degli emulatori di terminale), o questa non è una misura affidabile di nulla di utile.

— Matteo Italia,

2

@ WinEunuuchs2Unix Da quello che posso vedere, c'è poca computazione. ma un sacco di I / O: recuperare il meteo da qualche parte, leggere la data e l'ora e stamparlo in un formato, leggere le informazioni di sistema, ecc. Comunque, hai mai usato Abaqus? I software di simulazione come Ansys o Simulink non sono associati allo I / O dello schermo quando si esegue la simulazione effettiva, a meno che non si imponga tale simulazione. È perfettamente possibile che questi mostrino i risultati giusti a seconda della simulazione effettuata.

— muru,

7

Pensaci: in WSL il tuo computer sta eseguendo l'intero sistema grafico di Windows (che è un orribile maiale delle risorse in primo luogo) più il sottosistema Ubuntu. In Ubuntu nativo esegue solo Ubuntu.

— JimDeadlock
fonte

1

@JimDeadlock Non credo davvero che uccida il desktop, semplicemente non lo visualizza. Ogni app gui è ancora in esecuzione in background, vero?

— Eric Duminil,

2

La GUI di Windows consuma un po 'di memoria, ma non molto uso della CPU quando non si fa nulla. Non vedo perché ciò avrebbe un impatto significativo?

— vidarlo,

1

Passare la console a un altro VT non uccide alcun processo; @EricDuminil è corretto. Potrebbe mettere in pausa le cose che utilizzavano il tempo della CPU per eseguire gli aggiornamenti grafici, perché il server X sa che non viene più visualizzato (e quindi non può perdere tempo sull'elaborazione OpenGL o altro). Ma se si esegue pstreeo ps auxw, è ovvio che tutti i processi sono ancora vivi. (O tope premi M per ordinare in base al consumo di memoria).

— Peter Cordes,

2

@MichaelEricOberlin: il passaggio a un altro VT non influisce sul runlevel! È solo che le console di testo sono ancora disponibili in un runlevel che avvia GDM. (E a proposito, i runlevel sono fondamentalmente un ricordo del passato; systemdnon funziona come SysV init. La prima parte di questo commento fa finta che stavi eseguendo una distribuzione Linux di 5 o 10 anni con una initconfigurazione vecchia scuola .) Ma sì , disconnettersi dalla sessione X e arrestare X11 / GDM libererà risorse, soprattutto se non si dispone di spazio di scambio o se il desktop presenta schifezze che si riattivano frequentemente anche quando sono "inattive".

— Peter Cordes,

1

@MichaelEricOberlin: il tuo commento è semplicemente sbagliato. Potresti considerare di eliminarlo?

— Eric Duminil,

1

Non so se questo influenzerà in particolare la tua simulazione, ma potrebbe:

WSL NON utilizza RAM per la memoria condivisa! Usa il disco!

Questo significa che se la tua simulazione utilizza memoria condivisa (pensa /dev/shm), potrebbe essere lenta e / o consumare il tuo dispositivo di archiviazione! E la penalità prestazionale viene da diversi livelli:

Il driver del file system
Il driver di archiviazione
Il supporto di memorizzazione

Ma se non lo fa, le prestazioni dovrebbero essere simili a quelle su Ubuntu bare metal (supponendo nessun altro I / O, come altri hanno già detto).

— user541686
fonte

davvero bello saperlo!

— ABCDEMMM,