בדיקות ביצועים

הגרסה הקצרה · נמדד 23 באוגוסט 2026 על קו הקוד ששוחרר בתור nzbfast 1.2.2

אין קליינט נמדד שזול יותר במעבד, בזיכרון ובדיסק ביחד

הסבבים החדשים ביותר בדף הזה רצו ב-23 וב-24 באוגוסט 2026 - החדש שבהם על בניית השחרור של v1.2.2 עצמה - מול הבניות העדכניות של ארבעה קליינטים אחרים על חומרה, קווים וספקים זהים: שתי צורות משימה מ-6.5 עד 87 GB, וקצבי קו מ-250 Mbit עד 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, כך שהבנייה שהפיקה את המספרים החדשים היא זו שאפשר להוריד. הסבבים האלה רצו על מכונת Apple Silicon עם 20 ליבות על קו של 1 Gbit. טבלאות ישנות יותר שומרות על הבניות והמכונות שמולן רצו (מכונות Apple מסדרת M: "אירופה" M1 Ultra על 10 GbE, "החוף המזרחי" M3 Ultra קו ~2.4-3.0 Gbps) ואומרות זאת; הן מפחיתות מהבנייה המשוחררת במקום להחמיא לה.
• הוגנות: אותם ספקים ו-TLS בכל מקום לכל קליינט, המקטעים רצים משולבים בזה אחר זה. כל מתחרה מכוונן למיטבו המתועד: SABnzbd קיבל pipelining_requests=8 (הוא מגיע עם 1, כלומר ללא צנרת, וההגדרה הזו שווה אחוזים דו-ספרתיים במשימות גדולות), NZBGet קיבל ArticleCache/DirectWrite/DirectUnpack/ParQuick, ו-rustnzb את התצורה המתועדת שלו. מאז 20 באוגוסט 2026 כל סבב מריץ חמישה ספקים ולא שישה - מספר הספקים אינו מנוף תפוקה על המכונות האלה, שבהן ספק בודד יכול להגיע לתקרת הקו בעצמו, ומערך קבוע שומר על הסבבים ברי-השוואה - כך שמספר על שישה ספקים בעמוד הזה אינו בר-השוואה ישירה למספר חדש יותר על חמישה, וכל טבלה מציינת כמה היא הריצה.
• מצב סופי: קובץ מאומת, מחולץ, שמיש - לא "ההורדה הסתיימה". לזה אתם באמת מחכים.
• ניתנות לשחזור: כל טענה מתוארכת ונמדדת באותה דרך: זמן שחלף + מוני בייטים של הממשק + שיא RSS של עץ התהליכים, ברזולוציה של 1-2 s. היכן שמקטע רץ על קובץ NZB שפורסם בפומבי, אנחנו נוקבים בשמו כדי שתוכלו להריץ אותו בעצמכם.
• הערות שיטה שחלות על העמוד כולו: זמן המעבד נדגם מעץ התהליכים בתדר 2 Hz בכל זרוע של טבלה, ולעולם אינו מוצב לצד מספר מחשבונאות אחרת, כי שתי השיטות חלוקות בכוונה. קלט/פלט לדיסק מצוטט ב-GiB ובייטים על הקו ב-GB עשרוני; אנחנו ממירים לפני שאנחנו מחלקים. וכל טבלה שמריצה את הבנייה שלנו מול הבנייה שלנו נושאת בקרת A/A - אותו בינארי מתחרה מול עותק זהה-בית של עצמו דרך אותו מתקן - כי בקרה כזו היא איך תפסנו את מתקן ההשוואה שלנו עצמו נותן קנס של כ-1.5% למי שרץ ראשון (הסיפור נמצא לצד טבלאות החילוץ למטה). שתי זרועות והחלפת סדר אינן מבטלות הטיה שנוחתת תמיד על הזרוע הראשונה; בקרת A/A חושפת אותה.

קווים איטיים יותר · נמדד 24 באוגוסט 2026 על nzbfast 1.2.2

ככל שהקו איטי יותר, כך הפער במהירות בין הקליינטים קטן - והחשבון גדל

על קו איטי מספיק, זמן הסיום של כל קליינט הוא הקו עצמו ולא יותר, כך שקו איטי מסתיר הרבה חטאים. מה שהוא לא יכול להסתיר הוא מה שכל קליינט שורף כדי למלא אותו. עיצבנו את מתקן ה-1 Gbit לשני קצבים שתוכניות אמיתיות באמת מציעות והרצנו את כל שש הזרועות בכל אחד - אותה מכונה, אותם חמישה ספקים, שלוש חזרות לכל קליינט כשהסדר מסתובב, כל מקטע נבדק בית-בית, 36 מתוך 36 נכונים לאורך שני הסבבים. זרוע ה-nzbfast ב-500 Mbit היא בניית השחרור של v1.2.2 עצמה.

