質問編集履歴
4
シングルスレッドプログラミングでの順次的記述方法を追加＋マルチコアに対する考察の追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -58,9 +58,107 @@
|
|
|
58
58
|
いくつか回答いただいて、シングルスレッドプログラミングとC10K問題が直結していないことに気が付きましたが、質問としてはC10K問題で復権したシングルスレッドプログラミングをどう思うかというポイントに変更して続けさせていただきたいと思います。
|
|
59
59
|
JavaScript のコールバックは嫌いですか？ lua などコルーチンの yield って懐かしくないですか？マルチスレッドプログラミングって難しくないですか？
|
|
60
60
|
|
|
61
|
-
|
|
62
|
-
|
|
61
|
+
####補足1：マルチコアについて
|
|
62
|
+
それほど性能がCPUに依存するアプリが少ないのではないかとは思いますが、、CPU依存が強い場合でもワーカプロセスに負荷分散することで、プログラム自身はシングルスレッド・協調的マルチタスクで書くことが可能だと思います。特に並列演算で問題が解決するような場合は、ワーカプロセス側で GPUをつかったり、SIMD命令を使うなど、マルチコア以上に並列度をあげる工夫が必要ではないかと考えます。この場合は、マルチスレッドプログラミングというよりも並列処理プログラミングになってくると思います。となると、やはりマルチスレッドプログラミングは不要なのではないかと思えてきます。
|
|
63
63
|
|
|
64
|
+
####補足２：イベント駆動型プログラミングの順次的記述
|
|
65
|
+
回答でイベント駆動型プログラミングのデメリットとしてサブルーチンのネスト構造などモジュール化がやりにくいという指摘がありました。 Javascript では、サブルーチンの呼び出し後の継続処理をコールバック関数（というかクロージャ）に記述するという技法で回避し、非同期でありながらモジュール化を行うことに成功しています。しかし、この技法はコールバック地獄と呼ばれており、モジュール化には成功しましたが、順次処理を記述すると、ネストがどんどん深くなるという欠点がありました。次世代 Javascript である es6 では、この問題を Promise という技法でさらに回避しております。
|
|
66
|
+
ここで、普通に順次的に記述したプログラムと Promiseを使って非同期処理可能でありながら順次的に記述したプログラムを比較してみます。
|
|
67
|
+
|
|
68
|
+
普通の順次的記述
|
|
69
|
+
```Javascript
|
|
70
|
+
function main() {
|
|
71
|
+
let x = 'default value of x';
|
|
72
|
+
let y = 'default value of y';
|
|
73
|
+
let z;
|
|
74
|
+
try {
|
|
75
|
+
z = getValuesForZ(x);
|
|
76
|
+
z = z.map(item => processItem(item));
|
|
77
|
+
if (z.includes(processItem(x))) {
|
|
78
|
+
y = processY(y);
|
|
79
|
+
}
|
|
80
|
+
console.log("x = " + x + ", y= " + y + ", z= " + z);
|
|
81
|
+
} catch (e) {
|
|
82
|
+
console.log(e);
|
|
83
|
+
}
|
|
84
|
+
}
|
|
85
|
+
|
|
86
|
+
function getValuesForZ(arg)
|
|
87
|
+
{
|
|
88
|
+
return ['value1', 'value2'].concat(arg);
|
|
89
|
+
}
|
|
90
|
+
|
|
91
|
+
function processItem(item) {
|
|
92
|
+
return 'processed:' + item;
|
|
93
|
+
}
|
|
94
|
+
|
|
95
|
+
function processY(y) {
|
|
96
|
+
return processYnest(y);
|
|
97
|
+
}
|
|
98
|
+
|
|
99
|
+
function processYnest(y) {
|
|
100
|
+
return 'processed in nested function:' + y;
|
|
101
|
+
}
|
|
102
|
+
|
|
103
|
+
main()
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
Promise を使った非同期処理可能な順次的記述
|
|
107
|
+
```Javascript
|
|
108
|
+
function main() {
|
|
109
|
+
Promise.resolve({
|
|
110
|
+
x: 'default value of x',
|
|
111
|
+
y: 'default value of y'
|
|
112
|
+
})
|
|
113
|
+
.then(getValuesForZ())
|
|
114
|
+
.then(state => {
|
|
115
|
+
return Promise.all(state.z.map(item => Promise.resolve(item).then(processItem())))
|
|
116
|
+
.then(z => Object.assign(state, {z}));
|
|
117
|
+
})
|
|
118
|
+
.then(state => {
|
|
119
|
+
return Promise.resolve(state.x).then(processItem()).then(r => {
|
|
120
|
+
if (state.z.includes(r)) {
|
|
121
|
+
return Promise.resolve(state).then(processY());
|
|
122
|
+
}
|
|
123
|
+
return state;
|
|
124
|
+
});
|
|
125
|
+
})
|
|
126
|
+
.then(state => {
|
|
127
|
+
console.log("x = " + state.x + ", y= " + state.y + ", z= " + state.z);
|
|
128
|
+
})
|
|
129
|
+
.catch(e => {
|
|
130
|
+
console.log(e);
|
|
131
|
+
});
|
|
132
|
+
}
|
|
133
|
+
|
|
134
|
+
function getValuesForZ()
|
|
135
|
+
{
|
|
136
|
+
return state => Object.assign(state, {z:['value1', 'value2'].concat(state.x)});
|
|
137
|
+
}
|
|
138
|
+
|
|
139
|
+
function processItem() {
|
|
140
|
+
return item => 'processed:' + item;
|
|
141
|
+
}
|
|
142
|
+
|
|
143
|
+
function processY() {
|
|
144
|
+
return state => {
|
|
145
|
+
return Promise.resolve(state.y)
|
|
146
|
+
.then(processYnest())
|
|
147
|
+
.then(y => Object.assign(state,{y}));
|
|
148
|
+
};
|
|
149
|
+
}
|
|
150
|
+
|
|
151
|
+
function processYnest() {
|
|
152
|
+
return y => 'processed in nested function:' + y;
|
|
153
|
+
}
|
|
154
|
+
|
|
155
|
+
main()
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
普通版は 34行に対して、Promise 版は48行と行数は増えてしまいましたが、処理順にプログラムを書くことができて、かつ、サブルーチンによるモジュール化もできていると思います。
|
|
159
|
+
モジュール化のみそは、サブルーチンが演算結果を返すのではなく、演算を行う関数を返すことです。このようにすることで、呼び出し側は非同期にその関数を呼び出すことができるわけです。
|
|
160
|
+
プログラムの詳細な説明は避けますが、順次処理、条件判定、繰り返し処理、サブルーチンのネスト呼び出しを含める例となっています。プログラムの処理内容には何の意味もありません。また、両方を比較しやすいように非同期処理は入っていませんが、Promise版の方ではいくらでも非同期処理を挿入できますが、普通版では非同期処理を挿入することは不可能です。
|
|
161
|
+
|
|
64
162
|
※１の参考：
|
|
65
163
|
[TCP/IP - Solving the C10K with the thread per client approach](http://stackoverflow.com/questions/17593699/tcp-ip-solving-the-c10k-with-the-thread-per-client-approach)
|
|
66
164
|
[「サーバ書くなら epoll 使うべき」は、今でも正しいのか](http://developer.cybozu.co.jp/archives/kazuho/2009/09/epoll-bac0.html)
|
3
論点をシングルスレッドプログラミングに変更
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -13,13 +13,54 @@
|
|
|
13
13
|
今回もプリエンプティブマルチタスク（マルチスレッド派）対協調的マルチタスク（イベント駆動型やコルーチン派）の戦いが始まっているように思います。これを第二次プリエンプティブ戦争と呼びましょう。
|
|
14
14
|
|
|
15
15
|
####協調的マルチタスク派
|
|
16
|
-
|
|
16
|
+
（いくつか回答いただいて、自分の好みの問題とC10K問題が直結していないことに気が付き、書き直しました）
|
|
17
|
+
私は個人的にはシングルスレッドイベント駆動型でコーディングするのが好きで、c10K問題を理由にマルチスレッドプログラミングのパラダイムを駆逐して欲しいくらいに思っています。たとえば、DBへの問い合わせが長い時間かかる場合に、ユーザからの要求やシステムのシャットダウンに対応して問い合わせを中断できるようにする場合、マルチスレッドで割り込みを気にしながら順次的に書くよりも自分で状態遷移を管理するほうが簡単ではないでしょうか。マルチスレッドの場合、
|
|
18
|
+
（DBへの問い合わせを中止できるようなドライバがあるかどうかはおいておいて）
|
|
17
19
|
|
|
20
|
+
```javascript
|
|
21
|
+
class 問い合わせ {
|
|
22
|
+
do() {
|
|
23
|
+
try {
|
|
24
|
+
DBへの問い合わせ
|
|
25
|
+
} catch (CancelSignal cs) {
|
|
26
|
+
if (微妙なタイミング判定) {
|
|
27
|
+
問い合わせ中止処理
|
|
28
|
+
}
|
|
29
|
+
}
|
|
30
|
+
}
|
|
31
|
+
onCancel() {
|
|
18
|
-
|
|
32
|
+
問い合わせ実行中スレッドへ CancelSignal を送信
|
|
19
|
-
JavaScript のコールバックは嫌いですか？ lua などコルーチンの yield って懐かしくないですか？
|
|
20
|
-
|
|
33
|
+
}
|
|
34
|
+
}
|
|
21
|
-
|
|
35
|
+
```
|
|
22
36
|
|
|
37
|
+
となり、問い合わせの終了とキャンセルシグナルの入力との微妙なタイミング判定（排他制御）が必要ですが、シングルスレッドであれば、
|
|
38
|
+
|
|
39
|
+
```javascript
|
|
40
|
+
class 問い合わせ {
|
|
41
|
+
do() {
|
|
42
|
+
DBへの問い合わせ((event) => this.handler(event));
|
|
43
|
+
}
|
|
44
|
+
handler (event) {
|
|
45
|
+
...
|
|
46
|
+
}
|
|
47
|
+
onCancel() {
|
|
48
|
+
問い合わせ中止処理
|
|
49
|
+
}
|
|
50
|
+
}
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
と書けて、シングルスレッドなので、handler 呼び出しと onCancel の呼び出しは早い者勝ちとなるわけです。
|
|
54
|
+
|
|
55
|
+
そもそも、OSレベルでは多重入力はイベント駆動で実装されているわけで、そのイベント駆動をそのままコーディングできるシングルスレッドイベント駆動プログラミングって気持ち良くないですか？
|
|
56
|
+
|
|
57
|
+
####質問：シングルスレッドプログラミングは好きですか？残ると思いますか？
|
|
58
|
+
いくつか回答いただいて、シングルスレッドプログラミングとC10K問題が直結していないことに気が付きましたが、質問としてはC10K問題で復権したシングルスレッドプログラミングをどう思うかというポイントに変更して続けさせていただきたいと思います。
|
|
59
|
+
JavaScript のコールバックは嫌いですか？ lua などコルーチンの yield って懐かしくないですか？マルチスレッドプログラミングって難しくないですか？
|
|
60
|
+
|
|
61
|
+
* 補足：マルチコアについて
|
|
62
|
+
一つは、それほど性能がCPUに依存するアプリが少ないというのがありますが、CPU依存が強い場合でも複数のシングルスレッドプロセスにロードバランサなどで負荷分散することで、プログラム自身はシングルスレッド・協調的マルチタスクで書くことが可能だと思います。
|
|
63
|
+
|
|
23
64
|
※１の参考：
|
|
24
65
|
[TCP/IP - Solving the C10K with the thread per client approach](http://stackoverflow.com/questions/17593699/tcp-ip-solving-the-c10k-with-the-thread-per-client-approach)
|
|
25
66
|
[「サーバ書くなら epoll 使うべき」は、今でも正しいのか](http://developer.cybozu.co.jp/archives/kazuho/2009/09/epoll-bac0.html)
|
2
typo修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
####また戦いが
|
|
11
11
|
その状況の中で、最近のWebでの議論を見ていると、Linux のマルチスレッドが非常に軽量・高速で協調的マルチタスクじゃなくてもマルチスレッドで十分性能が出るというベンチマーク結果が出てきているようです（※１）。そうなると、協調的マルチタスクの処理系はまたなくなってしまうのでしょうか。
|
|
12
12
|
前述の昔話において、パソコンのOSがプリエンプティブマルチタスクに置き換えられるときも、OSの実装者は「プリエンプティブマルチタスクなんて必要ない。プログラマが時間のかかる処理を実装するときに処理の途中経過を報告したり、中断したりする機能をちゃんと入れてれば、協調的マルチタスクのほうが効率が高いに決まっている」と執拗に粘ったのですが、世の中の流行には逆らえず（というよりも質の悪いプログラムの多さに負けて）、負けてしまいました。
|
|
13
|
-
今回もプリエンプティブマルチタスク（マルチスレッド派）対協調的マルチタスク（イベント駆動型やコルーチン派）の戦いが始まっているように思います。これを第二次プリンティブ戦争と呼びましょう。
|
|
13
|
+
今回もプリエンプティブマルチタスク（マルチスレッド派）対協調的マルチタスク（イベント駆動型やコルーチン派）の戦いが始まっているように思います。これを第二次プリエンプティブ戦争と呼びましょう。
|
|
14
14
|
|
|
15
15
|
####協調的マルチタスク派
|
|
16
16
|
私は個人的にはイベント駆動型が好きで、性能問題でマルチスレッド派を駆逐して欲しいくらいに思っています。そもそも、長時間の処理に入るのに、何時間かかるか予想もつかず、中断もできないようなプログラムの存在が良くないと思います。すべてのプログラムはそのユースケースに応じて、時間がかかりすぎる場合には中断できるとか、かかる時間を予測して途中経過を報告する機能が具備されているべきだと思います。それで、そのような機能を実装しようとすると、スレッドで割り込みを気にしながら順次的に書くよりも自分で状態遷移を管理するほうが簡単ではないでしょうか。
|
1
スレッド/リクエストによるc10k についての情報を追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -8,7 +8,7 @@
|
|
|
8
8
|
今、マルチスレッドのアーキテクチャが抱えるC10K問題に対応するために node.js、 nginx+lua などイベント駆動型やコルーチン型（＝協調的マルチタスク）で処理する処理系が出始めました。そして、従来の一つのリクエストを一つのスレッドが処理するプリエンプティブなマルチスレッド処理系に比べて高い性能が出るということが定説になっています。
|
|
9
9
|
|
|
10
10
|
####また戦いが
|
|
11
|
-
その状況の中で、最近のWebでの議論を見ていると、Linux のマルチスレッドが非常に軽量・高速で協調的マルチタスクじゃなくてもマルチスレッドで十分性能が出るというベンチマーク結果が出てきているようです。そうなると、協調的マルチタスクの処理系はまたなくなってしまうのでしょうか。
|
|
11
|
+
その状況の中で、最近のWebでの議論を見ていると、Linux のマルチスレッドが非常に軽量・高速で協調的マルチタスクじゃなくてもマルチスレッドで十分性能が出るというベンチマーク結果が出てきているようです（※１）。そうなると、協調的マルチタスクの処理系はまたなくなってしまうのでしょうか。
|
|
12
12
|
前述の昔話において、パソコンのOSがプリエンプティブマルチタスクに置き換えられるときも、OSの実装者は「プリエンプティブマルチタスクなんて必要ない。プログラマが時間のかかる処理を実装するときに処理の途中経過を報告したり、中断したりする機能をちゃんと入れてれば、協調的マルチタスクのほうが効率が高いに決まっている」と執拗に粘ったのですが、世の中の流行には逆らえず（というよりも質の悪いプログラムの多さに負けて）、負けてしまいました。
|
|
13
13
|
今回もプリエンプティブマルチタスク（マルチスレッド派）対協調的マルチタスク（イベント駆動型やコルーチン派）の戦いが始まっているように思います。これを第二次プリンティブ戦争と呼びましょう。
|
|
14
14
|
|
|
@@ -18,4 +18,9 @@
|
|
|
18
18
|
####質問：どっちが好きですか・どっちが勝つと思いますか
|
|
19
19
|
JavaScript のコールバックは嫌いですか？ lua などコルーチンの yield って懐かしくないですか？
|
|
20
20
|
みなさんはどちらが好きですか？どちらが勝つと予想しますか？
|
|
21
|
-
そもそもこの問題提起自身正しいと思いますか？
|
|
21
|
+
そもそもこの問題提起自身正しいと思いますか？
|
|
22
|
+
|
|
23
|
+
※１の参考：
|
|
24
|
+
[TCP/IP - Solving the C10K with the thread per client approach](http://stackoverflow.com/questions/17593699/tcp-ip-solving-the-c10k-with-the-thread-per-client-approach)
|
|
25
|
+
[「サーバ書くなら epoll 使うべき」は、今でも正しいのか](http://developer.cybozu.co.jp/archives/kazuho/2009/09/epoll-bac0.html)
|
|
26
|
+
いずれも、協調的マルチタスクに比べれば性能は出ないと思いますが、「協調的マルチタスクがないと１万コネクションはできないのかというとそうではない」という主張だと思います。桁が上がって１０万コネクションになれば、やはり協調的マルチタスクが必要なのかもしれません。
|