Benchmark

La versione breve · misurato il 23 agosto 2026 sulla linea di codice uscita come nzbfast 1.2.2

Nessun client misurato costa meno su processore, memoria e disco insieme

Le tornate più recenti di questa pagina sono girate il 23 e il 24 agosto 2026 - le più recenti di tutte sulla build di rilascio v1.2.2 stessa - contro le build attuali di altri quattro client su hardware, linee e provider identici: due forme di job da 6,5 a 87 GB, e velocità di linea da 250 Mbit a 10 GbE. In quelle tornate nessun client è costato meno di nzbfast su processore, memoria e disco insieme: ognuno costa di più su almeno due dei tre, il massimo risparmio ottenuto da uno qualsiasi di loro su un singolo asse è stato circa il 2 percento - un pareggio statistico, dentro la stessa variabilità da corsa a corsa di quel client - e sul disco ognuno di loro ha spostato almeno il doppio dei byte per un risultato byte-identico. Di serie, nzbfast ha anche tenuto la memoria più bassa di ogni client misurato, su ogni scenario, da 2,0x a 4,5x contro il rivale più vicino.

Qual è il tuo caso?

La maggior parte dei downloader scrive il tuo download su disco almeno due volte: una mentre lo scarica, e di nuovo mentre lo scompatta. nzbfast fa l'intero job in una sola passata, quindi scrive circa la metà dei byte per job, tiene meno in memoria mentre lavora, e spende meno secondi di processore per GB. Questo significa meno carico sulla macchina mentre la usi e metà delle scritture per job sui tuoi dischi, per gli stessi file byte-identici - e poiché ogni byte attraversa il disco circa una volta, il tuo disco deve tenere il passo della tua linea una sola volta.

nzbfast non vince ogni tabella di questa pagina, e quelle che perde sono sotto le prove che non vinciamo - inclusa una di questa stessa tornata. Quello che è rimasto vero in ogni tornata misurata è il conto complessivo.

Prima la metodologia

L'impostazione

• Client: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, ogni tabella sulle build che nomina. Le tornate più recenti (23 agosto 2026) hanno fatto correre le build allora attuali del campo - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 e Weaver 0.7.8, il suo binario distribuito più recente, identità provata per hash - contro la linea di codice uscita quella stessa notte come nzbfast 1.2.2, quindi la build che ha prodotto i nuovi numeri è quella che puoi scaricare. Quelle tornate sono girate su una macchina Apple Silicon a 20 core su una linea 1 Gbit. Le tabelle più vecchie mantengono le build e le macchine con cui hanno corso (macchine Apple M-series: «Europa» M1 Ultra su 10 GbE, «costa est» M3 Ultra con linea ~2,4-3,0 Gbps) e lo dichiarano; sottostimano la build distribuita invece di lusingarla.
• Equità: stessi provider e TLS ovunque per ogni client, prove eseguite in sequenza alternata. Ogni concorrente ottimizzato al suo meglio documentato: SABnzbd ha ricevuto pipelining_requests=8 (di serie è 1, cioè senza pipeline, e l'impostazione vale percentuali a due cifre sui job grandi), NZBGet ha ricevuto ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb la sua configurazione documentata. Dal 20 agosto 2026 ogni tornata fa correre cinque provider anziché sei - il numero di provider non è una leva di throughput su queste macchine, dove un solo provider può da solo raggiungere il tetto della linea, e un insieme fisso mantiene le tornate confrontabili - quindi una cifra a sei provider su questa pagina non è direttamente confrontabile con una più recente a cinque provider, e ogni tabella dichiara quale ha usato.
• Stato finale: un file verificato, estratto e utilizzabile, non «download terminato». È questo che aspetti davvero.
• Riproducibilità: ogni affermazione è datata e misurata allo stesso modo: tempo trascorso + contatori di byte dell'interfaccia + picco di RSS dell'albero dei processi, risoluzione 1-2 s. Dove una prova gira su un NZB pubblicato pubblicamente, lo indichiamo per nome così puoi rifarla tu stesso.
• Note di metodo valide per tutta la pagina: il tempo CPU è campionato dall'albero dei processi a 2 Hz su ogni braccio di una tabella e non viene mai messo accanto a una cifra da una contabilità diversa, perché i due metodi non concordano per costruzione. L'I/O del dispositivo è espresso in GiB e i byte di rete in GB decimali; convertiamo prima di dividere. E qualsiasi tabella che fa correre la nostra build contro la nostra stessa build porta un controllo A/A - lo stesso binario fatto correre contro una copia byte-identica di se stesso attraverso lo stesso banco - perché è quel controllo che ci ha permesso di scoprire che il nostro stesso banco di confronto assegnava una penalità di circa l'1,5% a qualunque strumento partisse per primo (la storia è accanto alle tabelle di estrazione più sotto). Due bracci e ordini scambiati non annullano un bias che ricade sempre sul primo braccio; un controllo A/A lo smaschera.

Linee più lente · misurato il 24 agosto 2026 su nzbfast 1.2.2

Più lenta è la linea, meno la velocità separa i client - e più lo fa il conto

Su una linea abbastanza lenta, il tempo di arrivo di ogni client è la linea e nient'altro, quindi una linea lenta nasconde molti peccati. Quello che non può nascondere è quanto ogni client brucia per riempirla. Abbiamo sagomato il banco da 1 Gbit su due velocità che sono quelle di piani reali e abbiamo fatto correre tutti e sei i bracci a ciascuna - stessa macchina, stessi cinque provider, tre ripetizioni per client con l'ordine ruotato, ogni prova controllata byte per byte, 36 su 36 corrette nelle due tornate. Il braccio nzbfast a 500 Mbit è la build di rilascio v1.2.2 stessa.

Leggi le due tabelle come un gradiente. A 250 Mbit l'intero campo atterra entro il 18% sul cronometro e conduciamo sul rivale più vicino del 4,4%; a 500 Mbit il divario si apre al 14,7%; alle velocità gigabit e 10 GbE nelle tabelle sopra e sotto si apre ulteriormente. Le differenze di velocità crescono con la linea. Le colonne delle risorse non aspettano una linea veloce: a ogni velocità misurata, ogni rivale ha tenuto almeno 3,9x la memoria, speso più processore, e spostato circa il doppio dei byte su disco per lo stesso file byte-identico.

Il regolatore delle connessioni si guadagna il suo posto sulle linee lente, e il contatore di scarti del limitatore dice perché. Le impostazioni predefinite hanno tenuto 25 connessioni dove ogni rivale ne faceva girare centinaia; lo stesso binario con il regolatore disattivato ne ha fatte girare 360. Meno flussi attraverso una coda fissa significa meno perdite e meno reinvii: il limitatore ha registrato circa 4.200 scarti per prova limitata contro circa 155.000 senza limite a 500 Mbit, e il braccio limitato era più veloce, 4,2x più leggero sulla memoria e 1,3x più leggero sulla CPU rispetto alla nostra stessa postura a 360 socket. Più connessioni non significa più velocità; sotto il gigabit è misurabilmente il contrario.

Misurato il 24 agosto 2026, mediane di tre, su una macchina Apple Silicon a 20 core con la linea sagomata a ciascuna velocità (la velocità sagomata verificata da una sonda indipendente prima di ogni tornata: 248 e 496 Mbit). Il braccio nzbfast a 500 Mbit è la build del tag di rilascio v1.2.2; la tornata a 250 Mbit è girata ore prima sulla stessa linea di codice. I conteggi di byte su una linea sagomata sono letti dal contatore proprio di ogni client, mai dall'interfaccia di rete (il limitatore scarta e TCP reinvia, quindi l'interfaccia conta entrambe le copie). I tempi totali sono confrontabili dentro ogni tabella, non tra tornate sagomate diversamente. ¹ Le tre prove di NZBGet a 500 Mbit sono andate da 114 a 158 s con letture delle risorse piatte - uno scarto genuino, quindi si cita la mediana e si dichiara lo scarto invece di restringerlo.

