Please note that only Marco's e-mails are making the list.  I don't see Michael's responses.

Gareth aka. Kit

On 29/10/2019 13:41, Marco van de Voort wrote:

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

fpc-devel maillist  -

This email has been checked for viruses by Avast antivirus software.

fpc-devel maillist  -

Reply via email to