Windows-versie 7-Zip heeft ondersteuning voor meer dan 64 threads

De Windows-versie van in- en uitpakprogramma 7-Zip heeft ondersteuning gekregen voor meer dan 64 cpu-threads. Alleen de duurste processors kunnen daar gebruik van maken.

De ondersteuning zit in versie 25.00, blijkt op GitHub. Als er meerdere groepen processors zijn op een Windows-machine, dan verdeelt de software de taken over die groepen, zo staat in de releasenotes. De ondersteuning voor meer dan 64 threads is voor het inpakken van bestanden in zip-, 7z- of xz-formaat. De ingebouwde Windows-functie voor in- en uitpakken van bestanden is beperkt tot één thread, merkt Tom's Hardware op.

7-Zip 25.00 voor Windows

Reacties (52)

[Fairy]

Let wel op met meer threads. Dit gaat ten koste van efficiëntie van je compressie.

Bij het maken van stappen in threads (vanaf 4 en vanaf daar zie je het bij de geheugen schatting) maakt ie aparte 'solid blocks' aan. Elk blok heeft zijn eigen dictionary.

Als je data hebt die eenvoudig te comprimeren is, dan is dat in 1 blok heel efficiënt, maar meerdere blokken zorgen ervoor dat die data ook weer voor de 1e keer in het blok moeten worden vastgelegd en dat gaat ten koste van de uiteindelijke grootte.

Als ik met 7-zip comprimeer en het moet zo klein mogelijk zijn dan gebruik ik normaliter 3 threads, tenzij het erg groot is en het daardoor te lang zou duren.

[Cybermage]

Dat merkte ik dus een paar je geleden dat een Threadripper dus nutteloos was omdat multithread ondersteuning toen nog in de kinderschoenen stond onder windows 10.

[Davey400]

omdat multithread ondersteuning toen nog in de kinderschoenen stond onder windows 10.

Sinds NT3.51 was er al ondersteuning voor meer dan 1 cpu. (Toen nog letterlijk middels 2 sockets. Je moest wel ‘even’ de kernel vervangen. 🤓)

De vraag is dus meer: wanneer noem je het ‘multi’, maar vanaf Windows 7 was de beperking 64 logical cpu’s. Voor het server equivalent was het toen al 256.

Dat jouw software er kennelijk niets nuttigs mee doet wil niet zeggen dat het OS de beperking is.

[Cybermage]

Nou onder 2990wx was de beperking dat er niet meer dan 16 cores 32 threads goed aan kon sturen in windows 10. Verder viel mij wel op dat ook veel onderdelen van microsoft windows 10 nog allemaal single threaded waren. Os moet het wel ondersteunen en daar start het al mee. Als OS al niet echt lekker loopt ermee , laat staan dan 3th party apps. Kortom op vele fronten beperkingen die ik heb ervaren onder windows 10 dat voor mij overstap naar windows naar Linux helaas onvermijdelijk was.

[CrazyBernie]

Voor tools die er goed mee omgaan is de multi cpu en later multi core ondersteuning van Windows echt perfect tenminste wanneer je kijkt naar alle nt versies.

Heb ze zelf allemaal gebruikt en ook bijna allemaal met multi cpu of multicore. Met de juiste use case in mijn geval allemaal als dev of test machine is het bijna altijd beter geweest dan single cpu systemen.

Wel zijn inderdaad veel componenten als nog single thread meestal de grote reden dat er tot voor kort voor consumenten gewoon maar heel weinig redenen waren om multi cpu systemen te hebben. Dus de gedeeltes die van ouds her al multi threading zijn vaak core onderdelen van Windows en de meeste server componenten.


Maar van die magische verbetering van de performance onder Linux of daarvoor Unix heb ik behalve in mijn begin tijd ( eind jaren negentig , begin van deze eeuw ) altijd maar weinig gemerkt .


Met uitzondering van http server performance dst is Jaren echt ruk geweest .

[Daedeloth]

Multithreading in kinderschoenen? 😅

Multithreading is al jaar en dag gewoon "een beetje meer werk voor developers".

[orvintax]

Multithreading is al jaar en dag gewoon "een beetje meer werk voor developers".

Ik neem aan dat dit sarcasme is? Het ligt echt een heel stuk genuanceerder dan dit. Multithreading is geen silver bullet. Alleen al de complexiteit die het introduceert brengt een hoop nuance mee. Daarnaast zijn er ook algoritmes die hier simpelweg niet geschikt voor zijn.

[Daedeloth]

Het "beetje meer" is inderdaad sarcasme, maar dat het aan specifiek windows 10 zou liggen, niet :)

[latka]

