<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>Maybe it is unrealistic to compare FPC to GCC and some commercial
compilers, but I personally like to aim high anyway.</p>
<p>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?<br>
</p>
<p>Gareth aka. Kit</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 09/11/2019 13:46, Michael Van
Canneyt wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.DEB.2.21.1911091445530.12738@home">
<br>
<br>
On Sat, 9 Nov 2019, Marco van de Voort wrote:
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">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).
<br>
<br>
</blockquote>
Start with asking why you feel the need to do it, and how much
would be enough.
<br>
</blockquote>
<br>
It's never enough:
<br>
<a class="moz-txt-link-freetext" href="http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html">http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html</a>
<br>
<br>
Michael.<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
fpc-devel maillist - <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
</blockquote>
</body>
</html>