CPUは人が作る。   

2007年10月28日



まずはいつもの余談から...

先日秋葉原ついでに一緒に呑んだ先輩が「美味いそばが食べたい。」という。 そういえば、そろそろ新そばの季節だ。 当サイトも休日のお昼には軽く麺類というパターンが多いが、 当サイトもどちらかというと麺類ならラーメンよりそば党である。1) 意見は一致し、美味いそば屋を探すことに。

もちろん、「蕎麦の産地=うまいそばが食べられる場所。」という単純な話ではない。 交通網の発達した現代では良質なそば粉の産地以外でもおいしいそばは食べられる。 というわけで近場でも問題はないのだが...せっかくだから気分だけでも本場で食べたいところだ。

で、そばの本場を探すわけだが、以前本日はひな祭り。(真壁のひな祭り編)で書いたけれど、 茨城は信州に劣らぬ良質なそば粉の産地だそうだ。 茨城のブランド品種である常陸秋そばというと、お米で言ったら魚沼産コシヒカリみたいなもので、それはもう大変な高級品である。 せっかく本場だと知ったのだから、ぶらぶらドライブも兼ねて常陸秋そばを使ったそばを食べに行く手を考えた。

当サイトはそば好きではあるがそば通というほどではない。なので、ネット上でおそばマニアのサイトを巡り歩いてみた。 異分野とはいえこういうときにはマニアの情報というのは本当に役に立つね。 おかげで、これは期待できそうというお店を数軒見つけることができた。 (いろいろとおもしろい話が書いてあるので、本来の目的を忘れてついつい読みふけってしまうのが欠点だが...)

ここ関東では秋蕎麦の収穫期は10月頃が盛り。つまり地元でとれた蕎麦での新そばは10月末頃からがシーズンとなる。 だが、偵察に行ったのは10月初旬だから、まだ蕎麦は花の段階で新そばには早すぎる。 というわけで、花見好きな当サイトはついでに蕎麦の花を楽しんでこようと思った。 ネット情報を元に日帰り温泉旅行を兼ねて、まずは本場茨城のそばどころ偵察にレッツラゴー。

蕎麦の本場、茨城県金砂郷の蕎麦畑
常陸秋そばは清冽な蕎麦の香りが強く上品な甘みが特徴とのこと。

得意のぶらぶらドライブは当サイト流のストレス解消術でもある。 と言うわけで蕎麦畑を探していざ茨城へ。 常陸太田市までは平野の水田ばかりで蕎麦畑のかけらもなかったが金砂郷から水府町にかけては山がちになり、 しばらく行くと...おっ、蕎麦畑が現れた。

当サイトは蕎麦の品種まではわからないのだが、わざわざ茨城で(しかも本場中の本場、金砂郷で) 常陸秋そば以外のノーブランド蕎麦を育てる意味もないだろうから、この蕎麦畑はおそらく常陸秋そばであろう。 ちょっと季節的には既に遅いらしくて、多くの蕎麦畑では実り始めていて写真写りが悪い状態だったのだが、 中には種まきが遅めで花盛りの蕎麦畑もあって、なんとか写真を撮る事ができた。

茨城の蕎麦は常陸秋そばという有名ブランド品種であるという。
おぉ、当サイトは本当にPCマニアのサイトなのか?という写真だね。(笑)

で、肝心の狙っていたそば屋なんだが...「本日のおそばは終了いたしました。」って、ガ〜ン。 しかも、意中の候補の2軒目も終わっていて完全に自爆追い打ちモード。 本場は客足が早いのか常陸秋そばのブランド力・集客力のせいなのか、結構早い時間帯で売り切れのそば屋が多いのね。

かといって、いかにも観光客向けの店に入る位のはアウト。 そんなことをする位なら、地元での当サイト御用達店2)で食べた方がよほどおいしいと思われる。 蕎麦の花が満開ということは新そばにはまだまだ早いわけで、この季節なら混まないと侮っていたのが運の尽きであった。トホホ。

