Kıyaslamalar

Kısacası · 23 Ağustos 2026'da nzbfast 1.2.2 olarak yayımlanan kod hattı üzerinde ölçüldü

Ölçülen hiçbir istemci işlemci, bellek ve diskte birlikte daha ucuz değil

Bu sayfadaki en yeni ayaklar 23 ve 24 Ağustos 2026'da koştu - en yenisi doğrudan v1.2.2 sürüm derlemesinde - özdeş donanım, hat ve sağlayıcılarda dört başka istemcinin güncel derlemelerine karşı: 6,5 ile 87 GB arasında iki iş biçimi, ve 250 Mbit'ten 10 GbE'ye hat hızları. Bu ayaklarda hiçbir istemci işlemci, bellek ve diskte birlikte nzbfast'ten ucuza gelmedi: her biri üçünden en az ikisinde daha pahalıya mal oldu, herhangi birinin tek bir eksende kazandığı en fazla şey yaklaşık yüzde 2 idi - o istemcinin kendi çalıştırmadan çalıştırmaya değişen aralığının içinde kalan, istatistiksel bir berabere - ve diskte, hepsi bayt-eşdeğeri bir sonuç için en az iki katı bayt taşıdı. Fabrika ayarlarıyla nzbfast, ölçülen her istemci arasında ölçülen her senaryoda da en az belleği tuttu, en yakın rakibe karşı 2,0x ile 4,5x arasında.

Hangisi size uyar?

Çoğu indirici, indirmenizi diske en az iki kez yazar: biri indirirken, biri de arşivi açarken. nzbfast tüm işi tek geçişte yapar, bu yüzden iş başına baytların yaklaşık yarısını yazar, çalışırken bellekte daha azını tutar, ve GB başına daha az işlemci saniyesi harcar. Bu, kullanırken makine üzerindeki daha az yük ve aynı bayt-eşdeğeri dosyalar için sürücülerinizde iş başına yarı yazma demektir - ve her bayt diski yaklaşık bir kez geçtiği için, sürücünüzün hattınıza yalnızca bir kez yetişmesi gerekir.

nzbfast bu sayfadaki her tabloyu kazanmıyor, ve kaybettikleri kazanmadığımız ayaklar altında - aynı ayaktan bir tanesi dahil. Ölçtüğümüz her ayakta değişmeyen şey birleşik faturaydı.

Önce yöntem

Kurulum

