Benchmarks

La version courte · mesuré le 23 août 2026 sur la ligne de code livrée comme nzbfast 1.2.2

Aucun client mesuré n’est moins cher à la fois en processeur, en mémoire et en disque

Les manches les plus récentes de cette page ont tourné les 23 et 24 août 2026 - la plus récente d’entre elles sur le binaire de la release v1.2.2 elle-même - contre les versions actuelles de quatre autres clients, sur un matériel, des lignes et des fournisseurs identiques : deux formes de tâche de 6,5 à 87 GB, et des débits de ligne de 250 Mbit à 10 GbE. Sur l’ensemble de ces manches aucun client n’a été moins cher que nzbfast à la fois en processeur, en mémoire et en disque : chacun coûte plus sur au moins deux des trois, le maximum économisé par l’un d’eux sur un seul axe a été d’environ 2 pour cent - une égalité statistique, à l’intérieur de la propre dispersion de ce client d’un run à l’autre - et sur le disque chacun d’eux a déplacé au moins deux fois plus d’octets pour un résultat identique octet pour octet. Tel que livré, nzbfast a aussi tenu la mémoire la plus faible de tous les clients mesurés, sur chaque scénario, de 2,0x à 4,5x face au rival le plus proche.

Lequel vous correspond ?

La plupart des téléchargeurs écrivent votre téléchargement sur disque au moins deux fois : une fois pendant le téléchargement, et une autre fois pendant le désarchivage. nzbfast fait toute la tâche en une seule passe, donc il écrit environ moitié moins d’octets par tâche, tient moins en mémoire pendant qu’il travaille, et dépense moins de secondes processeur par GB. C’est moins de charge sur la machine pendant que vous l’utilisez et moitié moins d’écritures par tâche sur vos disques, pour les mêmes fichiers identiques octet pour octet - et parce que chaque octet traverse le disque environ une fois, votre disque n’a qu’à suivre votre ligne une seule fois.

nzbfast ne gagne pas chaque tableau de cette page, et ceux qu’il perd sont sous les manches que nous ne gagnons pas - dont une de cette même manche. Ce qui a tenu à chaque manche que nous avons mesurée, c’est la facture combinée.

La méthodologie d’abord

Le protocole

• Clients : nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, chaque tableau sur les versions qu’il nomme. Les manches les plus récentes (23 août 2026) ont fait courir les versions alors actuelles du champ - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 et Weaver 0.7.8, son binaire livré le plus récent, identité prouvée par hachage - contre la ligne de code qui a été livrée cette nuit-là comme nzbfast 1.2.2, si bien que la version qui a produit les nouveaux chiffres est celle que vous pouvez télécharger. Ces manches ont tourné sur une machine Apple Silicon 20 cœurs sur une ligne 1 Gbit. Les tableaux plus anciens gardent les versions et machines qu’ils ont fait courir (machines Apple série M : « Europe » M1 Ultra en 10 GbE, « Côte Est » M3 Ultra ligne ~2,4-3,0 Gbps) et le disent ; ils sous-estiment la version livrée plutôt que de la flatter.
• Équité : mêmes fournisseurs et TLS partout pour chaque client, manches enchaînées et entrelacées dos à dos. Chaque concurrent réglé à son meilleur documenté : SABnzbd a reçu pipelining_requests=8 (il est livré à 1, c’est-à-dire sans pipelining, et le réglage vaut des pourcentages à deux chiffres sur les grosses tâches), NZBGet a reçu ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb sa configuration documentée. Depuis le 20 août 2026 chaque manche fait courir cinq fournisseurs plutôt que six - le nombre de fournisseurs n’est pas un levier de débit sur ces machines, où un seul fournisseur peut à lui seul atteindre le plafond de la ligne, et un ensemble fixe garde les manches comparables - donc un chiffre à six fournisseurs sur cette page n’est pas directement comparable à un chiffre plus récent à cinq fournisseurs, et chaque tableau dit lequel il a fait courir.
• État final : un fichier vérifié, extrait, utilisable, pas « téléchargement terminé ». C’est ce que vous attendez réellement.
• Reproductibilité : chaque affirmation est datée et mesurée de la même façon : temps écoulé + compteurs d’octets de l’interface + pic de RSS de l’arbre de processus, résolution de 1-2 s. Quand une manche tourne sur un NZB publié publiquement, nous le nommons pour que vous puissiez la reproduire vous-même.
• Notes de méthode valables pour toute la page : le temps processeur est échantillonné depuis l’arbre de processus à 2 Hz sur chaque bras d’un tableau et n’est jamais placé à côté d’un chiffre issu d’une comptabilité différente, parce que les deux méthodes divergent par construction. Les E/S disque sont exprimées en GiB et les octets sur le fil en GB décimaux ; nous convertissons avant de diviser. Et tout tableau qui fait courir notre propre version contre notre propre version porte un contrôle A/A - le même binaire couru contre une copie identique octet pour octet de lui-même via le même harnais - parce que c’est ce contrôle qui nous a permis de repérer notre propre harnais de duel en train d’imposer une pénalité d’environ 1,5 % à quel que soit l’outil qui courait en premier (l’histoire est à côté des tableaux d’extraction plus bas). Deux bras et des ordres inversés n’annulent pas un biais qui retombe toujours sur le premier bras ; un contrôle A/A l’expose.

Lignes plus lentes · mesuré le 24 août 2026 sur nzbfast 1.2.2

Plus la ligne est lente, moins la vitesse distingue les clients - et plus la facture le fait

Sur une ligne assez lente, le temps de fin de chaque client n’est plus que la ligne et rien d’autre, donc une ligne lente cache beaucoup de péchés. Ce qu’elle ne peut pas cacher, c’est ce que chaque client brûle pour la remplir. Nous avons façonné le banc 1 Gbit à deux débits que de vrais plans connaissent réellement et fait courir les six bras à chacun - même machine, mêmes cinq fournisseurs, trois répétitions par client avec l’ordre tourné, chaque manche vérifiée octet par octet, 36 manches sur 36 correctes sur les deux manches. Le bras nzbfast à 500 Mbit est le binaire de la release v1.2.2 lui-même.

