S.C. MAGI-SYSTEM 日記
Diary
2009年になって、実に3年ぶりに更新再開。

hns - 日記自動生成システム - Version 2.19.9

2005年03月12日() [n年日記]

[天気:晴れ](経堂某所) 起床:- 就寝:25:00

#1 [Univ] 第90回薬剤師国家試験 1日目

徹夜生活1日目。
朝8時前に家を出ないといけないこともあって、昨日の夜から不眠で試験勉強。
気付いたら朝になっていました。
こうやって長時間 iPod を再生しっぱなしにしておく *1 と、8時間前後というバッテリ時間が意外に短く感じられます。

本八幡から経堂の東京農業大学キャンパスまでの長旅。
東京横断とは言わなくても、それに近いくらいの移動距離です。
本八幡から総武線でお茶の水まで行き、そこから小田急線直通の地下鉄千代田線で 経堂へ向かう。

手応えについては…あはは。
尋かないで下さい。
*1: PowerBook で iTunes を使ってしまうと、ついつい PowerBook を触ってしまうので iPod で再生することにしていました。

2004年03月12日(金) [n年日記]

[天気:晴れときどき曇り](家) 起床:11:00 就寝:25:00

#1 [*BSD] Linpack Benchmark

TOP500 リストというのは結構有名だと思いますが、 ここのランキングは Flops で表されています。
はたして www.magisystem.netの Dual PentiumPRO 200MHz (1MB L2 Cache) がどのくらいの性能が出るのか Linpack Benchmark で計ってみました。
ブロックサイズやデータサイズを何パターンか試したところ、 ピーク値でだいたい 200MFlops 前後出ているようです。
まあ、サーバとしての運用をしつつの計測だったので完全なベンチマークとは言えないかもしれませんが、 だいたいの目安として妥当だと思います。
さきほどのリストの 500位 でも 400 G Flops 出ていることを考えると… 2000分の1 ですか?
まあ、相手が128台のクラスタであることを考えると、そんなもんかな。

計測することよりも、 ATLAS のコンパイルに1日もかかった方が長かった。(笑)
ちなみにせっかくの 1MB L2 Cache ですが、どうも演算の方が遅いために その L2 Cache をフルに充填させることなく、256〜384KB くらいしか使っていないようです。
つまり PentiumPRO 200MHz くらいの処理性能では 1MB の L2 Cache は 豚に真珠ってことですね。

…なんか悲しくなってきた。

2003年03月12日(水) [n年日記]

[天気:晴れ](家) 起床:8:00 就寝:21:45

#1 [Home] Nothing Special

毎日「よく分かる本」と戦っていると変化がなくてネタがないです。
今日は Slashdot.jp のネタです。
どうもニュースサイトを 無断でリンク しては いけない らしいです。
ふーん。
…というか、こういう新聞社系のニュースサイトってリンクでもされないと読まれないんじゃないの?
まぎーの日記は無断リンク 歓迎 なので、じゃんじゃんリンク *1 しちゃって下さい。
*1: でも 検索Bot は勘弁。(笑)

#2 [MacOSX] UFS or HFS+

MacOS Xのデフォルトファイルシステムは HFS+ なのですが、 実は UFS でもインストールできます。
HFS+ といえども、元となっているシステムがUnixではないので case insensitive *2 といった問題があるんです。
なぜこんなことが気になったかというと、先日 紹介 した PyGTK にまさにその問題があるのです。
PyGTK では GTK.py や GDK.py といったそれそれ gtk+ あるいは gdk-pixbuf に対するインターフェースと、 gtk.py という PyGTK そのものに対するラッパーが存在するんです。
もう分かりましたね。
そう HFS+ では GTK.py と gtk.py は同一と見なされてしまい、tar から展開する際に 後者の gtk.py が前者の GTK.py を 上書き してしまうのです。
ふぉぉ。

やっぱり UFS なのか?

という訳で、試しに UFS に MacOS X をインストールしてみちゃいました *3 。(笑)
Classic さえ使わなかったら UFS でも何ら問題ないかなぁ…と思ったんですが…
結論から言います。

遅くて遅くて使いものになりません。

MacOS X では MacOS 9.x以前(Classic)より引き継いでいる "リソースフォーク" という機能があります。
これは、各ファイルのヘッダに特殊なデータが収められているもので、WindosとMacでファイルをやり取りしたことがある人なら一度は見たことがある「Macバイナリ」とも呼ばれる部分です。
MacOS nativeではない UFS では、このリソースフォークを隠し属性の別ファイル *4 に書き込んでいるんですが、これがネックになっているっぽい。
つまり UFS で使うと、Finder内やMacOS Xなアプリケーションからファイルを操作すると "本来のファイル" と "リソースフォーク" の 2つ のファイルに対してアクセスしないといけないのです。
当然書き込みも2つのファイル *5 に対しておこるわけで…
ディスクアクセスがこんなにも遅くなるとは思わなかった。
*2: WindowsのFATもそうですね。例えば Makefile というファイルと makefile というファイルは Unix系(UFS)では "別" のファイルなんです。WindowsとかMacしか使ってない人には信じられないかもしれないが。
*3: 再インストールですか?!
*4: hogehoge.txt ならば ._hogehoge.txt となります。
*5: でもリソースフォークの方は数バイトの小さいファイルで、それ以上大きくはなりません。 サイズよりもアクセスしなくてはならなくなるファイル数が増えることが問題なのです。


最近の日記
2019年06月24日
10年振り
2009年12月31日
定期アップデート
2009年04月03日
定期アップデート
2009年03月22日
定期アップデート
2009年01月26日
pomera
2009年01月23日
今日のBOT
2009年01月22日
BOT
2009年01月20日
Seagate HDD
PowerPCの備忘録
RSS feed
abuse
2009年01月19日
Windows 7 beta
2009年01月16日
perl-after-upgrade
2009年01月14日
アクセスカウンタ
2009年01月13日
ひとまず完了
2009年01月12日
7.1-RELEASE(適用)
2009年01月10日
hns 2.19.9
2009年01月09日
recursion no
以上、3 日分です。
先月 2019年08月 来月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Namazu for hns による簡易全文検索
詳しくは 詳細指定/ヘルプを参照して下さい
検索式:

タイトル一覧
カテゴリ分類
Powered by hns-2.19.9, HyperNikkiSystem Project