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
