Benchmark-uri

Varianta scurtă · măsurat pe 23 august 2026 pe linia de cod lansată ca nzbfast 1.2.2

Niciun client măsurat nu este mai ieftin la procesor, memorie și disc împreună

Cele mai noi runde de pe această pagină au rulat pe 23 și 24 august 2026 - cea mai nouă dintre ele chiar pe build-ul de lansare v1.2.2 - față de build-urile curente ale altor patru clienți, pe hardware, linii și provideri identice: două forme de job, de la 6,5 la 87 GB, și viteze de linie de la 250 Mbit la 10 GbE. În aceste runde, niciun client nu a fost mai ieftin decât nzbfast la procesor, memorie și disc împreună: fiecare costă mai mult la cel puțin două din cele trei, cel mai mult a economisit oricare dintre ei pe o singură axă a fost circa 2 procente - o egalitate statistică, în interiorul marjei proprii de variație de la o rulare la alta a acelui client - iar pe disc, fiecare dintre ei a mutat cel puțin de două ori mai mulți octeți pentru un rezultat identic octet cu octet. Din lansare, nzbfast a ținut și cea mai puțină memorie dintre toți clienții măsurați, pe fiecare probă, cu 2,0x până la 4,5x față de cel mai apropiat rival.

Care ești tu?

Majoritatea descărcătoarelor îți scriu descărcarea pe disc de cel puțin două ori: o dată în timp ce o descarcă, și încă o dată în timp ce o despachetează. nzbfast face tot jobul într-o singură trecere, deci scrie cam jumătate din octeți per job, ține mai puțin în memorie cât timp lucrează și cheltuiește mai puține secunde de procesor per GB. Asta înseamnă mai puțină încărcare pe mașină cât timp o folosești și jumătate din scrierile pe disc per job, pentru aceleași fișiere identice octet cu octet - și pentru că fiecare octet traversează discul cam o singură dată, discul tău trebuie să țină pasul cu linia ta o singură dată.

nzbfast nu câștigă fiecare tabel de pe această pagină, iar cele pe care le pierde sunt sub probele pe care nu le câștigăm - inclusiv una din chiar această rundă. Ce s-a păstrat în fiecare rundă măsurată este nota de plată combinată.

Mai întâi metodologia

Configurația

• Clienți: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, fiecare tabel pe build-urile pe care le numește. Cele mai noi runde (23 august 2026) au concurat cu build-urile atunci curente ale câmpului - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 și Weaver 0.7.8, cel mai nou binar lansat de el, identitate dovedită prin hash - față de linia de cod care a fost lansată chiar în acea noapte ca nzbfast 1.2.2, deci build-ul care a produs cifrele noi este cel pe care îl poți descărca. Acele runde au rulat pe o mașină Apple Silicon cu 20 de nuclee pe o linie de 1 Gbit. Tabelele mai vechi păstrează build-urile și mașinile cu care au concurat (mașini Apple din seria M: "Europa" M1 Ultra pe 10 GbE, "Coasta de Est" M3 Ultra cu o linie de ~2,4-3,0 Gbps) și o spun; ele subestimează build-ul curent din lansare mai degrabă decât să-l flateze.
• Corectitudine: aceiași provideri și TLS pentru fiecare client, probele rulează una după alta, intercalate. Fiecare concurent reglat la maximul lui documentat: SABnzbd a primit pipelining_requests=8 (livrează 1, adică nepipeline-uit, iar setarea valorează procente cu două cifre pe job-uri mari), NZBGet a primit ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb configurația lui documentată. Din 20 august 2026, fiecare rundă concurează cu cinci provideri în loc de șase - numărul de provideri nu este o pârghie de debit pe aceste mașini, unde un singur provider poate atinge singur plafonul liniei, iar un set fix ține rundele comparabile - deci o cifră cu șase provideri de pe această pagină nu e direct comparabilă cu una mai nouă, cu cinci provideri, și fiecare tabel spune cu care a rulat.
• Stare finală: un fișier verificat, extras, utilizabil, nu doar "descărcare terminată". Asta e ce aștepți de fapt.
• Reproductibilitate: fiecare afirmație e datată și măsurată la fel: timp scurs + contoare de octeți la interfață + RSS de vârf al arborelui de procese, rezoluție de 1-2 s. Acolo unde o probă rulează pe un NZB postat public, îl numim ca să poți rula tu însuți proba.
• Note de metodă valabile pe toată pagina: timpul de procesor e eșantionat din arborele de procese la 2 Hz pe fiecare braț al unui tabel și nu e pus niciodată alături de o cifră dintr-o altă contabilizare, pentru că cele două metode diferă prin construcție. I/O-ul dispozitivului e exprimat în GiB, iar octeții de pe linie în GB zecimal; convertim înainte de a împărți. Și orice tabel care ne pune propriul build să concureze cu propriul build poartă un control A/A - același binar concurând cu o copie identică octet cu octet a lui însuși prin același banc de testare - pentru că acest control e cum am prins propriul nostru banc de testare acordând o penalizare de ~1,5% oricărui instrument care rula primul (povestea e lângă tabelele de extragere de mai jos). Două brațe și ordini inversate nu anulează o distorsiune care cade mereu pe primul braț; un control A/A o expune.

Linii mai lente · măsurat 24 august 2026 pe nzbfast 1.2.2

Cu cât linia e mai lentă, cu atât viteza desparte mai puțin clienții - și cu atât mai mult o face nota de plată

Pe o linie destul de lentă, timpul de terminare al fiecărui client e linia și nimic altceva, deci o linie lentă ascunde multe păcate. Ce nu poate ascunde e ce arde fiecare client ca s-o umple. Am modelat rig-ul de 1 Gbit la două viteze pe care planurile reale chiar le au și am concurat toate cele șase brațe la fiecare - aceeași mașină, aceiași cinci provideri, trei repetiții per client cu ordinea rotită, fiecare probă verificată octet cu octet, 36 din 36 corecte pe cele două runde. Brațul nzbfast la 500 Mbit e chiar build-ul de lansare v1.2.2.

