轉戰 Cell 的 PPU 組合語言或彙編語言(對岸的說法)中...

為什麼 Shady 會這麼突然要轉向組語呢？
理由很簡單...

因為編譯器的最佳化好麻煩，
有多麼麻煩呢？看以下分析就知道了。

雖然目前使用 C 語言就能碰到很底層的指令操作，
使用如 intrinsic 這類利用 C 行內組合語言做成的巨集或函式就能辦到，
但還是很難滿足最佳化的需求，因為還有很多指令是沒有 intrinsic 的...
就算自己製作，但 register 就很難用 C 控制。
最後交給編譯器的選項做最佳化，但魚與熊掌有時無法兼顧...
因此在需要了解很多編譯器選項和 C 程式中的編譯器指令下，
麻煩就出現了...

我只是弄個簡單的函式，
有需要搞得如此複雜嗎？

前篇 memcpy 的結果很清楚，
在 Shady 的編譯器選項中有最高的最佳化選項和避免某些微碼選項，
但效果之慘，後來 Shady 參考別人的程式，
有組語和 C 的程式，Shady 已將自己的 C 能做好的已做好了，
但 Shady 的 C 是用 VMX 撰寫的，卻還是輸給別人的 scalar 組語，
甚至使用別人比 Shady 還簡潔的 VMX 的 C 還是輸五倍。

以下是 memcpy 的最新測試結果，
4KB 為測試之容量且對齊記憶體 128 Bytes 位址(裡頭有更好的頻寬算法)：

再次告知 PS3 有一秒 79800000 ticks，
時脈為 3.192GHz，所以 1 tick 有 40 個 CPU 週期。

別人的 scalar 組語：4096Bytes / (62 ticks * 40) * 3.192GHz = 5.272GB/s
別人的 VMX 的 C：4096Bytes / (318 ticks * 40) * 3.192GHz = 1.028GB/s
Shady 的 VMX 的 C：只有 ~400MB/s ... ，說真的 Shady 的程式也很簡潔了。

所以總結就是 Shady 需要更簡潔的 C 撰寫和更多更適當的編譯器選項，
因此簡單的函式能用組語寫就用組語寫吧！