NAKAMURA Minoru の日記 (2004年4月)

先月の日記(2004年03月) 今月の日記(2004年04月)
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 | 4
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | slideshare | github | Qiita



4/30 (金)

世間では GW らしいが今日も元気に出勤だ

昨日買った本を徹夜で読んでいたので眠い。 午前中はほとんど思考力が働かない。

Eclipse v2.1.2 で複数ファイルに対して同時に修正を掛けるような機能を作った場合に、全部ファイルを元に戻すアンドゥ機能を実装するにはどうすればいいか考える。 アンドゥ機能を拡張するには IUndoManager を実装すればよさそうだが、これは 1個のファイルを情報しか保存できるインターフェイスになっていない。 複数ファイルのアンドゥは要求仕様の中にあるけど、さてどうしたものかしら…

[MyWeb] Web に載せようと…

IBM VM の Garbage Collection (GC) の解説を細々と書いていたのだが、どうも細かい話に偏り過ぎて自分の備忘録にしかなっていない。 ランタイム固有の事情を説明しないと GC の説明ってやり辛いし、ランタイムの構成方法は言語の事情によってがかなり変わってくるため難しい。
思うに Java VM そのもの説明が必要なのだが、日本語だとあまりうまいページがないようだ(英語でも少ないけど)。
で、一念発起して「Java VM の作り方」のページを書いてみようと思い立ち章立てを考えたりしている。 でも、読みたい人っているのかしら?
# でも Boehm-GC のページも Acrobat プラグインのページも作りかけてほったらかしなのよね (^_^;


4/29 (木)

今日は仕事はお休みに

午後5時頃にのそのそ起き出して、ゴールデン・ウィーク中に読む本を買いに神保町まで出る。
探していたのは「社会生物学の勝利」「経済学という教養」なのだが、三省堂には「社会生物学の勝利」は在庫切れ。 「経済学という教養」は見つかったので、他 3 冊と合わせて買ってきた。

「世界を不幸にしたグローバリズムの正体」は、世界銀行の上級副総裁兼チーフエコノミストだったスティグリッツが世銀を止めた (止めさせられた?) 後どういう気勢を揚げているのかが気になって手にとる。 やっぱりアジア通貨危機に対して IMF は惨いことをやっていたのね…

下 2 冊は平積みになっていたので思わず手にとってしまった本。
特にイグ・ノーベル賞のほうは三省堂が売り込みを掛けていて、平積みの山をクラスターにしていたなり。

P.S.

スティーブス・キングの「ドリーム・キャッチャー」を読んで以来、なんとなくオナラが止まらない。
「イグ・ノーベル賞」に出てくるUnder-Ease が必要かしら?
いや、本当にエイリアンに寄生されているのなら Under-Ease よりもドリーム・キャッチャーが必要なんだけど…

住吉家@元住吉 (ぐるなびラーメン)

元住吉駅から綱島街道沿いまで足を伸ばして住吉家へ。 ねぎラーメンを食べる。

住吉家・ねぎラーメン
ねぎラーメン

4/28 (水)

[MyWeb] 日記のデザインを微妙に変えてみる

この日記ページの CSS を修正。
見栄えを少しだけよくしてみる。

  • 見出しが <h1> → <h2> → <h3> の順に出てくるように変更
  • <dt> を CSS で修飾
  • 各所のマージンの広めに
  • <tt> 内の文字サイズを 1em に (デフォルトだと Netscape Navigator でノーマルよりも小さく見える)

こんなものかしら?


4/27 (火)

[Compiler] コンパイラに関する雑記

マイクロプロセッサーに新しい話題が多いせいか、コンパイラのネタも増えているなり。

AMD64 (IA-32e) 用の Microsoft の開発環境は IL32P64

22日に開かれた AMD & Microsoft Software Developer Conference のレポートがぼちぼち上がってきてるが、MYCOM PC WEB の大塚実氏の記事によると AMD64 用の Platform SDK に入っている C/C++ コンパイラは int/long 型が 32 ビット、ポインタ型が 64 ビットの IL32P64 (LLP64) らしい。 AMD64 用の Windows XP、Windows Server、Platform SDK はダウンロードしたけど、インストールするマシンがないからほっぽいといたので知らんかった。

64ビット UNIX 系 OS では、int 型 32ビットで long 型とポインタ型が 64 ビットの (I32)LP64 が普通なので、LLP64 には結構 違和感がある。
(けど、良く調べれば DEC-Alpha21x64 でも IA-64 でも LLP64 だったんだなぁ。)

Visual C++ 2005 には Profile-Guided Optimization が入るらしい

MSDN Library の Profile-Guided Optimization with Microsoft Visual C++ 2005 という記事には、VC もプロファイル結果を用いたフィードバック最適化を導入するという記事がある。 MS は Profile-Guilded OptimizationPGO と呼ばせたいようだ。 Link-Time Code Generation (LTCG) もやる (すでにある?)。

ただ 一番興味深いのは記事の中腹の Figure 7.
このグラフは Intel Itanium2 (IA-64)、AMD AMD64、Intel x86 の 3 つのアーキテクチャーで最適化をやった場合とやらない場合で計測して、どのぐらい性能に差があるかというデータ。 ベンチマークは SPEC CPU (95? or 2000?) で、AMD64 では int、fp 共に 10% 程度、Itanium2 では int で 15%、fp で 6% 程度の性能アップという結果になっている。
こっちで測った時に SPECint2000 で 12% 程度の速度アップだったので妥当かしら?

Intel C++ Compiler v8.0 がバグフィックスのアップデート

