Board logo

標題: [轉貼] Windows x64 運算環境的優點 [打印本頁]
作者: kayin    時間: 2007-6-7 12:35 AM     標題: Windows x64 運算環境的優點

發佈日期: 2007 年 5 月 16 日

作者： 賴榮樞
http://www.goodman-lai.idv.tw
自從超微在 2003 年推出第一顆 x64 處理器，x64 處理器至今已經是英特爾及超微最主要的 x86 處理器，不論是桌上型、筆記型、或伺服器等級的 x86 架構處理器，隨處可見內含 x64 技術的產品。雖然 x64 硬體架構早已經全面進入市場了，但依然處於萬事具備仍欠東風的階段；欠缺的是殺手級的 64 位元應用。


處理器有各種資料匯流排、位址匯流排、暫存器，這些的長度單位是位元，而且與處理器運作能力息息相關。而所謂的「64 位元」處理器，通常是指算術邏輯單元（Arithmetic and Logic Unit，ALU）暫存器或指令指標（instruction pointer，IP）暫存器的長度是 64 位元。
硬體廠商推出 x64 處理器的電腦早已不是新鮮事，事實上 x64 也不是第一款 64 位元處理器。遠早在 60 年代，IBM 所推出的超級電腦（IBM 7030 Stretch）就已經是 64 位元，90 年代的 RISC 處理器也有 64 位元的版本；例如 MIPS R4000、迪吉多 Alpha、昇陽 UltraSPARC、惠普 PA-RISC 等。英特爾雖然早在 1994 年就公佈了與惠普共同開發的 64 位元 IA-64 架構，但處理器 Itanium 是在 2001 年推出。若廣義的看待「個人化的電腦」（而非單指當年 IBM PC 傳承下來的「個人電腦」），用於蘋果 G5 的 PowerPC 處理器的推出時間（1997 年）也比 x64（2003 年）更早。


AMD64 與 EM64T


在 2003 年，超微根據其 AMD64 架構，推出了兩款 x86 平台的 64 位元處理器，分別是 Opteron 和 Athlon 64。在超微推出 AMD64 系列處理器之前，其他處理器廠商就已經推出過 64 位元的處理器，但是這些 64 位元處理器都是鎖定在伺服器或高階工作站等市場，而且使用的是異於 x86 的架構。例如 MIPS、迪吉多、昇陽、惠普、IBM 等廠商的 RISC 處理器，都有 64 位元的版本，而這些處理器大多用在高階的伺服器或工作站。
英特爾在 2001 年所推出的 Itanium，以及 2002 年的第二代 Itanium2 也是 64 位元處理器架構，而且微軟也曾經為 Itanium 和 Itanium2 推出過 64 位元的 Windows 作業系統，包括 Windows 2000 Workstation 和 Server 版本，以及 Windows XP Professional 和 Windows Server 2003。不過 Itanium 和 Itanium2 也是應用在高階的伺服器和工作站。
超微的 AMD64 系列處理器（簡稱 x86-64、x86_64 或 x64 處理器），雖然也是 64 位元的架構，但巧妙的是，AMD64 的架構是進化、而非革命。與前述其他 64 位元處理器最大的不同，是 AMD64 架構延伸了 x86 的 32 位元架構，因而保留了 x86 架構的相容性，因此除了可以直接執行 64 位元程式，也不用透過模擬器就能執行 x86 指令，這是 AMD64 能與現今絕大多數的 32 位元軟體保持優異相容性的關鍵。
而當超微開始銷售 x64 處理器，並且獲得市場接受之後，英特爾也決定要推出 x64 處理器。雖然名稱不同，但這兩家廠商的 x64 處理器是相容。英特爾 x64 專案代號是 Yamhill，但後來的正式名稱則用了好幾個名字，包括 IA-32e、EM64T（Extended Memory 64bit Technology）、Intel64。英特爾隨後將 x64 架構加入旗下 Pentium 4、Pentium D、Pentium Extreme Edition、Celeron D、Xeon，以及後續的 Core 2 雙核等系列處理器，因此這些處理器不僅都具備 x64 的 64 位元運算能力，也與 x86 相容（經常可以在英特爾文件見 IA-32e 或 Intel64 等名詞，這些都是 EM64T 的同義詞。IA 是 Intel Architecture 的縮寫，32 表示 32 位元，e 是 extension，也就是說這是以 32 位元延伸而成的架構。IA-32e 注定會是一個被換掉的名詞；用來稱呼 64 位元技術的名詞，裡面的數字竟然是 32，太容易混淆視聽了。另外，IA-32 是 32 位元 x86 架構，而 IA-64 則是 Itanium/Itanium2 架構）。