ただし、もう一つの目的地である袋田温泉郷はなかなかいいお湯であった。 入った温泉は露天風呂が渓流沿いにあって雰囲気も最高。 泉質は美人の湯として有名なメタケイ酸泉だったので、お肌もスベスベ。 もっとも、かわいい女性ならともかく、むさ苦しいPCマニアのお肌がスベスベになったところで何のありがたみも無い って言われればその通りなんけど。

と言うわけで一応は秋らしい話題で締めたところで、本題へどうぞ。

☆Vista導入から約半年。   
さて、当サイトもVistaを導入して半年以上になる。 その使用感はと言うと... 見た目がきれいになったこと(アエロの効果もあるが、フォントがきれいになったのが大きい。)と、 IEが標準でタブ・ブラウザになったのは良いのだが、全体的な使い勝手と安定性はイマイチという感じだ。 セキュリティーの観点からはやむを得ないのはわかってはいるが、 基本的に余計なお節介が多いのが当サイト的に「余計なお世話」的な印象を増している。

お節介と言えば、その昔某ワープロソフトで報告書を書いていて、知らない間に スペル訂正機能で「GHz」が全部「Ghz」に自動的に誤記訂正(笑)されていて赤っ恥をかいたことがあったっけ。 頭文字は大文字というスペルチェックが周波数の単位にまで適用されるという融通のなさが、 このような自動スペルミス作成機能を生むわけで、 なんか、この手の機能は意味論的に例外処理を判別できなければ無い方がマシと思った。

Vistaも同じであり、妙にいろいろと口出しするOSなくせに肝心の安定性がイマイチ。 で、「そんな機能は無い方がマシ!」とばかりに設定を変えてしまっている。

典型例はデフォルトの電源設定だろうか?

こいつは最悪最強のトラブルメーカーといった印象で、 最初は何が悪いのかよくわからなかったので、 ああだこうだといじってみたがあまり良くならなかった。

仕方ないのでWebでいろいろと情報を集めたところ、 こんな記事 を発見。実際やってみるとVistaが再起動で安定するというのは本当で、 結局は記事通りスリープ設定を止めてデフォルトをシャットダウンにすることで 数多くの災厄からマシンを守ることができる。 (これが入っていた頃は原因不明の不安定性にかなり悩まされていたからね。) シャットダウン・再起動設定に変更してようやくメインマシンとしてほぼ安定に使えるレベルになったわけだ。

スリープ機能は一見便利に思うかもしれないが、 Vistaのスリープ機能は万年床のようなものであろう。 放っておくと畳が腐るし、何よりだらしない。 終了時にすべてを閉じるのは行儀作法の内と思った方が良いだろう。 Vistaで謎の不安定性にお悩みの方は 上記記事を ご参考にお試しあれ。

というわけで、鳴り物入りで発表されたVistaだが、あまり売れていないという。 「WindowsXPマシンを入手する方法」なんてのがPC雑誌の記事になる位だからね。 特に自作機でのアップグレード需要は絶望的な状況らしい。

当サイトはPC用CPUについてマルチコア否定派最右翼に属するかと思うが、 その見解が正しい時期はVista登場から2〜3年後までと判断していた。 ハードウエア的なハードルの高いVistaがマルチコアマシンの普及を促進し、 それによりソフトのマルチスレッド対応のインセンティブが増すだろうという予測に基づいている。

しかし、Vistaの普及がここまで燦々たる状況だとすると、マルチコア対応アプリの普及もまだまだ先延ばしという事になるかもしれない。 現状、マルチコア対応ソフトというのはまだまだエンコード系がメインであり、それ以外のソフトの対応はボチボチという進捗だ。 最近になってようやく最新ゲームソフトでの対応が進みつつあることが唯一の希望の星だが、 当サイト流のマルチコア否定的見解は思っていたよりもずっと長い間正しい見解でいられるのかもしれない。 (これは喜んでいいのやら悲しんでいいのやら。)

