News Packprogramm: 7-zip Version 25.00 ist endlich eine „Threadripper-Edition“

[Autokiller677]

@Loopman: Das sollte ein Win 11 Problem sein und nicht die Schuld von 7z. 🤷‍♀️

Ne, ein Programm muss das bei der Installation über die entsprechende API registrieren.

 

[mae]

Was packt man den mit 7 zip wo man 64 kerne willkommen heisst? Muss ich jetzt mal ganz naiv fragen 😅

Ich verwende dafuer zwar nicht 7-zip, aber gestern habe ich ein Backup mit xz -1 (also die schnellste xz-Option) komprimiert, habe damit 8 Zen4-cores ausgelastet, und konnte von der Quelle trotzdem nur mit durchschnittlich 48MB/s lesen. Mit xz-Komprimierung und einem hoeheren Kompressionslevel kriegt man auch 192 Kerne ausgelastet. Ich habe mich aber jetzt entschieden, lieber gzip -2 zu verwenden, das komprimiert zwar nicht so gut, aber dafuer schneller, sogar mit nur einem Kern.

 

[Loopman]

Ich habe mich aber jetzt entschieden, lieber gzip -2 zu verwenden, das komprimiert zwar nicht so gut, aber dafuer schneller, sogar mit nur einem Kern

Das Problem ist, dass sich die meisten speicherintensiven Daten meist eh nicht (gut) packen lassen. Audio/Video meist klar unter 5%, selbst PDF usw. nur sehr eingeschränkt.

Deshalb nutzt man meistens nur die "Store" Variante, also ohne jegliche Kompression.
Das macht meistens mehr Sinn. Und hier limitiert fast nur der Speed des Datenträgers, weniger die CPU.

Die Größen von HDD/SSD sind mittlerweile so hoch, dass selbst Packraten von >90% bei den passenden Daten (textbasiert) kaum einen großen Unterschied machen.
Auch die Bandbreiten beim Up-/Download sind mittlerweile so hoch, dass man auch hier kaum noch Zeit/Volumen sparen kann. Zumindest als Privatperson.

 

[incurable]

Weniger Threadripper, mehr NVL-S.

 

[qiller]

in das neue Windows 11 Kontextmenü integrieren würden

War direkt das erste, was ich umgestellt habe: dauerhaft altes Kontextmenü.

 

[Popey900]

@qiller wie?

Edit:
Habe es hinbekommen

 

[qiller]

wie?

Für die Nachwelt:
https://www.deskmodder.de/wiki/index.php?title=Altes_Kontextmenü_öffnen_Windows_11

alt:

reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve

neu:

reg.exe delete "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve

 

[Stefan1200]

Was wichtiger wäre, wenn sie das Ding endlich mal in das neue Windows 11 Kontextmenü integrieren würden.

Darkmode wann?

Beides mit NanaZIP möglich, welches, mit etwas Verzögerung, immer auf der neusten 7-Zip Version basiert (aktuell verwendet es noch 24.09): https://github.com/M2Team/NanaZip

 

[andr_gin]

WinRAR unterstützt zwar noch nicht eine besonders hohe Anzahl an Threads, aber für mich ist es trotzdem das rundere Programm. Es ist zwar nicht kostenlos, kostet aber auch nicht die Welt.

Das mit der Threadanzahl kann man so pauschal nicht sagen, da die 2 Programme hier komplett andere Ansätze verfolgen:

7zip teilt die Daten zuerst einmal in Blöcke auf und komprimiert diese unabhängig von einander.

Vorteil:
.) Es skaliert mit größerer Threadanzahl deutlich besser, da jeder Thread unabhängig von den anderen arbeiten

Nachteil:
.) Ein Thread braucht immer 2x Dictionary Size (bei Ultra 128MB) an Daten. Bei kleineren Dateien bzw. am Ende des Komprimierungsvorgangs skaliert es also deutlich schlechter.
.) Da jeder Thread sein eigenes Dictionary hat skaliert der RAM Bedarf auch mit der Thread Anzahl. Man muss also bei Nutzung vieler Threads die Dictionary Size reduzieren da sonst der RAM ausgeht.

WinRAR verarbeitet die Daten sequentiell, teilt sich ein Dictionary und parallelisiert nur die Komprimierung selbst.

