Ytelsestester

Kortversjonen · målt 23. august 2026 på kodelinjen som ble utgitt som nzbfast 1.2.2

Ingen målt klient er billigere på prosessor, minne og disk sett under ett

De nyeste rundene på denne siden ble kjørt 23. og 24. august 2026 - de nyeste av dem på selve v1.2.2-utgivelsesbygget - mot de gjeldende byggene av fire andre klienter på identisk maskinvare, linjer og leverandører: to jobbformer fra 6,5 til 87 GB, og linjefarter fra 250 Mbit til 10 GbE. På tvers av disse rundene var ingen klient billigere enn nzbfast på prosessor, minne og disk sett under ett: hver av dem koster mer på minst to av de tre, det meste noen av dem sparte på en enkelt akse var omtrent 2 prosent - en statistisk uavgjort, innenfor den klientens egen spredning fra kjøring til kjøring - og på disk flyttet hver eneste av dem minst dobbelt så mange byte for et byte-identisk resultat. Som levert holdt nzbfast også minst minne av alle målte klienter, på hver eneste fixture, med 2,0x til 4,5x mot nærmeste rival.

Hvilken er deg?

De fleste nedlastere skriver nedlastingen din til disk minst to ganger: én gang mens den lastes ned, og igjen mens den pakkes ut. nzbfast gjør hele jobben i én omgang, så den skriver omtrent halvparten av bytene per jobb, holder mindre i minnet mens den jobber, og bruker færre prosessorsekunder per GB. Det er mindre belastning på maskinen mens du bruker den og halvparten av skrivingene per jobb på diskene dine, for de samme byte-identiske filene - og fordi hver byte krysser disken omtrent én gang, trenger disken din bare å holde følge med linjen din én gang.

nzbfast vinner ikke hver eneste tabell på denne siden, og de den taper står under etappene vi ikke vinner - inkludert én fra denne samme runden. Det som holdt i hver runde vi målte er den samlede regningen.

Metode først

Oppsettet

• Klienter: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, hver tabell på byggene den navngir. De nyeste rundene (23. august 2026) kappløp feltets da gjeldende bygg - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 og Weaver 0.7.8, dens nyeste utgitte binærfil, identitet bevist med hash - mot kodelinjen som ble utgitt samme natt som nzbfast 1.2.2, så bygget som produserte de nye tallene er det du kan laste ned. De rundene ble kjørt på en 20-kjerners Apple Silicon-maskin på en 1 Gbit-linje. Eldre tabeller beholder byggene og maskinene de kappløp (Apple M-serie-maskiner: "Europa" M1 Ultra på 10 GbE, "Østkysten" M3 Ultra ~2,4-3,0 Gbps-linje) og sier det; de underdriver det leverte bygget snarere enn å smigre det.
• Rettferdighet: samme leverandører og TLS overalt for hver klient, etapper kjørt rygg mot rygg flettet. Hver konkurrent tunet til sitt dokumenterte beste: SABnzbd fikk pipelining_requests=8 (den leveres med 1, altså ikke-pipelinet, og innstillingen er verdt tosifrede prosenter på store jobber), NZBGet fikk ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb sitt dokumenterte oppsett. Siden 20. august 2026 kappløper hver runde fem leverandører i stedet for seks - antall leverandører er ikke en hastighetsspak på disse maskinene, der én leverandør alene kan nå linjetaket, og et fast antall holder rundene sammenlignbare - så et sekstalls-leverandørtall på denne siden er ikke direkte sammenlignbart med et nyere femtalls-tall, og hver tabell sier hvilket den kjørte.
• Sluttilstand: en verifisert, utpakket, brukbar fil, ikke "nedlasting fullført". Det er det du faktisk venter på.
• Reproduserbarhet: hver påstand er datert og målt på samme måte: forløpt tid + grensesnitt-byteteller + prosesstre-topp-RSS, 1-2 s oppløsning. Der en etappe kjøres på en offentlig postet NZB, navngir vi den slik at du kan kjøre den selv.
• Metodenotater som gjelder på tvers av siden: CPU-tid samples fra prosesstreet ved 2 Hz på hver arm av en tabell og settes aldri ved siden av et tall fra en annen regnemåte, fordi de to metodene er uenige med hensikt. Enhets-I/O oppgis i GiB og nettbyte i desimale GB; vi konverterer før vi deler. Og enhver tabell som kappløper vårt eget bygg mot vårt eget bygg bærer en A/A-kontroll - den samme binærfilen kappløpt mot en byte-identisk kopi av seg selv gjennom samme testoppsett - fordi den kontrollen er hvordan vi oppdaget at vårt eget testoppsett ga en ~1,5%-straff til den verktøyet som kjørte først (historien står ved siden av utpakkingstabellene nedenfor). To armer og byttede rekkefølger kansellerer ikke en skjevhet som alltid lander på den første armen; en A/A-kontroll avdekker den.

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

Jo tregere linjen, jo mindre skiller hastigheten klientene - og jo mer skiller regningen

På en linje treg nok er hver klients fullføringstid linjen og ingenting annet, så en treg linje skjuler mange synder. Det den ikke kan skjule er hva hver klient brenner for å fylle den. Vi formet 1 Gbit-riggen til to farter ekte planer faktisk er, og kappløp alle seks armer på hver - samme maskin, samme fem leverandører, tre gjentakelser per klient med rekkefølgen rotert, hver etappe byte-sjekket, 36 av 36 korrekte på tvers av de to rundene. nzbfast-armen ved 500 Mbit er selve v1.2.2-utgivelsesbygget.

