Bagaimana makro yang mungkin / tidak mungkin dalam kernel Linux bekerja dan apa manfaatnya?

Saya telah menggali beberapa bagian dari kernel Linux, dan menemukan panggilan seperti ini:

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

atau

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

Saya telah menemukan definisi mereka:

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

Saya tahu itu untuk optimasi, tetapi bagaimana cara kerjanya? Dan berapa banyak penurunan kinerja / ukuran yang dapat diharapkan dari menggunakannya? Dan apakah itu sepadan dengan kerumitan (dan mungkin kehilangan portabilitas) setidaknya dalam kode bottleneck (di userspace, tentu saja).

Mereka memberi petunjuk kepada kompiler untuk memancarkan instruksi yang akan menyebabkan prediksi cabang lebih menyukai sisi "kemungkinan" dari instruksi lompatan. Ini bisa menjadi kemenangan besar, jika prediksi itu benar itu berarti bahwa instruksi lompatan pada dasarnya gratis dan akan mengambil nol siklus. Di sisi lain jika prediksi salah, maka itu berarti pipa prosesor perlu memerah dan dapat menghabiskan beberapa siklus. Selama prediksi itu benar sebagian besar waktu, ini akan cenderung bagus untuk kinerja.

Seperti semua optimisasi kinerja seperti itu, Anda hanya harus melakukannya setelah profil yang luas untuk memastikan kode benar-benar tersendat, dan mungkin diberi sifat mikro, yang sedang dijalankan dalam loop yang ketat. Umumnya pengembang Linux cukup berpengalaman sehingga saya akan membayangkan mereka akan melakukan itu. Mereka tidak terlalu peduli tentang portabilitas karena mereka hanya menargetkan gcc, dan mereka memiliki ide yang sangat dekat tentang perakitan yang mereka ingin hasilkan.

Mari kita dekompilasi untuk melihat apa yang dilakukan GCC 4.8 dengan itu

Tanpa __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;
}

Kompilasi dan dekompilasi dengan GCC 4.8.2 x86_64 Linux:

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

Keluaran:

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

Urutan instruksi dalam memori tidak berubah: pertama printfdan kemudian putsdan retqkembali.

Dengan __builtin_expect

Sekarang ganti if (i)dengan:

if (__builtin_expect(i, 0))

dan kami mendapatkan:

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>

The printf(dikompilasi untuk __printf_chk) dipindahkan ke akhir fungsi, setelah putsdan kembali untuk meningkatkan prediksi cabang seperti yang disebutkan oleh jawaban lainnya.

Jadi pada dasarnya sama dengan:

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

Optimasi ini tidak dilakukan dengan -O0.

Tapi semoga berhasil menulis contoh yang berjalan lebih cepat dengan __builtin_expecttanpa, CPU benar-benar pintar hari ini . Upaya naif saya ada di sini .

C ++ 20 [[likely]]dan[[unlikely]]

C ++ 20 telah membuat standar C ++ built-in: Bagaimana cara menggunakan atribut C ++ 20 yang kemungkinan / tidak mungkin dalam pernyataan if-else Mereka kemungkinan besar (pun!) Akan melakukan hal yang sama.

Ini adalah makro yang memberikan petunjuk kepada kompiler tentang ke mana cabang bisa pergi. Makro diperluas ke ekstensi spesifik GCC, jika tersedia.

GCC menggunakan ini untuk mengoptimalkan prediksi cabang. Misalnya, jika Anda memiliki sesuatu seperti berikut ini

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

return x;

Kemudian dapat merestrukturisasi kode ini menjadi sesuatu yang lebih seperti:

if (!x) {
  return x;
}

dosomething();
return x;

Keuntungannya adalah ketika prosesor mengambil cabang pertama kali, ada overhead yang signifikan, karena mungkin telah memuat dan mengeksekusi kode secara spekulatif lebih jauh ke depan. Ketika menentukan akan mengambil cabang, maka itu harus membatalkan itu, dan mulai pada target cabang.

Sebagian besar prosesor modern sekarang memiliki semacam prediksi cabang, tetapi itu hanya membantu ketika Anda telah melalui cabang sebelumnya, dan cabang tersebut masih dalam cache prediksi cabang.

Ada sejumlah strategi lain yang dapat digunakan oleh kompiler dan prosesor dalam skenario ini. Anda dapat menemukan detail lebih lanjut tentang cara kerja peramal cabang di Wikipedia: http://en.wikipedia.org/wiki/Branch_predictor

Mereka menyebabkan kompiler untuk memancarkan petunjuk cabang yang sesuai di mana perangkat keras mendukungnya. Ini biasanya hanya berarti memutar-mutar beberapa bit dalam opcode instruksi, sehingga ukuran kode tidak akan berubah. CPU akan mulai mengambil instruksi dari lokasi yang diprediksi, dan menyiram pipa dan memulai kembali jika ternyata salah ketika cabang tercapai; dalam hal petunjuknya benar, ini akan membuat cabang lebih cepat - tepatnya seberapa cepat akan tergantung pada perangkat keras; dan seberapa banyak hal ini mempengaruhi kinerja kode akan tergantung pada proporsi waktu yang tepat.