Windows x64 作業系統


光有硬體還不夠，軟體支援更是重要；雖然 x64 可以執行 32 位元作業系統及軟體，但要全面發揮 x64，還是需要 x64 版本的軟體。微軟在 2005 年推出了支援 x64 架構的 Windows 作業系統，分別是用戶端的 Windows XP Professional x64 Edition，以及伺服端的 Windows Server 2003 x64 Edition。雖然這兩個系統分屬不同的應用，但是它們都是以 Windows Server 2003 SP1 的原始碼為基礎（因此這兩款 Windows x64 作業系統實際上都具備了 SP1 的能力）。也因為支援了 x64 處理器，因此這兩個 Windows x64 作業系統自然都能存取到超過 4 GB 的實體記憶體。
就伺服端的應用而言，IA-64 版本的 Windows 主要是為了滿足大型資料庫與特定業務應用程式之客戶的需求；而 x64 版本的 Windows 則是針對廣泛用途的工作所設計。
Windows Server 2003 x64 Editions 是針對業界的 x64 架構所設計。能以高效能的方式同時執行 32 位元與 64 位元軟體，這項新平台可以延伸企業在 32 位元 Windows 的投資。x64 架構讓IT專業人員可以先執行 32 位元的 Windows，然後依照計劃移至 64 位元的 Windows。部署 x64 版本的 Windows 之後，可以在相同的系統上同時執行結合 32 位元與 64 位元的軟體；或者利用虛擬化的技術，在同一平台執行另一種版本的軟體。


更大的記憶體定址空間


x64 處理器最大的優點，是可以提供更大的記憶體定址空間。32 位元 x86 處理器最大的記憶體定址空間是 4 GB（2^32），對許多軟體這已經足夠，但是對某些必須處理相當大量資料的應用程式而言—尤其是伺服端的軟體，4 GB 卻是造成執行效能的瓶頸，因為當系統無法提供足夠的實體記憶體空間，就必須轉而使用通常是由硬碟空間提供的虛擬記憶體；存取硬碟的速度遠低於存取實體記憶體的速度。
4 GB 的記憶體上限對 32 位元處理器並非無解，但仍然有其限制。Physical Address Extensions（實體記憶體延伸，PAE）是內建於英特爾處理器的功能，這項功能可以讓應用程式存取 4 GB 以上的實體記憶體，但是這項功能需要作業系統的支援，目前 Windows Server 2003 Enterprise Edition、Windows Advanced Server, Limited Edition、Windows 2000 Datacenter Server、Windows 2000 Advanced Server、Windows XP SP2 及後續版本等 Windows 作業系統是利用 PAE 技術而突破 4 GB 的記憶體限制。此外，在設計 Windows 程式時，也必須利用 Windows 作業系統提供的 Address Windowing Extensions（AWE）功能，讓程式直接存取 4 GB 以上的記憶體（AWE 是 Windows 對 PAE 的實作）。x64 架構也以 NX 位元的方式支援 PAE。
PAE 和 AWE 是讓 32 位元系統突破 4 GB 記憶體上限的解決技巧，但這些額外的技巧會增加程式設計的困難度，而且因為 PAE 的分頁表還是得放在 4 GB 的記憶體空間，因此當 PAE 超過 16 GB 之後，執行效能也會降低。前述的 PAE 技術是為了讓 32 位元處理器能夠突破 4 GB 記憶體限制的權宜之計，真正的 64 位元處理器才是解決這項問題根本之道。
x64 架構可以讓直接存取的虛擬記憶體數量從 4 GB 變成 16 TB，使用者模式的行程和核心模式行程能平均使用這 16 TB 空間，原生的 x64 程式則擁有 8 TB 的虛擬記憶體定址能力。而 x64 架構也讓核心模式的驅動程式不需要透過 PAE，就能存取 4 GB 以上的實體記憶體（實際上將能存取所有的實體記憶體）。以下表格整理了 32 位元 Windows 以及 Windows x64 的記憶體存取與處理器數量的上限。