☆パーソナルユースでのマルチコア化の限界。   
というわけで、当サイト的には現状ではまだまだCPUコア単体の性能向上こそが実態としてのCPU性能向上を表していると考えている。 マルチコア化はPC用途にはまだ早すぎると思うし、特にクワッドコア以上のマルチコア化は よほどのヘビーユーザーでない限り実際にもほとんど有効ではないと思う。 これらはサーバー用途か、あるいはこうしたことがちゃんとわかっているセミプロ級コアユーザー向けだ。

Vistaを使いながらCore 2 Duoがどれくらいデュアルコアで動いているか稼働状況をワッチしているのだが、 以前メインで使っていたWindows2000と比べて稼働率が極端に上昇するような事は無かった。 VistaはバックグランドジョブがXPよりずっと多いと聞いていたから期待していたのだが、 「マシにはなっている。」という程度であり、マルチコアCPUでないとVistaは使えないというレベルでは決してない。 Vistaによってデュアルコア対応が進み、並列化率が上がることを期待していたのであるが、残念ながらまだまだ一方のコアは遊んでいるのである。 (並列化率は大甘の甘に見ても対応ソフトを使わない限り平均で30%未満であり、並列化効率という意味ではお話にならないレベルだろう。)

この主張、最初は皆様からかなりのご苦情を戴いたのであるが、最近は苦情は皆無となった。 理由は、その後ソフトウエアやアーキテクチャの専門家がマルチコア最大の問題点はソフトウエアの並列化対応にある事を学会で次々と発表したからである。 (典型例はRISCアーキテクチャの世界的権威、デイヴィッド・A・パターソン先生の講演) ついに、日経NE2007年10-8号で「マルチコア化は苦肉の策」との見解が報道され、 事ここに至って「マルチコアだから速い。」を連呼するのはCPUベンダーとPC雑誌のみという状況となった。

同記事の内容を引用させていただくと、「現在のような構成のパソコン向けマルチコア型マイクロプロセッサでは、 コア数増加の恩恵を享受できるのは4〜8コア程度までという見方をする関係者が多い。」とのことだが、 8コアでさえintel、AMDの次世代CPUに遠慮した報道であり、当サイトは学会情報をワッチして 実際には4コア程度が限界というのがプロの共通認識との情報を得ている。 しかも、これはアプリが対応を果たした上での話である。

プロ間では単純にマルチコア化を進めてもPC用途ではリニアに性能が向上しないことはもはや常識と化しているのに、 PC雑誌は知ってか知らずかこれを報道しない。本当に不思議なことだ。 (実際、この壁を破る方法を見つけ出す事が専門家の大きな技術開発命題になっており、活発な研究が行われている。)

この状態でマルチコア化が進むと何が起こるのだろう。 デュアルコアですら潜在能力を完全には引き出せていないのに、クアッドコア、オクタコアと進むと何が起こるか?  当然、同時に動かしているアプリの数を増やさないと性能が出せなくなる。

よくデュアルコアのメリットとして説明されるのは「性能が高いのではなくて、性能が落ちにくいのがメリット。」という意見だ。 この見解はデュアルコア程度ならばまだ正当と思うのだが、オクタコアではどうだろうか?

デュアルコアの場合は... 「ウイルススキャンをしながらエクセルを操作するとシングルコアでは大きく反応が遅れたがデュアルコアでは処理が遅くならなかった!  さすがにデュアルコアはすばらしい!」となる。3)

この程度の意見ならまだ許容範囲内だが...だがオクタコアではどうだろうか?

「ベンチマークを動かしながら、DVDを再生しながら、アンチウイルスソフトでHDDをスキャンしながら、エディタで文章を入力しながら、 ブラウザでフラッシュの多いWebサイトを見ながら、ゲームをしながら、プリントアウトをしていた。 このとき、エクセルで表計算を入力したところ、クアッドコアでは大きく反応が遅れたが、オクタコアでは反応が遅れる事は無かった!  オクタコアはなんてすばらしいCPUなのだろうか!」

なんて事になるが、もちろん笑い話でしかない。