Nachteil: Es skaliert bei großen Dateien nicht so gut.

Vorteile:
.) Es können auch kleinere Dateien voll parallelisiert werden.
.) Man kann deutlich größere Dictionary Sizes verwenden. Dies kann sich vor allem bei vielen (teilweise) gleichen Dateien im Archiv extrem auf die Archivgröße auswirken.

Für den täglichen Alltagsgebrauch ist der WinRAR Ansatz meiner Meinung nach deutlich besser.
Allerdings ist die 7zip Komprimierung an sich schon in der Regel etwas stärker was die niedrigere Dictionary bei Daten ohne vielen Duplikaten relativ gut kompensieren kann.

Für den Alltagsgebrauch und um ein paar Backups zu automatisieren nutze ich WinRAR (primär wegen der Performance bei kleinen Dateien).
Für Kundenprojekte (da Open Source) oder wenn ich etwas anderes außer Dateien komprimieren will (da dll vorhanden) nutze ich 7zip.

P.S.: Niemals den integrierten 7 zip Benchmark verwenden. Der ist rein synthetisch und absolut nicht repräsentativ besonders beim Dekomprimieren.

 

[Flyto]

Darkmode wann?

Es gibt einen inoffiziellen mod für darkmode:
https://github.com/ozone10/7zip-Dark7zip/releases

nutze ich selbst auch.

 

[zivilist]

Am Layout wurde nicht geschraubt? Deswegen verwende ich NanaZip. Vielleicht gibts davon bald auch eine neue Version.

 

[Epistolarius]

Was wichtiger wäre, wenn sie das Ding endlich mal in das neue Windows 11 Kontextmenü integrieren würden.

Darkmode wann?

NanaZip bietet beides und ist ein Fork von 7zip. Steht u. a. auch im Microsoft Store bereit und wird somit automatisch aktualisiert. Hat allerdings noch nicht die neuesten Updates von 7zip integriert.
https://github.com/M2Team/NanaZip
https://apps.microsoft.com/detail/9n8g7tscl18r

 

[phisCON]

War direkt das erste, was ich umgestellt habe: dauerhaft altes Kontextmenü.

Für Interessierte:
https://www.giga.de/tech/windows-11...-wiederherstellen--01J4S9H295EX3ASXA0XWQDPY55

 

[gymfan]

Was packt man den mit 7 zip wo man 64 kerne willkommen heisst? Muss ich jetzt mal ganz naiv fragen 😅

Es wäre mal interessant, was sich bei meinem monatlichen Backup damit an Performance ergibt. Meine hoffnungslos veralteten 8+8 Kerne sind >10 Minuten beschäftigt, bis sie die 20,2 GB Quelldaten zum 12,78 GB Archiv komprimiert haben.

Wobei mir der TR einen zu hohen Idle-Bedarf hat, um mir so eine Kiste hier hinzustellen.

Deshalb nutzt man meistens nur die "Store" Variante, also ohne jegliche Kompression.

Ich bin froh, dass aus meinen 20,2 GB nur noch 12,78 GB werden und ich sie, dank 7zip, trotzdem auf jedem von mir genutzten Gerät wieder problemlos entpacken könnte. Ob die CPU dafür 2 Minuten länger rechnet oder nicht ist mir egal.

Das sind immerhin 7,42 GB weniger, die ich durch den schnachend lahmen 100 MBit/s Internet-Upload quetschen muss. Und wehe, ich muss den Upload wegen parallelem HomeOffice auch noch massiv drosseln.

Auch die Bandbreiten beim Up-/Download sind mittlerweile so hoch

Ja klar, und Cloud-Speicher kostet auch nichts mehr, womit man sich jeder Optimierung sparen kann.

 

[ThirdLife]

Was packt man den mit 7 zip wo man 64 kerne willkommen heisst? Muss ich jetzt mal ganz naiv fragen 😅

ISO Images z.B. oder Backups fürs Archiv ? Nicht jedes Menschen Leben besteht nur daraus zwei 5MB Powerpoint-Files zu zippen. 🤣