一般的記憶體限制32 位元 WindowsWindows x64
虛擬位址空間總數（以單一行程為基礎）4 GB16 TB
每個 32 位元行程的虛擬位址空間2 GB（若以 /3 GB 選項開機，可達 3 GB）若以 /LARGEADDRESSAWARE 選項編譯可達 4 GB，否則為 2 GB
每個 64 位元行程的虛擬位址空間N/A8 TB
分頁集區470 MB128 GB
非分頁集區256 MB128 GB
System Page Table Entry (PTE)660 MB 到 900 MB128 GB
實體記憶體上限32 位元 WindowsWindows x64
Windows XP Professional4 GB128 GB
Windows Server 2003 標準版4 GB32 GB
Windows Server 2003 企業版64 GB1 TB
Windows Server 2003 Datacenter Edition64 GB1 TB

不過，理論上 x64 處理器的記憶體存取上限應該是 16 exabytes（2^64），但目前 Windows x64 的實體記憶體存取上限是 128 GB（2^37），而虛擬記憶體的存取上限則是 16 TB（2^40）。不論如何，128 GB 的實體記憶體存取上限，已經大大超過 32 位元處理器的 4 GB 上限，能夠符合許多高階工作站或伺服器的需求（使用者反而需要注意諸如硬體上的限制，尤其要注意主機板支援的主記憶體數量）。
直到目前為止，市場上絕大部份出貨的伺服器仍是以 x86 指令集為基礎的 32 位元伺服器為主。IT 專業人員已在這些伺服器上廣泛部署 32 位元 Windows，因為這樣的組合易於使用、功能廣泛，而且有豐富的應用軟體。而隨著 x64 硬體產品的推出，大部分新的 x86 架構伺服器已經是 x64 等級伺服器。這些伺服器沿用相同的 x86 指令集，但加上了 64 位元的功能。這意味著它們可以執行現有的 32 位元軟體，也能執行新的 64 位元軟體。


更豐富的軟體支援


Windows x64 目前最需要的，是更多的軟體支援，這可以分成驅動程式和應用程式等兩個方向來討論。大多數的 Win32 應用程式應該都能直接在 Windows x64 環境執行（不需要重新編譯，也就是二元碼相容），而這也是 x64 平台的一大優點，因為這讓企業可以繼續保有原本花費在 Win32 的 IT 投資。
Windows x64 的使用者模式有一個 WOW64 子系統（Windows On Windows64，WOW64.DLL），這個子系統將負責 32 位元應用程式與 Windows x64 作業系統之間的溝通：WOW64 子系統會將 32 位元應用程式的系統呼叫轉換成 Windows x64 作業系統的格式，然後再轉給 Windows x64；作業系統會以為這是由 WOW64 子系統所呼叫，而將結果傳給 WOW64，接著 WOW64 會再將 Windows x64 的傳回值轉換成 32 位元的格式，最後再送回當初發出呼叫的 32 位元應用程式。
因為 WOW64 子系統位於 Windows x64 的使用者模式，因此 WOW64 只能維繫 32 位元使用者模式程式與 Windows x64 的相容性，必須在核心模式執行的 32 位元應用程式或驅動程式，與 Windows x64 會有相容性的問題。
此外，在 Windows x64 當中，32 位元的應用程式不僅有完全與 64 位元程式互相獨立的執行環境，甚至連登錄機碼和軟體安裝的資料夾都各自獨立，以免兩種類型的軟體同時執行而發生衝突。因此程式裡不能混合 32 位元和 64 位元的程式碼；請牢記這點，因為許多軟體相容的問題都是因此而起。當然，個別的 32 位元和 64 位元行程可以透過行程之間的通訊結構（interprocess communications structures）相互傳送資料。雖然 32 位元應用程式在 64 位元作業系統依然會有 4 GB 的記憶體上限，但是卻可以擁有獨享的記憶體空間，不需要與作業系統核心、分頁表或其他的應用程式共用記憶體空間。


軟體相容性


大部分的 Win32 軟體應該都可以直接在 Windows x64 環境執行，不過仍有些特例。如果能瞭解這些例外情況，將有助於軟體的部署，並避免不相容的狀況發生。

Windows 32 On Windows x64