Il post danneggiato · rifatto correre il 24 agosto 2026, ogni build attuale

Quando il post ha dei buchi: 6,5 GB con 60, 20 e 5 articoli morti

Gli articoli scadono, i server li lasciano cadere in silenzio, i caricamenti arrivano incompleti - ed è il danno il punto dove il divario tra i client è più ampio, quindi ottiene una tornata tutta sua sulla build più recente di ogni client, nzbfast v1.2.2 incluso: macchina Europa a 10 GbE, cinque provider, 100 connessioni per client, la stessa release da 6,5 GB avvelenata a tre livelli di danno, tre ripetizioni per braccio con l'ordine alternato, ogni prova controllata byte per byte contro il file pulito. 63 prove su 65 sono tornate identiche byte per byte; le due che non lo sono sono nominate qui sotto, perché sono risultati.

Perché il post danneggiato è veloce qui. Quando manca un articolo, un client normalmente chiede al server successivo, poi al successivo ancora, finché ogni server non lo ha rifiutato - una camminata seriale i cui rifiuti richiedono da decine di millisecondi a un paio di secondi ciascuno, durante i quali il download resta a zero. nzbfast smette di chiedere: non appena i dati di parità già in mano coprono ciò che ancora manca, ripara immediatamente invece di finire la camminata. Questa è la seconda riga - lo stesso binario con quel comportamento disattivato è da 1,4x a 2,3x più lento a seconda del danno - e la tornata ha verificato che il meccanismo si attivava su ogni prova abilitata e mai su una disabilitata. Contro il rivale più vicino il margine è da 2,4x a 2,7x, senza sovrapposizioni in nessuna delle nove coppie di ripetizioni.

Il disco è dove il margine è più ampio, e non è il trucco della riparazione. Ogni braccio che ha completato ha prodotto lo stesso file da 6,48 GB; il nostro ha spostato 6,2-6,8 GB di I/O su disco per farlo, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB e rustnzb 12,8-13,1 GB. Questo è l'oleodotto a passata unica - la riga disattivata sposta gli stessi 6,2 GB - quindi vale tanto sui post danneggiati quanto su quelli integri.

¹ Le tre prove di SABnzbd al danno più pesante sono andate 43, 41 e 60 s - uno scarto genuino su ingressi identici, quindi si cita la media con l'intervallo dichiarato. ² rustnzb 1.4.5 ha consegnato ogni prova byte-corretta, e il suo costo sta nel tempo di processore piuttosto che nell'affidabilità: circa 1.620 secondi di CPU contro un tempo totale di 107 s al danno più pesante - circa quindici core occupati per l'intera prova - dove lo stesso output riparato ci costa circa 50 secondi di CPU. ³ Weaver ha spostato 1,5 GB e 4,9 GB dei 6,5 entro il nostro limite di 20 minuti ai due livelli di danno più pesanti - lo stesso mancato completamento in tutte e tre le tornate che lo hanno visto in gara, in tre notti separate; il limite è nostro e il mancato completamento è il risultato. A 5 articoli morti ha completato correttamente tutte e tre le volte. Il suo costo di processore lì è una storia a sé: circa 2.325 secondi di CPU per la prova da 194 s, contro i nostri 20.

Misurato il 24 agosto 2026, tutte le build attuali: nzbfast v1.2.2 (il tag di rilascio stesso), NZBGet 26.3-testing (build del 20 agosto), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. Un braccio di continuità ha fatto correre la build nzbfast della notte precedente dentro questa stessa tornata ed è atterrato entro un secondo da v1.2.2 su ogni scenario, quindi niente qui si appoggia a una notte fortunata; e le configurazioni rivali differiscono da quelle della tornata precedente solo per il percorso di applicazione, controllato chiave per chiave prima che la tornata girasse.

Affamalo di RAM · misurato il 24 agosto 2026 su nzbfast 1.2.2

