Re: [問題] 為什麼作業系統都用C寫? 而不用C++呢?

看板C_and_CPP (C/C++)作者 (火辣辣的大姊姊)時間16年前 (2009/03/08 03:09), 編輯推噓6(718)
留言16則, 5人參與, 最新討論串23/37 (看更多)
※ 引述《ledia (下班後才下棋)》之銘言: : ※ 引述《guest0079 (火辣辣的大姊姊)》之銘言: : : 1.效能也許會較差(這一點兩位y兄爭了很久): : :  說真的,我完全不能證明C++比C效能還差,甚至我可以證明,C效能永遠不比C++好 : :  證明如下: : :  若set_Y為C中效能優於C++的子集合,已知C++為C的超集,set_Y必然也是C++的子集 : :  set_Y at C > set_Y at C++,固set_Y為空集合 : :  總之,C做得到的C++也做得到,C++的效能沒理由較差 : C 和 C++ 誰比較好這個問題對我來說太沉重 : 畢竟我完全不懂 C++ : 不過你的證明.... 應該只是緩和氣氛的吧 ? : 因為 C++ 就算是 C 的超集 : 他們的 compiler 不是同一個 : C 做得到的 C++ 也做得到也許是對的 : 但是你也得先證明一下 C++ 是用不壞於 C 的效率去做的呀 : 不然怎麼能說 C++ 的效能沒理由較差呢 ? → xam:證明1就證錯方向了..沒抓到重點.. end 03/07 02:40 推 zerodevil:『一個人沒料的時候... (下略)』 03/07 02:44 看完你的文章,我就知道為上面兩位版友為什麼會有此反應了 以下針對效能這點再作說明(好啦,我知道場子已經冷了) 在我所發的文中,強調的是語言本身的特性,而不是編譯器的好壞。效能、易讀性、物件 導向、複雜度,四點內容所講的全是"語言本身"。問題出在於:"語言本身"所代表的效 能涵意是什麼?"程式碼的效能"事實上是與平台密切相關的,但是語言本身又與平台無 關。所以語言本身與實際測到的效能是完完全全的兩回事。比較C與Java兩種語言,哪種寫 出來的程式效能會比較好?答案是:視執行平台而定。(說這句一定有人想轉joke了) 在一般的處理器上(x86, 8051, ARM, xxx單晶片),絕對是用C寫的程式的效能較高 只要系統的RAM夠大,再把用C寫的JVM porting到某平台上,就能跑JAVA程式,但是效能 一定很差。但是,如果SUM出了一顆新CPU,是一顆JVM硬体處理器,也就把本來是軟体的 JVM用硬体來實作,則Java程式在該顆CPU上會擁有絕佳的效能,同時,這時候想在上面 跑C也不是不可能,只要寫得出compiler就行了。此時,用C程式在這顆CPU上跑的程式八 成會遠較Java程式慢 (N年前就聽說SUM要出這種Java專用的CPU,不知出了沒有,我想這 有一定的難度) 我舉這個例子,就是想說明如果要比較程式碼的效能,就一定要指定特定的編譯器與執 行平台才有意義 但是我從頭到尾所講的就不是"程式碼的效能",而是"語言本身特性所造就出來的效能差 異"。C、C++語言當初在設計,從一開始就定位在source code層級與平台無關的語言, "語言本身"與平台無關,也與編譯器無關,同樣的code可以用不同compiler編譯,也能 run在不同平台上。以上講的都是淺而易見的道理,會上這個版的人都明白 但是為什麼大家扯到效能的時候都隱含地把編譯器的因素考慮進去了? 如果把編譯器的因素考慮進去,就不必浪費時間討論了。今天我用code size最佳化的 compiler去編C,跟你用效率最佳化的C++ compiler去比較C與C++的效能有意義嗎? 另外,又假設C/C++兩者都用效能最佳化的原則編譯,來比較效能,就如同某版友所說 的: 推 buganini:呃 要怪就全部怪在compiler頭上就好了 所有的程式語言 03/07 13:36 → buganini:都是turing equivalent 極限最佳化結果應該都一樣 03/07 13:37 → buganini:所以都是compiler不好 *flee* 03/07 13:37 也就是說,若真的做到最佳化,根本都一樣快啊,這樣比也是沒意義 說到底,要比較C/C++效能,就我個人初淺的認知是"只能從語言的特性"去比較 假設某人設計出一種程式語言,他只定義一種資料型態 double 語言規定任何資料都以IEEE754的格式存於電腦中,所有資料都當成double來做運算 想必用這種程式語言來設計OS會有極大的困難,就算設計出一套程式,想必也是慢到不行 造成效能不張的原因最主要還是跟語言特性有很大的關係 另一個語言特性造成效能不張的例子就是Java。Java慢的原因大家都知道(JVM嘛), Java慢不是編譯器太差,而是當初就是以binary code層級跨平台為目標,再加上安全性 、gc等重重考量來設計這種語言,有VM的語言慢也是正常的 總結上面三段:我們說一個語言的效能好或壞,只看它編譯後的程式執行起來的速度是 不夠的。真正比較全面的評斷方法是:看語言特性(是不是能讓人編譯出有效率的程式、 是不是能設計出夠好的編譯器…,量測程式執行速度只是其中一個環結) 再回到C/C++的討論,我提的證明與針對C++的效能評論就是針對"語言特性"而來 : a. C++太多太雜太難掌握,讓程式人員浪費太多時間在語言本身而非問題的最佳解上 : b. C++會偷偷增加一些程式碼來維持本身的OO特性,一不小心就多出了不必要的code : c. C++會偷偷增加一些程式碼來維持運算子過載特性,一不小心就多出了不必要的 code : d. 用C++物件導向實作的函式庫,很方便使用沒錯,但代價就是負擔太大(如Qt) 請不要再提什麼compiler了,用gcc/g++編譯,效能根本沒太大差異 對於xam版友所說的: → xam:證明1就證錯方向了..沒抓到重點.. end 請問你說的重點是不是在於compiler?是不是在於library的實作? 如果是的話,你說的重點就我看來根本不是重點 什麼是語言,什麼是程式,先搞清楚,再來討論C/C++的效能才有意義 如果有人覺得我的論點是錯的,也請提出來討論 算了啦,散場了啦 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.136.212.64

