常見算法的GPU與CPU性能

Question

我很想知道是否有任何常見算法（排序，搜索，圖形等）已經移植到OpenCL（或任何GPU語言），以及性能如何與相同算法由CPU執行。我特別感興趣的結果（數字）。

謝謝！

Answer 1

在NVidia的網站上有這種東西的quite a few samples。請記住，排序等一些事情需要特殊的算法才能實現高效的並行性，而且在單個內核上的效率可能不如非線程算法。

Answer 2

GPU是高度專業化的硬件，旨在完成很好的並且高度並行的一小組任務。這基本上是算術（特別是單精度浮點數學，雖然新的GPU在雙精度上表現相當好）。因此，它們只適用於特定的算法。我不確定排序是否適合該類別（至少在一般情況下）。

更常見的例子是定價的金融工具，大量的矩陣數學，甚至defeating encryption（通過蠻力）。這就是說，我找到了Fast parallel GPU-sorting using a hybrid algorithm。

另一個通常引用的示例是running SETI@HOME on an Nvidia GPU，但它將蘋果與桔子進行比較。與CPU通常做的相比，GPU的工作單位是不同的（並且受到高度限制）。

Answer 3

在thrust看一看：

推力是平行 算法CUDA庫與接口 類似於C++標準模板庫 （STL）。 Thrust爲GPU 編程提供了靈活的高級接口，極大地提高了開發人員的生產力。

Answer 4

對於GPGPU引用的任何性能數字，請謹慎對待。許多人喜歡發佈真正令人印象深刻的數字，這些數據沒有考慮從CPU獲取輸入數據到GPU以及輸出數據所需的傳輸時間，這兩者都超過了PCIe瓶頸。

Answer 5

在許多接受圖片上傳的網站上，圖片大小調整必須是常見的。

調整2600ish x 2000ish 2MB jpeg圖像（512x512）的大小在C＃中花費23.5毫秒，絕對質量最低的選項和最近鄰採樣。使用的功能是graphics.DrawImage()的基礎之一。 CPU使用率也是％21.5。

在C＃端獲取「rgba byte array」並將其發送到GPU並在GPU中調整大小並將結果重新映射到映像中需要6.3毫秒，CPU使用率爲％12.7。這是用僅有320個內核的％55便宜的gpu完成的。

只有3.73X加速乘數。

這裏的限制因素是，將提取的20MB rgb數據（jpeg僅爲2MB！）發送給GPU。這個耗時的部分幾乎佔總時間的90％，包括C＃邊字節數組提取！所以我認爲，如果提取部分可以在GPU中完成，至少會有30倍的加速。

30X並不差。

然後，您可以通過調整大小層管道提取圖層來隱藏內存拷貝延遲以獲得更快的速度！這可能是40X-50X。

然後提高採樣質量（如雙三次而不是最近鄰），在GPU方面你有更多的優勢。添加5x5高斯濾波器僅添加了0.77毫秒。除此之外，CPU會獲得更高的時間，尤其是如果所需的高斯參數與C＃.Net實現不同的話。

---

即使你不滿意加速比，卸載到GPU，並具有CPU上的「自由核心」仍然是推動更多的工作，該服務器是有利的。

現在添加GPU功耗級別（在本例中爲30W vs 125W）的事實，它更有優勢。

---

CPU可以在

C[i]=A[i]+B[i] 

基準很難贏的時候雙方就優化代碼運行，你仍然可以卸載陣列的一半GPU和使用CPU + GPU在同一時間完成更快。

---

GPU不是爲非統一作品而構建的。圖形處理器由於分支而具有深度流水線，因此在站點後站立時間太長。另外SIMD類型的硬件也迫使它在所有工作項目上做同樣的事情。當一個工作項目與組完成不同的事情時，它會丟失跟蹤並在整個SIMD管道中增加泡泡，或者只是其他人等待同步點。因此，分支會影響深層和廣泛的管道區域，並使其在完全混沌條件下比CPU更慢。