Câu hỏi Hệ thống 32 bit so với 64 bit


Sự khác nhau giữa các hệ thống 32-bit và 64-bit là gì?

Nếu bạn đã sử dụng cả hai, bạn đã trải qua những sự khác biệt rõ ràng nào?

Có vấn đề gì khi sử dụng các chương trình 32 bit trên các hệ thống 64 bit trong một số trường hợp?


219
2017-10-17 11:14


gốc


Có rất nhiều nhầm lẫn ở đây, và ở nơi khác trên web, giữa địa chỉ vật lý (truy cập vào ram) PEA ảnh hưởng đến điều này, hội đồng quản trị mẹ ảnh hưởng đến điều này, và địa chỉ logic (bộ nhớ ảo cho mỗi quá trình). Trên một hệ điều hành 32 bit, bộ nhớ ảo được giới hạn ở 4GB trừ đi những gì mà hạt nhân dự trữ. Nó độc lập với RAM, bạn có thể có RAM 0,1MB hoặc 8GB và bạn sẽ có chính xác 4GB bộ nhớ ảo (nhưng một số bộ nhớ được đặt trước bởi hạt nhân). PEA có thể được sử dụng để có nhiều RAM hơn, nhưng không phải là câu trả lời hoàn hảo vì hạt nhân KHÔNG THỂ truy cập tất cả. - ctrl-alt-delor


Các câu trả lời:


Lưu ý: Những câu trả lời này áp dụng cho các CPU PC x86 tiêu chuẩn (Intel và AMD) và Windows (thường được cấu hình cho người dùng cuối). Các chip 32 bit hoặc 64 bit khác, các hệ điều hành khác và các cấu hình hệ điều hành khác có thể có sự cân bằng khác nhau.

Từ góc độ kỹ thuật, một hệ điều hành 64 bit cung cấp cho bạn:

  • Cho phép các quy trình riêng lẻ xử lý hơn 4 GB RAM (trong thực tế, hầu hết không phải tất cả các hệ điều hành 32 bit cũng giới hạn tổng RAM hệ thống có thể sử dụng đến dưới 4 GB, không chỉ tối đa cho mỗi ứng dụng).

  • Tất cả các con trỏ mất 8 byte thay vì 4 byte. Hiệu ứng sử dụng RAM là tối thiểu (vì bạn không có khả năng có một ứng dụng đầy gigabyte con trỏ), nhưng trong trường hợp lý thuyết tồi tệ nhất, điều này có thể làm cho bộ nhớ cache CPU có thể giữ 1/2 như nhiều con trỏ (làm nó có hiệu quả 1/2 kích thước). Đối với hầu hết các ứng dụng, đây không phải là một vấn đề lớn.

  • Có nhiều CPU có mục đích chung hơn đăng ký ở chế độ 64 bit. Đăng ký là bộ nhớ nhanh nhất trong toàn bộ hệ thống của bạn. Chỉ có 8 trong chế độ 32 bit và 16 thanh ghi mục đích chung ở chế độ 64 bit. Trong các ứng dụng máy tính khoa học tôi đã viết, tôi đã thấy hiệu suất tăng 30% bằng cách biên dịch lại ở chế độ 64 bit (ứng dụng của tôi thực sự có thể sử dụng thanh ghi bổ sung).

  • Hầu hết các hệ điều hành 32 bit thực sự chỉ cho phép các ứng dụng riêng lẻ sử dụng 2 GB RAM, ngay cả khi bạn đã cài đặt 4 GB. Điều này là do 2 GB không gian địa chỉ khác được dành riêng cho việc chia sẻ dữ liệu giữa các ứng dụng, với hệ điều hành và để giao tiếp với các trình điều khiển. Windows và Linux sẽ cho phép bạn điều chỉnh sự cân bằng này là 3 GB cho các ứng dụng và 1 GB được chia sẻ, nhưng điều này có thể gây ra sự cố cho một số ứng dụng không mong đợi thay đổi. Tôi cũng đoán nó có thể làm tê liệt một card đồ họa có 1 GB RAM (nhưng tôi không chắc chắn). Một hệ điều hành 64 bit có thể cung cấp cho các ứng dụng 32 bit riêng lẻ gần hơn với 4 GB đầy đủ để chơi cùng.

