今日は筑波に行こうと思っていたのだけど、あまりの寒さに断念。4月並みに
暖かかった日が今日ならよかったのに。
また机を作ることにしました。いつも通りの仕様。2x6 2.4m二本、2x4 2.4m3本 から荒木取り。天板用の2x6材は余分にもう一本使って、6枚の中からいいとこ 4本取りに。店で買う時に一枚一枚吟味しても、いざ使おうとするとひどいのが まじってる。ここずっと端材処理活動に励んでいたので新品の材料使うのは久々 だ。
桟積みしてまたしばらくシーズニング。
FF13続き。一日4,5匹づつタイマイを狩り続けている。タイマイのドロップは確 変だ。来ると9割近い確立で落とし続ける。継続範囲は4〜10体。継続している 時は実時間は関係なさそう。倒してセーブしてタイトルに戻って、1,2時間放置 してまたやって、また放置してでもずっと継続する。翌日まで放置してもOK。 なんとかこの確変を制御できないかとあれやこれや試しているのだけど、ない。 二回続けてドロップがなければ確変終了かな。
スケジューラアクティベーション続き。この論文ではアップコールの性能はカー ネルスレッドの5倍悪い。これは著者らはModula-2+のせいにしている。 しかしさすがDECだ。Modula-2+とは。
また机を作ることにしました。いつも通りの仕様。2x6 2.4m二本、2x4 2.4m3本 から荒木取り。天板用の2x6材は余分にもう一本使って、6枚の中からいいとこ 4本取りに。店で買う時に一枚一枚吟味しても、いざ使おうとするとひどいのが まじってる。ここずっと端材処理活動に励んでいたので新品の材料使うのは久々 だ。
桟積みしてまたしばらくシーズニング。
FF13続き。一日4,5匹づつタイマイを狩り続けている。タイマイのドロップは確 変だ。来ると9割近い確立で落とし続ける。継続範囲は4〜10体。継続している 時は実時間は関係なさそう。倒してセーブしてタイトルに戻って、1,2時間放置 してまたやって、また放置してでもずっと継続する。翌日まで放置してもOK。 なんとかこの確変を制御できないかとあれやこれや試しているのだけど、ない。 二回続けてドロップがなければ確変終了かな。
スケジューラアクティベーション続き。この論文ではアップコールの性能はカー ネルスレッドの5倍悪い。これは著者らはModula-2+のせいにしている。 しかしさすがDECだ。Modula-2+とは。
Scheduler Activations: Effective Kernel Support for the User-Level Management of Parallelism Thomas E.Anderson, Brian N.Bershad, Edward D.Lazowska and Henry M.Levy University of Washington ACM Transactions on Computersystems, Vol.10, No.1, February 1992,p53-79. 5 性能 我々の研究の目標は、カーネルスレッドの機能と、それぞれのアドレス空間上 のユーザ層で並行性を管理する性能と柔軟性を組み合わせることである。機能 と柔軟性については、これまでの章で検討した。性能の点で、三つの問題を検 討する。一つは、このシステムでユーザ層スレッド操作(即ち fork, block, yield)のコストはどの程度か? 二つ目に、カーネルとユーザ層の間の通信コス ト(具体的にはアップコール)はどうか? 三つ目は、アプリケーションの性能に 全体としてどの程度影響があるか? 5.1 スレッドの性能 ユーザ層スレッド操作のコストは、この研究の前からFireflyで使われていた FastThreadsパッケージ(これはTopazのカーネルスレッドの上で走行する。シス テムとの統合性は貧弱である)のそれと本質的には同じである。表4には、表1に あった、元のFastThreads、Topazのカーネルスレッド、Ultrixプロセスのデー タに今回のシステムのデータを追加した。 表4 スレッド操作の待ち時間 (usec) ---------------------------------------------------------------------------------------- FastThreads on FastThreads on Operation Topaz threads Scheduler Activations Topaz threads Ultrix processes ---------------------------------------------------------------------------------------- Null Fork 34 37 948 11300 Signal-Wait 37 42 441 1840 ---------------------------------------------------------------------------------------- 我々のシステムはユーザ層スレッドをカーネルスレッドの上で提供する利点を そのまま保っている。Null Forkでは3usec元のFastThreadsより悪くなっている。 これは実行中のスレッドの数を増減することと、カーネルに通知するかを決定 することによる(単一プロセッサのマシン、あるいは利用可能なできるだけ多く のプロセッサを常に要求する十分な並列性がある場合は、この部分はなくすこ とができる)。 Signal-Waitでは5usecの悪化している。これは横取りされたス レッドが再開しているのかどうか(その場合は、条件コードを復帰する余分な仕 事をしないとならない)を調べるコストによる。カーネルスレッドよりはまだ一 桁ほど性能がいいが、4.3章で述べたロックを保持した時のゼロオーバーヘッド のやり方なしでは、とても性能が悪くなる。この最適化なしでは、Null Forkは 49usecに、Signal-Waitは48usecになる。(Null ForkはSignal-Waitにくらべて より多くのきわどい領域がある) 5.2 アップコールの性能 スレッドの性能(5.1章)では、頻繁に起こる(カーネルとの関与のない)状況につ いての特性を示した。アップコールの性能、これはまれに起こる状況であるが、 いくかの理由により重要である。一つは、損益分岐点を決定するのに役立つ。 カーネルスレッドより性能がよくなりはじめるのに必要な、ユーザ層で実行で きるスレッド操作と、カーネルの関与が必要なスレッド操作の比である。もし、 ユーザ層スレッドをカーネルからスケジューラアクティベーションを使ってブ ロックあるいは横取りするコストがカーネルスレッドのそれと同等であれば、 スケジューラアクティベーションは単一プロセッサ上では現実的には同じにな りえる。さらに、スレッドが横取りされた時と、アップコールによってそれが 再スケジュールされた時の間の待ち時間によって、横取りされたスレッドが保 持しているきわどい資源のために、アプリケーションの他のスレッドがどの程 度待たないといけないかが決定される。 この実装を開始した時、アップコールの性能はTopazのカーネルスレッド操作と 同じくらいと期待していた。我々の実装はそれに較べて相当遅い。アップコー ルの性能を測定の一つは、二つのユーザ層スレッドがカーネルを通してシグナ ルし、それを待つ時間である。これは表4のSignal-Waitテストとその同期がカー ネルによってなされるという点以外では類似している。これは、I/O要求やペー ジフォルをスケジューラアクティベーションによって開始し、完結するオーバー ヘッドの近似する。そのSignal-Wait時間は2.4msecでTopazスレッドより5倍性 能が悪い。この違いの原因となる、スケジューラアクティベーション固有の問 題はみつからない。それは二つの実装問題のせいである。一つはスケジューラ アクティベーションをTopazのカーネルスレッドシステムのてっとりばやい改造 として作成したこと。もっと整備しなくてばならず、これをスクラッチからカー ネルに設計した場合にくらべてオーバーヘッドがあるということ。重要なのは Topazのスレッドシステムはアセンブラによって慎重に最適化されて書かれてい る。我々のカーネル実装は完全にModula-2+によって書かれている。比較として、 SchroederとBurrows[19]はSRC RPCの処理コストをModula-2+からアセンブラに 書き直すことで4倍以上減らした。従って、最適化されれば、アップコールの性 能はTopazのカーネルスレッドの性能と同程度になると期待する。結果として、 次章のアプリケーションの性能の測定は、製品レベルのスケジューラアクティ ベーションの実装よりは幾分悪い結果となる。
