Benchmarks

Den korte version · målt 23. august 2026 på den kodelinje, der blev leveret som nzbfast 1.2.2

Ingen målt klient er billigere på processor, hukommelse og disk tilsammen

De nyeste runder på denne side kørte 23. og 24. august 2026 - den nyeste af dem på selve v1.2.2-release-buildet - mod de aktuelle builds af fire andre klienter på identisk hardware, linjer og udbydere: to jobformer fra 6,5 til 87 GB, og linjehastigheder fra 250 Mbit til 10 GbE. På tværs af de runder var ingen klient billigere end nzbfast på processor, hukommelse og disk tilsammen: hver af dem koster mere på mindst to af de tre, det mest nogen af dem sparede på en enkelt akse var omkring 2 procent - en statistisk uafgjort, inden for den klients egen spredning fra kørsel til kørsel - og på disk flyttede hver eneste af dem mindst dobbelt så mange bytes for et byte-identisk resultat. Som leveret holdt nzbfast også mindst hukommelse af alle målte klienter, på hver eneste fixtur, med 2,0x til 4,5x mod den nærmeste rival.

Hvilken er dig?

De fleste downloadere skriver dit download til disk mindst to gange: én gang mens det hentes, og igen mens det pakkes ud. nzbfast klarer hele jobbet i ét gennemløb, så den skriver omkring halvdelen af bytes'ene pr. job, holder mindre i hukommelse mens den arbejder, og bruger færre processorsekunder pr. GB. Det er mindre belastning på maskinen mens du bruger den, og halvt så mange skrivninger pr. job på dine drev, for de samme byte-identiske filer - og fordi hver byte krydser disken omkring én gang, skal dit drev kun følge med din linje én gang.

nzbfast vinder ikke hver eneste tabel på denne side, og dem den taber findes under de ben, vi ikke vinder - inklusive ét fra samme runde. Det, der holdt i hver runde vi målte, er den samlede regning.

Metode først

Opsætningen

• Klienter: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, hver tabel på de builds, den navngiver. De nyeste runder (23. august 2026) kørte mod feltets dengang-aktuelle builds - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 og Weaver 0.7.8, dens nyeste leverede binær, identitet bevist ved hash - mod den kodelinje, der samme nat blev leveret som nzbfast 1.2.2, så det build, der producerede de nye tal, er det, du kan downloade. De runder kørte på en 20-core Apple Silicon-maskine på en 1 Gbit-linje. Ældre tabeller beholder de builds og maskiner, de kørte mod (Apple M-serie-maskiner: en "Europa" M1 Ultra på 10 GbE, en "Østkysten" M3 Ultra på en ~2,4-3,0 Gbps-linje) og siger så; de underdriver leveringsbuildet frem for at smigre det.
• Fairness: samme udbydere og TLS overalt for hver klient, ben kørt ryg mod ryg og flettet. Hver konkurrent tunet til sit dokumenterede bedste: SABnzbd fik pipelining_requests=8 (den leveres med 1, altså ikke pipelinet, og indstillingen er tocifrede procentpoint værd på store job), NZBGet fik ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb sin dokumenterede konfiguration. Siden 20. august 2026 kører hver runde mod fem udbydere frem for seks - antallet af udbydere er ikke en gennemløbshåndtag på disse maskiner, hvor én enkelt udbyder alene kan nå linjeloftet, og et fast antal holder runder sammenlignelige - så et tal med seks udbydere på denne side er ikke direkte sammenligneligt med et nyere tal med fem udbydere, og hver tabel siger, hvilket den kørte.
• Sluttilstand: en verificeret, udpakket, brugbar fil, ikke "download færdig". Det er det, du reelt venter på.
• Reproducerbarhed: hver påstand er dateret og målt på samme måde: forløbet tid + grænsefladens byte-tællere + spidsbelastning af RSS for procestræet, 1-2 s opløsning. Hvor et ben kører på en offentligt udgivet NZB, navngiver vi den, så du selv kan køre den.
• Metodenoter, der gælder for hele siden: CPU-tid samples fra procestræet ved 2 Hz på hver arm af en tabel og placeres aldrig ved siden af et tal fra en anden opgørelsesmetode, fordi de to metoder er bevidst uenige. Disk-I/O er angivet i GiB og netværksbytes i decimale GB; vi konverterer før division. Og enhver tabel, der kører vores eget build mod vores eget build, bærer en A/A-kontrol - den samme binær kørt mod en byte-identisk kopi af sig selv gennem samme testramme - fordi den kontrol er, hvordan vi opdagede, at vores egen benchmark-testramme gav en straf på ~1,5% til hvilket værktøj, der end kørte først (historien står ved siden af udpaknings- tabellerne nedenfor). To arme og ombyttede rækkefølger ophæver ikke en bias, der altid rammer den første arm; en A/A-kontrol afslører den.

Langsommere linjer · målt 24. august 2026 på nzbfast 1.2.2

Jo langsommere linjen, jo mindre adskiller hastighed klienterne - og jo mere gør regningen

På en linje langsom nok er hver klients sluttid linjen og intet andet, så en langsom linje skjuler mange synder. Det den ikke kan skjule, er hvad hver klient brænder af for at fylde den. Vi formede 1 Gbit-riggen til to hastigheder, som virkelige planer faktisk er, og kørte alle seks arme mod hver - samme maskine, samme fem udbydere, tre gentagelser pr. klient med rækkefølgen roteret, hvert ben byte-tjekket, 36 af 36 korrekte på tværs af de to runder. nzbfast-armen ved 500 Mbit er selve v1.2.2-releasebuildet.

