| Age | Commit message (Collapse) | Author |
|
Approximate tmerc (Snyder): speed optimizations
|
|
Extended tmerc (Poder/Engsager): speed optimizations
|
|
ENOMEM was wrongly set after setting PJD_ERR_ELLIPSOID_USE_REQUIRED
Note: it is a bit strange to forbid the pure spherical case whereas the
maths would allow it. I presume this is due to the typical usage of those
methods.
|
|
fwd: 7% faster on Core-i7@2.6GHz (with FMA triggered), 22% faster on GCE Xeon@2GHz (with FMA)
inv: 31% faster on Core-i7@2.6GHz (with FMA triggered), 60% faster on GCE Xeon@2GHz (with FMA)
The optimizations consists in different things:
- optionaly use the FMA (Fused Multiply Addition) instruction set with gcc >= 6.
Binaries are generated with the standard instruction set (SSE/SSE2),
and with one variant with FMA, and the appropriate version is selected automatically
at runtime. This gives a modest speedup, but measurable. The speedup is more
obvious on lower clocked CPU.
- inline mlfn and inv_mlfn
- for inv_mlfn avoid recomputation of sin()/cos() at each iteration stage,
by observing that the argument changes in modest way at each iteration,
and using approximation of sin()/cos(). The differences due to that approximation
are way below the 1e-11 tolerance threshold.
Different in results are neglectable (only found in areas where the approximations
of the Snyder formulas are already no longer valid)
Before:
$ echo 8e5 9e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx
799997.896522093331 8999999.520601103082
$ echo 8e5 5e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx
800000.000007762224 4999999.999971268699
$ echo 18e5 9e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx
1079182.990696100984 8661150.574729491025
$ echo 18e5 5e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx
1799997.510861013783 4999999.567328464240
After:
$ echo 8e5 9e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx
799997.896522093331 8999999.520601103082
$ echo 8e5 5e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx
800000.000007762224 4999999.999971268699
$ echo 18e5 9e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx
1079182.990696124267 8661150.574729502201
$ echo 18e5 5e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx
1799997.510861013783 4999999.567328464240
|
|
fwd: 52% faster on Core-i7@2.6GHz, 40% faster on GCE Xeon@2GHz
inv: 24% faster on Core-i7@2.6GHz, 36% faster on GCE Xeon@2GHz
Those speed-ups are obtained due to elimination of a number of
transcendental functions (atan, sincos, cosh, sinh), through the
use of usual trigonometric/hyperbolic formulas.
The numeric results before/after seem identical at worse up to
14 decimal digits, which is way beyond the apparent accuracy of the
computations
On a point, far from central meridian, where round-tripping is not so great:
Before:
echo "81 1" | src/proj -d 18 +proj=utm +zone=31 | src/proj -d 18 -I +proj=utm +zone=31
80.999994286593448578 0.999987970918421620
After:
$ echo "81 1" | src/proj -d 18 +proj=utm +zone=31 | src/proj -d 18 -I +proj=utm +zone=31
80.999994286593448578 0.999987970918422175
The benchmarking program used is:
```
#include "proj.h"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char* argv[])
{
if( argc != 3 ) {
fprintf(stderr, "Usage: bench quoted_proj_string fwd/inv\n");
exit(1);
}
PJ* p = proj_create(0, argv[1]);
const int dir = strcmp(argv[2], "inv") == 0 ? PJ_INV : PJ_FWD;
PJ_COORD coord;
if( dir == PJ_FWD )
{
coord.xy.x = 0.5; // rad
coord.xy.y = 0.5; // rad
}
else
{
coord.xy.x = 450000; // m
coord.xy.y = 5000000; // m
}
for(int i = 0; i < 40 * 1000* 1000; i++)
proj_trans(p, dir, coord);
proj_destroy(p);
return 0;
}
```
|
|
per line
Should hopefully result in no change in results, and hopefully more
readable code...
|
|
Affects output of 'proj -l'
|
|
|
|
|
|
Fix test issues on i386
|
|
Refs #1906
Fix remaining issues of https://github.com/OSGeo/PROJ/issues/1906#issuecomment-583168348
as found with gcc 8.2.0 -m32 -O2
|
|
Fix a few issues of #1906 found when running the test suite
on Ubuntu 16.04 with gcc 5.5 -m32. When applied on top of
the fix of #1912, make check succeeds
|
|
|
|
HEAD/1.90dev happy (fixes #1648)
|
|
ob_tran doc: fix/clarify semantics of o_lat_p/o_lon_p
|
|
when the point coordinates are super close to the origin (fixes #1654)
|
|
|
|
|
|
|
|
Patch proj-6.2.0-isea.gpatch by Eric Dechaux
|
|
Patches proj-6.2.0-hanato.gpatch and proj-6.2.0-mbtfpp.gpatch from Eric Dechaux
|
|
Remove unneeded C99 compatibility functions from math.cpp and proj_math.h
I'll do the clean up of the -std=c89 flags etc. as a separate pull request.
|
|
needs <limits.h>. Update scripts/reference_exported_symbols.txt and
src/proj_symbol_rename.h.
|
|
NaN being propagated. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15336
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15009
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14666
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17190
|
|
Northern hemisphere "warp" implemented incorrectly. See #1579
|
|
|
|
to be able to chain with unitconvert (fixes #1525)
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14602
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14477
Credit to OSS Fuzz
|
|
This is mostly to have better OSSFuzz report. Currently a lot
of bug summaries are like
`proj4/standard_fuzzer: Divide-by-zero in s_inverse`
By prefixing the projection name, we will get better reports, like
`Divide-by-zero in airy_s_inverse`
This also makes it slightly easier to set a breakpoint by
function name.
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14447
Credit to OSS Fuzz
|
|
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14421
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14410
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14384
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14342
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14286
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14279
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14250
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14248
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14211
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14138
Credit to OSS Fuzz
|
|
Partially revert e3346bb39c860883ed9a8ada0657139118e21ef0 (#195)
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14136
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14135
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14062
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14061
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14058
Credit to OSS Fuzz
|