XWIN II Weblog

巴里より帰る──写真整理編 V

今回も前回に引き続き。写真整理も終わりつつあるので、今回が一応の写真整理編最終回。コメント等は後刻追加します（と記したのが9月28日）。で、今回追記したのが10月14日（汗）。

シャンゼリゼ大通りに面するL’Alsaceのオープン店舗（部分）。我が国では、道路に店を出すというのが憚られるが（というか法違反。無論例外あり）、パリといわずに西洋では当たり前に見られる光景。L’Alsaceはパリに赴いた際、行くことが多かったが、今回は前を通っただけにとどまった。

オペラ座の館内見学には日本からの観光客が多いところの一つである。よって、このように6か国語の中の一つに含まれている。この日はたまたまリハーサル中で舞台見学はできなかったが、にもかかわらず見学料金は変わらないということだったので、中には入らなかった。

イノサンの泉。この日は晴れた日曜日ということもあって、多くの人たちが集まっていた。このすぐ近くには仏国王アンリ4世が暗殺された場所もある（この下文で紹介）。

フィリップ・オーギュスト（フィリップ2世）の城壁（市壁）跡の中でも有名なところの一つ、クローヴィス通りに残るもの。この道路自体も古いもので、ここに門の一つがあったことが城壁跡からも伺えるだろう（上部は壁が崩れているが、下部は整っている）。

リュテス競技場跡。ローマ時代の遺跡だが、特に入場制限などもなく単に公園（広場）的な利用がされている。私たちが行ったときには、子供たちがミニサッカーを楽しんでいた。

アンリ・ガリ小公園（Square Henri-Galli。スクウェア アンリ ガリ公園とする訳もあるが、Squareが小公園という意味合いなので微妙な表現）内にあるバスティーユ牢獄（要塞）の基盤の一部（遺構）。こんな所にあるのか、という意外性もあるが、それ以上に不可解なのがこの説明板のところまで行く出たてがない（柵を乗り越えるなど不正な方法なら可）。仕方がないので、望遠にして撮影したのが次の写真。

パリ市の船マークが付いている説明板。
VESTIGES DES FONDATIONS
DE LA BASTILLE
TOUR DE LA LIBERTE
DECOUVERTS EN 1899
ET TRANSPORTES SUR CET EMPLACEMENT
と読める。

あいにくヴァスチーユ要塞について詳しくないので何とも言えないが、文面からは自由の塔（TOUR DE LA LIBERTE）とあるので、8つの塔の一つがそういう名前だったのだろう（あまり似つかわしくない名前なので誤訳の可能性あり）。その塔の土台が1899年に発見され、ここに移されたとある。
ただ、まぁこれは知っていなければ単に通り過ぎるだけ、の場所でしかないのだが…。

そしてこちらもフィリップ・オーギュストの城壁（市壁）跡の一つ（写真右側）。正面に見えるのはサン・ポール=サン・ルイ教会。しかし、城壁跡は重要な文化財だと思うのだが、ご覧のように隣接する運動場があり、城壁跡にサッカーボールを蹴り飛ばしている子供たちがいた。そういう扱いでいいのかもしれないが…、う～む。

ブルボン朝最初の仏王アンリ4世が暗殺された場所、フェロヌリ通り（Rue Ferronnerie）。イノサンの泉の近くにある。場所を示す石板が写真左上（アーチ上方）にあるが、目線の高さよりも上にあるので、なかなか気付きにくい。

それを示す石板。
EN CE LIEU
LE ROI HENRI IV
FUT ASSASSINE PAR RAVALLAC
LE 14 MAI 1610
とある。

さらにパリ市の説明板（Historie de Paris）。これが目線の高さにあるおかげで、何とか見逃すことは免れることができる。

というわけで、ようやくコメント等が追加できました。

巴里より帰る──写真整理編 IV

今回も前回に引き続き、写真の整理。今、記録用の旅行記も書いているのだが、はっきりいって「いわゆる観光地」にあまり行っていないことに今さらながら気付いている（写真にはおさめたが、眺めた程度というのも多い）。シャンゼリゼは一回のみ。凱旋門は遠くからは見たが、近くまで行っていない等々。ま、観光にはそれぞれの形があるということで──。

これは、ジョルジュ・ブラッサンス公園（Parc Georges Brassens）内にあるシアターパンチ（THEATRE POLICHINELLE）の案内。パンチとジュディの人形劇を上演するという案内か？ 公園内にある小施設内で行われるというのが、いかにも伝統的といった趣を感ずる。

そしてこちらは、見てわかるとおりのトイレはこちら的案内看板。シャンゼリゼ大通りを歩いていて見つけたものだが、しっかり日本語対応である。が、しかし、最近多いとされる中国人観光客向けの対応はまだのようだ。今回、10日ほどの滞在で強く感じたのは、中国人観光客の多さだが、実際、私も何度となく中国人か？みたいな形で対応されたことが多かった（ニイハオと挨拶されたり、チャイニーズ？と聞かれたり等々）。さて、写真の話に戻るが、パリはトイレ地獄であるので、特に女性にとってのトイレ確保は厳しいものがある。公衆トイレのお世話になるにも有料対応は当たり前だが、さすがにシャンゼリゼ大通りでは1.5ユーロという破格の価格（普通は1ユーロしない）。ちょっと様子をうかがったところ、行列ができており、しっかり稼いでいるなぁという思いを強くした（藁慰）。

