NAKAMURA Minoru の日記 (2005年6月)

[Work] 今月はめっさ忙しかった

来月の半ばに開催される展示会の手伝いをさせられているが、 機器のトラブル & ソフトの不具合でズブズブの状態。 別件もあって、徹夜はしていないが、月のうち6日間 会社に泊まることになった。

今日もいろいろトラブル。 昨日まで動いていたソフトウェアが、今日は動作しなくなってしまう。
あれこれ原因を考えてチーフは電源系までも疑う始末。 でも UPS 設備 経由の電源に切り替えるとバグの割合が減ってしまう。

締め切りは後一週間ぐらい。

[Java] もう怒ったぞ〜〜〜

J2EE 1.3.1 RI で SPEC jAppServer を実行中。 しかし Servlet に接続できる最大接続数のパラメータが 25 に固定されることに気づく。 接続数を増やしていくと Servlet のログに No processor available, rejecting this connection というメッセージが 嫌になるほど吐き出される。

J2EE 1.3.1 RI の Servlet コンテナは Tomcat 4.0.2 がベース。
Tomcat の場合、 最大接続数を増やすには $J2EE_HOME/conf/server.xml ファイルの maxProcessors の属性を修正すればよいのだ。

<Server port="8005" shutdown="SHUTDOWN" debug="0">
  <Service name="Tomcat-Standalone">
    <Connector className="org.apache.catalina.connector.http.HttpConnector"
      port="8080" minProcessors="5" maxProcessors="75"
      enableLookups="true" redirectPort="8443"
      acceptCount="10" debug="0" connectionTimeout="60000"/>
  </Service>
</Server>

しかし値を変更しても変化なし。

J2EE 1.3.1 RI にはもう一つ $J2EE_HOME/config/web.properties というファイルがあり Servlet のポート番号を制御している。 詰まり設定ファイルが重複しているのだが、 こちらには最大接続数を決めるプロパティが用意されていない。

http.port=8000
documentroot=public_html/
https.port=7000
keystore.password=changeit
access.log=access.log
error.log=error.log
enable.invoker=false

しかしドキュメントを穴が空くほど読んでも設定が出てこない。
実行メソッドをトレースしたり、 コードをデバッガで追ったりしても解決できず。 最大接続数の設定は当然ながら存在するはずなのだが、 いったいぜんたいどうして見つからないのか？

最後には怒り骨髄に入る。
J2EE 1.3.1 を構成する Tomcat 4.0.2 のソースコードを落としてきて maxProcessors を強制固定。
$J2EE_HOME/lib/j2ee.jar 内の HttpConnector.class を入れ替える。

package org.apache.catalina.connector.http;

public final class HttpConnector
  implements Connector, Lifecycle, Runnable {

  private final int maxProcessors = 200;

  public void setMinProcessors(int minProcessors) {
    // this.minProcessors = minProcessors;
  }
}

所詮、Java プロダクツ。
クラスファイルを書き換えられては手も足も出るめぇ。

[DB] Oracle10g / Linux のトライアル版の期限

某所のシステムは、 手持ちの Oracle9i は Fedora Core3 ディストリビューションにはインストールできず、 Oracle10g のトライアル版をインストールして使っていた。

トライアル版の使用期限は1ヶ月なのだが、その期限が今日切れる。 どのようなメッセージを出して停止するか期待していたのだが、 Oracle をリブートしてもマシンをリブートしても停止する気配がない。 Why?

[Compiler] CodeWarrior でプラグインの作成

metrowerks の CodeWarrior は、 今年の 4 月で Windows 版と Mac 版の販売を終了した。

ところが某所では CodeWarrior Developement Studio for Symbian OS Personal Edition 向けに 開発環境を支援するプラグインを作成しようとしている。
クロスプラットフォーム環境なので IDE があるのは Windows/x86。
プラグインを作りたいのも Windows/x86。
Windows IDE のプラグインは CodeWarrior/x86 の C/C++ で作成する。
では CodeWarrior Developement Studio for Symbian OS Personal Edition の プラグインはどのコンパイラで作ればいいの？

製品の主な機能 には x86 コンパイラ v2.4.7 の文字が含まれている。 これでプラグインをビルドできそうな気もするが、 実際にビルドした人がいれば情報求む。

覚え書き

家賃払った。

[Java][Bench] SPEC JBB2005 が公開されたよ (www.spec.org、 IT Pro)

Java のベンチマーク SPECjbb2000 は、 名前を SPECjbb2005 と付け替えて延命措置が取られた。

