Re: Optimize mul_var() for var1ndigits >= 8

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Joel Jacobson <joel(at)compiler(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimize mul_var() for var1ndigits >= 8
Date: 2024-08-06 11:52:32
Message-ID: CAEZATCWEJ_uKnc7MrVaEkbT88nweWCzEqLxWXH6jBBoa=y6s1g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 5 Aug 2024 at 13:34, Joel Jacobson <joel(at)compiler(dot)org> wrote:
>
> Noted from 5e1f3b9eb:
> "While it adds some space on 32-bit machines, we aren't optimizing for that case anymore."
>
> In this case, the extra 32-bit numeric_mul code seems to be 89 lines of code, excluding comments.
> To me, this seems like quite a lot, so I lean on thinking we should omit that code for now.
> We can always add it later if we get pushback.
>

OK, I guess that's reasonable. There is no clear-cut right answer
here, but I don't really want to have a lot of 32-bit-specific code
that significantly complicates this function, making it harder to
maintain. Without that code, the patch becomes much simpler, which
seems like a decent justification for any performance tradeoffs on
32-bit machines that are unlikely to affect many people anyway.

Regards,
Dean

Attachment Content-Type Size
v4-0001-Extend-mul_var_short-to-5-and-6-digit-inputs.patch text/x-patch 11.1 KB
v4-0002-Optimise-numeric-multiplication-using-base-NBASE-.patch text/x-patch 13.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2024-08-06 12:23:26 Thread-unsafe MD5 on big-endian systems with no OpenSSL
Previous Message vignesh C 2024-08-06 11:42:27 Re: Logical Replication of sequences