「オープンソースには技術革新がない？」記事へのコメント

Component Object Model

[himuro (547)]

COM や OLE という視点でいくと、オープンソース陣営よりも
Microsoft 陣営のほうがはるかに進んでいると思う。
私は普段ほとんど Linux ばっかり使っているが、
Linux のソフト同士は協調するのが難しいと思う。
(ほとんどのソフトがライブラリレベルの機能共有とか
パイプでの連携程度にとどまっている。
オブジェクトとして連携できないものがほとんどだと思う)
Windows には COM で協調することで、ソフト同士が
連携しやすりという点にお

落とし穴: message passingによる性能劣化

[brake-handle (5065)]

COMのようなcomponent technologyは一部ではcode再利用などのご利益があったものの、実はperformanceを犠牲にしているという問題があります。

processや計算機の境界を超えたprocedure callというと思い出すのはMachですが、これについて最近びっくりする話を聞きました。実はMachはmessage passingの性能を上げるために、hardwareでそれを行っていたというのです(by Terry Lambert)。よくよく考えれば、processorのcall命令(あるいは相当物)と同じ程度までmessage passingのcostを切り詰めないと、message passingが性能の足を引っ張ってしまいます。

じゃ、

[Anonymous Coward]

Ｘの利点は？

昔メリット、今デメリット

[brake-handle (5065)]

よく日本でUnixをやっている人に見受けられるのですが、昔メリットだったことが今やデメリットになっていることに全く気づかないことがあります。Xもnfsも高機能な機器が高価だった昔はネットワークを通すことに意味がありました。しかしPCやらHDDがたたき売りされる今、帯域を求めたらネットワークなんてハナっから対象外です。それで例えばXでもMIT shmのようにネットワークを否定するような拡張をせざるを得ませんでした。

それでも分からない人には、この事実を突きつけておきましょう。4.2BSDが採用したsoftware interruptは当時の小さなmessage queueにとってはこの上ない機能でした。それが今や高速に終わらせるべきpacket処理を頻繁に横取りさせる原因となり、receive livelockの元凶 [harvard.edu](DoS攻撃による直接の影響)となっているのです。

Re:昔メリット、今デメリット

[G7 (3009)]

>今、帯域を求めたらネットワークなんてハナっから対象外

その逆転の論理が正しいとしたら、それはまたちょっとした皮肉ですね。unixに対しての。

なまじ高速なデバイスが有る時代に、却って帯域を「いかに空けるか」を気にしないとならないのですから(^^;、という皮肉もさることながら、
もっと皮肉なのは、「ネットワークが邪魔なら、(unixご自慢の)プロセスの壁だって、邪魔じゃん?」という点だと思うのです。

実際、共有メモリ(shm)で穴あけるってのは、プロセス壁の邪魔を(も)嫌った結果なわけでしょ?

また、最近流行のweb鯖では、1リクエストに1プロセスというモデルでCGIやってたら
日が暮れるのは判りきっているわけで、同一プロセス内でマルチスレッドこんにちわな時代になっちゃった、と。
#そういう状況では、本当はプロセスなんか要らないんだけど、たまたまOSはそういうモデルしか提供してないので、間借りしてるだけ。

というわけで、unixの根幹(だよね?)である「プロセスモデル」もまた、
「昔メリット、今デメリット」攻撃の矢面に立たされているんだなーと認識しています。

なお、プログラム(アプリ?)をobject単位で部品化する際、
それと同時にネットワーク透過モデルを導入する必要が有るのかどうか?については、
実は「どっちでも良い」ってのが答えだと思います。

なので、コンポーネントモデルを批判する際、できるならば、ネットワーク透過性への批判を、同時に込めないで頂けると、個人的に嬉しいです。
まぁ今回はCOMという1実装の話題なんでアレですが。

Re:昔メリット、今デメリット

[brake-handle (5065)]

簡単に分かることだけ。

たとえもっとも安価とされているuser-level threadを用いたとしても、one thread per requestでやっていては結局processをforkするのと全く変わりません(そのthreadが全く関係ない別のrequestに使い回されてしまう恐れがある、これは不必要な遅延を招くだけ)。httpの場合、本質的に効率を改善してくれるのはkeep-aliveによってapplication layerでのpollingを実現することです。これを実現すればprocessを使っていてもかなりthroughputが上がります。

processがどうこうというのは特定のOS、すなわちsoftwareに依存した問題に過ぎません。片や割込みのschedulingはethernet chipから冷蔵庫並みの汎用機にまで、物理層からapplication layerにまで共通する、全く別の問題であることをお忘れなく。

Re:昔メリット、今デメリット

[G7 (3009)]

>one thread per requestでやっていては結局processを
>forkするのと全く変わりません(そのthreadが全く関係ない別のrequestに使い回されてしまう恐れがある、これは不必要な遅延

遅延がどうこういう以前に、one per oneでは、複数リクエストが鯖内で混線しそうです。
それじゃ論外なので、そういう話題ではないと思います。

>httpの場合、本質的に効率を改善してくれるのはkeep-aliveによってapplication layerでのpollingを実現することで
>す。これを実現すればprocessを使っていてもかなりthroughputが上がります。

今回の文脈では、俺はどっちかってーとthreadの(pollingならぬ(^^;)poolingのほうを思い出します、効率改善の手法としては。
#ついでにいえば、webアプリを例にしましたが、HTTPに依存する問題を語りたかったわけじゃないです。
##もちろんHTTP側も別途最適化してくれることは望ましいですが。

たぶん、threadを生成しておいて、必要になったらそれを「使い」、リクエスト処理が終わって不要になったら「返す」、
ってことを普通やりますよね。
#当然ですがその際に、不当な使いまわしはしないように仕掛けを組みますよね。使用中のthreadは他から同時に使用されないようにするっつー。
#もちろん必要なContextも使いまわさないようにします。共有データとリクエスト別データとはきちんと分けます。
##って、この辺の話は、ふつーのJavaServletの話ですが。

>processがどうこうというのは特定のOS、すなわちsoftwareに依存した問題に過ぎません。片や割込みのschedulingはethernet
>chipから冷蔵庫並みの汎用機にまで、物理層からapplication layerにまで共通する、全く別の問題であることをお忘れなく。

あれ？今回って、いつからschedulingの話題になったんでしたっけ？

どっちかというと、COM(というか一般的にObjectモデル)を持つWinと、持たざる我らが(free)unixと、
の比較という文脈だったように思うのですが。

そして、効率の話をするときは、本質論が全てに優先するとは言い切れないのは、(きっと)ご存知の通り。
processもthreadもscheduling対象物という意味では同じでしょうけど、ここではむしろ両者の差異のほうが問題になるはずですよね…