Les de to tabellene som en gradient. Ved 250 Mbit lander hele feltet innenfor 18% på klokken og vi leder nærmeste rival med 4,4%; ved 500 Mbit åpner gapet seg til 14,7%; ved gigabit- og 10 GbE-fartene i tabellene over og under åpner det seg videre. Hastighetsforskjeller vokser med linjen. Ressurskolonnene venter ikke på en rask linje: ved hver målte fart holdt hver rival minst 3,9x minnet, brukte mer prosessor, og flyttet omtrent dobbelt så mange diskbyte for den samme byte-identiske filen.

Tilkoblingsregulatoren tjener sin plass på trege linjer, og formerens egen dropp-teller sier hvorfor. Leverte standardinnstillinger holdt 25 tilkoblinger der hver rival kjørte hundrevis; samme binærfil med regulatoren av kjørte 360. Færre strømmer gjennom en fast kø betyr mindre tap og mindre gjensending: formeren registrerte omtrent 4 200 dropp per begrenset etappe mot omtrent 155 000 ubegrenset ved 500 Mbit, og den begrensede armen var raskere, 4,2x lettere på minne og 1,3x lettere på CPU enn vår egen 360-socket- posisjon. Flere tilkoblinger er ikke mer hastighet; under en gigabit er det målbart det motsatte.

Målt 24. august 2026, medianer av tre, på en 20-kjerners Apple Silicon-maskin med linjen formet til hver fart (den formede farten verifisert av en uavhengig probe før hver runde: 248 og 496 Mbit). Den 500 Mbit-nzbfast-armen er v1.2.2-utgivelsestaggens bygg; 250 Mbit-runden ble kjørt timer tidligere på samme kodelinje. Bytetellinger på en formet linje leses fra hver klients egen teller, aldri nettverksgrensesnittet (formeren dropper og TCP sender på nytt, så grensesnittet teller begge kopiene). Klokketider er sammenlignbare innenfor hver tabell, ikke på tvers av ulikt formede runder. ¹ NZBGets tre etapper ved 500 Mbit spente 114-158 s med flate ressursavlesninger - en ekte spredning, så medianen er oppgitt og spredningen er oppgitt heller enn innsnevret.

Det skadede innlegget · re-kappløpt 24. august 2026, hvert bygg gjeldende

Når innlegget har hull i seg: 6,5 GB med 60, 20 og 5 døde artikler

Artikler utløper, servere dropper dem stille, opplastinger lander ufullstendige - og skade er der gapet mellom klienter er bredest, så det får sin egen runde på det nyeste bygget til hver klient, nzbfast v1.2.2 inkludert: Europa 10 GbE-maskin, fem leverandører, 100 tilkoblinger per klient, samme 6,5 GB-utgivelse forgiftet på tre skadenivåer, tre gjentakelser per arm med rekkefølgen alternert, hver etappe byte-sjekket mot den rene filen. 63 av 65 etapper kom tilbake byte-identiske; de to som ikke gjorde det er navngitt nedenfor, fordi de er resultater.

Hvorfor det skadede innlegget er raskt her. Når en artikkel mangler, spør en klient normalt neste server, så neste, til hver server har avvist den - en serievandring hvis avvisninger tar alt fra titalls millisekunder til et par sekunder hver, mens nedlastingen står på null. nzbfast slutter å spørre: så snart paritetsdataen den allerede har dekker det som fortsatt mangler, reparerer den umiddelbart i stedet for å fullføre vandringen. Det er den andre raden - samme binærfil med den oppførselen slått av er 1,4x til 2,3x tregere avhengig av skade - og runden verifiserte at mekanismen slo inn på hver aktiverte etappe og aldri på en deaktivert. Mot nærmeste rival er marginen 2,4x til 2,7x, uten overlapp i noen av de ni gjentakelsesparene.

Disk er der marginen er bredest, og det er ikke reparasjonstriksen. Hver fullførende arm produserte samme 6,48 GB fil; vår flyttet 6,2-6,8 GB disk-I/O for å gjøre det, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB og rustnzb 12,8-13,1 GB. Det er en-omgangs-rørledningen - den avslåtte raden flytter samme 6,2 GB - så det holder på skadede så vel som uskadde innlegg.

¹ SABnzbds tre etapper ved den tyngste skaden kjørte 43, 41 og 60 s - en ekte spredning på identiske inndata, så gjennomsnittet er oppgitt med spennet angitt. ² rustnzb 1.4.5 leverte hver etappe byte-korrekt, og kostnaden ligger i prosessortid heller enn pålitelighet: omtrent 1 620 CPU-sekunder mot en 107 s klokke ved den tyngste skaden - omtrent femten kjerner opptatt gjennom hele etappen - der samme reparerte output koster oss omtrent 50 CPU-sekunder. ³ Weaver flyttet 1,5 GB og 4,9 GB av 6,5 innenfor vår 20-minutters tidsgrense ved de to tyngste skadenivåene - samme ikke-fullføring i alle tre rundene som har kappløpt den, over tre separate netter; tidsgrensen er vår og ikke-fullføringen er resultatet. Ved 5 døde artikler fullførte den korrekt alle tre gangene. Dens prosessorkostnad der er sin egen historie: omtrent 2 325 CPU-sekunder for den 194 s etappen, mot våre 20.

Målt 24. august 2026, alle bygg gjeldende: nzbfast v1.2.2 (selve utgivelsestaggen), NZBGet 26.3-testing (20. august- bygg), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. En kontinuitetsarm kappløp forrige natts nzbfast-bygg inne i samme runde og landet innenfor ett sekund av v1.2.2 på hver fixture, så ingenting her rir på en heldig natt; og rivalenes konfigurasjoner skiller seg fra forrige rundes bare i applikasjonssti, sjekket nøkkel for nøkkel før runden ble kjørt.

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

Lav-minne-stigen: 87 GB i ~0,3 GB RAM

