Làm thế nào để các macro có khả năng / không có khả năng trong nhân Linux hoạt động và lợi ích của chúng là gì?

Tôi đã đào qua một số phần của nhân Linux và tìm thấy các cuộc gọi như thế này:

if (unlikely(fd < 0))
{
    /* Do something */
}

hoặc là

if (likely(!err))
{
    /* Do something */
}

Tôi đã tìm thấy định nghĩa của chúng:

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

Tôi biết rằng chúng là để tối ưu hóa, nhưng chúng hoạt động như thế nào? Và có thể giảm bao nhiêu hiệu suất / kích thước từ việc sử dụng chúng? Và nó có đáng để phiền phức (và có thể mất tính di động) ít nhất là trong mã tắc nghẽn (tất nhiên là trong không gian người dùng).

Chúng là gợi ý cho trình biên dịch để phát ra các hướng dẫn sẽ khiến dự đoán nhánh nghiêng về phía "có khả năng" của lệnh nhảy. Đây có thể là một chiến thắng lớn, nếu dự đoán là chính xác, điều đó có nghĩa là lệnh nhảy về cơ bản là miễn phí và sẽ không có chu kỳ. Mặt khác, nếu dự đoán sai, điều đó có nghĩa là đường ống xử lý cần phải được xóa và nó có thể tốn vài chu kỳ. Miễn là dự đoán là chính xác hầu hết thời gian, điều này sẽ có xu hướng tốt cho hiệu suất.

Giống như tất cả các tối ưu hóa hiệu suất như vậy, bạn chỉ nên thực hiện sau khi định hình mở rộng để đảm bảo mã thực sự bị tắc nghẽn và có thể có tính chất vi mô, rằng nó đang được chạy trong một vòng lặp chặt chẽ. Nói chung các nhà phát triển Linux khá có kinh nghiệm nên tôi sẽ tưởng tượng họ sẽ làm điều đó. Họ không thực sự quan tâm quá nhiều đến tính di động khi họ chỉ nhắm mục tiêu gcc và họ có một ý tưởng rất gần gũi về hội đồng mà họ muốn nó tạo ra.

Hãy dịch ngược để xem GCC 4.8 làm gì với nó

Không có __builtin_expect

#include "stdio.h"
#include "time.h"

int main() {
    /* Use time to prevent it from being optimized away. */
    int i = !time(NULL);
    if (i)
        printf("%d\n", i);
    puts("a");
    return 0;
}

Biên dịch và dịch ngược với GCC 4.8.2 x86_64 Linux:

gcc -c -O3 -std=gnu11 main.c
objdump -dr main.o

Đầu ra:

0000000000000000 <main>:
   0:       48 83 ec 08             sub    $0x8,%rsp
   4:       31 ff                   xor    %edi,%edi
   6:       e8 00 00 00 00          callq  b <main+0xb>
                    7: R_X86_64_PC32        time-0x4
   b:       48 85 c0                test   %rax,%rax
   e:       75 14                   jne    24 <main+0x24>
  10:       ba 01 00 00 00          mov    $0x1,%edx
  15:       be 00 00 00 00          mov    $0x0,%esi
                    16: R_X86_64_32 .rodata.str1.1
  1a:       bf 01 00 00 00          mov    $0x1,%edi
  1f:       e8 00 00 00 00          callq  24 <main+0x24>
                    20: R_X86_64_PC32       __printf_chk-0x4
  24:       bf 00 00 00 00          mov    $0x0,%edi
                    25: R_X86_64_32 .rodata.str1.1+0x4
  29:       e8 00 00 00 00          callq  2e <main+0x2e>
                    2a: R_X86_64_PC32       puts-0x4
  2e:       31 c0                   xor    %eax,%eax
  30:       48 83 c4 08             add    $0x8,%rsp
  34:       c3                      retq

Thứ tự lệnh trong bộ nhớ không thay đổi: đầu tiên printfvà sau đó putsvà retqtrả về.

Với __builtin_expect

Bây giờ thay thế if (i)bằng:

if (__builtin_expect(i, 0))

và chúng tôi nhận được:

0000000000000000 <main>:
   0:       48 83 ec 08             sub    $0x8,%rsp
   4:       31 ff                   xor    %edi,%edi
   6:       e8 00 00 00 00          callq  b <main+0xb>
                    7: R_X86_64_PC32        time-0x4
   b:       48 85 c0                test   %rax,%rax
   e:       74 11                   je     21 <main+0x21>
  10:       bf 00 00 00 00          mov    $0x0,%edi
                    11: R_X86_64_32 .rodata.str1.1+0x4
  15:       e8 00 00 00 00          callq  1a <main+0x1a>
                    16: R_X86_64_PC32       puts-0x4
  1a:       31 c0                   xor    %eax,%eax
  1c:       48 83 c4 08             add    $0x8,%rsp
  20:       c3                      retq
  21:       ba 01 00 00 00          mov    $0x1,%edx
  26:       be 00 00 00 00          mov    $0x0,%esi
                    27: R_X86_64_32 .rodata.str1.1
  2b:       bf 01 00 00 00          mov    $0x1,%edi
  30:       e8 00 00 00 00          callq  35 <main+0x35>
                    31: R_X86_64_PC32       __printf_chk-0x4
  35:       eb d9                   jmp    10 <main+0x10>

Các printf(biên soạn để __printf_chk) đã được chuyển đến tận cùng của hàm, sau putsvà sự trở lại để cải thiện dự đoán rẽ nhánh như đã đề cập bởi câu trả lời khác.

Vì vậy, về cơ bản nó giống như:

int main() {
    int i = !time(NULL);
    if (i)
        goto printf;
puts:
    puts("a");
    return 0;
printf:
    printf("%d\n", i);
    goto puts;
}

Tối ưu hóa này đã không được thực hiện với -O0.

Nhưng may mắn khi viết một ví dụ chạy nhanh __builtin_expecthơn không có, CPU thực sự thông minh ngày nay . Những nỗ lực ngây thơ của tôi đang ở đây .

C ++ 20 [[likely]]và[[unlikely]]

C ++ 20 đã tiêu chuẩn hóa các phần tử tích hợp C ++ đó: Cách sử dụng thuộc tính có khả năng / không có khả năng của C ++ 20 trong câu lệnh if-other Họ có thể (một cách chơi chữ!) Làm điều tương tự.

Đây là các macro cung cấp gợi ý cho trình biên dịch về cách một nhánh có thể đi. Các macro mở rộng sang các tiện ích mở rộng cụ thể của GCC, nếu chúng có sẵn.

GCC sử dụng những điều này để tối ưu hóa cho dự đoán chi nhánh. Ví dụ, nếu bạn có một cái gì đó như sau

if (unlikely(x)) {
  dosomething();
}

return x;

Sau đó, nó có thể cấu trúc lại mã này thành một cái gì đó giống như:

if (!x) {
  return x;
}

dosomething();
return x;

Lợi ích của việc này là khi bộ xử lý lần đầu tiên có một nhánh, sẽ có chi phí đáng kể, bởi vì nó có thể đã được tải và thực thi mã theo cách đặc biệt hơn nữa. Khi nó xác định nó sẽ lấy nhánh, thì nó phải làm mất hiệu lực của nó và bắt đầu tại mục tiêu nhánh.

Hầu hết các bộ xử lý hiện đại hiện nay đều có một số loại dự đoán nhánh, nhưng nó chỉ hỗ trợ khi bạn đã đi qua nhánh trước đó và nhánh vẫn nằm trong bộ đệm dự đoán nhánh.

Có một số chiến lược khác mà trình biên dịch và bộ xử lý có thể sử dụng trong các tình huống này. Bạn có thể tìm thêm chi tiết về cách các công cụ dự đoán chi nhánh hoạt động tại Wikipedia: http://en.wikipedia.org/wiki/Branch_predictor

Chúng làm cho trình biên dịch phát ra các gợi ý nhánh thích hợp nơi phần cứng hỗ trợ chúng. Điều này thường chỉ có nghĩa là xoay một vài bit trong opcode lệnh, vì vậy kích thước mã sẽ không thay đổi. CPU sẽ bắt đầu tìm nạp các hướng dẫn từ vị trí dự đoán, và làm sạch đường ống và bắt đầu lại nếu điều đó bị sai khi đạt được nhánh; trong trường hợp gợi ý là chính xác, điều này sẽ làm cho nhánh nhanh hơn nhiều - chính xác là phụ thuộc vào phần cứng nhanh hơn bao nhiêu; và mức độ này ảnh hưởng đến hiệu suất của mã sẽ phụ thuộc vào tỷ lệ gợi ý thời gian là chính xác.

Ví dụ, trên CPU PowerPC, một nhánh không định hướng có thể mất 16 chu kỳ, một 8 gợi ý chính xác và một gợi ý không chính xác 24. Trong các vòng lặp trong cùng, gợi ý tốt có thể tạo ra sự khác biệt lớn.

Tính di động không thực sự là một vấn đề - có lẽ định nghĩa nằm trong tiêu đề trên mỗi nền tảng; bạn chỉ có thể định nghĩa "có khả năng" và "không thể" thành không có gì cho các nền tảng không hỗ trợ gợi ý nhánh tĩnh.

