Why Regex Sucks in a Hot Loop
A while back I ripped a regex out of my SQL parser and replaced it with twenty lines of hand-written string scanning. Then I got nervous. Hand-rolling a scanner because you assume regex is slow is exa...
评论
点赞
收藏解析而非猜测：为什么诚实的API比智能的猜测更可靠
作者分享在开源PostgreSQL解析器前，删除了看似智能实则基于猜测的外键推断功能。文章指出“错误的结果比空结果更危险”，因为猜测会引发静默错误。作者将API改为必须提供Schema元数据才能返回结果，否则返回空。这种“不知道就说不知道”的设计反而提升了用户信任，是工程实践中关于API设计和诚实性的优秀案例。
微秒级的谎言：为什么你的Go计时器在GPU数据上撒谎
作者分享了一次踩坑经历：使用Go标准时间库测量CUDA内核执行时间得到160微秒，后发现因CPU与GPU异步执行导致测量失效。通过引入CUDA Events在Go中获取了真实的硬件耗时。文章解释了CPU侧计时器无法准确反映GPU实际运行时间的原理，并提供了使用Go绑定CUDA Events进行准确性能分析的解决方案。
删除 8.4GB Python 旁路服务：使用纯 Go 和 CGO_ENABLED=0 实现 CUDA 调用
作者分享了一个名为 gocudrv 的项目，旨在让 Go 服务无需 CGO 和 CUDA 工具链即可直接调用 NVIDIA GPU。文章基于实际生产环境痛点，指出通过 Python sidecar 访问 GPU 导致镜像臃肿（8.4GB）、冷启动慢及序列化开销大。通过纯 Go 实现 CUDA 驱动交互，实现了单静态二进制文件，显著优化了部署效率和资源占用。 
为什么大语言模型运行在GPU上而非CPU上
文章纠正了LLM使用GPU是因为其是特殊AI硬件的常见误解，指出GPU并非理解语言或推理，而是擅长在大量数据上并行执行相同的数值计算。LLM的推理过程本质上是这种大规模并行数值运算，因此GPU架构更适合。
无需cgo：在Go中调用CUDA的方法
作者分享了一个名为gocudrv的项目，旨在让Go代码在运行时动态加载NVIDIA驱动来调用CUDA，从而避免在编译时依赖CUDA头文件、C编译器或cgo。文章解释了避免cgo的原因，包括简化构建流程、减少平台特定工具链依赖以及便于跨平台编译。
我的第一个CUDA内核比单线程CPU循环还慢
作者分享初次编写CUDA内核时的踩坑经历：拥有数千个GPU核心，但性能却不如单线程CPU循环。文章指出GPU是吞吐量机器而非魔法加速器，若任务量不足，GPU只会带来开销而非加速。通过CPU与GPU的对比，强调了并行计算中数据规模和并行度的重要性。
设计他人真正愿意使用的Go SDK的三条规则
作者基于开源Go库的开发经验，提出设计易用SDK的三个规则。核心观点是API设计应从开发者视角出发，而非作者视角，强调降低新用户上手门槛，避免为作者自己方便而设计。
AI是头条新闻，工具才是护城河
文章指出英伟达五万亿美元市值的核心并非GPU硬件本身，而是围绕其构建的CUDA等软件栈及十五年积累的工程优化。作者强调芯片只是头条新闻，而完整的工具栈才是企业能够实际交付产品的护城河，这一视角在当前的AI讨论中常被忽视。
你的SQL中每个问号都在隐藏什么
文章通过一个具体的SQL查询示例，深入解析了SQL语句中占位符'?'在不同上下文中的多重含义和潜在陷阱。作者指出，看似简单的问号在预处理语句、动态SQL或特定数据库方言中可能代表完全不同的数据类型或逻辑，提醒开发者注意SQL注入风险、类型推断错误以及代码可读性问题。这是一篇针对后端和数据库开发者的实用技术警示文。
别再向LLM Agent发送9.3万Token的数据库Schema了
作者指出LLM Agent在查询数据库时反复查询information_schema导致大量Token浪费。通过在一个500表的数据库中，预先将Schema提供给Agent，实现了64%的Token减少。文章介绍了其构建的工具dbdense，这是一个包含提取、编译和服务三个步骤的离线管道。