如下觀點有點偏激,但不失爲一篇好文章程序員
全世界只有咱們是正確的,其餘的全錯了。咱們(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的演講視頻出來以後,大家觀看時準備好驚奇吧。這是將來,將來就在下週舊金山。