2003年12月の技術日記

X31のパフォーマンスを測定してみた。比較対照は DELL Inspiron8100。店頭で宣伝されている「Pentium M は、これまでの同クロック数の Pentium III,4 の1.5倍程度パフォーマンスがよい」(参考:Pentium-Mに続く90nmプロセスのモバイルプロセッサー“Dothan”が年内にも登場!! by ascii24.com)といううわさの確認。

スペック比較

CPUだけでなくメモリやバスも変わっているので、速度の結果がどこに由来するものかは難しい。

計算内容

MDや3DCGの幾何計算を意識してみて、主に3次元行列の計算をさせてみた。

3x3 Matrix

2つの3x3行列オブジェクトを用意して、400万回足し算をさせる。行列の実装として配列とフィールド値のものを比較。（一般的にフィールド実装のものが速いと言われている。）

200x200

200x200の行列を40回足し算させる。（4万個の倍精度実数の計算。単純に計算能力とメモリへのアクセスを見る）

3x3 Array

配列実装の行列の足し算の計算を40万回させる。計算の度にオブジェクトを使いまわす(Reuse)ものと、使い捨て(Creation)のものを比較。（一般的に使いまわす方が速いとされているが、最近のJVMは使い捨てをしてもそんなにパフォーマンスは悪くないので、無理をしてオブジェクトを使いまわしてわかりにくいプログラムを書かない方がよいと言われている）

3x3 Field

フィールド実装の行列の足し算の計算を40万回させる。計算の度にオブジェクトを使いまわす(Reuse)ものと、使い捨て(Creation)のものを比較。（大体上と一緒。ただし、メモリ確保のメインは配列ではなくて普通のオブジェクトなので、数値計算だけではなくて一般的なオブジェクトの再利用の効果を見ることが出来る。また、JVMのメモリ管理の速さなども影響する。）

ベンチ結果

結果は宣伝通りの性能を示した。

• PM(1.6G) / P3(1.1G) = 1.5〜3倍程度で、宣伝スペック通りと言える。
• 大きな配列やオブジェクト生成が絡むとX31の方が有利に見える。　→　1.5倍以上の速度向上の原因の多くはメモリに由来しているらしい。

その他の結果。

• 行列の計算は、配列の実装よりフィールド値による実装の方が圧倒的に速い。SUNのJVMでは20倍から30倍も速い。
• やっぱり大量に使いまわすオブジェクトは、新規に生成するより使いまわした方が速い。JVMにもよるが大体4倍〜5倍程度、最大20倍近くも差がある。
• SUNのWindows版JVMについては、１）配列の生成・操作は1.3.1が最も速い。２）単純なオブジェクト生成については1.4.2が速い。
• IBMのJVMはほとんどの項目についてSUNのJVMより高速。特に配列へのアクセスが2倍から5倍も速い。
• IBMのJVMはオブジェクトの生成が遅い。配列の生成はSUNのJVMと変わらないが、単純なオブジェクトではSUNのJVMより3倍近くも遅かった。

SUNのJVMはGCの動作を細かく設定できるので、それも含めてデータを取ればもう少し状況は変わるかもしれない。

結果一覧

配列とフィールド値の3x3の行列の速度比較

フィールド値の3x3行列のオブジェクト再利用と使い捨ての速度比較

配列の3x3行列のオブジェクト再利用と使い捨ての速度比較

X31を買って2週間後、当初の要望をほぼ完璧に満たすX40が発表された。とても痛い。

Opinion：仕事と家庭の「並列処理」は可能か (by ZDNet)

自分は整理が苦手なので、ほとんどの情報は電子的に保存して、しかも分類はなるべくせずに情報の引き出しはもっぱら検索に頼っている。
同様に、手帳も学部のときから電子手帳を使い続けて、現在はPDA（Sony Clie T600C）での生活。

読みたい情報をClieに移して、電車や移動中に読む。電車の中でメールを読み書き。ここの日記も、移動中にClieのメモ帳でほとんど書いている。さらに、起きた直後やることはコーヒーを入れながらメールの確認であり、眠くなって作業続行不可能まで手はキーボードの上で動いている。