Samme 87 GB-jobb som runden over, kjørt på nytt med harde minnebudsjetter på 2 GB, 1 GB og 256 MB - det auto-størrelsesvelgeren ville valgt på en 8 GB-maskin, en 4 GB-maskin, og en 2 GB NAS. Hver etappe produserte den identiske byte-sjekkede filen, og minnekolonnen fulgte budsjettet, aldri jobben:

Én etappe per budsjett på utgivelses- bygget, gatet mot samme output-sjekksum som seks-arms-runden. Det strammeste budsjettet koster omtrent 9% av klokketiden, og bare fordi denne linjen er 10 GbE - blokker som spilles ut koster tid bare når linjen løper fra disken, så på en typisk hjemme- forbindelse er et lite budsjett nesten gratis. Hele stigen, en 87 GB-nedlasting inkludert, får plass i 0,3-0,6 GB minne; ved leverte standardinnstillinger kjørte jobben på 286 MB. Ingen annen klient tilbyr et hardt prosessomfattende minnebudsjett; de nærmeste tingene er cache-størrelse-knapper, og runden under måler hva de koster.

Klemmen kappløpt mot feltets egne knapper. På 34 GB-fixturen (23. august 2026, 1 Gbit-maskin, fem leverandører, 30 av 30 etapper byte-korrekte), holdt NZBGet til en tilsvarende cache-klemme mer enn doblet CPU-en (215,5 til 453,0 CPU-sekunder, 2,10x) for å kjøpe et 52% kutt i topp-minnet, og SABnzbds klemme var nesten gratis men nådde bare en del av avtrykket. rustnzbs cache-innstilling var dekorativ i bygget som ble kappløpt, og Weaver har ingen minneknapp i det hele tatt, så begge kjørte uklemte som referansekolonner heller enn å bli vurdert på et budsjett de ikke kan holde. Vår egen side av den runden er avløst av v1.2.2-stigen over, som sier det samme ved 2,5x størrelsen: budsjettet er aldri den bindende begrensningen, fordi én omgang holder så lite til å begynne med.

Ledig plass · målt til megabyten

Hvor lite ledig plass en jobb trenger

En skriv-ut-og-pakk-ut-klient trenger plass til arkivvolumene og den utpakkede nyttelasten samtidig, så en jobb vil ikke starte uten omtrent dobbelt så mye ledig plass som nedlastingen. Én omgang trenger nyttelasten - og denne runden målte hvor lite mer, ved å krympe målvolumet til hver klient feilet. nzbfasts svar er en konstant på omtrent 50 MB klaring, ikke et forhold, og det holder fra en 6,5 GB-jobb til en 34 GB-jobb.

Målt på en 20-kjerners Apple Silicon-maskin, 1 Gbit-linje, fem leverandører, tre gjentakelser ved hver grense, hver fullførte etappe byte-sjekket - rivalradene den 22.-23. august 2026 (Weavers 34 GB-celle kjørt om den 24. august, note 1), og nzbfast-raden re-kuttet på v1.2.2-utgivelsesbygget den 24. august, som reproduserte begge grensene eksakt, 12 av 12 etapper enstemmige på tvers av de to fixturene. Cellene våre er et målt gulv: jobben fullfører 3 av 3 med 48,6 MB og 51,0 MB klaring, og avslås 3 av 3 omtrent 17 MB under det - så gulvet er ekte i begge retninger. Det jobben faktisk holder legger seg på outputen pluss omtrent 3 MB; klaringen betaler for de siste øyeblikkene av rørledningen, aldri for en andre kopi. Rivalenes celler er deres målte gulv på 6,5 GB-jobben og en bekreftet tilstrekkelighet ved samme forhold på 34 GB-jobben (3 av 3 byte-korrekte ved nøyaktig det forholdet); vi gikk ikke deres stige videre ned ved den større størrelsen, så deres sanne gulv der kan ligge noe under forholdet, og vi sier det heller enn å runde i vår egen favør.

Hvordan det faktisk ser ut å gå tom betyr like mye som tallet. 17 MB under gulvet sitt treffer nzbfast diskens avslag på en skriving, stopper rent med "tom for diskplass", holder alt som landet journalført, og et nytt forsøk gjenopptar uten å hente på nytt - en delvis fil du beholder, ikke en mislykket jobb. ¹ Weavers store-fixture-celle ble avklart av en ny kjøring den 24. august: tre av tre etapper byte-korrekte ved samme ~2,25x, hver av dem raskere enn den gode etappen fra første forsøk, på ledig plass identisk ned til byten. Ved første forsøk, den 23. august, hadde to av dens tre etapper stanset ved énsifrede MB/s med mer enn 60 GB fortsatt ledig og truffet rundens 40-minutters tidsgrense. Disse stansene kom ikke tilbake, og riggens stansmåling var utrullet og taus på alle tre etappene i den nye kjøringen, noe som er en positiv måling og ikke en manglende. Hva som forårsaket dem er fortsatt ukjent, og en ren ny kjøring er ingen diagnose: det finnes nå seks etapper ved dette forholdet, fire fullførte, og begge feilene kommer fra ett enkelt 80-minutters vindu den første natten.

Nøstede innlegg · målt 28. august 2026

Ti måter å pakke inn et innlegg på, og hvem som faktisk når fram til filen

Mye av det som legges ut, er bevisst vanskelig å åpne. Det virkelige filnavnet ligger begravd inne i et andre arkiv, av og til et tredje, av og til i et annet format på hvert nivå, slik at innlegget røper minst mulig om hva det inneholder. I tillegg kommer innlegg fram skadet: artikler utløper, opplastinger lander ufullstendige, og gjenopprettingsdataene må brukes før noe som helst kan pakkes ut. En nedlaster går gjennom den kjeden for deg, eller så gir den deg en mappe med arkiver og stopper.

Vi bygde derfor ti former som isolerer nettopp dette, lot hver aktuelle klient møte dem, og gjorde så det sammenligninger vanligvis hopper over: der en klient stoppet for tidlig, fullførte vi jobben for hånd med standardverktøyene og tok tiden på det også. En klient som gir opp raskt, ser rask ut helt til du teller arbeidet den etterlater til deg.

