Có thể sử dụng gợi ý nhánh trong C# không?

Question

Ví dụ, tôi biết nó được định nghĩa cho gcc và được sử dụng trong hạt nhân Linux như:

#define likely(x)  __builtin_expect((x),1) 
#define unlikely(x)  __builtin_expect((x),0) 

Nếu không có gì như thế này là có thể trong C#, là sự thay thế tốt nhất để tự sắp xếp lại nếu-tuyên bố, đưa nhất trường hợp có khả năng đầu tiên? Có cách nào khác để tối ưu hóa dựa trên loại kiến ​​thức bên ngoài này không?

Trên ghi chú liên quan, CLR biết cách xác định các điều khoản bảo vệ và giả định rằng nhánh thay thế sẽ được thực hiện, làm cho tối ưu hóa này không phù hợp để sử dụng trong các cảnh bảo vệ, đúng không?

(Lưu ý rằng tôi nhận ra điều này có thể là một vi-tối ưu hóa; Tôi chỉ quan tâm cho mục đích học tập.)

Answer 1

Câu trả lời ngắn: Số

dài trả lời: Bạn không thực sự cần trong hầu hết các trường hợp. Bạn có thể đưa ra gợi ý bằng cách thay đổi logic trong câu lệnh của bạn. Điều này dễ dàng hơn khi thực hiện với một công cụ hiệu suất, giống như công cụ được tích hợp vào các phiên bản cao hơn (và đắt tiền hơn) của Visual Studio, vì bạn có thể nắm bắt các bộ đếm chi nhánh bị lỗi. Tôi nhận ra điều này là dành cho mục đích học tập, nhưng thật tuyệt khi biết rằng JITer là rất tối ưu hóa mã của bạn cho bạn. Như một ví dụ (lấy khá nhiều nguyên văn từ CLR via C#)

Mã này:

public static void Main() { 
    Int32[] a = new Int32[5]; 
    for(Int32 index = 0; index < a.Length; index++) { 
     // Do something with a[index] 
    } 
} 

có thể dường như không hiệu quả, vì a.Length là một tài sản và như chúng ta đã biết trong C#, một tài sản thực sự là một tập hợp hai phương thức (get_Length và set_Length trong trường hợp này). Tuy nhiên, JIT biết rằng đó là một thuộc tính và lưu trữ độ dài trong một biến cục bộ cho bạn, hoặc inline phương thức, để ngăn chặn chi phí.

... một số nhà phát triển đã đánh giá thấp khả năng của trình biên dịch JIT và đã cố gắng để viết “mã thông minh” trong một nỗ lực để giúp trình biên dịch JIT . Tuy nhiên, bất kỳ nỗ lực thông minh nào mà bạn nghĩ ra sẽ gần như chắc chắn tác động tiêu cực đến hiệu suất và làm cho mã của bạn khó đọc hơn, giảm khả năng bảo trì của mã.

Trong số những thứ khác, nó thực sự đi xa hơn và không giới hạn kiểm tra một lần ngoài của vòng lặp thay vì bên trong vòng lặp, mà sẽ làm suy giảm hiệu suất.

Tôi nhận thấy nó không liên quan trực tiếp đến câu hỏi của bạn, nhưng tôi đoán điểm mà tôi đang cố gắng thực hiện là tối ưu hóa vi mô như thế này không thực sự giúp bạn nhiều trong C#, vì JIT thường nó tốt hơn, vì nó được thiết kế chính xác cho việc này. (Thực tế thú vị, trình biên dịch JIT x86 thực hiện tối ưu hóa tích cực hơn so với đối tác x64)

This article giải thích một số tối ưu hóa đã được thêm vào trong .NET 3.5 SP1, trong số đó là các cải tiến cho các nhánh thẳng để cải thiện dự đoán và vùng nhớ đệm. Tất cả điều đó được nói, nếu bạn muốn đọc một cuốn sách tuyệt vời mà đi vào những gì trình biên dịch tạo ra và hiệu suất của CLR, tôi khuyên bạn nên cuốn sách mà tôi trích dẫn từ trên, CLR thông qua C#.

EDIT: Tôi nên đề cập rằng nếu điều này hiện có thể có trong .NET, bạn có thể tìm thông tin trong số EMCA-335 standard hoặc working draft. Không có chuẩn hỗ trợ điều này và việc xem siêu dữ liệu trong một cái gì đó như IlDasm hoặc CFF Explorer không có dấu hiệu của bất kỳ siêu dữ liệu đặc biệt nào có thể gợi ý tại các dự đoán nhánh.