Vertailut

Lyhyt versio · mitattu 23. elokuuta 2026 koodilinjalla, joka julkaistiin nimellä nzbfast 1.2.2

Yksikään mitattu asiakas ei ole halvempi prosessorin, muistin ja levyn suhteen yhdessä

Tämän sivun uusimmat kierrokset ajettiin 23. ja 24. elokuuta 2026 - uusin niistä itse v1.2.2-julkaisuversiolla - neljän muun asiakkaan senhetkisiä versioita vastaan, samalla laitteistolla, linjoilla ja palveluntarjoajilla: kaksi työn muotoa 6,5:stä 87 GB:hen, ja linjanopeudet 250 Mbit:stä 10 GbE:hen. Näillä kierroksilla yksikään asiakas ei ollut nzbfastia halvempi prosessorin, muistin ja levyn suhteen yhdessä: jokainen maksaa enemmän vähintään kahdella kolmesta, suurin minkä tahansa niistä säästämä osuus millään yksittäisellä akselilla oli noin 2 prosenttia - tilastollinen tasapeli, kyseisen asiakkaan oman ajojen välisen vaihtelun sisällä - ja levyllä jokainen niistä siirsi vähintään kaksinkertaisen määrän tavuja tavulleen identtiseen tulokseen. Oletusasetuksin nzbfast piti myös vähiten muistia jokaisesta mitatusta asiakkaasta, jokaisessa testissä, 2,0x-4,5x lähimpään kilpailijaan nähden.

Kumpi näistä olet sinä?

Useimmat lataajat kirjoittavat latauksesi levylle vähintään kahdesti: kerran sitä ladatessa, ja uudelleen sitä purkaessa. nzbfast tekee koko työn yhdellä läpiajolla, joten se kirjoittaa noin puolet tavuista per työ, pitää vähemmän muistissa työskennellessään ja käyttää vähemmän prosessorisekunteja per GB. Se tarkoittaa vähemmän kuormaa koneellesi sitä käyttäessäsi ja puolet vähemmän kirjoituksia per työ levyillesi, samoista tavulleen identtisistä tiedostoista - ja koska jokainen tavu kulkee levyn yli noin kerran, levysi tarvitsee pysyä linjasi tahdissa vain kerran.

nzbfast ei voita jokaista taulukkoa tällä sivulla, ja ne joita se häviää löytyvät kohdasta erät, joita emme voita - mukaan lukien yksi tältä samalta kierrokselta. Se, mikä piti paikkansa jokaisella mittaamallamme kierroksella, on yhdistetty lasku.

Menetelmä ensin

Koeasetelma

• Asiakkaat: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, jokainen taulukko nimeää käyttämänsä versiot. Uusimmat kierrokset (23. elokuuta 2026) kilpailivat kentän silloisia senhetkisiä versioita vastaan - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 ja Weaver 0.7.8, sen uusin julkaistu binääri, identiteetti todistettu tiivisteellä - koodilinjaa vastaan, joka julkaistiin sinä yönä nimellä nzbfast 1.2.2, eli versio joka tuotti uudet luvut on se, jonka voit ladata. Nämä kierrokset ajettiin 20-ytimisellä Apple Silicon -koneella 1 Gbit:n linjalla. Vanhemmat taulukot pitävät ne versiot ja koneet, joilla ne kilpailivat (Apple M-sarjan koneet: "Eurooppa" M1 Ultra 10 GbE:llä, "Itärannikko" M3 Ultra ~2,4-3,0 Gbps:n linjalla) ja sanovat niin; ne aliarvioivat julkaistavan version sen sijaan että kaunistelisivat sitä.
• Reiluus: samat palveluntarjoajat ja TLS kaikkialla jokaiselle asiakkaalle, erät ajettu peräkkäin lomitettuina. Jokainen kilpailija viritetty dokumentoituun parhaimpaansa: SABnzbd sai asetuksen pipelining_requests=8 (se toimitetaan arvolla 1, eli putkittamattomana, ja asetus on arvoltaan kaksinumeroisia prosentteja suurissa töissä), NZBGet sai ArticleCache/DirectWrite/DirectUnpack/ParQuick-asetukset, rustnzb dokumentoidun kokoonpanonsa. 20. elokuuta 2026 lähtien jokainen kierros kilpailee viittä palveluntarjoajaa vastaan eikä kuutta - palveluntarjoajien määrä ei ole näillä koneilla läpäisyä säätävä vipu, koska yksikin palveluntarjoaja voi yksinään saavuttaa linjan katon, ja kiinteä joukko pitää kierrokset vertailukelpoisina - joten kuuden palveluntarjoajan luku tällä sivulla ei ole suoraan vertailukelpoinen uudemman viiden palveluntarjoajan luvun kanssa, ja jokainen taulukko kertoo kummalla se ajettiin.
• Lopputila: varmennettu, purettu, käyttökelpoinen tiedosto, ei "lataus valmis". Sitä sinä oikeasti odotat.
• Toistettavuus: jokainen väite on päivätty ja mitattu samalla tavalla: kulunut aika + verkkoliitännän tavulaskurit + prosessipuun huippu-RSS, 1-2 s tarkkuudella. Kun erä ajetaan julkisesti postatulla NZB:llä, nimeämme sen, jotta voit ajaa sen itse.
• Koko sivua koskevat menetelmähuomiot: CPU-aika näytteistetään prosessipuusta 2 Hz:n taajuudella jokaisessa taulukon sarakkeessa, eikä sitä koskaan aseteta eri laskentatavalla saadun luvun viereen, koska nämä kaksi menetelmää ovat tarkoituksella eri mieltä. Levy-I/O ilmoitetaan GiB:einä ja linjan tavut desimaali-GB:ina; muunnamme ennen jakamista. Ja jokainen taulukko, jossa oma versiomme kilpailee omaa versiotamme vastaan, kantaa mukanaan A/A-kontrolli - sama binääri kilpailee tavulleen identtistä kopiota itsestään vastaan saman testivälineistön läpi - koska juuri tämä kontrolli paljasti, että oma kaksintaistelutestimme antoi ~1,5 %:n rangaistuksen sille työkalulle, joka ajettiin ensin (tarina on alempana purkutaulukoiden vieressä). Kaksi haaraa ja vaihdetut järjestykset eivät kumoa vinoumaa, joka osuu aina ensimmäiseen haaraan; A/A-kontrolli paljastaa sen.

Hitaammat linjat · mitattu 24. elokuuta 2026 versiolla nzbfast 1.2.2

Mitä hitaampi linja, sitä vähemmän nopeus erottaa asiakkaita - ja sitä enemmän lasku erottaa

Riittävän hitaalla linjalla jokaisen asiakkaan valmistumisaika on pelkkä linjan nopeus eikä mitään muuta, joten hidas linja peittää paljon syntejä. Se mitä se ei voi peittää, on se mitä kukin asiakas polttaa täyttääkseen sen. Muotoilimme 1 Gbit:n koejärjestelmän kahteen nopeuteen, joita todelliset liittymät oikeasti ovat, ja kilpailutimme kaikki kuusi haaraa kummallakin - sama kone, samat viisi palveluntarjoajaa, kolme toistoa per asiakas järjestyksen kiertäessä, jokainen erä tavulleen tarkistettu, 36/36 oikein molemmilla kierroksilla. nzbfast-haara 500 Mbit:n nopeudella on itse v1.2.2-julkaisuversio.

Lue kaksi taulukkoa liukumana. 250 Mbit:n nopeudella koko kenttä mahtuu 18 %:n sisään kellosta ja johdamme lähintä kilpailijaa 4,4 %:lla; 500 Mbit:n nopeudella ero avautuu 14,7 %:iin; gigabitin ja 10 GbE:n nopeuksilla ylä- ja alapuolella olevissa taulukoissa se avautuu edelleen. Nopeuserot kasvavat linjan mukana. Resurssisarakkeet eivät odota nopeaa linjaa: jokaisella mitatulla nopeudella jokainen kilpailija piti vähintään 3,9x muistia, käytti enemmän prosessoria, ja siirsi noin kaksinkertaisen määrän levytavuja samasta tavulleen identtisestä tiedostosta.

Yhteysrajoitin ansaitsee paikkansa hitailla linjoilla, ja muotoilijan oma pudotuslaskuri kertoo miksi. Oletusasetukset pitivät 25 yhteyttä, kun jokainen kilpailija ajoi satoja. Sama binääri rajoitin pois päältä ajoi 360:tä. Vähemmän virtoja kiinteän jonon läpi tarkoittaa vähemmän häviötä ja vähemmän uudelleenlähetystä: muotoilija kirjasi noin 4 200 pudotusta per rajoitettu erä noin 155 000:ta vastaan rajoittamattomana 500 Mbit:n nopeudella, ja rajoitettu haara oli nopeampi, 4,2x kevyempi muistin ja 1,3x kevyempi CPU:n suhteen kuin oma 360-pistokkeen asentomme. Enemmän yhteyksiä ei ole enemmän nopeutta; gigabitin alapuolella se on mitattavasti päinvastoin.

Mitattu 24. elokuuta 2026, kolmen ajon mediaanit, 20-ytimisellä Apple Silicon -koneella linjan muotoiltuna kumpaankin nopeuteen (muotoiltu nopeus varmistettu riippumattomalla mittauksella ennen jokaista kierrosta: 248 ja 496 Mbit). 500 Mbit:n nzbfast-haara on itse v1.2.2-julkaisutagin versio; 250 Mbit:n kierros ajettiin tunteja aiemmin samalla koodilinjalla. Tavumäärät muotoillulla linjalla luetaan kunkin asiakkaan omasta laskurista, ei koskaan verkkoliitännästä (muotoilija pudottaa ja TCP lähettää uudelleen, joten liitäntä laskee molemmat kopiot). Kellonajat ovat vertailukelpoisia kunkin taulukon sisällä, ei eri tavoin muotoiltujen kierrosten välillä. ¹ NZBGetin kolme erää 500 Mbit:n nopeudella vaihtelivat välillä 114-158 s tasaisin resurssilukemin - aito hajonta, joten mediaani ilmoitetaan ja hajonta kerrotaan sen sijaan että se kavennettaisiin.

Vaurioitunut postaus · uudelleen kilpailutettu 24. elokuuta 2026, jokainen versio ajan tasalla

Kun postauksessa on reikiä: 6,5 GB, ja 60, 20 sekä 5 kuollutta artikkelia

Artikkelit vanhenevat, palvelimet pudottavat niitä huomaamatta, lataukset saapuvat vajaina - ja vauriotilanne on juuri se, missä ero asiakkaiden välillä on suurin, joten se saa oman kierroksensa jokaisen asiakkaan uusimmalla versiolla, nzbfast v1.2.2 mukaan lukien: Euroopan 10 GbE:n kone, viisi palveluntarjoajaa, 100 yhteyttä per asiakas, sama 6,5 GB:n julkaisu myrkytettynä kolmella vauriotasolla, kolme toistoa per haara järjestyksen vaihdellessa, jokainen erä tavulleen tarkistettu puhdasta tiedostoa vasten. 63/65 erää palasi tavulleen identtisenä; ne kaksi jotka eivät palanneet, on nimetty alla, koska nekin ovat tuloksia.

Miksi vaurioitunut postaus on nopea tässä. Kun artikkeli puuttuu, asiakas yleensä kysyy seuraavalta palvelimelta, sitten seuraavalta, kunnes jokainen palvelin on kieltäytynyt siitä - peräkkäinen kierros, jonka kieltäytymiset kestävät mistä tahansa kymmenistä millisekunneista pariin sekuntiin kukin, ja sen ajan lataus seisoo nollassa. nzbfast lopettaa kysymisen: kun jo käsillä oleva pariteettidata kattaa sen, mikä yhä puuttuu, se korjaa välittömästi sen sijaan että se viimeistelisi kierroksen. Se on toinen rivi - sama binääri tuo käytös pois päältä kytkettynä on 1,4x-2,3x hitaampi vauriosta riippuen - ja kierros varmisti mekanismin kytkeytyneen jokaisella käytössä olevalla erällä eikä koskaan pois kytketyllä. Lähimpään kilpailijaan verrattuna marginaali on 2,4x-2,7x, ilman päällekkäisyyttä yhdessäkään yhdeksästä toistoparista.

Levy on se, missä marginaali on suurin, eikä se ole korjaustemppu. Jokainen valmistuva haara tuotti saman 6,48 GB:n tiedoston; meidän siirsimme 6,2-6,8 GB levy-I/O:ta sen tehdessämme, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB ja rustnzb 12,8-13,1 GB. Se on yhden läpiajon putki - pois kytketty rivi siirtää saman 6,2 GB - joten se pitää paikkansa sekä vaurioituneilla että vaurioitumattomilla postauksilla.

¹ SABnzbdin kolme erää raskaimmalla vauriolla ajoivat 43, 41 ja 60 s - aito hajonta identtisillä syötteillä, joten keskiarvo ilmoitetaan vaihteluväli mainiten. ² rustnzb 1.4.5 toimitti jokaisen erän tavulleen oikein, ja sen hinta on prosessoriajassa eikä luotettavuudessa: noin 1 620 CPU-sekuntia 107 s:n kelloa vastaan raskaimmalla vauriolla - karkeasti viisitoista ydintä varattuna koko erän ajan - kun sama korjattu tuloste maksaa meille noin 50 CPU-sekuntia. ³ Weaver siirsi 1,5 GB ja 4,9 GB 6,5:stä 20 minuutin katkaisurajamme sisällä kahdella raskaammalla vauriotasolla - sama keskeneräisyys kaikilla kolmella kierroksella, jotka ovat kilpailuttaneet sitä, kolmena erillisenä yönä; katkaisuraja on meidän ja keskeneräisyys on tulos. 5 kuolleella artikkelilla se valmistui oikein kaikki kolme kertaa. Sen prosessorikustannus siinä on oma tarinansa: noin 2 325 CPU-sekuntia 194 s:n erälle, meidän 20:tämme vastaan.

Mitattu 24. elokuuta 2026, kaikki versiot ajan tasalla: nzbfast v1.2.2 (itse julkaisutagi), NZBGet 26.3-testing (20. elokuuta versio), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. Jatkuvuushaara kilpailutti edellisen yön nzbfast-version tällä samalla kierroksella ja osui sekunnin sisään v1.2.2:sta jokaisessa testitapauksessa, joten mikään tässä ei nojaa onnekkaaseen yöhön; ja kilpailijoiden asetukset eroavat edellisen kierroksen asetuksista vain sovelluspolun osalta, tarkistettu avain kerrallaan ennen kierroksen ajoa.