Citește cele două tabele ca pe un gradient. La 250 Mbit tot câmpul se încadrează în 18% pe cronometru și conducem în fața celui mai apropiat rival cu 4,4%; la 500 Mbit diferența se deschide la 14,7%; la vitezele de gigabit și 10 GbE din tabelele de mai sus și de mai jos se deschide și mai mult. Diferențele de viteză cresc odată cu linia. Coloanele de resurse nu așteaptă o linie rapidă: la fiecare viteză măsurată, fiecare rival a ținut cel puțin 3,9x memoria, a cheltuit mai mult procesor și a mutat cam dublul octeților de disc pentru același fișier identic octet cu octet.

Regulatorul de conexiuni își câștigă traiul pe linii lente, și contorul propriu de pierderi al modelatorului spune de ce. Setările implicite din lansare au ținut 25 de conexiuni acolo unde fiecare rival a rulat cu sutele; același binar cu regulatorul oprit a rulat cu 360. Mai puține fluxuri printr-o coadă fixă înseamnă mai puține pierderi și mai puține retrimiteri: modelatorul a înregistrat circa 4.200 de pierderi per probă plafonată față de circa 155.000 neplafonat la 500 Mbit, iar brațul plafonat a fost mai rapid, cu 4,2x mai ușor la memorie și 1,3x mai ușor la procesor decât propria noastră postură cu 360 de socket-uri. Mai multe conexiuni nu înseamnă mai multă viteză; sub un gigabit e măsurabil opusul.

Măsurat 24 august 2026, mediane a trei rulări, pe o mașină Apple Silicon cu 20 de nuclee, cu linia ei modelată la fiecare viteză (viteza modelată verificată printr-o sondă independentă înainte de fiecare rundă: 248 și 496 Mbit). Brațul nzbfast de 500 Mbit e chiar build-ul de la eticheta de lansare v1.2.2; runda de 250 Mbit a rulat cu ore mai devreme pe aceeași linie de cod. Numărul de octeți pe o linie modelată e citit din contorul propriu al fiecărui client, niciodată din interfața de rețea (modelatorul pierde pachete și TCP le retrimite, deci interfața numără ambele copii). Cronometrele sunt comparabile în interiorul fiecărui tabel, nu între runde modelate diferit. ¹ Cele trei probe ale lui NZBGet la 500 Mbit s-au întins între 114-158 s cu citiri de resurse plate - o variație reală, deci mediana e citată, iar variația e declarată în loc să fie restrânsă.

Postarea deteriorată · re-concurat 24 august 2026, fiecare build curent

Când postarea are găuri: 6,5 GB cu 60, 20 și 5 articole moarte

Articolele expiră, serverele le pierd în tăcere, încărcările aterizează incomplete - iar deteriorarea e locul unde prăpastia dintre clienți e cea mai largă, deci primește propria rundă pe cel mai nou build al fiecărui client, inclusiv nzbfast v1.2.2: mașină Europa de 10 GbE, cinci provideri, 100 de conexiuni per client, aceeași lansare de 6,5 GB otrăvită la trei niveluri de deteriorare, trei repetiții per braț cu ordinea alternată, fiecare probă verificată octet cu octet față de fișierul curat. 63 din 65 probe s-au întors identice octet cu octet; cele două care nu au fost sunt numite mai jos, pentru că sunt rezultate.

De ce postarea deteriorată e rapidă aici. Când un articol lipsește, un client întreabă în mod normal următorul server, apoi următorul, până când fiecare server l-a refuzat - o plimbare secvențială ale cărei refuzuri iau de la zeci de milisecunde la câteva secunde fiecare, timp în care descărcarea stă la zero. nzbfast se oprește din întrebat: odată ce datele de paritate deja în mână acoperă ce încă lipsește, repară imediat în loc să termine plimbarea. Ăsta e al doilea rând - același binar cu acest comportament oprit e de 1,4x până la 2,3x mai lent în funcție de deteriorare - iar runda a verificat că mecanismul s-a angajat la fiecare probă activată și niciodată la una dezactivată. Față de cel mai apropiat rival marja e de 2,4x până la 2,7x, fără nicio suprapunere în oricare din cele nouă perechi de repetiții.

Discul e locul unde marja e cea mai largă, și nu e trucul de reparare. Fiecare braț care termină a produs același fișier de 6,48 GB; al nostru a mutat 6,2-6,8 GB de I/O de disc făcând asta, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB și rustnzb 12,8-13,1 GB. Asta e pipeline-ul cu o singură trecere - rândul oprit mută aceleași 6,2 GB - deci se păstrează atât pe postările deteriorate cât și pe cele nedeteriorate.

¹ Cele trei probe ale SABnzbd la cea mai grea deteriorare au rulat 43, 41 și 60 s - o variație reală pe intrări identice, deci media e citată cu intervalul declarat. ² rustnzb 1.4.5 a livrat fiecare probă corectă octet cu octet, iar costul lui stă în timpul de procesor mai degrabă decât în fiabilitate: circa 1.620 de secunde de procesor față de un cronometru de 107 s la cea mai grea deteriorare - aproximativ cincisprezece nuclee ocupate pe toată proba - acolo unde același rezultat reparat ne costă circa 50 de secunde de procesor. ³ Weaver a mutat 1,5 GB și 4,9 GB din cele 6,5 în limita noastră de 20 de minute la cele două niveluri mai grele de deteriorare - aceeași neterminare în toate cele trei runde care l-au concurat, în trei nopți separate; limita e a noastră și neterminarea e rezultatul. La 5 articole moarte a terminat corect de toate trei ori. Costul lui de procesor acolo e propria lui poveste: circa 2.325 de secunde de procesor pentru proba de 194 s, față de cele 20 ale noastre.

Măsurat 24 august 2026, fiecare build curent: nzbfast v1.2.2 (chiar eticheta de lansare), NZBGet 26.3-testing (build din 20 august), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. Un braț de continuitate a concurat build-ul nzbfast din noaptea precedentă în interiorul aceleiași runde și a aterizat în interiorul unei secunde de v1.2.2 pe fiecare probă, deci nimic de aici nu se bazează pe o noapte norocoasă; iar configurațiile rivalilor diferă de cele ale rundei precedente doar prin calea de aplicare, verificate cheie cu cheie înainte ca runda să ruleze.

Înfometat de RAM · măsurat 24 august 2026 pe nzbfast 1.2.2