Từ quan điểm của người dùng:

  • Tốc độ ứng dụng thường nhanh hơn đối với ứng dụng 64 bit trong hệ điều hành 64 bit so với phiên bản 32 bit của ứng dụng trên hệ điều hành 32 bit nhưng hầu hết người dùng sẽ không thấy tốc độ này tăng lên. Hầu hết các ứng dụng cho người dùng bình thường không thực sự tận dụng lợi thế của các thanh ghi bổ sung hoặc các lợi ích được cân bằng bởi các con trỏ lớn hơn làm đầy bộ đệm.

  • Nếu bạn có bất kỳ ứng dụng hog bộ nhớ nào (như trình chỉnh sửa ảnh, xử lý video, tính toán khoa học, v.v.), nếu bạn có (hoặc có thể mua) hơn 3 GB RAM và bạn có thể tải xuống phiên bản 64 bit của ứng dụng, sự lựa chọn rất dễ dàng: sử dụng hệ điều hành 64 bit.

  • Một số phần cứng không có trình điều khiển 64 bit. Kiểm tra bo mạch chủ của bạn, tất cả các thẻ plug-in và tất cả các thiết bị USB trước khi thực hiện chuyển đổi. Lưu ý rằng trong những ngày đầu của Windows Vista, đã có rất nhiều vấn đề với trình điều khiển. Những ngày này mọi thứ thường tốt hơn.

  • Nếu bạn chạy quá nhiều ứng dụng tại một thời điểm mà bạn đang hết RAM (thông thường bạn có thể nói điều này bởi vì máy tính của bạn bắt đầu nhận được thực sự chậm và bạn nghe thấy ổ đĩa cứng crunching), sau đó bạn sẽ muốn có một hệ điều hành 64-bit (và đủ RAM).

  • Bạn có thể chạy các ứng dụng 32 bit (nhưng không phải trình điều khiển) trong Windows 64 bit mà không gặp vấn đề gì. Sự sụt giảm tồi tệ nhất mà tôi đã đo cho một ứng dụng 32-bit trong Windows 64-bit là khoảng 5% (có nghĩa là nếu mất 60 giây để làm điều gì đó trong Windows 32 bit, nó mất tối đa 60 * 1.05 = 65 giây với cùng một ứng dụng 32 bit trong Windows 64 bit).

32 bit so với 64 bit nào không phải bao hàm, ngụ ý:

Trên các hệ thống x86, 32 bit so với 64 bit trực tiếp đề cập đến kích thước của con trỏ. Đó là tất cả.

  • Nó không đề cập đến kích thước của C int kiểu. Đó là quyết định của việc thực hiện trình biên dịch cụ thể, và hầu hết các trình biên dịch phổ biến chọn 32-bit int trên các hệ thống 64 bit.

  • Nó không trực tiếp tham khảo kích thước của thanh ghi không phải con trỏ bình thường. Tuy nhiên, việc sử dụng thanh ghi số học 64 bit xảy ra để yêu cầu ứng dụng và hệ điều hành cũng chạy ở chế độ con trỏ 64 bit.

  • Nó không trực tiếp tham khảo kích thước của bus địa chỉ vật lý. Ví dụ: một hệ thống có các dòng bộ nhớ cache rộng 64 bit và tối đa 512GiB bộ nhớ chỉ cần 33 bit trong bus địa chỉ của nó (tức là log2(512*1024**3) - log2(64) = 33).

  • Nó không đề cập đến kích thước của bus dữ liệu vật lý: nó liên quan nhiều hơn đến chi phí sản xuất (số chân trong socket CPU) và kích thước dòng bộ nhớ cache.


262
2017-10-17 13:11



