TidBITS-J#472/22-Mar-99 TidBITS-J#472/22-Mar-99Power Mac G3 はどのくらい高速なのだろう? 特集記事で、Rick Holzgrafe 氏が、スピードについて熟考し、彼が 20 年に渡りさまざまなコンピュー タで実行してきたシンプルなプログラムを紹介する。G3 と Cray Y-MP と の比較をご覧あれ。今週号ではまた、Adam が TidBITS や TidBITS Talk の冒頭で見ることのできる新しいメールリストヘッダについて検証する。 ニュースでは、Apple による Mac OS X Server と QuickTime for Java 公 開ベータ版のリリース、また Darwin で Apple がオープンソースの時流に 乗るという話題を取り上げる。
目次：
Copyright 1997 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。
TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。
今回の TidBITS のスポンサーは：
（翻訳：高島 均 <mailto:hitak@kk.iij4u.or.jp>）
Apple 社が Darwin Open Source Project を発表 -- 先週、Apple は、 Mac OS X Server の基盤レイヤのソースコードを Darwin と呼ばれる初の オープンソースを通じて入手できるようにする予定だと発表した。Apple Public Source License に同意するデベロッパーは、Apple に登録してソー スコードにアクセスすることができる。このソースコードには、Mac OS X Server で Apple が拡張した Mach 2.5 マイクロカーネルに加え、 AppleTalk、HFS Plus ファイルシステム、新しい NetInfo 配給データベー スなどのいくつかの Apple の技術が含まれだろう。Apple によれば、その オープンソース提供物にはさらにソフトウエアを加える予定とのことだが、 Apple の飯の種である技術（現行の Mac OS、QuickTime、WebObjects、 NeXT アプリケーションレイヤなど）のソースコードがオープンソースとし てリリースされるなどと期待してはいけない。Darwin のソースコードは、 4 月の早い時期にはデベロッパーに提供されるはずだ。Darwin がデベロッ パーにとって真に有益であるのか、はたまた Apple が単にオープンソース の波に乗ってみただけなのか、現段階ではまだわからない。この問題につ いての TidBITS Talk での議論にご注目あれ。[GD]
<http://www.opensource.org/>
<http://www.apple.com/darwin/>
<http://www.publicsource.apple.com/apsl.html>
<http://db.tidbits.com/getbits.acgi?tlkthrd=629>
Mac OS X Server 出荷 -- Apple は先週、Mac OS X Server を出荷した。 これは、高機能サーバ用途向けの、Unix ベースの新しいオペレーティング システムである。以前 Rhapsody のコードネームで呼ばれていた Mac OS X Server には、人気のある Apache Web サーバ、Apple の WebObjects、 最近の Macintosh モデルを NetBoot で遠隔ブートする機能、高性能な Java 仮想マシン、DNS や Apple File Protocol のようなネットワークサー ビス、Web ベースの管理機構、そして、これまでどおりの Mac らしいユー ザーインターフェースを搭載している。（詳しくは TidBITS-462 の“新 型 iMacs、新型 G3s、そして Mac OS X Server”を参照。）Mac OS X Server は、Mach 2.5 マイクロカーネル上で BSD Unix 4.4 を走らせ（こ の 2 つによってプリエンプティブなマルチタスキングとプロテクトメモリ が提供される）、さらに、もともとは NeXT 社から獲得したアプリケーショ ン技術を搭載している。Mac OS X Server には、通常の Mac OS アプリケー ションの実行を可能にする Blue Box アプリケーションレイヤが含まれて いるとのことだ。ただ伝え聞くところによれば、Blue Box は、Mac OS X Server をワークステーションのように振る舞わせたり、あるいは現行の Mac OS サーバソフトウエアを実行させたりすることを意図したものではな いらしい。デベロッパーによる Mac OS X Server のサポートは高まってい る。企業のいくつかは、すでに Mac OS X Server 用プランを表明している し、間違いなくもっと多くの企業が続くことだろう。Apple は Mac OS X Sever を 499 ドルという思い切った価格に設定し、これでクライアント数 無制限のライセンス付きだ。Apple ではこのほか、Mac OS X Server をプ レインストールした 400 MHz G3 ベースのサーバ機を 4,999 ドルから販売 している（Apple によれば、これは 5000 ドル以下で買える最も高速な Apache サーバプラットホームとなる）。[GD]
<http://www.apple.com/macosx/server/>
<http://www.apache.org/>
<http://db.tidbits.com/getbits.acgi?tbart=05235>
QuickTime がカフェイン増量 -- Apple は本日、QuickTime for Java の 公開ベータリリースを発表した。これにより、QuickTime の射程範囲が、 Mac OS であろうと Windows であろうと Java で書かれたあらゆるアプリ ケーションにまで大きく広がることとなる。今のところ、QuickTime for Java に興味を示すのはデベロッパーだけだろうが、Java サポートは、 Apple の QuickTime 普及戦略のゴールへ向かう重要なステップである。 QuickTime for Java には、まず、MRJ 2.1（Windows Java Runtime Environment なら JRE 1.1.x もしくは 1.2）と QuickTime 3.0.2 をイン ストールしておく必要がある。QuickTime for Java インストールページか らリンクをたどってほしい。[ACE]
<http://www.apple.com/quicktime/qtjava/>
by Adam C. Engst <ace@tidbits.com>
（翻訳：尾高 里華子 <rikako@pobox.com>）
メールの仕組を初心者に説明する時、私はメールのヘッダのことを「一番 上にぐっちゃっとあるもの」と呼んでいる。それは我々人間にとって簡単 に消化できないものだからだ。ヘッダは、すべてのインターネットメール のメッセージの前にあり、数行の文字列から成っているもので、メッセー ジに関する情報を記述する役目がある。Date、From、Subject、To といっ た人間が判読できるヘッダのことはお分かりだろうが、Message-Id、 Content-Type、Received といったわけの判らない部分は見たくもないと 思っているだろうし、禁断の領域であるかもしれない。これら難解なメー ルのヘッダは人ではなくメールプログラムが判るように作られたものであ り、そのため、メールプログラムはわけの判らないもののトップクラスに 属しているヘッダを目に見えなくすることが多い。
しかし、99 年の年明けから TidBITS および TidBITS Talk で新しくちょっ と変わったメールヘッダを使い始めたことに気がついた方もいるだろう。 そのほとんどが最近普及しつつあるインターネットの標準で、私はそれら を「リストヘッダ」という総称で呼んでいる。これらリストヘッダは人間 が読んで判るもので、メーリングリストに入っている者にとって役に立つ 情報が含まれているうえに、もちろんメールプログラムにも判読でき、こ れを利用すれば登録してあるメーリングリストの管理がやりやすくなる。
<http://www.ietf.org/rfc/rfc2369.txt>
<http://www.ietf.org/internet-drafts/draft-chandhok-listid-03.txt>
ヘッダに注目 -- リストヘッダは標準化されており、メールプログラム はこのヘッダを考慮することから始めればよい。怠惰なデペロッパーがま ずサポートしてくれるのは、このリストヘッダを隠すことであろう。なぜ なら、すべてのメーリングリストのメッセージにこの数行のヘッダが付い てしまうからだ。このヘッダの便利な活用法としては、メッセージにリス トヘッダが添付されている際に、Unsubscribe メニュー項目が利用できる ようにすることだろう。そして、メーリングリストの購読に関する情報を 突き止め、ボタン一つでリスト全部またはその内の一つを購読中止でき、 メーリングリストのメッセージを自動的にフィルタをかけてくれるような インターフェースがあればさらに良い。このぐらいの機能がそろって初め て、メールプログラムがリストヘッダの機能を処理してくれるといえるの で、ヘッダを目に触れなくなるようにしてもよい。
また、メールプログラムがリストヘッダを直接サポートしてくれるように なる前でも、このリストヘッダは普通の人が自分でメーリングリストの申 込関連の処理を楽に行う助けになる。TidBITS で使っているリストヘッダを 一つ一つについては以下で説明するが、このヘッダには URL が含まれてい るので、リストヘッダの URL をクリックすることで、それぞれの役割であ る、リストの購読中止をするとか、ヘルプを取ってくる、リストのオーナー にメールを送るなどといったことができる。さらに、リストへの参加方法 を誰かに教えてあげようと思ったら、List-Subscribe ヘッダの URL をそ の人に送ってあげればよいのだ。
ヘッダ一覧 -- では、TidBITS で使用しているリストヘッダを一つずつ 見ていこう。そして、他のリストが採用するかも知れない理由と使いたが らない理由を考えよう。順番というものはなく、私たちは見て分かりやす いように単に長さ順にしている。
List-URL: <http://www.tidbits.com/> List-Archive: <http://www.tidbits.com/search/> List-Subscribe: <mailto:tidbits-on@tidbits.com> List-Unsubscribe: <mailto:tidbits-off@tidbits.com> List-Help: <http://www.tidbits.com/about/list.html> List-Owner: <mailto:editors@tidbits.com> (TidBITS Editors) List-Software: "ListSTAR v1.2 by StarNine Technologies, Inc." List-Id: "TidBITS Setext Distribution List" <setext.tidbits.tidbits.com> List-Post: <mailto:tidbits-talk@tidbits.com> (Discussions on TidBITS Talk)
TidBITS Talk では次のようなヘッダもある。
List-Digest: <mailto:tidbits-talk-digest@tidbits.com>
リストヘッダの使用について 正直なところ TidBITS と TidBITS Talk でリストヘッダを採用した理由としては、この標準化を奨めている人達の 一部と知り合いだというところが大きい。彼らはリストヘッダをサポート するようにと私たちを熱心に勧誘し、TidBITS と TidBITS Talk 用に最も 適したヘッダ群を作ろうとしている時に私の質問に答えてくれた。私たち の特殊な事情はさておいても、リストヘッダのことを考えてみるべき 4 種 類の人達がいる。メーリングリストを運営している人、メールプログラム を書いている人、メーリングリストのプログラムのデベロッパー、そして メーリングリストに申し込みをする一人一人である。
メーリングリストを運営しているすべての人が適切なリストヘッダを付け るよう奨めたい。ヘッダを作るのは難しい話ではないし、たいていのメー リングリストプログラムはカスタムヘッダを付けられるようになっている。 リストヘッダを作るのにかけた時間と努力が、TidBITS と TidBITS Talk の登録者が登録の管理をより簡単にできるようになるという形で報われる を期待している。
メールプログラムのデベロッパーは、リストヘッダのサポートを最適に組 み込む術を考え始めるべきだ。これらリストヘッダを元にメーリングリス トの登録を処理するインターフェースのあるツールの初期バージョンのも のを一つ見たが、本当に素晴らしいことだと思う。リストヘッダのサポー トしたものがたくさん出てくるまでは、サポートしたメールプログラムは それを機能リストに付け加えることができるのではないだろうか。
メーリングリスト管理プログラムを作成しているプログラマーはたいして することはないだろう。カスタムヘッダの機能はすでに一般的なものになっ ているのだから。しかし、リストヘッダを作成する手間はもっと簡単にな るようになるべきで、そうなればリストヘッダを使おうかという人が増え るだろう。
個人ユーザーの方には、一度リストヘッダというものを眺めて、こんなも のがあるんだということを覚えておいて頂きたいと思う。そうすれば、削 除してしまったメッセージに書かれていた情報を検索したい時は List-Archive ヘッダを、リストから外れたい時は List- Unsubscribe ヘッ ダを利用することができる。
長年いろいろと見てきているが、メーリングリストプログラムはユーザー にとって難しいものであるし、その処理を改善してくれるものはインター ネットコミュニティの利益になる。
by Rick Holzgrafe <rick@kagi.com>
（翻訳：尾高 修一 <shu@pobox.com>）
（ ：亀岡 孝仁 <tkameoka@fujikura.co.jp>）
Cannonball Express はかつて高速を誇った列車だ。あまりにも速かったの で、3 人の男がそれぞれ「来るぞ」「来たぞ」「行ったぞ」と言わなけれ ばならないほどだったという。コンピュータも高速なものだが、列車とは 違って自力では動けないものがほとんどだ。ではコンピュータを高速にし ているものは一体何で、ソフトウェアの設計はどれほどの影響を持つのだ ろうか? 今日のコンピュータは一昔前のものよりもどれだけ速いのだろう ? 最近私はこういった疑問に再度取り組んでみた。まずは古い記憶をたど ることから始めた。
先史時代 -- 20 年前、私は独学でプログラミングを学んでいて、夜間や 週末には DEC PDP-11/60 ミニコンピュータを使うことができた。こいつは 洗濯機よりも大きな代物で、平日の昼間には 20 人以上の技術者やエンジ ニアと共用していたのだ。ある日雑誌で言葉を使ったパズルを見つけたの で、こいつを PDP で解くプログラムを書いてやることにした。そのパズル とは以下のようなものだった。
方眼紙と一つの文を用意する。方眼紙にその文を以下のルールに従って書 き込んでいく。
方眼紙の桝目一つに一つの文字を書く。クロスワードパズルの要領だ。 大文字・小文字の違いやアルファベットの 26 文字以外のものはすべて無 視する。たとえば、“N. 1st Street”は“NSTSTREET”と全く同じことに なる。
文の最初の文字をどこでも好きな桝に書く。
続いて次の文字を最初の桝に接した桝に書く。ここで“接している”と いうのは、上下左右に加え、斜めにあるものも含まれる。もし接していて 必要な文字で埋められている桝があれば、それを再利用することもできる。 そうでない場合は空いている桝を使わなければならない。同じ桝を連続し て使用することはできない。同じ文字が連続している場合もだ。
最終目的はできるだけ小さな四角に収まるように文を書き込むことだ。 （微妙な点だが、できるだけ少ない桝目を使うということが目的なのでは ない。）得点を出すには、できるだけ小さな四角の面積を計算する。空の 桝目があった場合にはそれも含める。
お判りいただけただろうか? 桝目を徹底的に再利用することができるため、 早口言葉を使うのが一番おもしろい。“Peter Piper picked a peck of pickled peppers”に含まれる 37 文字は、3 x 5 の四角に収めることがで きる。こんな感じだ（等幅フォントでご覧頂きたい）。
OFIPT KCPER LEDAS
当時、私はコンピュータが“高速”なのは知っていたが、どのくらい速い のかは全く見当もつかなかった。ところが実はたいして速くないというこ とがわかったのだ。このパズルを解くプログラムを作り、早口言葉にちな んで Piper と命名した。金曜日の夜に Piper に適度な長さの文を与え、 月曜日の朝に見てみたらまだ動いていた。ベストとはいえない答えはいく つか見つけていたのだが、まだ処理が終わってはいなかったのだ。これで はいくらなんでも遅すぎる。自分で紙を使って解いてみたら 30 分でもっ と良い解にたどりついた。
どうしてこんなに時間がかかってしまったのだろう? Piper は“力任せ” 型のプログラムだったのだ。問題を解くために可能性のある解をすべて次 から次へと試してみる。ここで問題は可能な解の数が多すぎることにある。 文によって実際の数は変わるが、よほど単純なものでない限り選択枝は天 文学的な数字になる。この時私は初めて“高速”が必ずしも十分なスピー ドではないことに気がついたのだ。誰もがコンピュータを使い、遅さに嫌 気がさしている今日、この点は自明なことのように感じられる。だが 1979 年当時、この PDP-11 は私が目にしたわずか 2 台目のコンピュータだった のだ。
速さの秘密? 私は Piper の高速化に取り組まなければならないと感じ た。プログラムを速くするには 2 通りの方法がある。案 1 は問題を解決 するもっと良い方法を見つけることだ。だが、20 年たった今でももっと良 い方法は思いつかないでいる。そこで残されるのは案 2 で、古典的な能率 化の方法、つまり不要なステップを省くことだ。たとえば、Piper は可能 性のある解をすべて用意し、続いてそれぞれが必要とする面積を計算して いたのだ。どの解も文字を一つずつ置いていくので、完成した解の面積を 計算するのではなく、文字を一つ置いた時点で面積を計算するように Piper の仕様を変更した。こうすれば作業中の解がそれまでに発見した最もコン パクトな解よりも大きくなることが確実になったら、Piper はその解（と 途中まで同じ解）はすべて飛ばして次のものに進むことができる。これで 作業量を大幅にカットすることができ、Piper のスピードアップに大いに 貢献した。処理中の解の面積を記憶しておく賢い方法を発見したことも役 に立った。文字を置くたびにゼロから面積を計算するよりも速いからだ。 また、すばやく可能な最小の解を計算することもできた。ベストの答えが これほど小さくなるとは限らないものの、これ以上小さくはならないこと は確実だ。もし運良く Piper が理論的に可能な最小の解を突き止めたな ら、この時点で処理を中止することができる。こうしなかったら、もっと 良い解を求めて Piper がむだな努力を続けることになる。
ついには最初に挙げた文をそこそこの時間で処理できるぐらい Piper は優 秀になった。だが、私が追い求めていた究極の文、“How much wood would a woodchuck chuck if a woodchuck could chuck wood?”に対する答えは 得られずじまいだった。PDP（とおそらくは私の知恵）では力不足だったの だ。Piper を高速化するアイデアは出し尽くしてしまったが、それでも週 末だけでは処理しきれなかったのだ。だが、Piper をこれ以上改良するこ とはできないとしても、もっと速いコンピュータを使うという可能性は残 されている。
巨大な鉄の箱 --人々はプロセッサ速度をコンピュータの速度とみなす傾 向がある、しかし多くの要因が総合性能に影響を及ぼすのである。仮想メ モリーは、一度により大きなデータセットまたはより多くの問題を扱える 様にするが、速度は遅くなる。そこで、物理的に RAM を増設することで仮 想メモリーへの依存度を減らすことが出来る。より速いディスクと I/O バ スによってデータをより速くロード、保存できる。RAM ディスクとディス クキャッシングは、遅いディスク動作を稲妻の様に速い RAM アクセスに替 えてくれる。特別な超高速 RAM に使われる命令セットとデータキャッシュ は、ある種のプログラムに対しては大きな改善を示す。よく書かれたオペ レーティングシステムとツールボックスは、出来の悪いものより速度が速い。
しかし、結局はこれのどれも Piper にとっては重要でない。Piper は常に 少量のデータだけを使い、一旦動き出せばディスクの読み書きはしないし、 いかなる種類の I/O もほとんどない。その小さいコードとデータセットの お陰で Piper はデータと命令のキャッシングを生かすことが出来るが、し かし本当に必要とするのは“より速いハムスター”- より速く車輪を回転 させるより速いプロセッサである。
この間、私は私の最初の Mac 上で Piper のいろいろなバージョンを走ら せた、そして 1980 年代のなかばに、私は Apple Computer 社で働いてい て、プログラマの夢へアクセスする機会があった：Apple 社の当時の 15,000,000ドルの Cray Y-MPスーパーコンピュータである、世界の中でも 2 ダースあるかないかで論議はあるかも知れないが最も速いコンピュータ と言えるものであった。私は Cray ならば Piper などものの数ではないだ ろうと想定した。しかし、Cray はこの問題には適していなかった。それは 並列処理方式の浮動小数点マトリックス計算を使ってなら Cannonball Express の様に飛ばすことは出来たが、しかし Piper は高度に線形の、非 数学的問題であった。Piper は Cray の持っている 4 台のプロセッサのう ちの 1 台しか使わず、Cray が得意とする様な処理は使えなかった。Piper は Cray のパワーの公平なテストでなかった、とはいっても Cray は私が これまでに使った最も速いマシーンであった。Cray は、それまで全てのマ シーン（あの PDP、私の Mac Plus、私の Mac II）が失敗したことを成功 裏にやってのけた。“ウッドチャック”を 1 日未満で解いたのだ、計算完 了におよそ 20 時間しかかからなかった。私は、畏敬の念にうたれた - 20 時間?! 私には“ウッドチャック”が それ程 大きい問題であるという認 識はなかったのだ！
力を秘めた若造 -- その後、私は長いこと Piper を放ったらかしにして いた、しかし最近、私は最近のデスクトップ機がこれら昔のミニコンピュー タやメインフレームとどのぐらい戦えるのか興味を持ち始めた。私は記憶 をたどって Piper を書き直して、“ウッドチャック”を私の新しい氷ブルー 色の 400MHz Power Macintosh G3 上で走らせてみた。結果は以下の通り。 Piper は最初にフレーズをそのまま印刷し、次に解答が見つかればその解 答と経過時間を印刷する。個々の解答は見つかった最善のもので、しかも それまでの最善のものを越したものである。時間はランを開始してからの 秒数である；最後の時間は、全ランタイムである。（あいにく、“ウッド チャック”の最善の解答は Piper の計算上の最小解答サイズを越えていた ので、Piper は最善の解答を見つけた後も少しだけ走り続けた）
これが結果である。分かり易くするためいくつかの中間解答はそのまま残 しておいた、Piper がさらに小さい解答を見つけていくのがおわかり頂け ると思う。最終的には、“ウッドチャック”の中の 57 文字は 4 x 4 の長 方形に詰め込まれた。Piper の全ランタイムを、そして最善の解答を見つ けるまでの時間を見て欲しい：
How much wood would a woodchuck chuck if a woodchuck could chuck wood?
0 seconds:
ULD ADLU
HDOAIUCOHWUHOD
UCOWFKHDOMCWOW
K WO
1 seconds:
DLIFADLU
UCKOHWUHOD
OHDWOMCWOW
2 seconds:
ULCHC
HWUHODKUK
OMCWOWAFI
7 seconds:
HWUHOW
OMCWOD
IKAUCW
FLDHK
9 seconds:
HWUH
OMCW
LUOK
HDOI
CWAF
65 seconds:
HWM
OUC
IKH
FWC
ADO
LUO
67 seconds:
HWMU
OOCH
UDWK
LAFI
Total run time: 107 seconds
如何ですか：最善の解答を見つけるのに 1 分とちょっと、そのランを終え るのに 2 分未満である。たったの2分！1980年代の巨大な鉄の箱の手に余っ たものが。私の新しい G3 Mac は、あの 1,500 万ドルの Cray より 600 倍以上も速く“ウッドチャック”をやってのけた（そして、5,000 倍も安 い）。（より現実的な比較のためには、UCLA の Project Appleseed の記 述を参照。）
<http://www.apple.com/education/hed/aua0101/appleseed/>
自分の Mac の上で Piper の速度をチェックしたい人のために、コードを 以下に載せました；それは 40K のパッケージです。
<ftp://ftp.tidbits.com/pub/tidbits/misc/piper.hqx>
将来 -- 次に来るものは何か？400MHz は、すでに少し元気なく見える。 それは今日最高の Apple 製品である、しかし、私は第三者アクセラレータ で 550MHz ぐらい出せると言うのを見たことがある - そして時計は進み続 けている。近い将来に 1 GHzの（1,000MHz）チップを予測している人もい る。バスもより速くなっているし、そしてキャッシュはより少ないスペー スの中により多くのデータを保持し、さらにプロセッサチップ上に搭載す る事で更なるスピードを求めている。（小さい事は速い事である。光の速 度が現代のコンピュータ設計の中の重大な制限因子であるということを知っ ていますか？構成要素間の距離が近ければ近いほど、互いにより速く交信 できる。）
そして昔の Cray のように、マルチプロセッサデスクトップシステムは、 現れ始めている。これらは一つの問題を解くのに、その問題をバラして別々 のプロセッサ上で同時に処理することで団結して対処するのである。私は Cray の余分なプロセッサを使おうと試みなかったけれども、最近少しこれ について考えてみた。Piper は完全に線形である必要はない。私は 8- プ ロセッサシステムの上で、一つのプロセッサでの所用時間の 1/8 の時間で 動く Piper を作れる自信はある。
用意はいいですか？
来るぞ - 来たぞ - 行ったぞ！
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
｜ 
｜ 