Benchmarks

De korte versie · gemeten 23 augustus 2026 op de codelijn die uitkwam als nzbfast 1.2.2

Geen enkele gemeten client is goedkoper op processor, geheugen en schijf samen

De nieuwste rondes op deze pagina liepen op 23 en 24 augustus 2026 - de nieuwste ervan op de v1.2.2-releasebuild zelf - tegen de actuele builds van vier andere clients op identieke hardware, lijnen en providers: twee taakvormen van 6,5 tot 87 GB, en lijnsnelheden van 250 Mbit tot 10 GbE. Over die rondes heen was geen enkele client goedkoper dan nzbfast op processor, geheugen en schijf samen: elke client kost meer op ten minste twee van de drie, het meeste dat een van hen op één enkele as bespaarde was ongeveer 2 procent - een statistisch gelijkspel, binnen de eigen spreiding van run tot run van die client - en op schijf verplaatste elk van hen minstens tweemaal zoveel bytes voor een byte-identiek resultaat. Zoals uitgeleverd hield nzbfast ook het minste geheugen vast van elke gemeten client, op elke fixture, met een factor 2,0x tot 4,5x tegenover de naaste concurrent.

Welke bent u?

De meeste downloaders schrijven uw download minstens tweemaal naar schijf: eenmaal tijdens het downloaden, en nogmaals tijdens het uitpakken. nzbfast doet de hele taak in één doorgang, dus het schrijft ongeveer de helft van de bytes per taak, houdt minder in het geheugen terwijl het werkt, en besteedt minder processorseconden per GB. Dat is minder belasting op de machine terwijl u die gebruikt en de helft van de schrijfacties per taak op uw schijven, voor dezelfde byte-identieke bestanden - en omdat elke byte ongeveer één keer over de schijf gaat, hoeft uw schijf uw lijn maar één keer bij te benen.

nzbfast wint niet elke tabel op deze pagina, en de tabellen die het verliest staan onder de etappes die we niet winnen - inclusief één uit dezelfde ronde. Wat in elke ronde die we gemeten hebben standhield, is de gecombineerde rekening.

Eerst de methode

De opzet

• Clients: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, elke tabel op de builds die hij noemt. De nieuwste rondes (23 augustus 2026) racete tegen de dan actuele builds van het veld - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 en Weaver 0.7.8, zijn nieuwste uitgeleverde binary, identiteit bewezen via hash - tegen de codelijn die die avond uitkwam als nzbfast 1.2.2, dus de build die de nieuwe cijfers opleverde is degene die u kunt downloaden. Die rondes liepen op een 20-core Apple Silicon-machine op een lijn van 1 Gbit. Oudere tabellen behouden de builds en machines waartegen ze racete (Apple M-serie-machines: "Europa" M1 Ultra op 10 GbE, "oostkust" M3 Ultra ~2,4-3,0 Gbps-lijn) en zeggen dat ook; ze onderschatten de uitgeleverde build eerder dan hem te vleien.
• Eerlijkheid: overal dezelfde providers en TLS voor elke client, etappes achter elkaar afgewisseld gereden. Elke concurrent afgesteld op zijn gedocumenteerde optimum: SABnzbd kreeg pipelining_requests=8 (het wordt uitgeleverd op 1, dus ongepipelined, en de instelling is dubbelcijferige percentages waard op grote taken), NZBGet kreeg ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb zijn gedocumenteerde configuratie. Sinds 20 augustus 2026 racet elke ronde vijf providers in plaats van zes - het aantal providers is geen doorvoerhendel op deze machines, waar één provider alleen al het lijnplafond kan bereiken, en een vaste set houdt rondes vergelijkbaar - dus een cijfer met zes providers op deze pagina is niet rechtstreeks vergelijkbaar met een nieuwer cijfer met vijf, en elke tabel zegt welke van de twee hij liep.
• Eindtoestand: een geverifieerd, uitgepakt, bruikbaar bestand, niet "download voltooid". Dat is waar u werkelijk op wacht.
• Reproduceerbaarheid: elke bewering is gedateerd en op dezelfde manier gemeten: verstreken tijd + interfacebyte-tellers + piek-RSS van de procesboom, resolutie van 1-2 s. Waar een etappe draait op een publiek geplaatste NZB, noemen we hem, zodat u hem zelf kunt draaien.
• Methodenotities die voor de hele pagina gelden: CPU-tijd wordt bemonsterd uit de procesboom op 2 Hz op elke arm van een tabel en nooit naast een cijfer uit een andere boekhouding gezet, omdat de twee methoden principieel van elkaar verschillen. Schijf-I/O wordt opgegeven in GiB en netwerkbytes in decimale GB; we rekenen om voordat we delen. En elke tabel die onze eigen build tegen onze eigen build laat racen draagt een A/A-controle - dezelfde binary tegen een byte-identieke kopie van zichzelf, via dezelfde testbank - omdat die controle is hoe we onze eigen shootout-testbank betrapten op het geven van een penalty van ~1,5% aan wie het gereedschap ook als eerste liep (het verhaal staat naast de extractietabellen verderop). Twee armen en omgewisselde volgordes heffen een bias die altijd op de eerste arm landt niet op; een A/A-controle legt hem bloot.

Tragere lijnen · gemeten 24 augustus 2026 op nzbfast 1.2.2

Hoe trager de lijn, hoe minder snelheid clients scheidt - en hoe meer de rekening dat wel doet

Op een lijn die traag genoeg is, is de eindtijd van elke client de lijn en niets anders, dus een trage lijn verbergt veel zonden. Wat hij niet kan verbergen is wat elke client verbrandt om hem te vullen. We beperkten de 1 Gbit-opstelling tot twee snelheden die echte plannen echt hebben en racete alle zes armen op elke snelheid - dezelfde machine, dezelfde vijf providers, drie herhalingen per client met de volgorde geroteerd, elke etappe byte-gecontroleerd, 36 van de 36 correct over de twee rondes heen. De nzbfast-arm bij 500 Mbit is de v1.2.2-releasebuild zelf.

