Windows'ta Ubuntu üzerinde saf Ubuntu üzerinde bir simülasyon çalıştırma (WSL)

15

Aşağıdaki iki durumda aynı bilgisayarda büyük bir CAE simülasyonunu test etme hakkında bir soru sormak istiyorum .

Saf Ubuntu sistemi
Windows 10'da Ubuntu sistemi (WSL)

Her iki durumda da hesaplama hızları neredeyse aynı mı yoksa farklı mı?

windows windows-subsystem-for-linux benchmarks

— ABCDEMMM
kaynak

4

Simülasyonun doğasını bilmeden, bunu cevaplamak imkansızdır.

— muru

1

@muru: O kadar belirsiz değil . Bir "simülasyon", muhtemelen CPU veya bellek bağlı hale getiren, hesaplama açısından yoğun bir arka plan işidir. (Disk veya ağ G / Ç'si de bir darboğaz olabilir, ancak bu tür programları yazan insanların kaçınmaya eğilimli olduğu bir şeydir ve bazı modern simülasyon kodları GPU'yu paralel hesaplama için bile kullanabilir.) Bir kıyaslama kolayca yazabilir (veya indirebilir) tüm bu 2 ila 5 olası darboğazları test eder ve WSL ile yerel Ubuntu arasında herhangi biri için önemli bir fark olup olmadığını kontrol eder. Yapardım ama WSL (veya Windows 10) mevcut değil.

— Ilmari Karonen

3

@IlmariKaronen "muhtemelen". Çatlamış getirilen verilere bağlı olarak, CPU bağlı olsa bile IO yoğun olabilir. Ve yorumunuzun geri kalanı bunu kapatmak için oldukça iyi bir neden - burada olası darboğaz kombinasyonunun önemli olduğu hakkında hiçbir fikrimiz yok.

— muru

1

Bir cevap gönderdim, çünkü uygun kriterlerin zaten çevrimiçi olduğu ortaya çıktı . Açıkçası, OP'nin özel simülasyon kodunun WSL'de daha yavaş çalışıp çalışmayacağını kesin olarak söyleyemem; ancak her durumda, bu sorunun cevabı zaten OP'den başka kimsenin faydası değildir. Karşılaştırma ölçütlerine dayanarak cevaplayabileceğim şey, ne tür simülasyon kodlarının WSL ve yerel Linux arasında performans farklılıklarına sahip olması beklenebilir.

— Ilmari Karonen

muru, bir CAE Simülasyonudur (Abaqus CAE).

— ABCDEMMM

18

Simülasyon yazılımınız büyük olasılıkla CPU veya hafızaya bağlıdır . Bu tür iş yükleri için, kodun "çıplak metal" veya WSL içinde (veya yerel yürütme kullanan başka bir uyumluluk katmanı veya VM) içinde çalıştırılması arasında önemli bir fark görülmemesi dışında, her iki durumda da işletim sistemi çoğunlukla simülasyon kodu doğrudan CPU üzerinde çalışır.

Bununla birlikte, simülasyonunuzun en azından kısmen I / O bağlı olması da mümkündür ve bu noktada farklılıklar ortaya çıkabilir. Görünüşe göre, WSL (şu anda) disk G / Ç'sini önemli ölçüde yavaşlatabilecek oldukça yavaş bir dosya sistemi arayüz katmanına sahiptir. * Bununla birlikte, disk G / Ç, birçok toplu veri işleme görevi için büyük bir darboğaz olsa da, bir "simülasyon" genellikle gerektiği değil onun zaman okuma ve yazma dosyalarının çoğunluğunu harcama. Sizinki buysa, gereksiz fiziksel disk erişiminden kaçınmak için bir RAM diskinden (örn. Yerel ** Linux'ta tmpfs) çalıştırmayı düşünebilirsiniz.

Her durumda, emin olmanın tek yolu, simülasyonunuzu hem ortamlarda hem de çalıştırmanın ne kadar sürdüğü test etmektir. Ancak bunu yapmadan önce , Şubat 2018'deki Phoronix'in WSL ve Docker ile VirtualBox'a karşı yerel Linux performans karşılaştırması gibi mevcut kıyaslamalara bakmak ve aynı bileşenleri vurgulayan testlerin sonuçlarını incelemek isteyebilirsiniz. simülasyonun yaptığı gibi sistemin

