全世界只有我们是正确的，其他的全错了。我们(Erlang 程序员)找到了症结并正确的解决了问题，所有的其他人(非 Erlang 人)都找错了方向，解决了错误的问题。

全世界其他人想解决的问题是如何让现存的程序能并行执行。2004 年之前，摩尔定律一直有效。每年我们的程序执行都会变得更快，我们不需要成为一个优秀的程序员，我们不需要掌握更优化的算法就能让程序一年比一年更快。

芯片越来越大，时钟速度越来越快，程序运行速度越来越快，每年大概以 15% 幅度的性能提升。

到了 2004 年，这些现象终止了。芯片已经足够大，时钟的速率已经快到在一个时钟周期内时钟脉冲不能到达芯片的所有部分。电路设计开始改变。多核处理器出现。

从 2004 年开始，芯片的体积仍然在增大，但时钟的速率开始变小，每个芯片上的 CPU 数量开始增加。我们从每一个芯片只有一个超级处理器的时代进入到每个芯片有多个速度较慢、性能较弱的多核处理器时代。

由此开始，顺序执行的程序显得越来越慢，一年慢过一年，而并行执行的程序开始变得越来越快。

问题是，根本没有并行执行的程序，有也是极少。

而 Erlang 是一种具有并发特征的编程语言，所以 Erlang 程序本质上在具有并行能力的计算机上运行时要比其它程序都快的多。而唯一能阻挡它运行的更快的问题就是 Erlang 程序中可能存在一些必须顺序执行的瓶颈。

并行程序中有需要顺序执行的部分，这正应验了 Amdahl 定律。

假设你的程序中有 10% 是需要顺序执行的(其余部分可以并行)，可以并行的部分的执行时间可以压缩近似0——只要有足够的可以并行的处理器。但顺序执行部分的时间无法缩减。

如果程序中含有 10% 的需要顺序执行的代码，你的程序执行速度最高能提高 10 倍。其中1/10 的程序的速度永远无法提高，其它9/10 的程序的执行时间可以缩减至接近0。

所以，对于 Erlang 程序员来说，提高他们的程序的运行速度的技巧就是找出代码中需要顺序执行的部分。

而对于任何对于其他编写顺序执行程序的程序员来说，提高他们程序速度的方法是找出他们程序中可以并行执行的部分。

让串行程序自动并行化的征途铺满荆棘，无法走通。(并不完全是这样，在某些特殊环境中是可以实现的，但绝非易事)。

现在的数据中心了都排满了酷炫的新型计算机，某些顶级的配置里拥有多达 24 核。但它们的性能呢？这些酷炫的新机器能快 24 倍吗？

对某些程序来说是的，但对大多数程序来说不是。对大多数程序来说 24 个 CPU 中只有一个被利用。CPU 的低利用率成了一个严重的问题。这点正印证了 Alexander Gounares

Brilliant 在 Erlang factory 谈到的问题。

Alexander 的演讲让我们隐约看到了未来。他开创 concurix 让我们看到了未来的方向。他们正在开发工具能自动找出 Erlang 代码中需要顺序执行的瓶颈。

Concurix 使用这些工具来发现 Erlang 虚拟机中的瓶颈，在他们的测试中显示了惊人的结果。他们找到了一个图片处理应用中的瓶颈，它是 zlib 库中的一个程序锁，是用C写成的。他们用 Erlang 重写了它，用 Erlang 替换了C代码。

这真是不可思议，C程序本应更快，事实也是，但它却有个同步锁。Erlang 程序相比之下要慢，但没有状态锁，这赋予了它提升能力的机会。去掉了C代码后，用 Erlang 写成的图片处理应用比原始的C程序快了很多。

我很吃惊——惊奇于这样的好东西的出现。

当 Alexander 在 Erlang factory 的演讲视频出来之后，你们观看时准备好惊奇吧。这是未来，未来就在下周旧金山。