http://pc.watch.impress.co.jp/docs/2009/0205/kaigai487.htm
並列コンピューティングの大物を研究部門のトップにスカウトしたNVIDIA
這邊提到的將computing效率提升的三個方法：核心規模削減、減少控制(SIMD化)、減少資料搬移需求(利用資料區域性)。
GPU目前的問題正是因為由於像素間幾乎沒有相關性，”不需要處理資料區域性”所以對利用資料區域性非常地弱，NV50目前最大的課題也在此。所以找來Daily看來能對這點對症下藥….
不過這也代表，NVIDIA很可能將繼續加大投注於通用處理上的心力了。
哈哈
看樣子我之前的猜想似乎是對的
最終A/N這二家的產品將會近似Larrabee
我正在想”近似”Larrabee的意義是啥….
是近似x86 core？還是使用ring bus？
如果只是cache based的話好像有點說不通。
我正在想”近似”Larrabee的意義是啥….
是近似x86 core？還是使用ring bus？
如果只是cache based的話好像有點說不通。
現在GPGPU的問題恐怕是仍然沒有一個成熟而公開的標準.
使得大部份開發者都在期待+觀望…..
而且Intel在Larrabee上是要自己推一個
新的native X86 based GPGPU環境,
恐怕又攪亂一池春水
(萬一給它成功的話,N/A兩社可以收攤了)
看不出來未來GPU會近似Larrabee….
GPU是大量ALU core+大量輕量thrad,很少很小cache.
Larrabee是多核mini cpu,少量thrad,共用大cache.
現在GPGPU的問題恐怕是仍然沒有一個成熟而公開的標準.
使得大部份開發者都在期待+觀望…..
而且Intel在Larrabee上是要自己推一個
新的native X86 based GPGPU環境,
恐怕又攪亂一池春水
(萬一給它成功的話,N/A兩社可以收攤了)
看不出來未來GPU會近似Larrabee….
GPU是大量ALU core+大量輕量thrad,很少很小cache.
Larrabee是多核mini cpu,少量thrad,共用大cache.
> GPU是大量ALU core+大量輕量thrad,很少很小cache.
> Larrabee是多核mini cpu,少量thrad,共用大cache.
現在來說如果能解決data reuse和locality的問題，那GPGPU的發展應該就會快很多，問題是非用cache coherence不能解決嗎? 走message passing呢？
以前的Supercomputing這方面發展得很蓬勃的關係，所以其實不缺參考對象。
> GPU是大量ALU core+大量輕量thrad,很少很小cache.
> Larrabee是多核mini cpu,少量thrad,共用大cache.
現在來說如果能解決data reuse和locality的問題，那GPGPU的發展應該就會快很多，問題是非用cache coherence不能解決嗎? 走message passing呢？
以前的Supercomputing這方面發展得很蓬勃的關係，所以其實不缺參考對象。
那個減少資料搬移
講的不只是利用資料區域性.
還有字面上意思….讓資料一直在手邊不要搬動.
…..就是避免一直在不同core之間搬動同一筆資料.
這包涵了各核心各自有自己獨享的分散式register file
或獨佔的local memory等等不跟人家share的暫存區.
不為了維護各核心資料存取的一致性而犧牲效能.
雖然這樣會造成同一筆資料每個core附近各自有一份.
很浪費空間, 但是卻是暴力解決傳輸問題的好方法.
分散運算超級電腦也都是這樣搞, 不然上千上萬個core
光等待傳輸資料就慢斃了….解決方法就各做各的.
少做不必要的溝通,
某方面來說GPU其實已經是微型化的分散運算超級電腦.
那個減少資料搬移
講的不只是利用資料區域性.
還有字面上意思….讓資料一直在手邊不要搬動.
…..就是避免一直在不同core之間搬動同一筆資料.
這包涵了各核心各自有自己獨享的分散式register file
或獨佔的local memory等等不跟人家share的暫存區.
不為了維護各核心資料存取的一致性而犧牲效能.
雖然這樣會造成同一筆資料每個core附近各自有一份.
很浪費空間, 但是卻是暴力解決傳輸問題的好方法.
分散運算超級電腦也都是這樣搞, 不然上千上萬個core
光等待傳輸資料就慢斃了….解決方法就各做各的.
少做不必要的溝通,
某方面來說GPU其實已經是微型化的分散運算超級電腦.