1978年，一台新机器号称性能提升300%，实测却连旧电脑都跑不过。测试任务平时1小时完成，新机器跑了一整天还没结果。问题出在缓存——这个被多数人忽视的硬件细节，直接决定了软件能跑多快。
这是EDA（电子设计自动化）行业老兵Brian Bailey的真实经历。他在芯片设计工具领域摸爬滚打40年，得出的结论很刺耳：任何声称与硬件无关的软件，都是低效、臃肿的垃圾。这个判断放在今天AI算力军备竞赛的背景下，尤其值得细品。
一天完成的移植，对方以为要一周
Bailey的职业生涯始于Hilo开发团队。那是1980年代初，团队里有Phil Moorby、Simon Davdimann、Peter Flake等人——后来都成为EDA领域的传奇人物。他们的代码有个特点：从第一行开始就为可移植性设计。
当时没有Windows或Linux一统天下，每台计算机都自成体系。Bailey的工作就是拿着磁带，把软件移植到新平台。从抵达客户现场到测试完成，通常只要一天。计算机厂商的预期是一周，看到他的速度直接懵了。
秘密武器是一门叫BCPL的语言。它比C语言更早出现，语法类似，但极简到只有两种数据类型：整数，和指向整数的指针。字符串要塞进整数数组，结构体靠宏定义，每个元素用基地址加偏移量访问。
这种粗糙反而逼出了关键认知：数据对齐（Data Alignment）。如果内存地址没对齐，加载一个整数要花两倍时间。Bailey说，这是他在Hilo学到的第一课——性能不只看CPU多快，内存怎么访问同样致命。
3倍性能的新机，被缓存算法拖垮
第二课来自一次失败的移植。客户是大型计算机制造商，新机即将发布，官方标称性能是旧机的3倍。Bailey完成移植后跑测试，平时1小时的任务，新机器跑了一整天还没结束。
排查后发现，新机要么缓存缩水，要么分页算法被改。CPU确实更快，但内存子系统一直在"抖动"（Thrashing）——频繁在缓存和主存之间搬运数据，CPU大部分时间都在空等。
这次经历让Bailey形成核心观点：软件性能=CPU算力×内存效率。只看MIPS（每秒百万条指令）是外行，缓存大小、替换算法、数据局部性，这些硬件细节才是瓶颈所在。
他后来加入一家大型EDA公司，发现团队花了大量时间自建基础库，专门替换标准C库。通用库为了兼容各种场景，牺牲了大量性能；针对特定硬件优化的代码，才能榨干最后一滴算力。
被收购毁掉的代码库
Bailey的第三课来自接手一个"遗产项目"。软件经过多轮收购，原始开发者全部离职。他形容代码状态："就像一栋房子，每任房主都在原来的地基上盖新房，没人知道地下管线在哪。"
具体问题是内存管理。原始设计假设内存充足，后期功能堆叠导致碎片严重。Bailey团队花了数月重构，把内存占用砍掉60%，速度提升数倍。代价是代码不再"通用"——必须针对目标平台的内存架构重新调优。
这印证了他的判断：脱离硬件谈软件优化，是行业最大的幻觉。云计算时代，这个幻觉被包装成"弹性扩展"——性能不够就加机器，用硬件成本掩盖软件低效。
但AI训练正在打破这个舒适区。GPT-4级别的模型，训练成本以千万美元计，缓存命中率每提升1%，可能节省数百万。硬件细节从未如此昂贵。
BCPL的遗产：少即是多
回头看BCPL的设计，Bailey认为其极简主义有现代启示。只有两种数据类型，迫使程序员直面内存布局；没有高级抽象，反而消除了隐藏的性能陷阱。
他对比了现代编程的"肥胖症"：框架叠框架，依赖套依赖，一个简单功能拖进几十兆运行时。开发者抱怨"机器变慢了"，真相是软件在变胖——而且胖得理直气壮，因为"硬件会跟上"。
苹果M系列芯片的成功，某种程度上是对这种逻辑的反击。统一内存架构、大容量缓存、硬件加速单元，这些设计都在逼迫软件重新考虑硬件亲和性。Metal图形API比OpenGL快，不是因为API设计更好，而是因为它假设了特定的内存模型。
Bailey在2023年的文章中写道："声称硬件无关的软件时代已经结束。"他的论据不是技术怀旧，而是成本算术——当算力成为最稀缺的资源，任何抽象层损耗都变得不可接受。
这个判断对AI行业尤其尖锐。英伟达H100的显存带宽是瓶颈，Transformer的注意力机制是内存密集型，两者的匹配程度直接决定训练效率。PyTorch的内存优化器、FlashAttention算法，本质上都是在硬件约束下重写软件逻辑。
Google TPU的脉动阵列设计，更是把"软件硬件协同"推到极致。矩阵乘法被拆解成特定的数据流模式，软件必须按硬件的节奏编排计算。这不是限制，是契约——遵守契约才能拿到性能。
Bailey的经历揭示了一个被忽视的真相：软件工程师的"硬件无关"自豪感，往往是性能债务的伪装。早期EDA工具能在一天内移植，不是因为抽象层做得好，而是因为代码对硬件的假设足够清晰、足够可预测。
现代云原生架构的反例是Kubernetes。它实现了真正的硬件无关——同一套配置跑在任何云上。代价是15-30%的性能损耗，以及复杂的调参迷宫。多数团队选择接受，因为"弹性"比"效率"更优先。但当AI训练账单按月结算时，这个等式正在改写。
缓存设计、内存对齐、数据局部性，这些"底层"细节在BCPL时代是必修课，如今被高级语言隐藏。隐藏不等于消失——只是把优化责任推给了编译器、运行时、或最终付账的客户。
Bailey没有给出解决方案。他的文章更像一份证词：40年前在BCPL里手动对齐数据的年轻人，看着今天的软件膨胀，感到一种熟悉的荒谬。技术轮回，问题不变——只是账单数字后面多了几个零。
如果软件必须重新学会"看"硬件，开发者要补的课从哪里开始？
热门跟贴