そんな時、思うのはプライベートと仕事の境界が無くなっている事と、電子機器がすでに体の一部になっていること。家でもどこでも作業を行い、他人とのコミュニケーションの一部ははメール、日常の思考や記憶もPCやClieが支援している。こういう傾向は多分良くないのだと思う一方で、もっと効率的な man machine interface が出来ないかなとも思ってみたり。

普通だと、「fori」は、

for (int  = 0; < ; ++) {
 
}

になるが、これではぜんぜんうれしくない。マニュアルを見ると、「tempo-interactive を non-nil にしろ」と書いてあった。言うとおりにすると、「fori」の後に、変数名と上限を聞いてくるようになる。めでたく以下のように補完されるようになる。

for (int i = 0; i < 10 ; i++) {
 
}

最近知り合いが、職場の問題からうつになってしまった。病気とまではいかないまでも、楽しくない職場で辛い日々を送っている人は多い。そのほとんどの人達は、その仕事は好きだけれども、職場の人間関係が最悪だという。

ケーススタディ1：暴走上司

• 強力な政治力を持つ上司B氏。
• プロジェクトの度に、他所のプロジェクトから優秀な人材を勝手に引き抜く。
• 他のプロジェクトの都合など全く考えていない模様。
• 他のプロジェクトの構成員全員を自分のプロジェクトの指揮下に入れてしまうことも躊躇しない。
• しかし、例によってB氏のプロジェクト管理能力は低い。
• 集めた人材相応のパフォーマンスが発揮出きない。
• 集められた人達には、B氏に発言したりみんなで建設的な議論をする権限はない。
• 一方、もともと人数がぎりぎりの職場なので、引き抜かれたプロジェクトのパフォーマンスは激しく低下。
• 引き抜かれたとはいえ、プロジェクト失敗は許されないので、残りの人達や重複した人達は頑張るしかない。
• 他のプロジェクトのパフォーマンスが落ちることによって、相対的にB氏の評価が上がり、ますます自分が有能で組織にとって必要不可欠であると思い込み、自らの行動に自信を持つ。
• B氏は自分以外のプロジェクトにダメ出しをするが、引き抜いたことが原因だと思ってない。むしろもっと働けという。。
• B氏の上司には部下の管理能力が欠落しているため、Ｂ氏を指導することが出来ず、状況の改善は見込まれない。
• デスマーチ突入。

ケーススタディ2：ターミネーター

• C氏は入社10年以上のベテラン。
• 何らかの理由で上司からの嫌がらせが始まる。
  →例：育児休暇、C氏の態度、意見の不一致、リストラ退職など。
• 普段の言動、一挙手一投足、全ての書類に至るまでダメ出しが入る。
• C氏だけ会議や飲み会に呼ばれない。
• 上司は立ち場を利用してC氏の不利な状況を作る。
• 新入社員は、自分達も二の舞になることを避けるために上司に加担してしまう。
• 上司の介入があるため、組織の中で相談できる人がいない。
• 公的機関や法的手段に訴えても「そんなつもりはなかった」などの体のいい言い訳で簡単に逃げられ、報復でますます状況が悪化する。
• 生活がかかっている場合は、簡単に再就職できるわけもく、逃げることも出来ない。
• 結局、うつやパニック症になって人生を棒に振ったり、周辺の人々も辛くなる。

人付き合い

人付き合いは難しい。絶対という解決策や処方箋は無く、むしろ相性や才能が大きなウエイトを占める。

また、どこにでも非常識を振りまいて周囲を困らせる迷惑な人はいるものである。（：例 困ったちゃん、教えて君など）

そのため、トラブルに巻き込まれないための防衛手段として、最低限の処世術は身につけておくことが必要である。多分、「社会人のマナー」がその最低限の防衛的処世術に当たるのだと思う。

しかし、これで片づくような場面や職種はやっぱり少ない。競争や議論が出来ず、効率化の努力が出来ないような職場しか有効でないように思う。

マインドを高める

「無能な部下など一人もいない。いるのはいつも無能な上官だけだ。」と誰だったか忘れたがそういう言葉を見たときに非常に感動した覚えがある。

つまり、いつでも問題を引き起こすのは責任者であり、部下のせいにするのは無責任である。出来るできないも含めて管理するのが責任者のつとめであるということであろう。

その責任者がどうがんばってもできないと判断したのなら、出来ないとはっきり上や相手に言うべきである。結果として、プロジェクトは中止や延期になり、状況が改善されるかもしれない。あるいは役職をはずされるかもしれない。さらにもしかしたら、代わりの責任者がうまくやるかもしれない。それは、代わりの管理人の能力が優れていたか、殺人的フル稼働でがんばった結果であろう。

いずれにしろ、早めに失敗に気づけば本当に失敗するよりダメージは少ない。早くだめだと分かれば、それに対する対策も取りやすい。組織がそのような意見に敏感な場合は、すばやく対策を行って成功に導くことが出来る。

逆に、政治力で意見を封じ込めたり、意見を挑戦だと勘違いされてしまうような職場環境では、ミスや都合の悪い情報が隠される。その結果、間違った認識から判断を誤る。全体がそのような雰囲気の場合は、取り返しのつかない状況に発展するまで異常事態として認識されない。このような例は銀行、ＪＲ、医療事故など枚挙に暇がない。

参考：

「不確実性のマネジメント―危機を事前に防ぐマインドとシステムを構築する」 カール・E. ワイク (著), キャスリーン・M. サトクリフ (著), Karl E. Weick (原著), Kathleen M. Sutcliffe (原著), 西村 行功
サイズ: 19 x 13cm 発行: 2002/07 価格:
ISBN4-47-837403-1
『不測の事態にいかに対応するか。これは今日すべての企業に突きつけられた課題。原子力発電所や航空管制システムなどハイリスクな環境に身を置く組織を分析し、不確実性に対応できる組織マネジメントを紹介する。』

上のケースに見られるような上司に当たった場合は、職場の上から下まで終了している可能性が高いので、ほとんど状況を改善できる可能性が無いと思われる。なので選択肢は以下のよう。

• 責任を押しつけられないように注意しつつ、うまくおだててやり過ごし続ける
• さっさと職場を変えてしまう
• でもがんばって戦う

なんだかなぁ。

jpg,gif,pngを読むだけなら、java.awt.Toolkit.createImage で簡単に読める。保存も非公開APIを使えば一応出来るが、非公開なので将来への不安があるのと、精度のパラメーターが低めなので保存された画像は結構汚くなるので使いづらい。
また、ファイル形式についてもBMPぐらいなら自分で実装できるが、TIFFは仕様がぐちゃぐちゃなので大変。そんな時は画像系のライブラリを使うと良いみたい。

参考：J2SE v1.4の新機能：Image I/O、Java Image I/O(java.sun.com)、イメージ読み書きメモ

サンプルを適当にいじってみる。

JAIを使ってJPEGを読んで、精度を変えて保存してみる。JAIは大抵の画像フォーマットに対応しているので非常に便利。また、ライブラリの守備範囲が非常に広くて奥が深い。

import java.awt.image.*;
import java.awt.image.renderable.ParameterBlock;
import java.io.*;
import javax.media.jai.*;
import com.sun.media.jai.codec.*;
 
class JpegSaveTest {
 
    public static void main(String[] args) {
        PlanarImage dst1 = loadImage(args[0]);
        JPEGEncodeParam encodeParam = new JPEGEncodeParam();
        encodeParam.setQuality(0.1F);
        encodeImage(dst1, encodeParam, createOutputStream("a.jpg"));
        encodeParam.setQuality(0.5F);
        encodeImage(dst1, encodeParam, createOutputStream("b.jpg"));
        encodeParam.setQuality(0.95F);
        encodeImage(dst1, encodeParam, createOutputStream("c.jpg"));
    }
 
    private static FileOutputStream createOutputStream(String outFile) {
        FileOutputStream out = null;
        try {
            out = new FileOutputStream(outFile);
        } catch(IOException e) {
            System.out.println("IOException.");
            System.exit(1);
        }
        return out;
    }
 
    private static void encodeImage(PlanarImage img, JPEGEncodeParam param,FileOutputStream out) {
        ImageEncoder encoder = ImageCodec.createImageEncoder("JPEG", out,param);
        try {
            encoder.encode(img);
            out.close();
        } catch (IOException e) {
            System.out.println("IOException at encoding..");
            System.exit(1);
        }
    }
 
    private static PlanarImage loadImage(String imageName) {
        ParameterBlock pb = (new ParameterBlock()).add(imageName);
        PlanarImage src = JAI.create("fileload", pb);
        if (src == null) {
            System.out.println("Error in loading image " + imageName);
            System.exit(1);
        }
        return src;
    }
}

ImageIOを使って、JPEGの精度を指定して保存する。こちらはJ2SE1.4以上なら標準で入っているので面倒が少ない。ただし、標準では対応ファイルフォーマットが少ない。

import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;
import java.util.Iterator;
import javax.imageio.*;
import javax.imageio.stream.*;
import javax.imageio.plugins.jpeg.*;
 
class JpegSaveTest2 {
    public static void main(String[] args) throws IOException {
        IIOImage image = new IIOImage(ImageIO.read(new File(args[0])),null,null);
 
        Iterator writers = ImageIO.getImageWritersByFormatName("jpeg");
        ImageWriter writer = (ImageWriter)writers.next();
        File f = new File("aa.jpg");
        ImageOutputStream ios = ImageIO.createImageOutputStream(f);
        writer.setOutput(ios);
    
        ImageWriteParam param = new JPEGImageWriteParam(null);
        param.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
        param.setCompressionQuality(0.9f);
        writer.write(null,image,param);
    }
}

学習型SPAMフィルターがあると、SPAMがやってくるのが楽しみになる。
今日の見逃しSPAM。（xは一応伏字）