続いては、いわゆる切手市。シャンゼリゼ大通りの裏通りにあたるガブリエル通り（Avenue Gabriel）の歩道を半ば占拠するような形で、切手や古い手紙などが販売されている。写真に見えるような簡易な小屋的なものから、車をそのまま販売小屋的に利用しているものまで様々。しかし、まだ開店直後らしく人通りは私を含め数人程度。とてもではないが、店頭を見る雰囲気ではなかった（売り込み攻勢をかけられるため）。

こちらはオペラ座近くにあるエドワード7世通り（Rue Edouard VII。なお、仏語は英語の綴りEdwardとは異なる）。いわゆる歩行者専用の道路だが、パッサージュとは趣が異なっている。統一されたデザインによって、なかなかいい雰囲気である。

エドワード7世通りを進んでいくと、馬上のエドワード7世像が立っている広場に出る。エドワード7世は、自称ナポレオン3世の息子というだけの親仏家であり、長年パリに滞在していたこともあってか、なかなかにいい待遇に置かれているような印象だ。

これはちょっと場所は忘れてしまったが、あるショップのショウウィンドウにあったカラフルなパンツ。こういうパンツをパリの方々はお好みなのだろうか。

こちらは、リュクサンブール公園内にあるメディシスの泉。ここは木々に囲まれた常に木陰のできるところで、ベンチ（椅子）もそれなりに用意されていることから、一休みするには格好の場所。

同じくリュクサンブール公園内。この日は天候に恵まれ、青空と緑のコントラストが素晴らしかった。遠くに見えるのは通称モンパルナスタワー。至るところから見えるのが、良くもあり悪くもありだ。

そしてこちらは、サン・ジュヌヴィエーヴ教会内に鎮座する聖ジュヌヴィエーヴの石棺（をゴージャスな装飾が包む）。聖ジュヌヴィエーヴはパリを守った事で知られる古い聖人に列せられた女性であるが、観光客はこの石棺の中をのぞき込もうとするという何とも恐れ多い行為を平然と行っていた（苦笑）。写真を撮るのも見たようなものかもしれないが…。

続いては、モスケ・ド・カフェでの一休み。ここはイスラムの楽園をイメージしているためか、やたらと鳥が多い。そしておそろしく人慣れしている。茶には興味はないようだが、菓子を用意するとテーブルの上までやってきて、隙あらば奪おうという姿勢がありあり。

鳥つながりで、こちらはシテ島で毎週日曜日に開催されている鳥の市、での一コマ。これは鳥の餌専門店で、大きな袋入りのものから小さなものまで、様々な種類の鳥の餌が販売されていた。

そしてもう一つ、鳥の市の様子。写真はカナリアの一種？と思われるが、多くの鳥たちのほか、ネズミ（ハムスター）やウサギなどの小動物も販売されていた。多くの店は先の写真の鳥の餌専門店のように専門店化が進んでいて、ケージ（かご）だけを扱う店やネズミだけを扱う店など、好きな方であれば半日近くは楽しめるのではないだろうか。

といったところで、今回はここまで。

巴里より帰る──写真整理編 III

今回も前回の続きです。時間がないため、取り急ぎ写真のみのアップ。コメントは後刻つけます。

と、いう流れで後刻となりました。これからコメントと追加の写真を追加します。

パリのメトロはそのほとんどが第二次世界大戦前に敷設されたもの（そして半分程度は第一次大戦前に敷設）であり、地下鉄としての歴史は古い。そのためか、我が国のような統一的な駅名版を採用せず、駅によって違いが多く見られる。今回の旅行ではあまりメトロに乗らなかったが、それでも何駅かの写真は撮ってきた。そんなわけで、メトロの駅名版をいくつか見ていこう。

まずは「パレ・ロワイヤル = ミュゼ・デュ・ルーヴル駅」（Palais - Royal  Musée du Louvre）。私が初めてパリに訪れた時は、確か単にパレ・ロワイヤル駅と表したような気がするが、とにかく長い駅名である。が、メトロの中ではそれほど長いわけではない。メトロの駅名表記の基本はこのタイプで、濃い青（群青）系のバックに白いゴシック体の文字となっている。そして白タイルだ。

続いては「モンパルナス = ビヤンヴニュ駅」（Montparnasse  Bienvenüe）。パリ南部の交通の要衝であるので、乗降客も多い。ここは、基本タイプに類似だが、周囲が白く囲われているのが異なる点である。

続いては「コンコルド駅」（Concorde）。ここはなかなか洒落た感じで、フォントが異なるだけでなく、白タイルにも文字が乱舞する。ただ、すべてがこうなっているわけではなく…

こちらのように、基本タイプに似たようなものもある（ここは路線毎に違う）。ただし、白タイルの形状と素材が異なっているのがポイントか。

そしてこちらは「ラマルク = コランクール駅」（Lamarck - Caulaincourt）。白タイルは基本タイプを踏襲するが、駅名表示は配色は同様だが、タイルとなっているのが大きく異なる。また、周囲に茶色系のデザインタイルが配置され、なかなかいい感じである。これも駅名は長い方だが、遠目に字が小さくて見にくいからか、

このように「LAMARCK」と最初の方だけを記したものもある。いっそのこと、駅名を短くすればいいのに、と思ったりもするがそう単純な話でもないのだろう。

こちらは「アベス駅」（Abbesses）。モンマルトル観光の出発点ともいえる駅なので、乗降客が多い。先ほどの「ラマルク = コランクール駅」の隣駅の関係か、駅名表記のデザインは似たものとなっている。

さらに「アベス駅」に続く「ピガール駅」（Pigalle）。こちらは基本タイプなのだが、上写真は駅端にある駅名表示。何やらとってつけたような印象大だが、横に大きな広告が配置されているため、このあたりにも駅名表示をしておかないとまずいという、RATPの判断なのだろう（苦笑）。

