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