Scara memoriei reduse: 87 GB în ~0,3 GB de RAM

Același job de 87 GB ca runda de mai sus, rerulat la bugete fixe de memorie de 2 GB, 1 GB și 256 MB - ce ar alege auto-dimensionatorul pe o mașină de 8 GB, una de 4 GB, și un NAS de 2 GB. Fiecare probă a produs fișierul identic verificat octet cu octet, iar coloana de memorie a urmărit bugetul, niciodată jobul:

O singură probă per buget pe build-ul de lansare, plafonată față de aceeași sumă de control ca runda cu șase brațe. Cel mai strâns buget costă circa 9% din cronometru, și doar pentru că această linie e 10 GbE - blocurile revărsate costă timp doar când linia depășește discul, deci pe o conexiune obișnuită de acasă un buget mic e aproape gratuit. Toată scara, inclusiv o descărcare de 87 GB, încape în 0,3-0,6 GB de memorie; la setările implicite din lansare, jobul a rulat în 286 MB. Niciun alt client nu oferă un buget fix de memorie la nivel de proces; cele mai apropiate lucruri sunt niște setări de dimensiune a cache-ului, iar runda de mai jos măsoară ce costă acelea.

Plafonul concurat față de propriile butoane ale câmpului. Pe proba de 34 GB (23 august 2026, mașina de 1 Gbit, cinci provideri, 30 din 30 probe corecte octet cu octet), a ține NZBGet la un plafon echivalent de cache i-a mai mult decât dublat procesorul (215,5 la 453,0 secunde de procesor, 2,10x) ca să cumpere o reducere de 52% în memoria lui de vârf, iar plafonul lui SABnzbd a fost aproape gratuit dar a atins doar o parte din amprenta lui. Setarea de cache a lui rustnzb era decorativă în build-ul concurat, iar Weaver nu are niciun buton de memorie deloc, deci amândoi au rulat neplafonați ca și coloane de referință în loc să fie notați la un buget pe care nu-l pot ține. Propria noastră parte din acea rundă e depășită de scara v1.2.2 de mai sus, care spune același lucru la 2,5x dimensiunea: bugetul nu e niciodată constrângerea limitativă, pentru că o singură trecere ține atât de puțin de la bun început.

Spațiu liber · măsurat la megabyte

Cât de puțin spațiu liber are nevoie un job

Un client care scrie-apoi-despachetează are nevoie de loc pentru volumele arhivei și conținutul despachetat deodată, deci un job nu va porni fără aproape dublul descărcării libere. O singură trecere are nevoie de conținut - și această rundă a măsurat cât de puțin în plus, micșorând volumul țintă până când fiecare client a eșuat. Răspunsul lui nzbfast e o constantă de circa 50 MB de rezervă, nu un raport, și se păstrează de la un job de 6,5 GB la unul de 34 GB.

Măsurat pe o mașină Apple Silicon cu 20 de nuclee, linie de 1 Gbit, cinci provideri, trei repetiții la fiecare limită, fiecare probă terminată verificată octet cu octet - rândurile rivalilor pe 22-23 august 2026 (celula de 34 GB a lui Weaver reluată pe 24 august, nota 1), iar rândul nzbfast retăiat pe build-ul de lansare v1.2.2 pe 24 august, care a reprodus exact ambele limite, 12 din 12 probe unanime pe cele două probe. Celulele noastre sunt un plafon măsurat: jobul se termină 3 din 3 cu 48,6 MB și 51,0 MB de rezervă, și refuză 3 din 3 cu circa 17 MB sub asta - deci plafonul e real în ambele direcții. Ce ține jobul de fapt se stabilizează la conținutul plus circa 3 MB; rezerva plătește pentru ultimele momente ale pipeline-ului, niciodată pentru o a doua copie. Celulele rivalilor sunt plafonul lor măsurat pe jobul de 6,5 GB și o suficiență confirmată la același raport pe cel de 34 GB (3 din 3 corecte octet cu octet exact la acel raport); nu am mers cu scara lor mai jos la dimensiunea mai mare, deci plafonul lor adevărat acolo poate sta ceva mai jos de raport, și o spunem în loc să rotunjim în favoarea noastră.

Cum arată de fapt epuizarea contează la fel de mult ca cifra. La 17 MB sub plafonul lui, nzbfast lovește refuzul discului la o scriere, se oprește curat cu "spațiu de disc insuficient", păstrează jurnalizat tot ce a aterizat, iar o reîncercare reia fără a redescărca - un parțial pe care îl păstrezi, nu un job eșuat. ¹ Celula de probă mare a lui Weaver a fost rezolvată printr-o reluare pe 24 august: trei din trei probe corecte octet cu octet la același ~2,25x, fiecare mai rapidă decât proba bună de la prima încercare, cu spațiul liber identic până la octet. La prima încercare, pe 23 august, două din cele trei probe ale lui se blocaseră la viteze cu o cifră MB/s cu peste 60 GB încă libere și au lovit limita de 40 de minute a rundei. Acele blocaje nu au revenit, iar instrumentarea de blocaj a standului a fost activă și tăcută pe toate cele trei probe ale reluării, ceea ce e o măsurătoare pozitivă, nu una lipsă. Ce le-a provocat rămâne necunoscut, iar o reluare curată nu e un diagnostic: există acum șase probe la acest raport, patru terminate, iar ambele eșecuri vin dintr-o singură fereastră de 80 de minute din prima noapte.

Postări imbricate · măsurat la 28 august 2026

Zece feluri de a împacheta o postare și cine ajunge cu adevărat la fișier

Mare parte din ceea ce se publică este anume greu de deschis. Numele real al fișierului este îngropat într-o a doua arhivă, uneori a treia, uneori într-un format diferit la fiecare nivel, astfel încât postarea să dezvăluie cât mai puțin despre ce conține. La asta se adaugă faptul că postările sosesc deteriorate: articolele expiră, încărcările ajung incomplete, iar datele de recuperare trebuie folosite înainte de a putea extrage ceva. Un client fie parcurge acel lanț pentru dumneavoastră, fie vă întinde un dosar plin de arhive și se oprește.

