محک‌ها

نسخهٔ کوتاه · اندازه‌گیری‌شده 23 اوت 2026 روی خط کدی که به‌عنوان nzbfast 1.2.2 منتشر شد

هیچ کلاینت اندازه‌گیری‌شده‌ای روی پردازنده، حافظه و دیسک با هم ارزان‌تر نیست

تازه‌ترین دورهای این صفحه در 23 و 24 اوت 2026 اجرا شدند - تازه‌ترینشان روی خودِ ساخت انتشار v1.2.2 - در برابر ساخت‌های فعلی چهار کلاینت دیگر روی سخت‌افزار، خط‌ها و ارائه‌دهنده‌های یکسان: دو شکل کار از 6.5 تا 87 GB، و نرخ‌های خط از 250 مگابیت تا 10 GbE. در آن دورها هیچ کلاینتی روی پردازنده، حافظه و دیسک با هم از nzbfast ارزان‌تر نبود: هر کدام روی دست‌کم دو محور از آن سه بیشتر هزینه دارد، بیشترین صرفه‌جویی هر کدام روی هر محور تنها حدود 2 درصد بود - یک تساوی آماری، درون گسترهٔ اجرا-به-اجرای خودِ آن کلاینت - و روی دیسک هر کدامشان دست‌کم دو برابر بایت را برای نتیجهٔ بایت‌به‌بایت یکسان جابه‌جا کرد. در تنظیمات کارخانه، nzbfast همچنین کمترین حافظهٔ هر کلاینت اندازه‌گیری‌شده را در هر آزمون داشت، با نسبت 2.0 تا 4.5 برابر در برابر نزدیک‌ترین رقیب.

کدام‌یک شمایید؟

بیشتر دانلودکننده‌ها دانلودتان را دست‌کم دو بار روی دیسک می‌نویسند: یک بار حین دانلود، و بار دیگر حین باز کردنش. nzbfast تمام کار را در یک گذر انجام می‌دهد، پس حدود نصف بایت‌ها را در هر کار می‌نویسد، حین کار حافظهٔ کمتری نگه می‌دارد، و ثانیه‌های پردازندهٔ کمتری برای هر GB خرج می‌کند. یعنی بار کمتری روی ماشین حین استفاده‌تان و نصف نوشتن روی درایوهایتان در هر کار، برای همان فایل‌های بایت‌به‌بایت یکسان - و چون هر بایت تقریباً یک بار از دیسک عبور می‌کند، درایوتان فقط باید یک بار با خطتان همراهی کند.

‏nzbfast هر جدول این صفحه را نمی‌برد، و مواردی که می‌بازد زیر لِگ‌هایی که نمی‌بریم آمده‌اند - از جمله یکی از همین دور. آنچه در هر دوری که اندازه گرفتیم پابرجا ماند صورت‌حساب ترکیبی است.

اول روش‌شناسی

چیدمان آزمایش

• کلاینت‌ها: ‏nzbfast · SABnzbd · NZBGet · rustnzb · Weaver، هر جدول روی ساخت‌هایی که نام می‌برد. تازه‌ترین دورها (23 اوت 2026) ساخت‌های فعلی آن‌زمانِ این میدان را مسابقه دادند - SABnzbd 5.1.1، NZBGet 26.3-testing، rustnzb 1.4.5 و Weaver 0.7.8، تازه‌ترین باینری منتشرشده‌اش، هویت با هش اثبات‌شده - در برابر خط کدی که همان شب به‌عنوان nzbfast 1.2.2 منتشر شد، پس ساختی که این عددهای تازه را تولید کرد همان است که می‌توانید دانلود کنید. آن دورها روی یک ماشین اپل‌سیلیکون 20 هسته‌ای روی یک خط 1 گیگابیت اجرا شدند. جدول‌های قدیمی‌تر ساخت‌ها و ماشین‌هایی را که مسابقه داده‌اند نگه می‌دارند («اروپا» M1 Ultra روی 10 GbE، «ساحل شرقی» M3 Ultra خط ~2.4 تا 3.0 گیگابیت بر ثانیه، هر دو از سری M اپل) و این را می‌گویند؛ آنها ساخت منتشرشده را دست‌کم می‌گیرند نه آنکه بزرگ‌نمایی کنند.
• انصاف: ارائه‌دهنده‌ها و TLS یکسان همه‌جا برای هر کلاینت، لِگ‌ها پشت‌سرهم و درهم‌تنیده اجرا می‌شوند. هر رقیب روی بهترین حالت مستندشدهٔ خودش تنظیم شد: SABnzbd ‏pipelining_requests=8 گرفت (خودش با 1 منتشر می‌شود، یعنی بدون پایپ‌لاین، و این تنظیم روی کارهای بزرگ ارزش دو-رقمی درصدی دارد)، NZBGet ‏ArticleCache/DirectWrite/DirectUnpack/ParQuick گرفت، rustnzb پیکربندی مستندشدهٔ خودش را گرفت. از 20 اوت 2026 هر دور پنج ارائه‌دهنده را مسابقه می‌دهد نه شش - شمار ارائه‌دهنده روی این ماشین‌ها اهرم توان عملیاتی نیست، جایی که یک ارائه‌دهندهٔ تنها می‌تواند به سقف خط برسد، و یک مجموعهٔ ثابت دورها را قابل‌مقایسه نگه می‌دارد - پس یک عدد شش-ارائه‌دهنده روی این صفحه مستقیماً با یک عدد پنج-ارائه‌دهندهٔ تازه‌تر قابل‌مقایسه نیست، و هر جدول می‌گوید کدام را اجرا کرده.
• وضعیت پایانی: یک فایل تأییدشده، استخراج‌شده و قابل‌استفاده، نه «دانلود تمام شد». آنچه واقعاً منتظرش هستید همین است.
• تکرارپذیری: هر ادعا تاریخ‌دار است و به یک روش اندازه‌گیری شده: زمان سپری‌شده + شمارندهٔ بایت رابط + اوج RSS درخت پردازه، با تفکیک 1 تا 2 ثانیه. هرجا یک لِگ روی یک NZB منتشرشدهٔ عمومی اجرا می‌شود، نامش را می‌بریم تا خودتان بتوانید اجرایش کنید.
• یادداشت‌های روش‌شناسی که در سراسر صفحه اعمال می‌شوند: زمان CPU روی هر بازوی یک جدول با نمونه‌برداری 2 هرتزی از درخت پردازه گرفته می‌شود و هرگز کنار عددی از حساب‌داری متفاوتی گذاشته نمی‌شود، چون این دو روش عمداً با هم توافق ندارند. ورودی/خروجی دستگاه به GiB و بایت‌های سیم به GB اعشاری نقل می‌شوند؛ پیش از تقسیم تبدیل می‌کنیم. و هر جدولی که ساخت خودمان را در برابر ساخت خودمان مسابقه می‌دهد یک کنترل A/A همراه دارد - همان باینری در برابر یک کپی بایت‌به‌بایت یکسان از خودش از میان همان سازوکار مسابقه - چون آن کنترل همان چیزی است که با آن دریافتیم سازوکار مسابقهٔ خودمان دارد به هر ابزاری که اول اجرا شود جریمه‌ای حدود 1.5٪ می‌دهد (داستانش کنار جدول‌های استخراج پایین‌تر آمده). دو بازو و ترتیب‌های جابه‌جاشده سوگیری‌ای را که همیشه روی بازوی اول می‌نشیند خنثی نمی‌کنند؛ یک کنترل A/A آن را افشا می‌کند.

خط‌های کندتر · اندازه‌گیری‌شده 24 اوت 2026 روی nzbfast 1.2.2

هر چه خط کندتر، سرعت کمتر کلاینت‌ها را جدا می‌کند - و صورت‌حساب بیشتر

روی خطی به‌اندازهٔ کافی کند، زمان پایان هر کلاینت همان سیم است و بس، پس یک خط کند خیلی از گناهان را پنهان می‌کند. آنچه نمی‌تواند پنهان کند این است که هر کلاینت برای پرکردنش چه می‌سوزاند. دستگاه 1 گیگابیت را به دو نرخی که برنامه‌های واقعی واقعاً دارند شکل دادیم و هر شش بازو را روی هر کدام مسابقه دادیم - همان ماشین، همان پنج ارائه‌دهنده، سه تکرار برای هر کلاینت با ترتیب چرخانده‌شده، هر لِگ بایت‌بررسی‌شده، 36 از 36 درست در سراسر دو دور. بازوی nzbfast روی 500 مگابیت خودِ ساخت انتشار v1.2.2 است.

دو جدول را به‌عنوان یک شیب بخوانید. روی 250 مگابیت کل میدان درون 18٪ روی ساعت می‌نشیند و ما نزدیک‌ترین رقیب را با 4.4٪ می‌بریم؛ روی 500 مگابیت فاصله به 14.7٪ باز می‌شود؛ روی نرخ‌های گیگابیت و 10 GbE در جدول‌های بالا و پایین بیشتر باز می‌شود. اختلاف سرعت با خط رشد می‌کند. ستون‌های منبع منتظر خط سریع نمی‌مانند: در هر نرخ اندازه‌گیری‌شده، هر رقیب دست‌کم 3.9 برابر حافظه نگه داشت، پردازندهٔ بیشتری خرج کرد، و تقریباً دو برابر بایت‌های دیسک را برای همان فایل بایت‌به‌بایت یکسان جابه‌جا کرد.

تنظیم‌کنندهٔ اتصال روی خط‌های کند ارزشش را نشان می‌دهد، و شمارندهٔ افت خودِ شکل‌دهنده می‌گوید چرا. تنظیمات کارخانه 25 اتصال نگه داشت جایی که هر رقیب صدها اتصال اجرا کرد؛ همان باینری با تنظیم‌کنندهٔ خاموش 360 اجرا کرد. جریان‌های کمتر از میان صفی ثابت یعنی افت کمتر و ارسال‌مجدد کمتر: شکل‌دهنده حدود 4,200 افت برای هر لِگ محدودشده در برابر حدود 155,000 افت نامحدود روی 500 مگابیت ثبت کرد، و بازوی محدودشده سریع‌تر بود، 4.2 برابر سبک‌تر روی حافظه و 1.3 برابر سبک‌تر روی پردازنده در برابر وضعیت 360-سوکتی خودمان. اتصال بیشتر سرعت بیشتر نیست؛ زیر یک گیگابیت قابل‌اندازه‌گیری برعکس آن است.

اندازه‌گیری‌شده 24 اوت 2026، میانه‌های سه اجرا، روی یک ماشین اپل‌سیلیکون 20 هسته‌ای با خطش شکل‌داده‌شده به هر نرخ (نرخ شکل‌داده‌شده با یک کاوندهٔ مستقل پیش از هر دور تأیید شد: 248 و 496 مگابیت). بازوی ‏nzbfast روی 500 مگابیت ساختِ برچسب انتشار v1.2.2 است؛ دور 250 مگابیت ساعت‌ها زودتر روی همان خط کد اجرا شد. شمار بایت روی یک خط شکل‌داده‌شده از شمارندهٔ خودِ هر کلاینت خوانده می‌شود، هرگز از رابط شبکه (شکل‌دهنده افت می‌دهد و TCP ارسال‌مجدد می‌کند، پس رابط هر دو کپی را می‌شمارد). ساعت‌ها درون هر جدول قابل‌مقایسه‌اند، نه در سراسر دورهای شکل‌داده‌شدهٔ متفاوت. ¹ سه لِگ NZBGet روی 500 مگابیت از 114 تا 158 ثانیه گسترده بودند با خوانش‌های منبع ثابت - یک گسترش واقعی، پس میانه نقل می‌شود و گسترش گفته می‌شود به‌جای باریک‌شدن.

پست آسیب‌دیده · دوباره‌مسابقه‌داده‌شده 24 اوت 2026، هر ساخت فعلی

وقتی پست سوراخ دارد: 6.5 GB با 60، 20 و 5 مقالهٔ مرده

مقاله‌ها منقضی می‌شوند، سرورها بی‌سروصدا آنها را می‌اندازند، آپلودها ناقص فرود می‌آیند - و آسیب جایی است که فاصلهٔ میان کلاینت‌ها گسترده‌ترین است، پس دور خودش را روی تازه‌ترین ساخت هر کلاینت می‌گیرد، nzbfast v1.2.2 هم جزوشان: ماشین اروپا 10 GbE، پنج ارائه‌دهنده، 100 اتصال برای هر کلاینت، همان انتشار 6.5 GB مسموم‌شده در سه سطح آسیب، سه تکرار برای هر بازو با ترتیب متناوب، هر لِگ در برابر فایل پاک بایت‌بررسی‌شده. 63 از 65 لِگ بایت‌به‌بایت یکسان برگشتند؛ آن دویی که نه، پایین‌تر نام برده شده‌اند، چون خودشان نتیجه‌اند.

چرا پست آسیب‌دیده اینجا سریع است. وقتی مقاله‌ای گم است، یک کلاینت معمولاً از سرور بعدی می‌پرسد، بعد بعدی، تا هر سرور آن را رد کند - یک پیمایش پیاپی که ردهایش از دهها میلی‌ثانیه تا چند ثانیه هرکدام طول می‌کشد، حین آن دانلود روی صفر می‌نشیند. ‏nzbfast پرسیدن را متوقف می‌کند: به‌محض آنکه دادهٔ پاریتیِ از پیش در دست چیزی را که هنوز گم است پوشش دهد، فوراً ترمیم می‌کند به‌جای تمام‌کردن پیمایش. این سطر دوم است - همان باینری با آن رفتار خاموش 1.4 تا 2.3 برابر کندتر است بسته به آسیب - و دور تأیید کرد که سازوکار روی هر لِگ فعال درگیر شد و هرگز روی یک لِگ غیرفعال نه. در برابر نزدیک‌ترین رقیب فاصله 2.4 تا 2.7 برابر است، بدون هم‌پوشانی در هیچ‌کدام از نه جفت تکرار.

دیسک جایی است که فاصله گسترده‌ترین است، و ترفند ترمیم نیست. هر بازوی تمام‌کننده همان فایل 6.48 GB را تولید کرد؛ مال ما 6.2 تا 6.8 GB ورودی/خروجی دیسک برایش جابه‌جا کرد، NZBGet 12.7 تا 18.5 GB، SABnzbd 13.9 تا 20.3 GB و rustnzb 12.8 تا 13.1 GB. این خط لولهٔ یک‌گذر است - سطر خاموش‌شده همان 6.2 GB را جابه‌جا می‌کند - پس روی پست‌های آسیب‌دیده و آسیب‌ندیده یکسان پابرجاست.

¹ سه لِگ SABnzbd روی سنگین‌ترین آسیب 43، 41 و 60 ثانیه اجرا شدند - یک گسترش واقعی روی ورودی‌های یکسان، پس میانگین با گستره‌اش نقل می‌شود. ² ‏rustnzb 1.4.5 هر لِگ را بایت‌درست تحویل داد، و هزینه‌اش در زمان پردازنده می‌نشیند نه قابلیت‌اطمینان: حدود 1,620 ثانیهٔ پردازنده در برابر ساعت 107 ثانیه روی سنگین‌ترین آسیب - تقریباً پانزده هسته مشغول در سراسر کل لِگ - جایی که همان خروجی ترمیم‌شده برای ما حدود 50 ثانیهٔ پردازنده هزینه دارد. ³ ‏Weaver 1.5 ‏GB و 4.9 GB از 6.5 را درون سقف 20-دقیقه‌ای ما روی دو سطح سنگین‌تر آسیب جابه‌جا کرد - همان تمام‌نشدنی که در هر سه دوری که با آن مسابقه داده شده، روی سه شب جداگانه، دیده شده؛ سقف مال ماست و تمام‌نشدن نتیجه است. روی 5 مقالهٔ مرده هر سه بار درست تمام کرد. هزینهٔ پردازنده‌اش آنجا داستان خودش است: حدود 2,325 ثانیهٔ پردازنده برای لِگ 194 ثانیه‌ای، در برابر 20 مال ما.

اندازه‌گیری‌شده 24 اوت 2026، هر ساخت فعلی: ‏nzbfast v1.2.2 (خودِ برچسب انتشار)، NZBGet 26.3-testing (ساخت 20 اوت)، SABnzbd 5.1.1، ‏rustnzb 1.4.5، Weaver 0.7.8. یک بازوی پیوستگی ساخت nzbfast شب پیش را درون همین دور مسابقه داد و روی هر فیکسچر درون یک ثانیه از v1.2.2 نشست، پس چیزی اینجا سوار یک شب خوش‌شانس نیست؛ و پیکربندی‌های رقیب فقط در مسیر برنامه از دور پیشین فرق دارند، پیش از اجرای دور کلیدبه‌کلید بررسی‌شده.

گرسنه‌نگه‌داشتنش از RAM · اندازه‌گیری‌شده 24 اوت 2026 روی nzbfast 1.2.2

نردبان حافظهٔ کم: 87 GB در ~0.3 GB از RAM

همان کار 87 GB دور بالا، دوباره‌اجراشده روی بودجه‌های سخت حافظهٔ 2 GB، 1 GB و 256 MB - چیزی که خودکار-اندازه‌گیر روی یک ماشین 8 GB، یک ماشین 4 GB، و یک NAS 2 GB انتخاب می‌کند. هر لِگ همان فایل بایت‌بررسی‌شده را تولید کرد، و ستون حافظه بودجه را ردیابی کرد، هرگز کار را:

یک لِگ تنها برای هر بودجه روی ساخت انتشار، بسته‌بندی‌شده در برابر همان چک‌سام خروجی دور شش‌بازویی. تنگ‌ترین بودجه حدود 9٪ ساعت هزینه دارد، و فقط چون این خط 10 GbE است - بلوک‌های سرریزشده تنها وقتی زمان هزینه دارند که خط از دیسک جلو بزند، پس روی یک اتصال خانگی معمولی یک بودجهٔ کوچک نزدیک رایگان است. کل نردبان، با دانلود 87 GB هم جزوش، در 0.3 تا 0.6 GB از حافظه جا می‌گیرد؛ با تنظیمات کارخانه کار در 286 MB اجرا شد. هیچ کلاینت دیگری بودجهٔ سخت حافظهٔ کل-پردازه ارائه نمی‌دهد؛ نزدیک‌ترین چیزها تنظیمات اندازهٔ کش‌اند، و دور پایین‌تر هزینهٔ آنها را اندازه می‌گیرد.

گیره در برابر تنظیمات خودِ میدان مسابقه داده شد. روی فیکسچر 34 GB (23 اوت 2026، ماشین 1 گیگابیت، پنج ارائه‌دهنده، 30 از 30 لِگ بایت‌درست)، نگه‌داشتن NZBGet روی یک گیرهٔ کش هم‌ارز پردازنده‌اش را بیش از دو برابر کرد (215.5 به 453.0 ثانیهٔ پردازنده، 2.10 برابر) تا یک کاهش 52٪ در اوج حافظه‌اش بخرد، و گیرهٔ SABnzbd تقریباً رایگان بود اما فقط بخشی از ردپایش را رساند. تنظیم کش rustnzb روی ساخت مسابقه‌داده‌شده تزئینی بود، و Weaver هیچ گیرهٔ حافظه‌ای اصلاً ندارد، پس هر دو بی‌گیره به‌عنوان ستون‌های مرجع اجرا شدند به‌جای آنکه روی بودجه‌ای که نمی‌توانند نگه دارند نمره بگیرند. سمت خودِ ما از آن دور با نردبان v1.2.2 بالا جایگزین شده، که همان چیز را روی 2.5 برابر اندازه می‌گوید: بودجه هرگز محدودیت مقیدکننده نیست، چون یک‌گذر از ابتدا این‌قدر کم نگه می‌دارد.

فضای آزاد · اندازه‌گیری‌شده تا مگابایت

یک کار چه‌قدر فضای آزاد کم می‌خواهد

کلاینتی که می‌نویسد-و-بعد-باز-می‌کند هم‌زمان به جا برای جلدهای آرشیو و هم محمولهٔ بازشده نیاز دارد، پس یک کار بدون تقریباً دو برابر حجم دانلود فضای آزاد شروع نمی‌شود. یک‌گذر به محموله نیاز دارد - و این دور اندازه گرفت چه‌قدر بیشتر، با کوچک‌کردن جلد هدف تا هر کلاینت شکست بخورد. پاسخ nzbfast ثابتی حدود 50 MB فضای اضافه است، نه یک نسبت، و از یک کار 6.5 GB تا یک کار 34 GB پابرجا می‌ماند.

اندازه‌گیری‌شده روی یک ماشین اپل‌سیلیکون 20 هسته‌ای، خط 1 گیگابیت، پنج ارائه‌دهنده، سه تکرار روی هر مرز، هر لِگ تمام‌شده بایت‌بررسی‌شده - سطرهای رقیب در 22 تا 23 اوت 2026 (سلول 34 GB وِیوِر در 24 اوت دوباره اجرا شد، پانویس 1)، و سطر nzbfast دوباره‌بریده‌شده روی ساخت انتشار v1.2.2 در 24 اوت، که هر دو مرز را دقیقاً بازتولید کرد، 12 از 12 لِگ هم‌رأی در سراسر دو فیکسچر. سلول‌های ما یک کف اندازه‌گیری‌شده‌اند: کار با 48.6 MB و 51.0 MB فضای اضافه 3 از 3 تمام می‌شود، و حدود 17 MB زیر آن 3 از 3 رد می‌شود - پس کف در هر دو جهت واقعی است. آنچه کار واقعاً نگه می‌دارد روی خروجی به‌علاوهٔ حدود 3 MB می‌نشیند؛ فضای اضافه بابت آخرین لحظه‌های خط لوله پرداخت می‌شود، هرگز بابت یک کپی دوم. سلول‌های رقبا کف اندازه‌گیری‌شدهٔ آنها روی کار 6.5 GB و کفایت تأییدشده‌ای روی همان نسبت روی کار 34 GB است (3 از 3 بایت‌درست دقیقاً روی آن نسبت)؛ نردبانشان را در اندازهٔ بزرگ‌تر پایین‌تر نپیمودیم، پس کف واقعیشان آنجا ممکن است تا حدی زیر نسبت بنشیند، و ما این را می‌گوییم به‌جای گردکردن به سود خودمان.

آنچه تمام‌شدن واقعاً به آن شبیه است به اندازهٔ عدد اهمیت دارد. در 17 MB زیر کفش، nzbfast به رد دیسک روی یک نوشتن می‌خورد، پاکیزه با «فضای دیسک تمام شد» متوقف می‌شود، هرچه فرود آمده را ژورنال‌شده نگه می‌دارد، و یک تلاش دوباره بدون واکشی مجدد ادامه می‌دهد - یک ناتمامی که نگه می‌دارید، نه یک کار شکست‌خورده. ¹ سلول فیکسچر بزرگ Weaver با یک اجرای دوباره در 24 اوت حل شد: سه لِگ از سه لِگ بایت‌درست روی همان ~2.25 برابر، هر کدام سریع‌تر از لِگ خوبِ تلاش نخست، با فضای آزادِ یکسان تا حد بایت. در تلاش نخست، در 23 اوت، دو تا از سه لِگش با بیش از 60 GB هنوز آزاد روی نرخ‌های تک‌رقمی مگابایت‌بر-ثانیه گیر کرده و به سقف 40-دقیقه‌ای دور خورده بودند. آن گیرکردن‌ها بازنگشتند و ابزار سنجش گیرکردنِ رَک روی هر سه لِگ اجرای دوباره مستقر و خاموش بود، که یک خوانش مثبت است نه خوانشی غایب. اینکه چه چیزی آنها را ایجاد کرد هنوز ناشناخته است و یک اجرای دوبارهٔ تمیز تشخیص نیست: اکنون شش لِگ در این نسبت وجود دارد، چهارتا کامل شده، و هر دو شکست از یک پنجرهٔ 80-دقیقه‌ای در شب نخست می‌آید.

پست‌های تودرتو · اندازه‌گیری‌شده در ۲۸ اوت ۲۰۲۶

ده روش بسته‌بندی یک پست، و اینکه چه کسی واقعاً به فایل می‌رسد

بسیاری از آنچه منتشر می‌شود عمداً سخت‌گشودنی است. نام واقعی فایل درون بایگانی دومی دفن شده است، گاهی سومی، گاهی در هر لایه با قالبی متفاوت، تا پست کمترین اطلاعات را درباره محتوایش لو بدهد. افزون بر این، پست‌ها آسیب‌دیده می‌رسند: مقاله‌ها منقضی می‌شوند، بارگذاری‌ها ناقص می‌نشینند، و پیش از آنکه چیزی قابل استخراج باشد باید از داده‌های بازیابی استفاده کرد. یک برنامه دانلود یا این زنجیره را برای شما طی می‌کند، یا پوشه‌ای پر از بایگانی به شما می‌دهد و متوقف می‌شود.

پس ده شکل ساختیم که دقیقاً همین را جدا می‌کند، هر برنامه امروزی را در برابرشان آزمودیم، و سپس کاری کردیم که مقایسه‌ها معمولاً از آن می‌گذرند: هرجا برنامه‌ای زود متوقف شد، کار را با ابزارهای استاندارد دستی به پایان رساندیم و زمان آن را هم سنجیدیم. برنامه‌ای که زود تسلیم می‌شود سریع به نظر می‌رسد، تا وقتی کاری را که برایتان باقی گذاشته بشمارید.

nzbfast تنها برنامه‌ای است که هر ده شکل را بدون کمک به پایان می‌رساند. NZBGet نیز در هر شکل به فایل می‌رسد، اما در هشت مورد به 16 دور تعمیر و استخراج دستی نیاز دارد. SABnzbd پنج مورد را خودش تمام می‌کند و دو مورد حتی به‌صورت دستی هم دست‌نیافتنی می‌مانند. Weaver در دو مورد به فایل می‌رسد.

این الگو تصادفی نیست. شکل‌هایی که nzbfast از آنها می‌گذرد و دیگران نمی‌گذرند همان بسته‌بندی‌شده‌ها و آسیب‌دیده‌هایند: بایگانی درون بایگانی، تغییر قالب در میانه زنجیره، زنجیره‌ای پنج‌لایه، و بیش از همه بایگانی‌ای که خراب می‌رسد و داده‌های بازیابی خودش کنارش است. در همین مورد آخر، چهار برنامه مجموعه بیرونی را بی‌نقص استخراج می‌کنند، بایگانی معیوب را همراه با مجموعه بازیابی‌ای که آن را درست می‌کرد به شما می‌دهند، و متوقف می‌شوند.

آنجا که برنامه‌ها کار یکسانی را به پایان می‌رسانند، فاصله کم نیست. اینها هفت شکلی هستند که هر چهار برنامه رایج به آنها می‌رسند، با احتساب تعمیر دستی موردنیاز هرکدام:

چهار تا پنج برابر سریع‌تر، با کمتر از نیمی از بایت‌های نوشته‌شده. عدد دیسک همان عددی است که پس از دانلود هم اهمیت دارد: هر گیگابایت در آن ستون گیگابایتی است که درایو شما ناچار به پذیرفتنش شده، و برنامه‌هایی که از ناحیه میانی استفاده می‌کنند محتوا را می‌نویسند، دوباره می‌خوانند و باز می‌نویسند.

آنجا که جلوتر نیستیم، و چرا گفتنش می‌ارزد. در چهار شکل از ده شکل، یک رقیب در حین خودِ دانلود بایت کمتری از nzbfast می‌نویسد. هر بار به این دلیل که کمتر انجام داده است: در شکل با بایگانی درونی خراب، NZBGet 3.29 GB می‌نویسد در برابر 4.65 ما، سپس دور تعمیرش 2.91 دیگر می‌نویسد و روی 6.20 GB در برابر 4.65 ما تمام می‌کند. در بقیه، برنامه‌ای که کمترین را نوشته همان است که هرگز به فایل نرسیده. عدد کوچک دیسک همیشه صرفه‌جویی نیست.

اینها آزمون‌های توانایی‌اند، نه آزمون‌های سرعت. محتواها کوچک‌اند و از حافظه روی یک اتصال محلی سرو می‌شوند، بدون ارائه‌دهنده و بدون شبکه در مسیر؛ پس هیچ‌چیز اینجا محدود به سرعت دانلود نیست و ثانیه‌های مطلق بسیار کوتاه‌تر از زمانی‌اند که همین شکل‌ها در دنیای واقعی می‌گیرند. اینکه آیا یک شکل اصلاً کار دستی می‌طلبد، ویژگی شکل و برنامه است و مستقیماً منتقل می‌شود. ثانیه‌ها برنامه‌هایی را که کار یکسانی انجام می‌دهند مقایسه می‌کنند؛ پیش‌بینی نمی‌کنند یک کار واقعی چقدر طول می‌کشد.

نتایج کامل برای هر شکل، شرح هر شکل، و روش کار در صفحه داده‌های بایگانی‌های تودرتو است.

چرا اهمیت دارد

دیسک شما نصف کار را انجام می‌دهد

حافظهٔ فلش با نوشته‌شدن رویش فرسوده می‌شود. یک انتشار 94 گیگابایتی زیر ‏nzbfast حدود 90 گیگابایت نوشتن برای درایوتان هزینه دارد؛ زیر کلاینتی که مرحله می‌کند و باز می‌کند، همان انتشار تقریباً دو برابر هزینه دارد. روی یک NAS با دیسک‌های سخت، شکل یک‌گذر همچنین گذر تک‌رشته‌ای بلند پایان هر دانلود رمزگذاری‌شده را حذف می‌کند - مکثی که روی یک ایستگاه‌کار 32-هسته‌ای سریع با بازگشایی شتاب‌گرفته‌سخت‌افزاری ‏20 ثانیه اندازه گرفته شد، و متناظراً روی ماشین‌های کم‌توانی که بیشتر مردم واقعاً این را رویشان اجرا می‌کنند طولانی‌تر. عدد کوچک را نقل می‌کنیم چون همان چیزی است که اندازه گرفتیم.

مسابقهٔ اجزا

محک‌های فنی‌تر، برای کسانی که داده بیشتر می‌خواهند

ترمیم (PAR2) و باز کردن (RAR) کد بومی خودمان‌اند نه باینری‌های بسته‌بندی‌شدهٔ شخص‌ثالث، پس آنها را هم به‌تنهایی در برابر ابزارهای اختصاصی روی پیکره‌های یکسان مسابقه می‌دهیم، روی چهار ماشین که آنچه یک خواننده واقعاً ممکن است داشته باشد را می‌پوشانند. زمان فقط وقتی می‌شمارد که خروجی بایت‌به‌بایت با محمولهٔ منبع یکسان باشد: هر عدد RAR پایین‌تر در برابر منبع با sha256 بررسی شد، و هر فایل ترمیم‌شده در برابر مجموعهٔ بی‌عیب.

استخراج RAR: 7 شکل آرشیو، 6 ابزار

دور پیشین این جدول از 100 تا 200 MB برای هر شکل استفاده کرد، که اشتباه بود: حدود 28 میلی‌ثانیه راه‌اندازی پردازه 40٪ از لِگ ذخیره‌شده بود، و ترتیبی که تولید کرد در اندازهٔ واقعی دوام نمی‌آورد. این دور 1 GB محموله برای هر شکل است، و چند پاسخ را تغییر می‌دهد، از جمله چند مورد در جهت دیگر. آرشیوها با rar رسمی 7.23 ساخته می‌شوند، پس هیچ ابزاری روی ورودی رمزگذار خودش نمره نمی‌گیرد، و همان بایت‌ها روی هر ماشین مسابقه می‌دهند.

آنچه درون محموله است بیش از ظاهرش اهمیت دارد. محمولهٔ ساخته‌شده از کپی‌های بلوکی هر شکل فشرده را یک محک کپی-حافظه می‌کند؛ محمولهٔ متن خالص آن را یک محک لفظ-و-هافمن می‌کند؛ هر دو را اندازه گرفتیم و روی برنده توافق ندارند. پس چهار شکل فشردهٔ ما از سهم برابر متن، رکوردهای ساختاریافته و بایت‌های غیرقابل‌فشرده استفاده می‌کنند، و دو شکل دو سرِ آن گستره عمداً لِگ‌هایی جدایند: store غیرقابل‌فشرده است و repetitive تقریباً همه تطابق است. سازنده و سازوکار در مخزن‌اند، پس پیکره را می‌توان بایت‌به‌بایت بازساخت.

