- Intel Larrabee 1コア
44 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 00:44:21 ID:6R6YXCRn - 光の速度知ってる？電子の移動速度はそれよりずっと遅い。何の制約もなしにクロックが引き上げ続けられるなら、
マルチコアへのシフトなんてそもそもありえないっつーの。
もはやパイプラインを細分化してももはやクロックはそれほどのびないし
細分化した分パイプラインハザードのペナルティ食らって効率が上がらない。
もはやマルチコアのほうが高いスケーラビリティが得られる。
GPUで肩代わりさせてきた処理分野におけるCPUの復権が当面の目的。
グラフィックプロセッシングはピクセル数分は並列化可能だから、
CPUのマルチコア化を推進する動機としては十分だからな。
| - CPUアーキテクチャについて語れ 11
350 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 01:59:38 ID:6R6YXCRn - とまあ、案の定俺が言ったことそのまんまになりました。
互換こそ強みってのは皮肉にも後藤自身が説明したことなんだけどな。
彼は解釈に一貫性がないようで。
LarrabeeのSIMDはVEXの予約空間の一部を用いた512ビット版AVXってのはほぼ確定かな。
逆にそれ以外、無理なく割り当て可能なフィールドは無いだろう。
| - CPUアーキテクチャについて語れ 11
352 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 02:21:31 ID:6R6YXCRn - 勝利とかｗｗｗ
そんなものは求めていない。
最適化屋に必要なのはディベートではなく理想のCPUアーキテクチャなんだよ。
まして何言われても持論の間違いを認めない誰かさんみたいなバカが勝者(笑)なんて
当人以外思っちゃいない。
| - Intelの次世代CPUについて語ろう 35
271 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 03:46:06 ID:6R6YXCRn - http://pc.watch.impress.co.jp/docs/2008/0822/kaigai461.htm
Ctについては>>182あたりに書いたことがドンピシャ。
Larrabee新命令はどうやら既存命令とはOpcode食い合わないらしい
（＝512ビット版AVXそのものの先行実装の可能性大）
Larrabeeの位置づけといい、俺どれだけエスパーだよ
あまりに予想が当たりすぎててもう笑うしかねー
| - CPUアーキテクチャについて語れ 11
358 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 16:25:04 ID:6R6YXCRn - 逆に「動かない根拠」を提示してくれ。動くべきという根拠は示してる。
あ、後藤は想像に任せるとたまにとんでもない解釈をやるから却下。
まあ決め手はこの辺かな
・LNIは既存命令のOpcodeの共存を考慮したSSEの延長上の命令群。
・3オペランド拡張はAVXのVEXプレフィクスを使うことで実現でき、
しかも拡張フィールドがかなり余ってる。
→LNIはAVXの派生命令セットと考えるのが妥当。
・Intelには上位命令のサポートにあたり下位命令のサポートを打ち切った前例がない。
→SSEからLNIのゆるやかな移行も考慮すべき
・マスク・シャッフル機構も備えるよりワイドなSIMDユニットで128ビットのSIMDをサポートできない理由がない。
あとは、デコード部だが
スカラ部がPentium命令完全互換と言ってることが、むしろ確信させる要因となる。
つまりデコード盲腸であるx87すら使えるということ。
x87超越関数みたいなマイクロコードROM容量を圧迫する命令を削らないで
SSEみたいな比較的コストの高くない命令群のデコードをサポートできない
技術的理由がないからね。
もちSSEはVPUでやればよく、P5世代といわれるスカラパイプ自体に大きく手を入れる必要はない。
もちろんVPUでは小回りが利かない一部のSSE命令をマイクロコードで実装することもできる。
SSEはレガシィ扱いなので多少遅い程度なら問題ない。動くことが重要。
スカラ側がノーマルP5＋αってのとベクタ側でのSSE命令のサポートは、何ら矛盾しない。
| - CPUアーキテクチャについて語れ 11
359 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 17:05:37 ID:6R6YXCRn - OS含め「あらゆるコードが動く」って言ってるしね。
XMMレジスタがない64ビットなんてのもありえない。
x64非互換の新たな基本ISAを定義する必要が生じてしまう。
LNIは汎用IAでのサポートをも見越した命令群だと説明してる傍らで
自らの互換戦略と矛盾することを敢えてやる合理的理由がどこにあるかね？
| - CPUアーキテクチャについて語れ 11
361 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 18:45:32 ID:6R6YXCRn - > SSEがあったらいいナ
ないとx86の互換性戦略として矛盾する
> LarrabeeでSSEをサポートしたくない
お前の願望は聞いてない
ゲルジンガーの言葉のほうが説得力がある。
> LarrabeeのVPUが性能向上のためによりゆるやかなメモリコンシステンシモデルを採用している可能性が捨てられないし、
捨ててください。
> そうするとSSEと互換性を維持するのはそれなりのコストがかかる
何故？と言う質問はさておき
GPUとしての効率のために後方互換と言うメリットを犠牲にしたら
x86を選んだ意味そのものが否定されるよね。
・Larrabeeに移植して高速化できる可能性が高いx86コードほどSSEに依存している。
・SSEを排除したら64ビット拡張はx64との互換性がなくなってしまう。
性能の為なら基本ISAを分断するような問題すらあってもかまわないかのような前提でのあんたの仮説に価値はない。
べつに速く動けとは言ってない。
1命令10クロックかかってでもとにかく動くことが大事。
| - CPUアーキテクチャについて語れ 11
365 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 19:09:47 ID:6R6YXCRn - 根拠のない「可能性」を語るあんたほど感情的なもんはないよ
SSEをサポートしないのはこれまでIntelのとってきた方針と矛盾するし、
しないことで起きる問題のほうが甚大だ。
AVXのマニュアルなんかに目を通せばx86における
バイナリコードを含むコード資産の継承についてIntelの思想が理解できる。
| - CPUアーキテクチャについて語れ 11
366 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 19:22:34 ID:6R6YXCRn - >>364
ようやくまともな意見が出てきて安心した
SSE未サポート説を唱えるバカ連中は
「SSE抜きの64ビット拡張作ったから64ビットWindowsをもう1バージョン作ってね」
なんて通ると思ってるのかね。Yamhillプランすら踏みつぶしたMSに。
SSEの互換を切り捨てることで得られるメリット（あるのか？）にどんな幻想を抱いてるのか
さっぱり解りかねる
| - CPUアーキテクチャについて語れ 11
368 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 19:29:29 ID:6R6YXCRn - それはあんたが趣味でASIC組んでやってくれ。
1個人の願望をIntelに求めるな。
| - CPUアーキテクチャについて語れ 11
372 ：,,・´∀｀・,,）っ[]：2008/08/22(金) 19:44:25 ID:6R6YXCRn - ＞ウィークコンシステンシ
つか逆に、x86って常にL/S順序は一貫してたっけ？
じゃあ{m,l,s}fence命令は何のためにあるの？
SSEなんて殆どレジスタに作用する命令だし
VPU演算結果出力の下128ビットだけをXMMレジスタリに書き込むだけで良いはずなんだが。
なぜそれを無理と言い出すのか理解不能だったんだがようやく理解できた
x86命令セットを何も知らんのだろ？
| - CPUアーキテクチャについて語れ 11
374 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 19:57:10 ID:6R6YXCRn - XMMレジスタを一切読み書きしないx64用OSはおそらく存在すらしないな。
| - CPUアーキテクチャについて語れ 11
378 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 21:20:00 ID:6R6YXCRn - 珍説の動機はそんなことか
ずいぶんくだんねーな。
そりゃシリアル化が必要なところでは使わなきゃしゃーないし
SSEが使えないとする理由にはなり得ない。
P6、NetBurstのときも異常に遅い命令があって、最適化マニュアルにて使用非推奨にしたことはあった。
でも#UDにした命令はいまだかつてないんだよね。
| - CPUアーキテクチャについて語れ 11
380 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 21:32:02 ID:6R6YXCRn - それとも、SSEのあらゆる命令を使うと自動的にフェンスの副作用が起きるとでも思ってるのか？
x64で標準仕様となってるXMMレジスタとスカラ/SIMD命令が使えなくなる理由ならえらい迷惑な勘違いだぞ？
フェンスなんてそもそも頻繁に使う命令じゃねーよ。
マルチスレッド環境での共有変数の読み書きには必要ではある。
| - CPUアーキテクチャについて語れ 11
385 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 21:45:08 ID:6R6YXCRn - >>379
動くことに意味があるんだよ。
遅いとは言ってもx87よりは速いのは確実だし、動かないのは論外。
Intelは「緩やかな移行」の手段を提供してきた。
新命令に最適化して効果が大きい部分をまず先に重点的に新命令に書き換える
という選択肢が得られる。それがコード資産の継承の最大の意味。
いきなり全部書き直しだと、CellやCUDAに対する強みにならない。
| - CPUアーキテクチャについて語れ 11
388 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 22:00:13 ID:6R6YXCRn - フェンスの副作用のない命令までなんで禁止しないといけないの？
SSEにはベクトル要素毎に独立にメモリアクセスするようなLS命令はない。
シリアル化が必要なところで明示的なフェンス制御命令はどのみち必要だ。
SSEを禁止する理由にならない。
だいたいに16要素の独立ロード・ストアを等速で同時にこなせるわけがないだろJK
マスクを駆使して最大16回L/S発行するだけかもしらん。もちろんパイプラインはストールする。
キャッシュライン縛りの兼ね合いもあるし、
アセンブリレベルの生産性の向上には寄与するかもしれんが
スループットは最初から期待できない。
| - CPUアーキテクチャについて語れ 11
399 ：,,・´∀｀・,,）っ[sage]：2008/08/22(金) 23:05:53 ID:6R6YXCRn - シリアル化が必要なところで明示的なフェンス制御命令はどのみち必要だ。
SSEを禁止する理由にならない。
だいたいに16要素の独立ロード・ストアを等速で同時にこなせるわけがないだろJK
おそらくマスクを駆使して最大16回L/S発行するだけ。もちろんパイプラインはストールする。
キャッシュライン縛り（64か128バイト単位？でのデータ移動）の制約もあるからリッチにするだけ無駄。
アセンブリレベルの生産性の向上には寄与するかもしれんが。
|
|