- 主题:异步stream的问题
要么独占cpu，如果有多核的话。要么实时os，或者无os
【 在 AlphaO 的大作中提到: 】
: 是的，我摸索感觉，瓶颈主要可能是CPU不只专门接收。仅从代码看，接收1次完毕后，立刻用mpsc发出去，它理应立刻准备去接下一帧。但实际上我感觉——在异步await下——CPU此时也许会进行系统调度，比如后台其他任务突然占用该CPU一定时间等等。 其实如果无操作系统，或者实时
: 低撑渲靡幌拢兰撇换嵊形侍
--
FROM 125.34.113.*
不知道下面这个想法是否可以解决问题：
如果硬件是多核的，可以考虑再把接收消息暂存任务放到一个线程中，处理消息放到另一组线程中（这组线程数不要设置多余硬件cpu核-1），这样就不会有处理线程去干扰接收消息的线程了。
【 在 AlphaO 的大作中提到: 】
: 嗯，已经是分离的架构，类似下面语句不断循环
: if let Ok(size) = bufreader.read(&mut msg, MAX_READ_LENGTH).await {
: mpsc_handle_tx.try_send(msg).unwrap();
: ...................
--
修改:NewMonk FROM 117.133.64.*
FROM 117.133.64.*
这个思路尝试过，但对操作系统有要求，而对通用的windows和常用linux变种则行不通，因为这些通用操作系统，为了充分利用硬件，在线程调度方面有内置的优化策略，这种优化调度会动态打破线程和任务的绑定关系。例如，无法将一个核指定为仅仅运行1个特定任务而不运行其他，哪怕强行指定其他用户进程对该核的完全不亲和，但内核进程不归用户控制，还是会征用该核
【 在 NewMonk 的大作中提到: 】
: 不知道下面这个想法是否可以解决问题：
如果硬件是多核的，可以考虑再把接收消息暂存任务放到一个线程中，处理消息放到另一组...
--
FROM 114.246.94.*
你这个和dpdk类似。它可以做到独占核心。不过你的环境是嵌入式把？如果你可以不用os，可能比折腾这些更简单。
【 在 AlphaO 的大作中提到: 】
: 这个思路尝试过，但对操作系统有要求，而对通用的windows和常用linux变种则行不通，因为这些通用操作系统，为了充分利用硬件，在线程调度方面有内置的优化策略，这种优化调度会动态打破线程和任务的绑定关系。例如，无法将一个核指定为仅仅运行1个特定任务而不运行其他，哪怕
: 强行指定其他用户进程对该核的完全不亲和，但内核进程不归用户控制，还是会征用该核
: 如果硬件是多核的，可以考虑再把接收消息暂存任务放到一个线程中，处理消息放到另一组...
: ...................
--
FROM 123.125.167.*
确实有点这个意思，除了dpdk是利用以太网，我是利用U3。技术途径看着也差不多，数据全程零拷贝，恰好是Rust擅长的。最后软件要在windows上用，因为可能的使用者还是最习惯windows
【 在 chunhui 的大作中提到: 】
: 你这个和dpdk类似。它可以做到独占核心。不过你的环境是嵌入式把？如果你可以不用os，可能比折腾这些更简单。
:
--
FROM 1.202.157.*
厉害！
【 在 AlphaO 的大作中提到: 】
: 确实有点这个意思，除了dpdk是利用以太网，我是利用U3。技术途径看着也差不多，数据全程零拷贝，恰好是Rust擅长的。最后软件要在windows上用，因为可能的使用者还是最习惯windows
--
FROM 123.125.167.*
哪里，过奖了，如果用c/cxx、c#肯定搞不到性能这么快和好，可以说是95%得益于Rust工具链
【 在 chunhui 的大作中提到: 】
: 厉害！
--
FROM 1.202.157.*
rust是个好东西。我也想了解了解。
【 在 AlphaO 的大作中提到: 】
: 哪里，过奖了，如果用c/cxx、c#肯定搞不到性能这么快和好，可以说是95%得益于Rust工具链
--
FROM 123.125.167.*
赞
【 在 chunhui 的大作中提到: 】
: rust是个好东西。我也想了解了解。
--
FROM 1.202.157.*