دوباره‌مسابقه‌داده‌شده 23 اوت 2026 روی موتور 1.2.2، و پیمایش پابرجا می‌ماند. سه ابزاری که یک خواننده بیشترین وزن را به آنها می‌دهد - مال ما، unrar 7.23 و rarpar 0.2.5 - روی رومیزی 32-هسته‌ای روی موتور انتشار دوباره مسابقه داده شدند (کد استخراج مسابقه‌داده‌شده بایت‌به‌بایت با برچسب 1.2.2 یکسان است)، شش دور درهم‌تنیده، کمینه برای هر ابزار، خروجی هر لِگ در برابر فهرست محموله بررسی‌شده. ثانیه، کمتر بهتر است:

هر هفت شکل مال ماست، روی کمینه و روی میانه، 1.16 تا 4.29 برابر در برابر unrar. این زمان‌ها سلول‌به‌سلول با جدول گسترده‌تر پایین‌تر قابل‌مقایسه نیستند - سازوکار از دورهای آن جدول بازبینی شده و شمار دورها فرق دارد - پس هر جدول را کنار خودش بخوانید. جدول گسترده‌تر تاریخ‌ها و میدان شش‌ابزاری خودش را نگه می‌دارد، و ستون nzbfast آن موتوری را توصیف می‌کند که 1.2.2 منتشر می‌کند: دوباره‌مسابقهٔ بالا موتور فعلی را با ساخت آن جدول روی هر هفت شکل هم‌سطح اندازه گرفت، حل‌شده با شمار دستورالعمل سخت‌افزار (0.14٪ کمتر برای همان ساعت)، پس آن سلول‌ها اعداد یک ساخت جایگزین‌شده نیستند که برچسبی فعلی زده باشد. این دوباره‌مسابقه همچنین جایی است که قاعدهٔ A/A در بخش چیدمان به دست آمد. یک عبور همان‌روزه اول یک شکل را به‌عنوان پس‌رفتی کوچک در برابر ساخت پیشین خودمان گزارش کرد، و این خوانش با اجرای هر دو ترتیب بازو پابرجا ماند. یک کنترل A/A - همان باینری در برابر یک کپی بایت‌به‌بایت یکسان از خودش - نشان داد سازوکار به هر بازویی که اول اجرا شود جریمه‌ای حدود 1.5٪ می‌دهد: باینری یکسان تنها 6 از 15 دور را از جایگاه اول برد، و جابه‌جایی ترتیب‌ها سوگیری‌ای را که همیشه روی هرکس اول باشد می‌نشیند خنثی نمی‌کند. شمار دستورالعمل سخت‌افزار پرسشی را حل کرد که سازوکار نتوانست - ساخت تازه‌تر 0.14٪ دستورالعمل کمتر برای همان ساعت دیواری بازخرید می‌کند، پس پس‌رفتی وجود نداشت. هر مقایسهٔ ساخت-خودمان-در-برابر-ساخت-خودمان که اکنون منتشر می‌کنیم آن کنترل را همراه دارد.

کل میدان، ثانیه، کمتر بهتر است. بهترین از سه، ابزارها درهم‌تنیده درون هر دور به‌جای اجرا در بلوک، خروجی در برابر محمولهٔ منبع روی هر تک اجرا بررسی‌شده. ابزاری که بایت‌های نادرست تولید کرد یک یادداشت درستی می‌گیرد، هرگز یک زمان سریع. rarpar کد RAR و PAR2 خودِ Weaver است، ساخته‌شده از منبع در bd87611؛ کامیت را سنجاق می‌کنیم نه یک نسخه چون بسته‌هایش سه شمارهٔ نسخهٔ متفاوت حمل می‌کنند.

جایی که میدان نتوانست رقابت کند، و چرا. ¹ 7-Zip مسابقه‌داده‌شده اینجا بستهٔ Homebrew است، که هر شکل فشرده را با ‏ERROR: Unsupported Method رد می‌کند و فقط شکل ذخیره‌شده را روی macOS می‌خواند. نسخهٔ پیشین این صفحه آن را به ساخت macOS خودِ 7-Zip نسبت داد، که نادرست بود: Homebrew آن را بدون کدک غیررایگان unRAR می‌سازد، در حالی که ساخت macOS که ‏7-zip.org منتشر می‌کند کدک را حمل می‌کند و هر هفت شکل را کدگشایی می‌کند، همان‌طور که ساخت ویندوز می‌کند. دوباره‌اندازه‌گیری‌شده 14 اوت 2026. اگر 7-Zip را از پروژه به‌جای Homebrew نصب کنید، این ستون آنچه دارید را توصیف نمی‌کند. ² ‏bsdtar پشتیبانی چندجلدی RAR5 ندارد و بدون گزارش خطا فایلی بریده تولید کرد، پس آن لِگ یک شکست درستی است نه یک زمان کند؛ سازوکار ما با بررسی خروجی آن را گرفت، که چرایی ارزش بررسی خروجی است. ³ ‏bsdtar: Encryption is not supported. ⁴ ‏bsdtar: Declared dictionary size is not supported. ⁵ ‏unar هیچ ابزار خط‌فرمان ویندوزی منتشر نمی‌کند، پس میدان لپ‌تاپ پنج‌تاست. ⁶ گروه M5 Max سه ابزاری را مسابقه می‌دهد که یک خوانندهٔ macOS واقعاً به سراغشان می‌رود - unrar، rarpar و ما؛ unar، bsdtar و 7-Zip روی آن ماشین مسابقه داده نشدند. ‏unrar آن 7.22 است، تازه‌ترین ساختی که آنجا بی‌نظارت اجرا می‌شود.

هر شکل روی هر ماشین به‌جز یکی، و آن یکی تساوی است. شکل‌های تطابق-کوتاه به دو چیز مشخص در کدگشای ما می‌رسند. یک تطابق دو تا سی‌ودو بایتی زمانی برای یک فراخوانی کامل به روال کپی-حافظهٔ پلتفرم می‌پرداخت، و فراخوانی بیش از خودِ کپی هزینه داشت؛ کپی‌کردن سی‌ودو بایت ثابت از میان یک ثبات به‌جایش چرایی این است که repetitive، solid و فرهنگ‌لغت 128 مبی‌بایتی - سه شکل ساخته‌شده از تطابق‌های کوتاه - همه هم‌زمان سریع‌اند. و چک‌سام پایین‌دستِ رشتهٔ نویسنده اجرا می‌شود نه رویش. تنها سلولی که رأساً نمی‌بریم شکل ذخیره‌شده روی رومیزی 32-هسته‌ای است، جایی که unrar و ما سه میلی‌ثانیه از هم فاصله داریم روی لِگی که خالصاً جابه‌جایی بایت است - در دقت این جدول یکسان، پس هر دو سلول نشان‌گذاری شده‌اند و تساوی نمره می‌گیرد، نه باخت و نه برد.

شکلی که با بیشترین فاصله می‌بریم همان چیزی است که یوزنت واقعاً صدها تای آن را هم‌زمان پست می‌کند: 400 فایل ریز، 4.3 و 4.4 برابر در برابر unrar و 5.4 تا 5.5 برابر در برابر rarpar. آن موازی‌سازی هر-عضو است، و همان فاصلهٔ میان استخراج‌کننده‌ای است که برای یک صف دانلود نوشته شده و یکی که برای خط فرمان. شکل ذخیره‌شده، که سرشماری بالا می‌گوید 84٪ بایت‌های روی سیم است، برای سه ابزار جدی تقریباً یک تساوی است، چون در آن نقطه همه فقط دارند بایت جابه‌جا می‌کنند.

