九维我操你爹
AI 已死，编程即将迎来人类时刻！
昨天 cursor 和 codex 多轮对话没解决的一个问题，本人出马 1 分钟就找到了根本原因，去给 AI 说了下完美解决。
现在人类发展太快了，再过五年会变成什么样子真的很难想象！
昨天 cursor 和 codex 多轮对话没解决的一个问题，本人出马 1 分钟就找到了根本原因，去给 AI 说了下完美解决。
现在人类发展太快了，再过五年会变成什么样子真的很难想象！
Paul E. McKenney 的 perfbook 实在太好看了，虽然我才肛开始读到第四章，但已经解决了好几个困扰我多年的技术问题了。
比如前两周我才和 codex 讨论了 go 里两个 goroutines 并发（并行）读写一个 u64 全局变量到底有什么危害，我之前以为最多就是并发写导致另一线程读到旧值，这种 bug 我是可以容忍的，于是省掉 atomic.Load 好了，毕竟原子操作性能也不好。
而书上 4.3.4.1 Shared-Variable Shenanigans 这一节列出来一大堆无保护并发读写共享变量的潜在危害，其中 Store tearing 引用的这个 2019 年很新(?)的内核讨论令我大吃一精： https://lore.kernel.org/lkml/20190821103200.kpufwtviqhpbuv2n@willie-the-truck/
上面的 bar 在某个历史版本 arm64 gcc -O2 编译出的结果是
而 arm64 在 v8.4a 之前 stp store pair 指令是非原子的，如果有无保护并发读，另一个线程可能会读到只修改了一半 32bits 的变量。
书上说这类问题用 volatile / WRITE_ONCE / READ_ONCE 就可以比较轻量级地解决，但 go 没有 volatile 只能用原子指令，令人忧愁。
比如前两周我才和 codex 讨论了 go 里两个 goroutines 并发（并行）读写一个 u64 全局变量到底有什么危害，我之前以为最多就是并发写导致另一线程读到旧值，这种 bug 我是可以容忍的，于是省掉 atomic.Load 好了，毕竟原子操作性能也不好。
而书上 4.3.4.1 Shared-Variable Shenanigans 这一节列出来一大堆无保护并发读写共享变量的潜在危害，其中 Store tearing 引用的这个 2019 年很新(?)的内核讨论令我大吃一精： https://lore.kernel.org/lkml/20190821103200.kpufwtviqhpbuv2n@willie-the-truck/
void bar(u64 *x)
{
*x = 0xabcdef10abcdef10;
}上面的 bar 在某个历史版本 arm64 gcc -O2 编译出的结果是
bar:
mov w1, 61200
movk w1, 0xabcd, lsl 16
stp w1, w1, [x0]
ret而 arm64 在 v8.4a 之前 stp store pair 指令是非原子的，如果有无保护并发读，另一个线程可能会读到只修改了一半 32bits 的变量。
书上说这类问题用 volatile / WRITE_ONCE / READ_ONCE 就可以比较轻量级地解决，但 go 没有 volatile 只能用原子指令，令人忧愁。
这个人用 AI 回我把我这篇感想的效果拉满了。。。
https://github.com/yihong0618/gitblog/issues/336#issuecomment-3850824162
https://github.com/yihong0618/gitblog/issues/336#issuecomment-3850824162
#晚安世界
https://youtu.be/Kx_BSeCM3zM
好久没能顾得上睡前听听歌了。
虽然今天被人种草了没有听过的歌，但躺在床上还是习惯性地找出了这个视频放在后台反复播放。
这首歌确实就这样轻缓但有力地支持我度过了无数个失眠或伤心的夜晚。
但是毕竟总是听一首歌也会腻，所以今天找的是韩语译配的版本。
https://youtu.be/Kx_BSeCM3zM
好久没能顾得上睡前听听歌了。
虽然今天被人种草了没有听过的歌，但躺在床上还是习惯性地找出了这个视频放在后台反复播放。
这首歌确实就这样轻缓但有力地支持我度过了无数个失眠或伤心的夜晚。
但是毕竟总是听一首歌也会腻，所以今天找的是韩语译配的版本。
我不排斥用 AI 学外语，真的。我平时经常会练习写日语小作文，等我自己写完都会发给 AI 帮我润色，并告诉我它为什么这样改。久而久之确实能写出更地道的日语句子了
但是开始学一门新的语言的时候，我却强迫自己不去用 AI。不管是发音也好语法单词也罢，我全都以一种苦行僧般的心态，坚持沿着古法学习
之前也说过，我特别后悔自学日语时没有打好基础。到现在我看起来很会讲日语了，其实底层的发音和语法还是一团糟。如果能重来一遍，我宁愿花钱请人帮我在一开始的时候纠正发音和语法
也是因为这个经历，我特别恐惧 AI 把我带进沟里。一定要等自己有足够的语言基础了，才敢半信半疑地让 AI 给我学习的反馈
但是开始学一门新的语言的时候，我却强迫自己不去用 AI。不管是发音也好语法单词也罢，我全都以一种苦行僧般的心态，坚持沿着古法学习
之前也说过，我特别后悔自学日语时没有打好基础。到现在我看起来很会讲日语了，其实底层的发音和语法还是一团糟。如果能重来一遍，我宁愿花钱请人帮我在一开始的时候纠正发音和语法
也是因为这个经历，我特别恐惧 AI 把我带进沟里。一定要等自己有足够的语言基础了，才敢半信半疑地让 AI 给我学习的反馈
https://fixupx.com/i/status/2018610581423685890
🧵 スレッド • FixupX
Hayakawa Ayako (@AyakoHayakawa)
このバンドの歌詞も凄く好きだ。中国語独特のリズムが活きているけどリズムの為に意味を捨てていない。風土や民俗性や風刺や逆説などが混ざりあいつつ短く言い切り且つ余韻がある言葉。私にはとても翻訳出来ない。この素晴らしい歌詞も切り刻まれてしまった。それでも作品を残す事に意味がある。続
Hayakawa Ayako (@AyakoHayakawa) を引用
94年結成のバンド。同世代で残っているバンドは次々と大金と引き換えに跡形もなくなってしまったが、未だに好きで居させてくれているバンド。色々あってネットで…
Hayakawa Ayako (@AyakoHayakawa) を引用
94年結成のバンド。同世代で残っているバンドは次々と大金と引き換えに跡形もなくなってしまったが、未だに好きで居させてくれているバンド。色々あってネットで…
虽然工作中是和 seekdb 以及开源生态强相关的，但是技术选型还是要看是不是符合自己的需求和预期。
我觉得从站位上来讲，seekdb 的点位是选的比较好的，但是从目前跨平台能力和资源占用控制上，可能还需要打磨一段时间，内部是有计划去把这个项目做好的。选型的话，我也推荐看看 sqlite + sqlite vector / duckdb 以及像 lancedb 这些选择，确定这个是不是真的是你想要的。
如果你需要一个 mysql 语法兼容，需要一体的向量、全文、通用 db 能力，有一定 local first 支持，期待官方后续能够提供一些常见方案的数据库，可能 seekdb 有潜力成为一个可以考虑的选择。
不构成技术选型建议。
我觉得从站位上来讲，seekdb 的点位是选的比较好的，但是从目前跨平台能力和资源占用控制上，可能还需要打磨一段时间，内部是有计划去把这个项目做好的。选型的话，我也推荐看看 sqlite + sqlite vector / duckdb 以及像 lancedb 这些选择，确定这个是不是真的是你想要的。
如果你需要一个 mysql 语法兼容，需要一体的向量、全文、通用 db 能力，有一定 local first 支持，期待官方后续能够提供一些常见方案的数据库，可能 seekdb 有潜力成为一个可以考虑的选择。
不构成技术选型建议。
