NAKAMURA Minoru の日記 (2004年7月)

先月の日記(2004年06月) 今月の日記(2004年07月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2020 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2021 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2022 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2023 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2024 | 1 | 2 | 3
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | slideshare | github | Qiita



7/30 (金)

[Java] 方向性を変えよう

IA-64 プラットフォームでの太陽の JavaVM の性能はやはり惨澹たるもの。
BEA JRockit との性能差のほとんどは ダイナミックコンパイラにありそう。
JRockit の資料を見る限り ダイナミックコンパイラを作り直さないと追いつけそうにない。
コンパイラを作り直すマンパワーはないので、 ライブラリチューニングによって高速化できないか考える。

J2EE アプリケーションは String や StringBuffer の文字列処理が 大きなウェイトを占めているのでここを高速化できればかなり速くなるが、 太陽の JVM はあまり最適化されていない。 例えば

  • ロケーションの絡む文字列処理は負荷が大きいが、 最適化されていない(コードもデータも大きいからね)。
    特に日本語周辺の処理は、 後回しにされているようなので ライブラリに手を入れると高速化可能なり。
  • 文字列中から部分文字列を検索する String.index メソッドは 先頭から単純に文字を比較していく非効率なアルゴリズム。
    文字列検索では Boyer-Moore アルゴリズムなど高速なアルゴリズムが存在するので、 動的にプロファイル情報を取ってアルゴリズムを切り替えながら使用すれば 高速化できる(ような気がする)。
  • String.charAt、StringBuffer.append も アルゴリズムを適応的に切り替えると高速化できるはまりパターンがある。

ということをぼちぼち寝ながら考える。

今日の青森

青森では SWoPP をやっているはず。
共著の研究の発表があるが、中身を見てないっす。 ガクガク、ブルブル


7/29 (木)

[Compiler] EM64T 対応の Intel C++/Fortran Compiler v8.1 が公開

Interl Premier Support から Extended Memory 64 Technology (EM64T) 多対応の ICC/IFC v8.1 が公開された旨のメールが届く。 とりあえず Linux 版 Only。

早速 ダウンロード。
ICC の Package ID は l_cce_p_8.1.018、 IFC の Package ID は l_fce_p_8.1.018。 Build 番号は共に 20040708。

実機がないので確認はできないが、 現在 AMD64 最速の PathScale のコンパイラとどちらが 高速かが気になるところ。

追記:8/17

Linux 版は ICC 8.1 for EM64T は long 型とポインタ型が 64-bit な LP64。
ポインタは 64-bit だが、 Small (-mcmodel=small)Medium (-mcmodel=medium)Large (-mcmodel=large) の 3 種類のメモリモデルタイプが選択できる。 Small はコード領域とデータ領域を 4GB 以内にメモリを抑え、 Medium ではコード領域だけを 4GB 以内に抑え、 Large では無制限となる。 MS-DOS みたいだ。

あと何故か良く分からないが EM64T 版固有の制限として、 C++の例外や RTTI を無効にできない制限が加わった。

ICC v8.1 全体としては、 Eclipse 対応や gcc 3.3 に導入された Thread-local Strage (__thread) の機能が追加された。


7/28 (水)

インターネットはもっと分散化できないのかしら?

インターネットの世界ではまたもやワームが大量発生のもよう。
今度は google などの検索サイトがダメージを受けたようだ。

こういうことが起きるたびに思うのだが 「インターネットが核攻撃に対処するためのネットワーク」という 当初の目的に立ち返って分散化を進めることはできないかしら?

グリッドを使って主要機能の分散化をはかれないかしら?

現在では Web サーチエンジンが止まってしまうと さっぱり仕事にならない人も多い。
素人考えだが、 こういう重要機能を もっと分散配置できないものかしら?
例えば

  • ISP がグリッドノードを提供して、 検索サービス会社がそこに「Web 検索エンジン + データ」を流し込んで、 検索サイトを実現する。
  • ユーザーは近場の/空いている場所にアクセスして検索機能を利用。
  • 広告は検索サービス会社がベースだが、 グリッドを提供している ISP が特化した広告も出せる。

というのは無理かしら?

重要なファイルをイントラネット内に配置して配信できないか?

Windows アップデートのジレンマというのがあって、

インストールしたばかりの Windows OS には 外部から乗っ取りを受けるような深刻なセキュリティーホールがある。
そのため、 インターネットに接続する前にWindows アップデートを行う必要。
だが、 Windows アップデートを行うには インターネットに接続する必要。

深刻なバグの場合はセキュリティーパッチがファイル形式で提供もされる。
ただ、 普通の人は それを安全なマシンでダウンロードして セキュリティアップデートの掛かっていないマシンに移して実行というような 面倒な手順は踏んでくれない。 アップデート中に攻撃を受けないことを信じて エイヤとアップデートを実行するのみ。

こういう事態を防ぐために、 インターネットに行く前に適用可能なパッチを イントラネット内から自動検索するような機構はできないかしら? (IE のプロキシ自動設定ファイルのように)

追記:8/18
CNET の 記事 によると、 パッチ未適用の Windows パソコンをインターネットに接続した場合、 平均 20 分で侵入されてしまうそうだ。 ひぇ〜〜〜。

この研究者らによると、パッチ未適用のWindowsパソコンをインターネットに接続した場合、 平均わずか約20分で悪質なソフトウェアに侵入されてしまうという。 同グループが2003年に行った評価ではこの時間が約40分だった。それと比べると、時間が大幅に短縮されている。
SANS Instituteの一部門である Internet Storm Center は、 空いているIPアドレスに届くパケットを監視して20分という「生存時間」を算出した。 同センターは、セキュリティ問題に関する研究・教育を行っている。
ISP が NTP サービスも提供して欲しい

Windows OS が標準で NTP クライアントになる機能を持っていなかったためか、 NTP はいまいち人口に膾炙していない。 そのためか NTP サービスを提供してくれている ISP はほとんどないようだ。

最近は TV キャプチャリングをする人が増えたせいか、 NTP は使われるようになってきている。
それでも遠い未来や遥か昔からメールがくるのは なくならないナリよ。

本来は ISP 毎に NTP サーバーを立てて マルチキャストアドレス 224.0.1.1 が処理できるようにするのが 理想だと思うのだが。。。

ただ Windows 系 OS が標準で NTP クライアントになるようになると、 今 NNTP サーバーを立ち上げている少数のサイトは恐ろしいことに。。。

参考
日本の NTP サーバー

今日の届け物

ACM から 2004 SIGPLAN の CD-ROM が届く。
Online Membership には物理的なものは何ももらえないと思っていたからびっくりナリ。

コメントを書き込む
[本店@S.F.] 2004-07-30 15:51:16
素のOSに対してのWindowsUpdateに関しては、FireWallをイネーブルしてUpdateかけてやれば、だいたい大丈夫ではないでしょうか?完璧ではありませんが、、、
[管理人] 2004-07-31 00:15:21
今のところ FireWall 機能にバグが見つかっていないので「だいたい大丈夫」なんですけど、やっぱり論理的にみて穴がない方法が欲しいの心です。
あと、データセンターなんかだと何十台というマシンに OS を仕込むことになるんですけど、こいつらがバラバラに Windows Update サイトに繋ぎに行くのはいや〜んというのもあります。

ところでメリケンでは「Fahrenheit911」の人気はどうですか?
[本店@戻ってた] 2004-08-03 16:29:44
WindowsUpdate用のサーバを社内に立てれば、外に集中アクセスしに行くのは大分ましになりますよね?まあファイヤーウォールの問題はそれでも解決しませんが。

911に関してはテレビでぼちぼち取り上げられていましたよ。
[管理人] 2004-08-04 02:15:15
WindowsUpdate サーバーのミラーサーバーって作成可能なのですか?!
できればやってみたいですが、、、IIS が必要?

7/26 (月)

SCTP (Stream Control Transmission Protocol)

今日は SCTP の話を聞いたので そのメモを残しておく。
SCTP (Stream Control Transmission Protocol) は IP 上で動作するトランスポート層のプロトコルで、 TCP や UDP の alternative。TCP/IP ならぬ SCTP/IP。 SCTP の特徴は以下の通り。

  • モバイル環境での使用を意識して、 プロトコルレベルでマルチホーミング (Multi-Homing) を可能。
  • ストリーム指向のプロトコル。 1つのポートを使って複数のストリームを通信することができる (Multi-Streaming)。
  • メッセージが1つの通信フレームに収まるようにする機能をサポート。
  • TCP の設計・実装は古く DoS アタックなどに弱い。ここを改善。

この中で一番大きな特徴はマルチホーミング。
SCTP のマルチホーミングは信頼性の確保のためで、 現在はまだ負荷分散のために使うなどはできないようだ。

TCP や UDP で書かれたプログラムはサーバーとクライアントが 一対一の関係しか持ちえなかったので、 端末なりサーバーなりが移動して IP が変わってしまうと 接続を一旦遮断して貼り直す必要があった。
SCTP は接続先・接続元を示すのに 複数の IP を束にしたエンドポイント(endpoint)を指定する。 Endpoint に複数の IP を指定した場合、 その中から "primary" な IP を選んで通信するが通常だが、 primary との通信が遮断された場合 alternative への送信が行われる。

SCTP は色々と応用ができそうだが、 問題は現状 ルーターやゲートウェイが対応していないから、ルーター越しの通信が難しいこと。 とりあえず繋ぎの技術として SCTP over TCP や SCTP over HTTP があるといい??


7/25 (日)

横浜観光

スイスから来たインターンシップ生を交えて横浜観光。
横濱カレーミュージアム → ランドマークタワー → 空煉瓦の倉庫 → 中華街と歩行。


7/22 (木)

[Compiler] AMD64 向けコンパイラがバージョンアップ

HPC 分野では Opteron が Itanium2 はおろか Xeon すら蹴散らす勢い。
AMD64 用のコンパイラも(地味にだが)バージョンアップしていていい感じ。

HyperTransport を使って SMP 構成を取った Opteron は ローカルのメモリとリモートのメモリで速度に差があるけど、 このコンパイラはちゃんとその差を考えて配置して最適化をしてくれるのかしら?

カレンダー

職場でも使っている Web Calendar を 自宅のサーバーにセットしてみる。

[Trivia] 人類が採掘した金はプール何杯分か?

しばらく前から人類が掘り出した 金(Ag) の総量のデータを探していたのだが、 ここ で 見つけた。
2000年までの総量が 142,600 トン。 50メートルの競技用プール約3杯分。

子供の自分に同じような記事をみた時には 「競技用プール2杯分」と書かれた記憶がある。 約1杯分増加したようだ。 最近では毎年 2,500 トンづつ採掘が進んでいるので、 残り埋蔵量は 72,000 トンを 30年ぐらいで掘り尽くすもよう。

今日の楽天会員

いつのまにか楽●天の シルバー会員になっていたよ。

コメントを書き込む
[S.J.] 2004-07-29 22:37:52
所在不明が3,500トン・・・そのうち何トンくらい食べられたのでしょうかね。
[管理人] 2004-07-31 00:36:03
さすがに人類が食べることによって消費した金はトンには達しないのでは (^_^;
いっぱい食べた人は、後で回収されたでしょうし :-)

7/21 (水)

某社の某大学某学部の OB 会

新宿の京王プラザホテルで OB 会が開かれる。
会員は多いが、出席者は 20 人前後。新人は2人。

京王プラザホテル 47階
47階から見下ろす
新宿の夜景
新宿の夜景

料理は立食形式でしたが結構豪勢。

OB会: OB会: OB会:
OB会: OB会:
ゴルゴンゾーラクリームのニョッキ
OB会:
OB会: OB会: OB会:

うちの会社は人気がないから、来年はさらに寂しいものになりそうだ。


7/20 (火)

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

AMD から Athlon64 FX-53 (2.4GHz) のスコアと、 DELL から Intel Pentium M 755 (2.0GHz) のスコアが公開される。

Athlon64 FX-53 は CINT2000 が 1700(1601) で、 CFP2000 が 1597(1504)
CINT2000 は Operon 1500 よりもスコアが高くなり、 Pentium4 with HT EE に続き 2 位。

Pentium M 755 は CINT2000 が 1541(1528) で、 CFP2000 が 1088(1087)
整数系のスコアは Itanium2 よりも高くなり、 Intel の CPU の中では Pentium4 系 > Pentium M 系 > Itanium2 系の順位。

更新


7/19 (月)

[Java] メモ

うだるような気温と湿度の中、 エンスト中の脳味噌で調べものをして過ごす。

J2ME で動作する Servlet Container

J2ME で動作する Servlet コンテナを調査中。
JSP は不要、Servlet の仕様も完全に満たす必要がないという条件なら、 どこかに落ちてないものかしら?

distcc

IBM developerWorks の記事 より。
クラスタ環境を有効に利用して、 モジュール分割されたビルドを バラバラのノードで分散コンパイルするというツール。
make -j <n> のクラスタ版ね。

Java でデータバインディング (data binding)

Java のオブジェクトを XML へ変換・逆変換できる XML データバインディングツールをチェック。 以下のようなものがある。

結局、マーシャリングメソッドを書くのを どこまでサボれるかミソのような気がする。
このあたりは AOP 的な方法でどうにかならんものかしら、、、

そういや「脳味噌」ってどうして「味噌」なんだろう?
形状の一致? 色? それともまさかして味、、、


7/18 (日)

[Java] Java の invokevirtual 命令と invokeinterface 命令の違い

継承を使ったメソッド呼び出しと インターフェイスを用いたメソッド呼び出しの Java VM から見た時の動作の違いをここにまとめておく。

interface Interface {
  public void method3();
  public void method2();
  public void method1();
}

class Abstract {
  abstract public void method1();
  abstract public void method2();
}

class Implement extends Abstract implements Interface {
  public void method1() {}
  public void method2() {}
  public void method3() {}
}

Implement  object = new Implement();
Abstract   abstra = (Abstract) object;
Interface  interf = (Interface) object;

abstra.method1();   // (1) invokevirtual になる
interf.method1();   // (2) invokeinterface になる

Java のバイトコードレベルでは、 クラスの参照経由で呼び出す (1) とインターフェイス経由で呼び出す (2) は 別々のバイトコード命令となる。 (1) の方が invokevirtual で (2) の方が invokeinterface に変換される。

Java の invokevirtual 呼び出しは、 多重継承を使わないときの C++ の仮想関数呼び出しに似ている。
一般的な JavaVM の実装では、 Java クラスはそれぞれ一つづつ 仮想関数テーブル にあたるもの持っている。 Java は単一継承を採用しているため、 クラスを継承した場合はこの仮想関数テーブルを下方に どんどん拡張することになる。

この方式では 同じ signature を持つメソッドが、 派生元のクラスの仮想関数テーブルと派生先のクラスの仮想関数テーブルで 同じ index 番号を占めることになる。 そのため abstra.method1() の処理は、 メソッド void method1() にあたる index 番号を取得した後、 「abstra が参照するオブジェクトの仮想関数テーブル 0 番目のメソッドを呼び出す」という 処理で実現できる。 signature から index 番号への変換は、 abstra.method1() を最初に実行した時に1度だけ行い、 後は結果をキャッシュするなどの最適化ができる。

Abstract の仮想関数テーブル
indexMethod
0void method1()
1void method2()
Implement の仮想関数テーブル
indexMethod
0void method1()
1void method2()
2void method3()

一方、invokeinterface の動作は少々厄介で、 C++ の多重継承よりも動作が複雑になる。
まず invokeinterface は仮想関数テーブルの何番目に実行すべきメソッドが入っているかが 静的には決まらない。

interface Interface {
  public void method3();
  public void method2();
  public void method1();
}

class Implement2 implements Interface {
  public void method1() {}
  public void method2() {}
  public void method3() {}
}

class Implement3 implements Interface {
  public void method3() {}
  public void method2() {}
  public void method1() {}
}

Interface iref = (flag) ? (new Implement2()) : (new Implement3());

iref.method1();  // 仮想関数テーブルの何番目を使えばいいか静的決まらない。

そのため invokeinterface は 参照 iref の実体クラスが Interface インターフェイスを サポートしているかどうかをチェックし、 そんざいする場合はインターフェイスのメソッドから実体クラスのメソッドへの変換を毎回行う必要がある。

Implement2 クラスの仮想関数テーブル
indexMethod
0void method1()
1void method2()
2void method3()
Implement2 の Interface インターフェイス
インターフェイスの index Method 実体の index
0void method3()2
1void method2()1
2void method1()0
Implement3 クラスの仮想関数テーブル
indexMethod
0void method3()
1void method2()
2void method1()
Implement3 の Interface インターフェイス
インターフェイスの index Method 実体の index
0void method3()0
1void method2()1
2void method1()2

一つの実体クラスが N 種類のインターフェイスを持っている時、 インターフェイスの検索は最悪 O(N) となり、 馬鹿にならないコストになる。 普通の JavaVM ではインターフェイスをハッシュ値としたハッシュ検索や、 最近検索されたインターフェイスが再利用されるという時間局所性を利用したキャッシュ検索を用いて高速化しているが、 避けることができるなら invokeinterface よりも invokevirtual を使用した方が高速だ。

今日の買い物

DiMAGE Xi 用の SD Memory Card として 16MB (本体附属) と 64MB (お店でセット販売) を持っていたが、 64MB では 100 枚ぐらいしか撮りためないので 128MB の SD Memory Card を買い足す。


7/17 (土)

珊瑚礁と江の島

S.J. 氏に 湘南の有名なカレー屋 (?) レストラン珊瑚礁 に連れていってもらう。ちなみに本店の方。
珊瑚礁のカレーはブイヨンがきいて ビーフシチューのようなマイルドなカレーでうまーでした。

珊瑚礁:通り
ハワイ風の店先
珊瑚礁:オープンカフェ
オープンカフェ
珊瑚礁:入り口
入り口
珊瑚礁:駐車場
駐車場もアロハー
珊瑚礁:
地鶏カレー
珊瑚礁:
豚バラ三枚肉のカレー

ご飯を食べた後、 江の島観光 (参考:江の島マニアック)。
江の島には、 辺津宮・中津宮・奥津宮の三つのお社と、 弁財天を祭ってある岩屋が見所です。
小さい島ですが結構 奥行きがあり、 高低差があり運動不足の身には結構つらいです。
上りのみエスカレーター (有料) があります。

江の島:カーナビ
カーナビが捉えた
江の島
江の島:江之島名勝図
江之島名勝図
江の島:鳥居
鳥居をくぐると
江の島:仏像
真新しい仏像です
江の島:辺津宮
辺津宮
江の島:中津宮
中津宮
江の島:中津宮の解説
中津宮の解説
江の島:奥津宮の鳥居
奥津宮の鳥居
江の島:奥津宮
奥津宮
江の島:祠
龍の飾りのある祠です
中に宝箱がありそうです。
江の島:大展望台
大展望台(有料)です。
江の島:断崖絶壁
断崖絶壁
落ちたら死にます。

島の終端は海に面した岩場になっています。
ここに弁財天を祭ってある岩屋があるのですが、 有料なので臆して入りませんでした。
ここから船で帰ることもできますが、 やはり有料です。

江の島: 江の島: 江の島:
岩屋までの通路を
外から写したもの
江の島:
湘南の海岸が見えます
江の島:かき氷とラムネ
かき氷とラムネ
江の島:ねこ
江の島にはネコがたくさん。
みな寝ています。

最後に 江の島名物の「しらす丼」を食べて行く。
S.J.氏 おすすめ「生しらす丼」の店 「とびっちょ」 へ。

とびっちょ:看板
とびっちょ
とびっちょ:しらす丼
しらす丼
とびっちょ:生しらす丼
生しらす丼
ポン酢が合う。
コメントを書き込む
[SJ] 2004-07-20 11:26:06
ホント カレーうまかったっすねー。^^
僕が食べた方は「豚バラ三枚肉のカレー」だったと思います。
また行きましょう!

7/15 (木)

複数台の HDD の載せられる NAS が欲しい

PC パーツに興味がなくなってからずいぶん経つのだが、
挑戦者から発売予定の SOTO-HDZUE に ひさびさに食指を動かされる。

  • 3.5インチ HDD が 4台。
  • 接続は USB2、IEEE 1394a。

250 GB を 4 本積んで、1TB までいけそう。

本当は GbE の口を持って SMB か NFS をしゃべってくれる NAS 箱があるとベストなのだが、、、

追記:7/20

HDD が 4台入るリムーバブルケースは、 他にも グッドフェイス Quat というのがあった。
挑戦者の奴の中身はこれと同じかもしれん。


7/13 (火)

[Java][CPU] IA-64 は何だってこんなに IPC が低いんだ?

Itanium2 マシンに CPU のパフォーマンスモニタリングカウンタを利用する計測ツールをインストールしてもらったので、 JavaVM の性能測定を開始する。

IA-64 プラットフォームでは SUN の JavaVM よりも BEA の JavaVM の方が圧倒的に高速で、 その原因をずっと調べていたのだが (3/174/20)、 評価環境 (RedHat Enterprise Linux AS 3.0) では Intel VTune を動作させることができず足踏みをしていた。

インストールしてもらった計測ツールは ごにょごにょ だが、 ちゃんとデータは上がってくるようだ。
Sun Hotspot VM 1.4.2 と BEA JRockit 1.4.2 で SPECjbb2000 を動作させて IPC を計測すると、 Hotspot VM が 1.01 (0.67)、JRockit が 1.06 (0.86) なり (括弧内は NOP を除いた IPC)。
Itanium2 は 1サイクルに 6 命令発行できるはずでは。。。

[MyWeb] くっつきBBS

日記だけでなく、 各ページにも 「くっつきBBS」 を貼り付けてみた。

コメントを書き込む
[1] [ぶぅ] 2004-07-15 09:18:51
多分、スケジューラがダメなんでしょうね。JITの場合コンパイルにかけられる時間の制約が厳しいですから、スケジューリングの範囲を広げられないのかも。あるいはIntelのコンパイラ屋さんが手伝えば、もっと良くなるかな?
[2] [しゅどう] 2004-07-15 14:51:11
先日のJavaOneでJRockit Virtual Machineについての講演がありまして、スピーカ2人のうち1人がIntelの人でした。

The Performance Architecture of the BEA JRockit Virtual Machine for the JavaTM Platform
http://www.javaone04.com/catalog/catalog/sessionDetail.jsp?SESSION_ID=10273
[3] [しゅどう] 2004-07-15 15:01:13
JavaOneでのJRockit VMの発表スライドを、何枚かまとめてあります:

日記 6/30分
http://www.shudo.net/diary/2004jun.html#20040630

アプリに応じて適切なconfigを選ぶ。
configは20種類くらい用意してある。
という辺りが興味深かったです。
SPECjbb2000向けconfigが用意されてるのかもしれず。
[4] [ポセ] 2004-07-15 19:01:39
ちなみに、コンパイラはどれをご使用ですか?
IPCが1程度というのは、低すぎです。
[5] [ポセ] 2004-07-15 19:07:02
あと、パフォーマンスモニタカウントツール(pfmon)をお持ちでしたら、実行時間(Real time)と
BE_L1D_FPU_BUBBLE_L1D + BE_EXE_BUBBLE_ALLのイベントの値を取得して、教えてください。それと、CPUの周波数(1.5GHz?)ですね。
それで、少しは原因が特定できるかもしれません。
[6] [謎の管理人] 2004-07-15 19:35:07
> ぶぅさんへ
Hotspot VM の IA-64 スケジューラーがタコなのは確かです。
コンパイラは machine independent な部分が多くて、IA-64 向けの最適化はほとんどありません。
ただ Hotspot VM が駄目な理由は GC アルゴリズムとして Exact GC を選択した影響が出ているのではないかと考えています。Exact GC はコード中に GC safe point をぶちぶち挟み込むので、最適化の可能な範囲が局所化してしまいます。
あと、BEA JRockit に Intel の中の人も協力しているはずです。
[7] [管理人] 2004-07-15 19:40:25
> しゅどうさん
JavaOne2004 の発表者は Kumar Shiv 氏と Joakim Dahlstedt 氏ですね。IA-64 向け最適化について何か言っていましたか?
私は Kumar Shiv 氏が書いた ``Impact of JIT/JVM Optimizations on Java Application Performance\'\' という paper を持っているのですが、これは IA-32 向けの最適化の話しか載っていません。
IA-64 でもアーキテクチャーの概略は同じだとは思うのですが、、、
[8] [管理人] 2004-07-15 20:04:21
> ポセさん
初めまして。
この測定は JavaVM の動的コンパイラの性能評価をですので、静的コンパイラは使いません。計測環境は CPU は 2-way 1.3GHz。パフォーマンスカウンターを取得しているのは自家製のツールです。
(USER 側では) 単位 CPU サイクルに対して BE_L1D_FPU_BUBBLE_L1D・BE_EXE_BUBBLE(ALL)・合計のイベントが、Hotspot VM では5.23%, 34.7%, 40.0%、JRockit では 7.99%, 38.2%, 46.2% で発生しています。
[9] [しゅどう] 2004-07-20 11:52:19
IA-64固有の話はなかったです。
命令スケジューリングについての話は、一般論(例:Itaniumではとても重要)と、ごく簡単な概要だけでした:

Scheduling
- High level - code motion
- Focus: loops
- Before register allocation - 1st instruction scheduling phase
- Avoid false dependency artifacts
- Take advantage of many registers on Itanium
- After low-level optimizations - 2nd instruction scheduling phase
- Finalize the instruction order
[10] [ポセ] 2004-07-20 21:07:02
合計が40%程度ですか。。。。。
それほど、酷くメモリストールがおきているわけじゃないみたいですね。多いことは多いですが、通常のアプリケーションならこの程度は起こりえますので、問題ないレベルと言えます。
となると、他に問題があるのか。。。直接見ないと余計混乱させちゃいそうです。役立たずですみません。

7/12 (月)

Search エンジンの更新タイミングの謎

今年の 2月頃に URL をリネーム (/~nminoru/dairy//~nminoru/diary/) した。
現在、/robots.txt を以下の内容にしている。

User-agent: *
Disallow: /~nminoru/dairy/

そろそろ検索サイトから古い URL が除去されているかな?とチェックしてみる。
Google はすでに新しい Web ページを優先してヒットさせてくれているが、 MSN と Yahoo! Search は古い方が先に出てくる。

サーバーの referer ログを見る限り、 新しい URL は外のサイトからリンクされているのだが、 古い URL へのリンクをしているページは見当たらない。 MSN と Yahoo! Search のデーターベース更新のタイミングが まだ来ていない以外に なにか原因があるのかしらん。

P.S.

同僚の人が PowerBook を購入。職場に持ってきている。
隙を見つけて SPEC CPU2000 スコアを計測してみる予感。

お年玉付き年賀状

お年玉付き年賀状の引き換え期間は 7/20 (火) まで。
当選番号はこちら

追記:7/16

交換しました。


7/9 (金)

[Tips] Proftpd のバージョンアップで、ffftp が使用不能に

最近 Vine Linux の proftpd のバージョンが v1.2.10 に上がったが、 それ以来 Windows の ftp クライアント ffftp が正常に接続できなくなった。

原因は proftpd がセキュリティー上の理由で NLST コマンドのオプション指定を サポートしなくなったことにあるようだ。
ffftp 側で 「ホストの設定」の「LISTコマンドでファイル一覧を取得(L)」にチェックを入れると NLST コマンドの替わりに LIST コマンドを使うようになり接続可能になる。

今日のラー博

出張帰りにラー博に寄ると、 らーはく厨房がなくなっていた。


7/7 (水)

[Patent] Blade Server に関する基本特許

インターネット総研とトラストガードが ブレード・サーバーに関する基本特許を取得。
アメリカ、日本、台湾で成立し、 ヨーロッパでも申請済みのもよう。

日本での特許は特開2002-32153。 特許庁で PDF ファイルを落として眺めてみる (特許への直接リンクはできないようだ)。
2000年7月19日に出願、2002年1月31日に公開、 請求項目が11項目。

  • [請求項1〜3] 前面から差込可能なカートリッジ型サーバーユニット (つまりブレードサーバーユニットに関するもの)。
  • [請求項4] ブレードにヒートパイクを付けて冷却。
  • [請求項5] ブレードの前面に入出力用コネクタ、 冷却用の空気孔を設ける。
  • [請求項6〜11] ブレードを収めるサーバーユニット筐体の形状に関するもの (ブレード・筐体型のコネクタ、電源を筐体側に置きブレードに給電、集中冷却等)。

この特許に異議申し立てができないとすると、 回避するのはかなり困難そうなり。

[Trivia] 中国の漢字元素周期表

中国の元素周期表を発見。
日本では一部の元素には水素、炭素、窒素と漢字名をつけているが、 ほとんどはカタカタ表記。
一方、 中国はまじめに元素を翻訳しているようだが、 見たことのない漢字がわらわら。
これは元素用に新しく作った漢字ではないかしら?


7/6 (火)

[Food] インターン研修生の歓迎会

インターン研修生の歓迎会を武蔵中原駅ビルの「霧笛屋」で。

霧笛屋:舟盛
舟盛
霧笛屋:焼き鳥
焼き鳥
霧笛屋:ハスの唐揚
ハスの唐揚
霧笛屋:生春巻き
生春巻き
霧笛屋:
太巻き
(定期券と比較下さい)
霧笛屋:山芋巻き
山芋巻き
霧笛屋:玉子焼き
玉子焼き
霧笛屋:じゃがいも
じゃがいも
霧笛屋:てんぷら
てんぷら
霧笛屋:マンゴーのシャーベット
マンゴーのシャーベット
霧笛屋:アイスクリーム
アイスクリーム

7/5 (月)

スイス工科大学からインターン研修生の人がきたにょ

ドイツ語系スイス人。英語とフランス語がしゃべれる。

4月からの 3ヶ月の日本語研修を受けたそうなのだが、 すでに流暢に日本語を操る。
その上、日本にくる前 上海にいたそうで、中国語まで書けて読める。
なんと 「はさみ」「鋏」 と書けてしまう。

エーリッヒ・フォン・デニケンの国の人おそるべし。

グリコの地域限定お菓子

5/266/16 に続き、 グリコの地域限定お菓子の第三弾。

ポッキー:北海道地区限定
(北海道)
夕張メロン ポッキー

7/4 (日)

Amazon アソシエイトプログラムに参加

Amazon アソシエイトプログラム に参加。
自分の Web ページに DVD のカバーイラストを参照したかったのだが、 オンラインショップのイメージを勝手に使うことはできず沈思黙考していたが、 Amazon アソシエイトプログラムに参加すると カタログイメージを自分のサイトに置かさしてもらえるなり。

ファイティング・ニモ
DVD cover 7/2
ファイティング・ニモの DVD をゲット。
忙しいので当分見る時間なし。

のように紹介可能。


7/3 (土)

なんですか!この家は!!

今年、博士課程を卒業して頭が T から始まる企業に就職した niko 氏を大挙(15人?)して訪ねることになった。
氏は茨城の土浦に2階建の家(新築)を月9万円で借りている。 会社が家賃補助を 70% つけてくれるそうだ。
1階はリビングルーム & キッチン、風呂、トイレ別。 2階は2部屋、ベランダあり。 少しだが花壇とかもあり。
同僚の人には年1万円で畑を借りて、 野菜を育てたりする人もいるそうな。。。

6万7千円も家賃を払って、28平のアパートを借りている俺の立場がない。。。

niko氏宅
黄色い家です
niko氏宅
床下収納あり
niko氏宅
トイレは2階にもあります

niko氏の宅を訪問後、近くの竜ヶ崎森林公園で BBQ。

竜ヶ崎森林公園
不思議な家が建ち並びます。
竜ヶ崎森林公園
BBQ
竜ヶ崎森林公園
アスレッチク併営
コメントを書き込む
[本店] 2004-07-05 18:56:21
部屋の広さが尋常でないところみるとnikoくんって結婚するんですか?:-)
[管理人] 2004-07-07 03:08:39
かもしれませんよ v(^o^)v
でも9月頃に東京支社に転勤になるかもしれないそうです。
せっかくいい家を借りたのにもったいない。
[管理人] 2004-07-07 03:09:06
ちなみに家全体を掃除するのに2時間かかるそうです。

先月の日記(2004年06月) 今月の日記(2004年07月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2020 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2021 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2022 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2023 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2024 | 1 | 2 | 3
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | slideshare | github | Qiita


Written by NAKAMURA Minoru, Email: nminoru atmark nminoru dot jp, Twitter:@nminoru_jp