jbb2000 は TPC-C を意識した卸売業者向けのオンライン注文処理を模擬するベンチマークで、 input - business logic - database の 3 層が 1 つの Java VM 上で動作する。 jbb2005 は jbb2000 をほとんどそのまま受け継いだ。

個人的には、jbb2000 は 何を計測しているのか分からない フォーカス不明なベンチマークだと思っている。 特に実システムでは考えられないぐらいメモリに敏感に反応する傾向があるので、 3GB で動く条件なのに 200GB 近くメモリを使って計測が行われたりするのだ。
私としては jbb2005 を作るのなら中身をガラッと入れ替えるべきだと考えていたのだが、 結局 中身はほとんど変わらないものになった。 SPEC の中の人も jAppServer のデータがほとんど登録されないので弱気になって、 それなりの登録数のある jbb2000を捨てられないのではないかと思われ。

SPECjbb2000 からの変更点。

• Java 5.0 以上が必要 (Generics を使用等の理由)
• 計測時間の変更 (1warehouse の計測時間が120秒→240秒)
• データベース部分を B木構造 → HashMap/TreeMap に変更。
• 金額のデータを double から BigDecimal に変更。
• System.gc() を呼ばない。
• ソースコードが OOP スタイルに修正される。
• 出力のフォーマッタ等に XML を使用。

あと SPECint_rate200x のように、 独立した JVM を並列に走らせる multi-JVM モードが追加されている。 これはちょっと面白い。

[Java] java.net.HttpURLConnection の実装

SUN JRE の java.net.HttpURLConnection の 実装は腐っていると思われる。 HttpURLConnection は同一ホストへの連続したアクセスをソケットを閉じないで KeepAlive 処理するのだが、 その処理方法が奇妙だ。

• HttpURLConnection.disconnect ではソケットが close されない。 なんのための disconnect だ？
• あるスレッドが開いたソケットを別のスレッドに渡してしまう可能性がある。 実質的に HttpURLConnection.disconnect はマルチスレッドで使えないよ。

HttpURLConnection はコネクション指向の API ではないと言ってしまえばそれまでだけど、 どうにかならんのか...

[Java] Java でシステムクラスローダーを外してしまう方法

「Java のクラスアンロード (Class Unloading)」 に AppLoader.java のサンプルを追加。 AppLoader は loadClass をオーバーライドすることでクラスロードの委譲関係を破壊するサンプル。 本来、クラスパス(classpath) の検索範囲にあるクラスはシステムクラスパスが読み込むのだが、 このサンプルでは AppLoader が親よりも先に強制的に読み込んでしまう。

ただそれだけはつまらないので、AppLoader はクラスパスの拡張機能を持たせている。 複数の JAR ファイルをクラスパスに並べて実行するのは結構面倒。

java -cp .:./lib/A.jar:./lib/B.jar:./lib/C.jar SampleProgram arg1 arg2 ...

AppLoader を噛ませるとクラスパスが指定したディレクトリの直下にある JAR ファイルも検索パスに追加してくれる。 使用したい JAR ファイルが ./lib/ の下に固めてあるなら、 以下のように実行することが可能。

java -cp .:./lib/ AppLoader SampleProgram arg1 arg2 ...

./lib/ の下にある A.jar、B.jar、C.jar も自動的に検索して検索パスに加える。 ただし抑止できないので、余計な JAR ファイルがディレクトリ上にあると動かない。

[Bench] SPEC CPU2000

富士通の IPF サーバー PRIMEQUEST はしょんぼり (´・ω・｀) なことになっているが、
PRIMEPOWER の SPARC64 V チップの方は RISC 系商用プロセッサで初めて動作周波数 2 GHz を越え 2160MHz を達成 (富士通)。 SPECcpu2000 のスコアも公開される。

• int2000 のスコアは 1594(1456) で、 Itanium2 1.5GHz と POWER5 1.9GHz に微妙に勝ち非 IA-32 系ではトップ。
• fp2000 のスコアは 2139(1808) で、 POWER5 1.9GHz、Itanium2 1.5GHz に続く 3 位。
  ローテーションレジスタやフルパイプライン化された浮動小数点ユニットを持つ上位陣に比べて、 SPARC64 V は浮動小数点がちょっと弱いなり。

その他 www.spec.org に登録されたスコアとしては、 Dell の Precision Workstation 380 (3.8 GHz Pentium 4, 2MB L2) での計測では int2000 は 1815(1793)、 fp2000 が 1984(1976) となり、 微増。

追記：6/22

忘れていたけど RISC 系の PowrePC 97x はもっと前に 2.0GHz を越えていたよ。

[DB] Oracle DB の閲覧ツール

ここ最近、Oracle DB のために使用した Windows のツールの紹介。