(FWIW, Phoronix sonuçları çoğunlukla yukarıda özetlediğim genel ilkelere uyuyor gibi görünüyor, ancak görünüşe göre sanal diski her zaman hemen veri senkronize etmemesi nedeniyle VirtualBox gibi yerel Linux'u birkaç I / O bağlı ölçütte daha iyi performans gösteren birkaç tuhaflık var. Yukarıda not edemediğim, potansiyel olarak alakalı bir sorun, karşılaştırmalı değerlendirmelerin hem farklı ana bilgisayar ortamları hem de farklı Linux dağıtımları arasında çok iş parçacıklı OpenMP performansında önemli farklılıklar göstermesidir çıplak donanım üzerinde çalışırken bile . Bu çok şaşırtıcı değil, çünkü iş parçacığı ve IPC çekirdek tarafından işleniyor. Dağıtımlar arasındaki farkın çoğunun farklı çalışma zamanı ve / veya derleme zamanı çekirdek parametrelerini derleyebileceğini tahmin ediyorum.)

^{*) Göre bu MSDN blog yayınında yakından NTFS üzerinde yerel Linux dosya sistemi semantiğini öykünür ve örneğin monte etmek için kullanılır Volfs: 2016 den, WSL iki dosya sistemi arayüzü bileşenleri aslında var /ve /homeve DrvFs çoğunlukla semantik Windows benzeri sağlayan, ve ev sahibi, Windows sürücülere erişim için kullanılan üzeri /mnt/cvb yazılım özellikle yerel Linux dosya sistemi klasör DrvFs kendi veri dosyalarını depolamak için yapılandırılırken, aynı dosyaya birden sert bağlantıları gibi özellikler gerektirmiyorsa olabilir dosya erişim performansını artırmak WSL.}

^{**) Mayıs 2017'deki bu Reddit iş parçacığına göre , WSL'de "tmpfs şu anda disk kullanılarak taklit ediliyor". Geçtiğimiz yıl içinde bir şey değişmedikçe, bu muhtemelen WSL'de tmpfs kullanmanın normal bir disk-içi dosya sistemi kullanmaya kıyasla hiçbir performans avantajı sağlamadığı anlamına gelir.}

— Ilmari Karonen
kaynak

Belki sadece parametreleri ayarlamakla kalmaz, aynı zamanda derleyici seçenekleri de (örn. -O3 -march=haswellYa da bir şey. Clear Linux'un çekirdeklerini oluşturmak için gerçekte ne kullandığını bilmiyorum, belki de BMI2 / popcnt/ glibc ve çekirdekte ölçülebilir bir fark yaratabilecek ne varsa. Ancak AVX'den faydalanmayın çünkü çekirdek, yazılım-RAID5 / 6 hata düzeltme verileri gibi belirli kodlar dışında FPU kayıtlarına dokunmaktan kaçınır.)

— Peter Cordes

12

Windows'ta Ubuntu (WSL - 2017 Fall Creators Update) Linux ortamında "Pure" Ubuntu'dan kesinlikle daha yavaş.

Örneğin, ekran resmi Windows 10'da Ubuntu 16.04'e göre çok daha uzun sürer, yani imlecin Windows 10'da hareket ettiğini görebilirsiniz:

WSL Bash açılış ekranının boyanması yaklaşık 5 saniye sürer. Karşılaştırıldığında, Ubuntu 16.04'teki aynı açılış ekranı için yaklaşık 1 1/2 saniye:

CPU Kıyaslama

İlk bölüm ekran I / O'nun ne kadar yavaş olduğunu gösteriyor ancak CPU karşılaştırması ne olacak?

Bu Ask Ubuntu Q&A: Linux için CPU kıyaslama yardımcı programı , Linux ve Windows üzerinde Ubuntu 16.04 üzerinde testler yaptım. Linux'ta Windows 10 sürüm 1709'da yaklaşık 24 saniye, yaklaşık 31 saniye. Linux 6 saniye daha hızlı veya yaklaşık% 25 daha hızlı. Ancak Windows 10'u 1803 sürümüne (Redstone 4 aka Spring Creators Nisan 2018 güncellemesi) yükselttim ve Linux ile aynı olan 24 saniye sürdü.

Linux'ta Ubuntu 16.04

$ 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

Windows 10 yapı 1709 üzerinde Ubuntu 16.04

$ 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

Windows 10 derleme 1803 üzerinde Ubuntu 16.04

$ 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

NOT: 2018 için Windows 10 bahar güncellemesi ( Redstone 4 olarak adlandırıldı ) 9 Mayıs'ta (4 gün önce) çıktı ve geliştirmeleri kontrol etmek için yakında yükleyeceğim. Şüphesiz çok var. Beni ilgilendirdiğini bildiğim biri koşma yeteneğidircron başlangıçta iş . Gmail.com otomatik günlük yedeklemeler için buna ihtiyacım var.

NOT 2: Windows 10 Build 1803'ü (Nisan 2018 İlkbahar Yaratıcıları AKA Redstone 4 Güncellemesi) yeni kurdum ve ekran resmi çok daha hızlı. Bash açılış ekranını görüntülemek artık 5 saniye yerine sadece 3 saniyedir. CPU karşılaştırması şimdi Linux ile eşit.

— WinEunuuchs2Unix
kaynak

8

Bunun yanıltıcı olduğunu unutmayın - bu, G / Ç performansını ve diğer hesaplama performansını ayırt etmez. WSL'nin G / Ç için yavaş olduğu bilinir (bkz., Ör., Phoronix kıyaslamaları). Bu OP'nin hesaplamalarının WSL'deki kadar hızlı yapıp yapamayacağı hakkında hiçbir şey söylemez.