Windows en multithreading is behoorlijk beroerd op api gebied: als je meer dan 64 threads hebt kan de windows api het niet meer aan en moet je ala een 8-bitter met processor groups gaan werken (zeg maar 8bits bankswitching). Tot 64 threads is het meer van hetzelfde en meer dan 64threads moet je extra api calls gaan doen. Niet heel hard nagedacht bij het verzinnen van die api dat is wel duidelijk.

[YGDRASSIL]

Die api is nog uit de tijd van dualcore machines. Toen was 64 threads heeeel veeeel.

[Saffie01]

"640Kb should be enough for everybody"

[Darkwolf_1982]

...Wie heeft dat ooit uitgesproken?
In ieder geval NIET Bill Gates... ;)

[Die_ene_gast]

Dus windows gaat niet met de tijd mee? Duidelijk.

[YGDRASSIL]

Windows gaat heel hard met de tijd mee. De API is allang aangepast. Commentaar erop was dat bij meer dan 64 cores de affinity/scheduling per group van 64 gaat en dat dat onhandig is voor de developer.

[Die_ene_gast]

Dus zo erg up to date zijn ze niet?

Ik vond het bijzonder dat er pas bij w11 tabs zaten in de file explorer enzo. En nog steeds werkt dat minder lekker dan op linux.

[YGDRASSIL]

Tsja. Als je het hebben van tabs in een filetooltje als basis pakt om een OS te vergelijken dan ken ik er nog wel een paar. UserInterface voorkeuren zijn sowieso vrij persoonlijk. Ik vind het bijzonder dat nog steeds heel veel goede games niet werken op macos, laat staan op linux. Ieder zn ding.

[Die_ene_gast]

Als eindgebruiker merk ik toch voornamelijk de UI dingen, en daar loopt windows gewoon droevig ver achter.

Ook backwardcompatability king is niet waar. Vaak werken dingen niet in nieuwere windows versies, maar via wine werkt het wel op de nieuwste kernel.

Ik heb het altijd bijzonder gevonden, wij hebben hier ook nog w98 machines staan omdat het niet op nieuwere windows systemen werkt. Vaak wel op wine maar dat wilt men dan niet voor een draaiend systeem.

Toch prachtig om te zien.

[YGDRASSIL]

Prima. Ga modern Linux met Wine vergelijken met w98 wat al sinds 2002 EOL is. Ik ben blij dat ik gewoon een UI heb in windows en er niet een moet gaan selecteren uit de verschrikkelijke fragmentatie die in linux op alle gebieden terugkomt. Voor iedereen een eigen distro, met alle nadelen van dien, joepie! Op windows werkt hardware tenmninste out-of-the-box. Alle linux fans in mijn omgeving klagen steen en been dat er weer iets is wat op hun nieuwe laptop niet gesupport wordt, van wifi tot trackpad tot netwerkkaart tot videokaart. En met wine kun je misschien windows dingen draaien, maar dat kan ook zonder wine. Op windows, waar de software blijkbaar voor bedoeld is.

[Die_ene_gast]

Je wilt het expres niet snappen. Ik zeg toch waarom ik wine gebruik

[kdekker]

Dat is prima op een andere manier op te lossen. Waarschijnlijk bedoel je dat WaitForMultipleObjects Windows API functie niet meer dan 64 handles gelijk kan 'waiten'. Dat is idd wel een suf manco in de Windows kernel, maar goed, dat is op te lossen (bijv. door zelf een array van handles in blokken van 64 te wachten en dat in een thread).

Overigens, zoals bijv. @orvintax zegt: multi-threading is geen silver-bullet. Er komt een hoop extra codeerwerk bij. Stukken blijven altijd single-threaded (bijv. updaten van gedeelde data) en veel/meer multi-core CPU's komen met een lagere max klok als er meer cores zijn. Dus met meer-meer cores krijg je weliswaar simplistisch gerekend core x max-klokfreq-per-core meer ruwe rekenkracht, maar dat gaat voor bij aan de eerder genoemde extra kosten van de overhead (verdelen van werken, mutex/locks voor gedeelde data). En voor developers: heel veel lastiger bugs opsporen als er toch ergens meerdere threads in gedeeld geheugen zitten te wijzigen. Een develop is en blijft zelf zo'n beetje single-threaded in debug mogelijkheden ;-).

[Reactie gewijzigd door kdekker op 8 juli 2025 14:12]

[Cybermage]

Nou onder windows 10 viel het echt tegen hoe multithreaded applicaties waren. Zelfs de meest basale applicaties waren dat dus niet. Is nu wel aan het bijtrekken maar hoe lang is het er al.

[dasiro]

je moet voor de grap eens kijken hoe mooi windows-setup schaalt zowel qua thread als memory-usage in WinPE shift+F10 en dan in de cmd taskmgr (kan je trouwens nog eens genieten van de oude windows 7 versie )

