(Jangan menerapkan aturan ini tanpa berpikir. Lihat poin ESR tentang lokalitas cache untuk anggota yang Anda gunakan bersama. Dan dalam program multi-utas, berhati-hatilah dalam berbagi anggota yang ditulis oleh utas yang berbeda. Umumnya Anda tidak ingin data per-utas masuk satu struct sama sekali karena alasan ini, kecuali jika Anda melakukannya untuk mengontrol pemisahan dengan alignas(128) yang besar. Ini berlaku untuk atomic dan var non-atom; yang penting adalah thread menulis ke baris cache terlepas dari bagaimana mereka melakukannya.)

Aturan praktis: terbesar hingga terkecil alignof(). Tidak ada yang dapat Anda lakukan dengan sempurna di mana pun, namun sejauh ini kasus paling umum saat ini adalah implementasi C++ normal yang wajar untuk CPU normal 32 atau 64-bit. Semua tipe primitif memiliki ukuran pangkat 2.

Kebanyakan tipe memiliki alignof(T) = sizeof(T), atau alignof(T) yang dibatasi pada lebar register implementasi. Jadi tipe yang lebih besar biasanya lebih selaras dibandingkan tipe yang lebih kecil.

Aturan pengepakan struktur di sebagian besar ABI memberi anggota struct penyelarasan alignof(T) absolut mereka relatif terhadap awal struct, dan struct itu sendiri mewarisi alignof() terbesar dari semua anggotanya.

• Utamakan anggota yang selalu 64-bit (seperti double, long long, dan int64_t). ISO C++ tentu saja tidak memperbaiki jenis ini pada 64 bit / 8 byte, tetapi dalam praktiknya pada semua CPU yang Anda pedulikan, hal tersebut berlaku. Orang yang mem-porting kode Anda ke CPU eksotik dapat mengubah tata letak struct untuk mengoptimalkannya jika diperlukan.

• lalu pointer dan bilangan bulat lebar pointer: size_t, intptr_t, dan ptrdiff_t (bisa berukuran 32 atau 64-bit). Ini semua memiliki lebar yang sama pada implementasi C++ modern normal untuk CPU dengan model memori datar.

  Pertimbangkan untuk menempatkan daftar tertaut dan penunjuk kiri/kanan pohon terlebih dahulu jika Anda peduli dengan x86 dan CPU Intel. Pengejaran pointer melalui node di pohon atau daftar tertaut memiliki penalti ketika alamat awal struct berada di halaman 4k berbeda dari anggota yang Anda akses. Mendahulukan mereka menjamin hal itu tidak akan terjadi.

• lalu long (yang terkadang 32-bit meskipun pointernya 64-bit, di ABI LLP64 seperti Windows x64). Tapi dijamin setidaknya selebar int.

• lalu 32-bit int32_t, int, float, enum. (Secara opsional, pisahkan int32_t dan float di depan int jika Anda peduli dengan kemungkinan sistem 8/16-bit yang masih memasukkan tipe tersebut ke 32-bit, atau bekerja lebih baik dengan penyelarasan alaminya. Sebagian besar sistem seperti itu tidak memiliki beban yang lebih luas (FPU atau SIMD) jadi tipe yang lebih luas harus ditangani sebagai beberapa bagian terpisah sepanjang waktu).

  ISO C++ memungkinkan int menjadi sesempit 16 bit, atau lebar sewenang-wenang, namun dalam praktiknya, ini adalah tipe 32-bit bahkan pada CPU 64-bit. Perancang ABI menemukan bahwa program yang dirancang untuk bekerja dengan int 32-bit hanya membuang-buang memori (dan jejak cache) jika int lebih luas. Jangan membuat asumsi yang akan menyebabkan masalah kebenaran, tapi untuk kinerja portabel Anda hanya harus benar dalam kasus normal.

  Orang yang menyetel kode Anda untuk platform eksotik dapat melakukan penyesuaian jika perlu. Jika tata letak struct tertentu sangat penting bagi kinerja, mungkin komentari asumsi dan alasan Anda di header.

• lalu short / int16_t

• lalu char / int8_t / bool

• (untuk beberapa tanda bool, terutama jika sebagian besar dibaca atau jika semuanya dimodifikasi bersama-sama, pertimbangkan untuk mengemasnya dengan bitfield 1-bit.)

(Untuk tipe bilangan bulat yang tidak ditandatangani, temukan tipe bertanda tangan yang sesuai di daftar saya.)

array kelipatan 8 byte dengan tipe yang lebih sempit dapat dibuat lebih awal jika Anda menginginkannya. Namun jika Anda tidak mengetahui ukuran pasti jenisnya, Anda tidak dapat menjamin bahwa int i + char buf[4] akan mengisi slot sejajar 8 byte antara dua doubles. Tapi itu bukan asumsi yang buruk, jadi saya akan tetap melakukannya jika ada alasan (seperti lokalitas spasial dari anggota yang diakses bersama) untuk menyatukannya, bukan di akhir.

Tipe eksotik: x86-64 System V memiliki alignof(long double) = 16, namun i386 System V hanya memiliki alignof(long double) = 4, sizeof(long double) = 12. Ini adalah tipe x87 80-bit, yang sebenarnya berukuran 10 byte tetapi diisi menjadi 12 atau 16 sehingga merupakan kelipatan dari alignof-nya, sehingga memungkinkan array tanpa melanggar jaminan penyelarasan.

Dan secara umum akan menjadi lebih rumit bila anggota struct Anda sendiri merupakan agregat (struct atau gabungan) dengan sizeof(x) != alignof(x).

Perubahan lainnya adalah di beberapa ABI (misalnya Windows 32-bit jika saya ingat dengan benar) anggota struct diselaraskan dengan ukurannya (hingga 8 byte) relatif terhadap awal struct, meskipun alignof(T) adalah masih hanya 4 untuk double dan int64_t.
Hal ini untuk mengoptimalkan kasus umum alokasi terpisah memori selaras 8-byte untuk satu struct, tanpa memberikan jaminan keselarasan. i386 System V juga memiliki alignof(T) = 4 yang sama untuk sebagian besar tipe primitif (tetapi malloc masih memberi Anda memori selaras 8-byte karena alignof(maxalign_t) = 8). Tapi bagaimanapun, i386 System V tidak memiliki aturan pengepakan struct, jadi (jika Anda tidak mengatur struct Anda dari yang terbesar ke terkecil) Anda bisa mendapatkan anggota 8-byte yang kurang sejajar dengan awal struct .

Kebanyakan CPU mempunyai mode pengalamatan yang, dengan adanya pointer dalam register, memungkinkan akses ke offset byte apa pun. Offset maks biasanya sangat besar, tetapi pada x86 ini menghemat ukuran kode jika offset byte cocok dengan byte yang ditandatangani ([-128 .. +127]). Jadi, jika Anda memiliki array apa pun yang besar, lebih baik meletakkannya nanti di struct setelah anggota yang sering digunakan. Meskipun ini membutuhkan sedikit biaya tambahan.

Kompiler Anda akan selalu membuat kode yang memiliki alamat struct di register, bukan alamat di tengah struct untuk memanfaatkan perpindahan negatif pendek.

Eric S. Raymond menulis artikel Seni Pengemasan Struktur yang Hilang. Khususnya bagian Penataan ulang struktur pada dasarnya adalah jawaban atas pertanyaan ini.

Dia juga menyampaikan poin penting lainnya:

9. Keterbacaan dan lokalitas cache

Meskipun menyusun ulang berdasarkan ukuran adalah cara paling sederhana untuk menghilangkan kekotoran, hal ini belum tentu merupakan hal yang benar. Ada dua masalah lagi: keterbacaan dan lokalitas cache.

Dalam struct besar yang dapat dengan mudah dipecah melintasi batas baris cache, masuk akal untuk meletakkan 2 hal di dekatnya jika keduanya selalu digunakan bersama. Atau bahkan berdekatan untuk memungkinkan penggabungan muatan/penyimpanan, mis. menyalin 8 atau 16 byte dengan satu bilangan bulat (tidak selaras) atau memuat/menyimpan SIMD alih-alih memuat anggota yang lebih kecil secara terpisah.