Näännytä se RAM:ista · mitattu 24. elokuuta 2026 versiolla nzbfast 1.2.2

Niukan muistin porras: 87 GB ~0,3 GB:ssä RAM-muistia

Sama 87 GB:n työ kuin yllä olevalla kierroksella, ajettu uudelleen tiukoilla muistibudjeteilla 2 GB, 1 GB ja 256 MB - sellaisilla, jotka automaattinen koonvalitsija valitsisi 8 GB:n koneella, 4 GB:n koneella ja 2 GB:n NAS-laitteella. Jokainen erä tuotti identtisen tavulleen tarkistetun tiedoston, ja muistisarake seurasi budjettiaeikä koskaan työtä:

Yksi erä per budjetti julkaisuversiolla, portitettu samaa tulostarkistussummaa vastaan kuin kuuden haaran kierros. Tiukin budjetti maksaa noin 9 % kellosta, ja vain siksi että tämä linja on 10 GbE - vuotaneet lohkot maksavat aikaa vain kun linja ohittaa levyn, joten tyypillisellä kotiyhteydellä pieni budjetti on lähes ilmainen. Koko porras, 87 GB:n lataus mukaan lukien, mahtuu 0,3-0,6 GB:n muistiin; oletusasetuksilla työ ajettiin 286 MB:ssa. Mikään muu asiakas ei tarjoa kovaa koko prosessin muistibudjettia; lähimmät vastineet ovat välimuistin koon säätimet, ja alla oleva kierros mittaa mitä ne maksavat.

Puristin kilpailutettuna kentän omia säätimiä vastaan. 34 GB:n testitapauksessa (23. elokuuta 2026, 1 Gbit:n kone, viisi palveluntarjoajaa, 30/30 erää tavulleen oikein), NZBGetin pitäminen vastaavassa välimuistipuristimessa yli kaksinkertaisti sen CPU:n (215,5:stä 453,0:aan CPU-sekuntia, 2,10x) ostaakseen 52 %:n leikkauksen sen huippumuistiin, ja SABnzbdin puristin oli lähes ilmainen mutta ylsi vain osaan sen jalanjäljestä. rustnzb:n välimuistiasetus oli koristeellinen kilpailutetussa versiossa, eikä Weaverillä ole muistisäädintä lainkaan, joten molemmat ajoivat puristamattomina vertailusarakkeina sen sijaan että ne pisteytettäisiin budjetilla jota ne eivät voi pitää. Oman puolemme siitä kierroksesta korvaa yllä oleva v1.2.2-porras, joka sanoo saman asian 2,5x koolla: budjetti ei ole koskaan sitova rajoite, koska yhden läpiajon menetelmä pitää niin vähän hallussaan alun perinkin.

Vapaa tila · mitattu megatavun tarkkuudella

Kuinka vähän vapaata tilaa työ tarvitsee

Kirjoita-ulos-ja-pura-asiakas tarvitsee tilaa arkiston nideille ja puretulle hyötykuormalle yhtä aikaa, joten työ ei käynnisty ilman karkeasti kaksinkertaista latausta vastaavaa vapaata tilaa. Yhden läpiajon menetelmä tarvitsee vain hyötykuorman - ja tämä kierros mittasi kuinka vähän enemmän, kutistamalla kohdenidettä kunnes kukin asiakas epäonnistui. nzbfastin vastaus on vakio, noin 50 MB pelivaraa, ei suhdeluku, ja se pitää paikkansa 6,5 GB:n työstä 34 GB:n työhön.

Mitattu 20-ytimisellä Apple Silicon -koneella, 1 Gbit:n linjalla, viidellä palveluntarjoajalla, kolme toistoa kummallakin rajalla, jokainen valmistunut erä tavulleen tarkistettu - kilpailijoiden rivit 22.-23. elokuuta 2026 (Weaverin 34 GB:n solu ajettiin uudelleen 24. elokuuta, alaviite 1), ja nzbfast-rivi uudelleen mitattu v1.2.2-julkaisuversiolla 24. elokuuta, joka toisti molemmat rajat täsmälleen, 12/12 erää yksimielisiä molemmissa testitapauksissa. Solumme ovat mitattu alaraja: työ valmistuu 3/3 kertaa 48,6 MB:n ja 51,0 MB:n pelivaralla, ja kieltäytyy 3/3 kertaa noin 17 MB sen alapuolella - joten raja on todellinen molempiin suuntiin. Se, mitä työ oikeasti pitää hallussaan, asettuu tulosteeseen plus noin 3 MB; pelivara maksaa putken viimeiset hetket, ei koskaan toista kopiota. Kilpailijoiden solut ovat niiden mitattu alaraja 6,5 GB:n työssä ja vahvistettu riittävyys samalla suhteella 34 GB:n työssä (3/3 tavulleen oikein täsmälleen tuolla suhteella); emme kävelleet niiden porrasta pidemmälle alaspäin suuremmassa koossa, joten niiden todellinen alaraja siellä saattaa istua hieman suhdeluvun alapuolella, ja sanomme niin sen sijaan että pyöristäisimme omaksi eduksemme.

Se, miltä tilan loppuminen oikeasti näyttää, on yhtä tärkeää kuin luku. 17 MB alarajansa alapuolella nzbfast osuu levyn kirjoituskieltäytymiseen, pysähtyy siististi viestillä "levytila loppui", pitää kaiken saapuneen kirjattuna, ja uusi yritys jatkaa ilman uudelleenhakua - osittainen tulos jonka pidät, ei epäonnistunut työ. ¹ Weaverin ison testitapauksen solu ratkesi 24. elokuuta tehdyllä uusinta-ajolla: kolme erää kolmesta tavulleen oikein samalla ~2,25x:llä, kukin nopeampi kuin ensimmäisen yrityksen hyvä erä, vapaan tilan ollessa tavulleen sama. Ensimmäisellä yrityksellä, 23. elokuuta, kaksi sen kolmesta erästä oli juuttunut yksinumeroisiin MB/s-lukemiin yli 60 GB:n ollessa vielä vapaana ja osunut kierroksen 40 minuutin katkaisurajaan. Nuo juuttumiset eivät palanneet, ja telineen juuttumismittaus oli käytössä ja hiljaa kaikilla uusinta-ajon kolmella erällä, mikä on myönteinen mittaus eikä puuttuva. Mikä ne aiheutti on yhä tuntematonta, eikä puhdas uusinta-ajo ole diagnoosi: tällä suhteella on nyt kuusi erää, joista neljä valmistui, ja molemmat epäonnistumiset ovat samasta 80 minuutin ikkunasta ensimmäisenä yönä.

Sisäkkäiset julkaisut · mitattu 28. elokuuta 2026

Kymmenen tapaa paketoida julkaisu, ja kuka todella pääsee tiedostoon

Suuri osa julkaistusta on tarkoituksella vaikeaa avata. Todellinen tiedostonimi on haudattu toisen arkiston sisään, joskus kolmannen, joskus eri muodossa joka tasolla, jotta julkaisu paljastaisi mahdollisimman vähän sisällöstään. Lisäksi julkaisut saapuvat vaurioituneina: artikkelit vanhenevat, lähetykset saapuvat vaillinaisina, ja palautustietoja on käytettävä ennen kuin mitään voi purkaa. Lataaja joko kulkee tämän ketjun puolestasi tai ojentaa sinulle kansiollisen arkistoja ja pysähtyy.