Lees de twee tabellen als een verloop. Bij 250 Mbit landt het hele veld binnen 18% op de klok en lopen we 4,4% voor op de naaste concurrent; bij 500 Mbit opent het gat naar 14,7%; bij de gigabit- en 10 GbE-snelheden in de tabellen erboven en eronder opent het verder. Snelheidsverschillen groeien met de lijn. De resourcekolommen wachten niet op een snelle lijn: bij elke gemeten snelheid hield elke concurrent minstens 3,9x het geheugen vast, besteedde meer processor, en verplaatste ongeveer tweemaal de schijfbytes voor hetzelfde byte-identieke bestand.

De verbindingsregelaar verdient zichzelf terug op trage lijnen, en de eigen dropteller van de shaper zegt waarom. Standaardinstellingen hielden 25 verbindingen aan waar elke concurrent honderden liet lopen; dezelfde binary met de regelaar uit liep er 360. Minder stromen door een vaste wachtrij betekent minder verlies en minder opnieuw versturen: de shaper registreerde ongeveer 4.200 drops per beperkte etappe tegenover ongeveer 155.000 onbeperkt bij 500 Mbit, en de beperkte arm was sneller, 4,2x lichter op geheugen en 1,3x lichter op CPU dan onze eigen houding met 360 sockets. Meer verbindingen is niet meer snelheid; onder een gigabit is het meetbaar het tegenovergestelde.

Gemeten 24 augustus 2026, medianen van drie, op een 20-core Apple Silicon-machine met zijn lijn beperkt tot elke snelheid (de beperkte snelheid geverifieerd door een onafhankelijke proef voor elke ronde: 248 en 496 Mbit). De nzbfast-arm bij 500 Mbit is de releasetag-build van v1.2.2; de ronde bij 250 Mbit liep uren eerder op dezelfde codelijn. Bytetellingen op een beperkte lijn worden afgelezen van de eigen teller van elke client, nooit van de netwerkinterface (de shaper laat vallen en TCP verstuurt opnieuw, dus de interface telt beide kopieën). Klokken zijn vergelijkbaar binnen elke tabel, niet tussen verschillend beperkte rondes. ¹ De drie etappes van NZBGet bij 500 Mbit liepen uiteen van 114-158 s met vlakke resourcewaarden - een echte spreiding, dus de mediaan wordt opgegeven en de spreiding wordt vermeld in plaats van versmald.

De beschadigde post · opnieuw geracet 24 augustus 2026, elke build actueel

Als de post gaten heeft: 6,5 GB met 60, 20 en 5 dode artikelen

Artikelen verlopen, servers laten ze stilletjes vallen, uploads komen onvolledig aan - en schade is waar het gat tussen clients het breedst is, dus krijgt het een eigen ronde op de nieuwste build van elke client, nzbfast v1.2.2 inbegrepen: Europese 10 GbE-machine, vijf providers, 100 verbindingen per client, dezelfde release van 6,5 GB vergiftigd op drie schadeniveaus, drie herhalingen per arm met de volgorde afgewisseld, elke etappe byte-gecontroleerd tegen het schone bestand. 63 van de 65 etappes kwamen byte-identiek terug; de twee die dat niet deden staan hieronder genoemd, want ze zijn resultaten.

Waarom de beschadigde post hier snel gaat. Ontbreekt er een artikel, dan vraagt een client normaal gesproken de volgende server, dan de volgende, tot elke server het geweigerd heeft - een opeenvolgende gang waarvan de weigeringen tussen tientallen milliseconden en een paar seconden elk kosten, terwijl de download op nul staat. nzbfast stopt met vragen: zodra de herstelgegevens die al binnen zijn dekken wat nog ontbreekt, herstelt het meteen in plaats van de gang af te maken. Dat is de tweede rij - dezelfde binary met dat gedrag uitgeschakeld is 1,4x tot 2,3x trager afhankelijk van de schade - en de ronde verifieerde dat het mechanisme op elke ingeschakelde etappe inschakelde en nooit op een uitgeschakelde. Tegen de naaste concurrent is de marge 2,4x tot 2,7x, zonder overlap in een van de negen herhalingsparen.

Schijf is waar de marge het breedst is, en het is niet de herstelkunstgreep. Elke voltooiende arm produceerde hetzelfde bestand van 6,48 GB; de onze verplaatste 6,2-6,8 GB aan schijf-I/O om dat te doen, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB en rustnzb 12,8-13,1 GB. Dat is de one-pass-pijplijn - de uitgeschakelde rij verplaatst dezelfde 6,2 GB - dus het geldt zowel op beschadigde als op onbeschadigde posts.

¹ De drie etappes van SABnzbd bij de zwaarste schade liepen 43, 41 en 60 s - een echte spreiding op identieke invoer, dus het gemiddelde wordt opgegeven met het bereik vermeld. ² rustnzb 1.4.5 leverde elke etappe byte-correct, en zijn kosten zitten in processortijd eerder dan in betrouwbaarheid: ongeveer 1.620 CPU-seconden tegen een klok van 107 s bij de zwaarste schade - ruwweg vijftien kernen bezet gedurende de hele etappe - waar dezelfde herstelde uitvoer ons ongeveer 50 CPU-seconden kost. ³ Weaver verplaatste 1,5 GB en 4,9 GB van de 6,5 binnen onze afkapgrens van 20 minuten op de twee zwaarste schadeniveaus - hetzelfde niet-klaarkomen in alle drie de rondes die het geracet hebben, op drie afzonderlijke nachten; de afkapgrens is de onze en het niet-klaarkomen is het resultaat. Bij 5 dode artikelen voltooide het correct alle drie de keren. Zijn processorkosten daar zijn een eigen verhaal: ongeveer 2.325 CPU-seconden voor de etappe van 194 s, tegen onze 20.

Gemeten 24 augustus 2026, alle builds actueel: nzbfast v1.2.2 (de releasetag zelf), NZBGet 26.3-testing (build van 20 augustus), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. Een continuïteitsarm racete de nzbfast-build van de vorige avond binnen dezelfde ronde en landde binnen een seconde van v1.2.2 op elke fixture, dus niets hier rijdt op een gelukkige avond; en de configuraties van de concurrenten verschillen van die van de vorige ronde alleen in toepassingspad, sleutel voor sleutel gecontroleerd voordat de ronde liep.