Baris cache biasanya berukuran 32 atau 64 byte pada CPU modern. (Pada x86 modern, selalu 64 byte. Dan keluarga Sandybridge memiliki prefetcher spasial baris yang berdekatan di cache L2 yang mencoba menyelesaikan pasangan baris 128 byte, terpisah dari detektor pola prefetch HW streamer utama L2 dan prefetching L1d).

Fakta menarik: Rust memungkinkan kompiler menyusun ulang struct untuk pengemasan yang lebih baik, atau alasan lainnya. IDK apakah ada kompiler yang benar-benar melakukan itu. Mungkin hanya mungkin dengan optimasi seluruh program link-time jika Anda ingin pilihan didasarkan pada bagaimana struct sebenarnya digunakan. Jika tidak, bagian program yang dikompilasi secara terpisah tidak dapat menyetujui tata letaknya.

(@alexis memposting jawaban hanya tautan yang tertaut ke artikel ESR, jadi terima kasih untuk titik awalnya.)

gcc memiliki peringatan -Wpadded yang memperingatkan ketika padding ditambahkan ke struktur:

https://godbolt.org/z/iwO5Q3:

<source>:4:12: warning: padding struct to align 'X::b' [-Wpadded]
    4 |     double b;
      |            ^

<source>:1:8: warning: padding struct size to alignment boundary [-Wpadded]
    1 | struct X
      |        ^

Dan Anda dapat mengatur ulang anggota secara manual sehingga paddingnya lebih sedikit/tidak ada. Tapi ini bukan solusi lintas platform, karena tipe yang berbeda dapat memiliki ukuran/penjajaran yang berbeda pada sistem yang berbeda (terutama pointer berukuran 4 atau 8 byte pada arsitektur berbeda). Aturan umumnya adalah beralih dari perataan terbesar ke terkecil saat mendeklarasikan anggota, dan jika Anda masih khawatir, kompilasi kode Anda dengan -Wpadded satu kali (Tapi saya tidak akan menyimpannya secara umum, karena padding terkadang diperlukan).

Adapun alasan mengapa compiler tidak dapat melakukannya secara otomatis adalah karena standar ([ class.mem]/19). Ini menjamin, karena ini adalah struct sederhana dengan hanya anggota publik, &x.a < &x.c (untuk beberapa X x;), sehingga tidak dapat diatur ulang.

Sebenarnya tidak ada solusi portabel dalam kasus umum. Dengan tidak adanya persyaratan minimal yang diberlakukan standar, tipe dapat berupa ukuran apa pun yang diinginkan oleh implementasi.

Selain itu, kompiler tidak diperbolehkan menyusun ulang anggota kelas agar lebih efisien. Standar ini mengamanatkan bahwa objek harus ditata sesuai urutan yang dinyatakan (dengan pengubah akses), sehingga objek tersebut juga keluar.

Anda dapat menggunakan tipe lebar tetap seperti

struct foo
{
    int64_t a;
    int16_t b;
    int8_t c;
    int8_t d;
};

dan ini akan sama di semua platform, asalkan mereka menyediakan tipe tersebut, tetapi hanya berfungsi dengan tipe integer. Tidak ada tipe floating point dengan lebar tetap dan banyak objek/kontainer standar dapat memiliki ukuran berbeda pada platform berbeda.

Ini adalah masalah memori-vs-kecepatan di buku teks. Paddingnya adalah menukar memori dengan kecepatan. Anda tidak bisa mengatakan:

Saya tidak ingin "mengemas" struct saya.

karena paket pragma adalah alat yang diciptakan untuk melakukan perdagangan ini dengan cara lain: kecepatan untuk memori.

Apakah ada cara lintas platform yang dapat diandalkan

Tidak, tidak mungkin ada. Penyelarasan sepenuhnya merupakan masalah yang bergantung pada platform. Ukuran jenis yang berbeda merupakan masalah yang bergantung pada platform. Menghindari padding dengan melakukan reorganisasi bergantung pada platform.

Kecepatan, memori, dan lintas platform - Anda hanya dapat memiliki dua.

Mengapa kompiler tidak melakukan optimasi seperti itu (menukar struct/anggota kelas untuk mengurangi padding)?

Karena spesifikasi C++ secara khusus menjamin bahwa kompiler tidak akan mengacaukan struct Anda yang telah diatur dengan cermat. Bayangkan Anda memiliki empat pelampung berturut-turut. Terkadang Anda menggunakannya berdasarkan nama, dan terkadang Anda meneruskannya ke metode yang menggunakan parameter float[3].