Rakensimme siksi kymmenen muotoa, jotka eristävät juuri tämän, panimme jokaisen nykyisen asiakasohjelman niitä vastaan ja teimme sitten sen, minkä vertailut yleensä ohittavat: siellä missä ohjelma pysähtyi liian aikaisin, viimeistelimme työn käsin vakiotyökaluilla ja otimme siitäkin ajan. Nopeasti luovuttava ohjelma näyttää nopealta, kunnes lasketaan se työ, jonka se jättää sinulle.

nzbfast on ainoa, joka selvittää kaikki kymmenen ilman apua. Myös NZBGet pääsee tiedostoon jokaisessa muodossa, mutta tarvitsee 16 kierrosta käsin tehtyä korjausta ja purkua kahdeksassa niistä. SABnzbd selvittää viisi omin voimin, ja kaksi jää saavuttamattomiin käsinkin. Weaver pääsee tiedostoon kahdessa.

Kuvio ei ole sattumaa. Ne muodot, jotka nzbfast läpäisee ja muut eivät, ovat paketoidut ja vaurioituneet: arkisto arkiston sisällä, muodon vaihdos kesken ketjun, viisitasoinen ketju ja ennen kaikkea arkisto, joka saapuu rikkinäisenä omat palautustietonsa mukanaan. Viimeksi mainitussa neljä ohjelmaa purkaa ulomman joukon moitteettomasti, ojentaa sinulle rikkinäisen arkiston yhdessä sen korjaavan palautusjoukon kanssa, ja pysähtyy.

Siellä missä ohjelmat tekevät saman työn, ero ei ole pieni. Nämä ovat ne seitsemän muotoa, jotka kaikki neljä yleistä ohjelmaa saavuttavat, kunkin tarvitsema käsin tehty korjaus mukaan laskettuna:

Neljä tai viisi kertaa nopeampi, alle puolella kirjoitetuista tavuista. Levyluku on se, jolla on merkitystä vielä latauksen jälkeen: jokainen sarakkeen gigatavu on gigatavu, jonka levysi on joutunut ottamaan vastaan, ja välivarastointia käyttävät ohjelmat kirjoittavat sisällön ulos, lukevat sen takaisin ja kirjoittavat sen uudelleen.

Missä emme ole edellä, ja miksi se kannattaa sanoa. Neljässä kymmenestä muodosta kilpailija kirjoittaa vähemmän tavuja kuin nzbfast itse latauksen aikana. Joka kerta siksi, että se teki vähemmän: vaurioituneen sisäarkiston muodossa NZBGet kirjoittaa 3,29 GB meidän 4,65 vastaan, ja sitten sen korjauskierros kirjoittaa vielä 2,91 lisää päätyen 6,20 GB:hen meidän 4,65 vastaan. Muissa vähiten kirjoittanut ohjelma on sellainen, joka ei koskaan päässyt tiedostoon. Pieni levyluku ei aina ole säästäväisyyttä.

Nämä ovat kyvykkyystestejä, eivät nopeustestejä. Sisällöt ovat pieniä ja ne tarjoillaan muistista paikallisen yhteyden yli, ilman palveluntarjoajaa ja ilman verkkoa välissä, joten mikään tässä ei rajoitu latausnopeuteen ja absoluuttiset sekunnit ovat paljon lyhyempiä kuin samat muodot veisivät todellisuudessa. Se, vaatiiko muoto lainkaan käsityötä, on muodon ja ohjelman ominaisuus ja siirtyy sellaisenaan. Sekunnit vertaavat ohjelmia, jotka tekevät identtistä työtä; ne eivät ennusta, kauanko todellinen työ kestää.

Täydelliset muotokohtaiset tulokset, kunkin muodon kuvaus ja menetelmä ovat sisäkkäisten arkistojen datasivulla.

Miksi tällä on väliä

Levysi tekee puolet työstä

Flash-tallennustila kuluu kirjoittamisesta. 94 GB:n julkaisu maksaa levyllesi noin 90 GB kirjoitusta nzbfastin alla; asiakkaalla, joka vaiheistaa ja purkaa, sama julkaisu maksaa karkeasti kaksinkertaisesti. NAS-laitteessa kiintolevyillä yhden läpiajon muoto poistaa myös pitkän yksisäikeisen kierroksen jokaisen salatun latauksen lopussa - tauko, joka mitattiin 20 sekunniksi nopealla 32-ytimisellä työasemalla laitteistokiihdytetyllä avauksella, ja vastaavasti pidempi vähätehoisilla koneilla, joilla useimmat oikeasti ajavat tätä. Lainaamme pientä lukua koska se on se, jonka mittasimme.

Komponenttien kaksintaistelut

Teknisemmät vertailut, niille jotka haluavat lisää dataa

Korjaus (PAR2) ja purku (RAR) ovat omaa natiivikoodiamme pakattujen kolmannen osapuolen binäärien sijaan, joten kilpailutamme ne myös itsenäisesti omistettuja työkaluja vastaan identtisillä korpuksilla, neljällä koneella jotka kattavat sen, mitä lukija saattaisi oikeasti omistaa. Aika lasketaan vain kun tuloste on tavulleen identtinen lähdehyötykuorman kanssa: jokainen alla oleva RAR-luku on sha256-tarkistettu lähdettä vasten, ja jokainen korjattu tiedosto koskematonta settiä vasten.

RAR-purku: 7 arkistomuotoa, 6 työkalua

Tämän taulukon edellinen kierros käytti 100 MB - 200 MB per muoto, mikä oli virhe: noin 28 ms prosessin käynnistystä oli 40 % tallennuserästä, eikä sen tuottama järjestys säily realistisessa koossa. Tämä kierros on 1 GB hyötykuormaa per muoto, ja se muuttaa useita vastauksia, mukaan lukien joitakin toiseen suuntaan. Arkistot on luotu virallisella rar 7.23:lla, joten yhtäkään työkalua ei arvioida oman koodaimensa tuottamalla syötteellä, ja samat tavut kilpailutetaan jokaisella koneella.

Sillä, mitä hyötykuormassa on, on enemmän merkitystä kuin miltä näyttää. Lohkokopioista rakennettu hyötykuorma tekee jokaisesta pakatusta muodosta muistinkopiointivertailun; puhtaasta tekstistä koostuva hyötykuorma tekee siitä literaali-ja-Huffman-vertailun; mittasimme molemmat, eivätkä ne ole samaa mieltä siitä kuka voittaa. Joten neljä pakattua muotoa käyttävät yhtä suuria kolmanneksia tekstiä, rakenteisia tietueita ja pakkautumattomia tavuja, ja kaksi muotoa tuon välin ääripäissä ovat tarkoituksella omat erilliset eränsä: store on pakkautumaton ja repetitive on lähes pelkkiä osumia. Rakentaja ja testivälineistö ovat repositoriossa, joten korpus voidaan rakentaa uudelleen tavulleen samanlaiseksi.