Oracle Table Explorer (フリー)

Oracle の DB をスプレッドシートのように可視することのできるソフト。 SQL の実行や、データの import/export も可能。

SI Object Browser (売り物、試用版)

前述の Oracle Table Explorer よりも高機能な Oracle DB の可視化ソフト。 すでに出来上がっている Oracle DB のデータ部を、 SQL 文 (insert) として書き出すことのできる機能を探しているうちに発見。

[CPU] AMD Athlon64 X2 発売記念イベント (AKIBA PC Hotline!)

「AMD Athlon 64 X2 デュアルコア・プロセッサ発売記念イベント」が秋葉原で開催されたのでノコノコ見に行く。 12:00 の Linux Cafe di PRONTO の部に少し遅れていくとスシ詰め状態なので、 13:30 からのカクタソフマップの部を見る。

Linux Cafe di PRONTO の部は冷房の効いた喫茶店の貸し切りで開催だったが、 カクタソフマップの開催場所はアセンブリパーツ売り場のある出口の外側。 暑いし、車は通るし、隣にはたちばな書店怪しい看板が立ち並んでいる。 傍から見るとさぞ怪しいイベントに見えたに相違ない。

日本AMD社長の新社長ディビット・ユーゼ氏のプレゼンは日本語。
「本社に掛け合って日本に X2 を大量に入れさせました。」
「AMD の一番遅い Dual Core でも、競合会社(Intel)の一番速い Dual Core より速いで〜ス。」
「今お使いのシステムに BIOS を変えるだけで動きます。」
とか言ってナリ。

[Food] ラホール＠秋葉原

AMD のイベントを待つ間に秋葉原のラホールで「極辛カツのせカレー」を食べる。

店の前	極辛カレーのカツのせ

ここも「キッチン南海」 のようにデリーのカシミールカレーをアレンジした店のようだ。

[Movie] Z ガンダムI 星を継ぐ者 (公式)

川崎チネチッタの17:00の部で鑑賞。

同じチネチッタで見た「真夜中の弥次さん喜多さん」の時はほとんど女性ばかりだったのに、今回は野郎ばかり。 しかも、みんな仲良く背負い袋を背負っている...

新作部分のキャラデザはぬっぺりとして評判がよくないようだ。 自分も恩田尚之(キャラクター作画監督)の絵は、宮 太一郎の絵のようだと感じた。

[Linux] RedHat Enterprise Linux AS 4 をダウンロード

昨日 Opteron サーバーにプリインストールの RedHat Enterprise Linux AS 3 を Red Hat Network(RHN) に登録したのだが、今日になると登録が完了しており up2date の使用と最新バージョンのダウンロードが可能になった。

RHN に接続して RedHat Enterprise Linux AS 4 の x86 版 と x86_64 版のイメージをダウンロード。 手持ちの RHEL は x86_64 版なので、x86 版がダウンロード可能になっていたのは意外。

ちなみに x86版はCD-ROMで4枚分、x86_64版は5枚分になる。 DVD-ROM イメージも用意して欲しいところだ。

[C++][Prog] C++ で仮想関数を導入するなら最基底クラスから

2004/2/1 に続き 仮想テーブルポインタの話。

話の枕

C++ 言語には 「C++ は派生クラスは親クラスのポインタで扱える」と 「任意の型のポインタを void* として扱える」というルールがあるが、 両方を混ぜると危険ですよという話です。

仮想関数を持たない親クラス Base と、 それを派生した仮想関数を持つクラス Derived を考えます。

class Base {
public:
  int field1;
  int field2;
};

class Derived : public Base {
public:
  int field3;
  virtual ~Derived() {}
};

「C++ は派生クラスは親クラスのポインタで扱える」ので以下の記述は OK です。

Base* p0 = new Derived();
Derived* p1 = (Derived*)p0;

「任意の型のポインタを void* として扱える」ので以下の記述も OK です。

void* p2 = new Derived();
Derived* p3 = (Derived*)p2;

ですが下の記述は NG です。 処理系によって動作したり、動作しなかったりします。

Base* p4 = new Derived();
void* p5 = p4;
Derived* p6 = (Derived*)p5;

修正をするなら3行目を次のようにする必要があります。

Derived* p6 = (Derived*)(Based*)p5;

仮想テーブルポインタ

上は、仮想テーブルポインタをクラスのどこに置くかという点が問題になっている。

まず Base クラスは polymorphic でないので、 大概のコンパイラはこれを以下のようなレコード構造だと認識する。

