マイクロカーネル vs モノリシックカーネル

1 ：03/10/12 〜 最終レス ：2013/04/08

一度本気で語ってみたい題目。リーナスvsタネンバウムで
いろいろネタは出てるが、時代は変わっている。もう一度
語ってみようじゃないか。
・性能の違い
・実装の違い
・リーナスとタネンバウム
何でもいいので語ろう。

2 ：

おいおいおい・・・2getかよ

3 ：

初2getｷﾀ━━━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━━━!!!!!

4 ：

このスレはマジに語れるのか？？？？？？

5 ：

>>3
晒し上げ

6 ：

マイクロカーネルが、モノリシックカーネルより、いくつかの点で
「よい」とか言う主張だって、いい加減さは同じだよ。
良いというならば、具体的に数値化して示さなきゃ、学問ではない。
論理的に帰結を得られないならば、実測でもいいが、そのどちらも
書かずに、「よい」とか「悪い」とか書いたんでは、科学じゃない。
物理学などは、大学での研究が信頼性はかなり高いと思う。なぜなら、
全部理詰め、論理、数式などで精密に導いているから、実験を全く
しなくても、ほとんどの場合、正しい結果を得られる場合が多いと
考えられるから。
しかし、今の日本の工学の教科書みたいな論理(?)の進め方だと、
実験もロクにしていない癖に、精密な論理も用いてないので、
高頻度で間違いが入ってしまう。
実際、大学の試験で間違ったことを書かせることさえ、あり得るのでは
ないかと思ってしまう。
つまり、主観をテストで問うようなことがあり得ると言うこと。
こんなものを、学生にイレジエしては困る。
大学教育が進めば進むほど、日本の技術が間違った知識が蔓延したりね。
現場で実際にやってみると、間違ってたら動かないので気付くんだけど、
工学を馬鹿真面目にやってるだけでは気付かずに、馬鹿知識蔓延するよ、
まじで。

7 ：

組み込み向けにはマイクロカーネルがいいと思われ
モノリシック＆モジュールは便利だが、モジュールがこけると
カーネルごとこけるのがいただけない

8 ：

前にも書いたと思うけど、Tanenbaum教授は、マイクロカーネルを
信奉している人。一方、Linusは、マイクロカーネルに大した価値を
見出さない人で、むしろ、モノリシックカーネルを信奉している人。
この二人の意見は真っ向から対立する。
世界的にも、工学の教科書では、どうやら、「マイクロカーネル」の
方が次世代の形態で、「よい」とされているようだが、しかし、
教科書を書いた人の何割が、それを深く理解しているのだろうか。
実際問題、商用UNIXでも、マイクロカーネルに移行する機会があったの
にもかかわらず、速度パフォーマンスの面などを考慮した結果だと
思われるが、結局、採用されなかった。
マイクロカーネル代表の、Machでも、Minixでも、いろんな問題を
含んでおり、未だ解決されていない。
実際にOSを作っている人たちには、モノリシック派は、かなりの割合で
存在しているように思える。しかし、恐らくだが、他人のOSを研究したこと
はあっても、自分で作ったことはないであろう人が書いたOSの教科書
には、マイクロカーネルが賛美されてしまっている。
一見、事情を知らない人、例えば政府役人などが見れば、大学研究者
の方が、頭もよくて、最先端の知識があるから、現場の
「デジタル・ドカタ」であるところの、プログラマの言うことが
間違いで、大学研究者の方が正しいと見なしてしまい、ちゃんと
勉強して出直せと命じてしまうだろう。
しかし、実体はそうではないと思うのだ。

9 ：

> 実際問題、商用UNIXでも、マイクロカーネルに移行する機会があったの
> にもかかわらず、速度パフォーマンスの面などを考慮した結果だと
> 思われるが、結局、採用されなかった。
Solarisより遥かに頑丈なTru 64 UNIXを知らんのだな。
OSF-1から連綿と続く系統なんだが。

10 ：

Machは複雑になりすぎてるという論調はあるみたいだが、OSの研究
としては高く評価されているのでは？

11 ：