Câu trả lời rất hay. Đặc biệt là vì bạn đã lưu ý rằng không có giới hạn RAM 4GB, nhưng lại hạn chế quá trình sử dụng bộ nhớ. Chỉ cần cho thông tin của bạn, tôi nghĩ bạn nên xem liên kết này: unawave.de/windows-7-tipps/32-bit-ram-barrier.html?lang=EN - Breakthrough
Chúng là các ứng dụng không hoạt động trên các cửa sổ 64 bit: các ứng dụng 16 bit / ứng dụng sử dụng các trình điều khiển chế độ hạt nhân 32 bit hoặc unsigned. Đó là rất nhiều cho một người nghiện phần mềm như tôi ... - fluxtendu
@flextendu, với các yêu cầu về hiệu suất của các chương trình cũ, bạn gần như chắc chắn có thể chạy chúng trong một máy ảo. Với VMware player, Virtual PC và Virtual Box, không có lý do gì để không thử một trong số chúng, nếu bạn có một giấy phép Windows 32 bit. Nếu bạn không muốn gây rối với điều đó, họ có thể sẽ làm việc trong "Windows XP Mode" quá. - Mark Booth
Ứng dụng BTW, 32 bit sẽ không sử dụng nhiều hơn 2 GiB RAM trừ khi cờ cụ thể được bật trong tệp kê khai của chúng. Nguồn: blogs.technet.com/b/markrussinovich/archive/2008/11/17/… - Hello71
Có, tôi chắc chắn Hello71 đã nhấn vào một cái gì đó khá quan trọng mà không được đề cập ở đây: Hầu hết các ứng dụng 32 bit sẽ không bao giờ trực tiếp tận dụng bộ nhớ RAM thừa. Tôi nghĩ điều này đáng nói đến, phải không? - Django Reinhardt


Về cơ bản, bạn có thể làm mọi thứ với quy mô lớn hơn:

  1. RAM trên mỗi hệ điều hành: Giới hạn RAM 4GB trên x86 cho hệ điều hành (phần lớn thời gian)
  2. RAM cho mỗi quá trình: RAM giới hạn 4GB trên x86 cho các quy trình (luôn luôn). Nếu bạn nghĩ rằng điều này không quan trọng, hãy thử chạy một ứng dụng chuyên sâu cơ sở dữ liệu MSSQL lớn. Nó sẽ sử dụng> 4GB chính nó nếu bạn có nó và chạy tốt hơn nhiều.
  3. Địa chỉ: Địa chỉ là 64 bit thay vì 32 bit cho phép bạn có các chương trình "lớn hơn" sử dụng nhiều bộ nhớ hơn.
  4. Xử lý có sẵn cho các chương trình: Bạn có thể tạo nhiều tập tin xử lý, quy trình, ... Ví dụ trên Windows x64 bạn có thể tạo> 2000 luồng cho mỗi tiến trình, nhưng trên x86 gần hơn đến vài trăm.
  5. Các chương trình rộng hơn có sẵn: Từ một x64, bạn có thể chạy cả hai chương trình x86 và x64. (Ví dụ windows: wow64, windows32 trên mô phỏng windows64)
  6. Tùy chọn mô phỏng: Từ một x64, bạn có thể chạy cả hai máy ảo x86 và x64.
  7. Nhanh hơn: Một số tính toán nhanh hơn trên CPU 64 bit
  8. Chia nhiều tài nguyên hệ thống: Rất nhiều bộ nhớ RAM là rất quan trọng khi bạn muốn chạy ít nhất một máy ảo phân chia tài nguyên hệ thống của bạn.
  9. Các chương trình độc quyền có sẵn: Một số chương trình mới chỉ hỗ trợ x64. Ví dụ về Exchange 2007.
  10. Tương lai lỗi thời x86 ?: Theo thời gian ngày càng nhiều 64 bit sẽ được sử dụng và ngày càng nhiều x86 sẽ không được sử dụng. Vì vậy, các nhà cung cấp sẽ chỉ hỗ trợ hơn 64 bit.

Hai loại kiến ​​trúc 64-bit lớn là kiến ​​trúc x64 và IA64. Nhưng x64 là phổ biến nhất cho đến nay.

x64 có thể chạy lệnh x86 cũng như lệnh x64. IA64 cũng chạy các lệnh x86, nhưng nó không làm các phần mở rộng SSE. Có phần cứng chuyên dùng cho Itanium để chạy các lệnh x86; nó là một trình giả lập, nhưng trong phần cứng.

Như @Phil đã đề cập, bạn có thể có cái nhìn sâu hơn về nó hoạt động như thế nào.


107
2017-09-25 12:19



