Re: Fwd: Speed versus clarity

[Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>]

On Wed, Mar 29, 2023 at 09:41:52AM +0900, Steve wrote:
> Greetings, number theory maniacs!
> 
> In general, is the coding style of Pari meant to be biased towards clarity
> or towards performance? Obviously there's a continuum, but the Pari project
> itself might prefer cleaner elegant code over most performant just for
> maintenance and readability.
> 
> I ask since I am an obsessive optimizer, and I often squeeze out performance
> by special casing rare cases in order to streamline common cases. This tends
> to expand code size (often by 10x!) but also gives measurable performance.
> 
> So is replacing five clean lines of code in Pari for something simple and
> fundamental like issquare()  with an expanded function of 60 lines
> acceptable if that replacement is two times faster?  I of course could just
> write up the patch and submit it and it can be discussed in specifics at
> that point, but I wanted to get any quick guidance of whether this kind of
> code expansion would be eagerly viewed, discouraged, or (most likely!)
> considered but likely judged based on clarity/size/speed tradeoffs.

The actual issue is that we are not very good at measuring time.
It depends on the hardware but also on the usecase.
For example for issquare(N), in some application, N wil almost always be a square,
while in other N will almost never be a square. Ideally one should not use the
same algorithm for both case.

So I suggest you provide a benchmark that show what performance you want to
improve!

Thanks!
Bill.