La scala a bassa memoria: 87 GB in ~0,3 GB di RAM

Lo stesso job da 87 GB della tornata qui sopra, rifatto correre con budget di memoria fissi di 2 GB, 1 GB e 256 MB - ciò che il dimensionatore automatico sceglierebbe su una macchina da 8 GB, una da 4 GB, e un NAS da 2 GB. Ogni prova ha prodotto il file identico controllato byte per byte, e la colonna della memoria ha seguito il budget, mai il job:

Una sola prova per budget sulla build di rilascio, controllata contro lo stesso checksum di output della tornata a sei bracci. Il budget più stretto costa circa il 9% del tempo totale, e solo perché questa linea è 10 GbE - i blocchi riversati su disco costano tempo solo quando la linea supera il disco, quindi su una connessione domestica tipica un budget piccolo è quasi gratis. L'intera scala, download da 87 GB incluso, sta in 0,3-0,6 GB di memoria; alle impostazioni predefinite il job è girato in 286 MB. Nessun altro client offre un budget di memoria rigido a livello di processo; le cose più vicine sono manopole di dimensione della cache, e la tornata qui sotto misura quanto costano quelle.

Il vincolo messo in gara contro le manopole proprie del campo. Sullo scenario da 34 GB (23 agosto 2026, macchina 1 Gbit, cinque provider, 30 prove su 30 byte-corrette), tenere NZBGet a un vincolo di cache equivalente ha più che raddoppiato la sua CPU (da 215,5 a 453,0 secondi, 2,10x) per comprare un taglio del 52% nel suo picco di memoria, e il vincolo di SABnzbd era quasi gratuito ma raggiungeva solo parte del suo ingombro. L'impostazione della cache di rustnzb era decorativa nella build fatta correre, e Weaver non ha alcuna manopola di memoria, quindi entrambi hanno girato senza vincoli come colonne di riferimento invece di essere valutati a un budget che non possono tenere. Il nostro lato di quella tornata è superato dalla scala v1.2.2 qui sopra, che dice la stessa cosa a 2,5x la dimensione: il budget non è mai il vincolo determinante, perché la passata unica tiene così poco per cominciare.

Spazio libero · misurato al megabyte

Quanto poco spazio libero serve a un job

Un client che scrive e poi scompatta ha bisogno di spazio per i volumi dell'archivio e per il payload scompattato insieme, quindi un job non parte senza all'incirca il doppio del download libero. La passata unica ha bisogno del payload - e questa tornata ha misurato quanto poco di più, restringendo il volume di destinazione finché ogni client non falliva. La risposta di nzbfast è una costante di circa 50 MB di margine, non un rapporto, e vale da un job da 6,5 GB fino a uno da 34 GB.

Misurato su una macchina Apple Silicon a 20 core, linea 1 Gbit, cinque provider, tre ripetizioni a ogni limite, ogni prova completata controllata byte per byte - le righe rivali del 22-23 agosto 2026 (cella da 34 GB di Weaver ripetuta il 24 agosto, nota 1), e la riga nzbfast ritagliata sulla build di rilascio v1.2.2 il 24 agosto, che ha riprodotto entrambi i limiti esattamente, 12 prove su 12 unanimi nei due scenari. Le nostre celle sono un pavimento misurato: il job completa 3 su 3 con 48,6 MB e 51,0 MB di margine, e si rifiuta 3 su 3 a circa 17 MB sotto quello - quindi il pavimento è reale in entrambe le direzioni. Quello che il job tiene davvero si assesta sull'output più circa 3 MB; il margine paga gli ultimi istanti dell'oleodotto, mai una seconda copia. Le celle dei rivali sono il loro pavimento misurato sul job da 6,5 GB e una sufficienza confermata allo stesso rapporto su quello da 34 GB (3 su 3 byte-corrette esattamente a quel rapporto); non abbiamo sceso ulteriormente la loro scala alla dimensione più grande, quindi il loro vero pavimento lì potrebbe stare un po' sotto il rapporto, e lo diciamo invece di arrotondare a nostro favore.

Cosa sembra davvero esaurirsi conta quanto il numero. A 17 MB sotto il suo pavimento nzbfast incontra il rifiuto del disco su una scrittura, si ferma pulito con «spazio su disco esaurito», mantiene tutto ciò che è arrivato registrato nel journal, e un nuovo tentativo riprende senza riscaricare - un parziale che tieni, non un job fallito. ¹ La cella dello scenario grande di Weaver è stata risolta da una ripetizione il 24 agosto: tre prove su tre byte-corrette allo stesso ~2,25x, ognuna più veloce della prova buona del primo tentativo, con lo spazio libero identico al byte. Nel primo tentativo, il 23 agosto, due delle sue tre prove si erano bloccate a MB/s a una cifra con più di 60 GB ancora liberi e avevano colpito il limite di 40 minuti della tornata. Quei blocchi non sono tornati, e la strumentazione dei blocchi del banco era attiva e silenziosa su tutte e tre le prove della ripetizione, il che è una misura positiva e non una misura assente. Cosa li abbia causati resta ignoto, e una ripetizione pulita non è una diagnosi: ora esistono sei prove a questo rapporto, quattro completate, ed entrambi i fallimenti vengono da una sola finestra di 80 minuti nella prima notte.

Post annidati · misurato il 28 agosto 2026

Dieci modi di impacchettare un post, e chi arriva davvero al file

Molto di ciò che viene pubblicato è deliberatamente difficile da aprire. Il nome reale del file è sepolto dentro un secondo archivio, a volte un terzo, a volte in un formato diverso a ogni livello, così che il post riveli il meno possibile di ciò che contiene. A questo si aggiungono i post danneggiati: gli articoli scadono, i caricamenti arrivano incompleti e i dati di recupero vanno usati prima di poter estrarre qualsiasi cosa. Un client percorre quella catena per voi, oppure vi consegna una cartella di archivi e si ferma.

