7-zip is one of the software that I miss since I’ve moved to macOS
7-Zip for Windows can now use more than 64 CPU threads for compression
21–30 of 220 posts
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#22Posting this link to hn has consumed more human potential than the thing it is describing will save up to the end of time.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#237-zip is one of the software that I miss since I’ve moved to macOS
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#24I 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.
https://github.com/mcmilk/7-Zip-zstd
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#25I 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.
Hence why PeaZip is so popular, and J-Zip used to be before it was stuffed with adware.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#26Earlier quoted context omitted.
Not that many people care about zstd; I would assume most 7-zip users care about the convenience of the gui.
.. but 7-zip has a pretty terrible GUI? Hence why PeaZip is so popular, and J-Zip used to be before it was stuffed with adware.
Granted Windows 11 has started doing the same for its zip and 7zip compressors.
Same trick goes for opening archives or executables (Installers) as archives.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#27I 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.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#28Earlier quoted context omitted.
A lot of synchronization primitives in the NT kernel are based on a register width bit mask of a CPU set, so each collection of 64 hardware threads on 64 bit systems kind of runs in its own instance of the scheduler. It's also unfortunately part of the driver ABI since these ops were implemented as macros and inline functions. Because of that, transitioning a software thread to another processor group is a manual pro…
Wow. That's surprisingly lame.
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.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#29I 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.
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.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#30Earlier quoted context omitted.
Wow. That's surprisingly lame.
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.
And x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it.