Lisez les deux tableaux comme un gradient. À 250 Mbit tout le champ tient dans 18 % sur le chronomètre et nous devançons le rival le plus proche de 4,4 % ; à 500 Mbit l’écart passe à 14,7 % ; aux débits gigabit et 10 GbE des tableaux au-dessus et en dessous il s’élargit encore. Les écarts de vitesse grandissent avec la ligne. Les colonnes de ressources n’attendent pas une ligne rapide : à chaque débit mesuré, chaque rival a tenu au moins 3,9x la mémoire, dépensé plus de processeur, et déplacé environ le double des octets de disque pour le même fichier identique octet pour octet.

Le régulateur de connexions gagne sa place sur les lignes lentes, et le compteur de pertes du façonneur dit pourquoi. Les réglages livrés ont tenu à 25 connexions là où chaque rival tournait à des centaines ; le même binaire avec le régulateur coupé a tourné à 360. Moins de flux à travers une file fixe, c’est moins de pertes et moins de renvois : le façonneur a relevé environ 4 200 pertes par manche plafonnée contre environ 155 000 non plafonnées à 500 Mbit, et le bras plafonné était plus rapide, 4,2x plus léger en mémoire et 1,3x plus léger en processeur que notre propre posture à 360 sockets. Plus de connexions n’est pas plus de vitesse ; sous le gigabit c’est mesurablement le contraire.

Mesuré le 24 août 2026, médianes de trois, sur une machine Apple Silicon 20 cœurs avec sa ligne façonnée à chaque débit (le débit façonné vérifié par une sonde indépendante avant chaque manche : 248 et 496 Mbit). Le bras nzbfast à 500 Mbit est le binaire du tag de release v1.2.2 ; la manche à 250 Mbit a tourné quelques heures plus tôt sur la même ligne de code. Les comptages d’octets sur une ligne façonnée sont lus depuis le compteur propre à chaque client, jamais depuis l’interface réseau (le façonneur laisse tomber des paquets et TCP les renvoie, donc l’interface compte les deux copies). Les chronomètres sont comparables à l’intérieur de chaque tableau, pas entre des manches façonnées différemment. ¹ Les trois manches de NZBGet à 500 Mbit se sont étalées de 114 à 158 s avec des relevés de ressources stables - une dispersion réelle, donc la médiane est citée et la dispersion énoncée plutôt que resserrée.

Le post endommagé · recouru le 24 août 2026, chaque version à jour

Quand le post est troué : 6,5 GB avec 60, 20 et 5 articles morts

Les articles expirent, les serveurs les laissent tomber en silence, les envois arrivent incomplets - et l’endommagement est là où l’écart entre les clients est le plus large, donc ça a sa propre manche sur la version la plus récente de chaque client, nzbfast v1.2.2 compris : machine Europe 10 GbE, cinq fournisseurs, 100 connexions par client, la même release de 6,5 GB empoisonnée à trois niveaux de dégâts, trois répétitions par bras avec l’ordre alterné, chaque manche vérifiée octet par octet contre le fichier propre. 63 manches sur 65 sont revenues identiques octet pour octet ; les deux qui ne l’ont pas fait sont nommées ci-dessous, parce que ce sont des résultats.

Pourquoi le post endommagé est rapide ici. Quand un article manque, un client demande normalement au serveur suivant, puis au suivant, jusqu’à ce que chaque serveur l’ait refusé - une marche en série dont les refus prennent de quelques dizaines de millisecondes à deux secondes chacun, pendant laquelle le téléchargement reste à zéro. nzbfast arrête de demander : dès que les données de parité déjà en main couvrent ce qui manque encore, il répare immédiatement au lieu de finir la marche. C’est la deuxième ligne - le même binaire avec ce comportement coupé est 1,4x à 2,3x plus lent selon les dégâts - et la manche a vérifié que le mécanisme s’engageait sur chaque manche activée et jamais sur une désactivée. Contre le rival le plus proche la marge est de 2,4x à 2,7x, sans chevauchement dans aucune des neuf paires de répétitions.

Le disque est là où la marge est la plus large, et ce n’est pas l’astuce de réparation. Chaque bras qui a terminé a produit le même fichier de 6,48 GB ; le nôtre a déplacé 6,2-6,8 GB d’E/S disque pour y arriver, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB et rustnzb 12,8-13,1 GB. C’est le pipeline en une passe - la ligne coupée déplace les mêmes 6,2 GB - donc ça tient sur les posts endommagés comme sur les intacts.

¹ Les trois manches de SABnzbd au dégât le plus lourd ont tourné à 43, 41 et 60 s - une vraie dispersion sur des entrées identiques, donc la moyenne est citée avec la plage énoncée. ² rustnzb 1.4.5 a livré chaque manche correcte octet par octet, et son coût se trouve dans le temps processeur plutôt que dans la fiabilité : environ 1 620 secondes processeur pour un chronomètre de 107 s au dégât le plus lourd - à peu près quinze cœurs occupés pendant toute la manche - là où la même sortie réparée nous coûte environ 50 secondes processeur. ³ Weaver a déplacé 1,5 GB et 4,9 GB des 6,5 dans notre plafond de 20 minutes aux deux niveaux de dégâts les plus lourds - le même non-achèvement dans les trois manches qui l’ont couru, sur trois nuits séparées ; le plafond est le nôtre et le non-achèvement est le résultat. À 5 articles morts il a terminé correctement les trois fois. Son coût processeur là est sa propre histoire : environ 2 325 secondes processeur pour la manche de 194 s, contre nos 20.

Mesuré le 24 août 2026, toutes versions à jour : nzbfast v1.2.2 (le tag de release lui-même), NZBGet 26.3-testing (version du 20 août), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. Un bras de continuité a fait courir la version nzbfast de la nuit précédente à l’intérieur de cette même manche et a atterri à moins d’une seconde de v1.2.2 sur chaque scénario, donc rien ici ne repose sur une nuit chanceuse ; et les configurations rivales ne diffèrent de celles de la manche précédente que par le chemin d’application, vérifié clé par clé avant que la manche ne tourne.

