本文關鍵詞：C程序性能優(yōu)化：20個實驗與達人技巧，由筆耕文化傳播整理發(fā)布。

> c語言 > C程序性能優(yōu)化：20個實驗與達人技巧 序 2013-01-08 13:31:17         我要投稿   

本文所屬圖書 > C程序性能優(yōu)化：20個實驗與達人技巧

本書作者精通C程序性能優(yōu)化，具有近二十年的C語言編譯器和解釋器開發(fā)經驗，還為實時圖像處理專用芯片開發(fā)過C編譯器。作者從CPU與編譯器的運行機制講起，帶領讀者一步步了解程序的執(zhí)行成本、編譯器的優(yōu)化選項等，...  立即去當當網訂購

達人是按什么標準來對程序進行調優(yōu)的呢？如果有規(guī)律可循固然好，但達人的調優(yōu)方法都來源于日常積累起來的經驗和知識，所以沒有這方面經驗和知識的人是很難掌握的。
人在接觸陌生的事物時，為了能理解這個事物，一般都會結合以前的經驗和知識來進行類推。對沒有經驗的人來說，那些連類推也無法讀懂的信息，就如同魔法一般。

在本書中，筆者將會與大家一起，分享他根據自己多年的經驗和知識摸索出來的調優(yōu)方法，但具體如何調優(yōu)則因人而異。接下來請出另外一位對本書有諸多貢獻的松岡先生。

大家好，我是松岡。下面我們來聽聽片山老師的見解。但在此之前，由于我和片山老師解決問題的方向不同，所以我覺得有必要先聊聊彼此的研究領域，或者說是解決問題的前提吧。首先請片山老師先來介紹。

大家好，，我是片山。我呢，主要擅長Linux環(huán)境中的文本處理。在開發(fā)環(huán)境下經常喜歡打開幾個vi，只要顯示屏夠大就可以了。如何將事物精簡是USP研究所的基本理念。所使用的語言以C語言為主，不使用C++。

我主要在Windows環(huán)境下進行開發(fā)工作，使用C++、C#、Java等面向對象語言，因此在VisualStudio和Eclipse等集成開發(fā)環(huán)境下進行編程。所涉及的領域主要在圖像方面，擅長對圖像進行高效處理。

看來，我們彼此所擅長的開發(fā)環(huán)境和研究領域不一樣。我呢，打算站在讀者的角度就可能出現的疑問來與片山老師討教討教。

剛才不是說想聽我的見解嗎？怎么現在變成向我提問了？有點不祥的預感啊。

就當作是提問吧，不然讓你一個人拉鋸怎么行呢？這樣你一言我一語也挺好的。

所以嘛，通常的提問方式是我說完“這里要這樣做”，然后你就問：“為什么要這樣做呢？講解一下可以嗎？”是這樣嗎？

主要是因為這本書是從一個專家的角度來看高效編程的，而讀者并不是專家呀。不是有個詞叫“通常情況”嘛，這個“通常”靠的是平時積累起來的經驗和知識，所以對那些沒有這方面經驗和知識的人來說，簡直就像是克拉克的第三法則：超越理解范圍，感覺像是魔法一樣無法理解。

那我是魔法師？

有個詞叫做“天才”，或者說是“宗師”。

性能優(yōu)化是一種技術而非魔法。

在普通人看來，專家就像是魔法師，像是宗師。我呢，學習武術大概有20多年了，在武術界，段位只要相差兩個級別，級別低的人就完全無法理解級別高的人了。能理解比自己高兩個段位的技術理論的人是非常少見的。

這大概是由經驗和知識決定的吧。

是的。系統化的經驗和知識就像武術中的套路，這個套路不是靠看就能悟透的。而且為了保證自家套路不被其他套路抄襲，各家也想了很多辦法。這樣一來，即使被其他流派模仿了，也模仿不到其中的精髓。所謂精髓是指心法，是武術不被抄襲的關鍵所在。

哦……心法呀……

是的。所以即使是被其他流派的人抄襲過去了，然后研究其中的技術理論，以為能找到破解的方法，但實際上他們看到的都只是假象，他們破解的招數也根本不起作用。想想武術可是日本戰(zhàn)國時期的產物啊，那是性命攸關的事……

的確是這樣！

所以，門生看到老師的動作，心想“老師那樣做，我這樣做就能打敗他”，卻一下子就被老師踢飛了。他不知道，原來老師早就把他的心思看得一清二楚啦。