קראו את שתי הטבלאות כמדרג. ב-250 Mbit כל השדה נוחת בתוך 18% על השעון ואנחנו מובילים את המתחרה הקרוב ביותר ב-4.4%; ב-500 Mbit הפער נפתח ל-14.7%; בקצבי הגיגה-ביט וה-10 GbE בטבלאות שלמעלה ולמטה הוא נפתח עוד יותר. הפערים במהירות גדלים עם הקו. עמודות המשאבים לא מחכות לקו מהיר: בכל קצב שנמדד, כל מתחרה החזיק לפחות פי 3.9 מהזיכרון, הוציא יותר מעבד, והזיז בערך פי שניים מבייטי הדיסק לאותו קובץ זהה בית-בית.

וסת החיבורים מוכיח את עצמו בקווים איטיים, ומונה הזריקות של המעצב עצמו אומר למה. ברירות המחדל שנשלחות החזיקו 25 חיבורים במקום שכל מתחרה הריץ מאות; אותו בינארי עם הוסת כבוי הריץ 360. פחות זרימות דרך תור קבוע פירושו פחות אובדן ופחות שליחה חוזרת: המעצב רשם כ-4,200 זריקות למקטע מוגבל מול כ-155,000 לא-מוגבל ב-500 Mbit, והזרוע המוגבלת הייתה מהירה יותר, קלה פי 4.2 בזיכרון וקלה פי 1.3 במעבד מהעמדה שלנו עצמנו ב-360 סוקטים. יותר חיבורים אינם יותר מהירות; מתחת לגיגה-ביט זה מדיד להיפך.

נמדד 24 באוגוסט 2026, חציונים של שלוש, על מכונת Apple Silicon עם 20 ליבות שהקו שלה עוצב לכל קצב (הקצב המעוצב אומת בבדיקה עצמאית לפני כל סבב: 248 ו-496 Mbit). זרוע ה-nzbfast ב-500 Mbit היא בניית תגית השחרור v1.2.2; הסבב ב-250 Mbit רץ שעות קודם לכן על אותה שורת קוד. ספירת הבייטים על קו מעוצב נקראת ממונה הקליינט עצמו, לעולם לא מממשק הרשת (המעצב זורק ו-TCP שולח מחדש, כך שהממשק סופר את שני העותקים). הזמנים ברי-השוואה בתוך כל טבלה, לא בין סבבים מעוצבים באופן שונה. ¹ שלושת המקטעים של NZBGet ב-500 Mbit נעו בין 114-158 s עם קריאות משאבים שטוחות - פיזור אמיתי, כך שהחציון מצוטט והפיזור מוצהר במקום לצמצם אותו.

הפוסט הפגום · הורץ מחדש 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 s - פיזור אמיתי על קלטים זהים, כך שהממוצע מצוטט עם הטווח מוצהר. ² ‏rustnzb 1.4.5 סיפק כל מקטע נכון בית-בית, והעלות שלו יושבת בזמן מעבד ולא באמינות: כ-1,620 שניות-מעבד מול שעון של 107 s בנזק הכבד ביותר - בערך חמש עשרה ליבות עסוקות לאורך כל המקטע - כשאותו פלט מתוקן עולה לנו כ-50 שניות-מעבד. ³ Weaver הזיז 1.5 GB ו-4.9 GB מתוך ה-6.5 בתוך מגבלת 20 הדקות שלנו בשתי רמות הנזק הכבדות יותר - אותה אי-סיום בכל שלושת הסבבים שהריצו אותו, בשלושה לילות נפרדים; המגבלה היא שלנו והתוצאה היא אי-הסיום. ב-5 מאמרות מתות הוא סיים נכון בכל שלוש הפעמים. עלות המעבד שלו שם היא סיפור בפני עצמו: כ-2,325 שניות-מעבד למקטע של 194 s, מול ה-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 Gbit, חמישה ספקים, 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.