Uudelleen kilpailutettu 23. elokuuta 2026 1.2.2-moottorilla, ja pyyhkäisy pitää paikkansa. Kolme työkalua, joita lukija useimmiten punnitsee - meidän, unrar 7.23 ja rarpar 0.2.5 - kilpailutettiin uudelleen 32-ytimisellä pöytäkoneella julkaisumoottorilla (kilpailutettu purkukoodi on tavulleen identtinen 1.2.2-tagin kanssa), kuusi lomitettua kierrosta, minimi per työkalu, jokaisen erän tulos tarkistettu hyötykuormamanifestia vasten. Sekunteja, pienempi on parempi:

Kaikki seitsemän muotoa meidän, sekä minimissä että mediaanissa, 1,16x-4,29x unraria vastaan. Nämä ajat eivät ole solu solulta vertailukelpoisia alla olevan laajemman taulukon kanssa - testivälineistöä on tarkistettu sen taulukon kierrosten jälkeen ja kierrosmäärät eroavat - joten lue kumpikin taulukko itsenäisesti. Laajempi taulukko pitää omat päivämääränsä ja kuuden työkalun kenttänsä, ja sen nzbfast-sarake kuvaa moottoria jonka 1.2.2 toimittaa: yllä oleva uusintakilpailu mittasi nykyisen moottoritason sen taulukon versiolla kaikissa seitsemässä muodossa, ratkaistuna laitteiston käskylaskureilla (0,14 % vähemmän samalla kellonajalla), joten nämä solut eivät ole korvatun version lukuja nykyisen leiman alla. Tämä uusintakilpailu on myös se, missä koeasetelma-osion A/A-sääntö ansaittiin. Samana päivänä ajettu kierros ilmoitti ensin yhden muodon pienenä taantumana omaa aiempaa versiotamme vastaan, ja lukema säilyi molempien haarajärjestysten ajon jälkeen. A/A-kontrolli - sama binääri kilpailutettuna tavulleen identtistä kopiota itsestään vastaan - osoitti testivälineistön antavan sille haaralle joka ajettiin ensin noin 1,5 %:n rangaistuksen: identtinen binääri voitti vain 6/15 kierrosta ensimmäisestä paikasta, eikä järjestysten vaihtaminen kumoa vinoumaa joka osuu aina siihen joka on ensimmäisenä. Laitteiston käskylaskurit ratkaisivat kysymyksen jota testivälineistö ei voinut - uudempi versio suorittaa 0,14 % vähemmän käskyjä samalla kellonajalla, joten taantumaa ei ollut. Jokainen oma-versio-omaa-versiota-vastaan-vertailu jonka nyt julkaisemme kantaa mukanaan tuon kontrollin.

Koko kenttä, sekunteja, pienempi on parempi. Paras kolmesta, työkalut lomitettuna jokaisen kierroksen sisällä eikä ajettuna lohkoina, tuloste tarkistettu lähdehyötykuormaa vasten joka ikisellä ajolla. Työkalu, joka tuotti väärät tavut, saa oikeellisuushuomautuksen, ei koskaan nopeaa aikaa. rarpar on Weaverin oma RAR- ja PAR2-koodi, käännetty lähdekoodista bd87611; kiinnitämme committiin emmekä versioon, koska sen cratet kantavat kolmea eri versionumeroa.

Missä kenttä ei pystynyt kilpailemaan, ja miksi. ¹ Tässä kilpailutettu 7-Zip on Homebrew-paketti, joka kieltäytyy jokaisesta pakatusta muodosta virheellä ERROR: Unsupported Method ja lukee macOS:llä vain tallennetun muodon. Tämän sivun aiempi versio pani sen 7-Zipin macOS-version syyksi, mikä oli väärin: Homebrew kääntää sen ilman ei-vapaata unRAR-koodekkia, kun taas 7-zip.org:in toimittama macOS-versio kantaa koodekin ja purkaa kaikki seitsemän muotoa, aivan kuten Windows-versio. Uudelleenmitattu 14. elokuuta 2026. Jos asennat 7-Zipin projektilta Homebrewin sijaan, tämä sarake ei kuvaa sitä mitä sinulla on. ² bsdtarilla ei ole RAR5-moniosaistukea ja se tuotti typistetyn tiedoston ilmoittamatta virheestä, joten se erä on oikeellisuusvirhe eikä hidas aika; testivälineistömme havaitsi sen tarkistamalla tulosteen, minkä vuoksi tulosteen tarkistaminen kannattaa. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar ei toimita Windows-komentorivityökalua, joten kannettavan kenttä on viisi. ⁶ M5 Max -ryhmä kilpailuttaa kolme työkalua, joihin macOS-lukija oikeasti tarttuisi - unrar, rarpar ja me; unaria, bsdtaria ja 7-Zipiä ei kilpailutettu sillä koneella. Sen unrar on 7.22, uusin versio joka toimii siellä valvomatta.

Jokainen muoto jokaisella koneella yhtä lukuun ottamatta, ja se yksi on tasapeli. Lyhyiden osumien muodot palautuvat kahteen tiettyyn asiaan purkajassamme. Kahden - kolmenkymmenenkahden tavun osuma maksoi ennen täyden kutsun alustan muistinkopiointirutiiniin, ja kutsu maksoi enemmän kuin itse kopiointi; kiinteän kolmenkymmenenkahden tavun kopioiminen rekisterin kautta sen sijaan on syy siihen, miksi repetitive, solid ja 128 MiB:n sanakirja - kolme lyhyistä osumista rakennettua muotoa - ovat kaikki nopeita kerralla. Ja tarkistussumma kulkee kirjoittajan säikeen alavirrassa eikä sen päällä. Ainoa solu, jota emme voita suoraan, on tallennettu muoto 32-ytimisellä pöytäkoneella, jossa unrar ja me olemme kolme millisekuntia erillään erässä, joka on puhtaasti tavujen siirtämistä - identtinen tämän taulukon tarkkuudella, joten molemmat solut on merkitty ja se pisteytetään tasapeliksi, ei häviöksi eikä voitoksi.

Muoto, jossa voitamme eniten, on se jota Usenet oikeasti postaa satoja kerrallaan: 400 pientä tiedostoa, 4,3× ja 4,4× unraria vastaan ja 5,4×-5,5× vastaan rarpar. Se on jäsenkohtaista rinnakkaisuutta, ja se on ero latausjonolle kirjoitetun purkajan ja komentoriville kirjoitetun purkajan välillä. Tallennettu muoto, jonka yllä oleva kartoitus mukaan on 84 % linjan tavuista, on lähes tasapeli kolmelle vakavasti otettavalle työkalulle, koska siinä vaiheessa kaikki vain siirtävät tavuja.

Yksi valinta, joka kannattaa kertoa. Arkistot on pakattu pakkaimen ollessa kiinnitettynä neljään säikeeseen. RARin lohkojako muuten seuraa sen koneen ydinmäärää, joka pakkasi arkiston, joten 32-ytiminen kone ja 20-ytiminen kone tuottavat eri tavuja samasta syötteestä ja koneet lakkaavat olemasta vertailukelpoisia. Sen kiinnittäminen tekee purkukorpuksesta tavulleen identtisen kaikkialla, mikä on tarkoitus, mutta se myös rajoittaa kuinka suuri osa purkamisesta voi ajaa rinnakkain - joten kun kaksi lähintä muotoa olivat häviöitä, kilpailutimme ne uudelleen arkistoja vastaan jotka oli pakattu kaikilla 32 säikeellä, tarkistaaksemme ettei kiinnitys ollut syynä. Ei ollut: yhtenäinen siirtyi 4,2 %:sta jäljessä 2,4 %:iin jäljessä ja 128 MiB:n sanakirja 6,6 %:sta 6,3 %:iin, sama järjestys kummallakin tavalla. Molemmat ovat nyt voittoja kiinnitetyllä korpuksella leveämmällä marginaalilla kuin tuo tarkistus pystyisi selittämään.

