IBM CellBE Workshop内容和重點

有幸參加了IBM的這個training，不過由于IBM自己管理的失誤，很多人沒能知道教育訓練地點，在此特别鄙視一把。為期2天的training我參加了1天半，由2個IBM北京的講師輪番上陣，嗯，分别是龔大和潘大。廢話少說，切入正題。

首先是Cell的架構，應該已經很熟悉了，即使你不鳥IBM，PS3的硬體spec上也寫着：PPE+8SPE，9個核，10個硬體thread。PPE是legacy Power5的架構，把它當Power5使沒問題，完全相容，有L1，L2兩個cache。8個SPE，包含SPU向量處理器，為了向量處理和SIMD設計的，128個128bit通用寄存器（真多），dual issue channel，非常快，沒有硬體cache設計。SPE還包含LS(256K)，用于SPU的本地存儲器，latency也非常小、MFC用于DMA控制。EIB作為PPE和SPE之間的高速總線。

然後是開發環境。Cell SDK目前是2.1版本，跑在linux上。龔大說9月份會release 3.0，裡面xlc的一些超強優化特性以及FDPR-Pro的SPE版本都會出現。好，不管以後的版本多麼fancy，先來看手頭有的東西： toolchain和compiler，當然是C/C++的，分别對應PPU的和SPU的有2份，是以會編譯出兩種executable格式。編譯器可以用gcc或者IBM自己的xlc，據說xlc稍後的版本會有auto vectorization之類的功能粉墨登場，敬請期待。其他的工具鍊的東西可以參考普通x86上linux的那一套，基本用法當然是一模一樣的。除此之外，IBM的工程師們還提供了很多profiling工具，比如靜态的SPU timing工具，可以生成彙編代碼和時序圖、還有FDPR-Pro，對二進制代碼進行無人工參與的優化，不過目前隻對應PPU。為了友善大家發揮Cell的實力，IBM中國的lab也搞了一個叫ALF（Accelerated Library Framework）的東西，據說可以大大簡化程式員拆分workload的工作，可以以腳本（還是GUI？忘記了）的方式定義workload，然後可以讓程式自動優化處理時機，這個東西在教育訓練中沒有講到，看來要好好關注一把。 最後麼，還有些Eclipse插件，以及Cell的官方模拟器，這玩意兒将在運作時profiling中起到非常重大的作用，可以在裡面看到每個cycle、SPU執行狀态以及CPI（Cycle Per Instruction，據說普通程式可以優化到1.0左右，變态計算可以到0.6-0.7）和miss branching、dural issue rate等重要profiling資料，但缺點就是太慢，我在IBM的教室裡，P4的老機器，跑win2k，再跑vmware上的fc6，再在fc6裡跑simulator，又起來一個linux，即使是fast mode，模拟器工作的都很慢，如果是cycle mode，據說5秒鐘的程式可以跑上4個小時。

以上就是IBM目前能提供給Cell開發者的一些東西，當然也可以去alphaworks多逛逛，看看有什麼新貨。

接下來說說如何使Cell變得更強。基本上，PPE會作為一個程式協調者的身份，用來排程所有SPE的工作、準備SPE的資料等等。而大量的資料密集的計算将落在這8個SPU的身上。SPU不要看它小，小也是小強，前面說了，是個高速向量機，所有的指令都是向量指令，即使是标量的計算也要轉換到向量指令做。想起什麼來了？GPU是吧。我個人感覺Cell的位置是在傳統CPU和GPU之間，對pipelining的要求沒那麼變态，也不會有什麼shader标準來讓你束手束腳的做GP，但是又擁有general processor不具備的變态的向量處理能力，比較靈活，但效率可能沒有GPU這麼高，畢竟人家太專業了（PS3上folding at home還是比不過GPU的版本，但是比PC CPU版本要強多了）。哦，說遠了。話說要讓SPU發揮能力，主要看2方面。一是PPE能不能對SPE進行有效通信，二是SPE如何利用向量指令并優化自己的算法。那麼基本上這倆都是巨大的命題。以下簡要談談：

PPE和SPE之間通信主要3種方式：mailbox，signal，DMA。感覺mailbox和singal有點類似，都像是信号量一類的同步對象，不過是硬體級的。那麼既然分這2個東西，那麼一定是有不同的用途，這點需要稍後再作了解。DMA就很直覺了，有了mailbox和signal做同步，那麼DMA就可以放心的進行資料傳輸了，由于SPU隻能對LS進行操作，是以會有大量的代碼涉及到同步和DMA。

至于代碼向量化，IBM的best practice是，如果對Cell和待實作的算法不熟悉的話，建議先在PPE上做scalar的版本，然後可以一步步移植到SPE上，比如先做記憶體對齊，再将scalar操作變為向量操作，最後審查算法的資料無關性，是否可以并行操作，以及可否分開到其他SPE上去完成。當然如果是Cell大師的話，直接寫就可以了，不過貌似大師還沒有生出來。Rapidmind也提供了很high level的解決方案，号稱不用考慮硬體架構來寫多核程式，不過貌似IBM的人不鳥之，還是覺得自家的ALF爽。不過IBM也承認這是個很大的問題，也不是一朝一夕可以解決的（Free lunch is over）。

那麼以上基本就是第一天的内容，第二天就去了個上午，不過software programming model确實值得一聽。這裡就列舉了幾個有用的、常用的程式設計模型。比如streaming，幾個SPU并行處理無關的資料，這在單個SPU處理能力足夠的情況下較多采用、pipelining，幾個SPU串行處理相關資料，但是難以作load balancing，在資料相關性大，以及單個SPU處理能力不足的情況下可以考慮。還有executable或者data超出LS的256K限制範圍後，是用手動DMA，還是overlay程式段，或者采用software cache library來透明化LS和MM之間的隔閡。手動控制的DMA較适合data coherency較強的情況，若程式員知道一塊大的block資料，那麼最好使用這種方法。而software cache适合程式員需要random access大量MM資料的時候，而他對于資料coherency一無所知時，software cache可以提供較好的cache支援，因為SPE是沒有硬體cache設計的。而一旦你的code size超出了LS的範圍，就必須使用overlay來解決難題了，通過linker script來定義overlay的區域，但無須該動源碼，而且不用擔心會意外覆寫了程式空間。還有一些其他的model，比如kernel管理的SPU線程，離地球太遠了（但好像VxWorks在做），不過自己管理SPU做cooperative multitask還是有實際應用價值的。

其他的還講了SPU static timing的用法，生成的檔案可以清楚的知道靜态時序。以及通過模拟器動态運作，獲得實際運作資料，除了太慢，都很好用。

最後回公司了，錯過了他們一個mpeg2->H.264的實時轉碼的流媒體系統優化執行個體，可惜啊。買個PS3爽之。

幾天後發現Wenle和潘大是同學……汗一個。

轉載于:https://www.cnblogs.com/eygneph/archive/2007/07/20/825611.html