nzbfast er den eneste som fullfører alle ti uten hjelp. NZBGet når også filen i hver form, men trenger 16 runder med manuell reparasjon og utpakking i åtte av dem. SABnzbd fullfører fem på egen hånd, og to er uoppnåelige selv for hånd. Weaver når filen i to.

Mønsteret er ikke tilfeldig. Formene nzbfast kommer gjennom og de andre ikke, er de innpakkede og de skadede: et arkiv inni et arkiv, et formatskifte halvveis ned, en kjede i fem nivåer, og framfor alt et arkiv som kommer fram ødelagt med sine egne gjenopprettingsdata ved siden av. På den siste pakker fire klienter det ytre settet feilfritt ut, gir deg det ødelagte arkivet sammen med gjenopprettingssettet som ville reparert det, og stopper.

Der klientene gjør det samme arbeidet, er forskjellen stor. Dette er de sju formene alle fire utbredte klienter når, medregnet den manuelle reparasjonen hver av dem trengte:

Fire til fem ganger raskere, på under halvparten av de skrevne bytene. Disktallet er det som fortsetter å bety noe etter nedlastingen: hver gigabyte i den kolonnen er en gigabyte disken din har måttet ta imot, og klientene som mellomlagrer jobben, skriver ut innholdet, leser det tilbake og skriver det på nytt.

Der vi ikke ligger foran, og hvorfor det er verdt å si. På fire av de ti formene skriver en konkurrent færre byte enn nzbfast under selve nedlastingen. Hver gang fordi den gjorde mindre: på formen med skadet innerarkiv skriver NZBGet 3,29 GB mot våre 4,65, og så skriver reparasjonsrunden dens ytterligere 2,91 og ender på 6,20 GB mot våre 4,65. På de andre er klienten som skrev minst, en som aldri nådde filen. Et lavt disktall er ikke alltid nøysomhet.

Dette er kapasitetstester, ikke hastighetstester. Innholdet er lite og serveres fra minnet over en lokal tilkobling, uten leverandør og uten nettverk i veien, så ingenting her begrenses av nedlastingshastigheten, og de absolutte sekundene er langt kortere enn de samme formene ville tatt i virkeligheten. Om en form i det hele tatt krever håndarbeid, er en egenskap ved formen og klienten og overføres direkte. Sekundene sammenligner klienter som gjør identisk arbeid; de forutsier ikke hvor lang tid en ekte jobb tar.

Fullstendige resultater per form, hva hver form er, og metoden finnes på datasiden om nøstede arkiver.

Hvorfor det betyr noe

Disken din gjør halve jobben

Flash-lagring slites ut ved å bli skrevet til. En 94 GB-utgivelse koster disken din omtrent 90 GB skriving under nzbfast; under en klient som mellomlagrer og pakker ut, koster samme utgivelse omtrent dobbelt. På et NAS med harddisker fjerner formen i én omgang også den lange enkelttrådede omgangen på slutten av hver kryptert nedlasting - en pause målt til 20 sekunder på en rask 32-kjerners arbeidsstasjon med maskinvareakselerert opplåsing, og tilsvarende lengre på de svakere maskinene folk faktisk kjører dette på. Vi siterer det lille tallet fordi det er det vi målte.

Komponent-oppgjør

De mer tekniske testene, for de som liker mer data

Reparasjon (PAR2) og utpakking (RAR) er vår egen native kode heller enn medfølgende tredjeparts-binærfiler, så vi kappløper dem også frittstående mot de dedikerte verktøyene på identiske korpus, på fire maskiner som spenner det en leser faktisk kan eie. En tid teller bare når outputen er byte-identisk med kildenyttelasten: hvert RAR-tall under ble sha256-sjekket mot kilden, og hver reparerte fil mot det ubesudlede settet.

RAR-utpakking: 7 arkivformer, 6 verktøy

Forrige runde av denne tabellen brukte 100 MB til 200 MB per form, noe som var en feil: omtrent 28 ms prosessoppstart var 40% av lagret-etappen, og rekkefølgen den produserte overlever ikke ved en realistisk størrelse. Denne runden er 1 GB nyttelast per form, og den endrer flere svar, inkludert noen i motsatt retning. Arkiver lages av offisiell rar 7.23, så ingen verktøy dømmes på input fra sin egen enkoder, og de samme bytene kappløpes på hver maskin.

Hva som er i nyttelasten betyr mer enn det ser ut som. En nyttelast bygget av blokk-kopier gjør hver komprimerte form til en minne-kopi-test; en nyttelast av ren tekst gjør den til en literal-og-Huffman-test; vi målte begge og de er ikke enige om hvem som vinner. Så de fire komprimerte formene bruker like tredjedeler tekst, strukturerte poster og ukomprimerbare byte, og de to formene i ytterkantene av det spennet er separate etapper med hensikt: store er ukomprimerbar og repetitive er nesten bare treff. Byggeren og testoppsettet er i repositoriet, så korpuset kan bygges på nytt byte for byte.

Re-kappløpt 23. august 2026 på 1.2.2- motoren, og feiingen står. De tre verktøyene en leser oftest veier - våre, unrar 7.23 og rarpar 0.2.5 - ble re-kappløpt på 32-kjerners-skrivebordsmaskinen på utgivelsesmotoren (utpakkingskoden som kappløpes er byte-identisk med 1.2.2-taggen), seks flettede runder, minimum per verktøy, hver etappes output sjekket mot nyttelast-manifestet. Sekunder, lavere er bedre:

