Benchmarks

La versión corta · medido el 23 de agosto de 2026 en la línea de código que se publicó como nzbfast 1.2.2

Ningún cliente medido es más barato en procesador, memoria y disco a la vez

Las rondas más recientes de esta página corrieron el 23 y el 24 de agosto de 2026 - la más reciente de ellas sobre la propia versión publicada v1.2.2 - frente a las versiones actuales de otros cuatro clientes, en el mismo hardware, las mismas líneas y los mismos proveedores: dos formas de trabajo de 6,5 a 87 GB, y velocidades de línea de 250 Mbit a 10 GbE. En esas rondas, ningún cliente resultó más barato que nzbfast en procesador, memoria y disco a la vez: cada uno cuesta más en al menos dos de los tres, lo máximo que cualquiera de ellos ahorró en un solo eje fue de aproximadamente un 2 por ciento - un empate estadístico, dentro de la propia dispersión de ese cliente entre ejecuciones - y en disco todos ellos movieron al menos el doble de bytes para un resultado idéntico byte a byte. De fábrica, nzbfast también fue el que menos memoria ocupó de todos los clientes medidos, en todos los escenarios, por un margen de 2,0x a 4,5x sobre el rival más cercano.

¿Cuál eres tú?

La mayoría de los descargadores escriben tu descarga en el disco al menos dos veces: una mientras la descargan, y otra mientras la descomprimen. nzbfast hace todo el trabajo en una sola pasada, así que escribe aproximadamente la mitad de los bytes por trabajo, ocupa menos memoria mientras trabaja, y gasta menos segundos de procesador por GB. Eso es menos carga en la máquina mientras la usas y la mitad de las escrituras por trabajo en tus discos, para los mismos archivos idénticos byte a byte - y como cada byte cruza el disco aproximadamente una vez, tu disco solo tiene que seguir el ritmo de tu línea una vez.

nzbfast no gana todas las tablas de esta página, y las que pierde están bajo los tramos que no ganamos - incluido uno de esta misma ronda. Lo que se mantuvo en todas las rondas que medimos es la factura combinada.

Primero la metodología

El montaje

• Clientes: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, cada tabla en las versiones que nombra. Las rondas más recientes (23 de agosto de 2026) enfrentaron las versiones entonces vigentes del campo - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 y Weaver 0.7.8, su binario publicado más reciente, con la identidad probada por hash - contra la línea de código que se publicó esa misma noche como nzbfast 1.2.2, así que la versión que produjo las cifras nuevas es la que puedes descargar. Esas rondas corrieron en una máquina Apple Silicon de 20 núcleos con una línea de 1 Gbit. Las tablas más antiguas conservan las versiones y las máquinas con las que corrieron (máquinas Apple de la serie M: M1 Ultra «Europa» a 10 GbE, M3 Ultra «costa este» con línea de ~2,4-3,0 Gbps) y así se indica; subestiman la versión publicada en lugar de favorecerla.
• Equidad: los mismos proveedores y el mismo TLS en todas partes para cada cliente, tramos ejecutados espalda con espalda e intercalados. Cada competidor ajustado a su mejor configuración documentada: a SABnzbd se le puso pipelining_requests=8 (de fábrica trae 1, es decir, sin pipelining, y el ajuste vale porcentajes de dos dígitos en trabajos grandes), a NZBGet se le puso ArticleCache/DirectWrite/DirectUnpack/ParQuick, a rustnzb su configuración documentada. Desde el 20 de agosto de 2026 cada ronda enfrenta cinco proveedores en lugar de seis - el número de proveedores no es una palanca de rendimiento en estas máquinas, donde un solo proveedor ya puede alcanzar el techo de la línea, y un conjunto fijo mantiene las rondas comparables - así que una cifra con seis proveedores en esta página no es directamente comparable con una más nueva de cinco proveedores, y cada tabla indica cuál corrió.
• Estado final: un archivo verificado, extraído y usable, no «descarga terminada». Eso es lo que en realidad esperas.
• Reproducibilidad: cada afirmación está fechada y medida de la misma manera: tiempo transcurrido + contadores de bytes de la interfaz + RSS máximo del árbol de procesos, con una resolución de 1-2 s. Cuando un tramo corre sobre un NZB publicado públicamente, lo nombramos para que puedas ejecutarlo tú mismo.
• Notas de método válidas para toda la página: el tiempo de CPU se muestrea del árbol de procesos a 2 Hz en cada brazo de una tabla y nunca se coloca junto a una cifra de una contabilidad distinta, porque los dos métodos discrepan por diseño. La E/S de disco se da en GiB y los bytes de cable en GB decimales; convertimos antes de dividir. Y cualquier tabla que enfrenta nuestra propia versión contra nuestra propia versión lleva un control A/A - el mismo binario enfrentado contra una copia idéntica byte a byte de sí mismo, a través del mismo arnés - porque ese control es cómo detectamos que nuestro propio arnés de comparación le daba una penalización de ~1,5% a la herramienta que corriera primero (la historia está junto a las tablas de extracción más abajo). Dos brazos con los órdenes intercambiados no cancelan un sesgo que siempre recae en el primer brazo; un control A/A lo expone.

Líneas más lentas · medido el 24 de agosto de 2026 en nzbfast 1.2.2

Cuanto más lenta la línea, menos separa la velocidad a los clientes - y más lo hace la factura

Con una línea suficientemente lenta, el tiempo de finalización de cada cliente es el cable y nada más, así que una línea lenta esconde muchos pecados. Lo que no puede esconder es lo que cada cliente quema para llenarla. Configuramos el banco de 1 Gbit a dos velocidades que corresponden a planes reales y enfrentamos los seis brazos en cada una - la misma máquina, los mismos cinco proveedores, tres repeticiones por cliente con el orden rotado, cada tramo verificado byte a byte, 36 de 36 correctos en las dos rondas. El brazo de nzbfast a 500 Mbit es la propia versión publicada v1.2.2.