待望の ICC v8.0 の Windows/Linux 版の両方がアップデート。
Windows 版は IA-32 が Build 20040415、Itanium が Build 20040417 に、Linux 版は IA-32 が Build 20040412Z、Itanium2 が Build 20040416 (Package ID: l_cc_pc_8.0.066) にアップデートされる。

さっそく Linux/Itanium2 版で某ソフトのビルドを開始するが、、、今日の内にはコンパイルが終わらねぇ。

追記:4/28
やはり 4/6 のコンパイラエラーは改善されず。
最適化オプションを落とした場合はこのバグは回避できるのだが、リンクエラーが発生してしまう。

覚え書き

家賃を払った。


4/26 (月)

武蔵中原駅周辺に初めてのまともなラーメン屋が

武蔵中原駅に新しいラーメン屋ができたので行ってみる。
店の名前は 「明日香」。 ラーメン、餃子、ライスだけ。
ラーメンもとんこつ醤油 1 種類、麺はやや太め (家系?)。

明日香 明日香
店構え 煮玉子のせラーメン

「味が薄いと感じる人は入れてくださいと」かえしが置いてあるが、それほど薄いとは感じない。 醤油ラーメンの店としては、武蔵中原で一番うまい(というか武蔵中原はラーメン屋が少なすぎ)。

P.S.

しかし日記を読み直してみるとラーメン食べた話ばかりが続くなぁ。

コメントを書き込む
[秘密のアッコ] 2004-07-17 11:45:14
明日香の秘密を教えましょう。
何を隠そうあそこは元クリーニング屋さんで、
今も店員は変わっておらず同じ家族経営です。
私も期待して1度行きましたが、そのときは慣れていないせいか、”熱いのできおつけて”といわれたラーメンのぬるさに驚きました。今は改善されたのでしょうか?
ぬるいラーメンを食べたのはこのときが生まれて初めてです。
[管理人] 2004-07-20 11:34:43
秘密のアッコさんはじめまして。情報ありがとうございます。
クリーニング屋が潰れて明日香ができたのは知っていましたが、
同じ人がやっていたとは、、、

その後、明日香には数回行きましたが、ぬるくはなかったですよ。
秘密のアッコさんの時はたまたまだったのだと思います。

4/25 (日)

幸楽苑@元住吉

昼前に起きる。
元住吉の幸楽苑へ行って昼飯に「ざるラーメン」を食べて会社に。

幸楽苑・ざるラーメン・全体
全体
幸楽苑・ざるラーメン・麺
幸楽苑・ざるラーメン・たれ
たれ

[Java][Work] Eclipse の JDT プラグインを書いて一日を過ごす

お昼からずっと Eclipse の JDT プラグインを作成。 Java ソースコードを読み込んで、DOM/AST パーサーで解析し、しかるべき最適化を行って元のソースコードに戻そうとしてるが、いろいろ問題がある。

  • Eclipse の提供しているクラスのほとんどが Comparator インターフェイスを実装してくれていない。
    そのままでは比較やマップへの挿入がし辛い。 しょうがないので ASTNode、AST などに Comarator インターフェイスなどを実装したラッパークラスを用意することに。
  • アンドゥ機能のうまく実現できない。
    1ファイルづつのアンドゥはうまく行くけど複数ファイルに跨るアンドゥがうまく行かない。 なぜだろう?

    追記:4/30
    というか Eclipse でも正常に実装されていなかった。
    例えば「リファクタリング」-「名前変更」機能はプロジェクト中の全ての Java ファイルが変更の対象となるが、リファクタリング実行後にアンドゥを押しても変更前の状態には戻らない。

Eclipse の API はまだまだ機能不足なものが多く、なおかつ似た機能が色々な方法で提供されるなど冗長なところが多いように思われるなり。

追記:4/26
結局、プラグインを作って徹夜なり。

[Java][Tips] Eclipse の改善

2/184/15 の日記に書いた Windows 版 Eclipse の不都合を回避する方法がようやく見つかった。 Windows 版では Eclipse のウィンドウの一部にフォーカスが入ると、Z オーダーが切り替わってメインウィンドウが浮き上がってくる。 しかし他のプラットフォーム (Linux-motif 版で確認) ではそういうことはないので、プラットフォーム固有の部分に問題があるのだろうと当たりを付けて修正を掛ける。
まだ一部に不都合はあるが、気持ち悪い挙動が要約軽減された。 とりあえずオープンソース万歳だ。

どうでも言い話

Yahoo! JAPAN のニュースを読んでいたら故郷山口の話が。

「ドラマシップ、鉄道記念館、海響館回ろう 回遊性向上へ特割チケット」
【山口】 関門地区を訪れる観光客の 回遊性向上 を狙い、北九州、下関の両市は今月から三観光スポット共通の特別割 引チケット「関門遊遊チケット」を販売している。

海響館(水族館)だけに回遊性ねぇ…


4/24 (土)

[Compiler][Bench] IA-32/Windows で GCC 3.3.1 の CINT2000 を測定

Cygwin のアップデートを行ってx86 で動作する C/C++ コンパイラ の ページにある「手持ちの処理系の比較」に gcc 3.3.1 を追加。

gcc 2.95.3-5 と比べると 252.eon でコンパイルエラーが出るようになってしまった。 GCC2系 → GCC3 系で C++ 周りが大きく変わったのに影響が出ている。 性能自体は 164.gzip、255.vortex で 1割 程度性能が向上しているが他は大差ないようだ。


4/22 (木)

わさびフレーバーのジェラード

三島駅の新幹線口にある立食のパーラービュッフェ にはジェラードを売っているのだが、最近 わさびフレーバーのジェラードが売られ始めたのを発見。 ぴりりとしたわさびの辛さは結構いける。

上の写真は写りが悪いが、一番 緑色に撮れたもの。
色の着いた壁をバックにして撮影したものは、補正が掛ってジェラートが真っ白になってしまう。 写真を撮るのは難しい。

という話を知り合いにすると、「普通のバニラジェラートと両方買って並べて撮ればいいじゃん」と言われてしまった。
確かに。

P.S.

三島駅から出るバスに揺られるている間にときどき「怪しい少年少女博物館」というえらく面妖な看板を見掛ける。
何なのか大変気になるなり。


4/20 (火)

[Java] Itanium2 での BEA JRockit 1.4.2 の速さを調査中

IA-64 プラットフォームでの BEA JRockit 1.4.2 (以降、JRockit) と Sun Hotspot VM 1.4.2 (以降、Hotspot VM) の性能差の原因を調査中。 現行、大概のアプリケーションで JRockit は Hotspot VM に 0.5 倍程度の差をつけて勝つ。 原因を調べるが今の所手がかりなし。

JRockit はインタプリタモードを持たない(文字通りの) Just-In-Time コンパイラらしい。 メソッドは実行前 (?) にセミコンパイルされて実行される。 実行回数が多いメソッドはより高度な最適化コンパイラによって最適化されるようだ。
JRockit は最適化を抑止する -Xnoopt というオプションがあり、このオプションを使うと後段の最適化コンパイルを止めることができる。

Hotspot VM は最初 インタプリタモードでメソッドを実行し、その後 メソッドが CompileThreshold という回数を越えて「実行される」と動的コンパイラのコンパイル対象となる (デフォルトでは 10,000)。
オプションとして -Xint を指定すればメソッドはコンパイルされず常にインタプリタモードで動き続ける。 -Xcomp を指定すればメソッドは常にコンパイルされる。 -XX:CompileThreshold=<n> を指定すれば、コンパイルが掛かるタイミングを調整することができる。

おおよそのところ性能は以下のようになっている。

(JRockit)
ノーオプション
(JRockit)
-Xnoopt
(Hotspot VM)
ノーオプション
(Hotspot VM)
-Xcomp
(Hotspot VM)
-Xint

これが意味するところは JRockit の通常の(最適化でない)コンパイラと Hotspot VM の最適化コンパイラが同じ程度の性能 ということではないかしら…

追記:4/25

コンパイラされたコードの長さに注目するとほとんどのメソッドでは JRockit の翻訳コードは Hotspot VM の翻訳コードよりもサイズが小さく 1/2 〜 1/4 ぐらいの大きさ。 ただし非常に実行頻度が高いと思われるメソッドでは逆に JRockit の翻訳コードの方がサイズが大きくなっていることがある。

考えるに一般に同じ量の Java バイトコードをコンパイルした結果は JRockit の方がコンパクトなサイズになるが、実行頻度の高い部分での inlining は JRockit の方が強力に行われるのではないであろうか?

開発環境のアップデートの案内

開発環境のアップデートの案内がずいぶんきている。

  • VMware 社 から VMware Workstation v4.5.1 の案内がくる。
    今回の版では VM が高速化、Preboot eXecution Environment (PXE) のサポート、RAW ディスクの導入が図られている。
    管理人としては PXE の対応は嬉しい。 恐ろしく面倒なネットブート環境の作成の試行錯誤が大幅に短縮できそうなり。 後は VMware が iSCSI に対応してくれるとまことに嬉しいなり。

  • Intel 社から XScale PXA2xx 用の開発ツールの案内がくる。
    VTune と Intel C++ Compiler 8.0 for Windows 用のデバッガ。 ICC & VTune 購入者は Premier Support からダウンロード可能のようだが、XScale の開発環境はないので使用は不能。

  • Microsoft 社から Microsoft Visual C++ Toolkit 2003 が公開されたようだ。 Visual C++ に入っていた素の C/C++ コンパイラ & リンク等が無料で配布されている。
    元々 Platform SDK には C/C++ コンパイラは入っているのだが、今回のは (いちおう) 最適化が可能な版。
    追記:4/26
    Visual Studio 6.0 の Service Pack6 が公開されている。

  • PathScale 社 から AMD64/Linux 用の C/C++/Fortran コンパイラ PathScale EKO Compiler Suite が購入可能になった。 30 日使える試用版もあり。
    ベータ機能だが IA-32 (x86) バイナリを生成することも可能らしい。

  • OpenBase 社 から OpenBase SQL 8.0.2 の案内がくる。
    OpenBase の開発は Mac OS X がメインだが、今回は Windows2000/2003/XP 版。

4/17 (土)

疲労困憊のため午後 3 時ぐらいまで寝て過ごす

ようやく起き上がってネットをしているうちに、HIGH TOONED SON OF A BITCH というページを発見。
ジャック・ケッチャムの「オフシーズン」が実話を元にしていた ことを知る。

事件は 1400 年代のスコットランドの南西部 Galloway の出来事だそうで、Sawney Beane (or Bean)と彼の妻がBallantrae に近い海岸沿いの洞窟に隠れ住み、近隣を通り掛る旅行者を襲って食糧にしていたという。 2人は 25 年に渡って子供を産み育てて食人一族は 48 人にまで膨れ上がっていたそうな。 結局、1435 年に食人一族は発見・逮捕されて、皆処刑されたそうな。 南無三。

小説「オフシーズン」の方は、舞台を現代のアメリカに移していますが、6人の男女がわずかな武器を所持するだけの所を Sawney Beane のような食人一族に襲われる (食われる) というアドベンチャーです。 マジでおすすめ。

