 |
1
wzw 2020-12-28 16:59:29 +08:00 via iPhone
那 pika 也可以用
|
 |
2
julyclyde 2020-12-29 11:04:53 +08:00
js 和 go 界的事终于传播到了 rust 界？
|
 |
5
jinmingjian 2021-01-02 11:58:07 +08:00
我看了一下，我真觉得挺好，小还算美，洁癖我喜欢！用的是 std 的 sync io，性能应该，咳咳（老毛病...），有没有计划升级一下 io ？
|
 |
6
ltoddy OP @jinmingjian 性能我用写了一个 benchmark，发现比异步要快很多……
|
|
7
ltoddy OP 我之前尝试过，多线程+CSP 处理方式，性能吊打异步。
|
|
8
jinmingjian 2021-01-05 08:29:38 +08:00
@ltoddy 比 Rust 语言层的所谓 async 快，是很有可能的。现在 Rust 的 async 默认似乎是 thread local （不同版本可能有不同），对于大规模的 bench 肯定是不适合的，你需要调优。
但你现在这种同步式比真正高性能意义上的“异步”，那肯定是弱鸡的。 原因很简单，同步式调用在消息没返回之前线程时间片是浪费的，增加线程不改变这一点。这也和 CSP 无关，你 socket 读写是系统调用，任何用户态机制下，你这调用都必须浪费。CSP 和 coro/generator/future 本质是等价的，所以 CSP 并不会比 async 高明，且 Rust 不（完全）支持尾递归优化，写成 CSP 性能可能更弱。简单说，简单多线程效率比真正利用系统 /驱动层的异步机制效率至少差量级以上。我最近写 server，techmpower 的 plaintext 测试单机都是每秒一千万 request[1]，但 http 比 redis 说复杂 100 倍还是有的。 你可以把你的多线程+CSP 代码放出，我和你细品一下，当然时间是个问题，我们可以慢慢细品。 |
|
9
ltoddy OP @jinmingjian 多线程+CSP 是我很早超不多一年前了吧，那时候测得。
我自己那个 redis-rs 项目里面，写了一个简单的 benchmark，可以使用 make bench 运行。 bench 里面代码是参照： https://github.com/mitsuhiko/redis-rs 他里面做的，因为我想和他比较一下。 （速度比他快。 |
|
10
ltoddy OP 我思考了一 i 个问题，虽然处理方式不一样，但是我感觉，一般来说整洁清晰，质量不错的代码，也往往性能不错。
|
Select Language