回答編集履歴
2
ロック競合が多発するケースで追試しています
test
CHANGED
|
@@ -59,3 +59,15 @@
|
|
|
59
59
|
|
|
60
60
|
Windows 11 Homeでは電源オプションに応じたCPUスロットルがかかっており、パフォーマンスを優先する設定にしても完全には解除されないのかもしれません。
|
|
61
61
|
|
|
62
|
+
**追記その2** 2022-10-29
|
|
63
|
+
|
|
64
|
+
> * テストプログラムには、Rustで書かれたBitonic sorter（並列ソートアルゴリズムのひとつ）を使用
|
|
65
|
+
|
|
66
|
+
そのプログラムはロック競合をほとんど起こさないものだったので、あまり参考にならなかったかもしれません。別のプログラムで試してみました。電源モードは「最適なパフォーマンス」に設定しています。
|
|
67
|
+
|
|
68
|
+
* 128スレッドで並行処理し、
|
|
69
|
+
* ロック競合が多発するケースではWindowsの方がLinxuよりも1.7倍ほど**遅い**
|
|
70
|
+
* 多発しないケースではWindowsの方がLinxuよりも1.6倍ほど**速い**
|
|
71
|
+
|
|
72
|
+
性能差があることが確認できましたが、このプログラムはかなり複雑なことをしており、調査には適さないです。調査用にシンプルなプログラムを書いて調べてみたいと思います。（途中経過はRustの日本語Zulipチャットに[書いていきます](https://rust-lang-jp.zulipchat.com/#narrow/stream/124300-questions/topic/WLS.E3.81.A8windows.E3.81.A7.E5.AE.9F.E8.A1.8C.E3.81.97.E3.81.9F.E6.99.82.E3.81.AB2.E5.80.8D.E3.82.82.E9.80.9F.E5.BA.A6.E3.81.AB.E5.B7.AE.E3.81.8C.E5.87.BA.E3.82.8B.20.7C.20Teratail/near/306791607)）
|
|
73
|
+
|
1
優先順位ポリシーとWindowsでのテスト結果について追記しました
test
CHANGED
|
@@ -25,3 +25,37 @@
|
|
|
25
25
|
|
|
26
26
|
これを使ってみて、LinuxとWindowsでどのように性能が変わるかを確認してみるのはいかがでしょうか？ もし`std::sync::RwLock`が理由なら、`parking_lot::RwLock`を使うことで性能差がなくなるかもしれません。
|
|
27
27
|
|
|
28
|
+
**追記 2022-10-29**
|
|
29
|
+
|
|
30
|
+
`std::sync::RwLock`の優先順位ポリシーについて、追加情報があります。
|
|
31
|
+
|
|
32
|
+
* Linux版は今年6月にリリースされたRust 1.62からwriterロック優先に変更されたそうです。
|
|
33
|
+
* Rustの日本語コミュニティーで [教えてもらいました](https://rust-lang-jp.zulipchat.com/#narrow/stream/124300-questions/topic/.E2.9C.94.20WLS.E3.81.A8windows.E3.81.A7.E5.AE.9F.E8.A1.8C.E3.81.97.E3.81.9F.E6.99.82.E3.81.AB2.E5.80.8D.E3.82.82.E9.80.9F.E5.BA.A6.E3.81.AB.E5.B7.AE.E3.81.8C.E5.87.BA.E3.82.8B.20.7C.20Teratail/near/306651656)。
|
|
34
|
+
* 変更のpull request：https://github.com/rust-lang/rust/pull/95801#issue-1197239940
|
|
35
|
+
* Windows版は最近はOSが提供するSlim Reader/Writer (SRW) Locksを内部で使用しているそうです。
|
|
36
|
+
* このチケットに書かれていました：https://github.com/rust-lang/rust/issues/93740
|
|
37
|
+
* Microsoftの[ドキュメント](https://learn.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks)によると、SRWは優先順位ポリシーを持たない（ロックが取得される順序を保証しない）ようです。
|
|
38
|
+
* "There is no guarantee about the order in which threads that request ownership will be granted ownership; SRW locks are neither fair nor FIFO"
|
|
39
|
+
|
|
40
|
+
また、家族のWindows PCを借りて自分でも試してみました。（普段私はMacを使っていて、Windowsのことはあまり分かりません）
|
|
41
|
+
|
|
42
|
+
* Windows 11 Home
|
|
43
|
+
* WSL 2 Ubuntu 22.04
|
|
44
|
+
* Intel Core i7-12700Fを搭載しており、4つのEコア（高効率コア）と8つのPコア（高性能コア）がある
|
|
45
|
+
* Rust 1.64.0
|
|
46
|
+
* テストプログラムには、Rustで書かれたBitonic sorter（並列ソートアルゴリズムのひとつ）を使用
|
|
47
|
+
* https://github.com/ghmagazine/rustbook/tree/master/ch03/bitonic-sorter
|
|
48
|
+
|
|
49
|
+
以下のことが分かりました。
|
|
50
|
+
|
|
51
|
+
* 電源オプションの電源モードがデフォルトの「バランス」に設定されていると、マルチスレッド、シングルスレッドに関係なく、WSLに対して性能が落ちる
|
|
52
|
+
* シングルスレッドで1.6倍の時間がかかった
|
|
53
|
+
* マルチスレッドで4.5倍の時間がかかった
|
|
54
|
+
* Eコア（高効率コア）しか使われていない！
|
|
55
|
+
* 電源モードを「最適なパフォーマンス」に変更したところ、WSLに近い性能が出るようになった
|
|
56
|
+
* シングルスレッドで1.1倍の時間がかかった
|
|
57
|
+
* マルチスレッドで1.05倍の時間がかかった
|
|
58
|
+
* 全コア使われているが、クロック周波数がやや低い
|
|
59
|
+
|
|
60
|
+
Windows 11 Homeでは電源オプションに応じたCPUスロットルがかかっており、パフォーマンスを優先する設定にしても完全には解除されないのかもしれません。
|
|
61
|
+
|