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

Reply via email to