Am 16.12.2019 um 23:08 schrieb Marco van de Voort:
Op 2019-11-21 om 22:56 schreef Sven Barth via fpc-devel:
In the meantime I've managed to fix the dynamic package support that
had experienced a bit of bit rot in the last years. Though I've
currently only tested Win32 and Win64 (x86_64-linux a
Op 2019-11-21 om 22:56 schreef Sven Barth via fpc-devel:
In the meantime I've managed to fix the dynamic package support that
had experienced a bit of bit rot in the last years. Though I've
currently only tested Win32 and Win64 (x86_64-linux as well as
*-darwin *should* work as well). And as b
> Does that mean in some situations, if you have a small, tight loop, it
> might be better to optimise over speed in some very rare cases? For
> example, turning MOV EAX, $ into OR EAX, $FF to squeeze out a
> few extra bytes, even though the instruction introduces a false dependency.
Laten
To optimise SIZE over speed, sorry. Missed a word out.
On 22/11/2019 09:04, J. Gareth Moreton wrote:
Does that mean in some situations, if you have a small, tight loop, it
might be better to optimise over speed in some very rare cases? For
example, turning MOV EAX, $ into OR EAX, $FF t
Does that mean in some situations, if you have a small, tight loop, it
might be better to optimise over speed in some very rare cases? For
example, turning MOV EAX, $ into OR EAX, $FF to squeeze out a
few extra bytes, even though the instruction introduces a false dependency.
Gareth ak
> Op 10/11/2019 om 11:17 schreef Marģers . via fpc-devel
> > Most processors have a fairly large uop cache (up to 2048 for the newest
> >> generations iirc), so this would only be for the first iteration? Do you
> >> have a reference (agner fog page or so) or more explanation for this
> >> that de
Am 10.11.2019 um 16:06 schrieb Michael Van Canneyt:
On Sun, 10 Nov 2019, J. Gareth Moreton wrote:
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an ill
Op 10/11/2019 om 16:02 schreef J. Gareth Moreton:
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an illusion,
along with unfair comparisons with GCC (a b
Am 10.11.2019 um 15:47 schrieb Marco van de Voort:
(and btw, if you are serious about these scenarios, drop all
optimization work immediately, and start working on packages :-)
I don't know if that would help much, cause especially on Windows every
application would probably provide its own set
Am 10.11.19 um 18:01 schrieb J. Gareth Moreton:
Fair enough - thank you.
This is a bit of a micro-optimisation for the compiler in regards to
what I've just done, but I've noticed that, a couple of times, commands
to the effect of the following appear:
tasmlabel(symbol).decrefs;
if tasmlabel
Fair enough - thank you.
This is a bit of a micro-optimisation for the compiler in regards to
what I've just done, but I've noticed that, a couple of times, commands
to the effect of the following appear:
tasmlabel(symbol).decrefs;
if tasmlabel(symbol).getrefs = 0 then
...
That is... derefer
Am 10.11.19 um 17:42 schrieb J. Gareth Moreton:
Some of the "condition_in" functions need expanding though, and I don't
yet have an answer if it's okay to do operator overloading in the
compiler source (so I can do things like "if (jmp1.cond in jmp2.cond)
then", for example, instead of the mo
That seems fair, yep. Currently, vectorcall, and the more intricate
parts of the System V ABI, is only really beneficial when interfacing
with third-party libraries or when programming in assembly language.
Sorry if I've given you a headache with my stubbornness and passion.
I'll try to beha
Am 10.11.19 um 16:02 schrieb J. Gareth Moreton:
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an illusion,
along with unfair comparisons with GCC (a behe
On Sun, 10 Nov 2019, J. Gareth Moreton wrote:
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an illusion,
along with unfair comparisons with GCC (a beh
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an illusion,
along with unfair comparisons with GCC (a behemoth with corporate
support) and Microsoft Visua
Op 09/11/2019 om 15:51 schreef 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
Op 10/11/2019 om 11:17 schreef Marģers . via fpc-devel
Most processors have a fairly large uop cache (up to 2048 for the newest
generations iirc), so this would only be for the first iteration? Do you
have a reference (agner fog page or so) or more explanation for this
that describes this?)
I
On Sun, 10 Nov 2019 02:23:03 +
"J. Gareth Moreton" wrote:
> Does the smart linker strip out LCL components that are not used, or
> must everything that's registered in a package or unit be included?
If you mean with "registered" the RegsiterClass or RegisterComponents
functions:
If it is r
> Op 2019-11-09 om 02:24 schreef Marģers . via fpc-devel:
> >
> > 3) it changes code location (code cross page boundaries). For my particular
> > cpu there are 64 byte code page. If loop can fit in it, speed is twice as
> > it overlaps even one byte over page boundary. Jumping forward is ok (as
J. Gareth Moreton schrieb am So., 10. Nov.
2019, 03:23:
> Does the smart linker strip out LCL components that are not used, or must
> everything that's registered in a package or unit be included? Granted,
> since forms are being read from a resource file, I doubt it can really be
> tied into the
Does the smart linker strip out LCL components that are not used, or
must everything that's registered in a package or unit be included?
Granted, since forms are being read from a resource file, I doubt it can
really be tied into the compiler that closely.
Gareth aka. Kit
On 09/11/2019 15:50,
J. Gareth Moreton schrieb am Sa., 9. Nov. 2019,
16:20:
>
> On 09/11/2019 15:14, Michael Van Canneyt wrote:
> >
> >
> > On Sat, 9 Nov 2019, J. Gareth Moreton wrote:
> >
> >> Competitions aside, there are times where space is a premium, whether
> >> it be from distributing an application on a DVD,
On Sat, 9 Nov 2019, J. Gareth Moreton wrote:
I tend to think more size gains can be obtained from more aggressive
smartlinking.
The smartlinking is sometimes disabled by the way code is written.
To give an example, pas2js has a switch to convert published to public
sections. As a result, th
On 09/11/2019 15:14, Michael Van Canneyt wrote:
On Sat, 9 Nov 2019, J. Gareth Moreton wrote:
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
On 09/11/2019 13:46, Michael Van Canneyt wrote:
It's never enough:
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
Michael.
That level of byte-counting is just plain insanity, even for me! Still,
when it comes to byte-counting, I did do something similar in my first
ever patch
On Sat, 9 Nov 2019, J. Gareth Moreton wrote:
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 sing
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
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 jus
Op 2019-11-09 om 02:24 schreef Marģers . via fpc-devel:
3) it changes code location (code cross page boundaries). For my particular cpu there are 64 byte code page. If loop can fit in it, speed is twice as it overlaps even one byte over page boundary. Jumping forward is ok (as expected code fl
Op 2019-11-08 om 23:37 schreef J. Gareth Moreton:
It is a good point. With my C++ programs, I tend to compile with
everything statically linked and self-contained, since it tends to be
smaller than a dynamically-linked program plus the redistributable
combined (and the risk of "DLL Hell" mean
> By the way, what is your 'particular CPU'? If it's not Intel-based,
amd zen 1. gen - the same x86_64. Not much help for testing on other platforms.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailma
Thanks Marģers,
That makes a lot of sense. The jump sizes and indices for local
variables is a big one. On Intel processors, when generating addresses,
if the byte displacement fits into a signed byte (-128 to 127), then
said displacement only takes a byte to store... outside of that range i
blobing - i meant unnecessarily increase in size, that function loses good
shape. There is no such word "blobing" in English. My bad.
let me periphrases 'just wrong' - 'questionable right'. Currently inlining are
left in hands of programmers. And it is abused as magical performance booster.
Fo
It is a good point. With my C++ programs, I tend to compile with
everything statically linked and self-contained, since it tends to be
smaller than a dynamically-linked program plus the redistributable
combined (and the risk of "DLL Hell" means you can't just install the
redistributable in the
08.11.2019 16:28, J. Gareth Moreton:
[...]
No gain? Wow, is whole-program optimisation that underperforming? Given
the bloated size of FPC's binaries compared to, say, what a mainstream
C++ compiler than do, I would have thought that there could be a lot
Keep in mind that pretty much any tiny M
i'm willing to accept I have a lot to learn if you can educate me on
little intricacies like that, so I may better submit code to the
compiler. I don't want to say it's 'just wrong' though as there might
be gains in some situations. I guess it has something to do with memory
page sizes, right
Can you explain what you mean by 'blobbing'?
On 08/11/2019 19:36, Marģers . via fpc-devel wrote:
- Identifying functions that are only used once. This became a slight point of
contention between Florian and myself, because I inlined a couple of functions
Inlining every once used function is j
> - Identifying functions that are only used once. This became a slight point
> of contention between Florian and myself, because I inlined a couple of
> functions
Inlining every once used function is just wrong. Gain from eliminating call and
function prologue and epilogue might not be suffic
Thanks for the explanation. I still have a lot to learn with some
things. I guess when you compare yourself to the behemoths, you're
always going to look sloppy.
Things that come to mind that could be possible when I think about
whole-program optimisation and smart linking:
- Identificatio
J. Gareth Moreton schrieb am Fr., 8. Nov. 2019,
14:28:
>
> On 08/11/2019 13:14, Sven Barth via fpc-devel wrote:
> > ...
> > What's stopping that? Simple: no driving need. It's just work for
> > something that has essentially no gain.
>
> No gain? Wow, is whole-program optimisation that underperfo
On Fri, Nov 8, 2019 at 10:02 AM J. Gareth Moreton
wrote:
> I guess that's the consequence of Microsoft Visual C++ having such a large
> market share.
>
I mean, GCC is far more widely used than MSVC (and actually generates
rather smaller binaries usually.)
Also the Clang version of the MS compil
I guess that's the consequence of Microsoft Visual C++ having such a
large market share.
Gareth aka. Kit
On 08/11/2019 14:55, Ben Grasset via fpc-devel wrote:
On Fri, Nov 8, 2019 at 8:28 AM J. Gareth Moreton
mailto:gar...@moreton-family.com>> wrote:
The large binary sizes feel like an el
On Fri, Nov 8, 2019 at 8:28 AM J. Gareth Moreton
wrote:
> The large binary sizes feel like an elephant
> in the room that no-one talks about.
>
Relatively speaking, FPC actually does very well as far as binary size for
a language that specifically aims to have robust RTTI functionality. C++
bina
On 08/11/2019 13:14, Sven Barth via fpc-devel wrote:
...
What's stopping that? Simple: no driving need. It's just work for
something that has essentially no gain.
No gain? Wow, is whole-program optimisation that underperforming? Given
the bloated size of FPC's binaries compared to, say, what
J. Gareth Moreton schrieb am Fr., 8. Nov. 2019,
11:20:
>
> On 08/11/2019 09:49, Sven Barth via fpc-devel wrote:
> > ...
> > The compiler is compiled multiple times anyway when bootstrapping and
> > the need for the scripting there is not only the WPO, but the repeated
> > compilation of RTL and c
On 08/11/2019 09:49, Sven Barth via fpc-devel wrote:
...
The compiler is compiled multiple times anyway when bootstrapping and
the need for the scripting there is not only the WPO, but the repeated
compilation of RTL and compiler.
Also the compiler's infrastructure is currently not geared to
J. Gareth Moreton schrieb am Fr., 8. Nov. 2019,
04:01:
> Speaking of whole program optimisation, it always seems very fiddly to
> set up, to the point that the FPC bootstrapper needs a script to get it
> working. Not exactly user-friendly and practically demands learning a
> separate skill to ge
48 matches
Mail list logo
