Perché GCC non può supporre che std :: vector :: size non cambierà in questo loop?

Ho affermato a un collega che if (i < input.size() - 1) print(0);sarebbe stato ottimizzato in questo ciclo in modo che input.size()non venisse letto in ogni iterazione, ma risulta che non è così!

void print(int x) {
    std::cout << x << std::endl;
}

void print_list(const std::vector<int>& input) {
    int i = 0;
    for (size_t i = 0; i < input.size(); i++) {
        print(input[i]);
        if (i < input.size() - 1) print(0);
    }
}

Secondo l' Explorer del compilatore con le opzioni gcc, in -O3 -fno-exceptionsrealtà stiamo leggendo input.size()ogni iterazione e usando leaper eseguire una sottrazione!

        movq    0(%rbp), %rdx
        movq    8(%rbp), %rax
        subq    %rdx, %rax
        sarq    $2, %rax
        leaq    -1(%rax), %rcx
        cmpq    %rbx, %rcx
        ja      .L35
        addq    $1, %rbx

È interessante notare che in Rust si verifica questa ottimizzazione. Sembra che ivenga sostituito con una variabile jche viene decrementata ad ogni iterazione e il test i < input.size() - 1viene sostituito con qualcosa del genere j > 0.

fn print(x: i32) {
    println!("{}", x);
}

pub fn print_list(xs: &Vec<i32>) {
    for (i, x) in xs.iter().enumerate() {
        print(*x);
        if i < xs.len() - 1 {
            print(0);
        }
    }
}

Nell'Explorer del compilatore l'assembly pertinente è simile al seguente:

        cmpq    %r12, %rbx
        jae     .LBB0_4

Ho controllato e sono abbastanza sicuro che r12sia xs.len() - 1ed rbxè il contatore. In precedenza c'è un addfor rbxe un movesterno del loop in r12.

Perchè è questo? Sembra che se GCC è in grado di incorporare size()e, operator[]come ha fatto, dovrebbe essere in grado di sapere che size()non cambia. Ma forse l'ottimizzatore di GCC ritiene che non valga la pena estrarlo in una variabile? O forse c'è qualche altro effetto collaterale che potrebbe rendere questo non sicuro - qualcuno lo sa?

La chiamata di funzione non in linea a cout.operator<<(int)è una scatola nera per l'ottimizzatore (perché la libreria è appena scritta in C ++ e tutto l'ottimizzatore vede è un prototipo; vedere la discussione nei commenti). Deve presumere che qualsiasi memoria che potrebbe essere indicata da una var globale sia stata modificata.

(O la std::endlchiamata. A proposito, perché forzare una scarica di cout a quel punto invece di stampare solo una '\n'?)

ad esempio, per quanto ne sa, std::vector<int> &inputè un riferimento a una variabile globale e una di quelle chiamate di funzione modifica quella var globale . (O c'è un globale vector<int> *ptrda qualche parte, o c'è una funzione che restituisce un puntatore a static vector<int>in qualche altra unità di compilazione, o in qualche altro modo in cui una funzione potrebbe ottenere un riferimento a questo vettore senza essere passato da un riferimento ad esso da noi.

Se avessi una variabile locale il cui indirizzo non era mai stato preso, il compilatore poteva supporre che le chiamate di funzione non in linea non potessero mutarlo. Perché non ci sarebbe modo per nessuna variabile globale di contenere un puntatore a questo oggetto. ( Questo si chiama Escape Analysis ). Ecco perché il compilatore può tenere size_t iun registro tra le chiamate di funzione. ( int ipuò essere semplicemente ottimizzato perché è ombreggiato size_t ie non utilizzato altrimenti).

Potrebbe fare lo stesso con un local vector(es. Per i puntatori base, end_size ed end_capacity.)

ISO C99 ha una soluzione per questo problema: int *restrict foo. Molti compilatori C ++ supportano la int *__restrict foopromessa che l'accesso alla memoria a cui si foofa riferimento è accessibile solo tramite quel puntatore. Più comunemente utile nelle funzioni che accettano 2 array e vuoi promettere al compilatore che non si sovrappongono. Quindi può auto-vettorializzare senza generare codice per verificarlo ed eseguire un loop di fallback.

I commenti del PO:

In Rust un riferimento non modificabile è una garanzia globale che nessun altro sta mutando il valore a cui si fa riferimento (equivalente a C ++ restrict)

Ciò spiega perché Rust può eseguire questa ottimizzazione, mentre C ++ non può.

Ottimizzare il tuo C ++

Ovviamente dovresti usare auto size = input.size();una volta nella parte superiore della tua funzione in modo che il compilatore sappia che è un invariante di loop. Le implementazioni C ++ non risolvono questo problema per te, quindi devi farlo da solo.

Potrebbe anche essere necessario const int *data = input.data();sollevare carichi del puntatore dati dal std::vector<int>"blocco di controllo". È un peccato che l'ottimizzazione possa richiedere cambiamenti di fonte molto non idiomatici.

Rust è un linguaggio molto più moderno, progettato dopo che gli sviluppatori di compilatori hanno appreso ciò che era possibile in pratica per i compilatori. Mostra anche in altri modi, tra cui l'esposizione portabile di alcune delle cose interessanti che le CPU possono fare tramite i32.count_ones, ruotare, scansionare bit, ecc. È davvero stupido che ISO C ++ non esponga ancora nessuna di queste portabilità, tranne std::bitset::count().