Uithongeren van RAM · gemeten 24 augustus 2026 op nzbfast 1.2.2

De low-memory-ladder: 87 GB in ~0,3 GB RAM

Dezelfde taak van 87 GB als de ronde hierboven, opnieuw gedraaid bij vaste geheugenbudgetten van 2 GB, 1 GB en 256 MB - wat de auto-sizer zou kiezen op een machine met 8 GB, een met 4 GB, en een NAS met 2 GB. Elke etappe leverde het identieke byte-gecontroleerde bestand op, en de geheugenkolom volgde het budget, nooit de taak:

Eén etappe per budget op de releasebuild, getoetst aan dezelfde uitvoerchecksum als de ronde met zes armen. Het strakste budget kost ongeveer 9% van de klok, en alleen omdat deze lijn 10 GbE is - overgemorste blokken kosten alleen tijd wanneer de lijn de schijf voorbijloopt, dus op een gewone thuisverbinding is een klein budget bijna gratis. De hele ladder, een download van 87 GB inbegrepen, past in 0,3-0,6 GB geheugen; bij standaardinstellingen liep de taak in 286 MB. Geen andere client biedt een hard, procesbreed geheugenbudget; het dichtst in de buurt komen cachegrootte-instellingen, en de ronde hieronder meet wat die kosten.

De klem geracet tegen de eigen knoppen van het veld. Op de fixture van 34 GB (23 augustus 2026, 1 Gbit-machine, vijf providers, 30 van de 30 etappes byte-correct), verdubbelde het houden van NZBGet aan een gelijkwaardige cacheklem meer dan zijn CPU (215,5 naar 453,0 CPU-seconden, 2,10x) om een besparing van 52% op zijn piekgeheugen te kopen, en de klem van SABnzbd was bijna gratis maar bereikte maar een deel van zijn voetafdruk. De cache-instelling van rustnzb was decoratief in de geracete build, en Weaver heeft helemaal geen geheugenknop, dus beide liepen ongeklemd als referentiekolommen in plaats van beoordeeld te worden op een budget dat ze niet kunnen aanhouden. Onze eigen kant van die ronde is vervangen door de v1.2.2-ladder hierboven, die hetzelfde zegt op 2,5x de omvang: het budget is nooit de bindende beperking, omdat one-pass zo weinig vasthoudt om mee te beginnen.

Vrije ruimte · gemeten tot op de megabyte

Hoe weinig vrije ruimte een taak nodig heeft

Een client die eerst wegschrijft en dan uitpakt heeft in één keer ruimte nodig voor de archiefvolumes en de uitgepakte payload, dus een taak start niet zonder ruwweg tweemaal de download aan vrije ruimte. One-pass heeft de payload nodig - en deze ronde mat hoeveel meer, door het doelvolume te verkleinen tot elke client faalde. Het antwoord van nzbfast is een constante van ongeveer 50 MB marge, geen verhouding, en dat geldt van een taak van 6,5 GB tot een van 34 GB.

Gemeten op een 20-core Apple Silicon-machine, 1 Gbit-lijn, vijf providers, drie herhalingen bij elke grens, elke voltooide etappe byte-gecontroleerd - de rijen van de concurrenten op 22-23 augustus 2026 (cel van 34 GB van Weaver herhaald op 24 augustus, voetnoot 1), en de rij van nzbfast opnieuw gesneden op de v1.2.2-releasebuild op 24 augustus, wat beide grenzen exact reproduceerde, 12 van de 12 etappes eensgezind over de twee fixtures. Onze cellen zijn een gemeten bodem: de taak voltooit 3 van de 3 met 48,6 MB en 51,0 MB marge, en weigert 3 van de 3 ongeveer 17 MB daaronder - dus de bodem is echt in beide richtingen. Wat de taak werkelijk vasthoudt komt neer op de output plus ongeveer 3 MB; de marge betaalt voor de laatste momenten van de pijplijn, nooit voor een tweede kopie. De cellen van de concurrenten zijn hun gemeten bodem op de taak van 6,5 GB en een bevestigde toereikendheid bij dezelfde verhouding op die van 34 GB (3 van de 3 byte-correct bij precies die verhouding); we liepen hun ladder bij de grotere omvang niet verder naar beneden af, dus hun werkelijke bodem daar kan wat onder de verhouding liggen, en dat zeggen we ook liever dan in ons eigen voordeel af te ronden.

Hoe het er werkelijk uitziet als de ruimte opraakt doet er evenveel toe als het getal. Bij 17 MB onder zijn bodem raakt nzbfast de weigering van de schijf bij een schrijfactie, stopt netjes met "geen schijfruimte meer", houdt alles vast wat al binnen is en journaalt het, en een nieuwe poging hervat zonder opnieuw op te halen - een deel dat u houdt, geen mislukte taak. ¹ De cel van Weaver bij de grote fixture is opgelost door een herhaling op 24 augustus: drie van de drie etappes byte-correct bij dezelfde ~2,25x, elk sneller dan de goede etappe van de eerste poging, bij vrije ruimte die tot op de byte gelijk was. Bij de eerste poging, op 23 augustus, waren twee van zijn drie etappes gestagneerd bij enkele MB/s met meer dan 60 GB nog vrij en haalden ze de afkapgrens van 40 minuten van de ronde. Die stagnaties kwamen niet terug, en de stagnatiemeting van de opstelling was op alle drie de etappes van de herhaling actief en stil, wat een positieve meting is en geen ontbrekende. Wat ze veroorzaakte is nog onbekend, en een schone herhaling is geen diagnose: er bestaan nu zes etappes bij deze verhouding, vier voltooid, en beide mislukkingen komen uit één venster van 80 minuten in de eerste nacht.

Geneste berichten · gemeten op 28 augustus 2026

Tien manieren om een bericht te verpakken, en wie het bestand echt bereikt

Veel van wat er wordt geplaatst is met opzet moeilijk te openen. De echte bestandsnaam zit verstopt in een tweede archief, soms een derde, soms op elk niveau in een ander formaat, zodat het bericht zo weinig mogelijk prijsgeeft over de inhoud. Daar komt bij dat berichten beschadigd aankomen: artikelen verlopen, uploads komen onvolledig binnen en de herstelgegevens moeten worden gebruikt voordat er iets uitgepakt kan worden. Een downloader loopt die keten voor u af, of hij geeft u een map vol archieven en stopt.

