Czy Rust może zoptymalizować kopie bitowe podczas ruchu obiektu w przyszłości?

Question

Rozważmy fragment

struct Foo { 
    dummy: [u8; 65536], 
} 

fn bar(foo: Foo) { 
    println!("{:p}", &foo) 
} 

fn main() { 
    let o = Foo { dummy: [42u8; 65536] }; 
    println!("{:p}", &o); 
    bar(o); 
} 

Typowym result programu jest

0x7fffc1239890 
0x7fffc1229890 

gdzie adresy są różne.

Wygląda na to, że duża tablica dummy została skopiowana zgodnie z oczekiwaniami w implementacji przenoszenia kompilatora. Niestety, może to mieć nietrywialny wpływ na wydajność, ponieważ dummy jest bardzo dużą tablicą. Ten wpływ może zmusić ludzi do wyboru argumentu przekazującego przez odniesienie, nawet jeśli funkcja faktycznie "konsumuje" argument koncepcyjnie.

Od Foo nie pochodzi Copy, obiekt o jest przesuwany. Ponieważ Rust zabrania dostępu do przeniesionego obiektu, co uniemożliwia bar "ponowne użycie" oryginalnego obiektu o, zmuszając kompilator do wygenerowania potencjalnie drogiej kopii bitowej? Czy istnieje zasadnicza trudność, czy też zobaczymy, że kompilator kiedyś zoptymalizuje tę bitową kopię?

Answer 1

Biorąc pod uwagę, że w Rust (w przeciwieństwie do C lub C++) na adres o wartości nie jest uważana za ważne, nie ma nic w kategoriach języku który zapobiega elizja kopii.

Jednak dzisiaj rustc niczego nie optymalizuje: wszystkie optymalizacje są delegowane do LLVM i wydaje się, że trafiłeś w ograniczenie optymalizatora LLVM tutaj (nie jest jasne, czy to ograniczenie jest spowodowane tym, że LLVM jest blisko semantyki C lub jest tylko pominięcie).

Tak, istnieją dwie drogi poprawy generowania kodu dla tego:

• nauczanie LLVM do wykonywania tej optymalizacji (jeśli to możliwe)
• nauczania rustc aby wykonać tę optymalizację (przechodzi optymalizacji idą rustc teraz że ma MIR)

, ale na razie możesz po prostu chcieć uniknąć przydzielania tak dużych obiektów na stosie, na przykład możesz to zrobić za pomocą Box.