Rust vs Go vs C på Apple Silicon og Linux — benchmarks på rigtig hardware (2026)

Kort fortalt — Fire benchmarks på to maskiner: Apple M1 Pro (arm64, macOS 26.6, clang 21) og Intel i5-13400F (x86_64, Ubuntu 24.04, gcc 13). På M1 matcher Rust C inden for støj på alle tests. På Linux x86 slår gcc rustc på rekursiv fib (1,5×) og Go’s fib falder til 2,9× langsommere end C — et meget større gab end på arm64. Den største overraskelse: Rust’s parallel sum er 2,8× hurtigere end C pthreads på x86, sandsynligvis fordi LLVM folder heltalsrækken til en lukket formel som løkken aldrig rent faktisk kører.

Opsætning

Hvert benchmark kørtes tre gange; tabellerne nedenfor viser medianen af kørsel 2–3.

De fire benchmarks

1 — Primtalssold (primtal op til 10.000.000)

Fladt bool-array-sold: skrive-tungt sekventiel hukommelsesadgang, letgrebet indre løkke. God proxy for hukommelsesbåndbredde-begrænset kode.

2 — Rekursiv Fibonacci (n = 47)

Ingen heap-allokering, ingen løkker — ~2,97 milliarder stakrammer. Måler rå kald-dispatch, grenforudsigelse og hvor aggressivt hver compiler inliner/optimerer dyb rekursion.

3 — Matrixmultiplikation (512 × 512, f64, i-k-j løkkerækkefølge)

Cache-venlig løkkerækkefølge men stadig en tæt FP-akkumulering i den indre løkke. Her betyder auto-vektorisering og eliminering af grænsecheck mest.

4 — Parallel sum (100.000.000 heltal, 8 tråde)

8 POSIX-tråde (C), goroutines (Go) eller std::thread (Rust), der hver summerer en partition af 0..100_000_000. Tester tråd-spawn-overhead og hvor smart hver compiler håndterer den indre sum.

Resultater: Apple M1 Pro (arm64, clang 21, macOS)

Resultater: Intel i5-13400F (x86_64, gcc 13, Linux)

Median af 3 kørsler, kørsel 2 brugt. 2026-06-22.

Hastighed relativt til C, begge maskiner

Tre ting der er værd at forklare

1 — Go’s fib kollapser på x86

På M1 var Go’s fib(47) 11% langsommere end C — i praksis det samme. På i5’en er det 2,9× langsommere. Samme Go-version, samme algoritme. Forskellen er compiler-backend’en: Go’s arm64-kodegeneration håndterer dybe rekursive kaldkæder mere effektivt end dens amd64-kodegeneration. Dette er et kendt kvalitetsgab; Go’s x86-backend er generelt mindre moden end arm64-backendet til rekursionstunge mønstre.

2 — gcc slår rustc på rekursiv fib

På M1 (clang mod rustc, begge bruger LLVM) tog fib ~8,9s i begge sprog — identisk. På Linux producerede gcc 4,06s mens rustc producerede 6,02s — gcc er 1,5× hurtigere. GCC’s optimizer anvender mere aggressiv tail-rekursion og inlining-heuristikker for dette specifikke mønster på x86. Det er en påmindelse om at “Rust bruger LLVM” ikke betyder at det altid vinder over gcc; GCC har 30+ år af x86-optimeringskunst bag sig.

3 — Rust’s parallel sum er 2,8× hurtigere end C på x86

Rust-trådens krop er (start..end).sum::<u64>(). LLVM genkender en sum af en sammenhængende heltalsrækkevidde som en aritmetisk rækkeformel og erstatter løkken med en lukket beregning n*(n+1)/2 — O(1), uanset rækkeviddens størrelse. GCC med den manuelle for (i = start; i < end; i++) s += i;-løkke anvender SIMD-vektorisering men laver ikke spring til lukket form. Resultat: Rust’s otte tråde udfører hver én multiplikation; C’s otte tråde summerer hver 12,5M heltal. 2,8×-forskellen er udelukkende en compiler-optimeringsforkel, ikke en sprogforskel. (På arm64 var denne effekt mindre fordi Apple clang også anvender noget af denne optimering.)

Binærstørrelse og kompileringstid

Rust-binæren der er 4,3 MB på Linux mod 431 KB på macOS er den mest slående størrelsesforkel. På macOS linker Rust mod system-dylibs for dele af standardbiblioteket og holder binæren lille. På Linux linker Rust alt statisk, hvilket producerer en større men fuldt selvstændig binær uden system-biblioteksafhængighed — en reel fordel til containere.

Kompileringstider vender: Rust er 134ms på Linux mod 660ms på macOS for en enkelt fil. LLVM’s x86_64-backend er markant hurtigere til at udsende kode end dens arm64-backend.

Anno 2026: hvor lever hvert sprog?

C er stadig referencepunktet og stadig hurtigst på rå rekursivt arbejde når gcc’s optimizer er involveret. I 2026 er det ikke et førstehåndsvalg til nye projekter medmindre du skriver kernekode, embedded firmware eller FFI-klister — men compiler-kunsten akkumuleret siden 1972 er reel.

Go ramte 1.0 i 2012 med en klar tese: gør det at skrive netværkstjenester lige så hurtigt at udvikle som Python, mens man kører med effektiviteten af et kompileret sprog. Det har i høj grad lykkedes. Hvad det betaler for det: GC’en tilføjer latensvarians, og performance-loftet er lavere end Rust eller C for beregningstunge løkker. fib-resultatet på x86 afslører også at Go’s optimizer har reelle kvalitetsgab på visse mønstre — den er tunet til hvad Go-kode faktisk ligner (interfaces, kanaler, HTTP-handlere), ikke trærekursion.

Rust ramte 1.0 i 2015 og har brugt et årti på at bevise at hukommelsessikkerhed uden GC er opnåeligt i stor skala. I 2026 accepterer Linux-kernen Rust til drivere (siden 6.1), Firefox og Chromium erstatter gradvist C++ med det, og ISRG omskriver kritisk netværksinfrastruktur i det. Den lukkede formel-sum-optimering ovenfor er et godt eksempel på hvad “zero-cost abstractions” betyder i praksis: at skrive idiomatisk Rust lader compileren anvende transformationer som en manuel C-løkke ikke kan udløse.

Pick-one-guide

Benchmarks kørt på personligt hardware; dine tal vil variere med CPU, OS-indstillinger og compiler-flag. Koden er fire enkelt-fils programmer, ingen eksterne afhængigheder. Alle compilere kaldt med fulde optimeringsflag som vist ovenfor.