We hebben daarom tien vormen gebouwd die precies dat isoleren, elke actuele client ertegen laten uitkomen en vervolgens gedaan wat vergelijkingen meestal overslaan: waar een client vroegtijdig stopte, hebben we het werk met de hand afgemaakt met de standaardgereedschappen en dat ook geklokt. Een client die snel opgeeft lijkt snel, tot je het werk meetelt dat hij bij jou achterlaat.

nzbfast is de enige die alle tien zonder hulp afmaakt. NZBGet bereikt het bestand ook bij elke vorm, maar heeft daarvoor 16 rondes handmatig herstellen en uitpakken nodig bij acht ervan. SABnzbd voltooit er vijf zonder hulp en twee blijven zelfs met de hand onbereikbaar. Weaver bereikt het bestand bij twee.

Het patroon is niet willekeurig. De vormen die nzbfast wel aflegt en de anderen niet, zijn de verpakte en de beschadigde: een archief in een archief, een formaatwissel halverwege, een keten van vijf niveaus en vooral een archief dat beschadigd aankomt met zijn eigen herstelgegevens ernaast. Bij die laatste pakken vier clients de buitenste set foutloos uit, geven u het defecte archief samen met de herstelset die het zou repareren, en stoppen.

Waar clients hetzelfde werk afmaken, is het verschil groot. Dit zijn de zeven vormen die alle vier de gangbare clients bereiken, inclusief het handmatige herstel dat elk nodig had:

Vier tot vijf keer sneller, met minder dan de helft van de geschreven bytes. Het schijfcijfer is het cijfer dat na het downloaden blijft tellen: elke gigabyte in die kolom is een gigabyte die uw schijf heeft moeten verwerken, en de clients die het werk tussentijds opslaan schrijven de inhoud weg, lezen die terug en schrijven die opnieuw.

Waar we niet voorop lopen, en waarom dat gezegd moet worden. Bij vier van de tien vormen schrijft een concurrent tijdens het downloaden zelf minder bytes dan nzbfast. Steeds omdat hij minder deed: bij de vorm met een beschadigd binnenarchief schrijft NZBGet 3,29 GB tegenover onze 4,65, waarna zijn herstelronde er nog 2,91 bij schrijft en op 6,20 GB eindigt tegenover onze 4,65. Bij de andere is de client die het minst schreef er een die het bestand nooit bereikte. Een laag schijfcijfer is niet altijd zuinigheid.

Dit zijn capaciteitstests, geen snelheidstests. De inhoud is klein en wordt vanuit het geheugen over een lokale verbinding geleverd, zonder provider en zonder netwerk ertussen, dus niets hier wordt begrensd door de downloadsnelheid en de absolute seconden zijn veel korter dan dezelfde vormen in de praktijk zouden kosten. Of een vorm überhaupt handwerk vergt, is een eigenschap van de vorm en de client en laat zich rechtstreeks vertalen. De seconden vergelijken clients die identiek werk doen; ze voorspellen niet hoe lang een echte taak duurt.

Volledige resultaten per vorm, wat elke vorm is en de methode staan op de gegevenspagina over geneste archieven.

Waarom het ertoe doet

Uw schijf doet de helft van het werk

Flashopslag slijt door erop te schrijven. Een release van 94 GB kost uw schijf ongeveer 90 GB aan schrijven onder nzbfast; onder een client die staged en uitpakt, kost dezelfde release ruwweg het dubbele. Op een NAS met harde schijven verwijdert de one-pass-vorm ook de lange, eendraads pas aan het einde van elke versleutelde download - een pauze gemeten op 20 seconden op een snel 32-core werkstation met hardwareversnelde ontgrendeling, en navenant langer op de zuinige machines waarop de meeste mensen dit werkelijk draaien. We citeren het kleine getal omdat het het getal is dat we gemeten hebben.

Onderdeel-shootouts

De technischere benchmarks, voor wie meer data wil

Herstel (PAR2) en uitpakken (RAR) zijn onze eigen native code in plaats van gebundelde binaries van derden, dus racen we ze ook zelfstandig tegen de speciale gereedschappen op identieke corpora, op vier machines die dekken wat een lezer echt zou kunnen bezitten. Een tijd telt alleen als de output byte-identiek is aan de bronpayload: elk RAR-cijfer hieronder is sha256-gecontroleerd tegen de bron, en elk hersteld bestand tegen de ongeschonden set.

RAR-extractie: 7 archiefvormen, 6 gereedschappen

De vorige ronde van deze tabel gebruikte 100 MB tot 200 MB per vorm, wat een vergissing was: ongeveer 28 ms procesopstart was 40% van de store-etappe, en de volgorde die dat opleverde overleeft niet bij een realistische omvang. Deze ronde is 1 GB payload per vorm, en dat verandert verschillende antwoorden, sommige de andere kant op. Archieven worden gemaakt door de officiële rar 7.23, dus geen gereedschap wordt beoordeeld op invoer van zijn eigen encoder, en dezelfde bytes worden op elke machine geracet.

Wat in de payload zit doet er meer toe dan het lijkt. Een payload opgebouwd uit blokkopieën maakt van elke gecomprimeerde vorm een geheugenkopie-benchmark; een payload van puur tekst maakt er een literals-en-Huffman-benchmark van; we hebben beide gemeten en ze zijn het niet eens over wie wint. Daarom gebruiken de vier gecomprimeerde vormen gelijke derden tekst, gestructureerde records en niet-comprimeerbare bytes, en de twee vormen aan de uiteinden van dat bereik zijn met opzet aparte etappes: store is niet comprimeerbaar en repetitive is bijna alleen maar matches. De generator en de testbank staan in de repository, dus het corpus kan byte voor byte opnieuw worden gebouwd.

Opnieuw geracet op 23 augustus 2026 op de 1.2.2-engine, en de sweep houdt stand. De drie gereedschappen die een lezer het vaakst weegt - de onze, unrar 7.23 en rarpar 0.2.5 - werden opnieuw geracet op de 32-core desktop op de releaseengine (de geracete extractiecode is byte-identiek aan de tag 1.2.2), zes afgewisselde rondes, minimum per gereedschap, de uitvoer van elke etappe gecontroleerd tegen het payload-manifest. Seconden, lager is beter:

Alle zeven vormen zijn van ons, op het minimum en op de mediaan, 1,16x tot 4,29x tegen unrar. Deze tijden zijn niet vergelijkbaar cel voor cel met de bredere tabel hieronder - de testbank is herzien sinds de rondes van die tabel en de rondetellingen verschillen - lees dus elke tabel tegen zichzelf. De bredere tabel behoudt zijn eigen data's en zijn veld van zes gereedschappen, en zijn nzbfast-kolom beschrijft de engine die 1.2.2 uitlevert: de herrace hierboven mat de huidige engine naast de build van die tabel op alle zeven vormen, beslecht door hardware-instructietellingen (0,14% minder voor dezelfde klok), dus die cellen zijn geen cijfers van een achterhaalde build met een actueel label. Deze herrace is ook waar de A/A-regel in de opzetsectie is verdiend. Een pas van dezelfde dag rapporteerde eerst één vorm als een kleine regressie tegen onze eigen vorige build, en de lezing overleefde het draaien van beide armvolgordes. Een A/A-controle - dezelfde binary geracet tegen een byte-identieke kopie van zichzelf - liet zien dat de testbank aan wie de arm ook als eerste liep ongeveer een penalty van 1,5% gaf: de identieke binary won maar 6 van de 15 rondes vanaf de eerste slot, en het omwisselen van volgordes heft een bias die altijd op wie eerst is landt niet op. Hardware-instructietellingen beslechtten de vraag die de testbank niet kon - de nieuwere build haalt 0,14% minder instructies binnen voor dezelfde klok, dus er was geen regressie. Elke vergelijking van onze-build-tegen-onze-build die we nu publiceren draagt die controle.

Het hele veld, seconden, lager is beter. Beste van drie, gereedschappen afgewisseld binnen elke ronde in plaats van in blokken gedraaid, uitvoer gecontroleerd tegen de bronpayload op elke afzonderlijke run. Een gereedschap dat de verkeerde bytes produceerde krijgt een correctheidsnotitie, nooit een snelle tijd. rarpar is Weaver's eigen RAR- en PAR2-code, uit bron gebouwd op bd87611; we spelden de commit vast in plaats van een versie omdat zijn crates drie verschillende versienummers dragen.

Waar het veld niet kon meekomen, en waarom. ¹ De hier geracete 7-Zip is het Homebrew-pakket, dat elke gecomprimeerde vorm weigert met ERROR: Unsupported Method en op macOS alleen de opgeslagen vorm leest. Een eerdere versie van deze pagina weet dat aan de macOS-build van 7-Zip, wat onjuist was: Homebrew bouwt het zonder de niet-vrije unRAR-codec, terwijl de macOS-build die 7-zip.org uitlevert de codec meeneemt en alle zeven vormen decodeert, zoals de Windows-build ook doet. Opnieuw gemeten op 14 augustus 2026. Als u 7-Zip installeert vanaf het project in plaats van vanaf Homebrew, beschrijft deze kolom niet wat u heeft. ² bsdtar heeft geen ondersteuning voor RAR5-multivolume en produceerde een afgekapt bestand zonder een fout te melden, dus die etappe is een correctheidsfout eerder dan een trage tijd; onze testbank betrapte het door de uitvoer te controleren, wat is waarom het de moeite waard is de uitvoer te controleren. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar levert geen Windows-opdrachtregelgereedschap, dus het laptopveld is vijf. ⁶ De M5 Max-groep racet de drie gereedschappen die een macOS-lezer werkelijk zou pakken - unrar, rarpar en de onze; unar, bsdtar en 7-Zip werden op die machine niet geracet. Zijn unrar is 7.22, de nieuwste build die daar zonder toezicht draait.

Elke vorm op elke machine behalve één, en die ene is gelijkspel. De vormen met korte matches komen neer op twee specifieke dingen in onze decoder. Een match van twee tot tweeëndertig bytes betaalde vroeger voor een volledige aanroep van de geheugenkopieerroutine van het platform, en de aanroep kostte meer dan het kopiëren; tweeëndertig vaste bytes in plaats daarvan door een register kopiëren is waarom repetitive, solid en het woordenboek van 128 MiB - de drie vormen opgebouwd uit korte matches - allemaal ineens snel zijn. En de checksum draait stroomafwaarts van de schrijverthread in plaats van erop. De ene cel die we niet overtuigend winnen is de opgeslagen vorm op de 32-core desktop, waar unrar en wij drie milliseconden uit elkaar liggen op een etappe die puur bytes verplaatst - identiek op de precisie van deze tabel, dus beide cellen zijn gemarkeerd en het wordt gescoord als gelijkspel, geen verlies en geen winst.

De vorm waarop we met het meest winnen is degene die usenet werkelijk honderden tegelijk plaatst: 400 kleine bestanden, 4,3× en 4,4× tegen unrar en 5,4× tot 5,5× tegen rarpar. Dat is parallelisme per lid, en het is het verschil tussen een extractor geschreven voor een downloadwachtrij en een geschreven voor een opdrachtregel. De opgeslagen vorm, die volgens de telling hierboven 84% van de bytes over de lijn is, is voor de drie serieuze gereedschappen bijna gelijkspel, omdat op dat punt iedereen alleen maar bytes verplaatst.

Eén keuze die genoemd moet worden. De archieven zijn ingepakt met de compressor vastgezet op vier draden. RAR's blokindeling volgt anders het aantal kernen van de machine die het archief inpakte, zodat een machine met 32 kernen en een met 20 kernen uit dezelfde invoer verschillende bytes maken en de machines niet meer vergelijkbaar zijn. Vastzetten maakt het extractiecorpus overal byte voor byte gelijk, wat het doel is, maar het beperkt ook hoeveel van het decoderen parallel kan lopen - daarom hebben we de twee nauwste vormen, toen ze nog verliezen waren, opnieuw geracet tegen archieven ingepakt met alle 32 draden, om te controleren of het vastzetten niet de oorzaak was. Dat was het niet: solid ging van 4,2% achterstand naar 2,4% en het woordenboek van 128 MiB van 6,6% naar 6,3%, dezelfde volgorde in beide gevallen. Beide zijn nu winst op het vastgezette corpus, met een ruimere marge dan die controle zou kunnen verklaren.

