PINUPS - 上田新聞 blog版

噂には聞いていましたがもう出てくるんですか！！
ベンチメーカー（自称。最近ご無沙汰）としては、要チェック
な技術ですね。状況によっては、Athlon 64 X2 3800+ (Socket 939) からの移行も考えないと。

これは楽しみですねぇ～

発表日から推理すると、買い控え対策でしょう。
半導体数に見合った効果が上がるなら6IPC実装のコアを作ればよいわけです。

これが隠し玉と言われていた機能ですか？
これはベンチのみならずゲームのFPSにも影響しそうな機能ですね。
Core2に完全敗北と思ってたけど、実際の性能次第ではそれなりに戦えるかも？

ワンコアのシングル動作に比べどこまで性能向上が測れるか
見物ですね～。ゲームならアスロンの格言は健在w？

R-TH製作元のコストは高くなるが、アプリケーション側でマルチスレッディングに対応しなくても良くなるのでこっち側のコストは低くなる？

元々マルチスレッドに対応してたアプリケーションは変わらずなんだろうか。

なかなか微妙な感じですね～。
ほんとだったらかなりうれしいですが、７月２４日
だとすると、一ヶ月前にほとんど情報が出てこない
ということはあるのでしょうか。
BIOS対応も必要ということであれば、マザーメーカ
ーにも情報は行ってるはずですし、Rev.Fってコアの
写真とかからも拡張はされてないという話だったよ
うな・・。
でも、ワクテカして待つことにしようｗ

無いよりはあった方が良いほどのものなのか、それともシングルスレッドに限れば
C2Dの価格競合モデルと良い勝負ができるほどなのか。
とにかく情報待ちですね。

>ゲームならアスロンの格言は健在w？

現在ゲームはマルチスレッド化に向かっていますし、
ビデオカードのデュアルコア最適化の行われているので
最近のゲームではほとんど変わらないと思いますがね？どうでしょう。

パフォーマンスが必要なアプリケーションはマルチコアに対応するだろうし。通常そういうアプリはプログラム的に待ち時間がないようにマルチスレッドなり、オーバーラップドI/Oなりを利用するはずです。
まずブロッキングはありえないでしょう。
不要なアプリケーションは、多数のタスクを動かしている環境下で、むしろ他のアプリケーションの邪魔にならないように素直に1CPUでヒッソリと動いてくれた方が好ましい。

こちらはIntelの「Core Multiplexing Technology」

Core Multiplexing TechnologyとSingle Processor Mode図解
http://www.xtremesystems.org/forums/showpost.php?p=1530747&postcount=2
BIOS設定（Core Multiplexing Technologyの下にSW Single Processor Modeという項目もある）
http://www.xtremesystems.org/forums/showpost.php?p=1533914&postcount=59
SW Single Processor Mode有効時と通常時のπ104万桁比較
http://www.xtremesystems.org/forums/showpost.php?p=1533996&postcount=63

Core Multiplexing Technologyをdisableにしたら起動しなかった、と書いてあるのでこの機能は元々有効になっていたみたいです（少なくともD975XBX Rev 304とConroe ES品の組み合わせにおいては）。
図を見る限りCore Multiplexing Technology有効時には、有効/無効をCPU内部で動的に切り替えて動作し、有効動作時は実質シングルコア状態になりCore0がCore1の実行ユニットを共有する形になります。

洋π104万桁比較では、SW Single Processor Mode有効時と通常時（Core Multiplexing Technology有効時）で、後者が速いどころか前者が0.56%速いという結果になっています。
実行ユニットだけ増やしても、フェッチやデコーダやOoO等の他の機構がそのままなら、ほとんど性能向上に寄与しません。当たり前と言えば当たり前の結果です。
結局、実行ユニット数に見合った命令の供給ができなければ意味はなく、そのためにはスケジューラの強化が必要で、膨大なトランジスタを食うことになります。（≒ポラックの法則）