Affamez-le de RAM · mesuré le 24 août 2026 sur nzbfast 1.2.2

L’échelle basse mémoire : 87 GB en ~0,3 GB de RAM

La même tâche de 87 GB que la manche ci-dessus, rejouée à des budgets mémoire durs de 2 GB, 1 GB et 256 MB - ce que l’auto-dimensionneur choisirait sur une machine 8 GB, une machine 4 GB, et un NAS 2 GB. Chaque manche a produit le fichier identique vérifié octet par octet, et la colonne mémoire a suivi le budget, jamais la tâche :

Une seule manche par budget sur le binaire de release, comparée à la même somme de contrôle de sortie que la manche à six bras. Le budget le plus serré coûte environ 9 % du chronomètre, et seulement parce que cette ligne est en 10 GbE - les blocs déversés ne coûtent du temps que quand la ligne dépasse le disque, donc sur une connexion domestique typique un petit budget est proche du gratuit. Toute l’échelle, téléchargement de 87 GB compris, tient dans 0,3-0,6 GB de mémoire ; aux réglages livrés la tâche a tourné en 286 MB. Aucun autre client n’offre un budget mémoire dur à l’échelle du processus ; ce qui s’en rapproche le plus, ce sont des réglages de taille de cache, et la manche ci-dessous mesure ce qu’ils coûtent.

Le plafond couru contre les propres réglages du champ. Sur le scénario 34 GB (23 août 2026, machine 1 Gbit, cinq fournisseurs, 30 manches sur 30 correctes octet par octet), tenir NZBGet à un plafond de cache équivalent a plus que doublé son temps processeur (215,5 à 453,0 secondes processeur, 2,10x) pour acheter une réduction de 52 % de son pic de mémoire, et le plafond de SABnzbd a été presque gratuit mais n’a atteint qu’une partie de son empreinte. Le réglage de cache de rustnzb était décoratif sur le binaire couru, et Weaver n’a aucun réglage mémoire du tout, donc les deux ont tourné sans plafond comme colonnes de référence plutôt que d’être notés à un budget qu’ils ne peuvent pas tenir. Notre propre côté de cette manche est remplacé par l’échelle v1.2.2 ci-dessus, qui dit la même chose à 2,5x la taille : le budget n’est jamais la contrainte qui bloque, parce qu’une passe unique tient si peu pour commencer.

Espace libre · mesuré au mégaoctet près

Le peu d’espace libre dont une tâche a besoin

Un client qui écrit puis désarchive a besoin de place pour les volumes d’archive et la charge utile désarchivée en même temps, donc une tâche ne démarrera pas sans environ le double du téléchargement en libre. La passe unique a besoin de la charge utile - et cette manche a mesuré combien de plus, en rétrécissant le volume cible jusqu’à faire échouer chaque client. La réponse de nzbfast est une constante d’environ 50 MB de marge, pas un ratio, et elle tient d’une tâche de 6,5 GB à une de 34 GB.

Mesuré sur une machine Apple Silicon 20 cœurs, ligne 1 Gbit, cinq fournisseurs, trois répétitions à chaque borne, chaque manche terminée vérifiée octet par octet - les lignes rivales les 22-23 août 2026 (cellule 34 GB de Weaver reprise le 24 août, note 1), et la ligne nzbfast recoupée sur le binaire de release v1.2.2 le 24 août, qui a reproduit les deux bornes exactement, 12 manches sur 12 unanimes sur les deux scénarios. Nos cellules sont un plancher mesuré : la tâche se termine 3 fois sur 3 avec 48,6 MB et 51,0 MB de marge, et refuse 3 fois sur 3 environ 17 MB en dessous - donc le plancher est réel dans les deux sens. Ce que la tâche tient réellement se stabilise à la sortie plus environ 3 MB ; la marge paye pour les derniers instants du pipeline, jamais pour une deuxième copie. Les cellules des rivaux sont leur plancher mesuré sur la tâche de 6,5 GB et une suffisance confirmée au même ratio sur celle de 34 GB (3 fois sur 3 correctes octet par octet exactement à ce ratio) ; nous n’avons pas descendu leur échelle plus bas à la plus grande taille, donc leur vrai plancher là-bas peut se trouver un peu sous le ratio, et nous le disons plutôt que d’arrondir en notre propre faveur.

Ce à quoi ressemble vraiment la panne compte autant que le chiffre. À 17 MB sous son plancher nzbfast se heurte au refus d’écriture du disque, s’arrête proprement avec « espace disque insuffisant », garde journalisé tout ce qui est arrivé, et une reprise reprend sans retélécharger - un partiel que vous gardez, pas une tâche ratée. ¹ La cellule du grand scénario de Weaver a été tranchée par une reprise le 24 août : trois manches sur trois correctes octet par octet au même ~2,25x, chacune plus rapide que la bonne manche de la première tentative, sur un espace libre identique à l’octet près. Lors de la première tentative, le 23 août, deux de ses trois manches avaient calé à quelques MB/s avec plus de 60 GB encore libres et atteint le plafond de 40 minutes de la manche. Ces blocages ne sont pas revenus, et l’instrumentation de blocage du banc était déployée et silencieuse sur les trois manches de la reprise, ce qui est une mesure positive et non une mesure absente. Ce qui les a causés reste inconnu, et une reprise propre n’est pas un diagnostic : il existe maintenant six manches à ce ratio, quatre terminées, et les deux échecs viennent d’une seule fenêtre de 80 minutes la première nuit.

Publications emboîtées · mesuré le 28 août 2026

Dix façons d'emballer une publication, et qui atteint vraiment le fichier

Une grande partie de ce qui est publié est délibérément difficile à ouvrir. Le vrai nom de fichier est enfoui dans une deuxième archive, parfois une troisième, parfois dans un format différent à chaque niveau, afin que la publication révèle le moins possible de ce qu'elle contient. À cela s'ajoutent les publications endommagées : les articles expirent, les envois arrivent incomplets, et les données de récupération doivent être utilisées avant de pouvoir extraire quoi que ce soit. Un client parcourt cette chaîne pour vous, ou bien il vous remet un dossier d'archives et s'arrête.

