NAKAMURA Minoru の日記 (2003年4月)

不正アクセスの集計

操作ミスで3月と4月の初頭のアクセスログをロストしてしまったのでデータに穴ができる。
とりあえず、 4/7 日から月末まで管理人のサーバーのブロックしている TCP/UDP ポートへの アクセスを国別に集計すると以下のようになった。

寸評を加えると、

• 不正アクセス総数では中国がアメリカを抜いて一位に。 不正アクセスを仕掛けてくるホスト数でも肉薄している。
  
• 韓国からのアクセスが2月の一時期非常に少なかったのだが (MS SQL Slammer への対策のせい？)、 復調している。。。
  
• 日本からのアクセスがジワジワと増えている。 アクセス元の調べると YahooBB、ぷらら、so-net からのアクセスが増えてている。 特に YahooBB からの不正アクセスの増大はすごい。

参考

• 2/28 の不正アクセスの集計

カラープリンタの進化？

自費出版系 (^_^; に詳しい友人と話をして知ったのだが、 管理人が知らないうちに世の中のプリンタ事情は進んでしまっていたようだ。
カラーインクジェットプリンタはシアン、マゼンタ、イエロー、黒の4本の インクカートリッジを使うものだと思っていたが、 6色プリント、7色プリント、金銀プラスアルファしたプリンタが 存在するらしい。

また、アルプス電気の MD-5000以降のプリンタは (マイクロドライ方式だが)白色印刷が可能とのこと。 もっともアルプス電気はマイクロドライ方式プリンタの 店頭販売をやめてしまっているので、 白色印刷ができる民生プリンタの入手は困難になりつつある模様。

管理人はと言うと、 昨年の夏頃に hp のインクジェットプリンタ deskjet 948c を買ったものの、 いまだ最初についていたインクが切れていない。

[CPU][Bench] UltraSPARC III Cu 1200MHz、IIIi の 1002MHz の SPEC CPU2000 のスコアが登録

SPEC のページに、 SUN の新しい SPARC チップ UltraSPARC IIIi (1002MHz) のスコアと、 UltraSPARC III Cu の 1200MHz のスコアが登録された。
IIIi のスコアは Sun Fire V210 で、 SPECint_2k が 555、 SPECfp_2k が 841。 予想されたことながら単体性能はあまりよくないようだ。

UltraSPARC III Cu の 1200MHz のスコアは、 Sun Blade2000 で、 int2k が 722、 fp2k が 1,118。
同じ SPARC アーキテクチャの富士通のチップ SPARC64 V と、 周波数で差を縮めている(SPARC64 V が 1350MHz で、 SPEC CPUスコアが int2k の 850、fp2k の 1,228)。 もっともベラボーに積んだ 32MB の L3 キャッシュのおかげな気がするが。。。

P.S.

自動並列化コンパイラによる計測も行っている。 Blade 2000 の 2CPU モデルで 1,344。 2割前後性能が良くなっている。

更新

• 自分のサイトも更新。

[Work] 新人の歓迎会

南武線の武蔵溝の口の「たまい」で新人歓迎会があった。
午前中にしゃちょ〜の中の人が替わったニュースなどが伝わったので、 湿っぽい新人歓迎会であった。

[Linux] Linux はバグが多し

Windows や Solaris と比較すると Linux はスレッド・シグナル周りの挙動が極めて怪しい。

Solaris から Linux への移植を行ったプロダクツを相手に格闘しているが、 カーネルやスレッドライブラリのバージョンによって シグナルハンドラに渡される siginfo_t型の入力が POSIX にちゃんと 準拠していなかったり、 利用頻度が低い API の挙動が不正だったりする (sigaltstack API は、oss 経由で受け取る出力値がおかしい)。

それらはまだ回避方法があるのでよいのだが、 Linux では abortを呼んだ後に デッドロックをしてしまうという嫌らしい症状が起きている。 abort 処理を完了させるためにスレッドライブラリの中のロック or カーネル側のロックが 必要なようで、 別スレッドが運悪くそれを掴んだまま殺されてしまいデッドロックが起きると推測される。

NGPTL でシグナル周りの挙動はかなり改善されたと聞いているので、 それまでガマンして hack コードを書くしかないようだ。

[Work] 学生さんの見学が来た

某社にも学生の見学がやってくる。 厳しい業績を反映して人数は例年よりも激減。
管理人は応対係ではないが見学者の中に出身研究室の人がいるため、 見学会の後の懇親会にだけ呼ばれる。 人数が少ないため立食形式ではなくコースのフランス料理、 と言っても予算の都合で 前菜、スープ、肉料理、デザートの 4品で、 アルコールはビール。

堅苦しい雰囲気に学生さんはちょっと引き気味。

[CPU] AMD Opteron が発表

本日付で AMD から Opteron が 発表された。
今回 発表されたのは サーバー用の Opteron 244(1.8GHz)、242(1.6GHz)、240(1.4GHz)。
32ビットプロセッサとしての性能を測る 各種ベンチ%^!<%/7k2L$b 公開された。

1 CPU モデルの Opteron 144(1.8GHz) で SPEC CPU2000 を計測すると、 int2000 で1,170、 fp2000 で1,219 というスコアを達成。
まだ、spec.org に登録された公式値ではないが、 これまで x86 最速だった Pentium4 3.06GHz のスコアを追い越した!

参考

• μthe inquirer の記事 - Microsoft and AMD jointly developed Hammer chips
• μthe inquirer の記事 - Opteron - the SPEC king of X86 hill?
  

P.S.

バグも 見つかったみたい。

追記：4/25

[Tips] LaTeX2e で張り込める EPS ファイルをいかにして作成するか？

管理人はドキュメントを Linux/Solaris 上の LaTeX 2e で作成しているが、 図表は PowerPoint や Excel を使う。
ここに図表をいかにして LaTeX で使える EPS ファイルに変換するかという 問題が発生する。
日本語を含んだ WMF から単純変換した EPS ファイルは 日本語文字列と日本語フォントをそのまま含んでしまうのが問題なようで、 LaTex の翻訳時にエラーが出るか、 .dvi → .ps → .pdf 変換時にエラーが出てしまう。

これまで CorelDRAW8J を使って この問題を解決していた。
WMF ファイルを CorelDRAW8J で読み込み、 EPS ファイルでエクスポートすると、 LaTeX で利用可能な EPS ファイルとなっていたのだ (この際、「EPS へのエクスポート」のオプションとして 「テキストのエクスポート」を「曲線」(アウトライン化)、 「ヘッダーを含まない」を選択する)。
これはほぼ最良の解で、BoundBox なども自動的に正しく設定される。

しかし 昨年の10/11の日記にも書いた通り、 CorelDRAW9 相当の CorelDRAW ESSENTIAL では 日本語を含む WMF/EMF ファイルを正しく読み込むことができない。 この日本語 WMF/EMF ファイルが読み込めないという制限は、 以降の版でも改善されていないらしい。 CorelDRAW8J は Windows2000 以降にはインストールできないので、 OS のバージョンを上げると EPS ファイルの作成手法が失われてしまう。

そこでいろいろ代替手段を探していたのだが、 Adobe Illustrator に「アウトライン作成」機能があることが分かった。 Illustrator で WMF/EMF ファイルを読み込み → アウトライン作成 → EPS ファイル出力する。 Illustrator の出力する EPS ファイルは先頭に変なバイナリが入っているので これを削除して LaTex にインサートする。 .tex → .dvi の出力には成功するが、 xdvi で見てみるとなんとなく変な状態で EPS ファイルの部分をクリックすると 図がどんどん小さくなってしまう。 dvips で .dvi → .ps 化し、 Acrobat Distiller で .ps → .pdf すると変換に失敗する。
トホホ。

P.S.

なんとなく方法が見つかった。
Illustrator から直接 EPS ファイルを作らずに、 Acrobat Exchange を介すとうまく行く。

1. Adobe Illustorator で WMF/EMF ファイルを読み込む。
2. 「文字」-「アウトライン作成」を実行。
3. PDF ファイルに書き出す。
4. Acrobat Exchange で PDF ファイルを読み込む。
5. EPS ファイルで書き出す。

こうしてできた EPS ファイルは、 BoundBox 値が枠いっぱいになっているので、 修正の必要がある。

部屋を片付ける

一昨年にこの寮に引っ越して来てから 荷物が 1/4 ぐらい増えている。
増分はほとんど本か漫画本だが、 パソコン周辺機器の空箱なんかも積み上がっている。
このままだと単調増加していくだけなので、 意を決して漫画本のたぐいは半分ぐらい捨てることにした。

大量にある漫画本を選別をして、 お別れに読み直しをする。 ふと気づくと日が暮れようとしていた。。。

[Compiler] x86 用 C/C++ コンパイラの実力を比較してみる

x86用 C/C++ コンパイラ処理系の性能比較を SPEC INT2000 を用いて行う。
計測を行ったのは以下 処理系。

ICC は feedback optimization が ある場合とない場合の両方を実行した。
結果は下の表の通り。
c/e はコンパイルエラー、 e/e は実行時エラーまたは結果が不正だったことをあらわす。

性能うんぬんの前にコンパイラエラーが出たり、 実行中にエラーがでたりして途中で止まるのが問題。
ICC はすべてのベンチマークで結果が出せたが、 MVC は 176.gcc を実行中にエラーが発生、 GCC は 253.perlbmk がコンパイル不能で 他 2 つのベンチマークで実行中にエラーが発生した。
WCC は一番深刻で、 コンパイラが通ったベンチマークが 1/3 しかない。 処理系のライブラリが ANSI に完全には対応していないようで、 残りのベンチマークをコンパイルできるようにするためには 処理系の持つ include ファイルをかなり修正する必要がある。

追記：4/20

Microsoft Visual C++ 6.0 の結果を追加。

追記：5/13

Borland C++ Compiler 5.5.1 の結果を追加。

[OS] OS 間のスレッドの機能差

Linux と Windows と Solaris のあいだで、 スレッド機能の差を調べている。
スレッドを扱う API は Linux は POSIX スレッド API、Windows は Win32 API になる。 Solaris のみ Solaris スレッド API と POSIX スレッド API の 2 種類の API を持っている。

API 間に細かい違いは色々あるが決定的な違いは 2 つ。 スレッドスケジュールに関して、 もうひとつはキャンセレーション(Cancellation)と呼ばれる機構の有無。

Scheduling

Win32 スレッド API と Solaris スレッドには、 自スレッドの実行権を OS のスケジューラに返す API があるが、 POSIX スレッド API にはこれがない。 また Win32 スレッド API と Solaris スレッド API 、 現在 実行可能状態にある自分または他人のスレッドを 一時停止(suspend)させる API・ 一時停止しているスレッドを再開(resume)する API が存在するが、 POSIX スレッド API には該当するものがない。
Linux の場合、 前者の機能には等価な sched_yield() API が存在するが、 後者の機能を満たす API が存在しない。
このため、 外部からスレッドを一時停止/再開させるような、 強制的なスケジューリングがやりづらい。

Cancellation

Cancellation は特定のスレッドが終了する時に自動的に 呼び出されるコールバック関数を、 スレッド毎に登録する機能。 プロセスにおける atexit 関数的な機能を実現する。
この機能を持つのは POSIX スレッド API だけで、 Solaris スレッド API や Win32 スレッド API には 該当する機能が存在しない。

API を眺めてみると、 Windows の スレッド API は Solaris 系の スレッド API を ベースにしたことが伺える。
Solaris は POSIX スレッドと Solaris スレッドの両方を 持っているので逃げ手が打てるが、 片側分しかない Linux と Windows では 不足した機能を模擬するために シグナルハンドラ・構造化例外ハンドラを 用いた複雑なコードを書く必要に迫られる。

特に問題なのは Linux に thr_suspend/thr_resume がないこと。
POSIX スレッド API 準拠でも _np という postfix をつけて独自の API を増設している OS は多い (Linux は pthread_kill_other_threads_np などを持っている)。
2.6 系 kernel にのる新しいスレッドライブラリで そのあたりをどうにかしてももらえないのだろうか？

[時事] 東電の原発が止まる

東京電力の17機の原子力発電所が 全機停止する。
原子炉格納容器の漏洩率検査の偽装が発端になり、 17機の原発を全部 停止して検査するはめに陥ったわけだ。
検査も今年の夏には終わらなそう。 電力不足が心配されているので、 東京では計画停電をやるのかしらん？
某所においてあるサーバーが心配だ。

P.S.

全然、関係ないがでんこちゃん一族の構成は、 こう なっているようだ。

選挙に行く

県知事・県議会議員・市議会議員の選挙へ。
区と区の境に済んでいるので 投票会場までは 1キロ近く離れている。
2年間 住んでいる家の周りだが、 普段通らない道なので不案内。
陽気の中ぼちぼちと歩いて行く。

管理人のいる神奈川の県知事は全員 無所属。
白紙を投票して帰る。

投票上の途中に 焼き肉屋と ケンタッキーフライドチキンと ガストがあるのに気づいたのが、 今日の収穫だった。

[CPU] プロセッサの話とか

x86-64 以外にも、 新しいプロセッサの話がずいぶんと出回っているので記録しておく。

SUN の UltraSPARC IIIi

Jalapeno というコードネームで呼ばれていた UltraSPARC IIIi プロセッサが発表された模様。

• 14ステージのパイプライン
  
• 実行ユニットは x2 integer、2 FP/VIS、1 load/store、1 branch
  
• Cache coherent を取るためのバス(JBUS) は、 128 bits(data) + 36 bits(address) が150-200MHz 駆動。
  MOESI プロトコルで、4-way SMP に最適化されている。
• メモリインターフェイスは DDR SDRAM 266MHz (128 bits)
  
• 物理メモリ空間は 16GB(36bits)
• 0.13 μm プロセスルールで製造
  
• 1.2GHz の動作電力が 59W
  

IIIi は III(cu) は、 単体プロセッサとしての性能やメモリのバスバンド幅は強化されたが、 物理メモリが 16GB までに制約されたり マルチプロセッサのスケーラビリティは低下している？

Motorola の新しいチップ

掲示板にななしさんからたれこみがあったが、 Motorola が主催(?)する Motorola Smart Newtorks Developer Form(SNDF) 2003 Dallasで、 新しい PowerPC 7447/7457の詳細や、 7455 の SPEC CPU ベンチマーク結果 (SPECint_base2000 のみ)などが公開されたようだ。
Motorola の測定は PowerPC 7455 1.2GHz の Power MAC G4 上での計測と思われ、 500 というスコアを得ている。

SNDF 2003 Dallas の資料は、 Session by Topicからみるのが見やすい。

乱数発生器

VPN や SSL などの暗号化通信の必要性から、 乱数生成アルゴリズムを用いた擬似乱数ではなく、 自然現象を利用したハードウェアベースの乱数生成器が必要になっている。
パソコン系では、 すでに Intel の i810 チップセットと VIA の C3 Nehemiah がハードウェアベースの乱数発生器を持っていて、 Cryptograph Research Inc. が、 その評価を行っている。

これを読むと、
i810 は、 半導体素子の熱雑音を拾い、 それを増幅して乱数を発生させる回路を持っている。 乱数の発生速度は 75 K bit/sec。
Nehemiah は、 オシレータ(発振器) を複数組み合わせて、 わざと雑音を拾うようにした回路を持っている。 乱数の発生速度は 4〜9 M bit /sec。

[CPU] AMD x86-64 の関する噂

しばらく情報が停滞していたが、 AMD の x86-64 に関する話題が 頻繁に出てくるようになった。
備忘のために、まとめてみる。

• PC Watch の記事によ$k$H!" Opteron (旧コードネーム SlageHammer) は 4/22 日に、 Athlon64 (旧コードネーム ClawHammer) は 9月に 発売される予定。
  お値段は卸価格が Opteron 240 (1.4GHz) で $275、 242(1.6GHz) が $670 らしい。
  
• Microsoft は、 デスクトップ(コンシューマー)向け OS として x86-64 版 Windows XP、 サーバー向け OS として x86-64 版 Windows Server 2003 の リリースを明言。
  XP のコードネームは Anvil (かなとこ)。
  
• Serverworks が Opteron用のチップセットを作るかも
• SUN が自社サーバに Opteron を 採用するかも。 その場合、Solaris for x86-64 が出る？
• Apple が x86-64 を 採用するかも。 でも 採用しないという話もある。

参考

• AMD Zone

Amazon から本と DVD が届く

Amazon で注文していた本と DVD が届く。
アマデウス (AMEDEUS) のディレクターズカット版 DVD がようやく届いた。
20分の未公開シーンに心踊らせながらも 会社から持ち帰った仕事を続ける。

ついでに、一緒に注文していた本もくる。

1. マイ・アメリカン・ジャーニー (MY AMERICAN JOURNEY) コリン・パウエル (Colin Powell) & ジョゼフ・E・パーシコ(Joseph E. Persico)

2. アメリカを幸福にし世界を不幸にする不条理な仕組み (American's Political Mission, The New Economy and Japan) カレル・ヴァン・フォルフレン (Karel van Wolferen)

3. だからアメリカは嫌われる (THE EAGLE'S SHADOW: Why America Fascinates and Infuriates the World) マーク ハーツガード (Mark Hertsgaard)

4. ファーストフードと狂牛病 (FAST FOOD, MAD COW AND GREED) エリック・シュローサー (Eric Schlosser)

これ以外にも、 この数週間で以下の本を買って読んでいる。

5. 反米の理由 (Why Do People Hate America?) ジアウッディン・サーダー (Ziauddin Sardar) & メリル・ウィン・デービス (Merryl Wyn Davies)

6. アホでマヌケなアメリカ白人 (STUPID WHITE MEN) マイケル・ムーア (Michael Moore)

3/13分と併せると、 素晴らしき反米本のラインナップとなる。

それはいいのだが、学生時代から毎月、 DVD は1本か2本、書籍は10冊前後のペースで購入している。
書籍は購入して3日以内に読了しなかったものはないが、 DVD は (メーカーへの御布施と思って買った DVD-BOX を全部除いても) 未視聴な板が 20 枚近くある。
俺は何のために DVD 買ってるんだろう。。。

P.S.

一緒に注文した本の中で 一番 期待していた 写真集 軍艦島 - 眠りのなかの覚醒 だけ発送が遅れている。
ちゃんと届くとよいのだが。

追記：5/9

Amazon.co.jp より 軍艦島 - 眠りのなかの覚醒 が 在庫切れのメールが届く (涙)。

[Compiler] C++ コンパイラの怪は続く

3/11、 3/25に続き、 C++ のコンパイラの妙な現象を発見。
今度は GCC。

const int Value1 = 0; // ok
const Value2     = 0; // error

上記のコードは GCC version 3.2 (20020903)、version 2.95.3 (20010315) ではエラーとなる。 しかし、以下の処理系では問題なくコンパイラが完了する (ただし Intel C++ Compiler は警告を出す)。

• Microsoft VC 6.00.8447 (x86/win32)
• Sun WorkShop 6 update 1 Compilers C (sparc/solaris8)
• Intel(R) C++ Compiler for 32-bit application, Version 7.0 (x86/win32)
• Open Watcom C/C++32 Compile and Link Utility Version 1.0 (x86/win32)

これは、 型なしの const 変数が ISO の C++ 仕様で禁止されてしまったため。
ISO に準拠するならこれはエラーとすべきパターン。
つまり GCC が正しく、他の処理系が ISO に準拠していないということになる。

問題は次のコード。

class SelfClass;
class OtherClass;

class SelfClass {
private:
  friend class OtherClass; // ok
  friend class SelfClass;  // ok? warning? error?

  int dummy;
};

上記のコードは自分自身を friendクラスとして定義するが、 このコードも gcc version 3.2、2.95.3 (20010315) で class `SelfClass' is implicitly friends with itselfと、 エラーになる。
その他の処理系では問題なくコンパイラが完了する (ただし Intel C++ Compiler は警告を出す)。

これがなぜエラーになるのか分からない。
ISO C++ の仕様で新たに加えられた禁則を GCC だけが忠実にインプリメントしている可能性もあるが、
管理人はこの文法の追加を聞いたことがない。
＃ ISO の仕様書を購入すべきか？

現実問題と$7$F!" 生成的マクロやテンプレートの奥深い所にこのパターンが出てきて 容易に修正できないソースコードが存在する。 そのようなソースコードを GCC でコンパイルする必要に迫られているのだが、 このエラーはオプションでは切れない(ような)ので、 いったいどうすればいいのか困ってしまうなり。

[OS] Inside the AS/400

HDD の中身を整理していると Inside the AS/400 を翻訳した PDF が出てきた。
AS/400 は今は IBM eServer iSeries と呼ばれているもので、 同書は AS/400 の開発者の一人 Dr. Frank Soltis の著書。 それを日本 IBM の人が翻訳して、 Web 上で 公開していたのを落としたものだ (今は、序文以外は公開されていない)。

あらためて読み直して見ると、 Machine Interface(MI)、 単一レベル記憶、 統合データベースなど UNIX にないとんがった機構が いろいろ存在して面白い。

参考

• IBM eServer iSeries のページ
• IBM eServer iSeries の年表

[Java] WebLogic JRockit 8.1

BEA Systems から J2SE 1.4.1 相当の Java2 SDK WebLogic JRockit 8.1 が公開された。
8.1 は、基本的に 8.0 のバグフィックスバージョンだ。 公開されたのは x86/Windows 版、x86/Linux 版、IA-64/Linux 版の3種類。 8.1 から IA-64 サポートが正式にうたわれた。

またインストーラが日本語に対応したようだ。 ただ、Windows 版をインストールしようとするとどうしても 途中でエラーが出てとまってしまう。 日本語版の Windows 2000 Pro / Windows XP Pro を使っているとエラーが出るので、 日本語対応したインストーラに問題があるのかも知れない。

とりあえず回避方法を見つけたのでここにメモしておく。

1. あらかじめ JRockit 8.0 をインストールする インストール先ディレクトリを C:\Java\JRockit80_141_32\ とする。 このディレクトリの内容をそっくりコピーして C:\Java\JRockit81_141_32\ を作る。
   
   
2. jrockit-8.1-j2se1.4.1-win32.exe を実行。 しばらくすると「ようこそ...」というダイアログが出る。 その時、テンポラリディレクトリを覗いて、 インストールする内容が展開されたディレクトリを探す。
   仮に展開ディレクトリが sfx4E6F.tmp の場合、 内容は以下のようになる。

   $(TMP)\sfx4E6F.tmp\j141_02\
   $(TMP)\sfx4E6F.tmp\3rdparty.jar
   $(TMP)\sfx4E6F.tmp\AUTORUN.INF
   $(TMP)\sfx4E6F.tmp\bids.jar
   $(TMP)\sfx4E6F.tmp\comdev.jar
   $(TMP)\sfx4E6F.tmp\gpr.xml
   $(TMP)\sfx4E6F.tmp\jni.dll
   $(TMP)\sfx4E6F.tmp\jrockit8100_1026_COMP_win32.jar
   $(TMP)\sfx4E6F.tmp\win32_jrockit81_141_02_jdk.zip
   $(TMP)\sfx4E6F.tmp\win32_jrockit81_141_02_jrockit.zip
   $(TMP)\sfx4E6F.tmp\wizard.jar
   

   
   
3. win32_jrockit81_141_02_jdk.zipと win32_jrockit81_141_02_jrockit.zip を展開し、 その内容を C:\Java\JRockit81_141_32\ に上書きする。
   
   
4. レジストリの書き換え 下のような内容のファイルを hogehoge.reg で保存し、 レジストリとして読み込ませる。

   [HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\JRockit\8.1]
   
   [HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\JRockit\8.1\JRE]
   "CurrentVersion"="1.4"
   
   [HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\JRockit\8.1\JRE\1.4]
   "JavaHome"="C:\\java\\JRockit81_141_32\\jre"
   

   ＃ JavaHome の内容は、各環境に合わせて変更。
   

以上の方法で Windows 版 JRockit 8.1 は動作するようになったが、 インストーラーをちゃんと修正して欲しい。

追記：12/23

JRockit 8.1 の SP1 では直っているようだ。

Falcom ってどうして潰れないないのだろうか？

Xanado とか Y's で一世を風靡した 日本ファルコムが、 5/23 日に過去作品 (Y's I、II、英雄伝説 III、IV、XP、Zwei!) の Windows XP 版を出すらしい。

ファルコムはここ十年ぐらい数えるほどしか新作を発表してこないで、 旧製品の焼き直しを続けてきた。 Windows 版の Y's I なんて 内容に変化はないのにすでに 3 代目だ。 世の中にはコナミ商法とかサーカス商法とかあこぎな商売があるが、 過去の遺産が頼りのファルコム商法で良く持っているよな。。。

P.S.

iアプリ「イース」が出るらしい。
かつてのマイコン・コンシューマーゲーム機の性能に 携帯電話が追いついたのね。

[Work] 沼津で新年会

この日は沼津で新年会があった。
天ぷらのお店 「天春」で行われた。
メニュー等はすでに失念しているので写真だけ載せる。

お店の前	お座敷の飾り

ソフトの脆弱性

ソフトの脆弱性の発見が続いている。
覚書として列挙しておく (ただし、Windows OS & ソフトの脆弱性はのぞく)。

• Sendmail 8.12.8 以前
• Samba 2.0.x 〜 2.2.7a
• Windows 版 QuickTime6 以前
• Windows 版、Mac OS X 版の RealNetworks、RealOne Player、 RealPlayer

他にも SUN RPC XDR にセキュリティホールが 見つかったりしている。

[Compiler] x86 用 FORTRAN コンパイラの性能は？

x86 用 FORTRAN コンパイラと その性能を調べているが (2/9の日記・ ここ)、 ネット上でいくつかの処理系比較が公開されているのを見つけた。

Some linux Fortran benchmarks

Linux 上の Fortran コンパイラの比較。
幾つかの実 Fortran プログラムを用いて 処理系の性能比較を行っている。
対象となる処理系は Absoft の ProFortran Ver. 6、 Fujitsu の 富士通 Fortran Portland の PGI Fortran、 そして GNU F77 と f2c。

1. HOPE GRIB (F77)、 2. OPA & MICOM ocean models (F90)、 3. GMODEL ocean model (F90) 4. BS3DVW (ナビエ-ストーク方程式の求解; F77)

1. の結果は、 pgf90 > fujitsu > absoft(f70) > f2c。
g77 はオプションに未対応だったようだ。

2. の結果は、 absoft はコンパイル中にエラーが起き、 g77、f2c は F90 に未対応だ。 fujitsu と pgf90 は無事測定できるが、 測定環境が異なるため 比較できないようだ。

3. の結果は、 pgf77 > absoft(f90) > absoft(f77) > g77(2.91.66) > fujitsu > f2c の順。

姫野ベンチマークを用いた C/FORTRAN コンパイラの性能比較

Pentium4 (1.7GHz) & Red Hat Linux 7.3 環境で 姫路ベンチマークを用いた処理系の性能比較を行っている。
比較対象の処理系は GCC g77(2.95.3, 2.96)、 Absoft ProFortran (7.0)、 Fujitsu Fortran & C Package V2、 PGI Workstation (3.2a, 4.0)、 Intel Fortran Compiler (6.0)。

結果は、F77 コンパイラとしては、 pgi3.2 > pgi4.0 > absoft f77 > fujitsu > g77 2.95.3 > absoft f90 > g77 2.96 の順 (intel fortran は未計測)。
F90 コンパイラとしては、 pgi3.2 > pgi4.0 > intel > fujitsu > absoft(f90)の 順になるようだ。

性能差の一因は、SSE 対応だと思われる。 PGI と Intel は SSE に対応しているが、 Fujitsu と Absoft は未対応のようだ。 また このベンチマークだけかもしれないが g77 2.95.3 は以外に健闘している。 F77 のテスト結果だけを見ると fujitsu と absoft は g77 で代替できそうだ。

Long Write-Up

NAGWare f95 4.0、 PGI pgf90 v3.0、Fujitsu F90、Absoft ProFortran 6.0 (f90)を比較している。 詳細に読んでいないが、 グラフだけを見ると pgi3.0 > fujitsu > absfot(f90) > NAGのようだ。

PGI の処理系が あらゆるベンチマークでトップに立ち、 最も性能が高いようだ。

狂乱の一日も終わり

今日はエイプリルフール。
方々のページを巡ってネタページを探す。 乱痴気騒ぎとなっている。
イラク戦争の影響か真面目なニュースサイトでは ネタな記事はなし。