アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
ありえないけど (スコア:0)
瞬く間にシェア入れ替えが起きる。
なんて話になれば面白いけどな。
Re: (スコア:1)
# RISCの時にもあったわけだが。
Re:ありえないけど (スコア:1, 興味深い)
結局優秀なfab持ってるところが勝ちということで。
ManyCoreって口では簡単だけど実際はキャッシュの問題とかあってそれはもう大変です。
その点Intelはコンパイラなどソフトのほうもいろいろ研究しているから、これを
ひっくりかえすのはきついかと。
Re:ありえないけど (スコア:4, すばらしい洞察)
メニーコアを単にプロセッサを増やすものだとか思ってない?
実行ユニットはコアほど増やされないだろうし、もれはキャッシュが複雑になっても全体としてはかなり減ると思ってるよ。
というのは、まず投機実行は(ミス時のペナルティに他のコアを止めていた分も入るようになるため)メニーコアには有害なのでなくなるし、OutOfOrder発行(実行も?)も常に実行できる命令があるとみなせるために意味を失う。これに伴いレジスタリネーミングも無意味になる。要するに依存関係管理がただのコンテキストロックで済むようになるわけだ。
んで、これはSilverThomeがin-orderな理由でもある。
苦労してOutOfOrderしても綜合パフォーマンス的には無意味なんだ。
# さらに、少ないコアのままではパフォーマンスを向上できそうにないから「ソフトをマルチコア前提にしる!」なんて言ったりしてる。
当然圧倒的に有利なIntelに追い付くのは簡単ではないが、少なくともこのような大きな変化がある時はどうにかしやすい事は確か。
Re: (スコア:0)
投機実行といってどういうものを念頭に置いているのか知らないが、
さすがに分岐とメモリアクセスは投機実行しないわけにはいかないよ。ペナルティは減る傾向にあるけどね。
キャッシュの問題は、どんなタイプのコアであれキャッシュコヒーレンスを捨てない限りは存在するし、
単純にコア数が増えると問題も複雑になる。
Re:ありえないけど (スコア:1)
SMT/SMPの理由からしてわかってないし、やっぱりマルチコアを「ただくっつけただけ」だと思ってるみたいだなー。
よーするにパラダイムの違いを認識できてない。
まず、一つのコンテキストから並列性を抽出するにのは限界があるんだよ。今まではそのためにOutOfOrder発行/実行したり投機実行したりしてたけど、例えばOutOfOrder発行/実行したり投機実行したりする範囲がループの範囲を越えたらどうする?そこから並列性を抽出するにはループであることを認識しなきゃならんよね?そのためのロジックがどんな規模になるか想像できる?
で、そこでSMT/SMPなわけ。別のコンテキストは常にと言っていいほど依存性がない。つまりそのまま複数のパイプラインに突っ込める。で、これをさらに推し進めるとメニーコアになる。一つのコンテキストを止めてもいつでも依存性のない命令が待ってるので実行ユニットを待たせることがない。要するにパイプライン充填率を上げたいだけなわけだけど。
んで、投機実行だが...投機実行しなくても実行ユニットは常に有為な命令で一杯なので投機実行する理由なんてないし、常に有為な命令で一杯な実行ユニットに無為かもしれない命令を投入するというのがどういうことか、わかるだろ? さらにそれをする回路がバカデカイと来ている。んなもんステステ。
あー、無条件分岐を含めたただの先読みは実行されるのがわかってるから投機実行とは言わないよ。しなくても綜合性能にはペナルティはないけど、しても単一コンテキストのパフォーマンスでメリットがあって回路規模以外のデメリットはないから、したきゃするだろうね。並列性検出メカニズムも同様に回路規模以外のデメリットはないから同様にしたきゃするだろう。
キャッシュは確かに複雑にはなるだろうが同一ラインを複数のコンテキストでつつく行為は現状(のマルチコアではないSMP)でもペナルティが大きい行為だし、そのペナルティがさらに大きくなる実装で問題の複雑化を緩和することはできるんじゃない?
Re: (スコア:0)
最初から最後まで、理解できる文章が一つもなかった。
> 例えばOutOfOrder発行/実行したり投機実行したりする範囲がループの範囲を越えたらどうする?
どうする？と聞かれても。。。どうもしないよ。
> 要するにパイプライン充填率を上げたいだけなわけだけど。
SMTのことならわかるが、SMPとどう関係あるのか。。。
> 投機実行しなくても実行ユニットは常に有為な命令で一杯なので投機実行する理由なんてないし、
投機実行しないということは、条件分岐やTLBヒットが確定するまで命令フェッチを止めて他のコンテクストを実行する？
SMTと言えどもそれはちょっと。
> そのペナルティがさらに大きくなる実装で問題の複雑化を緩和することはできるんじゃない?
ペナルティが大きくなると問題が簡単になる？？？
Re:ありえないけど (スコア:1)
それがまさにプロセッサによる並列性抽出の限界なのでつ。
>SMTのことならわかるが、SMPとどう関係あるのか。。。
意味は同じだよ。メニーコアなSMPはSMTの「コア」にMMUがそれぞれ付いただけのモノだから。
# だから、メニーコアはソフトから見える「風景」とは違って、プロセッサをたくさんくっつけただけのものではない。
>投機実行しないということは、条件分岐やTLBヒットが確定するまで命令フェッチを止めて他のコンテクストを実行する？
>SMTと言えどもそれはちょっと。
それをするのが「メニーコア前提」。止めるのは命令フェッチというよりは実行ユニットへの投入だけど結果的には同じ。他にも実行結果への依存なんかでも実行は止まる。これは今のプロセッサでも同じで投機実行だのOutOfOrderだのはこの問題を軽減はするけど解決はしてない。止まる時は止まる。
# TLBヒット云々はレイヤが違うが解決方法は同じ。でもプロセスが増えるとちょっと苦しいかもね。
>ペナルティが大きくなると問題が簡単になる？？？
簡単になるのは回路、大きくなるのはキャッシュスヌーブ衝突時のペナルティ。で、そもそもここではキャッシュ制御回路が複雑になるのが問題なんだから、この方針で問題を軽減できる。でも同期のためのメモリを触らない命令が欲しいところでもある。
Re: (スコア:0)
いわゆる"absolute nonsense"というやつですね。
私が勝手にいろいろ補完していたので、おかしな説明に感じられていたようです。
Re:ありえないけど (スコア:1)