次に Base クラスを派生して Derived クラスが作られる時、 処理系によってレコード構造が異なるのだ。 GCC2以前とGCC3以降では、 仮想テーブルポインタ(vptr) を最初にスロットに挟み込むか最後のスロットに挟み込むかが変わるのだ。 Visual C++ も GCC3 以降のスタイルを使用している。

重要なのは GCC3 のスタイルでは、 Derived クラスの中に親クラスの Base が埋め込まれている点。 Derived ポインタを Base ポインタへ変換するキャストは、 暗黙のうちにポインタ内の数値を減算することになる。

(intptr_t)(Base*)p == (intptr_t)p - 4

2重キャストを用いないと、この加減算分が正しく繰り込まれないことになる。

[OS] Solaris Internals の 2nd Edition が出るよ (Exit 10)

Solaris Internals の作者 Jim Mauro の blog で Solaris Internals の第2版の予告があった。

Solaris Internals は Solaris で真面目なプログラム生活を送ろうという人に不可欠な OS 本。 初版は Solaris8 までの解説なので、第2版には Solaris9 で変わったスレッド機構や TLB、Solaris10 で加わった新機能の解説を望むところ。 すでに OpenSolaris のバイナリ & ソースコードが公開されたので、カーネルソースをじゃかじゃか見せながらネ。

[OS] Open Solaris の公式ページが開催 (opensolaris.org、MYCOM PC)

Solaris のオープンソース化がスタート。
OpenSolaris のソースコードは CDDL Version1.0 の下でダウンロード可能になった。 Web 経由でもソースコードをブラウジング可能。 ソースツリーの下には sparc、sparcv9、i386、amd64 の 4 つのアーキテクチャーが並んでいて気持ちイイ!!

Open Solaris のコンパイルには gcc 3.4.3 か Sun Studio10 Compiler が必要だが、 Sun Studio10 もフリーでダウンロード可能になった。 Open Solaris のビルドに必要なコンポーネントに絞ったコンパクトバージョンだが、 Fortran95 コンパイラまでついてくる。

P.S.

Sun Studio10 for SPARC をダウンロード。
これで Java2 SE SDK がビルドできると大変にありがたいのだが。

[Compiler] Intel C/C++/(Visual) Fortran Compiler v9.0 (Intel)

Intel コンパイラの最新バージョンが公開される (v8.1 → v9.0)。
Linux, Windows の両プラットフォームで、IA-32, IA-64, EM64T の 3 つのアーキテクチャをサポート。

EM64T 化は v8.1 でなされたので v9.0 ではそれほど大きなインパクトはないが、 地道に機能追加されている。

• 共通
  • マルチコアプロセッサ最適化コードの出力。
    (IA-32 アーキ) SSE3 最適化。
  • Window 版は Visual C++ 6.0 + Visual.NET に対応。
  • Linux 版は Eclipse 3.0 に対応。
• C/C++ コンパイラ
  • C/C++ では、バッファオーバーランを対策する実行時チェック機能導入。
  • Linux 版は GCC 3.2、3.3、3.4 に加えて最新の GCC4.0 互換に。
• Fortran コンパイラ
  • Hyper-Threading を使った Software-based Speculative Pre-Computation 最適化 を導入。
  • Fortran 2003 規格に対応。

驚いたのは Speculative Precomputation が商用コンパイラにしっかり入っているということ。
この最適化で性能が上がるとしたら凄いことだ。 スレッドレベル投機実行に弾みをつけることになるだろう。

1月で 58秒の遅れ

自宅の TV 録画サーバーになっている Windows マシンの内蔵時計が 58 秒も遅れていた。

2004/9/21 の日記 に書いた方法で 時刻合わせをしたと思っていたのだが、ちゃんと動作していなかったようだ。 Sakura Watch で最後に同期を取ったのだが一月前なので、 一日に 2 秒近く遅れていた計算になる。

録画は1分前から始めるようにしているのだが、 もう少し遅れると番組の頭が切れてしまうところだったぜ。

[MyWeb] 廃物利用

日記の内容をサルベージして独立ページを作成。

• SPECcpu2000 のビルドメモ
• 私の疑問
• RISC プロセッサの命令セットの特徴

最後の Ark 通信

ジャストシステムの 一太郎 Ark に関する メールマガジン「Ark 通信」の終了のお知らせが届く。
Ark は XML 編集ソフト xfy に引き継がれていくそうだ。

• xfy technology サイト
• xfy メーリングリスト

あうう

今日は、昼前に会社に出勤するつもりが起きたら夜の6時。
リモートではやり辛い仕事なので、出勤することにする。
＃ うちの会社は 社外 VPN を提供しているのに、どうして X プロトコルをトンネリングさせてくれないんだ。

[Food] イタリアンレストラン FRESCO＠武蔵中原

会社に行く前に飯を食べて行く。 武蔵中原の街中にあるイタリアンレストラン。

店の前

タラバガニとバジルのリングイネ

パンナコッタ

味はまあまあだが、立地条件から考えると価格が高い。上の二皿で1,900円は高いと思われ。
店員が多すぎるのでは (狭い店なのにウェイトレスが4人も!!)。

Google エラー

結構 珍しい Google がステータスコード 500番のエラーを出したところに遭遇。

画像の作成には WebScan.JP を利用。

[CPU][Java] PA-RISC は Java が ある程度 速かった

PA-RISC は PA-RISC 8900 を最後に退場することになるが、 すでに PA-RISC 8800 頃に速度競争の場から姿を消していた。 それでも SPECjbb2000 のスコアがぽつぽつ公開されているので、 Java を実行した場合の性能を予測することはできる。

SPEC jbb2000 とは以下のようなベンチマーク。

• 全部、Java で書かれたプログラム。 1台のマシン上で動作する。 Java 仮想マシンは自由に選んでよい。
• マルチスレッド化されたベンチマークで、1秒あたりのトランザクション処理数が測定対象になる。 測定は、1回の2分の計測を複数回繰り返す。 1回ごとに処理スレッドを順番に増やしてゆき、 ピークとなるスレッド数 N を見つけ、その後 N から 2 * N スレッドまでの 平均トランザクション数が全体のスコアになる。
• 極めて高い並列性があるため、 ピークは普通 CPU 数(コア数) の位置にでる。
• SMT (Simultaneous Multi-Threading; Intel は Hypert-Treading と呼ぶ) 機構を持つプロセッサに有利。 SMT を有効にすると 20% 〜 30%程度向上。
• 浮動小数点演算能力はほとんど関係ない。

8 Core(s)

8コア の計算機での SPEC jbb2000 スコアをアーキテクチャ毎に並べると以下の表の順になる (参考: 2003年7/1の日記)。 Dual-Core は 1チップで2コアと数えている。

POWER5 が圧倒的に速い。 もともと整数系も速い上に L3 キャッシュをべらぼうに積んでいて SMT が有効になっているのが強さの秘訣。

注目は PA-RISC 8800 がまだ Itanium2 に勝っている点だろう。
Itanium2 が最新の Merced チップ (1.6GHz / L3:9MB) でない点は割り引いて考えるべきだが、 この段階になっても逆転できない Itanium2 の存在意義って何だろう？ PA-RISC 8900 は 周波数が 1.1GHz に L2 キャッシュが倍 (64MB) に拡張されたのでもう少し性能が向上しているはずだが、 もうスコアが登録されることはないのが悲しい。

PA-RISC 8800 は出てこないが、 4-コア SMP マシンと 2-コア SMP マシンのアーキテクチャ別スコアを並べてみる。

4 Core(s)

2 Core(s)

2コアと4コアで、順番が入れ替わっているのが分かる。
POWER5 のスコアは 4-コア時の性能が 2-コア時の性能の倍になっており CPU 数によらない性能を出しているので POWER5 を軸に考えることができる。 そうすると Intel の Xeon 系と Opteron という「パソコン向けの石」が 4-way → 2-way で POWER5 を追い越していることが分かる。

特に Xeon 系はメモリが共有のシステムバスを介して行われるために way 数が増えるごとに 1 コアが使えるメモリ帯域が減っていくことや、 キャッシュプロトコルが大規模 SMP 向けでないことが効いている。 このあたりが、way 数 の大きな IA サーバーが使われない原因になっている。

Result/Core

最後に SPECjbb2000 のスコアをコア数で割った値を、アーキテクチャ毎に列挙。
CPU 数も違うのであんまり意味のあるデータではない。

Alpha は他のプロセッサーに後塵を拝すようになってしまった。
PA-RISC もやがてはこうなる宿命。

同一時刻に同一ホストから同一 URL へアクセスがあるのになぜか User-Agent が異なる

Web サーバーのアクセスログを見ているうちに変なアクセスパターンがあるのに気づく。
同一時刻に同一ホストから同一 URL へ連続して2回アクセスするパターンがあるのだ。
でもなぜか User-Agent が異なっている。

頻度は 3日に1度ぐらい。 残っている最古のアクセスログ(2003年の10月)からも発見できるので、 それ以前から存在しているようだ。