Nous avons donc construit dix formes qui isolent exactement cela, confronté chaque client actuel à ces formes, puis fait ce que les comparatifs omettent habituellement : là où un client s'est arrêté trop tôt, nous avons terminé le travail à la main avec les outils standard et chronométré cela aussi. Un client qui abandonne vite paraît rapide jusqu'à ce que l'on compte le travail qu'il vous laisse.

nzbfast est le seul à terminer les dix sans aide. NZBGet atteint aussi le fichier sur chaque forme, mais il lui faut 16 séries de réparation et d'extraction manuelles sur huit d'entre elles. SABnzbd en termine cinq sans aide et deux restent inaccessibles même à la main. Weaver atteint le fichier sur deux.

Le schéma n'a rien d'aléatoire. Les formes que nzbfast parcourt et que les autres ne parcourent pas sont les formes emballées et les formes endommagées : une archive dans une archive, un changement de format en cours de chaîne, un enchaînement à cinq niveaux, et surtout une archive qui arrive corrompue avec ses propres données de récupération jointes. Sur cette dernière, quatre clients extraient parfaitement l'ensemble extérieur, vous remettent l'archive défectueuse accompagnée du jeu de récupération qui la réparerait, et s'arrêtent.

Là où les clients accomplissent le même travail, l'écart de coût est net. Voici les sept formes que les quatre clients principaux atteignent, réparation manuelle comprise :

Quatre à cinq fois plus rapide, pour moins de la moitié des octets écrits. Le chiffre du disque est celui qui compte encore après le téléchargement : chaque gigaoctet de cette colonne est un gigaoctet que votre disque a dû absorber, et les clients qui passent par une zone de transit écrivent la charge utile, la relisent et la réécrivent.

Là où nous ne sommes pas devant, et pourquoi il faut le dire. Sur quatre des dix formes, un concurrent écrit moins d'octets que nzbfast pendant le téléchargement lui-même. À chaque fois, c'est parce qu'il en a fait moins : sur la forme à archive interne corrompue, NZBGet écrit 3,29 GB contre nos 4,65, puis sa passe de réparation en écrit 2,91 de plus, pour finir à 6,20 GB contre nos 4,65. Sur les autres, le client qui a le moins écrit est un client qui n'a jamais atteint le fichier. Un petit chiffre de disque n'est pas toujours une économie.

Ce sont des tests de capacité, pas des tests de vitesse. Les charges utiles sont petites et servies depuis la mémoire sur une connexion locale, sans fournisseur ni réseau sur le trajet : rien ici n'est limité par le débit de téléchargement et les secondes absolues sont bien plus courtes que ce que les mêmes formes prendraient dans le monde réel. Le fait qu'une forme exige ou non un travail manuel est une propriété de la forme et du client, et se transpose directement. Les secondes comparent des clients effectuant un travail identique, elles ne prédisent pas la durée d'une vraie tâche.

Les résultats complets par forme, la description de chaque forme et la méthode se trouvent sur la page de données des archives emboîtées.

Pourquoi c’est important

Votre disque fait la moitié du travail

Le stockage flash s’use en étant écrit. Une release de 94 GB coûte à votre disque environ 90 GB d’écriture sous nzbfast ; sous un client qui met en scène puis désarchive, la même release coûte à peu près le double. Sur un NAS à disques durs, la forme en une passe supprime aussi la longue passe monofil à la fin de chaque téléchargement chiffré - une pause mesurée à 20 secondes sur une station de travail 32 cœurs rapide avec déverrouillage accéléré par matériel, et proportionnellement plus longue sur les machines à faible puissance sur lesquelles la plupart des gens font vraiment tourner ça. Nous citons le petit chiffre parce que c’est celui que nous avons mesuré.

Duels de composants

Les benchmarks plus techniques, pour qui aime plus de données

La réparation (PAR2) et le désarchivage (RAR) sont notre propre code natif plutôt que des binaires tiers embarqués, donc nous les faisons aussi courir de façon autonome contre les outils dédiés sur des corpus identiques, sur quatre machines couvrant ce qu’un lecteur pourrait vraiment posséder. Un temps ne compte que quand la sortie est identique octet pour octet à la charge utile source : chaque chiffre RAR ci-dessous a été vérifié en sha256 contre la source, et chaque fichier réparé contre le jeu intact.

Extraction RAR : 7 formes d’archive, 6 outils

La manche précédente de ce tableau utilisait 100 MB à 200 MB par forme, ce qui était une erreur : environ 28 ms de lancement de processus représentaient 40 % de la manche stockée, et le classement qui en résultait ne survit pas à une taille réaliste. Cette manche est 1 GB de charge utile par forme, et ça change plusieurs réponses, y compris certaines dans l’autre sens. Les archives sont créées par le rar officiel 7.23, donc aucun outil n’est jugé sur une entrée issue de son propre encodeur, et les mêmes octets sont mis en duel sur chaque machine.

Ce qu’il y a dans la charge utile compte plus qu’il n’y paraît. Une charge utile faite de copies de blocs fait de chaque forme compressée un benchmark de copie mémoire ; une charge utile de texte pur en fait un benchmark de littéraux et de Huffman ; nous avons mesuré les deux et elles ne s’accordent pas sur le vainqueur. Donc les quatre formes compressées utilisent des tiers égaux de texte, d’enregistrements structurés et d’octets incompressibles, et les deux formes aux extrémités de cette plage sont des manches séparées exprès : store est incompressible et repetitive est presque toute en correspondances. Le générateur et le harnais sont dans le dépôt, donc le corpus peut être reconstruit octet pour octet.

Recouru le 23 août 2026 sur le moteur 1.2.2, et le balayage tient. Les trois outils qu’un lecteur pèse le plus souvent - le nôtre, unrar 7.23 et rarpar 0.2.5 - ont été recourus sur le bureau 32 cœurs sur le moteur de release (le code d’extraction en duel est identique octet pour octet au tag 1.2.2), six manches entrelacées, minimum par outil, la sortie de chaque manche vérifiée contre le manifeste de charge utile. Secondes, plus bas est meilleur :