נמדד על מכונת Apple Silicon עם 20 ליבות, קו 1 Gbit, חמישה ספקים, שלוש חזרות בכל גבול, כל מקטע שהושלם נבדק בית-בית - שורות המתחרים ב-22-23 באוגוסט 2026 (התא של 34 GB של Weaver הורץ מחדש ב-24 באוגוסט, הערה 1), ושורת nzbfast נחתכה מחדש על בניית השחרור v1.2.2 ב-24 באוגוסט, ששיחזרה את שני הגבולות בדיוק, 12 מתוך 12 מקטעים פה-אחד על פני שני התרחישים. התאים שלנו הם רצפה נמדדת: המשימה מסתיימת 3 מתוך 3 עם 48.6 MB ו-51.0 MB רזרבה, ומסרבת 3 מתוך 3 בערך 17 MB מתחת לכך - כך שהרצפה אמיתית בשני הכיוונים. מה שהמשימה בפועל מחזיקה מתייצב על הפלט ועוד כ-3 MB; הרזרבה משלמת עבור הרגעים האחרונים של הצינור, לעולם לא עבור עותק שני. התאים של המתחרים הם הרצפה הנמדדת שלהם במשימה של 6.5 GB ומספיקות מאושרת באותו יחס במשימה של 34 GB (3 מתוך 3 נכונים בית-בית באותו יחס בדיוק); לא ירדנו בסולם שלהם עוד יותר בגודל הגדול, כך שהרצפה האמיתית שלהם שם עשויה לשבת מעט מתחת ליחס, ואנחנו אומרים זאת במקום לעגל לטובתנו.

מה שהיגמרות שטח פנוי נראית כמוה בפועל חשוב לא פחות מהמספר. ב-17 MB מתחת לרצפה שלו nzbfast פוגע בסירוב הדיסק על כתיבה, נעצר בניקיון עם "אין שטח פנוי בדיסק", שומר את כל מה שנחת ביומן, והרצה חוזרת ממשיכה בלי להוריד מחדש - חלקי שאתם שומרים, לא משימה שנכשלה. ¹ התא של Weaver בתרחיש הגדול הוכרע בהרצה חוזרת ב-24 באוגוסט: שלושה מקטעים מתוך שלושה נכונים בית-בית באותו ~פי 2.25, כל אחד מהם מהיר יותר מהמקטע הטוב של הניסיון הראשון, על שטח פנוי זהה עד לבית. בניסיון הראשון, ב-23 באוגוסט, שניים משלושת המקטעים שלו נתקעו במהירות של ספרה בודדת MB/s עם יותר מ-60 GB עדיין פנויים ופגעו במגבלת 40 הדקות של הסבב. התקיעות האלה לא חזרו, ומדידת התקיעות של המתקן הייתה פרוסה ושקטה בכל שלושת מקטעי ההרצה החוזרת, וזו מדידה חיובית ולא היעדר מדידה. מה גרם להן עדיין לא ידוע, והרצה חוזרת נקייה אינה אבחנה: כיום קיימים שישה מקטעים ביחס הזה, ארבעה מהם הושלמו, ושני הכשלים מגיעים מחלון אחד של 80 דקות בלילה הראשון.

פרסומים מקוננים · נמדד ב-28 באוגוסט 2026

עשר דרכים לעטוף פרסום, ומי באמת מגיע אל הקובץ

חלק גדול ממה שמתפרסם קשה לפתיחה במכוון. שם הקובץ האמיתי קבור בתוך ארכיון שני, לפעמים שלישי, לפעמים בפורמט אחר בכל רובד, כדי שהפרסום יסגיר כמה שפחות על מה שהוא מכיל. על כך מתווסף שפרסומים מגיעים פגומים: מאמרים פגים, העלאות נוחתות חלקיות, ויש להשתמש בנתוני השחזור לפני שאפשר לחלץ משהו בכלל. תוכנת הורדה או שעוברת את השרשרת הזו עבורכם, או שהיא מוסרת לכם תיקייה מלאת ארכיונים ועוצרת.

לכן בנינו עשר צורות שמבודדות בדיוק את זה, העמדנו מולן כל תוכנה עדכנית, ואז עשינו את מה שהשוואות בדרך כלל מדלגות עליו: היכן שתוכנה עצרה מוקדם, סיימנו את העבודה ידנית בכלים הסטנדרטיים ומדדנו גם את הזמן הזה. תוכנה שמוותרת מהר נראית מהירה עד שסופרים את העבודה שהיא משאירה לכם.

nzbfast היא היחידה שמסיימת את כל העשר בלי עזרה. גם NZBGet מגיעה אל הקובץ בכל צורה, אך נדרשות לה 16 סבבים של תיקון וחילוץ ידניים בשמונה מהן. SABnzbd מסיימת חמש בכוחות עצמה, ושתיים נותרות בלתי נגישות אפילו ידנית. Weaver מגיעה אל הקובץ בשתיים.

התבנית אינה מקרית. הצורות ש-nzbfast עוברת והאחרות לא הן העטופות והפגומות: ארכיון בתוך ארכיון, החלפת פורמט באמצע השרשרת, שרשרת בת חמישה רבדים, ומעל הכול ארכיון שמגיע פגום ולצדו נתוני השחזור שלו עצמו. באחרונה, ארבע תוכנות מחלצות את המערך החיצוני בצורה מושלמת, מוסרות לכם את הארכיון הפגום יחד עם מערך השחזור שהיה מתקן אותו, ועוצרות.

היכן שהתוכנות משלימות את אותה עבודה, הפער אינו קטן. אלה שבע הצורות שכל ארבע התוכנות הנפוצות מגיעות אליהן, כולל התיקון הידני שכל אחת נזקקה לו:

פי ארבעה עד חמישה מהר יותר, בפחות ממחצית הבתים שנכתבו. נתון הדיסק הוא זה שממשיך להיות משמעותי אחרי ההורדה: כל ג'יגה-בייט בעמודה הזו הוא ג'יגה-בייט שהכונן שלכם נאלץ לקלוט, והתוכנות שמשתמשות באזור ביניים כותבות את התוכן, קוראות אותו בחזרה וכותבות אותו שוב.

היכן שאיננו מובילים, ומדוע ראוי לומר זאת. בארבע מתוך עשר הצורות מתחרה כותב פחות בתים מ-nzbfast במהלך ההורדה עצמה. בכל פעם משום שעשה פחות: בצורה עם הארכיון הפנימי הפגום, NZBGet כותב 3.29 GB לעומת 4.65 שלנו, ואז סבב התיקון שלו כותב עוד 2.91 ומסיים ב-6.20 GB לעומת 4.65 שלנו. באחרות, התוכנה שכתבה הכי מעט היא כזו שלא הגיעה אל הקובץ כלל. נתון דיסק נמוך אינו תמיד חיסכון.

אלה מבחני יכולת, לא מבחני מהירות. התכנים קטנים ומוגשים מהזיכרון דרך חיבור מקומי, בלי ספק וללא רשת בדרך, ולכן דבר כאן אינו מוגבל במהירות ההורדה והשניות המוחלטות קצרות בהרבה ממה שאותן צורות היו לוקחות במציאות. השאלה אם צורה דורשת עבודה ידנית בכלל היא תכונה של הצורה ושל התוכנה, והיא עוברת ישירות. השניות משוות בין תוכנות שמבצעות עבודה זהה; הן אינן חוזות כמה זמן תימשך משימה אמיתית.

התוצאות המלאות לכל צורה, מהי כל צורה, והשיטה נמצאים בעמוד הנתונים על ארכיונים מקוננים.

למה זה חשוב

הכונן שלכם עושה חצי מהעבודה

אחסון פלאש מתבלה מכתיבה אליו. פרסום של 94 GB עולה לכונן שלכם כ-90 GB של כתיבה תחת nzbfast; תחת קליינט שעושה שלבים ופורק, אותו פרסום עולה בערך כפול. ב-NAS עם דיסקים קשיחים הצורה החד-מעברית גם מסירה את המעבר החד-הליכי הארוך בסוף כל הורדה מוצפנת - השהיה שנמדדה ב-20 שניות על תחנת עבודה מהירה עם 32 ליבות עם פתיחה מואצת-חומרה, וארוכה בהתאם על המכונות חלשות-ההספק שרוב האנשים בפועל מריצים את זה עליהן. אנחנו מצטטים את המספר הקטן כי הוא זה שמדדנו.

השוואות רכיבים

בדיקות הביצועים הטכניות יותר, למי שאוהב עוד נתונים

תיקון (PAR2) ופריקה (RAR) הם קוד ילידי משלנו ולא בינאריים ארוזים של צד שלישי, אז אנחנו גם מריצים אותם בעצמאות מול הכלים הייעודיים על קורפוסים זהים, על ארבע מכונות שמשתרעות על מה שקורא אולי באמת מחזיק. זמן נספר רק כשהפלט זהה בית-בית למטען המקור: כל מספר RAR למטה נבדק ב-sha256 מול המקור, וכל קובץ מתוקן מול המערך הטהור.

חילוץ RAR: 7 צורות ארכיון, 6 כלים

הסבב הקודם של הטבלה הזו השתמש ב-100 MB עד 200 MB לכל צורה, וזו הייתה טעות: כ-28 ms של הפעלת תהליך היו 40% ממקטע ה-store, והסדר שהם הפיקו לא שורד בגודל ריאלי. הסבב הזה הוא 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; אנחנו מצמידים את ה-commit ולא גרסה כי החבילות (crates) שלו נושאות שלושה מספרי גרסה שונים.