Am construit deci zece forme care izolează exact acest lucru, am pus fiecare client actual să le înfrunte și apoi am făcut ceea ce comparațiile sar de obicei: acolo unde un client s-a oprit devreme, am terminat treaba manual cu uneltele obișnuite și am cronometrat și asta. Un client care renunță repede pare rapid până când numeri munca pe care ți-o lasă.

nzbfast este singurul care le termină pe toate zece fără ajutor. Și NZBGet ajunge la fișier la fiecare formă, dar are nevoie de 16 runde de reparare și extragere manuală la opt dintre ele. SABnzbd termină cinci de unul singur, iar două rămân inaccesibile chiar și manual. Weaver ajunge la fișier la două.

Tiparul nu este întâmplător. Formele pe care nzbfast le parcurge, iar ceilalți nu, sunt cele împachetate și cele deteriorate: o arhivă într-o arhivă, o schimbare de format la jumătatea lanțului, un lanț cu cinci niveluri și, mai ales, o arhivă care sosește coruptă cu propriile date de recuperare alături. La aceasta din urmă, patru clienți extrag setul exterior impecabil, vă întind arhiva defectă împreună cu setul de recuperare care ar repara-o, și se opresc.

Acolo unde clienții duc la capăt aceeași muncă, diferența nu este mică. Acestea sunt cele șapte forme la care ajung toți cei patru clienți răspândiți, incluzând repararea manuală de care a avut nevoie fiecare:

De patru până la cinci ori mai rapid, cu sub jumătate din octeții scriși. Cifra discului este cea care contează și după descărcare: fiecare gigabait din acea coloană este un gigabait pe care discul dumneavoastră a trebuit să îl absoarbă, iar clienții care folosesc o zonă intermediară scriu conținutul, îl citesc înapoi și îl scriu din nou.

Unde nu suntem în față și de ce merită spus. La patru din cele zece forme, un concurent scrie mai puțini octeți decât nzbfast chiar în timpul descărcării. De fiecare dată pentru că a făcut mai puțin: la forma cu arhivă interioară coruptă, NZBGet scrie 3,29 GB față de cei 4,65 ai noștri, apoi trecerea sa de reparare mai scrie 2,91, încheind la 6,20 GB față de cei 4,65 ai noștri. La celelalte, clientul care a scris cel mai puțin este unul care nu a ajuns niciodată la fișier. O cifră mică pe disc nu înseamnă întotdeauna cumpătare.

Acestea sunt teste de capabilitate, nu teste de viteză. Conținuturile sunt mici și sunt servite din memorie printr-o conexiune locală, fără furnizor și fără rețea pe traseu, așa că nimic de aici nu este limitat de viteza de descărcare, iar secundele absolute sunt mult mai scurte decât ar dura aceleași forme în lumea reală. Dacă o formă cere sau nu muncă manuală ține de formă și de client și se transferă direct. Secundele compară clienți care fac o muncă identică; ele nu prezic cât durează o sarcină reală.

Rezultatele complete pe fiecare formă, ce este fiecare formă și metoda se află pe pagina de date despre arhivele imbricate.

De ce contează

Discul tău face jumătate din muncă

Stocarea flash se uzează prin faptul că i se scrie. O lansare de 94 GB costă discul tău circa 90 GB de scriere sub nzbfast; sub un client care face staging și despachetează, aceeași lansare costă aproape dublu. Pe un NAS cu discuri dure, forma cu o singură trecere elimină și trecerea lungă, single-threaded de la sfârșitul fiecărei descărcări criptate - o pauză măsurată la 20 de secunde pe o stație de lucru rapidă cu 32 de nuclee și deblocare accelerată hardware, și corespunzător mai lungă pe mașinile cu putere redusă pe care le rulează de fapt majoritatea oamenilor. Citam cifra mică pentru că e cea pe care am măsurat-o.

Concursuri de componente

Benchmark-urile mai tehnice, pentru cei cărora le plac mai multe date

Reparația (PAR2) și despachetarea (RAR) sunt cod nostru nativ mai degrabă decât binare terțe integrate, deci le concurăm și separat față de instrumentele dedicate pe corpusuri identice, pe patru mașini care acoperă ce ar putea deține de fapt un cititor. Un timp contează doar când rezultatul e identic octet cu octet cu conținutul sursă: fiecare cifră RAR de mai jos a fost verificată sha256 față de sursă, și fiecare fișier reparat față de setul intact.

Extragere RAR: 7 forme de arhivă, 6 instrumente

Runda anterioară a acestui tabel a folosit 100 MB până la 200 MB per formă, ceea ce a fost o greșeală: circa 28 ms de lansare de proces erau 40% din proba stocată, iar ordinea pe care a produs-o nu supraviețuiește la o dimensiune realistă. Această rundă e 1 GB de conținut per formă, și schimbă mai multe răspunsuri, inclusiv câteva în direcția cealaltă. Arhivele sunt create de rar 7.23 oficial, deci niciun instrument nu e judecat pe conținut de la propriul lui encoder, iar aceiași octeți sunt concurați pe fiecare mașină.

Ce e în conținut contează mai mult decât pare. Un conținut construit din copii de blocuri face din fiecare formă comprimată un benchmark de copiere de memorie; un conținut de text pur îl face un benchmark de literale și Huffman; le-am măsurat pe amândouă și nu sunt de acord asupra cine câștigă. Deci cele patru forme comprimate folosesc treimi egale de text, înregistrări structurate și octeți incompresibili, iar cele două forme de la capetele acelui interval sunt probe separate intenționat: store e incompresibil și repetitive e aproape numai potriviri. Constructorul și bancul de testare sunt în depozit, deci corpusul poate fi reconstruit octet cu octet.

Re-concurat 23 august 2026 pe motorul 1.2.2, iar baleierea rezistă. Cele trei instrumente pe care un cititor le cântărește cel mai des - al nostru, unrar 7.23 și rarpar 0.2.5 - au fost re-concurate pe desktopul cu 32 de nuclee pe motorul de lansare (codul de extragere concurat e identic octet cu octet cu eticheta 1.2.2), șase runde intercalate, minimul per instrument, rezultatul fiecărei probe verificat față de manifestul conținutului. Secunde, mai puțin e mai bine:

Toate cele șapte forme sunt ale noastre, pe minim și pe mediană, de 1,16x până la 4,29x față de unrar. Acești timpi nu sunt comparabili celulă cu celulă cu tabelul mai larg de mai jos - bancul de testare a fost revizuit de la rundele acelui tabel, iar numărul de runde diferă - deci citește fiecare tabel față de el însuși. Tabelul mai larg își păstrează propriile date și câmpul lui de șase instrumente, iar coloana lui nzbfast descrie motorul pe care îl livrează 1.2.2: re-cursa de mai sus a măsurat motorul curent la nivelul build-ului acelui tabel pe toate cele șapte forme, decisă prin numărul de instrucțiuni hardware (0,14% mai puține pentru același cronometru), deci acele celule nu poartă cifrele unui build depășit sub o etichetă curentă. Această re-cursă e și locul unde regula A/A din secțiunea de configurație a fost câștigată. O trecere din aceeași zi a raportat mai întâi o formă ca o mică regresie față de propriul nostru build anterior, iar citirea a supraviețuit rulării ambelor ordini de brațe. Un control A/A - același binar concurând cu o copie identică octet cu octet a lui însuși - a arătat bancul de testare acordând oricărui braț care rula primul o penalizare de circa 1,5%: binarul identic a câștigat doar 6 din 15 runde din primul slot, iar inversarea ordinilor nu anulează o distorsiune care cade mereu pe oricine e primul. Numărul de instrucțiuni hardware a decis întrebarea pe care bancul de testare n-a putut - build-ul mai nou retrage 0,14% mai puține instrucțiuni pentru același cronometru, deci n-a existat nicio regresie. Fiecare comparație a propriului nostru build față de propriul nostru build pe care o publicăm acum poartă acel control.

Tot câmpul, secunde, mai puțin e mai bine. Cel mai bun din trei, instrumente intercalate în interiorul fiecărei runde mai degrabă decât rulate în blocuri, rezultatul verificat față de conținutul sursă la fiecare rulare în parte. Un instrument care a produs octeți greșiți primește o notă de corectitudine, niciodată un timp rapid. rarpar e propriul cod RAR și PAR2 al lui Weaver, construit din sursă la bd87611; fixăm commit-ul mai degrabă decât o versiune pentru că modulele lui poartă trei numere de versiune diferite.

Unde câmpul n-a putut concura, și de ce. ¹ 7-Zip concurat aici e pachetul Homebrew, care refuză fiecare formă comprimată cu ERROR: Unsupported Method și citește pe macOS doar forma stocată. O versiune anterioară a acestei pagini punea asta pe seama build-ului macOS al lui 7-Zip, ceea ce a fost greșit: Homebrew îl construiește fără codec-ul unRAR neliber, în timp ce build-ul macOS pe care îl livrează 7-zip.org poartă codec-ul și decodează toate cele șapte forme, la fel ca build-ul Windows. Remăsurat 14 august 2026. Dacă instalezi 7-Zip de la proiect mai degrabă decât de la Homebrew, această coloană nu descrie ce ai tu. ² bsdtar nu are suport pentru RAR5 multi-volum și a produs un fișier trunchiat fără să raporteze nicio eroare, deci acea probă e un eșec de corectitudine mai degrabă decât un timp lent; bancul nostru de testare l-a prins pentru că verifică rezultatul, motiv pentru care merită verificat rezultatul. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar nu livrează niciun instrument de linie de comandă pentru Windows, deci câmpul laptopului numără cinci. ⁶ Grupul M5 Max concurează cele trei instrumente spre care s-ar întoarce de fapt un cititor de macOS - unrar, rarpar și noi; unar, bsdtar și 7-Zip n-au fost concurate pe acea mașină. unrar-ul lui e 7.22, cel mai nou build care rulează nesupravegheat acolo.

Fiecare formă pe fiecare mașină în afară de una, iar aceea e egalitate. Formele cu potriviri scurte se reduc la două lucruri specifice din decodorul nostru. O potrivire de la două la treizeci și două de octeți obișnuia să plătească pentru un apel complet în rutina de copiere de memorie a platformei, iar apelul costa mai mult decât copierea; a copia treizeci și doi de octeți ficși printr-un registru în loc e motivul pentru care repetitive, solid și dicționarul de 128 MiB - cele trei forme construite din potriviri scurte - sunt toate rapide deodată. Iar suma de control rulează în aval de firul de scriere, nu pe el. Singura celulă pe care n-o câștigăm categoric e forma stocată pe desktopul cu 32 de nuclee, unde unrar și noi suntem la trei milisecunde distanță pe o probă care mută pur și simplu octeți - identice la precizia acestui tabel, deci ambele celule sunt marcate și e notată egalitate, nu pierdere și nu victorie.

Forma pe care o câștigăm cel mai mult e cea pe care Usenet chiar o postează cu sutele deodată: 400 de fișiere mici, 4,3× și 4,4× față de unrar și 5,4× până la 5,5× față de rarpar. Asta e paralelism per membru, și e diferența dintre un extractor scris pentru o coadă de descărcare și unul scris pentru o linie de comandă. Forma stocată, care recensământul de mai sus spune că e 84% din octeții de pe linie, e o egalitate aproape perfectă pentru cele trei instrumente serioase, pentru că în acel punct toată lumea doar mută octeți.

O alegere care merită declarată. Arhivele sunt împachetate cu compresorul fixat la patru fire. Divizarea pe blocuri a RAR-ului urmează altfel numărul de nuclee al mașinii care a împachetat arhiva, deci un desktop cu 32 de nuclee și unul cu 20 de nuclee produc octeți diferiți din aceeași intrare, iar mașinile încetează să mai fie comparabile. A fixa asta face corpusul de extragere identic octet cu octet peste tot, ceea ce e scopul, dar plafonează și cât de mult din decodare poate rula în paralel - deci atunci când cele două forme cele mai apropiate au fost pierderi, le-am re-concurat față de arhive împachetate cu toate cele 32 de fire, ca să verificăm că fixarea n-a fost cauza. N-a fost: solid a trecut de la 4,2% în urmă la 2,4% în urmă, iar dicționarul de 128 MiB de la 6,6% la 6,3%, aceeași ordine în ambele cazuri. Amândouă sunt acum victorii pe corpusul fixat cu o marjă mai largă decât ar putea explica acea verificare.

