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
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.
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
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
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,
Hi,
I would like to raise some concerns about the current implementation
of ordinal bithelpers in r 43417.
I do not have the rights to re-open that issue, and I did not want to
open a new one for it.
My concerns basically are the same I described in the associated
bugtracker issue
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
> - 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
Made some more updates to the jump optimisation patches, removing code
duplication and also some untidy debugging code.
Gareth aka. Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
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:
-
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
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
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
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++
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,
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
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
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
18 matches
Mail list logo