Sebagai contoh, pada CPU PowerPC, cabang yang tidak disentuh mungkin memerlukan 16 siklus, yang salah mengisyaratkan 8 dan yang salah mengisyaratkan 24. Dalam loop terdalam, petunjuk yang baik dapat membuat perbedaan besar.

Portabilitas sebenarnya bukan masalah - mungkin definisinya ada di header per-platform; Anda dapat dengan mudah mendefinisikan "kemungkinan" dan "tidak mungkin" untuk platform yang tidak mendukung petunjuk cabang statis.

long __builtin_expect(long EXP, long C);

Konstruk ini memberi tahu kompilator bahwa ekspresi EXP kemungkinan besar akan memiliki nilai C. Nilai baliknya adalah EXP. __builtin_expect dimaksudkan untuk digunakan dalam ekspresi kondisional. Dalam hampir semua kasus, ini akan digunakan dalam konteks ekspresi boolean di mana dalam kasus ini lebih mudah untuk mendefinisikan dua makro pembantu:

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

Makro ini kemudian dapat digunakan seperti pada

if (likely(a > 1))

Referensi: https://www.akkadia.org/drepper/cpumemory.pdf

(komentar umum - jawaban lain mencakup detail)

Tidak ada alasan Anda kehilangan portabilitas dengan menggunakannya.

Anda selalu memiliki opsi untuk membuat "inline" atau makro efek nil-efek sederhana yang memungkinkan Anda untuk mengompilasi pada platform lain dengan kompiler lain.

Anda tidak akan mendapatkan manfaat dari optimasi jika Anda menggunakan platform lain.

Sesuai komentar oleh Cody , ini tidak ada hubungannya dengan Linux, tetapi merupakan petunjuk bagi kompiler. Apa yang terjadi tergantung pada versi arsitektur dan kompiler.

Fitur khusus ini di Linux agak salah digunakan dalam driver. Sebagai osgx poin di semantik atribut panas , setiap hotatau coldfungsi yang disebut dengan di blok otomatis dapat mengisyaratkan bahwa kondisi ini kemungkinan atau tidak. Misalnya, dump_stack()ditandai coldjadi ini berlebihan,

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

Versi masa depan gccmungkin selektif inline fungsi berdasarkan petunjuk ini. Ada juga saran bahwa itu bukan boolean, tetapi skor seperti dalam kemungkinan besar , dll. Secara umum, itu harus dipilih untuk menggunakan beberapa mekanisme alternatif seperti cold. Tidak ada alasan untuk menggunakannya di sembarang tempat kecuali jalur panas. Apa yang dilakukan oleh kompiler pada satu arsitektur dapat sangat berbeda pada arsitektur lainnya.

Dalam banyak rilis linux, Anda dapat menemukan complier.h di / usr / linux /, Anda dapat memasukkannya untuk digunakan secara sederhana. Dan pendapat lain, tidak mungkin () lebih bermanfaat daripada kemungkinan (), karena

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

itu dapat dioptimalkan juga di banyak kompiler.

Ngomong-ngomong, jika Anda ingin mengamati perilaku detail kode, Anda dapat melakukannya dengan mengikuti:

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

Kemudian, buka obj.s, Anda dapat menemukan jawabannya.

Mereka adalah petunjuk ke kompiler untuk menghasilkan awalan petunjuk di cabang. Pada x86 / x64, mereka membutuhkan satu byte, jadi Anda akan mendapatkan paling banyak peningkatan satu byte untuk setiap cabang. Adapun kinerja, itu sepenuhnya tergantung pada aplikasi - dalam kebanyakan kasus, prediktor cabang pada prosesor akan mengabaikan mereka, hari ini.

Sunting: Lupa tentang satu tempat yang sebenarnya bisa mereka bantu. Itu dapat memungkinkan kompiler untuk menyusun ulang grafik aliran kontrol untuk mengurangi jumlah cabang yang diambil untuk jalur 'kemungkinan'. Ini dapat memiliki peningkatan yang ditandai dalam loop di mana Anda memeriksa beberapa kasus keluar.

Ini adalah fungsi GCC untuk programmer untuk memberikan petunjuk kepada kompiler tentang apa kondisi cabang yang paling mungkin dalam ekspresi yang diberikan. Ini memungkinkan kompiler untuk membangun instruksi cabang sehingga kasus yang paling umum mengambil jumlah instruksi yang paling sedikit untuk dieksekusi.

Cara instruksi cabang dibangun bergantung pada arsitektur prosesor.