全世界只有我們是正確的，其他的全錯了。我們(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的演講視訊出來之後，你們觀看時準備好驚奇吧。這是未來，未來就在下週舊金山。