2011-07-08 181 views
5

我知道ASM基本上是速度最快的,但它是什麼使得HLL比ASM更慢?抽象的意思是,例如在C++中,你有一個類,數據需要存儲在類中存儲的內容,它來自什麼,私有/公共訪問器和其他東西。當編譯這段代碼時,是否有實際的彙編代碼能夠找出有關該類的信息?就像CPython建立在C之上一樣,所以在運行時有比C更多的抽象和指令。我說的是真的嗎?我想我已經回答了我自己的問題,但我希望得到一個比我自己更有經驗的人的回答。爲什麼一些編程語言比其他編程語言更快?

編輯:據我所知,Python是解釋,但它不會比C慢,如果它被編譯?

回答

5

這是一個廣泛的問題。

就像ASM一樣,編譯語言也會被翻譯成機器指令(操作碼)(ASM也是一個抽象層)。一個好的編譯器實際上可能會超越平均ASM編碼器的結果,因爲它可以檢查大量代碼並應用大多數程序員無法手動執行的優化規則(對最佳執行等進行排序指令)。

在這方面,所有編譯語言都被創建爲「相等」。但是,有些人比其他人更平等。編譯代碼的性能如何基本取決於編譯器的性能,以及特定語言的性能。某些功能(如虛擬方法)會導致性能損失(上次檢查虛擬方法是使用函數指針表實現的,儘管我的知識可能在此處記錄)。

解釋性語言從根本上檢查程序執行時人類可讀的語言,實際上在程序運行時必須等同於編譯和執行階段。因此,他們幾乎總是比編制的對手慢一些。智能實現將逐步將部分代碼解釋爲執行(以避免解釋從未命中的分支),並緩存結果,以便給定部分代碼僅解釋一次。

還有一箇中間地帶,人類可讀語言被翻譯成僞代碼(有時稱爲P代碼或字節代碼)。這樣做的目的是讓代碼的緊湊表示能夠快速解釋,而且可以在許多操作系統上移植(您仍然需要一個程序來解釋每個平臺上的P代碼)。 Java屬於這一類。

+0

謝謝。是的,就像我在對paulsm4的評論中所說的那樣,語言可以是最複雜的語言,但如果它有一個好的編譯器,它仍然是最快的。這對我來說更有意義,所以再次感謝! – edaniels

2

其實,你的前提不一定是對的。

許多人會說優秀的編譯器可以勝過手工編譯的程序集。其他人可能會說像Java和.Net這樣的即時編譯器可以利用運行時啓發式方法,因此優於任何靜態編譯的代碼。

在編譯器和解釋器之間,我向你保證不是必然與高級語言和運行時效率之間的任何關聯 。 非常高級語言 可以產生非常有效代碼。

恕我直言...

+0

因此,真正歸結爲編譯器或解釋器如何選擇創建/優化實際機器代碼。如果它是一種編譯語言,這會讓我的觀點變得更慢,因爲編譯器(用C語言編寫)可能會採用類似於C編譯器中創建機器碼的步驟。 – edaniels

+0

很多人說這樣的話很容易。爲他們的索賠尋求客觀支持將會困難得多。 –

+0

你是否懶得谷歌,傑裏棺材?或者太討厭爲討論做出積極的貢獻? – paulsm4

1

作爲一個經驗法則,更抽象的(而且通常更方便程序員)的語言,越慢會。 C編譯器將生成彙編代碼,這就是爲什麼它是如此依賴於系統的原因。像Java這樣的語言在虛擬機中運行,這本身就是一個編譯好的程序。但是這種抽象概念會讓事情變得緩慢。

但這並不是說沒有例外。就像paulsm4所說的那樣,高級語言最終會比低級語言更高效,因爲他們可以利用各種模式(我不知道細節)。

+0

人們怎麼說現在JAVA不再比C++慢? –

1

當你談論語言的速度時,首先要問的是它是編譯還是解釋。 解釋型語言通常比編譯語言慢一到兩個數量級。

但這可能沒有關係。解釋型語言可能還有其他優點,你想要做什麼可能不需要盲目的速度 - 如果它有速度,你不會注意到。

例如,命令行shell語言全部被解釋(據我所知),這很好,因爲它們只是執行一個耗時的操作系統命令,接着是下一個。在命令之間切換的循環永遠不會被注意到。

即使在快速編譯語言中,只將一個庫調用緊接着另一個庫調用的程序,只需要在它們之間進行一些原始數據操作,從語言的速度中獲益不大,因爲所有時間都是正在地下室裏度過。

語言速度很重要的地方在那裏。 如果只編寫更高級別的代碼,編譯代碼的速度很小。 重要的是很多是如果你的代碼調用超過它真正需要的下級例程。 編譯器無法幫助你。 Here's an example of how to fix that kind of problem.