Abbiamo quindi costruito dieci forme che isolano esattamente questo, messo alla prova ogni client attuale e poi fatto ciò che i confronti di solito saltano: dove un client si è fermato in anticipo, abbiamo completato il lavoro a mano con gli strumenti standard e cronometrato anche quello. Un client che si arrende in fretta sembra veloce finché non si conta il lavoro che vi lascia.

nzbfast è l'unico a completare tutte e dieci senza aiuto. Anche NZBGet raggiunge il file su ogni forma, ma richiede 16 cicli di riparazione ed estrazione manuali su otto di esse. SABnzbd ne completa cinque da solo e due restano irraggiungibili anche a mano. Weaver raggiunge il file su due.

Lo schema non è casuale. Le forme che nzbfast percorre e le altre no sono quelle impacchettate e quelle danneggiate: un archivio dentro un archivio, un cambio di formato a metà catena, una catena a cinque livelli e soprattutto un archivio che arriva corrotto con i propri dati di recupero accanto. Su quest'ultima quattro client estraggono perfettamente l'insieme esterno, vi consegnano l'archivio difettoso insieme al set di recupero che lo riparerebbe, e si fermano.

Dove i client svolgono lo stesso lavoro, il divario non è ravvicinato. Queste sono le sette forme raggiunte da tutti e quattro i client principali, contando la riparazione manuale necessaria a ciascuno:

Da quattro a cinque volte più rapido, con meno della metà dei byte scritti. Il dato del disco è quello che continua a contare dopo il download: ogni gigabyte in quella colonna è un gigabyte che il vostro disco ha dovuto assorbire, e i client che usano un'area di transito scrivono il contenuto, lo rileggono e lo riscrivono.

Dove non siamo in testa, e perché vale la pena dirlo. Su quattro delle dieci forme un concorrente scrive meno byte di nzbfast durante il download stesso. Ogni volta perché ha fatto meno: sulla forma con archivio interno corrotto NZBGet scrive 3,29 GB contro i nostri 4,65, poi la sua passata di riparazione ne scrive altri 2,91, chiudendo a 6,20 GB contro i nostri 4,65. Sulle altre, il client che ha scritto meno è uno che non ha mai raggiunto il file. Un numero basso sul disco non è sempre parsimonia.

Questi sono test di capacità, non test di velocità. I contenuti sono piccoli e vengono serviti dalla memoria su una connessione locale, senza provider né rete nel percorso: nulla qui è limitato dalla velocità di download e i secondi assoluti sono molto più brevi di quanto le stesse forme richiederebbero nel mondo reale. Se una forma richieda o meno lavoro manuale è una proprietà della forma e del client, e si trasferisce direttamente. I secondi confrontano client che svolgono un lavoro identico, non prevedono quanto durerà un compito reale.

I risultati completi per forma, la descrizione di ogni forma e il metodo sono nella pagina dati sugli archivi annidati.

Perché conta

Il tuo disco fa metà del lavoro

Lo storage flash si consuma venendo scritto. Una release da 94 GB costa al tuo disco circa 90 GB di scrittura sotto nzbfast; sotto un client che scrive a fasi e scompatta, la stessa release costa all'incirca il doppio. Su un NAS con dischi meccanici la forma a passata unica rimuove anche la lunga passata a thread singolo alla fine di ogni download cifrato - una pausa misurata a 20 secondi su una workstation veloce a 32 core con sblocco accelerato via hardware, e corrispondentemente più lunga sulle macchine a bassa potenza su cui la maggior parte delle persone lo fa girare davvero. Citiamo il numero piccolo perché è quello che abbiamo misurato.

Confronti sui componenti

I benchmark più tecnici, per chi ama i dati

Riparazione (PAR2) ed estrazione (RAR) sono codice nativo nostro anziché binari di terze parti in bundle, quindi li facciamo correre anche da soli contro gli strumenti dedicati su corpora identici, su quattro macchine che coprono quello che un lettore potrebbe davvero possedere. Un tempo conta solo se l'output è byte-identico al payload sorgente: ogni cifra RAR qui sotto è stata controllata per sha256 contro la sorgente, e ogni file riparato contro il set incontaminato.

Estrazione RAR: 7 forme di archivio, 6 strumenti

La tornata precedente di questa tabella usava da 100 MB a 200 MB per forma, il che era un errore: circa 28 ms di avvio del processo erano il 40% della prova store, e l'ordinamento che produceva non sopravvive a una dimensione realistica. Questa tornata è 1 GB di payload per forma, e cambia diverse risposte, incluse alcune nella direzione opposta. Gli archivi sono creati dal rar ufficiale 7.23, così nessuno strumento viene giudicato su un input proveniente dal proprio stesso codificatore, e gli stessi byte vengono fatti correre su ogni macchina.

Cosa c'è nel payload conta più di quanto sembri. Un payload costruito con copie di blocchi rende ogni forma compressa un benchmark di copia in memoria; un payload di puro testo lo rende un benchmark di letterali e Huffman; abbiamo misurato entrambi e non concordano su chi vince. Quindi le quattro forme compresse usano terzi uguali di testo, record strutturati e byte incomprimibili, e le due forme agli estremi di quell'intervallo sono prove separate di proposito: store è incomprimibile e repetitive è quasi tutta corrispondenze. Il costruttore e il banco sono nel repository, così il corpus può essere ricostruito byte per byte.

Rifatto correre il 23 agosto 2026 sul motore 1.2.2, e la scansione regge. I tre strumenti che un lettore pesa più spesso - il nostro, unrar 7.23 e rarpar 0.2.5 - sono stati rifatti correre sul desktop a 32 core sul motore di rilascio (il codice di estrazione fatto correre è byte-identico al tag 1.2.2), sei tornate alternate, minimo per strumento, output di ogni prova controllato contro il manifesto del payload. Secondi, più basso è meglio:

Tutte e sette le forme nostre, sul minimo e sulla mediana, da 1,16x a 4,29x contro unrar. Questi tempi non sono confrontabili cella per cella con la tabella più ampia qui sotto - il banco è stato rivisto dalle tornate di quella tabella e i conteggi delle tornate differiscono - quindi leggi ogni tabella contro se stessa. La tabella più ampia mantiene le proprie date e il suo campo di sei strumenti, e la sua colonna nzbfast descrive il motore che 1.2.2 distribuisce: la nuova corsa qui sopra ha misurato il livello attuale del motore con la build di quella tabella su tutte e sette le forme, stabilito dai conteggi delle istruzioni hardware (0,14% in meno per lo stesso tempo totale), quindi quelle celle non sono i numeri di una build superata con un'etichetta attuale. Questa nuova corsa è anche dove è stata guadagnata la regola A/A nella sezione dell'impostazione. Un passaggio nello stesso giorno inizialmente ha riportato una forma come una piccola regressione contro la nostra stessa build precedente, e la lettura è sopravvissuta facendo girare entrambi gli ordini dei bracci. Un controllo A/A - lo stesso binario fatto correre contro una copia byte-identica di se stesso - ha mostrato che il banco assegnava a qualunque braccio partisse per primo una penalità di circa l'1,5%: il binario identico ha vinto solo 6 tornate su 15 dallo slot iniziale, e scambiare gli ordini non annulla un bias che ricade sempre su chi parte per primo. I conteggi delle istruzioni hardware hanno risolto la questione che il banco non poteva - la build più recente ritira lo 0,14% in meno di istruzioni per lo stesso tempo totale, quindi non c'era nessuna regressione. Ogni confronto nostra-build-contro-nostra-build che pubblichiamo ora porta quel controllo.

L'intero campo, secondi, più basso è meglio. Il migliore di tre, strumenti alternati dentro ogni tornata invece che fatti girare a blocchi, output controllato contro il payload sorgente su ogni singola corsa. Uno strumento che ha prodotto i byte sbagliati ottiene una nota di correttezza, mai un tempo veloce. rarpar è il codice RAR e PAR2 proprio di Weaver, compilato dai sorgenti al commit bd87611; fissiamo il commit anziché una versione perché i suoi crate portano tre numeri di versione diversi.

Dove il campo non ha potuto competere, e perché. ¹ Il 7-Zip fatto correre qui è il pacchetto Homebrew, che rifiuta ogni forma compressa con ERROR: Unsupported Method e legge solo quella memorizzata su macOS. Una versione precedente di questa pagina attribuiva questo alla build macOS di 7-Zip, il che era sbagliato: Homebrew lo compila senza il codec unRAR non libero, mentre la build macOS che 7-zip.org distribuisce porta il codec e decodifica tutte e sette le forme, come fa la build Windows. Rimisurato il 14 agosto 2026. Se installi 7-Zip dal progetto anziché da Homebrew, questa colonna non descrive quello che hai. ² bsdtar non ha supporto multivolume RAR5 e ha prodotto un file troncato senza segnalare un errore, quindi quella prova è un fallimento di correttezza piuttosto che un tempo lento; il nostro banco lo ha colto controllando l'output, ed è per questo che vale la pena controllare l'output. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar non distribuisce alcuno strumento a riga di comando per Windows, quindi il campo del laptop è cinque. ⁶ Il gruppo M5 Max fa correre i tre strumenti a cui un lettore macOS ricorrerebbe davvero - unrar, rarpar e noi; unar, bsdtar e 7-Zip non sono stati fatti correre su quella macchina. Il suo unrar è 7.22, la build più recente che gira lì senza supervisione.

Ogni forma su ogni macchina tranne una, e quella è un pareggio. Le forme a corrispondenza breve si riducono a due cose specifiche nel nostro decodificatore. Una corrispondenza da due a trentadue byte pagava una chiamata completa alla routine di copia in memoria della piattaforma, e la chiamata costava più della copia; copiare invece trentadue byte fissi attraverso un registro è il motivo per cui repetitive, solid e il dizionario 128 MiB - le tre forme costruite su corrispondenze brevi - sono tutte veloci insieme. E il checksum gira a valle del thread dello scrittore anziché su di esso. L'unica cella che non vinciamo apertamente è la forma memorizzata sul desktop a 32 core, dove unrar e noi siamo a tre millisecondi di distanza su una prova che si limita a spostare byte - identici alla precisione di questa tabella, quindi entrambe le celle sono segnate e viene valutato un pareggio, non una sconfitta e non una vittoria.

La forma in cui vinciamo di più è quella che usenet pubblica davvero a centinaia alla volta: 400 file piccoli, 4,3× e 4,4× contro unrar e da 5,4× a 5,5× contro rarpar. Questo è parallelismo per membro, ed è la differenza tra un estrattore scritto per una coda di download e uno scritto per una riga di comando. La forma memorizzata, che il censimento qui sopra dice essere l'84% dei byte sulla rete, è quasi un pareggio per i tre strumenti seri, perché a quel punto tutti si limitano a spostare byte.

Una scelta che merita di essere dichiarata. Gli archivi sono impacchettati con il compressore fissato a quattro thread. Altrimenti la suddivisione in blocchi di RAR segue il numero di core della macchina che ha impacchettato l'archivio, così una macchina a 32 core e una a 20 core producono byte diversi dallo stesso input e le macchine smettono di essere confrontabili. Fissarlo rende il corpus di estrazione identico byte per byte ovunque, ed è questo il punto, ma limita anche quanta parte della decodifica può girare in parallelo - perciò, quando le due forme più vicine erano sconfitte, le abbiamo rifatte correre contro archivi impacchettati con tutti e 32 i thread, per verificare che non fosse il fissaggio a causarlo. Non lo era: solid è passato dal 4,2% di ritardo al 2,4% e il dizionario 128 MiB dal 6,6% al 6,3%, lo stesso ordinamento in entrambi i casi. Entrambe ora sono vittorie sul corpus fissato, con un margine più ampio di quanto quella verifica potrebbe spiegare.

