Tag: cost

Cloudflare 花了不少力氣在 ARM 的伺服器上 (可以參考「Cloudflare 用 ARM 當伺服器的進展...」，或是更早的「Cloudflare 測試 ARM 新的伺服器」這篇)，最近在 ARM 上發現 jpegtran 的效能不是太好，花了不少力氣最佳化，發現有意外收穫：「NEON is the new black: fast JPEG optimization on ARM server」。

他們設的低標是讓每個 core 的效能大約在 Xeon 的 50%，但發現只有 26% 左右的效能：

Ideally we want to have the ARM performing at or above 50% of the Xeon performance per core. This would make sure we have no performance regressions, and net performance gain, since the ARM CPUs have double the core count as our current 2 socket setup.

In this case, however, I was disappointed to discover an almost 4X slowdown.

而他就想到這些圖形運算的程式應該早就在使用各種 SIMD 指令集加速，於是作者就想到，把 SSE 的最佳化部份 porting 到 ARM 上面的 NEON 說不定會有很大的幫助：

Not one to despair, I figured out that applying the same optimizations I did for Intel would be trivial. Surely the NEON instructions map neatly to the SSE instructions I used before?

而 porting 完後重新測試發現達到了 66% 的效能，已經超過本來的目標... 另外在批次處理中，也比 Xeon 快了：

繼續發研究時又發現 NEON 有一些在 SSE 沒有的指令 (沒有相似功能)，也許能提供更進一步的加速：

While going over the ARMv8 NEON instruction set, I found several unique instructions, that have no equivalent in SSE.

如果再把這些指令實做出來，會發現單 core 的效能已經到 Xeon 的 83%，而批次的速度又提昇了不少：

最後是整台伺服器都跑滿時的測試，會發現整台的效能差不多 (其實 ARM 的版本還贏一些)，但吃電量不到一半，而就算只拿他們常態在跑的 4 workers 來看 (應該是為了 latency 問題)，用電效率來到 6.5 倍：

With the new implementation Centriq outperforms the Xeon at batch reduction for every number of workers. We usually run Polish with four workers, for which Centriq is now 1.3 times faster while also 6.5 times more power efficient.

這篇在提醒之後在 ARM 上寫最佳化時，不要只從 SSE porting 到 NEON，要多看一下有沒有其他指令集是有幫助的...