Re: Optimizing libpng encode time
Bob Friesenhahn <[email protected]> Sun, 30 Aug 2020 10:02:52 -0500 (CDT)
| Newsgroups | gmane.comp.graphics.png.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, 29 Aug 2020, Adam Richter wrote:
> but I need to fix the no-filtering build. Unfortunately, I am seeing
> almost know speed up, even though completely commenting out the memcpy
> that all of this is trying to avoid, or making it copy only, say,
> every even row, results in an unbelievable speed-up of over a factor
> of 10 (for no memcpy) for the 4488x3508 image I used in the benchmark
> above. if it turns out that that memcpy avoidance is not a real
> optimization, these changes may make it easier to do some thread-level
> parallelization with OpenMP ("#omp pragma parallel for"...).
It would be good to use a high-quality profiler which can show the
time spent in CPU stalls due to waiting on memory. This can be
extremely illuminating.
In today's systems, all application memory is initialized by default
in some way because otherwise your process would see private data from
the kernel or some other process. Some kernel thread is initializing
this memory. If the kernel thread runs on the same core as your own
code, then the memory will already be pretty "hot" in the caches.
Perhaps there may be hardware-specific tricks to know if a memory page
is initilized to a particular state (e.g. already zero). Memory
freshly allocated using mmap() will behave differently than recycled
"heap" memory which was already used by the same process.
Regardless, if the memcpy is small and done in a L1 or L2 cache
without contention, then it may be insignificant compared to other
factors.
Take a look at the writings of the authors of Facebook's Zstandard
("Zstd") library
(https://engineering.fb.com/core-data/smaller-and-faster-data-compression-with-zstandard/).
The use of branchless algorithms to achieve speed-up on modern CPUs is
particularly facinating.
Bob
--
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt