Live data from Hacker News

7-Zip for Windows can now use more than 64 CPU threads for compression

7-zip.org

211–220 of 220 posts

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#211

Earlier quoted context omitted.

Same thing with "WAV" files. There's at least 3 popular formats for the audio data out there.

More 'useful' one is webp. It has both a lossy and lossless compression algorithm, which have very different strengths and weaknesses. I think nearly every device supports reading both, but so many 'image optimization' libraries and packages don't - often just doing everything as lossy when it could be lossless (icons and what not).

So apparently webp is also 'RIFF" which is the container for WAV files as well it seems. I did not know this. Also webp has its own specialized lossless algorithm. For things like icon art I generally just continue to use PNG. Is there an advantage to using Webp Losslesss?

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#212
post #136

Earlier quoted context omitted.

My main use case for 7z is bypassing corporate filters that block ZIPs from being sent.

I think gmail is onto you. They blocked one of my 7z files the other day.

Thankfully our corporate IT isn't onto me yet.

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#213
post #209
post #191

Earlier quoted context omitted.

That was an impressive result, so I tried it on a huge email inbox. uncompressed: 1512662084 xz --extreme -9: 508431572 12:47 zstd --ultra -21: 508432560 12:44 (-22 ran out of memory.) So at least by me zstd was identical to xz almost to the byte and the second.

It does really vary based on the data set. If the email data is mostly text with markup (like HTML/XML), you might want to try bzip3 too. It's also possible that a large part of your email is actually already-compressed binary data (like PDFs and images) possibly encoded in base-64. In that case it's likely that all tools are pretty good at compressing the text and headers, but can do little to compress the attachmen…

    bzip3 -b511: 580771424  8:51
I suspect your theory about compressed attachments is correct, although bzip3 isn't doing very well compared to the rest.

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#214

Earlier quoted context omitted.

tar.zstd is superior in basically every way, open, and portable

It's fine that we run in different circles, but I have yet to see one of these in the wild. Betamax was better, too.

Betamax wasn't better. This is just a meme.

Half the internet is tar.xz. tar.zstd will probably replace that.

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#215

Earlier quoted context omitted.

7-zip is the de-facto tool on Windows and has been for a long time. It's more than fast and compressed enough for 99% of peoples use cases. It's not going anywhere anytime soon. The more likely thing to eat into its relevance is now that Windows has built-in basic support for zipping/unzipping EDIT: other formats*, which relegates 7-zip to more niche uses.

Windows has had built in zip/unzip since vista. 7zip is far superior (and the install base proves that)

Windows now has 7z support. I fear 7-zip will continue to lose relevancy for consumers of .7z files.

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#216
post #213
post #209

Earlier quoted context omitted.

It does really vary based on the data set. If the email data is mostly text with markup (like HTML/XML), you might want to try bzip3 too. It's also possible that a large part of your email is actually already-compressed binary data (like PDFs and images) possibly encoded in base-64. In that case it's likely that all tools are pretty good at compressing the text and headers, but can do little to compress the attachmen…

bzip3 -b511: 580771424 8:51 I suspect your theory about compressed attachments is correct, although bzip3 isn't doing very well compared to the rest.

Interesting--thanks for checking! I had good experiences with bzip3 compressing Wikipedia XML dumps, to the point it even outperformed xz, so I thought something similar might happen here. Compression does remain a bit of a black art, where it's hard to predict what works without trying it out.

Overall I'm still slightly biased towards using zstd as a default, in that I believe:

  1. zstd will almost always be among fastest formats for decompression, which is obviously nice-to-have everything else being equal.
  2. zstd can achieve a very high compression ratio, depending on tuning; rarely will zstd significantly underperform the next best option.
Overall this is a pretty good case for using zstd by default, even if in some cases it's not noticably better than other formats. In your case, xz seems to be just as good.

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#217
post #135

Earlier quoted context omitted.

A 1% speed improvement for 1% of 7zip users is several times more productive than your comment.

This will not deliver your stated threshold.

You only strengthen my point.

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#218

Earlier quoted context omitted.

It's fine that we run in different circles, but I have yet to see one of these in the wild. Betamax was better, too.

Betamax wasn't better. This is just a meme. Half the internet is tar.xz. tar.zstd will probably replace that.

Betamax was objectively better in many categories; that it doesn't fit your narrative is now another one.

It was smaller, had better picture AND audio quality, and a better head to tape ratio.

It was also proprietary and stored less, which were 2 causes of it losing to VHS.

.zstd may END UP being a standard, or it may not, but sheer technical merit is not enough to guarantee it.

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#219

Earlier quoted context omitted.

Betamax wasn't better. This is just a meme. Half the internet is tar.xz. tar.zstd will probably replace that.

Betamax was objectively better in many categories; that it doesn't fit your narrative is now another one. It was smaller, had better picture AND audio quality, and a better head to tape ratio. It was also proprietary and stored less, which were 2 causes of it losing to VHS. .zstd may END UP being a standard, or it may not, but sheer technical merit is not enough to guarantee it.

Betamax, as released, was not better than VHS. It also had very low recording times of like 1 hour per tape.

Betamax was updated repeatedly, as was VHS. At no point was contemporaneous consumer Betamax able to match VHS for quality with the same recording times.

This is a persistent myth propagated primarily by people who have probably never seen Betamax in use.

Often people compare a professional version of betamax to consumer versions of VHS as well.

Re: 7-Zip for Windows can now use more than 64 CPU threads for compression

#220
post #187

Earlier quoted context omitted.

The `zip` command on Ubuntu is 6.0, which was released in 2009 and does not support zstd. It does support bzip2 though!

> The `zip` command on Ubuntu is 6.0, which was released in 2009 and does not support zstd. It does support bzip2 though! You probably mean the "unzip" command, which https://infozip.sourceforge.net/UnZip.html lists as 6.0 being the latest, released on 20 April 2009. Relevant to this discussion, new in that release are support for 64-bit file sizes, bzip2 compression method, and UTF-8 filenames. The "zip" command is…

> It would be great if both (or at least unzip) were updated to also support LZMA/XZ/ZSTD as compression methods,

Why ? Xz supports xz, zstd supports zstd. Why should unzip support xz or rar or gz ?

Post reply on HN