Miksi RAR4-riviä ei ole, ja mitä niille postauksille tapahtuu. Jokainen yllä oleva muoto on RAR5 tai RAR7, mitä Usenet postaa nykyään. Vanhempia RAR4-arkistoja tulee yhä vastaan, ja sama moottori lukee ne, myös pakatut ja salasanasuojatut muodot, samalla yhdellä läpiajolla kuin uudemmatkin sen sijaan että nideet kirjoitettaisiin levylle ja purettaisiin jälkikäteen. Ne eivät saa riviä tässä, koska virallinen rar 7.23 ei enää osaa luoda RAR4:ää, joten neutraalia korpusta kentän kilpailuttamiseksi ei ole; se työ tarkistetaan sen sijaan WinRAR 3.00:lla kirjoitettuja arkistoja vasten, tavu tavulta unraria vastaan.

PAR2-varmennus ja -korjaus: 1 GiB:n setti, neljä vauriotasoa

Korpus: 1 GiB satunnaista hyötykuormaa pakattuna tallennustilassa 21 RAR-nideeseen, sitten kaksi PAR2-settiä 10 %:n redundanssilla, yksi 1 MiB:n lohkoilla ja yksi 64 KiB:n lohkoilla, sitten kiinteät vauriokartat. Jokainen ajo käyttää samaa protokollaa: tuore kopio, koko korpuksen lukeminen kerran välimuistin lämmittämiseksi, sitten ajastus. Paras kolmesta lomitetusta kierroksesta; jokainen korjattu nide verrataan koskemattomaan settiin joka kierroksella. Pienempi on parempi.

Korjaus korpuksesta, koska tämän sivun aiempi versio liioitteli sitä. Sanoimme, että jokainen kone ajoi tavulleen identtistä korpusta, tarkistettuna tiivisteellä. Jokaisen setin jokaisen nideen tiivistäminen osoittaa, että se pitää paikkansa 32-ytimisellä pöytäkoneella ja Windows-kannettavalla, jotka täsmäävät tarkalleen, mutta ei 20-ytimisellä pöytäkoneella, jolla on eri satunnaispoiminta samasta muodosta: samat 21 nidettä samoilla koilla, samat kaksi lohkokokoa, ja vauriot varmennettu samoissa 3, 101 ja 1 500 lohkossa jaettuna saman tiedostomäärän yli. Jokainen luku rivin sisällä on silti mitattu tavuilla, jotka jokainen sen rivin työkalu jakaa, minkä varaan jokainen vertailu lepää. Mutta rivit eivät ole neljä näkymää yhteen syötteeseen, ja koska hyötykuorman luonne on arvoltaan noin 7 % erään kilpailijan skannaukselle, se kannattaa sanoa eikä silotella.

Mikä par2 on mikäkin. Alkuperäinen par2cmdline on referenssitoteutus, josta kaikki muut on haarautettu. par2cmdline-turbo on haara, joka toimittaa mukanaan ParPar'in käsin kirjoitetut SIMD Galois-kunta -ytimet: juuri se "turbo" tarkoittaa, ja siksi turbo alkuperäisen sijaan on se työkalu, jota kannattaa mitata vasten. Molemmat alla olevat turbo-sarakkeet ajavat samoja ParPar-ytimiä. Ne erottaa toisistaan ei laskutoimitus vaan käännös ja liput.

Vahvistettu julkaisuversiolla ajantasaista kilpailijaa vastaan, 24. elokuuta 2026. Nämä taulukot mitattiin ennen kuin 1.2.2 leikattiin ja ennen kuin par2cmdline-turbo julkaisi 1.5.0:n (20. elokuuta 2026), joten 20-ytiminen sarake kilpailutettiin uudelleen molemmilla: 1.2.2-julkaisuversiomme turbo 1.5.0:aa vastaan, kolme lomitettua kierrosta per erä, jokainen korjattu tiedosto verrattuna koskemattomaan settiin. Kaikki neljä erää toistuvat - meidän 0,18 / 0,30 / 0,75 / 2,02 tässä painettuja 0,19 / 0,33 / 0,74 / 2,07 vastaan, ja turbo 1.5.0 osuu muutaman prosentin sisään taulukon versiosta joka erällä ja molemmilla kokoonpanoilla. Solut pysyvät julkaistuina; kolme muuta konetta pitävät omat päivämääränsä.

Joten kilpailija esiintyy kahdesti, ja toinen niistä sarakkeista on sen parhain tapaus eikä sen oletus. Julkaisubinääri, jonka lataisit, on käännetty yleiselle perustason CPU:lle ja tiivistää vain muutaman tiedoston kerrallaan; saman lähdekoodin kääntäminen todelliselle isäntä-CPU:lle ja lipun -T16 antaminen sallii sen käyttää käskyjä, jotka koneella oikeasti on, ja tiivistää kuusitoista tiedostoa kerralla. Kannettavalla se on arvoltaan jopa 2,6x, pelkästään käännöksestä ja lipuista. Arvioi meidät viritetyn sarakkeen perusteella, joka on vaikeampi vertailu; toimitettuna-sarake on se, mitä joku joka lataa sen, oikeasti kokee. par2cmdline on alkuperäinen, versio 1.2.0, käännetty lähdekoodista jokaisella koneella. rarpar on Weaverin oma PAR2-toteutus, käännetty lähdekoodista sen Metal GPU -taustajärjestelmä käytössä. MultiParin par2j on vain Windowsille, joten se esiintyy vain Windows-kannettavan riveillä. M5 Max -rivit kilpailuttavat kaksi työkalua ajantasaisilla macOS arm64 -versioilla kahden turbo-sarakkeen vieressä; par2cmdline klassista ei kilpailutettu sillä koneella.

Kaikki kuusitoista nzbfast-solua - neljä konetta neljällä vauriotasolla - ovat meidän, useat yli 2× viritettyä versiota vastaan ja 2,3×-7,7× sitä vastaan, jonka oikeasti lataisit. Raskaan vaurion solut ovat mielenkiintoiset, ja alla oleva huomautus selittää niiden takana olevan algoritmin.

Alkuperäinen on taas taulukossa, ja kannattaa nähdä miksi haara on olemassa. Tämän sivun aiempi versio pudotti par2cmdline -sarakkeen sillä perusteella, että se oli hitaampi kuin kaikki muu kierroksella, mikä on totta eikä ole riittävän hyvä syy: se on toteutus, josta lähes jokainen muu työkalu polveutuu, ja lukijat ansaitsevat perustason oman väitteemme sijaan siitä. Raskaimmalla vauriotasolla se vie noin 69 s, kun SIMD-haara vie 3,2 s ja me viemme 3,1 s. Se kahdenkymmenen kerroin on koko argumentti käsin kirjoitetuille Galois-kunta-ytimille, ja se on sama argumentti jonka teemme omastamme.