続いては「Saint Georges」（サン・ジョルジュ駅）。やや基本タイプに近いが、駅名表示の周囲に緑と白の縁取りがあることに加え、フォントが細いタイプとなっている。そして言うまでもないが、椅子と椅子との間がかなりあいているのは、人を寝かせないための措置であることは言うまでもない。

そして「シャトー = ルージュ駅」（Château - Rouge）。駅名からは想像しにくいが、ここから地上に出ると黒人の方々が多い地区である。中でも圧巻は近くのプレ通り（Rue Poulet）で、アフロストリートとでも言うべきか、やたらとアフロヘアにしてくれそうな床屋（美容室）やアフロのかつらを売っている店が軒を並べている。

続いては「シテ駅」（Cité）。その名の通り、パリの中心で発祥の地でもあるシテ島の地下にある。ここは駅名版も他駅と違って個性的なほか、照明も丸形でいい感じである。

そして今回のとりを飾るのは「テュイルリー駅」（Tuileries）。メトロの駅は個性的な駅がいくつもあるが、ここもその一つに数えられる。上写真では1940年部分が見えるが、ホームの両側に1900年から10年ごとの印象的な出来事を写真等で表現している。乗客がじっくり見ることはあまりないかもしれないが、それでも面白い演出だと感じさせられた。

といったところで、今回はここまで。

巴里より帰る──写真整理編 II

前回の続きです。

これは、シテ島にかかるポンヌフ（橋）横に佇む観光船。アンリ4世像が見えます。

トゥール・モンパルナス（Tour Montparnasse。通称モンパルナスタワー）。パリ20区中唯一の超高層ビル（高さ210m、59階建）。だけあって、多少オープンスペースのあるところからはパリ市内のどこからでも見ることができる。その存在感は近くから見ると、さらに圧倒的で、これが景観論争を呼んだことは今でもそうだろうなぁと感ずることができる。

パリはトイレ地獄ではあるが、ゴミを捨てる場所は至る所にある。そのほとんどは金属製の輪っかにビニール袋に被せた簡易なものだが、家庭（オフィス）用のゴミ箱は、清掃車に対応した規格化・統一されたものが採用されている。清掃車にゴミ箱を2つセットするだけで、あとは清掃車が自動でゴミを格納するというその作業は、いかに我が国のゴミ収集が遅れているかを実感できる。また、清掃作業は日中まんべんなく行われているようで、市内を散策中にも様々なシーンで見られた。

これはルーヴル美術館で気になった絵の一つ。何やら視線を感ずると思って振り返ってみたら彼の姿が…（苦笑）。

パリ東駅（Gare de l'Est）。ストラスブール等、フランス東部、ドイツ方面への玄関口。ただ、初期にできた駅のため規模は小さく、数百メートル離れた北駅の存在がそれを裏付ける。東京駅等と同じように、駅と連結したホテルがあるのも特徴か。

とりあえず、ここまで。今日中に追記するかも。
ということで、ここからが追記分。

ヴァンブ蚤の市。で見かけたガラクタ…もとい売り物。全般的な傾向だが、蚤の市や屋外マルシェの日本人率（それも若い婦女子系）が異常に高いことに驚いた。雑貨というよりもガラクタ系が多いように見えたのだが、そんなことはどうでもいいのだろうか（いいはずがないだろう）。

こちらはマドレーヌ寺院内。写真を撮った日は日曜日だったため、このようにミサを行っている最中だった。もっとも、観光客の方が圧倒的に多かったのであるが。

そういえばやたらとUNIQLOの広告が目立っていた（バス等にも）が、オペラ地区に10月1日オープンするようで、店のできる場所にはこのような巨大広告が置かれていた。

そしてこちらはパリの地下鉄メトロの14号線は、ピラミッド（Pyramides）駅構内。パリの地下鉄は、1900年開業以降、ほとんどの路線が戦前に敷設されているが、この14号線だけは別格で1998年開業。駅設備もすごいが、何といっても日本語アナウンスが聞かれるのはメトロの中でも、おそらくこの路線のみだろう。自動列車運転システム採用のためか、ホームドアを採用しているが、相変わらず乗降車時にはボタンを押さなければならない点は変わらない。

bio市（マルシェ）の元祖的存在であるラスパイユ（Raspail）の朝市にある石鹸を販売する店頭。いい香りが印象的だが、ここも日本人率の異常な高さに驚く。毎度思うことだが、フランス語がかみ合っていないにもかかわらず、きゃぁきゃぁ騒いでいる若い日本娘たちを微笑ましく見守らせていただいた（苦笑）。

ジェラール・ミュロのサンジェルマン本店ディスプレイを飾るうまそうな、そして芸術的な作品たち。日本にもやってきているが、食べ比べするとわかるように、こちらの方が濃厚である。しかも安い。ここは、お総菜等も数多くあり、私的にはこんなお店が近くにあったらうれしいと思った。

といったところで、今回はここまで。

巴里より帰る──写真整理編 I

今回は、巴里（パリ、Paris）旅行の写真を整理しながら、自薦（苦笑）のものをアップし、わずかばかりのコメントを付けていく。では、始めよう。

これは、モンパルナス駅で購入したフランス国鉄（SNCF）の切符。シャトレまでの往復を窓口で買ったが、その片道（往路）切符。価格は二人分で27.20ユーロ（一人あたり13.60ユーロ）。パリ（モンパルナス）～シャルトルは首都圏でいうと、大雑把に東京～小田原といった感覚（間隔）だろうか。区間特急として考えれば、まぁ妥当な金額と思える。なお、イタリアとは違い、フランス国鉄は時刻表どおりに運行するのが当たり前（無論、遅れがないわけではないが）である。

