Re: libpng and multithreading

Not adding to the main part of this thread but I do have some input
for the filters part in case it's of any use there, for any row,
column or diagonal to be made multi-threaded despite depending on
local pixels, you can make an additional boolean array for declaring a
pixel done, this is just a fall back in case the threads dsync,
anyways since some filters rely on columns then rows you can launch a
thread per row starting from the 1st expected row, normally this will
result in the threads starting in the right order and reading the
expected pixel after it's been modified, you can further ensure this
by reading the 1st boolean of each row to check it's been set before
starting the next thread. Also if you add an additional row and column
on the outside of the image for the 0 values on -1 you can skip the
jump instruction and just do the calculation. If that was of use then
great, if not too bad, I'm no expert on filters.

On Mon, 21 Nov 2022 at 21:58, John Bowler
<[email protected]> wrote:
>
> On Mon, Nov 21, 2022 at 6:51 AM Manish Upadhyay <[email protected]> wrote:
>>
>> I was looking to improve performance of libpng by adding threading support in compression workflow.
>
>
> You need to do some profiling to see where the time is really going in your specific case.  Different cases produce radically different results; often an optimization really only works on one set of test cases.
>
> The  compression is done using zlib - it's not part of libpng - and it is very heavily optimized.  It also has a parallel implementation called pigz and it should be relatively easy to fork libpng to use that.  I don't know what the likely speedups are; it depends on the specific test case...
>
> The main place where libpng itself does something inherently parallelable is in filter code.  This has two aspects; vector parallel operation which is, of course, not MT, and MT.  So far as I can remember there is no vector write code but someone might have done something at some point.  This is the point where existing parallel code exists on the read side.
>
> For MT it's fairly obvious; there are multiple rows in a typical input image and they can be filtered independently.  Indeed the current code tests up to five different filter methods and I think it's easy to make those tests run in parallel.
>
> It is also possible to replace the heuristics by complete compression using zlib; this involves running multiple zlib instances using the zlib feature to clone the compression state.  Actually doing the latter without MT is likely to have a disastrous effect on performance, but with MT the overhead is the zlib clone and it sort-of sounds possible.
>
> That said the single fastest way of making a PNG write blindingly fast is to drop all the filters and select level 3 compression.  You could time these approaches across a range of images and, in fact, the (unfortunately named) program 'pngcp' in contrib/tools/pngcp.c has a non-default compilation option -DPNG_PNGCP_TIMING_SUPPORTED which will enable accurate compression timing given a POSIX 1993/09 compliant system (i.e. almost anywhere).
> _______________________________________________
> png-mng-implement mailing list
> png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/png-mng-implement