追記:4/19

新横浜の 文教堂書店 で、ジャック・ケチャックを多数発見。
以下を購入。


4/16 (金)

Amazon の検索サービス

Amazon が独自の検索サービス A9.com のテスト運用を開始したので見に行く。

現在は A9.com は検索の元となるデータベースは Google から提供してもらっているようで、Web 検索の結果は Google とほとんど同じだ。 A9.com の売りとしては Web 検索に加えて Amazon.com で取り扱っている書籍の中身を検索できるらしい。 今のところ日本語の書籍の情報はない(?) ようだ。

あと、A9 は Amazon.com のアカウントでログインさせてから検索サービスを使うように Personalize する。 検索情報は履歴として保存されるので、そのうち検索語と結びついた「お奨め商品」を提示されるようになるんだろうなぁ。

[Compiler][Trivia] UNIX 開発者のバッグドア

ITmedia の 4/14 の記事 「UNIX開発者のバックドアを思い出せ」 の記事の中にある「Linux開発者が生まれる前に、ケン・トンプソン氏は既に“大勢の目”でソースコードを監視しても問題を防げないことを証明していた」という文言が何を指しているのか知らんかったので調べる。 どうもケン・トンプソンがチューリング賞を受賞した時の記念講 Reflections on Trusting Trust を指しているようだ。

ケン・トンプソンがやったのは login コマンドに対するクラックだが、手段としては C コンパイラを用いる。 C コンパイラのソースコードにクラックコードを追加して以下のような機能を持つ「汚染された C コンパイラ」のバイナリを作成する。 このコンパイラは以下のような特徴を持つことになる。

  1. login コマンドがコンパイルされる時に狙いをつけてトロイの木馬のコードを挿入する。
  2. 汚染された C コンパイラから感染部分を剥ぎ取られないように、自分自身が self-compile される際にクラックコードを再挿入する。
    誰かが C コンパイラのソースコードを見てクラックコードがあることを発見し、その部分を削除して「汚染された C コンパイラ」で self-compile を行ったとする。 ソースコード上からクラックコードが削除されていても、汚染された C コンパイラのバイナリはクラック機能にあたるコードを挿入してからコンパイルするので、出来上がったバイナリは「汚染された」ままである。

一旦 汚染された C コンパイラのバイナリが完成すればソースコード上のクラック部分は元に戻して、バイナリとソースを一緒に配布すれば OK だ。

確かにこの方法だとソースコードを見てもクラックコードを発見することはできない。
でもこの方法でトロイの木馬を広めようとすると、C コンパイラのバイナリのディストリビューターになる必要があるから、クラックが発見された時には足は付きやすいわな。

紀要がインターネットで読める

理系人間としては一生読むことはないと思っていた 研究紀要
国立情報学研究所 (NII) が運営する研究紀要ポータルでは、国内の研究機関 (主に大学) の研究紀要がアーカイブされていた! さっそくアクセスして見る。

研究紀要ポータルに登録されている紀要情報には、本文を PDF で公開してくれている所とインデックスだけのところの 2 種類がある。 インデックスだけのところが多いが、それでも紀要を発行している国内の全ての研究機関を網羅しているわけではないようだ。

で、今日初めて知って驚いたのだが理学・工学系の学部・学科も紀要を発行しているところがある。
ていうか、出身学部の発行する紀要もあるなり。 オラ 在学中 一度も読んだことなかっただよ。

[Tips] SSH を使う時には関連ディレクトリのパーミッションに気をつけよう

SSH では接続先ホストの ~/.ssh/authorized_keys に接続元ホストの公開鍵を登録するが、その際 ~/ は group、other から書き込み禁止、~/.ssh/ は group、other から実行・読み込み禁止になっていること。

[Work] 職場に新人が配属される

そんだけ。


4/15 (木)

[Java] Eclipse 問題少し進展

2月18日の日記 にも書いた Win32 版の eclipse (v2.1.2) で発生する不具合。
デフォルトの MS-Windows は、ウィンドウのどこか一部をクリックするとそのウィンドウが一番上に浮いて同時にアクティブになる。 だが Tweak UI を使うことで X Window System 風の X-Mouse モードに変更が可能だ。 マウスカーソルを入れたウィンドウがアクティブとなりフォーカスを得るが、ウィンドウの Z-Order はそのままだ。

しかし eclipse はこの X-Mouse モードに対応しておらず、別のウィンドウの重なって下に隠れている eclipse にマウスを合わせると eclipse がトップに出てくる症状に襲われている。 マウスカーソルを少し動かしただけでグニョーンと eclipse が浮き上がってしまい非常に不便だ。 この問題の解決方法をほうぼうの人に聞いたのだが、誰に聞いても分からない。 仕方がないので自分でソースコードを読んで見たところ一応、問題らしきところを発見。

ソースコード中の org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/Display.java のファイルで WM_ACTIVATEAPP メッセージをハンドリングしているのだが、その処理の中で eclipse を含むウィンドウを一番前に持ってくる処理が存在した。

  case OS.WM_ACTIVATEAPP:
    if (wParam != 0) {
      Shell shell = getModalShell ();
      if (shell != null) shell.bringToTop ();
    }
    break;

ここは shell.bringToTop (); ではなく、shell.setFocus (); にすべきような気がする。 明日 (以降) に実際にビルドして、直るかどうか確認してみよう。

追記:4/18

駄目だった。
shell.bringToTop() のような箇所がまだまだあるようだ。

追記:4/26

