SSE Assembler vs Optimizied C++
打破匯編的神話?
匯編語言對于軟件工程人員來說，是高速精簡的代稱，但同時也是晦澀難懂的代名詞。學(xué)校的老師，各種各樣的書籍寶典，總是舉出各種各樣的例子來向我們灌輸著這樣一個定律：C++編譯后產(chǎn)生的代碼在執(zhí)行效率上不如匯編編譯成機(jī)器代碼。但是匯編代碼在編寫的時候晦澀難懂，使得開發(fā)效率大為降低。但是在那個CPU寄存器非常珍貴，內(nèi)存異樣稀少的時代，匯編相對C有著獨(dú)特的優(yōu)勢，可以極其精確的為每一個變量分配寄存器和內(nèi)存，但是同時也使得開發(fā)過程緩慢無比，因?yàn)橐徊涣羯窬蜁斐杉拇嫫鞣峙錄_突。同時由于那個時代的C++的編譯器的編譯效率不高，造成了編譯的時候產(chǎn)生的代碼無論在算法和體積上都無法和匯編相比。
最近在編寫引擎的時候，一直在匯編的執(zhí)行效率和C++的編寫效率上猶豫不覺。一開始試著編寫了2個不同版本的Vector類，叉積分別使用SSE匯編和C++優(yōu)化。然后我試著編譯了這兩個不同的版本，編譯的時候?qū)⑺袃?yōu)化選項(xiàng)全部打開，并最大化速度優(yōu)先。測試程序?qū)τ诿總€版本調(diào)用1億次叉積運(yùn)算，總共進(jìn)行了10次，最后的出的結(jié)果令人瞠目結(jié)舌。SSE匯編10次測試全部敗于C++，C++所用的時間只相當(dāng)于SSE的三分之一。
今天新編了一個四元數(shù)類，同樣在從四元數(shù)向矩陣的轉(zhuǎn)換中，使用了Intel網(wǎng)站上的Id Software的匯編代碼，和C++代碼。同樣進(jìn)行速度最大化優(yōu)化，1億次轉(zhuǎn)換測試，結(jié)果在預(yù)測之內(nèi)，差別雖然沒有向量測試的那么驚人，但C++仍然比匯編高效。
新一代編譯器都支持在編譯時打開SSE增強(qiáng)指令集，這意味著，包括Visual Studio在內(nèi)的C++編譯器，能夠在從C/C++到匯編代碼的過程中，自動盡可能的使用SSE增強(qiáng)指令集來提高匯編代碼效率。手寫SSE匯編，由于人員之間的水平差異，不可能將匯編代碼優(yōu)化到最高水準(zhǔn)，而編譯器使用了高效的算法來優(yōu)化產(chǎn)生的匯編代碼，這使得，一個資質(zhì)普通的程序員寫出的SSE代碼，會比由C++編譯器編譯出的匯編代碼要慢的多。當(dāng)然這個世界上總是有著驚人天賦的天才，一定能夠在同等條件下寫出比編譯器快得多的匯編代碼，但是這不具有普遍性，在軟件業(yè)高速發(fā)展的今天，通用性，易用性，費(fèi)效比，以及重用性才是軟件工程中最重要的，而花大錢雇一個匯編高手來寫核心意味著這個代碼具有最差的移植性，最差的可讀性，以及最差的重用性，這是不可取的。
我們應(yīng)該相信現(xiàn)代編譯器能夠在最短時間內(nèi)編譯出最優(yōu)代碼，而事實(shí)上，這個也已經(jīng)成為了既定的現(xiàn)實(shí)。拋棄手動的SSE匯編，讓編譯器來完成這項(xiàng)工作，是最明智的做法。當(dāng)然我們應(yīng)該在編寫C++代碼時稍微考慮一下數(shù)據(jù)流的生成順序，以便讓編譯器發(fā)揮出最大效能，至于如何優(yōu)化數(shù)據(jù)流，將在下一篇中介紹。
ps: 在Visual Studio.NET 2003下，將“啟用增強(qiáng)指令集”設(shè)置為SSE/SSE2即可。