Menjalankan simulasi di Ubuntu murni vs di Ubuntu di Windows (WSL)

15

Saya ingin mengajukan pertanyaan tentang pengujian simulasi CAE besar pada komputer yang sama dalam dua situasi berikut.

  1. Sistem Ubuntu murni
  2. Sistem Ubuntu di Windows 10 (WSL)

Apakah kecepatan perhitungan dalam kedua kasus hampir sama atau mereka berbeda?

windows windows-subsystem-for-linux benchmarks ABCDEMMM
sumber
4
Tanpa mengetahui sifat simulasi, ini tidak mungkin dijawab.
muru
1
@uru: Itu tidak samar - samar. "Simulasi" mungkin merupakan pekerjaan latar belakang yang intensif secara komputasi, yang membuatnya terikat dengan CPU atau memori. (Disk atau I / O jaringan mungkin juga menjadi penghambat, tetapi itu adalah sesuatu yang cenderung dihindari oleh orang-orang yang menulis program semacam itu, dan beberapa kode simulasi modern bahkan dapat menggunakan GPU untuk komputasi paralel.) Orang dapat dengan mudah menulis (atau mengunduh) benchmark yang menguji semua 2 hingga 5 kemungkinan kemacetan ini, dan memeriksa apakah ada perbedaan yang signifikan antara WSL dan Ubuntu asli untuk semuanya. Saya akan melakukannya, tetapi saya tidak memiliki WSL (atau Windows 10) tersedia.
Ilmari Karonen
3
@IlmariKaronen "mungkin". Tergantung pada data yang dibawa, itu bisa menjadi IO intensif bahkan jika CPU terikat. Dan sisa komentar Anda adalah alasan yang cukup bagus untuk menutup ini - kami tidak tahu apa kombinasi kemacetan yang mungkin terjadi di sini.
muru
1
Yah, saya memang mengirim jawaban, karena ternyata tolok ukur yang sesuai sudah online . Jelas, saya tidak bisa mengatakan dengan pasti apakah kode simulasi spesifik OP akan berjalan lebih lambat di WSL atau tidak; tetapi bagaimanapun, jawaban untuk pertanyaan itu tidak berguna bagi siapa pun kecuali OP. Apa yang bisa saya jawab, berdasarkan tolok ukur, adalah jenis kode simulasi apa yang bisa diharapkan memiliki perbedaan kinerja antara WSL dan Linux asli.
Ilmari Karonen
@muru, ini adalah Simulasi CAE (Abaqus CAE).
ABCDEMMM

Jawaban:

18

Perangkat lunak simulasi Anda kemungkinan besar terikat dengan CPU atau terikat memori . Untuk beban kerja seperti itu, orang tidak akan kecuali melihat perbedaan yang signifikan antara menjalankan kode pada "bare metal" atau di dalam WSL (atau lapisan kompatibilitas lain atau VM yang menggunakan eksekusi asli), karena dalam kedua kasus OS sebagian besar hanya menunggu sedangkan kode simulasi berjalan langsung pada CPU.

Namun, ada kemungkinan juga bahwa simulasi Anda setidaknya sebagian terikat I / O, dan di situlah perbedaan mungkin muncul. Rupanya, WSL (saat ini) memiliki lapisan antarmuka sistem file yang agak lambat yang dapat memperlambat disk I / O secara signifikan. * Itu mengatakan, sementara disk I / O dapat menjadi hambatan utama untuk berbagai jenis tugas pemrosesan data massal, sebuah "simulasi" biasanya tidak menghabiskan sebagian besar waktunya untuk membaca dan menulis file. Jika milik Anda, Anda mungkin ingin mempertimbangkan untuk menjalankannya dari disk RAM (mis. Tmpfs pada native ** Linux) untuk menghindari akses disk fisik yang tidak perlu.

Bagaimanapun, satu-satunya cara untuk memastikan adalah menguji simulasi Anda di kedua lingkungan dan waktu berapa lama untuk berjalan. Namun, sebelum melakukan itu, Anda mungkin ingin melihat tolok ukur yang ada, seperti WSL vs Docker vs VirtualBox vs tolok ukur kinerja Linux asli oleh Phoronix dari Februari 2018 , dan periksa hasilnya untuk setiap tes yang menekankan komponen yang sama dari sistem seperti simulasi Anda.