Waarom er geen RAR4-rij is, en wat er met die posts gebeurt. Elke vorm hierboven is RAR5 of RAR7, wat is wat usenet tegenwoordig plaatst. Oudere RAR4-archieven duiken nog steeds op, en dezelfde engine leest ze, inclusief de gecomprimeerde en met wachtwoord beveiligde vormen, in dezelfde enkele doorgang als de nieuwere, in plaats van de volumes eerst naar schijf te schrijven en ze daarna uit te pakken. Ze krijgen hier geen rij omdat de officiële rar 7.23 geen RAR4 meer kan maken, dus er is geen neutraal corpus om het veld op te racen; dat werk wordt in plaats daarvan getoetst aan archieven geschreven door WinRAR 3.00, byte voor byte tegen unrar.

PAR2-verificatie en -herstel: set van 1 GiB, vier schadeniveaus

Corpus: 1 GiB willekeurige payload ingepakt in store-modus in 21 RAR-volumes, dan twee PAR2-sets bij 10% redundantie, één met blokken van 1 MiB en één met 64 KiB, dan vaste schadekaarten. Elke run gebruikt hetzelfde protocol: verse kopie, het hele corpus één keer lezen om de cache op te warmen, dan de tijd opnemen. Beste van drie afgewisselde rondes; elk hersteld volume wordt op elke ronde vergeleken met de ongeschonden set. Lager is beter.

Een correctie over het corpus, omdat een eerdere versie van deze pagina te veel beweerde. We zeiden dat elke machine een byte-identiek corpus draaide, gecontroleerd met een hash. De hash van elk volume van elke set berekenen laat zien dat dat klopt voor de 32-core desktop en de Windows-laptop, die exact overeenkomen, en niet voor de 20-core desktop, die een andere willekeurige trekking van dezelfde vorm bevat: dezelfde 21 volumes met dezelfde groottes, dezelfde twee blokgroottes, en schade geverifieerd op dezelfde 3, 101 en 1.500 blokken verdeeld over hetzelfde aantal bestanden. Elk cijfer binnen een rij is nog steeds gemeten op bytes die elk gereedschap in die rij deelt, wat is waar elke vergelijking op rust. Maar de rijen zijn geen vier blikken op één invoer, en omdat het karakter van de payload ongeveer 7% waard is voor het scannen van één concurrent, is dat het zeggen waard in plaats van het glad te strijken.

Welke par2 welke is. De originele par2cmdline is de referentie-implementatie waar iedereen van is afgeleid. par2cmdline-turbo is de fork die de hand-geschreven SIMD-Galoisveldkernels van ParPar meebrengt: dat is precies wat "turbo" betekent, en dat is waarom turbo, in plaats van het origineel, het gereedschap is dat de moeite waard is om tegen te meten. Beide turbo-kolommen hieronder draaien diezelfde ParPar-kernels. Wat ze scheidt is niet de rekenkunde maar de build en de vlaggen.

Bevestigd op de uitgeleverde build tegen de actuele concurrent, 24 augustus 2026. Deze tabellen werden gemeten voordat 1.2.2 werd gesneden en voordat par2cmdline-turbo 1.5.0 uitbracht (20 augustus 2026), dus de kolom met 20 cores werd opnieuw geracet op beide: onze releasebuild 1.2.2 tegen turbo 1.5.0, drie afgewisselde rondes per etappe, elk hersteld bestand vergeleken met de ongeschonden set. Alle vier etappes reproduceren - de onze 0,18 / 0,30 / 0,75 / 2,02 tegen de 0,19 / 0,33 / 0,74 / 2,07 hier afgedrukt, en turbo 1.5.0 landt binnen een paar procent van de build in de tabel op elke etappe en beide configuraties. De cellen blijven staan zoals gepubliceerd; de andere drie machines behouden hun eigen data's.

De concurrentie verschijnt dus tweemaal, en één van die kolommen is zijn beste geval eerder dan zijn standaard. De releasebinary die u zou downloaden is gecompileerd voor een generieke basis-cpu en hasht maar een paar bestanden tegelijk; dezelfde bron voor de werkelijke host-cpu bouwen en -T16 meegeven laat het de instructies gebruiken die die machine echt heeft en zestien bestanden tegelijk hashen. Op de laptop is dat tot 2,6x waard, volledig uit build en vlaggen. Beoordeel ons op de afgestelde kolom, wat de moeilijkere vergelijking is; de kolom zoals uitgeleverd is wat iemand die het downloadt werkelijk ervaart. par2cmdline is het origineel, versie 1.2.0, uit bron gebouwd op elke machine. rarpar is Weaver's eigen PAR2-implementatie, uit bron gebouwd met zijn Metal-GPU-backend ingeschakeld. De par2j van MultiPar is alleen Windows, dus die verschijnt alleen op de rijen van de Windows-laptop. De M5 Max-rijen racen de twee gereedschappen met actuele macOS-arm64-builds naast de twee turbo-kolommen; par2cmdline klassiek werd op die machine niet geracet.

Alle zestien nzbfast-cellen - vier machines bij vier schadeniveaus - zijn van ons, meerdere met meer dan 2× tegen de afgestelde build en met 2,3× tot 7,7× tegen degene die u werkelijk zou downloaden. De cellen bij zware schade zijn de interessante, en de notitie hieronder legt het algoritme erachter uit.

Het origineel staat weer in de tabel, en het is de moeite waard te zien waarom de fork bestaat. Een eerdere versie van deze pagina liet de kolom par2cmdline weg op grond dat hij trager was dan al het andere in de ronde, wat waar is en geen goede genoeg reden: het is de implementatie waar bijna elk ander gereedschap van is afgeleid, en lezers verdienen de baseline in plaats van onze bewering erover. Op het zwaarste schadeniveau kost het ongeveer 69 s waar de SIMD-fork 3,2 s neemt en wij 3,1 s nemen. Die factor twintig is het hele argument voor de hand-geschreven Galoisveldkernels, en het is hetzelfde argument dat we maken voor de onze.