Lee las dos tablas como un gradiente. A 250 Mbit todo el campo cae dentro de un 18% en el reloj y le llevamos al rival más cercano una ventaja del 4,4%; a 500 Mbit la brecha se abre al 14,7%; a las velocidades de gigabit y 10 GbE de las tablas de arriba y abajo se abre todavía más. Las diferencias de velocidad crecen con la línea. Las columnas de recursos no esperan a una línea rápida: a cada velocidad medida, cada rival ocupó al menos 3,9x la memoria, gastó más procesador, y movió aproximadamente el doble de bytes de disco para el mismo archivo idéntico byte a byte.

El gobernador de conexiones se gana el sustento en líneas lentas, y el propio contador de descartes del conformador dice por qué. La configuración de fábrica mantuvo 25 conexiones donde cada rival corrió cientos; el mismo binario con el gobernador desactivado corrió con 360. Menos flujos por una cola fija significa menos pérdida y menos reenvío: el conformador registró unos 4.200 descartes por tramo con tope frente a unos 155.000 sin tope a 500 Mbit, y el brazo con tope fue más rápido, 4,2x más ligero en memoria y 1,3x más ligero en CPU que nuestra propia postura de 360 sockets. Más conexiones no es más velocidad; por debajo de un gigabit es mediblemente lo contrario.

Medido el 24 de agosto de 2026, medianas de tres, en una máquina Apple Silicon de 20 núcleos con su línea conformada a cada velocidad (la velocidad conformada verificada por una sonda independiente antes de cada ronda: 248 y 496 Mbit). El brazo de nzbfast a 500 Mbit es la versión de la etiqueta de publicación v1.2.2; la ronda de 250 Mbit corrió horas antes sobre la misma línea de código. Los recuentos de bytes en una línea conformada se leen del propio contador de cada cliente, nunca de la interfaz de red (el conformador descarta y TCP reenvía, así que la interfaz cuenta las dos copias). Los tiempos totales son comparables dentro de cada tabla, no entre rondas conformadas de forma distinta. ¹ Los tres tramos de NZBGet a 500 Mbit fueron de 114 a 158 s con lecturas de recursos planas - una dispersión genuina, así que se cita la mediana y se declara la dispersión en vez de acotarla.

La publicación dañada · vuelta a correr el 24 de agosto de 2026, todas las versiones actuales

Cuando la publicación tiene agujeros: 6,5 GB con 60, 20 y 5 artículos muertos

Los artículos expiran, los servidores los descartan en silencio, las subidas llegan incompletas - y el daño es donde la brecha entre clientes es más ancha, así que consigue su propia ronda con la versión más reciente de cada cliente, nzbfast v1.2.2 incluido: máquina «Europa» de 10 GbE, cinco proveedores, 100 conexiones por cliente, el mismo lanzamiento de 6,5 GB envenenado en tres niveles de daño, tres repeticiones por brazo con el orden alternado, cada tramo verificado byte a byte contra el archivo limpio. 63 de 65 tramos volvieron idénticos byte a byte; los dos que no lo hicieron se nombran más abajo, porque son resultados.

Por qué la publicación dañada es rápida aquí. Cuando falta un artículo, un cliente normalmente pregunta al siguiente servidor, y luego al siguiente, hasta que todos los servidores lo han rechazado - un recorrido en serie cuyos rechazos tardan entre decenas de milisegundos y un par de segundos cada uno, durante los cuales la descarga se queda en cero. nzbfast deja de preguntar: en cuanto los datos de paridad que ya tiene en la mano cubren lo que todavía falta, repara de inmediato en vez de terminar el recorrido. Esa es la segunda fila - el mismo binario con ese comportamiento desactivado es de 1,4x a 2,3x más lento según el daño - y la ronda verificó que el mecanismo se activó en cada tramo habilitado y nunca en uno deshabilitado. Contra el rival más cercano el margen es de 2,4x a 2,7x, sin solapamiento en ninguno de los nueve pares de repeticiones.

El disco es donde el margen es más ancho, y no es por el truco de reparación. Cada brazo que terminó produjo el mismo archivo de 6,48 GB; el nuestro movió 6,2-6,8 GB de E/S de disco haciéndolo, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB y rustnzb 12,8-13,1 GB. Eso es la tubería de una pasada - la fila desactivada mueve los mismos 6,2 GB - así que se mantiene tanto en publicaciones dañadas como en publicaciones sanas.

¹ Los tres tramos de SABnzbd con el daño más pesado fueron 43, 41 y 60 s - una dispersión genuina sobre entradas idénticas, así que se cita la media con el rango declarado. ² rustnzb 1.4.5 entregó cada tramo correcto byte a byte, y su coste está en tiempo de procesador y no en fiabilidad: unos 1.620 segundos de CPU frente a un reloj de 107 s con el daño más pesado - unos quince núcleos ocupados durante todo el tramo - donde la misma salida reparada nos cuesta a nosotros unos 50 segundos de CPU. ³ Weaver movió 1,5 GB y 4,9 GB de los 6,5 dentro de nuestro límite de 20 minutos en los dos niveles de daño más pesados - el mismo no-terminar en las tres rondas que lo han enfrentado, en tres noches distintas; el límite es nuestro y el no-terminar es el resultado. Con 5 artículos muertos completó correctamente las tres veces. Su coste de procesador ahí es su propia historia: unos 2.325 segundos de CPU para el tramo de 194 s, frente a nuestros 20.

Medido el 24 de agosto de 2026, todas las versiones actuales: nzbfast v1.2.2 (la propia etiqueta de publicación), NZBGet 26.3-testing (versión del 20 de agosto), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. Un brazo de continuidad enfrentó la versión de nzbfast de la noche anterior dentro de esta misma ronda y quedó a menos de un segundo de v1.2.2 en cada escenario, así que nada aquí depende de una noche con suerte; y las configuraciones de los rivales difieren de las de la ronda anterior solo en la ruta de la aplicación, comprobada clave por clave antes de que corriera la ronda.

Hazlo pasar hambre de RAM · medido el 24 de agosto de 2026 en nzbfast 1.2.2

La escalera de baja memoria: 87 GB en ~0,3 GB de RAM

El mismo trabajo de 87 GB de la ronda de arriba, vuelto a correr con presupuestos de memoria fijos de 2 GB, 1 GB y 256 MB - lo que el autoajuste elegiría en una máquina de 8 GB, una de 4 GB, y un NAS de 2 GB. Cada tramo produjo el archivo idéntico verificado byte a byte, y la columna de memoria siguió al presupuesto, nunca al trabajo:

Un solo tramo por presupuesto sobre la versión publicada, comprobado contra la misma suma de comprobación de salida que la ronda de seis brazos. El presupuesto más ajustado cuesta alrededor de un 9% del tiempo total, y solo porque esta línea es 10 GbE - los bloques volcados a disco cuestan tiempo solo cuando la línea supera al disco, así que en una conexión doméstica típica un presupuesto pequeño sale casi gratis. Toda la escalera, descarga de 87 GB incluida, cabe en 0,3-0,6 GB de memoria; con la configuración de fábrica el trabajo corrió en 286 MB. Ningún otro cliente ofrece un presupuesto de memoria fijo para todo el proceso; lo más parecido son los ajustes de tamaño de caché, y la ronda de abajo mide lo que esos cuestan.

El tope enfrentado contra los propios ajustes del campo. En el escenario de 34 GB (23 de agosto de 2026, máquina de 1 Gbit, cinco proveedores, 30 de 30 tramos correctos byte a byte), imponerle a NZBGet un tope de caché equivalente más que dupli su CPU (de 215,5 a 453,0 segundos de CPU, 2,10x) para comprar un recorte del 52% en su memoria máxima, y el tope de SABnzbd fue casi gratis pero solo alcanzó parte de su huella. El ajuste de caché de rustnzb era decorativo en la versión enfrentada, y Weaver no tiene ningún ajuste de memoria, así que los dos corrieron sin tope como columnas de referencia en vez de puntuarse con un presupuesto que no pueden sostener. Nuestro propio lado de esa ronda queda superado por la escalera de v1.2.2 de arriba, que dice lo mismo a 2,5x el tamaño: el presupuesto nunca es la restricción vinculante, porque una pasada ya ocupa muy poco de entrada.

Espacio libre · medido al megabyte

Cuán poco espacio libre necesita un trabajo

Un cliente de escritura-y-luego-extracción necesita espacio para los volúmenes del archivo y para la carga útil descomprimida a la vez, así que un trabajo no arrancará sin tener libre aproximadamente el doble de la descarga. Una pasada solo necesita la carga útil - y esta ronda midió cuánto más, encogiendo el volumen de destino hasta que cada cliente fallaba. La respuesta de nzbfast es una constante de unos 50 MB de margen, no una proporción, y se mantiene desde un trabajo de 6,5 GB hasta uno de 34 GB.

Medido en una máquina Apple Silicon de 20 núcleos, línea de 1 Gbit, cinco proveedores, tres repeticiones en cada límite, cada tramo completado verificado byte a byte - las filas de los rivales del 22-23 de agosto de 2026 (celda de 34 GB de Weaver repetida el 24 de agosto, nota 1), y la fila de nzbfast vuelta a cortar sobre la v1.2.2 el 24 de agosto, que reprodujo los dos límites con exactitud, 12 de 12 tramos unánimes en los dos escenarios. Nuestras celdas son un mínimo medido: el trabajo se completa 3 de 3 con 48,6 MB y 51,0 MB de margen, y se niega 3 de 3 unos 17 MB por debajo de eso - así que el mínimo es real en las dos direcciones. Lo que el trabajo realmente ocupa se asienta en la salida más unos 3 MB; el margen paga los últimos momentos de la tubería, nunca una segunda copia. Las celdas de los rivales son su mínimo medido en el trabajo de 6,5 GB y una suficiencia confirmada con la misma proporción en el de 34 GB (3 de 3 correctos byte a byte exactamente con esa proporción); no bajamos más su escalera en el tamaño mayor, así que su verdadero mínimo ahí puede estar algo por debajo de la proporción, y lo decimos así en vez de redondear a nuestro favor.

Lo que se ve al quedarse sin espacio importa tanto como el número. A 17 MB por debajo de su mínimo, nzbfast choca con el rechazo del disco al escribir, se detiene limpiamente con «sin espacio en disco», mantiene registrado todo lo que ya había llegado, y un reintento retoma sin volver a descargar - un parcial que conservas, no un trabajo fallido. ¹ La celda del escenario grande de Weaver quedó resuelta por una repetición el 24 de agosto: tres de tres tramos correctos byte a byte con el mismo ~2,25x, cada uno más rápido que el tramo bueno del primer intento, con el espacio libre idéntico hasta el byte. En el primer intento, el 23 de agosto, dos de sus tres tramos se habían atascado a velocidades de un solo dígito en MB/s con más de 60 GB todavía libres y chocaron con el límite de 40 minutos de la ronda. Esos atascos no volvieron, y la instrumentación de atascos del banco estuvo desplegada y en silencio en los tres tramos de la repetición, lo que es una medida positiva y no una ausencia de medida. Qué los causó sigue sin saberse, y una repetición limpia no es un diagnóstico: ahora hay seis tramos con esa proporción, cuatro completados, y los dos fallos vienen de una sola ventana de 80 minutos la primera noche.

Publicaciones anidadas · medido el 28 de agosto de 2026

Diez formas de empaquetar una publicación, y quién llega de verdad al archivo

Buena parte de lo que se publica es deliberadamente difícil de abrir. El nombre real del archivo queda enterrado dentro de un segundo contenedor, a veces un tercero, a veces en un formato distinto en cada nivel, para que la publicación revele lo menos posible sobre lo que contiene. A eso se suma que las publicaciones llegan dañadas: los artículos caducan, las subidas llegan incompletas y hay que usar los datos de recuperación antes de poder extraer nada. Un cliente recorre esa cadena por usted, o le entrega una carpeta de archivos y se detiene.