まぁ、ゲームをしながらエディタで文章を入力しながらDVDを鑑賞しながらエクセルの表計算ができるとか、 仮にそういう聖徳太子みたいな人がゴロゴロ居たとしても、こんな状況が頻繁に発生すると思う人はまずいないだろう。(笑) しかし、Vistaのバックグランドジョブをもってしてもデュアルコアで無ければ使い物にならないという状況を作り出せなかった以上、 エンコードのようにソフトがマルチスレッド対応しない限りはパーソナルユースではこういう状況でしか優位性は発揮できない。 (オクタコアはサーバー用途を念頭にしたCPUであり、対応アプリが主流になるまではパーソナルユースとは無縁なCPUだと思う。)

どうもPC雑誌は結論先にありきで一般ユーザーのユーセージモデルを無視した使用形態でのベンチ結果を採用する傾向があっていただけないが、 デュアルコアではなくオクタコアだと上記の通りそのバカバカしさ加減が誰にでもわかるようになるから、かえってだまされにくくなるだろうね。 8コアのSPEが搭載されたCELLがあれほどの高性能を誇りながらなぜPS3が失敗したのかをよく考えていただければ真の状況はわかると思う。 対応アプリがあってこそのマルチコアなのである。

で、そのマルチコアへの対応状況だが...エンコード以外の対応状況はどうだろうか?

オクタコアのゲームでの性能はこの評価記事を見れば推定できる。 このサイトの評価記事を読むと、グラフィック性能がボトルネックになっていない1024×768の解像度で 8コアの性能は1コアの最大で2.6倍だそうだ。

ここで、ポラックの法則を思い出していただきたい。 もし仮に8コアと同じダイ面積のシングルコアCPUが製造できたとしたら、その推定性能はどれくらいになるだろうか?

それは80.5=2.82だから2.82倍である。 シングルコアでもCPU性能が直接結果に反映すると仮定すればの話だが、 ロスト・プラネットというバリバリにマルチスレッド対応した次世代ソフトですら同一ダイサイズのシングルコアCPUにかなわないのである。 (まして、そこまでのマルチスレッド対応を果たしていない現状のアプリでは...書くまでもないことだろう。)

今、ソフトウエア開発担当者の間では(マルチメディア用途以外における)マルチコア対応での性能向上が驚くほど低レベルであることに驚きの声が上がっているそうだ。 (組み込み用途の場合だが、理論ピーク性能で2〜4倍になっても、実効性能は1.2倍程度である事が多いとのこと。)

が...当サイトに言わせれば何を今更の感がある。 そもそもマルチメディア系以外のPC用途ではフローコントロールがメインの処理である。 数値処理がメインのスパコンと同じ並列化率を期待する事自体に根本的な無理があると言えるだろう。 だから、データ処理部分の負荷が全負荷の大部分を占めるエンコードソフトは、 ある意味でスパコン用途と負荷の状態が似ているので例外的にマルチコアがよく効くのである。

スパコン分野では元々データ並列性が高いことや扱う人間がトップクラスの頭脳集団であることから99.5%以上などという驚異的な並列化率が実現できている。 だから、あの数のCPUでもシステムとしてそこそこまともに使えるのである。 しかし、並列化率が70%だったらコア数を無限に増やしてでさえ総合性能は約3.3倍にしかならない。 そして、フローコントロール用途での並列化率がスパコン並みに上がる目処は現在の技術水準ではまったく立っていない。 これらを鑑みて、マルチコアに対するPC雑誌の評価はあまりにも現状を無視して楽観的すぎると当サイトはあえて再度指摘したい。

だが、問題はここからCPUコア単体の性能を上げることが非常に難しいことである。 だから、当サイトはマルチコア化は消去法で残った選択肢であって、積極採用されたアーキテクチャではないという立場を取る。 (日経NEが「マルチコア化は苦肉の策」と報道するのと考えている中身は同じである。)

マルチコアという概念はPC用CPUでデュアルコアが主流になるずっと以前から基本概念は完成されていた。 と言うわけで、仮にマルチコア化がクライアント用途でもスケーラブルに有効とすると、 なぜマルチコアがもっと以前の段階で設計されなかったのか...という疑問に答えられるだろうか?

答えられないからこそ、マルチコア化は消去法による選択なのである。