Lichte schade is het geval dat ertoe doet. Een handjevol mislukte artikelen is veel typischer dan 101 dode blokken, en niets zoals 1.500. Het meeste van een licht herstel is helemaal geen Reed-Solomon-wiskunde, het is het lezen en MD5'en van een gigabyte, en daarom volgt de rij met 3 blokken de rij met de schone verificatie eerder dan de herstelrijen.

Het zwaarste schadeniveau is een ander soort werk, en het krijgt een ander algoritme. Dat laatste niveau beschadigt 1.500 blokken over alle 21 volumes en verbruikt ongeveer 91% van de herstelgegevens, waar de Reed-Solomon-rekenkunde, eerder dan hashen of schijf, bijna al het werk wordt. De uitgeleverde build berekent de zwaarste herstellingen nu met een getaltheoretische transformatie in plaats van de klassieke Galoisveldvouwing - dezelfde wiskunde, geëvalueerd in een vorm die veel beter schaalt bij hoge blokaantallen: 2,7× voor op de afgestelde build op de 20-core desktop, en op de Windows-laptop 2,7× voor op de afgestelde build en 2,2× voor op MultiPar. Lichte schade loopt nog steeds via het klassieke pad, wat is waarom de andere niveaus nauwelijks bewogen: de transformatie loont pas boven ongeveer 512 beschadigde blokken, dus daaronder gebruikt de verdeler hem niet.

Een sneller pad is het alleen waard te hebben als het nooit fout kan zijn. Beide paden berekenen dezelfde grootheid en zijn per constructie bit-identiek, en elk herstel op deze pagina werd getoetst aan de herbouwde bestanden die overeenkwamen met de ongeschonden set: 228 getimede herstellingen over de machines in deze ronde, nul mismatches. De uitgeleverde build vertrouwt niet op dat trackrecord. Elk herstel verifieert zijn eigen uitvoer tegen de bestandshashes, en één dat zou falen zou automatisch worden overgedaan met het klassieke pad, de afwijking loggen, en het klassieke pad aanhouden voor de rest van die run. De instelling staat in het dashboard als Fast PAR mode voor wie het liever helemaal niet heeft, en machines met te weinig geheugen ervoor wijzen het uit zichzelf af in plaats van te proberen en te falen. Opnieuw gemeten op 2 augustus op de actuele build: de twee desktops landen binnen een paar procent van deze tabel, en met Fast PAR mode uitgeschakeld valt de 20-core desktop terug op precies de tragere tijd van het klassieke pad, wat zegt dat de winst de methode is en niet de omstandigheden.

De kolom van de Windows-laptop had een correctie nodig, en die gaat tegen ons. Windows verplaatst aanhoudend achtergrondwerk na een paar seconden naar de efficiëntiekernen. Onze daemon meldt zich daar bij het opstarten voor af en geen van de andere gereedschappen kan dat, dus publiceerde een eerdere versie van deze pagina hun gedrosselde tijden alsof het hun eigen tijden waren. Diezelfde machine opnieuw draaien met elk gereedschap op hoge prioriteit verplaatst het hele veld: op het zwaarste schadeniveau gaat par2-turbo van 22,4 s naar 6,41 en rarpar van 59,2 s naar 14,4, en voor één versie van deze pagina veranderde dat de kolom van winst voor ons naar een verlies. De hele laptopkolom wordt nu zo gemeten - de correctie blijft staan ook al is de rij sindsdien teruggewonnen door de algoritmewijziging hierboven, omdat de tijden van het veld op die machine alleen eerlijk zijn met de drossel opgeheven.

RAR-herstelrecords: herstellen zonder PAR2

Wanneer PAR2 de schade niet kan dekken, is het herstelrecord in het RAR-bestand zelf de laatste verdedigingslinie. Tot 1.0.8 faalde het onze op elk archief boven ongeveer 13 MB, dus deze etappe kon helemaal niet gereden worden. Schade is drie gaten van 3.000 byte op 20%, 50% en 80% door het beschermde gebied heen. Beide gereedschappen produceerden uitvoer die byte-identiek was aan het ongeschonden bestand, en de onze is byte-identiek aan wat rar r zelf schrijft. Beste van drie, 32-core desktop, beide gereedschappen samen opnieuw geracet op 2 augustus.

Een eerdere versie van deze pagina toonde de omvang van 512 MB als een verlies, en verklaarde dat als de prijs van het stukje bij beetje doorwerken van het volume in plaats van alles in het geheugen te houden. Die verklaring klopte destijds en is nu achterhaald: de kosten waren een bit-seriële CRC64 in het herstelpad, vervangen door een tabelgestuurde, en het verlies verdween ermee. Er is geen kruispunt meer, en de begrensde werkset is behouden. De omvang van 2 GB staat erin omdat de volumes die een daemon werkelijk tegenkomt 8 GB tot 20 GB zijn, geen 512 MB, en een etappe die onder het echte bereik stopt is niet veel van een test.

Wat deze snede verplaatste, en de controle die dat zegt. Uitvinden welke blokken beschadigd zijn was de grootste fase van dit herstel geworden - groter dan de herstelrekenkunde zelf - en het liep op één draad, 64 KB lezend uit elke groep over het hele bestand, één keer per groep. Het maakt nu één opeenvolgende pas in bestandsvolgorde met de checksums per shard parallel berekend, en het herstelde volume wordt gekloond in plaats van gekopieerd waar het bestandssysteem dat kan. Detectie alleen viel van ongeveer 300 ms naar 18 ms op het archief van 512 MB, wat het grootste deel is van wat hierboven bewoog. De controle is de kolom naast de onze: rar r werd opnieuw geracet in dezelfde rondes op dezelfde machine en kwam terug binnen een paar procent van zijn vorige tijden, dus de verandering in het gat is van ons en niet van de testbank.

De M5 Max herhaalt het patroon, geracet op 31 juli met hetzelfde corpus en dezelfde toetsen: 0,050 / 0,066 / 0,171 / 0,581 s tegen de 0,211 / 0,335 / 0,751 / 1,735 van rar r over de omvangen van 16 MB tot 512 MB - 3,0× tot 5,1× sneller; de omvang van 2 GB werd op die machine niet geracet. Die cijfers dateren van vóór de detectieherschrijving hierboven beschreven, dus ze zijn van de oudere build, hier behouden als de tweede machine in plaats van als een actueel cijfer.

