我正在爲Windows移動設備上的代碼性能做一些基準測試，並注意到一些算法在某些主機上的性能明顯更好，其他。當然，考慮到時鐘速度的差異。針對ARM進行優化：爲什麼不同的CPU對不同算法的影響有所不同（並且有很大的不同）
供參考的統計數據（所有結果從相同的二進制生成的，由Visual Studio 2005定位的ARMv4編譯）：
英特爾XScale PXA270
ARM1136EJ-S芯（嵌入在MSM7201A芯片）
ARM926EJ-S芯（嵌在OMAP 850芯片）
我簽出了浮點數作爲可能的c ause，雖然算法B確實使用浮點代碼，但它並沒有在內部循環中使用它，並且沒有一個核心似乎具有FPU。
所以我的問題是，什麼機制可能會導致這種差異，最好與如何修復/避免有問題的瓶頸建議。
在此先感謝。
一個可能的原因是，926具有更短的管道（5個循環與8個週期爲1136，這個），所以轉移誤預測是在926
也就是說成本更低，也有很多這些處理器之間的體系結構差異，太多無法肯定地說明，爲什麼您在不瞭解您實際執行的指令的情況下看到了這種效果。
我運行了一個預測基準（測試第16位i ++ vs第16位LSFR），它確實表明1136顯示了與926相比的顯着損失，該926映射到實現（大量嵌套ifs每個項目與有限狀態機在大多數時間處於相同狀態） – Combuster 2009-10-07 08:52:19
時鐘速度只是一個因素。如果不是更大的因素，總線寬度和延遲也很大。緩存是一個因素。如果從媒體運行而不是從內存運行，則程序運行的媒體速度。
此測試是否在測試的任何時候使用任何共享庫或是否全部是內部代碼？在不同平臺之間的媒體上獲取共享庫（即使它是相同的SD卡）。
這是相同的算法爲每個平臺或相同的二進制分別編譯？你也可以看到一些編譯器引起的變化。通過改變編譯器設置，可以在同一平臺上輕鬆地從同一個編譯器獲得快50％的速度。如果可能，您希望執行相同的二進制文件，並確保在測試循環中不使用共享庫。如果不是相同的二進制反彙編測試每個平臺的循環，並確保除寄存器選擇以外沒有任何變化。
+1對於CACHE設置。 – Alphaneo 2009-10-07 04:59:01
從你提供的數據，其難度一點確切的問題，但我們可以分享一些以前的經驗
有關人士分析，
乙進一步深入你的代碼，不僅僅是算法，而且是在塊級別，並試圖理解導致瓶頸的塊。找到導致瓶頸的塊後，嘗試拆開塊的源代碼，然後檢查組件。它可能有幫助。
看起來像問題是在緩存設置或內存相關的東西（也許我的緩存「溢出」）。 管道延遲，分支預測誤差通常不會有顯着差異。
你可以試着算一些基本操作，在每個算法執行，例如：
而且你會得到的信息，事情得到926慢得多。在此之後，你可以檢查可疑塊，使他們使用或多或少密集。你會得到答案。
此外，在VS中啓用匯編列表生成並使用它（但不是您的高級源代碼）作爲研究的基礎會好得多。
p.s .:可能問題出在操作系統/軟件/固件？你在乾淨的系統上測試過嗎？所有設備的操作系統都一樣？
聽起來像第三個處理器對我來說太慢了...... – RCIX 2009-10-06 10:09:27
我只是在猜測，但性能不佳可能是由chache碰撞引起的，具體取決於內存佈局。 – starblue 2009-10-06 10:27:58
只是速度較慢的處理器無法解釋爲什麼算法速度提高50％現在速度降低50％... 通過將內部陣列的尺寸從2048更改爲2048 + 12，我確實獲得了最差情況8秒的時間，以避免緩存關聯性問題（感謝提示，starblue），但它並不包含所有內容，因爲比率現在是62sec vs 31sec。 – Combuster 2009-10-06 11:58:16