یک انتخاب که ارزش اعلام دارد. آرشیوها با فشرده‌ساز سنجاق‌شده روی چهار رشته بسته‌بندی می‌شوند. در غیر این صورت شکافِ بلوکِ RAR شمار هسته‌های هر ماشینی را که آرشیو را بسته‌بندی کرده دنبال می‌کند، پس یک جعبهٔ 32-هسته‌ای و یک جعبهٔ 20-هسته‌ای از همان ورودی بایت‌های متفاوتی تولید می‌کنند و ماشین‌ها قابل‌مقایسه بودن را از دست می‌دهند. سنجاق‌کردنش پیکرهٔ استخراج را همه‌جا بایت‌به‌بایت یکسان می‌کند، که نکته است، اما همچنین سقف می‌زند چه‌قدر از کدگشایی می‌تواند موازی اجرا شود - پس وقتی دو شکل نزدیک‌ترین باخت بودند، دوباره در برابر آرشیوهایی که با هر 32 رشته بسته‌بندی شده بودند مسابقه دادیم، تا بررسی کنیم سنجاق‌کردن دلیلش نبوده. نبود: سالید از 4.2٪ عقب به 2.4٪ عقب رفت و فرهنگ‌لغت 128 مبی‌بایتی از 6.6٪ به 6.3٪، همان ترتیب در هر دو حالت. هر دو اکنون روی پیکرهٔ سنجاق‌شده با حاشیه‌ای گسترده‌تر از آنچه آن بررسی می‌توانست توضیح دهد بردند.

چرا سطر RAR4 نیست، و چه بر سر آن پست‌ها می‌آید. هر شکل بالا RAR5 یا RAR7 است، که همان چیزی است که یوزنت امروز پست می‌کند. آرشیوهای RAR4 قدیمی‌تر هنوز پیدا می‌شوند، و همان موتور آنها را می‌خواند، از جمله شکل‌های فشرده و گذرواژه‌دارشان، در همان یک گذر به‌جای نوشتن جلدها روی دیسک و بازکردنشان پس از آن. اینجا سطری نمی‌گیرند چون rar رسمی 7.23 دیگر نمی‌تواند RAR4 بسازد، پس پیکرهٔ بی‌طرفی برای مسابقه‌دادن میدان نیست؛ آن کار در برابر آرشیوهایی که WinRAR 3.00 نوشته بررسی می‌شود، بایت‌به‌بایت در برابر unrar.

تأیید و ترمیم PAR2: مجموعهٔ 1 گیبی‌بایتی، چهار سطح آسیب

پیکره: 1 گیبی‌بایت محمولهٔ تصادفی بسته‌بندی‌شده حالت-ذخیره در 21 جلد RAR، سپس دو مجموعهٔ PAR2 با 10٪ افزونگی، یکی با بلوک‌های 1 مبی‌بایتی و یکی با 64 کیلوبایتی، سپس نقشه‌های آسیب ثابت. هر اجرا از همان پروتکل استفاده می‌کند: کپی تازه، خواندن کل پیکره یک بار برای گرم‌کردن کش، سپس زمان‌گیری. بهترین از سه دور درهم‌تنیده؛ هر جلد ترمیم‌شده در برابر مجموعهٔ بی‌عیب روی هر دور مقایسه می‌شود. کمتر بهتر است.

اصلاحی دربارهٔ پیکره، چون نسخهٔ پیشین این صفحه آن را بزرگ‌نمایی کرد. گفتیم هر ماشین یک پیکرهٔ بایت‌به‌بایت یکسان اجرا کرد، بررسی‌شده با هش. هش‌کردن هر جلد از هر مجموعه نشان می‌دهد آن دربارهٔ رومیزی 32-هسته‌ای و لپ‌تاپ ویندوز درست است، که دقیقاً هم‌خوان‌اند، و دربارهٔ رومیزی 20-هسته‌ای نه، که برداشت تصادفی متفاوتی از همان شکل را نگه می‌دارد: همان 21 جلد در همان اندازه‌ها، همان دو اندازهٔ بلوک، و آسیب تأییدشده روی همان 3، 101 و 1,500 بلوک پخش‌شده روی همان شمار فایل. هر عدد درون یک سطر هنوز روی بایت‌هایی اندازه‌گیری شده که هر ابزار آن سطر با هم شریک است، که همان چیزی است که هر مقایسه رویش تکیه می‌کند. اما سطرها چهار دیدگاه از یک ورودی نیستند، و چون طبیعت محموله برای یک رقیب حدود 7٪ روی اسکن ارزش دارد، این ارزش گفتن دارد نه لعاب‌کاری.

کدام par2 کدام است. ‏ par2cmdline اصلی پیاده‌سازی مرجعی است که همه از آن فورک شده‌اند. ‏par2cmdline-turbo فورکی است که هسته‌های میدان-گالوای SIMD دست‌نویس ParPar را بسته‌بندی می‌کند: دقیقاً همین معنی «توربو» است، و چرایی این است که توربو، نه اصلی، ابزار ارزش سنجش در برابر است. هر دو ستون توربو پایین‌تر همان هسته‌های ParPar را اجرا می‌کنند. آنچه جدایشان می‌کند حساب نیست، ساخت و پرچم‌هاست.

تأییدشده روی ساخت انتشاری در برابر رقیب فعلی، 24 اوت 2026. این جدول‌ها پیش از بریده‌شدن 1.2.2 و پیش از انتشار ‏par2cmdline-turbo 1.5.0 (20 اوت 2026) اندازه گرفته شدند، پس ستون 20-هسته‌ای روی هر دو دوباره مسابقه داده شد: ساخت انتشار 1.2.2 ما در برابر توربو 1.5.0، سه دور درهم‌تنیده برای هر لِگ، هر فایل ترمیم‌شده در برابر مجموعهٔ بی‌عیب مقایسه‌شده. هر چهار لِگ بازتولید می‌شوند - مال ما 0.18 / 0.30 / 0.75 / 2.02 در برابر 0.19 / 0.33 / 0.74 / 2.07 چاپ‌شده اینجا، و توربو 1.5.0 درون چند درصد از ساخت جدول روی هر لِگ و هر دو پیکربندی می‌نشیند. سلول‌ها همان‌طور که منتشرشده می‌مانند؛ سه ماشین دیگر تاریخ‌های خودشان را نگه می‌دارند.

پس رقابت دو بار حاضر می‌شود، و یکی از آن ستون‌ها بهترین حالتش است نه پیش‌فرضش. باینری انتشاری که دانلود می‌کنید برای یک پردازندهٔ خط‌مبنای عمومی کامپایل شده و فقط چند فایل را هم‌زمان هش می‌کند؛ کامپایل‌کردن همان منبع برای پردازندهٔ میزبانِ واقعی و دادن -T16 می‌گذارد از دستورالعمل‌هایی که آن ماشین واقعاً دارد استفاده کند و شانزده فایل را هم‌زمان هش کند. روی لپ‌تاپ این تا 2.6 برابر ارزش دارد، کاملاً از ساخت و پرچم‌ها. ما را روی ستون کوک‌شده نمره بدهید، که مقایسهٔ سخت‌تر است؛ ستون همان‌طور-که-منتشرشده آن چیزی است که کسی که دانلودش می‌کند واقعاً تجربه می‌کند. par2cmdline نسخهٔ اصلی، 1.2.0، ساخته‌شده از منبع روی هر ماشین است. rarpar پیاده‌سازی PAR2 خودِ Weaver است، ساخته‌شده از منبع با پشتیبان GPU متال آن فعال. par2j مالتی‌پار فقط-ویندوزی است، پس فقط روی سطرهای لپ‌تاپ ویندوز ظاهر می‌شود. سطرهای M5 Max دو ابزار با ساخت‌های macOS arm64 فعلی را کنار دو ستون توربو مسابقه می‌دهند؛ ‏par2cmdline کلاسیک روی آن ماشین مسابقه داده نشد.

هر شانزده سلول nzbfast - چهار ماشین روی چهار سطح آسیب - مال ما هستند، چند تا با بیش از 2 برابر در برابر ساخت کوک‌شده و با 2.3 تا 7.7 برابر در برابر آنچه واقعاً دانلود می‌کنید. سلول‌های آسیب-سنگین جالب‌ترین‌اند، و یادداشت پایین‌تر الگوریتم پشتشان را توضیح می‌دهد.

نسخهٔ اصلی به جدول برگشته، و ارزش دیدن دارد چرا فورک وجود دارد. نسخهٔ پیشین این صفحه ستون par2cmdline را بر این پایه انداخت که از هر چیز دیگر در دور کندتر بود، که درست است و دلیل کافی نیست: پیاده‌سازی‌ای است که تقریباً هر ابزار دیگر از آن منشعب شده، و خواننده‌ها سزاوار خط‌مبنایند نه ادعای ما دربارهٔ آن. روی سنگین‌ترین سطح آسیب حدود 69 ثانیه می‌کشد جایی که فورک SIMD 3.2 ثانیه می‌کشد و ما 3.1. آن ضریب بیست کل بحث برای هسته‌های میدان-گالوای دست‌نویس است، و همان بحثی است که برای مال خودمان می‌کنیم.

