PGO比靜態優化要慢（intel編譯器）

我正在使用用於I-32A體系結構的英特爾C編譯器。當我編譯我的C程序使用下列選項：PGO比靜態優化要慢（intel編譯器）

icl mytest.c /openmp /QxHost /fp:fast /fast

試運行需要3.3s。現在，我嘗試使用PGO，所以我編譯：

icl mytest.c /openmp /QxHost /fp:fast /fast /Qprof-gen

然後我和我的樣本輸入運行可執行文件的2-3倍，並重新編譯：

icl mytest.c /openmp /QxHost /fp:fast /fast /Qprof-use

希望它能兼顧收集信息。它實際上告訴我它使用.dyn文件，但是結果可執行文件比沒有Qprof使用的文件更慢（3.85s），這與運行的數據完全相同（對於PGO應該是完美的）。我試着將openmp線程設置爲1，認爲它可能與.dyn輸出混淆，但結果是相同的 - 它比簡單編譯慢。

我的問題是：它甚至在理論上是可能的，或者我用編譯器選項以某種方式搞亂了PGO過程？

來源

2012-07-21 Piotr Lopusiewicz

'/ Qpprof-use'？第二個p應該在那裏嗎？ – CAFxX 2012-07-21 20:30:56

只是一個錯字;打字速度比從控制檯複製粘貼要快:) – 2012-07-21 21:21:34

一個3.3秒的浮點應用程序不會從配置文件引導優化中受益。根據我的猜測，您正在進行某種原始數據處理，如果您需要原始FLOP而不是PGO，則更適合手工編寫程序集。

PGO不會告訴編譯器如何優化內部循環以消除分支延遲並保持管道充滿。它可能告訴它，如果你的循環可能只運行5000次或如果你的浮游物滿足一些標準。

它與統計上代表您希望運行的其他數據的數據一起使用。換句話說，您可以將它與數據一起用於您希望能夠以良好的剪輯運行其他數據的程序。它並不一定爲手頭的程序進行優化，正如你所說的，甚至可能會減慢它的可能淨收益。

這實際上取決於您的程序，但OpenMP FP應用程序不是PGO的用途。像所有其他東西一樣，它不是「魔力子彈」。

來源

2012-07-21 16:04:28

謝謝，這很有幫助。我仍然感到驚訝，它會給配置文件運行時的EXACT SAME數據帶來更糟糕的結果。有沒有一些解釋呢？ – 2012-07-21 16:34:51

@PiotrLopusiewicz是的。就像我說的那樣，它可能會確定你的循環通常會在5000次迭代後終止。如果這樣做，它會添加代碼來檢查大約5,000次迭代的終止條件。它基本上會增加啓發式方法，以加速平均預測的情況，而不一定是您確實正在運行的情況，例如qsort性能如何攤銷。順便說一句，循環的東西只是一個簡單的例子。 – 2012-07-21 16:43:02

PGO比靜態優化要慢（intel編譯器）

回答

相關問題