Les sept formes sont toutes à nous, sur le minimum et sur la médiane, 1,16x à 4,29x contre unrar. Ces temps ne sont pas comparables cellule par cellule avec le tableau plus large ci-dessous - le harnais a été révisé depuis les manches de ce tableau et les décomptes de manches diffèrent - donc lisez chaque tableau contre lui-même. Le tableau plus large garde ses propres dates et son champ à six outils, et sa colonne nzbfast décrit le moteur que livre la 1.2.2 : la reprise ci-dessus a mesuré le niveau du moteur actuel avec la version de ce tableau sur les sept formes, tranché par des comptages d’instructions matérielles (0,14 % de moins pour le même chronomètre), donc ces cellules ne sont pas les chiffres d’une version dépassée portant une étiquette actuelle. Cette reprise est aussi là où la règle A/A dans la section protocole a été gagnée. Un passage le même jour a d’abord rapporté une forme comme une petite régression contre notre propre version précédente, et la lecture a survécu à faire tourner les deux ordres de bras. Un contrôle A/A - le même binaire couru contre une copie identique octet pour octet de lui-même - a montré le harnais imposant à quel que soit le bras qui courait en premier une pénalité d’environ 1,5 % : le binaire identique n’a gagné que 6 des 15 manches depuis la première place, et inverser les ordres n’annule pas un biais qui retombe toujours sur celui qui est premier. Les comptages d’instructions matérielles ont tranché la question que le harnais ne pouvait pas trancher - la version plus récente retire 0,14 % moins d’instructions pour le même chronomètre, donc il n’y avait pas de régression. Chaque comparaison de notre version contre notre version que nous publions maintenant porte ce contrôle.

Tout le champ, secondes, plus bas est meilleur. Meilleur sur trois, outils entrelacés à l’intérieur de chaque manche plutôt que courus en blocs, sortie vérifiée contre la charge utile source à chaque run individuel. Un outil qui produit les mauvais octets reçoit une note de correction, jamais un temps rapide. rarpar est le propre code RAR et PAR2 de Weaver, compilé depuis les sources au commit bd87611 ; nous épinglons le commit plutôt qu’une version parce que ses crates portent trois numéros de version différents.

Où le champ n’a pas pu être en concurrence, et pourquoi. ¹ Le 7-Zip mis en duel ici est le paquet Homebrew, qui refuse chaque forme compressée avec ERROR: Unsupported Method et ne lit que la forme stockée sur macOS. Une version antérieure de cette page mettait ça sur le compte du binaire macOS de 7-Zip, ce qui était faux : Homebrew le compile sans le codec unRAR non libre, tandis que le binaire macOS que 7-zip.org livre porte le codec et décode les sept formes, comme le fait le binaire Windows. Remesuré le 14 août 2026. Si vous installez 7-Zip depuis le projet plutôt que depuis Homebrew, cette colonne ne décrit pas ce que vous avez. ² bsdtar n’a pas de support multi-volume RAR5 et a produit un fichier tronqué sans signaler d’erreur, donc cette manche est un échec de correction plutôt qu’un temps lent ; notre harnais l’a repéré en vérifiant la sortie, ce qui est pourquoi ça vaut la peine de vérifier la sortie. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar ne livre aucun outil en ligne de commande pour Windows, donc le champ du portable est à cinq. ⁶ Le groupe M5 Max met en duel les trois outils qu’un lecteur macOS choisirait vraiment - unrar, rarpar et nous ; unar, bsdtar et 7-Zip n’ont pas été mis en duel sur cette machine. Son unrar est la 7.22, la version la plus récente qui y tourne sans surveillance.

Chaque forme sur chaque machine sauf une, et celle-là est une égalité. Les formes à correspondances courtes se ramènent à deux choses précises dans notre décodeur. Une correspondance de deux à trente-deux octets payait autrefois pour un appel complet dans la routine de copie mémoire de la plateforme, et l’appel coûtait plus que la copie ; copier trente-deux octets fixes via un registre à la place est pourquoi repetitive, solid et le dictionnaire 128 MiB - les trois formes construites à partir de correspondances courtes - sont toutes rapides d’un coup. Et la somme de contrôle tourne en aval du fil de l’écrivain plutôt que dessus. La seule cellule que nous ne gagnons pas franchement est la forme stockée sur le bureau 32 cœurs, où unrar et nous sommes à trois millisecondes d’écart sur une manche qui ne fait que déplacer des octets - identiques à la précision de ce tableau, donc les deux cellules sont marquées et c’est noté une égalité, pas une perte et pas une victoire.

La forme où nous gagnons le plus est celle qu’Usenet publie réellement par centaines à la fois : 400 petits fichiers, 4,3× et 4,4× contre unrar et 5,4× à 5,5× contre rarpar. C’est du parallélisme par membre, et c’est la différence entre un extracteur écrit pour une file de téléchargement et un écrit pour une ligne de commande. La forme stockée, dont le recensement ci-dessus dit qu’elle représente 84 % des octets sur le fil, est une quasi-égalité pour les trois outils sérieux, parce qu’à ce stade tout le monde ne fait que déplacer des octets.

Un choix qui vaut la peine d’être déclaré. Les archives sont empaquetées avec le compresseur épinglé à quatre threads. La découpe en blocs de RAR suit sinon le nombre de cœurs de quelle que soit la machine qui a empaqueté l’archive, donc un bureau 32 cœurs et un bureau 20 cœurs produisent des octets différents à partir de la même entrée et les machines cessent d’être comparables. L’épingler rend le corpus d’extraction identique octet pour octet partout, ce qui est le but, mais ça plafonne aussi la part du décodage qui peut tourner en parallèle - donc quand les deux formes les plus proches étaient des pertes nous les avons recourues contre des archives empaquetées avec les 32 threads, pour vérifier que l’épinglage n’en était pas la cause. Ce n’était pas le cas : solid est passé de 4,2 % en retard à 2,4 % en retard et le dictionnaire 128 MiB de 6,6 % à 6,3 %, le même classement dans les deux cas. Les deux sont maintenant des victoires sur le corpus épinglé par une marge plus large que ce que cette vérification pourrait expliquer.