これは、シャルトル大聖堂。駅から見えるので、ほとんど迷うことはない。やや上りの坂道だが、私の足では10分もかからずに到着できた。シャルトルと言えば、やはり大聖堂。そして大聖堂と言えばステンドグラスのバラ窓が著名だが、私が気になったものは……

これである。正面向かって右手側にある、この困ったような顔の人。悪魔みたいなヤツに手をつながれ、肩口から手を回され顔を寄せられて、耳に何やら吐息を吹きかけるような…。こんな状況下に置かれれば、このような困った顔になってしまうのも当然だと言えるだろう（苦悶笑）。

シャルトル旧市街は、歴史的街並みとして指定されているようで、電柱地中化も行われていた（ちょっと外れるとしっかりと電柱が立っているのが見える）。ただ、これは仕方のないことだが、UHFアンテナや衛星アンテナが屋根の上に立っているので、そこが残念と言えば残念なところ。旧市街は散策していてとてもよかったのだが、シャルトルを訪れる多くの、というかほとんどの観光客はここまでやってこないようで、大聖堂とその周辺の土産物店だけで終わるのはもったないように思う。まぁ、ピンポイントで強行軍で回らされるツアーでは、それもやむを得ないところなんだろうが…。

これは、フランス学士院。セーヌ川のルーブル側河岸からひときわ目立つ建物だが、近くに来るとその偉容さに圧倒される。この近辺は、アンティーク系の店が多く、ウィンドウを眺めているだけでも面白い。私は骨董の趣味はないが、骨董趣味をお持ちであれば私以上に楽しめるだろう。

ルーヴル美術館で著名なものの一つ、ミロのヴィーナス、の後ろ姿。ここは常時誰かしらがカメラを構えており、米国系または中国系の人たち（そして日本のバカップル）がヴィーナス像と並んで写真におさまろうと、像の前は修羅場となっていることが多い。美術品を鑑賞しようという雰囲気はゼロである。

さらに混雑しているのは、モナ・リザ前。これでも人が減った状態で撮影したのだが、広い室内空間であるにもかかわらず、絵の前だけはそれを感じさせない混雑。絵そのものも分厚いガラスに守られていること、近寄ることもままならないことから、これも美術品を鑑賞しようという雰囲気はゼロである。

サンジェルマン・デ・プレ地区にある現存するパリ最古のカフェ、Le Procope。カフェといいながら店の看板には「RESTAURANT」とあるが、食事もできる程度の意味だろうか。1686年から、というから今年で323年にも及ぶ。老舗のカフェは、店の雰囲気やよし！であった。

パリを散策していて何が困るかと言えば、やはりトイレ。日本はトイレ天国なので、そのつもりでいるとパリでは痛い目に遭う。適当なタイミングでカフェ等に行く、という方法もないではないが、やはりいざという時に利用できるトイレを覚えておくといいだろう。で、ここはサン・シュルピス教会内のトイレ。基本的に教会に用のある人用なのだが、そこはそれ。神に救いを求めたくなるような切羽詰まった状況では、ありがたく利用させていただくこともやむを得ないだろう…。

パリ中心部のセーヌ川には、日本で言ういわゆる河川敷的なものはないが、すぐ川の側まで降りられるようになっているところが多い。セーヌ川岸からルーヴル方向を眺めた様子だが、こういうところをクルーズでなく、ゆっくり歩いてみるのも楽しい。まぁ、橋の下などは今一つではあるが、それでも全体的にはいいものである。

シャルル・ド・ゴール国際空港出発ロビーにある有料インターネットPC。今やどこでもインターネットができて当たり前、というのはパリにおいても同様で、今回、事実上のネット禁止令（苦笑）が出ていたため、ようやく帰りの空港内において、時間つぶしの一環としてほぼ10日ぶりにアクセスした。OSはWindows XPで、フランス語版ではあるが、日本語表示はまったくといっていいほど問題はない。Unicodeさまさまだ。

シテ島にあるパリ警視庁本庁舎。壁面工事中だが、なかなかに素敵な広告？となっている。いずれも警察官（事務員）はホンモノの方のようだ。こういうセンスのある工事現場、日本（東京）ではなかなか見ることができない。

セーヌ川にかかるカルーゼル橋から、ロワイヤル橋方向を眺めた。午後8時過ぎに日没となるので、午後8時半頃でもこんな感じ。カメラマンの腕が今一つのため、実際よりも大きく劣るが、ホンモノの夕焼けは実に見応えがあった。

といったとこで、今回はここまで。

巴里より帰る

昨日、仕事の出張も含め、二週間ほどの巴里（パリ、Paris）への滞在を終え無事に帰宅した。いかんせん、深夜の帰宅だったので何もする気力がなく、今日も朝からぼぉ～っとしつつ、洗濯などを行ってまさに残務処理を行っている。

そんなわけで旅行を振り返っている暇もなく、取り急ぎ写真のみアップしておきます。

以上、簡単ですが今回はここまで。

Hyper-Threading──嗚呼、Freeze模様（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Hyper-Threadingの有用性──Super πとTMPGEnc同時実行 II」

巻頭言 981　「Hyper-Threading──嗚呼、Freeze模様」

Super πとTMPGEncの同時実行テストで思わぬトラブルを招来してしまったが、これが「Dual Xeon 2.20GHz ＋ Tyan Thunder i860 S2603 ＋ Hyper-Threading OFF」によるものかを検証したい。
（ところで前回（昨日）、「場合によっては、午後あたりに加筆するかもしれないが──」としていたが、単に記述するだけならそれも可能だったのだが、今回は帰宅して自宅マシンでの検証を要するために結果としてできなかった。帰宅したのが午前様では、無理というものであったといえようか。）

