コンパイル失敗。
-std=c99をつけてみたのだけど同じ結果だ。こんどは-pedanticも外してみよう。
ダメだ。-std=c99ではなくて-std=gnu99にしてみよう。
先に進んだけど dri_util.cで型の二重定義とか言われて終了。
とりあえず#if 0...#endifでシカト。
こんどはfbmmx.cで撃沈。
__builtin_ia32_por()などでエラーになっているのだけど、この関数がなんなのか解らなかったのでGoogleで検索してみたらパッチがヒット。ありがとう偉い人。
100円ショップで買ったLEDライトをつけられるように、東急ハンズでナスカンとリングを購入。
ナスカンにしておくとベルトループにくくりつけておくのが楽。
流石に100円という感じで仕上げとかは甘いけど、LR41を4つ使うだけあって割と明るい。手元を照らす分には困らないというか明るすぎるくらい。
さらに予備のLR41が入っているため、合計8つ。電池だけで100円するんじゃないかという勢い。
散髪屋の跡地に古本屋ができていた。せっかくだから覗いてみたら、噂の一年戦争が5,630円。高いなあ。
買い取り価格はいくらなんだろう。
radeon_chipset.hでstatic定義したSymTabRec REDEONChipsets[]が、後でextern宣言されていたためにエラー。
ビルド完了。長かった。
ドキドキしたけど、とりあえず起動した。速くなったかどうかは解らない。まあ、起動時の待ち時間のほとんどがデバイスからの完了待ちだろうから関係ないとも言える。
ファイルが元に戻されてしまったのでまた「ろ」が入力できなかったり。
sysctlでoopsを吐くようになった。
Xがコンパイルできた時点でgcc3.4.3を消してしまったのは失敗だったか。
/proc/sys/net/default/の下にアクセスすると死ぬようで、echoとかで書いてみるとbashも死ぬ。
って2.6.11.8のChangeLogではGCC4.0系でどーの、というのは見当たらないし、FIVAだけなんだろうか。
とりあえずrc.sysinitからsysctlの記述を消しておこうか。
って2.6.11.8のChangeLogにsyscallsで死ぬとか書いてる。でもUMLの話のようだし関係ないかなあ。
私と同じ現象を発見。私だけではないようなので一安心。
-O2を付けたときの最適化にバグがある模様。
最近気になることというか、それは違うのではないか、と思うことがあり実験することとした。
私自身は書かなきゃ書かないで良いではないか、と思っているものの平日はほぼ毎日更新していたような状態なので説得力に欠ける。というわけで、私自らが更新をやめてみた次第。
一カ月ほど更新を停止して、停止したことに対する反響はまったく無し。日記を更新しないことで被るペナルティは皆無であると言えよう。
にも関わらず、更新しないと行けないようなプレッシャーを感じる人が多いようだ。更新しないと読者が去っていく、ということを想像しているのだろう。去ったからどうだというのだ。無理に更新を継続することで、質が下がっては意味がない。たまに更新するけど面白いページと、5分に一回更新するけどどーでもいい内容のページ、どちらを読むだろうか。5分に一回はやりすぎだが。多少手抜きというかほどほどでよろしい。面白くなくて毎日更新と面白くなくて年に一度の更新であれば、結局面白くないのだ、無理に更新することはない。
mixi依存症と自称する人を取材した記事(http://www.itmedia.co.jp/news/articles/0408/31/news049.html)がITmediaに掲載されていたけども、このなかでも更新するとレスポンスがある、だから励みになるというような物らしい。そのうちに、レスポンスを期待感とでも勘違いするのだろう、更新しないと行けないような気分になるのかもしれない。
そんなことはまったくない。それは単に自意識過剰というものだ。読者というのは、面白いものがあれば、別になんでも良く、それが特定の日記や1コンテンツである必要はない。つまり代替が利くのだ。
だから面倒だと思ったら、疲れたと思ったら、更新するネタが無いと思ったら、更新しなくても善い。あなたは読者を必要としているかもしれないが読者はあなたを必要とはしていないのだから。それでも「いや、読者さんからのレスポンスが!」とか言うのなら止めないが、単に自意識過剰である可能性が高いということを繰り返し言っておきたい。
ちなみに、ReadMe!のカウンタでは220/日程度から100/日程度に下がっている。もともと平日の時のほうがカウンタが多く200前後、休日には下がり気味で180前後なので連休であることを考慮すると実はあんまり変わっていない可能性もある。一応平日に当たる5/2は137まで回復している。連休明けまで放置しておくべきかもしれない。
反響など無い、と書いたわけだけども、ありがたいことに再開後に反響を頂いた。
JR西日本の従業員が脱線した電車に乗客として乗っていたとのこと。事故発生後、会社つまりJR西日本なのだろうが、そちらに連絡したら「時間通りに出勤するように」と指示したということをマスコミが問題視している。
何が問題なのだろうか。極めて妥当な指示ではないのか。その従業員が出勤しないと、他の電車の運行に支障が出るだろう。出ないかもしれないが、それはその従業員のスケジュールを確認しないと判らない。おそらく、出勤されないと困るだろうから時間通りに出勤するように指示したのだと思う。
各マスコミは、従業員に救助活動を指示しなかったことを問題視しているようだ。しかし、出勤時間前なのだから会社から命令される筋合いは無い。雇用契約の範囲外の時間帯なのだから、雇用者側から時間外労働を命令することはいかがなものかと思う。だから、救助活動を指示しなかったということは別に問題とは思わない。仮に、救助活動を指示した場合、それは業務命令となるのか、その場合の給与はどうなるのか。その時に連絡を受けた上司にそのあたりを決定する権限があったのか。無かったとしたら指示を出せないのは当然だと思う。
従業員の方が自発的に救助活動を行わなかったのは、単にその従業員の人間性の問題だと思う。
やはり何事も実験。
日本でいちばん満員になる電車は、どうやら東急・田園都市線らしいということがわかりました。そこで、開発メンバーが、大阪から出張し、カバンの中にパソコンを入れて測定してみました。本体の表裏にセンサーやシートを貼り付けて荷重などを調べるんです。人間そのものにも同様のセンサーを取り付けました。
理屈だけではなくて、それを確認することがエンジニアリングの重要なポイントだと思う。
こうして目標、100kgの荷重に耐えるという、具体的な目標を設定してそれを実現していく。
さらに一工夫、のエコノミーモード。理屈は簡単で言われてみればなるほど、としか言いようが無いのだけども、充電容量ギリギリまで充電してしまうとバッテリを傷めるから80%充電で抑えておこうというもの。
まさに、基本性能としてバッテリでの運用時間が12時間とか8時間といった長時間を実現できているからこその荒技である。12時間持つのなら、その8掛けで9.6時間。それでも多くのモバイルパソコンのバッテリ運用時間を超えている。
目から鱗。確かに8時間程度持てばバッテリ稼働時間としては充分というか、余る。私自身、6時間程度持てば妥協できるので、ほとんどの人は納得できる稼働時間ではないだろうか。ここまで持つのなら、多少バッテリ稼働時間が持たなくても小型のバッテリで軽くしたいと考える人もいるだろう。
気になるのが、これが週間モバイル通信でもユビキタス情報局でもなく、Re:config.sysの記事だということだ。
せっかくだからgcc 4.1のsnapshotをビルド中。
5日の20時頃からコンパイルしているが一向に終わらない。そろそろ24時間。
cとc++だけコンパイルするつもりで../configure --enable-janguage=c,c++としたのだけど、正しくは../configure --enable-janguages=c,c++なので、cとc++に合わせてf95にjava、Objective-Cまでコンパイルされている。
つーかgcjのコンパイルがとても恐ろしい。メモリを11M以上使用したり、1ファイルに20分以上かかっていたり。
ついにPIDが一周した。というか寝ている間にもう一周位していたかもしれない。
swapは24Mくらいしか使ってないし、gcc 4.0の時と比べるとメモリはあまり使わなくなった模様。
とかいってたらまたPIDが一周した。すでに何周かしているのだろう。
カーネルがコンパイルできなかった。internal errorとか出てる。こう来るとは予想外だ。
GCCのアップデートには手を出さないでおこう。
ノートPCにはext3よりもReiserFSという話もあるし、再インストールしよう。
しまった、Fedora Core 1ではインストール時にReiserFSが選べないではないか。結局ext3か。
何かと噂のcoLinuxを入れてみた。MediaGX 200MHzのFIVAでいろいろコンパイルするよりは1GHzのVGN-T90でコンパイルした方が速そうだし。
が、ネットワーク周りがうまく行かない。外と通信できない。何を見落としているのだろう。
よく考えたら最初の/以外にももろもろのソースを入れるためのディスク領域が必要だしどうしたものか。メモリは128MBも割り当てるとかなりきつい。VGN-T90用の増設メモリは今どのくらいの価格だろうか。
とりあえずKDEだと起動してから操作可能になるまで待つのが苦痛なのでfluxboxをコンパイル…ってXFree86-develを入れ忘れたようだ。
/etc/yum.confを書き換えてrikenを指すようにしてyum。
そういえばemacs 21があるけど、これは動くのだろうか。cannaとかも使えるようならmuleをコンパイルしなくてもよさそうだけども。
yum updateしても-lX11でXOpenDisplay()とリンクできないとか抜かしやがる。吹っ飛ばす前はできていたのに。環境変数のINCLUDEとLIBに代わる設定ファイルがあったハズなんだけども手間隙掛けたくないので上書きインストールする。インストール中はまったりと大航海時代。これでダメだったら設定ファイルの名前を調べて設定し直せばいいだろう。
で、上書きインストールが終わったのでリブートしたらXが立ち上がらなくなった。さすがにこれは想定の範囲外だ。
途方に暮れたのでフォーマットして再インストールを指示し、寝る。
とりあえずコンパイル完了。
というかまだXが起動するか試していない。コンパイルできただけでも前進というか、configureがXlibを使用可能だと判断してくれただけでありがたい。
起動すると液晶が真っ白のまま停止。
そういえばまだXF86Configに手を入れてないな。入れなくてもちょっとは動いたハズだけども。
InquirerにSonomaデスクトップという見出しがあった。中は超低電圧Celeron 650MHzにi815Eを組み合わせたもの。Sonomaではない。というかPentium Mですらない。
と言うわけで再度挑戦。
結局どうにもこうにもうまく行かないと言うかpppの設定方法がまったく解らないのでredhat-config-networkのお世話になった。
しかしwvdial.confにパスワードが載るのが気に入らない。
結局pppについてはブラックボックスのままになってしまった。
とりあえず、FIVAにもOperaをインストールする。
すっとばす前はFirefox 1.03を試していたけどもOperaのほうが軽く感じる。
普通にダウンロードしようとするとopera-8.0-20050415.5-shared-qt.i386-en.rpmを取得しようとするのだけどもftpで接続してディレクトリ一覧を取得するとopera-8.0-20050415.6-shared-qt.i386-en.rpmというのがあったのでこちらをダウンロードした。
Firefoxではよく解らなかったフォントの設定だけども、とりあえず日本語はmplusのフォントで表示できるようになったし大体よい感じ。Formのボタンなどもmplusのビットマップフォントで表示できるとよいのだけど、これはうまくいかない。
ちなみにGoth_Pを指定すると何も表示されなくなるのでFxdを指定している。気になるがなにがなんだかさっぱりだ。
ランバ・ラル萌え。
アルミホイールで計量化! かどうかは知らないけども(多分関係ない)オタク心を突いてくるマウスが。
右手で持つと親指の部分がしっくりくる辺りは士郎正宗マウスのようだ。この親指部分のでっぱりがセレクタとして使えて、800dpi/400dpiの切替えができるとかだとますますツボに入ると思うのだけど。
少し前の記事だけどもCNETの記事が不思議だ。
これに対し、1つのCPUの内部に複数のCPUコアを装備するマルチコアのアプローチであれば、周波数を引き上げるよりも容易に性能を向上できる。加えて、CPUコアを複数詰め込むために微細化が必要になり、消費電力の上昇も抑えられるというわけだ。
クロック周波数を引き上げるよりは性能を向上させやすいのは確かだけれども微細化が必要になり消費電力の上昇も抑えられると言うのは少しおかしい。同じ面積にCPUコアを複数突っ込もうとするのであれば微細化は必要だ。逆にいうと面積を広げてしまえば微細化する必要が無い。また微細化したところで消費電力が下がるわけではないというのはPrescottコアのPentium 4で証明済だ。
今日気が付いたけど、Operaの上で日本語が入力できない。これは厄介だ。
うはwwwwwwwww「め」が入力できないwwwwwwwwwめが、めがぁぁぁぁぁっ!!!!!!!11
単に/がsgtml-slashに割り当てられているだけなんだけど。
M+フォントを指定させると表示がなされない件は、Gothicの指定に付いてXLFDの-p-が無いためのようだ。OperaがフォントをXに要求するときに指定されたフェイス名を用いて固定ピッチの場合には-c-を、可変ピッチの場合には-p-を付けて要求しているのだろう。M+では可変ピッチのGothicについてはファミリ名がGoth_Pと異なるファミリ名を付けているためフォントのロードができていないようだ。
全部Gothicとなるように書き換えてやったら表示できた。
M+のインストーラなどに手を入れて全部Gothicとなるようにしてインストールしなおしてみたら再発。何か漏れがあるのだろう。
通常、xfontselで-mplus-gothic-*と指定すると一番最初にヒットするもの、iso8859-1のフォントが表示されるハズなのに、なぜかjisx0208が表示される。
慣れない環境と言うか、xyzzyのhtml+-modeの支援が無い状態で書いているとタグの整合性を自分で確認しなくてはならないのだけど忘れてしまう。
まだファイルを月別に分割するプログラムをlinuxに移植していないので月別ファイルを作る処理に時間差ができてしまうのも気になる。というか、何とかしなければならない。
試してみたら動かなかった。font-lock回りで止まるようでhilit-string-findの定義が無効だと言うエラーが出る。yahtml.elのこの部分をコメントアウトしてみたが別のところで止まる。とりあえずはyahtml-use-font-lockをnilにすると動いたけどこれはこれであんまりなので止めた。
使ってるemacsが19.34と古いためだろう。
おとなしく最初から含まれているsgml-modeでキーの割当をcanna-self-insert-commandに上書きして使うことにする。
カーソルの上下移動が物理行単位なのが耐えられない。というわけでどうにかしようと思ったらどうにもならないことが判った。xyzzyにあるnext-virtual-lineとprevious-virtual-lineが無い。
無いものは作ってしまえと言うことで作った。
微妙に1文字ずれると思っていたら折り返し部分で右端に\\とか表示されているためでちょっと気に入らないがここは妥協する。
たまにモードラインに「かな漢字変換に失敗しました」と表示して漢字変換をサボるのはなぜだろう。
あとはC-;とC-:にkill-regionとかkill-ring-saveを割り当てたいのだけどこれがうまく行かない。
出来上がったのはこんな感じ。添削希望。
(defvar x-logical-col nil) (defun next-logical-line () "move to next logical line" (interactive) (if truncate-lines (next-line) (if (not (eq last-command 'next-logical-line)) (setq x-logical-col (% (current-column) (1- (window-width))))) (let ((nrow) (mrow)) (progn (setq nrow (/ (current-column) (1- (window-width)))) (move-to-column (+ (current-column) (1- (window-width)))) (setq mrow (/ (current-column) (1- (window-width)))) (if (and (eolp) (eq nrow mrow)) (progn (forward-char 1) (move-to-column x-logical-col))))))) (defun prev-logical-line () "back to previous logical line" (interactive) (if truncate-lines (previous-line) (progn (if (not (eq last-command 'next-logical-line)) (setq x-logical-col (% (current-column) (1- (window-width))))) (let (ncol) (setq ncol (- (current-column) (1- (window-width)))) (if (< 0 ncol) (move-to-column ncol) (progn (beginning-of-line) (backward-char 1) (setq ncol (% (current-column) (1- (window-width)))) (if (<= x-logical-col ncol) (move-to-column (- (current-column) ncol (- x-logical-col)))))))) (setq this-command 'next-logical-line)))
多分、新しいEmacs21などでは最初からできるのだろう。いや、next-line-add-newlinesがtなくらいだからいつまでもこのままかも知れない。
でできた。
従来機種と変わらない大きさの筐体サイズでi915を載せて来たり、基板を30%ほど小型化するなど気合いのは行った製品。
基板を小さくできたため、代わりにバッテリを大型化し5時間のバッテリ駆動時間を確保した。
「20周年にふさわしい製品を作れ。月並みな製品では絶対にだめだ」
しかし、一部マニアでないと判らないチップセットの新型化や、分解しないと判らない基板の小型化というのが20周年にふさわしいのだろうか。もっとも、東芝にはlibrettoという強烈な個性を持つ製品があるので問題ないとは思うが。
普通の人から見たら「20周年記念と気合い入れてる割には重くなったのね」としか見えない。
それはともかくとして、なぜこれがRe:config.sysの記事なのか。
こんなものがあったとは。これでだいぶ打鍵数が減る。
(set-key 'yomi-mode "L" '(self-insert henkan))と組み合わせてかなり入力が楽になって来た。
Lなのはよく判らないけど\S-lでは利かなかったため。S-kで「、」、S-lで「。」を入力すると言う変形仮名入力なのでこうなっている。
ところで、「最適"化"」の「化」はcannaにはどのように登録してやればよいのだろう。WXGのやけにマニアックな品詞分類に慣れているとシンプルすぎて困る。
昨日書いた関数だけども、中で(1- (window-width))を何度も評価するのが気に入らないので書き直してみたり。この程度でカーソル移動速度が変わるとは思えないけども頻繁に使うものなので手を入れてみる。
ヘタレなので(setq transient-mark-mode t)としてマーク部分を可視化して使っているのだけどもkill-ring-saveしたあとにもマークが残るのが気に入らない。というか、マーク領域が無くなること自体がemacsとしてはアレなわけだけども、どうもどこでマークしたか忘れてしまうのが悩みだ。
というわけでkill-ring-saveしたらquitするよう関数を書いてキーに割り当ててみたら動かない。というか、kill-ring-saveを呼ぶ関数をキーに割り当ててもダメだ。
ごちゃごちゃやってたらcall-interactivelyを使って呼び出せば動くことが解った。これが正しいやりかたなのかどうかは解らない。正しいやりかたなのかどうかは解らない。
まあ、quitするのもアレかなあ、と思ったのでC-SPCでtransient-mark-modeをtにしてコピーするときにnilするような流れで書いてみた。
Emacsはいじればいじるだけ深みにはまるあり地獄のようなプログラムだ。つーか、いじってて面白い。危険だ。
5月13日付でリリースされていた。
We put a lot of effort into this release to make it the most stable and fastest fluxbox so far, check for yourself.
とのことなので、是非自分で確認してみたい。
たまにKinput2のウィンドウが出て来てEmacsごと固まる。これはどうしたら回避できるのだろう。XIMを使わないようにEmacsをコンパイルしておけば良いのだろうか。
Kinput2のウィンドウを閉じるとEmacsも道連れになるので不便極まりない。
これはXMODIFIERSの値が正しく設定されていると発生する現象だった。Operaで日本語が入力できないのはこの環境変数が正しく設定されていなかったためで、これを設定するとOperaで日本語が入力できるようになるわけだけども、代わりにEmacsで入力できなくなる。困る。
普段入力できていたのは、初回にEmacsを起動してKinput2もろとも死滅した後に立ち上げたEmacsを使っていたためのようだ。
Fluxboxのメニューに
(Emacs) {XMODFIERES="@im=none" emacs}
とすることで解決。したのか?
XIMを使わないEmacsを作れば良いのだろうけども19.34のconfigureの引数を見た限りではそういう設定はなさそうだ。
13日付でリリースされていた。
Emacsとか旧ナスル朝艦隊とかと格闘していたために気付かなかった。
Emacs21.4.2をmakeしてみる。
出来上がったものを./src/emacsとして起動してみたら、先日試したとき程重くない。というか、起動に1分かかっていたのが嘘のようだ。
というわけで早速乗り換えることにする。このままではcannaが使えないのでそれ用のpathcも当てる。
どうやら描画の優先度をものすごく下げてあるようで、スクロールさせるとどこまでスクロールしているのか解らない。ありといえばありだとは思うけども、エディタの挙動としてはどうかと思う。
とにかく画面がかっこ良くなった雰囲気。
マルチスレッドはパフォーマンス低下の原因でもあるのだ。
とあるので興味をひかれた。マルチスレッドがパフォーマンスを低下させる要因というのがあまり思い付かなかったからだ。せいぜいがスレッドを作りすぎてコンテキストスイッチのオーバヘッドが増えることくらいしか思い付かない。
見出しには「リソース競合から守る」とあるので同期、排他制御についての記事なのかとも考えるが排他制御とパフォーマンスはあまり関係がない。マルチスレッドで処理中にリソースの競合が発生し待たされたとする。その場合、待たされた方は処理が停止するけども、その停止状態は必要な待ち状態なので仕方がない。逆に、シングルスレッドにしたところでパフォーマンスが改善するかといえば、排他制御の必要がなくなるだけで先行スレッドが時間をかけていた処理が早く終るわけではない。結局かかる時間には大差がなくパフォーマンスがあがるわけではない。ご飯を食べている間は味噌汁を飲むことはできない。味噌汁の消費速度が低下してはいるものの、それをもって食事という作業のパフォーマンスが落ちているとは言えない。つまり、リソース競合によるパフォーマンス低下というのはマルチスレッドが原因とは思えない。
Javaアプリケーションによるロック競合が発生している状態でGlance/gpmによる計測を行った例です。これを見れば、ほとんどのCPU時間が青色の「System」（OSコード）によって消費され、紫色の「User」（アプリケーション・コード）の割合が低くなっていることが分かります。しかし本来、Javaアプリケーションの動作が正常であれば、CPU時間の大半をUserが占めていなくてはなりません。これは、ロック競合の多発を示す1つの指標となります。
CPU時間の大半をUserが占めていなければならない、というのは正しい。しかし、Systemが占めていることがロックの競合を示しているというわけではない。適切な待機関数を用いていればスレッドはCPUタイムを使わない。つまり、SystemにもUserにもCPU時間を使っているという形跡は残さない、単にスレッドが停止しているように見える。
ここでは、「Cumulative system call count」の項目に注目します（図3）。すると、「sched_yield」や「ksleep」などの特定のシステム・コールがかなりの頻度で呼び出されていることが分かります。また、これらに比較して、図3の矢印で示される「send」と「recv」の呼び出し回数はかなり低くなっています。
send()やrecv()をそれほど呼び出していないのに頻繁にスレッドを停止させるようなシステムコールが発行されているとなると、本来処理するべき送受信処理以外でそれらを呼んでいると考えられる。実際、図3のスクリーンショットを確認すると
| Systemcall | 呼び出し回数 | 所用時間 |
|---|---|---|
| sched_yield | 57,565 | 10.82058 |
| ksleep | 6,772 | 99.80373 |
| send | 122 | 0.00120 |
| recv | 90 | 1340.5443 |
となっている。sendではほとんど時間がかかっていないし、recvは呼び出し回数の割に時間がかかりすぎだ。つまり、送信はボトルネックとはなっていないし、受信では正しくブロッキングされていると思われる。確かにsched_yieldの呼び出し回数は多いが所用時間はrecvの1%以下であり問題ではないと思う。
図3の矢印で示される「send」と「recv」の呼び出し回数はかなり低くなっています。この2つのシステム・コールは、Javaアプリケーションのネットワーク処理をつかさどるため、本来であればもっと高い頻度で呼び出されなくてはなりません。つまり、アプリケーション設計の不具合によるロック競合の影響で、呼び出される回数が低く抑えられているのです。
確かにsend()を呼び出している回数は少ないし、所用時間もそれほどかかっていない。想定するsend()呼び出しの回数がどの程度なのかは解らないのでこれは少ないのかもしれない。この点については判断材料が少ないので保留する。
recv()については異論がある。呼び出し回数の割に時間がかかりすぎている。つまり、これはrecv()を呼んでも受信すべきデータが到着していないということだろう。非ブロッキングモードのソケットであるならば逆に受信すべきデータが多すぎて処理が追い付いていないことになる。非ブロッキングモードなら受信すべきデータが無ければすぐに呼び出し元に戻るため、呼び出し回数は増えるはずだ。しかし、110程度のスリープしている時間とrecv()の1340という所用時間を考えると、recv()の中ではほとんどスリープしていないように思える。
リソースの競合が発生しているのなら、リソースの開放待ちのためにもっとスリープしているはずだ。どちらかというとアプリケーション設計見落としにより、受信データが多すぎるというように見える。これはリソース競合とは関係が無い話だ。
もし、これがリソースの競合によるものだとしたら提示するデータが不足していると思う。
記事の内容としては、有用なツールの紹介であり解りやすいと思う。なんにしろ、プロファイラを使ってボトルネックを正しく計測しようというのは正しい姿勢だ。根拠もなく推測で性能改善を図ろうというのは論理的な姿勢ではない。
面白い。この手があったかと言うか、思い付く方も思い付く方だ。
仕掛けが良く解らなくて、資料を当たっていたりしたので日曜にはネタにできなかった。RING0経由でキャッシュでも盗めるのかと想っていたがそうではなかった。というか、さすがにそこまで不思議な実装ではない。
というもの。原文では
1,024ビットの秘密鍵RSAを処理させる。OpeSSLはスライディングウィンドウを用いたChinee Remainder公式で秘密鍵を処理する。1,024ビットのモジュロ式を512ビットのモジュロ式2つに分けて処理をする。スパイ用のプロセスを動かしL1キャッシュを観察。乗算とアクセスの傾向から512ビットに含まれている約200ビットが判明する。また、乗数が31以上であることがほとんどであることから乗算無しで求める0から5ビットの値を推測することができる。
下位256ビット、もしくは512ビットに分割されたモジュロ式それぞれから半分のビットが解ればRSAの秘密鍵は解ける。しかし、追加のビットは乗算後に残されたfootprintに含まれているのでそれから入手することができる。。
と、ちょー訳というか雰囲気だけ参考になればという感じなのであまり当てにしないで頂きたい。RSAのアルゴリズム自体が解っていないのでこういう方法で計算しているのかどうかということも確認していない。
解るのは、アクセスのレイテンシから既知のテーブルへのアクセス履歴を推測し、キーの内容を読みとろうと言うもの。似たような手口としては、暗証番号を入力するテンキーのすり減り具合やバネのヘタリ具合から暗証番号を推測しようと言うものに近いと思う。
なので、回避するには「キャッシュを共用しない」つまりHyperThreadingを使わないというように指示されているけどもアクセス履歴が解らないようにしてしまえば良いのでもっと複数のプロセスを走らせてキャッシュのミスヒットを増やすというのでも回避できるのではないだろうか。
OpenSSLが使用するスライディングウィンドウの配置をランダムに決定するとか、単独ではなくて常に複数のキーを処理するようにするとか。
ひたすらに2MBほどランダムに読み書きしまくるプロセスを走らせておくというのも効果があるかも知れない。
Inquirerの記事によるとVIAがPentium Mとピン互換、Socket 479のCPUを発表するようだ。
ただし、現在解っているのはそれだけで、それ以上のことは不明とされている。
FIVAで動かしているXでM+フォントを絶賛愛用中なのだけども、いくつかの字体が気に入らない。
ありがちなのは0に斜線を入れたいというのだけども、「か」のハネがいまいち好みではないとか、濁点は斜めではなくて縦に入っていた方が視認性が良い(半濁点と混同しにくい)とか、asciiの小文字はもう1px大きい方がコーディングしやすいとかやけに個人的な都合によるものなのでちょくちょく書き換えている。
しかし、iso8859の字体を直してもそれをjisx0201に反映させるのが手間でどうしたものか悩んでいる。
iso8859-1とのdiffをとって、それをjisx0201に当てれば解決するだろうか。一番良いのはアーカイブに含まれている元データに手を入れてしまうのがいいんだけども、そうするとインストーラが当てようとするパッチが当たらなくてハマる。
とりあえず、後は
当たりも手を入れよう。
不正アクセスの被害に遭った価格.comのサーバーは自社で運営していたもので、「インターネット関連企業として“最高のセキュリティ対策”を施していた」。
企業として「セキュリティには手をかけていませんでした」とは言えないのは解るけど、そう簡単に「最高のセキュリティ」と言われてしまうと苦笑してしまう。
このように発表すると、
の2種類の解釈ができると思うが、どうも後者の「ウチは悪くないんだ」という言い訳がましいものを感じてしまう。
それに、仮に本当に「最高のセキュリティ」だとしたならば他のサイトはもっと信頼性、安全性に劣ると言っているわけで、そのような不安定な社会基盤を使って買物しようというような奇特な人が出て来るだろうか。最高のセキュリティでこれなら、しばらくはオンラインショッピングは差し控えよう、と考えるのが普通の考えだと思う。
また、一時閉鎖を伝える別の記事では、一種のサイバーテロ的な行為と認識した
とあるのがまた笑いを誘ってしまうが、これはクラックされた状態では中国ドメインにアクセスするように細工されていたという噂もあり、このことが中国からの反日テロリズムと認識されているのかも知れない。なんにせろ、テロ行為であれば、まずは犯行声明の発表を待ちたい。
AMDがDELLにCPUを売り込むためのパイプとして活動するのか、それともDELLがIntelから値切るための材料として機能するのか、はたして。
2インチの画面(液晶なのかどうかは記事では触れられていない)を搭載し、横4インチ、縦2インチのサイズ。2.8オンスというから80グラム位。
めちゃくちゃちっちゃい。画面の保護はどうするのだろうか。簡単なカバーでも付くのか、それとも初代GBAのように剥き出しなのか。
なお、PC Watchの記事には、このGame Boy Microの画像もある。初代ファミコンのコントローラより小さなサイズでゲームができると言うのは衝撃的。ファミコンコントローラカラーが発売されたらぜひ買いたい。そしてスターソルジャーをプレイしたい。
商品のコマーシャルには、KONISHIKIあたりを使って欲しいなあ。本体がどこにあるのか解らなくなる。
画像を見る限り、Game Boy Microには一つ足りないものがある。キーホルダーなどを付けるためのランヤードリンクだ。
ThinkPadを作れるのは、いまは大和だけ。それ以外の製品には、ThinkPadのブランドは使用されることはない
こういう、自信と誇りに満ちた物作りができるというのは羨ましい。製品の品質と大和の開発力に自信があるからこそできる発言だと思う。
実のところ、ThinkPadは壊れにくいパソコンと言うわけではない。他のパソコンと同程度、ちょっとは頑丈かなという程度でしか無い。それでもThinkPadなら安心というのは、もし壊れたとしてもその後のサポートが充実していたからだし、各部品も個別に取り寄せられて自分でできる範囲なら修理できた。いざと言う時にも「ThinkPadなら何とかなる」という部分が安心につながっている。
また、他のパソコンと同程度に壊れてしまうと言うことがある意味「ThinkPadが壊れるようなら他のノートでも壊れるだろう」みたいな基準にもなっている。どっちにしろ壊れるなら安い方がいいのだけど、修理費用を考えるとThinkPadという感じ。
しかし、これからは今までと同じように壊れてしまうとちょっと問題がある。今までは「ThinkPadでも壊れたか、仕方が無い」で済んでいたものが「やっぱりレノボになったからかなあ」と思われてしまう。同じ品質でも受け止められ方が変わってしまう。レノボには大変だけど、今までのThinkPad品質を越えないと今までと同じ評価を受けることができない。ThinkPadの品質はトップレベルだ。液晶はちょっと劣るけど色再現性などは重要視していないのだろう。そのトップレベルの品質をさらに向上させるのは難しい。
ThinkPadのユーザーのなかで、低価格を購入理由にしたという例は極めて少ない。それは同社の購入者調査の結果からも明らかだ。だが、コストメリットが出せれば、これまで以上に、競争力が高まるのは紛れもない事実。
逆に高価格を理由に購入をあきらめた、というケースは多いのではないだろうか。
私の場合はThinkPad s30とかXとかを考えたけど値段でPCG-SRX3にしたし。勤務先でThinkPad T買ってくれと頼んだけど値段を理由にRになった。RはRなりにThinkPad品質ではあったもののやっぱり不満があったりもした。同じ値段で買うならRではなくて別のメーカのノートのほうが良かったかなとも思えたけども、そのときにはRS-232Cがどうしても必要だったりしてThinkPadであることの有難みを満喫した。
ThinkPadの開発予算で得た技術を転用してかつてのiSeriesのような家庭用低価格モデルという感じのレノボノートが出ると嬉しいかも知れない。
HKEY_LOACAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstallへのアクセス権限が新規インストールとWindows 9xからのアップグレードインストールとで異なると言う話。
問題が発生した時の対処としては、アクセス権限を手動で設定し直せ、ということで手順は上記MicrosoftのKnowledgeBaseから参照できる。
気になるのが、ここで使用されている画像がBMP形式と言うところだ。拡張子はGIFなんだけど、中身はBMP。
今ごろ気が付いたけど、@ITには見出しが設定されていない。そのため、リンクをたどるのがものすごく面倒。マウスを使わないとたどるのに手間がかかる。
「新着記事」や「@IT FYI」などは見出しとしてマークして欲しい。
Michaels of Oregon社製のカイデックスホルスタに備え付けられている止め具に不具合があるため、ホルスタに入れようとすると暴発する危険性があるとのこと。
GLOCKはセフティが無いのでトリガをひいたら発射してしまう。ホルスタに押し込む際に止め具がトリガに接触してしまうのかも知れない。警官が一名すでに事故に遭いふとももを撃ち抜いているそうだ。
っていうか、The Inquirerはなんでもアリだな。
うっかりさんなミスだった。
設定ファイルを読み込んでいる最中、次はここから追記する、というポインタを保持しながら設定ファイルを読みすすめていく。最初はx86の1ページ、つまり4KBしか確保していない。途中でメモリが足りなくなった時にはメモリの再確保を行なう。再確保を行なったときに読み込んだ情報を格納する追加ポインタの位置も再設定しなければならないのにそれが抜けていた。というか位置を設定した後にメモリを再確保していたので食い違っていた。
倉庫が引越しされるとは限らないので、増設しても元の場所に格納できることもある。が、大量のデータが来た場合には元の場所を放棄して引っ越さなければならないため、後で引っ越し前の場所にデータを格納しようとすると住居不法侵入と言うかそんな感じでOSに殺される。今時のOSでは住居不法侵入(範囲外の書き込み)や覗き(範囲外の読み込み)は死刑だ。Zap Zap Zap.
なるほど。
先頭にあるのはうっとうしいのでどこかにどけておこうとは思ったのだけど、先頭にあるのはそれはそれで、最初に読み飛ばせば邪魔ではないかもと思って先頭に置いてみたわけだ。
しかし、先頭は「最高レベルの操作性」とあるくらいなのでやはり避けた方が無難かも知れない。特にGoogleさんの中の人は広告持って来るのに時間がかかってレンダリング速度にも影響が出てるし。
もっともOperaの広告に付いては先頭から移動するつもりは全く無い。勇敢なるCEOに敬意を表したい。
ちなみに、Opera 7からアップグレードしたからか、Windows版のOpera 8はそのまま広告も出ずに使えている。
先月の実験とは逆の話になるけども、見てる人は見てる。
それは見るに値するなんらかの価値があるからだろう。良く解らないけども。見られて恥ずかしくないような活動を心がけたい。
他人から「注目するだけの価値がある」と思わせるような評価を得たいのであれば、何らかの行動を起こさなければならない。活動しないことには注目もされないし評価もされない。悪い表ではなくて、プラスになるような評価を得たいのであれば、自分だけのためではなく、他人から見ても価値のある活動をしなければならない。まあ、ほどほどに。
あの米長邦雄永世棋聖が著作権侵害で訴えられたとのこと。これがなかなかにややこしい話。
原告はソフトウェア開発会社である棋泉。棋泉は、米長邦雄永世棋聖と共同で将棋ソフトを開発。当然ソフトウェア部分の著作権は棋泉が保持。ソフトウェアに納められている詰将棋問題やコラムについては米長永世棋聖が著作権を保持する内容で契約を結んだとのこと。
それだけならばまだいいが、その後米長永世棋聖は別のソフトウェア開発会社「サクセス」と共同で「みんなの将棋」開発。
サクセスと開発した「みんなの将棋」が棋泉と開発した将棋ソフトウェアと類似している、というのが原告側の主張のようだ。
正直、同じ人が監修したのであれば内容は似てくるのは仕方が無いと思う。さらに、テーマがどちらも「将棋」という同じものなので、似てないと言う方が無茶だ。
原告の主張する類似点は記事によると
が類似とされている。初級中級上級というのはよくある分類で著作権で保護すべき創作的な発想とは思えないし、講座や実戦解説はそのためのソフトウェアなのだからあって当り前だと言える。GBAのヒカルの碁ですら講座が含まれている。というか、将棋やマージャン系のテーブルゲームであれば遊び方としてある程度の「講座」と呼べるものが含まれているだろう。実戦解説のほうは、棋泉が用意した解説であれば通るかも知れない。ただし、米長永世棋聖の棋譜を元に解説したのであれば、棋譜の著作権者は米長永世棋聖とその対局者であり、解説者は二次著作権者だとも言える。契約によってはNHKとか大会主催の新聞者が棋譜に対する著作権を持っているかも知れない。が、解説者にはどの程度の著作権を主張できるのだろうか。問題の構成や順序については、棋泉が考案した問題や順序であれば、それは認められるだろう。しかし、詰将棋問題の著作権は米長永世棋聖が保持するという内容で契約しているので、それ以外の問題だったのだろうか。
米長永世棋聖によると
「著作権者及び著作者、人格権は米長に帰する」と契約書の第1条に明記されております。
とのことなので、詰将棋問題やコラムについては米長永世棋聖が書作権をもっているという原告側の主張と食い違っている。まあ、契約書があるのだからすぐにはっきりするだろう。
Opera内蔵のIRCクライアントを起動してみたところ、日本語…というかISO-2022-JPが通らない。どうもESCを落してくれているようで日本語に切り替わらないようだ。
仕方が無いのでIRCクライアントを入れる。どうせなら日本語入力が楽なEmacsから使えるものが良いと言ってみたらirchatを紹介された。site-lisp/に突っ込んでみたらすんなり動いた。
まだ操作方法が解らないのが難点。複数チャンネルを同時に見るとか。それはともかくとして、irchatを起動してても別フレームでコーディングしているとIRC側は全然見えない。
とりあえず無事に終了した模様。
CygwinでX11のアプリが書けると実験が楽だと思ってCygwinをインストール。Cygwinである必要は無くて単にWindows機でX11のアプリを書いて動かせられれば良いのだけど、多分Cygwinを使うのが早くて安そうだ。
しかし、gcc -I/usr/X11R6/include -L/usr/X11R6/lib -lXt a.cとしてもXtAppInitialize()にリンクできない。undefined symbolといわれてしまう。nmでlibXt.a.dllを見てもXtAppInitialize()はあるようで、なぜリンクできないのかはさっぱり解らない。
PS3の負け。
メガドライブとかサターンとかドリームキャストとか買ってる私が言っても説得力が無いかも知れないが。
プログラマ個人として、こう言ってしまうのは情けない気もするけども、今のゲームプログラムは簡単に作れることが重要視されている。難しいことはしたがらない。作品のリリース間隔も短いし規模は大きくなる。売れるかどうかはギャンブルなので、作品が外れたときの保険としてすぐに次の作品をリリースできるような体質が望ましい。
まずはインプレスの二つの記事。
単純な性能、数値上の性能だけを見ればPS3のほうが上回りそうだ。GPUを使わなくてもSPEだけでフライトシミュレータやレンダリングができてしまう。
それでもXbox360の方に分があると思う。
記事のタイトルにもなっているけどPS3のグラフィクス処理エンジンはNVIDIA製のプロセッサとは別にSPEも使える。しかし、使おうとするとこれはプログラマ側が意図的に使わないといけない。多分、自動的には使ってくれない。今後のライブラリで改善されるかも知れないけども、7つあるSPEのうち、どの程度をレンダラとして使うか、という意志決定はプログラム中で明示しなければならないだろう。これは面倒だ。
それにひきかえ、Xbox360ならシェーダプログラムをGPUに送り込んでしまえば、後はGPUがやってくれる。楽だ。
ゲームの場合は調整などの後工程が作品の品質を決める。ここで、処理が遅いからといってSPEの割り当て数を変えようものなら大変な作り直しになりかねない。SPEの使い方に慣れるまで、1年くらいは様子見といった雰囲気だけど、それだけ間が開いてしまえば本体の普及数にも差が出てしまう。
私がメガドライブやサターンを買ったのは、そのハード性能にわくわくできたからだ。夢を見ることができたからだ。ドリームキャストはそれほどでもなかったけど。
PS3にはそういった夢もない。Game Boy microのほうがよっぽとわくわくする。PS3はゲーム機ではない、なんて言っている。それではゲーム機が欲しい人はわくわくできない。SCEIがどういう夢を見てPS3を作ったのか伝わって来ない。SCEIの夢を共有できない。それにくらべて、Xbox360はPCの延長というかゲーム機の延長線の上にあり、どういったものかが想像しやすい。まだMicrosoftの描く夢のほうが解りやすい気がする。
解るものと解らないもの、どちらにお金を出すか、というと解るものに出すのではないだろうか。だから、多分私はGame Boy Microを買うと思う。これが一番解りやすい。
Xbox 360もPS3も、すごいゲーム機であることは良く解る。だからといってそれで何ができるか、と言うのが伝わって来ない。
いまだにサターンのレイディアントシルバーガンとかガングリフォンが面白すぎる。GBAのF-ZEROも楽しい。私が時代に取り残されているだけかも知れないが、ハードウェアの性能の差がゲームの面白さの絶対的差ではないということをサターンやGAMEBOY Advanceは教えてくれる。
まずは、森さんのコラムからこの一節。
制作スタッフによると、劇場映画クオリティのオープニングを作るにあたって、Xbox 360のゲームシーンがハイビジョンクオリティであるために、この2つの差別化に苦労したという。これまでのゲームのようにオープニングとゲームシーンの画質がまったく異なるという時代ではなくなってしまったのだ。ゲームといっても次世代ゲーム機向けタイトルは、プレビューで水口氏がいみじくも繰り返したように、もう「映画並み」になってしまっている。そのため、実際の制作もほぼ映画並みの人員と作業、工程が必要になっており、これまで通りのやり方では通用しなくなってきている。今では、クリエイティブなゲーム制作にもシステマティックなアプローチが不可欠になりつつあるのだ。
クリエイティブなゲーム製作とあるけども、もちろんゲーム製作だけがクリエイティブというわけではない。システム設計もアプリケーション開発もそれぞれにクリエイティブだ。
ゲームであれアプリケーション開発であれ、どんな内容のものでも規模が大きくなるにつれ開発手法、管理手法としてなんらかの体系づけられた手法が必要になると言うことだ。
なぜ体系づけられたものが必要になるのか。
体系づけられないと理解できないからだ。
人間、一人が理解し、把握し、制御できる規模というものには限界がある。それぞれについては個人差があるが無限ではない。私が理解できない規模のものでも別の人なら理解できるだろう。これが個人差と言うものだ。しかし、それでもいつか理解を越える規模のものが出来上がる。これが限界と言うものだ。
こうした限界に突き当たる前に、理解が容易な範囲に分割して管理しよう、というのが体系づけられた開発手法、管理手法といえる。
なぜ分割するのか。それは先程書いたように、個人の理解できる規模というのには限界があり、かつ個人差があるからだ。
たとえば映画の「メメント」という作品がある。10分しか記憶していられない記憶障害の人を主人公としたものだ。この作品、把握できる時間軸が広い人なら鑑賞中に物語をつなぎ合わせることができるかも知れない。しかし、それを普通の理解力だと思って他人に求めるのは無理だと言えよう。最後まで見てから考え直したり、2回、3回繰り返して理解できる人もいれば、逆再生してやっと、という人もいる。それが個人差と言うものだ。
体系づけられた開発手法というものは、こうした個人差のある理解力でも理解できる範囲に区切って開発対象を分けよう、というもの。どの程度の理解力に合わせるか、というのは開発チームの理解力に左右される。理解力が低い組織による開発であれば細かな単位に分割される、というか分割しないと理解してくれない。理解できない。そうでなければ、大雑把な単位で構わない。
ここで、はてなのCTOの伊東さんの話になる。
これから先、Perlでアジャイルに者を作る会社が続々と増えるなんてことはあり得ないでしょう。でも、はてなという会社はそれが正しい方法論だと確信しているし、僕らは、頭でっかちの設計屋が何日もかけて設計するようなやり方よりも、よっぽどすぐれたやり方でやっていると思っています。
はてなという組織の中では、このやり方は正しいのだろうと思う。本人がそう信じているのだから反論する理由もない。しかし、それが他の組織でも正しいか、というとそうではない。どこでも通用するやり方ではない、ということは注意したい。
アジャイルな、つまりAGI型の素早い開発ができる組織で、かつ素早く開発できる規模のものを作るときに限り成り立つ。
伊東さんが「素早く開発できる規模」というものと私が素早く開発できる物の規模というのは違うだろう。これからはアジャイルだ、といってとりあえず作って壊し作って壊すというのを繰り返すのも悪くは無いが、自分が作ろうとしているものが自分がアジャイルに開発できる規模に収まっているかどうか、正しく認識しなければならない。
古くからあるような、ウォータフォール式に設計をしぼり込んで機能を分割し、それぞれの規模が充分に小さくなったらそこから先はアジャイルでも良いと思う。
しかし、最初からとりあえず作ってみてダメなら作り直す、というやり方は素人にはお勧めできない。そういう芸当はポール・グラハムや伊東さんのような一定水準を越える能力を持っている人だけができる芸当だ。何事にも向き不向きがある。伊東さんのやり方が向いている人もいれば向いていない人もいる。教科書通りにうまくできないからと言って安易に教科書のせいにするのはちょっと置いておいて、ゆっくりと設計を考えることが必要だ。
頭でっかちの設計屋が何日もかけて設計する
のは、理由がある。アイデアも設計も実装も同じ人が担当し、その人が実装できる規模であれば設計書なんていらない。しかし、森さんのコラムにあるように規模が大きくなって来るとアイデアを出すのはプランナ、設計はデザイナ、実装はプログラマというような分業が余儀なくされる。こういう体系づけられた組織では体系づけられた開発手法が必要になる。
プランナが考えたものをデザイナが設計する。その設計を元に実現させるためのコードを書く。こうした意志の伝達の間にはロスが生じる。このロスを最小限にするために頭でっかちな設計屋が設計する必要がある。馬鹿な実装屋にはそれに合わせた馬鹿丁寧な設計書が必要だし、そうでなければやりすぎないように釘を指した設計書が必要だ。
今時のアプリケーションは複雑で、一人で思い付けるものではないし一人ですべてを把握できるものではない。そうした複雑さを克服するために、簡単なものに分解しなければならない。複数人で作業をするのであればなおさらだ。同じ目的を共有するためにも大きな目標をより小さな単純化された目標に置き換えなければならない。複雑なものを複雑なまま処理できる人は限られている。
プログラムがうまく書けない、という人はとりあえず書いてみる、というのも一つの手だけども、ゆっくりと紙に向かって、自分が作りたいものが一体なんなのかということを具体的に想像できるまで考えてみるというのも一つの手だと思う。
いきなりつくり出してうまく行く、というのは作りたいもののイメージがちゃんと出来上がっていて、全体像を把握しているからだ。その場合はイメージ通りに作り込んで行く、落し込んで行けばいいだけの話なのでコーディングは全体の作業の20%しか占めない。
逆にイメージが固まっていなかったり、思ったより複雑なのであればイメージを固めたり簡単なモデルにしなければならない。ゆっくりと考えたり、イメージしやすいような原型モデルを仮に作ってみて想像力を補う、という手法もある。
それでも作れないのであれば、理由は次のうちのどれかだ。
プログラマの生産性、つまり能力には100倍ほどの差があると言われている。トップクラスのプログラマが100mを10秒で走るスプリンタだとするならば、ひどいプログラマは1,000秒、つまり16分40秒かけて100mを走るのである。普通、徒歩の移動速度が80m/分と言われているので、100mを16分という速度は歩くよりも遅い。できるプログラマとできないプログラマとではこのくらい差がある。
できるプログラマの話を鵜呑みにして、それが自分にもできると思ってそのままマネしようものなら、100mを16分で走るハメになる。
10秒は無理だとしてもせめて15秒、20秒は切りたい。プロだというのなら11秒か。16分もかけて走るような不様な真似はしたくない。そのためにも他人の走り方ではなくて自分に合った走り方というのを考えなければならない。
価格.comの事例か他人事ではない、ということは他にも同様の被害を被っているサイトがあるので自明とも言える。
さて、ここでも出て来た「サイバーテロ」。不正アクセスがテロなのならば、不法侵入や空巣はローカルテロなのか。ゴミの日ではないときに燃えないゴミを出すのはご近所テロなのか。
何でも「テロ」呼わばりして危機感を煽るのは勘弁して欲しい。
オンラインゲームのパスワードを盗もうとすることのどこがテロリズムなのか。
たびたび出て来る毎度の話。AppleがIntelのチップを採用するかも、という。
記事にあるような理由であれば、あり得ない。
PowerPC 970系の性能は、同じクロックのBaniasに匹敵する。それに、PowerPC 970FXの平均消費電力は2GHzで24.5W。最大消費電力は60Wくらいになるのではないか。これではTDPが30WのDothanには敵わない。
しかし、クロックを1/4ほど落せば電圧を下げられる。それで消費電力は1/2にできる。1.5GHz駆動でよければ30Wで動かせてしまう。Dothanよりはクロックが下がってしまうが、サブノートに突っ込むには充分な性能だし消費電力だ。記事にあるようなCentorinoにバンドルされるCPUと同程度の消費電力のCPUコアであれば、既にあるのだ。
それに17インチPowerBookに載せようと言うのであれば、60Wという消費電力は問題にならないかも知れない。17インチに2GHz、15インチに1.5GHz、12インチには1.2GHzと分ければ載せられないこともない。PowerMac G5との差別化のために、もう少しクロックを落すかも知れない。12インチクラスのx86機は1.2GHz程度なので64ビットのPowerPCなら1GHzでも張り合えるだろう。
だから、消費電力を理由にx86を選択すると言うことはあり得ない。
playstation 3やXbox 360に搭載されるCPUもPowerPC 970系と見られている。これらの消費電力は60Wもないようだ。3.2GHzで動作しているCellが7つのSPEを含めて40W程度という話もある。SPEの消費電力が4GHz@1.1Vで4W。動作電圧を1/10下げて1Vにすると1/√10くらい、30%くらいは下がる。3W。1V駆動でも3.2GHzで動かせる。ISSCCのセッションで発表された数値とも合う。PowerPCコアであるPPEと二次キャッシュの面積を考えるとSPE3つ分くらいの消費電力だろうか。そうなると3.2GHzでも12Wでしかない。もうちょっと多めに見て15Wとしてもノートには載せられる。PowerPC 970FXの発表から時間もだいぶ経ったことだし、何らかの改良がなされているのではないだろうか。
それでもx86を採用するとしたらどのような利点があるだろうか。x86の利点には、大量に出荷されることによる価格の安さがあると思う。だから本体価格を下げるためにx86を選択する、というのであれば一つの理由にはなる。しかし、これも考えにくい。
こちらは記事で触れられているように、互換機の問題が出てくるから。簡単に互換機が作られないようにプロテクトをかけるのであれば、そこでコストが発生する。結局本体価格が安くならない。これでは意味が無い。
x86機のクロック周波数が3.2GHzとかモデルナンバー4000+とかいうのと比較してPowerG5の1.8GHzというのは見劣りするかも知れない。
しかし、1.8GHzというクロック周波数はAthlon 64ならモデルナンバー3000+に相当する。4000+のAthlon 64ですらクロック周波数は2.4GHzにしか過ぎず、クロック周波数比で33%の差しか無い。
それでいながらデュアルCPUなのだからPowerMac G5は最近のWindows機と比較しても性能的にはひけをとらない。だからクロック周波数だけを見て悲観的になることは無いと思う。
ノート用のPowerPCプロセッサについては、しばらく待たないと行けないだろう。Pentium Mが登場したのはTransmetaがCrusoeやEfficeonを発表することで省電力プロセッサの競争を生み出して市場を奪いかけ、Intelが対抗したため。しかしPowerPCにはそのような競争が無かった。だから省電力Power G5というような製品は出て来なかった。
しかし、今ゲーム機の中にPowerPCをいれてしまった。リビングに置いて、かつ邪魔にならないサイズにするためには省電力かを進めるしか無い。その成果がPowerBookに採り入れられるのではないだろうか。
また、AMDのモデルナンバー3000+に匹敵するプロセッサをノートにいれようとするのは難しい。Windows機であればビデオチップを統合型にするなどということもできるが、Macintoshであれば、Mactintoshであるためにも外付けのビデオコントローラが必要だ。そうなると発熱はWindows機と比較しても増える。
3000+の性能に拘らず、2000+くらいの性能のPowerG5だとノートに収まるのではないだろうか。クロック周波数は1.4GHzくらいまで落さなければならないだろうけどこれならやってやれないことは無いと思う。
そうした妥協の産物と言える製品をAppleが出すとは思えないけども。
昨日、今日とでとりあえず600行くらい書いた。
X Toolkitの資料の無さには泣けてくる。
去年書きかけたときはShellWidgetとFormWidgetができるというのが気に入らなくてXlibで書いていたのだけど、XtAddEventHandler()が無いととても不便なのでXtで書くことにする。というか、あれはFIVAをインストールし直したときにソースごと吹っ飛ばしていたりする。どうせ捨てるつもりだったし。
勉強しないといけないのは次のもの。
前途多難というか、先は長い。
私はかな入力なので、非常入力しにくい。
それにしても、ただひたすらに「w」を連打するのに、なぜ「っうぇ」という謎の文字列が混入するのか。激しく疑問だった。
この謎は今から二年程前にROで所属していたギルドマスタから明解な説明を頂いた。
魂のリズムに合わせて「W」キーをプッシュプッシュ!
たまに魂がが逸れて横の「E」キーを押してしまい、それが「っうぇ」という絶妙な味わいを醸し出すとのこと。
おそらく、例の「へぇ〜ボタン」のようにWキーを連打するのだろう。
私が「wwwwwwwww」とか入力する場合は一度かな漢字変換をOFFにしておもむろに「W」キーを押し込み、2秒くらい待ってから指を離す。こんなつまらない押し方では魂のほとばしりを感じさせるような「wwwwwwwwwwww」にはならないのである。
とか言ってると、ものすごくナチュラルに「っうぇ」を使いこなす方もいたりする。その流れるような「w」と「っうぇ」は、まさにnative.
逆毛の道もまた楽しからずや。
ちなみに、自宅のJapanist 2003には読み「ててて」で「wWw」という単語が登録されている。
というわけで、ローマ字入力の人なら誰でもナチュラルに「www」から「wwっうぇ」に繋げられるのだと思っていたが、やじうまWatchを見る限り、そういうものではないようだ。ナチュラルに繋げるためには魂がこめられた連打が必要らしい。
SQLインジェクションを許すような設定、運用で、どうなったら「最高のセキュリティが破られた」と言えるのか。
これまでのサイト攻撃は、OSの不備やホームページをネットに提供するプログラムのミスなどを突くケースが多かった。今回は、プログラムに欠陥がなくても、コンピューターが正規の命令か悪意のある命令かは判断できない点を突き、命令をそのまま実行させて支配下に置いていた。
プログラムに欠陥は無い。
つまり、物を載せたら落ちる棚みたいなもので、「物を載せてはいけません」という取り決めがありそれが守られている限りは問題は発生しない。価格.comのシステムも、「このシステムにはユーザが入力した文字列をSQL文として実行してしまうことがありますが、そのようなことをしなければ問題はありません」という取り決めなのだろう。こういうノーガード戦法で最終的に被害を被るのは、システムの所有者ではなくて利用者だ。今回の場合、価格.comではなくて、価格.comに広告を出稿していた店であったり、個人情報を登録していた客の方。こうした人達を守るのが個人情報保護法であり、不正アクセス防止法だと思うのだけど、全然機能していない。
不正アクセスをしては行けません、というような不正アクセス防止法ではなくて、不正アクセスをされては行けませんというような不正アクセス防止法が必要なのではないか。不正アクセスを試みるのは良くないが(なにしろ不正だから)、そのような不正なアクセスを受け入れてしまう方にも何らかの罰則が必要だろう。
管理責任を果して法による保護が受けられる、というのではなくて管理責任を果たしていないと罰則が適用される、と言うような。銀行でも預金の引き落としなどで本人確認の義務がどーのこーの、という話がある。それと同じ。
やりにくい世の中だとは思うけども、そうでもしないと何も改善しようとしない気がする。そもそも、既に最高のセキュリティを保持しているような組織であれば、罰則が適用されても今までと何も変わらない。飲酒運転の罰金が値上げされても、元々飲酒運転をしない人には何も影響が無いのと同じ。
肝心なことを書き忘れていたことに気が付いた。
これから先、Perlでアジャイルに者を作る会社が続々と増えるなんてことはあり得ないでしょう。でも、はてなという会社はそれが正しい方法論だと確信しているし、僕らは、頭でっかちの設計屋が何日もかけて設計するようなやり方よりも、よっぽどすぐれたやり方でやっていると思っています。
方法論として、どちらが優れたやり方か、ということは決定できない。
解決すべき問題領域、実行する組織など、様々な要因によって適した方法論は異なる。
短期間に破棄して新しいものを作り直すような用途であれば、事前の設計に時間はかけられないからプロトタイピングを繰り返して実用可能なものができたら投入する、というやり方でも良い。
一度動かしたらしばらくは停止させない、させられないものであれば事前の設計に時間をかけても構わない。後で止めない、ということのほうが重要だから。
Delphiというのは、単にObject PascalコンパイラにVCLというGUIライブラリとフレームワークを組み合わせた統合開発環境なので、比較するのであればObject Pascalを抜きだして比較するべきか。
Visual Basicがトップにあるのは、抽象的すぎて具体的なことをやろうとすると途端に苦労するあたりとか。Visual BasicもDelphiみたいなもので、構造化BASICにWindows GUIを操作するための文法をくっつけたものなのでこれも言語だけ抜きだして比較するべきかも知れないけども、Delphiと違って高度な統合かがなされているために分離することができない。文法レベルでFormとかButtonが定義されている。フォームやボタンが無い環境には持って行けない。プログラミング言語として考えるとアホかと思う。
GUI構築環境として考えるなら良くできてる。GUIで操作する処理自体はActieXで作り込めば別の言語で作ることもできるし、外に追い出せるのでかなりのレベルで抽象化できる。というか、Visual Basicでできないことは外に追い出さないといけないので、抽象化せざるをえない。
逆に、GUIとイベントを記述するためのアセンブラという見方もできる。
Java、C#、C++あたりは微妙。かなり重複していると思う。C++は、行こうと思えばどこまでも下に行けるのでこの位置か。C#はC++のレイヤまで下に行くことはできないけどJavaとは被る。
Object Pascalは、抽象化というかクラスを構文でサポートとはいっても、使えるというだけで、オブジェクトの寿命は外から管理しないといけない(Txxx.CreateとFreeを呼ばないといけない)。関数のオーバロードがないのでメソッドの抽象化や隠蔽に難がある(オーバライドはできる)。friendが無い。オーバロードは別になくても困らないけどもfriendがないと2つのクラスにまたがる操作をしたいときに片方を片方に押し込めたり無理な実装をするハメになりやすい。
でもproperty構文は便利だなあ。これはC++よりもいい。property構文を使うとメンバに対するsetter/getterをその都度定義できる。a.setValue(5)と書くよりa.value := 5と書くほうが解りやすいし、それでいてsetterとして定義された関数が呼び出されるので代入時に別途処理ができる。a.colorに代入されたら再描画するとか。setterを定義せずにgetterだけを定義すると、メンバ変数がリードオンリとして振舞うのも面白い(定数ではないので別のメソッドからは変更できる)。syntax sugarと言えばそれまでだけど。
シェルスクリプトはどこだろう。C以下という気がする。全然抽象度は高くないように感じるけど、使いこなせるようになったらすごいんだろうか。
行末に移動しようとしてCtrl+Eを押して悶絶する。
GeForce 6800UltraからG70と呼ばれていたGeForce 7800GTXに移行すると通知したとのこと。
GeForce 6800GT/Ultraは慢性的な品不足で、その理由は同一カードを2つ使用するSLIに一端があるとしている。
とりあえず訳。
NVIDIAのユーザは、12ヵ月以内にSLIシステムにアップグレードすることを計画して1枚のGeForce 6800カードを購入した。私が推測するに、ユーザは単にSLIシステムにアップグレード可能なシステムを夢に見ているだけならばいいのだけども、そうでなければ>NVIDIAは7800GTXを既存の6800カードと共存させることを考えなければならないだろう。
もし、NVIDIAが6800シリーズを廃止したら何が起こるだろう。多くの(SLIにアップグレードを計画している)ユーザは動揺し、失望するだろうけども、いつでもeBayからカードを買うことができる。
最後の一文は、「ユーザはeBayからカードを買うといった代替手段を持っている」というような感じなんだけど、そもそも
Many customers bought Geforce 6800 GT or Ultra series and it turns out that those cards are very hard to find right now.
多くの顧客はGeForce 6800GT/Ultraシリーズを購入した。そして、今はそれらのカードがとても見付けにくいということが判明した。
あるので、eBayからでも買えなくなるんじゃないのか。代替のカード、たとえばATiのカードに乗り換えるというのなら解らないでもないけども。
まあ、SLIを計画しているユーザとしては
という選択肢が出て来るわけで、6800の流通が止まらなければ特に問題は無いのではないだろうか。でも、移行するって言っているみたいだしなあ。SLIにするつもりなら早めにやっておけということか。
その噂のG70、GeForce 7800GTXはATiのR520よりすごいとUnrealの中の人は信じているようだ。
君にアドバイスしなければならない。注意して考えろよ、TimとEpicは、NVIDIAと一緒に寝てるんだぜ。
いつも通りのオチ。
しかしWall Street Journalの人はどうしてAppleにIntel製CPUを使いたがらせるんだろう。
これでIntelの製造能力に余裕ができる。超低電圧のPentium Mの供給不足はいまはもう落ち着いているのだろうか。だとしたら更に価格を落してくるかも知れない。
RedHat感覚で/usr/src/linuxでmake; make modules_install; make installするとハマる。
mkinitrdのつくりが違ってて、指定しないと/etc/sysconfig/kernelで指定されているドライバをinitrdに取り込むようになっている。そのためsd_mod.koがなくて/をマウントできないとか素敵な事態が発生する。
面倒だけどmake installはしないで、cp arch/i386/boot/bzImage /boot/vzlinuz-X.Y.ZZZZ; mkinitrd -k /boot/vmlinuz-X.Y.ZZZZ -m "modulesいろいろ" -i /boot/initrd-X.Y.ZZZZというようなことをして/boot/grub/menu.lstを自分で書いた方が良い。
PC WEBはこういう記事を出してくれるから好きだ。
ベンチマークその1でRelease/FullOptで/GSを指定しているのはなぜだろう。あと、基本ランタイムチェックは既定値になっているけども、既定値だとチェックしたような気がする。どうだっけ。
Proc_7()の説明だけども
xor eax, eaxというコードはEAXレジスタの初期化で、条件比較のために0を利用するため、実行している。
というのは誤り。関数の戻り値をEAXレジスタに格納する必要があり、この場合比較結果として不一致(0/False)を格納している。比較結果が一致していた場合にはsete alでEAXレジスタが1になる。
で、本質的な違いは、一旦渡されたパラメータをECXレジスタに明示的に格納させ、次いでそれとEAX(つまり0)を比較するか、それとも渡されたパラメータのポインタの先の値とEAXを直接比較させることで、どのレジスタを使うかCPUに任せるか、の違いである。
これも誤り。
アセンブルコードを見てみると
op code operand move cx, DWORD PTR _Enum_Par_Val$[esp-4] xor eax, eax cmp ecx, 2 sete al ret 0
となっている。cmp ecx, 2とあるので比較はECXと2の比較であってEAXとは比較していない。
また、ReleaseビルドECXレジスタにロードするコードについての解説にあるレジスタリネーミングの解説も誤っている。P6が行なっているレジスタリネーミングはプログラマやアセンブルコードでは見えないレイヤで行なっている。そのため、明示的にECXを指定したところでシャドウレジスタへの割当を阻害するものではない。
言うまでもなく、CPUはメモリの値とレジスタの値を直接比較したりはしない。
これはその通りで、cmp命令で直接メモリを指定するとCPUの内部では「メモリからロード」「内部レジスタに格納」「比較」といったような分解がなされる。
直接比較せずにmoveでECXレジスタにロードするのは、このメモリからロード、というのを明示的に行なうため。Pentiumだとパイプラインが2つあるのだけど、それぞれ一つの命令しか処理できない。直接メモリを指定する命令を発行してしまうと、次のsete命令では比較結果が必要なので比較命令が完了するまで止まってしまう。2つのパイプラインを有効に使えない。だからメモリからのロードを先行して発行しておいて、その隙に別のパイプラインでEAXレジスタを0にする、という流れになる。P6であればアウトオブオーダ実行に頼れるのでこのようなことは考えなくて良い。
XtAppMainLoop()のループ中に別途イベントを起こして起床させたい。
Win32であればMsgWaitForMultipleObjects()でメッセージループと別のイベントのどちらも待機させることが可能なのだけど、XtAppMainLoop()を呼んでしまうととにかく戻って来ないと言うかXのイベント以外はアレしてくれないのでどうにもならない。
XlibでXtのイベントループを書くしかないのか(というかXtAppMainLoop()のソースをコピーして別のイベントにも注意するように書き換えてしまうのが安直だが簡単)こういうニーズを満たしてくれる関数はないのだろうか。
非同期コピー、非同期ファイルリスティングなどを実現するにも、非同期操作の完了をXtAppMainLoop()に通知する手段が必要なんだけども。
Xのイベントで通知するのはなんとなく気に入らない。自分の中で発生したイベントなのに、通知にわざわざXサーバを経由しなければならないというのが。
今のDF170と同じく同期式で作ってしまって様子を見るほうが早いだろうか。
とりあえず作ってしまうというのは簡単だけども、後から気が変わったときに作り直すのは大変だからもう少し設計と言うか作りたいものと手段を整理しないとコードを書けない。
「ヴ」が入力できない。
「う゛」と入力後、cannaのkatakanaを実行すると「ヴ」になる。
それをEnterでkakuteiさせると「ウ゛」になってしまう。
cannaの設定が悪いのかEmacsの設定が悪いのか。
仕様書が私が書いたものとしては認めたくない程に品質がよろしくないので、出勤して書き直す。
某課長のツッコミに耐えられるかどうかは判らないが、このままでは耐えられないこと請け合い。
2GHzで20Wというのは魅力。
でもTransmetaが結局敗退したことを考えるとこの手のCPUは商業的にやりくりできるのかどうかが疑問。
キャッシュが128KBと少ないのが気になるけど、CPUを800MHzにしてFSBと等速にしてしまえば、むしろキャッシュが要らないとか。レイテンシがあるからちょっとはあった方がいいけど。
発表からもう1年か。
ViAはチップセットだけではなくて組み込み用のビデオもあるしIntelのように一社で全部賄えるベンダなので、せっかくだから全部まとめてノートPCの形で出してくれると面白い。
まだ不明な点は多いけども手に付くところをコーディング。
フォントのベースラインが欲しかったのでFontSetからFontStructを得るにはどうしたらいいのだろう、とかしばらく悩んだけども、各フォントでベースラインが異なる可能性がある、というか多分違うことを考えるとFontStructからベースラインを知ろうとするアプローチは誤りなのだろう。
Windowsみたいに、左上座標指定で描画するほうが簡単なような気がする。さすが後発なだけはある。
交易レベル23到達。
戦闘レベルをもう少しあげたい。まだ11だし。というか、25日のアップデートでオープニングムービーが差し替えられていた。謎の鼻歌が無くなってて激しく驚く。この間抜けな鼻歌はなんですか、とか思っていたけど無くなったら無くなったでちょっと寂しい。
銀行の預金が15Mに到達。使わないナオを処分して16Mになるかどうか。工芸スキルが8まできたので、もう少しあげてから会計士に戻ろうか。縫製をあげたい。
しばらくFIVAのXではfbdevを使っていた。こちらだとX起動時に液晶がホワイトアウトしないので気分的に良かった。
vesaだとDPMSがなぜか機能しないのだけど、fbdevだと電源は切れないもののとりあえずブランクスクリーンにはなってくれる。
が、ふと/etc/X11/XF86Configを見たらOptionにDPMSを付けていないことに気が付いた。xset dpmsしても効果は無かったからダメだとは思いつつもDPMSをつけドライバをvesaに戻して再起動。
あれ、Xが起動しない。なんでー?
29日の締めくくり、と思っていたけど日付は変わってしまった。
というわけで昨日書いたもの。300行程増えた。1日300行というところなのか。とりあえずカーソルらしいものが動く。スクロールはまだできない。
再描画させるためにXClearArea()を呼んでいるのだけども、この時の座標指定をWin32と同じだと思い込んでいて右下の座標を指定してしまいちらついてしまいかなり悩んだ。思い込みと言うのはツボに入るとなかなか気づかない。
GCのデフォルトフォントがどう、とか背景色/前景色をどう取得するのかとか知らないことが多すぎる。Win32ならGetSysColor()で取得できるわけだけども、Xだとリソースで個別に設定できるわけだし。いや、どのリソースを参照して色が変わる、というのをこちらで文書化すべきなのか。どっちが先なんだ。
「境界例」と「うつ病」は分けて考えなければいけないらしい。
医者を信用できない患者、信用してくれない患者に苛立つ医師。心の安らぎを与えてくれるのは、医師ではなくて薬。
リストカットなどの自傷行為は、他者へのアピールプレイだと考えていたが、相手を試す意味もある、という考え方も紹介されている。これには思い至らなかった。何のためのアピールプレイなのかさっぱり判らなかったけれども、これなら積極的にキズを見せつけて来るのも理解できる。
でも、じっと待つ、という治療方針ではたぶん医者は信頼されないだろう。彼らは今の生きにくさをなんとかしてほしいのだから。では、積極的な介入をすべきか、というと、それがうまくいくとは限らない。症状が増幅されたり関係が壊れてしまうこともある。それでもやはり、失敗覚悟で何らかの介入をしなきゃ、精神科医はどんどん信頼されなくなってしまうんじゃないかなあ、と医師のはしくれとしては思うのである。
最後の一文が特に深い。
医師も患者も、まずは信頼関係を結ぶことが重要なのではないか、という気になる。
昨晩、某所で「風博士使っている人いる?」と聞いたら、「Windows版があれば使う」という意見が多かった。
でも、僕は思うのだけど、例えば風博士を今のままWindowsに移植しても、誰も使わないと思う。
この2つの「使う」は意味が違う。
最初の「あれば使う」というのは、「あれば試しに使って様子を見てみる」という意味ではないだろうか。この場合、Windows版があれば、即座に乗り換えて使い続ける、という意味ではない。
次の「誰も使わないと思う」というのは「継続して使い続ける」という意味で使っているように見受けられる。
既存のWindows版ブラウザに存在している機能が無いことを理由に誰も使わない
としているようなのだけど、使うか使わないかを決めるのは利用者であって作成者ではない。動作させるためにはGeckoなど付随するものが必要というのもハードルが高いかも知れないが、そのハードルを乗り越えるのも使用者だ。インストーラなどの工夫でハードルを低くすることはできるかも知れないがHDDのスペースを用意するなど、最終的に乗り越えるのは使用者なので、作る側はとりたてて心配する必要は無い。というか、心配しても仕方が無い。少なくとも、別のHDDを買ってきてもらってそちらにLinuxをインストールしてもらうところから始めるよりはよっぽどハードルが低い。
あちらには、ハッパをかけるつもりでちょっと煽るような文章で書いておいたけれども、どっかの誰かと同じものを作ろう、というのであればわざわざ作って他人に見せる意味が無い。たとえばSlepnirをLinuxに移植したとしよう。それをさらにWindowsに移植しよう、というのはナンセンスだ。ネタにはなるけど。しかし、風博士が他のブラウザには無い特徴をもち、それが使用者の心を掴むようなものであれば、他とは違うという一点で存在する価値があると思う。
使う使わないはまた別の話で、他人に使って欲しくて作っているのであれば使ってもらえるかどうかが最優先になるのだろうけれども、作りたくて作っているとか自分で使うために作っているのであれば他人のニーズなんてコーヒーのないクリープ以下だ。
Windows版を作るとユーザからの変更要望が多岐に渡ることも想定され、そのことも懸念となっている模様。しかし、そんなものは切捨てて構わない。「世界で一番美しいものを作った。それがPSPだ」くらいの心意気でt構わない。誰かに頼まれて作っているわけではなく、自発的に作っているのであればなおさら。他人に媚びるようじゃ方針が安定せず中途半端なものになりがちだ。他人の意見に惑わされず、スジを一本通すようなGRADIUSのレーザを心掛けたい。ファミコン版のレーザは筋が通ってない。まるでなっちゃいない。リップルレーザに至ってはなにがどうなってレーザを名乗っているのか小一時間問い詰めたい。
HyperThreadingの脆弱性というのは、仮想CPUコアがキャッシュを共有していることからメモリのアクセスパターンを推測できるというもの。
メモリのアクセスパターンが判れば、規則的なアクセスを繰り返すプログラムの動作が推測でき、このことからもう一方の仮想CPUコアが取り扱っているデータを推測できると言うもの。
けして記事中にあるように直接パスワードが盗めると言うものではない。
カーテンに映った人影を見て、なにをしているか、例えば食事をしているということは推測することはできても、ラーメンを食べているのかカレーを食べているのかまでは判らない。食事の内容を把握するためには、前後の買物の内容を知っておく必要がある。同様に、この脆弱性を使用してSSLの秘密鍵を盗もうとするならば、SSLを処理するプログラムのバージョンなどを知る必要がある。まあ、OpenSSLであれなんであれ出回っているバージョンはそれほど多くないし、おそらく最新バージョンだと仮定できるわけだけど。
また、この手口で盗聴するのであれば盗聴先と同じ物理CPUに盗聴用のプロセスを仕込ませなければならない。これはなかなか難しい。というか、任意のサーバに任意のプログラムを送り込んで、それを実行させられると言う時点でそのサーバの安全性は疑わしいと思う。レンタルのCGIサービスで、Cのような非インタプリタ処理系が使えるところ、というのが狙い目か。
この問題の影響を受けるのはマルチユーザーのサーバだけだが、こうしたサーバは広く使用されている。「最も明らかな例は、大多数の小規模なEコマースサイトが利用している共有ウェブサーバだ。これらのシステムでは、この欠陥は非常に深刻だ」（Percival）
この主張にあるような電子商取引を扱うサーバで、かつユーザから任意のプログラム実行を受け付けるというような設定はあり得ないのではないだろうか。また、共有サーバであるならばキャッシュのアクセスパターンを盗聴しても、共有されているために複数のプロセスが動いているために混信してしまい、アクセスパターンが目標としているプロセスのアクセスパターンなのか判らないのではないだろうか。
それとも、発表していない別の手口があるとか。
個人的に、キャッシュの共用は不具合ではなくて便利な機能だと思っている。仮想コア1が順序良くデータを処理している間、別のコア2が次に使う予定のデータをキャッシュにプリロードしておくことができる。それによりコア1はストールすることなく処理を継続できる。まあ、そのためのfetch命令とかもあるわけだし別のコアでやらなきゃいけないというものでもない。
先日のPC WEBにあったコンパイラの最適化ベンチマークとも言える記事。気になるところがあったので確認のために試してみた。
32ビットベンチマーク(2)で触れられているのだけど、
の二種類を例に挙げている。条件分岐を排除したのがMicrosoftのコンパイラで、条件分岐を用いたのがIntelのコンパイラ。CPUの条件分岐予測をあまり信用していないMicrosoftと自社のCPUの予測分岐回路に絶対の自信を持つIntelとの熱いバトルとも言える。
というわけで、
の3つで試してみた。MediaGX(200MHz)でも試してみたいけども、いまX.orgのビルド中であと6時間ほどかかるので無理。
試してみたコードは次の通り。
mov eax, ecx xor eax, eax cmp ecx, 2 sete al ret
cmp eax, 2 je label1 xor eax, eax ret; label1: mov eax, 1 ret
cmp eax, 2 jnz label2 xor eax, eax ret; label2: mov eax, 1 ret
後ろの二つは、分岐予測をどちらを優先しているのか確認するために行った。分岐予測が完璧ならばどちらでも同じ結果になるはずだ。
とにかく次のようなコードで繰り返し呼び出して計測してみた。
s = rdtsc();
for( i = 0xFFFFF; --i;)
{
for(j = 10; --j;)
test1(j);
}
e = rdtsc();
printf("test1 %d.\n", e - s);
同じバイナリを3つのPCで動作させた結果は次の通り。32回動作させてその平均を記録した。
| PC/分岐 | sete | je | jnz |
|---|---|---|---|
| PCG-SRX3 | 86,200,687.66 | 96,623,407.72 | 105,402,026.60 |
| VGN-T90PS | 69,952,356.50 | 76,540,601.63 | 79,913,028.94 |
| Athlon XP | 99,210,955.84 | 153,748,700.80 | 150,077,299.70 |
seteを100%として消費クロックの比率。
| PC/分岐 | sete | je | jnz |
|---|---|---|---|
| PCG-SRX3 | 100% | 112% | 122% |
| VGN-T90PS | 100% | 109% | 114% |
| Athlon XP | 100% | 155% | 151% |
なかなか面白い結果になった。
また、全体的にPentium Mの消費クロックが少ないのが目につく。Pentium Mだと80Mクロック消費する処理がAthlon XPだと150Mクロックと倍近い勢いになる。またどのCPUでも分岐しないコードの方が速いという結果になった。
一見してVisual C++の方がスマートに見えるが、ここで問題になるのがSETE命令。IA-32 Intel Architecture Optimization Reference Manualによれば、この命令はレイテンシ5、スループット1.5となっており、もっと遅い命令は幾らでもあるから、極端に遅いとは言えないまでも、それほど速くもない。それならjeで条件分岐を行ってもそれほどペナルティは無い(というか、この程度の範囲なら分岐先は両方とも命令キャッシュに格納されている)から、むしろste命令の結果が出てくる6.5クロック分、処理が待たされるよりも分岐させるほうがトータルで高速という判断がなされたと思われる。ドラスティックに違う訳ではないにせよ、Visual C++よりも一歩踏み込んだチューニングがなされている結果がこの性能向上に繋がっているのではないかと思われる。
記事中ではsete命令を使わないことを示してIntelのほうがチューニングが進んでいるとしているが、計測してみるとこのような結果となった。
私はPentium 4は持っていないのでPentium 4ではどうなのか解らないが、Pentium 4では逆の結果となるのかもしれない。しかしパイプラインが倍の長さになることを考えると、Pentium Mよりもヒドイ結果が予想される。実際の所はどうなのか楽しみだ。
特訓を動かして、もっと弾がでないとダメだ、と思い立ちmake。
するとwasmがemmsを受け付けてくれなくてハマる。少なくともWatcom C/C++ 11.0J付属のwasmなら受け付けてくれるのだけど、OpenWatcomの1.3付属だとアウト。理解できない。
何がいけないのか調べたもののさっぱり見当がつかず、とりあえずOpenWatcom 1.2付属のwasmを取り出してみたらこれだとアセンブルしてくれた。
1.3だとダメなのか。なんでだろう。
ここで手間取ってしまったので弾を増やそう計画は延期。