Pourquoi il n’y a pas de ligne RAR4, et ce qui arrive à ces posts. Chaque forme ci-dessus est RAR5 ou RAR7, ce qu’Usenet publie aujourd’hui. Les anciennes archives RAR4 apparaissent encore, et le même moteur les lit, formes compressées et protégées par mot de passe comprises, dans la même passe unique que les plus récentes plutôt qu’en écrivant les volumes sur disque puis en les désarchivant après. Elles n’ont pas de ligne ici parce que le rar officiel 7.23 ne peut plus créer de RAR4, donc il n’y a pas de corpus neutre sur lequel mettre le champ en duel ; ce travail est vérifié contre des archives écrites par WinRAR 3.00 à la place, octet pour octet contre unrar.

Vérification et réparation PAR2 : jeu de 1 GiB, quatre niveaux de dégâts

Corpus : 1 GiB de charge utile aléatoire empaquetée en mode stocké dans 21 volumes RAR, puis deux jeux PAR2 à 10 % de redondance, l’un en blocs de 1 MiB et l’un en 64 KiB, puis des cartes de dégâts fixes. Chaque run utilise le même protocole : copie fraîche, lecture du corpus entier une fois pour chauffer le cache, puis chronométrage. Meilleur sur trois manches entrelacées ; chaque volume réparé est comparé au jeu intact à chaque manche. Plus bas est meilleur.

Une correction à propos du corpus, parce qu’une version antérieure de cette page l’a surestimé. Nous disions que chaque machine faisait tourner un corpus identique octet pour octet, vérifié par hachage. Hacher chaque volume de chaque jeu montre que c’est vrai du bureau 32 cœurs et du portable Windows, qui correspondent exactement, et pas du bureau 20 cœurs, qui tient un tirage aléatoire différent de la même forme : les mêmes 21 volumes aux mêmes tailles, les deux mêmes tailles de bloc, et les dégâts vérifiés aux mêmes 3, 101 et 1 500 blocs répartis sur le même nombre de fichiers. Chaque chiffre à l’intérieur d’une ligne est encore mesuré sur des octets que chaque outil de cette ligne partage, ce sur quoi repose chaque comparaison. Mais les lignes ne sont pas quatre vues d’une seule entrée, et puisque le caractère de la charge utile vaut environ 7 % pour le balayage d’un concurrent, ça vaut la peine de l’énoncer plutôt que de l’enjoliver.

Quel par2 est lequel. Le par2cmdline original est l’implémentation de référence dont tout le monde a forké. par2cmdline-turbo est le fork qui embarque les noyaux SIMD de champ de Galois écrits à la main de ParPar : c’est précisément ce que « turbo » veut dire, et c’est pourquoi turbo, plutôt que l’original, est l’outil qui vaut la peine d’être mesuré. Les deux colonnes turbo ci-dessous font tourner ces mêmes noyaux ParPar. Ce qui les sépare, ce n’est pas l’arithmétique mais la compilation et les options.

Confirmé sur la version livrée contre le rival actuel, 24 août 2026. Ces tableaux ont été mesurés avant que la 1.2.2 ne soit taguée et avant que par2cmdline-turbo ne sorte en 1.5.0 (20 août 2026), donc la colonne 20 cœurs a été recourue sur les deux : notre binaire de release 1.2.2 contre turbo 1.5.0, trois manches entrelacées par manche, chaque fichier réparé comparé au jeu intact. Les quatre manches se reproduisent - les nôtres à 0,18 / 0,30 / 0,75 / 2,02 contre les 0,19 / 0,33 / 0,74 / 2,07 imprimés ici, et turbo 1.5.0 atterrit à quelques pour cent près de la version du tableau sur chaque manche et les deux configurations. Les cellules restent telles que publiées ; les trois autres machines gardent leurs propres dates.

Donc la concurrence apparaît deux fois, et l’une de ces colonnes est son meilleur cas plutôt que son défaut. Le binaire de release que vous téléchargeriez est compilé pour un processeur générique de base et ne hache que quelques fichiers à la fois ; compiler la même source pour le processeur hôte réel et passer -T16 lui permet d’utiliser les instructions que cette machine a vraiment et de hacher seize fichiers à la fois. Sur le portable ça vaut jusqu’à 2,6x, entièrement dû à la compilation et aux options. Jugez-nous sur la colonne réglée, qui est la comparaison la plus dure ; la colonne telle que livrée est ce que vit vraiment quelqu’un qui la télécharge. par2cmdline est l’original, version 1.2.0, compilé depuis les sources sur chaque machine. rarpar est la propre implémentation PAR2 de Weaver, compilée depuis les sources avec son backend GPU Metal activé. Le par2j de MultiPar est Windows uniquement, donc il apparaît seul sur les lignes du portable Windows. Les lignes M5 Max mettent en duel les deux outils avec des binaires macOS arm64 actuels à côté des deux colonnes turbo ; par2cmdline classique n’a pas été mis en duel sur cette machine.

Les seize cellules nzbfast - quatre machines à quatre niveaux de dégâts - sont toutes à nous, plusieurs par plus de 2× contre la version réglée et de 2,3× à 7,7× contre celle que vous téléchargeriez réellement. Les cellules à dégâts lourds sont les plus intéressantes, et la note ci-dessous explique l’algorithme derrière elles.

L’original est de retour dans le tableau, et ça vaut la peine de voir pourquoi le fork existe. Une version antérieure de cette page avait retiré la colonne par2cmdline au motif qu’elle était plus lente que tout le reste de la manche, ce qui est vrai et n’est pas une raison suffisante : c’est l’implémentation dont presque tous les autres outils descendent, et les lecteurs méritent la référence plutôt que notre affirmation à son sujet. Au niveau de dégâts le plus lourd elle prend environ 69 s là où le fork SIMD prend 3,2 s et nous prenons 3,1 s. Ce facteur de vingt est tout l’argument pour les noyaux de champ de Galois écrits à la main, et c’est le même argument que nous faisons pour les nôtres.

