Các chương trình 64 bit có lớn hơn và nhanh hơn các phiên bản 32 bit không?

Tôi cho rằng tôi đang tập trung vào x86, nhưng tôi thường quan tâm đến việc chuyển từ 32 lên 64 bit.

Về mặt logic, tôi có thể thấy rằng hằng số và con trỏ, trong một số trường hợp, sẽ lớn hơn nên các chương trình có khả năng lớn hơn. Và mong muốn phân bổ bộ nhớ trên ranh giới từ cho hiệu quả sẽ có nghĩa là nhiều khoảng trắng hơn giữa các lần phân bổ.

Tôi cũng đã nghe nói rằng chế độ 32 bit trên x86 phải xóa bộ nhớ cache của nó khi chuyển đổi ngữ cảnh do có thể có không gian địa chỉ 4G chồng chéo.

Vì vậy, những lợi ích thực sự của 64 bit là gì?

Và như một câu hỏi bổ sung, liệu 128 bit có còn tốt hơn không?

Biên tập:

Tôi vừa viết chương trình 32/64 bit đầu tiên của mình. Nó tạo danh sách / cây được liên kết gồm các đối tượng 16 byte (phiên bản 32b) hoặc 32 byte (phiên bản 64b) và thực hiện rất nhiều thao tác in ra stderr - không phải là một chương trình thực sự hữu ích và không phải là một cái gì đó điển hình, nhưng nó là chương trình đầu tiên của tôi.

Kích thước: 81128 (32b) v 83672 (64b) - vì vậy không có nhiều sự khác biệt

Tốc độ: 17 giây (32b) v 24 giây (64b) - chạy trên hệ điều hành 32 bit (OS-X 10.5.8)

Cập nhật:

Tôi lưu ý rằng một phiên bản lai x32 ABI (Giao diện nhị phân ứng dụng) đang được phát triển có kích thước 64b nhưng sử dụng con trỏ 32b. Đối với một số thử nghiệm, nó dẫn đến mã nhỏ hơn và thực thi nhanh hơn 32b hoặc 64b.

https://sites.google.com/site/x32abi/

Trừ khi bạn cần truy cập thêm bộ nhớ mà địa chỉ 32b sẽ cho phép bạn, nếu có thì lợi ích sẽ rất nhỏ.

Khi chạy trên CPU 64b, bạn sẽ nhận được cùng một giao diện bộ nhớ cho dù bạn đang chạy mã 32b hay 64b (bạn đang sử dụng cùng một bộ nhớ cache và cùng một BUS).

Trong khi kiến ​​trúc x64 có thêm một số thanh ghi cho phép tối ưu hóa dễ dàng hơn, điều này thường bị phản đối bởi các con trỏ thực tế hiện lớn hơn và việc sử dụng bất kỳ cấu trúc nào có con trỏ dẫn đến lưu lượng bộ nhớ cao hơn. Tôi ước tính mức tăng sử dụng bộ nhớ tổng thể cho ứng dụng 64b so với ứng dụng 32b vào khoảng 15-30%.

Tôi thường thấy tốc độ cải thiện 30% cho mã máy tính chuyên sâu trên x86-64 so với x86. Điều này rất có thể là do chúng ta có thanh ghi mục đích chung 16 x 64 bit và thanh ghi 16 x SSE thay vì thanh ghi mục đích chung 8 x 32 bit và thanh ghi 8 x SSE. Điều này xảy ra với trình biên dịch Intel ICC (11.1) trên Linux x86-64 - kết quả với các trình biên dịch khác (ví dụ: gcc) hoặc với các hệ điều hành khác (ví dụ: Windows), tất nhiên có thể khác.

Bất kể lợi ích là gì, tôi khuyên bạn nên luôn biên dịch chương trình của mình theo kích thước từ mặc định của hệ thống (32-bit hoặc 64-bit), vì nếu bạn biên dịch thư viện dưới dạng nhị phân 32-bit và cung cấp nó trên 64-bit hệ thống, bạn sẽ buộc bất kỳ ai muốn liên kết với thư viện của bạn cung cấp thư viện của họ (và bất kỳ phụ thuộc thư viện nào khác) dưới dạng nhị phân 32-bit, khi phiên bản 64-bit là mặc định có sẵn. Điều này có thể gây khá nhiều phiền toái cho mọi người. Khi nghi ngờ, hãy cung cấp cả hai phiên bản thư viện của bạn.

Đối với những lợi ích thiết thực của 64-bit ... rõ ràng nhất là bạn có được không gian địa chỉ lớn hơn, vì vậy nếu mmap một tệp, bạn có thể giải quyết nhiều tệp cùng một lúc (và tải các tệp lớn hơn vào bộ nhớ). Một lợi ích khác là, giả sử trình biên dịch thực hiện tốt công việc tối ưu hóa, nhiều phép toán số học của bạn có thể được thực hiện song song (ví dụ: đặt hai cặp số 32 bit vào hai thanh ghi và thực hiện hai phép cộng trong một phép toán cộng), và lớn các phép tính số sẽ chạy nhanh hơn. Điều đó nói rằng, toàn bộ thứ 64 bit so với 32 bit sẽ không giúp bạn về độ phức tạp tiệm cận, vì vậy nếu bạn đang tìm cách tối ưu hóa mã của mình, có lẽ bạn nên xem xét các thuật toán thay vì các yếu tố liên tục như thế này.

