Go 1.5 的進展

Andrew Gerrand 在「The State of Go - Where we are in May 2015」這份投影片裡面提到了不少 1.5 的改變與改善,預定在今年八月釋出。

首先是全部都改用 Go 寫,不再需要 C 語言的協助了:

The gc tool chain has been converted from C to Go.

而效能上的改善最大的是 GC 的部份:

另外是對行動平台的發展:

Go 1.5 provides support for Android and experimental support for iOS.

這樣變得頗有趣的,自家的 Android 有打算換掉 Java 嗎?

CloudFlare 對 Go 上面加解密系統的改善

CloudFlare 發佈了自己版本的 Go,修改了其中的 crypto subsystem:「Go crypto: bridging the performance gap」。

文章花了不少篇幅介紹 AEAD (Authenticated Encryption with Associated Data),而目前 CloudFlare 支援的是 AES-GCM 與 ChaCha20-Poly1305,也是兩大主流,分別佔了 60% 與 10% 的 HTTPS 流量:

As such today more than 60% of our client facing traffic is encrypted with AES-GCM, and about 10% is encrypted with ChaCha20-Poly1305.

CloudFlare 提供的改進使得速度快很多,並且有考慮到 side-channel attack 的問題:

Both implementations are constant-time and side-channel protected.

                         CloudFlare          Go 1.4.2        Speedup
AES-128-GCM           2,138.4 MB/sec          91.4 MB/sec     23.4X

P256 operations:
Base Multiply           26,249 ns/op        737,363 ns/op     28.1X
Multiply/ECDH comp     110,003 ns/op      1,995,365 ns/op     18.1X
Generate Key/ECDH gen   31,824 ns/op        753,174 ns/op     23.7X
ECDSA Sign              48,741 ns/op      1,015,006 ns/op     20.8X
ECDSA Verify           146,991 ns/op      3,086,282 ns/op     21.0X

RSA2048:
Sign                 3,733,747 ns/op      7,979,705 ns/op      2.1X
Sign 3-prime         1,973,009 ns/op      5,035,561 ns/op      2.6X

AES-GCM 與 EC 的改善主要是利用 CPU 指令集加速:

[T]herefore we created assembly implementations of Elliptic Curves and AES-GCM for Go on the amd64 architecture, supporting the AES and CLMUL NI to bring performance up to par with the OpenSSL implementation we use for Universal SSL.

不過 RSA 的部份雖然幅度也不小 (比起 AES 與 EC 的部份是不大,不過純就數字來看,快了一倍多也不少),不過沒提到怎麼改善,只稍微帶過:

In addition the fork includes small improvements to Go's RSA implementation.

用 Go 寫的 Tor Relay Server

Zite 上看到的「Implementing a Tor relay from scratch」,用 Go 寫的 Tor Relay Server。

會跳下去用 Go 寫是因為效能上的考量:

[...], but the lack of AES-NI instructions on the CPUs cause a significant slowdown.

但因為一個 IP 只能跑兩個 instance,這就有點痛了:

To maximize the amount of relayed data, it is normal to simply run multiple instances of the program, up to two per IP address.

而作者的目標是超過現有的極限:

My final goal was to beat the Tor speed record, which was at roughly 200 megabytes per second.

成果就是直接吃滿 2Gbps (250MBytes/sec),而且 CPU 只用了 60%:

[...] He set up a server with my relay and within a few days we had broken the Tor speed record with a nice 250 megabytes per second, effectively maxing out the network link. CPU usage was at a nice 60% across 12 cores. But his relay also suffered from the memory issues and had to be restarted every few days.

作者的程式碼放在 GitHub 上,之後應該會有人跳進去改寫:「A fast implementation of the Tor OR code, in Go」。

C 對 Go Channel 的實做

在「Pure C implementation of Go channels.」這邊看到有人在 C 語言裡面實做 Go 的 Channel,包括了 Unbuffered 與 Buffered 版本。

看起來是支援 multithreading 的:「Add missing pthread_cond_destroy in chan init cleanup」、「Add -lpthread to CFLAGS」。

Go 對 Android 的支援

GoogleDavid Crawshaw 提出了「Go support for Android」的計畫。

提案中是希望 Go 1.4 可以開始支援:

During the Go 1.4 cycle, GOOS=android will be introduced to the Go repository, along with cgo support on Android (contributed by Elias Naur). Dalvik/ART-loadable .so files will be produced using the external linker provided in the Android NDK.

不確定 Go 目前的運作方式是怎麼樣 (i.e. Google 的影響力到底有多少),前幾天才出 1.3:「Go 1.3 is released」,1.4 應該還有一段時間才有機會看到。

用 Go 發展的 groupcache...

groupcacheBrad Fitzpatrick 最新的作品 (之前最有名的兩個作品是 memcachedOpenID 1),目標在於取代一部分 memcached 的功能。

以官方的說明是:

groupcache is a caching and cache-filling library, intended as a replacement for memcached in many cases.

另外一篇介紹文是「Playing With Groupcache」。

跟 memcached 差異最大的地方在於「沒有更改與刪除的功能」,一旦寫進去後就不會變動。在放棄 update/delete 的特性後,換來的是:

  • Cluster 的能力。
  • 處理熱點的能力。

以往在 memcached server 之間是沒有交集的,在 groupcache 則是 cluster 起來。另外以前在 memcached 會因為同時存取同一個 key 而造成 single CPU overloading 的問題,在 groupcache 則透過 auto-mirror 機制解決。

不過還是得想一下要怎麼用,畢竟沒有 update/delete 功能...