Les dégâts légers sont le cas qui compte. Une poignée d’articles en échec est bien plus typique que 101 blocs morts, et rien de comparable à 1 500. La majeure partie d’une réparation légère n’est pas du tout les maths de Reed-Solomon, c’est la lecture et le MD5 d’un gigaoctet, ce qui est pourquoi la ligne à 3 blocs suit la ligne de vérification propre plutôt que les lignes de réparation.

Le niveau de dégâts le plus lourd est un genre de travail différent, et il reçoit un algorithme différent. Ce dernier niveau endommage 1 500 blocs sur les 21 volumes et consomme environ 91 % des données de récupération, ce qui est là où l’arithmétique de Reed-Solomon, plutôt que le hachage ou le disque, devient presque tout le travail. Le binaire livré calcule les réparations les plus lourdes avec une transformée en nombres théoriques plutôt que le pli classique en champ de Galois - les mêmes maths, évaluées sous une forme qui passe bien mieux à l’échelle sur un grand nombre de blocs : 2,7× devant la version réglée sur le bureau 20 cœurs, et sur le portable Windows 2,7× devant la version réglée et 2,2× devant MultiPar. Les dégâts légers font encore tourner le chemin classique, ce qui est pourquoi les autres niveaux ont à peine bougé : la transformée ne paye qu’au-delà d’environ 512 blocs endommagés, donc en dessous le répartiteur ne l’utilise pas.

Un chemin plus rapide ne vaut la peine que s’il ne peut pas se tromper. Les deux chemins calculent la même quantité et sont identiques bit à bit par construction, et chaque réparation de cette page a été vérifiée par la correspondance des fichiers reconstruits avec le jeu intact : 228 réparations chronométrées sur les machines de cette manche, zéro divergence. Le binaire livré ne se repose pas sur ce relevé. Chaque réparation vérifie sa propre sortie contre les empreintes des fichiers, et une qui échouerait serait refaite avec le chemin classique automatiquement, journaliserait la divergence, et garderait le chemin classique pour le reste de ce run. Le réglage est dans le tableau de bord sous Mode PAR rapide si vous préférez ne pas l’avoir du tout, et les machines avec trop peu de mémoire pour ça le déclinent d’elles-mêmes plutôt que d’essayer et d’échouer. Remesuré le 2 août sur la version actuelle : les deux bureaux atterrissent à quelques pour cent de ce tableau, et avec le Mode PAR rapide coupé le bureau 20 cœurs retombe exactement au temps plus lent du chemin classique, ce qui dit que la victoire tient à la méthode et non aux conditions.

La colonne du portable Windows avait besoin d’une correction, et elle va contre nous. Windows relègue le travail de fond soutenu sur ses cœurs d’efficacité après quelques secondes. Notre démon s’en exclut au démarrage et aucun des autres outils ne le peut, donc une version antérieure de cette page publiait leurs temps bridés comme s’ils étaient les temps propres des outils. Relancer cette machine avec chaque outil élevé en priorité haute déplace tout le champ : au niveau de dégâts le plus lourd par2-turbo passe de 22,4 s à 6,41 et rarpar de 59,2 s à 14,4, et pour une coupe de cette page ça a transformé la colonne de la nôtre en une que nous perdions. Toute la colonne du portable est mesurée ainsi maintenant - la correction reste même si la ligne a depuis été regagnée par le changement d’algorithme ci-dessus, parce que les temps du champ sur cette machine ne sont honnêtes qu’avec la limitation levée.

Enregistrements de récupération RAR : réparer sans PAR2

Quand PAR2 ne peut pas couvrir les dégâts, l’enregistrement de récupération à l’intérieur du RAR lui-même est la dernière ligne de défense. Jusqu’à la 1.0.8 la nôtre échouait sur toute archive au-delà d’environ 13 MB, donc cette manche ne pouvait pas être courue du tout. Les dégâts sont trois trous de 3 000 octets à 20 %, 50 % et 80 % de la région protégée. Les deux outils ont produit une sortie identique octet pour octet au fichier intact, et la nôtre est identique octet pour octet à ce que rar r écrit lui-même. Meilleur sur trois, bureau 32 cœurs, les deux outils recourus ensemble le 2 août.

Une version antérieure de cette page montrait la taille 512 MB comme une perte, et l’expliquait comme le prix de traverser le volume par morceaux plutôt que de tout tenir en mémoire. Cette explication était correcte à l’époque et est maintenant obsolète : le coût était un CRC64 bit-série dans le chemin de réparation, remplacé par un tabulé, et la perte est partie avec. Il n’y a plus de croisement, et l’ensemble de travail borné a été gardé. La taille 2 GB est là parce que les volumes que rencontre vraiment un démon font 8 GB à 20 GB, pas 512 MB, et une manche qui s’arrête sous la plage réelle n’est pas un grand test.

Ce qui a bougé cette coupe, et le contrôle qui le dit. Trouver quels blocs sont endommagés était devenu la phase la plus grande de cette réparation - plus grande que l’arithmétique de réparation elle-même - et tournait sur un seul thread, lisant 64 KB de chaque groupe à travers le fichier, une fois par groupe. Ça fait maintenant une passe séquentielle unique dans l’ordre du fichier avec les sommes de contrôle par éclat calculées en parallèle, et le volume réparé est cloné plutôt que copié là où le système de fichiers peut le faire. La détection seule est tombée d’environ 300 ms à 18 ms sur l’archive 512 MB, ce qui est l’essentiel de ce qui a bougé ci-dessus. Le contrôle est la colonne à côté de la nôtre : rar r a été recouru dans les mêmes manches sur la même machine et est revenu à quelques pour cent de ses temps précédents, donc le changement dans l’écart est le nôtre et pas celui du banc.

Le M5 Max répète le motif, couru le 31 juillet avec le même corpus et les mêmes gardes : 0,050 / 0,066 / 0,171 / 0,581 s contre les 0,211 / 0,335 / 0,751 / 1,735 de rar r sur les tailles de 16 MB à 512 MB - 3,0× à 5,1× plus rapide ; la taille 2 GB n’a pas été mise en duel sur cette machine. Ces chiffres précèdent la refonte de détection décrite ci-dessus, donc ce sont ceux de la version plus ancienne, gardés ici comme la deuxième machine plutôt que comme un chiffre actuel.

