[postgis-devel] PostGIS 3.3.0beta1 released

[Greg Troxel]

"Darafei \"Komяpa\" Praliaskouski" <me at komzpa.net> writes:

>> >   > The new --enable-lto flag improves math computations.
>> >   Does this mean "gets more correct answers" or just "expected to take
>> >   less CPU time"?  I think it's the latter.  Either way, would be good
>> >   to adjust wording to accurately describe it.
>
> LTO = Link Time Optimization, allows the compiler to optimize and inline
> the code across the source code file boundaries. Removes function calls in
> loops and tightens some steps where functions are wrapper over wrapper over
> wrapper.

Thanks - that's what I thought, so

  The new --enable-lto flag enables increased optimization.

would seem right.

It would be really interesting if there are benchmarks for things (part
of test suite?), which could have published results with/without LTO and
with varying -march on a few platforms.  I have no idea if this is a few
% or 2x, and if 2x that suggests that perhaps more inline defs in .h vs
.c only impls would help the non-LTO case.

My impression is that while LTO is great for efficiency, it is somewhat
fragile in terms of working everywhere and requiring the same compiler
for every file, not necessarily true (but typical) otherwise.  So I
think it is good that it's non-default.

> With correct -march/-mcpu enables more vectorization than otherwise
> possible.

I take that to mean that if you are building for a target with
SIMD/vector instructions, that LTO usually achieves more vectorization
than a non-LTO build.

What's "correct" is complicated.  For a person building code to run on
the machine they are building it on, yes you want -march tuned to that
hardware.

Packaging systems are building for a defined CPU class, and programs
must run on a all members of that class.  For example in pkgsrc the
NetBSD/i386 class is I think all CPUs 486 and up, maybe i586 and up.
That of course excludes various SSE2 optimizations.  Besides
-march=native, the system could add a new i686 target that requires a
CPU with many such features -- and have twice as many binary packages.
With x86_64, the base case is better and this is less of an issue.  But
in the arm world, I recently found out that some (most) GNU/Linux
distributions build for arm(v4/)-softfloat and armv7hf, leaving RPI1
(earmv6hf) users to not use their hardware floating point or
vectorization.

> Generally a very desired thing when you need performance (like in
> PostGIS).

Some packages do run-time selection of code for various HW levels, with
a complicated build system that builds variations for different cpu
types.  I think openssl does this, resulting in taking a few illegal
instruction faults on startup to find the fastest version that runs.

I am not suggesting that postgis should go there, certainly not without
benchmarks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20220708/5c23b998/attachment.sig>