آسیب سبک همان موردی است که اهمیت دارد. چند مقالهٔ ناموفق بسیار معمول‌تر از 101 بلوک مرده است، و چیزی مثل 1,500 نیست. بیشتر یک ترمیم سبک اصلاً ریاضی رید-سولومون نیست، خواندن و MD5-کردن یک گیبی‌بایت است، که چرایی این است که سطر 3-بلوکی سطر تأیید-پاک را دنبال می‌کند نه سطرهای ترمیم.

سنگین‌ترین سطح آسیب نوع دیگری از کار است، و الگوریتم دیگری می‌گیرد. آن آخرین سطح 1,500 بلوک را در سراسر هر 21 جلد آسیب می‌زند و حدود 91٪ دادهٔ بازیابی را مصرف می‌کند، جایی که حساب رید-سولومون، به‌جای هش یا دیسک، تقریباً کل کار می‌شود. ساخت انتشاری سنگین‌ترین ترمیم‌ها را با یک تبدیل عدد-نظری به‌جای چین کلاسیک میدان-گالوای حساب می‌کند - همان ریاضی، در شکلی ارزیابی‌شده که در شمار بلوک بالا بسیار بهتر مقیاس می‌گیرد: 2.7 برابر جلوتر از ساخت کوک‌شده روی رومیزی 20-هسته‌ای، و روی لپ‌تاپ ویندوز 2.7 برابر جلوتر از ساخت کوک‌شده و 2.2 برابر جلوتر از MultiPar. آسیب سبک هنوز مسیر کلاسیک را اجرا می‌کند، چرایی اینکه سطرهای دیگر تقریباً هیچ جابه‌جا نشدند: تبدیل تنها بالای حدود 512 بلوک آسیب‌دیده می‌پردازد، پس زیر آن گسیل‌کننده از آن استفاده نمی‌کند.

مسیری سریع‌تر تنها وقتی ارزش داشتن دارد که نتواند اشتباه باشد. هر دو مسیر همان مقدار را حساب می‌کنند و به‌طور ساختاری بیت‌به‌بیت یکسان‌اند، و هر ترمیم این صفحه در برابر تطابق فایل‌های بازساخته با مجموعهٔ بی‌عیب گیت‌بندی شد: 228 ترمیم زمان‌گیری‌شده در سراسر ماشین‌های این دور، صفر ناهم‌خوانی. ساخت انتشاری روی آن سابقه تکیه نمی‌کند. هر ترمیم خروجی خودش را در برابر هش‌های فایل تأیید می‌کند، و آنی که شکست بخورد به‌طور خودکار با مسیر کلاسیک دوباره انجام می‌شود، واگرایی را ثبت می‌کند، و مسیر کلاسیک را برای بقیهٔ آن اجرا نگه می‌دارد. این تنظیم در داشبورد به‌عنوان حالت PAR سریع هست اگر ترجیح می‌دهید اصلاً نداشته باشیدش، و ماشین‌هایی با حافظهٔ خیلی کم برایش خودشان به‌جای امتحان و شکست ردش می‌کنند. دوباره‌اندازه‌گیری‌شده در 2 اوت روی ساخت فعلی: هر دو رومیزی درون چند درصد این جدول می‌نشینند، و با حالت PAR سریع خاموش رومیزی 20-هسته‌ای دقیقاً به زمان کندتر مسیر کلاسیک برمی‌گردد، که می‌گوید برد روش است نه شرایط.

ستون لپ‌تاپ ویندوز به اصلاحی نیاز داشت، و به ضرر ماست. ویندوز کار پس‌زمینهٔ پیوسته را چند ثانیه بعد به هسته‌های کارآمدی می‌راند. دیمن ما از راه‌اندازی از آن کنار می‌کشد و هیچ ابزار دیگری نمی‌تواند، پس نسخهٔ پیشین این صفحه زمان‌های خفه‌شدهٔ آنها را چنان منتشر کرد گویی زمان‌های خودِ ابزارها بود. دوباره‌اجرای آن ماشین با بلندکردن هر ابزار به اولویت بالا کل میدان را جابه‌جا می‌کند: روی سنگین‌ترین سطح آسیب par2-turbo از 22.4 ثانیه به 6.41 می‌رود و rarpar از 59.2 ثانیه به 14.4، و برای یک برش این صفحه آن ستون را از مال ما به یکی که باختیم تبدیل کرد. کل ستون لپ‌تاپ اکنون به همان روش اندازه‌گیری می‌شود - اصلاح باقی می‌ماند حتی با آنکه سطر از وقتی تغییر الگوریتم بالا دوباره برده شده، چون زمان‌های میدان روی آن ماشین فقط با خفگی برداشته‌شده صادقانه‌اند.

رکوردهای بازیابی RAR: ترمیم بدون PAR2

وقتی PAR2 نمی‌تواند آسیب را بپوشاند، رکورد بازیابی درون خودِ RAR خط دفاع آخر است. تا 1.0.8 مال ما روی هر آرشیو بالای حدود 13 MB شکست می‌خورد، پس این لِگ اصلاً قابل‌اجرا نبود. آسیب سه سوراخ 3,000-بایتی روی 20٪، 50٪ و 80٪ از میان ناحیهٔ محافظت‌شده است. هر دو ابزار خروجی بایت‌به‌بایت با فایل بی‌عیب یکسان تولید کردند، و مال ما بایت‌به‌بایت با آنچه rar r خودش می‌نویسد یکسان است. بهترین از سه، رومیزی 32-هسته‌ای، هر دو ابزار دوباره با هم مسابقه داده‌شده در 2 اوت.

نسخهٔ پیشین این صفحه اندازهٔ 512 MB را به‌عنوان باخت نشان داد، و آن را بهای کار از میان جلد تکه‌تکه به‌جای نگه‌داشتن کل آن در حافظه توضیح داد. آن توضیح آن‌زمان درست بود و اکنون منسوخ است: هزینه یک CRC64 بیت-پی‌درپی در مسیر ترمیم بود، جایگزین‌شده با یکی جدول‌محور، و باخت با آن رفت. دیگر گذاری وجود ندارد و مجموعهٔ کاری کران‌دار حفظ شد. اندازهٔ 2 GB اینجاست چون جلدهایی که یک دیمن واقعاً به آنها می‌رسد 8 GB تا 20 GB هستند، نه 512 MB، و لِگی که زیر گسترهٔ واقعی متوقف می‌شود چندان آزمونی نیست.

چه چیزی این برش را جابه‌جا کرد، و کنترلی که این را می‌گوید. یافتن اینکه کدام بلوک‌ها آسیب‌دیده‌اند بزرگ‌ترین مرحلهٔ این ترمیم شده بود - بزرگ‌تر از خودِ حساب ترمیم - و روی یک رشتهٔ تنها اجرا می‌شد، 64 KB از هر گروه در سراسر فایل می‌خواند، یک بار برای هر گروه. اکنون یک گذر پیاپی به ترتیب فایل می‌زند با چک‌سام‌های هر-قطعه محاسبه‌شده موازی، و جلد ترمیم‌شده شبیه‌سازی (کلون) می‌شود به‌جای کپی جایی که فایل‌سیستم بتواند این کار را بکند. تشخیص به‌تنهایی روی آرشیو 512 MB از حدود 300 میلی‌ثانیه به 18 میلی‌ثانیه افتاد، که بیشتر آنچه بالا جابه‌جا شد است. کنترل ستون کنار ماست: rar r در همان دورها روی همان ماشین دوباره مسابقه داده شد و درون چند درصد از زمان‌های پیشین خودش برگشت، پس تغییر در فاصله مال ماست نه بنچ.