bringToTop 自体を無効化してしまったところ、マウスカーソルを合わせるだけで Z オーダーを入れ替えてしまうという問題は直った。 修正を行ったのは ECLIPSE_SRC/plugins/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/Decorations.java の中にある赤字の行。 ここをコメントアウトしただけ。 ant でビルドした後、ECLIPSE_SRC/plugins/org.eclipse.swt.win32/ws/ ディレクトリにある swt.jar ファイルを ECLIPSE/plugins/org.eclipse.swt.win32_2.1.2/ws/win32/ ディレクトリに移動して終わり。

本当にこんな荒っぽい修正で他に障害が出ないのかという疑問は残るが とりあえず使ってみよう。

void bringToTop () {
	/*
	* This code is intentionally commented.  On some platforms,
	* the ON_TOP style creates a shell that will stay on top
	* of every other shell on the desktop.  Using SetWindowPos ()
	* with HWND_TOP caused problems on Windows so this code is
	* commented out until this functionality is specified and
	* the problems are fixed.
	*/
// 	if ((style & SWT.ON_TOP) != 0) {
//		int flags = OS.SWP_NOSIZE | OS.SWP_NOMOVE | OS.SWP_NOACTIVATE; 
//		OS.SetWindowPos (handle, OS.HWND_TOP, 0, 0, 0, 0, flags);
//	} else {
//		OS.BringWindowToTop (handle);
//	}
}

ただ、完全に直ったわけではないようだ。
マウスカーソルをアウトライン・ビューに合わせると Eclipse 全体が浮かび上がってくるし、ウィンドウの枠の部分に合わせた時にもタイミングによっては浮かび上がってくることがある。

KILL BILL

KILL BILL Vol.1 の DVD を買う。


4/13 (火)

[Compiler][Linux] IA-64 版 RHEL 3.0 の GCC 3.2.3 はバグてるっぽい

RedHat Enterprise Linux v3.0 の IA-64版に入っている GCC 3.2.3 は setjmp/longjmp 周りでバグって入る可能性が高い。

巨大な C++ プログラムの中に以下のような sigsetjmp を使う箇所があるのだが、ここで呼び出される __sigsetjmp の中で SIGBUS エラーが発生している(引数のアライメントの条件は正しい)。

