アカウント名:
パスワード:
COMのようなcomponent technologyは一部ではcode再利用などのご利益があったものの、実はperformanceを犠牲にしているという問題があります。
processや計算機の境界を超えたprocedure callというと思い出すのはMachですが、これについて最近びっくりする話を聞きました。実はMachはmessage passingの性能を上げるために、hardwareでそれを行っていたというのです(by Terry Lambert)。よくよく考えれば、processorのcall命令(あるいは相当物)と同じ程度までmessage passingのcostを切り詰めないと、message passingが性能の足を引っ張ってしまいます。Machのころはこの差が顕著に現れた(それゆえにMachは全体では使いものにならなかった)のですが、今ではあまり気にしなくなったのか、高い金を出してprocessor能力のほとんどをprocedure callに費やすことが多くなっています。
選択肢を残すという点では、Unix-likeなOSにはむしろ計算機のperformanceをそのままuserに使わせてあげることに専念して欲しいですね。
そもそも、pipeでviはつくれないってのじたいが、言いがかりっぽい。 UNIXは部品の組み合わせで今自分がやりたい処理を簡単に 行うことができる、ってのがツールキットアプローチであって、 部品を組み合わせて簡単にアプリが作れるなんていうのが UNIXの利点だなんて誰も言ったのか?
既存部品+少しの新規コード+糊
という図式を考えるとして、UNIXの場合は、 既存部品=フィルタ・ツール、糊=pipe なわけですが、 これでviのようなものが作れないのは確かにそ
よく日本でUnixをやっている人に見受けられるのですが、昔メリットだったことが今やデメリットになっていることに全く気づかないことがあります。Xもnfsも高機能な機器が高価だった昔はネットワークを通すことに意味がありました。しかしPCやらHDDがたたき売りされる今、帯域を求めたらネットワークなんてハナっから対象外です。それで例えばXでもMIT shmのようにネットワークを否定するような拡張をせざるを得ませんでした。
それでも分からない人には、この事実を突きつけておきましょう。4.2BSDが採用したsoftware interruptは当時の小さなmessage queueにとってはこの上ない機能でした。それが今や高速に終わらせるべきpacket処理を頻繁に横取りさせる原因となり、receive livelockの元凶 [harvard.edu](DoS攻撃による直接の影響)となっているのです。
簡単に分かることだけ。
たとえもっとも安価とされている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にまで共通する、全く別の問題であることをお忘れなく。
それは全ての場合ではないです。in processな場合は関数呼び出しとほとんど同じ程度のオーバヘッドですし、オートメーションをサポー
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
Component Object Model (スコア:1)
Microsoft 陣営のほうがはるかに進んでいると思う。
私は普段ほとんど Linux ばっかり使っているが、
Linux のソフト同士は協調するのが難しいと思う。
(ほとんどのソフトがライブラリレベルの機能共有とか
パイプでの連携程度にとどまっている。
オブジェクトとして連携できないものがほとんどだと思う)
Windows には COM で協調することで、ソフト同士が
連携しやすりという点にお
落とし穴: message passingによる性能劣化 (スコア:2, 興味深い)
COMのようなcomponent technologyは一部ではcode再利用などのご利益があったものの、実はperformanceを犠牲にしているという問題があります。
processや計算機の境界を超えたprocedure callというと思い出すのはMachですが、これについて最近びっくりする話を聞きました。実はMachはmessage passingの性能を上げるために、hardwareでそれを行っていたというのです(by Terry Lambert)。よくよく考えれば、processorのcall命令(あるいは相当物)と同じ程度までmessage passingのcostを切り詰めないと、message passingが性能の足を引っ張ってしまいます。Machのころはこの差が顕著に現れた(それゆえにMachは全体では使いものにならなかった)のですが、今ではあまり気にしなくなったのか、高い金を出してprocessor能力のほとんどをprocedure callに費やすことが多くなっています。
選択肢を残すという点では、Unix-likeなOSにはむしろ計算機のperformanceをそのままuserに使わせてあげることに専念して欲しいですね。
Re:落とし穴: message passingによる性能劣化 (スコア:1)
>Unix-likeなOSにはむしろ計算機のperformanceをそのままuserに使わせてあげることに専念して欲しい
userに何を「させてあげられ得る」のか?という点では、unixのモデルには、ちと不安を感じています。
前述したとおり「unixにはviを作る力が無い(あれはC言語に有るのです(^^;)」のであって、
unixモデルの範囲で(楽に)やれることの範囲ってのは、結構狭いように感じるのです。
ゲイツ実装がそういうモノであるかどうかとは独立に、
もともとのコンポーネントモデルってものは、viを作れる(^^;モデルであるわけです。
エディタのように、各部品が「緊密に」状態情報を相互にやりとりしないと作れないソフトを、です。
unix部品化(=パイプ)モデルで、ObserverPatternを組めるもんなら組んでみてくださいって感じ。
もちろん効率の低いアクロバットは却下として。
そもそも「同一のインスタンスへコールバックする」という概念で、つまずいてしまうはずです。
その限界を超えるには、unixモデルの中では本質的に、ごりごり書くしか無いわけで。
じゃあ(unix上でvi的なものを作れる)GNOMEなりなんなりが何をやっているか?というと、
unixの枠とは無関係な世界をいったん築いて、その上でやっているわけですから、
あれはunixの手柄ではない。
MSになんらかの革新の手柄が有ったとは思えませんし、実装も色々腐ってるようですが(^^;、
原則としてwinには、unixよりは「ちょっと進んだ(=革新済みの)便利なもの」が入っているってのは、事実かも。
よだん:
プロセス壁超えがコンポモデルと常にツガイであるとも限らないのでよろしく。
なんかマイナーですが(^^;、delphi/kylixのモデル(あくまで実態はクラスライブラリでしかない)だって、それなりにコンポモデルであるはずです。
というか、いつの間にコンポという言葉が壁超えの意味を内包するようになったんだろう?
ここ数年の「コンポ」という言葉のブームよりは、delphiのほうがちょっと先輩だと思うんだけどなあ(^^;
Re:落とし穴: message passingによる性能劣化 (スコア:0)
そもそも、pipeでviはつくれないってのじたいが、言いがかりっぽい。 UNIXは部品の組み合わせで今自分がやりたい処理を簡単に 行うことができる、ってのがツールキットアプローチであって、 部品を組み合わせて簡単にアプリが作れるなんていうのが UNIXの利点だなんて誰も言ったのか?
既存部品+少しの新規コード+糊
という図式を考えるとして、UNIXの場合は、 既存部品=フィルタ・ツール、糊=pipe なわけですが、 これでviのようなものが作れないのは確かにそ
Re:落とし穴: message passingによる性能劣化 (スコア:1)
>UNIXは部品の組み合わせで今自分がやりたい処理を簡単に
>行うことができる、ってのがツールキットアプローチであって、部品を組み合わせて簡単にアプリが作れるなんていうのが UNIXの
>利点だなんて誰も言ったのか?
いや、それは「unix(勢)が言うところのToolkitApproach」の定義に過ぎないと思いますよ。
状態モデルてゆーかObjectぽいものをサポートしてないToolkitApproachだ、ということ。
で、ObjectっぽいものをサポートしたToolkitApproachというものも、また別途ありえると思うのですが、どうでしょう?
もちろん、どんな定義であろうとそれはそれなのですが、実際には、サポートする範囲が狭い定義(に基づいた実装)は
当然ながら不便であるわけです。両者の間には、しばしば、はっきりした優劣が有るはずです。
で、Objectっぽいモデルを使ってpipeっぽいモデルを代用することは容易ですが、逆は困難です。
言ってしまえば、簡単にアプリが作れないことを以って、unixのやりかたは(ここで言ってるやり方より)劣ってる、と言えるはずです。
わが道を行くぞと言うのは自由ですが、そう主張する「価値」は低い、ということです。実用性において劣っているのですから。
古いシステムだからそういうものをサポートしてなくても「当然」だといえるのは確かですが、
だからって(相対的)存在価値が今もなお変わっていないか?というと、そうは言えないはずです。
なお、「処理」と「アプリ」の差は何だ?という問題がありますね。
少なくとも俺は、「処理の可能性(ability)の束」がアプリである、と定義して良いと思います。
というか、両者を必要(?)以上に別物あつかいしたがるのは、悪い意味でのunix的考え方だなーと思います。
両者を統合して考える能力が無い環境だからこそ、別物だと考えざるを得ない、というわけです。
unixでも、望む処理の羅列をscriptという形で永続化できるわけですが、その方法論の延長で
「状態モデル込みの処理」のパターンを(しばしば複数束ねて)、永続化できるならば、
それ即ちアプリになり得たはずです。でもunixはそうしなかった。
#Tcl/Tkとか使えば、そういうものを作ることは出来ますが、それにOSは何も貢献していないので、ここでは論外。
さて。
>一度、本物のviを作って見せてくれよ。できたら信用してやる。stevieとかvip-modeみたいな偽物はダメよ。
>つまり、何が言いたいかというとエディタの場合、バリエーションがありすぎる。既存部品が使えないだろうってこと。
うわ。そういう要望ですか。なんだかなあ。
それ言い出したら、「あらゆる部品化アプローチ(勿論unix方式も)」について、悲観的に捉えざるを得なくなるだけなんですが…
まあいいでしょう。結論からいえば、今そういう実装が有るかどうかは別(^^;として、原理的には可能です。
どうすればいいかというと、viというものを「分解」するんです。
たとえば、キーバインドを司るObjectは、表示Objectとは、別物としておく。
モードを司るものも、データを貯めるもの(Buffer?)も、Lisp処理系(^^;も、全部別々のObjectにする。
そして、それらを「接続」するんです。
部品は好きなものを選べばいいでしょう。viじゃなくEmacsなキーバインドを司るObjectに差し替えれば
そのエディタのキーバインドはEmacsになるはず。純正viもstevieもなんでも有りでしょう。
もちろん、そういう着脱可能な細かい部品を自由に接続して運用できるようにするには、
なんらかのインターフェース規約を先に作らないと駄目ですが、
そういうのは仕様違いをラップするObjectを挟むことだって出来るので、まぁ後からなんとでもなるでしょう。
ちなみに言えば、この「部品が接続されたパターン」が、古典的にいう「アプリ」に相当するものになるはずです。
余談:
「Unixをもう少しましなものにしよう」 ( 本文和訳はこちら [os-omicron.org]、 Tikiで議論(^^;はこちら [os-omicron.org])
に有るように、部品化はもっと意識したいものです。
まぁプロプラ云々という台詞は「信じたくはない」ですけども、だからこそ尚更、
プロプラなんかに頼らずに、現代的な部品化の仕組みを大成させたいものだと思うのです。
部品化から背を向けるのはイタイだけっす。
> エディタは部品を組み合わせることでちょいちょいと作れるという例には当てはまらない
じゃ、 (スコア:0)
昔メリット、今デメリット (スコア:2, 興味深い)
よく日本でUnixをやっている人に見受けられるのですが、昔メリットだったことが今やデメリットになっていることに全く気づかないことがあります。Xもnfsも高機能な機器が高価だった昔はネットワークを通すことに意味がありました。しかしPCやらHDDがたたき売りされる今、帯域を求めたらネットワークなんてハナっから対象外です。それで例えばXでもMIT shmのようにネットワークを否定するような拡張をせざるを得ませんでした。
それでも分からない人には、この事実を突きつけておきましょう。4.2BSDが採用したsoftware interruptは当時の小さなmessage queueにとってはこの上ない機能でした。それが今や高速に終わらせるべきpacket処理を頻繁に横取りさせる原因となり、receive livelockの元凶 [harvard.edu](DoS攻撃による直接の影響)となっているのです。
Re:昔メリット、今デメリット (スコア:2, 興味深い)
その逆転の論理が正しいとしたら、それはまたちょっとした皮肉ですね。unixに対しての。
なまじ高速なデバイスが有る時代に、却って帯域を「いかに空けるか」を気にしないとならないのですから(^^;、という皮肉もさることながら、
もっと皮肉なのは、「ネットワークが邪魔なら、(unixご自慢の)プロセスの壁だって、邪魔じゃん?」という点だと思うのです。
実際、共有メモリ(shm)で穴あけるってのは、プロセス壁の邪魔を(も)嫌った結果なわけでしょ?
また、最近流行のweb鯖では、1リクエストに1プロセスというモデルでCGIやってたら
日が暮れるのは判りきっているわけで、同一プロセス内でマルチスレッドこんにちわな時代になっちゃった、と。
#そういう状況では、本当はプロセスなんか要らないんだけど、たまたまOSはそういうモデルしか提供してないので、間借りしてるだけ。
というわけで、unixの根幹(だよね?)である「プロセスモデル」もまた、
「昔メリット、今デメリット」攻撃の矢面に立たされているんだなーと認識しています。
なお、プログラム(アプリ?)をobject単位で部品化する際、
それと同時にネットワーク透過モデルを導入する必要が有るのかどうか?については、
実は「どっちでも良い」ってのが答えだと思います。
なので、コンポーネントモデルを批判する際、できるならば、ネットワーク透過性への批判を、同時に込めないで頂けると、個人的に嬉しいです。
まぁ今回はCOMという1実装の話題なんでアレですが。
Re:昔メリット、今デメリット (スコア:1)
簡単に分かることだけ。
たとえもっとも安価とされている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:昔メリット、今デメリット (スコア:1)
>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対象物という意味では同じでしょうけど、ここではむしろ両者の差異のほうが問題になるはずですよね…
Re:落とし穴: message passingによる性能劣化 (スコア:0)
それは全ての場合ではないです。in processな場合は関数呼び出しとほとんど同じ程度のオーバヘッドですし、オートメーションをサポー