Có gợi ý trình biên dịch nào cho GCC để buộc dự đoán rẽ nhánh luôn đi theo một cách nhất định không?

Đối với kiến ​​trúc Intel, có cách nào để hướng dẫn trình biên dịch GCC tạo mã luôn buộc dự đoán nhánh theo một cách cụ thể trong mã của tôi không? Phần cứng Intel có hỗ trợ điều này không? Điều gì về các trình biên dịch hoặc phần cứng khác?

Tôi sẽ sử dụng điều này trong mã C ++, nơi tôi biết trường hợp tôi muốn chạy nhanh và không quan tâm đến việc chạy chậm lại khi nhánh khác cần được thực hiện ngay cả khi nó gần đây đã sử dụng nhánh đó.

for (;;) {
  if (normal) { // How to tell compiler to always branch predict true value?
    doSomethingNormal();
  } else {
    exceptionalCase();
  }
}

Như một câu hỏi tiếp theo dành cho Evdzhan Mustafa, liệu gợi ý có thể chỉ định một gợi ý cho lần đầu tiên bộ xử lý gặp lệnh, tất cả dự đoán nhánh tiếp theo, hoạt động bình thường không?

Kể từ C ++ 20, các thuộc tính có thể xảy ra và không thể xảy ra nên được chuẩn hóa và đã được hỗ trợ trong g ++ 9 . Vì vậy, như đã thảo luận ở đây , bạn có thể viết

if (a>b) {
  /* code you expect to run often */
  [[likely]] /* last statement */
}

Ví dụ: trong đoạn mã sau, khối else được nội tuyến nhờ vào [[unlikely]]khối if

int oftendone( int a, int b );
int rarelydone( int a, int b );
int finaltrafo( int );

int divides( int number, int prime ) {
  int almostreturnvalue;
  if ( ( number % prime ) == 0 ) {
    auto k                         = rarelydone( number, prime );
    auto l                         = rarelydone( number, k );
    [[unlikely]] almostreturnvalue = rarelydone( k, l );
  } else {
    auto a            = oftendone( number, prime );
    almostreturnvalue = oftendone( a, a );
  }
  return finaltrafo( almostreturnvalue );
}

liên kết chốt thần so sánh sự hiện diện / vắng mặt của thuộc tính

GCC hỗ trợ chức năng __builtin_expect(long exp, long c)cung cấp loại tính năng này. Bạn có thể kiểm tra tài liệu tại đây .

Trong trường hợp explà điều kiện sử dụng và clà giá trị kỳ vọng. Ví dụ trong trường hợp bạn muốn

if (__builtin_expect(normal, 1))

Do cú pháp khó hiểu, điều này thường được sử dụng bằng cách xác định hai macro tùy chỉnh như

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

chỉ để giảm bớt nhiệm vụ.

Nhớ rằng:

1. cái này không chuẩn
2. một trình dự đoán nhánh của trình biên dịch / cpu có thể có nhiều kỹ năng hơn bạn trong việc quyết định những điều như vậy, vì vậy đây có thể là một sự tối ưu hóa vi mô sớm

gcc có __builtin_expect dài (kinh nghiệm dài, c dài) ( tôi nhấn mạnh ):

Bạn có thể sử dụng __builtin_expect để cung cấp cho trình biên dịch thông tin dự đoán nhánh. Nói chung, bạn nên sử dụng phản hồi hồ sơ thực tế cho điều này (-fprofile-arcs), vì các lập trình viên nổi tiếng là tệ trong việc dự đoán chương trình của họ thực sự hoạt động như thế nào . Tuy nhiên, có những ứng dụng khó thu thập dữ liệu này.

Giá trị trả về là giá trị của exp, phải là một biểu thức tích phân. Ngữ nghĩa của tích hợp được mong đợi là exp == c. Ví dụ:

if (__builtin_expect (x, 0))
   foo ();

chỉ ra rằng chúng ta không mong đợi gọi foo, vì chúng ta mong đợi x bằng 0. Vì bạn bị giới hạn trong các biểu thức tích phân cho exp, bạn nên sử dụng các cấu trúc như

if (__builtin_expect (ptr != NULL, 1))
   foo (*ptr);

khi kiểm tra giá trị con trỏ hoặc dấu phẩy động.

Như tài liệu lưu ý, bạn nên thích sử dụng phản hồi hồ sơ thực tế hơn và bài viết này cho thấy một ví dụ thực tế về điều này và cách nó trong trường hợp của họ ít nhất kết thúc là một sự cải tiến so với việc sử dụng __builtin_expect. Ngoài ra, hãy xem Cách sử dụng tối ưu hóa có hướng dẫn hồ sơ trong g ++? .

Chúng tôi cũng có thể tìm thấy một bài báo dành cho người mới nhân Linux về các macro kernal có khả năng () và không thể () sử dụng tính năng này:

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

Lưu ý việc !!sử dụng trong macro, chúng ta có thể tìm thấy lời giải thích cho điều này trong Tại sao sử dụng !! (điều kiện) thay vì (điều kiện)? .