E.F.G.H - - [28/Oct/2003:15:52:48 +0900] "GET /cgi-bin/minibbs/bbs.cgi?img=copyright HTTP/1.0" 200 399 "http://www.nminoru.jp/cgi-bin/minibbs/bbs.cgi" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
E.F.G.H - - [28/Oct/2003:15:52:48 +0900] "GET /cgi-bin/minibbs/bbs.cgi?img=copyright HTTP/1.0" 200 399 "-" "Mozilla/3.01 (compatible;)"

A.B.C.D - - [10/Jun/2005:15:01:02 +0900] "GET /~nminoru/diary/2005/06.html HTTP/1.1" 200 6079 "-" "Mozilla/3.01 (compatible;)"
A.B.C.D - - [10/Jun/2005:15:01:02 +0900] "GET /~nminoru/diary/2005/06.html HTTP/1.1" 200 39452 "http://www.google.co.jp/search?hl=ja&q=quad+precision+SPARC&lr=" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

2つのアクセスのうち referer がある方はアクセス毎に user-agent が異なっていて 人間が普通に使っているブラウザっぽい。 もう一方の referer がない方は "Mozilla/3.01 (compatible;)" に固定されていて、 なんらかのツールからのアクセスのようにも思える。 ただ何のために重複したアクセスをしているのかは不明だ。 無駄にしか思えないが。

P.S.

2004年の9/10 に書いた、 user-agent が "1.0" なアクセスはいまだ続いている。
1度だけ固定IPアドレスで Web サーバーを公開しているサイトからアクセスが来たので、 サイト管理者に「調査に協力しろゴラァ〜」というメールを出したのだが返信なし。 IIS を使っていたので Windows 系の OS につくスパイウェアの類なんだろうなぁ。

[Java] HttpUnit を使う (公式)

ちょっと複雑な Web アクセスをシミュレーションをする必要があり、 Mercury の LoadRunner のスクリプトを書こうと勉強していた。 しかし付け刃の知識では色々トラブルがあってうまく処理が書けない。

しょうがないので Java でクライアントを直に書くことにする。 最初は java.net.HttpConnection を使って作ろうとしたのだが、 こいつは HTTP/1.1 のコネクションを貼り続けたまま、 リクエストを複数回だすことができないのね。。。

なんかうまいツールをと思って探していると HttpUnit を見つけた。 Web の画面を解析してフォーム等を Java オブジェクトで認識できるようにしてくれている。 へろへろプログラム。

// 対話的な HTTP 通信を開く
WebConversation wc = new WebConversation();

// http://server:port/path/servlet にリクエストを投げる
WebRequest request = new GetMethodWebRequest("http://server:port/path/servlet");

// そのレスポンスを受け取る
WebResponse response = wc.getResponse(request);

// ステータスが 200 番であること
if (response.getResponseCode() != 200) {
  return false;
}

// 最初のフォームを取得
WebForm[] forms = response.getForms();
WebForm form = forms[0];

// フォーム中の SELECT/OPTION 要素の値を取得
String[] values = form.getOptionValues("item_name");

// フォームの値をセット
form.setParameter("cust_id",   Integer.toString(customerId));
form.setParameter("item_name", values[random(values.length)]);
form.setParameter("qty",       Integer.toString(1));
                
// サブミットボタンを押す
response = form.submit(form.getSubmitButton("submit","Add"));

出力される HTML 画面の一部を切りとってプログラム的に加工したいときに便利だ。

とりあえず目的の負荷シミュレーターを作成できた。万歳。

[Java] .NET と Java の速度比較ベンチマーク (TheServerSide.NET、TheServerSide.COM)

Java PetStore ベンチマーク合戦以降も Java 陣営と Microsoft .NET の性能競争は続いていたもよう。 今回は Microsoft 側からの挑戦。

Java2 SE 5.0 と .NET 2.0 beta2 で Web サービス通信、XML 解析の性能比較が行われる。 比較対象は Microsoft 側は .NET 2.0 beta2 + .NET 1.1 + IIS 6.0、 Java 側は SUN JWSDP 1.5 + SUN HTTP Server 6.1 + IBM WebSphere 6.0 + IBM HTTP Server 6.0 で、

結果は大雑把にいうと「.NET 2.0 の方が倍ぐらい速い」。 Java 側としては、この結果をどう分析しようかしら。

更新

• 「Java の各種ベンチマーク」 のページに、今回のベンチマークを追加しておく。

はてなRSS (はてなRSS)

気づかないうちに「はてな」に RSS アグリゲーターができていた。
これまで Firefox のブックマークで RSS を読んでいたが、 Web ベースの方が使い勝手がいいので 移行中。

ところで はてなシリーズの favicon.ico の中で、 はてな RSS の favicon.ico だけが中の文字が明るいよ。

