[fpc-devel] inline... and philosophy

[J. Gareth Moreton]

Competitions aside, there are times where space is a premium, whether it 
be from distributing an application on a DVD, bandwidth or data limits 
(even some first world countries are still on dial-up in places, or are 
otherwise monopolised by a single, bad-quality provider), the smaller 
capacity of solid-state hard drives (especially on some laptops) and can 
otherwise be a money saver sometimes.

Now, I don't condone EXE compression except maybe for setup programs, 
and I don't condone making a binary smaller at the expense of 
performance (hence why you should never use the "LOOP" opcode).

It is mentioned on the Wiki article that those who program on embedded 
systems use their own customised libraries for smaller sizes and higher 
speed.  Nothing wrong with that, but I don't think RTL patches should be 
ignored straight-up.  I hoped to update uComplex to be friendlier to 
newer processors (one problem that Delphi had) by aligning the type and 
utilising vectorcall on win64 (aligning the type is enough on Unix-like 
systems for the compiler to take full advantage of the vector 
registers).  This can make a significant improvement in performance AND 
code size once the compiler gets smarter with vectorisation.  Given it's 
a very old unit, I've done my best to ensure backwards compatibility is 
maintained in Pascal-only code, although I think there will always be 
breaks in edge cases.

Maybe it is unrealistic to compare FPC to GCC and some commercial 
compilers, but I personally like to aim high anyway.

In truth, I think the FPC test suite could use some more benchmark tests 
to a) see if a proposed performance buff actually improves compiler 
speed (e.g. what I did for improving case blocks), and b) to see if a 
size reduction optimisation doesn't impact speed too badly.  Ideas that 
spring to mind... integer and floating-point division operations (recent 
versions of the compiler convert them to multiplications when possible), 
and maybe a use-case for uComplex.  Granted, I could make my own 
highly-optimised mathematical unit, but how might one recommend people 
use it over what's supplied with FPC?

Gareth aka. Kit


On 09/11/2019 13:46, Michael Van Canneyt wrote:
>
>
> On Sat, 9 Nov 2019, Marco van de Voort wrote:
>
>>> Seeking to reduce binary size (without sacrificing speed) and make 
>>> as many optimisations as possible may be a fool's errand because the 
>>> returns don't justify the costs, but I personally enjoy the 
>>> challenge and puzzle-solving element of it.  I just hope I haven't 
>>> scared off the administrators when I argued with Florian on my jump 
>>> optimisations (the aforementioned inline/blobing issue).
>>>
>> Start with asking why you feel the need to do it, and how much would 
>> be enough.
>
> It's never enough:
> http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
>
> Michael.
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20191109/0a40b659/attachment.html>