之前我提過 WOW64 子系統，這個子系統可以視為 Windows x64 所虛擬的 32 位元 Windows 執行環境，因此 WOW64 其實是為 "32" 位元程式而設計。此外，在 Windows x64 系統的 WINDOWS 資料夾裡面，SYSTEM32 資料夾也非如其名，這個資料夾實際上是放置 64 位元的系統檔案，SYSWOW64 資料夾才是放置 WOW64 子系統所需要的 32 位元系統檔案。
之所以有這種「32 是 64、64 是 32」的現象，是因為 Windows x64 在載入應用程式之前，並不知道程式是 32 位元還是 64 位元，而當載入並確認應用程式是 32 位元或 64 位元之後，64 位元的程式就使用 SYSTEM32 資料夾裡的系統檔案，而 32 位元的程式則被 WOW64 子系統導引並使用 SYSWOW64 資料夾裡的系統檔案；但是對 32 位元的程式來說，並不知道已經被導引到 SYSWOW64 資料夾，還是以為用的是 SYSTEM32 資料夾裡的系統檔案。因此，沒有符合 Windows 程式設計規範的 32 位元程式在 Windows x64 執行的時候，可能會因為無法被導引到 SYSWOW64 資料夾，而繼續使用 SYSTEM32 資料夾裡的 64 位元系統檔案，就會造成相容性的問題而無法執行。
還有一個類似的情況是安裝軟體的資料夾：Windows x64 有兩個安裝軟體的資料夾，一個是大家熟知的 Program Files，另一個是 Program Files (x86)；前者「預設」是供 x64 應用程式使用，後者「預設」是用來存放 32 位元應用程式。如果程式是以微軟規範的方式取得安裝軟體資料夾的位置，例如環境變數或系統 API，就會得到上述預設的位置，不然就會發生 32 位元應用程式安裝到 Program Files 資料夾的結果。
類似的情況也會發生在存取系統的登錄資料庫。Windows x64 有兩個獨立的軟體設定值存放處，x64 應用程式是存放在 HKEY_LOCAL_MACHINE\SOFTWARE\，但是 32 位元應用程式則是存放在 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node。如果應用程式存取登錄資料庫的方式最終是藉由系統 API 來完成，那麼 WOW64 會將 32 位元應用程式對登錄資料庫的存取，導到 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node。

無法執行 16 位元程式

WINDOWS 資料夾裡面雖然還有 16 位元系統檔案專用的 SYSTEM 資料夾，但實際上 16 位元的 Windows 軟體無法在 Windows x64 執行，因此這個資料夾通常是空的，就算真的將 16 位元的系統檔案安裝於此，16 位元的 Windows 軟體還是無法在 Windows x64 執行。

驅動程式的問題

另一類會發生相容性問題的程式，大多是與系統底層較為相關的程式，尤其是需要在核心模式執行的軟體，都必須升級到 x64 版本，這是因為 WOW64 位於 Windows x64 的使用者模式，無法處理需要在核心模式執行的軟體。
驅動程式必須在核心模式執行，許多防毒軟體的模組也必須在核心模式執行，這些軟體都得升級到 x64 版本。比較特別的是部分會以驅動程式的方式運作的軟體，常見的狀況是以列印的方式產生文件檔案，例如 Adobe Acrobat，就是以列印的方式產生PDF檔案，因此這類的軟體都會在系統安裝印表機驅動程式。但若印表機驅動程式仍是 32 位元，就會無法列印文件。實際上因為這些軟體提供的驅動程式都是 32 位元，因此軟體的安裝程式根本無法將驅動程式裝進 Windows x64 系統。

32 位元與 64 位元無法共同運作

Windows x64 並不允許 x64 應用程式直接呼叫或內含任何 32 位元的程式碼，因為32位元應用程式和 x64 應用程式是在兩個獨立的空間執行，這也會導致若干的相容性問題。例如 Windows x64 的檔案總管是 64 位元的應用程式，而像是 WinRAR 等軟體會以 Shell Extension 的方式來增加檔案總管的功能，例如以滑鼠右鈕按下壓縮檔所出現的快顯功能表會包含解壓縮的動作，就是利用 Shell Extension 的方式達成。檔案總管的 Shell Extension 其實是 COM 物件，這是 32 位元程式。因此在 Windows x64 環境，WinRAR 等軟體在檔案總管滑鼠右鈕所加入的功能都不見了。
另一個例子是 x64 版本的 Internet Explorer 和網頁內的 ActiveX 控制項。ActiveX 控制項也是 32 位元的程式，所以也無法與 x64 版本的 Internet Explorer 相互運作。但這麼一來會造成很多網頁無法正常瀏覽，因為網頁上的 Flash 動畫、ASF 影音檔案都必須依賴 ActiveX 控制項來播放，所以在 Windows x64 還保留了 32 位元的 Internet Explorer，就是為了能繼續執行 ActiveX 控制項。

.NET