Super πとTMPGEnc同時実行テストにおいて、4CPU状態でまったく問題が発生しないのに、「/numproc=2」オプションを追加して強制的に 2CPU状態（いずれも物理プロセッサ有効）にすると、Freezeしてしまう。ちなみにこのようなFreezeは、Thunder i860をベースにしたDual Xeonマシンでは、Xeon 1.70GHzを使っていた時まで含めて初めてのことである。それだけ安定度の高かったものが、こうもあっさりFreezeしてしまうということは、単純に考えても強制的に2CPU状態にしたことが原因であるとしか考えられない。

本来なら、BIOS設定で「Jackson Techonogy」をEnabledからDisabledにすればいいのだろうが、以前の巻頭言でもふれたように、BIOS設定での「Jackson Techonogy」をどちらにしても、Windows XPはHyper-Threadingテクノロジを有効にしてしまう。なので、このBIOS設定をEnabledからDisabledに変えても意味はないと思いつつ、念のためということで「Jackson Techonogy」をEnabledからDisabledに設定変更し、かつ「/numproc=2」オプションを追加して2CPU状態で起動した Windows XP Professionalで、再度同時実行テストを行った。しかし、結果は同じようにFreezeしてしまったのである（なお、Super πとTMPGEncのCPU割り当てをそれぞれ独立して与えても、結果は変わらなかった）。

Super πとTMPGEnc同時実行中Freezeした画面写真（擬似的にHyper-ThreadingをOFF）

やはり、Thunder i860のBIOS（バージョン1.04）での「Jackson Technology」設定は、Windows XPにおいては事実上無意味であることが再確認できたに過ぎなかった。それでは、2CPUであることが問題という可能性を消し去るため、Windows XP Home Editionで起動し、Hyper-Threadingを有効にした2CPU状態（物理プロセッサとしては１つ、論理プロセッサとして２つ）で同時実行テストを行った。結果は予想どおり、無事にテストは終了し、実行タイムはSuper π（52万桁）が59秒、TMPGEncが1分47秒という結果となり、Dualプロセッサでの実行タイムとは大幅に遅れたことから、物理プロセッサは１つであることが裏付けられた。厳密に言えば、OS環境が異なっているので、今度はWindows XP Home Editionのboot.ini中に「/numproc=1」と設定することで、強制的に1CPU状態とし、Hyper-ThreadingをOFFにして同時実行テストを行った。これでFreezeすれば、ほぼ間違いなく、Hyper-Threadingがらみの問題となるが、これも予想どおり処理の途中でFreezeした。
以上のことから、次のことがいえるだろう。

『Hyper-Threadingテクノロジが有効にされているXeonプロセッサをTyan Thunder i860（BIOSバージョン1.04）に搭載し、OSにWindows XPをインストールすると、BIOSの設定いかんにかかわらず、常にHyper-Threadingテクノロジは有効になり、OSからは論理プロセッサの総数が認識されるようになる。これに「/numproc」オプションで、OSのサポートするCPU数を減らし、見かけ上物理プロセッサだけを有効にした状態で、Super πとTMPGEncを同時実行すると、処理の途中で常にFreezeする。』

なぜ、Freezeするのか？という根本的な原因は、とにかくエラーログがまったく出力されず、完全なFreeze状態になってしまうため、どういった理由でFreezeしたかはわからない。ICEを利用したり、リモートデバッグを行う等すれば、ある程度原因の取っ掛かりを掴めるかも知れないが、とてもではないがそこまで行う労力は割けない。
とはいいつつも、理由がまったくわからないわけでもない。推測ではあるが、おそらく「/numproc」オプションでCPU数を制限することが、 Hyper-Threadingテクノロジを考慮に入れていないか、またはThunder i860のBIOS設定でHyper-Threadingテクノロジを上手に殺していないための不具合ではないかと思われる。いずれにしても、 Hyper-Threadingテクノロジを下手に制限しない方がいいということだけは間違いないだろう。

聞くところによれば、Hyper-Threadingテクノロジは、システム（BIOS）上の設定でサーバ向けでなければEnableされないという話があるが、私のThunder i860の環境においては、現段階でという条件付きだが、下手にHyper-ThreadingテクノロジをDisableする方が却って不具合が起こるという結果となった。いや、むしろBIOSでDisableにしても、Windows XPがHyper-Threadingテクノロジを有効にしてしまうことが問題かもしれない。いやいや、それ以前の問題として、Windows 2000 Professional上でのSandra 2002の挙動も気にかかる。Windows 2000は、Hyper-Threadingをサポートしていないが、Sandra 2002はおそらくXeonの設定（CPUID）から判断してHyper-Threadingを有効とみなしているので、ソフトウェアの適用によってこのあたりの挙動は左右されるといっていいかもしれない。つまり、Hyper-ThreadingのEnabled/Disabledの判断は、もっともっと根源的なところで行わなければならないのに、私の使用するThunder i860ではそれができていないのではないか、という可能性の問題である。

さて、Hyper-Threadingの総括をそろそろ行う予定だが、それは次回以降とさせていただくつもりである。（2002/1/25）

【当時を思い起こして】
今では液晶ディスプレイは当たり前だが、当時は性能も今一つで解像度も低く、やたらと高価だったので、ノートPC以外での選択肢は私は想定外だった。この画面写真も今はなき、トリニトロンディスプレイである。ブラウン管タイプは、もうほとんど見なくなったなぁ。

Hyper-Threading──Super πとTMPGEnc同時実行 II（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Hyper-Threadingの有用性──Super πとTMPGEnc同時実行」