Læs de to tabeller som en gradient. Ved 250 Mbit lander hele feltet inden for 18% på uret, og vi fører over den nærmeste rival med 4,4%; ved 500 Mbit åbner hullet sig til 14,7%; ved gigabit- og 10 GbE-hastighederne i tabellerne ovenfor og nedenfor åbner det sig yderligere. Hastighedsforskelle vokser med linjen. Ressourcekolonnerne venter ikke på en hurtig linje: ved hver målte hastighed holdt hver rival mindst 3,9x hukommelsen, brugte mere processor, og flyttede omkring dobbelt så mange diskbytes for den samme byte-identiske fil.

Forbindelsesregulatoren tjener sin plads på langsomme linjer, og shaperens eget dropstælleri siger hvorfor. Standardindstillinger som leveret holdt 25 forbindelser, mens hver rival kørte hundreder; den samme binær med regulatoren fra kørte 360. Færre strømme gennem en fast kø betyder mindre tab og mindre gensending: shaperen registrerede omkring 4.200 drop pr. begrænset ben mod omkring 155.000 ubegrænset ved 500 Mbit, og den begrænsede arm var hurtigere, 4,2x lettere på hukommelse og 1,3x lettere på CPU end vores egen 360-socket- tilstand. Flere forbindelser er ikke mere hastighed; under en gigabit er det målbart det modsatte.

Målt 24. august 2026, medianer af tre, på en 20-core Apple Silicon-maskine med sin linje formet til hver hastighed (den formede hastighed verificeret af en uafhængig probe før hver runde: 248 og 496 Mbit). Den 500 Mbit nzbfast-arm er selve v1.2.2-releasetag-buildet; 250 Mbit-runden kørte timer tidligere på samme kodelinje. Bytetal på en formet linje er læst fra hver klients egen tæller, aldrig netværksgrænsefladen (shaperen dropper og TCP gensender, så grænsefladen tæller begge kopier). Vægge er sammenlignelige inden for hver tabel, ikke på tværs af forskelligt formede runder. ¹ NZBGets tre ben ved 500 Mbit spændte fra 114-158 s med flade ressourceaflæsninger - en ægte spredning, så medianen er angivet, og spredningen er nævnt frem for indsnævret.

Det beskadigede opslag · kørt igen 24. august 2026, alle builds aktuelle

Når opslaget har huller: 6,5 GB med 60, 20 og 5 døde artikler

Artikler udløber, servere dropper dem stille, uploads lander ufuldstændige - og skade er der, hvor kløften mellem klienter er bredest, så det får sin egen runde på det nyeste build af hver klient, nzbfast v1.2.2 inklusive: Europa 10 GbE-maskine, fem udbydere, 100 forbindelser pr. klient, samme 6,5 GB-release forgiftet ved tre skadesniveauer, tre gentagelser pr. arm med rækkefølgen ombyttet, hvert ben byte-tjekket mod den rene fil. 63 af 65 ben kom tilbage byte-identiske; de to, der ikke gjorde, er navngivet nedenfor, fordi de er resultater.

Hvorfor det beskadigede opslag er hurtigt her. Når en artikel mangler, spørger en klient normalt den næste server, så den næste, indtil hver server har afvist den - en seriel vandring, hvis afvisninger tager alt fra titalls millisekunder til et par sekunder hver, mens downloadet står stille på nul. nzbfast holder op med at spørge: så snart de paritetsdata, den allerede har i hånden, dækker det, der stadig mangler, reparerer den øjeblikkeligt i stedet for at fuldføre vandringen. Det er anden række - den samme binær med den opførsel slået fra er 1,4x til 2,3x langsommere afhængigt af skaden - og runden bekræftede, at mekanismen aktiveredes på hvert aktiveret ben og aldrig på et deaktiveret. Mod den nærmeste rival er marginen 2,4x til 2,7x, uden overlap i nogen af de ni gentagelsespar.

Disk er, hvor marginen er bredest, og det er ikke reparationstricket. Hver fuldførende arm producerede den samme 6,48 GB-fil; vores flyttede 6,2-6,8 GB disk-I/O for at gøre det, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB og rustnzb 12,8-13,1 GB. Det er one-pass-pipelinen - rækken med funktionen slået fra flytter de samme 6,2 GB - så det holder på både beskadigede og ubeskadigede opslag.

¹ SABnzbds tre ben ved den kraftigste skade kørte 43, 41 og 60 s - en ægte spredning på identiske input, så gennemsnittet er angivet med intervallet nævnt. ² rustnzb 1.4.5 leverede hvert ben byte-korrekt, og dens omkostning ligger i processortid frem for pålidelighed: omkring 1.620 CPU-sekunder mod et 107 s ur ved den kraftigste skade - omkring femten kerner beskæftiget hele benet igennem - hvor det samme reparerede output koster os omkring 50 CPU-sekunder. ³ Weaver flyttede 1,5 GB og 4,9 GB af de 6,5 inden for vores 20-minutters afskæring ved de to tungere skadesniveauer - det samme ikke-fuldførte i alle tre runder, den er kørt i, over tre separate nætter; afskæringen er vores, og det ikke-fuldførte er resultatet. Ved 5 døde artikler fuldførte den korrekt alle tre gange. Dens processoromkostning der er sin egen historie: omkring 2.325 CPU-sekunder for det 194 s ben, mod vores 20.

Målt 24. august 2026, alle builds aktuelle: nzbfast v1.2.2 (selve releasetagget), NZBGet 26.3-testing (build fra 20. august), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. En kontinuitetsarm kørte den foregående nats nzbfast-build inden i samme runde og landede inden for ét sekund af v1.2.2 på hver fixtur, så intet her rider på en heldig nat; og rival- konfigurationerne adskiller sig fra foregående rundes kun ved anvendelsessti, tjekket nøgle for nøgle før runden kørte.

Sult den for RAM · målt 24. august 2026 på nzbfast 1.2.2

Lavhukommelses-stigen: 87 GB i ~0,3 GB RAM