要執行 .NET 應用程式，系統必須安裝 .NET 執行環境。而在 Windows x64 系統，1.x 版的 .NET 執行環境是在 WOW64 以 32 位元的方式執行，因此，以 Microsoft .NET Framework 1.x 所開發的 .NET 應用程式也是以 32 位元的方式執行。
x64 版本的 .NET 出現在 .NET 2.0，而且這個版本的 .NET 也同時會有 32 位元的版本。微軟並沒有將 Microsoft .NET Framework 1.x 移植到 x64 版本的計畫，其實是相容性的問題。因為 .NET 1.x 為了達到與 Win32 較大的相容性，允許程式開發人員在 .NET 應用程式直接呼叫 COM，但是對 Windows x64 來說，並不允許 x64 應用程式直接呼叫或內含任何 32 位元的程式碼，因此就算將 Microsoft .NET Framework 1.x 移植到 x64 版本，目前許多 .NET 1.x 應用程式還是無法在 Windows x64 執行。
最妥善的作法，就是讓 .NET 1.x 執行環境和應用程式繼續以 32 位元的方式在 Windows x64 執行，而讓 x64 版本的 .NET 從 2.0 開始。.NET 2.0 針對 x64 的改良還不止於此，.NET 2.0 的編譯程式可以讓程式開發人員針對處理器選擇 Win32、x64、IA-64、或其他處理器，讓 .NET 應用程式可以適用更多的執行環境。
此外，因為 Windows x64 的 IIS 6 預設是以 64 位元的模式執行，因此無法與 Microsoft .NET Framework 1.x 共同運作，必須透過以下的指令將 IIS 6 切換到 32 位元來執行，才能繼續執行 ASP.NET 1.x 的程式：
cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set
w3svc/AppPools/Enable32bitAppOnWin64 1


Windows x64 原生軟體


有了作業系統、驅動程式，接著要考量的是應用軟體的數量。Win32 原本就擁有非常豐富的應用軟體，雖然這些軟體「應該」都能直接在 Windows x64 環境繼續執行，但是軟體開發商也漸漸體認到 x64 對高階運算的影響與重要性，因此已經有越來越多的 Windows x64 原生軟體面市，尤其是伺服端軟體；Windows x64 原生軟體才能展現 x64 龐大記憶體定址能力的優點。
以微軟的伺服器軟體產品而言，已經確定要大幅提高對 Windows x64 的支援，因此這兩年推出的伺服器軟體，大多都已提供了 Windows x64 版本。以下簡述微軟目前所提供的 Windows x64 伺服器軟體。

•Windows Server 2003 R2：包括標準版、企業版、Datacenter 等三款功能、需求各異的 Windows Server 2003 R2 版本。
•Windows Server "Longhorn"：下一代的 Windows Server 不僅將會有 x64 版本，而且也可能是最後一款 32 位元的 Windows 伺服器作業系統。
•Microsoft Exchange Server 2007：正式版本僅支援 x64 版本，32 位元版本僅有試用版。
•Microsoft SQL Server 2005：標準版、企業版和開發版都另有 x64 版本。
•Microsoft BizTalk Server 2006
•Microsoft Commerce Server 2007
•Microsoft Virtual Server 2005 R2
•Microsoft Operations Manager 2005

簡化 IT 管理成本


x64 處理器的另一項優點，是可以簡化組織內的 IT 管理成本，甚至簡化軟體開發成本。對 IT 人員管理系統或網路來說，管理 Windows x64 與 32 位元 Windows 的方式幾乎完全相同，IT 人員只要使用相同的管理工具，就能將 Windows x64 加入現今的 Windows 網路系統；此外，這更是保障了企業主目前部分的 IT 投資。這些優點源自於 x64 架構是以 x86 延伸而來，如此的作法讓 Windows x64 能夠相容現今的 32 位元 Windows 應用程式。
從 32 位元延伸到 64 位元，延伸而來的不只是更大的記憶體存取能力和更快的執行速度，還能實現更多的應用。隨著 x64 處理器和相關硬體周邊的成熟，再加上微軟推出 Windows x64，以及更多 x64 版本的伺服器軟體，x64 在高階如伺服器的應用已經逐步成熟。例如 Windows Server 2003 Datacenter Edition 或企業版能提供 1 TB 的實體記憶體存取空間，再搭配 x64 版本的 SQL Server 2005，將能一次將整個龐大的資料庫載入記憶體，提供用戶端最快速、穩定的資料存取服務。

參考資料

•Benefits of Microsoft Windows x64 Editions (英文)




歡迎光臨 Kuroshio Ocean Design - 黑潮設計 (http://forum.kod.tw/) Powered by Discuz! 7.2