Um. IA64 chạy lệnh x86. Tuy nhiên, nó không làm các phần mở rộng SSE. Có phần cứng chuyên dùng cho Itanium để chạy các lệnh x86; nó là một trình giả lập, nhưng trong phần cứng. - tzot
Một vài năm trước, Raymond Chen đã đăng bài về "giới hạn" năm 2000, và nó ít nhiều là một truyền thuyết đô thị: blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx - bk1e
Upvote cho Arstechnica cho lời giải thích của họ. - Avihu Turzion
RAM giới hạn 4GB không hoàn toàn đúng (nó đúng hơn là giới hạn nhân tạo đặt trên hệ thống Windows người dùng gia đình), kiểm tra PAE. Với phần cứng cập nhật nhất, hạt nhân Linux PAE (được sử dụng theo mặc định cho 32bit) có thể giải quyết nhiều hơn 4GB. Tương tự áp dụng cho FreeBSD và NetBSD. - Izzy
Hệ thống 32 bit không thể sử dụng nhiều hơn 4GB (dấu chấm đầu tiên) vì "địa chỉ" (dấu chấm thứ 3) .Bởi vì số 32 bit cao nhất là 4.294.967.296 (= 4GB). Vì vậy, puncts 1 và 3 của bạn là CÙNG. Bạn có thể xóa dấu câu thứ 3. :) - Jet


Tác động lớn nhất mà mọi người sẽ nhận thấy tại thời điểm này là máy tính 32 bit chỉ có thể giải quyết tối đa 4GB bộ nhớ. Khi bạn tắt bộ nhớ được phân bổ cho các ứng dụng khác bởi hệ điều hành, PC của bạn có thể chỉ hiển thị khoảng 3.25GB bộ nhớ có thể sử dụng. Di chuyển qua 64bit và giới hạn này biến mất.

Nếu bạn phát triển nghiêm túc thì điều này có thể rất quan trọng. Hãy thử chạy một số máy ảo và bạn sẽ sớm hết bộ nhớ. Các máy chủ có nhiều khả năng cần thêm bộ nhớ và vì vậy bạn sẽ thấy rằng việc sử dụng 64bit là lớn hơn nhiều trên các máy chủ hơn là các máy tính để bàn. Định luật Moore đảm bảo rằng chúng ta sẽ có nhiều bộ nhớ hơn trên các máy và do đó tại một số máy tính để bàn điểm cũng sẽ chuyển sang 64bit như là tiêu chuẩn.

Để có mô tả chi tiết hơn về sự khác biệt của bộ xử lý, hãy xem bài viết tuyệt vời này từ ArsTechnica.


46
2017-09-25 12:16



Nền tảng 32-bit và giới hạn 4GB là một phần của sự nhầm lẫn và (là) chủ yếu là giới hạn lựa chọn / thiết kế kiến ​​trúc hệ điều hành. Thực sự, 4GB từ 32-bit thực sự là trên một giới hạn trong một không gian VA quá trình. Địa chỉ vật lý hỗ trợ 36 bit trên CPU Intel 32 bit - Tall Jeff
Bạn thực hiện một điểm tốt đó là chắc chắn đúng sự thật. Nhưng tác động trong thế giới thực của người dùng máy tính là có máy sẽ không sử dụng 4GB đầy đủ mà họ trả tiền cho. Bố tôi đã có vấn đề này và vẫn còn nhầm lẫn rằng 4GB ông trả tiền cho không thể được sử dụng đầy đủ.
Đánh giá cao quan điểm của bạn, nhưng chỉ cố gắng lái xe khái niệm rằng sửa chữa không phải là trong bộ vi xử lý hoặc đi đến 64-bit, nó chỉ là vấn đề của một thiết kế hệ điều hành được cải thiện một chút. Điều này được giải quyết, ví dụ, trên các phiên bản doanh nghiệp của Windows thậm chí trở lại trong các phiên bản 32-bit. Nó cho phép 64GB RAM. - Tall Jeff
Về mặt kỹ thuật, giới hạn không biến mất. Nó di chuyển xa hơn đến nơi nó là không thực tế / không thể cài đặt nhiều RAM trên một máy tính bất cứ lúc nào trong thập kỷ tới.
Xem nhận xét của tôi về PAE ở trên: giới hạn 4GB là không đúng đối với toàn bộ hệ thống - nhưng chỉ áp dụng cho các quy trình đơn lẻ (không quá trình nào có thể truy cập 4GB và chính nó - nhưng toàn bộ hệ thống, tức là tất cả các quá trình với nhau, có thể được bật PAE). Vì vậy, trừ khi một ứng dụng có lợi nhuận từ việc có thể truy cập 4GB trở lên (chẳng hạn như trình chỉnh sửa video / trình chuyển đổi có tệp video lớn) và 8GB + cài đặt, nó không nên làm cho sự khác biệt nhiều cho dù sử dụng 32bit hoặc 64bit. - Izzy


