Chạy ứng dụng .NET 32 bit trong hệ điều hành 64bit, có thực sự xấu không?

Question

Tôi hiểu rằng chúng tôi có thể biên dịch một Ứng dụng .NET bằng cách nhắm mục tiêu AnyCPU, điều này sẽ gây ra chạy 32 bit trong hệ điều hành 32 bit và 64 bit trong hệ điều hành 64 bit.

Tuy nhiên, đã xảy ra lỗi được báo cáo * trên hệ điều hành 64 bit mà ứng dụng của tôi đã đưa ra lỗi và giải pháp cho điều đó, tôi cần nhắm mục tiêu x86.

Bây giờ câu hỏi của tôi: Có thực sự xấu khi nhắm mục tiêu x86 mặc dù khi mã của bạn sắp chạy trong x64 không? Chúng ta đang nói về loại hiệu suất nào? (ứng dụng của tôi là khá nhiều CPU nhưng nó thực sự khó khăn để đưa ra)

Sau khi tất cả các.NET Framework sẽ chạy trong 32bit mà âm thanh xấu cho tôi thay vì lấy sức mạnh địa chỉ đầy đủ của CPU x64 **.

* Tôi không thể nhớ lỗi nhưng giải pháp nhắm mục tiêu cụ thể đến x86 và giải quyết được sự cố.

** Tôi không chắc liệu điều đó có quan trọng hay không nhưng ứng dụng của tôi không sử dụng bất kỳ biến Int64 nào.

Answer 1

Không, không tệ; Thực tế, đối với một ứng dụng tôi đang làm việc, tôi có để nhắm mục tiêu x86 (vì nó mang lại các đối tượng COM, mà nhà cung cấp không hỗ trợ x64)

Answer 2

Tôi đã có một ứng dụng crunching số sử dụng CPU rất nhiều (brute buộc một số giải pháp). Chạy nó trên 64-bit. NET Framework (8 giây) là khoảng 4 lần nhanh hơn 32 bit (30 giây). Đó chỉ là một trường hợp duy nhất.

Answer 3

Điều bạn cần nhớ là một quá trình 32-bit để chạy trong một môi trường 64-bit, hệ thống phải làm một bản dịch địa chỉ bộ nhớ cho tất cả mọi thứ nó làm. Nó có tồi không? Nó phụ thuộc vào kịch bản. Nó chắc chắn không hiệu quả như nó có thể. Chạy một verion 32 bit của IIS trên một máy chủ x-64 là đau đớn chậm so với những gì nó có thể được. Tất cả phụ thuộc vào nhu cầu của ứng dụng của bạn là gì.

Answer 4

No. Nó sẽ chạy mà không có sự cố. Trên thực tế, chúng tôi thường thấy các ứng dụng 32 bit của chúng tôi chạy trên 64bit Vista tốt hơn so với trên Vista 32 bit, do trình quản lý bộ nhớ hệ điều hành mới hơn. Nhắm mục tiêu x86 trực tiếp sẽ hoạt động tốt. Tuy nhiên, có thể chạy tự nhiên trên 64bit sẽ có những ưu điểm khác, như khả năng truy cập nhiều bộ nhớ hơn, đăng ký nhiều hơn cho CPU, v.v., do đó, đáng để nỗ lực vào và hoạt động nếu có thể.

Answer 5

Không, không phải là xấu khi cần nhắm mục tiêu x86 trên hệ thống x64. Bạn sẽ bỏ lỡ các lợi ích x64 thêm và kết thúc chạy trong lớp mô phỏng 32 bit. Nhưng đó là tốt hơn so với bị phá vỡ hoàn toàn, và hầu hết các ứng dụng hiện có vẫn còn 32bit.