— muru

6

Her iki durumda da açılış ekranını çizmenin etkili bir şekilde anında olmadığına gerçekten şaşırıyorum. Bilgisayarınız, örneğin video oynatırken birkaç milisaniye içinde çok daha karmaşık ekran güncellemeleri yapmaktan (muhtemelen) mutludur. Son kez, ilk kaydınızdaki kadar yavaş bir terminal gördüm, 90'ların başında, 2400 bps modemime bir BBS ararken.

— Ilmari Karonen

"Linux'ta Ubuntu" ile ne demek istiyorsun?

— Jon Bentley

3

Dürüst olmak gerekirse, bu tür bir kıyaslama, konsol boyama hızını esasen ölçen herhangi bir kıyaslama gibi, her türlü gerçekçi program için tamamen işe yaramaz. Program darboğazı konsol I / O (çoğu terminal emülatörlü Linux'ta bile kötü bir şekilde yavaş) veya bu yararlı bir şeyin güvenilir bir ölçüsü değil.

— Matteo Italia

2

@ WinEunuuchs2Unix Görebildiğim kadarıyla, küçük bir hesaplama var. ama bir çok I / O: havayı bir yerden almak, tarih ve saati okumak ve bir biçimde yazdırmak, sistem bilgilerini okumak vb. Her neyse, hiç Abaqus kullandınız mı? Bunun gibi simülasyon yazılımı veya Ansys veya Simulink, simülasyonu zorlamadığınız sürece gerçek simülasyonu çalıştırırken ekrana G / Ç bağlı değildir . Bunların, yapılan simülasyona bağlı olarak doğru sonuçları göstermeleri mükemmel bir şekilde mümkündür.

— muru

7

Bir düşünün - WSL'de bilgisayarınız tam grafiksel Windows sistemini (ilk etapta korkunç bir kaynak domuzudur) artı Ubuntu alt sistemini çalıştırıyor. Yerel Ubuntu'da sadece Ubuntu çalışıyor.

— JimDeadlock
kaynak

1

@JimDeadlock Masaüstünü gerçekten öldürdüğünü düşünmüyorum, sadece görüntülemiyor. Her gui uygulaması hala arka planda çalışıyor, değil mi?

— Eric Duminil

2

Windows GUI biraz bellek tüketir, ancak hiçbir şey yapmazken CPU kullanımı fazla değildir. Bunun neden önemli bir etkisi olduğunu anlamıyorum?

— vidarlo

1

Konsolu farklı bir VT'ye değiştirmek hiçbir işlemi öldürmez; @EricDuminil doğru. Grafik sunucusu güncellemeleri yapmak için CPU zamanını kullanan şeyleri duraklatabilir, çünkü X sunucusu artık görüntülenmediğini bilir (ve bu nedenle OpenGL işlemlerinde veya herhangi bir şeyde hiç zaman kaybetmeyebilir). Ama koşarsanız pstreeya da ps auxw, tüm süreçlerin hala hayatta olduğu açıktır. (Veya topbellek tüketimine göre sıralamak için M tuşuna basın).

— Peter Cordes

2

@MichaelEricOberlin: Başka bir VT'ye geçmek çalışma seviyesini etkilemez! Sadece metin konsolları GDM'yi başlatan bir çalışma seviyesinde hala mevcut . (Ve BTW, çalışma seviyeleri temelde geçmişte kaldı; systemdSysV gibi çalışmıyor init. Bu yorumun daha önceki kısmı, eski bir okul initkurulumuyla 5 veya 10 yıllık bir Linux dağıtımı yapıyormuş gibi davranıyor .) Ama evet , X oturumunuzdan çıkış yapmak ve X11 / GDM'yi durdurmak, özellikle takas alanınız yoksa veya masaüstünüzde "boşta" olduğunda bile sık sık uyanan bok var.

— Peter Cordes

1

@MichaelEricOberlin: Yorumunuz oldukça basit. Lütfen silmeyi düşünür müsünüz?

— Eric Duminil

1

Bunun özellikle simülasyonunuzu etkileyip etkilemeyeceğini bilmiyorum, ancak:

WSL DEĞİL paylaşılan bellek için RAM ! Diski kullanır!

Bu, simülasyonunuz paylaşılan bellek kullanıyorsa (düşünün /dev/shm) yavaş olabilir ve / veya depolama cihazınızı yıpranmış olabilir! Ve performans cezası birkaç katmandan geliyor :

Dosya sistemi sürücüsü
Depolama sürücüsü
Depolama ortamı

Ancak bunu yapmazsa, performans çıplak metal Ubuntu'ndakine benzer olmalıdır (diğerlerinin belirttiği gibi başka G / Ç olmadığı varsayılırsa).

— user541686
kaynak

bunu bilmek gerçekten çok iyi!

— ABCDEMMM