[fpc-devel] Question on updating FPC packages

[Marco van de Voort]

Op 2019-10-27 om 10:27 schreef Michael Van Canneyt:
>
>
> Absolutely.
>
> Personally, I don't have any concern for performance in this sense. 
> Almost zero.
> I invariably favour code simplicity over performance, for sake of 
> maintenance.

But there is another kick-in-the-open-door statement about performance: 
That the most performance is gained in a relative small part of the code.

To tackle that you need tools to force the compiler to behave a certain 
way that might not (yet?) be doable on the compiler side. IMHO it is 
unfair to deem this all microoptimization just because it doesn't hurt you.

>
> For good reason: for the kind of code which I create daily, the kind of
> micro-optimizations that you seem to refer to, are utterly insignificant,
> and I expect the compiler to handle them. If it currently does not, 
> then I
> think the compiler, rather than the code, must be improved.

Just the vectorizing will probably more than double the performance. 
Just look at the asm that I posted and imagine reducing it to one 
instruction.

And while set FFT unit is not yet a performance bottle neck  for us now, 
it has been marked as a relative large factor of the measurement time. 
(iirc it is about 1ms for a 400 sample array on somewhat older hardware)

And what is exactly needed might change at any given moment. If a new 
camera comes out, if processing can keep up you can process more samples 
which in turn reduces errors and improves the measurement nearly 
automatically

Doing the same purely algorithmically usually means  weeks-months of 
hard maths trying to improve signal quality, and after that validating 
that for umpteen products and customers etc etc. Believe me, 
"Microoptimization" then sounds very tempting.

If Gareth can get this running enough to show that the FFT reduces 
instructions, I can just stuff it in a DLL, and have it lying on a shelf 
to insert into the Delphi app when needed. Which would be great.

> Code should not entirely disregard optimization, but then it should be 
> on a
> higher level: don't use bubble sort when you can use a better sort. No
> amount of micro-optimization will make bubble sort outperform quickort.

(

Interesting example, I'm not really a hardcore algorithms man, but I can 
think of some potential problems with that statement:

1 that only goes for N->Infinity and that computers don't have infinite 
resources. If quicksort uses more memory (e.g. to track state) it might 
not apply in certain circumstances.

2   if your swap() function is extremely expensive, sorting an already 
sorted array is more expensive with quicksort because it is a non stable 
sort.

3 the non recursive bubble sort might be easier to unroll and then 
optimize by the compiler in cases of sorting a fixed number of items. 
(e.g. ordering the elements of a short vector)

)

Anyway, besides the fun, the "algorithms" mantra is only a first order 
guideline, not an absolute truth.

> Saying that the code is 'almost unusably slow' is the kind of 
> statement that does
> not help. I use the code almost daily in production, no complaints about
> performance, so clearly it is usable.

True. Claims should be proven, and with code that does something (not 
with simply a loop around a single operation)

But that is why I brought up the FFT unit. It is possible that that is 
such a case.