(FWIW, hasil Phoronix tampaknya sebagian besar cocok dengan prinsip-prinsip umum yang saya uraikan di atas, meskipun ada beberapa keanehan yang menonjol seperti VirtualBox yang ternyata mengungguli Linux asli dalam beberapa tolok ukur terikat I / O, tampaknya karena disk virtualnya tidak selalu segera menyinkronkan data ke disk fisik .Salah satu masalah yang berpotensi relevan yang saya gagal catat di atas adalah bahwa tolok ukur menunjukkan perbedaan signifikan dalam kinerja OpenMP multi-threaded baik antara lingkungan host yang berbeda dan juga antara distro Linux yang berbeda bahkan ketika berjalan pada perangkat keras yang telanjang. itu tidak terlalu mengejutkan, karena threading dan IPC ditangani oleh kernel. Saya kira banyak perbedaan antara distro-distro yang ada mungkin disebabkan oleh runtime yang berbeda dan / atau kompilasi parameter tuning kernel waktu.)

*) Menurut posting blog MSDN ini dari 2016, sebenarnya ada dua komponen antarmuka sistem file di WSL: VolFs, yang secara dekat mengemulasi semantik sistem file Linux asli di atas NTFS dan digunakan untuk me-mount eg /dan /home, dan DrvFs, yang menyediakan sebagian besar semantik seperti Windows dan digunakan untuk mengakses drive Windows host melalui /mnt/cdll. Jika perangkat lunak Anda tidak secara khusus memerlukan fitur sistem file Linux asli seperti banyak tautan keras ke file yang sama, mengonfigurasinya untuk menyimpan file datanya dalam folder DrvFs dapat meningkatkan kinerja akses file pada WSL.

**) Menurut utas Reddit ini dari Mei 2017, "tmpfs saat ini ditiru menggunakan disk" di WSL. Kecuali ada sesuatu yang berubah selama setahun terakhir, ini mungkin berarti bahwa menggunakan tmpfs pada WSL tidak memberikan manfaat kinerja dibandingkan menggunakan sistem file pada disk normal.