なぜだか人力検索で聞いてみるか？

追記：7/14

アイコンのデザインが変更になったようで、 地と文字のコンストラストが統一された。

郵便局留め

某ファンクラブの会誌が郵便で配達されたらしいく、 不在通知が部屋のポストに届いている。
武蔵小杉の郵便局に保管されているものを取りに行く。

[CPU] Apple は Intel プロセッサを採用するか？

Apple が Motorola の PowerPC プロセッサから Intel プロセッサに乗り換えるのではないかという噂が飛びかっているが、 米国時間の本日 サンフランシスコで開催される Worldwide Developer Conference (WDC) で明らかになるよ。

追記：6/7

基調講演で Jobs が正式発表。
2006年に Intel チップの Mac が登場、2007年内に PPC からの移行を完了するそうだ。

しかし PPC64 用の開発ツールを作っているメーカーは泣き出したいだろうな。 Fortran コンパイラを作っている absoft とか。

参考

• Apple のプレスリリース (Apple)
• WWDC キーノート概要 (MacNN's IRC Network)

Adobe Photoshop Album 2.0 mini (Adobe)

Adobe が Photoshop Album 2.0 の機能制限版 mini を無料で公開している。
フォトレタッチソフトとしては「一般的なバランスの調整」(オン・オフのみ。レベル調整はなし)、「トリミング」、「赤目の修正」のみが可能で、 ぼかし等のエフェクト機能はない。

ただトリミング機能は充実していて、トリミング枠の縦横比を固定したズームが可能だ。 矩形の始点と終点を指定するようなトリミング機能を使うと、 トリミング枠がこちらが思う 4:3 の縦横比にならないのでずっと苦労していたのが これを使うと解消しそう。

ちなみに現在のところこの Web に写真を貼るのに以下の手順を踏む。

1. DiMAGE Xi で 2048x1536 で撮影
2. デジカメ附属の DiMAGE Viewer で 画像の回転、明るさ・コンストラクトを調整。
3. 必要に応じてトリミング、エフェクト加工。
4. すなねぃる で 100x75 / 75x100 のサムネイルを作成。
5. BatchGOO で原本の 2048x1536 を Web 掲載用の 640x480 にリサイズ。

このフローがもっと高速にまわせるツールがあるといいのだが。

追記：5/11

3千枚強の自分のデジカメ写真を Photoshop Album 2.0 mini に取り込むと、 サムネイルを表示しただけの状態で CPU 使用率が 100% を振り切れるようになった。 やたら重くて使えない。。。

[CPU] RISC 命令アーキテクチャーの変態度チェック

6/2 の日記の続き。 MIPS、SPARC、PowerPC、PA-RISC、Alpha の五大 RISC アーキテクチャに関するアーキテクチャの特徴のメモを発掘。 フローチャートにしてみる。

[CPU] PA-RISC 追悼

昨日 PA-RISC の訃報を聞いてから昔書いたメールを漁っていたら、 PA-RISC がいかに変態的な命令セットなのかを説明するメモが出てきた。 他の RISC プロセッサの命令セットに関する予備知識があることを前提として書いているため 分かり辛いかもしれないが、 文末の表現を過去形にあらためて掲載してみる。
とくに断らない限り PA-RISC 2.0 (64-bit) のみ扱う。

レジスタ

レジスタは RISC プロセッサとしては標準的だった。

• 64-bit 汎用レジスタが 32 本 (GR0 は 0 レジスタ)
• 64-bit FP レジスタが 32 本 (ただし特殊な使い方があった)

即値フィールド

即値の扱いは捻くれていた。

• 算術演算は 11ビット符号付き即値が使えるが、 論理演算に即値フィールドはなかった。
• 32-bit の上位 21ビット即値([32:12]) をソースレジスタに足す演算があり、 11ビット即値と組み合わせると 2 命令で 32-bit 定数を作れた。
• ロード命令のアドレス指定即値は符号付き 14ビット(ただし prescale で 3 ビットシフト可)だが、 符号付き16ビットもあった。
  MIPS はほぼ全ての命令に16ビット即値が完備されている (算術演算は符号付き、論理演算は符号なしとして扱う)。
  Alpha は符号なし 8 ビット即値が基本で、 加算命令にのみ符号付き16ビット即値命令があった。

演算

• 乗算・除算命令は加算・減算と同型。
  つまりディスティネーションレジスタに書き出す R0 = R1 op R2 の形式。
  MIPS は乗・除・剰余算の結果は専用レジスタに格納される。
  SPARC は V9 になるまで整数乗算・除算がなかった。 SPARC は V9 になるまで専用スタイルを使う特殊な乗・除算命令が定義されていた。 ただし実際のチップにはその命令が実装されておらず、 コンパイラもその命令は出力せずにライブラリを呼び出していた。 V9 は R0 = R1 op R2 の形式。
  Alpha は R0 = R1 op R2 の形式だった。
• ビット操作演算があった。
  Alpha にもあった。Alpha にはバイト操作命令もあった。
• 一部命令(Shift and Add、Scaled-Indexed Loads) でスケールをつけた演算が可能。
  つまり r0 = r1 + r2 << sa、 r0 = [r1 + r2 << sa] (sa は 0 〜 3 の即値) という形で計算できた。
  これはループの中で配列を扱う時などにとっても便利だった。
  Alpha にもあった。
• Parallel Subword Operations といって、 64-bit レジスタを 16-bit づつに区切って処理する整数ベクター演算があった。
  マルチメディア系対応した飽和演算処理がされた。
  x86 の MMX の走りですな。

ロード・ストア命令

メモリアクセス命令は他の RISC プロセッサと大差なかった。
ただし Address Updates という機能がロード命令にあり、 ロードと一緒に (ベース) レジスタの内容をインクリメント・デクリメントができていた。

条件分岐命令

PA-RISC の条件分岐命令はかなり複雑で、 combined operation annd conditional branch で 演算命令と分岐命令がくっついた形をしていた。
基本は 2 つのレジスタの比較演算の正否によって分岐の成立を決定するが、 ADDB・MOVIB という「足し算の結果で分岐」・「レジスタ間転送の結果で分岐」という 特殊な条件条件分岐命令もあった。

MIPS は 1-汎用レジスタの中身を見て分岐。 2-汎用レジスタの内容を比較しての分岐もあり。
SPARC、POWER は条件フラグの値で分岐。
Alpha は 1-汎用レジスタのチェックで分岐。

遅延スロット(delayed slot) の呪いはきっちり受けていた。

Nullification

PA-RISC の最大の特徴だったのが Nullification。
Nullification は条件によって後続の命令を nullify (実行しない、スキップする) という機能だった。 プレディケート付き命令の走りみたいな機能だったあるね。

• Branches with Conditional Nullification
  Nullification が指定された条件分岐命令は、 delayed slot の命令を実行するかどうかを決定する。
  • 後方分岐の場合、not-taken で nullify。
  • 前方分岐の場合、taken で nullifiy。
• Operatoins with Conditional Nullification
  通常演算にも Nullification が指定でき、 演算の結果が条件を満たしたら後続命令が nullify された (たとえば加算命令の場合、演算の結果がオーバーフローしたら or Not など、 条件を決められる)。

浮動小数点演算

浮動小数点レジスタは、以下のように 3 種類に使えた。

1. そのまま使って 64-bit FP レジスタが 32本。
2. 2本づつ束ねて 128-bit FP レジスタが 16本。
3. 半分に分割して 32-bit FP レジスタが 64本 (下半分が L、上半分が R)。

Mulitply and Add 命令もあった。
あと FP ユニットを使った固定小数点乗算命令があったが詳細は不明。

しかし SPARC 命令セットと比べると、 PA-RISC 命令セットの変態度はかわいいものだね。
ちなみに、私の頭の中にある命令セットの変態度は下のような順。

(ふつう) Alpha < MIPS < POWER < PA-RISC << SPARC < AMD64 < IA-32 << IA-64 (変態)

修正：6/3

ちょっと修正。

[CPU] さようなら RA-RISC (公式、 ITmedia)

HP が PA-RISC アーキテクチャーの最後のチップ PA-8900 をリリース。
PA-8800 に続き今流行りの dual-core チップ。
あまり情報がないが GEEK.com の PA-8900 チップの諸元 の ページが埋まるのを祈ろう。

これまで MIPS プロセッサーを載せていた HP NonStop Server も、 Itanium2 サーバーを使った HP Integrity NonStop Server に交替。

追記：6/2

endian.net の PA-8900 が更新されている。
PA-8800 と本質的な違いはなく、 動作周波数が 〜 1.1GHz に伸び、L2 が 64MB (PA-8800 は 32MB) に増強されただけのようだ。

Google AdSense のリンクユニット広告

日記の右肩にリンクユニット型 AdSense 広告を配置。
これで Google 先生がこの日記をどのように特徴抽出しているか丸分かり。
でもリストに「ヤミ金」とかが出てくると萎え。

[時事] 地震

19:06 M3.9、19:40 M3.7、20:44 M4.2。
いずれも東京湾を震源とした地震が発生。
川崎は震度2。