Chỉ vì kỹ thuật này được sử dụng trong nhân Linux không có nghĩa là sử dụng nó lúc nào cũng hợp lý. Chúng ta có thể thấy từ câu hỏi này mà gần đây tôi đã trả lời sự khác biệt giữa hiệu suất hàm khi truyền tham số là hằng số thời gian biên dịch hoặc biến mà nhiều kỹ thuật tối ưu hóa cuộn thủ công không hoạt động trong trường hợp chung. Chúng ta cần lập hồ sơ mã cẩn thận để hiểu liệu một kỹ thuật có hiệu quả hay không. Nhiều kỹ thuật cũ thậm chí có thể không phù hợp với tối ưu hóa trình biên dịch hiện đại.

Lưu ý, mặc dù nội trang không di động nhưng cũng hỗ trợ __builtin_expect .

Ngoài ra trên một số kiến trúc, nó có thể không tạo ra sự khác biệt .

Không có. (Ít nhất là trên bộ xử lý x86 hiện đại.)

__builtin_expectđược đề cập trong các câu trả lời khác ảnh hưởng đến cách gcc sắp xếp mã lắp ráp. Nó không ảnh hưởng trực tiếp đến dự đoán nhánh của CPU. Tất nhiên, sẽ có những ảnh hưởng gián tiếp đến dự đoán rẽ nhánh do sắp xếp lại mã. Nhưng trên các bộ vi xử lý x86 hiện đại, không có lệnh nào cho CPU biết "giả sử nhánh này được / không được sử dụng".

Xem câu hỏi này để biết thêm chi tiết: Dự đoán nhánh tiền tố Intel x86 0x2E / 0x3E thực sự được sử dụng?

Nói rõ hơn, __builtin_expectvà / hoặc việc sử dụng -fprofile-arcs có thể cải thiện hiệu suất mã của bạn, bằng cách đưa ra gợi ý cho bộ dự đoán nhánh thông qua bố cục mã (xem Tối ưu hóa hiệu suất của lắp ráp x86-64 - Căn chỉnh và dự đoán nhánh ), đồng thời cũng cải thiện hành vi của bộ đệm bằng cách giữ mã "không chắc" tránh xa mã "có thể xảy ra".

Cách chính xác để xác định các macro có khả năng xảy ra / không chắc chắn trong C ++ 11 là như sau:

#define LIKELY(condition) __builtin_expect(static_cast<bool>(condition), 1)
#define UNLIKELY(condition) __builtin_expect(static_cast<bool>(condition), 0)

Phương pháp này tương thích với tất cả các phiên bản C ++, không giống như [[likely]], nhưng dựa vào phần mở rộng không chuẩn __builtin_expect.

Khi các macro này xác định theo cách này:

#define LIKELY(condition) __builtin_expect(!!(condition), 1)

Điều đó có thể thay đổi ý nghĩa của các ifcâu lệnh và phá vỡ mã. Hãy xem xét đoạn mã sau:

#include <iostream>

struct A
{
    explicit operator bool() const { return true; }
    operator int() const { return 0; }
};

#define LIKELY(condition) __builtin_expect((condition), 1)

int main() {
    A a;
    if(a)
        std::cout << "if(a) is true\n";
    if(LIKELY(a))
        std::cout << "if(LIKELY(a)) is true\n";
    else
        std::cout << "if(LIKELY(a)) is false\n";
}

Và đầu ra của nó:

if(a) is true
if(LIKELY(a)) is false

Như bạn có thể thấy, định nghĩa của LIKELY sử dụng !!như một diễn viên để boolphá vỡ ngữ nghĩa của if.

Vấn đề ở đây không phải là điều đó operator int()và operator bool()nên có liên quan. Đó là thực hành tốt.

Thay vì sử dụng !!(x)thay vì static_cast<bool>(x)làm mất ngữ cảnh cho các chuyển đổi theo ngữ cảnh C ++ 11 .

Vì các câu trả lời khác đều đã được gợi ý đầy đủ, bạn có thể sử dụng __builtin_expectđể cung cấp cho trình biên dịch một gợi ý về cách sắp xếp mã hợp ngữ. Như các tài liệu chính thức đã chỉ ra, trong hầu hết các trường hợp, trình lắp ráp được tích hợp trong bộ não của bạn sẽ không tốt bằng trình lắp ráp do nhóm GCC chế tạo. Tốt nhất bạn nên sử dụng dữ liệu hồ sơ thực tế để tối ưu hóa mã của bạn, thay vì phỏng đoán.

Dọc theo các dòng tương tự, nhưng chưa được đề cập, là một cách cụ thể của GCC để buộc trình biên dịch tạo mã trên một đường dẫn "lạnh". Điều này liên quan đến việc sử dụng các thuộc tính noinlinevà cold, làm chính xác những gì chúng nghe giống như chúng làm. Các thuộc tính này chỉ có thể được áp dụng cho các hàm, nhưng với C ++ 11, bạn có thể khai báo các hàm lambda nội tuyến và hai thuộc tính này cũng có thể được áp dụng cho các hàm lambda.

