（這篇目的是拋磚引玉，吸引各位神人補完下去，並且希望提高這討論區的氣氛）
（這文章未經嚴謹論證，本人不為其中任何錯誤負責）
APU已經出了一段時間了，讓我們從工程角度看一下APU吧。
1. 統一了CPU和GPU的記憶體控制器
這一點，記憶中是AMD先發表的，不過首先實作起來的卻是Intel的Sandy Bridge（笑）。
想當年（事後孔明模式發動中），我和朋友們都認為這是開玩笑的，可是這最終成為了事實（再笑）。
2. 要統一記憶體控制器為什麼那麼難？
首先，現代CPU很多時間是浪費在等待上的。等待什麼？等待資料從主記憶體拿出來再放到CPU那裡。真正關係到CPU效能的，是CPU說了它想拿資料後，要久時間才能真正拿到資料（Latency）。
為了讓CPU不那麼容易白白等待，CPU才會有什麼L1L2L3，把資料放多一份在CPU內部而不用再問主記憶體拿。
而BandWidth（有多少資料能）對CPU來說，絕大部份時候都沒什麼意思的。（所以為何雙通道記憶體比單通道記憶體只影響到少於5%效能）
而GPU呢？GPU是常常要做超大量相同的小些工作（我們行內人叫massive threading，其中一個例子便是遊戲中各位常常聽到的shader啦）。
對GPU來說，每件工作做慢一點是沒所謂的，反正每個工作都很小型，在１／６０秒內應該有絕對足夠的時間來完成的。
所以，現代GPU做事是「三心兩意」的。工作１進行了一點點，然後便去進行工作２進行了一點點，然後便工作３，工作４，工作Ｎ（沒記錯，amd下一代的GCN，即是7970，是有１０組工作的）。所以，記憶體慢（Latency高）一點是沒什麼所謂，像是工作１要找記憶體拿資料，只要資料在GPU執行工作２－工作Ｎ其間能送到GPU，GPU是沒有任何等待的。（這是理想啦，別炮我這一點）
而因為GPU是有超大量工作要做，所以需要的資料量（BandWidth）也是超高的。（所以有時明明用同一個GPU的，64bit，128bit，256bit，GDDR3和GDDR5會效能差那麼大）
用最白一點來說：CPU是想要空運，求快不求多；GPU是想要海運，求多不求快。２者不同的設計要求，讓統一記憶體控制器一直很難。
3. APU統一了CPU和GPU的記憶體控制器，那結果呢？
結果便是GPU方面的需求滿足不了。
APU的記憶體控制器其實還是以Latency（CPU看重的東西）優先的。因為不那麼做的後果便是CPU會慢得不能接受。（這點等硬體高人補充）
所以，不管APU還是Sandy Bridge的GPU都是面對bandwidth不足的問題。（而AMD的記憶體控制器沒intel那麼好，所以問題更加突顯出來。也是為何用高時頻和雙通道記憶體便能立即給GPU大幅提升效能的原因）
不是AMD和intel不想把更好的GPU加進去，而是即使用了更好的GPU，也會因為bandwidth不足而表現不出應有效能變得單純浪費電晶體和電而已。
4. APU只是把GPU從北橋晶片搬到CPU內部而已？
如果這是在問Sandy Bridge，答案是的。（當然Sandy Bridge的GPU放到CPU是有好處的，但是不在這文章討論）
可是對APU來說：統一記憶體控制器並不是為了偷工減料，而是為了GPGPU（把程式放到GPU上運行），一種用來把程式放到GPU上運行的東西（heterogeneous computing）。
傳統上，把東西給GPU運算，需要程式員把資料由主記憶體抄到顯示卡上的專屬記憶體，然後計算好了再把資料由顯示卡上的專屬記憶體抄回主記憶體。（我說也覺得麻煩，各位可以明白這是多煩人多消耗效能的一件事）
因為抄來抄去會大幅影響到效能，傳統的GPGPU必需把工作盡量全部在GPU上做完，然後再一次把資料拿回來的。
結果，如果２件工作之間有少量用CPU來做比較好的東西，也因為要迴避抄來抄去而都由必須GPU來做。這結果很多程式最後都只能放棄，乾脆只由CPU來做算了。
而APU統一了記憶體控制器，那便表示資料能不用抄來抄去，應該用GPU做的東西才由GPU做，否則便用CPU來處理。
而AMD最近在大幅推廣OpenCL（Open Computing Language），用來做GPGPU的東西。目的是希望未來程式能做到以前只有超級電腦才能做的東西。
像是：真實的液體模擬（像是真正的滑浪，而不是像現在遊戲用簡單數學來偽裝的）。超大量的粒子碰撞啦。（AMD的官方示範是APU配上openCL能處理３００００個粒子，而現在單純用ＣＰＵ應該少於２０００個）
（註１：現在遊戲中，有些遊戲有像黏液怪物的東西，這其實內部是用了十多個球體，再配上很多彈簧，再加上畫面加工做到的。）
（註２：intel也有openCL的實作，但是如果我沒記錯，他的openCL是最終把運算放到CPU做的）
5. APU和openCL會是未來？
以下是辦公室中的對話：
老闆：我們來研究一下未來專案用openCL如何？
軟體架構師：（指向超級混亂的桌面）這個白色信封，不知內部裝了一封辭職信會是如何？
老闆：哈哈哈。。。。。。
軟體架構師：哈哈哈。。。。。。
老闆：當我沒說。
軟體架構師：（繼續寫會在X86和ARM架構上運行的C++和java中）
來做一個簡單說明吧，對一個資深軟體工程師來說：
善用C++特性，善用STL的強大能力，寫一個不錯效能的單一CPU程式假設是1單位時間
用多CPU的程式大約1.5-2單位時間
用多CPU，並且針對CPU存取資料的特性做最大優化，大約3-5單位時間
用上openCL的一般優化的程式，大約>20單位時間
用上openCL，並且對nVidia和AMD都作優化的程式，大得我不敢想像（笑）
6. 除了openCL很難使用之外：
除了遊戲軟體，一般商用軟體現在其實不太吃重CPU的，因為現在CPU其實很快。（小聲：某演講會，AMD工程師最讓我可信的一句：「其實intel CPU是很快的。」）
而遊戲軟體，除了大型遊戲軟體，有以千萬計開發費用的，否則也開始回歸原點，用創意，輕鬆去玩，也不吃openCL的。
最有可能吃openCL，便是遊戲大作（對不起，我買了battlefield3到現在還沒玩過）。
nVidia當年曾經推廣過PhyX，用CPU作粒子加速，最終失敗的原因不在於難用。而且如果遊戲必須配上nVidia顯卡才能用，那便表示要放棄超過一半的使用者！
所以最終遊戲開發商最終只能用PhyX做遊戲中一些無關痛癢，沒有了也沒太大關係的東西（像是爆炸時用PhyX便能有多些爆炸碎片）。
今天openCL是否成功，其實正是像當年PhyX很看nVidia最終是否支持。而nVidia，他其實早便有了CUDA這個專屬的GPCPU東西，他是否想支持openCL嘛，別問我，我也想知道。
（其實我今天是感冒發燒中，不能好好工作才寫一點東西的。文筆有點亂，希望各位看得懂）
。
。
。
。