Received: from [211.131.156.xx] (HELO 203.141.35.113) by (うちのメールサーバ)...
Received: from [127.0.0.1] by MS34
  (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Wed, 24 Dec 2003 15:51:47 
Subject: 人道復興支援について。。。
From: jun.-1982.xxxx@ezweb.ne.jp
X-Mailer: Mail Distributer
Reply-To: jun.-1982.xxxx@ezweb.ne.jp
Message-ID: 
Date: Wed, 24 Dec 2003 15:51:47 
  
どう思う？語り合わない？お布団の中とかお風呂とかでさ(#^.^#)

短い日本語は見逃される傾向にあるようだ。

しかし、内容がまれに見る傑作だ。意味が分からないところが新しい。目的はFromに返信させることか。Googleで探すと各地に出没しているらしい。

ヘッダのMessageIDやReceivedの 203.141.35.113 は yahoo.co.jp のものなのだが、ODNのアクセスポイントからの偽装。ArGoSoftのWindowsで動くフリーのメールサーバらしいが、最新版は1.8.4.7で、ChangeLogを見るとSec〜Fi〜 Crus〜 serv〜ので、〜すれば〜したりできそう。Mail Distributer はフリーの同報メール発信ソフト。技術的に幼稚なのか、それともこれでも先端を行っているのか。

最近の枝が付くことを恐れない無神経なSPAMは、直接配送相手のSMTPサーバに送りつけるので、中継が出来るサーバを無くせば大丈夫だというわけでもないらしい。

2003年末、IT戦士志願者の主張（全文）を読みながら、日経新聞に就職した先輩や、MSXFANのバボを思い出した。

先輩は文系出身で文化部を希望していたのに、兜町に派遣されたりして苦労したといっていた。あるときには洗濯できるスーツを特集するために徹夜で何枚ものスーツを洗ったとか。記事を読んだけども、それ（日経）っぽい力強い文章だった。見た目や性格も力強い人だったので、きっと文化部ではなくて兜町の方に回されたのかもしれない。

その昔、MSXFANというかなりいけていた雑誌があった。バボはその雑誌の読者の欄の担当者。今でも多くの人の心をつかんで放さないほどの印象的な文章を書いていた。当時、小中学生だった自分も大きな衝撃を受けて、バボの文章の書き方を研究したほどである。その時の「暮らしの適当手帳」は今でも大切にとってある。探してみると、スキャンをこっそり公開しているところがあった。

いつもは反MSの痛い文章を並べるだけであまり内容の無い「ゲイツ君」だけども、今回の教えることはかなり良い。今回も一応反MSではあるけども、今回の矛先は、IT教育と称して、子どもにMS製品の使い方を教えようという日本の教育現場に対して。しかし、こんなことになってしまったのは、専門外のことは分からないということと、余裕が無くてそんなに難しいことは出来ないということが原因であろう。最近は、学校の先生に何でもかんでも押し付けすぎだと思う。

先日、専門学校でJavaを教えている人とお話をする機会があった。その人の教え方は自分にとってかなり衝撃の内容であった。

開発環境

• NetBeansを使う（インストールが一発）
• JDKやEclipseは導入から難しいのでNG
• 最初はGUIプログラムからはじめる（コンソールやServletで始めるなどもってのほか）
• ボタンを押すと何かするプログラム
• 難しいことは抜きにとりあえず動かす
• 一通り出来たところで、JDKや裏でやっていることをちょっと説明

オブジェクト指向

• 「オブジェクト指向」という言葉はほとんど最後まで使わない
• クラスはCanvasの継承から入る（結構初めの方で）
• 誰が何時paintを呼ぶのかは教えない（意味がない）
• 後で、普通に型の拡張という考えからクラス・継承を教える

JDBC

• まずACCESSを使う
• まず、自分でテーブルの実態を触って見なければ分からない
• 触ろうとしているテーブルの実態がつかめれば、JDBCは難しくない

とにかく

• 徹底的にJava言語のみに集中する
• 本質的なこと以外で難しく感じたり、やる気をそぐのは良くない
• とりあえず、目の前で動かさせる
• 独習Javaなどを始めとする多くの入門書はこの観点からはNG

ということで、この方法に合った本を出す予定らしい。

「昔、自分がWindowsで始めてプログラムをしたのがDelphiで、ボタンを押して何かをするプログラムだったのだけど、すぐ動く割にぜんぜん納得がいかなかった記憶がある」と言うと、「そんな人は放っといても出来るようになる」と。そう言われてみれば、これはこれでいいのかもしれない。

店頭に並べてあったので触ってみた。キーが軽くて非常によいと思った。薄さ軽さも非常に良い。これだけでちょっと欲しくなった。

トラックポイントが使いにくい気がした。X31のものに慣れているせいかもしれない。また、キーボード奥のCPUが入っているところがかなり熱かった。どこも満遍なく熱くなっていたので、放熱の効果は高いのかもしれないが、夏の暑いときの動作が不安かも。

ただ、やっぱり30万円超えてしまうのはちょっと買いづらい。

非ユークリッド幾何学の歴史とソフトウェア工学の進化（前）（後）
ソフトウエアは未だ「工学」からは程遠いが、UMLがそれに近いかもという話。

個人的に思うのは、誰が良い設計が出来るかの評価。ソフトウエアの成果物は橋やビルのように見て分からないので、継ぎはぎだらけだったり、貧弱な構造やアルゴリズムを使っていてもとりあえず動けばOKになってしまう。プログラムが言語ではなくて、美しい図であれば、少なくとも言語よりは良い悪いの判断が付きやすいのではないかなと思う。ということで、図であるUMLが候補ではあるけども、もっと美しい図になるような言語が必要であると思う。

「今日カレー食べた」でもアリ論
未だに「blog（Web日記）はどうあるべきか」という論争が起きているらしい。良識や社会のルールに従って書いていれば、何をどう日記に書いてもよいと思う。ただし、公開している以上、どこからリンクを張られてどう批判されるか分からないという覚悟はしておくべきであるとは思う。とはいえ、一応の覚悟があっても2chからリンクが張られるとどきどきしてしまう。