Alle syv formene våre, på minimum og på medianen, 1,16x til 4,29x mot unrar. Disse tidene er ikke sammenlignbare celle for celle med den bredere tabellen under - testoppsettet er revidert siden den tabellens runder og rundetallene skiller seg - så les hver tabell mot seg selv. Den bredere tabellen beholder sine egne datoer og sitt seks-verktøys felt, og dens nzbfast-kolonne beskriver motoren 1.2.2 leverer: re-kappløpet over målte den gjeldende motoren på nivå med den tabellens bygg på alle syv former, avgjort av maskinvare-instruksjonstellinger (0,14% færre for samme klokketid), så de cellene er ikke et avløst byggs tall som bærer en gjeldende etikett. Dette re-kappløpet er også der A/A-regelen i oppsettsdelen ble opptjent. En pass samme dag rapporterte først én form som en liten regresjon mot vårt eget forrige bygg, og avlesningen overlevde å kjøre begge armrekkefølgene. En A/A-kontroll - samme binærfil kappløpt mot en byte-identisk kopi av seg selv - viste at testoppsettet ga hvilken som helst arm som kjørte først omtrent en 1,5%-straff: den identiske binærfilen vant bare 6 av 15 runder fra den første plassen, og å bytte rekkefølger kansellerer ikke en skjevhet som alltid lander på hvem som er først. Maskinvare-instruksjonstellinger avgjorde spørsmålet testoppsettet ikke kunne - det nyere bygget trekker tilbake 0,14% færre instruksjoner for samme klokketid, så det var ingen regresjon. Hver vårt-bygg-mot-vårt-bygg-sammenligning vi publiserer nå bærer den kontrollen.

Hele feltet, sekunder, lavere er bedre. Beste av tre, verktøy flettet inne i hver runde heller enn kjørt i blokker, output sjekket mot kildenyttelasten på hver eneste kjøring. Et verktøy som produserte feil byte får en korrekthetsnote, aldri en rask tid. rarpar er Weavers egen RAR- og PAR2-kode, bygget fra kilde ved bd87611; vi fester commit-en heller enn en versjon fordi crate-ene dens bærer tre forskjellige versjonsnumre.

Der feltet ikke kunne konkurrere, og hvorfor. ¹ 7-Zip kappløpt her er Homebrew-pakken, som avviser hver komprimerte form med ERROR: Unsupported Method og leser bare den lagrede formen på macOS. En tidligere versjon av denne siden skyldte det på 7-Zips macOS-bygg, noe som var feil: Homebrew bygger den uten den ikke-frie unRAR-kodeken, mens macOS-bygget 7-zip.org leverer bærer kodeken og dekoder alle syv former, slik Windows-bygget gjør. Re-målt 14. august 2026. Hvis du installerer 7-Zip fra prosjektet heller enn fra Homebrew, beskriver ikke denne kolonnen det du har. ² bsdtar har ingen RAR5-multi-volum-støtte og produserte en avkuttet fil uten å rapportere en feil, så den etappen er en korrekthetsfeil heller enn en treg tid; testoppsettet vårt fanget det ved å sjekke outputen, som er hvorfor det er verdt å sjekke outputen. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar leverer ingen Windows-kommandolinjeverktøy, så det bærbare feltet er fem. ⁶ M5 Max-gruppen kappløper de tre verktøyene en macOS-leser faktisk ville gripe til - unrar, rarpar og oss; unar, bsdtar og 7-Zip ble ikke kappløpt på den maskinen. Dens unrar er 7.22, det nyeste bygget som kjører uten tilsyn der.

Hver form på hver maskin unntatt én, og den ene er uavgjort. De korte-treff-formene kommer ned til to spesifikke ting i dekoderen vår. Et treff på to til trettito byte pleide å betale for et fullt kall inn i platformens minne-kopi-rutine, og kallet kostet mer enn kopien; å kopiere en fast trettito byte gjennom et register i stedet er hvorfor repetitive, solid og 128 MiB-ordboken - de tre formene bygget av korte treff - alle er raske på én gang. Og sjekksummen kjører nedstrøms fra skrivetråden heller enn på den. Den ene cellen vi ikke vinner utvetydig er den lagrede formen på 32-kjerners-skrivebordsmaskinen, der unrar og vi er tre millisekunder fra hverandre på en etappe som kun flytter byte - identisk ved denne tabellens presisjon, så begge cellene er merket og den scores som uavgjort, ikke et tap og ikke en seier.

Formen vi vinner med mest er den usenet faktisk poster hundrevis av om gangen: 400 små filer, 4,3× og 4,4× mot unrar og 5,4× til 5,5× mot rarpar. Det er per-medlem-parallellitet, og det er forskjellen mellom en utpakker skrevet for en nedlastingskø og en skrevet for en kommandolinje. Den lagrede formen, som folketellingen over sier er 84% av bytene på nettet, er en nær uavgjort for de tre seriøse verktøyene, fordi på det punktet flytter alle bare byte.

Ett valg verdt å erklære. Arkivene er pakket med kompressoren festet til fire tråder. RARs blokkdeling følger ellers kjernetallet til hvilken som helst maskin som pakket arkivet, så en 32-kjerners maskin og en 20-kjerners maskin produserer forskjellige byte fra samme input og maskinene slutter å være sammenlignbare. Å feste den gjør utpakkingskorpuset byte-identisk overalt, som er poenget, men det setter også et tak på hvor mye av dekodingen som kan kjøre parallelt - så da de to nærmeste formene var tap, re-kappløp vi dem mot arkiver pakket med alle 32 tråder, for å sjekke at festingen ikke var det som forårsaket det. Det var det ikke: solid gikk fra 4,2% bak til 2,4% bak og 128 MiB-ordboken fra 6,6% til 6,3%, samme rekkefølge uansett. Begge er nå seire på det festede korpuset med en bredere margin enn den sjekken kunne forklare.