Samme 87 GB-job som runden ovenfor, kørt igen ved faste hukommelsesbudgetter på 2 GB, 1 GB og 256 MB - det, autostørrelsen ville vælge på en 8 GB-maskine, en 4 GB-maskine og et 2 GB NAS. Hvert ben producerede den identiske byte-tjekkede fil, og hukommelseskolonnen fulgte budgettet, aldrig jobbet:

Ét ben pr. budget på release- buildet, gatet mod den samme output-tjeksum som seks-arms-runden. Det strammeste budget koster omkring 9% af væggen, og kun fordi denne linje er 10 GbE - spildte blokke koster kun tid, når linjen overhaler disken, så på en typisk hjemme- forbindelse er et lille budget tæt på gratis. Hele stigen, en 87 GB-download inklusive, passer i 0,3-0,6 GB hukommelse; ved standardindstillinger som leveret kørte jobbet i 286 MB. Ingen anden klient tilbyder et fast, procesbredt hukommelsesbudget; de nærmeste ting er cache-størrelses-håndtag, og runden nedenfor måler, hvad de koster.

Begrænsningen kørt mod feltets egne håndtag. På 34 GB-fixturen (23. august 2026, 1 Gbit-maskine, fem udbydere, 30 af 30 ben byte-korrekte), fik det at holde NZBGet til en tilsvarende cache-begrænsning dens CPU til at mere end fordobles (215,5 til 453,0 CPU-sekunder, 2,10x) for at købe et fald på 52% i dens spidshukommelse, og SABnzbds begrænsning var næsten gratis, men nåede kun en del af dens aftryk. rustnzbs cache-indstilling var dekorativ i det kørte build, og Weaver har slet intet hukommelseshåndtag, så begge kørte ubegrænsede som referencekolonner frem for at blive bedømt ved et budget, de ikke kan holde. Vores egen side af den runde er afløst af v1.2.2-stigen ovenfor, som siger det samme ved 2,5x størrelsen: budgettet er aldrig den bindende begrænsning, fordi ét gennemløb holder så lidt til at begynde med.

Fri plads · målt til megabyten

Hvor lidt fri plads et job behøver

En skriv-ud-og-pak-ud-klient har brug for plads til arkivbindene og den udpakkede nyttelast samtidig, så et job vil ikke starte uden groft dobbelt så meget fri plads som downloadet. Ét gennemløb har kun brug for nyttelasten - og denne runde målte hvor lidt mere, ved at formindske målbindet, indtil hver klient fejlede. nzbfasts svar er en konstant på omkring 50 MB margen, ikke et forhold, og det holder fra et 6,5 GB-job til et 34 GB-job.

Målt på en 20-core Apple Silicon-maskine, 1 Gbit-linje, fem udbydere, tre gentagelser ved hver grænse, hvert fuldført ben byte-tjekket - rivalrækkerne fra 22.-23. august 2026 (Weavers 34 GB-celle kørt om den 24. august, note 1), og nzbfast-rækken genkørt på v1.2.2-releasebuildet 24. august, som gengav begge grænser præcist, 12 af 12 ben enige på tværs af de to fixturer. Vores celler er en målt bund: jobbet fuldføres 3 af 3 med 48,6 MB og 51,0 MB margen, og nægter 3 af 3 omkring 17 MB under det - så bunden er ægte i begge retninger. Hvad jobbet faktisk holder, lander på outputtet plus omkring 3 MB; margenen betaler for de sidste øjeblikke af pipelinen, aldrig for en anden kopi. Rivalernes celler er deres målte bund på 6,5 GB-jobbet og en bekræftet tilstrækkelighed ved samme forhold på 34 GB-jobbet (3 af 3 byte-korrekte ved præcis det forhold); vi gik ikke deres stige længere ned ved den større størrelse, så deres reelle bund der kan ligge noget under forholdet, og det siger vi frem for at runde i vores egen favør.

Hvordan det rent faktisk ser ud at løbe tør betyder lige så meget som tallet. Ved 17 MB under sin bund rammer nzbfast diskens afvisning på en skrivning, stopper rent med "out of disk space", holder alt, der landede, journalført, og et nyt forsøg genoptager uden at hente igen - en delvis fil du beholder, ikke et mislykket job. ¹ Weavers celle for den store fixtur blev afklaret af en gentagelse den 24. august: tre ud af tre ben byte-korrekte ved samme ~2,25x, hvert af dem hurtigere end det gode ben fra første forsøg, med fri plads identisk ned til byten. Ved første forsøg, den 23. august, var to af dens tre ben gået i stå ved encifrede MB/s med mere end 60 GB stadig fri og havde ramt rundens 40-minutters afskæring. De standsninger kom ikke igen, og riggens standsningsmåling var udrullet og tavs på alle tre ben i gentagelsen, hvilket er en positiv måling og ikke en manglende. Hvad der forårsagede dem er stadig ukendt, og en ren gentagelse er ingen diagnose: der findes nu seks ben ved dette forhold, fire fuldførte, og begge fejl stammer fra ét enkelt vindue på 80 minutter den første nat.

Indlejrede opslag · målt den 28. august 2026

Ti måder at pakke et opslag ind på, og hvem der faktisk når filen

Meget af det, der bliver lagt op, er bevidst svært at åbne. Det rigtige filnavn ligger begravet i et andet arkiv, undertiden et tredje, undertiden i et andet format på hvert niveau, så opslaget røber så lidt som muligt om, hvad det indeholder. Dertil kommer, at opslag ankommer beskadigede: artikler udløber, uploads lander ufuldstændige, og genoprettelsesdataene skal bruges, før noget som helst kan pakkes ud. En downloader går kæden igennem for dig, eller også rækker den dig en mappe med arkiver og stopper.