03/08 03:16, , 1F
C的語法比C++單純很多,所有合法的C都很容易算出overhead
03/08 03:16, 1F

03/08 03:18, , 2F
,目前的OS kernel也沒複雜到用C會造成實作上的困難,尤其
03/08 03:18, 2F

03/08 03:19, , 3F
在user-kernel之間溝通時,也沒辦法直接用OO的界面,那到
03/08 03:19, 3F

03/08 03:20, , 4F
底為什麼要用C++來寫OS? 其實大家討論這麼多,為什麼不弄
03/08 03:20, 4F

03/08 03:22, , 5F
個小project,直接用C++寫個小kernel,用太多想像和理論來
03/08 03:22, 5F

03/08 03:23, , 6F
評斷一個軟體專案的實務問題,永遠會輕忽很多的小細節.
03/08 03:23, 6F

03/08 03:43, , 7F
問題是你對這個語言根本不了解也能講這麼多,真是不簡單
03/08 03:43, 7F

03/08 03:50, , 8F
我只是亂喇賽 怎麼也中槍XD
03/08 03:50, 8F

03/08 03:50, , 9F
沒辦法啊 一直都引不出真正有經驗的高手來討論
03/08 03:50, 9F

03/08 03:53, , 10F
那我在喇賽一個問題好了 寫一個C++ compiler 你要用
03/08 03:53, 10F

03/08 03:53, , 11F
C還是C++寫? (再次逃跑)
03/08 03:53, 11F

03/08 03:57, , 12F
tinlans 等級高到你根本看不懂, 還說沒高手, 真是有眼無珠
03/08 03:57, 12F

03/08 04:43, , 13F
所以 散場吧
03/08 04:43, 13F

03/08 04:45, , 14F
說到大神兩個字 我會想到兩個人DarkKiller和tinlans
03/08 04:45, 14F

03/08 04:49, , 15F
Master 也是阿.. 不過大神他很少降臨了
03/08 04:49, 15F

03/08 09:55, , 16F
「不討論編譯器好壞」這句就看得出來完全外行
03/08 09:55, 16F
文章代碼(AID): #19iiQ0kH (C_and_CPP)
討論串 (同標題文章)
文章代碼(AID): #19iiQ0kH (C_and_CPP)