De ce nu există un rând RAR4, și ce se întâmplă cu acele postări. Fiecare formă de mai sus e RAR5 sau RAR7, ceea ce postează Usenet astăzi. Arhivele RAR4 mai vechi încă apar, iar același motor le citește, inclusiv formele comprimate și protejate cu parolă, în aceeași singură trecere ca cele mai noi, în loc să scrie volumele pe disc și să le despacheteze ulterior. Nu primesc niciun rând aici pentru că rar 7.23 oficial nu mai poate crea RAR4, deci nu există un corpus neutru pe care să concurăm câmpul; acea muncă e verificată față de arhive scrise de WinRAR 3.00 în loc, octet cu octet față de unrar.

Verificare și reparare PAR2: set de 1 GiB, patru niveluri de deteriorare

Corpus: 1 GiB de conținut aleator împachetat în mod stocat în 21 de volume RAR, apoi două seturi PAR2 la 10% redundanță, unul la blocuri de 1 MiB și unul la 64 KiB, apoi hărți de deteriorare fixate. Fiecare rulare folosește același protocol: copie proaspătă, se citește întregul corpus o dată pentru a încălzi cache-ul, apoi se cronometrează. Cel mai bun din trei runde intercalate; fiecare volum reparat e comparat față de setul intact la fiecare rundă. Mai puțin e mai bine.

O corecție despre corpus, pentru că o versiune anterioară a acestei pagini a exagerat-o. Am spus că fiecare mașină rulează un corpus identic octet cu octet, verificat prin hash. Calcularea hash-ului fiecărui volum din fiecare set arată că asta e adevărat pentru desktopul cu 32 de nuclee și laptopul Windows, care se potrivesc exact, dar nu pentru desktopul cu 20 de nuclee, care ține un extras aleator diferit al aceleiași forme: aceleași 21 de volume la aceleași dimensiuni, aceleași două dimensiuni de bloc, iar deteriorarea verificată la aceleași 3, 101 și 1.500 de blocuri distribuite peste același număr de fișiere. Fiecare cifră dintr-un rând e încă măsurată pe octeți pe care fiecare instrument din acel rând îi împarte, pe asta se bazează fiecare comparație. Dar rândurile nu sunt patru vederi ale unei singure intrări, iar cum caracterul conținutului valorează circa 7% pentru scanarea unui concurent, merită declarat mai degrabă decât trecut cu vederea.

Care par2 e care. par2cmdline original e implementarea de referință din care s-au bifurcat toți. par2cmdline-turbo e bifurcația care vinde nucleele SIMD scrise de mână pentru câmp Galois ale lui ParPar: exact asta înseamnă "turbo", și de asta turbo, mai degrabă decât originalul, e instrumentul care merită măsurat. Ambele coloane turbo de mai jos rulează aceleași nuclee ParPar. Ce le separă nu e aritmetica, ci build-ul și flag-urile.

Confirmat pe build-ul de lansare față de rivalul curent, 24 august 2026. Aceste tabele au fost măsurate înainte ca 1.2.2 să fie tăiat și înainte ca par2cmdline-turbo să lanseze 1.5.0 (20 august 2026), deci coloana cu 20 de nuclee a fost re-concurată pe amândouă: build-ul nostru de lansare 1.2.2 față de turbo 1.5.0, trei runde intercalate per probă, fiecare fișier reparat comparat față de setul intact. Toate cele patru probe se reproduc - ale noastre 0,18 / 0,30 / 0,75 / 2,02 față de cele 0,19 / 0,33 / 0,74 / 2,07 tipărite aici, iar turbo 1.5.0 aterizează în câteva procente de build-ul din tabel la fiecare probă și la ambele configurații. Celulele rămân așa cum sunt publicate; celelalte trei mașini își păstrează propriile date.

Deci concurentul apare de două ori, iar una din acele coloane e cazul lui cel mai bun mai degrabă decât cel implicit. Binarul de lansare pe care l-ai descărca e compilat pentru un procesor generic de bază și calculează hash-ul doar la câteva fișiere deodată; a construi aceeași sursă pentru procesorul real al mașinii și a trece -T16 îi permite să folosească instrucțiunile pe care le are cu adevărat acea mașină și să calculeze hash-ul a șaisprezece fișiere deodată. Pe laptop asta valorează până la 2,6x, integral din build și flag-uri. Judecă-ne pe coloana reglată, care e comparația mai grea; coloana din lansare e ce trăiește cineva care o descarcă. par2cmdline e originalul, versiunea 1.2.0, construit din sursă pe fiecare mașină. rarpar e propria implementare PAR2 a lui Weaver, construită din sursă cu backend-ul lui Metal GPU activat. par2j al lui MultiPar e doar pentru Windows, deci apare doar pe rândurile laptopului Windows. Rândurile M5 Max concurează cele două instrumente cu build-uri macOS arm64 curente alături de cele două coloane turbo; par2cmdline clasic n-a fost concurat pe acea mașină.

Toate cele șaisprezece celule nzbfast - patru mașini la patru niveluri de deteriorare - sunt ale noastre, câteva cu mai mult de 2× față de build-ul reglat și de 2,3× până la 7,7× față de cel pe care l-ai descărca de fapt. Celulele cu deteriorare grea sunt cele interesante, iar nota de mai jos explică algoritmul din spatele lor.

Originalul e din nou în tabel, și merită văzut de ce există bifurcația. O versiune anterioară a acestei pagini a scos coloana par2cmdline pe motiv că era mai lent decât orice altceva din rundă, ceea ce e adevărat și nu e un motiv suficient de bun: e implementarea din care aproape orice alt instrument coboară, iar cititorii merită referința mai degrabă decât afirmația noastră despre ea. La cel mai greu nivel de deteriorare durează circa 69 s acolo unde bifurcația SIMD durează 3,2 s și noi durăm 3,1 s. Acel factor de douăzeci e întregul argument pentru nucleele Galois scrise de mână, și e același argument pe care îl facem pentru ale noastre.

Deteriorarea ușoară e cazul care contează. Câteva articole eșuate sunt mult mai tipice decât 101 blocuri moarte, și nimic ca 1.500. Cea mai mare parte a unei reparații ușoare nu e deloc matematica Reed-Solomon, e citirea și calcularea MD5 pentru un gigabyte, motiv pentru care rândul de 3 blocuri urmează rândul de verificare curată mai degrabă decât pe cele de reparare.

