7-Zip for Windows can now use more than 64 CPU threads for compression
31–40 of 220 posts
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#32Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#33I 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.
Being a bit faster or efficient won't make most people switch. 7z offers great UX (convenient GUI and support for many formats) that keeps people around.
If anything, the gui and ux is terrible compared to winrar.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#34Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#35Earlier 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.
All the GUI I need is right click-> extract here or to folder. And 7zip is doing that nicely.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#36Earlier 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.
I mean, x86 didn't, but other systems had been exceeding 64 cores since the late 90s. And x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it.
> other systems had been exceeding 64 cores since the late 90s.
Windows didn’t run on these other systems, why would Microsoft care about them?
> x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it
For publicly accessible web servers, Linux overtook Windows around 2005. Then in 2006 Amazon launched EC2, and the industry started that massive transition to the clouds. Linux is better suited for clouds, due to OS licensing and other reasons.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#37I 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.
> Everyone can open a ZIP file, and they don't really care if the file is a few MBs bigger.
You can use ZSTD with ZIP files too! It's compression method 93 (see https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT which is the official ZIP file specification).
Which reveals that "everyone can open a ZIP file" is a lie. Sure, everyone can open a ZIP file, as long as that file uses only a limited subset of the ZIP format features. Which is why formats which use ZIP as a base (Java JAR files, OpenDocument files, new Office files) standardize such a subset; but for general-purpose ZIP files, there's no such standard.
(I have encountered such ZIP files in the wild; "unzip" can't decompress them, though p7zip worked for these particular ZIP files.)
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#38Earlier 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.
I mean, x86 didn't, but other systems had been exceeding 64 cores since the late 90s. And x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it.
> And x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it.
If that were the case the above system wouldn't have needed 8 sockets. With NUMA systems the app needs to be scheduling group aware anyways. The difference here really appears when you have a single socket with more than 64 hardware threads, which took until ~2019 for x86.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#39Earlier quoted context omitted.
I mean, x86 didn't, but other systems had been exceeding 64 cores since the late 90s. And x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it.
> other systems had been exceeding 64 cores since the late 90s. Windows didn’t run on these other systems, why would Microsoft care about them? > x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it For publicly accessible web servers, Linux overtook Windows around 2005. Then in 2006 Amazon launched EC2, and the industry started that massive transition to the clouds. Linux is b…
> Windows didn’t run on these other systems, why would Microsoft care about them?
Because it was clear that high core count, single system image platforms were a viable server architecture, and NT was vying for the entire server space, intending to kill off the vendor Unices.
. For publicly accessible web servers, Linux overtook Windows around 2005. Then in 2006 Amazon launched EC2, and the industry started that massive transition to the clouds. Linux is better suited for clouds, due to OS licensing and other reasons.
Linux wasn't the only OS. Solaris and AIX were NT's competitors too back then, and supported higher core counts.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#40Earlier quoted context omitted.
I mean, x86 didn't, but other systems had been exceeding 64 cores since the late 90s. And x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it.
> And x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it. If that were the case the above system wouldn't have needed 8 sockets. With NUMA systems the app needs to be scheduling group aware anyways. The difference here really appears when you have a single socket with more than 64 hardware threads, which took until ~2019 for x86.
There were single image systems with hundreds of cores in the late 90s and thousands of cores in the early 2000s.
I absolutely stand by the fact that Intel and AMD didn't pursue high core count systems until that point because they were so focused on single core perf, in part because Windows didn't support high core counts. The end of Denmark scing forced their hand and Microsoft's processor group hack.