Optimalizované C stáhlo parse_number() na 19 ns. Rust vyhrál jen první kolo

Simon Willison nechal Claude Opus 5.5 vytvořit čtyři varianty SQLite funkce parse_number(), která z textu jako -$1,234.56 udělá číslo. Výsledek je užitečný hlavně tím, že první překvapení nenechal být a rozebral, odkud se vzalo.

Rust porazil přímočaré C, dokud C nepřestalo volat obecný parser

Test zahrnul dvě varianty v Rustu a dvě v C. Přímočaré C zpracovalo smíšená data za 67,3 ns na řádek, zatímco Rust potřeboval 40,5 až 45,9 ns. U desetinných čísel byl rozdíl ještě větší: 106,3 ns proti 46,5 až 54,5 ns.

Příčinou nebyl jazyk jako celek. C verze předávala desetinná čísla obecné funkci strtod(), zatímco Rust použil rychlejší cestu ve svém parseru. Po doplnění zhruba třiceti řádků pro běžné hodnoty kleslo optimalizované C na 19,2 ns u smíšených dat, 15,8 ns u celých čísel a 17,5 ns u desetinných.

Malá funkce odkryla cenu abstrakcí i cenu ruční práce

C rozšíření mělo 14 408 B. Varianty v Rustu zabraly 298 464 B a 320 864 B, protože s sebou nesly standardní knihovnu a další podpůrný kód. Optimalizované C zároveň vyžadovalo 104 řádků kódu, ruční práci s buffery, kontrolu přetečení a opatrnost kolem desetinných výpočtů.

Rustové varianty byly kratší a bezpečnější na napsání. V tom je praktická pointa pro vývojáře: u malé, často volané funkce může C koupit nižší latenci a menší binárku, ale účet přijde ve složitějším kódu a širším prostoru pro chyby. Volba jazyka tedy závisí na tom, zda je kritická každá nanosekunda, nebo čas lidí, kteří budou rozšíření udržovat.

Výsledek stojí na úzkém mikrobenchmarku, ne na univerzálním souboji jazyků

Měření proběhlo na jednom Linux x86-64 stroji se 2 vCPU, nad 2 miliony řádků. Každý údaj je nejlepší z 15 běhů po odečtení základního průchodu tabulkou. To dobře izoluje cenu funkce, ale neříká, jak se varianty chovají v jiné knihovně C, na jiné architektuře nebo uvnitř aplikace s další prací kolem databáze.

Také jde o výzkumný report vytvořený pomocí LLM. Důvěryhodnost mu nedává původ textu, nýbrž zveřejněný kód, 40 ručních testů a 8 milionů fuzz porovnání bez nalezené odchylky. I tak zůstává reprodukce na dalším stroji důležitější než sebejistý závěr z jedné tabulky.

Reprodukce ukáže, zda výhoda přežije mimo autorův stroj

Nejcennější další signál bude stejné měření na macOS, ARM a s jinými implementacemi standardní knihovny. Zajímavé bude také odstranit alokaci Vec z obou variant v Rustu a sledovat, kolik rozdílu patří jazyku a kolik obalu knihovny.

Pro běžné nasazení rozhodnou i data z reálných importů: podíl chybných hodnot, délka řetězců a četnost pomalé záložní cesty přes strtod(). Právě tam se ukáže, zda 19,2 ns přežije kontakt s daty, která nevznikla pro benchmark.

Lilithin verdikt

Rust doběhl před první C implementací, jenže optimalizovaná verze mu na 2 milionech řádků ukázala záda. U tak malé funkce nerozhoduje vlajka jazyka, ale parser, který skutečně měříte.