Así que construimos diez formas que aíslan exactamente eso, enfrentamos a cada cliente actual con ellas y luego hicimos lo que las comparativas suelen omitir: donde un cliente se detuvo antes de tiempo, terminamos el trabajo a mano con las herramientas estándar y lo cronometramos también. Un cliente que se rinde rápido parece veloz hasta que se cuenta el trabajo que le deja a usted.

nzbfast es el único que termina las diez sin ayuda. NZBGet también llega al archivo en todas las formas, pero necesita 16 rondas de reparación y extracción manuales en ocho de ellas. SABnzbd termina cinco sin ayuda y dos resultan inalcanzables incluso a mano. Weaver llega al archivo en dos.

El patrón no es casual. Las formas que nzbfast recorre y las demás no son las empaquetadas y las dañadas: un contenedor dentro de otro, un cambio de formato a mitad de camino, una cadena de cinco niveles y, sobre todo, un contenedor que llega corrupto con sus propios datos de recuperación al lado. En esta última, cuatro clientes extraen el conjunto exterior perfectamente, le entregan el contenedor defectuoso junto con el conjunto de recuperación que lo arreglaría, y se detienen.

Donde los clientes realizan el mismo trabajo, la diferencia no es pequeña. Estas son las siete formas que alcanzan los cuatro clientes principales, contando la reparación manual que necesitó cada uno:

De cuatro a cinco veces más rápido, con menos de la mitad de los bytes escritos. La cifra de disco es la que sigue importando después de la descarga: cada gigabyte de esa columna es un gigabyte que su unidad tuvo que absorber, y los clientes que usan una zona intermedia escriben el contenido, lo vuelven a leer y lo escriben otra vez.

Dónde no vamos por delante, y por qué conviene decirlo. En cuatro de las diez formas un competidor escribe menos bytes que nzbfast durante la propia descarga. En todos los casos es porque hizo menos: en la forma con contenedor interno corrupto, NZBGet escribe 3,29 GB frente a nuestros 4,65, y luego su pasada de reparación escribe otros 2,91, terminando en 6,20 GB frente a nuestros 4,65. En las demás, el cliente que menos escribió es uno que nunca llegó al archivo. Una cifra baja de disco no siempre es ahorro.

Estas son pruebas de capacidad, no de velocidad. Los contenidos son pequeños y se sirven desde memoria por una conexión local, sin proveedor ni red por medio, así que nada aquí está limitado por la velocidad de descarga y los segundos absolutos son mucho más cortos de lo que esas mismas formas tardarían en el mundo real. Que una forma requiera o no trabajo manual es una propiedad de la forma y del cliente, y se traslada directamente. Los segundos comparan clientes haciendo un trabajo idéntico, no predicen cuánto durará una tarea real.

Los resultados completos por forma, qué es cada forma y el método están en la página de datos de archivos anidados.

Por qué importa

Tu disco hace la mitad del trabajo

El almacenamiento flash se desgasta por escribir en él. Un lanzamiento de 94 GB le cuesta a tu disco unos 90 GB de escritura con nzbfast; con un cliente que hace dos pasadas y descomprime, el mismo lanzamiento cuesta aproximadamente el doble. En un NAS con discos duros, la forma de una pasada también elimina la larga pasada de un solo hilo al final de cada descarga cifrada - una pausa medida en 20 segundos en una estación de trabajo rápida de 32 núcleos con desbloqueo acelerado por hardware, y correspondientemente más larga en las máquinas de bajo consumo donde la mayoría de la gente realmente ejecuta esto. Citamos el número pequeño porque es el que medimos.

Comparativas de componentes

Los benchmarks más técnicos, para quien quiere más datos

Reparar (PAR2) y descomprimir (RAR) son código nativo nuestro, no binarios de terceros empaquetados, así que también los enfrentamos por separado contra las herramientas dedicadas sobre corpus idénticos, en cuatro máquinas que abarcan lo que un lector podría realmente tener. Un tiempo solo cuenta cuando la salida es idéntica byte a byte a la carga útil de origen: cada cifra de RAR de más abajo se comprobó con sha256 contra el origen, y cada archivo reparado contra el conjunto prístino.

Extracción de RAR: 7 formas de archivo, 6 herramientas

La ronda anterior de esta tabla usaba entre 100 MB y 200 MB por forma, lo cual fue un error: unos 28 ms de arranque de proceso eran el 40% del tramo «store», y el orden que producía no sobrevive a un tamaño realista. Esta ronda es 1 GB de carga útil por forma, y cambia varias respuestas, incluidas algunas en el sentido contrario. Los archivos se crean con el rar 7.23 oficial, así que ninguna herramienta se juzga con una entrada de su propio codificador, y los mismos bytes se enfrentan en cada máquina.

Lo que hay dentro de la carga útil importa más de lo que parece. Una carga útil hecha de copias de bloques convierte cada forma comprimida en un benchmark de copia de memoria; una carga útil de texto puro la convierte en un benchmark de literales y Huffman; medimos las dos y no coinciden en quién gana. Así que las cuatro formas comprimidas usan tercios iguales de texto, registros estructurados y bytes incompresibles, y las dos formas en los extremos de ese rango son tramos separados a propósito: store es incompresible y repetitive es casi todo coincidencias. El generador y el arnés están en el repositorio, así que el corpus se puede reconstruir byte por byte.

Vuelto a correr el 23 de agosto de 2026 sobre el motor 1.2.2, y el barrido se mantiene. Las tres herramientas que un lector más suele sopesar - la nuestra, unrar 7.23 y rarpar 0.2.5 - se volvieron a enfrentar en el escritorio de 32 núcleos sobre el motor publicado (el código de extracción enfrentado es idéntico byte a byte a la etiqueta 1.2.2), seis rondas intercaladas, el mínimo por herramienta, la salida de cada tramo comprobada contra el manifiesto de la carga útil. Segundos, menos es mejor:

Las siete formas nuestras, en el mínimo y en la mediana, de 1,16x a 4,29x contra unrar. Estos tiempos no son comparables celda por celda con la tabla más amplia de abajo - el arnés se ha revisado desde las rondas de esa tabla y los recuentos de rondas difieren - así que lee cada tabla contra sí misma. La tabla más amplia conserva sus propias fechas y su campo de seis herramientas, y su columna de nzbfast describe el motor que trae la 1.2.2: la vuelta a correr de arriba midió el nivel de motor actual con la versión de esa tabla en las siete formas, resuelto por conteo de instrucciones de hardware (0,14% menos para el mismo tiempo total), así que esas celdas no son las cifras de una versión superada llevando una etiqueta actual. Esta vuelta a correr es también donde se ganó la regla A/A de la sección de montaje. Un pase el mismo día primero reportó una forma como una pequeña regresión contra nuestra propia versión anterior, y la lectura sobrevivió a correr los dos órdenes de brazo. Un control A/A - el mismo binario enfrentado contra una copia idéntica byte a byte de sí mismo - mostró que el arnés le daba al brazo que corriera primero una penalización de aproximadamente 1,5%: el binario idéntico ganó solo 6 de 15 rondas desde la primera posición, y intercambiar los órdenes no cancela un sesgo que siempre recae en quien va primero. El conteo de instrucciones de hardware resolvió la pregunta que el arnés no pudo - la versión más nueva retira un 0,14% menos de instrucciones para el mismo reloj, así que no había ninguna regresión. Cada comparación de nuestra-versión-contra-nuestra-versión que publicamos ahora lleva ese control.

Todo el campo, segundos, menos es mejor. Mejor de tres, herramientas intercaladas dentro de cada ronda en vez de corridas en bloques, salida comprobada contra la carga útil de origen en cada ejecución. Una herramienta que produjo bytes incorrectos se lleva una nota de corrección, nunca un tiempo rápido. rarpar es el propio código RAR y PAR2 de Weaver, compilado desde el código fuente en bd87611; fijamos el commit en vez de una versión porque sus crates llevan tres números de versión distintos.

Dónde no pudo competir el campo, y por qué. ¹ El 7-Zip enfrentado aquí es el paquete de Homebrew, que rechaza cada forma comprimida con ERROR: Unsupported Method y solo lee la almacenada en macOS. Una versión anterior de esta página lo achacó a la compilación de 7-Zip para macOS, lo cual era incorrecto: Homebrew lo compila sin el códec unRAR no libre, mientras que la compilación para macOS que distribuye 7-zip.org sí lleva el códec y decodifica las siete formas, igual que la compilación para Windows. Vuelto a medir el 14 de agosto de 2026. Si instalas 7-Zip desde el proyecto en vez de desde Homebrew, esta columna no describe lo que tienes. ² bsdtar no admite RAR5 multivolumen y produjo un archivo truncado sin reportar ningún error, así que ese tramo es un fallo de corrección y no un tiempo lento; nuestro arnés lo detectó comprobando la salida, que es justo por lo que vale la pena comprobar la salida. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar no distribuye ninguna herramienta de línea de comandos para Windows, así que el campo del portátil es de cinco. ⁶ El grupo M5 Max enfrenta las tres herramientas a las que realmente recurriría un lector de macOS - unrar, rarpar y la nuestra; unar, bsdtar y 7-Zip no se enfrentaron en esa máquina. Su unrar es el 7.22, la versión más reciente que corre ahí sin supervisión.

Todas las formas en todas las máquinas menos una, y esa es un empate. Las formas de coincidencias cortas se reducen a dos cosas concretas de nuestro decodificador. Una coincidencia de dos a treinta y dos bytes solía pagar una llamada completa a la rutina de copia de memoria de la plataforma, y la llamada costaba más que la copia; copiar en su lugar treinta y dos bytes fijos a través de un registro es por qué repetitive, solid y el diccionario de 128 MiB - las tres formas construidas con coincidencias cortas - son todas rápidas a la vez. Y la suma de comprobación corre aguas abajo del hilo del escritor en vez de sobre él. La única celda que no ganamos claramente es la forma «store» en el escritorio de 32 núcleos, donde unrar y nosotros estamos a tres milisegundos de distancia en un tramo que es puramente mover bytes - idéntico a la precisión de esta tabla, así que las dos celdas están marcadas y se puntúa como empate, ni pérdida ni victoria.

La forma en la que ganamos por más margen es la que usenet realmente publica a cientos a la vez: 400 archivos pequeños, 4,3× y 4,4× contra unrar y de 5,4× a 5,5× contra rarpar. Eso es paralelismo por miembro, y es la diferencia entre un extractor escrito para una cola de descargas y uno escrito para una línea de comandos. La forma «store», que el censo de arriba dice que es el 84% de los bytes que van por el cable, es un empate casi perfecto para las tres herramientas serias, porque a ese punto todo el mundo simplemente mueve bytes.

Una decisión que vale la pena declarar. Los archivos se empaquetan con el compresor fijado a cuatro hilos. La división en bloques de RAR, si no, sigue el número de núcleos de la máquina que empaquetó el archivo, así que una máquina de 32 núcleos y una de 20 núcleos producen bytes distintos a partir de la misma entrada y las máquinas dejan de ser comparables. Fijarlo hace que el corpus de extracción sea idéntico byte a byte en todas partes, que es el objetivo, pero también limita cuánto de la decodificación puede correr en paralelo - así que cuando las dos formas más cercanas eran pérdidas, las volvimos a enfrentar contra archivos empaquetados con los 32 hilos, para comprobar que no era la fijación lo que lo causaba. No lo era: «solid» pasó de un 4,2% por detrás a un 2,4% por detrás y el diccionario de 128 MiB de un 6,6% a un 6,3%, el mismo orden en ambos casos. Las dos son ahora victorias en el corpus fijado por un margen más amplio del que esa comprobación podría explicar.