Vi byggede derfor ti former, der isolerer præcis det, lod hver aktuel klient møde dem og gjorde så det, sammenligninger normalt springer over: hvor en klient stoppede for tidligt, gjorde vi arbejdet færdigt i hånden med standardværktøjerne og tog tid på det også. En klient, der giver op hurtigt, ser hurtig ud, indtil man tæller det arbejde, den efterlader til dig.

nzbfast er den eneste, der klarer alle ti uden hjælp. NZBGet når også filen i hver form, men har brug for 16 runder manuel reparation og udpakning i otte af dem. SABnzbd klarer fem på egen hånd, og to er uopnåelige selv i hånden. Weaver når filen i to.

Mønstret er ikke tilfældigt. De former, nzbfast kommer igennem, og de andre ikke, er de indpakkede og de beskadigede: et arkiv i et arkiv, et formatskift midtvejs, en kæde i fem niveauer og frem for alt et arkiv, der ankommer ødelagt med sine egne genoprettelsesdata ved siden af. På den sidste pakker fire klienter det ydre sæt fejlfrit ud, rækker dig det ødelagte arkiv sammen med det genoprettelsessæt, der ville reparere det, og stopper.

Hvor klienterne udfører det samme arbejde, er forskellen stor. Dette er de syv former, som alle fire udbredte klienter når, inklusive den manuelle reparation, hver enkelt havde brug for:

Fire til fem gange hurtigere, på under halvdelen af de skrevne byte. Disktallet er det, der bliver ved med at betyde noget efter downloaden: hver gigabyte i den kolonne er en gigabyte, din disk har måttet tage imod, og de klienter, der bruger et mellemlager, skriver indholdet ud, læser det tilbage og skriver det igen.

Hvor vi ikke er foran, og hvorfor det er værd at sige. På fire af de ti former skriver en konkurrent færre byte end nzbfast under selve downloaden. Hver gang fordi den gjorde mindre: på formen med beskadiget inderarkiv skriver NZBGet 3,29 GB mod vores 4,65, og derefter skriver dens reparationsrunde yderligere 2,91 og ender på 6,20 GB mod vores 4,65. På de øvrige er den klient, der skrev mindst, en, der aldrig nåede filen. Et lavt disktal er ikke altid nøjsomhed.

Dette er kapacitetstest, ikke hastighedstest. Indholdet er lille og serveres fra hukommelsen over en lokal forbindelse, uden udbyder og uden netværk undervejs, så intet her begrænses af downloadhastigheden, og de absolutte sekunder er langt kortere, end de samme former ville tage i virkeligheden. Om en form overhovedet kræver håndarbejde er en egenskab ved formen og klienten og kan overføres direkte. Sekunderne sammenligner klienter, der udfører identisk arbejde; de forudsiger ikke, hvor lang tid en rigtig opgave tager.

Fuldstændige resultater pr. form, hvad hver form er, og metoden findes på datasiden om indlejrede arkiver.

Hvorfor det betyder noget

Dit drev udfører halvdelen af arbejdet

Flashlager slides ned ved at blive skrevet til. En 94 GB release koster dit drev omkring 90 GB skrivning under nzbfast; under en klient, der stager og pakker ud, koster den samme release cirka det dobbelte. På et NAS med harddiske fjerner ét-gennemløbs-formen også det lange enkelttrådede gennemløb i slutningen af hver krypteret download - en pause målt til 20 sekunder på en hurtig 32-core arbejdsstation med hardware-accelereret oplåsning, og tilsvarende længere på de lavere-ydende maskiner, de fleste rent faktisk kører dette på. Vi citerer det lille tal, fordi det er det, vi målte.

Komponent-opgør

De mere tekniske benchmarks, for dem der vil have flere data

Reparation (PAR2) og udpakning (RAR) er vores egen indbyggede kode frem for medfølgende tredjeparts-binærer, så vi kører dem også selvstændigt mod de dedikerede værktøjer på identiske korpora, på fire maskiner, der spænder over det, en læser reelt kunne eje. En tid tæller kun, når outputtet er byte-identisk med kildens nyttelast: hvert RAR-tal nedenfor er sha256-tjekket mod kilden, og hver repareret fil mod det uberørte sæt.

RAR-udpakning: 7 arkivformer, 6 værktøjer

Den forrige runde af denne tabel brugte 100 MB til 200 MB pr. form, hvilket var en fejl: omkring 28 ms procesopstart var 40% af gemt-benet, og den rækkefølge, det producerede, overlever ikke ved en realistisk størrelse. Denne runde er 1 GB nyttelast pr. form, og det ændrer flere svar, herunder nogle den anden vej. Arkiver oprettes af officiel rar 7.23, så intet værktøj bedømmes på input fra sin egen encoder, og de samme bytes kører på hver maskine.

Hvad der er i nyttelasten betyder mere, end det ser ud til. En nyttelast bygget af blokkopier gør hver komprimeret form til en hukommelseskopi-benchmark; en nyttelast af ren tekst gør den til en literal-og-Huffman-benchmark; vi målte begge, og de er ikke enige om, hvem der vinder. Så de fire komprimerede former bruger lige tredjedele tekst, strukturerede poster og ukomprimerbare bytes, og de to former i hver ende af det spænd er separate ben med vilje: store er ukomprimerbar, og repetitive er næsten udelukkende matches. Bygger og testramme ligger i repositoriet, så korpuset kan genopbygges byte for byte.

Kørt igen 23. august 2026 på 1.2.2- motoren, og gennemgangen holder. De tre værktøjer, en læser oftest vejer - vores, unrar 7.23 og rarpar 0.2.5 - blev kørt igen på 32-core-desktoppen på releasemotoren (den udpakningskode, der kører mod, er byte-identisk med 1.2.2-tagget), seks flettede runder, minimum pr. værktøj, hvert bens output tjekket mod nyttelast-manifestet. Sekunder, lavere er bedre:

Alle syv former vores, på minimum og på medianen, 1,16x til 4,29x mod unrar. Disse tider er ikke sammenlignelige celle for celle med den bredere tabel nedenfor - testrammen er revideret siden den tabels runder, og runde-antallet er forskelligt - så læs hver tabel mod sig selv. Den bredere tabel beholder sine egne datoer og sit felt af seks værktøjer, og dens nzbfast-kolonne beskriver den motor, 1.2.2 leverer: genkørslen ovenfor målte det aktuelle motor- niveau med den tabels build på alle syv former, afgjort af hardware-instruktions- tællinger (0,14% færre for samme væg), så de celler er ikke et forældet builds tal med et aktuelt mærkat på. Denne genkørsel er også, hvor A/A-reglen i opsætningsafsnittet blev optjent. Et pas samme dag rapporterede først én form som en lille regression mod vores eget forrige build, og aflæsningen overlevede at køre begge armrækkefølger. En A/A-kontrol - den samme binær kørt mod en byte-identisk kopi af sig selv - viste, at testrammen gav hvilken arm der end kørte først, omkring en straf på 1,5%: den identiske binær vandt kun 6 af 15 runder fra den første plads, og at bytte rækkefølger ophæver ikke en bias, der altid rammer den, der er først. Hardware-instruktionstællinger afgjorde spørgsmålet, testrammen ikke kunne - det nyere build afvikler 0,14% færre instruktioner for samme ur- tid, så der var ingen regression. Hver vores-build-mod-vores-build-sammenligning, vi publicerer nu, bærer den kontrol.

Hele feltet, sekunder, lavere er bedre. Bedste af tre, værktøjer flettet inden i hver runde frem for kørt i blokke, output tjekket mod kildens nyttelast ved hver eneste kørsel. Et værktøj, der producerede forkerte bytes, får en korrekthedsnote, aldrig en hurtig tid. rarpar er Weavers egen RAR- og PAR2-kode, bygget fra kilde ved bd87611; vi fastpinner commit'en frem for en version, fordi dens crates bærer tre forskellige versionsnumre.

Hvor feltet ikke kunne følge med, og hvorfor. ¹ Den 7-Zip, der kører her, er Homebrew-pakken, som afviser hver komprimeret form med ERROR: Unsupported Method og kun læser den gemte på macOS. En tidligere version af denne side lagde det på 7-Zips macOS-build, hvilket var forkert: Homebrew bygger den uden den ikke-frie unRAR-codec, mens den macOS-build, 7-zip.org leverer, bærer codec'en og afkoder alle syv former, ligesom Windows-buildet gør. Genmålt 14. august 2026. Installerer du 7-Zip fra projektet frem for fra Homebrew, beskriver denne kolonne ikke det, du har. ² bsdtar har ingen RAR5-understøttelse af flere bind og producerede en afkortet fil uden at rapportere en fejl, så det ben er en korrektheds-fejl frem for en langsom tid; vores testramme fangede det ved at tjekke outputtet, hvilket er hvorfor det er værd at tjekke outputtet. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar leverer intet Windows-kommandolinjeværktøj, så laptop-feltet er fem. ⁶ M5 Max-gruppen kører de tre værktøjer, en macOS-læser rent faktisk ville gribe til - unrar, rarpar og os; unar, bsdtar og 7-Zip blev ikke kørt på den maskine. Dens unrar er 7.22, det nyeste build, der kører uovervåget der.

Hver form på hver maskine undtagen én, og den ene er uafgjort. De korte-match-formerne kommer ned til to specifikke ting i vores dekoder. Et match på to til toogtredive bytes plejede at betale for et fuldt kald ind i platformens hukommelseskopi-rutine, og kaldet kostede mere end kopien; at kopiere fast toogtredive bytes gennem et register i stedet er hvorfor repetitive, solid og 128 MiB-ordbogen - de tre former bygget af korte matches - alle er hurtige på én gang. Og tjeksummen kører nedstrøms for skriverens tråd frem for på den. Den ene celle, vi ikke vinder udelukkende, er den gemte form på 32-core-desktoppen, hvor unrar og vi er tre millisekunder fra hinanden på et ben, der udelukkende flytter bytes - identisk ved denne tabels præcision, så begge celler er markeret, og det bedømmes som uafgjort, ikke et tab og ikke en sejr.

Den form, vi vinder mest på, er den, usenet rent faktisk udgiver hundredvis af ad gangen: 400 små filer, 4,3× og 4,4× mod unrar og 5,4× til 5,5× mod rarpar. Det er parallelisme pr. medlem, og det er forskellen mellem en udpakker skrevet til en downloadkø og én skrevet til en kommandolinje. Den gemte form, som optællingen ovenfor siger er 84% af bytes'ene på linjen, er næsten uafgjort for de tre seriøse værktøjer, fordi alle på det tidspunkt bare flytter bytes.

Ét valg værd at erklære. Arkiverne pakkes med kompressoren fastpinnet til fire tråde. RARs blokopdeling følger ellers kernetallet på den maskine, der pakkede arkivet, så en 32-core-maskine og en 20-core-maskine producerer forskellige bytes fra samme input, og maskinerne holder op med at være sammenlignelige. At fastpinne det gør udpaknings-korpuset byte-identisk overalt, hvilket er pointen, men det sætter også et loft for, hvor meget af afkodningen der kan køre parallelt - så da de to tætteste former var tab, kørte vi dem igen mod arkiver pakket med alle 32 tråde, for at tjekke at fastpinningen ikke var årsagen. Det var den ikke: solid gik fra 4,2% bagud til 2,4% bagud og 128 MiB-ordbogen fra 6,6% til 6,3%, samme rækkefølge begge veje. Begge er nu sejre på det fastpinnede korpus med en bredere margin, end det tjek kunne forklare.