Cel mai greu nivel de deteriorare e un alt tip de muncă, și primește un alt algoritm. Acel ultim nivel deteriorează 1.500 de blocuri pe toate cele 21 de volume și consumă circa 91% din datele de recuperare, unde aritmetica Reed-Solomon, mai degrabă decât hash-ul sau discul, devine aproape toată munca. Build-ul de lansare calculează reparațiile cele mai grele cu o transformare numeric-teoretică în loc de plierea clasică pe câmp Galois - aceeași matematică, evaluată într-o formă care scalează mult mai bine la numere mari de blocuri: 2,7× în față build-ului reglat pe desktopul cu 20 de nuclee, iar pe laptopul Windows 2,7× în față build-ului reglat și 2,2× în față lui MultiPar. Deteriorarea ușoară încă rulează calea clasică, motiv pentru care celelalte niveluri abia s-au mișcat: transformarea plătește doar peste circa 512 de blocuri deteriorate, deci sub asta dispecerul n-o folosește.

O cale mai rapidă merită avută doar dacă nu poate fi greșită. Ambele căi calculează aceeași cantitate și sunt identice la nivel de bit prin construcție, iar fiecare reparație de pe această pagină a fost condiționată de potrivirea fișierelor reconstruite cu setul intact: 228 de reparații cronometrate pe mașinile din această rundă, zero nepotriviri. Build-ul de lansare nu se bazează pe acel istoric. Fiecare reparație își verifică propriul rezultat față de hash-urile fișierelor, iar una care ar eșua ar fi refăcută cu calea clasică automat, ar înregistra divergența, și ar păstra calea clasică pentru restul acelei rulări. Setarea e în tabloul de bord ca Mod PAR rapid dacă preferi să n-o ai deloc, iar mașinile cu prea puțină memorie pentru ea o refuză singure în loc să încerce și să eșueze. Remăsurat pe 2 august pe build-ul curent: cele două desktopuri aterizează în câteva procente de acest tabel, iar cu Modul PAR rapid oprit, desktopul cu 20 de nuclee revine la exact timpul mai lent al căii clasice, ceea ce spune că victoria e metoda și nu condițiile.

Coloana laptopului Windows a avut nevoie de o corecție, și e împotriva noastră. Windows retrogradează munca susținută de fundal pe nucleele de eficiență după câteva secunde. Daemonul nostru renunță la asta la pornire și niciun alt instrument nu poate, deci o versiune anterioară a acestei pagini a publicat timpii lor retrogradați ca și cum ar fi fost ai instrumentelor înseși. Rerularea acelei mașini cu fiecare instrument ridicat la prioritate înaltă mișcă tot câmpul: la cel mai greu nivel de deteriorare, par2-turbo trece de la 22,4 s la 6,41 și rarpar de la 59,2 s la 14,4, iar pentru o versiune a acestei pagini asta a transformat coloana din a noastră într-una pe care am pierdut-o. Toată coloana laptopului e măsurată acum așa - corecția rămâne chiar dacă rândul a fost recâștigat de schimbarea de algoritm de mai sus, pentru că timpii câmpului pe acea mașină sunt onești doar cu retrogradarea ridicată.

Înregistrări de recuperare RAR: reparare fără PAR2

Când PAR2 nu poate acoperi deteriorarea, înregistrarea de recuperare din interiorul RAR-ului însuși e ultima linie de apărare. Până la 1.0.8, al nostru eșua pe orice arhivă peste circa 13 MB, deci această probă nici nu putea fi rulată. Deteriorarea e trei găuri de 3.000 de octeți la 20%, 50% și 80% prin regiunea protejată. Ambele instrumente au produs un rezultat identic octet cu octet cu fișierul intact, iar al nostru e identic octet cu octet cu ce scrie rar r el însuși. Cel mai bun din trei, desktopul cu 32 de nuclee, ambele instrumente re-concurate împreună pe 2 august.

O versiune anterioară a acestei pagini arăta dimensiunea de 512 MB ca pe o pierdere, explicând-o ca prețul lucrului prin volum în bucăți în loc să țină tot în memorie. Explicația aceea era corectă la vremea respectivă și e acum depășită: costul era un CRC64 bit-serial în calea de reparare, înlocuit cu unul bazat pe tabel, iar pierderea a dispărut odată cu el. Nu mai există o intersecție, iar setul de lucru mărginit a fost păstrat. Dimensiunea de 2 GB e aici pentru că volumele pe care le întâlnește de fapt un daemon sunt de 8 GB până la 20 GB, nu 512 MB, iar o probă care se oprește sub intervalul real nu e prea mult un test.

Ce a mișcat această tăiere, și controlul care o spune. Găsirea blocurilor deteriorate devenise cea mai mare fază a acestei reparații - mai mare decât aritmetica reparării în sine - și rula pe un singur fir, citind 64 KB din fiecare grup din tot fișierul, o dată per grup. Acum face o singură trecere secvențială în ordinea fișierului, cu sumele de control per bucată calculate în paralel, iar volumul reparat e clonat mai degrabă decât copiat acolo unde sistemul de fișiere poate face asta. Detectarea singură a scăzut de la circa 300 ms la 18 ms pe arhiva de 512 MB, ceea ce e cea mai mare parte a ce s-a mișcat mai sus. Controlul e coloana de lângă a noastră: rar r a fost re-concurat în aceleași runde pe aceeași mașină și s-a întors în câteva procente de timpii lui anteriori, deci schimbarea din diferență e a noastră și nu a bancului de testare.

M5 Max repetă tiparul, concurat pe 31 iulie cu același corpus și aceleași porți: 0,050 / 0,066 / 0,171 / 0,581 s față de 0,211 / 0,335 / 0,751 / 1,735 ale lui rar r pe dimensiunile de la 16 MB la 512 MB - de 3,0× până la 5,1× mai rapid; dimensiunea de 2 GB n-a fost concurată pe acea mașină. Acele cifre precedă rescrierea de detectare descrisă mai sus, deci sunt ale build-ului mai vechi, păstrate aici ca a doua mașină mai degrabă decât ca o cifră curentă.