Perché non c'è una riga RAR4, e cosa succede a quei post. Ogni forma qui sopra è RAR5 o RAR7, che è quello che usenet pubblica oggi. Archivi RAR4 più vecchi si vedono ancora, e lo stesso motore li legge, incluse le forme compresse e protette da password, nella stessa passata unica di quelli più recenti invece di scrivere i volumi su disco e scompattarli dopo. Non hanno una riga qui perché il rar ufficiale 7.23 non può più creare RAR4, quindi non c'è un corpus neutrale su cui far correre il campo; quel lavoro è invece controllato contro archivi scritti da WinRAR 3.00, byte per byte contro unrar.

Verifica e riparazione PAR2: set da 1 GiB, quattro livelli di danno

Corpus: 1 GiB di payload casuale impacchettato in modalità store in 21 volumi RAR, poi due set PAR2 al 10% di ridondanza, uno a blocchi da 1 MiB e uno da 64 KiB, poi mappe di danno fisse. Ogni corsa usa lo stesso protocollo: copia fresca, lettura dell'intero corpus una volta per scaldare la cache, poi cronometrare. Il migliore di tre tornate alternate; ogni volume riparato è confrontato contro il set incontaminato a ogni tornata. Più basso è meglio.

Una correzione sul corpus, perché una versione precedente di questa pagina lo esagerava. Dicevamo che ogni macchina faceva girare un corpus byte-identico, controllato per hash. Calcolare l'hash di ogni volume di ogni set mostra che è vero per il desktop a 32 core e il laptop Windows, che corrispondono esattamente, e non per il desktop a 20 core, che tiene un'estrazione casuale diversa della stessa forma: gli stessi 21 volumi alle stesse dimensioni, le stesse due dimensioni di blocco, e danno verificato agli stessi 3, 101 e 1.500 blocchi distribuiti sullo stesso numero di file. Ogni numero dentro una riga è comunque misurato su byte che ogni strumento di quella riga condivide, ed è su questo che si fonda ogni confronto. Ma le righe non sono quattro viste dello stesso input, e poiché il carattere del payload vale circa il 7% per la scansione di un concorrente, vale la pena dichiararlo invece di sorvolarci.

Quale par2 è quale. L'originale par2cmdline è l'implementazione di riferimento da cui tutti hanno derivato. par2cmdline-turbo è il fork che integra i kernel SIMD per campi di Galois scritti a mano di ParPar: è esattamente questo che significa "turbo", ed è per questo che turbo, anziché l'originale, è lo strumento contro cui vale la pena misurarsi. Entrambe le colonne turbo qui sotto fanno girare quegli stessi kernel ParPar. Ciò che le separa non è l'aritmetica ma la build e i flag.

Confermato sulla build distribuita contro il rivale attuale, 24 agosto 2026. Queste tabelle sono state misurate prima che 1.2.2 fosse tagliata e prima che par2cmdline-turbo rilasciasse 1.5.0 (20 agosto 2026), quindi la colonna a 20 core è stata rifatta correre su entrambe: la nostra build di rilascio 1.2.2 contro turbo 1.5.0, tre tornate alternate per prova, ogni file riparato confrontato contro il set incontaminato. Tutte e quattro le prove si riproducono - le nostre 0,18 / 0,30 / 0,75 / 2,02 contro le 0,19 / 0,33 / 0,74 / 2,07 stampate qui, e turbo 1.5.0 atterra entro pochi punti percentuali dalla build in tabella su ogni prova ed entrambe le configurazioni. Le celle restano come pubblicate; le altre tre macchine mantengono le proprie date.

Quindi la concorrenza compare due volte, e una di quelle colonne è il suo caso migliore anziché il suo predefinito. Il binario di rilascio che scaricheresti è compilato per una CPU generica di base e calcola l'hash di solo un paio di file alla volta; compilare lo stesso sorgente per la CPU host reale e passare -T16 gli permette di usare le istruzioni che quella macchina ha davvero e calcolare l'hash di sedici file alla volta. Sul laptop questo vale fino a 2,6x, interamente dalla build e dai flag. Giudicaci sulla colonna ottimizzata, che è il confronto più difficile; la colonna di serie è quello che chi lo scarica sperimenta davvero. par2cmdline è l'originale, versione 1.2.0, compilato dai sorgenti su ogni macchina. rarpar è l'implementazione PAR2 propria di Weaver, compilata dai sorgenti con il suo backend GPU Metal abilitato. Il par2j di MultiPar è solo Windows, quindi compare solo sulle righe del laptop Windows. Le righe M5 Max fanno correre i due strumenti con build arm64 macOS attuali accanto alle due colonne turbo; par2cmdline classico non è stato fatto correre su quella macchina.

Tutte e sedici le celle nzbfast - quattro macchine a quattro livelli di danno - sono nostre, diverse per più di 2× contro la build ottimizzata e per da 2,3× a 7,7× contro quella che scaricheresti davvero. Le celle a danno pesante sono quelle interessanti, e la nota qui sotto spiega l'algoritmo dietro di esse.

L'originale è di nuovo in tabella, e vale la pena vedere perché esiste il fork. Una versione precedente di questa pagina aveva tolto la colonna par2cmdline con la motivazione che era più lenta di tutto il resto nella tornata, il che è vero e non è una ragione sufficiente: è l'implementazione da cui quasi ogni altro strumento discende, e i lettori meritano il riferimento di base invece della nostra affermazione su di esso. Al livello di danno più pesante impiega circa 69 s dove il fork SIMD ne impiega 3,2 e noi 3,1. Quel fattore venti è tutto l'argomento a favore dei kernel per campi di Galois scritti a mano, ed è lo stesso argomento che facciamo per il nostro.

Il danno leggero è il caso che conta. Una manciata di articoli falliti è molto più tipica di 101 blocchi morti, e niente di simile a 1.500. Gran parte di una riparazione leggera non è affatto la matematica Reed-Solomon, è leggere e calcolare l'MD5 di un gigabyte, ed è per questo che la riga a 3 blocchi segue la riga della verifica pulita anziché quelle di riparazione.

