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