ん？最近のOSが提供するAPIって内部的にマルチスレッドっしょ？
多かれ少なかれ普通に組まれた待ち時間アリのソフトウェアならデュアルコアは有効じゃ…。
あと3IPC前提の設計に、強引に実行ユニットだけ増やしても速度が上がるとは思えんのだけど…。ボトルネックが別の場所に来るだろうし
むしろ速度下がりそう…。

両者とも似たような事をやっているようですね。
それほど宣伝をしていないところを見ると...、おまけ機能的なものなのかも。
マルチスレッドアプリや、マルチタスクでは、スタンダードモードの方が速い、とかだったりして。

両社で既にコア設計も違うのに同じだろうみたいな考えが儲的なのでしょうか。

現状でシングルコアとデュアルコアで差がつく用途とほとんど変わらない用途どちららが多いかと言われれば後者が圧倒的に多いです。
ほとんどのソフトウェアがデュアルコアの方が明確に高速となるまでは有効な手段と考えられるでしょう。

ま、単純な予想では、片コアつぶして、OCみたいな予想もありますけどね〜。
その方が性能が伸びるんじゃないでしょうかね。

2個のCPUで調停を取る時間が大きすぎるため、速度上昇は殆ど無いか、マイナスに傾くかだろうと思います。
将来に1次キャッシュを共有するCPUが出た場合には、多少は効果が出るとは思いますが。

後はWin9x系で素直に1CPUとして使いたいケースでは心理的に効果があるかも？

コードとデータの両方がキャッシュに載ってしまうドライストンみたいなタイプと、コード（の一部？）しかキャッシュに収まらない3DMark(デュアル非対応の旧バージョン)などで、この効果を比べてみたいですね。PIは参考程度で。
というか、どの比較も基本的に参考程度だけど。いろんな比較結果を総合しないと結論は出せませんよね。

>両社で既にコア設計も違うのに同じだろうみたいな考えが儲的なのでしょうか。

同じなんて言ってないのに、敏感に反応しちゃうんだね。namelessは儲けだから仕方ないかw

プロセッサの高速化のアイデアに関しては、論文さかのぼっていくと結構昔のものが多いですよ。各社で実装方法が多少異なっても、似た感じに見えるのは共通のアイデアを元にしてるからでしょう。
今の論文みておけば5～6年後のプロセッサの姿が想像できるかも。今はまだハードウェア食い過ぎて実装できないアイデアがいくつもあります。

無理に高速化しようと思えば・・・

1.
Out of Order で、処理の順番を入れ替えてもOKなものを
別のCPUに処理してもらい、自身は処理の入れ替えられないもの
に集中する・・・
ただし、この程度の並列化なら現状のシングルCPU内でも
当然のごとく行われているし、でなければIPC3なんて
とても達成できません。
一方、SSE系の処理なら、単純だが膨大な数値演算の連続なので
並列化できるケースは多く、高速化の期待は持てます。
（かの悪名高い深いパイプラインのPentium4でもストールしなかったの
ですから、さらなる並列処理の余地はあるでしょう）

2.
処理の順番を入れ替えできないもの、代表的には分岐処理
の場合、もし分岐がAとBだった場合・・・
自身がAと予測した場合、Aとその続きを結果を待たず投機処理し
Bをもう片方のCPUが投機処理します。
もし、予測が外れてBだった場合、もう片方のCPUが処理を
続行すれば言い訳で、この場合、分岐予測が外れた場合の
ペナルティをゼロにできます・・・
ただし、もともとAthlon64は分岐予測精度では定評がありますし、
外した場合でも、パイプラインが浅いため、ペナルティは少なくて
済んでいるはずです。
実際のところ、どの程度のペナルティが発生しているかによって、
向上幅も決まってくるでしょう。

とりあえず、浮動小数点ユニットだけ使えればConroeに追いつくでしょ。

投機マルチスレッディング技術が出るまでの繋ぎですかねえ。

>ただし、もともとAthlon64は分岐予測精度では定評がありますし
これってプレスコットの間違いだよね?

どちらも分岐予測精度は昔に比べるとはるかに高いです。
どっちのほうがヒット率が高いかはわかりませんが、
Pentium4のほうがパイプラインが深いためにミスしたときの
ペナルティが大きいから全体で見ればAthlon64のほうが
無駄は少ないと思います。

>どちらも分岐予測精度は昔に比べるとはるかに高いです。
>どっちのほうがヒット率が高いかはわかりませんが、

実行ユニットと周辺デバイスとの速度乖離が顕著になってから
は実効性能を上げるには不可欠の技術となっていますから、
P6以降のCPUで分岐予測に注力していないものは無いといえます。

ただその実際の効果のほどは実行内容に大きく依存しますし、
そもそも設計思想の大きく異なるNetburstとK8で単純に
比較することに無理がありますね。

Reverse HTが効果を発揮するかどうかは増えた実行ユニット
をいかに遊ばせることなく使えるかどうかにかかっている
わけで、結局のところ一般のシングルスレッド性能向上の
手法と同じです。

ということは、分岐予測やプリフェッチが効果を発揮し、
高キャッシュヒット率を維持できる用途ではそれなりの効果を
発揮できるでしょう。

従って、Core2DuoがK8を大きく凌駕する分野ではリカバリー
可能なわけで、的を射た改良ではないかと思います。

ただ、リークされたベンチ結果からプリフェッチ・予測分岐の
性能はCore2Duoの方が高いと考えられますから、同様の機能を
INTELが採用したらさらなる性能向上が期待できそうです。

>従って、Core2DuoがK8を大きく凌駕する分野ではリカバリー
>可能なわけで、的を射た改良ではないかと思います。

焜炉も同様の機能は実装済みなわけでして・・
http://www.xtremesystems.org/forums/showpost.php?p=1530747&postcount=2

http://mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/Hammer-Info.html
後半でReverse-HTについて語ってますが、「これまで言われていた意味でのReverse-HT」が現在発売中の（来年発売予定のと範囲を広げたにしても）AMDプロセッサにおいて可能になるとは99.99%ぐらいの確率であり得ないと思います。

Hammer-Infoの人ですら「デコーダが増える=IPCが向上する」というウォーズマン理論は否定してますね

>Reverse HTが効果を発揮するかどうかは増えた実行ユニット
>をいかに遊ばせることなく使えるかどうかにかかっている
>わけで
waro

結局、現在のCPUにとって一番の問題は、命令分岐でどうするかだろうと思います。

現在のように予測精度に頼る方法は、トランジスタをとりすぎますし、そもそもQuadを超えるコア数になったときに、予測確率が上がるはずがありません。
ついでにメモリレイテンシが致命傷になりつつある現状では、メモリのバースト転送を維持することが最大の課題になるはずです。

というわけで個人的には、IA64系と同じように、命令分岐でYesとNoの両方を処理し、違う方を廃棄するやり方をReverse HTと言っているような気がします。
ただしオーバーヘッドが大きいので、専用の処理を行う部分を入れないと、高速化には繋がりにくい代物だと思います。
何れにせよQuadをDualとして扱わせようとする時なら、かなり現実的だと思います。

intelは本気で2コアを1CPUとして扱うかも…とも思います。
何しろintelですから…

> Hammer-Infoの人ですら「デコーダが増える=IPCが向上
> する」というウォーズマン理論は否定してますね

少々行きすぎな感のあるくらいにAMDに肯定的な（願望的）
予想が多い上記サイトで否定的なのは驚きですが、かといって
具体的な根拠も示さずに99.9%ありえないと断言されても
説得力が無いなと感じます。

実は自分も最初は単純な実行ユニット増設だけでは効果が薄く、実際に採用される可能性は低いだろうと考えていました。

というのも、長い間P6以降のアーキテクチャではIPCを
3以上に高めることはできない、というのが「定説」で、
それがデコーダ・実行ユニットを一定数にとどめ、その
範囲での最適化を各社各様に進めてきた経緯があるからです。

従ってデコーダやプリフェッチ・予測分岐の強化の伴わない
実行ユニット増設だけでは効果が無いと考えられるからです。

が、次の記事を見て、最新のアーキテクチャならIPCをそれ
以上に高めうるのかもしれないと思い始めました：

http://pc.watch.impress.co.jp/docs/2006/0626/kaigai285.htm

記事中にあるようにCoreアーキテクチャのCISC回帰による
IPC向上というアプローチは、すでにK7以降AMDが採用
しており、さらなるIPC向上を可能にする素地は以前から
できていたといえます。

デコーダ等の強化もあればさらに普遍的な性能向上を達成
できるでしょうが、実装コストが高いので性能対消費電力を
重視する今のトレンドとは逆行する流れです。

ReverseHTなる機能なら、効果を発揮する場面は限定的
ながら、実装コストによっては面白い技術ではないかと
思います。

>かといって具体的な根拠も示さずに99.9%ありえないと断言されても
この技術に否定的な立場を取るか否かで現行のx86CPUをどこまで理解してるかがわかるね。
Hammer-Infoの人はそれなりに造詣が深いようで。

>http://pc.watch.impress.co.jp/docs/2006/0626/kaigai285.htm
この後藤氏の記事に安藤氏は異論を唱えてますが。
http://www.geocities.jp/andosprocinfo/wadai06/20060701.htm
「CISCへの回帰」とかわけのわからんものより王道的な改良が効いていると、当たり前の主張ですが。

>現在のように予測精度に頼る方法は、トランジスタをとりすぎますし、
>そもそもQuadを超えるコア数になったときに、予測確率が上がるはずがありません。
>というわけで個人的には、IA64系と同じように、命令分岐でYesとNoの両方を処理し、
>違う方を廃棄するやり方をReverse HTと言っているような気がします。
>何れにせよQuadをDualとして扱わせようとする時なら、かなり現実的だと思います。
waro

ここは個人のblogですので、sugariさんも通りすがられさんも、議論は他の場所でやっていただけませんか？

安藤氏のHPの内容は、冒頭こそCISCへの回帰という見出しに
ついて疑問を呈していますが、その後の文章を見ると、「Core
の新機能」とIntelが主張する手法がすでに非X86系では実績
のあるもので別段目新しい手法ではない、という主張で、
そういったアプローチの実効性そのものを否定しているわけ
ではないようですが。

確かに、Coreの高性能の最大のカギが同時命令実行数の増加に
あるというのは確かにその通りだと思います。

ただ、前述のようにマイクロコードに分解してリアルタイムに
同時実行可能な命令組み合わせを探すアーキテクチャでは、
継続的に3IPC以上の実効性能を維持するのは難しいわけで、
マイクロOP Fusionをはじめとする手法との組み合わせ
によってはじめて効果を発揮するものであるのもまた確か
でしょう。

そして、それによって得られる性能向上は効果は限定的される
もののシンプルな実行ユニット数増加によっても一定の性能
向上が得られることになりますね。
しかもそのために必要な実装上のコストはごく小規模で済みます。

であれば実際の効果はともかくとしても別に搭載しても損は
無いかなと考えますが。

まあ、アーキテクチャに関する実測データを伴わない議論は
主張者の考え方次第でどうにでも変わるものですから、
延々と自分の主張を述べたところで仕方が無いのも確かです。
また正直、このReverseHTなる機能が声を大にして主張する
ほどの良い機能だと思っているわけでもありません＾＾；

ただ、実装コストの少なさとAMDがおかれた状況を考えると、
採用する可能性はあるんじゃないかと「予想している」だけです。