说高频交易，要看是多高频

大家在抬杠过程中，总是说纳秒级，那我们就说纳秒级的tick to trade策略

交易所统计数据中，从新的tick发出，到收到下一次order flow的第一批高峰，大概是在16ns到500ns左右，这一批策略，基本上就是你说的，并发量在100(当然，对交易来说100也不小了）以内，因为基本上是一块芯片对一个合约，网卡收到交易所收到数据以后，所有的FIX解包就在网卡芯片上直接完成，然后的确是一个大的mesh，直接算出来，所有的策略参数，都是烧死在硬件里的，尽量减小动态读取的次数。这批头部玩家的主要区别其实是网线接在交易所路由器的第几个口，因为路由器背板转发事实上也是有先后的，能相差十几纳秒


【 在 philbloo 的大作中提到: 】
: network processor 也好，FPGA 也好，ASIC 也好，架构里还是有 memory system，总不可能全部数据都在 register file 甚至全都在 crossbar 里吧？当然可以设计成多核之间完全并行，不共享 memory port，总线还是会有 contention 吧？
: 是不是因为并发的数量很小（小于几千）所以可以做一个大块的 mesh，做到整个 dataflow 完全没有 contention 而不影响 thruput？
: btw，这种公司是只设计 IP，后续工作全部外包出去，还是自己设计整个 SoC，直接跟 fab 接口？
: ...................
--
FROM 183.128.163.*

所以你的意思是，因为懒得管理资源生命周期，所以一股脑干脆直接用协程

这不是滥用又是什么

协程这种模式，不是为了给你简化资源的管理的，而是为了在某些真的需要很高性能但又不得不异步的情况下采用的，省的就是user层面的资源存取和context资源存取的速度。

C10K个个都需用很高性能，这个需求和场景本身就是有问题的。c10k问题的瓶颈永远是在io上，比如说他那个例子，就是在数据库的读取上，就算用了几万个协程，最后瓶颈还是在数据库io上，它看起来cpu跑满了，恐怕实际上大部分的cpu的开销都在协程的资源分配和释放查超时上。

如果不论什么场景都无脑协程，我觉得不如不要写c++了



【 在 hgoldfish 的大作中提到: 】
: 随便弄个 c10k，就开几万个协程了。一个协程处理一条连接。
: 而且我很喜欢在协程里面管理一系列对象的生命周期。所有的对象都申请在协程栈里面，协程退出的时候一次性全都销毁掉，不要在堆里面搞来搞去。
:
--
FROM 183.128.163.*