☆今回のIDFでは種明かし無し。   
しかし、 「Reinventing Computing」 - スパコン界の巨人・Burton Smith博士 という記事に書かれている通り、3つの壁の存在によりCPUコア単体の性能はもはや上げられないのだそうだ。 同記事から引用すると下記の通りである。 (余談だが、Burton Smith先生もマルチコア最大の問題点はソフトの並列性にあるという意見である。)

  1. 1サイクルに同時実行できる命令数の飽和(ILP Wall)
  2. 消費電力の制約(Power Wall)
  3. メモリ性能の制約(Memory Wall)
こんな状態で期待しているCPUコアの変革だが、当然順風満帆とは行かないだろう。 今一番話題のネタはNehalemだが、期待していいものだろうか?

Nehalemの前にPenrynを見てみよう。 SkulltrailとモバイルPenrynのベンチマーク結果を公表 という記事を見る限りPenrynの性能はまあまあのようだ。

記事では劇的に速度が上がる例が紹介されている。 しかし、当サイトが某一流新聞記者の講演から学んだ 「語られたことよりも、語られなかったことに注目して分析すべし。」という分析手法によれば、 この記事はSSE4以外での性能向上は劇的ではないという結論の状況証拠になるからだ。

Penrynの改良点はキャッシュ増量がメインだから確実に性能が上がる。 ただし、キャッシュ増量だから手堅いけれど劇的には上がらない。 しかし、劇的性能向上をアピールするためにSSE4対応ソフトの結果のみを報道する。 まさに語られなかったことが真実を示す、予想通りの結果である。

ただし、これはPenrynにダメ出ししている訳ではない。 PCマニア的な好奇心は満たしてはくれないが、小さな改良からコツコツと... といった感じに地道に改良を行う手法ももちろん大切だと思う。 手堅い設計は効果こそ低めだけど、大きな穴がない設計でもある。 Net-Burstの失敗を見れば、大きな穴がない設計という概念は地味だけど重要な事だ。

で、肝心のNehalemだが...ん? 今回のIDFではCPUコアのアーキテクチャについては公開無しですか?

いや〜、期待してたんですけどねぇ。

Nehalemのコア内部については次回のIDFで公開されるそうだ。 当サイトは一応トレースキャッシュ系の技術が採用される事を予想しているわけだが、 この予想が正しいかどうかは次回IDFまで持ち越しとなった。 (当サイトのNehalem予想は、GPUの統合、SMTの復活、トレースキャッシュの採用の3件、内2件は既に予想を当てている。 目指せパーフェクト!って事で注目度は大きいかったのだが...)

あんまり早く情報を公開するとPenrynの買い控えにつながりかねないから情報の公開時期というのは商売としては重要であろう。 その意味ではやむを得ない事ではあるが、ちょっと残念である。

ただし、重要なことがある。 それはNehalemのコア部分のダイサイズがPenrynに比べてかなり巨大だったことだ。 このダイ写真を見たときには思わずニヤリとしてしまった。

この巨大さだが、Penrynでは未だ64bit性能があまり改善されないと予想され、 それをNehalemで大きく改善するためにトランジスタを投入した事を計算に入れても、 まだ大きすぎるサイズである。

コアが巨大と言うことはintelはまだまだシングルコア性能が重要と認識している証となる。 もしマルチコア化が今後のトレンドとして正しく、コア数にスケールして性能が向上するならば、 コアは逆に小さくしてその分コア数を増やすことがポラックの法則の指し示す正しい方向性だ。 しかし、コアの巨大化はそれに逆行する方向であり、それはコア設計の未熟さ加減を意味するか、 もしくは、まだまだシングルコア性能が重要と認識しているかのどちらかを示しているからだ。

設計をしくじったダイをIDFで公表するなんて事はもちろんあり得ないから、 intelはメニーコアと称してマルチコア化を進めているが、本心ではシングルコア性能の拡大も また非常に重要なことを正しく認識していると考えるべきだろう。