巻頭言 980　「Hyper-Threading──Super πとTMPGEnc同時実行 II」

Super π（CPU 0, CPU 3）とTMPGEnc（CPU 1, CPU 2）同時実行時のパフォーマンスモニタ

CPU使用率は、同時実行中は75%（Super πにCPU２つを割り当てているが、実行スレッドは１つのため）を示していたが、Super πの処理が終了した後のイメージショットなので画面上は50%となっているが、注目はCPU 0（CPU使用率の履歴の最左）とCPU 3（同、最右）のぶれの大きさである。これまでCPU使用率の履歴をいくつか示してきたが、Super π及びTMPGEncを実行中は、常に振り切れた状態、つまり上で見ると真ん中二つのようになっていた。この激しいぶれは一体、何を示しているのだろうか。
（前回までの続き）

ちなみにSuper πをデフォルトの状態（CPU 0～CPU 3すべてを割り当て）で一つだけ実行した場合、パフォーマンスモニタは次のようになっていた。

Super πで４つのCPUを割り当てた際のCPU使用率遷移

このように、確かにCPU間でSuper πの実行スレッドは分担して行われているものの、さすがに切り替え頻度はTMPGEncを同時実行している時ほど激しいものではない。これらのことから考えられることとしては、TMPGEncのCPU占有度があまりに高いため、Super πがCPUを占有する間もなく、どちらか（CPU 0またはCPU 3）の空き具合、つまり、物理プロセッサに相対するCPU 1またはCPU 2のTMPGEncの実行スレッドのタイミングを見ながら、OS（Windows XP）が切り替えを行っているために、このように実行されるCPUの異動が頻繁に行われると見ていいだろう。

こういった形で処理が並列化しているために、TMPGEncから見れば、本来CPUを占有したいにもかかわらず、OS関与に伴うSuper πの実行スレッドという横槍が入ることから、これまでの実行タイムから若干遅れたものとなったと想定されるというわけである。無論、Super πの側からすれば、TMPGEncがCPUを占有し続けることが多いので、なかなか実行スレッドを処理することができず、こちらも実行タイムが遅れるとなる。

では、同じベンチマークテストをHyper-ThreadingをOFFにした場合はどうなるだろうか。これを行うには、Xeon 2.20GHzからHyper-Threadingテクノロジが使用できないXeon 1.70GHzにプロセッサを変更すれば確実だが、あの面倒な換装作業をしばらくは行いたくないので、擬似的にHyper-ThreadingをOFFにする、/numproc=2オプションを追加することで、物理プロセッサのみを有効にするという方法を採った。
CPUの割り当てはデフォルト（Super π、TMPGEncいずれもCPU 0とCPU 1を割り当て）で、同時実行を行うと………。

─── Freeze…………。

Super πがおおよそ12周目、TMPGEncがおおよそ処理の50％目前といったところで、見事にフリーズである。いやぁ、あっさり落ちるものだと感心しながら、ハードウェアリセットを行い、もう一度、同じ環境で同時実行テストを行うと、

─── Freeze…………。

ははははは……。
当環境だけとは思いたいが、Dual Xeon 2.20GHzでHyper-Threadingを擬似的にOFFにして物理プロセッサ２つのみを有効にし、Super πとTMPGEncを同時実行させると、ハードウェアリセットでなければ復旧不可能なとんでもないフリーズ（ブルーバックが出ないのはもちろん、エラーログすら吐き出されないので、可能性としてはプロセッサ周りが致命傷という恐れが高い）が発生することが確認できた。念のため、もう一度ハードウェアリセットをかけて再々テストを行ったが、やはり結果は同じ。再現性が高いものであるのは疑いない。

それでは、と、再び4CPU状態（/numproc=2をはずす）で同時実行テストを行ったところ、こちらはまったく問題なくテストを終えた。どうやら、 Windows XPそのものの環境にダメージを受けているわけではないので、「Hyper-Threadingを擬似的にOFFにして物理プロセッサ２つのみを有効」にしたことがフリーズの原因であるのは確かだとなる。

というわけで、思いがけないことで時間を食ってしまった。本来なら、Super πとTMPGEncの同時実行テストの話を総括した後、他のテストなりを行う予定でいたのだが、思いがけぬトラブル（仕様？ Bug？）によって、時間が足りなくなってしまったため（Dual XeonマシンはWindows XP起動前までの起動時間が長いのよ）、今回は中途半端であるがこの辺で終わりとしたい。場合によっては、午後あたりに加筆するかもしれないが、例によってあてにならない話なので、かもしかの話ということでご容赦いただきたい。

というわけで続きます。（2002/1/24）

【当時を思い起こして】
このトラブルは、ハードウェアによるものなのか、Hyper-Threading Technologyにからむものなのか、OS側の問題なのか。まったく切り分けることができないまま終わったのが悔やまれるが、使えるICEが自宅になかったので仕方がない。おそらく複合系のような気もするが…。

Hyper-Threadingの有用性──Super πとTMPGEnc同時実行（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「マルチスレッドでのHyper-Threading ── TMPGEnc編 II」

巻頭言 979　「Hyper-Threadingの有用性──Super πとTMPGEnc同時実行」

さて、今回の巻頭言は繰り延べとなっているTMPGEnc 2.02とSuper πを同時実行させながら、Hyper-Threadingテクノロジの有用性を探っていくことにしよう。
と、これを行う前に、これまでの簡単な復習──というほどのものではないが、これまでのSuper π及びTMPGEncにおけるテスト結果から導出されるHyper-Threadingの特長についてふれておくことにする。

