[分享] Desire 820好像要出來了!!
陳誠誼2014-8-24 06:17
本文章最後由( 陳誠誼 )於 2014-8-24 06:24 編輯
謙 發表於 2014-8-23 17:46
64位元的優點是什麼 其實我不太懂 跟一般手機差在哪
這裏用維基百科來說明32bit與64bit，不止是存在速度的差異，最明顯的是RAM的容量擴增。以下維基百科:
處理器中的暫存器通常可分為三種：整數、浮點數、其它。在所有常見的主流處理器中，只有整數暫存器（integer register）才可存放指標值（記憶體資料的位址）。非整數暫存器不能存放指標來讀寫記憶體，因此不能用來避開任何受到整數暫存器大小所影響的記憶體限制。
幾乎所有常見的主流處理器（大部分的 ARM 和 32 位元 MIPS 實作是明顯的例外）整合了浮點數硬體，它有可能使用 64 位元暫存器保存資料，以供處理。例如，x86 架構包含了 x87 浮點數指令，並使用 8 個 80 位元暫存器構成堆疊結構。後來的 x86 修改版和 x86-64 架構，又加入 SSE 指令，它使用 8 個 128 位元寬的暫存器（在 x86-64 中有 16 個暫存器）。與之相較，64 位元 Alpha 系列處理器，除了 32 個 64 位元寬整數暫存器以外，也定義了 32 個 64 位元寬的浮點數暫存器。
記憶體限制[編輯]
目前大部分的 CPU（截至2005年），其單個暫存器可存放虛擬記憶體中任意資料的記憶體位址（本機）。因此，虛擬記憶體（電腦在程式的工作區域中所能保留的資料總量）中可用的位址取決於暫存器的寬度。自 1960 年的 IBM System/360 起，然後 1970年 的 DEC VAX 微型電腦，以及 1980 年 中期的 Intel 80386，在事實上一致開發合用的 32 位元大小的暫存器。32 位元暫存器意味著 232 的位址，或可使用 4 GB 的記憶體。當時在設計這些架構時，4 GB 的記憶體遠遠超過一般所安裝的可用量，而認為已足夠用於定址。認為 4 GB 位址為合適的大小，還有其它重要的理由：在應用程式中，如資料庫，42 億多的整數已足夠對大部分可計算的實體分配唯一的參考參照。
然而在 1990 年初，成本不斷降低的記憶體，使安裝的記憶體數量逼近 4 GB，且在處理某些類型的問題時，可以想像虛擬記憶體的使用空間將超過 4 GB 上限。為此，一些公司開始釋出新的 64 位元架構晶片家族，最初是提供給超級電腦、頂級工作站和伺服器機器。64 位元運算逐漸流向個人電腦，在 2003 年，某些型號的 蘋果公司 Macintosh 產生線轉向 PowerPC 970 處理器（蘋果公司稱為「G5」），並在 2006 年，轉向 EM64T 處理器，且 x86-64 處理器在頂級的 PC 中遂漸普及。64 位元架構的出現，有效的將記憶體上限提升至 264 位址，相當於 1844 多京或 16 EB 的記憶體。從這個角度來看，在 4 MB 主記憶體很普遍時，最大的記憶體上限 232 的位址大約是一般安裝記憶體的 1000 倍。如今，當 1 GB 的主記憶體很普遍時，264 的位址上限大約是 1 百億倍。
今天市面上大部分的消費級 PC 存在著人為的記憶體限制，因受限於實體上的限制，而幾乎不太可能需要完整支援 16 EB 容量。舉例來說，Apple 的 Mac Pro 最多可安裝實體記憶體至 16 GB，而無必要支援超過的大小。最新的 Linux 核心（版本 3.11.2）可編譯成最高支援 64 GB 的記憶體。
32 與 64 位元[編輯]
從 32 位元到 64 位元架構的改變是一個根本的改變，因為大多數作業系統必須進行全面性修改，以取得新架構的優點。其它軟體也必須進行移植，以使用新的效能；較舊的軟體一般可藉由硬體相容模式（新的處理器支援較舊的 32 位元版本指令集）或軟體模擬進行支援。或者直接在 64 位元處理器裡面實作 32 位元處理器核心（如同 Intel 的 Itanium 處理器，其內含有 x86 處理器核心，用來執行 32 位元 x86 應用程式）。支援 64 位元架構的作業系統，一般同時支援 32 位元和 64 位元的應用程式。
明顯的例外是 AS/400，其軟體執行在虛擬的指令集架構，稱為 TIMI（技術獨立機器介面），它會在執行之前，以低階軟體轉換成原生機器碼。低階軟體必須全部重寫，以搬移整個 OS 以及所有的軟體到新的平台。例如，當 IBM 轉移較舊的 32/48 位元「IMPI」指令集到 64 位元 PowerPC（IMPI 完全不像 32 位元 PowerPC，所以這比從 32 位元版本的指令集轉移到相同指令集的 64 位元版本的規模還要龐大）。
64 位元架構無疑可應用在需要處理大量資料的應用程式，如數位視訊、科學運算、和早期的大型資料庫。在其它工作方面，其 32 位元相容模式是否會快過同等級的 32 位元系統，這部分已有很多爭論。在 x86-64 架構（AMD64 和 Intel 64）中，主要的 32 位元作業系統和應用程式，可平滑的執行於 64 位元硬體上。
Sun 的 64 位元 Java 虛擬機的啟動速度比 32 位元虛擬機還慢，因為 Sun 仍假定所有的 64 位元機器都是伺服器，而且只有為 64 位元平台實作「伺服器」編譯器（C2）。[1]「客戶端」編譯器（C1）產生較慢的代碼，不過編譯較快速。所以儘管在 64 位元 JVM 的 Java 程式在一段很長的週期會執行的較好（一般為長時間運作的「伺服器」應用程式），它的啟動時間可能更久。對於短生命期的應用程式（如 Java 編譯器 javac）增加啟動時間可控制執行時間，使 64 位元的 JVM 整體變慢。
應當指出，在比較 32 位元和 64 位元處理器時，速度並不是唯一的考量因素。應用程式，如多工、應力測試（stress testing）、叢集（clustering）（用於HPC）可能更適合 64 位元架構以正確部署。為了以上原因，64 位元叢集已廣泛部署於大型組織，如 IBM、Vodafone、HP、微軟。
優缺點[編輯]
一個常見的誤解是：除非電腦安裝的記憶體大於 4 GB，否則 64 位元架構不會比 32 位元架構好。這不完全正確：
部分作業系統保留了一部分行程位址空間供作業系統使用，減少使用者程式可用於對映記憶體的位址空間。例如，Windows XP DLL 以及 userland OS 元件對映到每一個行程的位址空間，即使電腦裝有 4 GB 的記憶體，也僅剩下 2 至 3.8 GB（端視其設定）的可用位址空間。這個限制在 64 位元 Windows 中不會出現。
檔案的記憶體對映不再適合 32 位元架構，尤其是相對便宜的 DVD 燒錄技術的引入。大於 4 GB 的檔案不再罕見，如此大的檔案無法簡單的對映到 32 位元架構的記憶體，只能對映檔案的一部分範圍到位址空間，並以記憶體對映存取檔案。當有需要時，就必須將這些範圍對映進或對映出位址空間。這是一個問題，因為充裕的記憶體對映仍是從磁碟至記憶體最有效率的存取方法，如果作業系統能適當實行的話。
64 位元架構主要的缺點是，相對於 32 位元架構，佔用相同的資料會消秏更多的記憶體空間（由於腫漲的指標，以及其它型態和對齊補白等可能）。這會增加行程對記憶體的需求，且可能會影響高效能處理器快取的使用。解決方法之一是維持一部分 32 位元模型，且大致合理有效。高效能導向的 z/OS 作業系統便採取這個方法，要求程式代碼存放在 32 位元位址空間的任一數字，資料物件則可（選擇性）存放在 64 位元區域。
目前主要的商業軟體是建立在 32 位元代碼，而非 64 位元代碼，所以不能取得在 64 位元處理器上較大的 64 位元位址空間，或較寬的 64 位元暫存器和資料路徑的優點。然而，免費或自由軟體作業系統的使用者已經可以使用專有的 64 位元運算環境。並非所有的應用程式都需要大量的位址空間或操作 64 位元資料項，所以這些程式不會享受到較大的位址空間或較寬的暫存器和資料路徑的好處；主要受益於 64 位元版本的應用程式，並不會享受到使用 x86 的版本，會有更多的暫存器可以使用。
記住此篇是舉電腦來說明，就算手機廠將32位元提升為64位元，對手機的應用程式不會有什麼影響。
這麼長大概也不是太了解，不過沒關係很快即能體驗．
以上資料來自維基百科網址:
http://zh.wikipedia.org/wiki/64%E4%BD%8D%E5%85%83
★HTC論壇三週年生日快樂★
因為你讓我超越想像、不斷實現完美的畫面，讓我看見這一路令人驚豔的一切，我愛上HTC～
檢舉
回應
因為你讓我超越想像、不斷實現完美的畫面，讓我看見這一路令人驚豔的一切，我愛上HTC～
Vector Tsai2014-8-24 20:30
陳誠誼 發表於 2014-8-24 05:57
若把它放在高階機，那S810出來要放在哪裡呢？所以這是有策略性考慮的，把它放在中階機若能壓低價格，那麼 ...
感謝陳大的說明
我的意思是說，如果這個東西這麼好
為什麼它還算是 " 中階機 " 呢？
也就是說，中階的定義就模糊了 ( 只剩價格？ )
檢舉 回應
