Well, when it comes to the specific changes I made to uComplex... the
compiler might be able to detect a kind of 'auto-const' system, but
actually inserting 'const' into the formal parameters helps with syntax
checking as well as generating more efficient code, namely modifying the
parameter when you're perhaps not supposed to.
For vectorcall, I don't think the compiler will correctly guess when and
when not to use the calling convention, and there are times where you
may not want to use vectorcall, usually when interfacing with
third-party programs or libraries. In this case, it's more likely that
the programmer may stumble upon unintented behaviour if it tries to
enable vectorcall for something that is meant to be the default
Microsoft ABI instead.
And using assembly language to directly call the uComplex routines I
don't think is a realistic real-world example, considering that's a
situation where you're more likely to be using the XMM registers
directly to do such mathematics. Besides, I think all bets are off when
it comes to assembly language - in this instance I tried to make sure
that Pascal code didn't have to change though (other than a
recompilation maybe).
I could just say 'screw it' and write my own complex number library, but
then that would just add to the growing collection of third-party
libraries instead of a standard set of libraries that are antiquated and
potentially sluggish on modern systems.
Gareth aka. Kit
On 30/10/2019 22:02, Florian Klämpfl wrote:
Am 29.10.19 um 14:06 schrieb Marco van de Voort:
Op 2019-10-27 om 10:46 schreef Florian Klämpfl:
Am 27.10.19 um 10:27 schrieb Michael Van Canneyt:
If you genuinely believe that micro-optimization changes can make a
difference:
Submit patches.
As said: I am against applying them. Why? They clutter code and
after all, they make assumptions about the current target which not
might be always valid. And time testing them is much better spent in
improving the compiler and then all code benefits. Another point:
for example explicit inline increases normally code size (not always
but often), so it is against the use of -Os. Applying inline
manually on umpteen subroutines makes no sense. Better improve auto
inlining.
Auto inlining is also no panacea. It only works with heuristics,
and is thus only as good as a formula of the heuristic.
Yes. And manually adding inline is only as good as the knowledge of
the user doing so. If somebody implements it right (I did not, I used
the easiest approach and used an existing function to estimate the
complexity of a subroutine). The compiler can just count the number of
the generate instructions or even calculate the length of the
procedure and then decide to keep the node tree for inlining.
Changing calling conventions, vectorizing, loops all complicates
that, and it will never be perfect, and a change here will lead to a
problem there etc.
See above.
If you know a routine can evaluate to one instruction in most cases,
I don't see anything wrong with just marking it as such.
The compiler knows this as well as the compiler generated the code.
Why should I guess if the compiler knows?
_______________________________________________
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