Mặc dù điều này vẫn thuộc danh mục chung của tối ưu hóa vi mô, và do đó, lời khuyên tiêu chuẩn được áp dụng — hãy thử nghiệm đừng đoán — tôi cảm thấy nó thường hữu ích hơn __builtin_expect. Hầu như không có bất kỳ thế hệ nào của bộ xử lý x86 sử dụng gợi ý dự đoán nhánh ( tham khảo ), vì vậy điều duy nhất bạn có thể ảnh hưởng đến dù sao là thứ tự của mã lắp ráp. Vì bạn biết mã xử lý lỗi hoặc mã "trường hợp cạnh" là gì, bạn có thể sử dụng chú thích này để đảm bảo rằng trình biên dịch sẽ không bao giờ dự đoán một nhánh với nó và sẽ liên kết nó với mã "nóng" khi tối ưu hóa kích thước.

Sử dụng mẫu:

void FooTheBar(void* pFoo)
{
    if (pFoo == nullptr)
    {
        // Oh no! A null pointer is an error, but maybe this is a public-facing
        // function, so we have to be prepared for anything. Yet, we don't want
        // the error-handling code to fill up the instruction cache, so we will
        // force it out-of-line and onto a "cold" path.
        [&]() __attribute__((noinline,cold)) {
            HandleError(...);
        }();
    }

    // Do normal stuff
    ⋮
}

Thậm chí tốt hơn, GCC sẽ tự động bỏ qua điều này để hỗ trợ phản hồi hồ sơ khi nó có sẵn (ví dụ: khi biên dịch với -fprofile-use ).

Xem tài liệu chính thức tại đây: https://gcc.gnu.org/onlineocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

__builtin_expect có thể được sử dụng để cho trình biên dịch biết bạn mong đợi một nhánh đi theo hướng nào. Điều này có thể ảnh hưởng đến cách mã được tạo. Các bộ xử lý điển hình chạy mã tuần tự nhanh hơn. Vì vậy, nếu bạn viết

if (__builtin_expect (x == 0, 0)) ++count;
if (__builtin_expect (y == 0, 0)) ++count;
if (__builtin_expect (z == 0, 0)) ++count;

trình biên dịch sẽ tạo ra mã như

if (x == 0) goto if1;
back1: if (y == 0) goto if2;
back2: if (z == 0) goto if3;
back3: ;
...
if1: ++count; goto back1;
if2: ++count; goto back2;
if3: ++count; goto back3;

Nếu gợi ý của bạn là đúng, điều này sẽ thực thi mã mà không có bất kỳ nhánh nào thực sự được thực hiện. Nó sẽ chạy nhanh hơn chuỗi thông thường, trong đó mỗi câu lệnh if sẽ phân nhánh xung quanh mã điều kiện và sẽ thực thi ba nhánh.

Bộ xử lý x86 mới hơn có hướng dẫn cho các nhánh dự kiến ​​sẽ được thực hiện hoặc cho các nhánh dự kiến ​​không được thực hiện (có một tiền tố hướng dẫn; không chắc chắn về chi tiết). Không chắc liệu bộ xử lý có sử dụng cái đó hay không. Nó không hữu ích lắm, vì dự đoán rẽ nhánh sẽ xử lý điều này tốt. Vì vậy, tôi không nghĩ rằng bạn thực sự có thể ảnh hưởng đến dự đoán nhánh .

Liên quan đến OP, không, không có cách nào trong GCC để yêu cầu bộ xử lý luôn cho rằng nhánh được lấy hoặc không được sử dụng. Những gì bạn có là __builtin_expect, thực hiện những gì người khác nói. Hơn nữa, tôi nghĩ rằng bạn không muốn nói với bộ vi xử lý cho dù các chi nhánh được thực hiện hay không luôn . Các bộ vi xử lý ngày nay, chẳng hạn như kiến ​​trúc Intel có thể nhận ra các mẫu khá phức tạp và thích ứng một cách hiệu quả.

Tuy nhiên, đôi khi bạn muốn kiểm soát xem theo mặc định, một nhánh được dự đoán có được thực hiện hay không: Khi bạn biết mã sẽ được gọi là "lạnh" đối với thống kê nhánh.

Một ví dụ cụ thể: Mã quản lý ngoại lệ. Theo định nghĩa, mã quản lý sẽ xảy ra đặc biệt, nhưng có lẽ khi nó xảy ra hiệu suất tối đa là mong muốn (có thể có một lỗi nghiêm trọng cần xử lý càng sớm càng tốt), do đó bạn có thể muốn kiểm soát dự đoán mặc định.

Một ví dụ khác: Bạn có thể phân loại đầu vào của mình và nhảy vào mã xử lý kết quả phân loại của bạn. Nếu có nhiều phân loại, bộ xử lý có thể thu thập số liệu thống kê nhưng mất chúng vì việc phân loại tương tự không xảy ra đủ sớm và các nguồn dự đoán được dành cho mã được gọi gần đây. Tôi ước sẽ có một nguyên thủy để nói với bộ xử lý "vui lòng không dành tài nguyên dự đoán cho mã này" theo cách mà đôi khi bạn có thể nói "không lưu vào bộ nhớ cache này".