MMn ist das für ein Tool wie 7Zip nur bedingt ein echtes Problem weil meist eh sachte gepackt wird, sodass Storagespeed viel eher limitiert. Der reale Gewinn an weniger Platzbedarf ist ultra gering ggü. dem höheren Energiebedarf bei bspw. Volllast auf der CPU.

Stimmt halt leider null. Bei mir limitiert klar die CPU. Mit Best-Case mal 1-200MB/s sind wir weit weg von einer Gen 4 oder gar Gen 5 NVME sofern man wirklich was komprimieren will.

 

[mae]

Das Problem ist, dass sich die meisten speicherintensiven Daten meist eh nicht (gut) packen lassen. Audio/Video meist klar unter 5%, selbst PDF usw. nur sehr eingeschränkt.

Klar, sind ja schon komprimiert.

Hier ein paar Daten: Ich habe jetzt fuer die Verzeichnisse mit den Audio-Dateien und Photos ein Separates backup (ohne Komprimierung) erstellt, und die restlichen Verzeichnisse (wo auch PDFs und vielleicht auch einzelne Bilder o.ae. drin sind) mit Komprimierung.

242GB Gesamtinhalt der Partition (Ausgabe von df)
158GB Groesse des komprimierten tar-files fuer die ganze Partition, komprimiert mit xz -1
 67GB Audio und Photo-Verzeichnisse (Groesse des tar-files), bleiben 175GB fuer den Rest
110GB Groesse des komprimierten tar-files fuer die 175GB, komprimiert mit gzip -2

Wenn man davon ausgeht, dass die Audio- und Photo-Verzeichnisse nicht komprimiert werden koennen, ist der Rest (175GB) von xz -1 auf 91GB komprimiert worden.

Deshalb nutzt man meistens nur die "Store" Variante, also ohne jegliche Kompression.
Das macht meistens mehr Sinn. Und hier limitiert fast nur der Speed des Datenträgers, weniger die CPU.

Wenn der Speed des Zielmediums limitiert (ist bei einem Backup von NVME auf HDD wohl der Fall), dann zahlt sich ein bisschen Kompression wohl doch aus.

Die Größen von HDD/SSD sind mittlerweile so hoch, dass selbst Packraten von >90% bei den passenden Daten (textbasiert) kaum einen großen Unterschied machen.

Was meinst Du damit? Wenn ich um den Faktor 10 komprimieren kann, brauche ich 10 mal weniger Platz auf dem Backup-Medium, muss spaeter ausduennen bzw. Platten wechseln etc.

 

[ThirdLife]

btw, wo bleiben die Threadripper Benchmarks?

TR kann ich nicht bieten, aber einen 9950X3D dafür:

 

[qiller]

Was meinst Du damit? Wenn ich um den Faktor 10 komprimieren kann, brauche ich 10 mal weniger Platz auf dem Backup-Medium, muss spaeter ausduennen bzw. Platten wechseln etc.

Man braucht mehr Rechenpower (bzw. der Energieverbrauch beim Packen ist höher) und das Packen dauert halt länger. Und wenn von sagen wir mal 500GB Daten 490GB Bilder und Videos sind und nur 10GB gut komprimierbare andere Dateiformate, spart man absolut vlt. 5, 6 o. 7 GB. Bei einer Archivdateigröße von ~500GB ohne Kompression vs. ~493GB mit Kompression kann ich schon verstehen, dass viele dann einfach "speichern" nehmen.

Mit der Methode "schnellste" komme ich mit meinem 16-Kerner auf etwas über 220MB/s. Bei der Methode "speichern" auf ~1.7GB/s.

 

[ThirdLife]

Bei einer Archivdateigröße von ~500GB ohne Kompression vs. ~493GB mit Kompression kann ich schon verstehen, dass viele dann einfach "speichern" nehmen.

Und warum sollte ich dann überhaupt was packen ? Nenn mir bitte einen sinnvollen Grund warum ich jetzt zB einen UHD-Film packen sollte. Der IST schon gepackt. Makes no fucking sense.

 

[qiller]

Makes no fucking sense.

So ist es. Ich hab ja auch nicht gesagt, dass ich das so handhabe^^. Ich hab meine Videos einfach auf 2 unterschiedlichen Datenträgern gespeichert bzw. synce die mit robocopy, that's it. Die sind nicht im Backup enthalten.