היכן שהשדה לא הצליח להתחרות, ולמה. ¹ ה-7-Zip שמתחרה כאן הוא חבילת Homebrew, שמסרבת לכל צורה דחוסה עם ERROR: Unsupported Method וקוראת רק את הצורה המאוחסנת ב-macOS. גרסה קודמת של העמוד הזה תלתה זאת בבנייה של 7-Zip ל-macOS, מה שהיה שגוי: Homebrew בונה אותו בלי הקודק unRAR הלא-חופשי, בזמן שבניית ה-macOS ש-7-zip.org משחררת נושאת את הקודק ומפענחת את כל שבע הצורות, כמו בניית Windows. נמדד מחדש 14 באוגוסט 2026. אם אתם מתקינים את 7-Zip מהפרויקט ולא מ-Homebrew, העמודה הזו לא מתארת את מה שיש לכם. ² ל-bsdtar אין תמיכה ב-RAR5 מרובה-כרכים והוא הפיק קובץ קטוע בלי לדווח שגיאה, כך שהמקטע הזה הוא כשל נכונות ולא זמן איטי; המתקן שלנו תפס את זה על ידי בדיקת הפלט, וזו הסיבה שכדאי לבדוק את הפלט. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ ‏unar לא משחררת שום כלי שורת-פקודה ל-Windows, כך ששדה הלפטופ הוא חמישה. ⁶ קבוצת ה-M5 Max מריצה את שלושת הכלים שקורא ב-macOS באמת היה פונה אליהם - unrar, ‏rarpar ואנחנו; unar, ‏bsdtar ו-7-Zip לא התחרו על המכונה הזו. ה-unrar שלה הוא 7.22, הבנייה החדשה ביותר שרצה שם ללא השגחה.

כל צורה על כל מכונה חוץ מאחת, וזו תיקו. צורות ההתאמה-הקצרה מגיעות לשני דברים ספציפיים במפענח שלנו. התאמה של שניים עד שלושים ושניים בייטים נהגה לשלם עבור קריאה מלאה לשגרת העתקת-הזיכרון של הפלטפורמה, והקריאה עלתה יותר מההעתקה; העתקת שלושים ושניים בייטים קבועים דרך רגיסטר במקום זאת היא הסיבה ש-repetitive, ‏solid ומילון ה-128 MiB - שלוש הצורות הבנויות מהתאמות קצרות - כולן מהירות בבת אחת. והצ'קסום רץ במורד הזרם של תהליכון הכותב ולא עליו. התא היחיד שאיננו מנצחים בו באופן מוחלט הוא הצורה המאוחסנת בשולחן העבודה עם 32 הליבות, שבו unrar ואנחנו במרחק שלוש מילישניות זה מזה במקטע שהוא טהור הזזת בייטים - זהה ברמת הדיוק של הטבלה הזו, כך ששני התאים מסומנים וזה מקבל ציון תיקו, לא הפסד ולא ניצחון.

הצורה שבה אנחנו מנצחים הכי הרבה היא זו שיוזנט באמת מפרסמת מאות ממנה בכל פעם: 400 קבצים קטנים, פי 4.3 ופי 4.4 מול unrar ופי 5.4 עד פי 5.5 מול rarpar. זו מקביליות לפי-חבר, וזה ההבדל בין מחלץ שנכתב לתור הורדות לבין אחד שנכתב לשורת פקודה. הצורה המאוחסנת, שהמפקד שלמעלה אומר שהיא 84% מהבייטים על הקו, היא כמעט תיקו עבור שלושת הכלים הרציניים, כי בשלב הזה כולם פשוט מזיזים בייטים.

בחירה אחת ששווה להצהיר עליה. הארכיונים ארוזים כשהדחוס מוצמד לארבעה תהליכונים. פיצול הבלוקים של RAR אחרת עוקב אחרי מספר הליבות של המכונה שארזה את הארכיון, כך שמכונה עם 32 ליבות ומכונה עם 20 ליבות מייצרות בייטים שונים מאותו קלט והמכונות מפסיקות להיות ברות-השוואה. הצמדה הופכת את קורפוס החילוץ לזהה-בית בכל מקום, וזו הנקודה, אבל היא גם מגבילה כמה מהפענוח יכול לרוץ במקביל - אז כששתי הצורות הקרובות ביותר היו הפסדים הרצנו אותן מחדש מול ארכיונים שנארזו עם כל 32 התהליכונים, כדי לבדוק שההצמדה לא הייתה הגורם. היא לא הייתה: solid זזה מ-4.2% מאחור ל-2.4% מאחור ומילון ה-128 MiB מ-6.6% ל-6.3%, אותו סדר בשני המקרים. שתיהן עכשיו ניצחונות בקורפוס המוצמד במרווח רחב יותר ממה שהבדיקה הזו יכלה להסביר.

