Re: Greatest Common Divisor

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Greatest Common Divisor
Date: 2020-01-03 23:49:18
Message-ID: 13445.1578095358@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)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.

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

Also, if we end up having a "numeric" implementation, it absolutely is
worth it for that, because there is nothing cheap about numeric_div.
I'd be sort of inclined to have the swap in the other implementations
just to keep the algorithms as much alike as possible.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikael Kjellström 2020-01-04 00:05:56 Re: sidewinder has one failure
Previous Message Andres Freund 2020-01-03 23:30:22 Re: Greatest Common Divisor