Ilmari Karonen
sumber
Mungkin bukan hanya parameter tuning, tetapi opsi kompiler (misalnya -O3 -march=haswellatau sesuatu. Saya tidak tahu apa yang sebenarnya digunakan Clear Linux untuk membangun kernel mereka, tetapi mungkin BMI2 / popcnt/ apa pun yang dapat membuat perbedaan yang terukur dalam glibc dan kernel. (Kernel menang akan mendapat manfaat dari AVX, karena kernel menghindari menyentuh register FPU kecuali dalam kode spesifik seperti data-error-koreksi data perangkat lunak RAID5 / 6.)
Peter Cordes
12

Ubuntu di Windows (WSL - 2017 Fall Creators Update) jelas lebih lambat dari Ubuntu "Murni" di lingkungan Linux.

Misalnya pengecatan layar membutuhkan waktu beberapa kali lebih lama di Windows 10 dibandingkan Ubuntu 16.04, artinya Anda sebenarnya dapat melihat pergerakan kursor di Windows 10:

WSL bash startup.gif

Diperlukan waktu sekitar 5 detik untuk mengecat layar WSL Bash. Sebagai perbandingan, ini sekitar 1 1/2 detik untuk layar splash yang sama di Ubuntu 16.04:

Terminal Ubuntu splash.gif

Benchmarking CPU

Bagian pertama menunjukkan betapa lambatnya I / O layar tetapi bagaimana dengan pembandingan CPU?

Dari Tanya Jawab tentang Ubuntu ini: Utilitas benchmark CPU untuk Linux , saya menjalankan pengujian pada Ubuntu 16.04 di Linux dan Windows. Di Linux sekitar 24 detik pada Windows 10 versi 1709 sekitar 31 detik. Linux 6 detik lebih cepat atau sekitar 25% lebih cepat. Namun saya hanya memutakhirkan Windows 10 ke versi 1803 (pembaruan Redstone 4 alias Spring Creators April 2018) dan butuh 24 detik yang sama dengan Linux.

Ubuntu 16.04 di 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 pada 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 pada 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

CATATAN: Pembaruan Windows 10 musim semi untuk 2018 (dijuluki Redstone 4 ) keluar pada 9 Mei (4 hari yang lalu) dan saya akan segera menginstalnya untuk memeriksa peningkatan. Tak ayal ada banyak. Satu yang saya tahu yang menarik minat saya adalah kemampuan untuk menjalankan cronpekerjaan di startup. Saya memerlukannya untuk backup harian otomatis ke gmail.com.

CATATAN 2: Saya baru saja menginstal Windows 10 Build 1803 (April 2018 Spring Creators Update AKA Redstone 4) dan lukisan layar jauh lebih cepat. Sekarang hanya 3 detik, bukan 5 detik untuk menampilkan layar splash Bash. Benchmark CPU setara dengan Linux sekarang.

WinEunuuchs2Unix
sumber
8
Perhatikan bahwa ini menyesatkan - ini tidak membedakan kinerja I / O dan kinerja komputasi lainnya. WSL dikenal lambat untuk I / O (lihat misalnya, tolok ukur Phoronix). Itu tidak mengatakan apa-apa tentang apakah perhitungan OP dapat dilakukan secepat WSL.
muru
6
Jujur saya terkejut bahwa menggambar layar splash tidak efektif instan dalam kedua kasus. Komputer Anda (mungkin) senang melakukan pembaruan layar yang jauh lebih kompleks dalam beberapa milidetik, misalnya saat memutar video. Dan terakhir kali saya melihat terminal selambat dalam rekaman pertama Anda di awal 90-an, ketika memutar BBS pada modem 2400 bps saya.
Ilmari Karonen
Apa yang Anda maksud dengan "Ubuntu di Linux"?
Jon Bentley
3
Jujur, tolok ukur semacam ini sama sekali tidak berguna untuk semua jenis program realistis, karena tolok ukur apa pun yang pada dasarnya mengukur kecepatan mengecat konsol. Kemacetan program Anda adalah konsol I / O (yang terkenal lambat bahkan di Linux dengan kebanyakan emulator terminal), atau ini bukan ukuran yang dapat diandalkan untuk hal apa pun yang berguna.
Matteo Italia
2
@ WinEunuuchs2Unix Dari apa yang bisa saya lihat, ada sedikit kompuasi. tetapi banyak I / O: mengambil cuaca dari suatu tempat, membaca tanggal dan waktu, dan mencetaknya dalam format, membaca informasi sistem, dll. Lagi pula, apakah Anda pernah menggunakan Abaqus? Perangkat lunak simulasi seperti itu atau Ansys atau Simulink tidak terikat layar I / O ketika menjalankan simulasi yang sebenarnya kecuali Anda memaksakan simulasi menjadi demikian. Sangat mungkin bagi ini untuk menunjukkan hasil akhir hanya tergantung pada simulasi yang dilakukan.
muru
7

Pikirkan tentang hal ini - di WSL komputer Anda menjalankan sistem grafis Windows penuh (yang merupakan sumber daya yang mengerikan di tempat pertama) ditambah subsistem Ubuntu. Di Ubuntu asli itu hanya menjalankan Ubuntu.

JimDeadlock
sumber
1
@ JimDeadlock Saya benar-benar tidak berpikir itu membunuh desktop, hanya saja tidak menampilkannya. Setiap aplikasi gui masih berjalan di latar belakang, bukan?
Eric Duminil
2
Windows GUI mengkonsumsi beberapa memori, tetapi tidak terlalu banyak menggunakan CPU ketika tidak melakukan apa-apa. Saya tidak mengerti mengapa itu akan berdampak signifikan?
vidarlo
1
Beralih konsol ke VT yang berbeda tidak mematikan proses apa pun; @EricDuminil benar. Mungkin menghentikan hal-hal yang menggunakan waktu CPU untuk melakukan pembaruan grafik, karena server X tahu itu tidak lagi ditampilkan (dan dengan demikian mungkin tidak membuang waktu pada pemrosesan OpenGL atau apa pun). Tetapi jika Anda menjalankan pstreeatau ps auxw, sudah jelas bahwa semua proses masih hidup. (Atau topdan tekan M untuk mengurutkan berdasarkan konsumsi memori).
Peter Cordes
2
@MichaelEricOberlin: Mengubah ke VT lain tidak mempengaruhi runlevel! Hanya saja konsol teks masih tersedia di runlevel yang memulai GDM. (Dan BTW, runlevel pada dasarnya adalah sesuatu dari masa lalu; systemdtidak berfungsi seperti SysV init. Bagian awal dari komentar ini berpura-pura bahwa Anda menjalankan distro Linux berusia 5 atau 10 tahun dengan initpengaturan sekolah lama .) Tapi ya , keluar dari sesi X Anda dan menghentikan X11 / GDM akan membebaskan sumber daya, terutama jika Anda tidak memiliki ruang swap, atau desktop Anda memiliki omong kosong yang sering bangun bahkan ketika "idle".
Peter Cordes
1
@MichaelEricOberlin: Komentar Anda salah besar. Bisakah Anda mempertimbangkan untuk menghapusnya?
Eric Duminil
1

Saya tidak tahu apakah ini akan mempengaruhi simulasi Anda secara khusus, tetapi mungkin:

WSL TIDAK menggunakan RAM untuk memori bersama! Itu menggunakan disk!

Ini berarti, jika simulasi Anda menggunakan memori bersama (berpikir /dev/shm), mungkin lambat dan / atau usang perangkat penyimpanan Anda! Dan penalti kinerja datang dari beberapa lapisan:

  • Driver sistem file

  • Driver penyimpanan

  • Media penyimpanan

Tetapi jika tidak melakukan ini, maka kinerjanya harus sama dengan yang ada pada Ubuntu bare-metal (dengan asumsi tidak ada I / O lain, seperti yang disebutkan orang lain).

pengguna541686
sumber
sangat bagus untuk mengetahuinya!
ABCDEMMM