長整數運算

兩部分兩個我的問題。這是更有效/快：長整數運算

int a,b,c,d,e,f; 
int a1,b1,c1,d1,e1,f1; 
int SumValue=0; // oops forgot zero 
// ... define all values 
SumValue=a*a1+b*b1+c*c1+d*d1+e*e1*f*f1;

或

Sumvalue+=a*a1+b*b1+c*c1; 
Sumvalue+=d*d1+e*e1*f*f1;

我猜第一個是。我的第二個問題是爲什麼。

我想第三個問題是，在任何時候都有必要分解一個加法運算（除了編譯器對延長線數的限制等）。

編輯

是唯一一次我會看到一個緩慢下來的時候那麼整個運算不能在緩存合適？我認爲這是不可能的 - 在這種情況發生之前，編譯器可能會對兩行很多行繼續生氣。也許我必須明天打球並看看。

來源

2010-10-26 Marm0t

它的算術，用'e':-) – Arun 2010-10-26 05:51:53

把它們放在一個非常大的循環中，並計時。然後你會知道哪一個更快。 – abelenky 2010-10-26 06:04:03

@ArunSaha，爲什麼評論你可以編輯？ :-) – ergosys 2010-10-26 08:01:02

你測量了嗎？兩種方法的優化機器代碼可能非常相似，如果不相同的話。

編輯：我只是測試這一點，結果是我所期待的：

$ gcc -O2 -S math1.c # your first approach 
$ gcc -O2 -S math2.c # your second approach 
$ diff -u math1.s math2.s 

--- math1.s 2010-10-26 19:35:06.487021094 +0200 
+++ math2.s 2010-10-26 19:35:08.918020954 +0200 
@@ -1,4 +1,4 @@ 
- .file "math1.c" 
+ .file "math2.c" 
    .section .rodata.str1.1,"aMS",@progbits,1 
.LC0: 
    .string "%d\n"

就是這樣。相同的機器代碼。

來源

2010-10-26 05:42:59

是的，但是您生成的機器碼可能甚至不會執行算術運算，至少如果您從OP複製粘貼片段。如果你使用優化標誌，它可能會優化算術，因爲你實際上沒有對'SumValue'做任何事情。當我查看由gcc生成的程序集時，如果我設置優化標誌，它甚至不會執行算術。 '.main'部分中唯一的是'ret'指令。 – 2010-10-26 06:27:57

感謝 - 應該有自己diff'd它我沒有想到：） – Marm0t 2010-10-26 11:57:22

@Charles，我確信'SumValue'被用於傳遞給'printf（「％d \ n」）'和結果是相同的。 – 2010-11-11 03:38:26

他們很可能會被轉換成相同數量的機器指令，所以他們會花費相同的時間長度。

來源

2010-10-26 05:43:16 oadams

這就是爲什麼它有助於熟悉彙編語言。在這兩種情況下，都會生成彙編指令，將操作數對加載到寄存器並執行加法/乘法運算，並將結果存儲在寄存器中。也可以生成的指令存儲在由SumValue代表的內存地址最終的結果，這取決於你如何使用SumValue.

總之，無論結構是可能執行相同的，尤其是優化標誌。即使他們不是在某個平臺上執行相同的操作，但這兩種方法都沒有內在的東西可以真正幫助解釋爲什麼在C++級別。充其量，通過查看編譯器如何將C++結構轉換爲彙編指令，您將能夠理解其中一個性能優於另一個的原因。

我想第三個問題是，在任何點就必須打破了加法運算（除了編譯器限制上線延續等等數）。

這不是真的需要分手加法操作。但它可能有助於可讀性。

來源

2010-10-26 05:51:55

在一行上可以組合的操作數量沒有任何限制......實際上，編譯器會接受任何您要關注的數字。編譯器考慮操作發生在換行符被約定很久之後 - 它正在處理詞法符號和語法規則，然後是抽象語法樹。除非你的編譯器編寫得非常糟糕，否則這兩個語句對於int數據的性能都會很好。請注意，在result = a * b + c * d + e * f等情況下，編譯器沒有序列點並且知道優先級，所以完全自由地評估並組合子表達式（給定的硬件）。結果+ = a * b;結果+ = c * d;方法中，您要插入序列點，以便編譯器被要求在另一個之前完成一個表達式，但可以自由地並且應該 - 意識到結果不會在增量之間的其他地方使用，因此可以像第一種情況那樣自由地進行優化。

更一般地說：我可以給這樣的性能查詢最好的建議是1）不要擔心它是一個實際的問題，除非你的程序運行速度太慢，然後配置文件找出哪裏2）如果好奇或分析表明一個問題，然後嘗試你可以想到的所有方法並衡量真實的表現。另外：+ =有時可以更高效，例如，爲了連接到一個現有的字符串，因爲+對這樣的對象可能涉及到創建臨時對象和更多的內存分配 - 模板表達式解決了這個問題，但由於它們實現起來非常複雜而且編譯速度較慢，所以很少使用。

來源

2010-10-26 05:54:49

+1不要擔心它，並配置您的程序 – rve 2010-10-26 06:53:01

回答

相關問題