[Cybermage]

Kan het niet meer meer testen maar wil wel geloven dat als alle bload er af is dat het beter schaald. Tja heb mijn threadripper van de hand gedaan. Was net zo onzinnig thuis te hebben als een mainframe. Gemiddelde ryzen processor met 16 cores 32 threads zijn practischer en velen malen beter upgradeble.

[dasiro]

ik ben nog eens in m'n archief gedoken en het was blijkbaar een capture:

2qDPWrN6urUGpTKWL58LoIWi.jpg (1022×867)

geen idee welke cpu's er nu ook alweer in zaten, maar zelfs gevirtualiseerd trok hij nog 12 cores vol

[Reactie gewijzigd door dasiro op 7 juli 2025 23:37]

[kdekker]

Een Threadripper had en heeft 0.0 te maken met een mainframe. Je reactie laat duidelijk zien dat je nog nooit met een mainframe te maken hebt gehad (die wil je niet eens thuis hebben staan, nog los van het feit of je groepenkast zoiets trekt . In ieder geval de spaarrekening van verreweg de meeste mensen onder ons niet).

[Argantonis]

Tja je moet wel weten wat je koopt en waarvoor je dat doet, en dat bleek bij jou niet het geval. Vraag me af waarom je überhaupt een threadripper kocht als je er geen use-case voor had. Met minder cores kan je ook wel toe als je alleen maar wat applicaties in parallel wil draaien.

[Tjidde]

Buiten dat veel applicaties hadden uit die tijd eindelijk een methode die niet threadsafe ontwikkeld kon worden op een of andere manier. Dus die is dan maar singlethreaded gedaan werd, waardoor het ook bij 100 cores niet veel beter werd. Vaak ook nog eens de methode die het meeste tijd kostte.

Gelukkig zie je dat wel meer en meer verdwijnen.

[tHe_BiNk]

Het aantal single thread apps > multi thread apps op MS Windows.


Het is nog steeds slecht met de low volume special software. Zelden dat ik met dit soort speciale dure software meer dan 1 thread zie belast.

[dasiro]

de vraag is of dit nu ook zoveel meer werk was om van de vorige hoeveelheid naar het huidige (onvermelde) maximum te gaan.

[MSalters]

Zodra je met iets als File I/O werkt is multi-threading opeens heel veer complexer. Het concept van een file pointer is vrij algemeen ("Lees volgende 1024 bytes") maar in een multi-threaded applicatie is dat opeens eeen synchronisatiepunt. Welke bytes zijn "de volgende 1024" eigenlijk?

[xorpd]

De file pointer is gekoppeld aan de file descriptor, dus is er alleen synchronisatie nodig als de file descriptor geërfd wordt. Dan nog is het niet aan te raden om twee processen naar dezelfde file te laten schrijven. Oftewel jouw punt is een non-issue en komt in de praktijk niet voor.

[MSalters]

We hebben het hier over multithreading. Alle threads in een proces delen de file pointer. Niets erven.

(File descriptor? Het gaat over Windows).

[xorpd]

File handle / file descriptor, same difference. In jouw scenario is overigens de meest gebruikte aanpak om een van die threads de writer te laten zijn, en zo de arbitratie in userland te doen.

[willieverhoef]

Ja en nee, niet ieder proces loont zich om hier gebruik van te maken. Als een berekening afhankelijk is van het voorgaande resultaat, kun je het niet opsplitsen. UI, IO, maar als je thread moet wachten op de IO, is daar geen winst te behalen. Soms kan het dan wel tijden het ophalen.

[BCC]

Dat ligt nogal aan de workload. Je kan ook niet met 9 vrouwen in 1 maand een baby maken.

[PaulHelper]

Ik had deze vergelijking echt niet aan zien komen maar hij toont opzich wel goed wat het probleem is. Ga ik onthouden 🤣🤣🤣

[tw_gotcha]

eh wat? we gebruiken al een jaar of 4 een threadripper, het is maar net of de software die je bouwt ermee om kan gaan. Onder c++ bestaat die ondersteuning al langer, ik snap niet zo goed wat dat met win 10 te maken heeft. Maar meer threads is niet altijd positief, omadat er ook nog data uitgewisseld moet owrden, dus het ligt vaak aan de balans tussen puur nm berekeningen en data caching. Dus soms valt de winst tegen

[Cybermage]

Nou heb zelf een threadripper 2990wx gehad. (32 cores 64 threads) in begin tijd en toen was de ondersteuning van windows 10 niet echt optimaal om maar zo netjes te zeggen. Nou normaal handeld het os de threads af en dat ging windows 10 niet lekker af na 16 cores 32 threads toen. Dat hebben ze later wel gepatched. Nu hebben ze speciaal voor de threadripper windows workstation.