Le rarpar de Weaver est absent de ce tableau seul, et pas par choix : il n’implémente pas cette réparation. Invité à réparer une de ces archives il répond « embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data », et laisse le fichier endommagé. Il apparaît dans chaque autre comparaison de cette page : les quatre manches PAR2 ci-dessus, les sept formes d’extraction avant ça, et la manche de volumes de récupération immédiatement ci-dessous, qui est le travail qu’il dit faire - et qu’il gagne.

Volumes de récupération : reconstruire des fichiers .rev entiers manquants

L’autre moitié de l’histoire de récupération propre à RAR, et jusqu’à cette manche la plus grosse perte de cette page. Un fichier .rev est un volume de récupération autonome : trois d’entre eux à côté d’un jeu de 21 volumes peuvent reconstruire trois volumes quelconques qui ne sont jamais arrivés. Corpus : 1 GiB stocké dans 21 volumes de 50 MB avec rar rv3, puis les volumes 4, 11 et 19 supprimés - trois perdus contre trois volumes de récupération, ce qui est le pire cas que le jeu puisse encore survivre. Meilleur sur trois, chaque volume reconstruit comparé au volume intact.

La cellule 32 cœurs ici était à 3,12 s contre les 0,47 de rar rc dans la coupe précédente de cette page, publiée comme 6,6× plus lente et le pire chiffre qui s’y trouvait. La cause était la résolution d’effacement tournant à environ 48 MB/s de sortie reconstruite là où celle de RARLab en tenait 320 ; elle tourne maintenant sur la même arithmétique tabulée que le reste du code de récupération, ce qui est une amélioration d’un facteur sept et transforme la perte en victoire sur les deux machines. Les marges sont de 3 % et 14 %, donc c’est une victoire à énoncer platement plutôt qu’à mettre en avant, et la raison pour laquelle elle est énoncée du tout est que la perte l’a été en premier.

Cette manche existe parce que le rarpar de Weaver implémente exactement ça et a demandé à être mesuré dessus. Il gagnait confortablement quand nous l’avons publié pour la première fois, et nous l’avons publié à l’époque pour cette raison.

La correspondance de fichiers n’a jamais été le coût, ce qui vaut la peine d’être noté parce que c’était le suspect intuitif : les volumes de récupération ne portent aucun nom de fichier, donc nous identifions quels emplacements ont survécu en calculant la somme de contrôle de chaque volume sur disque plutôt qu’en faisant confiance à leur nom, et contre un jeu intact, où la correspondance est tout ce qui se passe, la passe entière prend 0,18 s.

Ce qui a bougé d’autre, et où ça ne se voit pas. Deux autres changements de moteur ont atterri que ces corpus ne peuvent pas voir, listés ici pour que les chiffres ci-dessus ne soient pas lus comme toute l’histoire : les archives RAR5 comptant des dizaines de milliers de membres résolvent chaque membre une fois plutôt que de parcourir la liste par worker, ce qui est 3× moins de temps processeur à 40 000 membres ; et le lecteur de bits RAR1.3 travaille un mot à la fois, ce qui est 2×. Aucun n’apparaît ci-dessus, parce que les formes ici ont 400 membres et pas de RAR1.3.

Ce que nous ne faisons délibérément pas : nous ne créons jamais de PAR2. Un téléchargeur n’a aucune raison de le faire, et ParPar possède cette manche. Nous achetons aussi de la vitesse avec de la mémoire sur les deux moteurs : l’extraction culmine autour de 240 MB contre les 41 MB d’unrar, et la vérification autour de 126 MB contre les 7 MB de turbo, parce que ce sont les moteurs en ligne qui accompagnent un téléchargement en direct plutôt que des exécutions autonomes ponctuelles. La forme à dictionnaire de 128 MiB est le pire cas, à environ 304 MB contre les 139 MB d’unrar. La réparation la plus lourde coûte maintenant de la mémoire aussi : la méthode plus rapide pour 512 blocs manquants et plus travaille depuis les données de récupération tenues en résidence, donc elle est autorisée jusqu’à un quart de la RAM de la machine, plafonnée à 4 GB, et une machine qui ne peut pas se le permettre prend tranquillement la méthode basse mémoire à la place - la même arithmétique et les mêmes temps que les lignes du milieu du tableau PAR2, juste pas le 3× de la dernière. Si vous voulez la plus petite empreinte résidente possible pour une tâche autonome, les outils dédiés gagnent encore cette colonne.

Preuve de transport · mesuré sur la 1.2.2

Le moteur suit le rythme des lignes réelles

• ~8,7 Gbps soutenus à travers une flotte de cinq fournisseurs sur une ligne 10 GbE, vérification et extraction en flux comprises - la manche des 87 GB ci-dessus, le 24 août 2026, v1.2.2, 360 connexions : 77,4 GB sur le fil en 71 s avec la charge utile vérifiée et extraite à mesure de son arrivée. Pas un chiffre de rafale : toute la tâche à ce débit.
• À 1 Gbit et en dessous, la ligne est la limite et nzbfast s’y tient : ~96 % d’une ligne 500 Mbit et ~96 % d’une ligne 250 Mbit à travers la vérification et l’extraction, pour une fraction de la mémoire et du disque de chaque rival - la section sous le gigabit ci-dessus.
• Le coût processeur de toute la tâche sur la tâche de 87 GB est 1,7 seconde processeur par GB avec le régulateur de connexions actif - téléchargement sur TLS, vérification, disponibilité de réparation et extraction compris - contre 3,0 à 28 pour le champ dans la même manche ; le bras à plein débit ci-dessus en dépense 4,3.

Des coupes antérieures de cette page portaient un ensemble plus large de démonstrations de transport - runs de saturation multi-ligne, gains de pipelining par RTT, une preuve de contre-pression, des mesures de plafond de décodage - courues sur des versions que la v1.2.2 a depuis dépassées. Sous la règle de cette page elles sont retirées plutôt que laissées à vieillir, et reviennent à mesure qu’elles sont recoupées sur la release actuelle ; les trois affirmations ci-dessus sont celles déjà remesurées sur v1.2.2.