次の2つの状況で同じコンピューターで大規模なCAEシミュレーションをテストすることについて質問したいと思います。
どちらの場合も計算速度はほぼ同じですか、それとも異なりますか?
シミュレーションソフトウェアは、おそらく CPUバウンドまたはメモリバウンド です。このようなワークロードの場合、コードを「ベアメタル」で実行するか、WSL内で実行するか(または他の 互換性レイヤー またはVMネイティブ実行を使用する) )、どちらの場合でも、シミュレーションコードがCPU上で直接実行されている間、OSはほとんど待機しているだけです。
ただし、シミュレーションが少なくとも部分的にI/Oバウンドである可能性もあり、そこから違いが生じる可能性があります。どうやら、WSLには(現在)かなり遅いファイルシステムインターフェイスレイヤーがあり、ディスクI/Oを大幅に遅くする可能性があります。*とはいえ、ディスクI/Oは多くの種類のバルクデータ処理タスクの主要なボトルネックになり得る一方で、「シミュレーション」通常、notはファイルの読み取りと書き込みの時間の大半を費やすべきではありません。必要な場合は、RAMディスク(ネイティブ** Linuxのtmpfsなど)から実行することを検討して、不必要な物理ディスクアクセスを回避することができます。
いずれの場合でも、確認する唯一の方法は、両方の環境でシミュレーションをテストし、実行にかかる時間です。ただし、それを行う前に、次のような既存のベンチマークを確認することをお勧めします 2018年2月からのPhoronixによるWSL対Docker対VirtualBox対ネイティブLinuxパフォーマンスベンチマーク 、シミュレーションと同じシステムのコンポーネントに負荷をかけるテスト。
(FWIW、Phoronixの結果は上記で概説した一般的な原則とほぼ一致しているように見えますが、VirtualBoxのようないくつかの注目すべき奇妙な点がいくつかのI/Oバウンドベンチマークで明らかにネイティブLinuxを上回っています。上記で注意しなかった潜在的に関連する問題の1つは、ベンチマークが、異なるホスト環境と異なるLinuxディストリビューションの両方でマルチスレッドOpenMPパフォーマンスに大きな違いを示すことです裸のハードウェアで実行している場合でも、スレッドとIPCがカーネルによって処理されるため、後から考えると、それほど驚くことではありません。異なるランタイムおよび/またはコンパイル時カーネル調整パラメータ。
*) このMSDNブログの投稿 2016年から、実際にはWSLに2つのファイルシステムインターフェイスコンポーネントがあります。VolFsは、NTFSを介してネイティブLinuxファイルシステムセマンティクスをエミュレートし、マウントに使用されます。 /
および/home
、およびDrvFs。主にWindowsに似たセマンティクスを提供し、/mnt/c
などを介してホストWindowsドライブにアクセスするために使用されます。ソフトウェアが特にネイティブLinuxファイルシステムを必要としない場合同じファイルへの複数のハードリンクのような機能、データファイルをDrvFsフォルダーに保存するように構成するmayは、WSLのファイルアクセスパフォーマンスを向上させます。
**)2017年5月の このRedditスレッド によれば、WSLの「tmpfsは現在ディスクを使用してエミュレートされています」。過去1年で何かが変更されていない限り、これはおそらく、WSLでtmpfsを使用しても通常のオンディスクファイルシステムを使用した場合よりもパフォーマンスが向上しないことを意味します。
WindowsのUbuntu(WSL-2017 Fall Creators Update)は、Linux環境の「純粋な」Ubuntuよりも明らかに遅いです。
たとえば、Windows 10ではスクリーンペインティングにUbuntu 16.04と比べて何倍も時間がかかります。つまり、Windows 10ではカーソルが実際に移動するのを見ることができます。
WSL Bashスプラッシュスクリーンがペイントするのに約5秒かかります。比較すると、Ubuntu 16.04の同じスプラッシュスクリーンの場合、約1 1/2秒です。
最初のセクションでは、画面I/Oの速度が遅いことを示していますが、CPUベンチマークについてはどうですか?
このUbuntuの質問に関するQ&A: LinuxのCPUベンチマークユーティリティ から、LinuxおよびWindows上のUbuntu 16.04でテストを実行しました。 Linuxでは、Windows 10バージョン1709では約24秒、約31秒です。 Linuxは6秒高速で、約25%高速です。ただし、Windows 10をバージョン1803(Redstone 4別名Spring Creators April 2018 update)にアップグレードしたところ、Linuxと同じ24秒かかりました。
$ 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
$ 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
$ 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
注:2018年のWindows 10春の更新(Redstone 4)と呼ばれました) 5月9日(4日前)にリリースされ、すぐにインストールして改善を確認します。間違いなくたくさんあります。私が興味を持っていることの1つは、起動時にcron
ジョブを実行できることです。 gmail.comへの毎日の自動バックアップに必要です。
注2:Windows 10ビルド1803(2018年4月Spring Creators Update別名Redstone 4)をインストールしたばかりで、画面の描画ははるかに高速です。 Bashスプラッシュ画面を表示するのに、5秒ではなく3秒になりました。 CPUベンチマークは現在Linuxと同等です。
それについて考えてみてください-WSLでは、コンピューターは完全なグラフィカルWindowsシステム(最初は恐ろしいリソースを大量に消費します)とUbuntuサブシステムを実行しています。ネイティブUbuntuでは、Ubuntuのみが実行されます。
これが特にあなたのシミュレーションに影響を与えるかどうかはわかりませんが、次の可能性があります。
つまり、シミュレーションで共有メモリを使用している場合(/dev/shm
と考えてください)、速度が低下したり、ストレージデバイスが消耗したりする可能性があります。そして、パフォーマンスのペナルティは、いくつかの層から来ます:
ファイルシステムドライバー
ストレージドライバー
記憶媒体
ただし、これが行われない場合、パフォーマンスはベアメタルUbuntuのパフォーマンスに似ているはずです(他のI/Oが他の人が言及したように仮定しない場合)。