Không có gì miễn phí: mặc dù các ứng dụng 64 bit có thể truy cập nhiều bộ nhớ hơn các ứng dụng 32 bit, nhược điểm là chúng nhu cầu nhiều bộ nhớ hơn. Tất cả những con trỏ sử dụng để cần 4 byte, bây giờ họ cần 8. Ví dụ, yêu cầu mặc định trong Emacs là bộ nhớ 60% nhiều hơn khi nó được xây dựng cho một kiến ​​trúc 64-bit. Dấu chân bổ sung này làm tổn thương hiệu suất ở mọi cấp độ của phân cấp bộ nhớ: các tệp thực thi lớn hơn mất nhiều thời gian hơn để tải từ đĩa, các bộ làm việc lớn hơn khiến phân trang nhiều hơn và các đối tượng lớn hơn có nghĩa là ít phù hợp hơn trong bộ đệm bộ xử lý. Nếu bạn nghĩ về CPU có bộ nhớ đệm L1 16K, ứng dụng 32 bit có thể hoạt động với 4096 con trỏ trước khi nó bị lỗi và chuyển tới bộ đệm L2 nhưng ứng dụng 64 bit phải tiếp cận bộ đệm L2 sau 2048 con trỏ.

Trên x64, điều này được giảm nhẹ bởi các cải tiến kiến ​​trúc khác như đăng ký nhiều hơn, nhưng trên PowerPC nếu ứng dụng của bạn không thể sử dụng> 4G, nó có khả năng chạy nhanh hơn trên "ppc" hơn "ppc64". Ngay cả trên Intel có khối lượng công việc chạy nhanh hơn trên x86, và ít chạy hơn 5% nhanh hơn trên x64 so với x86.


31
2017-10-13 10:45



Câu trả lời này cho thấy rằng PowerPC64 không tốt bằng x86-64. Sự thật là powerpc64 không cải thiện powerpc, vì powerpc không bị hỏng. - ctrl-alt-delor
Linux bây giờ có một ABI x32, với tất cả các lợi ích tốc độ của x86-64 (nhiều thanh ghi, thiết kế lại ABI), nhưng với con trỏ 32 bit. 1 để chỉ ra rằng lợi ích của chế độ 64bit không phải là từ việc tăng chiều rộng thực tế, nhưng từ cơ hội để giảm rất nhiều hành lý đang giữ lại kiến ​​trúc. Regs 64bit có giá trị cho một số ứng dụng, nhưng không gian con trỏ 64 bit ít thường xuyên hơn. - Peter Cordes


Một hệ điều hành 64 bit có thể sử dụng nhiều RAM hơn. Đó là về nó, trong thực tế. 64-bit Vista / 7 sử dụng các tính năng an toàn của fancier cho nơi chúng đặt các thành phần quan trọng trong RAM, nhưng đó không thực sự là 'đáng chú ý' như vậy.

Từ ChrisInEdmonton:

Hệ điều hành 32 bit trên ix86   hệ thống với PAE có thể giải quyết lên đến 64   GB RAM. Hệ điều hành 64 bit   trên x86-64 có thể truy cập tới 256 TB   không gian địa chỉ ảo, mặc dù điều này có thể   được nâng lên trong các bộ vi xử lý tiếp theo,   đến 16 EB. Lưu ý rằng một số hoạt động   hệ thống giới hạn không gian địa chỉ   hơn nữa, và hầu hết các bo mạch chủ sẽ   có các hạn chế bổ sung.


19
2017-10-17 11:24



