Je výsledný kód opravdu rychlejší s menší paměťovou stopou?
Dokázal byste si představit, že by se v něm dal naprogramovat engine 2,5D počítačové hry třídy AAA?
Většinou není rychlejší než dobře napsaný kód v C.
(1) Důvodem je převážně to, že v Rustu je zvykem pracovat s hodnotami po jednom, po jednom je alokovat a po jednom je uvolňovat za pomoci RAII. A to je pomalé. V dobře napsaném C kódu byste pracoval se skupinami objektů a uvolňování by měl být ideálně no-op.
(2) V Rustu totitž moc jednoduše nejde používat vlastní alokátory. V ideálním případě chcete různé alokátory pro různé věci. Takže třeba u hry pro každý frame máte nějaký arena alokátor, kde se alokuje velice rychle, a na konci framu vše uvolníte jen nastavením jedné proměnné.
(3) V benchmarcích někdy vyjde Rust rychlejší než C. Někdy je to dáno tím, že C používá pomalý malloc ze standardní knihovny a Rust má rychlejší alokátor. Když v takových případech nahradíte alokátor v C jiným, tak začne být rychlejší kód v C.
(4) Teoreticky by mohl být Rust rychlejší díky optimalizacích založených na přísnějších pravidlech aliasingu. Bohužel v Rustu ta pravidla zatím nejsou přesně specifikovaná. Až je nějaká komise přesně určí, tak se teprve uvidí, jaké knihovny mají nedefinované chování (např. kdyby se určilo, že platí Stacked Borrows, tak knihovny jako tokio nebo json budou mít nedefinované chování).
(5) Engine samozřejmě jde naprogramovat, ale Rust na to moc vhodný není. Spíše vám hází klacky pod nohy a vy pak končíte s méně efektivním kódem, protože abyste uspokojil borrow checker, tak kopírujete něco, co byste jinak kopírovat nemusel.
Zobrazit příspěvky
