Re: [問題] 常用指令的時脈開銷?

[littleshan (我要加入劍道社!)]

※ 引述《DrStein (啤酒肚)》之銘言：
: 開發平台(Platform): (Ex: VC++, GCC, Linux, ...)
:         x86, arm, mips, powerPC....etc
: 問題(Question)：
:         常用指令 大體上就是:
:         整數 的加法，乘法 ，除法
:         32位 加法，乘法
:         64位 加法，乘法
:         想知道這些指令分別消耗多少時鐘數。。。
:         小弟只知道 x86 :
:         整數 加法 -> 2時鐘
:         整數 乘/除 -> 三時鐘數  ( 看架構，沙橋就是兩個時鐘(?))
:         平移，指定該是都一個時鐘數。
:         有這些才好精確定論，程式是卡在記憶體交換上還是運算上
:         有神人可以幫補完這張表嗎 謝謝
去找 CPU 的 spec 就會有這張表
但即使你有這張表，也沒有太大的幫助就是了
因為:
 1. pipelining
    一道指令在 CPU 中至少會經過 fetch/decode/load/execute/store 等階段
    而 x86 架構下由於指令複雜，一般都會把一道指令再拆成更小的μOp
    同樣的指令在不同的情況下 (前後指令都會影響到 pipeline 的執行效率)
    會消耗不同的 cpu cycle

 2. super scalar
    現代的 CPU 都有複數個運算單元，因此如果有兩道不相依的相同指令：
    add eax, ebx
    add ecx, edx
    像上述的情況，因為 CPU 擁有兩個加法器，它可以同時執行這兩道指令。

 3. out-of-order
    前述的 super scalar 有其限制，也就是指令必需互不相依才能同時執行。
    因此在不影響結果的前提下，
    CPU 會試圖調整指令的順序，儘量讓互不相依的指令排在一起以利平行化。

因為這些複雜的因素，直接把所有指令耗用的 cpu cycle 加起來是非常不精確的。

所以就如板友說的，要了解自己程式的時間花在哪裡，用 profiler 比較好。
另一個方法是使用 simulator 之類的來模擬真正的 CPU

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 114.32.15.163
推 DrStein:x86不是都把指令流水線優化到不行? 所以1.該是沒問題吧
→ james732:優化到不行的話，不就更代表單一指令的時間沒啥意義嗎？
→ littleshan:要看compiler呀
→ DrStein:優化到極致 不是只看execute 的時間就好了?
→ DrStein:這和編譯器有什麼關系? 流水線優化完全是硬體內部的事
→ Ebergies:不一樣, 因為 execute 時間比較長, 而且程式結構不同
→ DrStein:一樣的命令，好的cpu流水線更深，亂序運行範圍更廣
→ Ebergies:指令 compact (?) 的比例也不一樣
→ Ebergies:所以才說用 profiler 比較好
推 DrStein:在下是想自己用執行的時間加總起來 就差不多是cpu運行時間
→ DrStein:若這時間與實既時間差異過大 那就是卡在記譯體訪問上
→ james732:我可以請問為什麼你不考慮用 profiler 嗎...XD
→ DrStein:能用紙筆就用紙筆，編程珠磯裡面也有提到 估算
→ DrStein:估算是種讓自己掌握系統能力的訓練
→ littleshan:最好是你可以神準預測branch prediction有沒有命中
→ james732:我以為"估算"是算演算法的時間/空間複雜度這類的東西?
推 tropical72:branch prediction 的確是難以處理的東西.
推 danielguo:另外記憶體 cache locality 的影響不小, 紙筆只能猜測
→ jwboy:覺得如果用迴圈兜的話，branch prediction影響不大