[fpc-devel] Question on updating FPC packages

J. Gareth Moreton gareth at moreton-family.com
Tue Oct 29 15:14:52 CET 2019

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:
>> 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.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

More information about the fpc-devel mailing list