メモリの動的確保方法。

これまでいくつかの動的メモリ確保方法を用いて数値実験を行ってきた。大きくわけて次の３つの方法である。

1. MALLOC  : malloc / free
2. MMAP    : mmap / munmap
3. HUGETLB : mmap / munmap

しかしながら、優先キューにはあまり要素を確保されないので、初めは小さく確保し必要になったら要素数を大きくするような実装にしたい。そこで、MALLOC と MMAP に関してはそれぞれ realloc と mremap でリサイズ可能であることは確かめたのだが、HugeTLB に関してはどうもうまくいかない。

1. MALLOC  : malloc / realloc / free
2. MMAP    : mmap / mremap / munmap
3. HUGETLB : mmap / mremap?? / munmap

mremap だと思うのだが。エラー番号 29 になる。

修士論文の提出方法。

ちょっと気になったので、書いておく。うちの大学では、PDF を CD-R に焼いて提出することになっていた。しかしながら、CD-R は１人２枚（論文と要旨はそれぞれ別）のディスクを使うため、もったいない。700MB なら例えば研究室ごとに提出すべきではないかと思う。そのまま保存するのであれば、学生にディスクを焼かせるというのはいかがなものかと思うし、まとめるのが面倒ではないかと思うのだが。。。まあ、不思議なルールというのは、どこにでもあるものだ。

ubuntu - rpm。

■ RPM パッケージの利用方法
プリンタのドライバをインストールする際に RPM しかなく、ソースからのコンパイルは何かと面倒なので、
alien をつかってみることとした。で、*.deb が生成されるため、簡単。

$ sudo alien foo.rpm

次のようにすると、直接インストール。

$ sudo alien -i foo.rpm

ubuntu - adobe reader 8。

Adobe Reader 8 をインストールメモ。
x86_64 であるので、32bit パッケージは警告を出してしまうので、
--force-architecture をつけてインストール。楽ちん楽ちん。

$ sudo apt-get install ia32-libs
$ sudo dpkg -i --force-architecture AdobeReader_jpn-8.1.3-1.i386.deb

TeX 環境。

TeX 関係のパッケージのインストールメモ。複数サイトから拾ってきたので、かぶっているのもあるのかも。

$ sudo apt-get install texlive texlive-latex-extra dvipng latex-xft-fonts 
okumura-clsfiles xdvik-ja dvipsk-ja latex-cjk-japanese latex-cjk-japanese-wadalab 
jbibtex-bin mendexk xpdf xpdf-japanese gv gs-cjk-resource cmap-adobe-japan1 
cmap-adobe-japan2 cmap-adobe-cns1 cmap-adobe-gb1

$ sudo apt-get install ptex-base ptex-bin ptex-jisfonts jbibtex-bin jmpost mendexk dvipsk-ja 
dvi2ps xdvik-ja gv gnome-gv okumura-clsfiles vfdata-morisawa5 dvi2ps-fontdesc-morisawa5 
dvipdfmx cmap-adobe-cns1 cmap-adobe-gb1 cmap-adobe-japan1 cmap-adobe-japan2 
adobereader-jpn xpdf gs gs-esp gs-cjk-resource 
 
$ jisftconfig add

ubuntu@Wubi メモ - 2。

Let's Note CF-W8 にインストールして使用している。
Ubuntu は今までちょこっとしか使ったことがなかったが、なかなかよい。
今のところ、以下のような問題点がある。

・ハイバーネートが使用不可（Wubi のため）、サスペンドはうまくいく
・OFF の光学ドライブは使用不可（BIOS で 常に ON にしておけば OK）
・無線 LAN もうまく動作
・スピーカーでの音声出力の方法が分からない（イアホンは確認済）

スケジュール帳 - その後。

４月始まりまでのつなぎとして買ったスケジュール帳をなくしてしまったことは、以前書いた。そのせいでつなぎのスケジュール帳を再び買うことになったのだが、こういうものは買った途端見つかるというのが大抵で、今回も漏れず見つかった。どこにあったかというとソファの隙間である。こういったことが多いので、気をつけなければならない。やはり思い入れのあるものでないと大切に使わないものだ。

