Remove ttmath?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Remove ttmath?

Paul Ramsey
So, we ran into some issues with GEOS 3.8 on a Power architecture, and based on what tests failed, I suspect the issue is with our use of ttmath.

In particular, this comment says to me (and just eyeballing what's going on) that there is some in-baked assumptions about endianness.

https://github.com/libgeos/geos/blob/master/include/geos/algorithm/ttmath/ttmathbig.h#L2607-L2609

The only reason we're using ttmath is because Mateusz happened to choose it for his initial experiments on supporting the higher precision code in JTS. Turns out there's no reason we cannot use exactly the same routines as JTS does, though, and they have NO ENDIAN assumptions in them, so they'll be portable.

The port of the JTS code is here:

https://github.com/libgeos/geos/pull/303

Amazingly, all the regression tests still pass.

Also, just based on running the full test suite, the DD code seems 5-10% faster than ttmath. This isn't entirely surprising, since ttmath is an arbitrary precision system, while doubledouble uses nothing but standard double math and the assumption that all double representations and operations are to IEEE spec.

I'm going to port the JTS unit tests so we have a little more foundation under this work, but then I'd like to rip out ttmath in 3.9.

I'm a little worried that we cannot support big-endian machines in 3.8, so I think we might consider back-porting this work to 3.8 and switch over to it for big-endian architectures.

Paul

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: Remove ttmath?

Regina Obe
+1 to ripping out in 3.9 and eventually backporting to 3.8 after some testing.

> -----Original Message-----
> From: geos-devel [mailto:[hidden email]] On Behalf
> Of Paul Ramsey
> Sent: Wednesday, April 15, 2020 5:17 PM
> To: GEOS Development List <[hidden email]>
> Subject: [geos-devel] Remove ttmath?
>
> So, we ran into some issues with GEOS 3.8 on a Power architecture, and
> based on what tests failed, I suspect the issue is with our use of ttmath.
>
> In particular, this comment says to me (and just eyeballing what's going on)
> that there is some in-baked assumptions about endianness.
>
> https://github.com/libgeos/geos/blob/master/include/geos/algorithm/ttma
> th/ttmathbig.h#L2607-L2609
>
> The only reason we're using ttmath is because Mateusz happened to choose
> it for his initial experiments on supporting the higher precision code in JTS.
> Turns out there's no reason we cannot use exactly the same routines as JTS
> does, though, and they have NO ENDIAN assumptions in them, so they'll be
> portable.
>
> The port of the JTS code is here:
>
> https://github.com/libgeos/geos/pull/303
>
> Amazingly, all the regression tests still pass.
>
> Also, just based on running the full test suite, the DD code seems 5-10%
> faster than ttmath. This isn't entirely surprising, since ttmath is an arbitrary
> precision system, while doubledouble uses nothing but standard double math
> and the assumption that all double representations and operations are to
> IEEE spec.
>
> I'm going to port the JTS unit tests so we have a little more foundation under
> this work, but then I'd like to rip out ttmath in 3.9.
>
> I'm a little worried that we cannot support big-endian machines in 3.8, so I
> think we might consider back-porting this work to 3.8 and switch over to it
> for big-endian architectures.
>
> Paul
>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: Remove ttmath?

Sandro Santilli-4
In reply to this post by Paul Ramsey
On Wed, Apr 15, 2020 at 02:16:52PM -0700, Paul Ramsey wrote:

> The only reason we're using ttmath is because Mateusz happened to
> choose it for his initial experiments on supporting the higher precision
> code in JTS. Turns out there's no reason we cannot use exactly the same
> routines as JTS does, though, and they have NO ENDIAN assumptions in them,
> so they'll be portable.

+1 for that, JTS routines seems best option to me.

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: Remove ttmath?

Paul Ramsey
Thanks, I'm going to procede to merge to master when I'm green on CI.
I have added all the JTS tests, so I feel good about the foundation.
Once I have merge to master, I'm going to experiment with adding one of the new bigendian architectures supported by Travis into the CI (because more CI!)

P.

> On Apr 16, 2020, at 4:46 AM, Sandro Santilli <[hidden email]> wrote:
>
> On Wed, Apr 15, 2020 at 02:16:52PM -0700, Paul Ramsey wrote:
>
>> The only reason we're using ttmath is because Mateusz happened to
>> choose it for his initial experiments on supporting the higher precision
>> code in JTS. Turns out there's no reason we cannot use exactly the same
>> routines as JTS does, though, and they have NO ENDIAN assumptions in them,
>> so they'll be portable.
>
> +1 for that, JTS routines seems best option to me.
>
> --strk;
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: Remove ttmath?

Daniel Baston
In reply to this post by Paul Ramsey
I ran some of my performance benchmarks (overlay, PIP) am seeing roughly equal or slightly better performance on the DD branch. So, sounds like a win to me.

Dan

On Wed, Apr 15, 2020 at 5:17 PM Paul Ramsey <[hidden email]> wrote:
So, we ran into some issues with GEOS 3.8 on a Power architecture, and based on what tests failed, I suspect the issue is with our use of ttmath.

In particular, this comment says to me (and just eyeballing what's going on) that there is some in-baked assumptions about endianness.

https://github.com/libgeos/geos/blob/master/include/geos/algorithm/ttmath/ttmathbig.h#L2607-L2609

The only reason we're using ttmath is because Mateusz happened to choose it for his initial experiments on supporting the higher precision code in JTS. Turns out there's no reason we cannot use exactly the same routines as JTS does, though, and they have NO ENDIAN assumptions in them, so they'll be portable.

The port of the JTS code is here:

https://github.com/libgeos/geos/pull/303

Amazingly, all the regression tests still pass.

Also, just based on running the full test suite, the DD code seems 5-10% faster than ttmath. This isn't entirely surprising, since ttmath is an arbitrary precision system, while doubledouble uses nothing but standard double math and the assumption that all double representations and operations are to IEEE spec.

I'm going to port the JTS unit tests so we have a little more foundation under this work, but then I'd like to rip out ttmath in 3.9.

I'm a little worried that we cannot support big-endian machines in 3.8, so I think we might consider back-porting this work to 3.8 and switch over to it for big-endian architectures.

Paul

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel