- 主题:stackoverflow 有个比较 c++ stackful 和 stackless 协程的帖子
都用数据库了，还抠个毛的速度啊
【 在 ylh0315 的大作中提到: 】
: 我设计的高频交易架构是这样：
: 服务器多核多线程，TPC模式，每个链接一个线程。多台服务器。服务器要处理数据库业务，只能使用简单的多线程模式。
: 加一个管理器，对多台服务器设置连接池。对每台服务器有限个链接（服务器有限个线程）。对多个服务器进行负载均衡和容错。
: ...................
--
FROM 183.128.164.*
兄弟，醒醒，意义不大，真在乎速度的都是FPGA+RTOS，都不是RTOS，随便一个cpu切片就洗白了
【 在 mvtec 的大作中提到: 】
: 有专用网卡比如solarflare
: 专门做kernel bypass
: Solarflare之类网卡取得multicast data
: ...................
--
FROM 183.128.164.*
你们这个所谓的交易构架，客户端有几万个，我就表示怀疑是不是正儿八经的交易构架
【 在 ylh0315 的大作中提到: 】
: 是的。
: 但是具体到其中关键算法，扣一点指令还是会的。
: 比如管理器，取服务器的连接，将客户端数据发往服务器，等服务器返回后，先释放连接，后给客户端返回数据。保证连接能够尽快为下一个客户使用。
--
FROM 125.118.37.*
听起来更像经纪商的平台构架，而不是交易构架，哪个正儿八经的交易系统，会有几个万个客户端
【 在 ylh0315 的大作中提到: 】
: 在TUXEDO基础上的改进版。
: 性能比它高多了。
: 在交易过载的情况下，最长响应时间与平均响应时间之比，
: ...................
--
FROM 183.128.164.*
严重怀疑是不是什么和OS相关的macro没加，导致boost是在模拟fiber，而不是调用OS api来实现
【 在 mvtec 的大作中提到: 】
: fiber的运行速度跟屎一样
: 还真敢用
: 我们有个feed handler
: ...................
--
FROM 183.128.164.*
okok
【 在 ylh0315 的大作中提到: 】
: 其实重点是，在高频交易系统中，在交易管理环节，需要协程技术，而且是多线程的协程。需要高效率的切换，一个服务完成后，尽可能快速切换到另一个用户，尽量减少服务的空等时间。
: 有点像银行的排队机，一个窗口空了，马上叫下一位。
: 单线程的协程不行，一个连接空闲了，线程还在别的协程忙活，慢慢悠悠轮到这个协程再处理。
: ...................
--
FROM 183.128.164.*
因为你在说纳秒级别 如果kernel by pass只省了纳秒级别 那么用cpu跑交易逻辑是没有意义的 因为随便一个大一些的cache miss或者cpu 切片都比这个大
所有你看见的纳秒级的tick to trade的 都是交易逻辑直接烧在网卡芯片里的
CPU处理交易逻辑的 就算再kernel by pass 也会涉及到硬件中断 甚至就算你的网卡芯片可以by pass cpu直接写内存 你绑交易逻辑的核也需要读内存而不是读缓存 就算读缓存 只要你不是读一级缓存 在现在cpu的构架下 都涉及同步各个核之间的缓存同步
绝大部分墙街的公司 除了真正的几个用fpga的头部玩家 无非都是照猫画虎而已
【 在 mvtec 的大作中提到: 】
: 兄弟厉害一句话就把华尔街这帮trading公司全给否了。 ...
--
FROM 36.28.191.*
我们在说同一个东西么？做外汇平台的就别在这儿秀了
【 在 ylh0315 的大作中提到: 】
: 交易处理都不需要纳秒级，也不用RTOS。自动控制系统才需要。交易系统关注的主要指标是：并发的客户数，响应时间，秒级，亚秒 ...
--
FROM 36.28.191.*
你想要秀 那我就告诉你 你那个构架就是个垃圾 几万个客户端 你一个连接一个线程？就你这个构架 用不用协程都一样 你的瓶颈是在网络io和数据库io上 你在这儿秀协程甚至都不是正确的使用场景
Epoll IOCP直接解决掉你一半以上的问题 然后另一半 你需要把数据库信息内存化 把数据库和内存结构体同步起来 放弃sql查询 直接读内存结构体
庸人瞎忙
【 在 ylh0315 的大作中提到: 】
: 大家讨论嘛。这贴不是说的协程吗？有说协程怎样用于高频交易的，我就说了这么多。见谅。 ...
--
FROM 36.28.191.*
有什么看不明白的
说了半天就是stackless的协程没法自动保存context
然后又说了半天stack
full的协程stack内存分配有玄学
讲真
这点东西有什么可讨论出来的
标准库的协程这玩意出来才多久
要用要讨论你们也等24的小补丁版出来再讨论
现在真的要用要么就自己每个协程弄个标识
自己heap上弄个内存布局好一点的map查一下
要么最好别用
一来新东西 就不管应用场景一股脑就想用新的 协程有携程的好处 异步回呼有异步回呼的好处 真的每个异步需要高效到保存context用协程嘛？真的有需要用几万个协程的场景么？
协程又不是什么新东西
【 在 hgoldfish 的大作中提到: 】
: 是协程不是线程。你好像没看明白这一系列的帖子都是在讲协程。 ...
--
FROM 36.28.191.*