De rarpar van Weaver ontbreekt alleen in deze tabel, en niet uit keuze: het implementeert dit herstel niet. Gevraagd om zo'n archief te herstellen antwoordt het "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data", en laat het bestand beschadigd. Het verschijnt in elke andere vergelijking op deze pagina: alle vier de PAR2-etappes hierboven, alle zeven extractievormen daarboven, en de etappe met herstelvolumes direct hieronder, wat de taak is die het zegt te doen - en die het wint.

Herstelvolumes: ontbrekende .rev-bestanden opnieuw opbouwen

De andere helft van RAR's eigen herstelverhaal, en tot deze ronde het grootste verlies op deze pagina. Een .rev-bestand is een zelfstandig herstelvolume: drie ervan naast een set van 21 volumes kunnen elke drie volumes herbouwen die nooit zijn aangekomen. Corpus: 1 GiB opgeslagen in 21 volumes van 50 MB met rar rv3, waarna volumes 4, 11 en 19 verwijderd - drie verloren tegen drie herstelvolumes, het ergste geval dat de set nog kan overleven. Beste van drie, elk herbouwd volume vergeleken met het ongeschonden origineel.

De cel met 32 cores stond hier op 3,12 s tegen de 0,47 van rar rc in de vorige versie van deze pagina, gepubliceerd als 6,6× trager en het slechtste cijfer erop. De oorzaak was dat het uitwisoplossen op ongeveer 48 MB/s herbouwde uitvoer draaide waar RARLab's er 320 haalde; het draait nu op dezelfde tabelgestuurde rekenkunde als de rest van de herstelcode, wat een zevenvoudige verbetering is en het verlies op beide machines in winst verandert. De marges zijn 3% en 14%, dus het is winst om nuchter te vermelden in plaats van te verkopen als kop, en de reden dat het überhaupt wordt vermeld, is dat het verlies eerst is vermeld.

Deze etappe bestaat omdat Weaver's rarpar precies dit implementeert en vroeg om erop gemeten te worden. Het won comfortabel toen we het voor het eerst publiceerden, en we publiceerden het toen om die reden.

De bestandsmatching was nooit de kostenpost, wat de moeite waard is om vast te leggen omdat het de voor de hand liggende verdachte was: herstelvolumes dragen geen bestandsnamen, dus we identificeren welke slots overleefden door elk volume op schijf te checksummen in plaats van te vertrouwen op hoe ze heten, en tegen een onbeschadigde set, waar matching het enige is dat gebeurt, neemt de hele pas 0,18 s.

Wat er nog meer verschoof, en waar dat niet zichtbaar is. Nog twee engine-wijzigingen landden die deze corpora niet kunnen zien, hier genoemd zodat de cijfers hierboven niet als het hele verhaal worden gelezen: RAR5-archieven met tienduizenden leden lossen elk lid één keer op in plaats van de lijst per werker te doorlopen, wat 3× minder processortijd is bij 40.000 leden; en de RAR1.3-bitlezer werkt een woord tegelijk, wat 2× is. Geen van beide verschijnt hierboven, omdat de vormen hier 400 leden hebben en geen RAR1.3.

Wat we bewust niet doen: we maken nooit PAR2 aan. Een downloader heeft daar geen reden toe, en ParPar bezit die etappe. We kopen ook snelheid met geheugen op beide engines: extractie piekt rond 240 MB tegen de 41 MB van unrar, en verificatie rond 126 MB tegen de 7 MB van turbo, omdat dit de inline engines zijn die meerijden met een lopende download in plaats van zelfstandige eenmalige runs. De vorm met het woordenboek van 128 MiB is de ergste ervan, bij ongeveer 304 MB tegen de 139 MB van unrar. De zwaarste herstelling kost nu ook geheugen: de snellere methode voor 512-plus ontbrekende blokken werkt vanuit de herstelgegevens die resident worden gehouden, dus het mag tot een kwart van het geheugen van de machine gebruiken, begrensd op 4 GB, en een machine die dat niet kan missen neemt stilletjes de low-memory-methode - dezelfde rekenkunde en dezelfde tijden als de middelste rijen van de PAR2-tabel, alleen niet de 3× op de laatste. Wilt u de kleinst mogelijke residente set voor een standalone taak, dan winnen de speciale gereedschappen nog steeds die kolom.

Transportbewijs · gemeten op 1.2.2

De engine houdt gelijke tred met echte lijnen

• ~8,7 Gbps volgehouden door een vloot van vijf providers op een 10 GbE-lijn, inclusief in-stream verificatie en extractie - de ronde van 87 GB hierboven, 24 augustus 2026, v1.2.2, 360 verbindingen: 77,4 GB netwerk in 71 s met de payload geverifieerd en uitgepakt terwijl die binnenkwam. Geen burstcijfer: de hele taak op dat tempo.
• Bij 1 Gbit en eronder is de lijn de grens en zit nzbfast erop: ~96% van een 500 Mbit-lijn en ~96% van een 250 Mbit-lijn door verificatie en extractie heen, tegen een fractie van het geheugen en de schijf van elke concurrent - de sectie over sub-gigabit hierboven.
• De processorkosten van de hele taak op de taak van 87 GB zijn 1,7 CPU-seconden per GB met de verbindingsregelaar aan - download over TLS, verificatie, herstelgereedheid en extractie inbegrepen - tegen 3,0 tot 28 voor het veld in dezelfde ronde; de arm met volledige doorvoer hierboven besteedt 4,3.

Eerdere versies van deze pagina droegen een breder stel transportdemonstraties - saturatieruns over meerdere lijnen, winst per RTT op pipelining, een backpressure-bewijs, decodeplafondmetingen - geracet op builds die v1.2.2 sindsdien heeft vervangen. Onder de regel van deze pagina worden ze met pensioen gestuurd in plaats van te laten verouderen, en keren terug zodra ze opnieuw gesneden zijn op de actuele release; de drie beweringen hierboven zijn degene die al opnieuw gemeten zijn op v1.2.2.