• 硬件架构的命令式本质
  现代CPU基于冯·诺依曼架构，核心是指令流驱动的状态修改——寄存器读写、内存地址访问、顺序执行（即使乱序执行也是硬件为模拟顺序语义做的优化）。函数式语言的等式模型、不可变性需要先被编译成符合硬件特性的命令式指令，这个转换过程本身就存在开销。比如递归的调用栈处理、不可变数据的复制或共享，都需要编译器做额外的映射工作；而C这类语言的语法和抽象本身就贴近硬件操作，开发者写的代码几乎可以直接对应机器指令，编译器的转换成本极低。

• 函数式核心特性的隐性开销
  不可变性、引用透明性这些特性虽然给编译器优化提供了理论基础，但也带来了实际的性能成本：

  • 不可变性意味着数据修改必须创建新实例，即使编译器能做复制消除优化，也无法覆盖所有场景。比如Haskell的惰性单向链表，缓存命中率远低于C的连续数组，这种数据结构的本质差异不是编译器能完全弥补的。
  • 高阶函数、闭包的使用会引入额外的间接调用或环境捕获开销，编译器需要识别并展开这些抽象才能达到命令式代码的效率，但这个过程并不总能完美完成。
  • 惰性求值会导致计算延迟，可能引发不必要的内存分配或计算顺序混乱，增加编译器优化的复杂度。

• 编译器优化的成熟度差距
  C/C++的编译器（GCC、Clang）经过数十年的发展，积累了海量针对硬件的优化pass：循环展开、自动向量化、寄存器分配、内存布局优化、分支预测优化等，这些优化的针对性和成熟度远高于多数函数式语言的编译器。比如GHC（Haskell编译器）虽然也有先进的优化，但在底层硬件适配、循环优化的精细度上，还是无法和GCC/Clang相比。

• 内存模型与管理的差异
  函数式语言通常依赖GC管理内存，即使是无GC的函数式语言，内存分配模式也以大量小对象为主，这会带来分配/回收的开销。而C/Rust允许开发者精确控制内存布局：用栈分配替代堆分配、手动调整内存对齐、直接操作指针，这些操作能最大化缓存命中率和内存使用效率，而函数式语言的抽象层通常屏蔽了这些细节，编译器很难自动做出同样精准的内存优化。

• 开发者的控制粒度差异
  在C/Rust中，开发者可以直接干预底层细节：手动编写SIMD指令、调整循环顺序优化缓存、指定寄存器使用、自定义内存布局。这些细粒度的优化是编译器自动优化很难覆盖的——比如针对特定硬件的循环展开次数、手动调整的数据预取策略，都能带来显著的性能提升，而函数式语言的抽象层限制了这种直接控制的可能性。

内容的提问来源于stack exchange，提问作者Ambiguous Illumination