Kevyt vaurio on se tapaus, jolla on väliä. Kourallinen epäonnistuneita artikkeleita on paljon tyypillisempi kuin 101 kuollutta lohkoa, eikä lähelläkään 1 500:aa. Suurin osa kevyestä korjauksesta ei ole lainkaan Reed-Solomon-matematiikkaa, vaan gigatavun lukemista ja MD5-tiivistämistä, minkä vuoksi 3-lohkon rivi seuraa puhdas-varmennus-riviä eikä korjausrivejä.

Raskain vauriotaso on erilaista työtä, ja se saa erilaisen algoritmin. Se viimeinen taso vaurioittaa 1 500 lohkoa kaikkien 21 nideen yli ja kuluttaa noin 91 % palautusdatasta, jolloin Reed-Solomon-laskutoimitus, ei tiivistäminen tai levy, muodostaa lähes koko työn. Julkaisuversio laskee raskaimmat korjaukset lukuteoreettisella muunnoksella klassisen Galois-kunta-taitoksen sijaan - sama matematiikka, arvioituna muodossa joka skaalautuu paljon paremmin korkeilla lohkomäärillä: 2,7× viritettyä versiota edellä 20-ytimisellä pöytäkoneella, ja Windows-kannettavalla 2,7× viritettyä versiota edellä ja 2,2× MultiParia edellä. Kevyt vaurio ajaa yhä klassista polkua, minkä vuoksi muut tasot liikkuivat tuskin lainkaan: muunnos maksaa itsensä takaisin vasta noin 512 vaurioituneen lohkon yläpuolella, joten sen alapuolella jakelija ei käytä sitä.

Nopeampi polku kannattaa vain, jos se ei voi olla väärässä. Molemmat polut laskevat saman suureen ja ovat bitilleen identtisiä rakenteensa puolesta, ja jokainen tämän sivun korjaus portitettiin sillä, että jälleenrakennetut tiedostot täsmäävät koskemattomaan settiin: 228 ajastettua korjausta tämän kierroksen koneilla, nolla eroavaisuutta. Julkaisuversio ei nojaa tuohon ennätykseen. Jokainen korjaus varmentaa oman tulosteensa tiedostotiivisteitä vasten, ja epäonnistunut tehtäisiin automaattisesti uudelleen klassisella polulla, kirjattaisiin eroavaisuus lokiin, ja pidettäisiin klassinen polku lopun sitä ajoa. Asetus on koontinäytössä nimellä Nopea PAR-tila jos et halua sitä lainkaan, ja koneet, joissa on liian vähän muistia sille, kieltäytyvät siitä itse yrittämisen ja epäonnistumisen sijaan. Uudelleenmitattu 2. elokuuta nykyisellä versiolla: molemmat pöytäkoneet osuvat muutaman prosentin sisään tästä taulukosta, ja Nopea PAR-tila pois kytkettynä 20-ytiminen pöytäkone palaa täsmälleen klassisen polun hitaampaan aikaan, mikä kertoo että voitto on menetelmässä eikä olosuhteissa.

Windows-kannettavan sarake tarvitsi korjauksen, ja se on meitä vastaan. Windows siirtää jatkuvan taustatyön tehokkuusytimilleen muutaman sekunnin kuluttua. Taustapalvelumme kieltäytyy siitä käynnistyksessä eikä yksikään muu työkalu voi, joten tämän sivun aiempi versio julkaisi niiden kuristetut ajat ikään kuin ne olisivat työkalujen omia. Sen koneen ajaminen uudelleen jokaisen työkalun ollessa nostettuna korkeaan prioriteettiin liikuttaa koko kenttää: raskaimmalla vauriotasolla par2-turbo siirtyy 22,4 s:sta 6,41:een ja rarpar 59,2 s:sta 14,4:ään, ja yhdellä tämän sivun leikkauksella se käänsi sarakkeen meidän voitostamme häviöksemme. Koko kannettavan sarake mitataan nyt sillä tavalla - korjaus pysyy vaikka rivi on sittemmin voitettu takaisin yllä olevalla algoritmimuutoksella, koska kentän ajat sillä koneella ovat rehellisiä vain kuristuksen ollessa poistettuna.

RAR-palautustietueet: korjaus ilman PAR2:ta

Kun PAR2 ei riitä kattamaan vauriota, itse RARin sisällä oleva palautustietue on viimeinen puolustuslinja. Versioon 1.0.8 asti meidän epäonnistui jokaisessa yli noin 13 MB:n arkistossa, joten tätä erää ei voitu ajaa lainkaan. Vaurio on kolme 3 000 tavun reikää 20 %:n, 50 %:n ja 80 %:n kohdalla suojattua aluetta. Molemmat työkalut tuottivat tulosteen, joka on tavulleen identtinen koskemattoman tiedoston kanssa, ja meidän on tavulleen identtinen sen kanssa mitä rar r itse kirjoittaa. Paras kolmesta, 32-ytiminen pöytäkone, molemmat työkalut kilpailutettu uudelleen yhdessä 2. elokuuta.

Tämän sivun aiempi versio näytti 512 MB:n koon häviönä, ja selitti sen hinnaksi sen, että nide käydään läpi paloissa sen sijaan että se pidettäisiin kokonaan muistissa. Se selitys oli oikea silloin ja on nyt vanhentunut: kustannus oli bittisarjallinen CRC64 korjauspolussa, korvattu taulukkopohjaisella, ja häviö lähti sen mukana. Risteyskohtaa ei enää ole, ja rajattu työjoukko säilytettiin. 2 GB:n koko on tässä koska nideet, joita taustapalvelu oikeasti kohtaa, ovat 8 GB - 20 GB, ei 512 MB, eikä ala todellisen alueen alapuolelle jäävä erä ole kummoinenkaan testi.

Mikä liikutti tätä leikkausta, ja kontrolli joka sanoo niin. Sen selvittäminen, mitkä lohkot ovat vaurioituneet, oli kasvanut tämän korjauksen suurimmaksi vaiheeksi - suuremmaksi kuin itse korjauslaskutoimitus - ja se ajettiin yhdellä säikeellä, lukien 64 KB jokaisesta ryhmästä tiedoston yli, kerran per ryhmä. Se tekee nyt yhden peräkkäisen läpiajon tiedostojärjestyksessä osaskohtaisten tarkistussummien laskettuina rinnakkain, ja korjattu nide kloonataan kopioimisen sijaan siellä missä tiedostojärjestelmä pystyy siihen. Pelkkä havaitseminen putosi noin 300 ms:sta 18 ms:iin 512 MB:n arkistossa, mikä on suurin osa siitä, mikä liikkui yllä. Kontrolli on sarake meidän vieressämme: rar r kilpailutettiin uudelleen samoilla kierroksilla samalla koneella ja palasi muutaman prosentin sisään aiemmista ajoistaan, joten muutos erossa on meidän eikä testipenkin.

M5 Max toistaa kuvion, kilpailutettuna 31. heinäkuuta samalla korpuksella ja porteilla: 0,050 / 0,066 / 0,171 / 0,581 s rar r'n 0,211 / 0,335 / 0,751 / 1,735:tä vastaan 16 MB:n - 512 MB:n koissa - 3,0× -5,1× × nopeampi; 2 GB:n kokoa ei kilpailutettu sillä koneella. Nämä luvut ovat ajalta ennen yllä kuvattua havaitsemisen uudelleenkirjoitusta, joten ne ovat vanhemman version lukuja, säilytettynä tässä toisena koneena eikä ajantasaisena lukuna.