Por qué no hay fila para RAR4, y qué pasa con esas publicaciones. Todas las formas de arriba son RAR5 o RAR7, que es lo que usenet publica hoy. Todavía aparecen archivos RAR4 más antiguos, y el mismo motor los lee, incluidas las formas comprimidas y protegidas con contraseña, en la misma pasada única que los más nuevos en vez de escribir los volúmenes en disco y descomprimirlos después. No tienen fila aquí porque el rar 7.23 oficial ya no puede crear RAR4, así que no hay corpus neutral sobre el que enfrentar al campo; ese trabajo se comprueba en su lugar contra archivos escritos con WinRAR 3.00, byte por byte contra unrar.

Verificación y reparación PAR2: conjunto de 1 GiB, cuatro niveles de daño

Corpus: 1 GiB de carga útil aleatoria empaquetada en modo «store» en 21 volúmenes RAR, luego dos conjuntos PAR2 al 10% de redundancia, uno con bloques de 1 MiB y otro de 64 KiB, y luego mapas de daño fijos. Cada ejecución usa el mismo protocolo: copia fresca, leer todo el corpus una vez para calentar el caché, y luego cronometrar. Mejor de tres rondas intercaladas; cada volumen reparado se compara contra el conjunto prístino en cada ronda. Menos es mejor.

Una corrección sobre el corpus, porque una versión anterior de esta página lo exageró. Decíamos que cada máquina corría un corpus idéntico byte a byte, comprobado por hash. Calcular el hash de cada volumen de cada conjunto muestra que eso es cierto en el escritorio de 32 núcleos y en el portátil Windows, que coinciden exactamente, y no en el escritorio de 20 núcleos, que tiene un sorteo aleatorio distinto de la misma forma: los mismos 21 volúmenes con los mismos tamaños, los mismos dos tamaños de bloque, y el daño verificado en los mismos 3, 101 y 1.500 bloques repartidos entre el mismo número de archivos. Cada cifra dentro de una fila se sigue midiendo sobre bytes que comparte cada herramienta de esa fila, que es en lo que descansa cada comparación. Pero las filas no son cuatro vistas de una sola entrada, y como el carácter de la carga útil vale alrededor de un 7% para el escaneo de un competidor, vale la pena declararlo en vez de pasarlo por alto.

Qué par2 es cuál. El par2cmdline original es la implementación de referencia de la que todos se bifurcaron. par2cmdline-turbo es la bifurcación que incorpora los núcleos de campo de Galois SIMD escritos a mano de ParPar: eso es precisamente lo que significa «turbo», y es por lo que turbo, en vez del original, es la herramienta que vale la pena medir. Las dos columnas turbo de abajo corren esos mismos núcleos de ParPar. Lo que las separa no es la aritmética sino la compilación y los flags.

Confirmado sobre la versión publicada contra el rival actual, 24 de agosto de 2026. Estas tablas se midieron antes de que se cortara la 1.2.2 y antes de que par2cmdline-turbo publicara la 1.5.0 (20 de agosto de 2026), así que la columna de 20 núcleos se volvió a enfrentar con las dos: nuestra versión publicada 1.2.2 contra turbo 1.5.0, tres rondas intercaladas por tramo, cada archivo reparado comparado contra el conjunto prístino. Los cuatro tramos se reproducen - los nuestros 0,18 / 0,30 / 0,75 / 2,02 frente a los 0,19 / 0,33 / 0,74 / 2,07 impresos aquí, y turbo 1.5.0 queda dentro de unos pocos puntos porcentuales de la versión de la tabla en cada tramo y en las dos configuraciones. Las celdas se mantienen tal como se publicaron; las otras tres máquinas conservan sus propias fechas.

Así que la competencia aparece dos veces, y una de esas columnas es su mejor caso y no su configuración por defecto. El binario de publicación que descargarías está compilado para una CPU base genérica y solo hashea un par de archivos a la vez; compilar el mismo código fuente para la CPU real del equipo y pasar -T16 le permite usar las instrucciones que esa máquina realmente tiene y hashear dieciséis archivos a la vez. En el portátil eso vale hasta 2,6x, enteramente por la compilación y los flags. Júzganos por la columna ajustada, que es la comparación más dura; la columna de fábrica es lo que en realidad experimenta quien se lo descarga. par2cmdline es el original, versión 1.2.0, compilado desde el código fuente en cada máquina. rarpar es la propia implementación de PAR2 de Weaver, compilada desde el código fuente con su backend de GPU Metal activado. El par2j de MultiPar es solo para Windows, así que aparece únicamente en las filas del portátil Windows. Las filas de M5 Max enfrentan a las dos herramientas con compilaciones actuales de macOS arm64 junto a las dos columnas turbo; el par2cmdline clásico no se enfrentó en esa máquina.

Las dieciséis celdas de nzbfast - cuatro máquinas en cuatro niveles de daño - son nuestras, varias por más de 2× contra la versión ajustada y de 2,3× a 7,7× contra la que realmente te descargarías. Las celdas de daño pesado son las interesantes, y la nota de abajo explica el algoritmo detrás de ellas.

El original vuelve a la tabla, y vale la pena ver por qué existe la bifurcación. Una versión anterior de esta página quitó la columna de par2cmdline alegando que era más lenta que todo lo demás de la ronda, lo cual es cierto y no es una razón suficiente: es la implementación de la que casi todas las demás herramientas descienden, y los lectores merecen la línea base en vez de nuestra afirmación sobre ella. En el nivel de daño más pesado tarda unos 69 s donde la bifurcación SIMD tarda 3,2 s y nosotros tardamos 3,1 s. Ese factor de veinte es todo el argumento a favor de los núcleos de campo de Galois escritos a mano, y es el mismo argumento que hacemos por los nuestros.

