很多人都不知道看似輕描淡寫的這2行敘述，對cell的影響有多重大!
其實要發揮cell的實力，如何在cell架構上 programming 是最難的問題!
別以為寫cell的program只是把code寫好然後給compiler吃，compiler就會自動生出完美的parallelized executable，
哪個部分PPE該做 哪個部分給SPE平行做都自動切的整整齊齊，各個SPE隨時工作滿檔，
都處於peak performance的狀態，218GFLOPS輕鬆達成
哪有這麼好康的事?

相反的，PPE跑的code跟SPE跑的code是分開來寫的、分開compile的，
要叫SPE做事的話PPE就要自己開1個SPE thread叫某個SPE做事，SPE不會沒事自己找work來做，
所以SPE再多你的program無法平行化給SPE做也是沒用。

此外，cell的PPE和SPE的addressing space不一樣，PPE有64bit的定址能力，
而SPE只看的到自己256KB的local storage(LS)，所以要將之前在shared memory架構
寫的code 要port到SPE執行的話將會發生以下問題:
1. 之前在shared memory架構爽爽用的global variable對SPE來說通通看不到，
要存取的話請用DMA，但是DMA的限制一堆，例如source和destination address
都要能被16整除、DMA size必須為1,2,4,8或16倍數 byte...

2. 最頭痛的pointer問題，因為pointer所指向的data幾乎都不在LS裡，要的話請DMA，
如果pointer有2顆 '*' 以上的在pointer dereference時準備被搞死吧!

3. SPE的LS只有小小的256KB，所以搞出了SPE compiler可以吃C++ code，但是居然
不能用C++標準的IO library : iostream這種鳥事 ，因為iostream的linkable大小就超
過256KB，更慘的是SPE code編譯完的exeutable隨便都有幾十KB，所以SPE在執行
時只剩大概200KB可用，之前在shared memory架構幾乎不在意 available memory
space，new, malloc 要多少space就有多少，但在SPE code裡LS剩多少卻變得
非常斤斤計較。

4. workload怎麼分給SPEs執行?要完全parallel還是搞SPE pipelining?

5. 要cell當GPU可以，請IBM拿出3D graphics API(例如像openGL) for cell，不然
遊戲廠商開發遊戲都來不及了哪有閒工夫替cell寫3D graphics API，有現成 for GPU
的API誰不想直接用?

如果cell不需要programmer精心設計sequential code如何parallelize給SPE執行，
就可以隨時達到IBM號稱的peak performance的話，那這樣一顆cell賣不到1萬塊，IBM還真是佛心來的!