Hvorfor det ikke er noen RAR4-rad, og hva som skjer med de innleggene. Hver form over er RAR5 eller RAR7, som er hva usenet poster i dag. Eldre RAR4-arkiver dukker fortsatt opp, og samme motor leser dem, inkludert de komprimerte og passordbeskyttede formene, i samme enkeltomgang som de nyere heller enn å skrive volumene til disk og pakke dem ut etterpå. De får ingen rad her fordi den offisielle rar 7.23 ikke lenger kan lage RAR4, så det finnes intet nøytralt korpus å kappløpe feltet på; det arbeidet sjekkes mot arkiver skrevet av WinRAR 3.00 i stedet, byte for byte mot unrar.

PAR2-verifisering og -reparasjon: 1 GiB-sett, fire skadenivåer

Korpus: 1 GiB tilfeldig nyttelast pakket i lagret-modus i 21 RAR-volumer, deretter to PAR2-sett ved 10% redundans, ett ved 1 MiB-blokker og ett ved 64 KiB, deretter faste skadekart. Hver kjøring bruker samme protokoll: fersk kopi, les hele korpuset én gang for å varme opp cachen, så ta tiden. Beste av tre flettede runder; hvert reparerte volum sammenlignes mot det ubesudlede settet på hver runde. Lavere er bedre.

En korreksjon om korpuset, fordi en tidligere versjon av denne siden overdrev det. Vi sa at hver maskin kjørte et byte-identisk korpus, sjekket med hash. Å hashe hvert volum av hvert sett viser at det er sant for 32-kjerners-skrivebordsmaskinen og den bærbare Windows-maskinen, som stemmer eksakt, og ikke for 20-kjerners-skrivebordsmaskinen, som holder et annet tilfeldig utvalg av samme form: samme 21 volumer ved samme størrelser, samme to blokkstørrelser, og skade verifisert ved samme 3, 101 og 1500 blokker spredt over samme antall filer. Hvert tall inne i en rad er fortsatt målt på byte som hvert verktøy i den raden deler, som er hva hver sammenligning hviler på. Men radene er ikke fire visninger av én input, og siden nyttelastens karakter er verdt omtrent 7% for én konkurrents skanning, er det verdt å si rett ut heller enn å glatte over.

Hvilken par2 som er hvilken. Den originale par2cmdline er referanseimplementasjonen alle andre er forgrenet fra. par2cmdline-turbo er forgreningen som leverer ParPars håndskrevne SIMD-Galois-felt-kjerner: det er nøyaktig hva "turbo" betyr, og det er hvorfor turbo, heller enn originalen, er verktøyet verdt å måle mot. Begge turbo-kolonnene under kjører de samme ParPar-kjernene. Det som skiller dem er ikke aritmetikken men bygget og flaggene.

Bekreftet på leveringsbygget mot den gjeldende rivalen, 24. august 2026. Disse tabellene ble målt før 1.2.2 ble kuttet og før par2cmdline-turbo ga ut 1.5.0 (20. august 2026), så 20-kjerners-kolonnen ble re-kappløpt på begge: vårt 1.2.2-utgivelsesbygg mot turbo 1.5.0, tre flettede runder per etappe, hver reparerte fil sammenlignet mot det ubesudlede settet. Alle fire etapper reproduserer - våre 0,18 / 0,30 / 0,75 / 2,02 mot 0,19 / 0,33 / 0,74 / 2,07 trykt her, og turbo 1.5.0 lander innenfor noen få prosent av bygget i tabellen på hver etappe og begge konfigurasjonene. Cellene står som publisert; de andre tre maskinene beholder sine egne datoer.

Så konkurrenten opptrer to ganger, og én av de kolonnene er dens beste tilfelle heller enn dens standard. Utgivelsesbinærfilen du ville laste ned er kompilert for en generisk grunnlinje-CPU og hasher bare et par filer om gangen; å bygge samme kildekode for den faktiske vertsmaskinens CPU og sende -T16 lar den bruke instruksjonene den maskinen faktisk har og hashe seksten filer om gangen. På den bærbare er det verdt opp til 2,6x, utelukkende fra bygg og flagg. Døm oss på den tunede kolonnen, som er den vanskeligere sammenligningen; den som-levert-kolonnen er hva noen som laster den ned faktisk opplever. par2cmdline er originalen, versjon 1.2.0, bygget fra kilde på hver maskin. rarpar er Weavers egen PAR2-implementasjon, bygget fra kilde med sin Metal GPU-backend aktivert. MultiPars par2j er Windows-bare, så den opptrer på de bærbare Windows-radene alene. M5 Max-radene kappløper de to verktøyene med gjeldende macOS-arm64-bygg ved siden av de to turbo-kolonnene; par2cmdline klassisk ble ikke kappløpt på den maskinen.

Alle seksten nzbfast-celler - fire maskiner ved fire skadenivåer - er våre, flere med mer enn 2× mot det tunede bygget og med 2,3× til 7,7× mot det du faktisk ville laste ned. De tunge-skade-cellene er de interessante, og noten under forklarer algoritmen bak dem.

Originalen er tilbake i tabellen, og det er verdt å se hvorfor forgreningen finnes. En tidligere versjon av denne siden droppet par2cmdline-kolonnen med begrunnelsen at den var tregere enn alt annet i runden, som er sant og ikke en god nok grunn: det er implementasjonen nesten alle andre verktøy stammer fra, og lesere fortjener grunnlinjen heller enn vår påstand om den. Ved det tyngste skadenivået tar den omtrent 69 s der SIMD-forgreningen tar 3,2 s og vi tar 3,1 s. Den faktoren tjue er hele argumentet for de håndskrevne Galois-felt-kjernene, og det er samme argument vi gjør for våre.

