通用語言執行平台(CLR)

.NET   Framework的核心是其運行時的執行環境，稱為通用語言執行平台(CLR) (common language runtim)  或  .NET運行時。在CLR的控制下啟動並執行代碼常常稱為Managed 程式碼。  
  但是，在CLR執行開發的原始碼之前，需要編譯它們(在C#中或其他語言中)。在.NET中，編譯分為兩個階段：  
  (1)   把原始碼編譯為Microsoft中繼語言(IL)。  
  (2)   CLR把IL編譯為平台專用的代碼。  
  這種兩階段的編譯過程非常重要，因為Microsoft中繼語言(Managed 程式碼)是提供.NET的許多優點的關鍵。下面看看其原因。  
  1.   平台無關性  
  首先，這意味著包含位元組代碼指令的同一檔案可以放在任一平台中，運行時編譯過程的最後階段可以很容易完成，這樣代碼就可以運行在該特定的平台上。換言之，編譯為中繼語言就可以獲得.NET平台無關性，這與編譯為Java位元組代碼就會得到Java平台無關性是一樣的。  
  注意.NET的平台無關性目前只是一種可能，目前.NET只能用於Windows平台，但人們正在積極準備，使它可以用於其他平台(參見Mono項目，它用於建立.NET的開放源執行方式，參見http://www.go-mono.com/)。  
  2.   提高效能  
  前面比較了Java，IL實際上比Java位元組代碼的野心還要大。IL總是即時編譯的(稱為JIT編譯)，而Java位元組代碼常常是解釋性的，Java的一個缺點是在運行應用程式時，把Java位元組代碼轉換為內部可執行代碼的過程會導致效能的損失。  JIT編譯器並不是把整個應用程式一次編譯完(這樣會有很長的啟動時間)，而是只編譯它調用的那部分代碼(這是其名稱由來)。代碼編譯過一次後，得到的內部可執行代碼就儲存起來，直到退出該應用程式為止，這樣在下次運行這部分代碼時，就不需要重新編譯了。Microsoft認為這個過程要比一開始就編譯整個應用程式代碼的效率高得多，因為任何應用程式的大部分代碼實際上並不是在每次運行過程中都執行。使用JIT編譯器，這種代碼從來都不會編譯。  
  這解釋了為什麼託管IL代碼的執行幾乎和內部機器代碼的執行速度一樣快，但是並沒有說明為什麼Microsoft認為這會提高效能。其原因是編譯過程的最後一部分是在運行時進行的，JIT編譯器確切地知道程式運行在什麼類型的處理器上，利用該處理器提供的任何特性或特定的機器代碼指令來最佳化最後的可執行代碼。  
  傳統的編譯器會最佳化代碼，但它們的最佳化過程是獨立於代碼所啟動並執行特定處理器的。這是因為傳統的編譯器是在發布軟體之前編譯為內部機器可執行檔代碼。即編譯器不知道代碼所啟動並執行處理器類型，例如該處理器是x86相容處理器或Alpha處理器，這超出了基本操作的範圍。例如Visual   Studio   6最佳化了一台一般的Pentium機器，所以它產生的程式碼就不能利用Pentium   III處理器的硬體特性。相反，JIT編譯器不僅可以進行Visual   Studio   6所能完成的最佳化工作，還可以最佳化代碼所啟動並執行特定處理器。