x86命令の所要クロック計測スレPart2
■ このスレッドは過去ログ倉庫に格納されています
0481201
2006/06/27(火) 01:34:12シングルコアにしたって必ずデコードしてるので、片コアの性能は落ちないはずです。
このデコード時に担当レジスタを決めてもう片方に伝えてしまえば、デコードに関する相互参照は無くなります。
もしくは、デコード時にCore1が「Core0はどのレジスタを担当しようとしているか」を
予測出来るスケジュール規則にしておけば、残りが自分の担当というわけで、担当レジスタを伝える必要も無くなります。
これなら片方が中心になる必要も無いので真にSMPで実現出来ますね。
「1.3のケースで1.5が出れば万々歳」には激しく同意です。
以下は>>469を見ただけで理解出来た人には蛇足です。
>>469のコードで左側のコアに注目した場合、
右側のコアの最初の2行は、完全に同期してもほんの少しはIPCを上げられそうですが
実際には左のコアがレジスタの内容を非同期で送信してしまえば、
左のコアは止まる事無く勝手に続けてしまって構わないわけです。
バッファがいっぱいになれば、もしくはバッファを持たない場合で送信命令が連続している場合は
前の送信が完了するまで待つ必要がありますが、
実際には常時もう片方を参照しなければならないようなコードは稀なのでIPCは向上します。
片コアだけどんどん先に行ってしまうとバッファがいっぱいになり(バッファ無しでも同じ)
ただでさえボトルネックな通信が更にボトルネックになってしまうので、
通信を均等にさせるように振らないといけなそうですね。
あとは通信にかかる時間がどれくらいかですが…専用に繋がっていればもちろん速いですし、
L1の様な広大な空間&大きなラインサイズではなくレジスタの数とサイズはたかが知れているので速く出来ないですかね?
と、妄想なのに力説してしまいましたが、この方法が実現出来た場合に嬉しい事は、同じ事をマルチコアでやらせるのでは*無い*という事。
通信を無視すればデコーダと演算器の多いCPUとして機能するので、マルチスレッドかが困難なアプリケーションのIPCを上げられるという事です。
■ このスレッドは過去ログ倉庫に格納されています