そもそもPC用途でも性能がコア数にスケールするならば、ポラックの法則から考えて PC用にはLarrabeeのような超シンプルなx86コアを多数搭載したプロセッサを設計しなければならないのである。 しかし、intelでのLarrabeeの立場はGPGPUと同じ流れを狙った物であり、 Larrabee自体がメインコアになることはあり得ない。 intel自身もLarrabeeの最初の投入用途はグラフィックスだと言っている。 (ヘテロジュニアスマルチコアの小さいコア側をLarrabeeが担うことはあっても、 Larrabee自体が単体でPCのメインプロセッサになることはあり得ないと当サイトは断言しておく。)

つまり、intelはLarrabee的な設計はメインコアの補助プロセッサとしては非常に有効だが、 ヘテロコアの中での複雑な側のコアの代役は務まらないし、また複雑なコアを止めてシンプル& ホモジュニアスなマルチコアもPC用途には不向きと考えている証拠となる。 (最近のPC雑誌はマルチコアに対して提灯記事しか書かず、学会関連をワッチして得た常識とは あまりにもかけ離れた結論ばかりだったので、まさかintelも本気で...なんて考えていたので、 ちょっと安心した。)

☆なぜPenrynではデコード系が改良されなかったのか?   
ではコアを複雑にしてまでシングルコア性能のどこを改善しようとしたのだろう?

Nehalemではトレースキャッシュの採用を当サイトは予想しているわけだが、 その最大の理由は消費電力削減とデコード能力の向上だ。 特に64bitでのデコード能力向上には注目している。

当サイトはT7200を買った訳だが、こいつの弱点はデコード系がボトルネックになっているという報道がある。 そして、デコード系の刷新にはいくつかの方法があるが、その一つにデカップルドアーキテクチャがある。 デコード系とそれ以降をトレースキャッシュでデカップルすれば、 キャッシュにヒットする限りは複雑な可変長命令のデコード問題が表に出ることはない。 (デカップル後の命令長は固定長だから、可変長命令デコードのデメリットはトレースキャッシュにヒットする限りそこで遮断される。)

また、トレースキャッシュはキャッシュヒット時にデコード済みの命令を再利用することで、デコードに関わる消費電力を削減できる。 つまり、Net-Burstアーキテクチャは失敗した設計だったが、そのすべてがダメだったわけではなく、 潜在能力的には再設計に値する部分もあると考えている。 (SMTも同様に再利用可能な技術と考えていたが、この予想は既に的中した。)

実は当サイトはトレースキャッシュの搭載をMeromの予想として掲載したことがある。 この予想はものの見事に外れたわけだが、その際にもデカップルドアーキテクチャの優位性が失われたとは考えていなかった。 従って、予想失敗の理由としては、長所を上回る短所の存在を考えて、その短所はトレースキャッシュのキャッシュ効率の低さだと予想した。

これが正しいかどうかはシロウトには検証の方法がないので、今のところは何とも言えない。 だが、「Penrynではデコード系は改良されない。」という予想は的中させることができた。 Meromではデコード系が最大のボトルネックとされながら、なぜPenrynではデコード系は改良されないと考えたのか...

それには二つの理由がある。

一つはチックタックモデルで言うところのPenrynがチックの番だからという点が指摘できる。 デコード系の大幅刷新はアーキテクチャの根幹に関わる事だから、ミクロンルールの刷新と同時に行うのは大きなリスクが伴う。 チックタックモデルはリスク回避が最大の目的だから、これに逆らう大幅設計変更はよほどの緊急事態で無ければあり得ない方法だろう。

しかし、デコード系が最大の欠点とは言いながら、Coreマイクロアーキテクチャは成功したアーキテクチャである。 チックタックモデルを破棄してまでデコード系を改良するほどの事は無いだろう。

デコード系を3並列から4並列に強化する事でさえタックプロセッサのMeromで行われた強化である。 もしデカップルドアーキテクチャの採用が抜本的改革とすると、 4並列への機能強化以上の抜本的改革になるデコード系の大幅刷新がチックプロセッサのPenrynで行われるハズがない。 だから、デコード系の改良は無しと予想したのである。 (もちろん、フェッチ帯域問題に対して対症療法で事に当たるという手はある。 この場合は効果は薄いが、チックプロセッサでも対応可能と思われる。 この話はあくまで抜本的改良を行う場合についてなので、その点はご注意いただきたい。)

