DEV Community

Betelgeuse
Betelgeuse

Posted on

Kdy je Rust rychlejší než Go

Na začátek jeden fakt: Rust není inherentně rychlejší než Go, jako jazyk nemá nic, co by jej činilo v principu rychlejším, oba překladače generují stejně kvalitní kód a ani standardní knihovny těchto jazyků se efektivitou nijak zásadně neliší. Proč má tedy Rust (nezaslouženou) pověst rychlejšího jazyka?

Rust svým založením nutí vývojáře nealokovat objekty na haldě, je-li to možné (někdy není vyhnutí). Go naopak vývojářům nedává možnost volby, a protože jeho escape analýza není dokonalá, často skončí na haldě objekt, který by klidně mohl žít na zásobníku. Z uvedeného plyne, že je-li nějaký jinak shodný program v Rustu rychlejší než v Go, je to jeho lepším využíváním zásobníku. Kdyby objekty alokoval na haldě (což mnoho jazyků dělá automaticky, v Rustu nebo C(++) by to ovšem byla hrubá nedbalost) například pomocí Box, najednou by byl program v Rustu pomalejší.

Zde se dostáváme k rozdílu mezi alokátory. Go používá variantu tcmalloc, což je poměrně rychlý alokátor zamezující fragmentaci haldy a optimalizovaný pro běh více vláken. Rust používá standardní alokátor z libc, který se liší podle OS, nicméně na macOS, Linuxu i Windows je poměrně pomalý a jeho výkon ve vícevláknových programech bývá katastrofální. Skóre srovná použití nějakého vhodnějšího alokátoru, Rust například umí použít jemalloc původně z BSD, který výkonem za tcmallocem příliš nezaostává (Rust jej ostatně dříve používal jako standardní, než přešel k systémovému libc).

Kdo by chtěl podvádět v benchmarcích, může použít v Rustu například mimalloc, což je velice rychlý alokátor vyvinutý pro obskurní logický jazyk, jinak ale univerzální. Go alokátor nijak jednoduše vyměnit neumí, proto by s takto přeloženým programem téměř vždy prohrálo.

Discussion (0)