Lett skade er tilfellet som betyr noe. En håndfull mislykkede artikler er langt mer typisk enn 101 døde blokker, og ingenting som 1500. Mesteparten av en lett reparasjon er ikke Reed-Solomon-matematikken i det hele tatt, det er å lese og MD5-e en gigabyte, som er hvorfor 3-blokk-raden følger den rene-verifiserings-raden heller enn reparasjonsradene.

Det tyngste skadenivået er en annen type arbeid, og det får en annen algoritme. Det siste nivået skader 1500 blokker på tvers av alle 21 volumer og bruker opp omtrent 91% av gjenopprettingsdataen, som er der Reed-Solomon-aritmetikken, heller enn hashing eller disk, blir nesten alt arbeidet. Leveringsbygget beregner de tyngste reparasjonene med en tallteoretisk transform i stedet for den klassiske Galois-felt-foldingen - samme matematikk, evaluert i en form som skalerer langt bedre ved høye blokktall: 2,7× foran det tunede bygget på 20-kjerners-skrivebordsmaskinen, og på den bærbare Windows-maskinen 2,7× foran det tunede bygget og 2,2× foran MultiPar. Lett skade kjører fortsatt den klassiske veien, som er hvorfor de andre nivåene knapt beveget seg: transformen lønner seg først over omtrent 512 skadede blokker, så under det bruker ikke fordeleren den.

En raskere vei er bare verdt å ha hvis den ikke kan ta feil. Begge veiene beregner samme størrelse og er bit-identiske av konstruksjon, og hver reparasjon på denne siden ble gatet på at de gjenbygde filene stemte mot det ubesudlede settet: 228 tidtatte reparasjoner på tvers av maskinene i denne runden, null avvik. Leveringsbygget stoler ikke på den statistikken. Hver reparasjon verifiserer sin egen output mot filhashene, og en som feilet ville blitt gjort på nytt med den klassiske veien automatisk, logge avviket, og beholde den klassiske veien for resten av den kjøringen. Innstillingen er i dashbordet som Rask PAR-modus hvis du heller vil være uten den helt, og maskiner med for lite minne til den avslår den selv heller enn å prøve og feile. Re-målt 2. august på gjeldende bygg: de to skrivebordsmaskinene lander innenfor noen få prosent av denne tabellen, og med Rask PAR-modus slått av faller 20-kjerners-skrivebordsmaskinen tilbake til nøyaktig den klassiske veiens tregere tid, som er det som sier at seieren er metoden og ikke betingelsene.

Den bærbare Windows-maskinens kolonne trengte en korreksjon, og den går mot oss. Windows forviser vedvarende bakgrunnsarbeid til effektivitetskjernene noen sekunder inn. Vår daemon melder seg ut av det ved oppstart og ingen av de andre verktøyene kan, så en tidligere versjon av denne siden publiserte deres strupede tider som om de var verktøyenes egne. Å kjøre den maskinen på nytt med hvert verktøy løftet til høy prioritet flytter hele feltet: på det tyngste skadenivået går par2-turbo fra 22,4 s til 6,41 og rarpar fra 59,2 s til 14,4, og for én versjon av denne siden snudde det kolonnen fra vår til en vi tapte. Hele den bærbare kolonnen er nå målt slik - korreksjonen står selv om raden siden er vunnet tilbake av algoritmeendringen over, fordi feltets tider på den maskinen bare er ærlige med strupingen løftet.

RAR-gjenopprettingsposter: reparasjon uten PAR2

Når PAR2 ikke kan dekke skaden, er gjenopprettingsposten inne i selve RAR-en siste forsvarslinje. Frem til 1.0.8 feilet vår på ethvert arkiv over omtrent 13 MB, så denne etappen kunne ikke kjøres i det hele tatt. Skade er tre 3000-byte hull ved 20%, 50% og 80% gjennom det beskyttede området. Begge verktøy produserte output byte-identisk med den ubesudlede filen, og vår er byte-identisk med hva rar r selv skriver. Beste av tre, 32-kjerners-skrivebordsmaskin, begge verktøy re-kappløpt sammen 2. august.

En tidligere versjon av denne siden viste 512 MB-størrelsen som et tap, og forklarte det som prisen for å arbeide gjennom volumet i biter heller enn å holde alt i minnet. Den forklaringen var korrekt den gang og er nå avleggs: kostnaden var en bit-serie CRC64 i reparasjonsveien, erstattet med en tabellstyrt en, og tapet fulgte med. Det er ikke lenger noen krysning, og det avgrensede arbeidssettet ble beholdt. 2 GB-størrelsen er her fordi volumene en daemon faktisk møter er 8 GB til 20 GB, ikke 512 MB, og en etappe som stopper under det ekte spennet er ikke mye av en test.

Hva som flyttet dette kuttet, og kontrollen som sier det. Å finne hvilke blokker som var skadet hadde blitt den største fasen av denne reparasjonen - større enn selve reparasjonsaritmetikken - og den kjørte på én tråd, og leste 64 KB ut av hver gruppe gjennom filen, én gang per gruppe. Den lager nå ett sekvensielt pass i filrekkefølge med per-skår-sjekksummene beregnet parallelt, og det reparerte volumet klones heller enn kopieres der filsystemet kan gjøre det. Deteksjon alene falt fra omtrent 300 ms til 18 ms på 512 MB-arkivet, som er mesteparten av det som flyttet over. Kontrollen er kolonnen ved siden av vår: rar r ble re-kappløpt i de samme rundene på samme maskin og kom tilbake innenfor noen få prosent av sine tidligere tider, så endringen i gapet er vår og ikke testens.

M5 Max gjentar mønsteret, kappløpt 31. juli med samme korpus og porter: 0,050 / 0,066 / 0,171 / 0,581 s mot rar rs 0,211 / 0,335 / 0,751 / 1,735 på tvers av 16 MB til 512 MB-størrelsene - 3,0× til 5,1× raskere; 2 GB-størrelsen ble ikke kappløpt på den maskinen. De tallene går forut for deteksjonsomskrivingen beskrevet over, så de er det eldre byggets, holdt her som den andre maskinen heller enn som et gjeldende tall.