long __builtin_expect(long EXP, long C);

Cấu trúc này cho trình biên dịch biết rằng biểu thức EXP rất có thể sẽ có giá trị C. Giá trị trả về là EXP. __builtin_Exect có nghĩa là được sử dụng trong một biểu thức điều kiện. Trong hầu hết các trường hợp, nó sẽ được sử dụng trong ngữ cảnh của các biểu thức boolean trong trường hợp đó sẽ thuận tiện hơn nhiều khi định nghĩa hai macro trợ giúp:

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

Các macro này sau đó có thể được sử dụng như trong

if (likely(a > 1))

Tham khảo: https://www.akkadia.org/drepper/cpumemory.pdf

(nhận xét chung - câu trả lời khác bao gồm các chi tiết)

Không có lý do gì mà bạn nên mất tính di động bằng cách sử dụng chúng.

Bạn luôn có tùy chọn tạo một macro "nội tuyến" hoặc macro hiệu ứng đơn giản cho phép bạn biên dịch trên các nền tảng khác với các trình biên dịch khác.

Bạn sẽ không nhận được lợi ích của việc tối ưu hóa nếu bạn ở trên các nền tảng khác.

Theo nhận xét của Cody , điều này không liên quan gì đến Linux, nhưng là một gợi ý cho trình biên dịch. Điều gì xảy ra sẽ phụ thuộc vào phiên bản kiến ​​trúc và trình biên dịch.

Tính năng đặc biệt này trong Linux được sử dụng sai trong trình điều khiển. Như osgx chỉ ra trong ngữ nghĩa của thuộc tính nóng , bất kỳ hothoặc coldhàm nào được gọi trong một khối có thể tự động gợi ý rằng điều kiện có khả năng hay không. Ví dụ, dump_stack()được đánh dấu coldđể điều này là dư thừa,

 if(unlikely(err)) {
     printk("Driver error found. %d\n", err);
     dump_stack();
 }

Các phiên bản trong tương lai gcccó thể chọn lọc nội tuyến một chức năng dựa trên những gợi ý này. Cũng có ý kiến ​​cho rằng nó không phải boolean, nhưng một số điểm rất có thể , v.v ... Nói chung, nên sử dụng một số cơ chế thay thế như thế cold. Không có lý do để sử dụng nó ở bất cứ nơi nào ngoài những con đường nóng. Những gì một trình biên dịch sẽ làm trên một kiến ​​trúc có thể hoàn toàn khác nhau trên một kiến ​​trúc khác.

Trong nhiều bản phát hành linux, bạn có thể tìm thấy compier.h trong / usr / linux /, bạn có thể đưa nó vào sử dụng một cách đơn giản. Và một ý kiến ​​khác, không chắc () hữu ích hơn là có khả năng (), bởi vì

if ( likely( ... ) ) {
     doSomething();
}

nó có thể được tối ưu hóa trong nhiều trình biên dịch.

Và nhân tiện, nếu bạn muốn quan sát hành vi chi tiết của mã, bạn có thể thực hiện đơn giản như sau:

gcc -c test.c objdump -d test.o> obj.s

Sau đó, mở obj.s, bạn có thể tìm thấy câu trả lời.

Chúng gợi ý cho trình biên dịch để tạo tiền tố gợi ý trên các nhánh. Trên x86 / x64, chúng chiếm một byte, do đó, bạn sẽ nhận được nhiều nhất là tăng một byte cho mỗi nhánh. Về hiệu năng, nó hoàn toàn phụ thuộc vào ứng dụng - trong hầu hết các trường hợp, bộ dự đoán nhánh trên bộ xử lý sẽ bỏ qua chúng, những ngày này.

Chỉnh sửa: Quên về một nơi mà họ thực sự có thể giúp đỡ. Nó có thể cho phép trình biên dịch sắp xếp lại biểu đồ luồng điều khiển để giảm số lượng nhánh được lấy cho đường dẫn 'có khả năng'. Điều này có thể có một sự cải thiện rõ rệt trong các vòng lặp trong đó bạn đang kiểm tra nhiều trường hợp thoát.

Đây là các hàm GCC để lập trình viên đưa ra gợi ý cho trình biên dịch về điều kiện nhánh có khả năng nhất sẽ là gì trong một biểu thức đã cho. Điều này cho phép trình biên dịch xây dựng các hướng dẫn nhánh sao cho trường hợp phổ biến nhất sẽ lấy số lệnh ít nhất để thực thi.

Làm thế nào các hướng dẫn chi nhánh được xây dựng phụ thuộc vào kiến ​​trúc bộ xử lý.