現在使用中のノートPCを延命
乗り換え先候補となるノートPCを、色々検討してみたりもしたのですが、最終的な結論として、当面は現在使用中の Let's note CF-J10 の使用を継続することにしました。
但し、「特に何もしないでそのまま使用を継続」という訳にも行かなかったので、幾つか延命措置を講じることに。
メモリの増設
現在使用中の CF-J10 の一番の問題は、最大搭載可能メモリが 6GB という点です。
この容量では、1GB のメモリを割り当てた仮想マシンの場合、1台稼動させるのがやっとです。とてもではありませんが、「2つの仮想マシンで Solaris と Linux の挙動を比較しつつ、ネット上の資料をブラウザで参照する」などということは出来そうにありません。
ノートPC乗り換えに対する元々のモチベーションにおいて、仮想マシンを複数稼動させるために「せめてメモリは8GB欲しい」という点は、結構な比率を占めていたのです。
ところが、後述するキーボードの問題への対処で、分解した CF-J10 本体を眺めていたところ、「本体内蔵メモリ (2GB)」と呼ばれるものが、一般的な SO-DIMM モジュールであることに気が付きました。
てっきり基盤に直付けされているもの(= 事後増設は不可)と思っていたのですが……
どこからどう見ても、取替え可能な一般的な SO-DIMM にしか見えませんので、「自前で搭載メモリを増量できるのでは?」という考えに至るのは当然と言えるでしょう(笑)
インターネットの海を彷徨うこと暫し…… 16GB 増設での動作報告がありました!
OpenSolaris 勉強会 2014.05
日本OpenSolarisユーザーグループ主催の Tokyo OpenSolaris 勉強会 2014.05 に参加してきました。
今回は何故かドタキャンが多発して、参加者9名での開催でした。会場セキュリティの都合から、参加締め切りが前日になってしまっているため、「当日でもキャンセル可能なので、まずは参加登録を!」とのアナウンスに効果があった、ということで、良しとしておきましょう (笑) > ポジティブシンキング
今回は、原口さんの「はじめての DTrace(3) "簡単なことからコツコツと"」枠との二本立てでした。
続きを読むノートPC買い替え候補の調査
普段持ち歩いている Let's note CF-J10 を購入したのが、3年前の 2011年初夏でした。
これまでの経験では、そろそろスペックの見劣りや、経年劣化による問題が出てくる頃なので、世代交代を念頭に入れておく必要があります。
これまでの私のノートPC選定基準は:
- 本体重量 1kg 未満 (or 最大で 1.1kg 前後)
- 満充電で5〜6時間程度稼動できるバッテリー
- プログラム開発(コンパイル等)が出来る程度の CPU パワー
というものでしたが、現状だと更に以下の項目を追加したいところです。
- 搭載可能メモリ 8GB 以上 (1GB メモリを割り当てた仮想マシンを同時に2つ稼働可能)
この条件に合致する手頃な価格のノートPCに関して、ここ暫く色々調べまわった結果を、備忘録代わりに公開しておきます。
※ 最終的には、CF-J10 に延命措置を施すことにしました。
Panasonic
Panasonic からは、「アンダー 1kg」な CF-Rn/Jn シリーズの後継機種が、CF-J10 以降は出ていません。
とりあえず 1.1kg 前後で妥協するなら、一応候補はあるのですが、プログラム開発に使える程度のスペックを満たそうとすると、20万円オーバーコースになってしまいます。
Panasonic のラインナップは、経費で購入できるビジネスマン向けに、比較的高価格帯へとシフトしている印象がありますね。
Mercurial 開発環境におけるテストセット実行性能の改善
先に結論を書いておきますが、要するに:
利用可能な CPU コア数を増やし、高並列に実施すれば、早く終わる
という、至極平凡な話です(笑)。
事の始まり
先日、自分の投函したパッチに関して、マスターリポジトリに変更が取り込まれる寸前に、ちょっとした間違いに気付いたので:
まだ修正が間に合うなら、正式取り込みはちょっと待ってくれない?
数10分以内に、修正版のテストを実施して、再投函するから。
という意図のメールを開発向け ML に投函したところ:
ちょ、え、まじ?テストが2分で完走しない環境なの? (意訳)
という返信をもらいました。
私の Mercurial 開発のメイン環境は、VirtualBox on 64bit Windows7 上で稼動する 64bit debian 環境なのですが、仮想環境ホスト側は、メモリこそ当時としては破格の 16GB を搭載しているものの、静穏・省電力を重視して AMD Phenom II X4 905e を使用してるので、2009年の導入から5年程が経過した今となっては、流石に非力さを隠せません。
また、以前(3年程前?)確認した際には、15分程度で完走していた(と記憶している) Mercurial のテストセットも、現時点で改めて確認してみたら、完走に30分を要するまでに肥大していました…… orz
件の返信のような「2分で完走」は無理にしても、流石にテスト完走に30分掛かるのはまずいので、開発環境における Mercurial テストセットの実行性能改善に着手することにしました。
OS毎のシステムコール実行性能 〜 その6(まとめ)
幾つかのシステムコールの実行性能をOS毎に計測して、「Mac OS X 上では、予想通りシステムコール実行性能が低めでした」という結論でサックリ終わる予定だったのですが、実際に計測してみると、思った以上に色々なバリエーションがあったため、予想外に内容が膨らんでしまい、今回を含めて6回にも渡るエントリになってしまいました。
とりあえずは、ある程度の傾向が掴めたので、今回のまとめをもって、一連のエントリは一旦終わりにしようと思います。
- その1: fork, execve の性能計測
- その2: vfork の性能計測
- その3: fstat, lstat の性能計測
- その4: getpid, gettimeofday の性能計測
- その5: time, umask の性能計測
- その6: まとめ
まとめ
本エントリ群での計測結果を、以下にまとめておきます。
まずは、各OSの計測環境は以下の通りです。
---- | MacOSX | Linux | Solaris |
---|---|---|---|
OS 詳細 | Lion (10.7.5) | Debian (2.6.32-5) | OpenIndiana (151.a2) |
CPU | Core i5 2415M (2.3GHz) | Core i5 2410M (2.3GHz) | |
利用可能コア/スレッド数 | 4 | 2 | |
メモリ | 16GB | 2GB | |
インストール形態 | ベアメタル | 仮想環境 (VirtualBox on Windows7 64bit) |
そして、システムコール毎の計測結果は以下の通りです。
OS毎のシステムコール実行性能 〜 その5
- その1: fork, execve の性能計測
- その2: vfork の性能計測
- その3: fstat, lstat の性能計測
- その4: getpid, gettimeofday の性能計測
- その5: time, umask の性能計測
- その6: まとめ
time の性能比較
「システムコール実行性能の比較」という点では微妙ですが、前回の gettimeofday
で乗りかかった船 (笑) ですから、time
の実行性能も比較してみましょう。
以下は、0x4000000 =約6千7百万回の繰り返しで計測したものです (単位: 秒)。なお、time
の引数には NJLL を指定し、結果の書き込みは行わせないようにしています。
---- | Mac OS X | Linux | Solaris |
---|---|---|---|
time | 13.30 | 243.82 | 26.39 |
gettimeofday | 2.86 | 250.78 | 32.94 |
OS毎のシステムコール実行性能 〜 その4
本来であれば、その3までに実施した計測に先立って確認しておくべきなのですが、各OS毎の「システムコール実施自体のコスト」を、ここで改めて比較しようと思います。
実のところ、「比較しようと思います」などと言いつつ、比較そのものは出来ていないのですが、その理由は順次説明します。
- その1: fork, execve の性能計測
- その2: vfork の性能計測
- その3: fstat, lstat の性能計測
- その4: getpid, gettimeofday の性能計測
- その5: time, umask の性能計測
- その6: まとめ
getpid の性能比較
本来の処理に時間を要する (or 実装によって所要時間が大きく変動し得る) システムコールでは、「システムコール実施コスト」を比較することはできません。
とりあえず思い浮かんだものとしては、自プロセスのプロセスIDを取得する getpid
あたりが妥当そうな気がします。
早速、getpid
実施を繰り返すプログラムを作成して、システムコール実施状況を確認してみました……繰り返し回数とシステムコール実施数が全然一致しません…… orz
Linux 上では strace
、Mac OS X 上では dtruss
と DTrace の両方を使って、システムコール実施状況を確認した限りでは、一度だけ getpid
システムコールが実施されるものの、どんなに繰り返し回数を増やしても、それ以後は getpid
が実施されません。
ソースコードでの確認はしていませんが、おそらく:
という実装ではないかと思われます。