למה אין שורת RAR4, ומה קורה לפרסומים האלה. כל צורה שלמעלה היא RAR5 או RAR7, וזה מה שיוזנט מפרסמת היום. ארכיוני RAR4 ישנים יותר עדיין צצים, ואותו מנוע קורא אותם, כולל הצורות הדחוסות והמוגנות-בסיסמה, באותו מעבר יחיד כמו החדשים יותר במקום לכתוב את הכרכים לדיסק ולפרוק אותם אחר כך. הם לא מקבלים שורה כאן כי rar 7.23 הרשמי כבר לא יכול ליצור RAR4, כך שאין קורפוס ניטרלי להתחרות בו על השדה; העבודה הזו נבדקת מול ארכיונים שנכתבו על ידי WinRAR 3.00 במקום זאת, בית בבית מול unrar.

אימות ותיקון PAR2: מערך של 1 GiB, ארבע רמות נזק

קורפוס: 1 GiB של מטען אקראי ארוז במצב store לתוך 21 כרכי RAR, ואז שני מערכי PAR2 ברדונדנטיות של 10%, אחד בבלוקים של 1 MiB ואחד ב-64 KiB, ואז מפות נזק קבועות. כל הרצה משתמשת באותו פרוטוקול: עותק טרי, קריאת הקורפוס כולו פעם אחת לחימום המטמון, ואז תזמון. הטוב מבין שלושה סבבים משולבים; כל כרך מתוקן מושווה מול המערך הטהור בכל סבב. נמוך יותר טוב יותר.

תיקון לגבי הקורפוס, כי גרסה קודמת של העמוד הזה הגזימה בו. אמרנו שכל מכונה הריצה קורפוס זהה-בית, נבדק בגיבוב. גיבוב כל כרך בכל מערך מראה שזה נכון לגבי שולחן העבודה עם 32 הליבות ולפטופ ה-Windows, שתואמים בדיוק, ולא לגבי שולחן העבודה עם 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 מסוג Metal שלו מופעל. ה-par2j של MultiPar הוא Windows-בלבד, כך שהוא מופיע רק בשורות לפטופ ה-Windows. שורות ה-M5 Max מריצות את שני הכלים עם בניות arm64 עדכניות ל-macOS לצד שתי עמודות הטורבו; par2cmdline הקלאסי לא התחרה על המכונה הזו.

כל שישה עשר תאי nzbfast - ארבע מכונות בארבע רמות נזק - הם שלנו, כמה מהם ביותר מפי 2 מול הבנייה המכוונת ובפי 2.3 עד פי 7.7 מול זו שהייתם באמת מורידים. תאי הנזק הכבד הם המעניינים, וההערה למטה מסבירה את האלגוריתם שמאחוריהם.

המקורי חזר לטבלה, וכדאי לראות למה הפיצול קיים. גרסה קודמת של העמוד הזה הסירה את עמודת par2cmdline בטענה שהיא הייתה איטית יותר מכל השאר בסבב, וזה נכון ולא סיבה מספיק טובה: זה היישום שכמעט כל כלי אחר צאצא ממנו, וקוראים ראויים לקו הבסיס במקום לטענה שלנו עליו. ברמת הנזק הכבדה ביותר זה לוקח כ-69 s שבו הפיצול ה-SIMD לוקח 3.2 s ואנחנו לוקחים 3.1 s. המקדם עשרים הזה הוא כל הטיעון עבור הגרעינים המכתובים ביד של שדה גלואה, וזה אותו טיעון שאנחנו עושים עבור שלנו.

נזק קל הוא המקרה שחשוב. כמה מאמרות שנכשלו הרבה יותר טיפוסי מ-101 בלוקים מתים, ולא כלום כמו 1,500. רוב תיקון קל אינו מתמטיקת Reed-Solomon בכלל, זו קריאה וגיבוב MD5 של גיגה-בייט, וזו הסיבה ששורת 3 הבלוקים עוקבת אחרי שורת האימות-הנקי ולא אחרי שורות התיקון.

רמת הנזק הכבדה ביותר היא סוג עבודה שונה, והיא מקבלת אלגוריתם שונה. הרמה האחרונה הזו פוגעת ב-1,500 בלוקים על פני כל 21 הכרכים וצורכת כ-91% מנתוני השחזור, וזה המקום שבו החשבון של Reed-Solomon, ולא הגיבוב או הדיסק, הופך כמעט לכל העבודה. בניית השחרור מחשבת את התיקונים הכבדים ביותר עם התמרה תורת-מספרית במקום קיפול שדה-גלואה הקלאסי - אותה מתמטיקה, מוערכת בצורה שמתרחבת הרבה יותר טוב במספרי בלוקים גבוהים: פי 2.7 לפני הבנייה המכוונת בשולחן העבודה עם 20 הליבות, ובלפטופ ה-Windows פי 2.7 לפני הבנייה המכוונת ופי 2.2 לפני MultiPar. נזק קל עדיין רץ בנתיב הקלאסי, וזו הסיבה שהרמות האחרות בקושי זזו: ההתמרה משתלמת רק מעל כ-512 בלוקים פגומים, כך שמתחת לזה המתזמן לא משתמש בה.