そして、もう一点は設計チームが同じであること。 MeromとPenrynは同じイスラエルの部隊が設計した。 しかし、Nehalemはオレゴンの設計部隊の手になる設計だ。

ずいぶん以前のことだが、当サイトはPrescotteの予想でμOPs-Fusionの導入を進言した事がある。 これは結果としては予想が的中していたのだが、効果の面ではうまく行ったとは言い難い。 デカップルドアーキテクチャとμOPs-Fusionは相性がよい...というのが当サイトの予想だが、 少なくともPrescottでは導入に見合う性能は発揮できていなかった。

これは、Pentium-Mでは最初からμOPs-Fusionの導入を前提とした基本設計が行われていたのに対し、 Net-Burstでは後付の緊急導入的要素が大きかったためだと考えている。 アーキテクチャの根幹に関わる機能は付け焼き刃の後付では上手く機能しないわけだ。 すべてをゼロから再設計する時に初めて導入可能なレベルであると気づいたわけだ。

同じ事がCoreマイクロアーキテクチャにも言えると思う。 Meromはチックタックモデルで言うところのタックプロセッサだから、 アーキテクチャは大幅改変されると信じてデカップルドアーキテクチャの採用を予想した。 だが、これは大外れに終わった。

Meromはかなり抜本的にアーキテクチャが変わると大々的に報道されていたが、 今見直してみると実はそれほどではなかったという報道もある。 とすると、真の意味の抜本的改革とは以前の概念を破棄するところから始めなければならないと思う。

☆CPUは人が作る。   
問題は「真の意味での抜本的改革」がどこで行われるかだ。 以前、予想を間違えた頃の当サイトの考え方は、 「設計の矛盾による現実の問題点を対症療法(部分的改良)でカバーできなくなったときに抜本的改革が行われる。」 という考え方だった。

しかし、今の考えは少々違う。 今の当サイトの考え方は、「基本設計を行う担当者が変わったとき。」である。 合理性の所産という考え方から、あまりにも泥臭い人間的な考え方に変わってしまったわけで、 自分でもちょっと「いいのかな。これで〜。」なんて思うんだけど、 根幹部分でのアーキテクチャ設計というものは開発者の信条・信念が 大きく設計思想に反映されるものだという事をここ最近の経験で知ったからである。

「コンピュータはコンピュータが設計する。」とはよく言われていることだ。 確かにEDAツール無しでCPUを設計することなど万が一にもできないことだし、 事前に性能を予測するためのシミュレーションも当然のように行われている。 体育館いっぱいに設計図を広げて回路を検証なんて話は、若い技術者にとってはもはや都市伝説の域だろう。

しかし、コンピュータは新たな設計概念を「創造」する事はできない。 このような初期段階での根幹設計ではおそらく実際の設計でもコンピュータの出番は少なく、 技術的検討もホワイトボードにマジックで手書きしながら喧々囂々と議論の日々... 信念と信条、ポリシーのぶつかり合い...

「ここはもう部分的改良では限界だから、こういう新技術を導入してシステムトータルのパフォーマンスを改善すべきだろ!」
「いや、あんたの案はリスクが大きすぎるよ。そこはクリティカルパスの改善で十分だ!」
喧々囂々... という想像をしてしまうが、おそらくは正しい想像だろう。

Net-BurstへのμOPs-Fusionの導入があまり良い実績をあげられなかったことや、 Meromでデカップルドアーキテクチャが導入できなかった事から考えて、 「最適設計はコンピュータが何とかしてくれる。」という考えは間違いであろう。 特に個別の要素技術の継ぎ目部分のような、機能ユニットの性能そのものではなく、 それらを組み合わせた場合の機能ユニット間の整合性(1+1が2になるのかといった部分)では 根本的な設計思想は未だ設計者個人の資質に左右される要因が思ったよりも大きな比重を占めているのではないだろうか? (部分最適化ならコンピュータの支援がよく効くが、全システムでのトータルな最適化はコンピュータの支援が効かず、 最終的にはアーキテクトの設計思想に強く左右されると考えるようになった。)

