Larry O’Brien 对关于多核处理器和适应它的语言一定能带来性能提升的假设提出质疑。
原理很简单。没有边际效应（side effect）的函数式编程基本上将自己交给了并行（译者注：意思是最适合并行的技术）。比较有意思的是 Map 函数，在 Map 里函数被应用到数组里的每一个元素。
一些乐观人士看到这儿的时候，说“哈哈，编译器可以轻松地将那些计算分发到一个线程池，在一个有多核的机器上会有性能优势。”确实如此，如果函数非常长或者数组非常大的话。否则，通过多核 / 多处理器分发计算的开销会比在一个核里执行 Map 要大的多。最糟糕的情况是，当函数和数据已经在原核的缓存中时，分发它的性能会非常低效。
从历史上来比较说明，Larry 提到 C/C++ 的内联关键字（inline keyword）。他说在大多数情况下，内联关键字是一个灾难。“绝大多数开发人员在考虑内联关键字给他们带来的好处时，做的很糟糕。因为，仅作为分发用时，Map 会是反生产力的，内联的代码会降低效率（现代处理器的芯片缓存使得代码的大小和位置对性能而言是非常重要的）”
- 那些声称每一个调用都会被分发的语言，它们有足够的能力去克服并行带来的性能问题吗？
- 在并行发生的时候，程序员所要使用的语言在主流程序员的手中会像内联一样，成为一场灾难吗？
- 会有一个混合的方法同时解决这两个问题吗？
公众号推荐：
跳进 AI 的奇妙世界，一起探索未来工作的新风貌！想要深入了解 AI 如何成为产业创新的新引擎？好奇哪些城市正成为 AI 人才的新磁场？《中国生成式 AI 开发者洞察 2024》由 InfoQ 研究中心精心打造，为你深度解锁生成式 AI 领域的最新开发者动态。无论你是资深研发者，还是对生成式 AI 充满好奇的新手，这份报告都是你不可错过的知识宝典。欢迎大家扫码关注「AI前线」公众号，回复「开发者洞察」领取。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
大淘宝中后台无代码页面生产新模式
中间件演进和稳定性治理实践
字节跳动DataOps落地实践和思考
评论