if (sigsetjmp(aClassInstance->_sigjmp_buf, 1) == 0) {

これを下のように書き換えると何故かエラーが発生しなくなった。

sigjmp_buf tmp_buf;
if (sigsetjmp(tmp_buf, 1) == 0) {
  aClassInstance->_sigjmp_buf[0] = tmp_buf[0];

摩訶不思議!?

P.S.

UNIX 系 OS で実行コンテキストの保存・復帰を行う API は3組ある。
1. はシグナルコンテキストを保存・復帰するという保証がないため、普通は 2. か 3. を使うべし。

  1. setjmp、longjmp
  2. sigsetjmp、siglongjmp
  3. getcontext、setcontext、(swapcontext、makecontext)

[Java] Java の (同期) ロックについて

Tiger (Java2 SE v1.5) の Concurrent Utilities (JSR-166) について S.J. 氏とのメールでやり取りした時の覚え書き。

java.util.concurrent.locks.ReentrantLock クラスや java.util.concurrent.Semaphore クラスは、ロックの fairness の選択が可能。 ロックの fairness は競合が発生した場合に、スレッドの待ち合わせをどのように行うかという点に関係する。

  • Fair なロックは、先にロックを試みたスレッドが後から来たスレッドよりも先にロック所有権を獲得できる順序を保護するロックポリシー。
  • Unfair なロックは後からロックを試みたスレッドが先に待っているスレッドを追い越してロック所有権を獲得できる順番抜かしを許すロックポリシー。

Unfair なポリシーがあるのは fair なポリシーなロックよりも高速に処理が可能だから。
その理由は以下のようなもの。

  • 現在の OS のコンテキストスイッチは 10 ナノ秒のオーダーで行われるのが主流である。 1GHz で IPC (Instruction Per Cycle) 1 のプロセッサーの場合、1回のコンテキストスイッチの間に 1,000 命令分以上 実行できる換算である(この仮定は現在のプロセッサとしてはかなり遅い方に入る)。
    一方、十分に設計された並列プログラムの場合、短いクリティカルセッションが多数できる。 そのため競合さえなければコンテキスト・スイッチ 1回の時間の間にほとんどのクリティカルセクションを楽に走り抜けることができる。

  • 次に実際に競合が発生した場合を考えてみる。 ロックを獲得できなかったスレッドはブロックされ待機状態 (asleep) に居るが、その後 ロックの所有者のスレッドがロックを解放した場合ロックの所有権が空くことになる。
    Fair なロックの場合は次に待っているスレッドにロックの所有権を渡してしまうが、ロックの所有権を手に入れたスレッドは最低でも次のコンテキストスイッチまでは起き上がってこない。 この状態で後からこのクリティカルセクションに入ろうとしたスレッドがいると、今動作していないスレッドにロックを捉まれてブロックされることになる。 これはたいへん効率が悪い。

  • そのため unfair なロックの解放時には、待ちを行っているスレッドがいてもロックをフリーな状態のまま放置することにする。
    後からクリティカルセクションに入ろうとしたスレッドは待ちを行っているスレッドを尻目にロックの所有権を横取りできる。
    結局 これは 今動いているスレッドを優先する というポリシーである。 クリティカルセクションに入ろうとしたスレッドはプロセッサーの実行権を持っていて、ロックで待っているスレッドはプロセッサーの実行権を持っていないのであるから、今動いているスレッドにロックの所有権を与えても次のコンテキストスイッチまでにはクリティカルセッションを抜けているのである。

問題は、クリティカルセクションが上のような前提が成り立つほど小さくなくて、多数のスレッドから何度も何度も繰り返しロックされるような場合。 いったん競合が発生してしまうと、ホットに動いているスレッドだけがロックを獲得し続けて、競合のため待機状態になったスレッドは二度と起き上がれないということが発生する。

P.S.

よく考えてみると Java 言語に元々ある synchronized も言語仕様に fair か unfair かの規定はなく実際の JavaVM では unfair なポリシーを採用しているので、上のような問題が置きうる。

[Tips] HTML の <p> の使い方

今までずっと勘違いしていたのだが、<p> の中にはブロック要素は含めないそうだ。
ブロック要素は <ul> 〜 </ul> <block> 〜 </block> など(平たくいうと視覚的に)改行を挟み込むような HTML タグ。

<p>
このようなの使い方は誤りらしい。
  <!-- </p> -->
  <ul>
  </ul>
</p>

ブロック要素の先頭までに <p> が閉じない場合、</p> が省略されたとみなされるようだ。 上の例の場合は 赤字の位置に </p> が補われれ、青字の位置の </p> はイレギュラーになるようだ。

このような書き方をいろんな所でやっている。 暇な時に修正することにしよう。


4/12 (月)

[MyWeb][Prog] スタックオーバーフローハンドリングのページを作成

仕事が忙しくて書きかけの資料の断片ばかりが溜まってゆくが、何とか スタックオーバーフローハンドリング のページをまとめる。
舌足らずな文章だが、こんな危篤なテクニックは誰も使わないから適当でよいことにしよう。

グレッグ・パラストの「金で買えるアメリカ民主主義」を読了

グレッグ・パラスト著の「金で買えるアメリカ民主主義」を読了。 「入門経済学」の著者 J・E・スティグリッツは、世界銀行の上級副総裁兼チーフエコノミストだったけど、世銀の中で浮いていて結局 干されてしまったのね。 ためになるなぁ。


4/9 (金)

[Linux][Prog] 求ム! LinuxThread から NPTL へのマイグレーションマニュアル

RedHat が RedHat Linux9 (RHL9) や RedHat Enterprise Linux 3.0 (RHEL3) で入れてきた Native Posix Thread Library (NPTL) だが、これが原因で動かないプログラムが多発している。
それでも i386 アーキのプログラムの変換はそこそこうまく行っているのだが、ia64 アーキのプログラムエラは原因が掴めぬなり。
Migrating applications to the 2.6 kernel and NPTL というドキュメントには、LinuxThreads から NPTL への移植にあたり以下の点に留意せよと書いてある。

  1. getpid が全てのスレッド内で同じ値を返すようになった。
  2. setuid / setgid などがプロセス全体に有効になった。
  3. vfork を使用している場合、pthread_atfork に登録されているハンドラは実行されない。
  4. pthread_kill_other_threads_np など使えなくなった API がある。

その他、pthread_t は元々 unsigned long int 型だったので、LP64 環境では 64 ビットのデータ幅を持っている。 pthread_tint 型に代入している場合には注意が必要。

あと、IA-64/Linux は i386/linux のバイナリがそのまま動くわけだが、RedHat は互換性強化のために子プロセスから見た時の uname -m の見え方を変更する setarch コマンドを用意している。 i386/linux バイナリの中には実行すると OS をハングさせるプログラムも一部にあってsetarch でそれが救えるかもと思い使用してみる。

setarch <arch> <command>

マニュアルに従って <arch> の部分に i386 と記入するが、「そのアーキテクチャーは知りません」というようなメッセージが出るだけ。 なぜなのかしら〜。

追記:4/12

IA-64 の RHEL 3.0 では pthread_t は 64ビット符号無し整数型なのだが、LinuxThreads 互換で動かしている場合には 32 ビット長で収まる範囲の値しか取らないようだ。 一方、NPTL の場合は 2^32 ビットを越える数値を取っているため pthread_t 型を単純に int 型にキャストしている場合、LinuxThreads ではうまく動くのに NPTL では動かないという状況がある(あった)。

追記:4/14

LinuxThreads においてスレッドはメモリ空間を共有する別プロセスとして実装されていた。 そのためプロセス ID を返す API getpid はスレッド別に異なる値を返していた。
一方、NPTL は異なるスレッドであっても統一された PID を持つ。 LinuxThreads と同様にスレッドを識別してくれる PID が必要な場合には、 gettid API などを使う。

1. gettid API を呼ぶ
pid_t p1 = gettid(void);

2. gettid API への関数ポインタを動的に得て呼ぶ。
pid_t (*gettid_proc)(void);
gettid_proc = (pid_t (*)(void))dlsym(RTLD_DEFAULT, "gettid");
pid_t p3 = gettid_proc();

3. システムコール gettid を呼ぶ
pid_t p2 = (pid_t)syscall(SYS_gettid);

4/7 (水)

Google 以外の検索エンジンもチェックしよう

Google に対抗して Web 検索サイトエンジンの開発競争が進んでいる。
それに伴ってか色々な種類の crawler が動きまわっているようだ。

AlltheWeb
打倒 Google に燃える Overtune の検索サイト(だったが Yahoo に買収された)。
Google を真似たインターフェイスなので、Google からの乗り換えに違和感は少ない。
日本語ページはないが日本語ページを認識した検索は可能。 ただ、データーベースに入っている日本語ページの総量は少ないのか、同じキーワードを使うと Google よりも候補数が絞られる。
いくつか検索してみたが、検索ページのトップにくるサイトは Google と似ている。 順位付けは Google と同程度のようだ。 nminoru を引くと 一番上に載せてくるのは○。
ただ、リンクファームを回避する機能は Google よりも弱そうだ。

Crawler は FAST-WebCrawler を使って "FAST-WebCrawler/3.8 (crawler at trd dot overture dot com; http://www.alltheweb.com/help/webmaster/crawler)" のような User-Agent を残していたが、今は "Yahoo-MMCrawler/3.x (mm dash crawler at trd dot overture dot com)" のように変わったようだ。
vivisimo
ここも新興の検索サイト。
日本語ページはないが、日本語キーワードでの検索は可能。 ただし、日本語ページに対象を絞った検索等には対応していない。
vivisimo の特徴は Clustering Engine という機能。 普通のフラットリストの検索結果とは別に、検索結果を階層化して表示する Clustered Results を表示してくれる。
どのような Crawler を使っているのかはよくわからない。
MSN Search
説明不要。
Crawler は "msnbot/0.11 (+http://search.msn.com/msnbot.htm)" のような形式を取る。
Alexa Web Search
Amazon.com がやっている Crawler サービス。
表ページの検索は Powered by Google の模様だが、"ia_archiver" という User-Agent を動かしてネットから Web ページをかき集めているもよう。 かき集めたページは Internet Archive のページなどのサービスになっている。
Openfind
台湾にある中国語の検索サイト。 英語のページがあるのかないのか分からない…
Crawler は Openbot という独自開発 (?) で、"Openbot/3.0+(robot-response@openfind.com.tw;+http://www.openfind.com.tw/robot.html)" という形式。 結構、昔からアクセスがある老舗。
Gais
これも台湾にある中国語の検索サイト。詳細はよく分からない。
Crawler は "Gaisbot/3.0+(robot@gais.cs.ccu.edu.tw;+http://gais.cs.ccu.edu.tw/robot.php)" の形。

ユーザーが直接使えるわけではなさそうだが、以下のような会社の crawler も来ている。

FAST
ノルウェーにある企業向けに Web 検索サービスを提供する会社のようだ。
企業のイントラネット内にある Web ページをまとめて検索できるイントラネット用検索サーバーを構築するのが仕事のようだが、、、
以下のような User-Agent を持った crawler が活発に外交を進めている。 "FAST-WebCrawler/3.8 (atw-crawler at fast dot no; http://fast.no/support/crawler.asp)"
NameProtect
ここは検索サービスとは関係なく、企業の知的所有権が Web 上で侵害されているかどうかをチェックしてくれる会社のようだ。
Crawler は "NPBot (http://www.nameprotect.com/botinfo.html)" となる。
Turnitin
ここも知的所有権のチェックサービスを行っているようだ。
Crawler は "TurnitinBot/2.0 http://www.turnitin.com/robot/crawlerinfo.html" となる。
その他
その他にも研究目的、全文検索サイトの構築の準備、何のためかよく分からないが多数来ている。
  • Kototoi Project の Zao
  • 東大 喜連川研究室 の Steeler
  • アライド・ブレインズ Loki

P.S.

それはそれとして User-Agent を見ていると面白いものがある。

  • "Mozilla/4.0 (compatible; MSIE 6.0; BTRON; http://www.tron.org)" ... 超漢字からアクセスしてくれているかしら?
  • "MizukitanMizugi/2.0 (compatible; filmtnh; MS-DOS 5.0A-H)" ... 本当かよ?
  • "Family Computer (compatible; Family Basic V3)" ... もっとありえねぇ

創意工夫あるべし。

[Work] 被会社訪問

今日は W 大の教授が学生さんを連れてきたなり。

[時事] 地震

震度3の地震が来た。
このアパート激しく揺れるんだけど大丈夫かしらん。


4/6 (火)

[Compiler] Intel C/C++ Compiler 8.0 はやっぱり buggy。ゲロ吐きやがった。

Itanium2/RHEL AS3.0 上で Intel C/C++ Compiler 8.0 を使っているが、いろいろ問題が発覚。

まずこのプラットフォームの icc はインラインアセンブラが使えない。
IA-32/Linux 版は GCC と同形式のインラインアセンブラに対応しているのだが IA-64/Linux 版では未対応。 マニュアルを見る限り独自形式のインラインアセンブラもないようだ。 機械語がどうしても使いたければ組み込み関数かアセンブラを使えってことかよ。

あと複雑なソースをコンパイルしようとすると コンパイラがコアダンプする ことがある。
下が時のエラーメッセージで、コンパイラドライバ icc が内部で呼び出している mcpcom が core dump している。

icc: error: /opt/intel_cc_80/bin/mcpcom: core dumped
icc: error: Fatal error in /opt/intel_cc_80/bin/mcpcom, terminated by unknown signal(139)

強めの最適化オプション (-prof_gen/prof_use-ipo) を使うと間違ったオブジェクトを生成する例には何度か遭遇しているが、問題が出たのは最適化レベル -O3 程度。 商用コンパイラが勝手に落ちるなと言いたい。。

追記:4/7

mpcom は 400MB 以上もメモリを使用しているもよう。
この調子だと 4GB のメモリでは足らない。

[Work] 備忘

学生の会社見学がもう一丁ある。


4/5 (月)

[MyWeb] ホームページにカウンタを付けてみた

ホームページにアクセスカウンタを取り付けてみた。
とほほの WWWW 入門 にある取り付けたのは WwwCounter にある Perl スクリプトベースの CGI。
2000年3月7日より 2003年3月3日まで 53,540回アクセスがあったが、これを繰り込んで再カウントを始める。

ついでにこれまでシンボリックリンクで解決していた箇所を URL Rewriting で処理することにした。
http://www.nminoru.jp/~nminoru/dairy/http://www.nminoru.jp/~nminoru/diary/ へ転送され、「最新の日記」の日記も http://www.nminoru.jp/~nminoru/diary/current_month.html の URL から今月の日記分に転送される。

追記:4/6

WwwCounter は画像が表示される速度が遅いため WWW Homepage Access Counter and Clock (通称 wwwcount) に切り替えてみた。 速度的には不満はなし。

設定ファイル ($(Counter)/conf/count.cfg) の書き方のメモ。
wwwcount はアクセスをカウントしない (アクセスを無視する) ホストを IP で指定することができるが、以下の点には注意が必要かも。

  • 単一の IP ではなくサブネットを指定したい場合には、ネットワークの IP とサブネットマスクを空白で区切って1行づつ書く。
  • アクセス元の識別に REMOTE_ADDR よりも HTTP_X_FORWARDED_FOR が優先されるようだ。
    そのためイントラネットの内側からプロキシ経由でアクセスしている場合でも、プロキシが HTTP_X_FORWARDED_FOR に対応している場合にはイントラネットの内側のホストの IP で制限を掛ける必要がある。
[ignore IPs]
  10.20.230.0  255.255.255.0
  10.25.166.0  255.255.255.0
  133.11.94.252

上の例の場合、2行目は 10.20.230.0 - 10.20.230.255 を制限、3行目は 10.25.166.0 - 10.25.166.225 を制限、4行目は 133.11.94.252 を制限する。


4/4 (日)

[Work] 激烈に忙しい

ほにゃらら に GC アルゴリズムの移植を行っている。
1.X 系から 1.Y 系で card marking 周りの処理が随分変わっているのですんなりとは行かぬなり。
1.Y 系と 1.Z 系にはほとんど差はないのだが…


4/3 (土)

刀削麺荘@神田小川町

麺点師が削り出すかの刀削麺(ダオシャオミエン) をやっている「刀削麺荘」 というチェーン店があるらしい。 秋葉原に注文していた物品を引き取りに行くついでに小川町にある刀削麺荘に行ってみた。

とりあえず刀削麺のラーメン 「麻辣刀削麺」 を食べる。
麺が細いところと太いところが波打っていて、独特の食感がある。 ただ麺の味はうどんのようだ。
スープは唐辛子で赤いがそれほど辛くはない (四川料理的な酸っぱさもない)。

刀削麺荘・お店の前 刀削麺荘・垂れ幕 刀削麺荘・麻辣刀削麺
お店の前 垂れ幕 麻辣刀削麺

時間が無かったので「ラーメン」みたいなのを食べてすぐ出てしまったが、本当は西安料理全般のお店なので火鍋 (麻辣湯) やラム肉の排骨鍋 (醤油湯) などの鍋物がお勧めらしい。

あと麺を削るところを見ることができなかったのが残念。 時間が合えば削り出すところを見ることができるのだろうけど…

お買い物リスト

  • 月刊アスキー別冊 蘇るPC-9801伝説
  • 集英社文庫のジェイムズ・ジョイスの「ユリシーズ」の4巻
  • グレッグ・パラスト「金で買えるアメリカ民主主義」
  • Matrix Revolution
  • 君が望む永遠 DVD Vol.2

4/2 (金)

[Bench][Compiler] IA-64/Linux のコンパイラ性能差 (浮動小数編)

引き続きItanium2 1.3GHz / RHEL AS 3.0 上でコンパイラの性能を確かめる。
今度は CFP2000 の中で C 言語で書かれた 4 つのベンチマークをコンパイルして計測。 GCC 3.2.3 (build 20030502) と Intel C/C++ Compiler v8.0 (l_cc_pc_8.0.058_pl063.1) でいろいろオプションを変えた場合、結果は以下のようになった。

Compiler Options 177.mesa 179.art 183.equake 188.ammp
GCC -O3 -funroll-loop 574 1240 396 553
-O3 -funroll-loop -fmasth-fast 591 1190 399 571
ICC -O3 -ipo ONESTEP=no 839 (142%) 5518 (445%) 1867 (471%) 1024 (179%)
-O3 -ipo +FDO ONESTEP=no 1059 (179%) 5068 (409%) 2834 (715%) 1190 (208%)
-O3 -ipo ONESTEP=yes 837 (142%) 5662 (457%) 1867 (471%) 1025 (180%)
-O3 -ipo +FDO ONESTEP=yes 1056 (179%) 5623 (453%) 2816 (711%) 1186 (208%)

同じベンチマークの結果は縦方向に並べた。 +FDO はプロファイル結果を使ったフィードバック最適化、 ONESTEP=yes はファイル間解析を現わしてる。 括弧内の数字は GCC 側の中で一番いいスコアを 100% とした時の相対値。

GCC → ICC で向上率が小さいものでも 40% アップ。 いいものだと 7 倍以上の性能向上が得られている。
プロファイルを使ったフィードバック最適化もこちらは全てのベンチマークに渡って効果を出してる。
一方、ONESTEP=yes を選択してファイル間解析を行った効果は小さいようだ。 C 言語の浮動小数演算プログラムでは、効果のあるプロシージャー間最適化の範囲がファイル内に閉じる傾向があるのかも。


4/1 (木)

[Work] 就職活動ご苦労様にょ

工学系研究科の大学院生が会社見学に来たなり。
いろいろあるので詳細は記述不能。


先月の日記(2004年03月) 今月の日記(2004年04月)
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 | 4
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | slideshare | github | Qiita


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