你用过 Go 的 math/big （或者其他 decimal 包）就知道了，他们的加减乘除是这样的：

```
func (z *Int) Add(x, y *Int) *Int
func (z *Int) Sub(x, y *Int) *Int
func (z *Int) Mul(x, y *Int) *Int
func (z *Int) Quo(x, y *Int) *Int
```

本来一行就能写完公式，你用上面的 API 要不断搞中间变量，硬是写成十几二十行，每次写点复杂的计算公式或者 code review ，我就头大，非常想要运算符重载。

@zeusho871 目前 llgo 对 go 支持不咋地，连 fmt, net/http 这些都没有 :(

之前有人做过测试，以 C 为基线，Rust 的运行时检测大约带来 1.77x 的损耗，其中 bound check 大约占 50%。

https://dl.acm.org/doi/fullHtml/10.1145/3551349.3559494

用 outbox 模式，把消息也写到 db 。

@NessajCN Rust for Linux 做的就是 kernel api 封装 + high level 抽象，说是调用也没问题。

如果 Rust 不进内核倒没这么多问题了，让 Rust 开发者改调用的就是了。

但是 Rust 进到内核之后，C 开发者和 Rust 开发者的合作就会有很多问题。C API 改动导致 Rust 代码编译不过的话，怎么办？放着不管？ 让 C 开发者学 Rust ，改 Rust 代码？ C 部分的开发、设计会不会受 Rust 的影响和限制？。。。

@NessajCN bindgen 生成的只是 low level binding ，还是 unsafe 的。像 25:29 那些 safe high level API (get_or_create_inode) 还是要手搓。如果 iget_locked 真的改了（虽然我觉得这个 api 基本不会改了），手搓的部分还是要再搓一遍。然后实现就会不同步。

@matrix1010 想起来为什么没有用 x/sys/cpu ，因为它的 cacheLineSize 是私有的，只能用 CacheLinePad ，浪费了一点点内存 :|

@matrix1010 对。x/sys/cpu 会根据指令集决定。 刚看了源码，也是因为 Apple Silicon 改成了 128 :)

就差把 amd64 也改成 128 了 :(

看到里面实现了一个 Counter ，然后加了 cache line pad ，cacheLineSize 写死了 64 。

但是 Apple Silicon 的 cache line 是 128 ，所以还是有 false sharing 。

然后 Intel 虽然 cache line 是 64 ，但是 prefetcher 一次可能会读两个 cache line ，而 AMD 又没类似的优化。

还有些大小核 cache line 不一样的。

所以现在常见的做法是 ARM64, AMD64 都假设是 128 。

参考：
- crossbeam::utils::CachePadded 的 PR： https://github.com/crossbeam-rs/crossbeam/pull/636, 顺藤摸瓜可以找到很多讨论
- https://github.com/embedded-momo/fastcounter-go 一个类似的 Go 实现，固定 128 cache line 。