2010-04-09 69 views
4

我知道這個問題的「銷售推銷」答案是肯定的,但它在技術上是否屬實。公共語言運行時(CLR)被設計爲基於命令式編程(IP)的中間語言,但是在處理聲明式編程(DP)時,這具有明顯的含義。.net中是否使用了所有語言?同等表示?

那麼,在CLR中實現時,基於不同於範式的語言的語言的效率如何?

我也感覺到DP的步驟會產生額外的抽象層次,可能無法模擬所有表現,這是否是一個公平的評論?

我已經使用F#做了一些簡單的測試,並且它看起來都很棒,但是如果程序變得更復雜,我是否錯過了一些東西?

+0

我還沒有看到任何宣傳材料聲稱。不同的編譯器產生不同的代碼。 – 2010-04-09 09:52:20

+1

重複? http://stackoverflow.com/questions/144227/c-f-performance-comparison – 2010-04-09 10:51:51

回答

2

在一天結束的時候,所有編程語言編譯成他們正在運行的CPU的本機代碼,所以同樣的問題可以在所有(不只是那些編譯問任何語言到MSIL)。

對於基本上只是對方的語法變體的語言(例如C#和VB.NET),我不會指望有太大的區別。但是,如果語言太分歧(例如C#與F#),那麼你不能真正進行有效的比較,因爲無論如何你都不能真正寫出兩個「等價的」代碼示例。

+0

我想你已經做了一個關於「比較」等效代碼的好處。它是我現在的問題。我可以做簡單的測試來查看輸出並完成它,但複雜的代碼要複雜得多。到目前爲止F#看起來不錯。 – WeNeedAnswers 2010-04-09 09:32:11

8

不能保證語言爲等效代碼生成相同的IL,所以我可以放心地說,並不能保證所有的.NET語言都具有同樣的性能。

但是,如果它們產生相同的IL輸出,那就沒有區別。

+0

但這裏存在真正的問題。如果一種語言的設計與CLR的基礎結構一致,並且同構地映射這些結構,那麼它對於高性能應用程序來說是一個更好的選擇。但是這對於使用聲明設計的語言有嚴重的影響。我不希望有相同的代碼,但是如果所有的語言都是CLR的「頭等公民」,那麼我會期望它的表現是平等的。 – WeNeedAnswers 2010-04-09 09:42:57

+0

一種語言可以是純粹的功能,並且仍然可以在設計底層機器結構時進行設計。對同構沒有要求。它只需要一個更智能的編譯器。參見[在Haskell中的流式融合後的帖子](http://donsbot.wordpress.com/2010/02/26/fusion-makes-functional-programming-fun/)。當然,智能編譯器很難編寫,所以通常的做法是提供語言中的低級構造和高級構造,然後通過改變高到低來優化慢程序。 – 2010-04-09 13:07:51

+0

不錯的鏈接Nathan,喜歡它。你可以看到它和CLR一起工作,或者CLR只是一個抽象層,太高而不能實現這種聰明的思維。 – WeNeedAnswers 2010-04-09 13:33:34

0

該語言可以被認爲是IL代碼的「前端」,因此語言之間唯一的區別是編譯器是否會生成相同的IL代碼或更少/更有效的代碼。

從我在網上閱讀的大部分內容看來,儘管我沒有看到任何顯示主要語言C#/ C++之間顯着區別的東西,但託管C++編譯器在優化IL代碼方面做得最好/VB.NET。

你甚至可以嘗試將以下內容編譯爲IL並查看!?

F#

#light 
open System 
printfn "Hello, World!\n" 
Console.ReadKey(true) 

C#

// Hello1.cs 
public class Hello1 
{ 
    public static void Main() 
    { 
     System.Console.WriteLine("Hello, World!"); 
     System.Console.ReadKey(true); 
    } 
} 
+0

使用VB,C#或C++使用相同的基本構造,我期望生成的代碼是相同的,因爲它們都非常相似(也許VB有一些深奧的東西,取決於它開發的模式)。但作爲@codeka在他的帖子中提到的F​​#很難進行比較。 – WeNeedAnswers 2010-04-09 09:36:12

+0

同意,F#解釋的方式使得幾乎不可能寫任何東西*,但是*一個非常簡單的測試,就像上面的測試一樣。儘管如此,查看爲每個代碼生成的IL代碼是相當有趣的。 – Siyfion 2010-04-09 09:43:03

7

首先,廣泛的語言在.NET平臺肯定含有生成具有不同性能的代碼語言,所以不是所有的語言都同樣高性能。它們都編譯爲相同的中間語言(IL),但生成的代碼可能不同,某些語言可能依賴於反射或動態語言運行時(DLR)等。

但是,BCL(以及其他由語言使用的庫)將具有相同的性能,而不管您稱之爲什麼語言 - 這意味着如果您使用某個庫進行昂貴的計算或渲染而無需自己進行復雜的計算,那麼使用哪種語言並不重要用它來調用它。

我認爲思考問題的最好方法不是思考語言,而是思考這些語言提供的不同功能和編程風格。下面列出其中一些:

  • 不安全的代碼:您可以在C++/CLI和某些時候也是用C#中使用不安全的代碼。這可能是編寫某些操作的最有效方式,但是您會失去一些安全保證。

  • 靜態類型,命令式:這是C#和VB.Net中編程的常用風格,但您也可以使用F#中的命令式風格。值得注意的是,許多尾遞歸函數被編譯成靜態類型,勢在必行IL代碼,所以這也適用於一些F#的功能

  • 靜態類型,功能:這是使用最F#程序。生成的代碼與命令類別使用的代碼大不相同,但它仍然是靜態類型的,因此沒有顯着的性能損失。比較命令功能有點困難,因爲最佳實現看起來在兩個版本中都有很大不同。

  • 動態類型:像IronPython和IronRuby的語言使用動態語言運行時,其實現動態方法調用等,這是多少有些慢於靜態類型的代碼(但DLR以多種方式優化)。請注意,使用C#4.0 dynamic編寫的代碼也屬於此類別。

有可能不屬於任何這些種類排列的許多其他語言,但我認爲,上述名單涵蓋了大部分的常見的情況(絕對涵蓋所有微軟的語言)。

+0

在開發針對它的語言時,必須考慮底層架構。看看cPython與GIL有關的問題,都是因爲使用C而產生的。那些1960年代的Lispers和他們的lisp機器正在開展一些工作:) – WeNeedAnswers 2010-04-09 13:54:41

4

我敢肯定,有一些情況下,用一種.NET語言編寫的慣用代碼的性能稍高於另一種。然而,退後一步,爲什麼這很重要?你有沒有一個性能目標?即使在單一語言中,通常也有可能影響性能的選擇,並且有時需要根據可維護性或開發時間來交換性能。如果您沒有達到可接受性能目標的目標,那麼就不可能評估語言之間的任何性能差異是否有意義或可忽略不計。另外,編譯器也在不斷髮展,所以今天相對性能的真實情況不一定會持續下去。 JIT編譯器也在不斷髮展。即使處理器設計是可變的和不斷髮展的,所以相同JITTed本機代碼可以在具有不同緩存層次結構,管線尺寸,分支預測等的處理器之間執行不同的操作。

說了這麼多,可能有幾條寬泛的規則很大程度上成立:

  1. 算法的不同可能會做出比編譯器的差異較大的差異(至少在比較的CLR運行靜態類型語言)
  2. 對於能夠很容易地被並行化的問題,語言這使很容易利用多個處理器/內核將提供一種簡單的方法來加速你的速度你的代碼。
相關問題