[fpc-devel] Question on updating FPC packages
Marco van de Voort
fpc at pascalprogramming.org
Tue Oct 29 14:41:11 CET 2019
Op 2019-10-27 om 10:27 schreef Michael Van Canneyt:
> Personally, I don't have any concern for performance in this sense.
> Almost zero.
> I invariably favour code simplicity over performance, for sake of
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
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
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
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.
More information about the fpc-devel