Il livello di danno più pesante è un tipo di lavoro diverso, e riceve un algoritmo diverso. Quell'ultimo livello danneggia 1.500 blocchi su tutti e 21 i volumi e consuma circa il 91% dei dati di recupero, ed è lì che l'aritmetica Reed-Solomon, e non l'hashing o il disco, diventa quasi tutto il lavoro. La build distribuita calcola le riparazioni più pesanti con una trasformata teorico-numerica invece della classica riduzione su campo di Galois - la stessa matematica, valutata in una forma che scala molto meglio ad alti conteggi di blocchi: 2,7× avanti alla build ottimizzata sul desktop a 20 core, e sul laptop Windows 2,7× avanti alla build ottimizzata e 2,2× avanti a MultiPar. Il danno leggero continua a girare sul percorso classico, ed è per questo che gli altri livelli si sono mossi appena: la trasformata conviene solo oltre circa 512 blocchi danneggiati, quindi sotto quella soglia lo smistamento non la usa.

Un percorso più veloce vale la pena averlo solo se non può essere sbagliato. Entrambi i percorsi calcolano la stessa quantità e sono identici bit per bit per costruzione, e ogni riparazione su questa pagina è stata verificata sul fatto che i file ricostruiti corrispondessero al set incontaminato: 228 riparazioni cronometrate sulle macchine di questa tornata, zero discordanze. La build distribuita non si affida a quel primato. Ogni riparazione verifica il proprio output contro gli hash dei file, e una che fallisse verrebbe rifatta automaticamente con il percorso classico, registrerebbe la divergenza nel log, e manterrebbe il percorso classico per il resto di quella corsa. L'impostazione è nella dashboard come Fast PAR mode se preferisci non averla affatto, e le macchine con troppo poca memoria per usarla la rifiutano da sole invece di provare e fallire. Rimisurato il 2 agosto sulla build attuale: i due desktop atterrano entro pochi punti percentuali da questa tabella, e con Fast PAR mode disattivato il desktop a 20 core torna esattamente al tempo più lento del percorso classico, il che dice che la vittoria è il metodo e non le condizioni.

La colonna del laptop Windows aveva bisogno di una correzione, e va contro di noi. Windows retrocede il lavoro in background sostenuto sui suoi core efficienti dopo pochi secondi. Il nostro demone rifiuta questo comportamento all'avvio e nessuno degli altri strumenti può farlo, quindi una versione precedente di questa pagina pubblicava i loro tempi rallentati come se fossero i tempi propri degli strumenti. Rifacendo correre quella macchina con ogni strumento portato ad alta priorità sposta l'intero campo: al livello di danno più pesante par2-turbo passa da 22,4 s a 6,41 e rarpar da 59,2 s a 14,4, e per un taglio di questa pagina questo ha trasformato la colonna da nostra a persa. L'intera colonna del laptop è misurata così ora - la correzione resta anche se la riga è stata da allora rivinta dal cambio di algoritmo qui sopra, perché i tempi del campo su quella macchina sono onesti solo con il throttle sollevato.

Record di recupero RAR: riparare senza PAR2

Quando PAR2 non può coprire il danno, il record di recupero dentro il RAR stesso è l'ultima linea di difesa. Fino a 1.0.8 il nostro falliva su qualsiasi archivio oltre circa 13 MB, quindi questa prova non poteva proprio girare. Il danno sono tre buchi da 3.000 byte al 20%, 50% e 80% della regione protetta. Entrambi gli strumenti hanno prodotto un output byte-identico al file incontaminato, e il nostro è byte-identico a quello che rar r stesso scrive. Il migliore di tre, desktop a 32 core, entrambi gli strumenti rifatti correre insieme il 2 agosto.

Una versione precedente di questa pagina mostrava la dimensione da 512 MB come una sconfitta, e la spiegava come il prezzo di lavorare sul volume a pezzi anziché tenerlo tutto in memoria. Quella spiegazione era corretta all'epoca ed è ora superata: il costo era un CRC64 bit-seriale nel percorso di riparazione, sostituito con uno guidato da tabelle, e la sconfitta se n'è andata con esso. Non c'è più un incrocio, e l'insieme di lavoro limitato è stato mantenuto. La dimensione da 2 GB è qui perché i volumi che un demone incontra davvero sono da 8 GB a 20 GB, non 512 MB, e una prova che si ferma sotto l'intervallo reale non è un gran test.

Cosa ha spostato questo taglio, e il controllo che lo dice. Trovare quali blocchi sono danneggiati era diventata la fase più grande di questa riparazione - più grande dell'aritmetica di riparazione stessa - e girava su un singolo thread, leggendo 64 KB da ogni gruppo attraverso il file, una volta per gruppo. Ora fa una passata sequenziale in ordine di file con i checksum per shard calcolati in parallelo, e il volume riparato viene clonato anziché copiato dove il filesystem può farlo. Il solo rilevamento è sceso da circa 300 ms a 18 ms sull'archivio da 512 MB, che è gran parte di quello che si è mosso qui sopra. Il controllo è la colonna accanto alla nostra: rar r è stato rifatto correre nelle stesse tornate sulla stessa macchina ed è tornato entro pochi punti percentuali dai suoi tempi precedenti, quindi il cambiamento nel divario è nostro e non del banco.

Il M5 Max ripete lo schema, fatto correre il 31 luglio con lo stesso corpus e gli stessi controlli: 0,050 / 0,066 / 0,171 / 0,581 s contro gli 0,211 / 0,335 / 0,751 / 1,735 di rar r nelle dimensioni da 16 MB a 512 MB - da 3,0× a 5,1× più veloce; la dimensione da 2 GB non è stata fatta correre su quella macchina. Quelle cifre precedono la riscrittura del rilevamento descritta qui sopra, quindi sono della build più vecchia, mantenute qui come seconda macchina anziché come numero attuale.

