以下是老木請我轉貼的,是從http://www.mobile01.com/topicdetail.php?f=177& ... 轉過來的,請大家參考
gate2 wrote:
http://macperformanceguide.com/SnowLeop ... mance.html
這些都是極大程度依賴序列記憶體存取的程式，依照 Mac OS X 記憶體管理原則，64 bit 系統核心略微超越 32 bit 系統核心（約 3%～5%），並不讓人意外。5% 的差異有多大？原本要一小時才能算完的東西，現在只需要 57 分鐘就好。我不曉得這三分鐘的差異，是不是足以改變一個人對 SL 的觀感。
另外這個測試的基本假設就犯了一個錯：在機器上安裝夠多的記憶體，不代表應用程式的運算全都是在實體記憶體上執行。在 Mac OS 下任何程序的動作都會牽涉到 VM 運作，記憶體切換（paging）動作無論如何都會發生，差別只在於記憶體切換動作的頻繁程度。Mac OS X 核心和其他的 UNIX 系統不同，不是用一個事先配置好的硬碟分割區（或檔案）來處理切換，Mac OS X 核心會動態的幫每一個應用程式『長』虛擬記憶體，而且核心會嘗試使用現階段所有可用的實體記憶體來存放資料。此外，部份程式（例如 Photoshop）會自行處理資料 Swap，不完全依靠系統本身的記憶體管理功能。因此這個網頁執行測試的基礎論點不完全正確。
我承認我對 Helicon Focus 的測試結果感到極度困惑；18% 的差異不是一個可以無視的數據。我無法解釋為何系統核心的差異對 Helicon Focus 有如此大的影響。唯一我認為可能的解釋（除了上述自行處理 Swap 這種狀況以外）就是：Helicon Focus 本身採用的記憶體配置程式寫法不適合 SL 的運作模式。我猜測 Helicon Focus 是採用分批配置記憶體的做法，來取代一次要求大量記憶體。因此 32bits 系統核心就必須更加頻繁的處理虛擬記憶體內容搬移，因此拖慢了系統反應的速度。原本 Helicon Focus 可能打算用這種方法在 32bits 執行環境下幫助系統核心的記憶體管理達到最大效能，但是到了 64 bits 執行環境，這種做法反而變成累贅，讓系統無法發揮出最大效能。
無論如何，這樣的測試與一般使用者在日常使用中會碰到的狀況有非常大的落差。如果閣下對這方面的主題有研究，請提供更接近日常生活使用的應用程式在 64 bits 核心下執行效能比 32 bits 核心快很多的案例。
Cullegg wrote:
http://www.apple.com/tw/macosx/refinements/
首先感謝閣下指出我的錯誤。我現在確實已經知道『50% 效能提升』這句話是 Apple 講的了。但是針對我其他的論點，閣下似乎沒有提出足以反駁的立論。
以下節錄自美國官網：
Faster, more powerful Safari.
With Snow Leopard, Safari 4 delivers up to 50 percent faster JavaScript performance thanks to its 64-bit support.6 In addition, Safari is even more resistant to crashes. It turns out that the number one cause of crashes in Mac OS X is browser plug-ins. So Apple engineers redesigned Safari to make plug-ins run separately. If a plug-in crashes on a web page, Safari will keep running.
以下節錄自台灣官網：
更快、更強大的 Safari
Snow Leopard 支援 64 位元，JavaScript 的處理速度因此提升 50%。此外，Safari 還不容易當掉。大多數 Mac OS X 中瀏覽器故障都是由瀏覽器外掛模組引起的，Apple 工程師因此重新設計了 Safari, 讓外掛模組分開運行。所以如果有一個網頁外掛模組當掉，Safari 一樣能正常運行。
請問在上面兩段中，Apple 有說過 Safari 的 Javascript 之所以變快是因為系統核心是 64bits 嗎？
讓我們仔細，一個字一個字慢慢解讀上面那兩段話：
1. Snow Leopard 支援 64 位元
解讀：這句話正確，因為 Snow Leopard 的系統函式庫與記憶體管理的確支援 64 bits 應用程式執行。它並沒有講說，Snow Leopard 的『系統核心』是 64-bits。
2. JavaScript 的處理速度因此提升 50%
解讀：改用 64 bits 表示應用程式必定重新編譯過，使用的函式庫和編譯器最佳化方法都不同，的確有可能讓速度變快。除了 50% 這個數字是否為真有待檢驗以外（坦白說在下完全不相信 Apple 在註釋中解釋的『測試』結果足以代表實際狀況），這句話並沒有錯誤或誇大不實。
把上面兩句話組合在一起就是『Snow Leopard 的系統函式庫與記憶體管理支援 64 bits 應用程式執行；而以 64 bits 模式重新編譯過的 Safari，執行速度會比以前快』。這句話並沒有邏輯上的錯誤。
請問到底是 Apple 說錯還是使用者自己會錯意？
你今天會引用這句話，其實就是錯誤認知『應用程式是 64-bits ，所以核心一定是 64-bits』。很多人都並沒有想過，『64-bits 應用程式可以在 32-bits 核心上執行』這件事。就像『68K 程式碼可以在 PowerPC 上執行、PowerPC 程式碼可以在 Intel CPU 上執行』一樣不可思議。
再看到底下的註釋 6，Apple 用來測試出 50% 這個數字的，是一台 2.0GHz MacBook 和一台 2.66GHz iMac。現在是不是有人要用陰謀論，認為 Apple 用來測試的 MacBook 是特地上了 EFI64 的特製機種？
Cullegg wrote:
至於事實上，64跟速度有沒有關係，個人認為也不必然.. 互有爭議，我也不是學這專業
有沒有關係？當然是有的。可是關係有多大，這才是你所謂的【不必然】。
什麼叫做必然什麼叫做不必然？以上述 50% 這件事為例，坦白說，我壓根不相信 50% 這個數字；Javascript 引擎的運算量根本不足以察覺出整數運算和記憶體存取的差異，唯一的可能就是『Apple 在重新編譯成 64bits 時特別下足苦功來進行優化』，簡單的說，造成 Javascript 引擎效能提升的真正原因，依據我對計算機學的認知，那不是單純的 32bits / 64bits 問題。換句話說，64bits 不是效能進化的『必然條件』，『重新編譯時的優化』才是。
退一萬步來說，就算 JavaScript 真的有 50% 效能增進好了，換算為平均的頁面讀取瀏覽效能，能有多少的改善？實際上除了某些特殊 AJAX 網頁以外，大部分網頁的 Javascript render 速度和 I/O 造成的延遲相比（單純的 Socket I/O 與 Cache I/O，不考慮網路延遲）根本微不足道。因此這 50% JavaScript 的增效對於一般人整體瀏覽經驗的改善，或許只有 5%。
簡單的說，這個必然與不必然，就單純只是邊際效益的問題。
造成電腦執行效率不佳的原因有非常多。增加記憶體，換更快的硬碟，換上 Gigabits 網路交換器，甚至改用不同的應用程式，這些簡單的動作都會大幅改善應用程式的執行效率，而且是普遍增加。相較於大量記憶體運算類型超重負載應用程式的 5% 效能增加，各位認為何者比較重要？在一台只裝了 1G RAM、5400 RPM 硬碟的機器上，抱怨系統核心不能用 64-bits 模式執行，這就叫做本末倒置。
再強調一次重點：Kernel 不是 64 bits不代表應用程式不能用 64 bits 模式執行。事實上對執行效率有影響的，主要是應用程式本身而不是系統核心。
實際上應用程式本來就是獨立於系統作業核心之外運作。應用程式和系統核心會扯上關係的，就只有記憶體配置、記憶體存取、I/O 動作、應用程式間通訊（包括信號、旗標、鎖定等）這些（參見下面的延伸閱讀三）。排除系統核心因最佳化處理的差異、以及多核心機器的排程等因素，對應用程式影響最大有二，第一是整數運算工作，第二就是記憶體運算動作。整數運算工作很容易理解，但是真正會大量用到 64-bits 甚至 128-bits 長整數運算的，大多是加密等動作；64-bits 應用程式在進行 128-bits 公鑰演算法加密運算的時候，速度確實會有明顯（以倍數計算）的提升。而記憶體運算動作在『頻繁、大量、序列處理極大記憶體區塊』的情況下才會有比較明顯的差異。對於瀏覽、輸入、互動等隨機存取動作比較多、幾乎沒有長整數運算需要、且多是小量存取的應用程式，差異根本不明顯。
正如同樓上前輩所述，SL 最大的效能提升點，是在改善多核心執行緒排程、簡化 OpenCL 框架、以及其他核心模組（QuickTime等）的改變。而這些改變都是系統框架（Framework）層級的改變，用大家比較懂得方法來講，就是 SL 提供更多威力強大的開發工具，讓開發者更容易開發出高效能的應用程式。這才是真正有價值的東西。
所以根本不必擔心你的機器能不能支援 64 bits，因為在絕大多數的使用者情境中，使用者不會感受到任何差異。應用程式本身才是重點。到頭來還是那句話，系統核心有沒有 64-bits，純粹是大水管心態在作祟，一般使用者根本不會注意到有什麼差異。
不必備份，我行不改姓坐不改名，我就是這個論調：『系統核心有沒有 64-bits，純粹是大水管心態在作祟』。這是基於我個人對作業系統的了解、對 Mac OS X 記憶體管理的了解，以及對應用程式執行效能瓶頸的了解所得出來的推論。我不認為這個論調是絕對真理，我接受任何反面的論述和例證，但是請指點真正有意義的論述和例證。Helicon Focus 的案例我無法解釋，但我懷疑那個測試只是個案，代表性不足。除非你每天都要用 Helicon Focus 來工作，那我沒話講。
延伸閱讀之一：
http://blog.fosketts.net/2009/08/30/64b ... rd-kernel/
這一篇有解釋為何某些機種可以執行 64 bits 系統核心、而某些機種不行。同時也有截圖證明 64-bits 應用程式可以在 32-bits 核心之上執行。
延伸閱讀之二：
http://en.wikipedia.org/wiki/64-bit
A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GB of main memory. This is not entirely true:
* Some operating systems reserve portions of process address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, Windows XP DLLs and other user mode OS components are mapped into each process's address space, leaving only 2 to 3 GB (depending on the settings) address space available. This restriction is not present in 64-bit operating systems.
Because device drivers in operating systems with monolithic kernels, and in many operating systems with hybrid kernels, execute within the operating system kernel, it is possible to run the kernel as a 32-bit process while still supporting 64-bit user processes. This provides the memory and performance benefits of 64-bit for users without breaking binary compatibility with existing 32-bit device drivers, at the cost of some additional overhead within the kernel. This is the mechanism by which older versions of Mac OS X enables 64-bit processes while still supporting 32-bit device drivers.
延伸閱讀之三：
http://en.wikipedia.org/wiki/Hybrid_kernel
http://en.wikipedia.org/wiki/File:OS-structure.svg
http://en.wikipedia.org/wiki/File:OS-structure2.svg
這張圖片很清楚的解釋了，系統核心服務（驅動程式、檔案系統等）都是獨立於系統核心空間之外運作。