Super πのようなシングルスレッドアプリケーションでは、基本的に一つのCPUしか使用しないため、CPU 0～CPU 3のいずれに割り当てても、いくつ割り当てようとも結果は同じとなる。そして複数実行した場合は、各々の実行スレッドは独立して実行されることから、スレッド同期を行う必要がないため、実行スレッドの間口が増えるHyper-Threadingの有用性を確認できた。

一方、TMPGEncのようなマルチスレッドアプリケーションでは、基本的にプロセスが支配下に置くことのできるスレッドを一つ一つCPUに割り当てることができるので、スレッドの数だけCPUがあれば、それだけ有効に利用することができる。だが、TMPGEncでは実行スレッドが二つのみであること、スレッド間同期またはプロセッサリソースの占有率の高さ等によって、実質、スレッド毎に物理プロセッサを割り当てなければ意味がないことから、 TMPGEncの複数同時実行だけでなく、単体実行においてもHyper-Threadingの有用性を見出すことはできなかった。

以上の結果を踏まえて、Super πとTMPGEncを同時実行させたとしたら、どういう予想を立てることができるだろうか。単純に考えれば、２つの実行スレッドのプロセッサリソース占有度が高いと目されるTMPGEncが物理プロセッサを乗っ取ったなら、Super πはプロセッサリソースが有効に使うことができず、停止状態に陥ってしまうということが予想できるだろう。これでは、Hyper-Threadingを活かすことはできないとなるのは明白である。

以上のような予想を立てつつ、最初に行う同時実行テストはデフォルトの状態、つまり、CPUの割り当てを特に設定することなく（CPU割り当て上は、CPU 0～CPU 3すべてを当てている）、行った結果から示してみよう。
と、その前に。TMPGEncのテストは従来のものと同様だが、Super πのテストは、通常行う104万桁の計算でなく、52万桁の計算に変えている。変えた理由だが、TMPGEncのテストと実行タイムをなるべく合わせるため、TMPGEncが通常42秒で処理を終了することから、これに近い38秒で処理を終了する52万桁を採用したということである。
では、デフォルトでの同時実行の結果だ。

デフォルト状態（すべてのCPUが割り当て）で、Super πとTMPGEncを同時実行。

いきなり面白い結果となった。Super πについては、初めて52万桁の計算を行ったため、実行タイムが目新しいタイムとなるのはもちろんだが、TMPGEncの実行タイムは54秒という、これまでにまったく見たことのない実行タイムとなった。これまでは、マルチスレッド（２つの実行スレッド）が有効に機能した42秒前後の実行タイムと、実質シングルスレッドのみが有効となった1分25秒前後の実行タイムしかなかった（TMPGEncを複数実行した際に、一方のTMPGEncによってすべてのプロセッサリソースを奪われた場合は実行タイムが大幅に遅れたが、これは例外）。それがこのテストでは54秒とどちらともつかない中途半端なものなのだから、これはじっくりと検証する価値があるというものだろう。

手始めに、物理プロセッサをSuper πとTMPGEncそれぞれに割り当てたらどうなるかを確かめてみよう。シングルスレッドアプリケーションであるSuper πは、プロセッサリソースをTMPGEncに奪われることなく実行できるので、おそらくは単体テストと同様の38秒程度か、あるいはそれよりやや時間がかかる程度であろう。一方、TMPGEncは、物理プロセッサ一つでは実質マルチスレッドを有効に活用できないので、マルチスレッドオプションを無効にした 1分25秒程度と予想できる。
それでは、CPU 0とCPU 2をSuper π、CPU 1とCPU 3をTMPGEncにそれぞれ割り当てた結果をご覧いただこう。

CPU 0とCPU 2にSuper πを、CPU 1とCPU 3にTMPGEncを固定して実行。

何かすいぶんとベタな予想とその結果だと思われるかもしれないが、これが現実である。何度計測しても同じような結果なので、引き続き、Super πをCPU 0だけ、そしてTMPGEncをCPU 1だけに割り当て、残るCPU 1とCPU 2にはこの二つのアプリケーションを割り当てないような形でテストを行ってみた。結果は以下のとおりとなった。

CPU 0にSuper πを、CPU 1にTMPGEncを固定して実行。

シングルスレッドアプリケーションであるSuper πが、CPUの割り当て数を減らしても結果が変わらないのは自明だが、マルチスレッドアプリケーションであるTMPGEncがマルチスレッドオプションを有効にしておきながら、それが機能していないように見えるのは、これまでに指摘しているように物理プロセッサを一つだけしか割り当てていないことによるものだろう。改めて、Hyper-ThreadingがTMPGEncでは有用でないことが確認できたといえるものだが、今はそれに注目しているのではない。TMPGEncの実行タイムが54秒となる組み合わせとしては、物理プロセッサをそれぞれに割り当てたものではないという結果が重要なのである。そうなると、次なる組み合わせは、物理プロセッサをまたがった割り当てでテストを行うことが適当だろう。CPU 0とCPU 3をSuper π、CPU 1とCPU 2をTMPGEncと割り当てた結果は次のとおり。

CPU 0とCPU 3にSuper πを、CPU 1とCPU 2にTMPGEncを固定して実行。

Super πが１秒ほど速くなっているが、誤差の範囲だろう。これが、デフォルトの状態で行った結果と同等であるのはほぼ間違いない。それでは、このテストを実行中のCPU使用率は、どう推移したのだろうか。これも実に興味深い結果を示している。

Super π（CPU 0, CPU 3）とTMPGEnc（CPU 1, CPU 2）同時実行時のパフォーマンスモニタ

