Live data from Hacker News

Pigz: Parallel gzip for modern multi-processor, multi-core machines

zlib.net

171–180 of 197 posts

Re: Pigz: Parallel gzip for modern multi-processor, multi-core machines

#171
post #52

If you are interested in optimizing parallel decompression and you happen to have a suitable NVIDIA GPU, GDeflate [1] is interesting. The target market for this is PC games using DirectStorage to quickly load game assets. The graph in [1] shows DirectStorage maxing out the throughput of a PCIe Gen 3 drive at about 3 GiB/s when compression is not used. When GPU GDeflate is used, the effective rate hits 12 GiB/s. If yo…

I wonder if and if not why not ML uses this to speed up training

Re: Pigz: Parallel gzip for modern multi-processor, multi-core machines

#173
post #161

Earlier quoted context omitted.

Even if you ignore threading models prior to pthreads, pthreads itself dates to 1995.

And Unix 1973

So: Unix was ~22 when Pthreads were introduced in 1995, and Pthreads are 28 years old now.

Re: Pigz: Parallel gzip for modern multi-processor, multi-core machines

#174
post #21

Earlier quoted context omitted.

I wasn't aware the Unix philosophy was to not use multithreading on large jobs that can be parallelized. You can complain about philosophies but this is just using the wrong tool for the job. Complain about bzip if you feel the bzip authors should have made multithreaded implementation for you.

Unix generally favors processes over threads, at least the old school Unix. Threads are a more recent innovation. The old approach was that programs don't need internal parallelism because you can get it by just piping stuff and relying on the kernel's buffering to keep multiple processes busy. Eg, tar is running on one core dealing with the filesystem, gzip is running on another core compressing stuff. In the early…

Processes can still be fine. If you're lucky you can be debating over whether you'd like something to be 99x or 100x faster.

Re: Pigz: Parallel gzip for modern multi-processor, multi-core machines

#175
post #171
post #52

If you are interested in optimizing parallel decompression and you happen to have a suitable NVIDIA GPU, GDeflate [1] is interesting. The target market for this is PC games using DirectStorage to quickly load game assets. The graph in [1] shows DirectStorage maxing out the throughput of a PCIe Gen 3 drive at about 3 GiB/s when compression is not used. When GPU GDeflate is used, the effective rate hits 12 GiB/s. If yo…

I wonder if and if not why not ML uses this to speed up training

The model weights (the thing being updated by the training process) stay loaded in gpu memory during training (the slow part). This could be useful to serialize the model weights to disk when checkpointing or completed, but it's a drop in the bucket compared to the rest of the time spent training.

Re: Pigz: Parallel gzip for modern multi-processor, multi-core machines

#177

Earlier quoted context omitted.

In video games long loading times for levels is a serious pain point, so video game developers put a lot of effort into tuning up compression algorithms to get the best wall clock time considering both the time to fetch content from storage and the time to decompress. If the target is a console you may know exactly what hardware is there so you can justify the effort in tuning. (it’s more complex today because you ha…

Don't most games/game engines use TGA format for their textures? Those are all RLE-encoded if I'm not mistaken (which is very fast but very inefficient space-wise). Or perhaps that is just at game creation and those will get baked to some other image format for distribution?

The most important thing for modern texture compression is that the GPU supports it without ever having to decompress - saves VRAM and memory bandwidth. So it's usually specialized formats like ASTC.

Re: Pigz: Parallel gzip for modern multi-processor, multi-core machines

#178

John Carmack just had a tweet today on this problem: >I started a tar with bzip command on a big directory, and it has been running for two days. Of course, it is only using 1.07 cores out of the 128 available. The Unix pipeline tool philosophy often isn’t aligned with parallel performance. https://twitter.com/ID_AA_Carmack/status/1656708636570271768...

There are several programs to solve this problem. He just wanted to complain and write something built around that.

Re: Pigz: Parallel gzip for modern multi-processor, multi-core machines

#179
post #82

Still blows my mind people still use gzip. 20 years ago I was expecting by this point in time for there to be lots of effort put into increasing compression and working towards getting that fast, instead its been a push for speed. It makes sense with how the internet has changed. These days gzip isn't even in the top 100 as far as compression goes, hell even something like RAR or 7zip are far back compared to the bes…

It shouldn't, it's still plenty fast for 95% of the stuff out there that you wanna make a zipped archive of. It's pretty much installed everywhere too

Re: Pigz: Parallel gzip for modern multi-processor, multi-core machines

#180
post #65

Best of luck with the implementation, but I do hope the authors realise they should avoid naming their software tools like an old-school pornographic film. I thought we had learned that from the GIMP[1]. [1] https://www.theregister.com/2019/08/28/gimp_open_source_imag...

There is nothing pornographic about “pigz.”

Pigs elicits images of heavy exchange of bodily fluids between the intervenients
Post reply on HN