很有趣呢，將經驗系統化。

回到我們剛才說的話題上來，其實這個經驗系統化與編程也是有關聯的。在編程的領域里，經驗和知識也是在通過各種方法逐步系統化，而面向對象的設計模式就是其中一種。

也許如此。但我的確不贊同使用類。我的立場是：即使不使用某種架構也能得到更為精簡的程序。

而我則是在非常積極地使用面向對象。但與片山老師剛好相反，我不用設計模式。不過，即使不用也能做出點事情。

“也能做出點事情”？那就表示這能做的事兒也是以經驗和知識作后盾的啰？

大概是這樣的吧。起初看到設計模式的時候就有種意料之中的感覺。我用類來組裝成部件，與設計模式結合起來，發(fā)現可以通過生成差分法編程來追加功能，所以我認為是能做點什么的。

我并不喜歡用C++的類來創(chuàng)建實例的指針。那樣會產生很多看不見的成本，如果無法估計程序所需成本，那要進行高效編程是比較困難的。

的確，在看不見的地方消耗成本會很不舒服。聽說在某些項目中，將實例應用到方法時，復制構造函數會帶來很大的開銷。單復制這一個動作就會變得十分緩慢，以至于不能回復到原態(tài)。

是啊，如果不了解處理系統在做些什么，就不能理解其中哪些部分產生了運行開銷。更可怕的是不了解這些情況的人還會因此廢棄實例，從而造成回收垃圾（garbage
collection）的開銷。

但即使是使用虛擬機的Java和C#，內存管理與垃圾回收對程序員來說也都是不可見的吧。

我認為還是對內存的碎片等多留點心會比較好。

關于這一部分內容，大家可以去看Ruby之父松本先生的書[1]，相當有趣。話說片山先生曾經開發(fā)過編譯器吧？

是的。對于編譯器如何分配CPU寄存器等我比較熟悉。在用C語言進行編程時，對編譯器的使用也是相當小心的。

那也就是說，C語言是最能直接分配CPU資源的語言了。除了匯編以外。

C語言似乎更像是匯編的語法糖。

以前，C編譯器還沒有怎么優(yōu)化過，我們在使用的時候都是一邊想象著編譯器會生成什么樣的代碼一邊編程，也是一邊編程一邊誘導編譯器：“生成這樣的代碼吧。”

這樣的話，在高效編程時就必須掌握處理系統的相關知識。

片山老師使用什么樣的編譯器呢？

我主要是用GNUC（GCC）。根據工作的需要有時也會用其他編譯器，但還是以GCC為主。
那關于GCC生成代碼的各種偏好你都了解吧？

那是必須的。

我主要是用微軟的編譯器，偶爾也用英特爾的。英特爾的編譯器只有在使用英特爾品牌CPU時才能達到非常棒的優(yōu)化效果，猶如手工匯編。

那是當然的。因為它們非常了解CPU內部的運作嘛。

就好像是在優(yōu)化的時候，一邊計算著CPU的內部成本一邊生成代碼似的。

使用GCC不會優(yōu)化到那種地步。如果對特定的CPU進行了優(yōu)化的話，就會偏離GCC的初衷——應對各種各樣的CPU。

在序中，兩位專家都闡述了各自的立場，在后面的內容中也會以對話的形式呈現兩位不同的觀點。

[1]即《松本行弘的程序世界》（松本行弘著人民郵電出版社ISBN:978-7-115-25507-5）。原書名為《まつもとゆきひろコードの世界~スーパー·プログラマになる14の思考法》。

點擊復制鏈接 與好友分享!回本站首頁 您對本文章有什么意見或著疑問嗎？請到論壇討論您的關注和建議是我們前行的參考和動力   上一篇：C程序性能優(yōu)化：20個實驗與達人技巧 下一篇：目錄 相關文章

序

推薦者序

1.1.2 并行程序設計和多核程序設計

1.3.5 程序運行環(huán)境

2.1 程序的基本編寫格式

譯者序

推薦序一

推薦序二

C程序設計伴侶：幫你更好地理解譚浩強

1.1 計算機程序是什么 什么是計算

圖文推薦

  本文關鍵詞：C程序性能優(yōu)化：20個實驗與達人技巧，由筆耕文化傳播整理發(fā)布。

本文編號：54584