CPU使用率は、同時実行中は75%（Super πにCPU２つを割り当てているが、実行スレッドは１つのため）を示していたが、Super πの処理が終了した後のイメージショットなので画面上は50%となっているが、注目はCPU 0（CPU使用率の履歴の最左）とCPU 3（同、最右）のぶれの大きさである。これまでCPU使用率の履歴をいくつか示してきたが、Super π及びTMPGEncを実行中は、常に振り切れた状態、つまり上で見ると真ん中二つのようになっていた。この激しいぶれは一体、何を示しているのだろうか。

───というところで出勤時間が来てしまった。この続きは、また次回以降ということですいません。（2002/1/23）

【当時を思い起こして】
───というところで出勤時間が来てしまった。この台詞で終わることはかなり多かったように思う。だいたい、巻頭言に費やしていた時間は概ね30分。専ら出勤前の朝に書いていたのであった。今は昔。人生を充実させるために、現在はそういう時間を朝取ることはかなわなくなったが、それはそれでよかったと思っている。

マルチスレッドでのHyper-Threading ── TMPGEnc編 II（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「マルチスレッドでのHyper-Threading ── TMPGEnc編」

巻頭言 978　「マルチスレッドでのHyper-Threading ── TMPGEnc編 II」

次回は、TMPGEnc 2.02とSuper πを同時実行させながら、Hyper-Threadingテクノロジの有用性を探っていく予定である──としていたが予定を変更させていただくことにする。理由の一つ目は、Intel社のMobileプロセッサに関する話題を一回挟んだこと。これは結果としてそうなったというものだが、もう一つの理由は、TMPGEncによるベンチマークテストを同時に二つ実行した場合どうなるか、ということを確かめるためである。このテストを新たに追加する目的は、 CPUの割り当てが物理プロセッサの割り当て個数の違いだけで、論理プロセッサの個数に依存しないという事実を再確認することが目的である。

Super πでは、同じ実行スレッドが２つであっても、単一物理プロセッサ内の論理プロセッサでスレッドを分け合うことによって、明らかに差が生じていた。だが、 TMPGEncではどのように論理プロセッサを割り当てても、物理プロセッサとしていくつ割り当てられているかによってのみ差が生じた。これをよりはっきりさせるには、二つのTMPGEncを同時実行させ、それぞれに物理プロセッサを一つずつ割り当てる（CPU 0とCPU 2に一つ目のTMPGEnc、CPU 1とCPU 3に二つ目のTMPGEnc）ものと、それぞれに物理プロセッサを二つ割り当てる（CPU 0とCPU 1に一つ目のTMPGEnc、CPU 2とCPU 3に二つ目のTMPGEnc）ものを比較することである。それでは、その結果を以下に示そう。

CPU 0, CPU 2に一つ目のTMPGEncを、CPU 1, CPU 3に二つ目のTMPGEncを割当て実行

CPU 0, CPU 1に一つ目のTMPGEncを、CPU 2, CPU 3に二つ目のTMPGEncを割当て実行

テスト内容及び方法は、巻頭言976を参照いただきたいが、なかなか興味深い結果となっている。その差はわずかに１秒だが、これは測定誤差の範疇に収めても支障はないものだろう。つまり、物理プロセッサを意識して割り当ててもそうでなくても、どちらも結果は変わらないということである。これだけでも驚くべき結果だが、それ以上に興味深いのは、マルチスレッドオプションを有効にしないテストとほぼ同じ実行タイムとなっているということだ。これはどういうことだろう。

以前にも議論したように、TMPGEnc 2.02でマルチスレッドを有効にすると、処理を実行するスレッドは二つになるが、この実行スレッドはプロセッサリソースを使い切るか、あるいはスレッド間同期によって、事実上一つのスレッドが一つの物理プロセッサを完全に占有してしまうと考えられる（厳密に言えばそうはならないが、アプリケーション間同士ではそう見えるということ）。このため、物理プロセッサが一つしかない場合（強制的に一つしか割当てられていないことも同義）、マルチスレッドは有効に機能せず、結果としてシングルスレッドと同じになってしまうわけである。

TMPGEncを二つ同時に実行するということは、言い換えれば４つの実行スレッドのうち、２つの実行スレッドだけが意味を持つので、残る２つはプロセッサリソースを占有することができず、まったく実行されることがない（ほとんど実行されることがない）ということである。だからこそ、マルチスレッドであってもシングルスレッドと同じ結果となるわけだが、ここで一つ疑問が生ずる。それは、CPU 0とCPU2、CPU 1とCPU 3というように、明確に物理プロセッサを一つずつTMPGEncに与えれば問題はないが、CPU 0とCPU 1、CPU 2とCPU 3というように、物理プロセッサをまたいで割り当てを行うと、物理プロセッサを占有するスレッドが両方とも一方のTMPGEncになった場合、物理プロセッサが割り当てられないTMPGEncは処理が停止してしまうのではないかという疑問である。

このことを確認するために、CPU 0とCPU 1、CPU 2とCPU 3という割り当てで、何度かテストを繰り返すと、４度目のテストでは、一方のTMPGEncの処理が完全に停止してしまい、処理が継続している TMPGEncが終了して、ようやくもう一方のTMPGEncの停止状態が解除されることで、実行タイムが大きく乖離するという現象が発生した。このように予想通りの結果を見たことから、先ほどの推論はまったくの的外れではないということと、また、OS（Windows XP）が論理プロセッサの割り当てに関して、物理プロセッサとの関係を意識していないで割り当てを行っていることも、結果として確かめられたとなるだろう。この点が、まさにHyper-Threadingのアキレス腱というわけである。

さて、次回の予定だが、今度こそSuper πとTMPGEncの同時実行によるHyper-Threadingの検証を行うつもりである。（2002/1/22）