CHỈNH SỬA :
Vui lòng bỏ qua tuyên bố của tôi về phép cộng song song. Điều này không được thực hiện bởi một câu lệnh thêm thông thường ... Tôi đã nhầm lẫn điều đó với một số hướng dẫn được vector hóa / SSE. Một lợi ích chính xác hơn, ngoài không gian địa chỉ lớn hơn, là có nhiều thanh ghi mục đích chung hơn, có nghĩa là nhiều biến cục bộ hơn có thể được duy trì trong tệp thanh ghi CPU, truy cập nhanh hơn nhiều so với việc bạn đặt các biến trong ngăn xếp chương trình (thường có nghĩa là đi ra ngoài bộ đệm L1).

Ngoài việc có nhiều thanh ghi hơn, 64-bit có SSE2 theo mặc định. Điều này có nghĩa là bạn thực sự có thể thực hiện một số phép tính song song. Các phần mở rộng SSE cũng có các tính năng khác. Nhưng tôi đoán lợi ích chính là không phải kiểm tra sự hiện diện của các tiện ích mở rộng. Nếu là x64, nó có sẵn SSE2. ... Nếu trí nhớ của tôi phục vụ tôi một cách chính xác.

Tôi đang viết mã một công cụ cờ vua có tên là foolsmate . Việc trích xuất di chuyển tốt nhất bằng cách sử dụng tìm kiếm cây dựa trên minimax đến độ sâu 9 (từ một vị trí nhất định) đã thực hiện:

về Win32cấu hình: ~ 17.0s;

sau khi chuyển sang x64cấu hình: ~ 10.3s;

Đây là 41% của khả năng tăng tốc!

Chỉ có lý do cho việc chuyển ứng dụng của bạn sang 64 bit là cần thêm bộ nhớ trong các ứng dụng như cơ sở dữ liệu lớn hoặc ứng dụng ERP với ít nhất 100 người dùng đồng thời trong đó giới hạn 2 GB sẽ bị vượt quá khá nhanh khi ứng dụng lưu vào bộ nhớ cache để có hiệu suất tốt hơn. Đây là trường hợp đặc biệt trên hệ điều hành Windows, nơi số nguyên và dài vẫn là 32 bit (chúng có biến mới _int64. Chỉ con trỏ là 64 bit. Trên thực tế, WOW64 được tối ưu hóa cao trên Windows x64 để các ứng dụng 32 bit chạy với mức phạt thấp trên Windows 64 bit Hệ điều hành. Kinh nghiệm của tôi trên Windows x64 là phiên bản ứng dụng 32 bit chạy nhanh hơn 10-15% so với 64 bit vì trong trường hợp trước đây, ít nhất đối với cơ sở dữ liệu bộ nhớ độc quyền, bạn có thể sử dụng con trỏ arithmatic để duy trì b-tree (phần lớn bộ xử lý chuyên sâu của hệ thống cơ sở dữ liệu) . Các ứng dụng tính toán chuyên sâu yêu cầu số thập phân lớn để có độ chính xác cao nhất không được cung cấp gấp đôi trên hệ điều hành 32-64 bit. Các ứng dụng này có thể sử dụng _int64 nguyên bản thay vì mô phỏng phần mềm. Tất nhiên cơ sở dữ liệu dựa trên đĩa lớn cũng sẽ cho thấy sự cải thiện trên 32 bit chỉ đơn giản là do khả năng sử dụng bộ nhớ lớn cho các kế hoạch truy vấn bộ nhớ đệm, v.v.

Nhiều dữ liệu hơn được chuyển giữa CPU và RAM cho mỗi lần tìm nạp bộ nhớ (64 bit thay vì 32), vì vậy các chương trình 64 bit có thể nhanh hơn miễn là chúng được viết sao cho tận dụng đúng cách.

Trong trường hợp cụ thể từ x68 đến x68_64, chương trình 64 bit sẽ có cùng kích thước, nếu không muốn nói là nhỏ hơn một chút, sử dụng nhiều bộ nhớ hơn một chút và chạy nhanh hơn. Điều này chủ yếu là do x86_64 không chỉ có các thanh ghi 64 bit mà còn có số lượng nhiều gấp đôi. x86 không có đủ thanh ghi để tạo ra các ngôn ngữ đã biên dịch hiệu quả nhất có thể, vì vậy mã x86 sử dụng rất nhiều lệnh và băng thông bộ nhớ chuyển dữ liệu qua lại giữa các thanh ghi và bộ nhớ. x86_64 có ít dung lượng hơn nhiều, vì vậy nó chiếm ít dung lượng hơn một chút và chạy nhanh hơn. Dấu chấm động và hướng dẫn vectơ xoay bit cũng hiệu quả hơn nhiều trong x86_64.

Tuy nhiên, nói chung, mã 64 bit không nhất thiết phải nhanh hơn và thường lớn hơn, cho cả mã và bộ nhớ sử dụng trong thời gian chạy.

Bất kỳ ứng dụng nào yêu cầu sử dụng CPU như chuyển mã, hiệu suất hiển thị và hiển thị phương tiện, cho dù đó là âm thanh hay hình ảnh, chắc chắn sẽ yêu cầu (tại thời điểm này) và được hưởng lợi từ việc sử dụng 64 bit so với 32 bit do khả năng xử lý tuyệt đối của CPU lượng dữ liệu được ném vào nó. Vấn đề không phải là không gian địa chỉ vì nó là cách dữ liệu được xử lý. Bộ xử lý 64 bit, được cung cấp mã 64 bit, sẽ hoạt động tốt hơn, đặc biệt là với những thứ khó về mặt toán học như chuyển mã và dữ liệu VoIP - trên thực tế, bất kỳ loại ứng dụng 'toán học' nào cũng sẽ được hưởng lợi nhờ việc sử dụng CPU và hệ điều hành 64 bit. Hay chưng minh tôi sai.