要GPGPU還是要CPU?

http://www.realworldtech.com/forums/index.cfm?action=detail&id=103306&threadid=103203&roomid=2

ATI has been doing concurrent kernels (or whatever you wish to call them) since RV770 days. It’s a new feature for NV, but not for ATI.
David

不過到底是serial還是實際上可以usimultaneously還是有點差距….
G8x/G9x切換要很長時間基本上是不太能用,不過ATI好像能跑的東西都沒有所以也無法評價….(抖)

http://insidehpc.com/2009/10/06/interview-with-hpc-pioneer-justin-rattner/
Interview With An HPC Pioneer

And they have early performance results that will be presented at an IEEE conference later this year that show that the Larrabee outperforms both the Nehalem and NVIDIA’s GT280 on volumetric rendering problems.

volumetric rendering方面Larrabee跑贏Nehalem和GTX280。
老實講這還真的要看演算法….不過對programmer而言「GPU因為架構關係會挑演算法所以不好」這點倒是很重要的思考點。
到底怎樣叫做被架構限制、怎樣又叫做演算法有問題….

在〈要GPGPU還是要CPU?〉中有 4 則留言

  1. GPU的話可能偏向記憶體階層之類的問題吧….
    尤其是GPGPU和CUDA大多要知道「texture」這個東西。

  2. cpu也有記憶體階層, 指令排列會影響cache hit rate. 幸好compiler發展有成, 現在在cpu上開發程式也不用管這麼多硬體的細節了.
    同理, “因為架構關係會挑演算法”, 是在暗示沒有夠好的tool chain來排除硬體關聯性嗎, 所以總是得量身訂做.

  3. 有些比如說non-UMA,cache coherence等問題.
    幾乎不存在只靠純軟體/compiler的解法吧 ??
    一定要硬體有基本的功能輔助.

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料