Hvorfor der ikke er nogen RAR4-række, og hvad der sker med de opslag. Hver form ovenfor er RAR5 eller RAR7, hvilket er det, usenet udgiver i dag. Ældre RAR4-arkiver dukker stadig op, og den samme motor læser dem, inklusive de komprimerede og adgangskode-beskyttede former, i det samme ene gennemløb som de nyere, frem for at skrive bindene til disk og pakke dem ud bagefter. De får ingen række her, fordi den officielle rar 7.23 ikke længere kan oprette RAR4, så der er intet neutralt korpus at køre feltet mod; det arbejde er i stedet tjekket mod arkiver skrevet af WinRAR 3.00, byte for byte mod unrar.

PAR2-verificering og -reparation: 1 GiB-sæt, fire skadesniveauer

Korpus: 1 GiB tilfældig nyttelast pakket i gemt-tilstand i 21 RAR-bind, derefter to PAR2-sæt ved 10% redundans, ét ved 1 MiB-blokke og ét ved 64 KiB, derefter faste skadeskort. Hver kørsel bruger samme protokol: frisk kopi, læs hele korpuset én gang for at varme cachen op, tag så tid. Bedste af tre flettede runder; hvert repareret bind sammenlignes med det uberørte sæt ved hver runde. Lavere er bedre.

En rettelse om korpuset, fordi en tidligere version af denne side overdrev det. Vi sagde, at hver maskine kørte et byte-identisk korpus, tjekket ved hash. At hashe hvert bind af hvert sæt viser, at det er sandt for 32-core-desktoppen og Windows-laptoppen, som matcher præcist, og ikke for 20-core-desktoppen, som rummer et andet tilfældigt udtræk af samme form: de samme 21 bind i de samme størrelser, de samme to blokstørrelser, og skade verificeret ved de samme 3, 101 og 1.500 blokke spredt over det samme antal filer. Hvert tal inden i en række er stadig målt på bytes, som hvert værktøj i den række deler, hvilket er det, hver sammenligning hviler på. Men rækkerne er ikke fire visninger af ét input, og eftersom nyttelastens karakter er omkring 7% værd for én konkurrents scanning, er det værd at sige frem for at glatte ud.

Hvilken par2 er hvilken. Den originale par2cmdline er referenceimplementeringen, alle forgrenede fra. par2cmdline-turbo er den fork, der leverer ParPars håndskrevne SIMD Galois-felt-kerner: det er præcis, hvad "turbo" betyder, og det er hvorfor turbo, frem for originalen, er værktøjet værd at måle mod. Begge turbo-kolonner nedenfor kører de samme ParPar-kerner. Hvad der adskiller dem, er ikke aritmetikken men buildet og flagene.

Bekræftet på leveringsbuildet mod den aktuelle rival, 24. august 2026. Disse tabeller blev målt før 1.2.2 blev skåret, og før par2cmdline-turbo udgav 1.5.0 (20. august 2026), så 20-core-kolonnen blev kørt igen mod begge: vores 1.2.2-releasebuild mod turbo 1.5.0, tre flettede runder pr. ben, hver repareret fil sammenlignet med det uberørte sæt. Alle fire ben gengiver sig - vores 0,18 / 0,30 / 0,75 / 2,02 mod de 0,19 / 0,33 / 0,74 / 2,07 trykt her, og turbo 1.5.0 lander inden for et par procent af buildet i tabellen på hvert ben og begge konfigurationer. Cellerne står som publiceret; de andre tre maskiner beholder deres egne datoer.

Så konkurrenten optræder to gange, og én af de kolonner er dens bedste tilfælde frem for dens standard. Den release-binær, du ville downloade, er kompileret til en generisk baseline-CPU og hasher kun et par filer ad gangen; at bygge samme kilde til den faktiske vært-CPU og give -T16 lader den bruge de instruktioner, den maskine reelt har, og hashe seksten filer ad gangen. På laptoppen er det op til 2,6x værd, udelukkende fra build og flag. Bedøm os på den tunede kolonne, som er den hårdere sammenligning; som-leveret-kolonnen er det, nogen der downloader den, rent faktisk oplever. par2cmdline er originalen, version 1.2.0, bygget fra kilde på hver maskine. rarpar er Weavers egen PAR2-implementering, bygget fra kilde med dens Metal GPU-backend slået til. MultiPars par2j er kun Windows, så den optræder kun i Windows-laptop-rækkerne. M5 Max-rækkerne kører de to værktøjer med aktuelle macOS arm64-builds ved siden af de to turbo-kolonner; par2cmdline klassisk blev ikke kørt på den maskine.

Alle seksten nzbfast-celler - fire maskiner ved fire skadesniveauer - er vores, flere med mere end 2× mod det tunede build og med 2,3× til 7,7× mod det, du rent faktisk ville downloade. De tunge-skade-cellerne er de interessante, og noten nedenfor forklarer algoritmen bag dem.

Originalen er tilbage i tabellen, og det er værd at se hvorfor forken findes. En tidligere version af denne side droppede par2cmdline-kolonnen med den begrundelse, at den var langsommere end alt andet i runden, hvilket er sandt og ikke en god nok grund: det er implementeringen, næsten hvert andet værktøj nedstammer fra, og læsere fortjener baseline'en frem for vores påstand om den. På det tungeste skadesniveau tager den omkring 69 s, hvor SIMD-forken tager 3,2 s, og vi tager 3,1 s. Den faktor tyve er hele argumentet for de håndskrevne Galois-felt-kerner, og det er samme argument, vi fører for vores egen.

Let skade er det tilfælde, der betyder noget. En håndfuld fejlede artikler er langt mere typisk end 101 døde blokke, og intet i nærheden af 1.500. Det meste af en let reparation er slet ikke Reed-Solomon-matematikken, det er at læse og MD5'e en gigabyte, hvilket er hvorfor 3-blok-rækken følger ren-verificering-rækken frem for reparationsrækkerne.