‏M5 Max همان الگو را تکرار می‌کند، مسابقه‌داده‌شده 31 ژوئیه با همان پیکره و گیت‌ها: 0.050 / 0.066 / 0.171 / 0.581 ثانیه در برابر 0.211 / 0.335 / 0.751 / 1.735 مال rar r در سراسر اندازه‌های 16 MB تا 512 MB - 3.0 تا 5.1 برابر سریع‌تر؛ اندازهٔ 2 GB روی آن ماشین مسابقه داده نشد. آن عددها پیش از بازنویسی تشخیص توصیف‌شده بالا هستند، پس مال ساخت قدیمی‌ترند، اینجا نگه‌داشته‌شده به‌عنوان ماشین دوم به‌جای عددی فعلی.

‏rarpar Weaver از این جدول تنها غایب است، و نه به انتخاب: این ترمیم را پیاده‌سازی نمی‌کند. خواسته‌شده یکی از این آرشیوها را درست کند، پاسخ می‌دهد «embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data»، و فایل را آسیب‌دیده رها می‌کند. در هر مقایسهٔ دیگر این صفحه حاضر است: هر چهار لِگ PAR2 بالا، هر هفت شکل استخراج پیش از آن، و لِگ جلد-بازیابی بلافاصله پایین‌تر، که همان کاری است که می‌گوید انجام می‌دهد - و می‌برد.

جلدهای بازیابی: بازساخت کل فایل‌های گمشدهٔ .rev

نیمهٔ دیگر داستان بازیابی خودِ RAR، و تا این دور بزرگ‌ترین باخت این صفحه. یک فایل .rev یک جلد بازیابی مستقل است: سه‌تای آن کنار یک مجموعهٔ 21-جلدی می‌تواند هر سه جلدی را که هرگز نرسیده‌اند بازسازی کند. پیکره: 1 گیبی‌بایت ذخیره‌شده در 21 جلد 50 MB با rar rv3، سپس جلدهای 4، 11 و 19 حذف‌شده - سه گمشده در برابر سه جلد بازیابی، که بدترین حالتی است که مجموعه هنوز می‌تواند از آن جان سالم به‌در برد. بهترین از سه، هر جلد بازساخته در برابر جلد بی‌عیب مقایسه‌شده.

سلول 32-هسته‌ای اینجا در آخرین برش این صفحه 3.12 ثانیه در برابر 0.47 مال rar rc بود، منتشرشده به‌عنوان 6.6 برابر کندتر و بدترین عدد رویش. علت این بود که حلِ محو با حدود 48 MB/s خروجی بازساخته اجرا می‌شد جایی که مال RARLab 320 نگه می‌داشت؛ اکنون روی همان حساب جدول‌محور بقیهٔ کد بازیابی اجرا می‌شود، که بهبودی هفت‌برابری است و باخت را به یک برد روی هر دو ماشین تبدیل می‌کند. حاشیه‌ها 3٪ و 14٪‌اند، پس بردی است ارزش گفتن صریح را دارد نه تیتر شدن، و چرایی اینکه اصلاً گفته می‌شود این است که باخت اول گفته شد.

این لِگ وجود دارد چون rarpar ‏Weaver دقیقاً همین را پیاده‌سازی می‌کند و خواست رویش اندازه‌گیری شود. وقتی اول منتشرش کردیم راحت می‌برد، و همان‌وقت به همان دلیل منتشرش کردیم.

تطبیق فایل هرگز هزینه نبود، که ارزش ثبت دارد چون مظنون شهودی بود: جلدهای بازیابی هیچ نام فایلی حمل نمی‌کنند، پس با چک‌سام‌کردن هر جلد روی دیسک به‌جای اعتماد به نامشان تشخیص می‌دهیم کدام جایگاه‌ها جان سالم به‌در برده‌اند، و در برابر یک مجموعهٔ آسیب‌ندیده، جایی که تطبیق تنها اتفاقی است که می‌افتد، کل گذر 0.18 ثانیه طول می‌کشد.

چه چیز دیگری جابه‌جا شد، و کجا نمود ندارد. دو تغییر موتور دیگر فرود آمدند که این پیکره‌ها نمی‌توانند ببینند، اینجا فهرست‌شده تا عددهای بالا کل داستان خوانده نشوند: آرشیوهای RAR5 با ده‌ها هزار عضو هر عضو را یک بار حل می‌کنند به‌جای پیمایش فهرست برای هر کارگر، که 3 برابر زمان پردازندهٔ کمتر روی 40,000 عضو است؛ و خوانندهٔ بیتیِ RAR1.3 یک کلمه در هر زمان کار می‌کند، که 2 برابر است. هیچ‌کدام بالا ظاهر نمی‌شود، چون شکل‌های اینجا 400 عضو دارند و بدون RAR1.3.

آنچه عمداً انجام نمی‌دهیم: ما هرگز PAR2 نمی‌سازیم. یک دانلودکننده دلیلی برای این کار ندارد، و ParPar آن لِگ را دارد. همچنین سرعت را با حافظه روی هر دو موتور می‌خریم: اوج استخراج حدود 240 MB در برابر 41 MB مال unrar است، و اوج تأیید حدود 126 MB در برابر 7 MB مال توربو، چون اینها موتورهای درون‌خطی‌اند که سوار یک دانلود زنده می‌شوند نه یک‌بارمصرف‌های مستقل. شکل فرهنگ‌لغت-128-مبی‌بایتی بدترینش است، حدود 304 MB در برابر 139 MB مال unrar. سنگین‌ترین ترمیم اکنون حافظه هم هزینه دارد: روش سریع‌تر برای 512-به‌بالا بلوک گمشده از دادهٔ بازیابی نگه‌داشته‌شده در حافظه کار می‌کند، پس تا یک‌چهارم RAM ماشین به آن اجازه داده می‌شود، سقف‌زده روی 4 GB، و ماشینی که آن مقدار را ندارد بی‌سروصدا روش کم‌حافظه را به‌جایش می‌گیرد - همان حساب و همان زمان‌های سطرهای میانی جدول PAR2، فقط نه آن 3 برابر روی آخری. اگر کوچک‌ترین مجموعهٔ کاری ممکن برای یک کار مستقل می‌خواهید، ابزارهای اختصاصی هنوز آن ستون را می‌برند.

اثبات انتقال · اندازه‌گیری‌شده روی 1.2.2

موتور با خط‌های واقعی همراهی می‌کند

• ~8.7 گیگابیت بر ثانیه پیوسته در سراسر یک ناوگان پنج-ارائه‌دهنده روی یک خط 10 GbE، از جمله تأیید و استخراج درون‌جریانی - دور 87 GB بالا، 24 اوت 2026، ‏v1.2.2، 360 اتصال: 77.4 GB سیم در 71 ثانیه با محموله تأییدشده و استخراج‌شده همان‌طور که می‌رسید. عددی از یک انفجار کوتاه نیست: کل کار با آن نرخ.
• روی 1 گیگابیت و پایین‌تر، خط سقف است و nzbfast رویش می‌نشیند: ~96٪ از یک خط 500 مگابیتی و ~96٪ از یک خط 250 مگابیتی در سراسر تأیید و استخراج، با کسری از حافظه و دیسک هر رقیب - بخش زیر-گیگابیت بالا.
• هزینهٔ پردازندهٔ کل کار روی کار 87 GB 1.7 ثانیهٔ پردازنده برای هر GB است با تنظیم‌کنندهٔ اتصال روشن - دانلود روی TLS، تأیید، آمادگی‌ترمیم و استخراج هم جزوش - در برابر 3.0 تا 28 برای میدان در همان دور؛ بازوی تمام-توان‌عملیاتی بالا 4.3 خرج می‌کند.

برش‌های پیشین این صفحه مجموعه‌ای گسترده‌تر از نمایش‌های انتقال حمل می‌کردند - اجراهای اشباع چندخطی، سودهای پایپ‌لاین هر-RTT، اثباتی از فشار-پس‌رونده، اندازه‌گیری‌های سقف کدگشایی - مسابقه‌داده‌شده روی ساخت‌هایی که v1.2.2 از آن‌زمان جایگزین کرده. زیر قاعدهٔ این صفحه بازنشسته می‌شوند به‌جای رهاشدن برای کهنه‌شدن، و همان‌طور که روی انتشار فعلی دوباره بریده شوند برمی‌گردند؛ سه ادعای بالا آنهایی‌اند که از پیش روی v1.2.2 دوباره اندازه گرفته شده‌اند.