瀏覽單個文章
Artx1
Registered User
 

加入日期: Jun 2002
您的住址: 耗電量頗高的地方.
文章: 1,959
引用:
作者Arucueid
以我的看法, ECC 主要是給CUDA 運算用的, 我不認為圖形會非常需要ECC,
也許在 CAD 之類的繪圖上會需要, 但是一般消費階層來說, 算是雞肋
像素算錯, 頂多顏色不太對, 但是 CUDA/科學/非 graphic 運算上, 一個錯誤可能整個 work 報銷...

沒有tessellation unit, 用 SP 去算的話, 那應該是取決於 SP 的性能, 就我們所知這次丟進去的功能很多, 幾乎等於 CPU 裡的 FPU, 還能吃 C++這種遊戲常用的語言.

如果 SP 的執行效率夠高, 那應該能把影響降低, 但是不保證不會有影響, 畢竟要分出一些 SP 去計算.

又, 如果 SP 能直接吃原始的程式語言, 不經過 Driver/API, 理論上應該能提升一些效能
但是這又取決於 SP 對這種語言的處理效能, 一個弄不好反而會弄巧成拙


基本上ECC的確是給CUDA運算用,但是非ECC不可的只有長時間,大規模的運算。
所以就像Cray的CTO登台一樣,那是給大規模系統用的。
當然這回GTC去的一堆都是Grand Challange級的運算需求,神經元切片的Volumetric動不動就「整個internet的總資料量以上」(2mm^3的區域總共1.x PB)那還真的是ExaFLOPS等級的。

相依性本來就不容易處理,像網頁的CSS就實在非常靈活所以非得從頭到尾依序做,不然會被相依性搞死,這也是瀏覽器快不起來的原因之一,目前能做的大概只有JIT compile成machine code,也沒什麼方法再加速。
但是反過來說,現在網頁上吃重的大概普遍是flash內的HD影像,所以加速這個部份就比CSS要來得重要。
同理,超大規模的資料分析通常不會有很大的相依性,通常是dataset大到真的很難處理。
而且本來能平行化的東西就是一小部份,先做能做的事情總是很重要。

所以說,擔心的事情可能大半都是整個計算機界的聖杯,真的解決了會名流青史的w
但是商機卻又不見得和這種事情重疊,這點最有意思。

相對於過去CUDA來說,Fermi最重要的改善是cache子系統、引入64bit單一線性定址(不標注的話不使用share memory、並且因此可以使用C++)、高速的context switching與多kernel同時處理、最後是IEEE754-2008和全面ECC(不只記憶體還有內部register file、cache、shared memory等整個資料流)保護,讓它真的有從高階到低階可以打遍天下(沒說無敵手喔)的HPC能力。

最後,第四季的Tesla大概有一千萬美金的進帳,開始賺錢了呢。
     
      
舊 2009-10-02, 04:36 PM #11
回應時引用此文章
Artx1離線中