Re: Fwd: Speed versus clarity

[Oliver Bandel <oliver@first.in-berlin.de>]

Hello,

Quoting  Steve <global@jamasaru.com> (snt: 2023-03-29 02:41 +0200 CEST) (rcv: 2023-03-29 02:42 +0200 CEST):
> 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'm not the one who can answer your PARI-related questions, but in
general I would prefer code clarity over speed optimization in most
cases.

> 
> 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.

One general rule of thumb that has established over the last decades
regarding how to write code (and I agree here) is: the less lines the better.


> 
> 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?

60 lines / 5 lines = 12

but only 2 times faster... hmhhh

60 lines on the other hand is not too much,
even though 5 lines is better for clarity.
But if that is not just a singular case but instead it is intended to
blow up the code in many areas of he code base, it might be not a good
idea.
"I am an obsessive optimizer" sounds a bit like "this one function is
just the beginning" ;-)

I believe that optimizing certain features can bring a lot of fun.
Obession though might be a bad guidebook. ;-)

I wonder if there really is a need to make that function faster.
That would be the first question to answer.
Did people complain, that the function you want to optimise is too slow?
Than that might be a reason to change the code.


> 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.

How would you measure the speedup and be sure it is not an artifact?

I would recommend this talk here on youtube to get an impression on
what might go wrong:

"Performance Matters" by Emery Berger
   - 2019-09-15 -
  https://www.youtube.com/watch?v=r-TLSBdHe1A


This talk here is some years older, but might nevertheless be of interest:

"Benchmarking: You're Doing It Wrong" by Aysylu Greenberg
   - 2014-09-21 -
  https://www.youtube.com/watch?v=XmImGiVuJno


Ciao,
  Oliver