落し物。

プライベートでは週１以上でカラオケを利用しているが、先日 MP3 プレーヤを忘れてしまい、かつ連絡をしなかったので、取りに行ったときにはすでに警察に届けた後だった。MP3 プレーヤ、オスオスのステレオミニケーブル、ステレオミニ-ステレオ変換プラグ（どういう使い方しているか分かってしまいそうだ。）と、レアな組み合わせだったのだが、よくそのままの形で帰って来てくれたと思う。

PowerPoint のPDF 化。

修論発表では、接続した途端に PC が落ちてしまい、見苦しいスライドで発表することになってしまったが、実は PDF の準備はしていた。Acrobat elements による変換だったのだが、埋め込んだ PNG がひどいものになった。ということで、PDF は諦めて、を学科の用意していた PC 上で PowerPoint ファイルを実行したのだが、デフォルトでは入ってない MeiryoKe フォントの存在をすっかり忘れていて、大変なことになっというわけである。

[その他の形式で保存]で PDF 変換（アドオンを入れる必要がある）すればよかったというオチで、Acrobat elements よりも小さなファイルサイズ（今回は半分）できれいな PDF に変換が可能だった。Acrobat elements では、PDF プリンタで印刷することで PDF を作成することになるため、とても時間がかかってしまっていた。直接変換する仕組みがあるなら、その方がよいという話である。

実行時間 v.s. メモリ要求量。

2-heap に対しての実行時間とメモリ要求量のトレードオフについて。2-heap を実装するための配列を動的 (2-heap[d]) にとるか、静的 (2-heap[s]) にとるかという点に関して、ひとまず以下のような結果になっている。2-heap に格納されるデータ数は、高々 [点数-1] だが、道路ネットワークでは数千程度であるので、静的にとるとそのほとんど無駄になってしまう。以下は 4 threads の結果であるが、このくらいの性能低下であれば、悪くないだろう。

malloc で確保していれば気軽に realloc できるが、mmap などで確保している場合 mremap をすることになるだろう。HugeTLBfs でも同様だろうか。また、そのコストなど、調べてみよう。

[4 threads]
2-heap[s]  166.0 sec / 3460 MB
2-heap[d]  170.4 sec / 1998 MB

修士論文審査発表会。

どうにか無事（？）終了しました。

Let's Note CF-W8 で発表を予定したのだが、VGA 端子に差し込むと固まってしまったために急遽学科で用意していた PC を使用することに。作成したスライドはデフォルトでは入っていないフォントだらけであるので、体裁がとんでもないことになってしまって、見苦しいものをお見せすることに。。やはり PDF ですね。

SDPA ゼミ。

SDPA ゼミに参加。すごく丁寧に教えていただきました。今までバラバラな事柄がある程度つながったようでした。深いところでは全然わかってないですが、流れは追えるようになったかと。これから楽しくなりそうだ。

最短路ソルバーのボトルネック。

後藤さんから頂いたプログラムの実行結果の抜粋。（ずいぶん温めてきてしまいましたが）このプログラムでは、２スレッドで同じ領域のデータを参照していく際のメモリバンド幅を測定している。L2 キャッシュに乗るであろうサイズの場所を見ていくと、L2 共有コア同士では他の場合と比べ 16 % ほど性能が低下している。２プロセス同時実行では 21 % ほどであるので、これがボトルネックの主要原因であるといえる。

ソースコードの整理。

少しずつソースコードを整理している。やはり K&R をもう一回きちんと読み直すか。性能に大きく影響を及ぼさない部分に関しては、関数化して読みやすくするつもりである。メモリ確保ルーチン付近をきれいにしてみたが、かなり読みやすくなった。

データの配置方法と性能。

様々なアーキテクチャ上でのデータの配置方法を変えての実行時間について。次のように、graph (forward-star) についてと、node (作業領域) について、以下のように２種類用意した。

graph1 : 改善前
graph2 : 改善後
node2 : 改善後
node1 : 改善後

Nehalem では広域なメモリバンド幅のおかげで、こういった工夫の効果が見えづらいようである。