Đối với một hệ điều hành, 32-bit so với 64-bit CHỈ đề cập đến kích thước của con trỏ (những gì đoạn đầu tiên của bạn một cách chính xác thảo luận). -1: Một số hệ điều hành chọn khóa kích thước nguyên mặc định cho kích thước con trỏ, nhưng cả Windows lẫn Linux đều không làm như vậy. Độ chính xác của phép toán nguyên là không thay đổi. Không có hệ điều hành được sử dụng rộng rãi nào thay đổi độ chính xác của dấu phẩy động (những gì đoạn thứ hai yêu cầu). "float" hoặc "single" là 32 bit, "double" là 64 bit, bất kể hệ điều hành có sử dụng con trỏ 32 bit hay 64 bit hay không. - Mr Fooz
Ah, tôi rõ ràng đã nhầm lẫn, cảm ơn vì đã dọn dẹp :) - Phoshi
Không vấn đề gì. -1 -> +1 - Mr Fooz
Có thể có giá trị chỉnh sửa câu trả lời của bạn để nhà nước có bao nhiêu bộ nhớ RAM có thể được truy cập. Một hệ điều hành 32 bit trên một hệ thống ix86 với PAE có thể giải quyết tối đa 64 GB RAM. Một hệ điều hành 64 bit trên x86-64 có thể truy cập tới 256 TB không gian địa chỉ ảo, mặc dù điều này có thể được nâng lên trong các bộ xử lý tiếp theo, lên đến 16 EB. Lưu ý rằng một số hệ điều hành giới hạn không gian địa chỉ hơn nữa và hầu hết các bo mạch chủ sẽ có các hạn chế bổ sung. - ChrisInEdmonton
Tôi muốn giữ nó đơn giản, vì các con số chủ yếu đủ cao để không liên quan tại thời điểm này, nhưng nó không thể làm tổn thương để dính chúng trong bây giờ. - Phoshi


Không chắc tôi có thể trả lời tất cả các câu hỏi của bạn mà không cần viết toàn bộ bài luận (luôn có Google ...), nhưng bạn không cần phải thiết kế các ứng dụng của mình khác nhau cho 64bit. Tôi đoán những gì đang được đề cập đến là bạn phải lưu tâm đến những thứ như kích thước con trỏ không còn kích thước giống như ints. Và bạn có một tải toàn bộ các vấn đề tiềm ẩn với các giả định sẵn có trên một số loại dữ liệu nhất định dài bốn byte mà có thể không còn đúng nữa.

Điều này có khả năng đi lên tất cả các loại thứ trong ứng dụng của bạn - mọi thứ từ lưu / tải từ tệp, lặp qua dữ liệu, căn chỉnh dữ liệu, tất cả các cách thức hoạt động bitwise trên dữ liệu. Nếu bạn có một codebase hiện có mà bạn đang cố gắng port, hoặc làm việc trên cả hai, có khả năng bạn sẽ có rất nhiều niggles nhỏ để làm việc thông qua.

Tôi nghĩ đây là vấn đề triển khai, chứ không phải là vấn đề thiết kế. I E. Tôi nghĩ rằng "thiết kế" của nói, một gói chỉnh sửa ảnh sẽ giống nhau bất cứ điều gì từ ngữ. Chúng tôi viết mã biên dịch cho cả hai phiên bản 32bit và 64bit, và thiết kế chắc chắn không khác nhau giữa hai - đó là cùng một codebase.

Các "thỏa thuận lớn" cơ bản trên 64bit là bạn có được quyền truy cập vào một không gian địa chỉ bộ nhớ lớn hơn nhiều so với 32bit. Điều này có nghĩa rằng bạn có thể thực sự chuck trong hơn 4Gb bộ nhớ vào máy tính của bạn và thực sự có nó tạo sự khác biệt.

Tôi chắc rằng các câu trả lời khác sẽ đi vào chi tiết và lợi ích nhiều hơn I.

Về mặt phát hiện sự khác biệt thì lập trình bạn chỉ cần kiểm tra kích thước của một con trỏ (ví dụ: sizeof (void *)). Câu trả lời của 4 có nghĩa là 32 bit của nó, và 8 có nghĩa là bạn đang chạy trong một môi trường 64bit.


14
2017-09-25 12:29



Nếu bạn viết các chương trình tình cờ giả định rằng các kiểu con trỏ nhất định có cùng kích thước với các kiểu tích phân nhất định, thì bạn có thể dùng nó. Điều này đã đúng trong một thời gian dài. - David Thornley
@ David: Bạn hoàn toàn đúng. Thật không may, có một tấn mã ra có mà chính xác điều đó.


Một quy trình 32 bit có một không gian địa chỉ ảo là 4 GB; điều này có thể quá ít đối với một số ứng dụng. Một ứng dụng 64 bit có một không gian địa chỉ hầu như không giới hạn (tất nhiên nó bị giới hạn, nhưng bạn rất có thể sẽ không đạt đến giới hạn này).

Trên OSX có những ưu điểm khác. Xem bài viết sau, tại sao có hạt nhân chạy trong không gian địa chỉ 64 bit (bất kể ứng dụng của bạn chạy 64 hay 32) hay ứng dụng của bạn chạy trong không gian địa chỉ 64 bit (trong khi hạt nhân vẫn là 32 bit) dẫn đến hiệu suất tốt hơn nhiều. Để tóm tắt: Nếu một trong hai là 64 Bit (kernel hoặc app, hoặc cả hai khóa học), TLB ("translation lookaside buffer") không phải được flushed bất cứ khi nào bạn chuyển từ kernel sang sử dụng space và back (mà sẽ tăng tốc độ truy cập RAM).

Ngoài ra, bạn có hiệu suất tăng khi làm việc với các biến "long long int" (các biến 64 bit như uint64_t). Một CPU 32 bit có thể thêm / chia / trừ / nhân hai giá trị 64 bit, nhưng không phải trong một hoạt động phần cứng đơn lẻ. Thay vào đó, nó cần phải chia hoạt động này thành hai (hoặc nhiều hơn) 32 bit hoạt động. Vì vậy, một ứng dụng hoạt động rất nhiều với các số 64 bit sẽ có tốc độ tăng khả năng thực hiện phép toán 64 bit trực tiếp trong phần cứng.

Cuối cùng nhưng không kém phần kiến ​​trúc x86-64 cung cấp nhiều thanh ghi hơn các kiến ​​trúc x86 cổ điển. Làm việc với thanh ghi nhanh hơn nhiều so với làm việc với RAM và nhiều thanh ghi CPU có, ít thường xuyên hơn nó cần trao đổi giá trị đăng ký vào RAM và quay lại thanh ghi.

Để tìm hiểu xem CPU của bạn có thể chạy ở chế độ 64 bit hay không, bạn có thể xem các biến sysctl khác nhau. Ví dụ. mở một thiết bị đầu cuối và loại

sysctl machdep.cpu.extfeatures

Nếu nó liệt kê EM64T, CPU của bạn hỗ trợ không gian địa chỉ 64 bit theo chuẩn x86-64. Bạn cũng có thể tìm kiếm

sysctl hw.optional.x86_64

Nếu nó nói 1 (true / enabled), CPU của bạn hỗ trợ chế độ bit x86-64, nếu nó nói 0 (false / disabled), nó không. Nếu thiết lập không được tìm thấy ở tất cả, xem xét nó là sai.

Lưu ý: Bạn cũng có thể tìm nạp biến sysctl từ bên trong ứng dụng C gốc, không cần sử dụng công cụ dòng lệnh. Xem

man 3 sysctl

10
2017-09-25 12:34



lỗi: "machdep.cpu.extfeatures" là một khóa không xác định
Tôi đoán nó không được gọi là EM64T, cũng vậy, nếu bạn không đủ may mắn để có được intel.


Lưu ý rằng không gian địa chỉ có thể được sử dụng nhiều hơn bộ nhớ (thực). Người ta cũng có thể nhớ bản đồ các tệp lớn, có thể cải thiện hiệu năng trong các mẫu truy cập lẻ hơn vì các bước đệm bộ đệm mức VM cấp mạnh hơn và hiệu quả hơn. Nó cũng an toàn hơn khi phân bổ khối bộ nhớ lớn trên 64 bit vì bộ nhớ heapmanager ít hơn có khả năng gặp phải sự phân mảnh không gian địa chỉ mà sẽ không cho phép nó phân bổ một khối lớn.

Một số điều được nói trong chủ đề này (giống như việc tăng gấp đôi số đăng ký) chỉ áp dụng cho x86-> x86_64, chứ không áp dụng cho 64-bit nói chung. Cũng giống như thực tế rằng dưới x86_64 một đảm bảo có SSE2, 686 opcodes và một cách rẻ tiền để làm PIC. Những tính năng này hoàn toàn không phải là về 64-bit, mà là về việc cắt giảm di sản và khắc phục các hạn chế x86 đã biết

Hơn nữa, người ta thường chỉ việc tăng gấp đôi số lượng đăng ký là nguyên nhân của việc tăng tốc, trong khi nó có nhiều khả năng là sử dụng SSE2 mặc định, điều đó làm cho việc lừa (tăng tốc các chức năng memcpy và tương tự). Nếu bạn bật cùng một bộ cho x86 thì sự khác biệt sẽ nhỏ hơn. (*) (***)