[Arrigi]

Was dat geen NUMA-ding?

Yep: https://level1techs.com/article/unlocking-2990wx-less-numa-aware-apps

Die CPU was een speciaal soort 2-in-1 (of meer, afhankelijk van de variant). Windows kon dat wel aan... afhankelijk van de editie.

https://www.anandtech.com/show/15483/amd-threadripper-3990x-review/3

Op zich niet echt een blaam op Windows. Kwestie van een apart HW-design + oude API + gebruiker die zich daar niet van bewust is.

[bapemania]

Het gaat er in het stuk over dat 7zip in hun nieuwste versie (25.00) onder Windows (10 en/of 11 kan ik niet uit het stuk halen) 64 threads ondersteunt, dat stat los van zipfiles extracten met Verkenner onder windows 10 en 11, dát is gelimiteerd tot 1 thread. Je kunt dua kijken of je een palket multithreaded met 7zip 25 sneller kunt in- uitpakken dan met verkenner.

[michelr]

Multi-thread support zit al tijdje in 7z. Let op: alleen bepaalde methodes (eg LZMA, LZMA2); deflate is bv single-thread. Meest efficient is meerdere files in/uitpakken (worst-case 1 thread per file); enkele grote file is meer nuttig met LZMA2 (schaalt beter, deelt file op in stukken).

[Reactie gewijzigd door michelr op 7 juli 2025 20:24]

[fenrirs]

Uit ervaring met pigz (parallel gzip) kan ik zeggen dat er na 32-48 threads (of daar omtrent) geen winst meer is. Zal voor 7zip niet heel veel anders zijn denk ik.

[jeroen3]

Ik denk dat het juist wel loont, maar de input data moet mee schalen.

[latka]

En geheugen bandbreedte.... Leuk dat je 64 cores hebt die full fledged superpipelined 10 bytes per cycle kunnen unzippen, maar dan moet je wel 10*aantal cores bytes per cycle inlezen en wegschrijven en dat lukt vrijwel nooit. Als de data super gecomprimeerd is lees je 1 bytes en schrijf je er 1000 of het is vrijwel niet gecomprimeerd en het is 1 byte in = 1 byte uit. In dat laatste geval kun je de hoogste concurrency halen (en de laagste compressie) maar moet je met 64 cores op 5ghz ongeveer 3.2 terabyte per seconde ophalen (en nog ergens opslaan... Dus minimaal *2). De 10bytes per cycle is volledig fictief, maar het punt is dat meer cores betekent dat je eerder tegen de problemen van traag geheugen loopt (voor de goede orde 3.2tb/s is 3*5090 oid)

[fenrirs]

Precies dit

[laptopleon]

Dertig jaar geleden had je al PowerMac’s die mp (multi-processor) waren. Daar had je toen in de praktijk maar weinig aan, omdat alleen een paar Photoshopfilters zoals rgb omzetten naar cmyk er gebruik van maakten.

Als ik het goed begrijp is dit dus nog steeds een zwak punt. Je zou denken dat na al die tijd rekenwerk van een ‘zware’ app standaard / meer automatisch al gedistribueerd wordt over de beschikbare rekenkracht.

[Mouze88]

Hoeveel is meer dan 64 threads? Zoveel als er maximaal beschikbaar zijn?

De AMD Ryzen Threadripper PRO 9995WX heeft 192 threads.

[Reactie gewijzigd door Mouze88 op 7 juli 2025 20:19]

[Ché Mig]

Tja maar een beetje threadrippende 7-zipper pakt ook wel minstens 3 pakketjes tegelijk uit tijdens het inpakken

[Quacko]

Ik heb met 7zip al jaren last, om de zoveel tijd probeer ik het eens. Maar het gebeurt heel vaak dat het zeker bij grote files die in verschillende compressed archives worden gesplitst dat die altijd een fout geeft helemaal aan het einde van unpacken met dacht ik een crc error. Ik heb dit nooit met andere compressietools.

Dit bij verschillende systemen door de jaren heen, nooit anders geweten.

[Bux666]

Leuk artikel, maar dit las ik 2 dagen geleden al op Tweakers in de downloads.

[SuperDre]

Hebben ze ondertussen gefixed dat je de default instellingen op ultra kunt zetten en dat je dan gewoon met rechtermuisknop in 1x naar een bestand kunt comprimeren ipv de optie met de ... Moeten gebruiken waarbij die dan 7zip interface opent en dan alsnog op de OK knop kunt drukken.. want op ultra stand scheelt toch best aardig wat ten opzichte van de default.

[nelizmastr]

Mooi, heb hier nog een server met 2x 20c/40t CPU's erin liggen. Lekker 7zippen dus met die bak