Weaverin rarpar puuttuu tästä ainoasta taulukosta, eikä valinnasta: se ei toteuta tätä korjausta. Kun sitä pyydetään korjaamaan yksi näistä arkistoista, se vastaa "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data", ja jättää tiedoston vaurioituneeksi. Se esiintyy jokaisessa muussa tämän sivun vertailussa: kaikki neljä yllä olevaa PAR2-erää, kaikki seitsemän sitä ylempänä olevaa purkumuotoa, ja heti alla oleva palautusnide-erä, joka on juuri se työ, jonka se sanoo tekevänsä - ja jonka se voittaa.

Palautusnideet: kokonaan puuttuvien .rev tiedostojen jälleenrakennus

RARin oman palautustarinan toinen puoli, ja tähän kierrokseen asti tämän sivun suurin häviö. .rev -tiedosto on itsenäinen palautusnide: kolme niitä 21 nideen setin vierellä voi jälleenrakentaa mitkä tahansa kolme nidettä jotka eivät koskaan saapuneet. Korpus: 1 GiB tallennettuna 21 nideeseen à 50 MB komennolla rar rv3, sitten nideet 4, 11 ja 19 poistettu - kolme hävinnyttä kolmea palautusnidettä vastaan, mikä on pahin tapaus jonka setti voi vielä selvittää. Paras kolmesta, jokainen jälleenrakennettu nide verrattuna koskemattomaan.

32-ytimen solu oli tässä 3,12 s, verrattuna rar rc'n 0,47:ään tämän sivun viime leikkauksessa, julkaistuna 6,6× hitaampana ja sen huonoimpana lukuna. Syy oli pyyhkimisratkaisu, joka pyöri noin 48 MB/s jälleenrakennettua tulostetta, kun RARLabin versio ylsi 320:een; se pyörii nyt samalla taulukkopohjaisella laskutoimituksella kuin loput palautuskoodista, mikä on seitsenkertainen parannus ja kääntää häviön voitoksi molemmilla koneilla. Marginaalit ovat 3 % ja 14 %, joten se on voitto joka kannattaa sanoa suoraan eikä otsikoida, ja syy siihen että se sanotaan ollenkaan on se, että häviö sanottiin ensin.

Tämä erä on olemassa koska Weaverin rarpar toteuttaa juuri tämän ja pyysi tulla mitatuksi siinä. Se voitti mukavasti, kun julkaisimme sen ensimmäisen kerran, ja julkaisimme sen silloin juuri siitä syystä.

Tiedostojen täsmäytys ei koskaan ollut kustannus, mikä kannattaa kirjata ylös koska se oli intuitiivinen epäilty: palautusnideet eivät kanna tiedostonimiä, joten tunnistamme mitkä paikat selvisivät tarkistussummaamalla jokaisen levyllä olevan nideen sen sijaan että luottaisimme siihen miksi niitä kutsutaan, ja vaurioitumatonta settiä vasten, jossa ainoastaan täsmäytys tapahtuu, koko läpiajo kestää 0,18 s.

Mikä muu liikkui, ja missä se ei näy. Kaksi muuta moottorimuutosta laskeutui, joita nämä korpukset eivät näe, listattuna tässä jotta yllä olevia lukuja ei lueta koko tarinana: RAR5-arkistot kymmenillä tuhansilla jäsenillä ratkaisevat kunkin jäsenen kerran sen sijaan että listaa käveltäisiin per työntekijä, mikä on 3× vähemmän prosessoriaikaa 40 000 jäsenellä; ja RAR1.3-bittilukija työskentelee sana kerrallaan, mikä on 2×. Kumpikaan ei näy yllä, koska tämän muodoilla on 400 jäsentä eikä RAR1.3:a.

Mitä emme tee tarkoituksella: emme koskaan luo PAR2:ta. Lataajalla ei ole syytä siihen, ja ParPar omistaa sen erän. Ostamme myös nopeutta muistilla molemmissa moottoreissa: purku huipentuu noin 240 MB:aan unrarin 41 MB:aa vastaan, ja varmennus noin 126 MB:aan turbon 7 MB:aa vastaan, koska nämä ovat sisäänrakennettuja moottoreita jotka kulkevat elävän latauksen mukana itsenäisten kertasuoritusten sijaan. 128 MiB:n sanakirjamuoto on siitä pahin, noin 304 MB unrarin 139 MB:aa vastaan. Raskain korjaus maksaa nyt myös muistia: nopeampi menetelmä 512:lle tai useammalle puuttuvalle lohkolle työskentelee keskusmuistissa pidetystä palautusdatasta, joten sille sallitaan enintään neljäsosa koneen RAM-muistista, katossa 4 GB, ja kone joka ei voi antaa sitä ottaa hiljaa käyttöön vähämuistisen menetelmän sen sijaan - sama laskutoimitus ja samat ajat kuin PAR2-taulukon keskimmäisillä riveillä, vain ei sitä 3×:ää viimeisellä. Jos haluat pienimmän mahdollisen keskusmuistijalanjäljen itsenäiselle työlle, omistetut työkalut voittavat yhä sen sarakkeen.

Siirtotodistus · mitattu versiolla 1.2.2

Moottori pysyy oikeiden linjojen tahdissa

• ~8,7 Gbps ylläpidettynä viiden palveluntarjoajan kaluston läpi 10 GbE:n linjalla, mukaan lukien virrassa tapahtuva varmennus ja purku - yllä oleva 87 GB:n kierros, 24. elokuuta 2026, v1.2.2, 360 yhteyttä: 77,4 GB linjalla 71 s:ssa hyötykuorman tullessa varmennetuksi ja puretuksi sitä mukaa kun se saapui. Ei purskeluku: koko työ sillä nopeudella.
• 1 Gbit:ssä ja sen alapuolella linja on rajoittava tekijä ja nzbfast istuu sen päällä: ~96 % 500 Mbit:n linjasta ja ~96 % 250 Mbit:n linjasta varmennuksen ja purun läpi, murto-osalla jokaisen kilpailijan muistista ja levystä - yllä oleva alle-gigabitin osio.
• Koko työn prosessorikustannus 87 GB:n työssä on 1,7 CPU-sekuntia per GB yhteysrajoittimen ollessa päällä - lataus TLS:n yli, varmennus, korjausvalmius ja purku mukaan lukien - kentän 3,0-28:aa vastaan samalla kierroksella; yllä oleva täyden läpäisyn haara käyttää 4,3:a.

Tämän sivun aiemmat leikkaukset kantoivat laajemman joukon siirtodemonstraatioita - monilinjaisia kyllästysajoja, per-RTT-putkitushyötyjä, vastapaineen todistuksen, purkukaton mittauksia - kilpailutettuna versioilla, jotka v1.2.2 on sittemmin korvannut. Tämän sivun säännön alla ne poistetaan käytöstä sen sijaan että ne jäisivät vanhenemaan, ja ne palaavat kun ne leikataan uudelleen nykyiselle julkaisulle; kolme yllä olevaa väitettä ovat ne, jotka on jo mitattu uudelleen v1.2.2:lla.