C# jitter cải tiến trong các phiên bản framework tương lai

Question

Tôi nhận thấy rằng trình tạo mã C# tạo ra mã chậm hơn so với trình biên dịch C++, ngay cả khi không có cấu trúc "quản lý trên đầu" được sử dụng (chẳng hạn như các mảng có đánh chỉ mục đã chọn).

Để lượng hóa nó, tôi timed vòng lặp sau đây đơn giản:

public static int count = 1000000000; 
public static int Main() 
{ 
    int j = 0; 
    for (int i = 0; i < count; ++i) 
    { 
     j += (i % 2 == 0) ? ((i + 7) >> 3) : (i * 7); 
    } 
    return j; 
} 

vòng lặp này có 3.88s để thực hiện (biên soạn với/o). Vòng lặp tương đương được biên dịch với VC 2010 (-O2) mất 2,95 giây.

Để xác minh rằng mã kém thực sự được tạo, tôi đã so sánh mã máy: tạo danh sách (/ FA) từ trình biên dịch VC và đính kèm trình gỡ lỗi vào chương trình C# (sau khi kết thúc vòng lặp).

Thật vậy, phiên bản C++ đang sử dụng một số thủ thuật thông minh. Ví dụ để tránh phép nhân tốn kém bằng 7, có một thanh ghi riêng biệt được tăng lên 7 mỗi lần đếm vòng lặp. C# phiên bản hiện nhân (imul) mỗi lần. Có những khác biệt khác nữa.

Tôi hiểu rằng C# jitter có ít thời gian hơn nhiều để biên dịch mã trong thời gian chạy hơn VC tại thời gian xây dựng. Nhưng ví dụ: Java jitter là tự động tối ưu hóa các phương pháp thường được sử dụng. C# dường như không làm điều đó.

Câu hỏi của tôi là: đang có kế hoạch cải thiện trình khởi chạy C# trong các phiên bản khuôn khổ trong tương lai không?

Answer 1

đang có kế hoạch cải thiện trình khởi chạy C# trong các phiên bản khuôn khổ trong tương lai không?

Bạn có hỏi thực tế có một cuộc họp bí mật vào tháng trước giữa Microsoft và Xamarin hay không, trong khi cả hai đã dành cả thập kỷ qua để cải thiện người chơi tương ứng, làm cho mọi thứ tốt hơn, và sẽ không bận tâm nữa, và MS sẽ tái chỉ định tất cả mọi người trong khi Xamarin sẽ từ chối bất kỳ bản vá được gửi để cải thiện jitter?

Tôi muốn nói rằng điều này là không thể, và giống như mọi dự án phần mềm được phát triển tích cực khác trên thế giới, có những kế hoạch để cải thiện nó.

Bên cạnh đó, nếu tôi thực sự muốn chạy mã bạn đã cung cấp càng nhanh càng tốt, tôi sẽ tối ưu hóa nó thành return 161315136;. Mã như vậy có thể chứng minh rằng việc thực hiện A chậm hơn so với triển khai B trong một trường hợp cụ thể, nhưng không nói gì về nơi mà những người đứng đằng sau một trong hai triển khai nên tập trung nỗ lực của họ.

Answer 2

phát hành xây dựng, VS2008SP1, NET 3.5SP1, trung bình 10 xét nghiệm:

.NET, x86: 2.646 seconds 
C++, x86: 2.652 seconds 
.NET, x64: 2.352 seconds 
C++, x64: 2.090 seconds 

sai lầm cổ điển được giả định rằng/o rất có ý nghĩa, đo thời gian jitting, chạy debug xây dựng, thử nghiệm với trình gỡ lỗi kèm theo do đó trình tối ưu hóa jitter bị tắt.

Các x64 jitter sử dụng thủ thuật tương tự như bạn đã đề cập, nó không phải là duy nhất để mã máy phát điện C++:

00000030 xor   r9d,r9d 
... 
00000059 add   r9d,7 

Một tính năng mới cho .NET 4.5 là sơ Tối ưu hóa hướng dẫn.

Các kế hoạch trong tương lai không bao giờ được chia sẻ bởi một công ty như Microsoft và không có điểm nào để đoán chúng.