Với .Net, lý do bình thường cần làm là phụ thuộc vào một dll chỉ 32 bit gốc. Nếu bạn rời khỏi .Net của bạn nhắm mục tiêu từ bất kỳ cpu nó sẽ cố gắng để tải của bạn 32-bit dll trong chế độ 64-bit, dẫn đến một vụ tai nạn. Cuối cùng, bạn muốn di chuyển khỏi sự phụ thuộc đó để bạn có thể sử dụng chế độ 64 bit. Nhưng đối với một bản phát hành, nó sẽ không giết bạn.

Answer 6

Tôi sẽ nói cách tốt nhất để nói chắc chắn nếu để đo lường, nhưng rõ ràng nếu nó sẽ không chạy đúng thì thật khó để đo lường.

Trước hết, hãy xem có sự cố về hiệu suất hay không. Nếu có vẻ như đó là vấn đề thì hãy xem liệu bạn có thể xác định chính xác ứng dụng đó không chính xác trong ứng dụng không tuân thủ x64 hay không. Hầu hết các mã .NET phải là nền tảng độc lập, do đó, thủ phạm có khả năng nhất là bất kỳ thư viện bên trong hoặc bên thứ ba gốc nào.

Answer 7

Câu trả lời là "tùy thuộc."Nó phụ thuộc vào những gì ứng dụng của bạn làm, cho dù nó truy cập vào bộ nhớ rất nhiều hay không. Kevin là đúng: bộ vi xử lý không phải dịch địa chỉ rất nhiều, nhưng điều này có thể sẽ không làm tổn thương hiệu suất của ứng dụng của bạn quá nhiều. phần cứng hướng dẫn chủ yếu là giống nhau giữa x86 và amd64 và không có quá nhiều không hiệu quả ở đó giả sử các tác giả CLR biết những gì họ đang làm (và tôi chắc chắn rằng họ đã làm) Bạn có thể thấy một sự khác biệt hiệu suất lớn nếu bạn đang làm đồ họa thao tác, nhưng vì đây chỉ là một ứng dụng .NET, tôi không nghĩ bạn là thế. Đối với một số nhiệm vụ crunching bạn có thể nhận thấy sự khác biệt như Mehrdad đã đề cập, mặc dù tôi sẽ ngạc nhiên nếu bạn đã làm vậy. trong tất cả, tôi sẽ nói đừng lo lắng về các vấn đề hiệu suất trừ khi bạn có một ứng dụng nhạy cảm về hiệu suất. Sau đó, chỉ lo lắng về các vấn đề hiệu suất khi bạn hiểu được ứng dụng của bạn.

Answer 8

Nếu bạn sử dụng cấu trúc phân bổ, và có nhiều tính toán 64 bit (gấp đôi, dài) thì bạn sẽ thấy hiệu suất giảm do động cơ 32 bit Jit kém tiên tiến so với 64 bit.

Nếu không, phiên bản 32 bit và 64 bit của .Net có hiệu suất tương tự một cách khôn ngoan.

Và cũng nếu bạn không cần phải vượt quá giới hạn 2GB cho quá trình của bạn, bạn không cần 64 bit để giải quyết khả năng, hệ điều hành sẽ chăm sóc của điều đó cho bạn sử dụng một chế độ đặc biệt gọi là CPU Long Mode - Khả năng tương thích SubMode. (CPU thực sự đang chạy ở chế độ 64 bit, nhưng sử dụng 32 bit để giải quyết, để tương thích)

Answer 9

Có "lỗi" của bạn là mã .NET của bạn sử dụng đối tượng COM 32 bit không?

Trường hợp này thực sự có thể là một vấn đề khi chạy tiến trình .NET trên kiến ​​trúc 64 bit đã được biên dịch với cài đặt AnyCPU.

Lý do là quy trình sẽ được thực hiện dưới dạng quy trình 64 bit và bất kỳ thành phần COM nào được thực thi trong quá trình cũng phải là phiên bản 64 bit. Nếu đây không phải là trường hợp quá trình của bạn sẽ thoát.

Một giải pháp khả thi là đặt nền tảng đích của bạn thành x86.