El daño ligero es el caso que importa. Un puñado de artículos fallidos es mucho más típico que 101 bloques muertos, y nada parecido a 1.500. La mayor parte de una reparación ligera no es en absoluto la matemática de Reed-Solomon, es leer y calcular MD5 de un gigabyte, que es por lo que la fila de 3 bloques sigue a la fila de verificación limpia en vez de a las de reparación.

El nivel de daño más pesado es un tipo de trabajo distinto, y se lleva un algoritmo distinto. Ese último nivel daña 1.500 bloques en los 21 volúmenes y consume alrededor del 91% de los datos de recuperación, que es donde la aritmética de Reed-Solomon, más que el hashing o el disco, se convierte en casi todo el trabajo. La versión publicada calcula las reparaciones más pesadas con una transformada teórico-numérica en vez del pliegue clásico de campo de Galois - la misma matemática, evaluada en una forma que escala mucho mejor con recuentos de bloques altos: 2,7× por delante de la versión ajustada en el escritorio de 20 núcleos, y en el portátil Windows 2,7× por delante de la versión ajustada y 2,2× por delante de MultiPar. El daño ligero sigue corriendo la vía clásica, que es por lo que los otros niveles apenas se movieron: la transformada solo compensa por encima de unos 512 bloques dañados, así que por debajo de eso el despachador no la usa.

Una vía más rápida solo vale la pena tenerla si no puede estar equivocada. Las dos vías calculan la misma cantidad y son idénticas a nivel de bit por construcción, y cada reparación de esta página se comprobó contra que los archivos reconstruidos coincidieran con el conjunto prístino: 228 reparaciones cronometradas entre las máquinas de esta ronda, cero discrepancias. La versión publicada no depende de ese historial. Cada reparación verifica su propia salida contra los hashes del archivo, y una que fallara se rehará automáticamente con la vía clásica, registrará la divergencia, y mantendrá la vía clásica para el resto de esa ejecución. El ajuste está en el panel como Modo PAR rápido si prefieres no tenerlo en absoluto, y las máquinas con muy poca memoria para él lo rechazan por sí solas en vez de intentarlo y fallar. Vuelto a medir el 2 de agosto sobre la versión actual: los dos escritorios quedan dentro de unos pocos puntos porcentuales de esta tabla, y con el Modo PAR rápido desactivado el escritorio de 20 núcleos vuelve exactamente al tiempo más lento de la vía clásica, que es lo que dice que la victoria es el método y no las condiciones.

La columna del portátil Windows necesitaba una corrección, y va en nuestra contra. Windows relega el trabajo sostenido en segundo plano a sus núcleos de eficiencia a los pocos segundos. Nuestro daemon renuncia a eso al arrancar y ninguna de las otras herramientas puede hacerlo, así que una versión anterior de esta página publicó sus tiempos limitados como si fueran los propios de las herramientas. Volver a correr esa máquina con cada herramienta elevada a prioridad alta mueve todo el campo: en el nivel de daño más pesado par2-turbo pasa de 22,4 s a 6,41 y rarpar de 59,2 s a 14,4, y en un corte de esta página eso convirtió la columna de nuestra en una que perdíamos. Toda la columna del portátil se mide así ahora - la corrección se mantiene aunque la fila se ha vuelto a ganar desde entonces por el cambio de algoritmo de arriba, porque los tiempos del campo en esa máquina solo son honestos con el límite levantado.

Registros de recuperación de RAR: reparar sin PAR2

Cuando PAR2 no puede cubrir el daño, el registro de recuperación dentro del propio RAR es la última línea de defensa. Hasta la 1.0.8 el nuestro fallaba en cualquier archivo de más de unos 13 MB, así que este tramo no se podía correr en absoluto. El daño son tres agujeros de 3.000 bytes al 20%, 50% y 80% de la región protegida. Las dos herramientas produjeron una salida idéntica byte a byte al archivo prístino, y la nuestra es idéntica byte a byte a lo que escribe el propio rar r. Mejor de tres, escritorio de 32 núcleos, las dos herramientas vueltas a enfrentar juntas el 2 de agosto.

Una versión anterior de esta página mostraba el tamaño de 512 MB como una pérdida, y lo explicaba como el precio de trabajar el volumen por partes en vez de tenerlo entero en memoria. Esa explicación era correcta en su momento y ahora está obsoleta: el coste era un CRC64 bit a bit en serie en la vía de reparación, sustituido por uno basado en tabla, y la pérdida se fue con él. Ya no hay ningún cruce, y se conservó el conjunto de trabajo acotado. El tamaño de 2 GB está aquí porque los volúmenes que un daemon realmente encuentra van de 8 GB a 20 GB, no 512 MB, y un tramo que se detiene por debajo del rango real no es mucha prueba.

Qué movió este corte, y el control que lo confirma. Encontrar qué bloques estaban dañados se había convertido en la fase más grande de esta reparación - más grande que la propia aritmética de reparación - y corría en un solo hilo, leyendo 64 KB de cada grupo a lo largo del archivo, una vez por grupo. Ahora hace una sola pasada secuencial en el orden del archivo con las sumas de comprobación por fragmento calculadas en paralelo, y el volumen reparado se clona en vez de copiarse donde el sistema de archivos puede hacerlo. Solo la detección cayó de unos 300 ms a 18 ms en el archivo de 512 MB, que es la mayor parte de lo que se movió arriba. El control es la columna junto a la nuestra: rar r se volvió a enfrentar en las mismas rondas en la misma máquina y volvió dentro de unos pocos puntos porcentuales de sus tiempos anteriores, así que el cambio en la brecha es nuestro y no del banco de pruebas.

El M5 Max repite el patrón, enfrentado el 31 de julio con el mismo corpus y las mismas comprobaciones: 0,050 / 0,066 / 0,171 / 0,581 s contra los 0,211 / 0,335 / 0,751 / 1,735 s de rar r en los tamaños de 16 MB a 512 MB - de 3,0× a 5,1× más rápido; el tamaño de 2 GB no se enfrentó en esa máquina. Esas cifras son anteriores a la reescritura de la detección descrita arriba, así que son de la versión más antigua, conservadas aquí como la segunda máquina y no como una cifra actual.

