寫程式碼的時候應該儘量用加法代替乘法?某琳2018-07-12 16:49:51

TLDR:沒影響

以下詳細解釋

取決於底層的CPU

在x86-64架構上,單就指令延遲和吞吐來說,成立

以牙膏廠的Ivy Bridge架構為例,ADD指令的延遲為1(即1週期後結果可用),吞吐為1/3(即實際計算佔用1/3週期),MUL指令的延遲為低64位3,高64位4,吞吐為1

可見乘法的延遲和吞吐都是比加法高的

Intel® 64 and IA-32 Architectures Optimization Reference Manual

參見表C-17

而且x86-64架構上乘法的目標暫存器是固定為DX:AX的(見指令集手冊B卷147頁),這一點還會影響編譯器的暫存器分配,何況x86-64本身暫存器就不多

Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B: Instruction Set Reference, M-U

但是別忘了現代的CPU的一些特性

首先,亂序執行,也就是說除非是高計算密度(受制於吞吐)或者是一個系列的計算(受制於延遲),CPU在等指令結果的時候完全可以去處理後續與目前操作沒有衝突的指令

其次,暫存器重新命名,雖然架構只定義了16個暫存器,但是CPU內可能還存在其它的暫存器,CPU分析指令資料流後可以靠這些暫存器打斷WAW和WAR型的依賴關係

綜合來說,除非你是在做高效能高密度計算,不然不需要關心這點,而如果你確實在做高效能高密度計算的話,首先應該考慮的最佳化途徑也不應該是減少乘法,而是資料本地性和SIMD

寫程式碼的時候應該儘量用加法代替乘法?桶桶子2018-07-12 23:06:06

謝……謝邀

邀……邀錯人了……我什麼都不懂……

還是讓大佬來肥答叭 @荊楚笑笑生

啾咪ฅ(*°ω°*ฅ)*

寫程式碼的時候應該儘量用加法代替乘法?Fortuna丶i2018-07-13 08:54:57

謝邀!個人理解如下:

這個東西,好久沒研究了。這個問題不應該這麼問,並不是用加法代替乘法,或者是用減法代替除法。你往底層編譯器層面考慮,比如2 * 3,實際上的運算應該是儲存器為“2”開闢一個記憶體空間用於存放2,讓它進行2 * 3的運算,就需要在開闢一個記憶體空間存放另外一個2,讓2 + 2 在此基礎上再 + 2,以實現2 * 3的運算。除法也類似, 求5 / 2,那麼就是 5 - 2 - 2 = 1。不然,又如何告訴編譯器讓它進行加減乘除呢,所以這個問題應該是所有的計算都是建立在加減的基礎上的,乘除也不過都是在此基礎上演變過來的。

所以這個問題,結果就可想而知了

寫程式碼的時候應該儘量用加法代替乘法?沙子2018-07-13 17:33:28

請注意每個指令的時鐘週期,這個決定了指令的執行時間

寫程式碼的時候應該儘量用加法代替乘法?陋儒2018-07-14 14:21:48

這個看CPU的指令集。如果CPU支援乘法,那就是乘法快。在一些主要用於資料計算的CPU裡,比如DSP,支援MIMD,也就是一個指令週期同時可以做加法乘法和取資料,這種情況如果純粹給它加法,就浪費資源了。

編譯器會幫解決很多問題,不支援乘法的CPU,會幫編譯成加法。所以還是推薦該乘法就乘法,該加法就加法。

最後,我只聽說最好除法改成乘法。