Cũng nên nhớ rằng thường có một hình phạt ban đầu liên quan vì cấu trúc dữ liệu trung bình sẽ tăng lên đơn giản vì kích thước của một con trỏ lớn hơn. Điều này cũng có hiệu ứng bộ nhớ cache, nhưng đáng chú ý hơn trong thực tế là memcpy trung bình () (hoặc bất cứ điều gì tương đương với bản sao bộ nhớ là ngôn ngữ của bạn) sẽ mất nhiều thời gian hơn. Điều này chỉ ở độ lớn của một vài phần trăm btw, nhưng các tăng tốc có tên ở trên cũng ở độ lớn đó.

Thông thường căn chỉnh trên không cũng lớn hơn trên các kiến ​​trúc 64-bit (các bản ghi trước đây 32-bit chỉ thường trở thành một kết hợp của các giá trị 32-bit và 64-bit), thổi lên các cấu trúc nhiều hơn.

Nhìn chung, các thử nghiệm đơn giản của tôi cho thấy chúng sẽ loại bỏ triệt để nhau, nếu các trình điều khiển và thư viện thời gian chạy hoàn toàn thích nghi, không có sự khác biệt về tốc độ đáng kể cho ứng dụng trung bình. Tuy nhiên, một số ứng dụng đột nhiên có thể nhanh hơn (ví dụ: tùy thuộc vào AES) hoặc chậm hơn (cơ sở hạ tầng quan trọng được di chuyển liên tục / quét / đi và chứa nhiều con trỏ). Các thử nghiệm đã được trên Windows mặc dù, và do đó tối ưu hóa PIC đã không được chuẩn.

Lưu ý rằng hầu hết các ngôn ngữ JIT-VM (Java, .NET) sử dụng số lượng con trỏ trung bình đáng kể (nội bộ) hơn ví dụ. C ++. Có lẽ việc sử dụng bộ nhớ của họ tăng nhiều hơn cho chương trình trung bình, nhưng tôi không dám đánh đồng trực tiếp vào hiệu ứng chậm (vì đây thực sự là những con quái vật phức tạp và sôi nổi và thường khó dự đoán mà không đo lường)

(*) một thực tế ít được biết đến là số lượng thanh ghi SSE cũng tăng gấp đôi trong chế độ 64 bit

(**) Tiến sĩ Dobbs đã có một bài viết hay về nó cách đây vài năm.


9
2018-05-01 21:19





Bên cạnh những vấn đề không gian nhớ rõ ràng mà hầu hết mọi người đang đề cập ở đây, tôi nghĩ rằng nó đáng xem xét khái niệm "tính toán từ rộng" mà Knuth (trong số những người khác) đã nói về thời gian gần đây. Có rất nhiều hiệu quả để đạt được thông qua thao tác bit, và hoạt động bitwise trên một từ 64 bit đi xa hơn rất nhiều so với từ 32 bit. Tóm lại, bạn có thể thực hiện nhiều thao tác hơn trong thanh ghi mà không cần phải nhấn bộ nhớ, và từ góc độ hiệu suất, đó là một chiến thắng khá lớn.

Hãy xem Volume 4, pre-Fascicle 1A cho một số ví dụ về các thủ thuật thú vị mà tôi đang nói đến.


8
2017-09-25 12:36





Ngoài khả năng giải quyết thêm bộ nhớ x86_64 cũng có nhiều thanh ghi hơn cho phép trình biên dịch tạo ra mã hiệu quả hơn. Cải thiện hiệu suất thường sẽ khá nhỏ.

Kiến trúc x86_64 tương thích ngược với x86. Có thể chạy các hệ điều hành 32 bit chưa sửa đổi. Cũng có thể chạy phần mềm 32 bit chưa sửa đổi từ hệ điều hành 64 bit. Điều đó sẽ yêu cầu tất cả các thư viện 32-bit thông thường. Chúng có thể cần được cài đặt riêng.


7
2017-10-17 11:29



Đăng ký nhiều hơn, và một ABI được thiết kế lại (chức năng đi qua args trong đăng ký) thường là 10 đến 15% tốc độ, đó là khá tốt. Hiện tại có một x32 Linux ABI với các con trỏ 32 bit, nhưng sử dụng chế độ dài amd64, và các công cụ gọi điện của args-in-register. Vì vậy, bạn có tất cả các lợi ích tốc độ của amd64, nhưng không có chi phí cần 64bits cho mỗi con trỏ. Nó tốt cho mọi thứ không cần> 4GB bộ nhớ (ảo). - Peter Cordes