[fpc-devel] Question on updating FPC packages

[J. Gareth Moreton]

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.
https://www.avast.com/antivirus