c語言裡為什麼直觀的計算量更大卻計算更快？

1樓：安雨河

看反了，我配置的vscode+gcc（就是知乎上推薦的那一套）+i7 7700hq

好像2比1有0.5~1秒延遲，倒是沒有題主所說的那麼明顯的情況。

duration 1: 28.529000 sec, b = -2.423830

duration 2: 29.112000 sec, b = -2.423830

duration 1: 28.224000 sec, b = -2.423830

duration 2: 29.384000 sec, b = -2.423830

duration 1: 28.301000 sec, b = -2.423830

duration 2: 28.842000 sec, b = -2.423830

還有一次等待時間超過一分鐘了。

另外，縮小迴圈規模到***時

duration 1: 1.130000 sec, b = -2.423830

duration 2: 1.143000 sec, b = -2.423830

duration 1: 1.132000 sec, b = -2.423830

duration 2: 1.150000 sec, b = -2.423830

duration 1: 1.164000 sec, b = -2.423830

duration 2: 1.152000 sec, b = -2.423830

duration 1: 1.151000 sec, b = -2.423830

duration 2: 1.146000 sec, b = -2.423830

讓我想起來我初學微控制器時，書裡面說c語言對時間無法精準測試的事。或許0.5秒差距與此有關？

2樓：

基於某匿名使用者的答案，謹慎猜測，是CPU data path裡面forwarding path在不同情況下的不同延遲導致的。

test1的指令執行順序正好用上了最快的forwarding path；test2沒用上，結果導致uop等了更長的時間才被reschedule。應該和uop針對oprand的dispatch/schedule演算法有關。

3樓：saturnman

個人覺得不是編譯器的問題，我看了clang的彙編，確實更複雜的計算指令多了一條，你可以在隨便設定乙個變數xx,在迴圈裡讓xx=2.0之類，也能讓計算變快。我覺得可能是新的intel處理器內對迴圈進行了亂序執行和迴圈展開之類造成的，我沒有老處理器也沒有辦法測試。

不過一般測試執行速度指令過少幾乎沒有意義，因為CPU實在是太過複雜了。

補充一下，在ARM平台跑了一下，結果符合預期，ARM沒那麼多深度的再優化能力。

4樓：

不應該快，就算兩個乘法一步做，那也一樣快而已。這跟 CPU 有關，把硬體貼上來再說，會有人幫你看，搞 Hash 的人特喜歡。

5樓：Hippop

MSVC並沒有你說的情況:

我覺得，對於簡單的算術運算，優化的步驟完全可以靠編譯器來做，用不著把編譯器當傻子。現在的編譯技術優化能力已經遠遠超過算術表示式的化簡範圍了。這個程式要是開優化，這兩個for都是不存在的，時間為0。