xchacha20-ietf-poly1305 的速度只有 chacha20-ietf-poly1305 的一半？

[pexcn]

👋
我在不同的设备上测试过 shadowsocks-rust (v1.10.7) 的 chacha20-ietf-poly1305 和 xchacha20-ietf-poly1305 加密方式，发现 xchacha20-ietf-poly1305 的速度大概只有 chacha20-ietf-poly1305 的一半，而 libev 版本这两个加密方式的速度都差不多，这是什么原因呢？

注：速度测试的具体细节在 https://gist.github.com/pexcn/fe3dc944672cf70d6fda7a186240f932

[zonyitoo]

Well, I suspected that there are two main reasons

First of all, shadowsocks-libev uses libsodium for these two algorithms. chacha20 and xchacha20 have very similar implementation except nonce length, so they should perform nearly the same with the same implementation in one library. But xchacha20-ietf-poly1305 should expect to have lower performance compared to chacha20-ietf-poly1305 because it requires extra calculation on generating new keys and nonces on every encrypt calls.

Secondly, chacha20-ietf-poly1305 in this project uses ring as its backend, but xchacha20-ietf-poly1305 uses a pure Rust implementation. As you can see in its implementation, if your CPU supports SSE4.1, it will uses a pure assembly implementation.

The pure Rust implementation doesn't have that kind of optimization. It is expected to have performance differences between them.

Very decent benchmarks, could you make it into a table?

Interestingly, Intel J1900 has SSE4.1 accourding its specification, but chacha20-ietf-poly1305 and xchacha20-ietf-poly1305 performs nearly the same in the Rust implementation. Maybe newer the CPU is, the more performance gain from the pure assembly implementation.

[zonyitoo]

I made a simple test on my laptop

• macOS 11.2.3
• CPU Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz

Base test

Run iperf directly

------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 5001
TCP window size:  344 KByte (default)
------------------------------------------------------------
[  4] local 127.0.0.1 port 61927 connected with 127.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  33.8 GBytes  28.9 Gbits/sec

chacha20-ietf-poly1305

------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 3001
TCP window size:  584 KByte (default)
------------------------------------------------------------
[  4] local 127.0.0.1 port 62215 connected with 127.0.0.1 port 3001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  6.79 GBytes  5.83 Gbits/sec

xchacha20-ietf-poly1305

------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 3001
TCP window size:  400 KByte (default)
------------------------------------------------------------
[  4] local 127.0.0.1 port 62301 connected with 127.0.0.1 port 3001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  2.67 GBytes  2.30 Gbits/sec

Conclusion

It seems that target-cpu=native doesn't help to optimize all those XOR operations.

cc @LuoZijun

[zonyitoo]

Some more tests about AES-GCM and AES-CCM

aes-128-gcm

------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 3001
TCP window size:  344 KByte (default)
------------------------------------------------------------
[  4] local 127.0.0.1 port 62565 connected with 127.0.0.1 port 3001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  8.37 GBytes  7.19 Gbits/sec

aes-128-ccm

------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 3001
TCP window size:  576 KByte (default)
------------------------------------------------------------
[  4] local 127.0.0.1 port 62621 connected with 127.0.0.1 port 3001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  3.56 GBytes  3.05 Gbits/sec

[pexcn]

感谢你的回复 :)

刚刚看到一些相关的信息 briansmith/ring#411 和 #113 (comment) 大概了解了一些。

but xchacha20-ietf-poly1305 uses a pure Rust implementation

发现曾经是用过 libsodium 的, 后来改回去了，可能这样会使代码更漂亮些，不臃肿吧😀

Very decent benchmarks, could you make it into a table?

请问是要做成一个表格的意思吗？
我这个测试可能没有通用性，因为是用我自己的 docker image 来测试的，编译时有一些参数也和 release 的版本不同

Oh, BTW, did you enable Rust's native CPU optimizations? If no, please test again with environment variable RUSTFLAG="-C target-cpu=native" to let rustc produces optimized code for your host CPU.

习惯在 docker 里运行，比较方便，没有开启 Native CPU 优化 :)

[pexcn]

@zonyitoo
我的测试是用 iperf 测试 sstunnel 到 ssserver 之间的数据，这样测出来的结果准确吗？会不会被一些比如 SO_SNDBUF, SO_RCVBUF... 之类的参数影响呢？

顺带一提，我的测试脚本启动 ss-rust 的时候，还加了 --tcp-no-delay 参数，它是否会对测试结果有影响？

还有就是有没有办法不用 sstunnel 模式，直接测 sslocal 到 ssserver 之间的数据呢？

[zonyitoo]

会不会被一些比如 SO_SNDBUF, SO_RCVBUF... 之类的参数影响呢？

It shouldn't have any differences.

还加了 --tcp-no-delay 参数，它是否会对测试结果有影响？

It should be better to remove it.

还有就是有没有办法不用 sstunnel 模式，直接测 sslocal 到 ssserver 之间的数据呢？

It doesn't matter. Here we were testing the shadowsocks' protocol, not the local's proxy protocol. It is ok to test only with sstunnel and ssserver.

发现曾经是用过 libsodium 的, 后来改回去了，可能这样会使代码更漂亮些，不臃肿吧

Yes, it is quite annoying to cross compile it.

It would be nice to have briansmith/ring#411 resolved for xchacha20-ietf-poly1305, otherwise we will have to write our own assembly code.

[LuoZijun]

@pexcn 已经有一个 XChaCha20 的速度优化版本，如果 XChaCha20 成为标准了，那么就可以加进去。

https://github.com/LuoZijun/test_xchacha20_poly1305

[zonyitoo]

Please added into shadowsocks-crypto. Please.