Anda mengusulkan agar kompiler mengacaknya, berpotensi merusak semua kode sejak tahun 1970-an. Dan untuk alasan apa? Bisakah Anda menjamin bahwa setiap programmer benar-benar ingin menyimpan 8 byte per struct Anda? Saya, misalnya, yakin bahwa jika saya memiliki array 3 GB, saya mengalami masalah yang lebih besar daripada kurang lebih satu GB.

Sobat, jika Anda memiliki data 3GB, Anda mungkin harus mengatasi masalah dengan cara lain lalu menukar anggota data.

Daripada menggunakan 'array of struct', 'struct of arrays' dapat digunakan. Jadi katakan

struct X
{
    int a;
    double b;
    int c;
};

constexpr size_t ArraySize = 1'000'000;
X my_data[ArraySize];

akan menjadi

constexpr size_t ArraySize = 1'000'000;
struct X
{
    int    a[ArraySize];
    double b[ArraySize];
    int    c[ArraySize];
};

X my_data;

Setiap elemen masih mudah diakses mydata.a[i] = 5; mydata.b[i] = 1.5f;....
Tidak ada padding (kecuali beberapa byte antar array). Tata letak memori ramah cache. Prefetcher menangani pembacaan blok memori berurutan dari beberapa wilayah memori terpisah.

Hal ini tidaklah lazim seperti yang terlihat pada pandangan pertama. Pendekatan itu banyak digunakan untuk pemrograman SIMD dan GPU.

Array Struktur (AoS), Struktur Array

Meskipun Standar memberikan keleluasaan pada penerapan untuk menyisipkan jumlah ruang yang sewenang-wenang di antara anggota struktur, hal ini karena penulis tidak ingin mencoba menebak semua situasi di mana padding mungkin berguna, dan prinsip "jangan buang ruang tanpa alasan " dianggap terbukti dengan sendirinya.

Dalam praktiknya, hampir setiap implementasi umum untuk perangkat keras biasa akan menggunakan objek primitif yang ukurannya merupakan pangkat dua, dan penyelarasan yang diperlukan adalah pangkat dua yang tidak lebih besar dari ukurannya. Selanjutnya, hampir setiap implementasi seperti itu akan menempatkan setiap anggota suatu struct pada kelipatan pertama yang tersedia dari penyelarasannya yang sepenuhnya mengikuti anggota sebelumnya.

Beberapa orang yang suka bertele-tele akan mengatakan bahwa kode yang mengeksploitasi perilaku itu adalah "non-portabel". Kepada mereka aku akan membalasnya

Kode C bisa bersifat non-portabel. Meskipun Komite C89 berupaya memberikan kesempatan kepada pemrogram untuk menulis program yang benar-benar portabel, Komite C89 tidak ingin memaksa pemrogram untuk menulis program yang portabel, untuk menghalangi penggunaan C sebagai “assembler tingkat tinggi”: kemampuan untuk menulis kode spesifik mesin adalah hal yang tidak dapat dilakukan. salah satu kelebihan C.

Sebagai sedikit perluasan dari prinsip tersebut, kemampuan kode yang hanya perlu dijalankan pada 90% mesin untuk mengeksploitasi fitur-fitur yang umum pada 90% mesin tersebut--walaupun kode tersebut tidak sepenuhnya "khusus mesin"--adalah salah satu kekuatan C. Gagasan bahwa pemrogram C tidak boleh diharapkan untuk berusaha sekuat tenaga untuk mengakomodasi keterbatasan arsitektur yang selama beberapa dekade hanya digunakan di museum seharusnya sudah jelas, namun ternyata tidak.

Anda dapat menggunakan #pragma pack(1), namun alasan utamanya adalah karena kompilernya mengoptimalkan. Mengakses variabel melalui register lengkap lebih cepat daripada mengaksesnya hingga bit terkecil.

Pengepakan khusus hanya berguna untuk serialisasi dan kompatibilitas interkompiler, dll.

Seperti yang ditambahkan NathanOliver dengan benar, ini bahkan mungkin gagal di beberapa platform .