• İstemciler: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, her tablo adlandırdığı derlemelerde. En yeni ayaklar (23 Ağustos 2026) alanın o anki güncel derlemelerini yarıştırdı - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 ve Weaver 0.7.8, en yeni yayımlanan ikili dosyası, kimliği hash ile kanıtlanmış - o gece nzbfast 1.2.2 olarak yayımlanan kod hattına karşı, böylece yeni sayıları üreten derleme indirebileceğiniz derlemenin ta kendisi. Bu ayaklar 1 Gbit hatta 20 çekirdekli bir Apple Silicon kutuda koştu. Daha eski tablolar yarıştırdıkları derleme ve makineleri korur (Apple M serisi kutular: 10 GbE'de "Avrupa" M1 Ultra, ~2,4-3,0 Gbps hatta "Doğu Yakası" M3 Ultra) ve bunu belirtir; yayımlanan derlemeyi pohpohlamak yerine olduğundan düşük gösterirler.
• Adalet: her istemci için her yerde aynı sağlayıcılar ve TLS, ayaklar art arda iç içe koşuldu. Her rakip kendi belgelenmiş en iyisine ayarlandı: SABnzbd'ye pipelining_requests=8 verildi (kendisi 1 ile, yani hatsız gelir, ve bu ayar büyük işlerde çift haneli yüzdelere değer), NZBGet'e ArticleCache/DirectWrite/DirectUnpack/ParQuick verildi, rustnzb kendi belgelenmiş yapılandırmasıyla koştu. 20 Ağustos 2026'dan beri her ayak altı değil beş sağlayıcıya karşı koşuyor - bu kutularda sağlayıcı sayısı bir aktarım kolu değil, tek bir sağlayıcı bile hat tavanına ulaşabiliyor, ve sabit bir küme ayakları karşılaştırılabilir tutuyor - bu yüzden bu sayfadaki altı sağlayıcılı bir rakam daha yeni bir beş sağlayıcılı olanla doğrudan karşılaştırılabilir değil, ve her tablo hangisini koşturduğunu belirtir.
• Bitiş durumu: doğrulanmış, çıkarılmış, kullanılabilir bir dosya, "indirme bitti" değil. Aslında beklediğiniz şey bu.
• Yeniden üretilebilirlik: her iddia tarihlendirilmiş ve aynı yöntemle ölçülmüş: geçen süre + arayüz bayt sayaçları + süreç ağacı zirve RSS, 1-2 s çözünürlük. Bir ayak genel erişime açık bir NZB üzerinde koştuğunda, kendiniz koşturabilmeniz için onu adlandırıyoruz.
• Sayfa genelinde geçerli yöntem notları: CPU süresi, bir tablonun her kolunda süreç ağacından 2 Hz'de örneklenir ve asla farklı bir muhasebeden gelen bir rakamın yanına konmaz, çünkü iki yöntem tasarım gereği uyuşmaz. Aygıt G/Ç'si GiB cinsinden, ağ baytları ondalık GB cinsinden verilir; bölmeden önce çeviririz. Ve kendi derlememizi kendi derlememize karşı yarıştıran her tablo bir A/A kontrolü taşır - aynı ikili dosyanın kendisiyle bayt-eşdeğeri bir kopyasına karşı aynı düzenek üzerinden yarıştırılması - çünkü bu kontrol, kendi karşılaştırma düzeneğimizin hangi araç önce koşarsa ona ~%1,5'lik bir ceza verdiğini nasıl yakaladığımızdır (hikaye aşağıdaki çıkarma tablolarının yanında). İki kol ve değiştirilmiş sıralar, her zaman ilk kola inen bir yanlılığı iptal etmez; bir A/A kontrolü onu ortaya çıkarır.

Daha yavaş hatlar · 24 Ağustos 2026'da nzbfast 1.2.2 üzerinde ölçüldü

Hat ne kadar yavaşsa istemcileri hız o kadar az ayırır - fatura ise o kadar çok

Yeterince yavaş bir hatta her istemcinin bitiş süresi yalnızca hattır, başka bir şey değil, bu yüzden yavaş bir hat pek çok günahı gizler. Gizleyemediği şey her istemcinin onu doldurmak için ne yaktığıdır. 1 Gbit düzeneği gerçek planların gerçekten olduğu iki hıza şekillendirdik ve her hızda altı kolun tümünü yarıştırdık - aynı kutu, aynı beş sağlayıcı, istemci başına üç tekrar, sıra döndürülerek, her ayak bayt denetimli, iki ayaktaki 36 ayaktan 36'sı doğru. 500 Mbit'teki nzbfast kolu, v1.2.2 sürüm derlemesinin ta kendisi.

İki tabloyu bir eğim olarak okuyun. 250 Mbit'te tüm alan saatte %18 içine sığıyor ve en yakın rakibi %4,4 farkla geçiyoruz; 500 Mbit'te fark %14,7'ye açılıyor; yukarıdaki ve aşağıdaki gigabit ve 10 GbE hızlarında daha da açılıyor. Hız farkları hatla birlikte büyüyor. Kaynak sütunları hızlı bir hat beklemiyor: ölçülen her hızda, her rakip belleğin en az 3,9 katını tuttu, daha çok işlemci harcadı, ve aynı bayt-eşdeğeri dosya için disk baytlarının yaklaşık iki katını taşıdı.

Bağlantı denetleyicisi yavaş hatlarda hakkını veriyor, ve şekillendiricinin kendi düşürme sayacı bunun sebebini söylüyor. Fabrika ayarları, her rakip yüzlerce bağlantı çalıştırırken 25 bağlantı tuttu; denetleyicisi kapalı aynı ikili dosya 360 çalıştırdı. Sabit bir kuyruktan geçen daha az akış daha az kayıp ve daha az yeniden gönderme demek: şekillendirici, 500 Mbit'te sınırlı bir ayak başına yaklaşık 4.200 düşme kaydetti, sınırsız ayakta ise yaklaşık 155.000; sınırlı kol hem daha hızlı, hem 4,2 kat bellekte daha hafif, hem de kendi 360 soketlik duruşumuza göre CPU'da 1,3 kat daha hafifti. Daha çok bağlantı daha çok hız demek değil; gigabitin altında bu ölçülebilir biçimde tam tersi.

24 Ağustos 2026'da ölçüldü, üçün ortancaları, hattı her hıza şekillendirilmiş 20 çekirdekli bir Apple Silicon kutuda (şekillendirilen hız her ayaktan önce bağımsız bir yoklamayla doğrulandı: 248 ve 496 Mbit). 500 Mbit'teki nzbfast kolu v1.2.2 sürüm etiketi derlemesi; 250 Mbit ayağı aynı kod hattında saatler önce koştu. Şekillendirilmiş bir hatta bayt sayıları her istemcinin kendi sayacından okunur, asla ağ arayüzünden değil (şekillendirici düşürür ve TCP yeniden gönderir, bu yüzden arayüz her iki kopyayı da sayar). Duvar süreleri her tablo içinde karşılaştırılabilir, farklı şekillendirilmiş ayaklar arasında değil. ¹ NZBGet'in 500 Mbit'teki üç ayağı 114-158 s arasında yayıldı, kaynak okumaları sabitti - gerçek bir yayılma, bu yüzden ortanca verildi ve yayılma daraltılmadan belirtildi.

Hasarlı gönderi · 24 Ağustos 2026'da yeniden yarıştırıldı, her derleme güncel

Gönderide delikler olduğunda: 60, 20 ve 5 ölü makaleyle 6,5 GB

Makaleler süresi dolar, sunucular onları sessizce düşürür, yüklemeler eksik iner - ve hasar, istemciler arasındaki farkın en geniş olduğu yer, bu yüzden nzbfast v1.2.2 dahil her istemcinin en yeni derlemesinde kendi ayağını alıyor: Avrupa'da 10 GbE kutu, beş sağlayıcı, istemci başına 100 bağlantı, üç hasar düzeyinde zehirlenmiş aynı 6,5 GB sürüm, sırası dönüşümlü kolda üç tekrar, her ayak temiz dosyaya karşı bayt denetimli. 65 ayaktan 63'ü bayt-özdeş döndü; özdeş dönmeyen iki tanesi aşağıda adlandırıldı, çünkü onlar da birer sonuç.

Hasarlı gönderi burada neden hızlı. Bir makale eksik olduğunda, bir istemci normalde her sunucu onu reddedene kadar sırayla bir sonraki sunucuya sorar - her reddin onlarca milisaniyeden birkaç saniyeye kadar sürdüğü, indirmenin sıfırda oturduğu seri bir yürüyüş. nzbfast sormayı bırakır: elde bulunan eşlik verisi hâlâ eksik olanı kapsar kapsamaz, yürüyüşü bitirmek yerine hemen onarır. Bu ikinci satır - aynı ikili dosya bu davranış kapatılmış haliyle hasar düzeyine göre 1,4 ile 2,3 kat daha yavaş - ve ayak, düzeneğin her etkin kolda devreye girdiğini ve kapalı bir kolda hiç girmediğini doğruladı. En yakın rakibe karşı fark 2,4 ile 2,7 kat, dokuz tekrar çiftinden hiçbirinde çakışma olmadan.

Fark en genişini diskte açıyor, ve bu onarım hilesi değil. Tamamlanan her kol aynı 6,48 GB dosyayı üretti; bizimki bunu yaparken 6,2-6,8 GB disk G/Ç'si taşıdı, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB ve rustnzb 12,8-13,1 GB. Bu tek geçişli boru hattı - kapatılmış satır da aynı 6,2 GB'ı taşıyor - bu yüzden hasarlı ve hasarsız gönderilerde aynı biçimde tutuyor.

¹ SABnzbd'nin en ağır hasarda üç ayağı 43, 41 ve 60 s koştu - özdeş girdilerde gerçek bir yayılma, bu yüzden ortalama verildi ve aralık belirtildi. ² rustnzb 1.4.5 her ayağı bayt-doğru teslim etti, ve bedeli güvenilirlik değil işlemci süresinde: en ağır hasarda 107 s'lik saate karşı yaklaşık 1.620 CPU-saniyesi - neredeyse tüm ayak boyunca meşgul on beş çekirdek - aynı onarılmış çıktının bize yaklaşık 50 CPU-saniyesine mal olduğu yerde. ³ Weaver, iki daha ağır hasar düzeyinde 20 dakikalık kesim süremiz içinde 6,5'in 1,5 GB'ını ve 4,9 GB'ını taşıdı - onu yarıştıran üç ayrı gecedeki üç ayağın da paylaştığı aynı bitmeme; kesim süresi bizim, bitmeme ise sonuç. 5 ölü makalede üçünde de doğru biçimde tamamladı. Oradaki işlemci bedeli kendi hikayesi: 194 s'lik ayak için yaklaşık 2.325 CPU-saniyesi, bizim 20'mize karşı.

24 Ağustos 2026'da ölçüldü, her derleme güncel: nzbfast v1.2.2 (sürüm etiketinin ta kendisi), NZBGet 26.3-testing (20 Ağustos derlemesi), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. Bir süreklilik kolu, önceki gecenin nzbfast derlemesini bu aynı ayak içinde yarıştırdı ve her senaryoda v1.2.2'nin bir saniye içine indi, bu yüzden burada hiçbir şey şanslı bir geceye binmiyor; ve rakip yapılandırmaları önceki ayaktan yalnızca uygulama yolunda ayrılıyor, ayak koşmadan önce anahtar anahtar denetlendi.

Onu RAM'den mahrum bırakın · 24 Ağustos 2026'da nzbfast 1.2.2 üzerinde ölçüldü

Az bellek merdiveni: ~0,3 GB RAM'de 87 GB

Yukarıdaki koldaki aynı 87 GB iş, 2 GB, 1 GB ve 256 MB'lık sabit bellek bütçelerinde yeniden koşuldu - bir 8 GB kutuda, bir 4 GB kutuda ve bir 2 GB'lık NAS'ta otomatik boyutlandırıcının seçeceği şey. Her ayak özdeş bayt-denetimli dosyayı üretti, ve bellek sütunu bütçeyi izledi, işi asla:

Sürüm derlemede bütçe başına tek ayak, altı-kollu ayakla aynı çıktı sağlama toplamına karşı geçitli. En sıkı bütçe duvarın yaklaşık %9'una mal oluyor, ve yalnızca bu hat 10 GbE olduğu için - dökülen bloklar yalnızca hat diski geçtiğinde zaman kaybettirir, bu yüzden tipik bir ev bağlantısında küçük bir bütçe neredeyse bedava. 87 GB'lık bir indirme dahil tüm merdiven 0,3-0,6 GB bellekte sığıyor; fabrika ayarlarında iş 286 MB'ta koştu. Başka hiçbir istemci sabit, süreç genelinde bir bellek bütçesi sunmuyor; en yakın şeyler önbellek boyutu kadranları, ve aşağıdaki ayak onların bedelini ölçüyor.

Kelepçe, alanın kendi kadranlarına karşı yarıştırıldı. 34 GB senaryoda (23 Ağustos 2026, 1 Gbit kutu, beş sağlayıcı, 30 ayaktan 30'u bayt-doğru), NZBGet'i eşdeğer bir önbellek kelepçesine tutmak CPU'sunu ikiden fazla artırdı (215,5'ten 453,0 CPU-saniyesine, 2,10 kat), zirve belleğinde %52'lik bir kesinti satın almak için. SABnzbd'nin kelepçesi neredeyse bedavaydı ama ayak izinin yalnızca bir kısmına ulaştı. rustnzb'nin önbellek ayarı yarıştırılan derlemede süsten ibaretti, ve Weaver'ın hiç bellek kadranı yok, bu yüzden ikisi de tutamayacakları bir bütçede puanlanmak yerine referans sütunları olarak kelepçesiz koştu. Aynı ayağın bizim tarafımız, aynı şeyi 2,5 kat boyutta söyleyen yukarıdaki v1.2.2 merdiveniyle aşılmış durumda: bütçe asla bağlayıcı kısıt değil, çünkü tek geçiş baştan bu kadar az tutuyor.

Boş alan · megabayta kadar ölçüldü

Bir işin ne kadar az boş alanla yetindiği

Yazıp-sonra-açan bir istemci, arşiv birimleri ve açılmış yük için aynı anda yere ihtiyaç duyar, bu yüzden bir iş indirmenin kabaca iki katı boş alan olmadan başlamaz. Tek geçiş yükün kendisine ihtiyaç duyar - ve bu ayak, her istemci başarısız olana kadar hedef birimi küçülterek ne kadar az fazlasına ihtiyaç duyduğunu ölçtü. nzbfast'in yanıtı bir oran değil, yaklaşık 50 MB'lık sabit bir pay, ve bu 6,5 GB'lık bir işten 34 GB'lık bir işe kadar tutuyor.

20 çekirdekli bir Apple Silicon kutuda, 1 Gbit hatta, beş sağlayıcıda, her sınırda üç tekrarla ölçüldü, tamamlanan her ayak bayt denetimli - rakip satırlar 22-23 Ağustos 2026 (Weaver'ın 34 GB hücresi 24 Ağustos'ta yeniden koşuldu, dipnot 1)'da, ve nzbfast satırı 24 Ağustos'ta v1.2.2 sürüm derlemesinde yeniden kesildi, bu da her iki sınırı da tam olarak yeniden üretti, iki senaryoda 12 ayaktan 12'si hemfikir. Hücrelerimiz ölçülmüş bir taban: iş 48,6 MB ve 51,0 MB payla 3'te 3 tamamlanıyor, ve bunun yaklaşık 17 MB altında 3'te 3 reddediyor - bu yüzden taban her iki yönde de gerçek. İşin gerçekte tuttuğu şey çıktının yaklaşık 3 MB üstünde yerleşiyor; pay, boru hattının son anlarının bedelini öder, asla bir ikinci kopyanın değil. Rakiplerin hücreleri, 6,5 GB işteki ölçülmüş tabanları ve 34 GB'takinde aynı oranda doğrulanmış bir yeterlilik (o oranda tam olarak 3'te 3 bayt-doğru); onların merdivenini daha büyük boyutta daha aşağı yürümedik, bu yüzden oradaki gerçek tabanları orandan biraz aşağıda olabilir, ve bunu kendi lehimize yuvarlamak yerine söylüyoruz.

Tükenmenin gerçekte nasıl göründüğü sayı kadar önemli. Tabanının 17 MB altında nzbfast, bir yazmada diskin reddiyle karşılaşır, "boş disk alanı yok" diyerek temiz durur, inen her şeyi güncel tutulmuş olarak korur, ve bir yeniden deneme yeniden çekmeden devam eder - tuttuğunuz bir parça, başarısız bir iş değil. ¹ Weaver'ın büyük-senaryo hücresi 24 Ağustos'taki bir tekrarla çözüldü: üç ayağın üçü de aynı ~2,25 katta bayt bakımından doğru, her biri ilk denemenin iyi ayağından hızlı ve boş alan bayta kadar aynı. İlk denemede, 23 Ağustos'ta, üç ayağından ikisi 60 GB'dan fazla boş alan hâlâ varken tek haneli MB/s'de takılmış ve turun 40 dakikalık kesim süresine çarpmıştı. O takılmalar geri gelmedi ve düzeneğin takılma ölçümü tekrarın üç ayağında da devredeydi ve sessizdi; bu, eksik bir ölçüm değil olumlu bir ölçümdür. Onlara neyin yol açtığı hâlâ bilinmiyor ve temiz bir tekrar bir teşhis değildir: bu oranda artık altı ayak var, dördü tamamlandı ve iki başarısızlık da ilk gecedeki tek bir 80 dakikalık pencereden geliyor.

İç içe gönderiler · 28 Ağustos 2026 tarihinde ölçüldü

Bir gönderiyi paketlemenin on yolu ve dosyaya gerçekten kim ulaşıyor

Yayımlananların çoğu bilerek açılması zor hâle getirilir. Gerçek dosya adı ikinci bir arşivin, bazen üçüncüsünün içine gömülür, bazen her katmanda başka bir biçimde durur; böylece gönderi içeriği hakkında olabildiğince az şey ele verir. Üstüne bir de gönderiler hasarlı ulaşır: makaleler süresi dolup düşer, yüklemeler eksik iner ve hiçbir şey açılmadan önce kurtarma verisinin kullanılması gerekir. Bir indirici ya bu zinciri sizin için baştan sona yürür ya da elinize bir klasör dolusu arşiv verip durur.

Bu yüzden tam olarak bunu yalıtan on biçim kurduk, güncel her istemciyi bunlara karşı yarıştırdık ve sonra karşılaştırmaların genelde atladığı şeyi yaptık: bir istemci erken durduğunda işi standart araçlarla elle bitirdik ve onun da süresini tuttuk. Çabuk pes eden bir istemci, size bıraktığı iş sayılana kadar hızlı görünür.

Onunu da yardımsız bitiren tek istemci nzbfast. NZBGet de her biçimde dosyaya ulaşıyor, ama bunların sekizinde 16 tur elle onarım ve açma gerekiyor. SABnzbd beşini yardımsız bitiriyor, ikisine elle bile ulaşılamıyor. Weaver dosyaya ikisinde ulaşıyor.

Bu örüntü rastlantı değil. nzbfast'in geçtiği, diğerlerinin geçemediği biçimler paketlenmiş ve hasarlı olanlar: arşiv içinde arşiv, zincirin ortasında biçim değişimi, beş katmanlı bir zincir ve hepsinden önemlisi kendi kurtarma verisiyle birlikte bozuk gelen bir arşiv. Bu sonuncusunda dört istemci dıştaki kümeyi kusursuz açıyor, bozuk arşivi onu onaracak kurtarma kümesiyle birlikte elinize verip duruyor.

İstemcilerin aynı işi bitirdiği yerde fark küçük değil. Aşağıdakiler, yaygın dört istemcinin de ulaştığı yedi biçim; her birinin ihtiyaç duyduğu elle onarım dâhil:

Dört ila beş kat daha hızlı ve yazılan baytın yarısından azıyla. Disk rakamı indirmeden sonra da önemini koruyan rakamdır: o sütundaki her gigabayt, diskinizin kabul etmek zorunda kaldığı bir gigabayttır; işi ara belleğe alan istemciler içeriği yazar, geri okur ve yeniden yazar.

Önde olmadığımız yerler ve bunu söylemeye neden değer. On biçimin dördünde bir rakip indirmenin kendisi sırasında nzbfast'ten daha az bayt yazıyor. Her seferinde daha azını yaptığı için: bozuk iç arşiv biçiminde NZBGet bizim 4,65 değerimize karşılık 3,29 GB yazıyor, ardından onarım turu 2,91 daha yazıyor ve bizim 4,65 değerimize karşılık 6,20 GB ile bitiriyor. Diğerlerinde en az yazan istemci, dosyaya hiç ulaşamamış olandır. Küçük bir disk rakamı her zaman tutumluluk değildir.

Bunlar yetenek testleridir, hız testleri değil. İçerikler küçüktür ve yerel bir bağlantı üzerinden bellekten sunulur; yolda ne sağlayıcı ne de ağ vardır, dolayısıyla buradaki hiçbir şey indirme hızıyla sınırlı değildir ve mutlak saniyeler aynı biçimlerin gerçek dünyada alacağı süreden çok daha kısadır. Bir biçimin elle iş gerektirip gerektirmediği, biçimin ve istemcinin bir özelliğidir ve doğrudan aktarılır. Saniyeler, aynı işi yapan istemcileri karşılaştırır; gerçek bir işin ne kadar süreceğini öngörmez.

Biçim başına tüm sonuçlar, her biçimin ne olduğu ve yöntem iç içe arşivler veri sayfasında.

Neden önemli

Sürücünüz işin yarısını yapar

Flash depolama, üzerine yazılarak yıpranır. 94 GB'lık bir sürüm, nzbfast altında sürücünüze yaklaşık 90 GB'lık yazmaya mal olur; aşamalı çalışıp açan bir istemci altında aynı sürüm kabaca iki katına mal olur. Sabit diskli bir NAS'ta tek-geçiş biçimi ayrıca her şifreli indirmenin sonundaki uzun tek-iş-parçacıklı geçişi de kaldırır - donanım hızlandırmalı kilit açma özellikli hızlı 32 çekirdekli bir iş istasyonunda 20 saniye ölçülen, ve bunun gerçekte üzerinde çalıştığı düşük güçlü makinelerde buna karşılık gelen şekilde daha uzun bir duraklama. Küçük sayıyı aktarıyoruz çünkü ölçtüğümüz olan bu.

Bileşen kıyaslamaları

Daha fazla veri isteyenler için daha teknik kıyaslamalar

Onarım (PAR2) ve açma (RAR) paketlenmiş üçüncü taraf ikili dosyalar değil kendi yerli kodumuz, bu yüzden onları da bir okuyucunun gerçekten sahip olabileceği dört makinede, özdeş korpuslarda özel araçlara karşı bağımsız olarak yarıştırıyoruz. Bir süre yalnızca çıktı kaynak yüke bayt-eşdeğerse sayılır: aşağıdaki her RAR rakamı kaynağa karşı sha256 ile denetlendi, ve her onarılmış dosya el değmemiş sete karşı.

RAR çıkarma: 7 arşiv biçimi, 6 araç

Bu tablonun önceki ayağı biçim başına 100 MB ile 200 MB kullandı, ki bu bir hataydı: yaklaşık 28 ms'lik süreç başlatma, depolama kolunun %40'ıydı, ve ürettiği sıralama gerçekçi bir boyutta ayakta kalmıyor. Bu ayak biçim başına 1 GB yük, ve birkaç yanıtı değiştiriyor, kimisi ters yönde. Arşivler resmi rar 7.23 ile oluşturuluyor, böylece hiçbir araç kendi kodlayıcısından gelen girdide yargılanmıyor, ve aynı baytlar her makinede yarıştırılıyor.

Yükün içinde ne olduğu göründüğünden daha önemli. Blok kopyalarından oluşan bir yük, her sıkıştırılmış biçimi bir bellek-kopyalama kıyaslamasına çevirir; düz metinden oluşan bir yük onu bir yazı-tanıma-ve-Huffman kıyaslamasına çevirir; ikisini de ölçtük ve kazananda hemfikir değiller. Bu yüzden dört sıkıştırılmış biçim eşit üçte-bir metin, yapılandırılmış kayıt ve sıkıştırılamaz bayt kullanıyor, ve o aralığın uçlarındaki iki biçim kasıtlı olarak ayrı kollar: store sıkıştırılamaz ve repetitive neredeyse tümüyle eşleşme. Oluşturucu ve düzenek depoda, bu yüzden korpus bayt bayt yeniden inşa edilebilir.

1.2.2 motorunda 23 Ağustos 2026'da yeniden yarıştırıldı, ve tarama ayakta. Bir okuyucunun en çok tarttığı üç araç - bizimki, unrar 7.23 ve rarpar 0.2.5 - 32 çekirdekli masaüstünde sürüm motorunda (yarıştırılan çıkarma kodu 1.2.2 etiketine bayt-eşdeğer) yeniden yarıştırıldı, altı iç içe tur, araç başına asgari, her ayağın çıktısı yük manifestine karşı denetlendi. Saniye, düşük olan iyi:

Yedi biçimin tümü bizim, hem asgaride hem ortancada, unrar'a karşı 1,16 ile 4,29 kat arasında. Bu süreler aşağıdaki daha geniş tabloyla hücre hücre karşılaştırılabilir değil - düzenek o tablonun ayaklarından beri gözden geçirildi ve tur sayıları farklı - bu yüzden her tabloyu kendi içinde okuyun. Daha geniş tablo kendi tarihlerini ve altı-araçlı alanını koruyor, ve nzbfast sütunu 1.2.2'nin gönderdiği motoru anlatıyor: yukarıdaki yeniden yarış, güncel motoru o tablonun derlemesiyle yedi biçimin tümünde eşit ölçtü, donanım komut sayılarıyla çözüldü (aynı duvar için %0,14 daha az), bu yüzden o hücreler aşılmış bir derlemenin sayıları güncel bir etiket takınmış değil. Bu yeniden yarış, kurulum bölümündeki A/A kuralının kazanıldığı yer de. Aynı günkü bir geçiş önce bir biçimi kendi önceki derlememize karşı küçük bir gerileme olarak bildirdi, ve okuma her iki kol sırasını da koşturarak ayakta kaldı. Bir A/A kontrolü - aynı ikili dosyanın kendisiyle bayt-eşdeğeri bir kopyasına karşı yarıştırılması - düzeneğin ilk koşan kola yaklaşık %1,5'lik bir ceza verdiğini gösterdi: özdeş ikili dosya, ilk yuvadan yalnızca 15 turdan 6'sını kazandı, ve sıraları değiştirmek, her zaman ilk olana inen bir yanlılığı iptal etmiyor. Donanım komut sayıları, düzeneğin çözemediği soruyu çözdü - daha yeni derleme aynı duvar saati için %0,14 daha az komut çekiyor, yani gerileme yoktu. Şimdi yayımladığımız kendi-derlememiz-kendi-derlememize-karşı her karşılaştırma o kontrolü taşıyor.

Alanın tümü, saniye, düşük olan iyi. 3'ün en iyisi, araçlar her tur içinde bloklar halinde değil iç içe koşuldu, çıktı her tek koşuda kaynak yüke karşı denetlendi. Yanlış bayt üreten bir araç bir doğruluk notu alır, asla hızlı bir süre değil. rarpar, Weaver'ın kendi RAR ve PAR2 kodu, bd87611'de kaynaktan derlenmiş; sürümü değil taahhüdü sabitliyoruz çünkü paketleri üç farklı sürüm numarası taşıyor.

Alanın rekabet edemediği yer, ve sebebi. ¹ Burada yarıştırılan 7-Zip, her sıkıştırılmış biçimi ERROR: Unsupported Method ile reddeden ve macOS'ta yalnızca depolanmış olanı okuyan Homebrew paketi. Bu sayfanın önceki bir sürümü bunu 7-Zip'in macOS derlemesine bağlamıştı, ki bu yanlıştı: Homebrew onu ücretsiz olmayan unRAR kodeği olmadan derliyor, oysa 7-zip.org'un gönderdiği macOS derlemesi kodeği taşıyor ve Windows derlemesi gibi yedi biçimin de kodunu çözüyor. 14 Ağustos 2026'da yeniden ölçüldü. 7-Zip'i Homebrew'dan değil projeden kurarsanız, bu sütun sahip olduğunuzu anlatmıyor. ² bsdtar'ın RAR5 çok-ciltli desteği yok ve hata bildirmeden kesik bir dosya üretti, bu yüzden o kol yavaş bir süre değil bir doğruluk başarısızlığı; düzeneğimiz çıktıyı denetleyerek bunu yakaladı, ki bu çıktıyı denetlemenin neden değerli olduğu. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar hiçbir Windows komut satırı aracı göndermiyor, bu yüzden dizüstü alanı beş. ⁶ M5 Max grubu, bir macOS okuyucusunun gerçekten seçeceği üç aracı yarıştırıyor - unrar, rarpar ve biz; unar, bsdtar ve 7-Zip o makinede yarıştırılmadı. Onun unrar'ı 7.22, orada gözetimsiz koşan en yeni derleme.

Bir istisna dışında her makinede her biçim, ve o istisna bir berabere. Kısa-eşleşme biçimleri, kod çözücümüzdeki iki özel şeye dayanıyor. İki ile otuz iki bayt arasında bir eşleşme, platformun bellek-kopyalama yordamına tam bir çağrının bedelini öderdi ve çağrı kopyadan daha pahalıydı; onun yerine sabit otuz iki baytı bir yazmaç üzerinden kopyalamak, repetitive, solid ve 128 MiB sözlüğün - kısa eşleşmelerden kurulu üç biçim - hepsinin birden hızlı olmasının sebebi. Ve sağlama toplamı, yazıcının iş parçacığının üzerinde değil, ondan aşağıda akıyor. Açıkça kazanmadığımız tek hücre, 32 çekirdekli masaüstündeki depolanmış biçim, orada unrar ile biz salt bayt taşımadan ibaret bir kolda üç milisaniye arayla ayrılıyoruz - bu tablonun hassasiyetinde özdeş, bu yüzden iki hücre de işaretli ve bir kayıp da bir kazanç da değil bir berabere olarak puanlanıyor.

En büyük farkla kazandığımız biçim, usenet'in gerçekte aynı anda yüzlercesini gönderdiği biçim: 400 küçük dosya, unrar'a karşı 4,3× ve 4,4× ve rarpar'a karşı 5,4× ile 5,5×. Bu, üye-başına paralellik, ve bu bir indirme kuyruğu için yazılmış bir çıkarıcı ile bir komut satırı için yazılmış bir çıkarıcı arasındaki fark. Yukarıdaki sayımın baytların %84'ü dediği depolanmış biçim, üç ciddi araç için neredeyse bir berabere, çünkü o noktada herkes yalnızca bayt taşıyor.

Belirtmeye değer bir seçim. Arşivler dört iş parçacığına sabitlenmiş sıkıştırıcıyla paketleniyor. RAR'ın blok bölünmesi aksi halde paketleyen makinenin çekirdek sayısını izler, bu yüzden 32 çekirdekli bir kutu ile 20 çekirdekli bir kutu aynı girdiden farklı baytlar üretir ve makineler karşılaştırılabilir olmaktan çıkar. Onu sabitlemek, çıkarma korpusunu her yerde bayt-eşdeğer yapar, ki mesele bu, ama açmanın ne kadarının paralel koşabileceğini de sınırlar - bu yüzden en yakın iki biçim kayıpken, bu sabitlemenin sebep olup olmadığını denetlemek için onları 32 iş parçacığının tümüyle paketlenmiş arşivlere karşı yeniden yarıştırdık. Değildi: solid %4,2 gerideyken %2,4 gerisine, 128 MiB sözlük ise %6,6'dan %6,3'e geldi, sıralama her iki durumda da aynı. Her ikisi de artık sabitlenmiş korpusta, o denetimin açıklayabileceğinden daha geniş bir farkla kazanıyor.

Neden RAR4 satırı yok, ve o gönderilere ne olur. Yukarıdaki her biçim RAR5 ya da RAR7, ki usenet bugün bunu gönderiyor. Daha eski RAR4 arşivler hâlâ ortaya çıkıyor, ve aynı motor onları, sıkıştırılmış ve parolalı biçimleri dahil, birimleri diske yazıp sonra açmak yerine daha yenilerle aynı tek geçişte okuyor. Burada bir satırları yok çünkü resmi rar 7.23 artık RAR4 oluşturamıyor, bu yüzden alanı yarıştıracak yansız bir korpus yok; o iş bunun yerine WinRAR 3.00 tarafından yazılmış arşivlere karşı, unrar'a karşı bayt bayt denetleniyor.

PAR2 doğrulama ve onarım: 1 GiB'lik set, dört hasar düzeyi

Korpus: 21 RAR birimine depolama modunda paketlenmiş 1 GiB rastgele yük, sonra %10 fazlalıkta biri 1 MiB bloklu biri 64 KiB bloklu iki PAR2 seti, sonra sabit hasar haritaları. Her koşu aynı protokolü kullanıyor: taze kopya, önbelleği ısıtmak için tüm korpusu bir kez okumak, sonra ölçmek. İç içe üç turun en iyisi; her onarılmış birim her turda el değmemiş sete karşı karşılaştırılıyor. Düşük olan iyi.

Korpus hakkında bir düzeltme, çünkü bu sayfanın önceki bir sürümü onu abarttı. Her makinenin hash ile denetlenen bayt-eşdeğeri bir korpus koşturduğunu söylemiştik. Her setin her biriminin hash'ini almak bunun 32 çekirdekli masaüstü ve tam olarak eşleşen Windows dizüstü için doğru, 20 çekirdekli masaüstü için değil olduğunu gösteriyor, o aynı biçimin farklı bir rastgele çekilişini tutuyor: aynı boyutlarda aynı 21 birim, aynı iki blok boyutu, ve aynı dosya sayısına yayılmış aynı 3, 101 ve 1.500 blokta doğrulanan hasar. Bir satır içindeki her rakam yine de o satırdaki her aracın paylaştığı baytlar üzerinde ölçülüyor, ki her karşılaştırmanın dayandığı şey bu. Ama satırlar bir girdinin dört görünümü değil, ve yük karakteri bir rakibin taramasına yaklaşık %7 değdiği için, bunu göz ardı etmek yerine belirtmeye değer.

Hangi par2 hangisi. Orijinal par2cmdline, herkesin çatalladığı referans uygulama. par2cmdline-turbo, ParPar'ın elle yazılmış SIMD Galois-alanı çekirdeklerini paketleyen çatal: "turbo"nun tam olarak anlamı bu, ve orijinal yerine turbo'nun neden ölçülmeye değer araç olduğu bu. Aşağıdaki her iki turbo sütunu da aynı ParPar çekirdeklerini koşturuyor. İkisini ayıran şey aritmetik değil, derleme ve bayraklar.

24 Ağustos 2026'da gönderilen derleme güncel rakibe karşı doğrulandı. Bu tablolar 1.2.2 kesilmeden ve par2cmdline-turbo 1.5.0'ı yayımlamadan önce (20 Ağustos 2026) ölçüldü, bu yüzden 20 çekirdekli sütun her ikisine karşı da yeniden yarıştırıldı: 1.2.2 sürüm derlememiz turbo 1.5.0'a karşı, ayak başına iç içe üç tur, her onarılmış dosya el değmemiş sete karşı karşılaştırılarak. Dört ayağın dördü de yeniden üretiyor - bizimki 0,18 / 0,30 / 0,75 / 2,02, burada basılı 0,19 / 0,33 / 0,74 / 2,07'ye karşı, ve turbo 1.5.0 her ayakta ve her iki yapılandırmada da tablodaki derlemenin birkaç yüzde içine iniyor. Hücreler yayımlandığı gibi duruyor; diğer üç makine kendi tarihlerini koruyor.

Yani rakip iki kez beliriyor, ve o sütunlardan biri kendi varsayılanı değil en iyi durumu. İndireceğiniz sürüm ikili dosyası genel bir taban CPU için derlenmiş ve aynı anda yalnızca birkaç dosyayı hash'liyor; aynı kaynağı gerçek anamakine CPU'su için derleyip -T16 geçirmek, o makinenin gerçekten sahip olduğu komutları kullanmasına ve aynı anda on altı dosyayı hash'lemesine izin veriyor. Dizüstünde bu, salt derleme ve bayraklardan 2,6 kata kadar değer. Bizi ayarlanmış sütunda yargılayın, ki bu daha zor karşılaştırma; gönderilen sütun ise onu indiren birinin gerçekte yaşadığı şey. par2cmdline orijinali, sürüm 1.2.0, her makinede kaynaktan derlenmiş. rarpar, Weaver'ın Metal GPU arka ucu etkin kaynaktan derlenmiş kendi PAR2 uygulaması. MultiPar'ın par2j'si yalnızca Windows, bu yüzden yalnızca Windows dizüstü satırlarında beliriyor. M5 Max satırları, iki turbo sütununun yanında güncel macOS arm64 derlemeli iki aracı yarıştırıyor; par2cmdline klasiği o makinede yarıştırılmadı.

On altı nzbfast hücresinin tümü - dört makinede dört hasar düzeyi - bizim, ayarlanmış derlemeye karşı çoğu 2×'den fazla, ve gerçekte indireceğiniz derlemeye karşı 2,3× ile 7,7× arasında. Ağır-hasar hücreleri ilginç olanlar, ve aşağıdaki not arkalarındaki algoritmayı anlatıyor.

Orijinal tabloya geri döndü, ve çatalın neden var olduğunu görmeye değer. Bu sayfanın önceki bir sürümü par2cmdline sütununu, turdaki her şeyden yavaş olduğu gerekçesiyle düşürmüştü, ki bu doğru ve yeterince iyi bir gerekçe değil: bu, neredeyse her başka aracın türediği uygulama, ve okuyucular bizim onun hakkındaki iddiamız yerine tabanı hak ediyor. En ağır hasar düzeyinde yaklaşık 69 s alıyor, SIMD çatalının 3,2 s ve bizim 3,1 s aldığı yerde. O yirmi kat faktör, elle yazılmış Galois-alanı çekirdeklerinin tüm gerekçesi, ve bu bizimki için yaptığımız aynı gerekçe.

Hafif hasar önemli olan durum. Bir avuç başarısız makale, 101 ölü bloktan çok daha tipik, 1.500'e hiç benzemiyor. Hafif bir onarımın çoğu Reed-Solomon matematiği bile değil, bir gigabaytı okumak ve MD5'lemek, bu yüzden 3-bloklu satır onarım satırları yerine temiz-doğrulama satırını izliyor.

En ağır hasar düzeyi farklı bir tür iş, ve farklı bir algoritma alıyor. O son düzey, 21 birimin tümünde 1.500 bloğu hasarlıyor ve fazlalık verisinin yaklaşık %91'ini tüketiyor, ki burası Reed-Solomon aritmetiğinin, hash'leme ya da diskin değil, işin neredeyse tamamı olduğu yer. Gönderilen derleme, en ağır onarımları klasik Galois-alanı katlaması yerine bir sayı-teorik dönüşümle hesaplıyor - yüksek blok sayılarında çok daha iyi ölçeklenen bir biçimde değerlendirilen aynı matematik: 20 çekirdekli masaüstünde ayarlanmış derlemenin 2,7× önünde, ve Windows dizüstünde ayarlanmış derlemenin 2,7× ve MultiPar'ın 2,2× önünde. Hafif hasar hâlâ klasik yolu koşuyor, ki bu diğer düzeylerin neden neredeyse hiç kıpırdamadığının sebebi: dönüşüm ancak yaklaşık 512 hasarlı bloğun üzerinde karşılığını veriyor, bu yüzden onun altında sevk edici onu kullanmıyor.

Daha hızlı bir yol, ancak yanlış olamıyorsa değerlidir. Her iki yol da aynı niceliği hesaplıyor ve kuruluş gereği bit-özdeş, ve bu sayfadaki her onarım, yeniden inşa edilen dosyaların el değmemiş sete uymasına göre geçitlendi: bu ayaktaki makinelerde 228 zamanlanmış onarım, sıfır uyumsuzluk. Gönderilen derleme o kayıta güvenmiyor. Her onarım kendi çıktısını dosya hash'lerine karşı doğruluyor, ve başarısız olan biri otomatik olarak klasik yolla yeniden yapılır, sapmayı günlükler, ve o koşunun kalanı için klasik yolu korur. Ayar, hiç istemeyenler için panoda Hızlı PAR modu olarak var, ve bunun için yeterince belleği olmayan makineler denemek ve başarısız olmak yerine kendiliğinden reddediyor. 2 Ağustos'ta güncel derlemede yeniden ölçüldü: iki masaüstü bu tablonun birkaç yüzdesi içine iniyor, ve Hızlı PAR modu kapatıldığında 20 çekirdekli masaüstü tam olarak klasik yolun daha yavaş süresine geri düşüyor, ki bu kazananın koşullar değil yöntem olduğunu söylüyor.

Windows dizüstünün sütunu bir düzeltme gerektirdi, ve bu bizim aleyhimize. Windows, birkaç saniye içinde sürdürülen arka plan işini verimlilik çekirdeklerine indiriyor. Bizim daemon'umuz başlangıçta bundan çıkıyor ve diğer araçların hiçbiri çıkamıyor, bu yüzden bu sayfanın önceki bir sürümü onların kısılmış sürelerini sanki araçların kendi süreleriymiş gibi yayımladı. O makineyi her aracı yüksek önceliğe kaldırarak yeniden koşturmak tüm alanı hareket ettiriyor: en ağır hasar düzeyinde par2-turbo 22,4 s'den 6,41'e, rarpar ise 59,2 s'den 14,4'e gidiyor, ve bu sayfanın bir kesimi için bu, sütunu bizimkinden kaybettiğimiz bir sütuna çevirdi. Tüm dizüstü sütunu artık o şekilde ölçülüyor - düzeltme, yukarıdaki algoritma değişikliğiyle satır geri kazanılmış olsa bile kalıyor, çünkü o makinedeki alanın süreleri ancak kısıtlama kaldırılınca dürüst.

RAR kurtarma kayıtları: PAR2 olmadan onarım

PAR2 hasarı kapsayamadığında, RAR'ın kendi içindeki kurtarma kaydı son savunma hattıdır. 1.0.8'e kadar bizimki yaklaşık 13 MB'ın üzerindeki her arşivde başarısız oluyordu, bu yüzden bu ayak hiç koşturulamıyordu. Hasar, korunan bölge boyunca %20, %50 ve %80'de üç adet 3.000 baytlık delik. Her iki araç da el değmemiş dosyaya bayt-eşdeğer çıktı üretti, ve bizimki rar r'ın kendisinin yazdığına bayt-eşdeğer. 3'ün en iyisi, 32 çekirdekli masaüstü, her iki araç da 2 Ağustos'ta birlikte yeniden yarıştırıldı.

Bu sayfanın önceki bir sürümü 512 MB boyutunu bir kayıp olarak gösteriyordu, ve bunu birimin tamamını bellekte tutmak yerine parça parça çalışmanın bedeli olarak açıklıyordu. O açıklama o zaman doğruydu ve şimdi geçersiz: bedel onarım yolundaki bit-seri bir CRC64'tü, tablo güdümlü biriyle değiştirildi, ve kayıp onunla birlikte gitti. Artık bir geçiş noktası yok, ve sınırlı çalışma seti korundu. 2 GB boyutu burada, çünkü bir daemon'un gerçekte karşılaştığı birimler 512 MB değil 8 GB ile 20 GB arasında, ve gerçek aralığın altında duran bir kol pek bir sınav sayılmaz.

Bu kesimi ne hareket ettirdi, ve bunu söyleyen kontrol. Hangi blokların hasarlı olduğunu bulmak bu onarımın en büyük aşaması hâline gelmişti - onarım aritmetiğinin kendisinden bile büyük - ve tek bir iş parçacığında koşuyordu, dosya boyunca her grubun 64 KB'ını grup başına bir kez okuyarak. Şimdi parça-başına sağlama toplamları paralel hesaplanarak dosya sırasında tek bir sıralı geçiş yapıyor, ve dosya sisteminin yapabildiği yerde onarılan birim kopyalanmak yerine klonlanıyor. Saptama tek başına 512 MB'lık arşivde yaklaşık 300 ms'den 18 ms'ye düştü, ki bu yukarıda hareket edenin çoğu. Kontrol, bizimkinin yanındaki sütun: rar r aynı makinede aynı turlarda yeniden yarıştırıldı ve önceki sürelerinin birkaç yüzdesi içine geri döndü, bu yüzden aradaki farkta değişen bizimki, kıyaslama değil.

M5 Max, aynı korpus ve geçitlerle 31 Temmuz'da yarıştırılan örüntüyü tekrarlıyor: 16 MB'tan 512 MB'a kadar boyutlarda 0,050 / 0,066 / 0,171 / 0,581 s, rar r'ın 0,211 / 0,335 / 0,751 / 1,735'ine karşı - 3,0× ile 5,1× arasında daha hızlı; 2 GB boyutu o makinede yarıştırılmadı. Bu rakamlar yukarıda anlatılan saptama yeniden yazımından önce, bu yüzden burada güncel bir rakam değil eski derlemenin ikinci makine olarak tutulan rakamları.

Weaver'ın rarpar'ı yalnızca bu tablodan yok, ve bu bir seçim değil: bu onarımı uygulamıyor. Bu arşivlerden birini onarması istendiğinde "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data" yanıtını veriyor, ve dosyayı hasarlı bırakıyor. Bu sayfadaki her başka karşılaştırmada beliriyor: yukarıdaki dört PAR2 ayağının tümünde, ondan önceki yedi çıkarma biçiminin tümünde, ve hemen aşağıdaki, kendi yaptığını söylediği - ve kazandığı - kurtarma birimi kolunda.

Kurtarma birimleri: eksik tüm .rev dosyalarını yeniden inşa etmek

RAR'ın kendi kurtarma hikayesinin öteki yarısı, ve bu ayağa kadar bu sayfadaki en büyük kayıp. Bir .rev dosyası bağımsız bir kurtarma birimidir: 21 ciltlik bir setin yanında üç tanesi, hiç gelmeyen herhangi üç birimi yeniden inşa edebilir. Korpus: rar rv3 ile 21 birime, 50 MB'lık, depolanmış 1 GiB, sonra 4, 11 ve 19 numaralı birimler silindi - üç kurtarma birimine karşı üç kayıp, ki bu setin hâlâ atlatabileceği en kötü durum. 3'ün en iyisi, her yeniden inşa edilen birim el değmemiş olana karşı karşılaştırıldı.

Buradaki 32 çekirdekli hücre, bu sayfanın önceki kesiminde rar rc'nin 0,47'sine karşı 3,12 s'ydi, 6,6× daha yavaş ve üzerindeki en kötü rakam olarak yayımlanmıştı. Sebep, silme çözümünün RARLab'ın yönettiği 320'ye karşı yaklaşık 48 MB/s'lik yeniden inşa edilen çıktıda koşmasıydı; şimdi kurtarma kodunun geri kalanıyla aynı tablo güdümlü aritmetikte koşuyor, ki bu yedi kat bir iyileşme ve kaybı her iki makinede de bir kazanca çeviriyor. Farklar %3 ve %14, bu yüzden bu manşete çıkarmak yerine açıkça söylenecek bir kazanç, ve hiç söylenmesinin sebebi kaybın önce söylenmiş olması.

Bu kol var, çünkü Weaver'ın rarpar'ı tam olarak bunu uyguluyor ve bununla ölçülmeyi istedi. Onu ilk yayımladığımızda rahatça kazanıyordu, ve o sebeple o zaman yayımladık.

Dosya eşleştirme hiçbir zaman bedel olmadı, ki bu kaydetmeye değer çünkü sezgisel şüpheliydi: kurtarma birimleri hiçbir dosya adı taşımaz, bu yüzden hangi yuvaların hayatta kaldığını, ne çağrıldıklarına güvenmek yerine diskteki her birimi sağlama toplayarak belirliyoruz, ve yalnızca eşleştirmenin gerçekleştiği hasarsız bir sete karşı, tüm geçiş 0,18 s sürüyor.

Başka ne hareket etti, ve nerede görünmüyor. Bu korpusların göremediği iki motor değişikliği daha geldi, burada listeleniyor ki yukarıdaki sayılar tüm hikaye olarak okunmasın: onlarca binlerce üyeli RAR5 arşivleri her üyeyi işçi başına listeyi yürümek yerine bir kez çözümlüyor, ki bu 40.000 üyede 3× daha az işlemci süresi; ve RAR1.3 bit okuyucusu bir kerede bir sözcük çalışıyor, ki bu 2×. İkisi de yukarıda belirmiyor, çünkü buradaki biçimlerin 400 üyesi var ve hiç RAR1.3 yok.

Kasıtlı olarak yapmadığımız şey: hiçbir zaman PAR2 oluşturmuyoruz. Bir indiricinin buna sebebi yok, ve o kolu ParPar sahipleniyor. Ayrıca her iki motorda da hızı bellekle satın alıyoruz: çıkarma unrar'ın 41 MB'ına karşı 240 MB civarında zirve yapıyor, ve doğrulama turbo'nun 7 MB'ına karşı 126 MB civarında, çünkü bunlar tek seferlik bağımsız araçlar değil canlı bir indirmenin üzerinde yürüyen iç motorlar. 128 MiB-sözlük biçimi bunun en kötüsü, unrar'ın 139 MB'ına karşı yaklaşık 304 MB'ta. En ağır onarım artık belleğe de mal oluyor: 512-ve-üstü eksik blok için daha hızlı yöntem, bellekte tutulan kurtarma verisinden çalışıyor, bu yüzden makinenin RAM'inin dörtte birine kadar izinli, 4 GB'ta tavanlı, ve ayıracak yeri olmayan bir makine sessizce düşük-bellek yöntemini alıyor - PAR2 tablosunun orta satırlarıyla aynı aritmetik ve aynı süreler, yalnızca sonuncudaki 3× değil. Tek seferlik bir iş için mümkün olan en küçük mukim seti istiyorsanız, özel araçlar o sütunu hâlâ kazanıyor.

Aktarım kanıtı · 1.2.2'de ölçüldü

Motor gerçek hatlara yetişir

• 10 GbE bir hatta beş sağlayıcılı bir filo boyunca sürdürülen ~8,7 Gbps, akış içi doğrulama ve çıkarma dahil - yukarıdaki 87 GB ayağı, 24 Ağustos 2026, v1.2.2, 360 bağlantı: 71 s'de 77,4 GB ağ trafiği, yük geldikçe doğrulanmış ve çıkarılmış olarak. Bir patlama rakamı değil: o hızda işin tamamı.
• 1 Gbit ve altında hat sınırdır ve nzbfast onun üzerinde oturur: doğrulama ve çıkarma boyunca 500 Mbit'lik bir hattın ~%96'sı ve 250 Mbit'lik bir hattın ~%96'sı, her rakibin belleğinin ve diskinin bir kesrinde - yukarıdaki gigabit-altı bölüm.
• 87 GB'lık işte iş bütünü için işlemci bedeli GB başına 1,7 CPU-saniyesi bağlantı denetleyicisi açıkken - TLS üzerinden indirme, doğrulama, onarım-hazırlığı ve çıkarma dahil - aynı ayakta alan için 3,0 ile 28 arasındaki rakama karşı; yukarıdaki tam-verimli kol 4,3 harcıyor.

Bu sayfanın daha önceki kesimleri daha geniş bir aktarım gösterimi seti taşıyordu - çok-hatlı doygunluk koşuları, RTT başına hatlama kazançları, bir geri-basınç kanıtı, kod-çözme-tavanı ölçümleri - v1.2.2'nin o zamandan beri aştığı derlemelerde yarıştırılmış. Bu sayfanın kuralı altında yaşlanmaya bırakılmak yerine emekliye ayrılıyorlar, ve güncel sürümde yeniden kesildikçe geri dönüyorlar; yukarıdaki üç iddia v1.2.2'de zaten yeniden ölçülenler.