נתיב מהיר יותר שווה רק אם הוא לא יכול להיות שגוי. שני הנתיבים מחשבים את אותה כמות והם זהים-סיבית מבנייתם, וכל תיקון בעמוד הזה נשער מול הקבצים שנבנו מחדש תואמים למערך הטהור: 228 תיקונים מתוזמנים על פני המכונות בסבב הזה, אפס אי-התאמות. בניית השחרור לא נשענת על השיא הזה. כל תיקון מאמת את הפלט שלו עצמו מול גיבובי הקבצים, ואחד שנכשל יבוצע מחדש אוטומטית בנתיב הקלאסי, ירשום ביומן את הסטייה, וישמור על הנתיב הקלאסי לשארית ההרצה הזו. ההגדרה נמצאת בלוח המחוונים בתור מצב PAR מהיר אם הייתם מעדיפים לא להחזיק אותה בכלל, ומכונות עם מעט מדי זיכרון עבורה מסרבות לה מעצמן במקום לנסות ולהיכשל. נמדד מחדש ב-2 באוגוסט על הבנייה הנוכחית: שני שולחנות העבודה נוחתים בתוך כמה אחוזים מהטבלה הזו, ועם מצב PAR מהיר כבוי שולחן העבודה עם 20 הליבות נופל בחזרה בדיוק לזמן האיטי יותר של הנתיב הקלאסי, וזה מה שאומר שהניצחון הוא השיטה ולא התנאים.

עמודת לפטופ ה-Windows הזדקקה לתיקון, והוא פועל נגדנו. Windows מוריד עבודת רקע מתמשכת לליבות היעילות שלו אחרי כמה שניות. הדימון שלנו יוצא מכך בהפעלה ושום כלי אחר לא יכול, כך שגרסה קודמת של העמוד הזה פרסמה את הזמנים המוגבלים שלהם כאילו היו הזמנים של הכלים עצמם. הרצה חוזרת של המכונה הזו עם כל כלי מורם לעדיפות גבוהה מזיזה את כל השדה: ברמת הנזק הכבדה ביותר par2-turbo זז מ-22.4 s ל-6.41 ו-rarpar מ-59.2 s ל-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 מכל קבוצה על פני הקובץ, פעם אחת לקבוצה. היא עכשיו עושה מעבר סדרתי אחד בסדר הקובץ עם צ'קסומים לפי-רסיס מחושבים במקביל, והכרך המתוקן משוכפל ולא מועתק היכן שמערכת הקבצים יכולה לעשות זאת. האיתור לבדו ירד מכ-300 ms ל-18 ms בארכיון של 512 MB, וזה רוב מה שזז למעלה. הבקרה היא העמודה לצד שלנו: rar r הורץ מחדש באותם סבבים על אותה מכונה וחזר בתוך כמה אחוזים מהזמנים הקודמים שלו, כך שהשינוי בפער הוא שלנו ולא של הספסל.

ה-M5 Max חוזר על הדפוס, התחרה 31 ביולי עם אותו קורפוס ואותם שערים: 0.050 / 0.066 / 0.171 / 0.581 s מול ה-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 GiB מאוחסן לתוך 21 כרכים של 50 MB עם rar rv3, ואז כרכים 4, 11 ו-19 נמחקו - שלושה אבודים מול שלושה כרכי שחזור, שזה המקרה הגרוע ביותר שהמערך עדיין יכול לשרוד. הטוב מבין שלושה, כל כרך שנבנה מחדש מושווה מול הטהור.

התא של 32 הליבות כאן היה 3.12 s מול ה-0.47 של rar rc בחתך האחרון של העמוד הזה, פורסם כאיטי פי 6.6 והמספר הגרוע ביותר עליו. הסיבה הייתה פתרון המחיקה רץ בכ-48 MB/s של פלט שנבנה מחדש שבו RARLab ניהלה 320; זה עכשיו רץ על אותו חשבון מונחה-טבלה כמו שאר קוד השחזור, וזה שיפור פי שבעה והופך את ההפסד לניצחון בשתי המכונות. המרווחים הם 3% ו-14%, כך שזה ניצחון שכדאי להצהיר עליו בפשטות ולא לכותרת, והסיבה שהוא מוצהר בכלל היא שההפסד הוצהר קודם.

