En något som med tiden har blivit en rejäl designmiss i C/C++ (och som helt eller delvis tyvärr kopierat av många moderna språk) är dess alias-regler. D.v.s. två argument som skickas som pekare eller referens till en funktion kan helt eller delvis referera till samma minnesregion. Resultat av detta är att det nästan är omöjligt för kompilatorn att på ett helt 100 % säkert sätt utnyttja SIMD-instruktioner (SSE/AVX på x86, NEON på ARM) för att optimera koden.
Rust har överhuvudtaget inte detta problem då semantiken i språket garanterar att det vid varje specifikt kontext bara kan finnas en enda referens/pekare med skrivmöjlighet till ett specifikt minnesområde. Det kan finnas flera referenser/pekare för läsning, men det är inte ett problem.
Redan idag ser man att Rust/LLVM är väldigt aggressiv med att lägga ut SIMD-instruktioner när man t.ex. jobbar med vektorer/arrayer.
Men finns också småvinster på lite oväntade håll
int foo(const int *a, int *b) {
if (*a < 10) {
*b = bar(a, b);
}
if (*a >= 10) {
// do something
}
}
Här känns det ju som en uppenbar optimering att läsa in det a pekar på i ett register och återanvända eller till och med förutsätta att enda körs första if-kroppen eller så körs den andra. I Rust är den optimeringen helt OK, i C och C++ är den inte det (inte heller i C#/Java om vi i stället byter ut pekare mot referens till objekt).
Orsaken är att anropet till bar(a, b) kan ändra tillståndet på det a pekar på. Endera för att a och b pekar på samma sak eller helt enkelt för att bar(a, b) ändrar på det a pekar på via någon annan mekanisk (just det senare fallet är något många funktionella språk kan förutsätta inte händer).
Angående länken. Vet du vad DPDK är? Det finns självklart fall där C kan bli snabbare om man i C implementationen helt sonika väljer att överhuvudtaget inte verifiera vissa saker som alla de andra språken gör. Trots att C fallet totalt utelämnar verifiering av att man inte läser/skriver utanför allokerat minne i ett fall som till största del enbart består i att just läsa/skriva till minnesbuffertar så presterar det väldigt nära C (och bättre än något annat språk som testas).
Det är möjligt att ignorera dessa tester även i Rust i en specifik del av koden. Kan tyckas att man inte vunnit något över C i det läget, men poängen då är att man enbart skulle göra detta på små specifika områden som man måste lägga massor med resurser på att manuellt (d.v.s. med människor) verifiera att koden är korrekt.
Omvänt, även om man försöker lägga in samma tester i C blir det ändå inte alls samma sak. Off-by-one och data-race buggar i C kommer fortfarande kompilera och även om man försöker testa för dem, vilket inte är fallet i Rust.
DPDK är speciellt då det i praktiken är ett sätt att lyfta in direktaccess till nätverkskort i "user-space". Om/när vi börjar skriva OS i Rust så kommer just drivrutiner vara ett område där man måste kliva in Rust-världens "osäkra" delar. Går helt enkelt inte att göra vissa saker som måste göras i en drivrutin utan kontrollen som finns i ASM/C/C++ (vilket är en primär orsak till varför OS fortfarande skrivs primärt i C). Men fördelen mot C är att dessa områden är begränsade, så när det dyker upp en bugg behöver man (ignorerat kompilatorbuggar, men de är rätt sällan där felet ligger i praktiken) leta i de delar av koden som är markerade "unsafe" (nyckelordet i Rust för att gå in i C/C++ läget med avseende på kontroll/säkerhet).
Så för att förtydliga: Rust kan vara snabbare än C i kod som utför beräkningar och transformer på data, d.v.s. majoriteten av alla kod som skrivs. I HW-nära kod där man primärt gör trivial minnesaccess får man göra avvägningen mellan värdet i något högre prestanda (C-prestanda) utan säkerhet eller något lägre prestanda med säkerhet som inte kan uppnås i C.
C++ är närmare C än Rust här, men även C++ kan vara snabbare än C tack vare templates och allt mer funktioner som är s.k. "constexpr" (logik som evalueras vid kompilering). Rätt använt fångar också C++ vissa av de typiska C-buggarna, dock tillkommer endera en kostnad vid kompilering eller vid runtime (Rust har samma möjligheter som C++ här).
Angående det sista: det riktigt coola är just att man hittar data-race vid kompilering! Det finns några få saker man kan göra i C/C++/C#/Java (och säker ett par andra) som rent tekniskt är OK, men som inte kommer kompilera i Rust (men är oftast relativt enkelt att modifiera logiken så det även fungerar i Rust). Det är ett rätt litet pris att betala för att kunna hitta data-race och ha noll "undefined behavior" i all kod som kompilerar och inte är markerad "unsafe".
Slutligen: man måste komma ihåg att Rust deklarerades "stabilt" så sent som mitten av 2015. Jobbet med att riktigt få ut max ur de möjligheter som finns på kompilatornivå lär inte realiseras än på ett tag. Ge det till 2025, ett decennium brukar vara ungefär vad ny teknik behöver för att både visa sin riktiga potential samt även börjar visa eventuella brister.