El rarpar de Weaver está ausente solo de esta tabla, y no por elección: no implementa esta reparación. Cuando se le pide arreglar uno de estos archivos responde "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data", y deja el archivo dañado. Aparece en cualquier otra comparación de esta página: los cuatro tramos de PAR2 de arriba, las siete formas de extracción antes de eso, y el tramo de volúmenes de recuperación inmediatamente de abajo, que es el trabajo que dice hacer - y que gana.

Volúmenes de recuperación: reconstruir archivos .rev perdidos por completo

La otra mitad de la propia historia de recuperación de RAR, y hasta esta ronda la mayor pérdida de esta página. Un archivo .rev es un volumen de recuperación independiente: tres de ellos junto a un conjunto de 21 volúmenes pueden reconstruir cualesquiera tres volúmenes que nunca llegaron. Corpus: 1 GiB almacenado en 21 volúmenes de 50 MB con rar rv3, y luego se borran los volúmenes 4, 11 y 19 - tres perdidos contra tres volúmenes de recuperación, que es el peor caso que el conjunto todavía puede sobrevivir. Mejor de tres, cada volumen reconstruido comparado contra el prístino.

La celda de 32 núcleos aquí era de 3,12 s contra los 0,47 de rar rc en el último corte de esta página, publicado como 6,6× más lento y el peor número de ella. La causa era que la resolución de borrado corría a unos 48 MB/s de salida reconstruida donde RARLab gestionaba 320; ahora corre sobre la misma aritmética basada en tabla que el resto del código de recuperación, lo que es una mejora de siete veces y convierte la pérdida en victoria en las dos máquinas. Los márgenes son 3% y 14%, así que es una victoria para declarar con sencillez en vez de para destacar en un titular, y la razón por la que se declara siquiera es que la pérdida se declaró primero.

Este tramo existe porque el rarpar de Weaver implementa exactamente esto y pidió ser medido en él. Iba ganando cómodamente cuando lo publicamos por primera vez, y lo publicamos entonces por esa razón.

La coincidencia de archivos nunca fue el coste, lo cual vale la pena registrar porque era el sospechoso intuitivo: los volúmenes de recuperación no llevan nombres de archivo, así que identificamos qué ranuras sobrevivieron calculando la suma de comprobación de cada volumen en disco en vez de confiar en cómo se llaman, y contra un conjunto sin daño, donde lo único que pasa es la coincidencia, toda la pasada tarda 0,18 s.

Qué más se movió, y dónde no se nota. Aterrizaron otros dos cambios de motor que estos corpus no pueden ver, listados aquí para que las cifras de arriba no se lean como toda la historia: los archivos RAR5 con decenas de miles de miembros resuelven cada miembro una vez en vez de recorrer la lista por cada trabajador, lo que es 3× menos tiempo de procesador con 40.000 miembros; y el lector de bits de RAR1.3 trabaja una palabra a la vez, lo que es 2×. Ninguno de los dos aparece arriba, porque las formas de aquí tienen 400 miembros y ningún RAR1.3.

Lo que deliberadamente no hacemos: nunca creamos PAR2. Un descargador no tiene razón para hacerlo, y ese tramo es de ParPar. También compramos velocidad con memoria en los dos motores: la extracción llega a un pico de unos 240 MB contra los 41 MB de unrar, y la verificación a unos 126 MB contra los 7 MB de turbo, porque estos son los motores integrados que viajan junto a una descarga en vivo en vez de ejecuciones únicas independientes. La forma con diccionario de 128 MiB es lo peor de ello, con unos 304 MB contra los 139 MB de unrar. La reparación más pesada ahora también cuesta memoria: el método más rápido para 512 o más bloques perdidos trabaja a partir de los datos de recuperación mantenidos residentes, así que se le permite hasta una cuarta parte de la RAM de la máquina, con un tope de 4 GB, y una máquina que no puede permitírselo pasa en silencio al método de baja memoria en su lugar - la misma aritmética y los mismos tiempos que las filas intermedias de la tabla de PAR2, solo que sin el 3× de la última. Si quieres el conjunto residente más pequeño posible para un trabajo independiente, las herramientas dedicadas siguen ganando esa columna.

Prueba de transporte · medido en la 1.2.2

El motor sigue el ritmo de líneas reales

• ~8,7 Gbps sostenidos a través de una flota de cinco proveedores en una línea de 10 GbE, incluida la verificación y la extracción en flujo - la ronda de 87 GB de arriba, 24 de agosto de 2026, v1.2.2, 360 conexiones: 77,4 GB de cable en 71 s con la carga útil verificada y extraída a medida que llegaba. No es una cifra de ráfaga: es todo el trabajo a esa velocidad.
• A 1 Gbit y por debajo, la línea es el límite y nzbfast se sitúa justo en él: ~96% de una línea de 500 Mbit y ~96% de una línea de 250 Mbit a través de la verificación y la extracción, con una fracción de la memoria y el disco de cada rival - la sección de sub-gigabit de arriba.
• El coste total de procesador del trabajo de 87 GB es de 1,7 segundos de CPU por GB con el gobernador de conexiones activado - descarga sobre TLS, verificación, preparación para reparar y extracción incluidas - frente a entre 3,0 y 28 para el campo en la misma ronda; el brazo de máximo rendimiento de arriba gasta 4,3.

Cortes anteriores de esta página llevaban un conjunto más amplio de demostraciones de transporte - ejecuciones de saturación multilínea, ganancias de pipelining por RTT, una prueba de contrapresión, mediciones de techo de decodificación - enfrentadas sobre versiones que la v1.2.2 ha superado desde entonces. Bajo la regla de esta página se retiran en vez de dejarlas envejecer, y vuelven a medida que se cortan de nuevo sobre la versión actual; las tres afirmaciones de arriba son las que ya se han vuelto a medir sobre v1.2.2.