2012-03-15 28 views
-1

我不知道如何輸入到谷歌,所以我在這裏問這個。不同的操作員有不同數量的CPU使用情況嗎?

在編程中,操作員是否會花費不同的時間或CPU使用量?例如將:

x = y + z 

採取的時間較少量/ CPU比:

x = y * z 

我知道它是不明顯的,如果有的話。只是一個奇怪的問題。此外,如果您可以包含儘可能多的運算符(例如+ =, - =,* =和/ =以及所有常規運算符)

謝謝!

+0

運算符的性能可能會有很大的不同,取決於數據類型等。也許你可以去google搜索二進制算術,浮點運算等。 – joshuahealy 2012-03-15 03:44:15

回答

3

對於所有語言,數據類型,CPU等,沒有主列表,因爲變量太多了。

在某些語言中,運算符只是完全動態確定的類型分派的函數調用的語法糖,因此「a + b」可能是需要花費數分鐘的複雜函數調用,而「a * b」可能是一個需要幾毫秒的簡單函數調用,反之亦然。

在編譯時間固定的類型(包括C++和C,儘管C++已經重載)的語言中,您可以在編譯時確定將調用哪些內容,這有助於縮減很多內容,但仍然沒有給你最終的答案。 (另請參閱Dan D和Alex的答案。)

「擴展運算符」(+ =等)通常只是擴展後分配操作的簡寫。實際操作需要相同的時間。在動態類型調度的語言中,有時你也會切斷一些輔助(非操作符)的工作,因爲增強操作只需查找一次變量的類型。使用靜態(編譯時)鍵入,只要編譯器具有相當的智能性,簡單的a += b類型操作在運行時絕不會在a = a + b之上保存任何內容,它們只是更易於閱讀。更復雜的情況下,如p->q->r->s += t,實際上可以節省時間,因爲(在棘手的情況下)如果重複寫出p->q->r->s評估必須重複進行。

至於底層的CPU運算,也有一些經驗法則,但你必須拖拉出相應的CPU手冊,看看哪些適用於:

  • 對於整數,加法,減法和邏輯運算like和/或/ xor永遠不會比任何其他操作慢
  • 對於整數,乘法比加法更「困難」,即可能比加法等慢,但只要有足夠的CPU,速度可能會非常快 - 專注於它的力量;和劃分可能比乘法慢,或者可能仍然很快
  • 對於浮點運算,加法和減法比乘法和除法「更難」,所以它們可能會更慢(或不會,這又取決於晶體管的實際數量如果沒有FPU,浮點數可能會慢於整數
  • 如果有桶式或漏斗式移位器,移位總是很快,但如果不是,移位可能需要更長的時間(例如,x >> 4可能比x >> 1慢)
  • 在現代的CPU中,上述的指令調度@Alex可能取決於指令的順序,也可能不取決於指令的順序,例如, ,它可能會有所幫助以在整數單元指令之間散佈FPU指令(或者它可能不會)
  • 緩存效應(包括在高速緩存行中的特定點附近放置分支以及多級緩存未命中以及TLB未命中)可以完全淹沒效果在某些CPU上進行仔細的指令調度

這些類型的東西使編寫現代編譯器優化器變得非常棘手。 :-)

1

是的,在最低水平上,有時a * b的成本超過a + b,有時它是另一種方式。這實際上取決於使用的硬件和使用的語言。

親眼看看,運行幾次測試,重複操作數千次。

+0

謝謝,但是有什麼地方可以找我找到運營商列表和時間使用? 如果沒有,那麼我會做你說的並且運行多個測試XD。 – 2012-03-15 04:14:09

1

您需要檢查CPU手冊,看看有哪些邏輯和算術指令以及它們需要執行多少個週期。

如果沒有整數除法或乘法的指令,那麼您的編程語言將不得不使用更原始的操作(例如移位和加/減)來構造這些操作。對於長整數的簡單操作也是如此,例如加法,減法,比較,移位和或xor,逐位反轉。如果沒有使用長整數的指令,則必須使用較短的指令來構造,這意味着操作員的性能將取決於涉及的類型的大小。

有些CPU沒有浮點運算的指令,這意味着所有的浮點運算都需要使用整數運算的指令來構造,因此它們將比整數上的類似運算要慢。

要考慮的另一件事是,有問題的指令是否可以與CPU中的其他指令配對(如果配對(並行執行)是可能的話)。如果他們不能配對,他們會放慢附近的配對指示。一些CPU具有多個ALU,用於可以同時執行的簡單指令。除了簡單的配對之外,一些複雜的指令可能會使用CPU管線的更多階段,或者與簡單指令不同地使用它們,這會延遲執行其他簡單指令。

最終答案取決於您的CPU和編程語言/編譯器/解釋器。