Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

7-zip.org

Post reply on HN
Print view View original

131–140 of 220 posts

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

#131

Post by KronisLV »

rf15 wrote: post #13
d33 wrote: post #10

I worry that 7-Zip is going to lose relevance because lack of zstd support. zlib's performance is intolerable for large files and zlib-ng's SIMD implementation only helps here a bit. Which is a shame, because 7-Zip is a pretty amazing container format, especially with its encryption and file splitting capabilities.

Not that many people care about zstd; I would assume most 7-zip users care about the convenience of the gui.

That's basically me! I really like 7-Zip because it opens most archive formats I have to work with and also the .7z format has pretty good compression for the stuff I want to store longer term.

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

#132

Post by monocasa »

immibis wrote: post #68
Const-me wrote: post #28

Earlier quoted context omitted.

The NT kernel dates back to 1993. Computers didn’t exceed 64 logical processors per system until around 2014. And doing it back then required a ridiculously expensive server with 8 Intel CPUs. The technical decision Microsoft made initially worked well for over two decades. I don’t think it was lame; I believe it was a solid choice back then.

Linux had many similar restrictions in its lifetime; it just has a different compatibility philosophy that allowed it to break all the relevant ABIs. Most recently, dual-socket 192-core Ampere systems were running into a hardcoded 256-processor limit. https://www.tomshardware.com/pc-components/cpus/yes-you-can-...

Tom's hardware is mistaken in their reporting. That's raisng the limit without using CPUMASK_OFFSTACK. The kernel already supported thousands of cores with CPUMASK_OFFSTACK and has at least since the 2.6.x days.

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

#133

Post by marcellus23 »

d33 wrote: post #10

I worry that 7-Zip is going to lose relevance because lack of zstd support. zlib's performance is intolerable for large files and zlib-ng's SIMD implementation only helps here a bit. Which is a shame, because 7-Zip is a pretty amazing container format, especially with its encryption and file splitting capabilities.

Why are they not adopting ztsd?

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

#135

Post by tobinc »

ltbarcly3 wrote: post #22

Wow, a program that doesn't matter anymore has been very very minimally enhanced on a platform that doesn't matter anymore, benefitting the 7 users that have more than 64 real cores with Windoes and are regularly compressing archives so large that it doesn't drastically reduce the compression ratio to split it into more thsn 64 sections. Posting this link to hn has consumed more human potential than the thing it is d…

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

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

#136

Post by mrWiz »

dikei wrote: post #29
d33 wrote: post #10

I worry that 7-Zip is going to lose relevance because lack of zstd support. zlib's performance is intolerable for large files and zlib-ng's SIMD implementation only helps here a bit. Which is a shame, because 7-Zip is a pretty amazing container format, especially with its encryption and file splitting capabilities.

I use ZSTD a ton in my programming work where efficiency matters. But for sharing files with other people, ZIP is still king. Even 7z or RAR is niche. Everyone can open a ZIP file, and they don't really care if the file is a few MBs bigger.

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

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

#137

Post by snickerdoodle12 »

rf15 wrote: post #13
d33 wrote: post #10

I worry that 7-Zip is going to lose relevance because lack of zstd support. zlib's performance is intolerable for large files and zlib-ng's SIMD implementation only helps here a bit. Which is a shame, because 7-Zip is a pretty amazing container format, especially with its encryption and file splitting capabilities.

Not that many people care about zstd; I would assume most 7-zip users care about the convenience of the gui.

That's why 7zip should support it. People care about the convenience of the GUI and we all benefit from better compression being accessible with a nice GUI.

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

#138

Post by p_ing »

arp242 wrote: post #65
Const-me wrote: post #28

Earlier quoted context omitted.

The NT kernel dates back to 1993. Computers didn’t exceed 64 logical processors per system until around 2014. And doing it back then required a ridiculously expensive server with 8 Intel CPUs. The technical decision Microsoft made initially worked well for over two decades. I don’t think it was lame; I believe it was a solid choice back then.

> Computers didn’t exceed 64 logical processors per system until around 2014. Server systems were available with that since at least the late 90s. Server systems with >10 CPUs were already available in the mid-90s. By the early-to-mid 90s it was pretty obvious that was only going to increase and that the 64-CPU limit was going to be a problem down the line. That said, development of NT started in 1988, and it may hav…

"Server systems" but not server systems that Microsoft targeted. NT4 Enterprise Server (1996) only supported up to 8 sockets (some companies wrote their own HAL to exceed that limit). And 8 sockets was 8 threads with no NUMA back then, not something that would have been an issue for the purposes of this discussion.

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

#139

Post by starik36 »

mrWiz wrote: post #136
dikei wrote: post #29

Earlier quoted context omitted.

I use ZSTD a ton in my programming work where efficiency matters. But for sharing files with other people, ZIP is still king. Even 7z or RAR is niche. Everyone can open a ZIP file, and they don't really care if the file is a few MBs bigger.

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.

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

#140

Post by _zagj »

Night_Thastus wrote: post #113
d33 wrote: post #10

I worry that 7-Zip is going to lose relevance because lack of zstd support. zlib's performance is intolerable for large files and zlib-ng's SIMD implementation only helps here a bit. Which is a shame, because 7-Zip is a pretty amazing container format, especially with its encryption and file splitting capabilities.

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.

7-zip, through its .7z format, also supports AES encryption. I'd argue it's probably the easiest way to encrypt individual file archives that you need to access on both Windows and Linux. I have a script I periodically run that makes an encrypted .7z archive of all of my projects, which I then upload for off-site backup. (On-site, I don't bother encrypting.)
Post reply on HN