アカウント名:
パスワード:
EPICアーキテクチャの方向性から大間違いだったから。
Itaniumの目指したILPの向上が遅々として進まないのに対して、マルチコア使ったTLPの向上の方がCPU開発者もソフト開発者も楽だった。これは遅くとも2005年には明らかだった。
今のItaniumはアーキテクチャがボロボロなのを、でかいキャッシュだけでごまかしている欠陥品。廃れて当然。
それを言うなら実際のコードはVLIWするほど並列度がない事が多いって話だろう。DSPやグラボみたいな応用なら良かったんだろうけどな。
マルチメディア系など並列性の高いコード→そこだけSIMD命令使うようにすればいいそれ以外→もっと大きい単位で並列化（マルチスレッド）がいい
という感じですかね。
スレッドが違うとそれぞれのデータやコードは独立だから何も考えずに並列化できる。究極的にはプロセッサがスレッドの管理やって、命令一つでスレッド起こせるくらいになると思う。そうするとループの代わりにスレッド起こせるからね。# これに向いてるアーキテクチャが昔懐かしのスタックコンピュータ。# 明示的に割り当てなくてもスタックを使えるので本当に命令一つでスレッド起こせる。
あと、画像処理とかみたいに処理自体が巨大で、並列なのが分かりきってる処理はGPUにやらせちゃえってのがGPU内蔵化の流れ。SIMD命令はGPUに吸収されて消えるかもね。互換性があるから暫くは残るとしても。
タスクゲートへのジャンプ命令やコール命令がスタックの確保やレジスタの初期値設定までしてくれるとは初耳だなー。もっと詳しく教えてくれまいか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
しかしItaniumは何故こうなった (スコア:1, 興味深い)
インテルの最強の生産設備
インテルの資金力
これだけそろってるのにパッとしなかったのは何故だろう
Re: (スコア:0)
EPICアーキテクチャの方向性から大間違いだったから。
Itaniumの目指したILPの向上が遅々として進まないのに対して、
マルチコア使ったTLPの向上の方がCPU開発者もソフト開発者も楽だった。
これは遅くとも2005年には明らかだった。
今のItaniumはアーキテクチャがボロボロなのを、でかいキャッシュだけでごまかしている欠陥品。
廃れて当然。
Re: (スコア:0)
Re: (スコア:2, 興味深い)
それを言うなら実際のコードはVLIWするほど並列度がない事が多いって話だろう。
DSPやグラボみたいな応用なら良かったんだろうけどな。
Re: (スコア:0)
マルチメディア系など並列性の高いコード→そこだけSIMD命令使うようにすればいい
それ以外→もっと大きい単位で並列化（マルチスレッド）がいい
という感じですかね。
Re: (スコア:3, 興味深い)
スレッドが違うとそれぞれのデータやコードは独立だから何も考えずに並列化できる。
究極的にはプロセッサがスレッドの管理やって、命令一つでスレッド起こせるくらいになると思う。
そうするとループの代わりにスレッド起こせるからね。
# これに向いてるアーキテクチャが昔懐かしのスタックコンピュータ。
# 明示的に割り当てなくてもスタックを使えるので本当に命令一つでスレッド起こせる。
あと、画像処理とかみたいに処理自体が巨大で、並列なのが分かりきってる処理はGPUにやらせちゃえってのがGPU内蔵化の流れ。
SIMD命令はGPUに吸収されて消えるかもね。互換性があるから暫くは残るとしても。
Re: (スコア:0)
Re:しかしItaniumは何故こうなった (スコア:1)
タスクゲートへのジャンプ命令やコール命令がスタックの確保やレジスタの初期値設定までしてくれるとは初耳だなー。
もっと詳しく教えてくれまいか？