C/C++編譯器反饋優化

具有用於使用反饋優化不同的節目沒有人見過任何真實世界的數字，C/C++編譯器提供支持分支預測，緩存預加載功能等C/C++編譯器反饋優化

我搜索了它甚至令人驚訝的是，甚至連流行的翻譯發展集團似乎都沒有檢查這種效果。增加10％左右的ruby，python，php等性能應該被認爲是有用的。

真的沒有任何好處，或者整個開發者社區只是爲了懶得使用它嗎？

2009-11-04 Lothar

我相信你正在尋找的詞是'簡介指導優化'。我不知道任何發佈前後測量的重大項目，但我知道Firefox在其構建系統中支持PGO。請參閱https://developer.mozilla.org/en/Building_with_Profile-Guided_Optimization – int3

非正式地，我已經在嵌入式代碼基礎上看到了+ 10％，但從未見過任何正式的PGO研究。 –

10％是一個很好的球場數字。這就是說，...

你必須真正關心走這條路線的表現。我工作的產品（DB2）使用PGO和其他侵入式和侵略性優化。其中包括大量的構建時間（在某些平臺上爲三倍）以及開發和支持噩夢。

當出現問題時，將優化代碼中的故障位置映射回源代碼可能並不重要。開發人員通常不會期望不同模塊中的函數最終可能會合並和內聯，並且可能會產生「有趣」的效果。

與指針別名問題，這是討厭跟蹤也通常顯示與這些優化。你有非確定性構建的附加樂趣（在週一的構建中會出現別名問題，直到星期四再次消失，...）。

在這些積極的優化下，正確或不正確的編譯器行爲之間的界限也變得相當模糊。即使讓我們的編譯器家族（字面上的）優化問題（無論是在我們的源代碼還是編譯器中）仍然不易理解和解決。

來源

2009-11-04 14:54:55

這個。 PGO是快速迭代的致命的敵人，你不能僅僅爲了測試而離開它，因爲每隔一段時間它就會引入一個bug。這並不是說沒有任何好處，但與大多數應用程序的開發和支持成本相比，性能增益是微不足道的。 –

好吧把大衛。如果你使用主要的版本邊界來使編譯器更新準備好讓這些優化在幾個月後不能工作（可能會在GA日期附近再次運行;）。並準備好行爲穩定的服務發佈版本，以突然開始行爲異常。並且，... 爲什麼這不常見可能歸結爲金錢。在產品中使用PGO會有很大的人員配置費用。 –

請注意，PGO通常不會引入錯誤，而是_exposes_，_finds_或_trips over_ bugs。 – MSalters

通過性能分析工具完成通過分析來提高編譯器效率的傳統方法。但是，工具中的數據如何用於優化仍然取決於您使用的編譯器。例如，GCC是一個正在爲不同領域生成編譯器的框架。在這樣的編譯器框架中提供分析機制將非常困難。

我們可以依靠統計數據做一定的優化。例如，如果循環計數小於常數（例如7），則GCC展開一個循環。它如何修復常量將基於針對不同目標體系結構生成的代碼大小的統計結果。

簡介指導性優化跟蹤源的特殊領域。有關之前運行結果的詳細信息需要存儲，這是一個開銷。另一方面，輸入需要統計表示可能使用編譯器的目標應用程序。所以複雜度隨着不同輸入和輸出的數量而增加。簡而言之，決定簡介指導優化需要極端的數據收集。自動化或將此類分析嵌入源代碼需要仔細監控。否則，整個結果將會出錯，而我們努力游泳，我們實際上會淹死。

但是，這方面的實驗正在進行中。只需看看POGO。

來源

2009-11-04 15:17:28

從unladen-swallow（一期工程優化CPython的VM）：與海灣合作委員會的定向反饋優化工具實驗時

對於我們來說，在PyBench的棺材上的最後一顆釘子是，我們能夠生產出通用15％我們的macrobenchmarks性能提升;使用相同的培訓工作量，PyBench慢了10％。

所以有些人至少看着它。也就是說，PGO對構建環境設置了一些非常棘手的要求，這些要求很難滿足由分佈式異構人員構建的開源項目。重度優化還會導致難以調試heisenbugs。給編譯器提供性能關鍵部分的顯式提示的工作量較小。

也就是說，我期望從運行時配置文件指導優化中顯着提高性能。 JIT'ing允許優化器處理程序執行過程中數據變化的輪廓，並執行許多極其運行時數據特定的優化，從而爲靜態編譯提高代碼大小。特別是動態語言需要良好的基於運行時數據的優化才能運行良好隨着動態語言性能在近期得到了廣泛的關注（JavaScript VM，MS DLR，JSR-292，PyPy等），這方面還有很多工作要做。

來源

2009-11-04 16:36:42

C/C++編譯器反饋優化

回答

相關問題