המקטע הזה קיים כי rarpar של Weaver מיישם בדיוק את זה וביקש להימדד עליו. הוא ניצח בנוחות כשפרסמנו אותו לראשונה, ופרסמנו אותו אז מהסיבה הזו.

התאמת הקבצים אף פעם לא הייתה העלות, וכדאי לרשום זאת כי זה היה החשוד האינטואיטיבי: כרכי שחזור לא נושאים שמות קבצים, כך שאנחנו מזהים אילו משבצות שרדו על ידי גיבוב כל כרך על הדיסק במקום לסמוך על איך שהם נקראים, ומול מערך לא-פגום, שבו התאמה היא כל מה שקורה, המעבר כולו לוקח 0.18 s.

מה עוד זז, והיכן זה לא מוצג. נחתו שני שינויי מנוע נוספים שהקורפוסים האלה לא יכולים לראות, רשומים כאן כדי שהמספרים למעלה לא ייקראו כל הסיפור: ארכיוני RAR5 עם עשרות אלפי חברים פותרים כל חבר פעם אחת במקום להלך על הרשימה לכל עובד, וזה פי 3 פחות זמן מעבד ב-40,000 חברים; וקורא הביטים של RAR1.3 עובד מילה בכל פעם, וזה פי 2. אף אחד מהם לא מופיע למעלה, כי לצורות כאן יש 400 חברים ובלי RAR1.3.

מה שאנחנו בכוונה לא עושים: אנחנו אף פעם לא יוצרים PAR2. למוריד אין סיבה לכך, ו-ParPar מחזיקה במקטע הזה. אנחנו גם קונים מהירות בזיכרון בשני המנועים: החילוץ מגיע לשיא של סביב 240 MB מול 41 MB של unrar, והאימות סביב 126 MB מול 7 MB של טורבו, כי אלה המנועים המשולבים שרוכבים על הורדה חיה ולא ריצות עצמאיות חד-פעמיות. צורת מילון ה-128 MiB היא הגרועה ביותר מבחינה זו, בכ-304 MB מול 139 MB של unrar. התיקון הכבד ביותר עולה עכשיו זיכרון גם הוא: השיטה המהירה יותר עבור 512-ומעלה בלוקים חסרים עובדת מנתוני השחזור שמוחזקים שוכנים, כך שהיא מורשית עד רבע מה-RAM של המכונה, מוגבלת ב-4 GB, ומכונה שלא יכולה לוותר על כך שקטה לוקחת את שיטת הזיכרון-הנמוך במקום זאת - אותו חשבון ואותם זמנים כמו השורות האמצעיות של טבלת ה-PAR2, פשוט לא פי 3 על האחרונה. אם אתם רוצים את הקבוצה השוכנת הקטנה ביותר האפשרית למשימה עצמאית, הכלים הייעודיים עדיין מנצחים בעמודה הזו.

הוכחת תעבורה · נמדד על 1.2.2

המנוע עומד בקצב של קווים אמיתיים

• כ-8.7 Gbps מוחזקים דרך צי של חמישה ספקים על קו 10 GbE, כולל אימות וחילוץ בזרם - סבב ה-87 GB שלמעלה, 24 באוגוסט 2026, v1.2.2, ‏360 חיבורים: 77.4 GB על הקו ב-71 s כשהמטען מאומת ומחולץ עם הגעתו. לא מספר פרץ: המשימה כולה בקצב הזה.
• ב-1 Gbit ומטה, הקו הוא המגבלה ו-nzbfast יושב עליו: ~96% מקו של 500 Mbit ו-~96% מקו של 250 Mbit לאורך האימות והחילוץ, בשבריר מהזיכרון והדיסק של כל מתחרה - מדור תת-הגיגה-ביט שלמעלה.
• עלות המעבד של המשימה כולה במשימת ה-87 GB היא 1.7 שניות-מעבד לכל GB עם וסת החיבורים דלוק - כולל הורדה מעל TLS, אימות, נכונות-לתיקון וחילוץ - מול 3.0 עד 28 לשדה באותו סבב; הזרוע בקצב-המלא שלמעלה מוציאה 4.3.

חתכים קודמים של העמוד הזה נשאו מערך רחב יותר של הדגמות תעבורה - הרצות רוויה מרובות-קווים, רווחי צנרת לפי-RTT, הוכחת לחץ-נגד, מדידות תקרת-פענוח - שהתחרו על בניות ש-v1.2.2 החליפה מאז. תחת כלל העמוד הזה הן פורשות במקום להישאר להזדקן, וחוזרות כשהן נחתכות מחדש על השחרור הנוכחי; שלוש הטענות שלמעלה הן אלה שכבר נמדדו מחדש על v1.2.2.