Coreマイクロアーキテクチャはイスラエルの設計部隊が設計したために 最後までデカップルドアーキテクチャにはならなかった...というのが当サイトの最近の分析だ。 以前は、「ロジック回路というのは、どこで誰が設計しようと正しい物は正しいし、間違っている物は間違っている...」 と合理性の所産のように考えていたのだが、実態はそうではなく、もっとドロドロとした世界というのが今回の分析。 Penrynで、もっと言うとCoreマイクロアーキテクチャデカップルドアーキテクチャが採用されなかった理由としては、 根幹設計の変更が設計者の信念に合致しなかったという部分も大きいのではないだろうか? 

このあたりの人と人との信念のぶつかり合いのような事まで正しく把握できるかどうかが、 今後の予想ネタを的中させるのには重要なようだ。 (どこの設計グループはどんな設計思想を持っている人が指揮しているのか...とかだね。)

マルチコア化が当面の間PC用途では有効ではないという現状は、 困難とはいえまだまだシングルコア性能の向上が求められる事を意味している。 困難さ故に性能向上のペースは鈍るだろうが、逆に言えばこの困難さはこれらが誰にでもできる仕事ではない事を示している。 アーキテクトにとっては逆に腕の見せ所とも言えるだろう。

その意味において、まさにCPUは人が作る物だと言えると思う。



1)
ラーメンが嫌いという訳ではなく、これには理由がある。 当サイトの住みかは成田市にあるが、ここ成田市はラーメン不毛の地なのだ。 残念ながらジャンクフード系風味のお店が多い。 うまいラーメン屋というと...当サイトの舌でうまいと評価できるのはせいぜい安食の一番亭ってところかな? (いつも行列で本人が食べたことが無いので評価保留だが、仲間の噂によると日吉台の麺屋青山もうまいらしい。)

2)
成田近くでの当サイトお勧め店はというと...同じ「くろむぎ」と発音する異なるお店が2店あるが、この名前のお店はどちらもお勧め。
(「くろむぎ」とはそばの異名である。)
  1. 成田の日赤病院前から宗吾霊堂へ向かう途中にある「久呂麦」...腰の強さと味では当サイトいち押し。 硬派正攻法の粗挽きざる大盛りがお勧め。ただし、名店紹介の本に掲載されるぐらい名前が知れ渡っている店なので、食事時にはかなり混むのが弱点。 混む前の開店直後11:00頃に行くのがコツかな?
     
  2. 安食の栄町役場前にある「くろむぎ」...のど越しの良さでは当サイトいち押し。 現時点で週末における当サイト立ち寄り頻度最大店となっている。(店から見たら常連客扱いらしく、店員さんに顔を覚えられた!) かき揚げ丼とのセットメニューが金看板だが、辛み大根の目利きが良いのかおろしそばが上出来で当サイト的なお勧めだ。 一時期はおろしそば大盛りばかり注文していた時期もあるほどだ。駐車場無しなのが唯一の弱点。 ちなみに、店員さんに顔を覚えられると時々思いがけない一品がサービスされる事があって嬉しい。
成田地区周辺での当サイトお勧めそば屋2店
左は「久呂麦」の粗挽きざる大盛り(\1050)。右は「くろむぎ」のおろしそば大盛り(\1000)。

...って、当サイトはグルメサイトじゃないんだけど、今回は余談が余談だけにご容赦を...

3)
ちなみに、SMTを装備しない単純なシングルコアではこの意見は正当性がある。ただし、シングルコアでも SMTを装備すればこの問題に対応するのは十分に可能だしPC用途には適しているというのが当サイトの意見。 Silverthorneのような低消費電力系CPUでもSMTが流行りつつある現状は、最低限のシングルスレッド処理能力を維持したままで、 マルチスレッドな状況でも複数のスレッドに対して一定の応答性を維持したいという理由で説明できると思う。