Il rarpar di Weaver manca solo da questa tabella, e non per scelta: non implementa questa riparazione. Chiamato a riparare uno di questi archivi risponde "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data", e lascia il file danneggiato. Compare in ogni altro confronto di questa pagina: tutte e quattro le prove PAR2 qui sopra, tutte e sette le forme di estrazione più in alto, e la prova dei volumi di recupero subito sotto, che è esattamente il lavoro che dichiara di fare - e che vince.

Volumi di recupero: ricostruire interi file .rev mancanti

L'altra metà della storia di recupero propria di RAR, e fino a questa tornata la sconfitta più grande di questa pagina. Un file .rev è un volume di recupero standalone: tre di essi accanto a un set di 21 volumi possono ricostruire tre volumi qualsiasi che non sono mai arrivati. Corpus: 1 GiB memorizzato in 21 volumi da 50 MB con rar rv3, poi i volumi 4, 11 e 19 eliminati - tre persi contro tre volumi di recupero, il caso peggiore che il set può ancora sopravvivere. Il migliore di tre, ogni volume ricostruito confrontato contro quello incontaminato.

La cella a 32 core qui era 3,12 s contro gli 0,47 di rar rc nell'ultimo taglio di questa pagina, pubblicata come 6,6× più lenta e il peggior numero su di essa. La causa era la soluzione delle cancellazioni che girava a circa 48 MB/s di output ricostruito dove RARLab gestiva 320; ora gira sulla stessa aritmetica guidata da tabelle del resto del codice di recupero, il che è un miglioramento di sette volte e trasforma la sconfitta in una vittoria su entrambe le macchine. I margini sono 3% e 14%, quindi è una vittoria da dichiarare semplicemente anziché da titolare, e la ragione per cui è dichiarata affatto è che la sconfitta era stata dichiarata per prima.

Questa prova esiste perché il rarpar di Weaver implementa esattamente questo e ha chiesto di essere misurato su di esso. Stava vincendo comodamente quando lo abbiamo pubblicato la prima volta, e lo abbiamo pubblicato allora per quella ragione.

L'abbinamento dei file non è mai stato il costo, il che vale la pena registrare perché era il sospettato intuitivo: i volumi di recupero non portano nomi di file, quindi identifichiamo quali slot sono sopravvissuti calcolando il checksum di ogni volume su disco anziché fidarci di come sono chiamati, e contro un set non danneggiato, dove l'abbinamento è tutto ciò che accade, l'intera passata richiede 0,18 s.

Cos'altro si è mosso, e dove non si vede. Sono arrivati altri due cambiamenti del motore che questi corpora non possono vedere, elencati qui perché i numeri qui sopra non vengano letti come tutta la storia: gli archivi RAR5 con decine di migliaia di membri risolvono ogni membro una volta anziché percorrere la lista per ogni worker, il che è 3× meno tempo di processore a 40.000 membri; e il lettore di bit RAR1.3 lavora una parola alla volta, il che è 2×. Nessuno dei due compare qui sopra, perché le forme qui hanno 400 membri e niente RAR1.3.

Cosa deliberatamente non facciamo: non creiamo mai PAR2. Un downloader non ha ragione di farlo, e ParPar possiede quella prova. Compriamo anche velocità con memoria su entrambi i motori: l'estrazione raggiunge un picco intorno ai 240 MB contro i 41 MB di unrar, e la verifica intorno ai 126 MB contro i 7 MB di turbo, perché questi sono i motori inline che viaggiano insieme a un download dal vivo anziché one-shot standalone. La forma con dizionario a 128 MiB è la peggiore per questo, a circa 304 MB contro i 139 MB di unrar. Anche la riparazione più pesante ora costa memoria: il metodo più veloce per 512 o più blocchi mancanti lavora sui dati di recupero tenuti residenti, quindi gli è permesso fino a un quarto della RAM della macchina, con un tetto di 4 GB, e una macchina che non può permetterselo passa in silenzio al metodo a bassa memoria - la stessa aritmetica e gli stessi tempi delle righe centrali della tabella PAR2, solo non il 3× sull'ultima. Se vuoi l'insieme residente più piccolo possibile per un job standalone, gli strumenti dedicati vincono ancora quella colonna.

Prova di trasporto · misurato su 1.2.2

Il motore tiene il passo di linee reali

• ~8,7 Gbps sostenuti attraverso una flotta a cinque provider su una linea 10 GbE, inclusa la verifica e l'estrazione in flusso - la tornata da 87 GB qui sopra, 24 agosto 2026, v1.2.2, 360 connessioni: 77,4 GB di rete in 71 s con il payload verificato ed estratto man mano che arrivava. Non una cifra di raffica: l'intero job a quella velocità.
• A 1 Gbit e sotto, la linea è il limite e nzbfast ci sta sopra: ~96% di una linea 500 Mbit e ~96% di una linea 250 Mbit attraverso verifica ed estrazione, a una frazione della memoria e del disco di ogni rivale - la sezione sub-gigabit qui sopra.
• Il costo di processore dell'intero job sul job da 87 GB è 1,7 secondi di CPU per GB con il regolatore delle connessioni attivo - download su TLS, verifica, prontezza alla riparazione ed estrazione inclusi - contro da 3,0 a 28 per il campo nella stessa tornata; il braccio a piena velocità qui sopra spende 4,3.

Tagli precedenti di questa pagina portavano un insieme più ampio di dimostrazioni di trasporto - corse di saturazione multi-linea, guadagni di pipelining per RTT, una prova di contropressione, misure del tetto di decodifica - fatte correre su build che v1.2.2 ha da allora superato. Sotto la regola di questa pagina sono ritirate invece di essere lasciate invecchiare, e tornano man mano che vengono ritagliate sulla release attuale; le tre affermazioni qui sopra sono quelle già rimisurate su v1.2.2.