Det tungeste skadesniveau er en anden slags arbejde, og det får en anden algoritme. Det sidste niveau beskadiger 1.500 blokke på tværs af alle 21 bind og forbruger omkring 91% af genoprettelsesdataene, hvilket er der, hvor Reed-Solomon-aritmetikken, frem for hashing eller disk, bliver næsten alt arbejdet. Leveringsbuildet beregner de tungeste reparationer med en talteoretisk transformation i stedet for den klassiske Galois-felt-fold - samme matematik, evalueret i en form, der skalerer langt bedre ved høje blokantal: 2,7× foran det tunede build på 20-core-desktoppen, og på Windows-laptoppen 2,7× foran det tunede build og 2,2× foran MultiPar. Let skade kører stadig den klassiske sti, hvilket er hvorfor de andre niveauer knap nok flyttede sig: transformationen betaler sig kun over omkring 512 beskadigede blokke, så derunder bruger dispatcheren den ikke.

En hurtigere sti er kun værd at have, hvis den ikke kan tage fejl. Begge stier beregner samme størrelse og er bit-identiske ved konstruktion, og hver reparation på denne side var gatet på, at de genopbyggede filer matchede det uberørte sæt: 228 tidtagne reparationer på tværs af maskinerne i denne runde, nul uoverensstemmelser. Leveringsbuildet stoler ikke på den historik. Hver reparation verificerer sit eget output mod filhashene, og en der fejlede, ville automatisk blive gjort om med den klassiske sti, logge afvigelsen, og beholde den klassiske sti resten af den kørsel. Indstillingen findes i betjeningspanelet som Fast PAR mode, hvis du hellere vil undvære den helt, og maskiner med for lidt hukommelse til den afviser den selv frem for at forsøge og fejle. Genmålt 2. august på det aktuelle build: de to desktops lander inden for et par procent af denne tabel, og med Fast PAR mode slået fra falder 20-core-desktoppen tilbage til præcis den klassiske stis langsommere tid, hvilket er det, der siger, at sejren er metoden og ikke betingelserne.

Windows-laptoppens kolonne krævede en rettelse, og den går mod os. Windows degraderer vedvarende baggrundsarbejde til sine effektivitetskerner efter et par sekunder. Vores dæmon fravælger det ved opstart, og det kan ingen af de andre værktøjer, så en tidligere version af denne side publicerede deres struppede tider, som var de værktøjernes egne. At køre den maskine igen med hvert værktøj løftet til høj prioritet flytter hele feltet: på det tungeste skadesniveau går par2-turbo fra 22,4 s til 6,41, og rarpar fra 59,2 s til 14,4, og for én udgave af denne side vendte det kolonnen fra vores til én, vi tabte. Hele laptop-kolonnen måles sådan nu - rettelsen bliver stående, selvom rækken siden er vundet tilbage af algoritmeændringen ovenfor, fordi feltets tider på den maskine kun er ærlige med struppet løftet.

RAR-genoprettelsesposter: reparation uden PAR2

Når PAR2 ikke kan dække skaden, er genoprettelsesposten inde i selve RAR'en den sidste forsvarslinje. Indtil 1.0.8 fejlede vores på ethvert arkiv over omkring 13 MB, så dette ben kunne slet ikke køres. Skaden er tre huller på 3.000 bytes ved 20%, 50% og 80% gennem det beskyttede område. Begge værktøjer producerede output byte-identisk med den uberørte fil, og vores er byte-identisk med det, rar r selv skriver. Bedste af tre, 32-core-desktop, begge værktøjer kørt igen sammen 2. august.

En tidligere version af denne side viste 512 MB-størrelsen som et tab, og forklarede det som prisen for at arbejde gennem bindet i stykker frem for at holde det hele i hukommelsen. Den forklaring var korrekt dengang og er nu forældet: omkostningen var en bit-seriel CRC64 i reparationsstien, erstattet med en tabeldrevet, og tabet forsvandt med den. Der er ikke længere et krydsningspunkt, og det begrænsede arbejdssæt blev bevaret. 2 GB-størrelsen er her, fordi de bind, en dæmon rent faktisk møder, er 8 GB til 20 GB, ikke 512 MB, og et ben, der stopper under det reelle interval, er ikke meget af en test.

Hvad der flyttede dette snit, og kontrollen der siger det. At finde hvilke blokke der er beskadiget, var blevet den største fase af denne reparation - større end selve reparationsaritmetikken - og den kørte på én tråd, læste 64 KB ud af hver gruppe på tværs af filen, én gang pr. gruppe. Den laver nu ét sekventielt gennemløb i filrækkefølge med kontrolsummerne pr. shard beregnet parallelt, og det reparerede bind klones frem for kopieres, hvor filsystemet kan gøre det. Detektion alene faldt fra omkring 300 ms til 18 ms på 512 MB-arkivet, hvilket er det meste af, hvad der flyttede sig ovenfor. Kontrollen er kolonnen ved siden af vores: rar r blev kørt igen i de samme runder på samme maskine og kom tilbage inden for et par procent af sine tidligere tider, så ændringen i hullet er vores, ikke benchmarkens.

M5 Max gentager mønsteret, kørt 31. juli med samme korpus og gates: 0,050 / 0,066 / 0,171 / 0,581 s mod rar rs 0,211 / 0,335 / 0,751 / 1,735 på tværs af 16 MB til 512 MB-størrelserne - 3,0× til 5,1× hurtigere; 2 GB-størrelsen blev ikke kørt på den maskine. De tal går forud for omskrivningen af detektion beskrevet ovenfor, så de er det ældre builds, beholdt her som den anden maskine frem for som et aktuelt tal.

