@whileFalse 买撕裂者的都是为了 RECC 和 PCIE 去的

@zhuwd 几乎不存在可观测的差距

Go 没怎么太关心在 Windows 上的性能。以及 IOCP 的模型和 epoll 的模型不兼容，Go 选择了照顾 Linux 环境而加重了 Windows 上的开销。论及纯粹的性能来说 IOCP 比 epoll 强，要到 io_uring 这个接口出现才算打平。

在老东家用 k8s 的时候我是用支持 BGP 的 CNI 把整个集群内的地址都暴露到内网上了，内网可以直接访问集群内的所有 pod 和服务

GC 语言里 C#，无 GC 里 rust

你的分布式锁本身打算用什么实现？如果用 redis 这类自带脚本的东西那简单做一个按开始秒数作为 key 的有序集合，每次上锁用 lua 检查集合内是否有交集区间，有的话就失败让客户端等待，没有就写进去然后上锁成功。超时失败重试之类的都可以参考标准 redis 锁。感觉一小时就能搞完

先尝试 taskset 或者 numactl 把 mysql 绑定到一个 numa 节点再测一下看看

@dcsuibian 现在 openzfs 能加盘了

我就不一样了，我根本不用 AI 写代码，直接解决问题本身（

@weiwenhao
最终的核心还是在哪个线程上调度执行，也就是协程唤醒后在哪的这个问题。因为这牵扯到线程本地变量、线程特权之类的问题。至于如何通信那是很次要的问题

@weiwenhao
预留接口我实际上是指能自定义调度器算法等逻辑，不过有栈协程这点确实不好搞。但是实际上有些业务确实很需要自定义调度器，比如全局一个 M:N 调度器，然后有 N 个 M:1 调度器，以及重入调度器非重入调度器。但这些感觉不是很容易的在有栈协程上实现，无栈的比较容易。我觉得可以考虑先能够创建多个调度器并挂到上下文里，以及限定调度器的并行度。后续可以提供协程本地变量以及挂在协程上的上下文，避免 go 那个恶心的 ctx 参数到处传

@weiwenhao
函数参数和返回值的前后置感觉很割裂啊，为什么不选择单一方式呢？另外如果想做游戏的话调度器还是需要给开发者留下自定的接口，不然主线程调度会很难写，用起来非常恶心。

@knowckx 语法本身会大幅度影响最终性能，不可不仔细考虑。不过只要还关注编译速度等指标，那终究不能和完全不关心编译性能的一众语言比较最终性能的。

使用 Rust 的理由之一：开发者会犯错（

@ELLIA 性能差的不是一点半点

@ELLIA 但是 wtr max 耍猴，到现在都没货

那没辙了，非技术原因那只能谁拳头大谁说了算。不然做游戏，找不出比 C# 更好用的。

你换 Go 的目的是什么要想好。用目前的 LTS 的 dotnet 8 开发，无论是开发速度还是运行性能基本都比 Go 强。如果是因为公司要求或者人员技能构成的方面倒还无可厚非，如果单纯是觉得 Go 能带来比 C#更好的开发或者运行性能收益那我觉得你会亏爆。

因为互联网填的的那点数据不够中大型游戏策划一周的量。
一个游戏基本上再怎么小，也是几十张表起步，复杂游戏或者数值游戏在运营几年后轻松可以有个三四百张表几十万行到百万行的数据。
这些数据有很多都是需要策划拉公式并反复测试调整得到最终值，然后再张贴到另一张结果表里给开发。如果要把这些表格功能都给搬上后台里，开发工作量比游戏本身还大了。