Re: Greatest Common Divisor

Vik Fearing <vik.fearing@2ndquadrant.com>

From: Vik Fearing <vik.fearing@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>, Stephen Frost <sfrost@snowman.net>, Dean Rasheed <dean.a.rasheed@gmail.com>, Chapman Flack <chap@anastigmatix.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-01-04T00:21:32Z
Lists: pgsql-hackers
On 04/01/2020 00:49, Tom Lane wrote:
> Vik Fearing <vik.fearing@2ndquadrant.com> writes:
>> On 03/01/2020 20:14, Fabien COELHO wrote:
>>> The point of swapping is to a void possibly expensive modulo, but this
>>> should be done on absolute values, otherwise it may not achieve its
>>> purpose as stated by the comment?
>> Ah, true. How widespread are these architectures that need this special
>> treatment? Is it really worth handling?
> On some older RISC architectures, integer division is really slow, like
> slower than floating-point.  I'm not sure if that's true on any platform
> people still care about though.  In recent years, CPU architects have been
> able to throw all the transistors they needed at such problems.  On a
> machine with single-cycle divide, it's likely that the extra
> compare-and-branch is a net loss.


OK.


> Might be worth checking it on ARM in particular, as being a RISC
> architecture that's still popular.


I don't know how I would check this.


> Also, if we end up having a "numeric" implementation, it absolutely is
> worth it for that, because there is nothing cheap about numeric_div.


The patch includes a numeric version, and I take care to short-circuit
everything I can.


> I'd be sort of inclined to have the swap in the other implementations
> just to keep the algorithms as much alike as possible.


They can't quite be the same behavior because numeric doesn't have the
unrepresentable -INT_MIN problem, and integers don't have NaN.

-- 

Vik Fearing




Commits

  1. Add functions gcd() and lcm() for integer and numeric types.