NAKAMURA Minoru の日記 (2003年5月)

不正アクセスの集計

毎度だが、 管理人の管理しているサーバーのログを解析して、 今月分の不正アクセスの国別統計を集計してみた。 サーバーを閉じているポートへアクセスを掛けてきたサイトは 以下のようになる。
先月と比べると、 順位の多少の変動はあるものの上位・下位とも固定されてきたようだ。
ただ嘗てはトップにいた韓国が序々に相対順位を下げ、 中国が相対順位を上げている。

そのほか HTTP(80) 番へ、 Nimda / Code Red 系のアタックを掛けてきたものが 386 サイトあり、 国別順位でみると左の表のように中国と日本からのものに集中していることが分かる。
国内からアタックを掛けてきた 112 サイトを さらに DNS の逆引き情報で追跡すると 右の表のようなプロバイダーからのアクセスであった。 やはり YahooBB が圧倒的だ。。。

P.S.

それにしても中国・韓国のサイトは DNS を逆引きしてもドメイン名が出てこないのはなぜ？

[Compiler] C/C++ コンパイラの話

x86 をターゲットとした C/C++ 処理系

IA-32 のコンパイラを色々調べていたが 商業ベースものは管理人が思っていたよりも少ないことが判明。 メジャーなものは Microsoft、Intel、Borland、Metrowerks、PGI ぐらい。 KAI C++ はいつのまにかいなくなったし、 IBM VisualAge C++ は Windows NT 系への対応をすでに打ち切っているようだ。 調査の結果を 「x86 で動作する C/C++ コンパイラ」を更新。

C++ コンパイラのフロントエンド

C 言語は Java や Pascal のような仕様がシンプルな言語と違い、 double (*((*func)(int,long)))(short) のような奇妙奇天烈な変数定義ができるため フロントエンドを作成するのが難しい。 だが C++ 言語は C 言語の仕様をすべて引き継いだ上で さらに奇妙奇天烈な仕様を増やしたため、 フロントエンドを作成はさらに困難になっている。

そのため 現在の商業ベースの C++ コンパイラは、 コンパイラフロントエンドの開発を専門にしている「フロントエンド屋」の プロダクトを利用していることが多い。
管理人は 以下のような フロントエンド屋さんを見つけた。

• Edison Design Group
• John's PCCTS-based C++ Parser Page
• Comeau Computing

Edison Design Group のフロントエンドの顧客リストをみると、 使ったことのある C++ コンパイラメーカーの名前がづらづら。

Amazon から本が届く

AMAZON.co.jp で注文していた ルイス・ガースナー(Louis V. Gerstner,Jr)著 「巨象も踊る (Who Says Elephants Can't Dance?)」 が届く。 1990年代の初頭に経営危機に陥っていた IBM を建てなおした ガースナー CEO の回顧録である。 学生時代にはこの手のビジネス書を忌避していたのだが、 ついにこういう本を手に取る程オヤジになってしまったのだなぁ。。。
とりあえず忙しいので週末まで封印。

つでに自分自身への覚書として 4/9 以降 購入した本をここに書いておく。

• 「ご冗談でしょう、ファインマンさん (SURELY YOU'RE JOKING, MR. FEYMAN!) (上)(下)」
  R.P. ファインマン (Richard P. Feynman) with ラルフ・レイトン (Ralph Leighton) 岩波現代文庫 ISBN4-00-603005-3, 4-00-603006-1
  
  
• 「困ります、ファインマンさん (WHAT DO YOU CARE WHAT OTHER PEOPLE THINK? MR. FEYNMAN GOES TO WASHINGTON and others)」
  R.P. ファインマン (Richard P. Feynman) with ラルフ・レイトン (Ralph Leighton) 岩波現代文庫 ISBN4-00-603029-0
  
  
• 「移民と現代フランス - フランスは「住めば都」か - 」
  ミュリエル・ジョリブェ (Muriel Joliver)著 集英社新書 ISBN4-08-720189-9
  
  
• 「ヒエロニムス・ボッシェ (Hieronymus Bosch)」
  ハインリヒ・ゲルツ (Heinrich Goertz) 著 パルコ美術新書 ISBN4-89194-398-X
  
  
• 「初版 金枝編 (THE GOLDEN BOUGH) (上)(下)」
  J.G.フレイザー (James George Frazer) 著 ちくま学芸文庫 ISBN4-480-08737-0, 4-480-08738-9
  
  
• 「巨象も踊る (Who Says Elephants Can't Dance?)」
  ルイス・ガースナー (Louis V. Gerstner,Jr) 著 日本経済新聞社 ISBN4-532-31023-7
  

自分の趣味で買った本ながら脈絡がない。。。

[Perl] 私の知らない Perl の仕様

Perl でスクリプトを書くようになってから数年経つが、 今日はじめて次のような言語仕様に気づいた。

Perl の配列(あるいはリスト)変数のインデックス値は 0 から始まるが、 0 以上の代わりに負数を指定した時には配列の最後から順番に要素を指すらしい。 つまり -1 は配列の最後の要素を、 -2 は配列の最後から 2 番目の要素を、 -3 は(以下、略)。

@days = qw(Monday Tuesday Wednesday Thursday Friday Saturday Sunday);
print $days[-1]; # "Sunday" と表示される。
print $days[-7]; # "Monday" と表示される。
print $days[-8]; # "Monday" と表示される。別実装ではエラー。

print $days[8];  # "" と表示される。

結局、@array は $array[-scalar(@array)] から $array[scalar(@array)-1] までアクセスできることになる。

赤ラクダ本をさらっとみたところ splice 関数の説明に このことに触れた記述があったが、 青ラクダ本にはこのような仕様は載っていなかったと記憶している。 なんともあやしい仕様だ。

[Compiler] LCC-Win32

x86 のコードを出力できるフリーの C コンパイラ処理系 lcc-win32が、 バージョンを 4.2 に上げ .NET (MSIL) にも対応したようだ。

このコンパイラは Christopher W. Fraser らが書いた C コンパイラ処理系の教科書 A Retargetable C Compiler: Design and Implementation の教材であり、 LCC v3.6 は管理人が初めて読んだ C のコンパイラ処理系だ。 コンパイラ時間が短いのと、 Alpha、SPARC、MIPS(R3000)、IA-32 と 3人で作っているとは思えないほど多彩な ISA に対応しているのが利点。
もっとも 最適化機能はほとんど何にも入っていないので 実行速度には期待ができない。
時間ができたら SPECint2k を計測してみるつもり。

[Tips] ASTEC-X の新バージョン & 設定メモ

アステック社の ASTEC-X にしいバージョン(v4.00) が出ので、 アップデートファイルだけダウンロードしておいたが 時間が取れたのでインストールした。 普段、使っている VineLinux 2.6 で設定のメモを ここに残しておく。

Astec-X(Windows) から XDMCP を使ってログインするやり方
Vine Linux は X Display Manager が wdm になっているはず。
wdm では Windows 上の Astec-X から XDMCP 経由で Vine Linux ホストに ログインしようとすると X ログイン画面が上手く表示されない。 そこで画面がしょぼくなるが wdm を xdm に切り替える。
切り替え個所は /etc/sysconfig/dmtype に wdm の代わりに xdm と書く。

/etc/X11/XF86Config の書き換え
Windows 側で X サーバー側のフォントを利用するために、 フォントサーバを利用する。

Section "Files"
RgbPath    "/usr/X11R6/lib/X11/rgb"
#   FontPath   "unix/:-1"
FontPath   "tcp/localhost:7100"                    # 追加
FontPath	"/usr/X11R6/lib/X11/fonts/TrueType"
EndSection

Windows 側の IM を利用して日本語入力
Windows 側の IM を利用して Remote UNIX の kterm に日本語を入力 するには、Remote 側の X の設定が必要。 .Xdefaults に以下の記述を追加する。

KTerm*VT100*translations:#override<Key>Kanji:begin-conversion(_JAPANESE_CONVERSION)
!KTerm*vtMenu*eucmode*Label:	Japanese EUC Mode
KTerm*VT100*kanjiMode:		euc

更新が終わったら、xrdb でリソースの変更を反映させる。

> xrdb -merge ~/.Xdefaults

終わらないので Ctrl + D を打つ。

また XFree86 4.x からは 環境変数 XMODIFIERS を指定する必要がある。

(CSH)setenv XMODIFIERS "@im=ASTEC_IMS"
(BSH)export XMODIFIERS="@im=ASTEC_IMS"

これ以外にも設定する場所があったような気がするが失念。
思い出したら加筆する。

参考

• ASTEC-X の FAQ
• Vine Linux 用のフォント設定
• Kterm への Windows の IME の入力
• XFree86 4.x で Windows の IME を利用するには

[時事] 地震

6時半頃にかなり大きな揺れを感じる。
6時24分に宮城県沖で M7.0 の地震が発生した模様。
このところ地震が頻発しているし、 ファイルサーバのバックアップは全部取っておこう。

結局、ムダ金を使ってしまう…

TV 放送を受信しようと 5/11に 買った Mpeg TV Station/PCI (5,750円+税) は、 室内アンテナ(2,870円+税)を買い足してもダメだった。

その後 とりあえず部屋の壁まで来ているアンテナには問題がないことが確認できたので、 結局 BUFFALO の PC-MV5/U2 を購入してしまう。 26,800円(+税)の出費だ。

秋葉原 → 職場 → 寮に帰って TV 放送が受信可能なことを確認。
結局、TV を見れるようになるまでに 37,191円も払うはめに。。。

P.S.

ついでにキーボードのキートップを外す器具(税込み500円)を買ってきた。
キーとキーの隙間に 髪の毛、フケ、食べ物のかす、コーヒーの飛び散った汁などが挟まっているので、 ****** をテストしている時間を使ってキーボードの掃除する。

[Work] まだバグが消えない

****** のデバッグに1週間を掛けたが、 いまだバグの原因が決定できずにいる。

とりあえずバグが取れている(ように見える) オリジナルの ****** の最新版からコードを back port し、 こちら側が書いたコードを無効化すると、 手元の Pentium3 1GHz の 2way マシンでは 正しく動作しているように見える。 16way の SPARC マシンで一晩 連続稼働させて エラーがでないことを確認する。

今回のバグとは関係ないようだが、 潜在的なバグを新たに発見。
コンカレントに動作する部分の同期処理に問題があり、 タイミングによっては誤動作する可能性あり。

P.S.

16-way の SPARC マシンでも正常に動作しているようだ。

[Bench] 新しい SPEC CPU2000 スコアが登録

SPEC の ページにCPU2000 ベンチマークの新しいスコアが登録された。

登録されたのは AMD の Athlong XP 3200+(2200MHz)、 IBM の POWER4+ 1500/1700MHz、 富士通の SPARC64 V 1080/1100/1350MHz のもの。

Athlon XP 3200+ のスコアは int2k が 1,080(1,044)、 fp2k が 982(873)。
Barton コアになった Athlon XP 3000+ と比較すると周波数なりの性能向上だ。

IBM の POWER4+ のスコアは eServer pSeries 690 Turbo int2k で 1,113(1,077)、 fp2k で 1,699(1,598)。
いわゆる RISC 系プロセッサのなかで int2k が 1,000 を初めて越えた。
トップの Pentium4 with HT 3.0GHz の 1,2000、 次点の Opteron 144 の 1,170 にも大きく近づいた。
また、fp2k のスコア 1,699 は、 トップの Alpha 21364 1150MHz の 1,482、 次点の Itanium2 1GHz の 1,427 を大きく追い越しトップに輝いた！

富士通の SPARC64 V はすでに 1300MHz のスコアが公開されていたが、 PRIMEPOWER 900 という同じ巨体に 1300MHz を載せての4度目の挑戦である。 毎回 コンパイラの処理系やオプションが変わってきているので、 この計測のために涙ぐましい努力が払われているのであろう。
しかし、 結果は int2k で 892(767)、 fp2k で 1,322(1,047)。 フロントラインからは遠のいてしまったようだ。

P.S.

あと SUN が新しい Intel Box (Sun Fire V65x ;3.06 GHz Xeon) の fp2k スコアのみを公開した ( 1,011(1010) )。
OS は Red Hat Linux 7.3 で、 コンパイラは Intel 製。

更新

• SPECcpu2000 にみるプロセッサの性能自分のページ

[Work] デバッグ マラソン

木曜日(5/15) に分かった方針に従って、 金曜日から6日に渡って不眠不休のデバッグ作業を行う。
某プログラムの並列処理部分のバグだが、 問題の症状を出すために数千パーセントの負荷を 十数分間 かける続ける必要がある。 そのためか (UNIX 系のバージョンではそうでもないのだが) Windows バージョンではバグが発現すると GUI の制御を全部奪われてしまい、 デバッガを起動することも プロセスを殺すことも出来なくなる。
とにかく時間を浪費するデバッグ作業だ。

日曜日に論理的に考えてバグだと見られる場所を発見。
しかし、症状が改善されず。 どうも別の潜在バグを発見したらしい。

火曜日にもう1つバグを見つける。
こちらはバグにヒットしていたようで、 オプションによっては完走するようになった。 しかし、 別のオプションでは30分ぐらいすると停止する。

第2のバグが修正しきれずに残っているのか、 新たな第3・第4のバグがあらわれるのかは知らぬが、 今週も土日はないようだ。。。

Ogg Vorbis の話

MPEG Audio Layer3 (MP3) に代わるオープンな圧縮音楽フォーマットとして登場した Ogg Vorbis(拡張子は .ogg) だが、 Slashdot の この記事によると Ogg Vorbis のファイルフォーマット(というかビットストリームのフォーマット)が RFC3533 として登録されたようだ。 (フォーマットの説明の説明は、 ここもある)。

MP3 は そもそも規格が古いため後発のデジタル圧縮音楽のフォーマットに音質で遅れを取っている上に、 特許を持っている Fraunhofer IIS から圧力が掛かっているため、 他のデータ形式の流出が始まっている。
そのためか Ogg Vorbis は、 mp3PRO、ATRAC3、TwinVQ/Sound VQ のような中途半端でプロプラエタリな規格を押しのけ かなりな勢いで広まっている。 管理人の手元にも何故か大量の .ogg ファイルがある。 主観だが MP1〜3、Windows Media Audio に次ぐ地位を築いているのではないだろうか？

しかし、Ogg Vorbis には携帯オーディオプレイヤーで再生できないため、 パソコンでの利用に縛られてしまうという弱点がある。 ただ .ogg を再生可能にして欲しいというユーザーの要求は大きいようで、 ファームウェアアップデートで .ogg への対応を約した製品がぼちぼちあらわれた。
以下、管理人が分かっている範囲でメモしておく。

• Neuros Digital Audio Comput
  128MB のフラッシュメモリを内蔵版と 20GB の 1.8 インチ HDDユニットを抱えた 2 つの形態を持つ。 携帯オーディオプレイヤー。 この記事を読むと .ogg 対応が予定されているようだ。
  
  
• NEX ia
  Type II の Compact Flash Card に対応した小型のオーディオプレイヤー。 FM チューナー機能、ボイスレコーダー機能、FM レコーダーも備えている。
  製品紹介のページには "Supports multiple formats (MP3 and WMATM)) and emerging formats such as Ogg Vorbis through firmware upgrades." とある。
  
  
• iRiver iHP-100
  1.8インチ HDD 内蔵の携帯オーディオプレイヤー。
  これも FM チューナー機能と MP3 リアルタイムエンコーダのレコーディング機能を 持っているようだ。
  まだ発売されていないが、 この記事には .ogg 対応が謳われている。
  

ただ まだ実際に .ogg に対応した製品はないようだ。

P.S.

管理人としては今使用している RioVolt SP250 から、 HDD の携帯オーディオプレイヤーに乗り換えたいと考えている。 要件としては 「Ogg Vorbis 再生機能」、 「ボイスレコーダ機能」、 「タグの日本語表示、特に MP3 の ID3 が v2.3 (SJIS)に対応 」があること。
iHP-100 が .ogg 対応すれば理想的だが、 DSP メーカーが Ogg Vorbis デコーダプログラムを提供し始めたり、 1.8 インチ HDD の供給量の増大が囁かれたりしているので、 もう少し待ったほうがいいかも。。。

追記：5/30

ファームウェアアップデートでの Ogg 対応を確約している Neuros MP3 のレビューが MP3newswire.net にある。
Slash.dot にも 記事がポストされている。

[Work] 沼津に出張

仕事のミーティングのために毎度のごとく沼津へ出張。
今日は別件もあってうちの課からは 5人も沼津に出張している。
新横浜駅と三島駅の往復の新幹線代も馬鹿にならないだろう。。。

ミーティングには N.Y. の A 研究所からもエンジニアが来る。
ミーティングの内容はここには書けないが、 B *.*.* 上に実装した並列 GC のバグは、 こちらが書いたコードではなくて ベースとなっている C が書いたコードにあるようだとの認識に至る。

C も新しいバージョンではバグを修正しているので、 ソースコードの差分を追いかけてみるしかなさそうだ。

[Compiler] AMD64 対応コンパイラの話

AMD の Opteron が発売され、 SuSE、RedHat、TurboLinux から Linux のディストリビューションが、 Microsoft からは Windows 2003 Server と Windows XP の後継 OS の AMD64 対応が発表された。

一方、 コンパイラは GCC は ver 3.3 から AMD64 に移植されたものの、 メーカー製の AMD64 バイナリを生成するコンパイラはほとんどない。
AMD64 に対応したコンパイラを分かっている範囲でメモしておく。

PGI(Portland Group Compiler Technology)

PGI Workstation 5.0 から AMD64/Linux に 対応。
対応したのは Fortran77、Fortran90、C、C++ コンパイラ。
現在は 5.0 ベータを公開中。

Absoft

AMD64/Linux 対応 Fortran95 コンパイラを 開発中。
5月中旬にはテストを開始する予定らしい。

C/C++/FORTRAN に関しては、 ぼちぼちコンパイラを作るメーカーが出ている。
それ以外だと 64ビットのメモリアドレスを使う Java (JavaVM) が欲しいが、 誰が作るのだろうか？
SUN が直接移植しない場合、AMD が移植するのは難しそうだが、、、
＃ C# & .NET framework は Microsoft が作りそう。

追記：5/28

The Numerical Algorithms Group (NAG) も Fortran95 コンパイラを AMD64/Linux に対応させたようだ (ここ)。
コンパイラ不足の外堀は埋まりつつある。

[MyWeb] 新しい Web ページを作成

日記の見直しをして、 4/18 分の独立させて 「x86 で動作する C/C++ コンパイラ」というページを作成。

[Java] SUN の Java2 Platform, Standard Edition の v1.4.2 Beta をチェック

SUN はJ2SE v1.5 よりも先に v1.4.2 を出してくる。 おそらくこのバージョンが v1.4 系の最後になると思われる。 ベータ版が ここからダウンロード可能。

色々テストしてみたが、 v1.4.1 にあったバグが随分修正されている。 特に Parallel New GC (-XX:+UseParNewGC)の バグが修正されているのが嬉しい。

SUN はマルチプロセッサマシンでの性能向上を狙って、 J2SE v1.4.1 から Concurrent Mark & Sweep (-Xconc)、 Parallel Scavange GC (-XX:+UseParallelGC)、 Parallel New GC (-XX:+UseParNewGC) の 3 種類の並列ガーベージコレクションアルゴリズムを載せていた。

この 3 種類は少しずつ効果が違う。 Concurrent Mark & Sweep は GC が起こっていない時間にも GC 処理の一部をバックグラウンドで前倒して行うことで、 1回の GC で停止する時間を劇的に短縮する並列 GC。 これは全体の実行性能の少し犠牲になる。

Parallel Scavange GC と Paralell New GC は 共に GC を複数のスレッドで分担して行うことで短縮して 全体の性能を上げる並列 GC。 ただし、 Parallel Scavange GC は大規模 SMP マシン(16〜64 way) に、 Parallel New GC は小規模 SMP マシン (2〜4 way) に チューニングされているようだ。

普通の x86 Box で 2 〜 4 way 程度の SMP マシン上で v1.4.1 を走らせるには、 Parallel New GC が一番効果がある。
ただし、 Parallel New GC はえらいバグ持ちで experimental な扱いだった (GC スレッド数を -XX:ParallelGCThreads=<n> オプションを大きくすると、すぐにエラーで落ちる)が、 v1.4.2 では問題なく動作するようになった。

正式版では SMP マシンで動作させている場合には Parallel New GC が有効になる方がデフォルトになるかもしれない。

[CPU] AMD64 の Instruction Set Architecture を見る

http://www.x86-64.org/ には 4/22 付で AMD64 Architecture Programmer's Manual が公開されていた。
これまで他資料でも概略は説明されていたが、 今回は命令フィールドまできちんと明らかにされている。

うち眺めてみるが、 AMD は本当にひねりのない x86 アーキテクチャの 64 ビット化を行っている。 IA-32 にあった命令がそのまま 64 ビットモードでも使えるようになっていて、 新規に導入された命令はない。 管理人としては、 i386 から続く x86 命令セットを IA-32 というのであれば、 Itanium の命令セットよりも AMD64 の方がよっぽど IA-64 とよぶに相応しいと思われる。

特徴を上げてみると、

1. 64ビットモードでの 32 ビット演算のディスティネーションレジスタは、 上位 32 ビットのゼロ拡張(zero extension)が基本。
   これは IA-32 が、32 ビットモードで 16 ビット演算をやった場合の扱いと同じなので、 それとの整合性を取ったものだと思われる (実際には、RISC 系のプロセッサのように上位ビットは符号拡張(sign extension)された方が、 C コンパイラを作りやすい)。
   
   
2. 命令の即値フィールドは基本的に 32 ビットのまま。 ただし、64 ビットの即値フィールドを取る MOVE 命令がある。
   RISC 系のプロセッサは、命令フィールドが 32 ビット固定で、 16 ビット分しか即値フィールドがない (SPARC は例外的に、 22 ビット即値フィールドを取る即値代入命令があるが)。 そのため、 即値代入命令のみで 64 ビットレジスタに即値を充填するためには、 最低でも 4 命令が掛かっていた。
   しかし、 CISC の AMD64 は命令中に 64 ビット(8バイト)の即値フィールドを埋め込むことで、 1命令で充填が可能。凄い \(^_^)/
   
   
3. INC/DEC 命令がない。
   IA-32 の INC/DEC 命令は別の目的のために流用されてしまったので。。。

x86 のコンパイラがすでに存在しているのなら、 AMD64 用を作成するのはそれほど難しくなさそう。
今ならまだ需要がありそうだし、 AMD64 用の C/C++ コンパイラを作るのは面白そうだ。

追記：5/17

友人の T 氏より AMD64 の INC/DEC 命令について指摘があったが、

• IA-32 において INC/DEC 命令はフラグ依存のある低速な命令。
  最適化マニュアルでは ADD/SUB 命令を使うことが推奨されている命令なので なくても困らない。
  
• AMD64 から削除されたのは 8086 時代から存在する 1バイトのフォーマットの INC/DEC 命令 (INC(40h〜47h)、DEC(48h〜4Fh) の opcode 16個分を占めている)。
  この 40h 〜 4Fh のオペランドを AMD64 ではレジスタの 64 ビット拡張を表現する REX プレフィックスとして 転用している。
  
• 後ろにオペランドをとる 2バイト以上の INC/DEC 命令は、AMD64 にも存在する。
  

TV を見ようと

管理人の住む寮の部屋には TV がない。
部屋に引っ越した当初は パソコンに挿さっている ATI ALL-IN-WONDER 128 PRO で TV を見ようと思っていたのだが、 アンテナが悪いかのか ATI ALL-IN-WONDER 128 PRO の チュナーがいかれたのか受信できない。

そこで 秋葉のによったついでに、 コムサテライト3号店で 1番安かった KWORLD COMPUTER の Mpeg TV Station / PCI(KW-TV878R-PRO III/M)を購入。 5,750円なり。 1番安かったが Ulead の VideoStudio SE Ver5.0、 PHOTO EXPLORER SE Basic Ver7.0、 InterVideo WinDVR が付いてくる。

急ぎ足で家に帰って接続してみると、、、映らない。
アンテナコードも一緒に買って帰ったので交換して繋ぎ直してみても、、、 映らない。

ここまで来てようやく 壁の TV アンテナのモジュールまで信号が来ていないのではないか!? という可能性に気づく。。。

追記：5/13

寮の管理人さんに聞くと、 壁のモジュールまでは信号が着ているらしい。 NHK の受信料を払っていない寮生のモジュラーには TV 信号がこないのではないかと邪推したがさすがにそんなことはないようだ。

追記：5/22

新横浜のビックカメラで 室内アンテナを購入して TV チュナーカードに接続。 だが画面は砂嵐のまま。
例えアンテナを接続していない場合でも、 ノイズだらけの画面が出てもよさそうな気がするのだが。。。

[Java] Tiger(Java2 SE 1.5) からの Java 言語仕様の拡張

Java 言語は、 SUN の配布する次の Java 2 Platform, Standard Edition 1.5 (以下、J2SE 1.5) から、 その言語仕様に大きな修正が加えられる予定だ。
その内容を SUN のエンジニア Dr. Joshua Bloch が 紹介するページが公開された (ここ)。

J2SE 1.5 で Java 言語仕様に追加される予定の機能は大きく6点。

1. Generics
2. Enhanced for Loop
3. Autoboxing / unboxing
4. Typesafe enums
5. Static import
6. Metadata

ただし、仕様がまだ決定ではないので変更される可能性がある。

P.S.

長すぎるので、日記から外して独立したページを作った (ここ)。

音量調整ボリュームに関する疑問

Windows やソフトウェアの WAV・MP3 プレイヤーには 音量調整のボリュームがついている。 たいがいスライダー式になっていて 0 〜 MAX までの調整が可能だが、 このボリュームのポジションと音量が一致しないように感じる。

無論、 物理的な音の大きさと人間が感じる音の大きさにはズレがあって、 ボリュームの移動量と音量感覚を一致させるためには、 ボリュームの移動量(X) が物理的な音量(Y) に対して、 直線(Y=X) ではなく指数カーブ (Y=X^a) とする必要がある。

アナログオーディオの世界では、 音量調整には可変抵抗(Variable Register; VR) が使われるが、 VR には Aカーブ(指数カーブ)、Bカーブ(直線カーブ)、Cカーブ(対数カーブ)のような種類があって、 音量調整には A カーブの VR を使うと決まっている。 オーディオ機器の中身は デジタルとなったが「ボリュームの移動量と音量感覚の一致」の 原則は守られているようだ。

ひるがえって PC の世界では、 スライダーコントロールの数値が、 そのまま音量になっているように聴こえる。 OS の再生コントローラのボリュームが 線形に音量調整しているのはしかたないかもしれないが、 Media Player や Real Player の コントロールは聴覚上のものに合わせられないのだろうか？

[CPU][Bench] Opteron の SPEC CPU2000スコアが登録される

SPECのホームページに、 AMD Opteron の SPEC CPU2000 の計測結果が大量に登録された。
今回登録されたスコアの最高値は、 4/22に公開されたものと同じで、 Opteron 144 (1.8GHz) の Windows Server 2003(32-bit) 上での計測結果である int2k の 1,170、fp2k の 1,219。

登録された Opteron の結果をまとめると、 以下の表のようになる (括弧内の数値は base 値)。

Linux は、SuSE Linux Enterprise Server8。 (*1) の CFP2000 の結果は、 FORTRAN77 は Intel Fortran Compiler を、 FORTRAN90 は Compaq Visual Fortran Compiler を使っている。

AMD64 側もすでに SPEC CPU を公開できる程度に 完成しているのに安心した。
AMD64 対応した GCC のバイナリは、 IA-32 Intel コンパイラには負けているが 負け幅は1割程度の差なので、 Opteron 用に最適化された商用コンパイラが 出てくれば引っくり返せそうだ。 PGI がすでに AMD64対応の Fortran77/90、C、C++ コンパイラをベータリリースしているので、 AMD にはぜひともこれを評価して欲しいところだ。

同時に Intel も Pentium4 with HT の 3.0GHz / 3.06GHz のスコアを公開してきた。 システムバスが 800MHz になった Pentium4 w/HT 3.0GHz は int2k が 1,200、fp2k が 1,207。 fp は負けたが int で勝って INT2000 の王者の地位を守った。

参考

• 自分のサイト：SPECcpu2000 にみるプロセッサの性能自分のページも更新。

[Compiler] Borland C++ Compiler 5.5.1 を使ってみる

フリーで公開されている x86 用 C/C++ コンパイラの中に Borland C/C++ Compiler 5.5 があるのを思い出し、 x86 用の C/C++ コンパイラの性能比較に加えてみようと 軽くテストしてみた。

とりあえず、 SPEC INT2000 ベンチマークをコンパイルしたところ 164.gzip、175.vpr、181.mcf、197.parser、256.bzip2、300.twolf の 6 ベンチマークはビルドに成功したが、 176.gcc、186.crafty、252.eon、253.perlbmk、254.gap、255.vortex の 6 ベンチマークはエラーとなってしまった。
コンパイルエラーはシンボルの定義の不整合が原因のようだ。 コンパイラ付属のヘッダーファイルと、 CINT2000 ソースコード中で定義されているシンボルが衝突したりする。 これを動くようにするのは、 ちょっと手間が掛かりそうなので作業は留保する。

とりあえず 181.mcf と 256.bzip2 だけ計測してみたが、 181.mcf で 241、256.bzip2 と 269 なった。

追記：5/13

コンフィギュレーションを修正したところ 186.crafty がコンパイルできた。
コンパイルできていないそれ以外のベンチマークは、 include ファイルのシンボルの衝突が深刻で容易に修正できそうにないので諦める。
計測を開始したところ、300.twolf がランタイムエラーとなった。 実行性能は GCC 2.95.3 (cygwin) よりも悪く、 Open Watcom C/C++ とどっこいのようだ。

[CPU][Bench] PowerPC 970 & 64-bit Mac OS X のベンチマークが公開？

MacBidouille の この記事によると、 すでに PowerPC 970 1.4GHz single processor と 1.8GHz dual processor の Mac が存在し、 Cinema 4D-XL、Photoshop、Bryce5 を用いたベンチマークとして性能測定がされたらしい。
その結果、G4 1.42GHz の PowerMac Dual より 87% から 254% 性能が高いと結論づけられた 、、、、、 と良かったのだが MacBidouille のベンチマーク内容に事実と食い違う部分があったりして内容の真偽があやしまれ、 Mac 系の情報サイトや掲示板に飛び火して紛糾している。

ベンチマーク結果の正しいかどうか管理人には判断がつかないが、 とりあえず PPC 970 が出荷される日まで待つしかない。

参考

• Slashdot の記事：Preliminary OS X & PPC970 Benchmarks
• MacRumors：5/5 PowerMac 970 Benchmarks、 5/6 MacBidouille Rumors Followup、 5/7 MacBidouille Rumor Summary

パソコン選びに付き合って…

友人の Aze 氏が自分のノートパソコンをリプレースしたいと言うので、 パソコン選びに付き合って ひさしぶりに秋葉原巡りを行う。 しかし Aze 氏は機種選定はおろか、 ノートパソコンを買いたいのかディスクトップパソコンを買いたいのか 決めかねている状況。

ほうぼうを歩き潰してノートパソコンを買うと決断。
要件を分析すると Aze 氏の希望は15型以上の液晶ディスプレイ、 DVD-R ドライブ、TV チュナー機能付き。
富士通、NEC、SONY のノートパソコンに候補が絞られる。

ソフマップの1号店で実物を見ながら、 Aze 氏は SONY の PCG-GRV-88G に決定する。
しかし、シカゴ店では完売。 すでに生産中止。
石丸各店、ロケット、Laox 等をしらみ潰し探す。 7店目のラジオデパート向いのガード下の店で 最後の1台をゲット。
その後、 ソフマップ1号店に戻って Canon のインクジェットプリンタを購入。

JR 駅前で Aze 氏と分かれ帰路につくが足が棒のようになっている。
今日一日で 2 万歩以上あるいた。

P.S.

家に帰ってソフマップから「特別値引きチケット」なるものが 送られていたことに気づく。 1万円以上の買うと1,000円引きのチケット。
使わせておけばよかった。。。

DVD-R をひたすら焼く

連休を使って HDD のデータのバックを DVD-R メディアに取ろうと決意。
とにかく朝からひたすら焼いて13枚焼いたところでメディアが尽きる。

[Work] 並列 GC ルーチンの移植が完了

連休中だが会社に出社。
ここ 3 日ぐらい掛けてやっていた 並列 GC の移植作業を終わらせる。

並列 GC ルーチンの実装はすでに終了していたのだが、 実行するとバグが出てエラーで止まる。 で、 原因は 昨日 ソースコードをチェックしていたメイン部分ではなく、 並列GCが始まるプロローグ部分を移植し忘れていたこと。
6時間ぐらい無駄な時間を費した。トホホ。