> Solarisより遥かに頑丈なTru 64 UNIXを知らんのだな。
> OSF-1から連綿と続く系統なんだが。
HP-UXへ統合という名目で葬られましたが何か？
セットだったAlphaもItaniumへ統合って名目で葬られたしね。
で、結局Mach出身でシェアトップなのはOS Xだね。
∴Darwin <<<<<<<<<<<<<<< HP-UX <<<<<<<<<<< Tru64 <<<<<<<<<<<<<<< Solaris
<<<<< *BSD <<<<<<<<<<< (超えられない壁） <<<<<<<<<<< 犬糞

12 ：

確かに理論だけでは語れない部分が多々あるのは確か。
実際に日本でOSの開発をしている開発者はどう思うので
しょうかねぇ

13 ：

マイクロカーネルの例として、Minix, Mach, WindowsNTについて。
Minixは、マイクロカーネルだが、MMUを使っておらず、保護が全くない
(と思う)。また、教材用のため(というか、学者が作ったOSで、学者は
そういうことを理由にしがちなのだけど）、遅いらしい（MMUを使わずに
マイクロカーネルにするという、意味不明なことをやっていて、個人的に
は方針が見えない。MMUなしのOS作りは、MMUありよりかなり簡単なので、
余り勉強にならず、教材としても余り意味がないかも。）
Machは、高速化するために恐ろしく難しくなっているというLinusの
コメントがある。マイクロカーネルの当初の目的は、作りの単純さに
あったはずなので、本末転倒だと言えるのではないか。
WindowsNTは、ネットでの資料によれば、比較的高速らしいが、真偽
のほどはよく分からない。速度測定や比較は、やり方を適切にして、
考察を正確に行わなければ正しいことは言えないので、余りネットや
雑誌の資料は当てにならない。実感として特に遅い事はないと思うが、
WindowsNT系は、Windows9x系よりも明らかに遅いことは事実。
よって、このケースでもマイクロカーネルの方がやはり遅い。
しかも、遅さも無視できる程度ではない。

14 ：

Minixで、MMUを使わずにマイクロカーネルを採用する意図が、私には全く
理解できない。
MMUを使わなければ、そもそもデータ保護ができない。
そもそも、「カーネルモード」と「ユーザーモード」の区別がなく、
また、別のタスクのメモリを簡単に読み書きできてしまう。

そもそも、OS作りで大変なのは、保護をしたいからこその複雑さ。
保護しなくて良いなら、ずっと簡単に書けてしまう。
マイクロカーネルにしたところで、保護しやすくなるわけはない（保護
がそもそもできないのだから。）。

マイクロカーネルの遅さの１つは、メモリ空間が異なるバッファ間のコピー
にある。MMUを使って保護目的にメモリ空間を故意に分離しているのだから、
普通にmemcpy()で済ませられず、通常、ページテーブルを書き換えて、
アドレス変換マッピングを変更する必要がある。
しかし、MMUを使わないなら、memcpy()で済ますことができるから、
この遅さは有り得なくなる。
よって、MMUを使っていないところの、Minixが仮に遅くないとしても、
マイクロカーネルの速度に関しては、何の根拠にもならない。

15 ：

保護するために複雑になる例 : メモリ確保
保護なしで済む例:malloc()関数。
malloc()関数は、確保したメモリブロック
の前後にヘッダを持つ。ユーザープログラムに間違いがあると、そのヘッダ
情報が破壊され、ヒープメモリシステム自体が崩壊する。
しかし、崩壊は、そのタスク内で留まる。
保護有りの例:保護機能を持つOSのシステムレベルでのメモリ確保
メモリブロックのヘッダ情報を、保護ページに格納することで、
アプリケーションが破壊することができないようになっている。
しかし、構造上、メモリブロック本体とヘッダの二種類が存在する
ことになり、適切に組まないと、メモリ空間を全部使い切ることが
できなくなったり、物理メモリ容量が余っているのに、ブロックの個数
制限があって事実上メモリ不足のようになってしまうことになるかも
しれない。前述のmalloc()に比べるとアルゴリズムが難しい。

16 ：

一応念のため:「マイクロカーネル」とは、ファイルシステム、タスクロード、
GUIシステムなどのOSの基本機能を、「タスク(プロセス)」にほぼ等価な形態で
実装する方式のことを言います。
次の理解は間違いです:
1. モジュール化したOSをマイクロカーネルという」
2. OSの一部をユーザーモードで実行できるようなものをマイクロカーネルという
1. については、多くの方が理解されているようですが、2.については誤解が
多いようです。
CPUの種類によっては異なるかも知れませんが、基本的には、特権レベルと
タスク(プロセス)は、概念が全く別で、タスクはメモリ空間の分離単位
ですが、ユーザーモードかカーネルモードは、特権レベルの違い、つまり、
保護上の差でしかありません。
従って、本当のタスク(プロセス)にしなくても、ファイルシステムをユーザー
モードで動かすことは可能です。
わかりやすく言えば、システムコールを、呼び出し元のタスクと同じメモリ
空間で実行する形態をモノリシックカーネル、メモリ空間を切り替えてから
実行する形態がマイクロカーネル、と言うことになると思います。
例えば、read()コールを発行すると、モノリシックなら、キャッシュに載って
いれば、タスク切り替えなしで単にmemcpy()で済むでしょうが、
マイクロカーネルならば、必ずFSのタスクに切り替わる必要があると
思います。

17 ：

参考:
Linuxの作者もマイクロカーネルの弱点を指摘:
http://www.linux.or.jp/JF/JFdocs/linus-lecture/monolithic.html
Mach:マイクロカーネルへ移行していくと速度低下が見られたため、モノリシック
に戻さざるを得ない状況になったが、未だこの欠点は克服されておらず、
パフォーマンスを重視するOSでは、モノリシックを採用している:
http://e-words.jp/w/E3839EE383BCE382AFE3839EE382A4E382AFE383ADE382ABE383BCE3838DE383AB.html

18 ：

Minixを書いた教授(Tanen.)が、Linusへ送った批判の言葉:
「私は、特定のハードウェアに密接に関係した、特にIntel系のような
奇妙なCPUに依存したオペレーティングシステムを新たに書くことは、
基本的に間違っていると指摘しているだけです。OSそのものは、新しい
ハードウェアのプラットフォームに簡単に移植できるものでなければな
りません。25年前にIBM 360用にアセンブラでOS/360を書いても、おそ
らく大目に見てもらえたでしょう。しかし、10年前、8088用にMS-DOSを
書いた愚考を、IBMやMicrosoftは今になって認識しています。
1991年に386用のためだけの新しいOSを書くということは、今学期の成績
でもう1つ「不可」をもらうことにつながります。もちろん、期末試験で
うまくやれば、まだ単位を取得できるかもしれませんが。」
逆にLinusが教授なら、Tanen.には、不可を与えたことでしょう（苦笑）。
個人的には以前から、Linusの言葉の方が、心に届く言葉であるように
思えていたのですが、最近、Minixの実情を知ってからは、ますます、
感情的に、Linusを応援したくなってきています。
どうみてもLinusの方が色んな意味で歴史に残る人物なのに、この人
は、全く、、、。

19 ：

>「特にIntel系のような 奇妙なCPUに依存したオペレーティングシス
>テムを新たに書くことは、 基本的に間違っていると指摘しているだけ
>です。」
心の奥底から、煮えくりかえりそうな嫌な感じを受けました。
"庶民の世界のパソコン"は、互換性を保ちつつ、徐々にスライドさせ
ていきながら、進化していく原則があるので、事実上、Intel以外の
プラットフォームが庶民に行き渡ることは当面ないんですよね。
工学の目的は、「物作りの手法を分析し、実際に役立てる」こと
だと私は思っているので、税金などから高いマシンを買って貰って、
悦に浸ってる工学研究者が許せません。
宇宙の研究とか、科学の基礎理論の研究をしている人なら、大いに
高いマシンを前提にすることも結構だと思うのですが、コンピュータ
のOSに関する工学的研究は、実際に今手に入る材料や環境で如何に
上手くやりくるするか、も当然重要になってくるはずで、訳の分か
らない独自SPECのマシンで遊んで偉そうにイバズリかえっている
この人のような人間は全く好きになれません。
こういう人種は人類にとってマイナスなんじゃないですかね。

20 ：

>> 16
でも、Linuxに関して言えば、カーネルには専用のメモリ空間が
ありますよね？つまり、2.はある意味正論になる？

21 ：

> 物理学などは、大学での研究が信頼性はかなり高いと思う。なぜなら、
> 全部理詰め、論理、数式などで精密に導いているから、実験を全く
> しなくても、ほとんどの場合、正しい結果を得られる場合が多いと
> 考えられるから。
ご冗談でしょう?

22 ：

今目の前にあるマシンに、もっといいOSを載せたい、というのが、
自然な動機だと思います。
そして、それにはどうすればいいかを考え、解決策を提供するのが
本来の「工学」の姿ではないでしょうか。
「学問」は、実際に役立たなければ意味がありません。ただ、
基礎理論は、実際に役に立つんです。複雑な数式によって書かれている
ので一見理論の遊びのように見える人もいるかも知れませんが、
実際、かなり色んな事に応用が利くので、重宝しています。
しかし、工学は基本的にその場しのぎ的な教訓にどうしてもなってしまう
性質を持っているので、現実に即したことを前提にしないとほとんど
応用が利かないんです。物理学などでは、運動方程式を、惑星に対しても、
野球のボールに対しても適用できてしまうので、何にでも応用が利くので
すが、工学では、10年前の教科書の大部分が、実は今は役に立たないこ
とも実際にあります。なので、前もって研究するのではなく、なるべく
今の現実に沿わして常に調整しながら研究していかないと、誰も
役立てることが出来ないような、無駄な学問ばかりが出来てしまいます。
数百年前にできた古典物理学が今でも現役で利用できるのが、基礎理論
の凄いところですが、工学はなかなかそうはいきません。蒸気機関
の工学的な理論は、そのままでは今ではほとんど利用できないでしょう。
なぜなら、基礎理論を、具体的に「適用」した後の「結果」だからです。
なので、適用を実際に沿わせないと、今も十年後も全く利用価値のない
「ゴミ」の学問だけが遺ってしまいます。その点で、Linusの方が、
工学をよく理解していると思いますね。

23 ：

Tanen.教授の主張は、どこを見ても狂ってるように思えます:
>しかし、10年前、8088用にMS-DOSを書いた愚考を、IBMやMicrosoftは
>今になって認識しています。
そもそも、そんなことを認識していると誰から聞いたんですかいな。
それに、当時、一番人気のあるのがIntel系でした。もともと、
8BITのIntel-8080Aが人気があり、Zilog社にZ80として移植され、
日本でもNECのTK80Aに8080A相当品、PC-8801シリーズには、Z80相当品
が用いられたことが有名です。それを16BITに拡張したのが、8086で、
それの安価版が8088です。しかし、当時、それを載せたパソコンは、
30万円〜50万円したので、それ以上のCPUを望むことは出来ませんでした。
68000シリーズもあって設計はよいのは知られていましたが、
8080A,Z80,8086,8088系統とは全く互換性がないので余り人気がありま
せんでした。ですので、MSやIBMが、8086,8088を対象にしたのは、
正しい選択だったと思います。市場に受けいられるにはそれしかなかった
とも言えます。実際、68000シリーズは、マニア受けは良かったのですが、
余り大きな潮流にはならず、大して普及しなかったのです。
基本的に、市場=民意なので、市場が欲しがるものは、世の中で必要とされて
いるものなのです。互換性を維持し続けないと、過去の資産が全く使えなく
なり、もし互換性を無視していたなら、ソフトウェアの実際的な運用に基づ
く発展は阻害されていたと思います。そもそも、市場で売れなかったと
思いますし、そうなれば、Tanen.教授の今の立場も無かったと思います。
市場が発展したからこそ、コンピュータサイエンスが政府などからも
支援の対象になって来たのでしょう。もし、互換性を全く考えずに
来ていたなら、今日のような発展はなかったと思います。
Tanen.教授の考え方は、全く的はずれで、どこか研究者の我が儘を感じ
させます。

24 ：

LCって誰？OSの開発者？

25 ：

>>21
そもそも、OS研究に限っては、大学でも、大して「アカデミック」では
無いと思う。全然大したことやってない。
それから、半導体の分野でも、企業の方が大学より5年は進んでいる
と聞いたことがある。
実際問題、Intelの技術より上回っている自信がある日本の大学
研究室はどのくらいあるだろう。
というよりも、ないんじゃなかろうか。
実装技術は、デジタル・ドカタにやらせておいて、高度な理論(笑)は、
学者である自分たちのみが考えられ得る、みたいに傲慢になっている
人までいるようで、馬鹿げています。

26 ：

>>24
そうだよ。ってゆーか、知らんかったんかい。（ｗ

27 ：

> 例えば、read()コールを発行すると、モノリシックなら、キャッシュに載って
> いれば、タスク切り替えなしで単にmemcpy()で済むでしょうが、
> マイクロカーネルならば、必ずFSのタスクに切り替わる必要があると
> 思います。
はいはい、それは70年代の真実な。
readの先がキャッシュ可能でローカルにあるものとは限らないのが現実だ。
マイクロカーネルかモノリシックかなんて議論、いまどきナンセンスなんだよ。
こんなスレで嬉々としているLCよ、教科書の範囲で水遊びしていることに気付け。

28 ：

>>14
タネンバウムが本当にやりたかったのはMinixみたいな糞じゃなくてAmoebaだったんだけどなー
UNIXの次は分散OSってことでPlan9やAmoebaが出てきた
PS3によってようやく分散OSが市民権を得るって時代になってんだけどなー

29 ：

>>26
知らんかった。詳しく教えてちょ！

30 ：

>>29
ここに書いてあるのは全部コピペだよ
http://pc.2ch.net/test/read.cgi/os/1026581522/
本人はもう2chからは手を引いたと言われている
ちょうど今日、彼のスレが幕を閉じた...
http://pc.2ch.net/test/read.cgi/os/1057237050/

31 ：

分散OSをさらに発展させるのは次世代プロセッサCELLになり得るか。
ちなみに、CELLで動くOSはモノリシックカーネルになるのだろうか、
それともマイクロカーネルか？

32 ：

マイクロカーネルが性能面で劣ることはタネンバウム自身
認めているので、そこを突いても無駄。
拡張性・生産性・ネットワーク透過という面の比較キボンヌ。

33 ：

>>30
あぁ、LCってLightConeの略か！「OSを作ろう」スレにも登場してた
人ですね。失敬。。。
でも、2chから手を引いたのなら何故このスレにいるのでしょうか？
お話は非常に面白いし参考になります、はい。

34 ：

>>33
だから本人じゃなくてどっかの厨が過去ログからコピペしてるだけっつってんじゃん

35 ：

失敬。
>>34の名前はミスです。
本当は30でした。

36 ：

拡張性は、理論的にはマイクロカーネルがの方が上のはずだが、
実際、モノリシックカーネル＋モジュールという形式の方が上
に見えるが、いかがでしょう？

37 ：

>>34
あ、そういうことね（＾＾；

38 ：

コピペであれ何であれ、
LightConeが一番しっかりしたこと書いてるように感じるのは気のせい？

39 ：

>>38
気のせい。(Linusさん信者だったのね。ふーん（´_ゝ｀）
つか、どっかでNWSOSをマイクロにしたいとか逝ってなかった？

40 ：

　∧||∧
（　 ⌒ ヽ　>>38
　∪　　ﾉ　お前が感じている感情は精神的疾患の一種だ。
　　∪∪　 鎮める方法はない。逝ってよし。

41 ：

>>39
855 名前： LightCone ◆sSJBc30S5w 投稿日： 03/06/21 23:04
NWSOSの開発を続行するかどうかよく分からないのですけど、取りあえず
メモリ取得の速度のオーダーを順番に確保していくときはO(1)程度に
高速化して、さらに、セクタバッファの探索にハッシュを用いたり、
ライブラリでファイルバッファをかまして高速化したりしたので、
ファイルやデータを扱うようなアプリは、かなり高速になったのですが、
さらに遅延書き込みも仮サポートしてみたおり、いっそ、マイクロカーネルに
しようかと思ったのですが、その利点に、かなり疑問があり、悩んでます。
なにか、ご意見有りませんか。

42 ：

>>41
なんか他所でも逝ってた様な気がする。(つか、何が"かなり高速"だよ。(w

43 ：

>>42
この頃のLﾀｿは互換ライブラリを締め出した頃よりずっと良くなってたんだけどなー
今はわけわかんない精神世界に逝っちゃったから技術者としてはおしまいだーね
あんたも文句ばっか言ってないで簡単なゲームでいいから作ってみなー

44 ：

>>43
そんなことしたいので、とりあえず図書館でまた本借りてきますた。

45 ：

>>44
できない奴はできないよ。
センスが無いんだから諦めろ。

46 ：

Minix使ったことある人っている？

47 ：

オブジェクト指向との親和性でマイクロカーネル優位。
これを生かすためにはオブジェクト指向言語が不可欠。
それもObjective-Cみたいな原始的なものがベスト。

48 ：

>>47
Darwinマンセー、だね！

49 ：

>>47
しかしパフォーマンスが悪いわな。
プロセス間通信によるオーバーヘッドをどう回避するか。

50 ：

>>49
だからDarwinではMachの純粋性を諦めて、
ファイルシステムやネットワーキング、ユーザー管理といったものも
カーネル空間の中で動作するようにしちゃったわけよ。

51 ：

>>50
あれってモノリシックだったんじゃ？

52 ：

>>51
そのことについて「Machの純粋性を諦めて」と書いたわけです。
ただ設計はどうあれMachのAPIは全部使えるのがミソでしょう。
QuartzなんかはMachのメッセージング機構を使いまくりなので
非MachのOSに移植するのは難しそうです。

53 ：

>>44
とりあえずあんたみたいな厨房にはC#がぴったりだよ。
間違ってもJavaとかRubyとかＷｉｄｅＳｔｕｄｉｏには手を出さないこと。
あんたと同レベルの基地外がうようよいる所だから、
基地外同士で連携されたりした日には
他人にどれだけ迷惑になるか分かったもんじゃないからな。

54 ：

>>52
ということはDarwinではモノリシックに軍配が上がったということ
ですよね？

55 ：

>>53
なんか必死に誘導しようとしているな

56 ：

Darwinの場合、UNIXであることが足かせになったってことだろな。
でっかい固まりとしてラップすることはできても、UNIX自体はオブジェクト指向ではない。
しかし、UNIXである利点は無視出来るもんでもない。

57 ：

いまさら、マイクロカーネルかモノリシックカーネルかで優劣競っても意味ないんじゃない？
RISC vs. CISC 論争を思い出すよ。

58 ：

>>54
現状では、ね。
CMTって言って、今後プロセッサの集積化がどんどん進むと思われるが、
1チップで16プロセッサとかなってくると、
果たして今のDarwinの構造が最適かという問題が出てくるだろう。
そうなってくると、むしろ1台のマシンの中で分散OS化した方が効率が良い。
でもここまでの高度化がJobsの言ってた「今後15年」っていうDarwinの寿命の中で
起きるかどうかは知らんけど。

59 ：

>>57
CPUが高速になった現代では意味のない議論だってことか？

60 ：

てか、UNIXが元々モノリシックってことか。

61 ：

>>59
同じことはJavaとか.NETとかのバイトコード方式にも言えるね

62 ：

>>58
現在の最高性能だけを視野に入れるならマイクロカーネルが有利だろうね。
最高性能だけを視野に入れるならだが。

63 ：

>>59
というより、どちらもお互いのイイトコ取りしてパフォーマンス上げてるから純粋性無くなってるってこと。
デバイスドライバのモジュール化とかさ。

64 ：

最高性能が欲しいならﾓﾉﾘｼｯｸのほうが絶対有利。
タスクスイッチしなくていいから。
(だからとてLC氏のDOSﾏﾝｾｰはなんか違うのだが)
もっと性能がほしいならＯＳなんか使わないのが正しい。

なおLinuxのデバドラモジュールはﾏｲｸﾛｶｰﾈﾙとは関係ない。

65 ：

>>64
そうだね。デバイスドライバのモジュールはマイクロカーネルのとは関係ないですね。
タスクスイッチなぁ。確かにですわな。
つーことは、単一プロセス・マルチスレッドでカーネル書くか、ってことだな。

66 ：

>>64
>>62は最高性能のマシンだけって意味だと思うけど。

67 ：

>>58
確かにCMTでもＳＭＰでも、マルチプロセッサになってくると、
マルチカーネルみたいなのに走りたくなってくる。
ただ、うまく作らないとロックのコストが高くなりすぎちゃうんだよね
カーネルをタスクで実装すると、そのあたりの設計の苦労が軽減する
気がする。（まあ別の苦労があるんだろうけど）
>>64
タスクスイッチのコストってそんなに大きいんだろうか
と常々思う。CPUが高速化するにつれ、他のコスト（キャッシュミスとか）
の方が大きくなっていくだろうね、きっと。

>>66
性能に関しては、MPマシンだとマイクロカーネル有利、1CPUならモノシリック有利
ってことじゃないかな

68 ：

s/モノシリック/モノリシック/
なんでかしらないが、素でよく間違える('A`)

69 ：

月刊ASCIIのセイで今の今までずーと"モノシリック"と思ってますた。。。

70 ：

>>67
SMPとかだと、どうしてもロックに恐ろしいくらいコストかかる。
そんでもってプロセス生成が異常に遅くなる。
そうなってくるとマルチスレッドのサポート具合がOS性能決めてくる結果になってしまう。

71 ：

CMT : Coarse grained MultiThreading
CMP : Chip-level MultiProcessing
で良かったでしょうか？

72 ：

>>71
CMT: Chip MultiThreading
が普通じゃないかな？

73 ：

>>72
THX!

74 ：

>>67
同一プロセス内でのスレッド切替はそんなに時間かからんよ。
VM切替を伴うものが問題。
だからスピードだけが欲しいならカーネル含めて
「単プロセス複スレッド」が有利。
もちろんVMはメモリ保護という重要な役割があるので
VMは欲しいことも多い。
(RTLinuxやVxWorksはこの辺がヘボいので苦労するらしい)
実際にはスレッドとかより>>70の言うような
排他ロック(mutex)による性能低下のほうが大きい。
ｼｽﾃﾑｺｰﾙ毎にｶｰﾈﾙを丸ごとロック(giant lock)する
昔のﾓﾉﾘｼｯｸｶｰﾈﾙはMPでは（思ったほど）性能が出ないことがある。

75 ：

>>74氏はご存知かと思うけど、「だったらプリエンティブカーネルに
すりゃいいじゃん」、と勝手に補足しておこう。
作るの地獄だけど。

76 ：

プリエンプティブとリエントラントを混同してる痛い香具師がいるな

77 ：

未だにカーネル丸ごとロックなOSって多いよね。
割込ロックだけにするとドライバとかプロトコルスタックとかも
全部書き直し必要だからしかたないと言えば仕方ないかもしれないけど。

78 ：

それわおめーだっつーの>>76
じゃ「リエントラントカーネル」て何よ。
プリエンプティブカーネルはリエントラントであることは必要条件だが

79 ：

どうでもいい話かもしれないか超漢字はマイクロカーネル採用らしい

80 ：

(^_^;

81 ：

未来指向派 vs リアリスト、みたいなもんだろ。未来指向派がマイクロカーネル。

82 ：

モノリシックカーネルで
プリエンティブマルチタスクで、なおかつ
リアルタイムOSなんて可能なんですかね？

83 ：

Lﾀﾝ、OS作り
や　　ら　　な　　い　　か　　？

84 ：

WinNTは実用的なマイクロカーネルだね！




WinXPでは崩れてるかもしれないけど

85 ：

GNU Hurd は Windows の夢を見るか？

86 ：

>>84
前から崩れてる。
NT3.51のころはきれいだったんだが…

87 ：

カトラー vs ストールマン

88 ：

BSD Conでこのスレの話題が出てきて藁他

89 ：

>>82
「リアルタイムOS」を定義汁。
話はそれから堕。

Lﾀｿが「DOSが層ですが」に120ﾙｸｽ

90 ：

>>82
可能だろ。
リアルタイム性に影響するのはタスクスイッチ方式と
システムコールの不可分性。

91 ：

すまん間違えた。
タスクのスケジューリング方式。

92 ：

その「タスク」にカーネルのお仕事が入るかどうかで
>>75のような地獄を見るかどうかが決まるわけで。

マイクロカーネルにすればこの辺はずいぶん楽になるわけで。

93 ：

>>74の「SMPだとmutexのコストが増加する」っての解説きぼんぬ。
複数のCPUが一つの資源を同時に取りに行って、なかなか取ることが
できないから、その間はスピンロックで待ってるから遅くなる、
ってこと？

94 ：

>>89
モノリシックカーネルで
プリエンティブマルチタスクで、なおかつ
ハードリアルタイムOSなんて可能なんですかね？

95 ：

>94 実現可能性を知りたいなら作ってみれば？
漏れがその条件を満たすならマイクロカーネルにするけど。
楽だし。

96 ：

しかしｶｷｺしてる椰子で「リアルタイムＯＳ」がどんなもんか
分かてるのはどのくらいいるんだ？
Lﾀｿが力いっぱいｶｿﾁｶﾞｲしてるくらいだから無理もないが
「リアルタイムＯＳは速い」わけでわないぞ。
早毛りゃ世の中のＯＳ全部リアルタイムＯＳになってるはずだ罠

97 ：

>>96 Lなんとかはどうでもいいよ。
とりあえず、このスレはこの厨房板の割にはレベル高いので、
μITRONくらいは知ってると思うから別にいいよな？

98 ：

デスクトップでリアルタイムOSってメリットあるの？

99 ：

どうなんでしょう。
人間相手に1msレベルの応答速度はいらないし。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

なんで超漢字なんてダサい名前にしたんだ (221)
一番良いOSは？ (359)
WinＸＰから2000に乗り換えて困った事 (234)
RedHat Linux最強！WinXPウンコ！ (212)
Windowsの限界を感じたとき (860)
フォーマット時の　「ＦＡＴ」　or　「ＮＴＦＳ」 (389)
--log9.info------------------
運命の人について語るスレ (653)
正しいデートの断り方・正しい振り方 (348)
同じクラスに好きな人　20人目 (932)
笑顔だけで異性の心を虜にできますか？ (228)
★★★純情板休憩所61.51★★★ (933)
。〇゜ 電車の中の恋心 58両目 ゜〇。 (277)
駅員を好きになってしまった人のスレ　2駅目 (406)
※※好きな人の名前を書いて呪うスレｗ※※ (440)
生理的に無理 (227)
何で女は気のない相手でも飲み行ったりするの？ (215)
社交不安障害(社会不安障害)63 (302)
■■怒りがとまらん・・・被害妄想？■■ (558)
統合失調症の陰性症状に苦しむ人39 (673)
お薬飲んだらageるスレ 24錠目 (259)
【金春】ハルシオンスレッド20【銀春】 (221)
友達も親しい知り合いも本当に一人もいない人 (847)
--log55.com------------------
2018 F1 GP 第06戦モナコGP lap12
【ATP】テニス総合実況スレ2018 Part375【WTA】
2018 F1 GP 第06戦モナコGP lap13
2018 F1 GP 第06戦モナコGP lap15
2018 F1 GP 第06戦モナコGP lap16
2018ｲﾝﾃﾞｨｶｰｼﾘｰｽﾞ Lap.12 第6戦ｲﾝﾃﾞｨ500 Lap.3
2018ｲﾝﾃﾞｨｶｰｼﾘｰｽﾞ Lap.13 第6戦ｲﾝﾃﾞｨ500 Lap.4
【ATP】テニス総合実況スレ2018 Part376【WTA】