Weavers rarpar mangler kun i denne tabel, og ikke af eget valg: den implementerer ikke denne reparation. Bedt om at reparere et af disse arkiver svarer den "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data" og efterlader filen beskadiget. Den optræder i hver anden sammenligning på denne side: alle fire PAR2-ben ovenfor, alle syv udpakningsformer længere oppe, og genoprettelsesvolumen-benet lige nedenfor, som er præcis det arbejde, den siger den udfører - og som den vinder.

Genoprettelsesvolumener: genopbygning af hele manglende .rev-filer

Den anden halvdel af RARs egen genoprettelseshistorie, og indtil denne runde det største tab på denne side. En .rev-fil er et selvstændigt genoprettelsesvolumen: tre af dem ved siden af et sæt på 21 bind kan genopbygge et hvilket som helst tre bind, der aldrig ankom. Korpus: 1 GiB gemt i 21 bind på 50 MB med rar rv3, hvorefter bind 4, 11 og 19 blev slettet - tre tabt mod tre genoprettelsesvolumener, hvilket er det værste tilfælde, sættet stadig kan overleve. Bedste af tre, hvert genopbygget bind sammenlignet med det uberørte.

32-core-cellen her var 3,12 s mod rar rcs 0,47 i det seneste snit af denne side, publiceret som 6,6× langsommere og det værste tal på den. Årsagen var, at sletnings-løsningen kørte ved omkring 48 MB/s genopbygget output, hvor RARLabs klarede 320; den kører nu på samme tabeldrevne aritmetik som resten af genoprettelseskoden, hvilket er en syvdobling og vender tabet til en sejr på begge maskiner. Marginerne er 3% og 14%, så det er en sejr værd at sige ligeud frem for at overskrifte, og grunden til at det overhovedet siges, er at tabet blev sagt først.

Dette ben findes, fordi Weavers rarpar implementerer præcis dette og bad om at blive målt på det. Den vandt komfortabelt, da vi først publicerede det, og vi publicerede det dengang af den grund.

Filmatchning var aldrig omkostningen, hvilket er værd at notere, fordi det var den intuitive mistænkte: genoprettelsesvolumener bærer ingen filnavne, så vi identificerer hvilke pladser der overlevede ved at tjeksumme hvert bind på disken frem for at stole på, hvad de hedder, og mod et ubeskadiget sæt, hvor matchning er alt, der sker, tager hele gennemløbet 0,18 s.

Hvad der ellers flyttede sig, og hvor det ikke ses. To flere motorændringer landede, som disse korpora ikke kan se, listet her så tallene ovenfor ikke læses som hele historien: RAR5-arkiver med titusindvis af medlemmer opløser hvert medlem én gang frem for at gennemgå listen pr. arbejder, hvilket er 3× mindre processortid ved 40.000 medlemmer; og RAR1.3-bitlæseren arbejder et ord ad gangen, hvilket er 2×. Ingen af dem optræder ovenfor, fordi formerne her har 400 medlemmer og intet RAR1.3.

Hvad vi bevidst ikke gør: vi opretter aldrig PAR2. En downloader har ingen grund til det, og ParPar ejer det ben. Vi køber også hastighed med hukommelse på begge motorer: udpakning topper omkring 240 MB mod unrars 41 MB, og verificering omkring 126 MB mod turbos 7 MB, fordi det er de indbyggede motorer, der følger et løbende download frem for at være selvstændige engangsforestillinger. 128 MiB-ordbog-formen er det værste tilfælde, ved omkring 304 MB mod unrars 139 MB. Den tungeste reparation koster nu også hukommelse: den hurtigere metode for 512-plus manglende blokke arbejder ud fra genoprettelsesdataene holdt resident, så den får lov til op til en fjerdedel af maskinens RAM, med et loft på 4 GB, og en maskine der ikke kan afse det, tager i det stille lavhukommelsesmetoden i stedet - samme aritmetik og samme tider som de midterste rækker i PAR2-tabellen, bare ikke de 3× på den sidste. Vil du have det mindst mulige residente sæt for et enkeltstående job, vinder de dedikerede værktøjer stadig den kolonne.

Transportbevis · målt på 1.2.2

Motoren følger med på rigtige linjer

• ~8,7 Gbps vedvarende gennem en fem-udbyder-flåde på en 10 GbE-linje, inklusive løbende verificering og udpakning - 87 GB-runden ovenfor, 24. august 2026, v1.2.2, 360 forbindelser: 77,4 GB på linjen på 71 s med nyttelasten verificeret og udpakket, efterhånden som den ankom. Ikke et byge-tal: hele jobbet ved den hastighed.
• Ved 1 Gbit og derunder er linjen grænsen, og nzbfast ligger på den: ~96% af en 500 Mbit-linje og ~96% af en 250 Mbit-linje igennem verificering og udpakning, ved en brøkdel af hver rivals hukommelse og disk - afsnittet om under-gigabit-linjer ovenfor.
• Den samlede processoromkostning for hele jobbet på 87 GB-jobbet er 1,7 CPU-sekunder pr. GB med forbindelsesregulatoren til - download over TLS, verificering, reparationsberedskab og udpakning inklusive - mod 3,0 til 28 for feltet i samme runde; fuld-gennemløbs- armen ovenfor bruger 4,3.

Tidligere snit af denne side bar et bredere sæt af transportdemonstrationer - multi-linje-mætningskørsler, per-RTT-pipelining- gevinster, et modtryksbevis, afkodningslofts-målinger - kørt på builds, som v1.2.2 siden har afløst. Under denne sides regel bliver de trukket tilbage frem for at blive stående og ældes, og de vender tilbage, efterhånden som de bliver skåret igen på den aktuelle release; de tre påstande ovenfor er dem, der allerede er genmålt på v1.2.2.