Weavers rarpar er fraværende fra denne tabellen alene, og ikke av eget valg: den implementerer ikke denne reparasjonen. Bedt om å fikse ett av disse arkivene svarer den "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data", og lar filen forbli skadet. Den opptrer i hver annen sammenligning på denne siden: alle fire PAR2-etapper over, alle syv utpakkingsformer over det, og gjenopprettingsvolum-etappen rett under, som er jobben den sier den gjør - og som den vinner.

Gjenopprettingsvolumer: gjenoppbygging av hele manglende .rev-filer

Den andre halvparten av RARs egen gjenopprettingshistorie, og frem til denne runden det største tapet på denne siden. En .rev-fil er et frittstående gjenopprettingsvolum: tre av dem ved siden av et 21-volums sett kan gjenoppbygge hvilke som helst tre volumer som aldri ankom. Korpus: 1 GiB lagret i 21 volumer på 50 MB med rar rv3, deretter slettet volum 4, 11 og 19 - tre tapt mot tre gjenopprettingsvolumer, som er det verste tilfellet settet fortsatt kan overleve. Beste av tre, hvert gjenoppbygde volum sammenlignet mot det ubesudlede.

32-kjerners-cellen her var 3,12 s mot rar rcs 0,47 i forrige kutt av denne siden, publisert som 6,6× tregere og det verste tallet på den. Årsaken var utslettelsesløsningen som kjørte ved omtrent 48 MB/s gjenoppbygd output der RARLabs klarte 320; den kjører nå på samme tabellstyrte aritmetikk som resten av gjenopprettingskoden, som er en sjufold forbedring og snur tapet til en seier på begge maskiner. Marginene er 3% og 14%, så det er en seier verdt å si rett ut heller enn å slå stort opp, og grunnen til at det sies i det hele tatt er at tapet ble sagt først.

Denne etappen finnes fordi Weavers rarpar implementerer nøyaktig dette og ba om å bli målt på det. Den vant komfortabelt da vi først publiserte den, og vi publiserte den da av den grunnen.

Filmatching var aldri kostnaden, noe som er verdt å notere fordi det var den intuitive mistenkte: gjenopprettingsvolumer bærer ingen filnavn, så vi identifiserer hvilke plasser som overlevde ved å sjekksumme hvert volum på disk heller enn å stole på hva de kalles, og mot et uskadd sett, der matching er alt som skjer, tar hele passet 0,18 s.

Hva annet flyttet seg, og hvor det ikke vises. To flere motorendringer landet som disse korpusene ikke kan se, listet her slik at tallene over ikke leses som hele historien: RAR5-arkiver med titusenvis av medlemmer løser hvert medlem én gang heller enn å vandre listen per arbeider, som er 3× mindre prosessortid ved 40 000 medlemmer; og RAR1.3-bitleseren jobber ett ord om gangen, som er 2×. Ingen av dem vises over, fordi formene her har 400 medlemmer og ingen RAR1.3.

Hva vi bevisst ikke gjør: vi lager aldri PAR2. En nedlaster har ingen grunn til det, og ParPar eier den etappen. Vi kjøper også hastighet med minne på begge motorene: utpakking topper rundt 240 MB mot unrars 41 MB, og verifisering rundt 126 MB mot turbos 7 MB, fordi dette er de innebygde motorene som rir en levende nedlasting heller enn frittstående engangskjøringer. 128 MiB-ordbok-formen er det verste av det, ved omtrent 304 MB mot unrars 139 MB. Den tyngste reparasjonen koster nå minne også: den raskere metoden for 512-pluss manglende blokker jobber fra gjenopprettingsdataen holdt resident, så den får lov til opptil en fjerdedel av maskinens RAM, begrenset til 4 GB, og en maskin som ikke kan avse det tar stille den lav-minne-metoden i stedet - samme aritmetikk og samme tider som de midtre radene i PAR2-tabellen, bare ikke 3× på den siste. Hvis du vil ha den minst mulige residente størrelsen for en frittstående jobb, vinner de dedikerte verktøyene fortsatt den kolonnen.

Transport-bevis · målt på 1.2.2

Motoren holder følge med ekte linjer

• ~8,7 Gbps vedvarende gjennom en fem-leverandør-flåte på en 10 GbE-linje, inkludert strømmende verifisering og utpakking - 87 GB-runden over, 24. august 2026, v1.2.2, 360 tilkoblinger: 77,4 GB over nett på 71 s med nyttelasten verifisert og pakket ut etter hvert som den ankom. Ikke et burst-tall: hele jobben ved den farten.
• Ved 1 Gbit og under er linjen grensen og nzbfast sitter på den: ~96% av en 500 Mbit-linje og ~96% av en 250 Mbit-linje gjennom verifisering og utpakking, ved en brøkdel av hver rivals minne og disk - underkapittel-delen over.
• Hele-jobben-prosessorkostnaden på 87 GB-jobben er 1,7 CPU-sekunder per GB med tilkoblingsregulatoren på - nedlasting over TLS, verifisering, reparasjonsberedskap og utpakking inkludert - mot 3,0 til 28 for feltet i samme runde; full-gjennomstrømnings- armen over bruker 4,3.

Tidligere kutt av denne siden bar et bredere sett transportdemonstrasjoner - multi-linje-metningskjøringer, per-RTT-pipelining- gevinster, en motpress-bevis, dekode-tak-målinger - kappløpt på bygg som v1.2.2 siden har avløst. Under denne sidens regel er de trukket tilbake heller enn latt eldes, og kommer tilbake etter hvert som de re-kuttes på det gjeldende utgivelsen; de tre påstandene over er de allerede re-målt på v1.2.2.