rarpar al lui Weaver lipsește doar din acest tabel, și nu prin alegere: nu implementează această reparare. Rugat să repare una din aceste arhive răspunde "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data", și lasă fișierul deteriorat. Apare în fiecare altă comparație de pe această pagină: toate cele patru probe PAR2 de mai sus, toate cele șapte forme de extragere de mai sus de asta, și proba de volume de recuperare imediat mai jos, care e chiar munca despre care spune că o face - și pe care o câștigă.

Volume de recuperare: reconstruirea fișierelor .rev lipsă în întregime

Cealaltă jumătate a poveștii proprii de recuperare a RAR-ului, și până la această rundă, cea mai mare pierdere de pe această pagină. Un fișier .rev e un volum de recuperare de sine stătător: trei dintre ele lângă un set de 21 de volume pot reconstrui oricare trei volume care n-au sosit niciodată. Corpus: 1 GiB stocat în 21 de volume de 50 MB cu rar rv3, apoi volumele 4, 11 și 19 șterse - trei pierdute față de trei volume de recuperare, care e cazul cel mai rău pe care setul îl mai poate supraviețui. Cel mai bun din trei, fiecare volum reconstruit comparat față de cel intact.

Celula de 32 de nuclee de aici era la 3,12 s față de cei 0,47 ai rar rc în ultima tăiere a acestei pagini, publicată ca 6,6× mai lentă și cea mai proastă cifră de pe ea. Cauza era rezolvarea de ștergere rulând la circa 48 MB/s de conținut reconstruit acolo unde cei de la RARLab gestionau 320; acum rulează pe aceeași aritmetică bazată pe tabel ca restul codului de recuperare, ceea ce e o îmbunătățire de șapte ori și transformă pierderea într-o victorie pe ambele mașini. Marjele sunt 3% și 14%, deci e o victorie de declarat simplu mai degrabă decât de titrat, iar motivul pentru care e declarată deloc e că pierderea a fost declarată prima.

Această probă există pentru că rarpar al lui Weaver implementează exact asta și a cerut să fie măsurat pe ea. Câștiga confortabil când am publicat-o prima dată, și am publicat-o atunci din acel motiv.

Potrivirea fișierelor n-a fost niciodată costul, ceea ce merită înregistrat pentru că era suspectul intuitiv: volumele de recuperare nu poartă nume de fișiere, deci identificăm ce sloturi au supraviețuit calculând suma de control a fiecărui volum de pe disc mai degrabă decât având încredere în cum sunt numite, iar față de un set nedeteriorat, unde tot ce se întâmplă e potrivirea, toată trecerea durează 0,18 s.

Ce s-a mai mișcat, și unde nu se vede. Încă două schimbări de motor au fost lansate pe care aceste corpusuri nu le pot vedea, listate aici ca cifrele de mai sus să nu fie citite ca întreaga poveste: arhivele RAR5 cu zeci de mii de membri rezolvă fiecare membru o singură dată în loc să parcurgă lista per lucrător, ceea ce e de 3× mai puțin timp de procesor la 40.000 de membri; iar cititorul de biți RAR1.3 lucrează câte un cuvânt deodată, ceea ce e de 2×. Niciuna nu apare mai sus, pentru că formele de aici au 400 de membri și niciun RAR1.3.

Ce nu facem intenționat: nu creăm niciodată PAR2. Un descărcător n-are niciun motiv s-o facă, iar ParPar deține acea probă. De asemenea cumpărăm viteză cu memorie pe ambele motoare: extragerea atinge un vârf de circa 240 MB față de cei 41 MB ai lui unrar, iar verificarea circa 126 MB față de cei 7 MB ai lui turbo, pentru că astea sunt motoarele inline care merg în paralel cu o descărcare vie mai degrabă decât rulări unice de sine stătătoare. Forma cu dicționar de 128 MiB e cea mai rea, la circa 304 MB față de cei 139 MB ai lui unrar. Cea mai grea reparație costă acum și memorie: metoda mai rapidă pentru 512 sau mai multe blocuri lipsă lucrează din datele de recuperare ținute rezident, deci i se permite până la un sfert din RAM-ul mașinii, plafonat la 4 GB, iar o mașină care nu poate ceda atât trece în tăcere la metoda cu memorie redusă în loc - aceeași aritmetică și aceiași timpi ca rândurile din mijloc ale tabelului PAR2, doar nu cei 3× de pe ultimul. Dacă vrei cel mai mic set rezident posibil pentru un job de sine stătător, instrumentele dedicate încă câștigă acea coloană.

Dovada de transport · măsurat pe 1.2.2

Motorul ține pasul cu linii reale

• ~8,7 Gbps susținut printr-o flotă de cinci provideri pe o linie de 10 GbE, inclusiv verificare și extragere în flux - runda de 87 GB de mai sus, 24 august 2026, v1.2.2, 360 de conexiuni: 77,4 GB de rețea în 71 s cu conținutul verificat și extras pe măsură ce sosea. Nu o cifră de rafală: tot jobul la acea viteză.
• La 1 Gbit și sub, linia e limita și nzbfast stă chiar pe ea: ~96% dintr-o linie de 500 Mbit și ~96% dintr-o linie de 250 Mbit prin verificare și extragere, la o fracțiune din memoria și discul fiecărui rival - secțiunea sub-gigabit de mai sus.
• Costul de procesor pentru întregul job de 87 GB e de 1,7 secunde de procesor per GB cu regulatorul de conexiuni pornit - incluzând descărcare peste TLS, verificare, pregătire de reparare și extragere - față de 3,0 până la 28 pentru câmp în aceeași rundă; brațul cu debit maxim de mai sus cheltuiește 4,3.

Tăieri anterioare ale acestei pagini purtau un set mai larg de demonstrații de transport - rulări de saturație multi-linie, câștiguri de pipelining per RTT, o dovadă de backpressure, măsurători de plafon de decodare - concurate pe build-uri pe care v1.2.2 le-a depășit de atunci. Sub regula acestei pagini, sunt retrase mai degrabă decât lăsate să îmbătrânească, și revin pe măsură ce sunt re-tăiate pe lansarea curentă; cele trei afirmații de mai sus sunt cele deja remăsurate pe v1.2.2.